[Freeipa-users] Joining realm failed: SASL Bind failed Local error (-2)
Dmitri Pal
dpal at redhat.com
Sat Mar 8 23:51:15 UTC 2014
On 03/08/2014 01:32 AM, Rashard.Kelly at sita.aero wrote:
> Hello all!!
>
> I cannot get a RHEL5.10 client to install!
>
> [root at 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 ipaserver at domain.com krb5kdc[29358](info): TGS_REQ (1
> etypes {18}) 10.226.124.10: ISSUE: authtime 1394259840, etypes {rep=18
> tkt=18 ses=18}, rkelly at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM
> Mar 08 06:24:00 ipaserver at 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}, rkelly at DOMAIN.COM for
> ldap/ipaserver.domain.com at 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 ipaserver at domain.como krb5kdc[29358](info): TGS_REQ (7
> etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0,
> rkelly at IPA2.DC.SITA.AERO for ldap/10.226.20.31 at DOMAIN.COM, Server not
> found in Kerberos database
> Mar 08 06:24:00 ipaserver at domain.com krb5kdc[29357](info): TGS_REQ (7
> etypes {18 17 16 23 1 3 2}) 10.22.22.10: UNKNOWN_SERVER: authtime 0,
> rkelly at IPA2.DC.SITA.AERO for ldap/10.226.20.31 at 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 <dpal at redhat.com>
> To: Trey Dockendorf <treydock at gmail.com>
> Cc: freeipa-users at redhat.com
> Date: 03/07/2014 05:43 PM
> Subject: Re: [Freeipa-users] Using external KDC
> Sent by: freeipa-users-bounces at redhat.com
> ------------------------------------------------------------------------
>
>
>
> On 03/07/2014 05:26 PM, Trey Dockendorf wrote:
> > On Thu, Mar 6, 2014 at 7:20 PM, Dmitri Pal<dpal at 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<treydock at gmail.com>
> >>> wrote:
> >>>> On Mon, Mar 3, 2014 at 7:29 PM, Dmitri Pal<dpal at 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 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
>
>
> --
> 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
>
>
> 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 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140308/9bbd5435/attachment.htm>
More information about the Freeipa-users
mailing list