This is another post in the series about configuring a SAS platform on Linux to use Integrated Windows Authentication (IWA), in this post I’m going to jot down some notes on steps 1-7 – configuring the Linux server for Active Directory (AD) Authentication.
Some time has passed since I wrote the original post, and a few things have changed. I’m now running SAS 9.4 M3, but this post should equally apply to SAS 9.4 M2. I have also switched the Linux distribution from Debian to CentOS 7.1. I am also using a much simpler method of joining the Linux server to the AD domain, using the realmd package (previously there were lots of individual steps using the underlying packages but realmd automates most of this). In this post I’m going to outline the simpler method using realmd of course.
Here goes …
This is a small development installation and the SAS metadata server, SAS compute tier, and SAS mid-tier are all running on the same Linux server machine named sas94m3 (with a fully qualified name of sas94m3.corp.example.com). It is going to join an AD domain CORP.EXAMPLE.COM using the domain controller ad01.corp.example.com.
Kerberos Client Config
I first install the Kerberos client software, configure it to use AD, and use kinit to get a ticket-granting ticket (TGT) as a domain admin. That way I don’t have to provide any credentials when using realmd.
yum install krb5-workstation krb5-devel
vi /etc/krb5.confNOTE: The krb5-devel package provides a /usr/lib64/libgssapi_krb5.so -> libgssapi_krb5.so.2.2 symlink. I noticed that SAS looks for libgssapi_krb5.so after turning on debugging in the sasauth.conf file.
The following Kerberos config was used (/etc/krb5.conf). There were a few minor edits to the default template originally installed (changes shown in bold below):
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = CORP.EXAMPLE.COM
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
CORP.EXAMPLE.COM = {
kdc = ad01.corp.example.com
admin_server = ad01.corp.example.com
}
[domain_realm]
.corp.example.com = CORP.EXAMPLE.COM
corp.example.com = CORP.EXAMPLE.COM
.example.com = CORP.EXAMPLE.COM
example.com = CORP.EXAMPLE.COMGet a Kerberos TGT for a domain admin:
kinit -V Administrator
Using default cache: persistent:0:0
Using principal: Administrator@CORP.EXAMPLE.COM
Password for Administrator@CORP.EXAMPLE.COM: ****************
Authenticated to Kerberos v5
Joining the Domain using realmd
It’s a good idea to make sure that DNS is working on the Linux server, checking the domain is discoverable, by making sure the following SRV record resolves for the corp.example.com domain:
dig -t SRV _ldap._tcp.corp.example.comNext install the realmd package:
yum install realmdI then create a custom config file for realmd prior to joining the domain. This is because I want to replicate previous behaviour where home dirs were in /home/userid and bare unqualified userids were used to login. You don’t need to create this file if you want to go with the default of /home/corp.example.com/userid for the home directory and using qualified userids (e.g. CORP\\userid or userid@corp.example.com).
vi /etc/realmd.confThis is my /etc/realmd.conf file contents:
[users]
default-home = /home/%U
default-shell = /bin/bash
[corp.example.com]
fully-qualified-names = noThe next step is to discover the domain and find out what additional packages might be needed:
realm discover --verbose CORP.EXAMPLE.COM
* Resolving: _ldap._tcp.corp.example.com
* Performing LDAP DSE lookup on: 192.168.202.5
* Successfully discovered: corp.example.com
corp.example.com
type: kerberos
realm-name: CORP.EXAMPLE.COM
domain-name: corp.example.com
configured: no
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-commonThen make sure all the required packages listed are installed:
yum install oddjob oddjob-mkhomedir sssd adcli samba-commonNow we can join the domain (I like to use the –verbose option to see what’s going on):
realm join --verbose CORP.EXAMPLE.COM
* Resolving: _ldap._tcp.corp.example.com
* Performing LDAP DSE lookup on: 192.168.202.5
* Successfully discovered: corp.example.com
* Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/sbin/adcli
* LANG=C /usr/sbin/adcli join --verbose --domain corp.example.com --domain-realm CORP.EXAMPLE.COM --domain-controller 192.168.202.5 --login-type user --login-ccache=/var/cache/realmd/realm-ad-kerberos-2X4E2X
* Using domain name: corp.example.com
* Calculated computer account name from fqdn: SAS94M3
* Using domain realm: corp.example.com
* Sending netlogon pings to domain controller: cldap://192.168.202.5
* Received NetLogon info from: AD01.corp.example.com
* Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-1GcMKP/krb5.d/adcli-krb5-conf-hG6H4k
* Looked up short domain name: CORP
* Using fully qualified name: sas94m3.corp.example.com
* Using domain name: corp.example.com
* Using computer account name: SAS94M3
* Using domain realm: corp.example.com
* Calculated computer account name from fqdn: SAS94M3
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Using fully qualified name: sas94m3.corp.example.com
* Using domain name: corp.example.com
* Using computer account name: SAS94M3
* Using domain realm: corp.example.com
* Looked up short domain name: CORP
* Computer account for SAS94M3$ does not exist
* Found well known computer container at: CN=Computers,DC=corp,DC=example,DC=com
* Calculated computer account: CN=SAS94M3,CN=Computers,DC=corp,DC=example,DC=com
* Created computer account: CN=SAS94M3,CN=Computers,DC=corp,DC=example,DC=com
* Set computer password
* Retrieved kvno '2' for computer account in directory: CN=SAS94M3,CN=Computers,DC=corp,DC=example,DC=com
* Modifying computer account: dNSHostName
* Modifying computer account: userAccountControl
* Modifying computer account: operatingSystem, operatingSystemVersion, operatingSystemServicePack
* Modifying computer account: userPrincipalName
* Discovered which keytab salt to use
* Added the entries to the keytab: SAS94M3$@CORP.EXAMPLE.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: HOST/SAS94M3@CORP.EXAMPLE.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: HOST/sas94m3.corp.example.com@CORP.EXAMPLE.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/SAS94M3@CORP.EXAMPLE.COM: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/sas94m3.corp.example.com@CORP.EXAMPLE.COM: FILE:/etc/krb5.keytab
* /usr/bin/systemctl enable sssd.service
ln -s '/usr/lib/systemd/system/sssd.service' '/etc/systemd/system/multi-user.target.wants/sssd.service'
* /usr/bin/systemctl restart sssd.service
* /usr/bin/sh -c /usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --nostart && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service
getsebool: SELinux is disabled
ln -s '/usr/lib/systemd/system/oddjobd.service' '/etc/systemd/system/multi-user.target.wants/oddjobd.service'
* Successfully enrolled machine in realmThe next step is to permit logins. I’ve allowed all AD logins, but you might want to be more specific.
realm --verbose permit --realm corp.example.com --all
* /usr/bin/systemctl restart sssd.service
* Successfully changed permitted logins for realmTesting
Now the server has joined the domain you can do a few simple tests to see if it is working.
Try to look up a domain user:
getent passwd sasdemo
sasdemo:*:1323801154:1323800513:SAS Demo User:/home/sasdemo:/bin/bashIf you didn’t use fully-qualified-names=no in /etc/realmd.conf you will need to use a qualified userid like so:
getent passwd CORP\\sasdemo
getent passwd sasdemo@corp.example.comIf the look up works, you can try logging in as a domain user:
su - sasdemoIf this works then you should be able to authenticate to the SAS Metadata Server using a domain account and launch a SAS Workspace Server. You won’t be able to use Integrated Windows Authentication yet because that requires some more configuration to be done – a topic for a future blog post :)
Finally, a few other things you might find useful ….
Rejoining the Domain
I you edit the realmd config /etc/realmd.conf you will want to leave and rejoin the domain for the settings to take effect:
realm leave --verbose CORP.EXAMPLE.COM
* Removing entries from keytab for realm
* /usr/sbin/sss_cache --users --groups --netgroups --services --autofs-maps
* Removing domain configuration from sssd.conf
* /usr/sbin/authconfig --update --disablesssdauth --nostart
getsebool: SELinux is disabled
* /usr/bin/systemctl disable sssd.service
rm '/etc/systemd/system/multi-user.target.wants/sssd.service'
* /usr/bin/systemctl stop sssd.service
* Successfully unenrolled machine from realm
realm join --verbose CORP.EXAMPLE.COMLeaving the Domain and Removing the Packages
If you need to want to start from scratch, or revert back to non-AD host authentication, you can leave the domain and uninstall the packages like so:
# Leave the domain
realm leave CORP.EXAMPLE.COM
# Remove the packages installed (and then any automatically installed dependances no longer needed)
yum remove oddjob oddjob-mkhomedir sssd adcli realmd krb5-workstation sssd
yum autoremove
# Remove the remaining SSSD config (if you don't need it anymore)
rm /etc/sssd/sssd.conf
# Remove the server's keytab (if you don't need it anymore)
rm /etc/krb5.keytabFinally go into AD Active Directory Users and Computers and remove the computer account for the server (SAS94M3).
Your Turn
If you’ve found this useful, or have any additional comments or tips on getting a Linux server authenticating against Active Directory in preparation for a SAS platform install, please let me know by leaving a comment below.
Hi Paul
This now sounds like you can do it before breakfast;-), many thanks for sharing this.
Thanks Bruno. I found it certainly does make it much easier, automating some of the otherwise manual tasks, and reducing the chances of human error.
Hi Paul, I tried this configuration and it worked perfectly, but, only users in the windows domain configured are able to sign, how can be this functionality extended to windows domains with a trusted relationship with the configured domain?
Rafael, I’m doing some more testing using realmd (sssd) and multiple domains and I’ll post my findings later on. My test environment has 3 domains (2 domains within the same forest and another domain in a separate trusted forest). How is yours configured: 2 domains within the same forest or 2 domains in separate trusted forests?
Rafael, I have it working with multiple domains in the same forest. If DOMAIN1.EXAMPLE.COM is my first domain, I needed to manually add the second domain DOMAIN2.EXAMPLE.COM into /etc/krb5.conf (otherwise I was getting authentication failures for DOMAIN2 users and the following error in /var/log/messages sssd_be: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot find KDC for realm “DOMAIN2.EXAMPLE.COM”).
The relevant sections of my /etc/krb5.conf look like this:
[realms]
DOMAIN1.EXAMPLE.COM = {
kdc = server1.domain1.example.com
admin_server = server1.domain1.example.com
}
DOMAIN2.EXAMPLE.COM = {
kdc = server2.domain2.example.com
admin_server = server2.domain2.example.com
}
[domain_realm]
.domain1.example.com = DOMAIN1.EXAMPLE.COM
domain1.example.com = DOMAIN1.EXAMPLE.COM
.domain2.example.com = DOMAIN2.EXAMPLE.COM
domain2.example.com = DOMAIN2.EXAMPLE.COM
After this DOMAIN1 users could log in using the unqualified user id (e.g. user1) and the unqualified user id would be used in the Accounts tab of the user in SAS Management Console User Manager plug-in.
DOMAIN2 users would have to log in with the qualified user id (e.g. user2@DOMAIN2) and that qualified user id would have to be used in the Accounts tab of the user in SAS Management Console User Manager plug-in.
You might change this behaviour with the sssd.conf use_fully_qualified_names option but I have not tried this myself as yet.
I should have also mentioned that I was unable to get cross-forest working with sssd. As far as I can see it is not support as yet. The man page for sssd-ad says:
“The AD provider is able to provide identity information and authentication for entities from
trusted domains as well. Currently only trusted domains in the same forest are recognized.”
If you have a cross-forest environment then you might want to look into alternative methods like FreeIPA, Centrify etc.
Hi Paul.
Thanks for you reply!!
This information is very useful for me, I had problems with the 2nd domain, now, I know how to solve it.
Also, we want to authenticate users from a third domain, but this is in another forest with a trust relationship.
As I can read, this is not supported by sssd.
Thanks again for you reply!
Appreciate your help!
Regards.
Hi Paul.
Correctly, I understand that if the SAS configuration is divided into meta tier, middle tier and computer tier each on its own Linux server, then do you need to perform these settings on each separate server?
It depends on your architecture and what you are trying to achieve. For AD authentication for the SAS Metadata Server then, yes, on it’s machine. For the compute tier if you want the SAS Object Spawner to launch SAS Workspace Server instances using the credentials of the requesting user then, yes, you will need to do it on that machine too. Alternatively, if you are doing SAS Token Authentication for SAS Workspace Servers, so they launch using a shared identity then, no, it won’t be necessary on that machine. For the mid-tier machine, you won’t be launching processes as the requesting user, so it won’t be necessary to do user level AD authentication on that machine. However, if you want to do IWA web authentication then you will need to do some Kerberos configuration on that machine to support it.
You may want to consider getting some help from SAS Professional Services or a local SAS Partner if you want more detailed assessment and advice for your specific environment. That will increase the likelihood of success and reduce the time to implementation.