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.