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?

[root@ipa1 ~]# ipa host-find server1
--------------
1 host matched
--------------
  Host name: server1.ipa.local
  Principal name: host/server1.ipa.local@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@ipa1 ~]# ipa host-find server2
--------------
1 host matched
--------------
  Host name: server2.ipa.local
  Certificate:
MIIDpjCCAo6gAwIBAgICANQwDQYJKoZIhvcNAQELBQAwNzEVMBMGA1UEChMMV0
REMOVED THE REST
Principal name: host/server2.ipa.local@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










From:   Sean Hogan/Durham/IBM@IBMUS
To:     Martin Babinsky <mbabi...@redhat.com>
Cc:     freeipa-users@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-boun...@redhat.com



Yes sir... I added the kinit kts in the previous thinking it was needed.

> [root@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@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 <mbabi...@redhat.com>
To: Sean Hogan/Durham/IBM@IBMUS
Cc: freeipa-users@redhat.com, Jakub Hrozek <jhro...@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@server1 read]# klist -e
> Ticket cache: KEYRING:persistent:111111111:11111111111
> Default principal: admin@ipa.local
>
> Valid starting Expires Service principal
> 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/ipa.local@IPA.LOCAL
> Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
>
>
> [root@server1 read]# klist -ke
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ----
>
--------------------------------------------------------------------------
> 1 host/server1.ipa.local@IPA.LOCAL (aes256-cts-hmac-sha1-96)
> 1 host/server1.ipa.local@IPA.LOCAL (aes128-cts-hmac-sha1-96)
> 1 host/server1.ipa.local@IPA.LOCAL (des3-cbc-sha1)
> 1 host/server1.ipa.local@IPA.LOCAL (arcfour-hmac)
>
>
>
> *Kinits *
>
> [root@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@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@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 <mbabi...@redhat.com>
> To: Sean Hogan/Durham/IBM@IBMUS, Jakub Hrozek <jhro...@redhat.com>
> Cc: freeipa-users@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@server1 rusers]# klist -ke
>> Keytab name: FILE:/etc/krb5.keytab
>> KVNO Principal
>> ----
>>
--------------------------------------------------------------------------
>> 1 host/server1.ipa.local@IPA.LOCAL (aes256-cts-hmac-sha1-96)
>> 1 host/server1.ipa.local@IPA.LOCAL (aes128-cts-hmac-sha1-96)
>> 1 host/server1.ipa.local@IPA.LOCAL (des3-cbc-sha1)
>> 1 host/server1.ipa.local@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@server1 pam.d]# kinit -k server1
>> kinit: Keytab contains no suitable keys for server1@IPA.LOCAL while
>> getting initial credentials
>> [root@server1 pam.d]# kinit -k server1.IPA.LOCAL
>> kinit: Keytab contains no suitable keys for server1.IPA.LOCAL@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@server1 pam.d]# kinit admin
>> Password for admin@ipa.local:
>> [root@server1 pam.d]#
>> [root@server1 pam.d]# klist
>> Ticket cache: KEYRING:persistent:1111111111:1111111111
>> Default principal: admin@IPA.LOCAL
>>
>> Valid starting Expires Service principal
>> 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/IPA.LOCAL@IPA.LOCAL
>>
>> [root@server1 pam.d]# ktutil
>> ktutil: rkt /etc/krb5.keytab
>> ktutil: l
>> slot KVNO Principal
>> ---- ----
>> ---------------------------------------------------------------------
>> 1 1 host/server1.ipa.local@IPA.LOCAL
>> 2 1 host/server1.ipa.local@IPA.LOCAL
>> 3 1 host/server1.ipa.local@IPA.LOCAL
>> 4 1 host/server1.ipa.local@IPA.LOCAL
>>
>>
>>
>> *Added debug_level = 10 on the domain section of sssd.conf and restarted
>> is all I see*
>> [root@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@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@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 <jhro...@redhat.com>
>> To: freeipa-users@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-boun...@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@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@IPA.LOCAL
>>>    2    1 host/server1.ipa.local@IPA.LOCAL
>>>    3    1 host/server1.ipa.local@IPA.LOCAL
>>>    4    1 host/server1.ipa.local@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 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 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

-- 
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

Reply via email to