This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Stephen, can you put together some sensible configurations that I can include in the doc?
thanks

Given the info in "Description of problem", how does this affect the current description of the type of identity/auth combinations that SSSD supports?

SSSD supports the following identity and authentication combinations:

    * LDAP/LDAP
      This combination uses an LDAP back end as both the identity and authentication provider.
    * LDAP/KRB5
      This combination uses an LDAP back end as the identity provider, and uses Kerberos to provide authentication.
    * proxy

 * LDAP/LDAP
  * Need to discuss ldap_schema rfc2307 vs. rfc 2307bis
  * Need to discuss Active Directory 2003(+Services For UNIX) and 2008 as an LDAP server - our example config file has a sample for AD 2003. Contact QE for help with 2008
  * Need to note that LDAP as an authentication provider REQUIRES one of LDAP+TLS, LDAPS or LDAP+GSSAPI to function (no auth across an unencrypted channel)
  * Need to explain how to use DNS service discovery for LDAP servers - see sssd-ldap(5)

 * LDAP/KRB5
  * Same discussions about identity above
  * Explain DNS service discovery for KRB5 servers.
  * Describe the necessity of the krb5_kadmin option for changing passwords
  * Provide an example configuration where the LDAP communication is protected by GSSAPI/Kerberos. This will require configuring the LDAP server with an ldap service principal and keytab and the client with a host keytab. (This is done implicitly by the IPA provider when the ipa-client-install script is run)

 * Proxy/KRB5
  * Should provide an example of using the proxy identity provider in concert with the native Kerberos authentication. A classic example would be NIS for identity and Kerberos for authentication

 * LDAP/Proxy
  * Should provide an example of using the native LDAP provider with a custom PAM stack
  * It must be absolutely clear that the proxy PAM stack may NOT recursively include pam_sss.so
  * An example configuration might be LDAP identity with a PAM stack requiring a smart-card for auth. (I'm not sure if we want to describe this exact case or suggest contacting support)

 * Proxy/Proxy
  * The way to use SSSD caching to handle any ID and AUTH provider that we do not natively support.

Chandra, can you help with the AD 2008 configuration info?

I'm also interested in getting more info for point #4 of LDAP/KRB5. I might be doing some of these things without even realizing when I do a basic install and config.

David, using GSSAPI protected communication for LDAP is an advanced configuration not supported by authconfig.

It involves a number of steps:

On the LDAP server:
 * Set up a Kerberos service principal for the LDAP server (see the LDAP server docs for how to do this

On the KDC:
 * Create a host principal for the client (SSSD) machine
 * Generate a host keytab for the host principal above
 * Configure the SSSD to use GSSAPI for communicating with the LDAP server
  * ldap_sasl_mech = gssapi
  * ldap_sasl_authid = host/machine.fqdn@REALM
  * ldap_krb5_keytab = /etc/krb5.keytab (default)
  * ldap_krb5_init_creds = true (default)
  * ldap_krb5_ticket_lifetime = 86400 (default)
  * krb5_realm = REALM

For more details, see sssd-ldap(5)

AD 2003 partly done but still waiting on info for 2008

Hi David,

Can you check this one today and make sure you got all you need?

- Mike

Based on the info in the thread "windows 2008 ADS available for sssd testing" on the mailing list I'm clearing the need_info flag; I should have enough here to put together at least useable draft doc.

4c70bdf..0f88d9d  master -> master

Added subsection with Windows AD 2008 configuration.

Advanced configuration using GSSAPI is out of scope at present.

Currently working on updating LDAP/Proxy config.

Based on comments on the mailing list, I'm not going to dig into configuring proxy domains in the standard user doc. We might be able to include it in advanced doc later, perhaps on the wiki. Opinion appears to be "It's not something the average admin should be attempting."

Added note to ensure the PAM stack does not recurse to pam_sss.so

0f88d9d..f6d44a0  master -> master

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Reassigning to default as per discussion with dept leaders.

Reply from sbose:

yes, it means your LDAP server must support the startTLS operation

And also:

you can delete LDAP+GSSAPI here. We do not support LDAP+GSSAPI when it comes to authentication, because if you have Kerberos already set up, you should use it for authentication, too.

Probably need to assign this back to Martin for doc updates.

sbose has "volunteered" to be SME for this  ;-)

Moving back to assigned for Comment#24 to be actioned

(In reply to comment #25)
> Moving back to assigned for Comment#24 to be actioned

Removed LDAP+GSSAPI in Red_Hat_Enterprise_Linux-Deployment_Guide-6-web-en-US-1-111.el5

Back to you John ;)

Thanks,
Martin