Attachment 882758 Details for Bug 1045223 – Mail thread Mark-Brice

Mail thread Mark-Brice

file_1045223.txt (text/plain), 19.99 KB, created by Mark Heslin on 2014-04-04 14:48:47 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Mark Heslin

Created: 2014-04-04 14:48:47 UTC

Size: 19.99 KB

patch

obsolete

>Hi Brice,
>
>I've added comments in-line below.
>
>On 04/04/2014 12:24 AM, Brice Fallon-Freeman wrote:
>> Hey, Mark.
>>
>> Thanks you so much for taking the time to give me all of this information! I hope I've used it in the right way...
>Glad to help :-)
>> re the intention of this topic:
>> I'm not too sure. This is Alex's thought-baby; I'm just tacking myself on. He's back from PTO next week, and I'll check with him, but I think the intention is just to go through Kerberos a little, and then how it interacts with Active Directory. In that vein, I think we've done ok; or at least, we're on the right track.  
>>
>> This is what I have:
>> http://skynet.usersys.redhat.com:8080/pressgang-ccms-ui/#SearchResultsAndTopicView;query;topicIds=30326
>>
>> (This is using Pressgang, our internal docs writing software. I hope you can see it. Though I've never had problems with showing people things in the past.)
>>
>> Please, let me know what you think. I've taken into consideration what you've said in your last paragraph, ie, stripping it down to a few sentences.
>
>Yes, I can see it. I think if the goal is to just explain how Kerberos can be used then I would simplify this even further
>and say something like this:
>
>---
>
>The default authentication method for OpenShift is to use the Apache mod_auth_basic module. For environments looking
>for improved security and scale-out capabilities, Kerberos can be configured to authenticate to Active Directory as follows:
>   
>First, install Kerberos using the following command:
>
>        $ yum install mod_auth_kerb
>
>Next, modify the /var/www/openshift/broker/httpd/conf.d/openshift-origin-auth-remote-user.conf/ file. Configure highlighted
>sections to match your environment:
>
>  LoadModule auth_basic_module modules/mod_auth_basic.so
>  LoadModule authz_user_module modules/mod_authz_user.so
>  LoadModule auth_kerb_module modules/mod_auth_kerb.so
>
>  # By default the LDAPCacheTTL directive is set to 600 seconds. If you want to
>  # effectively disable LDAP caching in mod_ldap, set the directive to 0. There
>  # is a performance trade-off, but disabling the cache will make things like
>  # password changes effective immediately.
>  # http://httpd.apache.org/docs/2.4/mod/mod_ldap.html
>  # LDAPCacheTTL 0
>    <Location /broker>
>        AuthName "OpenShift Broker"
>        AuthType Kerberos
>  KrbMethodNegotiate On
>  KrbMethodK5Passwd On
>  KrbServiceName HTTP/broker1.example.com
>  KrbAuthRealms EXAMPLE.REDHAT.COM
>  Krb5KeyTab /var/www/openshift/broker/httpd/conf.d/http.keytab
>        Require valid-user
>        # The node->broker auth is handled in the Ruby code
>        BrowserMatch Openshift passthrough
>        Allow from env=passthrough
>        Order Deny,Allow
>        Deny from all
>        Satisfy any
>    </Location>
>    # The following APIs do not require auth:
>    <Location /broker/rest/application_templates*>
>       Allow from all
>    </Location>
>    <Location /broker/rest/cartridges*>
>       Allow from all
>    </Location>
>    <Location /broker/rest/api*>
>       Allow from all
>    </Location>
>
>This approach requires the use of a service keytab file. A keytab file is generated on the Active Directory server
>as follows:
>
>  1. Create a new computer object on the Active Directory server for broker1.example.com
>
>          <insert Reference Architecture steps here - pg 62 >
>
>  2. Create a Kerberos service principal (SPN) for the OpenShift server - broker1.example.com. Give the service principal a password
>      and name it broker1.example.com.keytab:
>
>          <insert Reference Architecture steps here - pg 62-63 >
>
>  3. Securely transfer the keytab to broker1.example.com
>
>          <insert Reference Architecture steps here - pg 64 >
>
>---
>
>Brice I know this is lot to digest. The keytab is actually the most confusing thing here - it's basically a file that allows
>the OpenShift client (broker1.example.com) to do secure lookups (via LDAP) of users so that Kerberos can work.
>I have only configured keytabs with OpenShift to connect to IdM, not AD but in the earlier versions of my RHEL-AD
>Reference Architecture I did use keytabs to connect to AD so it should be identical but I have not confirmed it in the lab
>with OpenShift. Attached is v1.4 of Reference Architecture for details of the above steps. The latest version (v1.5)
>uses SSSD and the AD provider so the keytab is automatically generated and no longer applicable so we can't
>refer to that.
>
>To be honest, I'm not sure whether or not it makes sense to include this level of detail. You could just punt and say this:
>
>This approach requires the use of a service keytab file. Creating a keytab file requires the following:
>
>  - Creating a new computer object on the Active Directory server for broker1.example.com
>  - Creating a Kerberos service principal (SPN) for the OpenShift server - broker1.example.com.
>  - Setting  a password for the service principal and renaming it to broker1.example.com.keytab:
>  - Securely transferring the keytab to broker1.example.com
>
>For further details on Kerberos and Service Principals consult the Windows Active Directory documentation.
>
>> I only have a couple of questions:
>> 1. Active Directory is an example of a PAM, correct?
>No. Active Directory is a suite of directory services that includes customized versions of Kerberos, DNS, LDAP and NTP.
>It is only available on Windows Server platforms (Windows Server 2008, 2012, etc.) and is enabled as a Server Role.
>It's included with Windows Server versions.
>
>PAM (Pluggable Authentication Modules) are only available on the linux side of the house (Red Hat Enterprise Linux, Fedora, etc.).
>PAM modules are a system of libraries that handle the authentication tasks of applications (services) on linux systems.
>
>PAM modules provide a way to dynamically configure different authentication methods (Kerberos, LDAP, SSSD) for different
>applications (aka "services") such as Samba, OpenShift, etc.
>
>> 2. Do you think it would be useful to list the contents of /var/www/openshift/broker/httpd/conf.d/openshift-origin-auth-remote-user.conf/? I'm tempted to say no, mainly because I'm guessing the file is different for each setup, but I could be wrong.
>> 3. Do you think i might need to put more info into the paragraph at the bottom about Kerberos and Active Directory? It currently just seems to say 'AD is a PAM'.
>I included it but without knowing the full context of the documentation I'd say it's your call.
>
>Some of this is already documented in current reference architectures, OpenShift docs, etc. and the current reference architecture
>that I am working on. The problem with not including the above is that I have not seen this same configuration documented.
>
>> Anyway, like I said, if you've any suggestions I'd be more than happy to make any changes. And there isn't a definite timeframe for this, so if you have priorities I understand.
>>
>> Thanks again for all the information, and your time.
>> Brice.
>>
>> PS. Very jealous about Red Hat Summit! I live in Brisbane, Australia, so San Fran is a little out of the way for me... Maybe next year :)
>Summit is a two-edged sword. It's great to be a part of it, to help our customers, partners and to here from them directly.
>It's always chaotic, crazy busy to pull everything  together and since the timing is earlier this year even more so. On top of it
>all we have our normal jobs to do as well :-)
>
>Having said that, I've been there as a presenter each year I've been with Red Hat so this is my fourth consecutive year.
>I'm excited to be a part of it, enjoy the feedback and knowing I'm making a difference for our customers - it makes the craziness
>worth it :-)
>
>-m
>
>> ----- Original Message -----
>> From: "Mark Heslin" <mheslin@redhat.com>
>> To: "Brice Fallon-Freeman" <bfallonf@redhat.com>
>> Sent: Thursday, April 3, 2014 1:31:14 AM
>> Subject: Re: BZ 1045223
>>
>> Hi Brice,
>>
>> No worries, I'm buried between projects and Summit :-)
>>
>> Ok, let me try to start from the top and work down a bit to help 
>> clarify, simplify things for you.
>> This is long but I think it will help you better understand and communicate.
>>
>> First, Kerberos is a mechanism for Single Sign-On mechanism that 
>> operates on a client-server model.
>> The server is the KDC (Kerberos Key Distribution Center) whose purpose 
>> is to manage the granting
>> of tickets to clients. Kerberos tickets have an expiration time (usually 
>> something like 14 hrs) so once
>> a ticket has expired it either has to be refreshed or a new ticket granted.
>>
>> The client-side requests a ticket (from the Kerberos server "KDC") using 
>> either installed command line tools
>> 'kinit' or from the application/service level through the PAM (Pluggable 
>> Authentication Module) libraries.
>>
>> Keep in mind that Kerberos is available for basically every platform - 
>> RHEL, Windows, Mac/OS, etc.
>> This means that a RHEL Kerberos client can obtain a ticket from both 
>> RHEL and non-RHEL KDC's.
>> If OpenShift is authenticating through Active Directory then the clients 
>> are RHEL and the KDC is AD.
>>
>> For OpenShift, you can can configure the broker(s) console to use 
>> Kerberos as follows:
>>
>>        # yum install mod_auth_kerb
>>        - Edit 
>> /var/www/openshift/broker/httpd/conf.d/openshift-origin-auth-remote-user.conf
>>
>> LoadModule auth_basic_module modules/mod_auth_basic.so
>> LoadModule authz_user_module modules/mod_authz_user.so
>> *LoadModule auth_kerb_module modules/mod_auth_kerb.so     <--- Load the 
>> Kerberos auth module
>> *
>>
>> # By default the LDAPCacheTTL directive is set to 600 seconds. If you 
>> want to
>> # effectively disable LDAP caching in mod_ldap, set the directive to 0. 
>> There
>> # is a performance trade-off, but disabling the cache will make things like
>> # password changes effective immediately.
>> # http://httpd.apache.org/docs/2.4/mod/mod_ldap.html
>> # LDAPCacheTTL 0
>>   <Location /broker>
>>       AuthName "OpenShift Broker"
>>       AuthType Kerberos
>> KrbMethodNegotiate On
>> KrbMethodK5Passwd On
>> *KrbServiceName HTTP/broker1.example.com   <--- My Broker name (local host)
>> *
>> *KrbAuthRealms EXAMPLE.REDHAT.COM <--- My Kerberos realm - should match 
>> /etc/krb5.conf
>> *
>> *Krb5KeyTab /var/www/openshift/broker/httpd/conf.d/http.keytab  <--- 
>> Obtained from the KDC we're using
>> *
>>       Require valid-user
>>       # The node->broker auth is handled in the Ruby code
>>       BrowserMatch Openshift passthrough
>>       Allow from env=passthrough
>>       Order Deny,Allow
>>       Deny from all
>>       Satisfy any
>>   </Location>
>>   # The following APIs do not require auth:
>>   <Location /broker/rest/application_templates*>
>>      Allow from all
>>   </Location>
>>   <Location /broker/rest/cartridges*>
>>      Allow from all
>>   </Location>
>>   <Location /broker/rest/api*>
>>      Allow from all
>>   </Location>
>>
>> This example is from the systems engineering work I've been doing to 
>> integrate OpenShift with IdM.
>> In this case a pair of IdM servers are the KDC and the OpenShift 
>> brokers, nodes are the clients.
>>
>> Now you may ask, where does AD fit into this picture? Well, for RHEL 
>> clients including OpenShift, you can
>> either integrate (authenticate) directly or indirectly to AD. Direct 
>> integration means exactly that - the client
>> authenticates directly to AD using either native or 3rd party solutions. 
>> Indirect means the client uses a centralized
>> identity server which integrates to AD.  Attached is a draft for my 
>> upcoming Summit talk that talks about this
>> in more detail (see you're timing was good afterall ;-))
>>
>> btw - Just to clarify: Integration means user authentication, plus ID 
>> tracking/name resolution and ID mapping.
>>
>> OpenShift and direct AD integration without Kerberos is demonstrated in 
>> the attached OpenShift Enterprise Reference
>> Architecture,  (pg. 40-42). The same config file 
>> /var/www/openshift/broker/httpd/conf.d/openshift-origin-auth-remote-user.conf
>> on the broker is modified to use  mod_authnz_ldap instead of mod_auth_kerb.
>>
>> The default OpenShift install uses mod_auth_basic which simply means it 
>> looks for a local htpasswd file but this does not
>> scale-out across multiple servers well.
>>
>> As far as your text - here are my suggestions:
>>
>> --Kerberos Interoperability with Active Directory--
>> Active Directory uses a customized version of Kerberos in order to allow Windows System Administrators to manage directory objects in a secure infrastructure.
>>
>> I would probably just say:
>>
>> ---Kerberos and Active Directory ---
>> Active Directory includes a customized implementation of Kerberos to allow Windows System Administrators to securely manage directory objects.
>>
>> When Active Directory uses Kerberos authentication, the client sends the user ID to the Authentication Service, requesting services for the user. The Authentication Service then generates a password for the user by hashing out the user's password found in the remote database. The Authentication Service then checks for the user in its own database, and, if the user exists, sends back two messages: one a Client/Ticket-Granting Service Session Key encrypted with the secret key of the user, and another with a Ticket-Granting Ticket encrypted with the secret key of the Ticket-Granting Service. Once the user receives the two messages, it attempts to decrypt the first with the secret key generated by the user. If the password matches the password in the Authentication Service's database, the client decrypts the first message to obtain the Client/Ticket-Granting Service session key. The second message is decrypted once the client has enough information to authenticate itself to the Ticket-Gra
>> nting Service.
>>
>> Is the intent is to talk about Kerberos and AD in general, at a high 
>> level? If so, I would strip this all down to something much
>> simpler - just three, four, five sentences like I have above. To be 
>> honest, most folks don't really need to know the TGS and TGT.
>> I know the Wiki goes into this but the gist of what's needed is that you 
>> have a server (KDC) that grants tickets to clients
>> so that they have secure, single Sign-On (SSO) capabilities. The tickets 
>> have a limited lifetime and can be granted to clients
>> through either the CLI level or at the application service level via the 
>> PAM libraries. You may add in something from pg 6
>> of my RHEL-AD Integration Reference Architecture as well (attached).
>>
>> Hope this helps! Let me know if you have other questions, need more detail.
>>
>> Warm regards,
>>
>> -m
>>
>>
>> On 04/02/2014 02:15 AM, Brice Fallon-Freeman wrote:
>>> Hi, Mark.
>>>
>>> Sorry it's taken a little to return this email. With the release of Enterprise 2.1 we've been a bit busy with other things. BZs have taken a backseat... And as I'm an Australian living in Brisbane, I thought an email would've been the best way to carry this on, what with the time differences and all.
>>>
>>> So I can see the bits in the Reference Architecture where it talks about Active Directory [1]. but I'm not sure how it works together with Kerberos. This is where I probably add the disclaimer that I'm not very technologically inclined...so I'm not too sure how the two things work together.
>>>
>>> So according to Alex (who reported the BZ), I should be after "context regarding OpenShift/Active Directory interoperability or the legwork it would take to be able to use this feature in general. In the absence of a reference architecture, an overview of OpenShift/AD use cases particularly within the context of adding Kerberos SSH keys would be helpful. [2]"
>>>
>>> I did find this [3], which, though is Wikipedia, does seem to be heading in the right direction.
>>>
>>> The following is what I sort of have so far that I think I can add to the docs:
>>>
>>> --Kerberos Interoperability with Active Directory--
>>> Active Directory uses a customized version of Kerberos in order to allow Windows System Administrators to manage directory objects in a secure infrastructure.
>>>
>>> When Active Directory uses Kerberos authentication, the client sends the user ID to the Authentication Service, requesting services for the user. The Authentication Service then generates a password for the user by hashing out the user's password found in the remote database. The Authentication Service then checks for the user in its own database, and, if the user exists, sends back two messages: one a Client/Ticket-Granting Service Session Key encrypted with the secret key of the user, and another with a Ticket-Granting Ticket encrypted with the secret key of the Ticket-Granting Service. Once the user receives the two messages, it attempts to decrypt the first with the secret key generated by the user. If the password matches the password in the Authentication Service's database, the client decrypts the first message to obtain the Client/Ticket-Granting Service session key. The second message is decrypted once the client has enough information to authenticate itself to the Ticket-Gra
>>> nting Service.
>>>
>>> ---------------------------------------------------
>>>
>>> Note that this is the info stolen from both the Reference Arch and the Wikipedia page.
>>>
>>> So Mark, do you think this enough? I'm not even sure if this is the right information, let alone what Alex is asking for. I think I can see a clearer view of what i need to be doing, but like I said, i'm not too tech-ey when it comes to this stuff. Please, let me know if there's anything you'd like to add/change/suggest. I'm up for anything.
>>>
>>> Thanks a billion.
>>> Brice.
>>>
>>> [1] http://www.redhat.com/rhecm/rest-rhecm/jcr/repository/collaboration/jcr:system/jcr:versionStorage/064065990a0526024c77d7212bdacdae/2/jcr:frozenNode/rh:resourceFile
>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1045223
>>> [3] http://en.wikipedia.org/wiki/Kerberos_%28protocol%29#Client_Authentication
>>>
>>> ----- Original Message -----
>>> From: "Mark Heslin" <mheslin@redhat.com>
>>> To: "Brice Fallon-Freeman" <bfallonf@redhat.com>
>>> Cc: "Scott Collier" <scollier@redhat.com>, "Alex Dellapenta" <adellape@redhat.com>
>>> Sent: Friday, March 28, 2014 12:32:57 AM
>>> Subject: Re: BZ 1045223
>>>
>>> Hi Brice,
>>>
>>> Yes, Alex reached out to me a ways back and since I offered to assist
>>> the offer is still good :-)
>>>
>>> Ping me directly and if you have a pointer to what you have I can look
>>> it over and give you my thoughts.
>>>
>>> I'm more focused on the IdM side but work closely with AD all the time
>>> so it would make the most sense
>>> for me to help you.
>>>
>>> Thanks,
>>>
>>> -m
>>>
>>>
>>>
>>> On 03/27/2014 09:51 AM, Scott Collier wrote:
>>>> Hey Brice, Alex,
>>>>
>>>> Adding Mark here as he may have some free cycles to pick this back up.
>>>>
>>>> -Scott
>>>>
>>>> On 03/27/2014 08:31 AM, Alex Dellapenta wrote:
>>>>> Hi Brice. I had started tracking people down a few months ago, but
>>>>> then big time dropped the ball on it. Scott provided a link to the
>>>>> ref-arch they wrote, and Mark Heslin said he'd be available to chat
>>>>> (at least back in January). See my latest comment in the BZ for the
>>>>> thread:
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1045223#c4
>>>>>
>>>>> HTH,
>>>>> alexd
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Brice Fallon-Freeman" <bfallonf@redhat.com>
>>>>>> To: "Alex Dellapenta" <adellape@redhat.com>, "Scott Collier"
>>>>>> <scollier@redhat.com>
>>>>>> Sent: Thursday, March 27, 2014 12:22:13 AM
>>>>>> Subject: BZ 1045223
>>>>>>
>>>>>> Hi, guys.
>>>>>>
>>>>>> I'm going through my BZs and found this one I had completely
>>>>>> forgotten about:
>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1045223
>>>>>>
>>>>>> I've made the changes suggested by Alex, but he mentions that Scott
>>>>>> may be
>>>>>> the man to go to for an OpenShift/Active Directory reference arch.
>>>>>> Or -- "In
>>>>>> the absence of a reference architecture, an overview of OpenShift/AD
>>>>>> use
>>>>>> cases particularly within the context of adding Kerberos SSH keys
>>>>>> would be
>>>>>> helpful." So maybe even a good-looking example?
>>>>>>
>>>>>> Either of you guys remember/think you can help me with this?
>>>>>>
>>>>>> Thanks.
>>>>>> Brice.
>>>>>>
>>

Actions: View

Attachments on bug 1045223: 882758 | 882760