On Tue, May 3, 2011 at 9:24 AM, Ben Kevan <ben.kevan@gmail.com> wrote:
On Tue, May 3, 2011 at 9:18 AM, Stephen Gallagher <sgallagh@redhat.com> wrote:
On Tue, 2011-05-03 at 09:11 -0700, Ben Kevan wrote:
> On Tue, May 3, 2011 at 8:48 AM, Stephen Gallagher
> <sgallagh@redhat.com> wrote:
>
>         On Tue, 2011-05-03 at 08:35 -0700, Ben Kevan wrote:
>         > On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher
>         > <sgallagh@redhat.com> wrote:
>         >         On Tue, 2011-05-03 at 06:51 -0700, Ben Kevan wrote:
>         >         > On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher
>         >         > <sgallagh@redhat.com> wrote:
>         >         >         On Mon, 2011-05-02 at 21:56 -0700, Ben
>         Kevan wrote:
>         >         >         > I'm wondering what the heck I'm doing
>         wrong. I'm
>         >         working on
>         >         >         getting
>         >         >         > SSSD + KRB5 working against 2008 R2 AD.
>         It's
>         >         working fine in
>         >         >         RHEL5 w/
>         >         >         > the standard LDAP.conf configuration.
>         I'm working
>         >         on sssd,
>         >         >         but am not
>         >         >         > getting a binddn connection to AD.
>         Here's my
>         >         config:
>         >         >
>         >         >         ...
>         >         >         > ldap_default_bind_dn =
>         ldapbinddn@DOMAIN.COM
>         >         >
>         >         >
>         >         >         This is not a DN. This is a username. It's
>         not the
>         >         same thing.
>         >         >         You need
>         >         >         to figure out ldapbinddn's full
>         distinguished name
>         >         in LDAP and
>         >         >         use that.
>         >         >
>         >         >
>         >         >
>         >         >
>         >         > This wasn't the issue. You're able to use both the
>         full DN,
>         >         or the
>         >         > shortened target method. It may not be documented,
>         but if
>         >         you're able
>         >         > to traverse AD anonymously, then you'l ll be
>         successful in
>         >         the method
>         >         > above. This is how I configured LDAP.con in RHEL5
>         even
>         >         though it
>         >         > requested the usage of a full DN.
>         >
>         >
>         >         That sounds like a non-standard extension, and I'd
>         really
>         >         advise against
>         >         relying on it. I won't guarantee that we won't parse
>         for a
>         >         valid DN and
>         >         reject it as an option (it may work right now, but I
>         might
>         >         call that a
>         >         bug rather than a feature).
>         >
>         >         >
>         >         >
>         >         >         > wtf am I doing wrong, and is ldap for
>         >         authentication better
>         >         >         then
>         >         >         > krb5? or should I stick with ldap for
>         >         authorization and krb5
>         >         >         for
>         >         >         > authentication?
>         >         >
>         >         >
>         >         >         Using krb5 for authentication allows you
>         to acquire
>         >         a
>         >         >         single-sign-on TGT
>         >         >         for use with other applications, so it's
>         probably
>         >         the
>         >         >         preferred method
>         >         >         in your case.
>         >         >
>         >         >
>         >         > The issue was the ldap_uri, where I had both
>         targets space
>         >         delimited
>         >         > and not comma delimited.
>         >         >
>         >
>         >
>         >         Ah, yes. That's caused problems for people before as
>         well.
>         >
>         >         >
>         >         > However, I'm still having an issue with the
>         results from
>         >         getent passwd
>         >         > <user>. Right now it's pulling / as homeDirectory,
>         where
>         >         homeDirectory
>         >         > should report as /home/<user>. What mapping should
>         this be
>         >         on a 2008
>         >         > R2 domain?
>         >         >
>         >
>         >
>         >         I'm guessing that ActiveDirectory isn't storing the
>         homedir as
>         >         the
>         >         "homeDirectory" attribute by default. You'll have to
>         look up
>         >         what it
>         >         should be in Windows Server 2008 R2, but at least on
>         older
>         >         systems the
>         >         attribute would have been msSFU30HomeDirectory
>         >
>         >         So you'd set
>         >         ldap_user_home_directory = msSFU30HomeDirectory
>         >         in the sssd.conf
>         >
>         >         >
>         >         > Also, pulling a getent group <groupname> I'm not
>         egtting the
>         >         correct
>         >         > list of members as it is in AD (in the pure ad
>         group and not
>         >         in the
>         >         > msSFU30 portion)
>         >
>         >
>         >         You shouldn't be. You should only see the list of
>         >         POSIX-compliant
>         >         members. If the user or group members don't have
>         POSIX
>         >         attributes, we
>         >         ignore them, since they aren't (and cannot be)
>         relevant.
>         >
>         >
>         > Doing an ldap search of a group I get the following for
>         members
>         > (without the antiquated methods of mapping msSFU30*)
>         > member: CN=Unix bpm,OU=Service
>         > Accounts,OU=Users,OU=Corporate,,DC=Domain,DC=com
>         > member: CN=Ben Kevan,OU=Standard
>         > Users,OU=Users,OU=Corporate,,DC=Domain,DC=com
>         > distinguishedName: CN=NorCal Linux
>         Admins,OU=Groups,DC=Domain,DC=com
>         >
>         >
>         > Is there a way I can see what is being linked by default in
>         sssd?
>         > Here's what I had in previous versions of ldap.conf for
>         mapping, maybe
>         > that'll help map what they should be in SSSD easier.
>         >
>         >
>         > nss_map_objectclass     posixAccount       User
>         > nss_map_objectclass     shadowAccount      User
>         > nss_map_objectclass     posixGroup         group
>         >
>         >
>         > nss_map_attribute       uid                sAMAccountName
>         > nss_map_attribute       uidNumber          uidNumber
>         > nss_map_attribute       gidNumber          gidNumber
>         > nss_map_attribute       uniqueMember       member
>         > nss_map_attribute       givenname          givenName
>         > nss_map_attribute       ou                 description
>         > nss_map_attribute       gecos              displayName
>         > nss_map_attribute       homeDirectory      unixHomeDirectory
>         > nss_map_attribute       loginShell         loginShell
>         > nss_map_attribute       shadowLastChange   pwdLastSet
>         >
>         >
>         > nss_base_passwd DC=Domain,DC=com?sub
>         > nss_base_shadow DC=Domain,DC=com?sub
>         > nss_base_group
>         > DC=Domain,DC=com?sub?&(objectCategory=group)(gidNumber=*)
>
>
>
>         The easiest way to see what SSSD is using would be to set
>         debug_level = 6
>         in the [domain/default] section, restart SSSD and then look
>         at /var/log/sssd/sssd_default.log
>
>         You'll see a number of lines like:
>
>         (Tue May  3 11:47:08 2011) [sssd[be[default]]]
>         [dp_get_options] (6):
>         Option ldap_search_timeout has value 6
>
>
>
> Perfect, that's exactly what i was looking for. I was previously
> starting sssd w/ -d4, and wasn't getting that. Looks like it's part of
> -d5.
>
>
> Here's the full list for anyone that cares:
> # grep sdap_get_map /var/log/sssd/sssd_default.log | awk -FOption
> '{ print $2 }'
<snip> 
>
>
> Doing an ldapsearch against 2008 R2 user account, i see the following
> for home directory:
> unixHomeDirectory: /home/bkevan
>
>
> I've set ldap_user_home_directory to unixHomeDirectory, but am still
> pulling the user with / set as home directory.
>
>
> Also, does sssd cache stuff? And maybe I'm pulling old data? I tried
> to getent passwd a different user, and it failed. Hummm.

Yes, SSSD caches data for 90 minutes by default. You can reduce this for
testing by setting in [domain/default]:

entry_cache_timeout = 30

(where the value is in seconds)

Note, this only works for new cached entries, so you may want to fully
purge your cache by stopping SSSD and doing 'rm
-f /var/lib/sss/db/cache_default.ldb' as root.

 The issue was indeed the cache. I've removed the cache and it works once I set the homedirectory. I just have to check the other configs. 

Lastly, is there any way to force lowercase lookups? i.e., getent passwd bkevan can find entry BKevan? Or will these have to be fixed in AD to be lowercase?

My only issue now with the exception of the forced lowercase lookups (SLES 11 does this by default for sAMAccount etc). Now I just need to find out why id doesn't show that users are part of groups that are posix compliant. 

Also, does SSSD have a different implementation of determining who can log into the system or not? Or should i continue utilizing pam_listfile?