SSH-SSSD Case Sensitivity Flag

As of RHEL 6 (SSSD package 1.6), a case_sensitive option was added to the valid list of parameters for a given provider in the /etc/sssd/sssd.conf file. When this value is false, querying SSSD for a given user will return the username in all lower case, regardless of the casing in Active Directory. This value can be set to Preserving which will return the casing used in the username in active directory.

Bash Orchestrator Implications

This is a relevant detail as attempting to create a new SSHClosed The SSH (secure shell) protocol provides for secure connections between computers. It provides several options for authentication, including public key, and protects the communications with strong encryption. logon on Keyfactor Command (see Adding Logons) requires that the username is entered as it appears in SSSD, regardless of this setting's value. Using Preserving makes the logons look like they do in AD so it may be a less confusing experience for system administrators or those in charge of provisioning the accounts. If this flag is set to false, SSSD will return the name as all lower case characters to preserve POSIX compliance, which is how usernames will need to be entered into Keyfactor Command to create them.

Note:   Besides the case-sensitive option setting, there are other SSSD settings that can affect how the username is presented which are not covered in this discussion.

Run the command below in your environment to determine how the username should be formatted.

getent passwd username@domain
Example:  

Figure 407: AD Account Properties

The results for the above user with the setting as false would be: bbrown@keyexample.com.

The result for the above user with the setting as Preserving would be: BBROWN@keyexample.com.

Warning:   This value should not be changed once home directories have already been created on the server, even if done so prior to installing the Bash OrchestratorClosed The Bash Orchestrator, one of Keyfactor's suite of orchestrators, is used to discover and manage SSH keys across an enterprise.. Doing so will result in a conflict between Keyfactor Command's understanding of a login's casing and SSSD's. You will then receive an error until this logon is removed or its home directory is updated on the target server.
Example:  User BBROWN@keyexample.com has a home directory /home/BBROWN@keyexample.com that is out of compliance with SSSD known directory /home/bbrown@keyexample.com.The resolution of this error, in the case of the case_sensitivity property, is to either update the logon's home directory in AD or remove the logon's home directory on the local server and re-add it through Keyfactor Command.
Example:  It is also possible for SSSD's understanding of a logon's home directory or account name to change if name of the domain changes in the SSSD config file. In this case, it's expected that the logon is removed from Keyfactor Command, in addition to its home directory on the Linux server, and re-added.