on Jan 6, 2015I’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?
Hello,
First check that the users which are not able to get the access on RSA SA, are they really able to get the access with their domains ID's on any of windows network system.
Regards,
Deepanshu Sood.
Hi all,
We are using version 10.4.0.2.
Another strange thing i noticed today is those users who are not able to login if they try wrong password then it do show "Bad Credentials". But with correct password, it keeps showing the login page
I do not have an answer for you, but I have also experienced this issue with 2 out of the 8 AD groups we have. Hopefully someone has an answer.
We've never had complete success with the AD authentication integration, that's going back to 10.0.2. Last serious attempt we made was in 10.3.2. I hope to hear you find some resolution.
Even after the AD auth, the larger problem we had was around how to limit which meta keys a particular user/group can access, you have to assign user/group permissions per meta field. If I recall correctly... its been a while since looking into this heavily. We just restrict access to SA to only certain authorized personnel.
Is the group name in AD has space or any special character ? What method of integration you are using for instance are you using LDAP or PAM?
Also please run "tailf /var/lib/netwitness/uax/logs/sa.log " in SA command line and then try to login to see if it shows any error message .
So I also have this same issue, only with some AD users. We have just implemented new AD groups for SA so I was hoping the users that were having issues would have it fixed but that was not the case.
Some additional info for RSA. I turned on addtional logging to the com.rsa.netwitness.carlos.security to see additional activity.
When the user logs in we get this.
2015-01-15T15:21:06.929 | DEBUG | Processing authentication request for user: xxxxxxx |
But when the user uses the wrong password we get
Authentication for xxxxx@xxxxxxxxx failed:javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]
Again when they use the correct password we see no additional logging and they just return to the log in screen.
I have seen similar errors. However, even when I can get all the users to authenticate correctly, the roles mapped to the imported AD groups never seem to work.
Having the same issues with a new SA install. The only users that are able to login are ones that logged in before the Active Directory SSL option was enabled. With the SSL option now enabled any new users just get redirected to the login page with no error, original users can still log in.
Edit: This is the Active Directory option under Administration -> System -> Security -> Settings, External Authentication set to Active Directory and only with the SSL option set to yes. There are no spaces in the mapped group names.
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.
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!
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
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.
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.
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
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
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
Sean, I'm pleased to hear you got it working!
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
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.
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!