We're currently evaluating moving our CentOS6 Linux workstations and servers from OpenLDAP to AD, but would like to avoid the AD schema customization needed to put sudo rules and autofs mappings there.
So we thought about keeping sudo and autofs info on the OpenLDAP infrastructure, while authenticating against AD.
The latter works very nicely using "id_provider=ad".
Regarding sudo and autofs info, in sssd.conf I have set up a 2nd domain with id_provider=ldap and auth_provider=none, referring to the old OpenLDAP server.
Indeed I've got autofs working this way (mapping NFS home directories).
sudo however does not work. It seems sssd_sudo only searches in the cache file containing info of the AD domain (which has no sudo info). The OpenLDAP domain ( it's ldb cache file actually carries the sudo rules as per ldbsearch output) is apparently ignored - seems like the function sudosrv_get_sudorules_from_cache() just looks into the AD domain's cache ( where the account info of the current user stems from)
Is my "split" approach totally flawed? Is there a way to make it work without patching the sssd_sudo sources to iterate over all domain caches ?
I can provide sssd.conf and log files. Just wanted to hear first about whether the approach should work at all and possible alternatives ...
Many thanks for comments/hints/proposals,
Uli
On 19 Jan 2018, at 15:03, Johannes-Ulrich Menzebach j.menzebach@dirac.ruhr.de wrote:
We're currently evaluating moving our CentOS6 Linux workstations and servers from OpenLDAP to AD, but would like to avoid the AD schema customization needed to put sudo rules and autofs mappings there.
So we thought about keeping sudo and autofs info on the OpenLDAP infrastructure, while authenticating against AD.
The latter works very nicely using "id_provider=ad".
Regarding sudo and autofs info, in sssd.conf I have set up a 2nd domain with id_provider=ldap and auth_provider=none, referring to the old OpenLDAP server.
Indeed I've got autofs working this way (mapping NFS home directories).
sudo however does not work. It seems sssd_sudo only searches in the cache file containing info of the AD domain (which has no sudo info). The OpenLDAP domain ( it's ldb cache file actually carries the sudo rules as per ldbsearch output) is apparently ignored - seems like the function sudosrv_get_sudorules_from_cache() just looks into the AD domain's cache ( where the account info of the current user stems from)
Is my "split" approach totally flawed? Is there a way to make it work without patching the sssd_sudo sources to iterate over all domain caches ?
I’m afraid it is expected that this setup doesn’t work, because one of the design decisions about the SSSD domains was that data should not overflow from one domain to another. So a user can only leverage sudo rules from their own domain.
I haven’t tried this at all, but as long as the id_provider and auth_provider are using ad, could you just add sudo_provider=ldap and then your sudo OpenLDAP server with as value of ldap_uri? Since two providers of two different types also don’t share data, it might work.
An alternative is always to use the built-in sudo LDAP support..
I can provide sssd.conf and log files. Just wanted to hear first about whether the approach should work at all and possible alternatives ...
Many thanks for comments/hints/proposals,
Uli
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Johannes-Ulrich Menzebach