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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
