Re: [SSSD-users] Multiple ldap accounts for sudo and users in sssd.conf

2013-05-10 Thread michael gabriel
Thanks for the update.  That's what I suspected.

 I will suggest to the powers above that we use one account but I don't
think that will happen.

Regards

MickeyG


On Thu, May 9, 2013 at 7:09 PM, Jakub Hrozek  wrote:

> On Thu, May 09, 2013 at 04:20:43PM +0100, michael gabriel wrote:
> > Hi there,
> >
> > We have two different ldap "accounts". One is used to get user account
> > information and the other is used get sudo information.
> >
> > Is there way to have two ldap_default_bind_dn's and
> ldap_default_authtok's
> > for each of these account configured in sssd.conf.
>
> No, currently that's not possible, sorry. The SSSD currently only keeps
> one connection to the LDAP server open for retrieving identity
> information and only performs binds to authenticate users.
>
> Is there a reason you don't want to use the "sudo" account to read user
> information as well? Is only the other account permitted to read
> non-sudoers information?
> ___
> 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


Re: [SSSD-users] RHEL5, sssd and the Global Catalog (Jakub Hrozek)

2013-05-10 Thread Jakub Hrozek
On Thu, May 09, 2013 at 03:06:30PM -0400, will_dar...@navyfederal.org wrote:
> wrote on 05/09/2013 02:44:00
>PM:
> 
>> From: Jakub Hrozek 
>> To: ,
>> Date: 05/09/2013 02:44 PM
>> Subject: Re: [SSSD-users] RHEL5, sssd and the Global Catalog (Jakub
>Hrozek)
>> Sent by: 
>>
>> On Thu, May 09, 2013 at 09:39:07AM -0400, will_dar...@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
t

Re: [SSSD-users] RHEL5, sssd and the Global Catalog (Jakub Hrozek)

2013-05-10 Thread Will_Darton
 wrote
on 05/10/2013 04:24:57 AM:

> From: Jakub Hrozek 
> To: ,

> Date: 05/10/2013 04:25 AM
> Subject: Re: [SSSD-users] RHEL5, sssd and the
Global Catalog (Jakub Hrozek)
> Sent by: 
> 
> On Thu, May 09, 2013 at 03:06:30PM -0400, will_dar...@navyfederal.org
wrote:
> >    
wrote on 05/09/2013 02:44:00
> >    PM:
> > 
> >    > From: Jakub Hrozek 
> >    > To: ,
> >    > Date: 05/09/2013 02:44 PM
> >    > Subject: Re: [SSSD-users] RHEL5, sssd and the
Global Catalog (Jakub
> >    Hrozek)
> >    > Sent by: 
> >    >
> >    > On Thu, May 09, 2013 at 09:39:07AM -0400, will_dar...@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 t

Re: [SSSD-users] Ldap Help

2013-05-10 Thread Brandon Foster
ok so after some modification of the ldap server and use of the
override functions I was able to make it work.
I can now id test.user and get a result, as  well as log in as my ldap users.

But when I do getent passwd |grep  i dont get anything back.

any ideas why?

On Thu, May 9, 2013 at 3:32 AM, Jakub Hrozek  wrote:
> On Wed, May 08, 2013 at 01:29:24PM -0400, Dmitri Pal wrote:
>> On 05/08/2013 12:57 PM, Brandon Foster wrote:
>> > On Wed, May 8, 2013 at 9:52 AM, Sumit Bose  wrote:
>> >> On Wed, May 08, 2013 at 09:43:48AM -0700, Brandon Foster wrote:
>> >>> On Wed, May 8, 2013 at 9:26 AM, Wojtak, Greg (Superfly)
>> >>>  wrote:
>>  I think your syntax is a little off.  Try
>> 
>>  ldapsearch -x -LLL '(&(uid=test.user)(objectClass=posixAccount))' uid
>>  uidnumber homedirectory gidnumber loginshell
>> 
>>  You should have those 5 values returned.
>> 
>>  --
>>  Greg Wojtak
>>  Senior Unix Systems Engineer
>>  Office: (313) 373-4306
>>  Mobile: (734) 718-8472
>> 
>> 
>> 
>> 
>> 
>> 
>>  On 5/8/13 11:52 AM, "Brandon Foster"  wrote:
>> 
>> > On Wed, May 8, 2013 at 5:05 AM, Sumit Bose  wrote:
>> >> On Tue, May 07, 2013 at 11:39:45AM -0700, Brandon Foster wrote:
>> >>> Hey all,
>> >>> Im back with another ldap question. this time I rebuilt sssd and
>> >>> followed this guide:
>> >>>
>> >>> http://blog.f1linux.com/2013/04/21/howto-part-3-ldap-client-configuratio
>> >>> n-and-troubleshooting/
>> >>> for setting up ldap authentication on my centos 6.4 system.
>> >>>
>> >>> my firewall is off and selinux is disabled.
>> >>>
>> >>> when i do an ldapsearch -x "cn=test.user" it returns all the correct
>> >>> information, but doing id test.user returns no user.
>> >> As you can see from the logs SSSD is using
>> >> "(&(uid=test.user)(objectclass=posixAccount))" as search filter, can 
>> >> you
>> >> check if ldapsearch with this filter finds the entry as well?
>> >> Additionally can you check that the user object is located below the
>> >> search base you have given in sssd.conf?
>> >>
>> >> HTH
>> >>
>> >> bye,
>> >> Sumit
>> >>> I've attached the log files and all of the relevant files and maybe
>> >>> some non relevant ones as well.
>> >>>
>> >>> it appears as tho it is searching for the user but is simply not
>> >>> finding anything. Is there an option to search for cn=test.user? and
>> >>> not by uid?
>> >>>
>> >>> any help will be much appreciated.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>> ___
>> >>> 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
>> > thanks for the reply,
>> > the user is definitely under the groups in sssd.conf.
>> >
>> > ldapsearch with objectclass=posixAccount seems to be part of the
>> > issue. Also it is searching for uid rather than the cn of the user.
>> >
>> > if I do ldapsearch -x "uid= it works fine
>> >
>> > if i do ldapsearch -x "uid="
>> > "objectclass=posixAccount" it does not.
>> >
>> > ldapsearch -x "uid=test.user" returns all of the users in the search.
>> >
>> > and finally ldapsearch -x "uid=test.user" "objectclass=posixAccount"
>> > returns no users.
>> >
>> > so how do I tell my sssd to not use this filter? and to use cn instead 
>> > of
>> > uid?
>> > ___
>> > 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
>> >>>
>> >>> sorry, not to familiar with the ldapsearch commands.
>> >>>
>> >>> anyways, test.user is not of objectclass posixAccoount so with that
>> >>> filter nothing comes back, if I change it to cn= and objectclass=> >>> objectlcass test.user is a part of> then it just returns the DN of the
>> >>> user.
>> >>>
>> >>> ldap_user_name = cn
>> >>> ldap_user_object_class =
>> >>>
>> >>> attributes in sssd.conf seem to be altering these values for me when i
>> >>> search for the id of test.user.
>> >>>
>> >>> but it cant seem to find uiduidnumber homedirectory gidnumber or
>> >>> loginshell attributes for my users.
>> >> it looks that you are using a custom LDPA schema. You can map the
>> >> default attributes for home directory etc to other values with
>> >>
>> >> ldap_use

Re: [SSSD-users] Ldap Help

2013-05-10 Thread Ondrej Valousek

Sssd does not enumerate by default so this is pretty much expected behaviour.
Try "getent passwd username" instead.
O.

Odesláno ze Samsung Mobile

Brandon Foster  napsal:
ok so after some modification of the ldap server and use of the
override functions I was able to make it work.
I can now id test.user and get a result, as  well as log in as my ldap users.

But when I do getent passwd |grep  i dont get anything back.

any ideas why?

On Thu, May 9, 2013 at 3:32 AM, Jakub Hrozek  wrote:
> On Wed, May 08, 2013 at 01:29:24PM -0400, Dmitri Pal wrote:
>> On 05/08/2013 12:57 PM, Brandon Foster wrote:
>> > On Wed, May 8, 2013 at 9:52 AM, Sumit Bose  wrote:
>> >> On Wed, May 08, 2013 at 09:43:48AM -0700, Brandon Foster wrote:
>> >>> On Wed, May 8, 2013 at 9:26 AM, Wojtak, Greg (Superfly)
>> >>>  wrote:
>>  I think your syntax is a little off.  Try
>> 
>>  ldapsearch -x -LLL '(&(uid=test.user)(objectClass=posixAccount))' uid
>>  uidnumber homedirectory gidnumber loginshell
>> 
>>  You should have those 5 values returned.
>> 
>>  --
>>  Greg Wojtak
>>  Senior Unix Systems Engineer
>>  Office: (313) 373-4306
>>  Mobile: (734) 718-8472
>> 
>> 
>> 
>> 
>> 
>> 
>>  On 5/8/13 11:52 AM, "Brandon Foster"  wrote:
>> 
>> > On Wed, May 8, 2013 at 5:05 AM, Sumit Bose  wrote:
>> >> On Tue, May 07, 2013 at 11:39:45AM -0700, Brandon Foster wrote:
>> >>> Hey all,
>> >>> Im back with another ldap question. this time I rebuilt sssd and
>> >>> followed this guide:
>> >>>
>> >>> http://blog.f1linux.com/2013/04/21/howto-part-3-ldap-client-configuratio
>> >>> n-and-troubleshooting/
>> >>> for setting up ldap authentication on my centos 6.4 system.
>> >>>
>> >>> my firewall is off and selinux is disabled.
>> >>>
>> >>> when i do an ldapsearch -x "cn=test.user" it returns all the correct
>> >>> information, but doing id test.user returns no user.
>> >> As you can see from the logs SSSD is using
>> >> "(&(uid=test.user)(objectclass=posixAccount))" as search filter, can 
>> >> you
>> >> check if ldapsearch with this filter finds the entry as well?
>> >> Additionally can you check that the user object is located below the
>> >> search base you have given in sssd.conf?
>> >>
>> >> HTH
>> >>
>> >> bye,
>> >> Sumit
>> >>> I've attached the log files and all of the relevant files and maybe
>> >>> some non relevant ones as well.
>> >>>
>> >>> it appears as tho it is searching for the user but is simply not
>> >>> finding anything. Is there an option to search for cn=test.user? and
>> >>> not by uid?
>> >>>
>> >>> any help will be much appreciated.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>> ___
>> >>> 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
>> > thanks for the reply,
>> > the user is definitely under the groups in sssd.conf.
>> >
>> > ldapsearch with objectclass=posixAccount seems to be part of the
>> > issue. Also it is searching for uid rather than the cn of the user.
>> >
>> > if I do ldapsearch -x "uid= it works fine
>> >
>> > if i do ldapsearch -x "uid="
>> > "objectclass=posixAccount" it does not.
>> >
>> > ldapsearch -x "uid=test.user" returns all of the users in the search.
>> >
>> > and finally ldapsearch -x "uid=test.user" "objectclass=posixAccount"
>> > returns no users.
>> >
>> > so how do I tell my sssd to not use this filter? and to use cn instead 
>> > of
>> > uid?
>> > ___
>> > 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
>> >>>
>> >>> sorry, not to familiar with the ldapsearch commands.
>> >>>
>> >>> anyways, test.user is not of objectclass posixAccoount so with that
>> >>> filter nothing comes back, if I change it to cn= and objectclass=> >>> objectlcass test.user is a part of> then it just returns the DN of the
>> >>> user.
>> >>>
>> >>> ldap_user_name = cn
>> >>> ldap_user_object_class =
>> >>>
>> >>> attributes in sssd.conf seem to be altering these values for me when i
>> >>> search for the id of test.user.
>> >>>
>> >>> but it cant seem to find uiduidnumber homedirectory gidnumber or
>> >>> loginshell attributes fo

Re: [SSSD-users] Ldap Help

2013-05-10 Thread Brandon Foster
cool that did it,
And enumerate =true made the grep command work as well.

thanks!

On Fri, May 10, 2013 at 11:26 AM, Ondrej Valousek  wrote:
>
> Sssd does not enumerate by default so this is pretty much expected
> behaviour.
> Try "getent passwd username" instead.
> O.
>
> Odesláno ze Samsung Mobile
>
> Brandon Foster  napsal:
> ok so after some modification of the ldap server and use of the
> override functions I was able to make it work.
> I can now id test.user and get a result, as  well as log in as my ldap
> users.
>
> But when I do getent passwd |grep  i dont get anything back.
>
> any ideas why?
>
> On Thu, May 9, 2013 at 3:32 AM, Jakub Hrozek  wrote:
>> On Wed, May 08, 2013 at 01:29:24PM -0400, Dmitri Pal wrote:
>>> On 05/08/2013 12:57 PM, Brandon Foster wrote:
>>> > On Wed, May 8, 2013 at 9:52 AM, Sumit Bose  wrote:
>>> >> On Wed, May 08, 2013 at 09:43:48AM -0700, Brandon Foster wrote:
>>> >>> On Wed, May 8, 2013 at 9:26 AM, Wojtak, Greg (Superfly)
>>> >>>  wrote:
>>>  I think your syntax is a little off.  Try
>>> 
>>>  ldapsearch -x -LLL '(&(uid=test.user)(objectClass=posixAccount))'
>>>  uid
>>>  uidnumber homedirectory gidnumber loginshell
>>> 
>>>  You should have those 5 values returned.
>>> 
>>>  --
>>>  Greg Wojtak
>>>  Senior Unix Systems Engineer
>>>  Office: (313) 373-4306
>>>  Mobile: (734) 718-8472
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>  On 5/8/13 11:52 AM, "Brandon Foster" 
>>>  wrote:
>>> 
>>> > On Wed, May 8, 2013 at 5:05 AM, Sumit Bose 
>>> > wrote:
>>> >> On Tue, May 07, 2013 at 11:39:45AM -0700, Brandon Foster wrote:
>>> >>> Hey all,
>>> >>> Im back with another ldap question. this time I rebuilt sssd and
>>> >>> followed this guide:
>>> >>>
>>> >>>
>>> >>> http://blog.f1linux.com/2013/04/21/howto-part-3-ldap-client-configuratio
>>> >>> n-and-troubleshooting/
>>> >>> for setting up ldap authentication on my centos 6.4 system.
>>> >>>
>>> >>> my firewall is off and selinux is disabled.
>>> >>>
>>> >>> when i do an ldapsearch -x "cn=test.user" it returns all the
>>> >>> correct
>>> >>> information, but doing id test.user returns no user.
>>> >> As you can see from the logs SSSD is using
>>> >> "(&(uid=test.user)(objectclass=posixAccount))" as search filter,
>>> >> can you
>>> >> check if ldapsearch with this filter finds the entry as well?
>>> >> Additionally can you check that the user object is located below
>>> >> the
>>> >> search base you have given in sssd.conf?
>>> >>
>>> >> HTH
>>> >>
>>> >> bye,
>>> >> Sumit
>>> >>> I've attached the log files and all of the relevant files and
>>> >>> maybe
>>> >>> some non relevant ones as well.
>>> >>>
>>> >>> it appears as tho it is searching for the user but is simply not
>>> >>> finding anything. Is there an option to search for cn=test.user?
>>> >>> and
>>> >>> not by uid?
>>> >>>
>>> >>> any help will be much appreciated.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>> ___
>>> >>> 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
>>> > thanks for the reply,
>>> > the user is definitely under the groups in sssd.conf.
>>> >
>>> > ldapsearch with objectclass=posixAccount seems to be part of the
>>> > issue. Also it is searching for uid rather than the cn of the user.
>>> >
>>> > if I do ldapsearch -x "uid= it works fine
>>> >
>>> > if i do ldapsearch -x "uid="
>>> > "objectclass=posixAccount" it does not.
>>> >
>>> > ldapsearch -x "uid=test.user" returns all of the users in the
>>> > search.
>>> >
>>> > and finally ldapsearch -x "uid=test.user"
>>> > "objectclass=posixAccount"
>>> > returns no users.
>>> >
>>> > so how do I tell my sssd to not use this filter? and to use cn
>>> > instead of
>>> > uid?
>>> > ___
>>> > 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
>>> >>>
>>> >>> sorry, not to familiar with the ldapsearch commands.
>>> >>>
>>> >>> anyways, test.user is not of objectclass posixAccoount so with that
>>> >>> filter nothing comes back, if I change it to cn= and objectclass=>> >

Re: [SSSD-users] Ldap Help

2013-05-10 Thread Bryan Harris
On May 10, 2013, at 2:26 PM, Ondrej Valousek  wrote:

> 
> Sssd does not enumerate by default so this is pretty much expected behaviour.
> Try "getent passwd username" instead.

That's weird, mine enumerates when I run like so. I wonder if I have an option 
in the config?

getent --service=sss passwd

Bryan___
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users


Re: [SSSD-users] Ldap Help

2013-05-10 Thread Dmitri Pal
On 05/10/2013 02:28 PM, Brandon Foster wrote:
> cool that did it,
> And enumerate =true made the grep command work as well.
Enumeration is generally not recommended. The main reason it is very
resource draining for the server and the client. It might be fine in
your environment but in general we do not recommend the enumeration to
be turned on.

We also do not recommend writing scripts that assume that enumeration is
on. It is better to assume that only ever logged in users can be
available on the system.
Enumeration might be needed only if you have some other third party
software that relies on the NSS users to be available for example if you
use a database and users that use database are the same users that are
server via SSSD to the DB application.
There are other use cases but they are rare.


>
> thanks!
>
> On Fri, May 10, 2013 at 11:26 AM, Ondrej Valousek  
> wrote:
>> Sssd does not enumerate by default so this is pretty much expected
>> behaviour.
>> Try "getent passwd username" instead.
>> O.
>>
>> Odesláno ze Samsung Mobile
>>
>> Brandon Foster  napsal:
>> ok so after some modification of the ldap server and use of the
>> override functions I was able to make it work.
>> I can now id test.user and get a result, as  well as log in as my ldap
>> users.
>>
>> But when I do getent passwd |grep  i dont get anything back.
>>
>> any ideas why?
>>
>> On Thu, May 9, 2013 at 3:32 AM, Jakub Hrozek  wrote:
>>> On Wed, May 08, 2013 at 01:29:24PM -0400, Dmitri Pal wrote:
 On 05/08/2013 12:57 PM, Brandon Foster wrote:
> On Wed, May 8, 2013 at 9:52 AM, Sumit Bose  wrote:
>> On Wed, May 08, 2013 at 09:43:48AM -0700, Brandon Foster wrote:
>>> On Wed, May 8, 2013 at 9:26 AM, Wojtak, Greg (Superfly)
>>>  wrote:
 I think your syntax is a little off.  Try

 ldapsearch -x -LLL '(&(uid=test.user)(objectClass=posixAccount))'
 uid
 uidnumber homedirectory gidnumber loginshell

 You should have those 5 values returned.

 --
 Greg Wojtak
 Senior Unix Systems Engineer
 Office: (313) 373-4306
 Mobile: (734) 718-8472






 On 5/8/13 11:52 AM, "Brandon Foster" 
 wrote:

> On Wed, May 8, 2013 at 5:05 AM, Sumit Bose 
> wrote:
>> On Tue, May 07, 2013 at 11:39:45AM -0700, Brandon Foster wrote:
>>> Hey all,
>>> Im back with another ldap question. this time I rebuilt sssd and
>>> followed this guide:
>>>
>>>
>>> http://blog.f1linux.com/2013/04/21/howto-part-3-ldap-client-configuratio
>>> n-and-troubleshooting/
>>> for setting up ldap authentication on my centos 6.4 system.
>>>
>>> my firewall is off and selinux is disabled.
>>>
>>> when i do an ldapsearch -x "cn=test.user" it returns all the
>>> correct
>>> information, but doing id test.user returns no user.
>> As you can see from the logs SSSD is using
>> "(&(uid=test.user)(objectclass=posixAccount))" as search filter,
>> can you
>> check if ldapsearch with this filter finds the entry as well?
>> Additionally can you check that the user object is located below
>> the
>> search base you have given in sssd.conf?
>>
>> HTH
>>
>> bye,
>> Sumit
>>> I've attached the log files and all of the relevant files and
>>> maybe
>>> some non relevant ones as well.
>>>
>>> it appears as tho it is searching for the user but is simply not
>>> finding anything. Is there an option to search for cn=test.user?
>>> and
>>> not by uid?
>>>
>>> any help will be much appreciated.
>>
>>
>>
>>
>>
>>
>>
>>> ___
>>> 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
> thanks for the reply,
> the user is definitely under the groups in sssd.conf.
>
> ldapsearch with objectclass=posixAccount seems to be part of the
> issue. Also it is searching for uid rather than the cn of the user.
>
> if I do ldapsearch -x "uid= it works fine
>
> if i do ldapsearch -x "uid="
> "objectclass=posixAccount" it does not.
>
> ldapsearch -x "uid=test.user" returns all of the users in the
> search.
>
> and finally ldapsearch -x "uid=test.user"
> "objectclass=posixAccount"
> returns no users.

Re: [SSSD-users] Ldap Help

2013-05-10 Thread Ondrej Valousek
+1 here.
It could be also of a security concern.
Unfortunately, yes, there is still some software vendors (cadence, are you 
listening?) relying on enumeration.


From: sssd-users-boun...@lists.fedorahosted.org 
[sssd-users-boun...@lists.fedorahosted.org] on behalf of Dmitri Pal 
[d...@redhat.com]
Sent: Friday, May 10, 2013 9:54 PM
To: sssd-users@lists.fedorahosted.org
Subject: Re: [SSSD-users] Ldap Help

On 05/10/2013 02:28 PM, Brandon Foster wrote:
> cool that did it,
> And enumerate =true made the grep command work as well.
Enumeration is generally not recommended. The main reason it is very
resource draining for the server and the client. It might be fine in
your environment but in general we do not recommend the enumeration to
be turned on.

We also do not recommend writing scripts that assume that enumeration is
on. It is better to assume that only ever logged in users can be
available on the system.
Enumeration might be needed only if you have some other third party
software that relies on the NSS users to be available for example if you
use a database and users that use database are the same users that are
server via SSSD to the DB application.
There are other use cases but they are rare.


>
> thanks!
>
> On Fri, May 10, 2013 at 11:26 AM, Ondrej Valousek  
> wrote:
>> Sssd does not enumerate by default so this is pretty much expected
>> behaviour.
>> Try "getent passwd username" instead.
>> O.
>>
>> Odesláno ze Samsung Mobile
>>
>> Brandon Foster  napsal:
>> ok so after some modification of the ldap server and use of the
>> override functions I was able to make it work.
>> I can now id test.user and get a result, as  well as log in as my ldap
>> users.
>>
>> But when I do getent passwd |grep  i dont get anything back.
>>
>> any ideas why?
>>
>> On Thu, May 9, 2013 at 3:32 AM, Jakub Hrozek  wrote:
>>> On Wed, May 08, 2013 at 01:29:24PM -0400, Dmitri Pal wrote:
 On 05/08/2013 12:57 PM, Brandon Foster wrote:
> On Wed, May 8, 2013 at 9:52 AM, Sumit Bose  wrote:
>> On Wed, May 08, 2013 at 09:43:48AM -0700, Brandon Foster wrote:
>>> On Wed, May 8, 2013 at 9:26 AM, Wojtak, Greg (Superfly)
>>>  wrote:
 I think your syntax is a little off.  Try

 ldapsearch -x -LLL '(&(uid=test.user)(objectClass=posixAccount))'
 uid
 uidnumber homedirectory gidnumber loginshell

 You should have those 5 values returned.

 --
 Greg Wojtak
 Senior Unix Systems Engineer
 Office: (313) 373-4306
 Mobile: (734) 718-8472






 On 5/8/13 11:52 AM, "Brandon Foster" 
 wrote:

> On Wed, May 8, 2013 at 5:05 AM, Sumit Bose 
> wrote:
>> On Tue, May 07, 2013 at 11:39:45AM -0700, Brandon Foster wrote:
>>> Hey all,
>>> Im back with another ldap question. this time I rebuilt sssd and
>>> followed this guide:
>>>
>>>
>>> http://blog.f1linux.com/2013/04/21/howto-part-3-ldap-client-configuratio
>>> n-and-troubleshooting/
>>> for setting up ldap authentication on my centos 6.4 system.
>>>
>>> my firewall is off and selinux is disabled.
>>>
>>> when i do an ldapsearch -x "cn=test.user" it returns all the
>>> correct
>>> information, but doing id test.user returns no user.
>> As you can see from the logs SSSD is using
>> "(&(uid=test.user)(objectclass=posixAccount))" as search filter,
>> can you
>> check if ldapsearch with this filter finds the entry as well?
>> Additionally can you check that the user object is located below
>> the
>> search base you have given in sssd.conf?
>>
>> HTH
>>
>> bye,
>> Sumit
>>> I've attached the log files and all of the relevant files and
>>> maybe
>>> some non relevant ones as well.
>>>
>>> it appears as tho it is searching for the user but is simply not
>>> finding anything. Is there an option to search for cn=test.user?
>>> and
>>> not by uid?
>>>
>>> any help will be much appreciated.
>>
>>
>>
>>
>>
>>
>>
>>> ___
>>> 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
> thanks for the reply,
> the user is definitely under the groups in sssd.conf.
>
> ldapsearch with objectclass=posixAccount seems to be part of the
> issue. Also