On (23/09/13 13:35), Lukas Slebodnik wrote:
>On (23/09/13 13:14), Jakub Hrozek wrote:
>>On Mon, Sep 23, 2013 at 12:40:00PM +0200, Jean-Baptiste Denis wrote:
>>> Hi,
>>>
>>> I'm using a trick, suggested with CAUTION by Jakub, that allows me to
>>> have all user using local home directory
>>> and some honoring their ldap ones.
>>>
>>> This is the spirit of my sssd.conf :
>>>
>>> ====================
>>> [sssd]
>>> config_file_version = 2
>>> services = nss, pam
>>> domains = local_home, ldap_home
>>>
>>> [nss]
>>> filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
>>> override_shell = /bin/bash
>>>
>>> [domain/local_home]
>>> override_homedir = /home/%u
>>> filter_users = john
>>> id_provider = ldap
>>> ldap_uri =
ldap://ldap.example.com/
>>>
>>> # same as above, without override_homedir and filter_users
>>> [domain/ldap_home]
>>> id_provider = ldap
>>> ldap_uri =
ldap://ldap.example.com/
>>> ====================
>>>
>>>
>>> I think I've got a side effect from this setup when I'm dealing
directly
>>> with uid.
>>>
>>> For example, if the filtered user has uid 4242, after a fresh restart of
>>> sssd, I cannot perform an uid -> username resolution :
>>>
>>> $ getent passwd 4242
>>> $ # NOANSWER
>>>
>>> But if try to get the john entry, everything is good after that
>>>
>>> $ getent passwd john
>>> john:*:4242:1010:John John:/ldap_home/john:/bin/bash
>>> $ getent passwd 4242
>>> john:*:4242:1010:John John:/ldap_home/john:/bin/bash
>>>
>>> But, if I restart sssd, it doesn't work anymore :
>>>
>>> # service sssd restart
>>> # getent passwd 4242
>>> # # NOANSWER
>>>
>>> Here is the corresponding sssd_nss.log when I've got no answer after
>>> sssd restart :
>>>
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [accept_fd_handler] (0x0400):
>>> Client connected!
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [sss_cmd_get_version] (0x0200):
>>> Received client version [1].
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [sss_cmd_get_version] (0x0200):
>>> Offered version [1].
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [sss_dp_issue_request] (0x0400):
>>> Issuing request for [0x4339e0:domains@local_home]
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [sss_dp_get_domains_msg]
>>> (0x0400): Sending get domains request for [local_home][not forced][]
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [sss_dp_internal_get_send]
>>> (0x0400): Entering request [0x4339e0:domains@local_home]
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [sss_dp_issue_request] (0x0400):
>>> Issuing request for [0x4339e0:domains@ldap_home]
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [sss_dp_get_domains_msg]
>>> (0x0400): Sending get domains request for [ldap_home][not forced][]
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [sss_dp_internal_get_send]
>>> (0x0400): Entering request [0x4339e0:domains@ldap_home]
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
>>> Deleting request: [0x4339e0:domains@local_home]
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [nss_cmd_getpwuid_search]
>>> (0x0100): Requesting info for [4242@local_home]
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [check_cache] (0x0400): Cached
>>> entry is valid, returning..
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [nss_cmd_getpwuid_search]
>>> (0x0400): Returning info for uid [4242@local_home]
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [fill_pwent] (0x0100): User
>>> [john@local_home] filtered out! (negative cache)
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [sss_dp_req_destructor] (0x0400):
>>> Deleting request: [0x4339e0:domains@ldap_home]
>>> (Mon Sep 23 12:32:02 2013) [sssd[nss]] [client_recv] (0x0200): Client
>>> disconnected!
>>>
>>> The line that worries me is this one '[fill_pwent] (0x0100): User
>>> [john@local_home] filtered out! (negative cache)'. My request does not
>>> seem to go through my fallback domain "ldap_home".
>>>
>>> What do you think ?
>>
>>That's a side-effect of the hack I didn't think about..I didn't
realize
>>we also check the negative cache again when returning the users.
>>
>>Can you check if it would help to use "filter_users = john@local_home"
?
>>
>This will not help, because john can be found in the both domains.
>Like Pavel wrote, we don't skip first domain if getpwuid is called.
>
>>Or alternatively, can you try a little different config? Instead of
>>filtering the user that needs a different homedir using the filter_user
>>option, maybe he could be filtered using an LDAP filter:
>>
>>[domain/local_home]
>>override_homedir = /home/%u
>>filter_users = john
>>id_provider = ldap
>>ldap_uri =
ldap://ldap.example.com/
>># Match all uses but john
>>ldap_user_search_filter = (!(cn=john))
>I check also this option and it didn't help.
>
Solution with ldap_user_search_filter works, but with different filter.
ldap_user_search_filter = (!(uid=usersssd01))
I tested configuration with IPA and cn attribute contains different value.
# usersssd01, users, accounts,
idm.lab.eng.brq.redhat.com
dn: uid=usersssd01,cn=users,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
cn: sssd user
^^^^^^^^^
This is a reason why ldap filter didn't work for me.
uid: usersssd01
uidNumber: 325600011
gidNumber: 325600011
// other attributes are omitted.
LS