Strange behaviour of kinit [Solved]

[steve]

On Sat, 2014-09-13 at 11:02 +0200, Lars Hanke wrote:
>  > On Fri, 2014-09-12 at 22:08 +0200, Lars Hanke wrote:
> >> Am 12.09.2014 21:14, schrieb steve:
> >
> 
> Solution summary: NTP was not running properly and the Samba4 KDC seems 
> to be more picky about time than the MIT KDC. After resynchronizing I 
> get tickets from Samba4.
> 
> The rest attached informally to help others:
> 
> >>>
> >>> DNS? Is the 386 client pointing _only_ at the Samba4 DC?
> >>
> >> The 386 client points to the AD DNS.
> > Does Samba4 DC == AD DNS?
> 
> No it's a seperate bind9, which replicates the Samba4 DNS.
> 
> > Guessing: You don't want to use any domain services on the 386 client.
> 
> Yes, that's the idea. I'm aiming at a setup as described here: 
> https://wiki.samba.org/index.php/Local_user_management_and_authentication/nslcd

We use sssd for the same. Their new AD backend v1.12.1 is a complete
replacement for winbind, is faster and easier than anything else we've
tested. The only gotcha for your setup maybe is that sssd requires the
machine key for the host upon which it is installed. If you're not gonna
join the domain, I don't think you're gonna get that.
> 
> > You simply want to authenticate? Is the Samba4 DC serving MGR?
> 
> No, the Samba4 DC serves AD.MICROSULT.DE. The respective DNS has no 
> Kerberos entries for MGR. Still the client bound to that DNS can 
> authenticate to MGR, but not to AD.MICROSULT.DE.
> 
> And it definitely connects. If I chose a non existing user name, I get 
> "client not found". Wrong password BTW yields "Password incorrect" on 
> MGR at least.
> 
> Wireshark shows that a request is sent to the DC to 
> krbtgt/AD.MICROSULT.DE and the DC answers KRB5KDC_ERR_PREAUTH_REQUIRED 
> (25). This happens twice.
> 
> Doing the same from the amd64 client I also see two requests for krbtgt. 
> The first is also denied with error 25, the second is granted. Apart 
> from the nonce, there's a difference in the padata, i.e. the second 
> request adds a PA-ENC-TIMESTAMP. The behaviour is the same on the 386 
> client.
> 
> ... and that brought me to check NTP!
Yeah. We got that once after a summer time hour change. I think the
default gives you around 5 mins max out of sync.

> >
> > ________________________________________________
> > Kerberos mailing list           Kerberos at mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos