1:44 p.m.
New subject: RHEL5, sssd and the Global Catalog (Jakub Hrozek)
On Thu, May 09, 2013 at 09:39:07AM -0400, Will_Darton(a)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
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) ?
Can you check if the POSIX attributes are replicated to the Global
Catalog (sorry, in a rush right now, can't check).
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)'
3:24 a.m.
New subject: RHEL5, sssd and the Global Catalog (Jakub Hrozek)
On Thu, May 09, 2013 at 03:06:30PM -0400, Will_Darton(a)navyfederal.org wrote:
<sssd-users-bounces(a)lists.fedorahosted.org> wrote on
05/09/2013 02:44:00
PM:
> From: Jakub Hrozek <jhrozek(a)redhat.com>
> To: <sssd-users(a)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(a)lists.fedorahosted.org>
>
> On Thu, May 09, 2013 at 09:39:07AM -0400, Will_Darton(a)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 ?
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?
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.
> 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(a)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(a)navyfederal.org
> */
>
> References
>
> Visible links
> 1. https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
3998
days inactive
3999
days old
sssd-users@lists.fedorahosted.org
4 comments
2 participants
participants (2)
-
Jakub Hrozek -
Will_Darton＠navyfederal.org