SSSD FAQ's Page
|
What is SSSD?
SSSD( System Security Services Daemon ) is another authentication library for
unix/linux systems similair to /etc/passwd and /etc/shadow. SSSD can do real
time authentication against AD/LDAP systems to perform authentication, rather
then authenticating through the clients local authentication mechanism.
|
|
SSSD Supported ENV
As of this writing, SSSD is supported on RHEL6 and higher OS platforms. RHEL5
and SUN systems do not provide the neccessary ssl libraries to make secure
connections to support SSSD.
|
|
What is SSSD trying to solve?
Linux users are in constant flux of having their password updated on all linux servers they
have access to, which can be quite frustrating when their password doesn't work, or they
need to use an older password on some linux systems, and a newer password on other systems.
When users change their password in LDAP, they need to wait for an unspecified period of time
before their password is updated on all linux servers. SSSD has a real time update, without
the wait time or an issue with an update failing from the account tool.
|
|
SSSD Configuration Information?
SSSD is already in the standard repo packages, and can be installed on any RHEL6+ client. When
installing, the service should be set to auto start. The configuration file for SSSD can be
found in /etc/sssd/ssssd.conf. A Default template file should look as such:
[sssd]
domains = corp.fedex.com
config_file_version = 2
services = nss, pam
[domain/corp.fedex.com]
access_provider = simple
auth_provider = ldap
cache_credentials = True
debug_level = 7
default_shell = /bin/bash
enumerate = false
fallback_homedir = /home/%u
id_provider = ldap
krb5_store_password_if_offline = True
ldap_group_member = uniqueMember
ldap_group_search_base = ou=groups,o=fedex,c=us
ldap_id_use_start_tls = true
ldap_schema = rfc2307bis
ldap_search_base = o=fedex,c=us
ldap_uri = ldaps://directory.fedex.com
ldap_user_fullname = displayName
ldap_user_name = fxLinuxId
ldap_user_search_base = ou=people,o=fedex,c=us
ldap_use_tokengroups = false
sudo_provider = none
use_fully_qualified_names = false
A line added to this config file for who has access, looks as such:
simple_allow_groups = ito_sa_implementation,oracle_group
This gives login access to any ldap accounts that belong to either the ito_sa_implementation or oracle_group image roles. Further access controls come from LDAP in the form of their groups. So anyone in the ito_sa_implementation image role, will belong to the ito_sa_implementation group. This means that if any sudo rules exist for the ito_sa_implementation group on the client, then the user will also inherit those rules. When a change is made to the configuration file to add/remove a image role, the service needs to be restarted.
When firing up SSSD for the first time, be sure to run this command to cause SSSD to link/auth to the corp domain with the right functions:
authconfig --update --enablesssd --enablesssdauth --enablemkhomedir
|
|
The Pro's to using SSSD
SSSD Provides the following benefits:
- Real Time Updates - Meaning when a user changes their password in LDAP, it is immediately ready on all linux servers using SSSD.
- No More Needing to set password hashes for first time users. - Meaning new employees no longer need to log into the Image site, set their UnixUser flag in ldap, wait an hour, and then change their LDAP password to complete the process. This is no longer needed with SSSD.
- Reduced Network Traffic - Account tools no longer need to push LDAP password updates daily to all servers ldap users are on.
- Image roles are configured - Use of LDAP Image roles, means access controls are given to image roles, and manager approvals, rather then the System Administrator needing to work access control tickets for a user. If a user needs access to a server, they request the image role to be included in, the manager approves it, and the user has immediate access to the server. There is no need for SA's to have to follow up with approvals, and initiating the acocunt tool to push/configure the user account, or template file updates in the account tool.
- Standardized Accounts - All linux accounts follow the same standard for their unix information. Meaning all ldap folks use "f" plus their LDAP ID for their unix account login on all SSSD systems. If their home directory does not exist, SSSD will create it for them.
|
|
The Con's to using SSSD
SSSD has the following issue:
- No network, No LDAP Accounts - If the server is not on the network, or cannot reach the LDAP server, the LDAP accounts will not work. If the account was on the server in the last few hours, the account will be cached in SSSD, and should work until the cache is lost. The solution to this problem is to get the client back on the network. If access to the client is needed to get the client back on the network, root password should be retrieved from whichever tool (CAPAM/Grunt/TESLA) to get root access, configure the client to talk on network again, and all accounts will be back online.
- User flexibility - If the user prefers a different shell, they would need to configure their environment on login to switch to the shell they would prefer. The default for SSSD gives all user the bash shell, as configured in LDAP.
UID/GID conflicts - While rare change, LDAP has UID values for accounts and groups. Most likely would be a rare case, but if there is a conflict with a uid/gid value on the client matching a value in LDAP, the client would need to have it's value updated to something unique from the LDAP given value.
|
|
How to get more Assistance?
Contact names for SSSD support help:
|
|
