On 03/08/2014 01:32 AM, rashard.ke...@sita.aero wrote:
Hello all!!

I cannot get a RHEL5.10 client to install!

[root@hostname ~]# ipa-client-install --hostname=hostname.domain.com --no-ntp --ca-cert-file=/etc/ipa/ca.crt DNS domain 'doman.com' is not configured for automatic KDC address lookup.
KDC address will be set to fixed value.

Discovery was successful!
Hostname:hostname.com
Realm:DOMAIN.COM
DNS Domain: domain.com
IPA Server: ipaserver.com
BaseDN: dc=ipa,dc=dc,dc=sita,dc=com

Joining realm failed: SASL Bind failed Local error (-2) !
child exited with 9
Installation failed. Rolling back changes.


This is what the krb log had to say

Mar 08 06:24:00 ipaser...@domain.com krb5kdc[29358](info): TGS_REQ (1 etypes {18}) 10.226.124.10: ISSUE: authtime 1394259840, etypes {rep=18 tkt=18 ses=18}, rke...@domain.com for krbtgt/domain....@domain.com Mar 08 06:24:00 ipaser...@domain.com krb5kdc[29357](info): TGS_REQ (4 etypes {18 17 16 23}) 10.226.20.31: ISSUE: authtime 1394259840, etypes {rep=18 tkt=18 ses=18}, rke...@domain.com for ldap/ipaserver.domain....@domain.com krb5kdc: Cannot determine realm for numeric host address - unable to find realm of host

Check your DNS. It seems that the client can't resolve the server. It should be either in /etc/hosts or resolve.conf should include DNS server that has records about the server.

Mar 08 06:24:00 ipaser...@domain.como krb5kdc[29358](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0, rke...@ipa2.dc.sita.aero for ldap/10.226.20...@domain.com, Server not found in Kerberos database Mar 08 06:24:00 ipaser...@domain.com krb5kdc[29357](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0, rke...@ipa2.dc.sita.aero for ldap/10.226.20...@domain.com, Server not found in Kerberos database


After reviewing the https://access.redhat.com/site/solutions/231543post IPA: Joining realm failed: SASL Bind failed Local error (-2) ! child exited with 9. I checked all my DNS info via dig and took a working DNS config from another server. Everything appears to be setup right. What could I be overlooking?

Thank You,
*Rashard Kelly**
**SITA** S*enior Linux Specialist



From: Dmitri Pal <d...@redhat.com>
To: Trey Dockendorf <treyd...@gmail.com>
Cc: freeipa-users@redhat.com
Date: 03/07/2014 05:43 PM
Subject: Re: [Freeipa-users] Using external KDC
Sent by: freeipa-users-boun...@redhat.com
------------------------------------------------------------------------



On 03/07/2014 05:26 PM, Trey Dockendorf wrote:
> On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal<d...@redhat.com>  wrote:
>> On 03/05/2014 06:24 PM, Trey Dockendorf wrote:
>>> Correction from my email, the condition that sets if a 389DS user is
>>> proxied to pam_krb5 is the "pamFilter", sorry.
>>>
>>> On Wed, Mar 5, 2014 at 5:22 PM, Trey Dockendorf<treyd...@gmail.com>
>>> wrote:
>>>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<d...@redhat.com>   wrote:
>>>>> On 03/03/2014 07:47 PM, Simo Sorce wrote:
>>>>>> On Mon, 2014-03-03 at 18:42 -0600, Trey Dockendorf wrote:
>>>>>>> Is it possible with FreeIPA to use an external KDC or pass some or all >>>>>>> authentication to an external KDC? The KDC at our University may give >>>>>>> me a one way trust if I describe my implementation plan for FreeIPA. >>>>>>> Currently I use 389DS with PAM pass through using untrusted pam_krb5. >>>>>>> I'd like to fully utilize FreeIPA without managing passwords since all
>>>>>>> my users already have University accounts.  I just want to manage
>>>>>>> authorization for my systems, not authentication.
>>>>>> You could set up a kerberos trust manually but at the moment we do not
>>>>>> support it in the code or the utilities.
>>>>>>
>>>>>> SSSD in particular will have no place to find identity information if >>>>>> all you have is a kerberos trust, you'd need also an external identity >>>>>> store to point to, but there is no builtin code in SSSD to link the 2
>>>>>> domain at this point.
>>>>>>
>>>>>> We are planning on working on IPA-to-IPA trust, and possibly
>>>>>> IPA-to-*other* so any requirements you can throw at us will be made
>>>>>> part
>>>>>> of the consideration and planning to add this kind of functionality in
>>>>>> the future.
>>>>>>
>>>>>> NM B HTH,
>>>>>> Simo.
>>>>>>
>>>>> Can you describe your workflows because I have some idea in mind?
>>>> Right now the workflow I have with 389ds using PAM Pass Through Auth
>>>> is the following:
>>>>
>>>> For users with the proper attribute defined in 'pamIDAttr'
>>>>
>>>> client --->   389DS --->   389DS server's pam_krb5 --->   Campus KDC
>>>>
>>>> For users lacking the attribute for 'pamIDAttr'
>>>>
>>>> client --->   389DS
>>>>
>>>> The Kerberos setup currently on the 389DS server is untrusted (no
>>>> krb5.keytab).
>>>>
>>>> The ideal workflow with FreeIPA would be
>>>>
>>>> client ---->   IPA --->   Campus KDC
>>>>
>>>>> Would you be OK if your accounts would be in IPA but the authentication
>>>>> would be proxied out?
>>>> This is fine with me.  Does the idea you describe allow for some
>>>> authentication (ie system accounts or internal accounts) to be handled
>>>> by FreeIPA?  That's the benefit to us when using PAM Pass Through
>>>> Auth, is that we can conditionally proxy out the authentication.
>>>>
>>>>> The idea is that you can use OTP RADIUS capability to proxy passwords to
>>>>> your main KDC.
>>>>>
>>>>> client ---OTP---> IPA ---> OTP Proxy ---> RADIUS ---> Your KDC
>>>>>
>>>>> Disclaimer: that would defeat the purpose of Kerberos and the password
>>>>> will
>>>>> be sent over the wire but it seems that you are already in this setup.
>>>>>
>>>>> Would you be interested to give it a try?
>>>> Absolutely.  Right now I need to contact our campus IT group and let
>>>> them know what I require to make our setup work.  I have been told a
>>>> one way trust is the most I can get.  Will that facilitate what you
>>>> described?
>>
>> You do not need trust for that setup. Any user account (i am not sure about >> special system accounts that are not created in cn=users) would be able to
>> go to external RADIUS server.
>>
>>
>>>>> Would require latest SSSD and kerberos library on the client though but
>>>>> would work with LDAP binds too.
>>>> Latest SSSD and Kerberos that's available in EL6, or latest upstream?
>>
>> Upstream.
>>
> Is it possible use these latest versions in EL6, or is using Fedora
> 19+ the only feasible way to do this?  If using EL6 is not possible,
> is it going to be something possible in EL7?


Latest RHEL7 beta snapshots might be a good starting point.
This will not be a part of RHEL6, sorry.

>
>> Please take a look at the design page: http://www.freeipa.org/page/V3/OTP-
>> that will give you an idea about the internals.
>>
>> Latest upstream UI should be able to allow to configure external RADIUS
>> servers and then change per user policy to proxy via RADIUS. Then you can
>> try binding with LDAP to IPA using password from your main KDC.
>> Then you can use SSSD on the same system to try to authenticate using
>> Kerberos. You will create a new user, set him to use RADIUS server for
>> authentication and then try to su to this user or ssh into the box as that >> user. It should work and klist should report a TGT for this user on the box.
>>
> Thanks for the info. I'll see if I can piece together how to make this work.

Let me know if you need any help or guidance with this POC.

>
>>>>> --
>>>>> 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@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@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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system.



_______________________________________________
Freeipa-users mailing list
Freeipa-users@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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to