Forum Discussion
APM - LDAP Authenticaion multiple domains
We have an LTM using the APM module for our Outlook Web Access service.
We have users from numerous AD domains who need to authenticate. In the visual policy editior i created an LDAP auth for one domain, then if a user fails that one, it will fallback to another LDAP auth for the other domain.
Looking at the logs i can see the user fail on the first LDAP query, but then it does not try the seccond LDAP query... Any thoughts on this?
Basically I need to be able to authenticate users from different domains, it would be good if this could be done using the domain\username method.
SSO is also in use here...
- JRahmAdminThis is possible today, but not for the faint of heart. You'll need to create a "front door" virtual for the APM session, and then a virtual for each domain, each requiring its own access policy with NTLM SSO, iRules, etc. v11, announced late last month and due to ship shortly, will have some built-in support for this, though I have not yet seen the details.
- Luca_55898NimbostratusThanks Jason,
- JRahmAdminiRules tie it all together. I can try to put an article together to detail the process, but it'll be next week at the earliest. Your SE might have a faster path to mocking this up if you can't wait.
- Luca_55898NimbostratusThat would be usefull. thanks.
- worf359_98967NimbostratusI have a similar, but slightly different requirement. In the visual policy editor I have a AD Auth for one domain, which should fallback to another domain if that one fails.
- farache_28983NimbostratusI have V11.2 and have this same issue.
- Wim_Vermoens_98Nimbostratus
Hi all
I resolved this issue by doing first an LDAP query to first specific domain. in a form like this. this also resolves the problem that you cannot have both UPN and pre-windows 2000 logons. In our case you now can logon with the both logon forms, AND for multiple domains
Logon Page -> Fallback -> Variable assign (Custom Variable: session.custom.last.username = Session Variable session.logon.last.username) -> Fallback -> (macro Domain 1) -> LDAP Query to first domain (|(UserPrincipalName=%{session.custom.last.username}@%{session.logon.last.domain})(sAMAccountName=%{session.custom.last.username}))
-> Variable Assign session.logon.last.username = LDAP attribute name sAMAccountName Expression on branch 1: expr { [mcget {session.logon.last.username}] equals "" }
So if this variable assign sets the value of session.logon.last.username to "" we will not continue to AD Auth, but we will flow into the next macro for the second domain. This is how we know that the query failed to the first domain.
Branch 1 -> Failure -> Macro Domain 2) -> repeat same steps for domain 2 Fallback -> AD Auth -> Succesfull -> Allow ending -> Fallback -> Deny ending
So the only extra thing you need to setup is an extra (per domain) AAA pool from the LDAP type.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com