<sssd-users-bounces@lists.fedorahosted.org> wrote
on 05/10/2013 04:24:57 AM:
> From: Jakub Hrozek <jhrozek@redhat.com>
> To: <sssd-users@lists.fedorahosted.org>,
> Date: 05/10/2013 04:25 AM
> Subject: Re: [SSSD-users] RHEL5, sssd and the
Global Catalog (Jakub Hrozek)
> Sent by: <sssd-users-bounces@lists.fedorahosted.org>
>
> On Thu, May 09, 2013 at 03:06:30PM -0400, Will_Darton@navyfederal.org
wrote:
> > <sssd-users-bounces@lists.fedorahosted.org>
wrote on 05/09/2013 02:44:00
> > PM:
> >
> > > From: Jakub Hrozek <jhrozek@redhat.com>
> > > To: <sssd-users@lists.fedorahosted.org>,
> > > Date: 05/09/2013 02:44 PM
> > > Subject: Re: [SSSD-users] RHEL5, sssd and the
Global Catalog (Jakub
> > Hrozek)
> > > Sent by: <sssd-users-bounces@lists.fedorahosted.org>
> > >
> > > On Thu, May 09, 2013 at 09:39:07AM -0400, Will_Darton@navyfederal.org
> > wrote:
> > > > If this comes across as HTML
sorry.. gotta find a better mail
> > client for
> > > > mailing lists... :/
> > > > I grabbed these logs right
after attempting a su - espadmin, so
> > that
> > > > should narrow down whats
there. I should mention this happens on
> > any
> > > > RHEL5 server, not just this
specific one, but it only happens with
> > a
> > > > couple of accounts from the
Global Catalog, not all of them...
> > > > Which leads me to believe
its something specific to
> RHEL5 and these
> > two
> > > > accounts.. just not
sure what is missing that RHEL5 is expecting?
> >
> > > >
> > > > Thanks for the assist.
> > > >
> > >
> > > Here is one peculiar thing - the SSSD was searching
for a
> user entry and
> > > got two results. Are you sure you're not seeing
a similar
> message on the
> > > RHEL6 clients?
> >
> > >
> > > > (Thu May 9 09:34:47
2013) [sssd[be[nfcu]]] [sdap_get_initgr_user]
> > (2):
> > > > Expected one user entry and
got 2
> > >
> >
> > I did get the same error on the RHEL6 side, but
it does not prevent su -
> > espadmin
> >
>
> > [root@slvdcls40 sssd]# grep "got 2" sssd_nfcu.log
> > (Thu May 9 15:03:09 2013) [sssd[be[nfcu]]]
[sdap_get_initgr_user]
> > (0x0040): Expected one user entry and got 2
> > (Thu May 9 15:03:09 2013) [sssd[be[nfcu]]]
[sdap_get_initgr_user]
> > (0x0040): Expected one user entry and got 2
>
> After re-checking the logs again, it seems that the real issue is
the
> lack of UID in the entry that the SSSD attempted to save. Saving the
> entry fails and the identity information can't be retrieved, so even
the
> login fails.
>
> Do the searches start working if you set:
> ldap_user_search_base = OU=UserAccounts,DC=hq,DC=nfcu,DC=net
>
>
> Does "getent passwd espadmin" or "id espadmin"
work ?
So if I set the search base to that location, everything
works fine. Which leads me to believe that RHEL5 is handling the
results of the search differently than RHEL6..
[root@slvdcls33 ~]# grep ldap_user_search_base
/etc/sssd/sssd.conf
ldap_user_search_base = OU=UserAccounts,DC=hq,DC=nfcu,DC=net
[root@slvdcls33 ~]# su - espadmin
2-[espadmin@slvdcls33 ~] ~$id
uid=1501(espadmin) gid=1501(esp) groups=1501(esp),2209(ibmcmgrp),9998(unix)
2-[espadmin@slvdcls33 ~] ~$getent
passwd espadmin
espadmin:*:1501:1501:ESP Admin:/home/espadmin:/bin/ksh
2-[espadmin@slvdcls33 ~] ~$id espadmin
uid=1501(espadmin) gid=1501(esp) groups=1501(esp),9998(unix),2209(ibmcmgrp)
>
> >
> > I'm having the AD Engineers doublecheck me here,
but I did find this:
> > # espadmin, SecureUsers, UserAccounts, hq.nfcu.net
> > dn: CN=espadmin,OU=SecureUsers,OU=UserAccounts,DC=hq,DC=nfcu,DC=net
> > cn: espadmin
> > department: esp
> > uid: espadmin
> > loginShell: /bin/ksh
> > unixHomeDirectory: /home/espadmin
> > gecos: ESP Admin
> > gidNumber: 1501
> > uidNumber: 1501
>
> Ah, looks like the POSIX mapping attributes are correct, thank you
for
> checking.
>
> >
> > # ESPAdmin, !UserAccounts, nfcu.net
> > dn: CN=ESPAdmin,OU=!UserAccounts,DC=nfcu,DC=net
> > cn: ESPAdmin
> > sn: ESPAdmin
>
> Interesting, is there no objectclass in this entry?
No this entry is probably just junk stuck out there
by someone.. I'm trying to get it removed, as I expect this will resolve
this issue.
>
> In the SSSD logs, I see that the SSSD tried to process this entry
and
> not the one with the POSIX attributes and failed to retrieve the
> uidNumber. I think that setting the user ldap search base should help
> you.
>
> >
> > Would/should RHEL5 and RHEL6 have a difference in
their response to
> > multiple accounts ?
> >
>
> At first I suspected that on RHEL6 we'd also require the presence
of a
> UID attribute in the LDAP search, but it's actually not the case.
>
> Perhaps there is an ordering issue, so if the search matches two entries,
> then maybe by chance SSSD (or LDAP libraries) on RHEL6 select the
one
> that contains the posix attributes.
It would surprise me a little that the mechanism is
different on RHEL6 than RHEL5. But only a little surprising..
so would this be a bug? or a "feature"
or functions as designed.
I have a case open with Red Hat for this issue already,
but I usually find I get faster support coming to the lists.
>
> > > The other interesting point I found in the
logs is:
> > > > (Thu May 9 09:34:46
2013) [sssd[be[nfcu]]] [sdap_save_user] (9):
> > Save
> > > > user
> > > > (Thu May 9 09:34:46
2013) [sssd[be[nfcu]]] [sdap_save_user] (1):
> > no uid
> > > > provided for [ESPAdmin] in
domain [nfcu].
> > >
> > > It seems that the SSSD didn't find the UID
number..are you
> sure the SSSD
> > > is configured to read the correct attributes
(and you're not missing a
> > > mapping to e.g. msSFU30UidNumber) ?
> >
> > I haven't messed with any mappings save for one:
> > ldap_user_name = cn
> >
> > So if there is another location where I could validate
this and you can
> > let me know I'll take a look.
> >
> > I don't see that attribute msSFU30UidNumber in the
ldapsearch above
> > (either via ldaps or Global Catalog).
>
> No, you're right, the attribute mappings look correct.
>
> > >
> > > Can you check if the POSIX attributes are replicated
to the Global
> > > Catalog (sorry, in a rush right now, can't
check).
> >
> > Here's the POSIX attributes, which I'm fairly certain
are all there
> > # espadmin, SecureUsers, UserAccounts, hq.nfcu.net
> > dn: CN=espadmin,OU=SecureUsers,OU=UserAccounts,DC=hq,DC=nfcu,DC=net
> > cn: espadmin
> > department: esp
> > uid: espadmin
> > loginShell: /bin/ksh
> > unixHomeDirectory: /home/espadmin
> > gecos: ESP Admin
> > gidNumber: 1501
> > uidNumber: 1501
>
> Yes, thanks for checking. I wasn't sure if they are all replicated
in
> the GC.
>
> >
> > # ESPAdmin, !UserAccounts, nfcu.net
> > dn: CN=ESPAdmin,OU=!UserAccounts,DC=nfcu,DC=net
> > cn: ESPAdmin
> > sn: ESPAdmin
> >
> > # search result
> > search: 2
> > result: 0 Success
> > >
> > > Can you simulate the search using ldapsearch?
> > >
> > > Something like:
> > > $ ldapsearch -H ldap://your.server:3268 -D
"bind_dn" -w "bind_pwd" -
> > > b DC=nfcu,DC=net '(&(cn=espadmin)(objectclass=user)'
> > >
> > > _______________________________________________
> > > sssd-users mailing list
> > > sssd-users@lists.fedorahosted.org
> > > [1]https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> >
> > /* -----------------------------
> > Will Darton
> > I.T. Operations
> > Information Services
> > Navy Federal Credit Union
> > wk 703.255.8639
> > cell: 703.232.2344
> > will_darton@navyfederal.org
> > */
> >
> > References
> >
> > Visible links
> > 1. https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users@lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
> _______________________________________________
> sssd-users mailing list
> sssd-users@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users