[Freeipa-users] New User - Possible to point authentication to external KDC

[Dmitri Pal]

On 03/01/2013 07:37 PM, Trey Dockendorf wrote:
> On Tue, Feb 26, 2013 at 1:18 PM, Dmitri Pal <dpal at redhat.com> wrote:
>> On 02/26/2013 01:31 AM, Trey Dockendorf wrote:
>>
>>
>> On Feb 25, 2013 1:23 AM, "Dmitri Pal" <dpal at redhat.com> wrote:
>>> On 02/23/2013 10:33 PM, Trey Dockendorf wrote:
>>>> I just begun evaluating FreeIPA, after having successfully used 389ds
>>>> for a few months.  The move from 389 ds to FreeIPA is to leverage the
>>>> authorization for host logins and also for simpler management.  The
>>>> University I am deploying at has a campus wide KDC and for security
>>>> and audit reasons I prefer to point my authentication services at that
>>>> Kerberos realm rather than storing passwords.  I have successfully
>>>> implemented this using the 389 ds pam pass through authentication
>>>> plug-in , but have not found any documentation on how to do this same
>>>> thing with FreeIPA.
>>>>
>>>> The complication with doing this is I do not have even a 1 way trust
>>>> with the KDC.  Getting a trust (even 1-way) is very difficult if not
>>>> impossible, but so far I've been able to make PAM work with that
>>>> situation both using local authentication and now 389 ds, both through
>>>> PAM.  Is it possible to have FreeIPA query a remote KDC while still
>>>> being able to fallback to the local password store (ie external users
>>>> not in campus domain).
>>> IPA uses the 389 DS so it might be possible to configure PAM pass
>>> through but there might be implications because if users are not in IPA
>>> you would not get a ticket and since you cant get a ticket you can't use
>>> UI and CLI. You can still bind using LDAP though as you do with the 389.
>>> So to manage IPA you would still have to have a user in IPA. However you
>>> will have two KDCs and I do not know what implications there would be
>>> for the clients, they might be confused.
>>> Frankly you are better off with 389 now untill we make setting up trusts
>>> with other IPAs or MIT KDCs simple. We did that for AD but it requires a
>>> clean DNS setup. I suspect DNS setup will be an issue in any case.
>>>
>>>> Thanks
>>>> - Trey
>>>>
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>
>>> --
>>> Thank you,
>>> Dmitri Pal
>>>
>>> Sr. Engineering Manager for IdM portfolio
>>> Red Hat Inc.
>>>
>>>
>>> -------------------------------
>>> Looking to carve out IT costs?
>>> www.redhat.com/carveoutcosts/
>>>
>>>
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Thanks for the response!  I do plan to have all my users in freeIPA.  My
>> goal is to have my freeIPA install just attempt a password authentication
>> against external KDC via pam on the IPA server before trying the local
>> password store.  With my current 389 setup, clients are unaware of our
>> campus KDC, the authentication is handled my 389 server and currently users
>> in my LDAP who have campus accounts get their password verified via PAM and
>> others in my LDAP use the local password stored in 389.
>>
>> The aspects of IPA aside from 389 are where my uncertainty lies.  For
>> example, if I have LDAP authenticate against an external KDC via PAM, can
>> the user still get a ticket from my IPA?
>>
>> Also getting a trust may not be possible even if freeipa makes the process
>> easier.  This is a politics issue with our campus' main IT group and
>> something I've worked around thus far.
>>
>> Is there anything in changes of the stock 389 that would prevent this from
>> working in IPA?  Also is there a preferred method for enabling plugins in
>> IPA?  Also how could I test this?  Would a client machine joined to my IPA
>> install be the best method?
>>
>> Thanks
>> - Trey
>>
>> If you hit IPA with a kerberos authentication to the best of my knowledge
>> KDC will read the data from LDAP and use it for authentication. It would not
>> do PAM proxy in this case. The pam proxy would be possible only for the LDAP
>> binds so I am not sure whether things would work for you.
>>
>> I see that you try to augment the existing infrastructure but I am not sure
>> I have a clear picture in my mind of the architecture you envision.
>> Is there any chance that you can put together a diagram?
>>
>> --
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager for IdM portfolio
>> Red Hat Inc.
>>
>>
>> -------------------------------
>> Looking to carve out IT costs?
>> www.redhat.com/carveoutcosts/
>>
>>
> Is the pam proxy for LDAP binds you mentioned using the method
> documented here,
> http://directory.fedoraproject.org/wiki/Howto:PAM_Pass_Through ?  That
> is what I have working currently with 389 by itself.
>
> Do any diagrams exist of the existing infrastructure design for
> FreeIPA?  I could augment an existing one to better illustrate my
> intended usage.
>
> A plain text example of what I do now , and wish to do with FreeIPA is
> something like this...
>
> Client login (SSH, or LDAP from web app, anything that queries
> OpenLDAP) - config[1]
>  |
>  |
>  |
> \/
> 389 ds server - config[2]
> |
> |
> \/
> Queries external KDC through PAM from the 389 server
> |
> |
> |----Authenticate user locally on 389 server via ldapserver PAM service
>   |-IF auth pam_krb5.so succeeds , user is authenticated
>   |
>   |-else Fallback to 389 stored userPassword
> _|
> |
> |
> \/
> Client authenticated
>
> I may be mixing terms and how Kerberos interacts with 389 differently
> than a 389 install by itself.  The goal would be that when an
> authentication request comes into FreeIPA, it first uses the server's
> local PAM service (defined by pamService) to attempt to validate the
> request.  If that validation succeeds, it proceeds like normal,
> issuing a ticket as if it had validated the authentication request
> locally.  If the validation fails, FreeIPA then proceeds like normal
> to query it's local resources for validation (if pamFallback: TRUE).

The PAM pass through feature was recently added to 389 DS and is
available but untested for FreeIPA.
We would be very interested to hear whether IPA with pam pass through
works for you or not the way you describe.
The intent for bringing this feature to IPA was close to your use case.

>
> The key benefit to this approach for my organization is primarily that
> we can avoid storing passwords for 99% of our users by querying the
> campus KDC, which in our university environment is a huge plus during
> annual audits.  The other benefit is that all clients are only
> configured to talk to 389 via pam_ldap and it's up to the 389 server
> to determine how to authenticate a user.

IPA assumes that it works with SSSD but may be it is better not to use
SSSD not to create cycle references. This is untried area.

>
> If utilizing the pam_passthruauth plugin won't work with FreeIPA,

Let us start with trying. Can you give it a try and see what issues you
face?

> would it be possible to have my clients configured to talk to FreeIPA
> as if it were only a 389 server, and not install ipa-client?  I
> realize that's likely something that FreeIPA was not designed for.
>
> All hostname and fqdn values consistently replaced.
>
> config[1] - Client Configuration
> # cat pam.d/password-auth-ac
> auth        required      pam_env.so
> auth        sufficient    pam_unix.so nullok try_first_pass
> auth        requisite     pam_succeed_if.so uid >= 500 quiet
> auth        sufficient    pam_ldap.so use_first_pass
> auth        required      pam_deny.so
>
> account     required      pam_access.so
> accessfile=/etc/security/access.netgroup.conf
> account     required      pam_unix.so broken_shadow
> account     sufficient    pam_localuser.so
> account     sufficient    pam_succeed_if.so uid < 500 quiet
> account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
> account     required      pam_permit.so
>
> password    requisite     pam_cracklib.so try_first_pass retry=3 type=
> password    sufficient    pam_unix.so sha512 shadow nullok
> try_first_pass use_authtok
> password    sufficient    pam_ldap.so use_authtok
> password    required      pam_deny.so
>
> session     optional      pam_keyinit.so revoke
> session     required      pam_limits.so
> session     [success=1 default=ignore] pam_succeed_if.so service in
> crond quiet use_uid
> session     required      pam_unix.so
> session     optional      pam_ldap.so
>
> # egrep -v "^#|^$" /etc/pam_ldap.conf
> base dc=dept,dc=example,dc=edu
> uri ldap://dept.example.edu
> pam_password clear
> ssl start_tls
>
> # egrep -v "^#|^$" /etc/openldap/ldap.conf
> URI ldap://dept.example.edu
> BASE dc=dept,dc=example,dc=edu
> TLS_CACERT /etc/ssl/certs/ca-bundle.crt
> TLS_REQCERT	demand
>
> # egrep -v "^#|^$" /etc/nslcd.conf
> uid nslcd
> gid ldap
> uri ldap://dept.example.edu
> base dc=dept,dc=example,dc=edu
> ssl start_tls
> tls_cacertfile /etc/ssl/certs/ca-bundle.crt
>
> ----------------------------------
> config[2] - 389 server
>
> # plugin config
> dn: cn=PAM Pass Through Auth,cn=plugins,cn=config
> objectClass: extensibleObject
> objectClass: nsSlapdPlugin
> objectClass: pamConfig
> objectClass: top
> cn: PAM Pass Through Auth
> nsslapd-pluginDescription: PAM pass through authentication plugin
> nsslapd-pluginEnabled: on
> nsslapd-pluginId: pam_passthruauth
> nsslapd-pluginInitfunc: pam_passthruauth_init
> nsslapd-pluginPath: libpam-passthru-plugin
> nsslapd-pluginType: preoperation
> nsslapd-pluginVendor: 389 Project
> nsslapd-pluginVersion: 1.2.10.2
> pamExcludeSuffix: cn=config
> pamFallback: TRUE
> pamIDMapMethod: RDN
> pamMissingSuffix: ALLOW
> pamSecure: TRUE
> pamService: ldapserver
>
> # cat /etc/pam.d/ldapserver
> auth        required      pam_env.so
> auth        sufficient    pam_krb5.so use_first_pass
> auth        sufficient    pam_unix.so nullok try_first_pass
> auth        required      pam_deny.so
>
> account     include       password-auth
>
> password     include       password-auth
>
> session     include       password-auth
>
> # cat /etc/krb5.conf
> [libdefaults]
>   default_realm = EXAMPLE.EDU
>   default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5 des3-hmac-sha1
>   default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5 des3-hmac-sha1
>   clockskew = 300
>
> [realms]
>   EXAMPLE.EDU = {
>     kdc = kerberos-1.example.edu:88
>     kdc = kerberos-2.example.edu:88
>     kdc = kerberos-3.example.edu:88
>     default_domain = example.edu
>     admin_server = kerberos-master.example.edu:749
> }
>
> [domain_realm]
>   example.edu = EXAMPLE.EDU
>   .example.edu = EXAMPLE.EDU
>
> [appdefaults]
>   pam = {
>     debug = false
>     ticket_lifetime = 1d
>     renew_lifetime = 1d
>     forwardable = true
>     proxiable = false
>     retain_after_close = false
>     minimum_uid = 500
>     try_first_pass = true
> }
>
> NOTE: The absence of '/etc/krb5.keytab' is the only way I've gotten
> this untrusted Kerberos authentication to work.
>
> Thanks
> - Trey


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/