BookmarkSubscribeRSS Feed

SAS Viya 3.2 LDAP for SAS Logon

Started ‎06-30-2017 by
Modified ‎06-30-2017 by
Views 5,436

As a follow on from my previous post, where we looked at the different authentication options for SAS Viya 3.2, in this blog I want to delve into more details on configuring LDAP for initial authentication.


In this blog we’ll examine


  • The implications of using LDAP authentication
  • The prerequisites
  • How authentication is processed
  • How to configure LDAP authentication
  • What to do if the configuration is wrong

LDAP Authentication is the default authentication provider for the SAS Viya 3.2 Visual Interfaces. We must configure a connection to a LDAP Provider for the SAS Viya 3.2 environment to be useable. There are two main types of LDAP provider:


  • Microsoft Active Directory
  • OpenLDAP based Providers

The configuration properties for the two different types of LDAP provider are different.


The main implication of using LDAP is the way in which the SAS Viya 3.2 environment connects to LDAP. The LDAP connection from both SAS Logon Manger and the identities microservice are made as a SIMPLE BIND. This means that the credentials used to make that SIMPLE BIND are exposed on the network.

Multiple connections are made between SAS Logon Manager and the LDAP provider. When an end-user logs into SAS Logon Manager using their LDAP credentials; two SIMPLE BINDS are made. The first SIMPLE BIND is performed as the LDAP service account and the second as the end-user. This means that the LDAP service account credentials are sent over the network for every login to the SAS Viya 3.2 environment. Whilst the end-user credentials are only sent when they log in.

The SIMPLE BIND in itself does not contain any network security. Therefore, you should look to encrypt this connection by using Transport Layer Security (TLS).

TLS can be used on LDAP connections in two different ways. The traditional mechanism is similar to how a web server would be configure for TLS. The TLS is negotiated initially and the connection URI for the LDAP provider changes. In this mechanism we connect to ldaps://hostname:636, where 636 is the standard secure port compared to the default unsecured port of 389. This is very similar to changing a website address to HTTPS from HTTP and the port to 443 from 80. This mechanism is often referred to as LDAPS.

The second mechanism to provide TLS on LDAP connections is called startTLS. With startTLS the connection is made as normal to ldap://hostname:389 and during the initial connection the TLS handshake is performed. So startTLS has the advantage of not requiring any changes to the connection URL. However, the client needs to be able to support startTLS.

For SAS Viya 3.2 the underlying technology powering both SAS Logon Manager and the identities microservice does not support startTLS. However LDAPS is supported and recommended.

Only a single LDAP connection can be defined in SAS Environment Manager. This single connection is shared by both SAS Logon Manager and the identities microservice. This means that only one set of connection details and search filters can be applied to both connections.


Authentication Process

The process of authenticating an end-user is shown in the figure below:



Where the steps are:


  1. The End-User connects to the SAS Logon application and enters their username and password in the login form.
  2. SAS Logon connects to the LDAP provider with a simple BIND using the stored credentials for a service account to search for the Distinguished Name of the end-user.
  3. SAS Logon makes a second simple BIND to the LDAP provider as the end-user using the password entered in the logon form and the Distinguished Name returned from the previous search.
  4. SAS Logon connects to the identities microservice to fetch custom and LDAP group information for the validated End-User.
  5. The identities microservice connects to the LDAP provider with a simple BIND using stored credentials for a service account. Regularly connecting to refresh the cache of users and groups, which is stored in SAS Infrastructure Data Server.



The LDAP connection properties can be configured at two points:

  • As part of the deployment using the sitedefault.yml
  • Post-deployment using the SAS Environment Manager

The default settings for the LDAP connection are geared towards Active Directory. This means that the majority of the defaults will work with Active Directory. While to make OpenLDAP work correctly more configuration items will need to be changed.

Sitedefault File

The sitedefault.yml can be used as part of the Ansible deployment to configure the connection to the LDAP provider. A sample sitedefault.yml is provided in roles/consul/files/sitedefault_sample.yml, within the playbook. Creating a sitedefault.yml in the roles/consul/files directory will enable the automatic configuration of the LDAP provider.

Since the majority of defaults will work for Active Directory to easily configure Active Directory as the LDAP provider you only need the following content in the sitedefault.yml:

             host: '<LDAP HOSTNAME>'
             port: 389
             userDN: '<Service Account DN>'
             password: '<Service Account Password>'
             baseDN: '<OU to start user search from>'
             baseDN: '<OU to start group search from>'


Note: YML files do not use tab – SPACE is King!

So all we are doing with this sitedefault.yml is providing the connection definitions to Active Directory in terms of the host, port, username, and password. Then for both the groups and users we provide the baseDN which is the point in the LDAP tree where any searches will start.

For OpenLDAP things are a bit more complicated. OpenLDAP allows administrators far more freedom with the object classes and information stored against both users and groups. Also OpenLDAP does not automatically provide the memberOf information for a user. Administrators can enable the memberOf information as an additional overlay within OpenLDAP.

A sample sitedefault.yml for OpenLDAP is:

             host: '<LDAP HOSTNAME>'
             port: '389'
             userDN: '<Service Account DN>'
             password: '<Service Account Password>'
             accountId: 'name'
             baseDN: '<OU to start group search from>'
             createdDate: 'createTimestamp'
             distinguishedName: 'none'
             member: 'member'
             modifiedDate: 'modifyTimestamp'
             objectFilter: '(objectClass=groupOfNames)'
             objectClass: 'groupOfNames'
             searchFilter: 'dn={0}'
             accountId: 'uid'
             baseDN: '<OU to start user search from>'
             createdDate: 'createTimestamp'
             distinguishedName: 'none'
             memberOf: 'memberOf'
             modifiedDate: 'modifyTimestamp'
             objectFilter: '(objectClass=inetOrgPerson)'
             objectClass: 'inetOrgPerson'
             searchFilter: 'uid={0}'


Note: YML files do not use tab – SPACE is King!

The settings provided for sas.identities.providers.ldap.connection are essentially the same as the Active Directory case. We provide the host, port, username, and password for making connections. The majority of changes are in how we search for and return group and user information.

For group information we have the following:

Attribute Value
accountId LDAP field: name
Used for short group name in SAS Viya
baseDN Starting point for the group search
createdDate LDAP field: createTimestamp
Used to show created date
distinguishedName none (see notes below)
member LDAP Field: member
Used to list group members
modifiedDate LDAP field: modifyTimestamp
Used to show modified date
objectFilter '(objectClass=groupOfNames)'
Used to ensure only groups are,returned from searches
objectClass 'groupOfNames'
An object class used in the,group definition in LDAP
searchFilter 'dn={0}'The search filter used to find,a group, search is dn={entered value}


For user information we have the following:

Attribute Value
accountId LDAP field: uid
Used for username in SAS Viya
baseDN Starting point for the user search
createdDate LDAP field: createTimestamp
Used to show created date
distinguishedName none (see notes below)
memberOf LDAP Field: memberOf
Used to list what groups a user is a member of
modifiedDate LDAP field: modifyTimestamp
Used to show modified date
objectFilter '(objectClass=inetOrgPerson)'
Used to ensure only users are,returned from searches
objectClass inetOrgPerson
An object class used in the,user definition in LDAP
searchFilter 'uid={0}'
The search filter used to find,a user, search is uid={entered value>


Key Information: distinguishedName must be set to none for OpenLDAP

The distinguishedName attribute for both the group and user search when using OpenLDAP must always be set to none. This is required in order to force the identities microservice to behave slightly different in how it fetches the groups the user is a member of. Essentially, with Active Directory, SAS Viya uses the distinguishedName attribute to do this lookup. In Active Directory, this happens to be an explicit LDAP field. Not all LDAP servers support this (OpenLDAP included) however, so an alternative mechanism is needed and setting the distinguishedName attribute to none triggers this alternative mechanism.

The examples above will both use standard unencrypted LDAP connections. To enable LDAPS we need to change an additional property in sas.idenities.providers.ldap.connection as well as updating the port value from 389 to 636. The addition property is url and should be set as follows:

url: 'ldaps://${}: ${sas.identities.providers.ldap.connection.port}'


Automatically Adding an Administrator

One final useful option with the sitedefaul.yml file is to automatically add an administrator to the SAS Viya 3.2 environment. By adding the following to the end of the sitedefault.yml:

             administrator: '<USERNAME>'


Will add the <USERNAME> to the SAS Administrators custom group. This means that any further configuration can be performed using this LDAP account rather than the sasboot account.


SAS Environment Manager

If you do not want to use the sitedefault.yml file to automatically configure the LDAP provider you can set all of the same property values using SAS Environment Manager. At the end of the deployment you can search the SAS Logon Manager log file for the URL to set the sasboot user’s password. For example running the following command:

cat /var/log/sas/viya/saslogon/default/sas-saslogon_* |grep sasboot


Will output something similar to:

Reset the password for the initial user "sasboot" by using this link: /SASLogon/reset_password?code=nVimwlvAlv


Where the code value will be different. Once you set the password for the sasboot user you will be automatically redirected to the configuration section of SAS Environment Manager. From this screen you can set all the properties for:

  1. sas.identities.providers.ldap.connection
  3. sas.identities.providers.ldap.user

The values entered in SAS Environment Manager will be the same values provided for the example sitedefault.yml files above.



Any issues with the LDAP connection properties can be corrected using SAS Environment Manager, you will need to be logged in with the sasboot user or a member of SAS Administrators. Remember to assume the SAS Administrators role to be able to make changes. Also the link to reset the sasboot password is only valid for 24 hours. If more than 24 hours have passed then SAS Logon Manager will need to be restarted.

Changes made to the LDAP connection properties should immediately take effect; at most there might be a 30 second delay. For example if the telephone number field is not being correctly returned for users, a change to the sas.identities.providers.ldap.user telephone field will immediately change the return information from the LDAP Provider. There is no need to restart any of the SAS Viya 3.2 services.



The LDAP connections for both the SAS Logon Manager and identities microservice are configured to use a pooled connection. The settings in sas.identities.providers.ldap.connection define the pool used for these connections. The default maximum number of active connections from the pool at the same time is 8. While this should be sufficient for initial deployments the pool configuration will probably need to be tuned for either a number of concurrent logins or long/complex LDAP searches.


Stuart Rogers


Hello @StuartRogers,


I am facing an issue during an LDAP integration with Viya (3.3 but I guess little difference with 3.2) due to some customer specifics.


Their LDAP server is Redhat Identity Management (IDM aka IPA) and after my efforts, it seems the LDAP schema is closer to OpenLDAP than a standard LDAP. But also some other customizations, such as not having objectClass=inetOrgPerson (hence no email apparently available or phone) and implementing instead classes such as posixGroup and posixAccount.


Do you have any experience with integrating Viya with RedHat DM/IPA? I do not manage to match the attribute mappings and the identities service is having an infinite loop. The error received is on finding an exception and not finding the  javax class PagedResultsControl


Any tip or referral to the right person would highly help.


Kind regards,



Hello @JuanS_OCS,


The documentation for RedHat IdM ( suggests that by default there should be both email and several phone number fields for the user.  These are flagged as optional so might not be used in your case.


The absence of email and/or phone number should not cause issues with SAS Viya 3.3 loading the end-user information.  The error you are seeing sounds more like; an issue with what is expected to be a unique value is not a unique value, or that you are hitting issues with the number of returned results.  I would encourage you open a Technical Support track where this can be investigated in more detail.


Thank you for your time.



Hi @StuartRogers,


many thanks to you, for your time and the information. We have a ticket with SAS Technical Support, running for a few days. We are waiting for the results of the analysis by our regional Technical Support. While I was investigating the problem as well by myself, I found your article, very interesting and useful.


After reading you, it seems to me we should start getting advanced information from the logs, to understand what is going on behind the scenes.


I found this document that explains how to set the logging level on specific services, hence we could change it in the Identities service to DEBUG or TRACE, I suppose. 


However, the document says :

Note: You cannot delete the configuration after you create it. You can only edit the configuration.


What is the default info level in the logs, before you create a rule? Is there a way, via command line (CLI) to change it? I suppose there is, or in the bootstrap-config, but I found no documentation in this area.


Thank you in advance,


Kind regards,


Hello @JuanS_OCS,


The TRACE logging for the Identities Microservice will enable you to see the exact LDAP query and result and should make things much clearer for you.


You should be able to set the logger back to WARN after collecting the information you require.  I would caution anyone about using the SAS Bootstrap-config tool; this is like using the Windows Registry Editor - yes you can do a great deal with it, but you can easily damage the deployment as well.


Thank you for your time.





Did you found any solution for your issue? what sas support suggested? I am also facing the similar issue where the error is written to the identity logs continuously. Thanks in advance.




Hi there @sascodequestion,


can your users, and groups, from LDAP, being able to sync in SAS Environment Manager?

If yes, you would need to lower the info level in logs, and preferable better to restart the saslogon-default and identities-default microservices.

If they cannot, you would need to debug further than this. Something you can try is to disable the capability of identities service to do pagination of users/groups while sync-ing. 


If you need more info on any of those areas, please let me know. I just don't know yet where is where you need some help.


I am configuring LDAP for my sas viya environment with sasbooth user.

Currently I am trying to configure LDAP for provider tenant as we have multi tendency enabled. So the environment I am trying fo LDAP is very first one, can be a provider tenant.

I have created AD and want to authentic with the users from my users ou.


But whenever I am trying to configure base dn for user setting I am getting error code 32, i know it's no object found error. 

But the user does exist in dn which I mentioned in basedn of user.

I am getting error like remaining name ou=people,ou=provider,ou=sas,dc=example,dc=com 

Though my tree start from ou=sas,dc=example,dc=com

I am not getting from where this ou=people,ou=provider getting appended to my base dn

Hello @Shriramwasule,


I think that you would be better served opening a Technical Support track rather than attempting to walk you through the setup in the comments here.  Since you have a multi-tenant deployment the LDAP setup needs a bit more consideration.  You need to decide if you are going with Single LDAP Server for All Tenants or Separate LDAP Server per Tenant as covered in the SAS Viya 3.5 documentation here: SAS Help Center: User and Group Requirements.


Thank you for your time.


Version history
Last update:
‎06-30-2017 06:02 AM
Updated by:



Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.

If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website. 

Register now!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started

Article Tags