Custom Expression Not Working with AD Authentication (directory search successful)

[mmartin_]

Hello,

SA4500 FIPS (remote cluster)

Version: 8.0R3:2 (build 30619)

When I use an LDAP authentication server type to search AD, my custom expressions to match OU's work just fine (userDN.OU = "whatever").  When I do the same with an AD server type, they do not match.  The directory is being searched and the attributes are being returned.  I can see them just fine in the trace, but the rolemapping says "no match" for those rules.

I configured everything from scratch for the AD auth -  All new sign-in policy, auth server, realm, role mapping, expressions, etc. - just to be sure.

I tried to match on both forms of the OU name listed in the variables.  No luck.  Again, this works just fine with LDAP as the auth type... and the logs look identical, except there is a match.

Info    PTR10305    2014/04/16 10:12:00 - Hostname - [*.*.*.*] - DOMAIN\user(Copy of Portal)[] - Variable userDN.OU = "OU NAME GOES HERE"
Info    PTR10305    2014/04/16 10:12:00 - Hostname - [*.*.*.*] - DOMAIN\user(Copy of Portal)[] - Variable [email protected] Active Directory - New.OU = "OU NAME GOES HERE"

Info    PTR10218    2014/04/16 10:12:00 - Hostname - [*.*.*.*] - DOMAIN\user(Copy of Portal)[] - No match on rule 'userDN.OU = "OU NAME GOES HERE"'
Info    PTR10218    2014/04/16 10:12:00 - Hostname - [*.*.*.*] - DOMAIN\user(Copy of Portal)[] - No match on rule '{[email protected] Active Directory - New.OU} = "OU NAME GOES HERE"'

Any idea why this is happening?

[mmartin_]

I understand that I could add an LDAP server, but at that point, I might as well just use it for auth too and not waste my time configuring two servers.

The reason why I thought this may (should) work is because the policy trace shows the attributes/variables coming back the exact same way when I enable "Group search with LDAP" in the AD Server type:

AD Type with Group search with LDAP:

Variable userDN.OU = "OU NAME GOES HERE"

LDAP Server Type:

Variable userDN.OU = "OU NAME GOES HERE"

So the fact that I can't use a custom expression to match on that is a limitation of the software (confirmed by JTAC), not a limitation based on what information I'm getting back from the AD server.  Clearly, if the same data is being displayed in plain text, right in front of me, the software could be written to give the ability to match on it.

Per JTAC, the custom expressions won't match based on how the attributes are stored in the user record.

This is fine though now that I have a clearer understanding.  I don't mind using LDAP.  Plus JTAC informed me that LDAP is the better choice and only to use the AD server type in the following scenarios:

"when you need machine authentication without certificates or trusted domains for user and group lookup"

Thanks!

[mmartin_]

Thanks!  That would help.  I spent a few hours trying to make it work before I put in a ticket since I assumed I had to have made a mistake somewhere in my config since the traces looked the same, except no match.

[Kita_]

Thanks for the feedback, mmartin.

I will discuss this internally to see if we can remove this from the policy trace to avoid the confusion for other customers.

[mmartin_]

Per JTAC - not supported with AD/NT type servers.  Must be LDAP, but LDAP is the better choice anyway and is more efficient per their advice.

[SVK_]

Hi Martin,

userDn.* is an LDAP attribute. with the Ad server instance you can specify a LDAP server for User Directory/Attribute:.

Essentially it would connect to the LDAP auth server instance to fetch any attributes/group membership.

Thanks & Regards,

SVK