SUSE Linux, Tech, Uncategorized

Simple SSSD Configuration with eDirectory on SUSE

Two Factor Authentication is a lofty goal for any linux administrator.  If you’re lucky enough to have access to an NetIQ eDirectory server, hardware based two factor authentication is closer than you think.

Tutorial on how to use SSSD (pronounced Triple “S” D) as a cross Linux platform (RHEL, SLES, Ubuntu, et. al) authentication agent instead of painful and often times disparate pam_ldap and sudoers configurations. Centralized user and group management using existing directory infrastructure. Learn how centrally store SSH key and sudoer configurations in LDAP. No more having to copy your SSH key to each new server. Create a SSH Key based single sign on solution. Your sudo commands are authenticated against your Directory. Expand the configuration of SSSD clients for 2 factor authentication using a HOTP configured YubiKey that does not require any changes on the authenticating client. Integration with eDirectory. Explore SSO Kerberized options with Active Directory and MIT Kerberos.

This is based from a presentation I gave at SUSECON 2016 in Washington D.C.   Right now it’s fairly unorganized and more as a place to gather my thoughts as I worked through developing my presentaion

Create a Bind Account for SSSD

In this case I’ve created cn=SSSDBInd,ou=service,o=gtopia

This account has read only rights to all the Users container in the tree.  This can be limited down to only the required attributes but for the sake of time we’ll skip that.   I may come back later and enhance this section.

This will be our user to bind with inside of SSSD because I do not want to allow anonymous searches on the Directory.

You will first need to ensure your LDAP server is capable of secure connections.   You will then need the Public self-signed certificate or the Public certificate of your Certificate Authority.

iManager CA Location

  1. Find the “Configure Certificate Authority” Task
  2. Open the certificates tab
  3. Select the Self Signed RSA Certificate
  4. Click Export
CA Certificate Export format
CA Certificate Export format

Save the file, (rename extension as .pem)

Upload the certificate to your client SSSD client.

Make the Certificate available to the whole system

  1. Copy certificate to /etc/ssl/certs
  2. Run the Hash Command to make it available in the hashed directory
susehost:/etc/ssl/certs # c_rehash /etc/ssl/certs/ 

This will rehash all the certificates in that folder and will be useful later.

Now that certificate is available you can configure the system ldap.conf file to use that certificate.

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE   dc=example,dc=com
#URI    ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never
TLS_CACERTDIR /etc/ssl/certs

IF you don’t configure the ldap.conf file you get errors like this

 # ldapsearch -H ldaps://ldap.gtopia.org ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate in certificate chain)

Now you can try a test Search

# ldapsearch -H ldaps://ldap.gtopia.org -x -b o=gtopia -D cn=SSSDBind,ou=service,o=gtopia -W objectclass=inetOrgPerson cn
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <o=gtopia> with scope subtree
# filter: objectclass=inetOrgPerson
# requesting: cn
#

# SSSDBind, Service, gtopia
dn: cn=SSSDBind,ou=Service,o=gtopia
cn: SSSDBind

# mark, users, gtopia
dn: cn=mark,ou=users,o=gtopia
cn: mark

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

This shows the server can really talk to LDAP outside of SSSD. Confirms working LDAP and pathing. So troubleshooting from here forward we know is only in SSSD land.

Configure sssd.conf

#pam-config –add –sss –mkhomedir

Add Posix Attributes to LDAP user

The schema must be extended before Attributes can be added, fortunatly the basic schema has been provided.

susehost:/opt/novell/eDirectory/lib64/nds-schema # ndssch -h ldap.gtopia.org -t GTOPIA admin.gtopia rfc2307-usergrou
p.sch
Password:
Logging into the tree as "admin.gtopia". Please Wait ...

Extending schema, For more details view schema extension logfile: /root/schema.log

NDS schema extension complete.

 

To do SUDO in sssd we must also extend the schema in LDAP for the SUDO attributes.  There is a schema provided that accomplishes this: /etc/openldap/schema/sudo.schema

unfortunatly this schema doesn’t work with the ndssch utility. Probably becuse this file isn’t well formed and not in the right format.   Here’s a good LDIF based schema file here:

#
# OpenLDAP schema file for Sudo
# Save as /etc/openldap/schema/sudo.schema
#

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.15953.9.1.1
    NAME 'sudoUser'
    DESC 'User(s) who may  run sudo'
    EQUALITY caseExactIA5Match
    SUBSTR caseExactIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.15953.9.1.2
    NAME 'sudoHost'
    DESC 'Host(s) who may run sudo'
    EQUALITY caseExactIA5Match
    SUBSTR caseExactIA5SubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.15953.9.1.3
    NAME 'sudoCommand'
    DESC 'Command(s) to be executed by sudo'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.15953.9.1.4
    NAME 'sudoRunAs'
    DESC 'User(s) impersonated by sudo (deprecated)'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.15953.9.1.5
    NAME 'sudoOption'
    DESC 'Options(s) followed by sudo'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.15953.9.1.6
    NAME 'sudoRunAsUser'
    DESC 'User(s) impersonated by sudo'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.15953.9.1.7
    NAME 'sudoRunAsGroup'
    DESC 'Group(s) impersonated by sudo'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.15953.9.1.8
    NAME 'sudoNotBefore'
    DESC 'Start of time interval for which the entry is valid'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.15953.9.1.9
    NAME 'sudoNotAfter'
    DESC 'End of time interval for which the entry is valid'
    EQUALITY generalizedTimeMatch
    ORDERING generalizedTimeOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.15953.9.1.10
    NAME 'sudoOrder'
    DESC 'An integer to order the sudoRole entries'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.15953.9.2.1
    NAME 'sudoRole'
    SUP top
    STRUCTURAL
    DESC 'Sudoer Entries'
    MUST ( cn )
    MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoOrder $ sudoNotBefore $ sudoNotAfter $ description )
    )

 

Once that file is loaded into the ldap server then we can create SUDOERS rules in LDAP.

Check this out as you work on this step: https://www.sudo.ws/readme_ldap.html

Here’s a sample output of creating an LDIF from the sudoers file.

host:~ # export SUDOERS_BASE=ou=Sudoers,o=gtopia
host:~ # sudoers2ldif /etc/sudoers
dn: cn=defaults,ou=Sudoers,o=gtopia
objectClass: top
objectClass: sudoRule
cn: defaults
description: Default sudoOption's go here
sudoOption: always_set_home
sudoOption: secure_path="/usr/sbin:/usr/bin:/sbin:/bin"
sudoOption: env_reset
sudoOption: env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"
sudoOption: !insults
sudoOption: targetpw
sudoOrder: 1

dn: cn=ALL,ou=Sudoers,o=gtopia
objectClass: top
objectClass: sudoRule
cn: ALL
sudoUser: ALL
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
sudoOrder: 2

dn: cn=root,ou=Sudoers,o=gtopia
objectClass: top
objectClass: sudoRule
cn: root
sudoUser: root
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
sudoOrder: 3

Create a sample user sudo command.

dn: cn=mark,ou=Sudoers,o=gtopia
objectClass: top
objectClass: sudoRule
cn: mark
sudoUser: mark
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL
sudoOption: !authenticate
sudoOrder: 3

Here is the sssd.conf

[sssd]
config_file_version = 2
services = nss, pam, sudo
# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
domains = LDAP

[nss]

[pam]

# Example LDAP domain
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
# ldap_schema can be set to "rfc2307", which stores group member names in the
# "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in
# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.
ldap_schema = rfc2307bis
ldap_uri = ldaps://ldap.gtopia.org:636
ldap_search_base = ou=users,o=gtopia
ldap_tls_cacertdir = /etc/ssl/certs
create_homedir = true
ldap_default_bind_dn = cn=SSSDBind,ou=service,o=gtopia
ldap_default_authtok_type = password
ldap_default_authtok = *****

#SUDOERS
sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,o=gtopia
#ldap_sudorule_object_class = sudoRole
sudoers_debug = 2
ldap_sudo_hostnames = client1.gtopia.org

Configuring SSH Keys in LDAP

Unless you’re using IPA, sshkeys in ldap cannot be done via sssd.   There is a very useful readme included.

debug: /usr/lib/ssh/ssh-ldap-helper -v -dd -s mark

Here is the Schema file suitable for loading sshPublicKeys into eDirectory.

dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.24552.500.1.1.1.13
    NAME 'sshPublicKey'
    DESC 'MANDATORY: OpenSSH Public key'
    EQUALITY octetStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.24552.500.1.1.2.0
    NAME 'ldapPublicKey'
    SUP top
    AUXILIARY
    DESC 'MANDATORY: OpenSSH LPK objectclass'
    MUST ( sshPublicKey $ uid ) )

 

You must configure an ldap.conf specifically for ssh.  This is useful in case something else mucks around with the openldap/ldap.conf file Here is all I needed in the /etc/ssh/ldap.conf

uri ldaps://ldap.gtopia.org
binddn cn=SSSDBind,ou=service,o=gtopia
bindpw ******
base ou=users,o=gtopia
scope sub
tls_cacertdir /etc/ssl/certs

Add these lines to sshd_config

#AuthorizedKeysCommand none
AuthorizedKeysCommand /usr/lib/ssh/ssh-ldap-wrapper
AuthorizedKeysCommandUser nobody

AuthorizedKeysFile      .ssh/authorized_keys

Test with the built in tools

~ # /usr/lib/ssh/ssh-ldap-helper -w -vv -dd -s mark
debug1: Reading configuration data /etc/ssh/ldap.conf
debug1: LDAP do connect
debug2: LDAP do connect OK
debug1: LDAP process user
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEA47di4ZmNoSWgFkjmaDry389Slhg7res4oploixROi8nL3CT3FsR9QzOrTuzOFuhZRkA5XMnh+QPXw6gX7xQJrktdm09QK5rblfZYLdAGdCpWYy2H1D79Ebbbrkm4dR/9GJJ5kAqBVV07Pn/LJCzaZ2l8E1pVLfz8JInW29aDTGdUG0s9C2loItSacA9K5A7lLrzrGQ3HTpD8+0SR0DQRG+sTpUJxwbrrHAFKRDvN8iy3STtP07jvzWrlJlIMHQ3QTY8sGORfrahQdZM2rhTnToDWyw+w/sBuVMZTJoftjcZVWw3El8mgWFvLoz3FKia7pMYN4cfxXDdpnSHiEbb23/DBdfyBPuILiDSgofJEJVJsU+xRAo4M8LpWSndN5ZJKSOAvpN6OWFx663auXRBYGAmPcnIgB9ZrYq79Xvf2+K7n9KYoskruQ6qjNPw1IDXTdJL4cqbJtcNqT8YIFGGu3pDwGfa/g1XXRj8GMH0nTN+Sysl2chz7pNiO4kBUwZD+PrPIeM+5gS8ObJ340bgHfvjE3IL33koh8glHmFGY9I1IP854Um3wk32lFPcJAIOgAlG98Wlr+XvAP7lzHAZUg1ak5BTlrKJTamsfEjLfAWMbrmTLeKmrdXQ4uDfJnxB7QYRQx6//p9ObLqrjOAizrJVaGOuNcOPFMMr7PDtFZts= Default
debug2: LDAP process user finished
debug1: LDAP do close
debug2: LDAP do close OK

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *