Having pain with user authentication on your old legacy Unix servers? Here comes the solution: ID-Views via LDAP.
If you need to preserve UID/GID or other stuff like shell on some legacy servers but want to have the benefits of a centrally managed identity management, then ID-Views is the answer. Since legacy servers usually do not have SSSD on board, such as traditional Unix Systems, you can also use LDAP to authenticate such users.
Use cases
You have different users with the same login ID but with different UID, GID shell, password etc. you can create User ID overrides and map them to your legacy users.
You can override the Shell. I.e. in AIX the Bash is in /usr/bin/bash and not like in Linux /bin/bash. Or you can set the Shell to /bin/ksh for AIX servers.
Be aware
On the long term you should clean up messy old environments as ID-views adds some complexity to your identity management. As those old kind of servers tend to be replaced with newer Linux distributions, they will die over the next years. At the end, ID-views can greatly help you during a transition period.
Test lab setup
- Your IPA server is called ipa1.example.com
- The example client is called ldap-view.example.com
- The ID-View is called oldstuff
- Example is named jdoe
What are ID-Views
Basically ID-Views are mappings of user credentials stored in a different LDAP base DN. This is: cn=myview,cn=views,cn=compat,dc=example,dc=com
where myview is replaced by the particular ID-View in this example “oldstuff”.
Underneath there are users and groups, so a complete ID-View DN for users would be cn=users,cn=oldstuff,cn=views,cn=compat,dc=example,dc=com.
Creating an ID-View
Log in to you IPA server and ensure you have a valid Kerberos Ticket for the admin user.
[root@ipa1 ~]# ipa idview-add --desc="Our old Unix Servers" oldstuff ------------------------ Added ID View "oldstuff" ------------------------ ID View Name: oldstuff Description: Our old Unix Servers [root@ipa1 ~]#
Next lets map a user. Lets assume that user jdoe need to have a login name of joe, a Korn shell, must be in the group with GIG 1002, has the UID of 1001 and has a home directory of /export/home instead of the standard values.
[root@ipa1 ~]# ipa idoverrideuser-add --desc="Overrides for Joe Doe" --shell=/bin/ksh --homedir=/export/home --uid=1001 --gidnumber=1002 oldstuff jdoe ----------------------------- Added User ID override "jdoe" ----------------------------- Anchor to override: jdoe Description: Overrides for Joe Doe UID: 1001 GID: 1002 Home directory: /export/home Login shell: /bin/ksh [root@ipa1 ~]#
If you want to use this ID-view with SSSD and ipa-client enabled machines, you can assign hosts and host groups to the ID-view. As this article is just taking care of legacy LDAP clients, this is out-of-scope.
Client Configuration
This varies from Linux distribution to another, traditional Unix servers are even more different. If in doubt, please consult your vendors manual.
For some Linux distributions, IPA can give you some hints how to configure your client.
[root@ipa1 ~]# ipa-advise ---------------------------------------------------------------------- List of available advices ---------------------------------------------------------------------- config-fedora-authconfig : Authconfig instructions for configuring Fedora 18/19 client with IPA server without use of SSSD. config-freebsd-nss-pam-ldapd : Instructions for configuring a FreeBSD system with nss-pam-ldapd. config-generic-linux-nss-pam-ldapd : Instructions for configuring a system with nss-pam-ldapd. This set of instructions is targeted for linux systems that do not include the authconfig utility.
<More output omitted>
Select the systems that match best for your system to configure. In my example I’ll use config-redhat-nss-pam-ldapd
[root@ipa1 ~]# ipa-advise config-redhat-nss-pam-ldapd #!/bin/sh # ---------------------------------------------------------------------- # Instructions for configuring a system with nss-pam-ldapd as a IPA # client. This set of instructions is targeted for platforms that # include the authconfig utility, which are all Red Hat based platforms. # ---------------------------------------------------------------------- # Schema Compatibility plugin has not been configured on this server. To # configure it, run "ipa-adtrust-install --enable-compat" # Install required packages via yum yum install -y wget openssl nss-pam-ldapd pam_ldap authconfig # NOTE: IPA certificate uses the SHA-256 hash function. SHA-256 was # introduced in RHEL5.2. Therefore, clients older than RHEL5.2 will not # be able to interoperate with IPA server 3.x. # Please note that this script assumes /etc/openldap/cacerts as the # default CA certificate location. If this value is different on your # system the script needs to be modified accordingly. # Download the CA certificate of the IPA server mkdir -p -m 755 /etc/openldap/cacerts wget http://ipa1.example.com/ipa/config/ca.crt -O /etc/openldap/cacerts/ipa.crt # Generate hashes for the openldap library command -v cacertdir_rehash if [ $? -ne 0 ] ; then wget "https://fedorahosted.org/authconfig/browser/cacertdir_rehash?format=txt" -O cacertdir_rehash ; chmod 755 ./cacertdir_rehash ; ./cacertdir_rehash /etc/openldap/cacerts/ ; else cacertdir_rehash /etc/openldap/cacerts/ ; fi # Use the authconfig to configure nsswitch.conf and the PAM stack authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=compat,dc=example,dc=com
Since this ipa-advice command is normally used for “standard” LDAP authentication, not for ID-Views. So we need to adjust the base DN to match the DN for the ID-View in question. The correct base DN for the example created above is cn=oldstuff,cn=views,cn=compat,dc=example,dc=com.
[root@ldap-view ~]# authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=oldstuff,cn=views,cn=compat,dc=example,dc=com -disablesssd --disablesssdauth [root@ldap-view ~]#
Optionally, you can also enable Kerberos:
[root@ldap-view ~]# authconfig --updateall --enableldap --enableldapauth --ldapserver=ldap://ipa1.example.com --ldapbasedn=cn=oldstuff,cn=views,cn=compat,dc=example,dc=com --disablesssd --disablesssdauth --enablekrb5 --enablekrb5kdcdns --enablekrb5realmdns [root@ldap-view ~]#
The script configures /etc/openldap/ldap.conf and /etc/nslcd.conf (and optionally /etc/krb5.conf) with the correct LDAP URI and base DN. On other systems, please consult your vendors manual on how to set those parameters.
Check the result
There are basically two methods to look up the user credentials: id and getent.
[root@ldap-view ~]# getent passwd jdoe jdoe:*:1001:1002:John Doe:/export/home:/bin/ksh [root@ldap-view ~]#
Lets switch to that user
[root@ldap-view ~]# su - jdoe Last login: Mon Nov 16 19:47:04 CET 2015 on pts/0 -ksh-4.2$ id uid=1001(jdoe) gid=1002 groups=1002 context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 -ksh-4.2$
Pitfalls
UID and GID Ranges
A decade ago it was the fashion that numeric UIDs begin with 500. Modern Linux systems start at 1000 and this is also a restriction in PAM. Check every file in /etc/pam.d/ for uid >= 1000 and uid < 1000. Change them to the value you need for your legacy system.
HBAC (Host Based Access Control)
There is one problematic issue with Non-SSSD authentication: There is no centrally managed HBAC possible. You can achieve this in two ways: LDAP filtering and sshd configuration.
If you are using PAM only fro ssh access, then configuring sshd is less complex. Just add AllowGroups oldstuff
to /etc/ssh/sshd_config and restart the daemon.
However, there is pam_hbac which is currently being developed. PLease have a look at https://github.com/jhrozek/pam_hbac for more information.
Have fun? No, definitively not with old stuff dinosaur style computing. But at least its less painful 😉
Hi Luc,
I’ve been looking into using views for legacy clients but haven’t been successful. Hope you have time to give me a hand.
Taking your setup as an example, if I user as basedn “cn=compat,dc=example,dc=com” I’m able to query users, but if I switch it to the view dn “cn=oldstuff,cn=views,cn=compat,dc=example,dc=com” it doesn’t work.
As I’m able to do an ldapsearch looking for users and find my users either in “cn=compat,dc=example,dc=com” and “cn=accounts,dc=example,dc=com” I should also be able to find them in “cn=oldstuff,cn=views,cn=compat,dc=example,dc=com”, but it doesn’t return any entries and I guess that’s the reason why the login using id views isn’t working for me.
Could this be related to the IPA version? I’m using IPA 4.2.0 (ipa-server-4.2.0-15.el7_2.15).
I haven’t found any other documentation saying that it’s possible to query users under the “views” dn, do you know if it’s and undocumented and unsupported feature?
From what I understand from the documentation by creating a view, it only enables us to query users under the “compat” dn.
Hope you can help me.
Thanks in advance.
JS
Hi,
Its supposed to be working but hard to debug if its not. Having a look at /var/log/dirsrv/slapd-EXAMPLE-COM/access shows you if the server is actually queried or not.