Bug 1045223

Created attachment 882758 [details]
Mail thread Mark-Brice

Folks - just wanted to update the bug.

I've added my conversations with Brice. It's up to you to decide whether or not you need the configuration details but I'm including them just in case you do. I've also tried to clarify a few points about Kerberos, Active Directory,e tc. as appropriate. 

I've included the broker config file (/var/www/openshift/broker/httpd/conf.d/openshift-origin-auth-remote-user.conf) and how it would be modified for use with Kerberos (mod_auth_kerb.so) to talk to AD. 

Please note that this requires the use of a keytab file and I have not configured this with OpenShift and confirmed it in the lab. I have configured keytabs like this in an earlier version (v1.4) of the RHEL-AD Reference Architecture (pgs. 62-64) so it should behave identically. I have configured OpenShift to use keytabs with IdM using this broker config file so in theory there is no reason OpenShift brokers (as RHEL clients) wouldn't work with it.

I'll attach v1.4 of the Refrence Architecturte as a folllow up.

-m

Created attachment 882760 [details]
RHEL-AD Reference Architecture - v1.4

Attaching for reference purposes. Pages 62-64 detail how to configure Kerberos service principal (SPN) on Windows/AD side and then use as a RHEL keytab.

Mark, apologies for the delay on this. I've been distracted and also been trying to get the thumbs up that we're heading in the right direction.

I'm currently trying to find a way to test this process for accuracy. I have a few things I can do, but if you have a way you can suggest to me I'd be all ears.

B

Brice,

The original context was for three separate but somewhat related issues:

 1. Adding a Kerberos Principal SSH Key [OSE Admin Guide]
 2. Creating a Specific SSH Key Type [OSE User Guide]
 3. Kerberos Authentication [OSE Deploy Guide]

I don't see 1. above in the Admin Guide link above but I do see 1. and 2.
in the User Guide (sectuon 3.2.3.1) so is that the correct context for them? 
If so, then is the goal to be able to use these against an existing AD environment or just to demonstrate in general how they would be used?

Here are a some things to think about - this can impact how you
would want to test these out:

  - SSH keys: These are typically created on a local host then copied to the
              remote host(s) that you want to access. If you have a lot of
              remotes hosts then this can be cumbersome. In looking at the
              text description in the User Guide (section 3.2.2) it appears
              that the context is basically pretty generic and geared towards
              RHC clients. AD has nothing to do with this but if you want
              bring AD into the picture then this is where keytabs come 
              into play and those are configured as I mentioned earlier
              and as documented in the Reference Architecture. 
              
              With IdM you can centrally store the keys so that all the IdM
              domain members have access to the (public part) of the key which 
              eliminates the need to create the key locally and then copy out 
              to all of remote hosts. For each host to be able to use the
              keys they must be clients of the IdM domain.

              *** To Test***

              - create local key, copy to an OSE broker or node as documented:

              $ rhc sshkey add KeyName KeyPath
                           
  - Key Types:
              As far as SSH key types, this is fairly new and started with
              the work Mark Lamourine did last year to have a Kerberos
              Principal be used as an SSH key type. Jordan Liggit on the
              OSE team handled the back-end OSE portion.

              To use this, you have to have an existing Kerberos realm in place 
              - this could be provided by AD, IdM or any Kerberos server 
              supporting Kerberos clients and Kerberos Single Sign-On (SSO) 
              capabilities.
  
              *** To Test ***
              - create local key, copy to an OSE broker or node as documented:

              $ rhc sshkey add KeyName --type KeyType --content KeyContent

                      ...or if a Kerberos realm is in place ...

              $ rhc sshkey add KeyName --type krb5-principal --content Principal

              Example:

              $ rhc sshkey MyKey --type krb5-principal --content user

                btw - KeyPath is optional (default is $HOME/.k5login

   - Kerberos Auth:

              This is already detailed in the included the broker config file (/var/www/openshift/broker/httpd/conf.d/).
              Keep in mind that this does not have to authenticate to Kerberos
              on AD, it could be any Kerberos server but obviously you must
              have Kerberos in place.

               *** To Test ***

               Configure openshift-origin-auth-remote-user.conf on broker as 
               per attached thread.

Brice - I hope this is more helpful. If you need more clarity let me know.
Perhaps we can just set up a time for a phone chat early morning/late evening 
to accomodate our time zones.

-m

Closing this BZ. 

The focus of the documentation team is going to shift from OpenShift v2 to v3, and only the remaining v2 doc BZs that feature actual errors in the docs will be worked on.

If there are any oppositions for any specific BZs, please contact me or the docs team.

Specifically, the majority of the work for this BZ has been updated, and released sometime in the past. Links can be found in Comment 3 above.