Failed To Initialize Credentials Using Keytab
Colby DuLin
Need help authenticating linux (Ubuntu) server that is joined to child domain.I can see the server name on the Domain Controller and able to run authentication test successfully however I am not able to login with my domain account. Seems like a config settings somewhere for SSSD or KRB5 config need to specify child domain.Also it is not a domain trust issue since Windows servers joined to child domain are accepting credentials from the parent accounts.
I'm not sure if you need to have both domains listed in a parent-child domain situation, but perhaps try just configuring the child domain by itself first. Or at least put the child first in the domains list.
How are you trying to authenticate the parent domain user? Are you trying to SSH or are you trying a getent locally on the server? Are you using a fully-qualified name to authenticate the parent domain user? e.g. getent passwd [email protected]
This error indicates it's trying to use a keytab with the wrong computer name Client '[email protected]' . It should be using [email protected] if it's joined to the child domain. Does the server keytab actually contain the correct server name for the child domain?
That's why I recommend simplifying the issue by ensuring you can log on with the child domain credential first. Although I really think you should start over with realm join if you didn't use this method.
May 12 07:00:33 neth13 [sssd[ldap_child[1733]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Cannot contact any KDC for realm 'AD.xxxxxxxxxx.AT'. Unable to create GSSAPI-encrypted LDAP connection.
Is it the DC for your domain or did you join another domain as a member? I have seen this on a server that joined a domain. There are several topics in the forums with the same error message.
=accountprovider%20error%2082
I just ran into another error_82 too. I had to remove Samba4 account provider and re-add the accountprovider. Then recreate the users and groups.
Fortunately all data for mail (SOGo) was still in place and accessible for the new useraccounts.
check again if host.fqdn a and ptr exists in the dns.
check resolv.conf
make sure your primary domain is listed first.you left and rejoined the domain, so you can try regenerateing your keytab file also.start with that
greetzLouis
idmap config * : range = 1000000-1999999
Is it really wrong to use autorid for this?Anyway: I have followed your advice, switched to tdb, left and rejoined
domain, and regenerated the keytab. The problem is still there.While doing this I found one stupid problem which was visible in my
original post:
I can get a TGT for any of them, and by default kinit chooses the
first. But the LDAP server won't talk to me unless I choose the
'WRN-RADTEST$' principal.Now I just need to work out how to get freeradius to choose the right
principal - but at worst I should be able to make a new keytab which
doesn't have the other two.Regards,
I can't use rlm_krb5, because I plan to use PEAP+MSCHAP for wifi
authentication. The krb5 module requires a cleartext password, but
MSCHAP does not pass a cleartext password. (It is possible to use krb5
authentication with TTLS+PAP or TTLS+GTC, both of which send a cleartext
password)However, I'm not actually at that point yet. First I'm configuring
freeradius to do the LDAP query. To do this I'm setting environment
variables:KRB5_CLIENT_KTNAME=/etc/krb5.keytab
KRB5CCNAME=MEMORY:Using KRB5_CLIENT_KTNAME means that the Kerberos library will
automatically fetch and renew ticket when required. And I'm telling it
to use the in-process MEMORY cache to hold those tickets.Aside: there is a nasty failure mode if you don't do it like this.
Suppose you type "kinit" to get a ticket, then start your radius server.
Everything appears to work fine, since radius uses the ticket you
generated. But then it stops working 12 hours later when the ticket
expires :-((Incidentally, this is all stuff I have working with FreeIPA; I'm trying
to port these working configs over to a Samba environment)So, back to the situation I'm in, where /etc/krb5.keytab has three
principals, but the first two don't work for authenticating the RADIUS
server to the LDAP server to do LDAP queries.POSSIBLE CAUSE: I found the following:
-not-found-in-kerberos-database-while-getting-initial/"Active Directory does not typically allow you to authenticate as a
service principal (specifically, does not let it acquire a TGT via an
AS_REQ); in theory, service principals are supposed to be for accepting
user credentials, not for authenticating to your kerberos realm.//
//
//This is different from Unix KDCs, which typically do not distinguish
between "service principals" and "user principals" by default, allowing
either to authenticate via kinit"//
//
/This doesn't mention *host* principals as such, but it seems likely
that host/foo@realm and service/foo@realm are both not allowed to
authenticate to Active Directory.And here:
-Express/Kerberos-Client-not-found-in-Kerberos-database/td-p/20591This also says you must kinit as '$'
WORKAROUND: I couldn't get freeradius to select a principal to use for
authentication, so instead I used ktutil to generate a keytab containing
only the 'WRN-RADTEST$' principal.rkt /etc/krb5.keytab
delent 1 # repeat this 10 times
wkt /etc/radius.keytaband chown'd this file so the radius server can access it. This now
works, yay! - freeradius can establish a connection to the LDAP server.
However:
(1) Does Samba change the host kerberos key periodically?If it does, I'll need to automate the updating of the radius keytab as
well. Unfortunately ktutil is not well suited to this role, unless you
are happy to type commands 'blind' to delete the first 10 entries (ugh)(2) Can "net ads keytab create" be told to extract just a single named
principal? That would simplify things. But I can't see how to.As usual... clues gratefully received.
About the "POSSIBLE CAUSE: I found the following.. " part.
Thats exactly why my squid kerberos group didnt work. I manualy added this where it was needed. ... A PROGRAM "login" to Windows Active Directory or Unix kdc as user .
(! Beware SERVICE must match what your program needed )
Squid need HTTP/SPN
Zarafa needs http/SPN It requires Active Directory to have an attribute userPrincipalname set to
< SERVICE/@REALM > for the associated acount.
This is usaully done by using msktutil.
But this is not done by samba-tools So you need to add this manualy.
Greetz, Louis
Am 20.12.2016 um 14:50 schrieb Brian Candler via samba:
> (2) Can "net ads keytab create" be told to extract just a single named
> principal? That would simplify things. But I can't see how to.
>
> As usual... clues gratefully received.
I'm not sure which section you mean is relevant. Maybe this:"When doing a PKINIT based Kerberos logon the KDC adds the
required PAC_CREDENTIAL_INFO element to the authorization data.
That means the NTHASH is shared between the PKINIT based client and
the domain controller, which allows the client to do NTLM based
authentication on behalf of the user."That sounds cool, but I can already use ntlm_auth to validate the MSCHAP
passwords. Modifying FreeRADIUS to be able to do this via Kerberos
doesn't gain me much.The other thing which I'd already noticed was the server-side storage of
GPG-encrypted plaintext passwords. It doesn't make a difference to
MSCHAP, but it'll be useful if I end up using an auth method which
requires the server to have the cleartext password (e.g. EAP-PWD)Cheers,Brian.
I read in MIT website it happens due to many unsuccessful login attempts or account expiry set in default policy in KDC.account can be unlocked using kadmin commands such as kadmin:modprinci spark/principal but I have cross checked with AD admin. He says we don't use kdc server to execute kadmin commands where as we use AD but says spark account is unlocked state when checked using AD UI.
The error you presented: "kinit: Clients credentials have been revoked while getting initial credentials" means the Active Directory account to which the keytab is related has been disabled, locked, expired, or deleted.
By default, one cannot unlock their own account in AD (unless they are Domain Administrator, Domain Account Operator, or a member of some other administratively privileged group). The AD admin would need to grant you these rights. Based on the problem description, it sounds entirely possible the AD admin is looking at the wrong account. For example if you run the command:
where "HTTP/somedomain.local" represents the SPN in this case, the output will reveal the name of the AD account tied to the SPN and keytab - your AD admin needs to look at that account and determine whether its been disabled, locked, expired, or deleted and take corrective action.
Dec 03 11:14:09 spikerealmd02.us.example.com [sssd[ldap_child[9653]]][9653]:Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
getting the below errors and not able to login with ad id , can some help on this ? do we need tweak any info in sssd.conf file ?
Jul 13 07:32:44 hutisalmalnxtest84.corp.jabil.org ldap_child[23107]: Failed to initialize credentials using keytab [MEMORY:/>
As a follow-on from my previous post, where we looked at some Kerberos Principles, in this blog I want to explorer further what is required to enable Kerberos out-bound authentication from SAS Cloud Analytic Services to a Secured Hadoop environment.
In the previous post I was quite vague on just what is required to setup this form of authentication. I merely stated we need to provide some credentials in the form of a Kerberos keytab to the CAS Controller. We will look at this in a little more detail.
4a15465005