<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

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

# ESPAdmin, !UserAccounts, nfcu.net
dn: CN=ESPAdmin,OU=!UserAccounts,DC=nfcu,DC=net
cn: ESPAdmin
sn: ESPAdmin

Would/should RHEL5 and RHEL6 have a difference in their response to multiple accounts ?  


> 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).

>
> 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

# 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
>
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

*/