Admin Auth with AD

[#1]

I have a test NIOS 8.2.4 environment and working with AD auth for Remote Admin logins. With everything setup according to the Admin Guide, I can't get any AD accounts to login to the Grid Manager.  I just get "Invalid Login" at every attempt.

Here's the steps I've taken thus far.  Following the NIOS Admin Guide, I have:

1) Created Authentication Server Groups --> Active Directory Service with three DCs

2) Created Authentication Policy, adding the created AD Service

3) Created Remote Admin group with the name EXACTLY as labeled in AD

4) Added the Admin group under "Map the remote admin group to the local group in this order" field with the group as first in the order.

Is there a log to show the error occurring in this situation?  I've tried multiple login formats (username, domain\username, user.name@domain.com) with no success.  Any help is appreciated!

Thanks,

WT

[#2]

Just found the Audit logs.  Showing the following:

Action: LOGIN_DENIED

Message: to=AdminConnector ip=192.168.123.123 info=AD,Local apparently_via=GUI

The test against all defined Domain Controllers were successful.

[#3]

I had it setup to use some domain accounts as administrators of the ... The bottom line is Active Directory Users can login to the XG firewall. hp printer error 79

[#4]

I still can't login under AD credentials.  Logs from the Grid Manager and my Domain Controllers both display either login failed/denied, but don't provide any useful data as to why it's failing.

[#5]

We had a similar issue in one of our labs.  It turned out to be an LDAP GPO within the domain.  I do not recall that exact setting.  Give a few and I will see if I can dig up the fix.

[#6]

Still looking but, if I recall correctly it was the DC GPO for requiring LDAP sigining.  I will advise whern I locate our document.

[#7 · Accepted solution]

I was finally able to successfully login via LDAP.  For whatever reason, the AD options were unsuccessful.  I'll keep tinkering, but at least for now one form of external auth works.  

[#8]

Here is what resolved our AD authentication in our lab.  Let me know if this fixes your problem.  If so, Kudos are always accepted. 

https://support.microsoft.com/en-us/help/2545140/fast-esp-unable-to-use-active-directory-accounts-fo...

[#9]

https://support.microsoft.com/en-us/help/2545140/fast-esp-unable-to-use-active-directory-accounts-fo...

The page was not found.

Do you have details about the procedure ?

Thanks

[#10]

Hi just wondering,

have you map the AD user to that particular group that you've created for infoblox?

this suppose to be config from the domain controller

[#11]

So I had to do a tcpdump and using a scratch account and unencrypted connection to AD to find the issue.  If you're having trouble mapping infoblox groups -> AD groups , and you're using a non-standard search path for your admin groups .. you must NOT add the base-dn of the domain to the search in Administration -> Administrator -> Authentication Policy -> {Active Directory Server} -> Additional Search Paths; as Infoblox does it for you.  So for instance:

• domain: ad.foo.com
• makes the baseDN dc=ad,dc=foo,dc=com
• if your users are under say "ou=Domain Users,ou=Domain,dc=ad,dc=foo,dc=com"
• when infoblox finds the user entry, it doesn't use the DN as listed .. but tries to create it using the search paths. 
• so if you're gonna use the addl search paths .. you have to put them in WITHOUT the baseDN like "ou=Domain Users, ou=Domain" .. and infoblox will append the baseDN for you

[#12]

For anyone else also hitting the deadlink it looks like PKIsolutions mirroed the KB

https://mskb.pkisolutions.com/kb/2545140

tl;dr Your DC is probably forcing signed ldap connections. You really should load your root CA cert into infoblox so you can do ldaps, but if not you can flip the regkey. https://support.microsoft.com/en-us/topic/2020-2023-and-2024-ldap-channel-binding-and-ldap-signing-r... goes into details on how to tweak the registry key and what the options are.  

Also I should note I currently do have some other services doing non secure ldap lookup successfully even though the registry is set to only allow secure lookups.