<div class="gmail_quote">On Tue, May 3, 2011 at 7:39 AM, Stephen Gallagher <span dir="ltr">&lt;<a href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Tue, 2011-05-03 at 06:51 -0700, Ben Kevan wrote:<br>
&gt; On Tue, May 3, 2011 at 4:47 AM, Stephen Gallagher<br>
&gt; &lt;<a href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a>&gt; wrote:<br>
&gt;         On Mon, 2011-05-02 at 21:56 -0700, Ben Kevan wrote:<br>
&gt;         &gt; I&#39;m wondering what the heck I&#39;m doing wrong. I&#39;m working on<br>
&gt;         getting<br>
&gt;         &gt; SSSD + KRB5 working against 2008 R2 AD. It&#39;s working fine in<br>
&gt;         RHEL5 w/<br>
&gt;         &gt; the standard LDAP.conf configuration. I&#39;m working on sssd,<br>
&gt;         but am not<br>
&gt;         &gt; getting a binddn connection to AD. Here&#39;s my config:<br>
&gt;<br>
&gt;         ...<br>
&gt;         &gt; ldap_default_bind_dn = <a href="mailto:ldapbinddn@DOMAIN.COM">ldapbinddn@DOMAIN.COM</a><br>
&gt;<br>
&gt;<br>
&gt;         This is not a DN. This is a username. It&#39;s not the same thing.<br>
&gt;         You need<br>
&gt;         to figure out ldapbinddn&#39;s full distinguished name in LDAP and<br>
&gt;         use that.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; This wasn&#39;t the issue. You&#39;re able to use both the full DN, or the<br>
&gt; shortened target method. It may not be documented, but if you&#39;re able<br>
&gt; to traverse AD anonymously, then you&#39;l ll be successful in the method<br>
&gt; above. This is how I configured LDAP.con in RHEL5 even though it<br>
&gt; requested the usage of a full DN.<br>
<br>
</div>That sounds like a non-standard extension, and I&#39;d really advise against<br>
relying on it. I won&#39;t guarantee that we won&#39;t parse for a valid DN and<br>
reject it as an option (it may work right now, but I might call that a<br>
bug rather than a feature).<br>
<div class="im"><br>
&gt;<br>
&gt;<br>
&gt;         &gt; wtf am I doing wrong, and is ldap for authentication better<br>
&gt;         then<br>
&gt;         &gt; krb5? or should I stick with ldap for authorization and krb5<br>
&gt;         for<br>
&gt;         &gt; authentication?<br>
&gt;<br>
&gt;<br>
&gt;         Using krb5 for authentication allows you to acquire a<br>
&gt;         single-sign-on TGT<br>
&gt;         for use with other applications, so it&#39;s probably the<br>
&gt;         preferred method<br>
&gt;         in your case.<br>
&gt;<br>
&gt;<br>
&gt; The issue was the ldap_uri, where I had both targets space delimited<br>
&gt; and not comma delimited.<br>
&gt;<br>
<br>
</div>Ah, yes. That&#39;s caused problems for people before as well.<br>
<div class="im"><br>
&gt;<br>
&gt; However, I&#39;m still having an issue with the results from getent passwd<br>
&gt; &lt;user&gt;. Right now it&#39;s pulling / as homeDirectory, where homeDirectory<br>
&gt; should report as /home/&lt;user&gt;. What mapping should this be on a 2008<br>
&gt; R2 domain?<br>
&gt;<br>
<br>
</div>I&#39;m guessing that ActiveDirectory isn&#39;t storing the homedir as the<br>
&quot;homeDirectory&quot; attribute by default. You&#39;ll have to look up what it<br>
should be in Windows Server 2008 R2, but at least on older systems the<br>
attribute would have been msSFU30HomeDirectory<br>
<br>
So you&#39;d set<br>
ldap_user_home_directory = msSFU30HomeDirectory<br>
in the sssd.conf<br>
<div class="im"><br>
&gt;<br>
&gt; Also, pulling a getent group &lt;groupname&gt; I&#39;m not egtting the correct<br>
&gt; list of members as it is in AD (in the pure ad group and not in the<br>
&gt; msSFU30 portion)<br>
<br>
</div>You shouldn&#39;t be. You should only see the list of POSIX-compliant<br>
members. If the user or group members don&#39;t have POSIX attributes, we<br>
ignore them, since they aren&#39;t (and cannot be) relevant.<br></blockquote><div><br></div><div>Doing an ldap search of a group I get the following for members (without the antiquated methods of mapping msSFU30*)</div><div>

<div>member: CN=Unix bpm,OU=Service Accounts,OU=Users,OU=Corporate,,DC=Domain,DC=com</div><div>member: CN=Ben Kevan,OU=Standard Users,OU=Users,OU=Corporate,,DC=Domain,DC=com</div><div>distinguishedName: CN=NorCal Linux Admins,OU=Groups,DC=Domain,DC=com</div>

</div><div><br></div></div>Is there a way I can see what is being linked by default in sssd? Here&#39;s what I had in previous versions of ldap.conf for mapping, maybe that&#39;ll help map what they should be in SSSD easier. <div>

<br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>nss_map_objectclass     posixAccount       User         </div><div>nss_map_objectclass     shadowAccount      User         </div><div>

nss_map_objectclass     posixGroup         group                </div><div><br></div><div>nss_map_attribute       uid                sAMAccountName</div><div>nss_map_attribute       uidNumber          uidNumber</div><div>

nss_map_attribute       gidNumber          gidNumber</div><div>nss_map_attribute       uniqueMember       member</div><div>nss_map_attribute       givenname          givenName</div><div>nss_map_attribute       ou                 description</div>

<div>nss_map_attribute       gecos              displayName</div><div>nss_map_attribute       homeDirectory      unixHomeDirectory</div><div>nss_map_attribute       loginShell         loginShell   </div><div>nss_map_attribute       shadowLastChange   pwdLastSet</div>

<div><br></div><div>nss_base_passwd <meta http-equiv="content-type" content="text/html; charset=utf-8">DC=Domain,DC=com?sub</div><div>nss_base_shadow <meta http-equiv="content-type" content="text/html; charset=utf-8">DC=Domain,DC=com?sub</div>

<div>nss_base_group DC=Domain,DC=com?sub?&amp;(objectCategory=group)(gidNumber=*)</div></div><div><br></div>