[Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server
Rob Crittenden
rcritten at redhat.com
Wed Nov 16 20:54:38 UTC 2016
Sean Hogan wrote:
> update..
>
> I decided to unenroll the box and remove it from IPA totally. I enrolled
> it again and the box is now working as expected. However I did check if
> server1 now has a host certificate loaded in IPA and it does not.
> I have not had to do anything extra in getting a host cert loaded into
> IPA with the RHEL 6 boxes so is there a step I am not doing in getting a
> host cert loaded into IPA from a rhel 7 client to a RHEL 6 server? I
> guess I can do it manual but if I do that certmonger will not auto renew
> them right?
In IPA 4.something ipa-client-install dropped getting a host certificate
by default. There is an option, --request-cert, if you want to continue
that behavior.
Getting a server cert for the host was intended to be future-proofing
and a convenience but we never used it for anything and never got any
reports that anyone else had either (except to notice it isn't there
anymore).
So yeah, you can either un-enroll and re-enroll with the option or
manually request one using ipa-getcert and it will be renewed
automatically in both cases.
rob
> [root at ipa1 ~]# ipa host-find server1
> --------------
> 1 host matched
> --------------
> Host name: server1.ipa.local
> Principal name: host/server1.ipa.local at IPA.LOCAL
> Password: False
> Keytab: True
> Managed by: server1.ipa.local
> SSH public key fingerprint: 12:95:CC:*REMOVED*
> (ssh-ed25519),
> 33:B9:74:26::*REMOVED*
> (ssh-rsa),
> 52:F3:DD:*REMOVED*
> (ecdsa-sha2-nistp256)
>
>
> Where for a RHEL 6 box I see this
>
>
> [root at ipa1 ~]# ipa host-find server2
> --------------
> 1 host matched
> --------------
> Host name: server2.ipa.local
> Certificate: MIIDpjCCAo6gAwIBAgICANQwDQYJKoZIhvcNAQELBQAwNzEVMBMGA1UEChMMV0
> *REMOVED THE REST*
> Principal name: host/server2.ipa.local at IPA.LOCAL
> Password: False
> Member of host-groups: bob
> Indirect Member of HBAC rule: bob2, bob1
> Keytab: True
> Managed by: server2.ipa.local
> Subject: CN=server2.ipa.local,O=IPA.LOCAL
> Serial Number: 212
> Serial Number (hex): 0xD4
> Issuer: CN=Certificate Authority,O=IPA.LOCAL
> Not Before: Tue Jul 26 20:48:58 2016 UTC
> Not After: Fri Jul 27 20:48:58 2018 UTC
> Fingerprint (MD5): 1f:b7:8f:*REMOVED*
> Fingerprint (SHA1): d3:2f:f:*REMOVED*
> SSH public key fingerprint: 1B:26:*REMOVED *
> (ssh-dss),
> 2D:66:D7:*REMOVED*
> (ssh-rsa)
>
>
>
>
> Sean Hogan
>
>
>
>
>
>
>
> Inactive hide details for Sean Hogan---11/16/2016 11:31:33 AM---Yes
> sir... I added the kinit kts in the previous thinking it waSean
> Hogan---11/16/2016 11:31:33 AM---Yes sir... I added the kinit kts in the
> previous thinking it was needed. > [root at server1 read]# kini
>
> From: Sean Hogan/Durham/IBM at IBMUS
> To: Martin Babinsky <mbabinsk at redhat.com>
> Cc: freeipa-users at redhat.com
> Date: 11/16/2016 11:31 AM
> Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server
> Sent by: freeipa-users-bounces at redhat.com
>
> ------------------------------------------------------------------------
>
>
>
> Yes sir... I added the kinit kts in the previous thinking it was needed.
>
>> [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local
>> kinit: Cannot contact any KDC for realm 'IPA.LOCAL' while getting
>> initial credentials
>> [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local
>> kinit: Program lacks support for encryption type while getting initial
>> credentials
>
>
>
> Sean Hogan
>
>
>
>
>
>
> Inactive hide details for Martin Babinsky ---11/16/2016 10:54:32 AM---On
> 11/16/2016 05:56 PM, Sean Hogan wrote: > Sorry.. listiMartin Babinsky
> ---11/16/2016 10:54:32 AM---On 11/16/2016 05:56 PM, Sean Hogan wrote: >
> Sorry.. listing ouput of klist -e and klist -ke... but k
>
> From: Martin Babinsky <mbabinsk at redhat.com>
> To: Sean Hogan/Durham/IBM at IBMUS
> Cc: freeipa-users at redhat.com, Jakub Hrozek <jhrozek at redhat.com>
> Date: 11/16/2016 10:54 AM
> Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server
> ------------------------------------------------------------------------
>
>
>
> On 11/16/2016 05:56 PM, Sean Hogan wrote:
>> Sorry.. listing ouput of klist -e and klist -ke... but kinit -k does not
>> seem to be working if I have it right.. kinit -kt is more promising but
>> still fails
>>
>>
>> *Klists*
>>
>> [root at server1 read]# klist -e
>> Ticket cache: KEYRING:persistent:111111111:11111111111
>> Default principal: admin at ipa.local
>>
>> Valid starting Expires Service principal
>> 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/ipa.local at IPA.LOCAL
>> Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
>>
>>
>> [root at server1 read]# klist -ke
>> Keytab name: FILE:/etc/krb5.keytab
>> KVNO Principal
>> ----
>> --------------------------------------------------------------------------
>> 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96)
>> 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96)
>> 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1)
>> 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac)
>>
>>
>>
>> *Kinits *
>>
>> [root at server1 read]# kinit -k /etc/krb5.keytab host/server1.ipa.local
> Sorry it should read 'kinit -kt /etc/krb5.keytab host/server1.ipa.local'
>
>> Extra arguments (starting with "host/server1.ipa.local").
>> Usage: kinit [-V] [-l lifetime] [-s start_time]
>> [-r renewable_life] [-f | -F] [-p | -P] -n [-a | -A] [-C]
>> [-E]
>> [-v] [-R] [-k [-i|-t keytab_file]] [-c cachename]
>> [-S service_name] [-T ticket_armor_cache]
>> [-X <attribute>[=<value>]] [principal]
>>
>> options: -V verbose
>> -l lifetime
>> -s start time
>> -r renewable lifetime
>> -f forwardable
>> -F not forwardable
>> -p proxiable
>> -P not proxiable
>> -n anonymous
>> -a include addresses
>> -A do not include addresses
>> -v validate
>> -R renew
>> -C canonicalize
>> -E client is enterprise principal name
>> -k use keytab
>> -i use default client keytab (with -k)
>> -t filename of keytab to use
>> -c Kerberos 5 cache name
>> -S service
>> -T armor credential cache
>> -X <attribute>[=<value>]
>>
>> [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local
>> kinit: Cannot contact any KDC for realm 'IPA.LOCAL' while getting
>> initial credentials
>> [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local
>> kinit: Program lacks support for encryption type while getting initial
>> credentials
>>
>>
>> Sean Hogan
>>
>>
>>
>>
>>
>>
>>
>> Inactive hide details for Martin Babinsky ---11/16/2016 09:33:08 AM---On
>> 11/16/2016 05:14 PM, Sean Hogan wrote: > Hi Jakub,Martin Babinsky
>> ---11/16/2016 09:33:08 AM---On 11/16/2016 05:14 PM, Sean Hogan wrote: >
>> Hi Jakub,
>>
>> From: Martin Babinsky <mbabinsk at redhat.com>
>> To: Sean Hogan/Durham/IBM at IBMUS, Jakub Hrozek <jhrozek at redhat.com>
>> Cc: freeipa-users at redhat.com
>> Date: 11/16/2016 09:33 AM
>> Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> On 11/16/2016 05:14 PM, Sean Hogan wrote:
>>> Hi Jakub,
>>>
>>> Thanks... here is output
>>>
>>>
>>> *klist -ke*
>>> [root at server1 rusers]# klist -ke
>>> Keytab name: FILE:/etc/krb5.keytab
>>> KVNO Principal
>>> ----
>>>
> --------------------------------------------------------------------------
>>> 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96)
>>> 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96)
>>> 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1)
>>> 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac)
>>>
>>>
>>>
>>> *kinit -k odd though as kinit -k seems to fail but kinit with admin
>>> seems to work indicating I can hit the KDC even though kinit -k says I
>>> cannot?*
>>>
>>> [root at server1 pam.d]# kinit -k server1
>>> kinit: Keytab contains no suitable keys for server1 at IPA.LOCAL while
>>> getting initial credentials
>>> [root at server1 pam.d]# kinit -k server1.IPA.LOCAL
>>> kinit: Keytab contains no suitable keys for server1.IPA.LOCAL at IPA.LOCAL
>>> while getting initial credentials
>> You need to specify full principal name as printed from klist command,
>> i.e. kinit -k /etc/krb5.keytab host/server1.ipa.local
>>
>>> [root at server1 pam.d]# kinit admin
>>> Password for admin at ipa.local:
>>> [root at server1 pam.d]#
>>> [root at server1 pam.d]# klist
>>> Ticket cache: KEYRING:persistent:1111111111:1111111111
>>> Default principal: admin at IPA.LOCAL
>>>
>>> Valid starting Expires Service principal
>>> 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/IPA.LOCAL at IPA.LOCAL
>>>
>>> [root at server1 pam.d]# ktutil
>>> ktutil: rkt /etc/krb5.keytab
>>> ktutil: l
>>> slot KVNO Principal
>>> ---- ----
>>> ---------------------------------------------------------------------
>>> 1 1 host/server1.ipa.local at IPA.LOCAL
>>> 2 1 host/server1.ipa.local at IPA.LOCAL
>>> 3 1 host/server1.ipa.local at IPA.LOCAL
>>> 4 1 host/server1.ipa.local at IPA.LOCAL
>>>
>>>
>>>
>>> *Added debug_level = 10 on the domain section of sssd.conf and restarted
>>> is all I see*
>>> [root at server1 sssd]# cat ldap_child.log
>>> (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18951]]]]
>>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program
>>> lacks support for encryption type
>>> (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18954]]]]
>>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program
>>> lacks support for encryption type
>>> (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18956]]]]
>>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program
>>> lacks support for encryption type
>>> (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18957]]]]
>>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program
>>> lacks support for encryption type
>>> (Wed Nov 16 10:58:02 2016) [[sssd[ldap_child[18958]]]]
>>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program
>>> lacks support for encryption type
>>> (Wed Nov 16 10:59:26 2016) [[sssd[ldap_child[18977]]]]
>>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program
>>> lacks support for encryption type
>>>
>>>
>>>
>>>
>>> *Additonal:*
>>>
>>> [root at server1 rusers]# systemctl -l status sssd.service
>>> sssd.service - System Security Services Daemon
>>> Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
>>> Drop-In: /etc/systemd/system/sssd.service.d
>>> └─journal.conf
>>> Active: active (running) since Wed 2016-11-16 10:30:43 EST; 17s ago
>>> Process: 3041 ExecStart=/usr/sbin/sssd -D -f (code=exited,
>> status=0/SUCCESS)
>>> Main PID: 3042 (sssd)
>>> CGroup: /system.slice/sssd.service
>>> ├─3042 /usr/sbin/sssd -D -f
>>> ├─3043 /usr/libexec/sssd/sssd_be --domain ipa.local --uid 0 --gid 0
>>> --debug-to-files
>>> ├─3044 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files
>>> ├─3045 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files
>>> ├─3046 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
>>> ├─3047 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files
>>> └─3048 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files
>>>
>>> Nov 16 10:30:43 server1.ipa.local sssd[3042]: Starting up
>>> Nov 16 10:30:43 server1.ipa.local sssd[be[ipa.local]][3043]: Starting up
>>> Nov 16 10:30:43 server1.ipa.local sssd[sudo][3045]: Starting up
>>> Nov 16 10:30:43 server1.ipa.local sssd[pam][3046]: Starting up
>>> Nov 16 10:30:43 server1.ipa.local sssd[nss][3044]: Starting up
>>> Nov 16 10:30:43 server1.ipa.local sssd[ssh][3047]: Starting up
>>> Nov 16 10:30:43 server1.ipa.local sssd[pac][3048]: Starting up
>>> Nov 16 10:30:43 server1.ipa.local systemd[1]: Started System Security
>>> Services Daemon.
>>> Nov 16 10:30:55 server1.ipa.local [sssd[ldap_child[3055]]][3055]: Failed
>>> to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]:
>>> Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP
>>> connection.
>>> [root at server1 rusers]#
>>>
>>> Seeing this in /var/log/sssd/sssd_ipa.local.log
>>>
>>> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [be_process_init]
>>> (0x0010): fatal error initializing data providers
>>> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [main] (0x0010): Could
>>> not initialize backend [14]
>>> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]]
>>> [select_principal_from_keytab] (0x0010): Failed to read keytab
>>> [default]: Bad address
>>> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [load_backend_module]
>>> (0x0010): Error (14) in module (ipa) initialization (sssm_ipa_id_init)!
>>>
>>> This is also strange but might be side effect I assume.. we mount NFS v4
>>> home dir with automount for central homes and profiles.. on the boxes
>>> having this issue some of the IDs show just the UID numbers/GID numebrs
>>> where some of the IDs actually show the UID name/GID name. We have over
>>> 2k servers showing the UID name/GID name with no issues.. just the boxes
>>> having this issue.
>>>
>>>
>>>
>>> Sean Hogan
>>>
>>>
>>>
>>>
>>>
>>>
>>> Inactive hide details for Jakub Hrozek ---11/16/2016 02:29:52 AM---On
>>> Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: Jakub Hrozek
>>> ---11/16/2016 02:29:52 AM---On Tue, Nov 15, 2016 at 07:24:38PM -0700,
>>> Sean Hogan wrote: >
>>>
>>> From: Jakub Hrozek <jhrozek at redhat.com>
>>> To: freeipa-users at redhat.com
>>> Date: 11/16/2016 02:29 AM
>>> Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server
>>> Sent by: freeipa-users-bounces at redhat.com
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> On Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote:
>>>>
>>>>
>>>> Hello,
>>>>
>>>>
>>>> I am starting to see some issues with a few RHEL7 boxes I have been
>>>> enrolling to my RHEL 6 IPA server regarding encryption.
>>>>
>>>>
>>>> RHEL 7 client
>>>> Red Hat Enterprise Linux Server release 7.1 (Maipo)
>>>> sssd-ipa-1.12.2-58.el7_1.18.x86_64
>>>> ipa-client-4.1.0-18.el7_1.4.x86_64
>>>>
>>>> RHEL 6 Server
>>>> Red Hat Enterprise Linux Server release 6.8 (Santiago)
>>>> sssd-ipa-1.13.3-22.el6_8.4.x86_64
>>>> ipa-server-3.0.0-50.el6.1.x86_64
>>>>
>>>>
>>>> The RHEL 7 client shows this in messages
>>>>
>>>> Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support
>>>> for encryption type
>>>
>>> Could you post a more verbose ldap_child log (debug_level=10 includes
>>> KRB5_TRACE-level messages) so that we see what kind of crypto was used?
>>>
>>>> Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize
>>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity
>>> check
>>>> failed. Unable to create GSSAPI-encrypted LDAP connection.
>>>>
>>>> I am also not seeing host certs for them on the ipa server but I do see
>>>> them on the local box.
>>>>
>>>> [root at server1 pam.d]# ktutil
>>>
>>> Can you run klist -ke as well to see what encryption types are included
>>> in the keytab?
>>>
>>> Is it possible to run "kinit -k" on the client?
>>>
>>>> ktutil: rkt /etc/krb5.keytab
>>>> ktutil: l
>>>> slot KVNO Principal
>>>> ---- ----
>>>> ---------------------------------------------------------------------
>>>> 1 1 host/server1.ipa.local at IPA.LOCAL
>>>> 2 1 host/server1.ipa.local at IPA.LOCAL
>>>> 3 1 host/server1.ipa.local at IPA.LOCAL
>>>> 4 1 host/server1.ipa.local at IPA.LOCAL
>>>> ktutil:
>>>>
>>>>
>>>> I have one RHEL 7 box with no issues as it was just enrolled (missing
>> host
>>>> certs in IPA though) and I compared and IPA ID login with a box not
>>>> working
>>>> *NOT Work*
>>>> type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0
>>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>>>> msg='op=PAM:authentication grantors=? acct="janedoe"
> exe="/usr/sbin/sshd"
>>>> hostname=10.10.10.10 addr=10.10.10.9 terminal=ssh res=failed'
>>>>
>>>> vs
>>>>
>>>> Works
>>>> type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0
>>>> auid=4294967295 ses=4294967295
>>> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023
>>>> msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit
>> acct="janedoe"
>>>> exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh
>>>> res=success'
>>>>
>>>> Its almost as if the pam files are not being read?
>>>>
>>>>
>>>>
>>>> Sean Hogan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>> --
>>>> Manage your subscription for the Freeipa-users mailing list:
>>>> _https://www.redhat.com/mailman/listinfo/freeipa-users_
>>>> Go to _http://freeipa.org_ <http://freeipa.org/> for more info on
> the project
>>>
>>> --
>>> Manage your subscription for the Freeipa-users mailing list:
>>> _https://www.redhat.com/mailman/listinfo/freeipa-users_
>>> Go to _http://freeipa.org_ <http://freeipa.org/> for more info on the
> project
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Martin^3 Babinsky
>>
>>
>>
>>
>
>
> --
> Martin^3 Babinsky
>
>
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
>
>
>
More information about the Freeipa-users
mailing list