Part 3 of 4 – SSSD Linux Authentication: Implementation Step-by-Step Guideline

December 6, 2017 | 15 minute read
Tim Melander
A-Team Cloud Solution Architect
Text Size 100%:

Introduction

In Part 2 of 4 – SSSD Linux Authentication: LDAP Identity Store Requirements all the aspects of the LDAP Identity Store requirements were covered. And before that in article Part 1 of 2 - SSSD Linux Authentication: Introduction and Architecture I covered an introduction and high-level architecture of SSSD, which will be very important for this article. Finally, in Part 3, I will cover all the necessary steps to implement SSSD in order to support the goals pointed out in Part 1 of 4 - SSSD Linux Authentication: Introduction and Architecture. I would review each step carefully before implementing it so that you fully understand the reason for each step.

 

Implentation

The following steps walk you through implementing SSSD and configuring SSSD.  Most of everything are examples you will need to extrapulate to fit your own deployment.

STEP 1 – Install SSSD

Your Linux server may or may not have SSSD already installed. The following show steps in determining if SSSD is already installed and if not how to install the package.

1a – Check for SSSD package

To determine if SSSD is installed run the following command as root.

 

[root@myhost] yum list installed | grep sssd
python-sssdconfig.noarch 1.13.3-56.el6 @public_ol6_latest
sssd.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-ad.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-client.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-common.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-common-pac.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-ipa.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-krb5.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-krb5-common.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-ldap.x86_64 1.13.3-56.el6 @public_ol6_latest
sssd-proxy.x86_64 1.13.3-56.el6 @public_ol6_latest

 

If you get the above list of packages you should be good, if not, go to the next step.

1b – If needed install SSSD package

If you don’t see anything from the previous step, then run the following command as root to install SSSD. Once it is installed you can run the same command from the previous step to review and be certain the SSSD packages are installed.

[root@myhost] yum –y install sssd sssd-client

 

TIP:  The sssd-tools package is an option you can install by running “yum –y install sssd-tools”.  This utility can be used to provide various functions to create, modify, or delete a user and groups among other useful things. 

 

 

STEP 2 – Configure /etc/nsswitch.conf

Next the Linux server /etc/nsswitch.conf needs to be configured to retrieve Posix attributes from the LDAP servers.

2a – Backup /etc/nsswitch.conf

As root make a backup of nsswitch.conf

[root@host ] cp /etc/nsswitch.conf /etc/ORIG_nsswitch.conf

2b – Edit /etc/nsswitch.conf

As root use a text editor like vi to configure /etc/nsswitch.conf

[root@host ] vi /etc/nsswitch.conf

2c – Configure /etc/nsswitch.conf

Make the specific configuration changes per the table below, then save /etc/nsswitch.conf, and exit the file.

Original Update
passwd: files
shadow: files
group: files
services: files
netgroup: nisplus
automount: files nisplus
passwd: files sss
shadow: files sss
group: files sss
services: files sss
netgroup: files sss
automount: files sss

 

###############################
# Example sssd.conf:
#
#
# /etc/nsswitch.conf
#
passwd: files sss
shadow: files sss
group: files sss
sudoers: files sss
#hosts: db files nisplus nis dns
hosts: files dns
#
# Example - obey only what nisplus tells us...
#services: nisplus [NOTFOUND=return] files
#networks: nisplus [NOTFOUND=return] files
#protocols: nisplus [NOTFOUND=return] files
#rpc: nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks: nisplus [NOTFOUND=return] files
#
bootparams: nisplus [NOTFOUND=return] files
#
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files sss
#
netgroup: files sss
#
publickey: nisplus
automount: files sss

 

STEP 3 – Enable SSSD

You will need to run the following command as root to enable SSSD.

[root@host] authconfig --update --enablesssd --enablesssdauth

 

STEP 4 – Add the TLS Certificates from LDAP for SSSD

As mentioned earlier, SSSD requires encrypted communication over the LDAP protocol using a TLS certificate. It is out of the scope of this article to provide the steps to configure certificates on the LDAP identity stores, so I will make the assumption that the identity LDAP store already has TLS certificates installed and working. To make sure, LDAPS can be verified in a couple steps.

4a – Install openldap-clients package

For troubleshooting purposes and also to help verify users in LDAP, it is advised to install openldap-clients on your Linux server if needed. If you already have ldapsearch installed you can skip this step.

Run the following command to see what package needs to be installed to provide ldapsearches.

[root@myhost] yum whatprovides */ldapsearch

You should get something returned and maybe the last one is similar to this.

[root@myhost]
openldap-clients-2.4.19-15.el6.x86_64 : LDAP client utilities
Repo : public_ol6_latest
Matched from:
Filename : /usr/bin/ldapsearch

Now run the following to install openldap-clients:

[root@myhost] yum -y install openldap-clients

4b – Use openssl to get the LDAP TLS certificate

As root login on the Linux server you installed SSSD, use openssl and run the following command to return the LDAP server TLS certificate (modify to your LDAP server hostname and port). This will return a long response that includes details of the certificate and the actual certificate within the headings; -----BEGIN CERTIFICATE----- and -----END CERTIFICATE--------.

[root@host] openssl s_client \
-connect my.ldaphost.com:1389 -showcerts </dev/null

Below is an example response --

[caption id="attachment_47826" align="aligncenter" width="948"]Example certificate response Example certificate response[/caption]

 

4c – Copy the TLS certificate to /etc/openldap/certs

Now copy the certificate that was returned running the openssl command and save it as some name; e.g. oid.cert.pem. Note the location does not necessarily have to be under /etc/openldap/cacerts. However, the correct permissions are required and the location reference can be defined in the sssd.conf file later.

[root@host] cd /etc/openssl/cacerts
[root@host] vi oid.cert.pem
<Enter “i” for insert> and paste in the cert retrieved previously

[caption id="attachment_47828" align="aligncenter" width="900"]Example insert x509 cert Example insert x509 cert[/caption]

 

<Hit esc and enter colon “:” wq to write and quite> (This is standard vi).

 

4d – Verify the TLS certificate

As root check the TLS certificate by running the following openssl command.

[root@host] openssl x509 -text -in oid.cert.pem

 

4e – Apply ownership and permissions to the TLS certificate

As root apply the proper ownership and permissions to the TLS certificate; modify the path if your certificates will be in a different location.

[root@host] chown root:root /etc/openldap/cacerts/oid.cert.pem
[root@host] chmod 644 /etc/openldap/cacerts/oid.cert.pem
[root@host] ls -l /etc/openldap/cacerts/oid.cert.pem
-rw-r--r--. 1 root root 985 May 3 15:03 /etc/openldap/cacerts/oid.cert.pem

 

4f - Verify LDAPS or LDAP OverTLS

Using the openldap version of ldapsearch run any of the following commands to verify LDAPS works. You should get a response that returns the base of your LDAP server. The first command uses LDAPS over the TLS port 636, and the second command tries TLS over the open port 389. You may need to see what options to use if your ldapsearch version is different.

[root@host] ldapsearch -x -H ldaps://my.ldap.com:636 –b "dc=oracle,dc=com"

 

# extended LDIF
#
# LDAPv3
# base <dc=oracle,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
#
# search result
search: 2
result: 48 Inappropriate authentication
text: Server is Configured to Deny Anonymous Binds
#
# numResponses: 1

 

OR

[root@host]  ldapsearch -x -Z -h ldap://my.ldap.com -p 389 -b "dc=oracle,dc=com"

 

ldap_start_tls: Operations error (1)
# extended LDIF
#
# LDAPv3
# base < dc=oracle,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
#
# search result
search: 3
result: 48 Inappropriate authentication
text: Server is Configured to Deny Anonymous Binds
#
# numResponses: 1

 

4e – Repeat for each LDAP identity source

Since SSSD requires all communication over LDAP to be TLS, the prior steps need to be repeated for each LDAP identity source that SSSD will be configured whether that termination point be a LDAP server or load balancer.

 

STEP 5 – Install Microsoft Identity Management for UNIX (optional)

The topic on whether you install Microsoft Identity Management for UNIX was already explained in the Pre-Install Guideline Overview section. If you do need this package installed, follow the instruction from Microsoft here https://msdn.microsoft.com/en-us/library/cc731178(v=ws.11).aspx.

 

STEP 6 – Configuring sssd.conf Parameters and Values

The heart of SSSD configuration is in the sssd.conf located under /etc/sssd. There are many parameters that can be used such as https://linux.die.net/man/5/sssd-ldap and https://linux.die.net/man/5/sssd-ad. The parameters used in this article are more specific to authenticating a user using a password stored in a LDAP server, and authorizing a user with groups also stored in a LDAP server, but SSSD certainly provides more features though that is out of scope.

6a – Create the sssd.conf file and set permissions

Run the following command to prepare a sssd.conf file.

[root@myhost] cd /etc/sssd
[root@myhost] touch sssd.conf
[root@myhost] chmod 0600 sssd.conf
[root@myhost] vi sssd.conf

 

6b – Add Common SSSD sections

The following table will provide the necessary parameters with examples. Your final sssd.conf should look similar depending on whether you are using multiple LDAP servers or also use Active Directory with the exception of any adjustments to the values per your environment.

SSSD [sssd] -

Parameter Value Description
config_file_version 2 SSSD 0.6.0 and later use version 2
reconnection_retries 3 Number of times services should attempt to reconnect in the event of a Data Provider crash or restart before they give up.
sbus_timeout 30
services nss, pam, autofs Comma separated list of services that are started when sssd itself starts.
domains OID, AD List of domains in the order you want them to be queried.

 

Example:

[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, autofs
domains = OID, AD

 

Option 2 – Using SSSD ldap_id_mapping to Active Directory objectSid

Use the following additional configurations if you decide to leverage SSSD’s id mapping feature that will dynamically generate a uid number for a user and assign a primary group along with a home directory and default shell.

 

NSS [nss] -

Parameter Value Description
reconnection_retries 3 Number of times services should attempt to reconnect in the event of a Data Provider crash or restart before they give up.
debug_level 2 Bit mask that indicates which debug levels will be visible; 9 is the highest.

 

Example:

[nss]
reconnection_retries = 3
debug_level = 2

 

PAM [pam] -

Parameter Value Description
reconnection_retries 3 Number of times services should attempt to reconnect in the event of a Data Provider crash or restart before they give up.
debug_level 2 Bit mask that indicates which debug levels will be visible; 9 is the highest.

 

Example:

[pam]
reconnection_retries = 3
debug_level = 2

 

6c – Add Active Directory section

Use the following parameters if you are using Active Directory, but pay attention to option 1 and 2 sections of this configuration and decide which is best for you based on comments made earlier on this topic.

[domain/AD] -

Parameter Value Description
description AD 2012R2 DC This section is only a label.
debug_level 2 Bit mask that indicates which debug levels will be visible; 9 is the highest.
enumerate true Determines if a domain can be enumerated; true, users and groups are enumerated.
min_id 1000 UID and GID limits for the domain.
id_provider ldap The identification provider used for the domain.
auth_provider ldap The authentication provider used for the domain.
ldap_schema rfc2307bis Specifies the Schema Type in use on the target LDAP server.
cache_credentials true Determines if user credentials are also cached in the local LDB cache
ad_server cloud.acme.com
ldap_search_base dc=my,dc=acme,dc=com The default base DN to use for performing LDAP user operations.
ldap_default_bind_dn cn=sssd_bind,cn=Users,
dc=my,dc=acme,dc=com
The default bind DN to use for performing LDAP operations.
ldap_default_authtok_type password The type of the authentication token of the default bind DN.
ldap_default_authtok <bind password> The authentication token of the default bind DN. Only clear text passwords are currently supported.
ldap_tls_reqcert allow Specifies what checks to perform on server certificates in a TLS session, if any.
ldap_tls_cacertdir /etc/openldap/certs Specifies the path of a directory that contains Certificate Authority certificates in separate individual files.
ldap_user_object_class user The object class of a user entry in LDAP.
ldap_user_name sAMAccountName The LDAP attribute that corresponds to the user's login name.
ldap_user_principal userPrincipalName The LDAP attribute that contains the user's Kerberos User Principal Name (UPN).
ldap_group_object_class group The object class of a group entry in LDAP; default posixGroup.
ldap_group_name cn The LDAP attribute that corresponds to the group name.
ldap_group_gid_number gidNumber The LDAP attribute that corresponds to the group's id.
ldap_force_upper_case_realm true Some directory servers, for example Active Directory, might deliver the realm part of the UPN in lower case, which might cause the authentication to fail.

 

Option 1 – Using Microsoft Identity Management for UNIX schema extension

Use the following additional configurations if you decide to install Microsoft Identity Management for UNIX schema extension.

[domain/AD] -

Parameter Value Description
ldap_id_mapping false Specifies that SSSD should attempt to map user and group IDs.
ldap_user_uid_number uidNumber The LDAP attribute that corresponds to the user's id.
ldap_user_gid_number gidNumber The LDAP attribute that corresponds to the user's primary group id.
ldap_group_gid_number gidNumber The LDAP attribute that corresponds to the group's id.
ldap_user_home_directory unixHomeDirectory The LDAP attribute that contains the name of the user's home directory, this can be modified per your environment.
ldap_user_shell loginShell The LDAP attribute that contains the path to the user's default shell, this can be modified per your environment.

 

Option 2 – Using SSSD ldap_id_mapping to Active Directory objectSid

Use the following additional configurations if you decide to leverage SSSD’s id mapping feature that will dynamically generate a uid number for a user and assign a primary group along with a home directory and default shell.

[domain/AD] -

Parameter Value Description
ldap_id_mapping true Specifies that SSSD should attempt to map user and group IDs.
ldap_user_objectsid objectSid The LDAP attribute that contains the objectSID of an LDAP user object stored in Active Directory.
ldap_group_objectsid objectSid The LDAP attribute that contains the objectSID of an LDAP group object stored in Active Directory.
ldap_user_primary_group primaryGroupID Active Directory primary group attribute for ID-mapping. Note that this attribute should only be set manually if you are running the “ldap” provider with ID mapping.
case_sensitive false New option that allows to treat names in a case insensitive manner. This option is set to "true" by default, maintaining the POSIX standard setting.
fallback_homedir /home/%d/%u et a default template for a user's home directory, this can be modified per your environment.
default_shell /bin/bash The LDAP attribute that contains the path to the user's default shell, this can be modified per your environment.

 

Example:

[domain/AD]
# AD General
description = AD 2012R2 DC
debug_level = 2
enumerate = true
min_id = 1000
#
# AD Providers
id_provider = ldap
auth_provider = ldap
#
# AD LDAP General
ldap_schema = rfc2307bis
cache_credentials = true
ldap_id_mapping = false
#
# AD LDAP Connection Settings
ad_server = my.acme.com
ldap_search_base = dc=my,dc=acme,dc=com
ldap_uri = ldaps://cloud.acme.com
ldap_default_bind_dn = cn=sssd_bind,cn=Users,dc=my,dc=acme,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = Oracle123
#
# AD Use below if you are using SSL/TLS
#ldap_id_use_start_tls = true
ldap_tls_reqcert = allow
ldap_tls_cacertdir = /etc/openldap/certs
#
# AD LDAP Objectclass Mappings
ldap_user_object_class = user
ldap_user_name = sAMAccountName
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_name = cn
ldap_force_upper_case_realm = True
#
# Uncomment the configurations of one of the options you decide to use.
# OPTION 1 – Microsoft Idm for UNIX
#ldap_user_uid_number = uidNumber
#ldap_user_gid_number = gidNumber
# ldap_group_gid_number = gidNumber
#ldap_user_home_directory = unixHomeDirectory
#ldap_user_shell = loginShell
#
# OPTION 2 – SSSD id_mapping
#ldap_user_objectsid = objectSid
#ldap_group_objectsid = objectSid
#ldap_user_primary_group = primaryGroupID
#case_sensitive = false
#ldap_id_mapping = true
#fallback_homedir = /home/%d/%u
#default_shell = /bin/bash

 

6d – Add other LDAP sections

The following table should work for other LDAP servers like OID, OUD, ODSEE, etc. If you use multiple LDAP servers be sure to name the [domain/<ldap>] section appropriately. Below is an example, but it could also be [domain/LDAP], [domain/LDAP1], etc. The label is simply a way to identify the LDAP server, which later you will see that the domain name will define the log name; e.g. below the log would be sssd_OID.log.

 

[domain/AD] -

Parameter Value Description
description OID 11.1.1.9.0 This section is only a label.
debug_level 2 Bit mask that indicates which debug levels will be visible; 9 is the highest.
enumerate true Determines if a domain can be enumerated; true, users and groups are enumerated.
min_id 1000 UID and GID limits for the domain.
id_provider ldap The identification provider used for the domain.
auth_provider ldap The authentication provider used for the domain.
ldap_schema rfc2307bis Specifies the Schema Type in use on the target LDAP server.
cache_credentials true Determines if user credentials are also cached in the local LDB cache.
ldap_search_base dc=my,dc=initech,dc=com The default base DN to use for performing LDAP user operations.
ldap_uri ldaps://my.initech.com:3131 The default base DN to use for performing LDAP user operations.
ldap_default_bind_dn cn=sssd_admin,cn=Users,
dc=my,dc=initech,dc=com
The default bind DN to use for performing LDAP operations.
ldap_default_authtok_type password The type of the authentication token of the default bind DN.
ldap_default_authtok <your password> The authentication token of the default bind DN. Only clear text passwords are currently supported.
ldap_tls_cacertdir /etc/openldap/cacerts Specifies the path of a directory that contains Certificate Authority certificates in separate individual files.
ldap_tls_reqcert allow Specifies what checks to perform on server certificates in a TLS session, if any.
ldap_user_object_class orclPerson The object class of a user entry in LDAP.
ldap_user_name uid The LDAP attribute that corresponds to the user's login name.
ldap_user_uid_number uidNumber The LDAP attribute that corresponds to the user's id.
ldap_user_gid_number gidNumber The LDAP attribute that corresponds to the user's primary group id.
ldap_user_home_directory homeDirectory The LDAP attribute that contains the name of the user's home directory.
ldap_user_shell loginShell The LDAP attribute that contains the path to the user's default shell.
ldap_group_name cn The LDAP attribute that corresponds to the group name.
ldap_group_object_class posixGroup The object class of a group entry in LDAP.
ldap_group_gid_number gidNumber The LDAP attribute that contains the names of the group's members.
ldap_group_member uniqueMember The LDAP attribute that contains the names of the group's members.

 

Example:

[domain/OID]
# OID LDAP General
description = OID 11.1.1.9.0
debug_level = 9
enumerate = true
min_id = 1000
#
# OID LDAP Providers
id_provider = ldap
auth_provider = ldap
# OID LDAP General
ldap_schema = rfc2307
cache_credentials = true
#
# OID LDAP Connection Settings
ldap_search_base = dc=my,dc=initech,dc=com
ldap_uri = ldaps://oid.initech.com:3131
ldap_default_bind_dn = cn=sssd_admin,cn=Users,dc=my,dc=initech,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = Oracle123
#
# OID LDAP Use below if you are using SSL/TLS
#ldap_id_use_start_tls = true
ldap_tls_cacertdir = /etc/openldap/certs
ldap_tls_reqcert = allow
#
# OID LDAP Objectclass Mappings
ldap_user_object_class = orclPerson
ldap_user_name = uid
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = homeDirectory
ldap_user_shell = loginShell
ldap_group_name = cn
ldap_group_object_class = posixGroup
ldap_group_gid_number = gidNumber
ldap_group_member = uniqueMember

STEP 7 – Configuring High Availability

High availability is accomplished by making sure the LDAP connection from SSSD is redundant. Adding high availability can be done in a couple of ways:

1. Configure sssd.conf with multiple LDAP URIs
2. Use a load balancer for the LDAPS hosts

This section will explain the configuration for option #1 above, but if option #2 is desired the previous steps for the sssd.conf configurations can be kept since the virtual IP hostname of the load balancer can be used against multiple LDAP servers to provide the redundancy.

OPTION 1 – Using sssd.conf with multiple URIs

The following sssd.conf parameters will need to be adjusted from the previous section including adding backup URIs for each [domain/<NAME>] section as needed.

 

[domain/<NAME>] -

Parameter Value Description
ldap_uri ldaps://ldaphost1.com:636, ldaps://ldaphost2.com:636 Comma delimited list of primary LDAP servers in order of preference that SSSD should try to connect.
ldap_backup_uri ldaps://ldaphost3.com:636, ldaps://ldaphost4.com:636 Failover LDAP server is tried if there are no primary servers available, and once a backup is used, after 31 seconds it tries the primary servers again periodically.  Once a primary is contacted again, the current backup is replaced.

 

Example:

[domain/AD]
ldap_uri = ldaps://ldap1.acme.com:636, ldaps://ldap2.acme.com:636
ldap_backup_uri = ldaps://ldap3.acme.com:636, ldaps://ldap4.acme.com:636

 

OPTION 2 – Using a Load Balancer

If a load balancer is used for high availability the following are required:

✓ TLS certificate is required on the Load Balancer connection
✓ LDAP communication needs to use TCP
✓ Load balancer periodically checks the LDAP server health

How the above are accomplished or configured is out-of-the-scope of this article.  That said, one point on the LDAP server health check, I would recommend the load balancer be configured to use a BIND to the LDAP server in order to determine if it is responding versus doing a simple TCP ping.  The reason is that there can be issues with the LDAP server yet the physical host is still up.  If this happens anything trying to use the LDAP connection will continue to think it is still working fine as the load balancer will never pull out any of the LDAP servers that are not working.

 

STEP 8 – Restart SSSD

Each time any change is made to the sssd.conf the SSSD service needs to be restarted. A better approach is as follows which not only stops and starts SSSD, but also clears the cache. First stop SSSD, remove the LDB cache, and start SSSD. Run the following commands as root.

[root@host] service sssd stop
[root@host] sss_cache -E
[root@host] rm -f /var/lib/sss/db/*
[root@host] service sssd start

 

Testing the Solution

Testing the solution is pretty straightforward. The following gives some basic steps to validate a user can authenticate and see their groups. However, it is recommended to validate that high availability also works --- HA testing is out-of-scope for this article.

 

Configuring a user account

Before you can initially login with a user using SSSD, UNIX expects certain attributes to exist for a user account; gid number, uid number, login shell, and a home directory.

1. Create a user in the LDAP store you want to test, this should be done for both Active Directory and OID11g or any additional LDAP servers.

2. Be sure to add values for the following attributes; the attributes can differ between LDAP identity stores.
NOTE: If using Active Directory and the SSSD option of ldap_id_mapping is used, there is nothing needed to change for an Active Directory account.

 

AD (If not using ldap_id_mapping) Other LDAP Servers
gidNumber gidNumber
uidNumber uidNumber
loginShell loginShell
unixHomeDirectory homeDirectory

 

3. Open a terminal window.

4. Enter “ssh jsmith@linuxhost” where jsmith is your username and linuxhost is the host of the Linux server, then press enter.

5. Enter a password and press enter.

6. If SSSD is working properly, you should immediately login and SSSD will automatically create a home directory if it does not exist.

 

TIP:  The home directory is only created once, so on logging into another server that is configured with SSSD it may complain that the home directory does not exist.  It is recommended that all the Linux servers use a shared mount where the users home directories will be located.

 

Querying User Information

Another verification this solution should be able to do is to query a user or group from a command-line.

1. As “root” you can enter some of the following commands. You should get details of the user returned, otherwise you may get an error message like “id: jsmith: No such user”, and if that is the case see the troubleshooting section.

a. getent passwd jsmith
b. id jsmith
c. id –u jsmith

2. As a logged in “user” on the system, at a command line some of the following commands can be used to return information about the current logged in user.

a. id
b. groups
c. passwd (Let’s user change their password, but there is a known issue with OID and Active Directory 2012R2 that does not allow SSSD to use passwd; see Known Issues section.)

 

Summary

Hopefully you were successful in implementing SSSD following the steps in this article.  This can be a tricky implementation and frustrating.  If you ran into problems, no worries, I have one last article, Part 4 of 4 - SSSD Authentication:  Known Problems and Troubleshooting.  In Part 4 I will cover known issues and tips on how to troubleshoot setting up and configuring SSSD.  If you were successful, it would not be a bad idea anyway to check out Part 4 for simply the knowledge of known issues I have come across in my own experience.

Tim Melander

A-Team Cloud Solution Architect

I started with Oracle in 2005 and been a member of the Oracle A-Team since 2012 though have worked in Identity and Access Management since 1999.  My journey with security continues the cloud that heavily includes Oracle Infrastructure Cloud (OCI).  I enjoy writing articles built on real life use cases to help in areas where a standard document may not provide. I am a strong believer in learning by example to which I try to incorporate as many helpful tips, excellent diagrams, and instructional steps as I can.


Previous Post

Part 2 of 4 – SSSD Linux Authentication: LDAP Identity Store Requirements

Tim Melander | 6 min read

Next Post


Part 4 of 4 - SSSD Authentication: Known Problems and Troubleshooting Tips

Tim Melander | 9 min read