Looking at the documentation in <SASHome>/SASFoundation/9.4/utilities/bin/sasauth.conf, there are three ways to authenticate a user (BIND, MATCH, or QUERY). We decided to go with the MATCH or QUERY methods for authentication. However, we've run into a few errors with both methods.
With MATCH, it seems that the user is found, but SAS runs into an issue with getting the encrypted password.
20190111-14:30:01 Authenticating user <USERNAME> via ldap 20190111-14:30:01 LDAP: Authenticating user <USERNAME> 20190111-14:30:01 Build entry DN: User domain ignored (if any). 20190111-14:30:01 Set LDAP to version 3. 20190111-14:30:01 LDAP: Connecting to <LDAP_URL> 20190111-14:30:01 LDAP: Using protocol version 3 20190111-14:30:01 LDAP: binding to '<LDAP_HOST_DN>' 20190111-14:30:01 LDAP: entrydn is '<LDAP_USERBASE> <LDAP_SEARCHBASE>' 20190111-14:30:01 LDAP: filter is '(&(sAMAccountName=<USERNAME>)(&(objectClass=user)))' 20190111-14:30:01 LDAP: UID is XXX 20190111-14:30:01 LDAP: GID is XXX 20190111-14:30:01 Request failed: 'Did not get encrypted password for user.' ```
With BIND, we're getting an operations error.
20190111-15:23:04 Authenticating user <USERNAME> via ldap 20190111-15:23:04 LDAP: Authenticating user <USERNAME> 20190111-15:23:04 LDAP: Search for user in domain <LDAP_DOMAIN> 20190111-15:23:04 Set LDAP to version 3. 20190111-15:23:04 LDAP: Connecting to <LDAP_DOMAIN> 20190111-15:23:04 LDAP: Using protocol version 3 20190111-15:23:04 LDAP: binding to '<LDAP_HOST_DN>,'XX XX' 20190111-15:23:04 LDAP: Searching for user DN using query '(sAMAccountName=<USERNAME>)' 20190111-15:23:04 DN query failed in domain '<LDAP_DOMAIN>' 20190111-15:23:04 Operations error
I had the following questions:
With MATCH and Active Directory, has anyone had any success with retrieving an encrypted password? I've used the password attribute unicodePwd, which is what our other applications use when authenticating against LDAP.
Is there a way to see the exact DN query that the QUERY method uses to find the user's DN? I'm thinking that this is our best bet with authenticating against LDAP.
Is there an additional setup that we have to do on the SAS EC2 instance to create users? As of now, we only have the sas user which is used to install and run SAS Studio Basic. Does each user in LDAP also need a corresponding Unix system user?
If anyone has successfully set up SAS Studio basic to authenticate against Active Directory (either using ldap or a combination of PAM and LDAP), could you please share an overview of your working configuration?
this is an interesting question. I would personally lay the AD or LDAP authentication onto the shoulders of the operating system itself, with PAM. But this would be my personal choice.
In this sense, with PAM and SSSD (or realm for Active Directory), you can let the operating system to authenticate internally with your Identity Provider, no matter which one. And once oyu do this, and you test that it works, that you can authenticate to the OS with your AD user, you only need to let SAS to use PAM on its terms (see http://support.sas.com/kb/49/432.html )
This would be my choice because then the authentication can be managed by its real experts. Also the authentication is much easier and secure for you, and, furthermore, Google is full of examples on how to do all of that.
This being said, let me answer ayour other questions:
1. I would not ever like to retrieve a password, encrypted or not. The more the confidential information is kept at origin, the best. A secure handshake is better!
2. Yes, there is always is, by increasing the level of the logs of the sas java process. I cannot recall not which one is the right one now, but if you are interested, I am sure SAS Technical Support can give you a hand there
3. If you use this authentication, yes, you would need local and AD user, corresponding, If you use the PAM module, you only need one that is in the AD or LDAP. Of course, extra admin actions would need to be taken then anyways in the SSSD configuration: which users would be part of what local groups, ACLs, roles for each local group, etc. The normal stuff.