Re: [Freeipa-users] CA setup and ipa-gertcert questions
On 01/13/2014 12:53 AM, Charlie Derwent wrote: On Sun, Jan 12, 2014 at 11:01 PM, Dmitri Pal d...@redhat.com wrote: On 01/11/2014 09:20 AM, Charlie Derwent wrote: Hi I'm experiencing an issue trying to use ipa-getcert on my IPA clients. When I run a command similar to this ipa-getcert request -K principal/`hostname` -D `hostname` \ -k /var/lib/ssl/private_keys/`hostname`.pem \ -f /var/lib/ssl/certs/`hostname`.pem Sometimes it will work, but 9 times out of 10 an ipa-getcert list will show the request failed with a status of CA_UNREACHABLE. I'm fairly certain it's not a time related issue as I tend to run the command just after enrolment and our NTP servers are rock solid. Now please correct me if I'm wrong (because it feels like I am wrong) but I think this is happening because not all of my replicas are Certificate Authorities but the clients are still trying to validate their certificate signing requests with them. Am I mistaken? Have I misconfigured something? If my theory is correct is there a way to force the client to only talk to the replica(s) running the CA service for these types of tasks? Anyway to try and get round the issue I decided to try and make all my IPA replicas Certificate Authorities and ran into the issue linked below Bug 905064 - ipa install error Unable to find preop.pin https://bugzilla.redhat.com/show_bug.cgi?id=905064 This has stopped me from rolling out the CA functionality across all of my replicas (and I almost trashed a replica in the process of trying to work around it). I'm not really bothered which way I go about solving the problem but would really appreciate some assistance as it feels like I'm stuck between a rock and a hard place. Thanks, Charlie ___ Freeipa-users mailing listFreeipa-users@redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users Even if the replica does not have CA it has code to turn around and proxy request to the corresponding replica that has CA. The first thing to check is the logs on the certmonger side that does the certificate request to see which replica it is trying to connect and httpd logs from the replica it tries to hit. If the requests do not hit (which I suspect the case since the client returned CA_UNREACHABLE) then it might be a firewall issue between the client and the replica. If it hits the server but server fails to proxy and returns CA_UNREACHABLE to the client then it is probably a FW issue between replicas. At least this is where I would dig. Also the bug you mentioned is a race condition and seems like a rare one so there is a chance it would not happen all the time if you try more than once or may be choose a different system. Do you hit every time you try? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs?www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Thanks for the tips regarding the CA authorization chain I'll try to take a closer log at the logs now I know what I'm looking for. Regarding the replica CA setup, once the installation failed the first time I didn't get another chance. No matter what I did the replica was convinced there was another CA already installed. I even resorted to uninstalling the replica completely by running ipa-setup-install --uninstall a few times consecutively to make sure everything was gone but whenever I tried to re-install adding the --setup-ca option it didn't work. I assumed there was a file or a service I had to stop or remove to get it going again so when I found this bug here https://bugzilla.redhat.com/show_bug.cgi?id=953488 I followed Tomas' steps in comment 4, not all the paths were the same (differences between IPA 3.0.0 and 3.2.0 I assume) but still no success. In the end dropping the --setup-ca option and reinstalling got me back to where I had left off. Was there a file/service I missed? I appreciate the help. Thanks Charlie It is hard to tell what went wrong without logs from ipareplica-install.log or PKI. But I would guess that the failed PKI instance is still here and not being uninstalled by IPA uninstaller. Tomas' instructions were for Dogtag 10 based CA, while you seem to use Dogtag 9. You can try uninstalling the Dogtag 9 based CA instance with following command run on the replica with broken CA (if it is still there): # /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force If that does not help, we would need the logs to continue investigating. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo rule processing order
Martin,
Sorry for the late reply.
Thanks for spotting this. I suspect I cannot just change ldap in our IPA.
This is part of a production environment consisting solely of supported
RHEL 6.4 servers. I can snapshot the IPA servers (they are VM's) to be able
to roll back in case of trouble, but I am not sure such a change is
supported.
Fred
On Fri, Jan 10, 2014 at 5:28 PM, Martin Kosek mko...@redhat.com wrote:
Ah, I think I found the root cause. Our sudoers compat tree configuration
missed out the sudoOrder attribute. The order was thus missing in LDAP
sudoers
and thus ineffective. I filed an upstream ticket to fix it:
https://fedorahosted.org/freeipa/ticket/4107
However, to hotfix it in your environment, could you try manually fixing
the
configuration on your FreeIPA server?
$ ldapmodify -h `hostname` -D cn=Directory Manager -x -W
dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: sudoOrder=%{sudoOrder}
This should do the trick.
Martin
On 01/10/2014 05:17 PM, Martin Kosek wrote:
On 01/10/2014 04:52 PM, Fred van Zwieten wrote:
Yes, you would expect that to help, wouldn't you :-)
Yes, I would :-)
Didn't even know this existed. Thanks for that.
User has 3 sudo rules. I have set the allow_all rule to 1, the second
rule
to 2 and the cobbler (with the !authenticate option) rule to 99:
What is the version of the SUDO on your system? According to
http://www.sudo.ws/sudoers.ldap.man.html
it was implemented in SUDO 1.7.5.
Martin
User may run the following commands on this host:
(root) ALL
(root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls,
/bin/more,
/usr/bin/less, !/bin/su
(root) NOPASSWD: /usr/bin/cobbler
(root) !/bin/su
Nope. Didn't help.
Fred
On Fri, Jan 10, 2014 at 3:59 PM, Martin Kosek mko...@redhat.com
wrote:
On 01/10/2014 11:52 AM, Fred van Zwieten wrote:
Hi,
I have a sudo rule in IPA that has the !authenticate option added to
enable
admins to execute certain programs as root without authentication.
It doesn't work. There is another rule for the admins that allow all
commands as long as they give their password.
In a sudoers file, you can solve this by specifing the nopasswd rule
as
last.
sudo -l from an IPA-client gives me this:
***@svr001 ~]$ sudo -l
Matching Defaults entries for *** on this host:
requiretty, !visiblepw, always_set_home, env_reset,
env_keep=COLORS
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS,
env_keep+=MAIL
PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE,
env_keep+=LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES,
env_keep+=LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME
LC_ALL
LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY,
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User may run the following commands on this host:
(root) NOPASSWD: ALL
(root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls,
/bin/more,
/usr/bin/less, !/bin/su
(root) NOPASSWD: /usr/bin/cobbler
(root) !/bin/su
I want the cobbler command to run without password authentication.
What
am
I doing wrong?
Would setting SUDO rule order help?
# ipa sudorule-mod -h
...
--order=INT integer to order the Sudo rules
...
Martin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Certificate system unavailable
Hi, I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the IPA WEBUI on any of the IPA servers says Certificate format error: [Errno -8015] error (-8015) unknown. I also notice that hosts says the certificate system is unavailable. certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). Looking at the pki-ca logs on the ipa servers I see that some selftest failed: # tail -100 selftests.log 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! the pki-cad service is running and pki-cad status displays the ports available. /etc/init.d/pki-cad status pki-ca (pid 28697) is running... [ OK ] My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 of the IPA servers has failed, and the current certificate is expiring the 19th of January, under a week from now. Do you have any suggestions to where I can start troubleshootng this issue? Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] About Freeipa
Hi there, We have a working authentication system for GNU/Linux consisting in a Mit Kerberos Server, and an OpenLDAP directory with a particular structure. I was wondering if we could use Freeipa to administer those working components as they are, without having to deploy a new Freeipa server from scratch. Thanks, tizo ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] About Freeipa
On Mon, 13 Jan 2014, tizo wrote: Hi there, We have a working authentication system for GNU/Linux consisting in a Mit Kerberos Server, and an OpenLDAP directory with a particular structure. I was wondering if we could use Freeipa to administer those working components as they are, without having to deploy a new Freeipa server from scratch. In short, no, it is not possible. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate system unavailable
Sigbjorn Lie wrote: Hi, I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the IPA WEBUI on any of the IPA servers says Certificate format error: [Errno -8015] error (-8015) unknown. I also notice that hosts says the certificate system is unavailable. certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). Looking at the pki-ca logs on the ipa servers I see that some selftest failed: # tail -100 selftests.log 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! the pki-cad service is running and pki-cad status displays the ports available. /etc/init.d/pki-cad status pki-ca (pid 28697) is running... [ OK ] My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 of the IPA servers has failed, and the current certificate is expiring the 19th of January, under a week from now. Do you have any suggestions to where I can start troubleshootng this issue? Check the trust on the audit certificate: # certutil -L -d /var/lib/pki-ca/alias/ ... auditSigningCert cert-pki-ca u,u,Pu If the trust is not u,u,Pu then you can fix it with: # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -t u,u,Pu Then restart the CA and it should be ok. What is the status on the failed certmonger requests? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Sudo rule processing order
Ok, that's up to your preference.
The hotfix below worked for me in my test environment and is pretty low risk.
But of course, it is not RHEL rubber stamped. Eventually, you can evaluate
the fix yourself in a test environment.
HTH,
Martin
On 01/13/2014 02:41 PM, Fred van Zwieten wrote:
Martin,
Sorry for the late reply.
Thanks for spotting this. I suspect I cannot just change ldap in our IPA.
This is part of a production environment consisting solely of supported
RHEL 6.4 servers. I can snapshot the IPA servers (they are VM's) to be able
to roll back in case of trouble, but I am not sure such a change is
supported.
Fred
On Fri, Jan 10, 2014 at 5:28 PM, Martin Kosek mko...@redhat.com wrote:
Ah, I think I found the root cause. Our sudoers compat tree configuration
missed out the sudoOrder attribute. The order was thus missing in LDAP
sudoers
and thus ineffective. I filed an upstream ticket to fix it:
https://fedorahosted.org/freeipa/ticket/4107
However, to hotfix it in your environment, could you try manually fixing
the
configuration on your FreeIPA server?
$ ldapmodify -h `hostname` -D cn=Directory Manager -x -W
dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: sudoOrder=%{sudoOrder}
This should do the trick.
Martin
On 01/10/2014 05:17 PM, Martin Kosek wrote:
On 01/10/2014 04:52 PM, Fred van Zwieten wrote:
Yes, you would expect that to help, wouldn't you :-)
Yes, I would :-)
Didn't even know this existed. Thanks for that.
User has 3 sudo rules. I have set the allow_all rule to 1, the second
rule
to 2 and the cobbler (with the !authenticate option) rule to 99:
What is the version of the SUDO on your system? According to
http://www.sudo.ws/sudoers.ldap.man.html
it was implemented in SUDO 1.7.5.
Martin
User may run the following commands on this host:
(root) ALL
(root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls,
/bin/more,
/usr/bin/less, !/bin/su
(root) NOPASSWD: /usr/bin/cobbler
(root) !/bin/su
Nope. Didn't help.
Fred
On Fri, Jan 10, 2014 at 3:59 PM, Martin Kosek mko...@redhat.com
wrote:
On 01/10/2014 11:52 AM, Fred van Zwieten wrote:
Hi,
I have a sudo rule in IPA that has the !authenticate option added to
enable
admins to execute certain programs as root without authentication.
It doesn't work. There is another rule for the admins that allow all
commands as long as they give their password.
In a sudoers file, you can solve this by specifing the nopasswd rule
as
last.
sudo -l from an IPA-client gives me this:
***@svr001 ~]$ sudo -l
Matching Defaults entries for *** on this host:
requiretty, !visiblepw, always_set_home, env_reset,
env_keep=COLORS
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS,
env_keep+=MAIL
PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE,
env_keep+=LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES,
env_keep+=LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE, env_keep+=LC_TIME
LC_ALL
LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY,
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User may run the following commands on this host:
(root) NOPASSWD: ALL
(root) /bin/cat, /bin/egrep, /bin/find, /bin/grep, /bin/ls,
/bin/more,
/usr/bin/less, !/bin/su
(root) NOPASSWD: /usr/bin/cobbler
(root) !/bin/su
I want the cobbler command to run without password authentication.
What
am
I doing wrong?
Would setting SUDO rule order help?
# ipa sudorule-mod -h
...
--order=INT integer to order the Sudo rules
...
Martin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate system unavailable
On Mon, January 13, 2014 15:58, Rob Crittenden wrote: Sigbjorn Lie wrote: Hi, I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the IPA WEBUI on any of the IPA servers says Certificate format error: [Errno -8015] error (-8015) unknown. I also notice that hosts says the certificate system is unavailable. certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). Looking at the pki-ca logs on the ipa servers I see that some selftest failed: # tail -100 selftests.log 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! the pki-cad service is running and pki-cad status displays the ports available. /etc/init.d/pki-cad status pki-ca (pid 28697) is running... [ OK ] My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 of the IPA servers has failed, and the current certificate is expiring the 19th of January, under a week from now. Do you have any suggestions to where I can start troubleshootng this issue? Check the trust on the audit certificate: # certutil -L -d /var/lib/pki-ca/alias/ ... auditSigningCert cert-pki-ca u,u,Pu If the trust is not u,u,Pu then you can fix it with: # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -t u,u,Pu Then restart the CA and it should be ok. Looks like this certificate is expired. This is the same output on all 3 of the ipa servers. How can this be fixed? # certutil -L -d /var/lib/pki-ca/alias/ -n auditSigningCert cert-pki-ca Certificate: Data: Version: 3 (0x2) Serial Number: 5 (0x5) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=DNS.DOMAIN Validity: Not Before: Thu Jan 19 19:44:24 2012 Not After : Wed Jan 08 19:44:24 2014 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Migration from OpenLDAP
On 13.1.2014 15:50, Alexander Bokovoy wrote: On Mon, 13 Jan 2014, tizo wrote: Hi there, We have a working authentication system for GNU/Linux consisting in a Mit Kerberos Server, and an OpenLDAP directory with a particular structure. I was wondering if we could use Freeipa to administer those working components as they are, without having to deploy a new Freeipa server from scratch. In short, no, it is not possible. I would like to elaborate this a bit more: You really can't use FreeIPA WebUI with home-grown LDAP+Kerberos system, but FreeIPA provides migrate-ds scripts which ease the transition from OpenLDAP. Please see http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Migrating_from_a_Directory_Server_to_IPA.html You need to migrate OpenLDAP data to one FreeIPA server and then you can simply create FreeIPA server replicas as need. In other words, the migrate-ds script is run only once even if you have multiple servers with replicated data. There are some limited capabilities for migration with user passwords, but I will let other people to elaborate - this is not area of my expertise. Let us know if you need any assistance during migration. -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate system unavailable
Sigbjorn Lie wrote: On Mon, January 13, 2014 15:58, Rob Crittenden wrote: Sigbjorn Lie wrote: Hi, I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the IPA WEBUI on any of the IPA servers says Certificate format error: [Errno -8015] error (-8015) unknown. I also notice that hosts says the certificate system is unavailable. certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). Looking at the pki-ca logs on the ipa servers I see that some selftest failed: # tail -100 selftests.log 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! the pki-cad service is running and pki-cad status displays the ports available. /etc/init.d/pki-cad status pki-ca (pid 28697) is running... [ OK ] My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 of the IPA servers has failed, and the current certificate is expiring the 19th of January, under a week from now. Do you have any suggestions to where I can start troubleshootng this issue? Check the trust on the audit certificate: # certutil -L -d /var/lib/pki-ca/alias/ ... auditSigningCert cert-pki-ca u,u,Pu If the trust is not u,u,Pu then you can fix it with: # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -t u,u,Pu Then restart the CA and it should be ok. Looks like this certificate is expired. This is the same output on all 3 of the ipa servers. How can this be fixed? # certutil -L -d /var/lib/pki-ca/alias/ -n auditSigningCert cert-pki-ca Certificate: Data: Version: 3 (0x2) Serial Number: 5 (0x5) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=DNS.DOMAIN Validity: Not Before: Thu Jan 19 19:44:24 2012 Not After : Wed Jan 08 19:44:24 2014 Go back in time to the 7th or 8th and run: # getcert resubmit -d /var/lib/pki-ca/alias -n auditSigningCert cert-pki-ca There may be other certs in a similar situation. getcert list will show you. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate system unavailable
On Mon, January 13, 2014 16:34, Rob Crittenden wrote: Sigbjorn Lie wrote: On Mon, January 13, 2014 15:58, Rob Crittenden wrote: Sigbjorn Lie wrote: Hi, I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the IPA WEBUI on any of the IPA servers says Certificate format error: [Errno -8015] error (-8015) unknown. I also notice that hosts says the certificate system is unavailable. certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). Looking at the pki-ca logs on the ipa servers I see that some selftest failed: # tail -100 selftests.log 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! the pki-cad service is running and pki-cad status displays the ports available. /etc/init.d/pki-cad status pki-ca (pid 28697) is running... [ OK ] My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 of the IPA servers has failed, and the current certificate is expiring the 19th of January, under a week from now. Do you have any suggestions to where I can start troubleshootng this issue? Check the trust on the audit certificate: # certutil -L -d /var/lib/pki-ca/alias/ ... auditSigningCert cert-pki-ca u,u,Pu If the trust is not u,u,Pu then you can fix it with: # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -t u,u,Pu Then restart the CA and it should be ok. Looks like this certificate is expired. This is the same output on all 3 of the ipa servers. How can this be fixed? # certutil -L -d /var/lib/pki-ca/alias/ -n auditSigningCert cert-pki-ca Certificate: Data: Version: 3 (0x2) Serial Number: 5 (0x5) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=DNS.DOMAIN Validity: Not Before: Thu Jan 19 19:44:24 2012 Not After : Wed Jan 08 19:44:24 2014 Go back in time to the 7th or 8th and run: # getcert resubmit -d /var/lib/pki-ca/alias -n auditSigningCert cert-pki-ca There may be other certs in a similar situation. getcert list will show you. Ouch. That would be rather disruptive I suppose. There is quite a lot of activity going to this server, not to mention it's the primary ntp and dns server for the network. Do you suppose this todo list will work ? Firewall off the rest of the network, leaving the ipa server alone Stop ntpd Set date to 8th of January Run the getcert resubmit command. Change date back to correct date Start ntpd Remove the firewall rules How many of the services is required to be restarted for the renewal to work after the date is changed to the 7th? Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate system unavailable
Hi, Thank you for your prompt reply Rob. On Mon, January 13, 2014 15:58, Rob Crittenden wrote: Sigbjorn Lie wrote: Hi, I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the IPA WEBUI on any of the IPA servers says Certificate format error: [Errno -8015] error (-8015) unknown. I also notice that hosts says the certificate system is unavailable. certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). Looking at the pki-ca logs on the ipa servers I see that some selftest failed: # tail -100 selftests.log 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! the pki-cad service is running and pki-cad status displays the ports available. /etc/init.d/pki-cad status pki-ca (pid 28697) is running... [ OK ] My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 of the IPA servers has failed, and the current certificate is expiring the 19th of January, under a week from now. Do you have any suggestions to where I can start troubleshootng this issue? Check the trust on the audit certificate: # certutil -L -d /var/lib/pki-ca/alias/ ... auditSigningCert cert-pki-ca u,u,Pu All the 3 ipa servers return u,u,Pu for auditSigningCert # certutil -L -d /var/lib/pki-ca/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-caCTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-cau,u,u If the trust is not u,u,Pu then you can fix it with: # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -t u,u,Pu Then restart the CA and it should be ok. I have restarted the dirsrv for PKI-IPA, and the pki-cad service on all 3 IPA servers. What is the status on the failed certmonger requests? After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the request is now: Request ID '20120119194518': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DNS-DOMAIN subject: CN=ipa01.dns.domain,O=DNS-DOMAIN expires: 2014-01-19 19:45:18 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes However I cannot find the certificate that's expired? Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate system unavailable
On Mon, January 13, 2014 16:17, Rob Crittenden wrote: Sigbjorn Lie wrote: Hi, Thank you for your prompt reply Rob. On Mon, January 13, 2014 15:58, Rob Crittenden wrote: Sigbjorn Lie wrote: Hi, I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the IPA WEBUI on any of the IPA servers says Certificate format error: [Errno -8015] error (-8015) unknown. I also notice that hosts says the certificate system is unavailable. certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). Looking at the pki-ca logs on the ipa servers I see that some selftest failed: # tail -100 selftests.log 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! the pki-cad service is running and pki-cad status displays the ports available. /etc/init.d/pki-cad status pki-ca (pid 28697) is running... [ OK ] My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 of the IPA servers has failed, and the current certificate is expiring the 19th of January, under a week from now. Do you have any suggestions to where I can start troubleshootng this issue? Check the trust on the audit certificate: # certutil -L -d /var/lib/pki-ca/alias/ ... auditSigningCert cert-pki-ca u,u,Pu All the 3 ipa servers return u,u,Pu for auditSigningCert # certutil -L -d /var/lib/pki-ca/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-pki-caCTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u If the trust is not u,u,Pu then you can fix it with: # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -t u,u,Pu Then restart the CA and it should be ok. I have restarted the dirsrv for PKI-IPA, and the pki-cad service on all 3 IPA servers. What is the status on the failed certmonger requests? After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the request is now: Request ID '20120119194518': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DNS-DOMAIN subject: CN=ipa01.dns.domain,O=DNS-DOMAIN expires: 2014-01-19 19:45:18 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes However I cannot find the certificate that's expired? Can provide the output of getcert rather than ipa-getcert? It will show additional certificates that are issued/renewed outside of the IPA API. rob Sure, I'll send you the output in private so I don't have to remove the domain names. Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com
Re: [Freeipa-users] Certificate system unavailable
On Mon, Jan 13, 2014 at 04:07:16PM +0100, Sigbjorn Lie wrote: After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the request is now: Request ID '20120119194518': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DNS-DOMAIN subject: CN=ipa01.dns.domain,O=DNS-DOMAIN expires: 2014-01-19 19:45:18 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes However I cannot find the certificate that's expired? That error message was the one the IPA server received and then relayed back to certmonger, so I'd expect that the expired certificate is the agent certificate that IPA uses when connecting to the CA's agent interface. That's stored in the NSS database in /etc/httpd/alias, with nickname ipaCert. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate system unavailable
On 13/01/14 19:13, Nalin Dahyabhai wrote: On Mon, Jan 13, 2014 at 04:07:16PM +0100, Sigbjorn Lie wrote: After I restarted dirsrv, pki-cad and then the httpd on ipa01 the status of the request is now: Request ID '20120119194518': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://ipa01.dns.domain:443/ca/agent/ca/displayBySerial': [Errno -12269] (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired.). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-DNS-DOMAIN//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-DNS-DOMAIN',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DNS-DOMAIN subject: CN=ipa01.dns.domain,O=DNS-DOMAIN expires: 2014-01-19 19:45:18 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes However I cannot find the certificate that's expired? That error message was the one the IPA server received and then relayed back to certmonger, so I'd expect that the expired certificate is the agent certificate that IPA uses when connecting to the CA's agent interface. That's stored in the NSS database in /etc/httpd/alias, with nickname ipaCert. Yes, the ipaCert certificate in /etc/httpd/alias/ is expired. Actually all certificates in /var/lib/pki-ca/alias/ is expired too, they all expired at the same date, within minutes of each other. It looks like they are the original certificates issued when I installed IPA, when I look at the Not Before timestamp of the certificates. Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Manage records while primary IPA is down
This question is really about HA of FreeIPA. I've noticed that new records cannot be added on the replica server while the primary is down. Ideally these services should be always available even when the Primary server is down (for maintenance or other reasons). Is it possible to have another Primary server replicating with the first Primary or to use one of the Replica servers to manage records while the Primary server is down. Thanks Dimitar ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Manage records while primary IPA is down
Dimitar Georgievski wrote: This question is really about HA of FreeIPA. I've noticed that new records cannot be added on the replica server while the primary is down. Ideally these services should be always available even when the Primary server is down (for maintenance or other reasons). Is it possible to have another Primary server replicating with the first Primary or to use one of the Replica servers to manage records while the Primary server is down. All servers in IPA are equal masters, the only difference may be the services running on any given server (DNS and a CA). The exception is if a master runs out of DNA values or has never been used to add an entry that requires one and the original IPA master is down. An IPA server will request a DNA range the first time it needs one but doesn't get one until then. I'm guessing that is what happened. I believe IPA 3.3 added some options to ipa-replica-manage to be able to control the DNA configuration. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate system unavailable
Sigbjorn Lie wrote: On Mon, January 13, 2014 16:34, Rob Crittenden wrote: Sigbjorn Lie wrote: On Mon, January 13, 2014 15:58, Rob Crittenden wrote: Sigbjorn Lie wrote: Hi, I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the IPA WEBUI on any of the IPA servers says Certificate format error: [Errno -8015] error (-8015) unknown. I also notice that hosts says the certificate system is unavailable. certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). Looking at the pki-ca logs on the ipa servers I see that some selftest failed: # tail -100 selftests.log 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! the pki-cad service is running and pki-cad status displays the ports available. /etc/init.d/pki-cad status pki-ca (pid 28697) is running... [ OK ] My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 of the IPA servers has failed, and the current certificate is expiring the 19th of January, under a week from now. Do you have any suggestions to where I can start troubleshootng this issue? Check the trust on the audit certificate: # certutil -L -d /var/lib/pki-ca/alias/ ... auditSigningCert cert-pki-ca u,u,Pu If the trust is not u,u,Pu then you can fix it with: # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -t u,u,Pu Then restart the CA and it should be ok. Looks like this certificate is expired. This is the same output on all 3 of the ipa servers. How can this be fixed? # certutil -L -d /var/lib/pki-ca/alias/ -n auditSigningCert cert-pki-ca Certificate: Data: Version: 3 (0x2) Serial Number: 5 (0x5) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=DNS.DOMAIN Validity: Not Before: Thu Jan 19 19:44:24 2012 Not After : Wed Jan 08 19:44:24 2014 Go back in time to the 7th or 8th and run: # getcert resubmit -d /var/lib/pki-ca/alias -n auditSigningCert cert-pki-ca There may be other certs in a similar situation. getcert list will show you. Ouch. That would be rather disruptive I suppose. There is quite a lot of activity going to this server, not to mention it's the primary ntp and dns server for the network. Do you suppose this todo list will work ? Firewall off the rest of the network, leaving the ipa server alone Stop ntpd Set date to 8th of January Run the getcert resubmit command. Change date back to correct date Start ntpd Remove the firewall rules Looks good. I'd restart the certmonger service rather than resubmitting each individually. Be prepared for renewal to not succeed. For some reason it didn't on and before expiration time so whatever problem existed then likely still remains. So the question to ask is what will I do if renewal fails again? Nothing catastrophic will happen, but it will likely mean having to roll forward again, debug, roll back, try again, and perhaps more than once. It's hard to say w/o knowing why it failed in the first place. How many of the services is required to be restarted for the renewal to work after the date is changed to the 7th? The renewal itself should restart the required services. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Manage records while primary IPA is down
On 01/13/2014 01:33 PM, Rob Crittenden wrote: Dimitar Georgievski wrote: This question is really about HA of FreeIPA. I've noticed that new records cannot be added on the replica server while the primary is down. Ideally these services should be always available even when the Primary server is down (for maintenance or other reasons). Is it possible to have another Primary server replicating with the first Primary or to use one of the Replica servers to manage records while the Primary server is down. All servers in IPA are equal masters, the only difference may be the services running on any given server (DNS and a CA). The exception is if a master runs out of DNA values or has never been used to add an entry that requires one and the original IPA master is down. An IPA server will request a DNA range the first time it needs one but doesn't get one until then. I'm guessing that is what happened. I believe IPA 3.3 added some options to ipa-replica-manage to be able to control the DNA configuration. We might be talking about the entries that have certificates. Is this the case? If so the certificate operations are proxied to the server that has full CA but AFAIR there is not failover there and I vaguely recall that there was ticket filed to address this scenario. So which entries we are talking about? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Odd problem with SSSD and SSH keys
I've got a strange situation where some of my workstations are reporting difficulty when sshing to remote systems, but there's no pattern I can discern. One user's machine can't get to system A, but I can, though I can't ssh to his workstation directly. Here's the kind of thing I see when doing ssh -vvv: debug1: Server host key: RSA 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab debug3: load_hostkeys: loading entries for host "rs512" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: loaded 0 keys debug3: load_hostkeys: loading entries for host "rs512" from file "/var/lib/sss/pubconf/known_hosts" debug3: load_hostkeys: found key type RSA in file /var/lib/sss/pubconf/known_hosts:2 debug3: load_hostkeys: loaded 1 keys @@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone coudl be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending RSA key in /var/lib/sss/pubconf/known_hosts:2 RSA host key for zw131 has changed and you have requested strict checking. Host key verification failed. # We haven't changed the host key; the public key files are dated October 23 of last year. Our configuration files for SSSD and SSH are managed by Puppet, so they are consistent from system to system. That said, I did compare a system that could remote to rs512 to one that could not and found no differences. Here are the files: /etc/sssd/sssd.conf: [domain/spx.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = zw129.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 ldap_tls_cacert = /etc/ipa/ca.crt [domain/.spx.net] cache_credentials = True krb5_store_password_if_offline = True krb5_realm = FOO.NET ipa_domain = .foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt chpass_provider = ipa ipa_dyndns_update = True ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net dns_discovery_domain = .spx.net [sssd] services = nss, pam, ssh config_file_version = 2 domains = .spx.net, spx.net [nss] [pam] [sudo] [autofs] [ssh] Is there anything else relevant that I should be looking at? -- Bret Wortman http://damascusgrp.com/ http://about.me/wortmanbret smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Odd problem with SSSD and SSH keys
On 01/13/2014 02:44 PM, Bret Wortman wrote: They're definitely different. I deleted the one in the file, then tried again. It put the bad key back in the file. I blew the whole file away and the same thing happened. Where is this key coming from if not from IPA? Puppet? On 01/13/2014 02:36 PM, Rob Crittenden wrote: Bret Wortman wrote: I've got a strange situation where some of my workstations are reporting difficulty when sshing to remote systems, but there's no pattern I can discern. One user's machine can't get to system A, but I can, though I can't ssh to his workstation directly. Here's the kind of thing I see when doing ssh -vvv: debug1: Server host key: RSA 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab debug3: load_hostkeys: loading entries for host rs512 from file /root/.ssh/known_hosts debug3: load_hostkeys: loaded 0 keys debug3: load_hostkeys: loading entries for host rs512 from file /var/lib/sss/pubconf/known_hosts debug3: load_hostkeys: found key type RSA in file /var/lib/sss/pubconf/known_hosts:2 debug3: load_hostkeys: loaded 1 keys @@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone coudl be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending RSA key in /var/lib/sss/pubconf/known_hosts:2 RSA host key for zw131 has changed and you have requested strict checking. Host key verification failed. # We haven't changed the host key; the public key files are dated October 23 of last year. Our configuration files for SSSD and SSH are managed by Puppet, so they are consistent from system to system. That said, I did compare a system that could remote to rs512 to one that could not and found no differences. Here are the files: /etc/sssd/sssd.conf: [domain/spx.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = zw129.foo.net chpass_provider = ipa ipa_dyndns_update = True ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 ldap_tls_cacert = /etc/ipa/ca.crt [domain/.spx.net] cache_credentials = True krb5_store_password_if_offline = True krb5_realm = FOO.NET ipa_domain = .foo.net id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt chpass_provider = ipa ipa_dyndns_update = True ipa_server = 192.168.208.46, _srv_, 192.168.10.111, 192.168.8.49 ldap_netgroup_search_base = cn=ng,cn=compat,dc=foo,dc=net dns_discovery_domain = .spx.net [sssd] services = nss, pam, ssh config_file_version = 2 domains = .spx.net, spx.net [nss] [pam] [sudo] [autofs] [ssh] Is there anything else relevant that I should be looking at? You might compare the value of the key in IPA to what is in /var/lib/sss/pubconf/known_hosts rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Manage records while primary IPA is down
I was referring to user accounts, and I believe they require certificates. With the Primary IPA being down I was not able to create new user entries on the replica servers. Hopefully the CA fail-over requirement is addressed in a new release of FreeIPA. Thanks, Dimitar On Mon, Jan 13, 2014 at 1:36 PM, Dmitri Pal d...@redhat.com wrote: On 01/13/2014 01:33 PM, Rob Crittenden wrote: Dimitar Georgievski wrote: This question is really about HA of FreeIPA. I've noticed that new records cannot be added on the replica server while the primary is down. Ideally these services should be always available even when the Primary server is down (for maintenance or other reasons). Is it possible to have another Primary server replicating with the first Primary or to use one of the Replica servers to manage records while the Primary server is down. All servers in IPA are equal masters, the only difference may be the services running on any given server (DNS and a CA). The exception is if a master runs out of DNA values or has never been used to add an entry that requires one and the original IPA master is down. An IPA server will request a DNA range the first time it needs one but doesn't get one until then. I'm guessing that is what happened. I believe IPA 3.3 added some options to ipa-replica-manage to be able to control the DNA configuration. We might be talking about the entries that have certificates. Is this the case? If so the certificate operations are proxied to the server that has full CA but AFAIR there is not failover there and I vaguely recall that there was ticket filed to address this scenario. So which entries we are talking about? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Manage records while primary IPA is down
On 01/13/2014 03:01 PM, Dimitar Georgievski wrote: I was referring to user accounts, and I believe they require certificates. With the Primary IPA being down I was not able to create new user entries on the replica servers. Hm? What kind of error you get? What does HTTP log shows on the replica you are performing operation against? User accounts have a certificate attribute but it is not used yet so it might be something else not related to certificates. Answers to the questions above would help. Also here are some hints that might be helpful in collecting and preparing information for our analysis: http://www.freeipa.org/page/Troubleshooting Hopefully the CA fail-over requirement is addressed in a new release of FreeIPA. Thanks, Dimitar On Mon, Jan 13, 2014 at 1:36 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 01/13/2014 01:33 PM, Rob Crittenden wrote: Dimitar Georgievski wrote: This question is really about HA of FreeIPA. I've noticed that new records cannot be added on the replica server while the primary is down. Ideally these services should be always available even when the Primary server is down (for maintenance or other reasons). Is it possible to have another Primary server replicating with the first Primary or to use one of the Replica servers to manage records while the Primary server is down. All servers in IPA are equal masters, the only difference may be the services running on any given server (DNS and a CA). The exception is if a master runs out of DNA values or has never been used to add an entry that requires one and the original IPA master is down. An IPA server will request a DNA range the first time it needs one but doesn't get one until then. I'm guessing that is what happened. I believe IPA 3.3 added some options to ipa-replica-manage to be able to control the DNA configuration. We might be talking about the entries that have certificates. Is this the case? If so the certificate operations are proxied to the server that has full CA but AFAIR there is not failover there and I vaguely recall that there was ticket filed to address this scenario. So which entries we are talking about? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Odd problem with SSSD and SSH keys
On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote: They're definitely different. I deleted the one in the file, then tried again. It put the bad key back in the file. I blew the whole file away and the same thing happened. Where is this key coming from if not from IPA? Can you try running sss_ssh_knownhostsproxy manually to see what key does it return? The keys are propagated to the file from the sssd database. If the client was offline, the client could use stale records. Can you verify the client has no connectivity issues? Honza (CC-ed) might have some more hints. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificate system unavailable
On 13/01/14 19:37, Rob Crittenden wrote: Sigbjorn Lie wrote: On Mon, January 13, 2014 16:34, Rob Crittenden wrote: Sigbjorn Lie wrote: On Mon, January 13, 2014 15:58, Rob Crittenden wrote: Sigbjorn Lie wrote: Hi, I seem to have issues with the certificate system on my IPA installation. Looking up hosts in the IPA WEBUI on any of the IPA servers says Certificate format error: [Errno -8015] error (-8015) unknown. I also notice that hosts says the certificate system is unavailable. certmonger: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Failure decoding Certificate Signing Request). Looking at the pki-ca logs on the ipa servers I see that some selftest failed: # tail -100 selftests.log 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Initializing self test plugins: 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin logger parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instances 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading all self test plugin instance parameters 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in on-demand order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: loading self test plugins in startup order 28697.main - [13/Jan/2014:15:06:33 CET] [20] [1] SelfTestSubsystem: Self test plugins have been successfully loaded! 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: Running self test plugins specified to be executed at startup: 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] CAPresence: CA is present 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SystemCertsVerification: system certs verification failure 28697.main - [13/Jan/2014:15:06:34 CET] [20] [1] SelfTestSubsystem: The CRITICAL self test plugin called selftests.container.instance.SystemCertsVerification running at startup FAILED! the pki-cad service is running and pki-cad status displays the ports available. /etc/init.d/pki-cad status pki-ca (pid 28697) is running... [ OK ] My main consern is that the certmonger requests for renew of certificates for LDAP on 2 out of 3 of the IPA servers has failed, and the current certificate is expiring the 19th of January, under a week from now. Do you have any suggestions to where I can start troubleshootng this issue? Check the trust on the audit certificate: # certutil -L -d /var/lib/pki-ca/alias/ ... auditSigningCert cert-pki-ca u,u,Pu If the trust is not u,u,Pu then you can fix it with: # certutil -M -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -t u,u,Pu Then restart the CA and it should be ok. Looks like this certificate is expired. This is the same output on all 3 of the ipa servers. How can this be fixed? # certutil -L -d /var/lib/pki-ca/alias/ -n auditSigningCert cert-pki-ca Certificate: Data: Version: 3 (0x2) Serial Number: 5 (0x5) Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=DNS.DOMAIN Validity: Not Before: Thu Jan 19 19:44:24 2012 Not After : Wed Jan 08 19:44:24 2014 Go back in time to the 7th or 8th and run: # getcert resubmit -d /var/lib/pki-ca/alias -n auditSigningCert cert-pki-ca There may be other certs in a similar situation. getcert list will show you. Ouch. That would be rather disruptive I suppose. There is quite a lot of activity going to this server, not to mention it's the primary ntp and dns server for the network. Do you suppose this todo list will work ? Firewall off the rest of the network, leaving the ipa server alone Stop ntpd Set date to 8th of January Run the getcert resubmit command. Change date back to correct date Start ntpd Remove the firewall rules Looks good. I'd restart the certmonger service rather than resubmitting each individually. Be prepared for renewal to not succeed. For some reason it didn't on and before expiration time so whatever problem existed then likely still remains. So the question to ask is what will I do if renewal fails again? Nothing catastrophic will happen, but it will likely mean having to roll forward again, debug, roll back, try again, and perhaps more than once. It's hard to say w/o knowing why it failed in the first place. How many of the services is required to be restarted for the renewal to work after the date is changed to the 7th? The renewal itself should restart the required services. This worked better than expected. Thank you! :) ipa01 and ipa02 seem to be happy again, getcert list no longer displays any certificates out of date, and all certificates in need of renewal within 28 days has been renewed. The webui also started working again and things seem to be
[Freeipa-users] Keberos and LDAP password
I'm very new to IPA. I run a ODSEE and I need to add in krb5. ODSEE allows us to store the KRB5 data in ldap, but there is no easy means of keeping the LDAP and Kerberos password in sync for a given account. I understand that IPA supplies Kerberos services. But is the krb5 password the same password that a LDAP bind would use. Meaning I have many applications that can not use Kerberos, but can use LDAP. Can these applications use IPA and expect that a given user account will have the LDAP password kept in sync with the krb5 password? thanks, Bob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Keberos and LDAP password
From what I understand I use currently... You can use just LDAP...I'm currently using LDAP/KRB where supported...and just straight LDAP on applications that don't support KRB Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christi...@4over.com mailto:christi...@4over.com www.4over.com http://www.4over.com On Mon, Jan 13, 2014 at 2:04 PM, Bob harv...@gmail.com wrote: I'm very new to IPA. I run a ODSEE and I need to add in krb5. ODSEE allows us to store the KRB5 data in ldap, but there is no easy means of keeping the LDAP and Kerberos password in sync for a given account. I understand that IPA supplies Kerberos services. But is the krb5 password the same password that a LDAP bind would use. Meaning I have many applications that can not use Kerberos, but can use LDAP. Can these applications use IPA and expect that a given user account will have the LDAP password kept in sync with the krb5 password? thanks, Bob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Keberos and LDAP password
On 01/13/2014 05:04 PM, Bob wrote: I'm very new to IPA. I run a ODSEE and I need to add in krb5. ODSEE allows us to store the KRB5 data in ldap, but there is no easy means of keeping the LDAP and Kerberos password in sync for a given account. I understand that IPA supplies Kerberos services. But is the krb5 password the same password that a LDAP bind would use. Meaning I have many applications that can not use Kerberos, but can use LDAP. Can these applications use IPA and expect that a given user account will have the LDAP password kept in sync with the krb5 password? Yes. It is the same. You can use IPA with Kerberos and/or LDAP clients. thanks, Bob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] One way trusts
Hello, I manage a suite of machines and services which are used for collaborative projects with external partners. I want to allow users within our organization to authenticate with their existing Active Directory accounts, and I have set up an External Users LDAP directory to establish identities for our partners. I have an LDAP server set up which merges the two directories and which forwards requests on to the correct directory. I like the idea of FreeIPA, however, I need support for a one-way trust. I don't have the ability to modify any entries in our AD server, but I do have a normal user account (hence I can bind to AD's LDAP interface). However, I think this is kind of a moot point since external users should under no circumstances be allowed access to our internal network/services. Read-only access to AD is just peachy. I found this old message (June 2012) on your mailing list which suggests one-way trusts may be on your radar. [1] However, I looked through your Trac tickets and didn't see any follow up. Did I miss something? Is this already implemented, or are plans in place? Thanks much, Bryce [1] https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] One way trusts
On 01/13/2014 06:29 PM, Nordgren, Bryce L -FS wrote: Hello, I manage a suite of machines and services which are used for collaborative projects with external partners. I want to allow users within our organization to authenticate with their existing Active Directory accounts, and I have set up an External Users LDAP directory to establish identities for our partners. I have an LDAP server set up which merges the two directories and which forwards requests on to the correct directory. I like the idea of FreeIPA, however, I need support for a one-way trust. I don't have the ability to modify any entries in our AD server, but I do have a normal user account (hence I can bind to AD's LDAP interface). However, I think this is kind of a moot point since external users should under no circumstances be allowed access to our internal network/services. Read-only access to AD is just peachy. I found this old message (June 2012) on your mailing list which suggests one-way trusts may be on your radar. [1] However, I looked through your Trac tickets and didn't see any follow up. Did I miss something? Is this already implemented, or are plans in place? Just to be sure I understand. You have internal users - they are in AD. You have external users - they are in LDAP. You merge two directories and you want to replace this setup with IPA. IPA can trust AD. Formally it is a mutual trust but in reality IPA does not have global catalog support for users in IPA to be able to access the resources in AD. So it is one way trust due to limited functionality. The global catalog support is being worked on. As soon as it is implemented we will add more granularity to the way the trusts are established and thus allow formal one way trusts. It seems that to support your use case you would need to make the external users be IPA users and make AD and IPA trust each other. Also if external users do not authenticate using Kerberos (for example they always use a special portal) then it does not matter what trust is between AD and IPA because those users will not have kerberos tickets that are leveraged in SSO in trust case. HTH. Thanks much, Bryce [1] https://www.redhat.com/archives/freeipa-users/2012-June/msg00206.html This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] One way trusts
Hi Dimitri, Just to be sure I understand. You have internal users - they are in AD. You have external users - they are in LDAP. You merge two directories and you want to replace this setup with IPA. Yes. It seems that to support your use case you would need to make the external users be IPA users and make AD and IPA trust each other. I think I concur about migrating my external users into IPA and making IPA trust AD. I may be ignorant of some AD nuance, but I do not see why AD needs to trust IPA. AD does not need to trust my LDAP clients currently. Also if external users do not authenticate using Kerberos (for example they always use a special portal) then it does not matter what trust is between AD and IPA because those users will not have kerberos tickets that are leveraged in SSO in trust case. I want to be able to point either an LDAP or a Kerberos client at IPA, and have it authenticate my enterprise and external users for me. I'm not going to tangle with SSO at the moment. Right now, we're just establishing an identity store. IPA can trust AD. Formally it is a mutual trust but in reality IPA does not have global catalog support for users in IPA to be able to access the resources in AD. In many of the tutorials/HOWTOs, I see that there is a requirement to provide credentials having the permission to add a computer to the domain, or being a member of an AD administration group. I'm a lowly standard User in the AD. I don't know if that means I can add a computer to the domain or not. I know I lack the ability to edit AD entries that aren't mine, so I really need a solution that does not require creating a trust relationship inside AD. Is there a way for me to comment out the AD-IPA trust creation, or would that break the IPA-AD trust? Thanks much, Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] FreeIPA and abfab?
In my previous message, I asked about one-way trust with AD to provide a means of extending our corporate AD with accounts for external cooperators. I expect this is just a technical matter: either FreeIPA supports it or not, and there's no conceptual obstacles. So, my password is the same, and everyone else needs a new account. Not ideal, but it's achievable fairly easily with existing tools. But what I really really want is an identity provider for the edge of the enterprise, where I live. My password is the same and external users can also use their normal password. Essentially, I want a software suite which interfaces between the enterprise environment where everything is centrally managed, and a federated environment where there are too many organizations to shake a stick at. I've been reading about Application Bridging for Federated Access Beyond Web (abfab). https://datatracker.ietf.org/wg/abfab/ It appears to me that the draft architecture document and the recently published RFCs (7055, 7056, 7057) defines a mechanism for enterprises to federate and opens up a whole new application space. The big question is, should enterprise-centric management apps expand to include federation, or will a whole new crop of solutions pop up? Or, more pointedly, could this gap be filled by augmenting an enterprise's existing AD deployment with a federation-aware FreeIPA? Has FreeIPA considered moving into this space? I can see several areas where a federation aware, AD compatible solution could add value to an organization: Use case 1: Synchronizing enterprise IDs with IDs exposed to the federation. (Currently, we have AD credentials and SAML credentials, and they are not synched. And our SAML IdP does not participate in a federation.) Use case 2: Software can use SAML credentials for workstation logins (if the workstations are on the research net); and allow only internal users to use internal services. Use case 3: Software provides access to internal + federated identities using LDAP, SAML, Kerberos, etc. Food for thought. I know this isn't near term, but at this point, I'm just curious if people are even thinking along these lines? Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
Been banging my head against the wall on this one for a few days, trying to get a workable configuration for HP ILO to authenticate via FreeIPA. I have a standard rhel6 environment (64 bit 6.4) with freeipa server (ipa-3.0.0-37.el6). The following works for me.. HP ILO4 Firmware 1.22 Default Directory Schema Directory Server Address: fqdn_of_myfreeipaserver Directory Server LDAP Port: 636 Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com but only if I login with my full dn Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com The test settings button in the ILO works only with the full dn. It doesn't work if I use the uid (less), or the cn (Les Stott). I can then login to ILO with Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com If I try to login with the cn, Les Stott I see an error in the logs... [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, line 473]: Failed to retrieve entry CN=Les Stott,cn=users,cn=accounts,dc=mydomain,dc=com: 32 I've read a lot of things about getting this to work. Apparently there are issues with HP ILO requiring the username in cn format but its in uid format in freeipa. You should also be able to login with your cn, but that doesn't work. I had a crack at trying Kerberos authentication as well, but it doesn't work and errors with Additional Pre-authentication required. Has anyone successfully been able to get HP ILO to work with FreeIPA such that you can login with just the username (i.e. less) or the CN (i.e. Les Stott)? Are schema changes required? Alternatively has anyone been able to get HP ILO to work with Kerberos auth to FreeIPA? Any help would be greatly appreciated. Regards, Les ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA and abfab?
On Tue, 14 Jan 2014, Nordgren, Bryce L -FS wrote: In my previous message, I asked about one-way trust with AD to provide a means of extending our corporate AD with accounts for external cooperators. I expect this is just a technical matter: either FreeIPA supports it or not, and there's no conceptual obstacles. So, my password is the same, and everyone else needs a new account. Not ideal, but it's achievable fairly easily with existing tools. But what I really really want is an identity provider for the edge of the enterprise, where I live. My password is the same and external users can also use their normal password. Essentially, I want a software suite which interfaces between the enterprise environment where everything is centrally managed, and a federated environment where there are too many organizations to shake a stick at. I've been reading about Application Bridging for Federated Access Beyond Web (abfab). https://datatracker.ietf.org/wg/abfab/ It appears to me that the draft architecture document and the recently published RFCs (7055, 7056, 7057) defines a mechanism for enterprises to federate and opens up a whole new application space. The big question is, should enterprise-centric management apps expand to include federation, or will a whole new crop of solutions pop up? Or, more pointedly, could this gap be filled by augmenting an enterprise's existing AD deployment with a federation-aware FreeIPA? Has FreeIPA considered moving into this space? I can see several areas where a federation aware, AD compatible solution could add value to an organization: Use case 1: Synchronizing enterprise IDs with IDs exposed to the federation. (Currently, we have AD credentials and SAML credentials, and they are not synched. And our SAML IdP does not participate in a federation.) Use case 2: Software can use SAML credentials for workstation logins (if the workstations are on the research net); and allow only internal users to use internal services. Use case 3: Software provides access to internal + federated identities using LDAP, SAML, Kerberos, etc. Food for thought. I know this isn't near term, but at this point, I'm just curious if people are even thinking along these lines? Yes, we do have plans on being able to bridge with SAML IdP. This work is not yet available for production use but we certainly are looking into making IPA identities available for consumption through SAML-assertions. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
