On Tue, May 3, 2011 at 9:24 AM, Ben Kevan <ben.ke...@gmail.com> wrote:
> On Tue, May 3, 2011 at 9:18 AM, Stephen Gallagher <sgall...@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
>> > <sgall...@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
>> > > <sgall...@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
>> > > > <sgall...@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 =
>> > ldapbin...@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?
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
