On Mon, Feb 22, 2016 at 03:31:53PM +0000, Mote, Todd wrote:
> 
> 
> -----Original Message-----
> From: Sumit Bose [mailto:[email protected]] 
> Sent: Monday, February 22, 2016 8:35 AM
> To: [email protected]
> Subject: [SSSD-users] Re: Problem with case sensitivity in Keytab
> 
> > 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.
> 
> Glad to see it's fixed, though Redhat currently only has version 0.7.5-4 in 
> Satellite for RHEL 7 and was built on 01-Jan-14, so this may exist in 7 
> still, I'm not Linux savvy enough to know/find out.  I do see that RHEL 6's 
> version, 0.8.0-1, was built on 17-Dec-15, but is not in my EPEL Server 6 
> channel.  I checked on some of my hosts and they are indeed running 0.7.3 
> still.

It will be fixed in the next RHEL7 realease, ticket is
https://bugzilla.redhat.com/show_bug.cgi?id=1061371.

About EPEL, adcli-0.8.0 is available, see
https://dl.fedoraproject.org/pub/epel/6/x86_64/adcli-0.8.0-1.el6.x86_64.rpm
but please note the typically the EPEL package will be retired when the
RHEL package becomes available.

bye,
Sumit

> 
> I talked to our Satellite admin and he reminded me that we curate patches in 
> our Satellite on a three-month schedule to allow large clusters of systems to 
> remain patch consistent and provide enough time for them all to patch 
> together.  Satellite last updated 01-Dec-15, so just missed getting 0.8.0.  
> It's due to sync again next Tuesday on 01-Mar-16, so I should have 0.8.0 on 
> everything RHEL 6 before too long.
> 
> > 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's consistent with what I observed.
> 
> > 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.
> 
> That's true, AD won't let you put two principals in the servicePrincipalName 
> attribute because it considers them the same principal and complains that one 
> with that name already exists.  Adcli join will however increment the 
> msDS-KeyVersionNumber attribute and remove all of the existing principals on 
> the AD object and then add them back with whatever options you set, if you 
> just do the join again, no delete required.  On Linux, it will increment the 
> knvo in the keytab so that it stays in step with the AD object attribute, and 
> just add new principals to the keytab.  I found myself with principals in my 
> keytab at one point duplicated, one set had 'host/' the other had 'HOST/'.  
> Adcli delete-computer may clean up the keytab for you too, I've not tried it 
> though.  
> 
> Todd
> 
> 
> > 
> > Todd
> > 
> > -----Original Message-----
> > From: Lukas Slebodnik [mailto:[email protected]]
> > Sent: Monday, February 22, 2016 5:07 AM
> > To: End-user discussions about the System Security Services Daemon 
> > <[email protected]>
> > 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$\@DS.LEEDS.AC.UK
> > >> 
> > >> # These do not work
> > >> kinit -k host/fqdn
> > >> kinit -k host/fqdn\@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
> > [email protected]
> > https://lists.fedorahosted.org/admin/lists/[email protected]
> > ed.org _______________________________________________
> > sssd-users mailing list
> > [email protected]
> > https://lists.fedorahosted.org/admin/lists/[email protected]
> > ed.org
> _______________________________________________
> sssd-users mailing list
> [email protected]
> https://lists.fedorahosted.org/admin/lists/[email protected]
> _______________________________________________
> sssd-users mailing list
> [email protected]
> https://lists.fedorahosted.org/admin/lists/[email protected]
_______________________________________________
sssd-users mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]

Reply via email to