Authentication Manager 8.6: Active Directory Identity Source

[Samuris]

I'm new to RSA. I'm running AM 8.6 and trying to add my active directory domain as an identity source, but failing. 

I set type to Microsoft Active Directory, Directory URL to ldap://server or ldap://server.domain.com (tried both), Directory User ID to mydomainadminaccount@domain.com and enter the password accurately. Then I hit Test Connection and always get the same error: Test Failed. Invalid user name or password specified.

Every other configuration I try gets me the error "Test Failed. Unable to establish a connection to the directory" so at least with the above error it's connecting. For some reason I can't authenticate and get the connection working.

Anybody have any ideas?

[DanielRobinson]

Some things to check: 1) Is the RSA appliance able to resolve the domain controller by hostname? e.g. from the RSA appliance command line: nslookup domain.com.  2) Can the RSA appliance ping the domain controller?  (can be done via command line or via operations console > administration > network > network tools).  3) Is the RSA appliances' clocks in sync with the domain controller's clock?  4) Is the Active Directory account being used by the RSA appliance to authenticate with the domain controller locked-out, is using the correct password, and has sufficient permissions?  5) Is TCP/Port 389 being allowed between the RSA appliance and the domain controller  e.g. check the host firewall, physical firewall, switch ACL.  The tcpdump tool is available via command line on the RSA appliance.  Become root via sudo su -    and run tcpdump -nni eth0 "host ip address of domain controller" -Xs0 | more    and when it works, you'll see a DNS query and response, and then see a three-way-handshake over TCP/port 389 followed by pushing of data where you will actually see, in the clear, the domain account you are using and the password it is using.  If you use LDAPS, by the way, you won't be able to see it because it will be encrypted.

[Samuris]

Thanks for the suggestions.

1) Yes I have checked DNS. I logged onto the appliance, was able to resolve the hostname via DNS.

2) Yes I was able to ping the DC.

3) The clocks were out of sync initially, but I fixed it. It made no change.

4) The account being used to test the connection is my domain administrator account. It is not locked out, the password is correct, and permissions should be good.

5) I ran the tcpdump command as you explained. I got a bit of traffic back, but how can I tell when it does a three-way handshake over port 389?

[DanielRobinson]

To ensure the traffic is just port 389 and to cut down on any traffic noise we don't care about, we'll add that to the tcpdump statement, and I'll use IP 192.168.1.2 to represent your domain controller: tcpdump -nni eth0 "host 192.168.1.2 and port 389" -Xs0 | more      And to clarify, you want to start this command just before you hit the Test Connection button for the Identity Source.  The results should immediately occur.  1) The first TCP packet should have the RSA IP send a request to 192.168.1.2.389 with "Flags [S]" set. 2) The second packet should be the 192.168.1.2.389 sending a packet to RSA IP with "Flags [S.]" and an "ack" on that line.  3) The third packet should have the RSA IP send a "Flags [.], ack" back to 192.168.1.2.389.  That would be the Syn, Syn-Ack, Ack three-way-handshake for a successful TCP port 389 connection.  Then, the fourth packet would be a "Flags [P.]" set where the RSA IP "pushes" the domain admin account name and its password inside that packet to the domain controller.  The -X option allows you to see the packet contents, so you should be able to see this account name and password.  And, in the tcpdump command, I am making the assumption that eth0 is your transport interface your RSA appliance is using to communicate with the domain controller.

[Samuris]

Well I see the two packets with Flags [S.], two with Flags [.], then two with Flags [P.] but the second P doesn't contain my password, but I do see an ldap error. X80090308:.LdapErr:.DSID-0C090447,.comment:.AcceptSecurityContext.error,.data.52e,.v3839.

Then I see a packet with Flags [F.]

[DanielRobinson]

Sounds like LDAP configuration on the domain controller needs adjusting or security policy settings associated with it.  I am not very familiar with troubleshooting LDAP, but I found a number of results from doing various searches for those different values in that LDAP error string you provided, so maybe one of those will be useful if you search on those error code values.  Here is one site I am not familiar with, but looked promising and might help ( https://ldapwiki.com/ ) , and there is also the ldp.exe tool that comes with Windows Server that might help.  From the searches, I did see that the code 52e is associated with authentication issues, and I did see a reference to Security Options settings related to LDAP server signing requirements found under Domain Controller Policy, but I almost didn't mention these here because I didn't want to send you down a rabbit hole.  Maybe someone more knowledgeable in LDAP might can chime in.  Good luck! 

[EmrhysStatum]

I wasnt able to add the AD Identity source initially. I tried a number of methods without any luck. After importing all the domain certs, I tried using Microsoft ADLDS which allowed me to progress to the mapping step. Once here it stated that my source was incorrect and I switched the source from ADLDS to AD and was successful. Not sure if this will help you but this helped me. Just a note that I did not use a domain admin account and I'm not sure why that is a requirement.