Stephen Gallagher wrote: > On 06/18/2010 08:02 AM, Stephen Gallagher wrote: >> On 06/18/2010 07:51 AM, David O'Brien wrote: >>> Sumit Bose wrote: >>>> On Fri, Jun 18, 2010 at 02:02:34PM +1000, David O'Brien wrote: >>>>> This time I'm wrestling with "native LDAP" vs any other sort of LDAP, >>>>> and where does MS Active Directory fit in? >>>>> >>>>> afaik "native LDAP" just means LDAP provides the identities and does the >>>>> authentication. If I'm using OpenLDAP or 389 that's easy enough. Switch >>>>> to IPA and Kerberos does the auth (= not native LDAP, right?). What if >>>>> I'm using MS Active Directory? Does that or can that do both? Does it >>>>> provide identities and rely on Kerberos for auth? Should I not be using >>>>> "native LDAP" at all to avoid confusion? >>>>> >>>>> "native" also comes up in the bug report* in relation to Kerberos: >>>>> "Should provide an example of using the proxy identity provider in >>>>> concert with the native Kerberos authentication." What's "native >>>>> Kerberos"? >>>>> >>>> in gneneral when we are talking about 'native LDAP' or 'native Kerberos' >>>> we mean the LDAP or Kerberos provider of sssd in contrast to using >>>> pam_ldap/nss_ldap or pam_krb5 with the proxy_provider. >>> ok, so it sounds like the following statement in the doc needs some repairs? >>> >>> "A native LDAP domain is one where the id_provider option is set to ldap >>> (id_provider = ldap). Such a domain requires a running LDAP server >>> against which to authenticate. This can be an open source LDAP server >>> such as OpenLDAP or Microsoft Active Directory. SSSD currently supports >>> Microsoft Active Directory 2003 (+Services For UNIX) and Active >>> Directory 2008. In all cases, the client configuration is stored in the >>> /etc/sssd/sssd.conf file. >>> >>> SSSD does not support authentication over an unencrypted channel. >>> Consequently, if you want to authenticate against an LDAP server, >>> TLS/SSL is required. If the LDAP server is used only as an identity >>> provider, an encrypted channel is not needed." >>> >>> In the case where we use pam_ldap/nss_ldap, what would be the value of >>> id_provider? >>> >>> thanks a lot >> This block of text seems pretty accurate to me, actually. >> >> with nss_ldap, id_provider=proxy, proxy_lib_name=ldap >> >> with pam_ldap, auth_provider=proxy, proxy_pam_target=<name of a PAM >> stack that includes pam_ldap.so> >> > > Additionally, in formal documentation we should probably keep > configuration of the proxy domains out of the standard documentation and > only into advanced configuration types. It's not something the average > admin should be attempting. > I'm very glad to hear that :-)
Some brave volunteer can perhaps add it to the wiki when appropriate. I can extract from there if required. -- David O'Brien Senior Technical Writer, Engineering Content Services Red Hat Asia Pacific Pty Ltd 193 North Quay, Brisbane "We couldn't care less about comfort. We make you feel good." Federico Minoli CEO Ducati Motor S.p.A. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
