On Mon, Feb 22, 2016 at 01:39:58PM +0000, Mote, Todd wrote:
I've come across the same issue in the last two weeks. here are
the details of my situation and how I worked around it.
I'm trying to design an agnostic way to join both RHEL 6 and RHEL 7 to AD and have
settled on adcli because it's available for both, realmd isn't for 6. In doing so
I also wanted to Kerberize SSH and fought with it for quite some time until I discovered
OpenSSH's proclivity to want lowercase 'host/...' in the principal. This is
what I found. It all came down to the case of the word 'host' in the principals
it creates in both the AD object and the keytab on the Linux host.
Adcli by default will create principals in the keytab and on the AD object itself with
uppercase 'HOST/...' but that effectively disables SSH, if I did nothing else but
change the case of the word 'host' in the AD object to be lowercase and match the
case in the keytab I could get SSH and AD lookups to work.
I finally ended up playing with adcli command line options and found that I could have
adcli create the principal in lowercase in both the keytab and the AD object by adding
" --service-name=host" as an option. Name lookups work and SSH works, and I
don't have to do anything special after the join to align principals. I'm not
sure what the consequences of a lowercase 'host/...' in a Kerberos principal is,
but this lets everything I need right now work for me.
I wondered if this was a bug or not, but I finally decided that because adcli creates the
principals consistently, it's really SSH's issue not working with uppercase
'HOST/...' in principals that's the problem.
As Patrice already mentioned the upper-case HOST/... is an issue in
adcli which is fixed in recent version of adcli, see
https://bugs.freedesktop.org/show_bug.cgi?id=84749 for details.
The lower-case version 'host/...' should be always used. I try to avoid
saying that this is the right or correct version, becasue it is just an
convention. According to the related RFCs Kerberos is case-sensitive
which means that 'HOST/...' and 'host/...' are different principals from
the Kerberos point of view. When a service is kerberized the client and
the server side programs of the service must use the same principal and
must not only use the same service name but the same case as well. Some
services like ssh ('host/...') or ldap ('ldap/...') use lower-case
service names while other services like dns ('DNS/...') or http
('HTTP/...') use upper-case service name.
That said the lower-case 'host/...' is mentioned in the Kerberos RFC
4120 in section 1.3 (
http://tools.ietf.org/html/rfc4120#section-1.3).
Although it is only a "might be derived from" I think it is a quite
strong recommendation to use (host/...) for services to access the host
directly like telnet and ssh.
Btw, if you switch to a newer version of adcli which uses host/... you
might need to removed the host with 'adcli delete-computer ...' first.
The reason is that AD treats Kerberos mostly case-insensitive (in
contrast to the RFC) and might not recognise that the new version of
adcli might want to change the principal to lower-case and keep using
the upper-case version.
HTH
bye,
Sumit
>
> Todd
>
> -----Original Message-----
> From: Lukas Slebodnik [mailto:lslebodn@redhat.com]
> Sent: Monday, February 22, 2016 5:07 AM
> To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
> Subject: [SSSD-users] Re: Problem with case sensitivity in Keytab
>
> On (22/02/16 11:48), Sumit Bose wrote:
> >On Mon, Feb 22, 2016 at 09:41:47AM +0000, John Hodrien wrote:
> >> On Mon, 22 Feb 2016, Patrice Peterson wrote:
> >>
> >> >Hey list,
> >> >
> >> >I have joined a CentOS 7 host to an AD domain using a fairly new
> >> >version of adcli (one of the versions that has this [0] bug fixed).
> >> >In its keytab, this host has a service principal of the form
'host/fqdn@REALM' (i.e. lowercase).
> >> >User lookups with SSSD don't work, and the SSSD log says
"Client
> >> >'host/fdqn@REALM' not found in Kerberos database. Unable to
create
> >> >GSSAPI-encrypted LDAP connection."
> >> >
> >> >However, if I use the 'old' adcli to join the node and create
the
> >> >keytab, it creates a service principal of the form
> >> >'HOST/fqdn@REALM'. With this keytab, I can do username lookups
just fine.
> >> >
> >> >Should this be considered a bug? Is there a way to make service
> >> >principal lookups w/SSSD case insensitive? I would like to keep the
> >> >lower-case principal names in my keytabs, because OpenSSH GSSAPI
> >> >auth only works with those.
> >> >
> >> >Thanks for any pointers!
> >>
> >> SSSD with a normal AD joined machine would use the SHORTHOST$@REALM
> >> entry, not any of the others. That one's the only one that's a
> >> userPrincipal by default (although you can choose *one* additional
userPrincipal if you require).
> >>
> >> You can test this on the command line as it's the only one kinit -k
> >> will work
> >> with:
> >>
> >> # These work
> >> kinit -k SHORTHOST$ kinit -k SHORTHOST$\(a)DS.LEEDS.AC.UK
> >>
> >> # These do not work
> >> kinit -k host/fqdn
> >> kinit -k host/fqdn\(a)DS.LEEDS.AC.UK
> >>
> >> So I'm not entirely sold on your diagnosis being correct.
> >
> >I agree with John here. Can you share your sssd.conf?
> >
> And also sssd domain log file and (*_child.log)
https://fedorahosted.org/sssd/wiki/Troubleshooting
>
> LS
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org