Issue with AD authentication

[RSAAdmin]

I’m facing a strange issue in which I have added AD group of my team and mapped “Analyst” role for the group in external group mapping. However not all members of the group are unable to login to SA. I have tried using 10 different users out of 6 were able to login.

Any suggestions to resolve this issue?

[Anonymous · Accepted solution]

Hello,

I am the Product Manager for Security Analytics.  What would be very helpful here is some additional context on your configuration.  You mention that some users of the group can login, but some can't.

• Are you using PAM or the built-in AD functionality?
• What is different about the two users? 
• Are the group members of different domains?  SA's built-in AD capability only supports group members who are in the same domain as the group.
• Is the user that can't login a member of the mapped group via another group?
• Do the users who cannot login have any special characters in their username?
• Can you confirm whether your AD instance is using UserPrincipleName (UPN) or sAMAccountName for the username? In 10.4.0.2 and older, the built-in AD functionality uses only the UPN field to match on user ID, so if the UPN field in your AD users isn't implemented consistently across all accounts, that could possibly explain it.  In a near-future release, you will be able to choose between these two fields for username mapping.

The answers to all these questions could help determine whether this is a misconfiguration, a bug, or an unsupported configuration.

For all those having issues setting up AD, opening a case with Customer Support will help us to track your problems internally and help to improve the experience in a future release.

Thank you!

[TimUnderhay]

I have absolutely no idea how my post showed up as Steve Brzozowski, but he was not the author of that last message.  'Twas I who wrote it.

Tim Underhay

[RSAAdmin]

1. Built-in AD functionality w/ 10.4.0.2
2. The users are identical permission/group wise
3. Single domain, members and group are the same
4. Only one group is mapped that contains all the users in questions
5. No special characters in the user name
6. sAMAccountName, UPN suffix in our environment uses our different external domain
   

Note: Users that logged on prior to the SSL option being enabled can still log in just fine. New users cannot log in since the SSL option was enabled.

[Anonymous]

Thanks Tim,

So I took your questions about the UPN/SAM to our Windows team and all our issues were solved .  We found one was the incorrect SAM to UPN.  The other actually had the wrong domain in the UPN user@xxx.xxxx.xxx was actually user@xxx.xxx

[TimUnderhay]

Tgiacchetti, I can't account for the inconsistent behaviour between the SSL/non-SSL setting, as it's something I haven't seen before.  Unfortunately there is little that can be done to debug the connection from the SA side once SSL is turned on, other than to run tcpdump to confirm the LDAP traffic is flowing.  Do you see any errors in /var/lib/netwitness/uax/logs/sa.log when one of those users attempts to log in?  Are you 100% sure something on the AD-side isn't causing the problem, as all the SSL checkbox really does is wrap the LDAP session in an SSL socket.  One other thing to check is did switching on SSL change the port to 3269?  If so, you might want to try changing it to 636, which is the standard LDAPS port.

Also, would you kindly expound on your answer number 6?

I would advise you to open a case with Customer Service so that it can be tracked and if necessary escalated to engineering.

As a workaround, your other option would be to use PAM.

[TimUnderhay]

Sean, I'm pleased to hear you got it working!

[RSAAdmin]

There is no message for the user when the correct credentials are used, it just redirects them to the login page. When the user purposefully types a bad password in it does give a fail message on the login page as well as in the logs:

2015-01-22 20:52:32,559 [qtp737468135-116885] INFO  com.rsa.netwitness.carlos.security.authentication.ad.util.LdapExceptionUtils - Active Directory authentication failed: Supplied password was invalid

I am able to use SSL LDAP via 636 on some of our vendor's appliances as well as Archer with no problems. I have also tried 636 and 3269 using SSL from the shell using the ldapsearch utility and I am able to perform queries.

Following up question 6, the UPNs are all username@zzz.com but our domain is zzzx.com

I was looking at the PAM option and made it through the configuration up to the NSS LDAP. It seems there is a discrepancy with a dependency for the nss-pam-ldapd package:

yum --enablerepo=sa install nss-pam-ldapd

...

Error: Package: nscd-2.12-1.132.el6_5.3.x86_64 (RSASoftware)

           Requires: glibc = 2.12-1.132.el6_5.3

           Installed: glibc-2.12-1.132.el6_5.4.x86_64 (@sa)

               glibc = 2.12-1.132.el6_5.4

[RSAAdmin]

Hello all,

I tried the same method given done y Sean and voila!! it worked.

It was incorrect SAM to UPN mapping. i modified it for one user and it worked.

Thanks to Tim as well

[TimUnderhay]

Thomas,

The behaviour you've described sounds like an authorisation failure, since authentication is succeeding.  SA is evidently not able to map the mapped group's users back to its members.  I would say the most likely explanation is the discrepancy in your UPN field, since this is the field that SA uses.

We discovered the problem you reported with the nscd package on our repo late last week and are in the process of resolving it, though I don't yet have an ETA.

One other option that may be available to you is to install the nscd-2.12-1.132.el6_5.4.x86_64.rpm package that's available on CentOS' own repository.  Some customers would consider option two dangerous since it doesn't have our 'seal of approval' on it, so the decision on how to proceed is yours.

# wget http://vault.centos.org/6.5/updates/x86_64/Packages/nscd-2.12-1.132.el6_5.4.x86_64.rpm

# yum install nss-pam-ldapd nscd-2.12-1.132.el6_5.4.x86_64.rpm