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=*)
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
