[Freeipa-users] Re: Unable to create GSSAPI-encrypted LDAP connection
On Mon, Dec 04, 2017 at 02:51:16PM +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the list,
>
>
>
> I've seen this issue on the list several times, but I've not yet seen a
> solution posted., We're having this issue on one of our SLES 12 SP2 hosts
> (we have other SLES hosts are fine), were seeing this error when users try
> and login, they just keep getting the Password: prompt and are unable to log
> in with FreeIPA accounts. Local accounts are fine. Hostnames have been
> changed to protect the innocent.
>
>
>
> In this hosts /var/log/sssd/ldap_child.log
>
> <27>1 2017-12-04T01:33:01.641547+00:00 sles01 sssd[ldap_child[17456 - -
> Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
> Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
>
> <27>1 2017-12-04T01:33:01.641772+00:00 sles01 sssd[ldap_child[17456 - -
> Preauthentication failed
>
> <27>1 2017-12-04T01:33:01.725694+00:00 sles01 sssd[ldap_child[17457 - -
> Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
> Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
>
> <27>1 2017-12-04T01:33:01.725987+00:00 sles01 sssd[ldap_child[17457 - -
> Preauthentication failed
>
>
>
> On the FreeIPA server from /var/log/krb5kdc.log
>
>
>
> 17 16 23 25 26}) 192.168.131.1: NEEDED_PREAUTH:
> host/sles01.example@example.org for krbtgt/example@example.org,
> Additional pre-authentication required
>
> Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
> 11
>
> Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): preauth
> (encrypted_timestamp) verify failure: Preauthentication failed
>
> Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
> etypes {18 17 16 23 25 26}) 192.168.131.1: PREAUTH_FAILED:
> host/sles01.example@example.org for krbtgt/example@example.org,
> Preauthentication failed
>
> Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
> 11
>
> Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
> etypes {18 17 16 23 25 26}) 192.168.131.1: NEEDED_PREAUTH:
> host/sles01.example@example.org for krbtgt/example@example.org,
> Additional pre-authentication required
>
> Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
> 11
>
> Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): preauth
> (encrypted_timestamp) verify failure: Preauthentication failed
>
> Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
> etypes {18 17 16 23 25 26}) 192.168.131.1: PREAUTH_FAILED:
> host/sles01.example@example.org for krbtgt/example@example.org,
> Preauthentication failed
>
>
>
> On the host in question klist gives the following (note that kinit works,
> even if ssh login does not):
>
>
>
> sles01:~ # klist -kte
>
> Keytab name: FILE:/etc/krb5.keytab
>
> KVNO Timestamp Principal
>
> -
>
>
>1 12/01/17 04:30:40 host/sles01.example@example.org
> (aes256-cts-hmac-sha1-96)
>
>1 12/01/17 04:30:40 host/sles01.example@example.org
^^^
> (aes128-cts-hmac-sha1-96)
>
> sles01:~ # kinit admin
>
> Password for ad...@example.org:
>
> kinit: Preauthentication failed while getting initial credentials
>
> sles01:~ # kinit admin
>
> Password for ad...@example.org:
>
> sles01:~ # kvno host/sles01.example@example.org
>
> host/sles01.example@example.org: kvno = 3
^^^
The host keys stored in /etc/krb5.keytab got out of sync, the keytab
still has KVNO 1 while the current one is already 3.
Most probably someone called ipa-getkeytab without writing the result
back to /etc/krb5.keytab. ipa-getkeytab be default will generate new
keys, you have to use the option --retrieve to get the current keys.
To fix this call ipa-getkeytab again with the --keytab=/etc/krb5.conf
option on sles01.example.org to update /etc/krb5.keytab.
HTH
bye,
Sumit
>
>
>
> Also, I've compared NTP and there's only ~2.5ms offset between the two
> hosts.
>
>
>
> Increasing the logging level of sssd to debug_level=9 which does not
> generate more logs.
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Unable to create GSSAPI-encrypted LDAP connection
Hello the list,
I've seen this issue on the list several times, but I've not yet seen a
solution posted., We're having this issue on one of our SLES 12 SP2 hosts
(we have other SLES hosts are fine), were seeing this error when users try
and login, they just keep getting the Password: prompt and are unable to log
in with FreeIPA accounts. Local accounts are fine. Hostnames have been
changed to protect the innocent.
In this hosts /var/log/sssd/ldap_child.log
<27>1 2017-12-04T01:33:01.641547+00:00 sles01 sssd[ldap_child[17456 - -
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
<27>1 2017-12-04T01:33:01.641772+00:00 sles01 sssd[ldap_child[17456 - -
Preauthentication failed
<27>1 2017-12-04T01:33:01.725694+00:00 sles01 sssd[ldap_child[17457 - -
Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
<27>1 2017-12-04T01:33:01.725987+00:00 sles01 sssd[ldap_child[17457 - -
Preauthentication failed
On the FreeIPA server from /var/log/krb5kdc.log
17 16 23 25 26}) 192.168.131.1: NEEDED_PREAUTH:
host/sles01.example@example.org for krbtgt/example@example.org,
Additional pre-authentication required
Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
11
Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): preauth
(encrypted_timestamp) verify failure: Preauthentication failed
Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.131.1: PREAUTH_FAILED:
host/sles01.example@example.org for krbtgt/example@example.org,
Preauthentication failed
Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
11
Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.131.1: NEEDED_PREAUTH:
host/sles01.example@example.org for krbtgt/example@example.org,
Additional pre-authentication required
Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): closing down fd
11
Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): preauth
(encrypted_timestamp) verify failure: Preauthentication failed
Dec 04 01:31:42 ipaserver01.example.org krb5kdc[1089](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 192.168.131.1: PREAUTH_FAILED:
host/sles01.example@example.org for krbtgt/example@example.org,
Preauthentication failed
On the host in question klist gives the following (note that kinit works,
even if ssh login does not):
sles01:~ # klist -kte
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
-
1 12/01/17 04:30:40 host/sles01.example@example.org
(aes256-cts-hmac-sha1-96)
1 12/01/17 04:30:40 host/sles01.example@example.org
(aes128-cts-hmac-sha1-96)
sles01:~ # kinit admin
Password for ad...@example.org:
kinit: Preauthentication failed while getting initial credentials
sles01:~ # kinit admin
Password for ad...@example.org:
sles01:~ # kvno host/sles01.example@example.org
host/sles01.example@example.org: kvno = 3
Also, I've compared NTP and there's only ~2.5ms offset between the two
hosts.
Increasing the logging level of sssd to debug_level=9 which does not
generate more logs.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Unable to use externa groups or users, truster domain object not found
> On 1 Dec 2017, at 10:52, Henrik Johansson wrote: > > Hi, > > Answers below, I found one thing that don’t look correct, on another > virtualised test-system I can get a cifs ticket when I am admin on the IPA > server, in this setup it only works if I get tickets from the AD domain > manually first: > > [root@ipaserver httpd]# kinit admin > Password for ad...@idm.test.net: > [root@ipaserver httpd]# klist > Ticket cache: KEYRING:persistent:0:0 > Default principal: ad...@idm.test.net > > Valid starting Expires Service principal > 12/01/2017 10:25:48 12/02/2017 10:25:39 krbtgt/idm.test@idm.test.net > [root@ipaserver httpd]# kvno -S cifs adserver.ad2.test.net > kvno: Server krbtgt/ad2.test@idm.test.net not found in Kerberos database > while getting credentials for cifs/adserver.ad2.test@ad2.test.net > [root@ipaserver httpd]# kinit adminu...@ad2.test.net > Password for adminu...@ad2.test.net: > Warning: Your password will expire in 5 days on Wed 06 Dec 2017 03:20:14 PM > CET > [root@ipaserver httpd]# kvno -S cifs adserver.ad2.test.net > cifs/adserver.ad2.test@ad2.test.net: kvno = 13 > > >> On 27 Nov 2017, at 14:06, Jakub Hrozek via FreeIPA-users >> wrote: >> >> On Tue, Nov 21, 2017 at 01:55:31PM +0100, Henrik Stigendal via FreeIPA-users >> wrote: >>> Hello everyone, >>> >>> I’m new to this and are trying to setup a working trust against an AD >>> forrest, I seem to have a working trust but when I try to reference >>> external groups (or users) I get: >>> >>> # ipa group-add-member ad_users_external --external "AD2\Domain Users" >>> [member user]: >>> [member group]: >>> Group name: ad_users_external >>> Description: AD users external map >>> Failed members: >>>member user: >>>member group: AD2\Domain Users: trusted domain object not found >>> - >>> Number of members added 0 >>> - >> >> I think the lookup goes eventually from the ipa command line framework >> to SSSD, does lookup through the usual SSSD channels (getent passwd >> username@domain) work? > > No, that does not work at all. > >> >>> >>> I enable some logging and last in the mail is the output there from the >>> command above, any suggestions what could cause this? Current version of >>> IPA is 4.5. >>> >>> Regards >>> Henrik >>> >>> Tue Nov 21 13:10:42.675713 2017] [:warn] [pid 38221] [client >>> 192.168.6.82:34714] failed to set perms (3140) on file >>> (/var/run/ipa/ccaches/ad...@idm.test.net)!, referer: >>> https://ipaserver.idm.test.net/ipa/xml >>> string_to_sid: SID AD2\Domain Users is not in a valid format >> >> btw did you try also a lookup of a name qualified with the full AD domain >> name (i.e. username@ad.domain instead of ad\\username)? I wonder if just >> the flatname is acting up.. > > > I’ve tested both without luck. I would suggest to find out why the lookups from the command line don’t work. You can check how to debug sssd here: https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html feel free to share your logs if they are not easy to read. > >> >>> lpcfg_load: refreshing parameters from /usr/share/ipa/smb.conf.empty >>> Processing section "[global]" >>> INFO: Current debug levels: >>> all: 11 >>> tdb: 11 >>> printdrivers: 11 >>> lanman: 11 >>> smb: 11 >>> rpc_parse: 11 >>> rpc_srv: 11 >>> rpc_cli: 11 >>> passdb: 11 >>> sam: 11 >>> auth: 11 >>> winbind: 11 >>> vfs: 11 >>> idmap: 11 >>> quota: 11 >>> acls: 11 >>> locking: 11 >>> msdfs: 11 >>> dmapi: 11 >>> registry: 11 >>> scavenger: 11 >>> dns: 11 >>> ldb: 11 >>> tevent: 11 >>> pm_process() returned Yes >>> added interface eno16780032 ip=192.168.6.82 bcast=192.168.6.255 >>> netmask=255.255.255.0 >>> added interface eno33559296 ip=192.168.44.67 bcast=192.168.44.255 >>> netmask=255.255.255.0 >>> added interface eno16780032 ip=192.168.6.82 bcast=192.168.6.255 >>> netmask=255.255.255.0 >>> added interface eno33559296 ip=192.168.44.67 bcast=192.168.44.255 >>> netmask=255.255.255.0 >>> added interface eno16780032 ip=192.168.6.82 bcast=192.168.6.255 >>> netmask=255.255.255.0 >>> added interface eno33559296 ip=192.168.44.67 bcast=192.168.44.255 >>> netmask=255.255.255.0 >>> added interface eno16780032 ip=192.168.6.82 bcast=192.168.6.255 >>> netmask=255.255.255.0 >>> added interface eno33559296 ip=192.168.44.67 bcast=192.168.44.255 >>> netmask=255.255.255.0 >>> finddcs: searching for a DC by DNS domain ad2.test.net >>> finddcs: looking for SRV records for _ldap._tcp.ad2.test.net >>> resolve_lmhosts: Attempting lmhosts lookup for name >>> _ldap._tcp.ad2.test.net<0x0> >>> getlmhostsent: lmhost entry: 127.0.0.1 localhost >>> ads_dns_lookup_srv: 2 records returned in the answer section. >>> ads_dns_parse_rr_srv: Parsed adserver.ad2.test.net [0, 100, 389] >>> ads_dns_parse_rr_srv: Parsed adserver.ad2.test.net [0, 100, 389] >>> Addrs = 192.168.5.158@389/adserver,192.168.5.104@389/adserver >>> finddcs: DNS SRV response
[Freeipa-users] Re: SSHFP Records on external DNS
From client command line ssh-keygen -r `hostname` will give you sshfp records. Anvar Kuchkartaev an...@aegisnet.eu Original Message From: Günther J. Niederwimmer via FreeIPA-users Sent: domingo, 3 de diciembre de 2017 15:50 To: freeipa-users@lists.fedorahosted.org Reply To: FreeIPA users list Cc: Günther J. Niederwimmer Subject: [Freeipa-users] SSHFP Records on external DNS Hello, I mean I have a Problem ;-). I like to include the SSHPF records on a external DNS Server but I don't found the correct entries created by ipa-client-install ?? Is there a way to found the SSHPF records to include on the external DNS Server. Thanks for the Help! CentOS 7.4 FreeIPA 4.5 -- mit freundlichen Grüssen / best regards, Günther J. Niederwimmer ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] SSHFP Records on external DNS
Hello, I mean I have a Problem ;-). I like to include the SSHPF records on a external DNS Server but I don't found the correct entries created by ipa-client-install ?? Is there a way to found the SSHPF records to include on the external DNS Server. Thanks for the Help! CentOS 7.4 FreeIPA 4.5 -- mit freundlichen Grüssen / best regards, Günther J. Niederwimmer ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
