On Tue, 2011-05-03 at 08:35 -0700, Ben Kevan wrote:
On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher
<sgallagh(a)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(a)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(a)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