David O'Brien wrote: > 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. >>>> >>>>
Hm? What about OpenLDAP that is available in RHEL and RHDS/389? Why are they not mentioned at all? We should support and doc them too. If this is not the case it seems really strange. Opinions? >>>> 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. > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
