The goal is to authorize and authenticate a RHEL host to an Active Directory 2008 infrastructure without resorting to Winbind. This expands on the FreeBSD guide I wrote one year ago, but it is a lot simpler since this technique uses the Samba suite and the wonderful automatic tools it provides. It also means that all authentication, not just SSH, can go through AD.
The secondary goal is getting NFSv4 to work. It's doable, but the caveat was painful: NFSv4 is kernel-space and RHEL 6's kernel does not use an encryption scheme allowed by Microsoft Server 2008 as a default. Add to this mess a mixed 2003/2008 AD environment and the sysadmin goes home to his kids with a headache every night. The latest Linux kernels do permit strong encryption, but I don't have the infrastructure to send kernel upgrades to all the workstations.
Note that all of this can be made into a script for fast deployment.
Credits
Please see the FreeBSD article for credits.Overview
- Set up a guest bind user on Active Directory to handle queries.
- Configure Kerberos, LDAP and Samba tools (Just the tools, you don't need the service running).
- Join the host to the domain.
- Set up SSSD on the Linux workstation. SSSD is lovely since it caches usernames/passwords. This permits laptops to operate outside the office and to defend against network dropouts inside. It replaces NSCD.
- Alter the host account on Active Directory to permit weak encryption for NFSv4.
Caveat
Even allowing weak crypto won't work in a mixed 2003 and 2008 environment due to the way the information is passed and stored among the directory servers. Use all 2003 or all 2008. There is a patch that would permit 2003 and 2008 to coexist available at Microsoft (I chose against it since we're using CIFS as an acceptable workaround).
Set up a guest bind user
Install Packages on the Host
- samba-common
- ntp
- sssd
- openldap
- ca-certificates (if your Active Directory uses LDAPS with a commercially-signed SSL certificate)
- oddjob
Set up NTP
If your host clock is not within 10 minutes of the Active Directory, authentication will FAIL. Do yourself a favour and set up the NTP daemon.
Configure Kerberos, LDAP and Samba on the Host
Certificates
You may not wish to, but I use a softlink in the /etc/openldap directory to point to the certificates in the /etc/pki/tls directories:ln -s /etc/pki/tls/certs/ca-bundle.crt /etc/openldap/certs/ca-bundle.crt |
/etc.krb5.conf
Remember Kerberos loves capitalization on domain names. Note the weak crypto statement needed for NFS4.
[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h forwardable = yes allow_weak_crypto = true default_tgs_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac [realms] EXAMPLE.COM = { kdc = ad1.example.com:88 kdc = ad2.example.com:88 admin_server = ad1.example.com:749 } [domain_realm] .example.com = EXAMPLE.COM [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }
/etc/openldap/ldap.conf
URI ldaps://ad1.example.com ldaps://ad2.example.com BASE dc=example,dc=com TLS_CACERT /etc/openldap/certs/ca-bundle.crt SASL_MECH GSSAPI REFERRALS noSome comments: I have two AD servers, of course, and since unencrypted ldap can result in group memberships being spoofed, I use secure ldap (ldaps). Set your referrals to no, otherwise the DS servers will pass the authentication buck back and forth. The cert, of course, can be set directly to /etc/pki/tls/certs/ca-bundle.crt rather than what I have set up.
/etc/samba/smb.conf
[global] workgroup =security = ads realm = EXAMPLE.COM use kerberos keytab = true password server = ad1.example.com log level = 2
Join the host to the domain
Rather than creating the Kerberos principals directly on AD, which takes a while, just use Samba:
net ads join -U administrator_account_name
Enter Administrator 's password: xxxxxxxxxxxxxx
You may get a DNS error, especially if your AD and your DNS systems are divided. Don't worry. You can verify that all went well by seeing if you have a shiny new /etc/krb5.keytab file:
klist -ke
Set Up SSSD
This will be a touch odd. Whenever anyone installs SSSD or makes a change to the authentication system through Red Hat tools, it blows up your /etc/sssd/sssd.conf file horribly. The idea, then, is to install sssd, set up authentication to go through sssd, and then write the sssd.conf you want.
/usr/sbin/authconfig --update --enablesssd --enablesssdauth --enablemkhomedir --disablefingerprint --disablesmartcard
Note I disabled fingerprint and smartcards. I don't need them. Maybe you do. I also ensured that new directories are created for new users.
Now that SSSD is the authentication mechanism, one can set up the SSSD.conf file one wants. Ensure that the file has rw------- permissions or it won't work!
[sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = LOCAL,default [nss] filter_groups = root filter_users = root reconnection_retries = 3 entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [pam] reconnection_retries = 3 offline_credentials_expiration = 0 offline_failed_login_attempts = 0 offline_failed_login_delay = 5 [domain/LOCAL] id_provider = local min_id = 1 max_id = 499 enumerate = False [domain/default] description = Kerberos 5 domain with Active Directory servers id_provider = ldap auth_provider = krb5 min_id = 500 enumerate = True timeout = 10 cache_credentials = True entry_cache_timeout = 300 # General ----------------------- # LDAP ldap_uri = ldaps://ad1.example.com:636,ldaps://ad2.example.com:636 ldap_default_authtok_type = password ldap_default_bind_dn = ldapbind@example.com ldap_default_authtok = musicaSacram67 ldap_search_base = dc=example,dc=com ldap_user_search_base = ou=Users,dc=example,dc=com ldap_group_search_base = dc=example,dc=com ldap_referrals = False ldap_schema = rfc2307bis ldap_search_timeout = 5 ldap_network_timeout = 5 # KRB5 chpass_provider = krb5 ldap_force_upper_case_realm = True krb5_server = ad1.example.com:88,ad2.example.com:88 krb5_realm = EXAMPLE.COM krb5_store_password_if_offline = true krb5_auth_timeout = 15 # Mapping -------------------- ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_principal = userPrincipalName ldap_group_gid_number = gidNumber ldap_user_gecos = cn ldap_user_home_directory = unixHomeDirectory ldap_id_use_start_tls = True ldap_user_object_class = user ldap_group_object_class = group ldap_group_member = member ldap_group_name = name ldap_user_name = uid ldap_user_shell = loginShell
Did you see the LDAP bind user and the badly-kept password? Also note the ldap_schema and ldap_referrals. The user search base and base I will leave to you as an exercise: I put in place holders.The mappings I swiped from other blogs :)
Once this file is in place, put it to work!
service sssd restart
Your host is now ready to welcome your network users.
Set up NFS4
Obviously, if you don't need it, skip this part.I will give the NFS4 system configuration in a later post. However, you will want to ensure it does work with Active Directory. To do that, you must make two (2) changes to the host account. I prefer to do it with LDAP since it is a lot more scriptable than installing, then pointing-and-clicking on ADSI edit on the AD server. They are
- Set the msDS-SupportedEncryptionTypes to 11 (decimal)
- Set UserAccountControl to its current value + 2097152 (decimal). Chances are the total will be 2166784 (69632 + 2907152)
I've done lost my ldapmodify script! I'll get that up in an update.
[UPDATE]
Anonymous has been very kind. He or she was having trouble with SSH using my guide. They added the following line to the sssd.conf: ldap_tls_reqcert = never to make it work, and let me know. This may be a solution for you. But ...
I haven't experienced the same trouble. Perhaps it may be because of the SSL cert being used on the Active Directory. My company had to install some intermediate certificates on the AD server since our SSL authority had changed its parent in order for the infrastructure to work.
Cheerio!
G
4 comments:
Hi, your tutorial is great and I managed to get AD authentication working. I can use su to switch to my LDAP users.
One question:
After this tutorial I can not ssh to my box as an LDAP user. Is there a special config required?
I have:
[sssd]
#debug_level = 3
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, ssh
domains = LDAP, LOCAL
#and an empty section:
[ssh]
Sorry, it's already working with SSH by using ldap_tls_reqcert = never
ldap_tls_reqcert = never
ldap_tls_reqcert = never and ssh works
Post a Comment