Re: [Freeipa-users] Client Certificate
On 09/19/2014 04:03 PM, Walid wrote: Thank you all, will investigate the requirements of host keytabs, and if there is a way around it by having it shared but secure for our context. Couple hints. 1. If you have a keytab stashed and the system was rebuilt you can now rerun ipa-client-install using this keytab to get a new one and configure the client system. It can run and then die but if you store the keytab after running ipa-client-install you would be able to revive it next time 2. In 4.1 you will be able to retrieve same keytab using ipa-getkeytab command. It is implemented to allow clusters that have to share the same key but it might be applicable to your use case too. Thanks Dmitri On 18 September 2014 23:04, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/18/2014 10:12 AM, Walid A. Shaari wrote: Hi, we are going to have a use case of diskless HPC clients that will use the IPA for lookups, I was wondering if i can get rid of the state-fulness of the client configuration as much as possible as it is more of a cattle than pets use case. that is i do not need to know that the client is part of the domain, no need to enroll a node with a certificate. and services will be mostly hpc mpi and ssh, not required to have an SSL certificate for secure communication. is it possible to get rid of the client certificate and the requirements for clients to enroll? or there are other uses for the certificate that i am not aware of ? regards Walid I think the main problem is making sure that the client can connect to IPA server. You can elect to not use ipa-client and just copy configuration files. The problem is that SSSD requires some type of the authentication to get to IPA as a host to do the lookups. So this connection must be authenticated. Since you want it to be stateless you do not want to manage keys or certs the only option (which I really do not like) is to use bind password in a file for LDAP connection. You would probably use the same unprivileged account for this bind. However when we get to 4.x you would need to adjust permissions on the server side to make sure that proper read permissions are granted. Having a password in a file is a security risk so make sure it is not leaked. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
I have recreated the problem. Rebooted the AD and now cannot kinit with AD users. [root@ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit y...@blue.com [22865] 1411157693.26121: Resolving unique ccache of type KEYRING [22865] 1411157693.26167: Getting initial credentials for y...@blue.com [22865] 1411157693.28577: Sending request (156 bytes) to BLUE.COM kinit: Cannot resolve servers for KDC in realm BLUE.COM while getting initial credentials The AD configured as forwarder: [root@ipaserver1 ~]# ipa dnsconfig-show Global forwarders: 192.168.227.60 i can ping the AD machine. 2014-09-16 10:28 GMT+03:00 Sumit Bose sb...@redhat.com: On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: Hello all ! I have deployed test environment for AD trust feature, the environment contains : Windows Server 2008 - AD Server. RHEL 7 - IPA 3.3 Server. RHEL 6.2 - IPA Client. I have established the trust as IPA in the sub domain of AD. AD DNS domain - blue.com IPA DNS domain - linux.blue.com All was working fine as i was able to kinit with AD users: [root@ipaserver1 ~]# kinit y...@blue.com Password for y...@blue.com: [root@ipaserver1 ~]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE Default principal: y...@blue.com Valid starting Expires Service principal 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/blue@blue.com renew until 09/17/2014 01:00:20 But after i rebooted the Windows Server Machine, i could not kinit with AD users anymore: [root@ipaserver1 ~]# kinit y...@blue.com kinit: Cannot resolve servers for KDC in realm BLUE.COM while getting initial The only IPA component used for kinit is the DNS server. How did you configure DNS (glue records? forwarder?). To get more details about what is failing you can call: KRB5_TRACE=/dev/stdout kinit y...@blue.com HTH bye, Sumit I have checked if all the IPA services where UP: [root@ipaserver1 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful After i restarted IPA services (ipactl restart), i was able to to kinit again. Restarting smb service would do the job as well (?). Just wanted to know if it is a know issue, or the AD should be re discovered if it reboots. I think i seen an issue about it in the mailing list some time ago (not sure). I did not increase the debug level and got the logs. But i can share the ipa and sssd version: rpm -qa | grep ipa ipa-server-3.3.3-28.el7_0.1.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.11.2-68.el7_0.5.x86_64 ipa-admintools-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 sssd-ipa-1.11.2-68.el7_0.5.x86_64 iniparser-3.1-5.el7.x86_64 libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 ipa-client-3.3.3-28.el7_0.1.x86_64 rpm -qa | grep sssd sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 sssd-ldap-1.11.2-68.el7_0.5.x86_64 sssd-common-1.11.2-68.el7_0.5.x86_64 sssd-common-pac-1.11.2-68.el7_0.5.x86_64 sssd-ad-1.11.2-68.el7_0.5.x86_64 sssd-krb5-1.11.2-68.el7_0.5.x86_64 sssd-1.11.2-68.el7_0.5.x86_64 python-sssdconfig-1.11.2-68.el7_0.5.noarch sssd-ipa-1.11.2-68.el7_0.5.x86_64 sssd-proxy-1.11.2-68.el7_0.5.x86_64 sssd-client-1.11.2-68.el7_0.5.x86_64 Thanks for all the helpers. -- 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
Re: [Freeipa-users] Client Certificate
Thank you all, will investigate the requirements of host keytabs, and if there is a way around it by having it shared but secure for our context. On 18 September 2014 23:04, Dmitri Pal d...@redhat.com wrote: On 09/18/2014 10:12 AM, Walid A. Shaari wrote: Hi, we are going to have a use case of diskless HPC clients that will use the IPA for lookups, I was wondering if i can get rid of the state-fulness of the client configuration as much as possible as it is more of a cattle than pets use case. that is i do not need to know that the client is part of the domain, no need to enroll a node with a certificate. and services will be mostly hpc mpi and ssh, not required to have an SSL certificate for secure communication. is it possible to get rid of the client certificate and the requirements for clients to enroll? or there are other uses for the certificate that i am not aware of ? regards Walid I think the main problem is making sure that the client can connect to IPA server. You can elect to not use ipa-client and just copy configuration files. The problem is that SSSD requires some type of the authentication to get to IPA as a host to do the lookups. So this connection must be authenticated. Since you want it to be stateless you do not want to manage keys or certs the only option (which I really do not like) is to use bind password in a file for LDAP connection. You would probably use the same unprivileged account for this bind. However when we get to 4.x you would need to adjust permissions on the server side to make sure that proper read permissions are granted. Having a password in a file is a security risk so make sure it is not leaked. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] AD Trust - Cannot resolve servers for KDC after reboot
On Fri, 19 Sep 2014, Genadi Postrilko wrote: I have recreated the problem. Rebooted the AD and now cannot kinit with AD users. [root@ipaserver1 ~]# KRB5_TRACE=/dev/stdout kinit y...@blue.com [22865] 1411157693.26121: Resolving unique ccache of type KEYRING [22865] 1411157693.26167: Getting initial credentials for y...@blue.com [22865] 1411157693.28577: Sending request (156 bytes) to BLUE.COM kinit: Cannot resolve servers for KDC in realm BLUE.COM while getting initial credentials The AD configured as forwarder: [root@ipaserver1 ~]# ipa dnsconfig-show Global forwarders: 192.168.227.60 i can ping the AD machine. If you rebooted AD DC, it takes time to start up its services. If Kerberos library cannot resolve SRV records for BLUE.COM, it means DNS service on AD DC didn't start up yet and cannot respond to DNS queries. 2014-09-16 10:28 GMT+03:00 Sumit Bose sb...@redhat.com: On Tue, Sep 16, 2014 at 01:39:41AM +0300, Genadi Postrilko wrote: Hello all ! I have deployed test environment for AD trust feature, the environment contains : Windows Server 2008 - AD Server. RHEL 7 - IPA 3.3 Server. RHEL 6.2 - IPA Client. I have established the trust as IPA in the sub domain of AD. AD DNS domain - blue.com IPA DNS domain - linux.blue.com All was working fine as i was able to kinit with AD users: [root@ipaserver1 ~]# kinit y...@blue.com Password for y...@blue.com: [root@ipaserver1 ~]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_oi15FrE Default principal: y...@blue.com Valid starting Expires Service principal 09/16/2014 01:00:25 09/16/2014 11:00:25 krbtgt/blue@blue.com renew until 09/17/2014 01:00:20 But after i rebooted the Windows Server Machine, i could not kinit with AD users anymore: [root@ipaserver1 ~]# kinit y...@blue.com kinit: Cannot resolve servers for KDC in realm BLUE.COM while getting initial The only IPA component used for kinit is the DNS server. How did you configure DNS (glue records? forwarder?). To get more details about what is failing you can call: KRB5_TRACE=/dev/stdout kinit y...@blue.com HTH bye, Sumit I have checked if all the IPA services where UP: [root@ipaserver1 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful After i restarted IPA services (ipactl restart), i was able to to kinit again. Restarting smb service would do the job as well (?). Just wanted to know if it is a know issue, or the AD should be re discovered if it reboots. I think i seen an issue about it in the mailing list some time ago (not sure). I did not increase the debug level and got the logs. But i can share the ipa and sssd version: rpm -qa | grep ipa ipa-server-3.3.3-28.el7_0.1.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.11.2-68.el7_0.5.x86_64 ipa-admintools-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 sssd-ipa-1.11.2-68.el7_0.5.x86_64 iniparser-3.1-5.el7.x86_64 libipa_hbac-python-1.11.2-68.el7_0.5.x86_64 ipa-client-3.3.3-28.el7_0.1.x86_64 rpm -qa | grep sssd sssd-krb5-common-1.11.2-68.el7_0.5.x86_64 sssd-ldap-1.11.2-68.el7_0.5.x86_64 sssd-common-1.11.2-68.el7_0.5.x86_64 sssd-common-pac-1.11.2-68.el7_0.5.x86_64 sssd-ad-1.11.2-68.el7_0.5.x86_64 sssd-krb5-1.11.2-68.el7_0.5.x86_64 sssd-1.11.2-68.el7_0.5.x86_64 python-sssdconfig-1.11.2-68.el7_0.5.noarch sssd-ipa-1.11.2-68.el7_0.5.x86_64 sssd-proxy-1.11.2-68.el7_0.5.x86_64 sssd-client-1.11.2-68.el7_0.5.x86_64 Thanks for all the helpers. -- 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 -- / Alexander Bokovoy -- 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
[Freeipa-users] PKI-CA fails to start (broken config after update?)
Hello,
Encountered same issue as described here:
https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html
https://www.redhat.com/archives/freeipa-users/2014-August/msg00224.html
Plain vanilla IPA setup. No changes, no customizations.
Recently IPA fails to start. Error happened right after a 'yum update'
and reboot.
---
Starting pki-ca: [ OK ]
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
...
Failed to start CA Service
Shutting down
Digging into the matter further...
The line that causes the error above is in
/usr/share/pki/scripts/functions (which is loaded by pki-ca init script):
netstat -antl | grep ${port} /dev/null
The $port variable is blank so call to grep is without a search
parameter. Hence invalid call to grep and subsequent error msg I'm
seeing as above.
$port is defined just a few lines above as
port=`grep '^pkicreate.unsecure_port='
${pki_instance_configuration_file} | cut -b25- -`
BUT! For whatever reason there is no line that starts with
pkicreate.unsecure_port in $pki_instance_configuration_file
(/var/lib/pki-ca/conf/CS.cfg). Thus no port info is ever obtained for
use in grep.
Why there is no such line in config file where one is expected is
unknown to me...
Versions currently installed
ipa-server-3.0.0-37.el6.x86_64
pki-ca-9.0.3-32.el6.noarch
Did updates to pki packages clobber the configs? What got broken? How do
I resolve it?
Thank you.
--
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
