Hello
A question
What another way I can enroll my server client on my IPA server ?
I have a server IPA with S.O. Fedora 24 and freeipa-server-4.3.3-1.fc24.x86_64
My client server have a S.O. CentOS release 5.10 with ipa-client-2.1.3-7.el5
This is the "ipa-client-install -d"
[root@l1 ~]# ipa-client-install -d
root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': None, 'uninstall': False, 'force': False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname': None, 'permit': False, 'server': None, 'prompt_password': False, 'mkhomedir': False, 'dns_updates': False, 'preserve_sssd': False, 'debug': True, 'on_master': False, 'ca_cert_file': None, 'realm_name': None, 'unattended': None, 'ntp_server': None, 'principal': None}
root : DEBUG missing options might be asked for interactively later
root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
root : DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
root : DEBUG [IPA Discovery]
root : DEBUG Starting IPA discovery with domain=None, servers=None, hostname=l1.example.com
root : DEBUG [ipadnssearchldap(example.com)]
root : DEBUG [ipadnssearchkrb]
root : DEBUG [ipacheckldap]
root : DEBUG Verifying that ipa.example.com (realm EXAMPLE.COM) is an IPA server
root : DEBUG Init ldap with: ldap://ipa.example.com:389
root : DEBUG Search LDAP server for IPA base DN
root : DEBUG Check if naming context 'cn=changelog' is for IPA
root : DEBUG Info attribute with IPA server version not found
root : DEBUG Check if naming context 'dc=example,dc=com' is for IPA
root : DEBUG Naming context 'dc=example,dc=com' is a valid IPA context
root : DEBUG Search for (objectClass=krbRealmContainer) in dc=example,dc=com(sub)
root : DEBUG Found: [('cn=example.COM,cn=kerberos,dc=example,dc=com', {'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'cn': ['example.COM']})]
root : DEBUG Discovery result: Success; server=ipa.example.com, domain=example.com, kdc=ipa.example.com, basedn=dc=example,dc=com
root : DEBUG Validated servers: ipa.example.com
root : DEBUG will use domain: example.com
root : DEBUG [ipadnssearchldap(example.com)]
root : DEBUG DNS validated, enabling discovery
root : DEBUG will use discovered server: ipa.example.com
Discovery was successful!
root : DEBUG will use cli_realm: EXAMPLE.COM
root : DEBUG will use cli_basedn: dc=example,dc=com
Hostname: l1.example.com
Realm: example.COM
DNS Domain: example.com
IPA Server: ipa.example.com
BaseDN: dc=example,dc=com
Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
root : DEBUG will use principal: admin
Synchronizing time with KDC...
root : DEBUG args=/usr/sbin/ntpdate -U ntp -s -b ipa.example.com
root : DEBUG stdout=
root : DEBUG stderr=
root : DEBUG Writing Kerberos configuration to /tmp/tmpSeQjKB:
#File modified by ipa-client-install
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
example.COM = {
kdc = ipa.example.com:88
master_kdc = ipa.example.com:88
admin_server = ipa.example.com:749
default_domain = example.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Password for admin@EXAMPLE.COM:
root : DEBUG args=kinit admin@EXAMPLE.COM
root : DEBUG stdout=Password for admin@EXAMPLE.COM:
root : DEBUG stderr=
root : DEBUG trying to retrieve CA cert via LDAP from ldap://ipa.example.com
root : DEBUG Existing CA cert and Retrieved CA cert are identical
In the line "root : DEBUG Existing CA cert and Retrieved CA cert are identical" It's don't progress.
Do Is there any other way I could do it ?
Thanks for your response
Jose Alvarez
Jose Alvarez R. via FreeIPA-users wrote:
Hello
A question
What another way I can enroll my server client on my IPA server ?
I have a server IPA with S.O. Fedora 24 and freeipa-server-4.3.3-1.fc24.x86_64
My client server have a S.O. CentOS release 5.10 with ipa-client-2.1.3-7.el5
This is the “ipa-client-install –d”
[root@l1 ~]# ipa-client-install -d
root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': None, 'uninstall': False, 'force': False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname': None, 'permit': False, 'server': None, 'prompt_password': False, 'mkhomedir': False, 'dns_updates': False, 'preserve_sssd': False, 'debug': True, 'on_master': False, 'ca_cert_file': None, 'realm_name': None, 'unattended': None, 'ntp_server': None, 'principal': None}
root : DEBUG missing options might be asked for interactively later
root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
root : DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
root : DEBUG [IPA Discovery]
root : DEBUG Starting IPA discovery with domain=None, servers=None, hostname=l1.example.com
root : DEBUG [ipadnssearchldap(example.com)]
root : DEBUG [ipadnssearchkrb]
root : DEBUG [ipacheckldap]
root : DEBUG Verifying that ipa.example.com (realm EXAMPLE.COM) is an IPA server
root : DEBUG Init ldap with: ldap://ipa.example.com:389
root : DEBUG Search LDAP server for IPA base DN
root : DEBUG Check if naming context 'cn=changelog' is for IPA
root : DEBUG Info attribute with IPA server version not found
root : DEBUG Check if naming context 'dc=example,dc=com' is for IPA
root : DEBUG Naming context 'dc=example,dc=com' is a valid IPA context
root : DEBUG Search for (objectClass=krbRealmContainer) in dc=example,dc=com(sub)
root : DEBUG Found: [('cn=example.COM,cn=kerberos,dc=example,dc=com', {'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'cn': ['example.COM']})]
root : DEBUG Discovery result: Success; server=ipa.example.com, domain=example.com, kdc=ipa.example.com, basedn=dc=example,dc=com
root : DEBUG Validated servers: ipa.example.com
root : DEBUG will use domain: example.com
root : DEBUG [ipadnssearchldap(example.com)]
root : DEBUG DNS validated, enabling discovery
root : DEBUG will use discovered server: ipa.example.com
Discovery was successful!
root : DEBUG will use cli_realm: EXAMPLE.COM
root : DEBUG will use cli_basedn: dc=example,dc=com
Hostname: l1.example.com
Realm: example.COM
DNS Domain: example.com
IPA Server: ipa.example.com
BaseDN: dc=example,dc=com
Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
root : DEBUG will use principal: admin
Synchronizing time with KDC...
root : DEBUG args=/usr/sbin/ntpdate -U ntp -s -b ipa.example.com
root : DEBUG stdout=
root : DEBUG stderr=
root : DEBUG Writing Kerberos configuration to /tmp/tmpSeQjKB:
#File modified by ipa-client-install
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
example.COM = {
kdc = ipa.example.com:88 master_kdc = ipa.example.com:88 admin_server = ipa.example.com:749 default_domain = example.com pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Password for admin@EXAMPLE.COM:
root : DEBUG args=kinit admin@EXAMPLE.COM
root : DEBUG stdout=Password for admin@EXAMPLE.COM:
root : DEBUG stderr=
root : DEBUG trying to retrieve CA cert via LDAP from ldap://ipa.example.com
root : DEBUG Existing CA cert and Retrieved CA cert are identical
In the line “*root : DEBUG Existing CA cert and Retrieved CA cert are identical*” It’s don’t progress.
I'm surprised it would end here as this isn't an error case. There is nothing after this line in the output or in /var/log/ipaclient-install.log?
rob
Hi Rob
Thanks for your response
No, there is nothing after this line in the output neither in /var/log/ipaclient-install.log
This is my /var/log/ipaclient-install.log
[root@l1 log]# cat /var/log/ipaclient-install.log 2017-06-07 09:57:29,671 DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': None, 'uninstall': False, 'force': False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname': None, 'permit': False, 'server': None, 'prompt_password': False, 'mkhomedir': False, 'dns_updates': False, 'preserve_sssd': False, 'debug': True, 'on_master': False, 'ca_cert_file': None, 'realm_name': None, 'unattended': None, 'ntp_server': None, 'principal': None} 2017-06-07 09:57:29,671 DEBUG missing options might be asked for interactively later
2017-06-07 09:57:29,671 DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' 2017-06-07 09:57:29,671 DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' 2017-06-07 09:57:29,676 DEBUG [IPA Discovery] 2017-06-07 09:57:29,676 DEBUG Starting IPA discovery with domain=None, servers=None, hostname=l1.example.com 2017-06-07 09:57:29,676 DEBUG [ipadnssearchldap(example.com)] 2017-06-07 09:57:29,733 DEBUG [ipadnssearchkrb] 2017-06-07 09:57:29,851 DEBUG [ipacheckldap] 2017-06-07 09:57:29,851 DEBUG Verifying that ipa.example.com (realm EXAMPLE.COM) is an IPA server 2017-06-07 09:57:29,851 DEBUG Init ldap with: ldap://ipa.example.com:389 2017-06-07 09:57:29,890 DEBUG Search LDAP server for IPA base DN 2017-06-07 09:57:29,894 DEBUG Check if naming context 'cn=changelog' is for IPA 2017-06-07 09:57:29,895 DEBUG Info attribute with IPA server version not found 2017-06-07 09:57:29,895 DEBUG Check if naming context 'dc=example,dc=com' is for IPA 2017-06-07 09:57:29,896 DEBUG Naming context 'dc=example,dc=com' is a valid IPA context 2017-06-07 09:57:29,896 DEBUG Search for (objectClass=krbRealmContainer) in dc=example,dc=com(sub) 2017-06-07 09:57:29,898 DEBUG Found: [('cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com', {'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'cn': ['example.COM']})] 2017-06-07 09:57:29,898 DEBUG Discovery result: Success; server=ipa.example.com, domain=example.com, kdc=ipa.example.com, basedn=dc=example,dc=com 2017-06-07 09:57:29,898 DEBUG Validated servers: ipa.example.com 2017-06-07 09:57:29,898 DEBUG will use domain: example.com
2017-06-07 09:57:29,898 DEBUG [ipadnssearchldap(example.com)] 2017-06-07 09:57:29,956 DEBUG DNS validated, enabling discovery 2017-06-07 09:57:29,956 DEBUG will use discovered server: ipa.example.com 2017-06-07 09:57:29,956 DEBUG will use cli_realm: EXAMPLE.COM
2017-06-07 09:57:29,956 DEBUG will use cli_basedn: dc=example,dc=com
2017-06-07 09:58:27,850 DEBUG will use principal: admin
2017-06-07 09:58:28,188 DEBUG args=/usr/sbin/ntpdate -U ntp -s -b ipa.example.com 2017-06-07 09:58:28,188 DEBUG stdout= 2017-06-07 09:58:28,188 DEBUG stderr= 2017-06-07 09:58:28,189 DEBUG Writing Kerberos configuration to /tmp/tmpSeQjKB: #File modified by ipa-client-install
[libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false ticket_lifetime = 24h forwardable = yes
[realms] EXAMPLE.COM = { kdc = ipa.example.com:88 master_kdc = ipa.example.com:88 admin_server = ipa.example.com:749 default_domain = example.com pkinit_anchors = FILE:/etc/ipa/ca.crt }
[domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
2017-06-07 09:59:58,552 DEBUG args=kinit admin@EXAMPLE.COM 2017-06-07 09:59:58,553 DEBUG stdout=Password for admin@EXAMPLE.COM:
2017-06-07 09:59:58,553 DEBUG stderr= 2017-06-07 09:59:58,555 DEBUG trying to retrieve CA cert via LDAP from ldap://ipa.example.com 2017-06-07 09:59:58,578 DEBUG Existing CA cert and Retrieved CA cert are identical
It’s don’t progress.
Thanks, Regards
Jose Alvarez R.
-----Original Message----- From: Rob Crittenden via FreeIPA-users [mailto:freeipa-users@lists.fedorahosted.org] Sent: miércoles 7 de junio de 2017 11:23 a.m. To: FreeIPA users list freeipa-users@lists.fedorahosted.org Cc: jalvarez@cyberfuel.com; Rob Crittenden rcritten@redhat.com Subject: [Freeipa-users] Re: Enroll CentOS 5 on FreeIPA 4.3
Jose Alvarez R. via FreeIPA-users wrote:
Hello
A question
What another way I can enroll my server client on my IPA server ?
I have a server IPA with S.O. Fedora 24 and freeipa-server-4.3.3-1.fc24.x86_64
My client server have a S.O. CentOS release 5.10 with ipa-client-2.1.3-7.el5
This is the “ipa-client-install –d”
[root@l1 ~]# ipa-client-install -d
root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': None, 'uninstall': False, 'force': False, 'sssd': True, 'krb5_offline_passwords': True, 'hostname': None, 'permit': False, 'server': None, 'prompt_password': False, 'mkhomedir': False, 'dns_updates': False, 'preserve_sssd': False, 'debug': True, 'on_master': False, 'ca_cert_file': None, 'realm_name': None, 'unattended': None, 'ntp_server': None, 'principal': None}
root : DEBUG missing options might be asked for interactively later
root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
root : DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
root : DEBUG [IPA Discovery]
root : DEBUG Starting IPA discovery with domain=None, servers=None, hostname=l1.example.com
root : DEBUG [ipadnssearchldap(example.com)]
root : DEBUG [ipadnssearchkrb]
root : DEBUG [ipacheckldap]
root : DEBUG Verifying that ipa.example.com (realm EXAMPLE.COM) is an IPA server
root : DEBUG Init ldap with: ldap://ipa.example.com:389
root : DEBUG Search LDAP server for IPA base DN
root : DEBUG Check if naming context 'cn=changelog' is for IPA
root : DEBUG Info attribute with IPA server version not found
root : DEBUG Check if naming context 'dc=example,dc=com' is for IPA
root : DEBUG Naming context 'dc=example,dc=com' is a valid IPA context
root : DEBUG Search for (objectClass=krbRealmContainer) in dc=example,dc=com(sub)
root : DEBUG Found: [('cn=example.COM,cn=kerberos,dc=example,dc=com', {'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'cn': ['example.COM']})]
root : DEBUG Discovery result: Success; server=ipa.example.com, domain=example.com, kdc=ipa.example.com, basedn=dc=example,dc=com
root : DEBUG Validated servers: ipa.example.com
root : DEBUG will use domain: example.com
root : DEBUG [ipadnssearchldap(example.com)]
root : DEBUG DNS validated, enabling discovery
root : DEBUG will use discovered server: ipa.example.com
Discovery was successful!
root : DEBUG will use cli_realm: EXAMPLE.COM
root : DEBUG will use cli_basedn: dc=example,dc=com
Hostname: l1.example.com
Realm: example.COM
DNS Domain: example.com
IPA Server: ipa.example.com
BaseDN: dc=example,dc=com
Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
root : DEBUG will use principal: admin
Synchronizing time with KDC...
root : DEBUG args=/usr/sbin/ntpdate -U ntp -s -b ipa.example.com
root : DEBUG stdout=
root : DEBUG stderr=
root : DEBUG Writing Kerberos configuration to /tmp/tmpSeQjKB:
#File modified by ipa-client-install
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
example.COM = {
kdc = ipa.example.com:88 master_kdc = ipa.example.com:88 admin_server = ipa.example.com:749 default_domain = example.com pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Password for admin@EXAMPLE.COM:
root : DEBUG args=kinit admin@EXAMPLE.COM
root : DEBUG stdout=Password for admin@EXAMPLE.COM:
root : DEBUG stderr=
root : DEBUG trying to retrieve CA cert via LDAP from ldap://ipa.example.com
root : DEBUG Existing CA cert and Retrieved CA cert are identical
In the line “*root : DEBUG Existing CA cert and Retrieved CA cert are identical*” It’s don’t progress.
I'm surprised it would end here as this isn't an error case. There is nothing after this line in the output or in /var/log/ipaclient-install.log?
rob _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Jose Alvarez R. wrote:
Hi Rob
Thanks for your response
No, there is nothing after this line in the output neither in /var/log/ipaclient-install.log
This is my /var/log/ipaclient-install.log
[snip]
Ok. The very next line is the execution of the enrollment using ipa-join. I guess the logging was limited back in 2.x.
So a brute force way of seeing what is happening would be to use strace like:
# strace -s 1024 -fF -o /tmp/strace.out ipa-client-install
gzip up strace.out and feel free to send it to me directly and I'll try to figure out what is going on.
You may want to look in /var/log/httpd/error_log on the IPA Master it is enrolling against to see if anything is logged on that side. What could be useful to know.
rob
Jose and I exchanged some files privately and I think I've narrowed down the enrollment problem to failing to get a keytab due to the error:
Failed to retrieve encryption type DES cbc mode with CRC-32 (#1)
This is because newer IPA servers don't support DES.
I don't recall the workaround for this but it likely involves enabling weak crypto support it the KDC, something I'm not sure works these days (not a bad thing).
I seem to recall I made a patch to ipa-getkeytab eons ago to cause it to not completely fail as long as one requested key type is retrieved by ipa-getkeytab but it seems unlikely to have been backported to EL 5 (and zero chance at this point).
Not sure what to recommend at this point. Enabling DES is not the best idea.
You could follow the manual client configuration instructions instead.
rob
On pe, 09 kesä 2017, Rob Crittenden via FreeIPA-users wrote:
Jose and I exchanged some files privately and I think I've narrowed down the enrollment problem to failing to get a keytab due to the error:
Failed to retrieve encryption type DES cbc mode with CRC-32 (#1)
This is because newer IPA servers don't support DES.
I don't recall the workaround for this but it likely involves enabling weak crypto support it the KDC, something I'm not sure works these days (not a bad thing).
I have this documented in https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/#en...
I seem to recall I made a patch to ipa-getkeytab eons ago to cause it to not completely fail as long as one requested key type is retrieved by ipa-getkeytab but it seems unlikely to have been backported to EL 5 (and zero chance at this point).
Not sure what to recommend at this point. Enabling DES is not the best idea.
Yes, this is not really for a world of 2017.
You could follow the manual client configuration instructions instead.
That would be a best option.
A keytab can be retrieved on a different machine and supplied to the CentOS 5 client. One needs to make sure only a specific AES key is retrieved because CentOS 5 does support AES-128 in backports, I think.
On (07/06/17 10:21), Jose Alvarez R. via FreeIPA-users wrote:
Hello
A question
What another way I can enroll my server client on my IPA server ?
I have a server IPA with S.O. Fedora 24 and freeipa-server-4.3.3-1.fc24.x86_64
My client server have a S.O. CentOS release 5.10 with
Just for your information CentOS 5 is not supported anymore https://lists.centos.org/pipermail/centos-announce/2017-April/022350.html
If you care about security fixes. Then I would recommend to migrate CentOS 6 or even 7
LS
freeipa-users@lists.fedorahosted.org