[Freeipa-users] IPA Server UI Behind Proxy
Hi, I've got my FreeIPA setup in an internal infrastructure, but I want to be able to have users access the web UI externally. I tweaked the ipa-rewrite.conf so it won't redirect me to the FQDN and then tried both a nginx reverse proxy and port forwarding, both works if the client manually sets the host name of the IPA server eg. ipa01.internaldomain.local in their /etc/hosts file. However if the client tries to to use eg. ipa.externaldomain.com with the same port forwarding or nginx proxy config, it'll silently error. The docs briefly touches on this - but doesn't really give much to go on. Any suggestions? Andrew . ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Server UI Behind Proxy
On Wed, 14 Aug 2013, Andrew Lau wrote: Hi, I've got my FreeIPA setup in an internal infrastructure, but I want to be able to have users access the web UI externally. I tweaked the ipa-rewrite.conf so it won't redirect me to the FQDN and then tried both a nginx reverse proxy and port forwarding, both works if the client manually sets the host name of the IPA server eg. ipa01.internaldomain.local in their /etc/hosts file. However if the client tries to to use eg. ipa.externaldomain.com with the same port forwarding or nginx proxy config, it'll silently error. The docs briefly touches on this - but doesn't really give much to go on. Any suggestions? Couple considerations here. First, you may need to play with debug level to see what principal mod_auth_kerb picks up when negotiation happens. Second, using Kerberos authentication requires both sides to own Kerberos principals for authentication process to go. Browsers select HTTP/server.fqdn as their target service principal when connection to the server.fqdn. Your IPA server only has HTTP/ipa01.internaldomain.local in its keytab in /etc/httpd/conf/ipa.keytab, which means it would only be able to respond on ipa01.internaldomain.local to Kerberos auth requests. A way to fix this is by making HTTP/ipa.externaldomain.com service in IPA (ipa service-add HTTP/ipa.externaldomain.com) and then use 'ipa-getkeytab' to fetch the keytab with the key for the service. Next step would be to merge content of this keytab with /etc/httpd/conf/ipa.keytab: (echo rkt /tmp/external.keytab; echo wkt /etc/httpd/conf/ipa.keytab) |ktutil Then restart httpd -- I'm not sure mod_auth_kerb re-reads the keytab on its change. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Server UI Behind Proxy
I followed your suggestions without much luck. Adding the kerberos keytab didn't change anything, when I try login through the UI it just redirects me again with the same notice: Your session has expired. Please re-login. However if I login with the incorrect details logs will show INFO: 401 Unauthorized: kinit: Client 'a...@domain.com' not found in Kerberos database while getting initial credentials and the UI will give me an error message. It seems when it's logged in with the correct credentials it's still finding itself lost. I have a feeling I'm overlooking something so simple.. Andrew On Wed, Aug 14, 2013 at 4:23 PM, Alexander Bokovoy aboko...@redhat.comwrote: On Wed, 14 Aug 2013, Andrew Lau wrote: Hi, I've got my FreeIPA setup in an internal infrastructure, but I want to be able to have users access the web UI externally. I tweaked the ipa-rewrite.conf so it won't redirect me to the FQDN and then tried both a nginx reverse proxy and port forwarding, both works if the client manually sets the host name of the IPA server eg. ipa01.internaldomain.local in their /etc/hosts file. However if the client tries to to use eg. ipa.externaldomain.com with the same port forwarding or nginx proxy config, it'll silently error. The docs briefly touches on this - but doesn't really give much to go on. Any suggestions? Couple considerations here. First, you may need to play with debug level to see what principal mod_auth_kerb picks up when negotiation happens. Second, using Kerberos authentication requires both sides to own Kerberos principals for authentication process to go. Browsers select HTTP/server.fqdn as their target service principal when connection to the server.fqdn. Your IPA server only has HTTP/ipa01.internaldomain.** local in its keytab in /etc/httpd/conf/ipa.keytab, which means it would only be able to respond on ipa01.internaldomain.local to Kerberos auth requests. A way to fix this is by making HTTP/ipa.externaldomain.com service in IPA (ipa service-add HTTP/ipa.externaldomain.com) and then use 'ipa-getkeytab' to fetch the keytab with the key for the service. Next step would be to merge content of this keytab with /etc/httpd/conf/ipa.keytab: (echo rkt /tmp/external.keytab; echo wkt /etc/httpd/conf/ipa.keytab) |ktutil Then restart httpd -- I'm not sure mod_auth_kerb re-reads the keytab on its change. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Server UI Behind Proxy
On 08/14/2013 08:00 AM, Andrew Lau wrote: Hi, I've got my FreeIPA setup in an internal infrastructure, but I want to be able to have users access the web UI externally. I tweaked the ipa-rewrite.conf so it won't redirect me to the FQDN and then tried both a nginx reverse proxy and port forwarding, both works if the client manually sets the host name of the IPA server eg. ipa01.internaldomain.local in their /etc/hosts file. However if the client tries to to use eg. ipa.externaldomain.com with the same port forwarding or nginx proxy config, it'll silently error. The docs briefly touches on this - but doesn't really give much to go on. Any suggestions? Andrew . Hi, FreeIPA RPC API, which Web UI uses, requires http referer header to start with 'https://ipa.server.hostname/ipa'. Given that you are using proxy, I assume that the referer is different and might be a cause of the issue. HTH -- Petr Vobornik ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Server UI Behind Proxy
Any suggestions or workaround, short of having to switch the IPA's hostname to use a public domain? Andrew On Wed, Aug 14, 2013 at 5:36 PM, Petr Vobornik pvobo...@redhat.com wrote: On 08/14/2013 08:00 AM, Andrew Lau wrote: Hi, I've got my FreeIPA setup in an internal infrastructure, but I want to be able to have users access the web UI externally. I tweaked the ipa-rewrite.conf so it won't redirect me to the FQDN and then tried both a nginx reverse proxy and port forwarding, both works if the client manually sets the host name of the IPA server eg. ipa01.internaldomain.local in their /etc/hosts file. However if the client tries to to use eg. ipa.externaldomain.com with the same port forwarding or nginx proxy config, it'll silently error. The docs briefly touches on this - but doesn't really give much to go on. Any suggestions? Andrew . Hi, FreeIPA RPC API, which Web UI uses, requires http referer header to start with 'https://ipa.server.hostname**/ipa'. Given that you are using proxy, I assume that the referer is different and might be a cause of the issue. HTH -- Petr Vobornik ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade failed -- how to recover?
Rob, I got past this, as you indicated, by doing that after first running: # ipa-ldap-updater --ldapi ./schema.update Using a schema.update tip file I found in a note from you after some hard core googling. Should that extra step have been necessary? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Tue, Aug 13, 2013 at 3:39 PM, Rob Crittenden rcrit...@redhat.com wrote: Bret Wortman wrote: I tried this, but no joy: # /usr/sbin/ipa-upgradeconfig --debug : : DEBUG: caSignedLogCert.cfg http://bl-1.com/click/load/**VWRaa1w-b0221U28CYQNlAT4-b0231http://bl-1.com/click/load/VWRaa1w-b0221U28CYQNlAT4-b0231 ** profile validity range is 720 INFO: [Certificate renewal should stop the CA] ERROR: Unable to find certmonger request ID for auditSigning Cert INFO: The ipa-upgradeconfig command was successful # Run getcert list and sift through the output and see if you have a request tracking for nickname auditSigningCert cert-pki-ca (or similar). But I still can't connect to http://ipamaster/ipa/ui/; I get a 903 error every time, and /var/log/httpd/error_log shows, in part: [Tue Aug 13 13:07:20.786566 2013] [:error] [pid 5890] KeyError: 'ipadnszone' [Tue Aug 13 13:07:20.786717 2013] [:error] [pid 5890] ipa: INFO: br...@foo.net mailto:br...@foo.net: json_metadata(None, None, object=u'all'): KeyError [Tue Aug 13 13:07:21.001525 2013] [:error] [pid 5890] ipa: INFO: br...@foo.net mailto:br...@foo.net: json_metadata(None, None, command=u'all'): SUCCESS DNS resolution, authentication and authorization all /appear/ to be working fine. The DNS schema was not updated properly. I'd run: # ipa-ldap-updater --upgrade rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa-users Digest, Vol 61, Issue 21
Aissa Brahimi wrote: Hi, I am having this issue: IPA server: CentOS6.x Host CentOS 5.x 2 different host and cannot join the IPA server: Here the 2 different output I got: There was a problem importing one of the required Python modules. The error was: No module named OpenSSL It is a missing dependency in the RHEL 5 client. yum install pyOpenSSL to fix it. and .. bash: ipa-client-install: command not found You either don't have the ipa-client package installed or /usr/sbin isn't in your path. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Restrict AD users from passwd
Hi All, Our current account management policy requires that users change their AD passwords via a special portal, however I've noticed that this can be bypassed by issuing passwd on a Linux system while logged in with AD credentials, thus changing their AD password. Any thoughts on the best way to prevent this action? What I've considered so far is removing the trust in AD, effectively creating a one-way trust, but that would limit functionality for future interoperability. Additionally, we could change the permissions for passwd on each Linux system, but this would be somewhat hackish and also complicated to enforce, since we're waiting on Foreman + Puppet to properly be integrated into Katello for our configuration management solution. Any way to restrict this via the FreeIPA UI? Thanks, Brian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade failed -- how to recover?
I believe you. I'm not upset at all that things go sideways every now and again. I'm surprised it doesn't happen more. Original failure (or, at least, first occurrence of ERROR) follows: 2013-08-13T13:56:07Z INFO [Setting up Firefox extension] 2013-08-13T13:56:07Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2013-08-13T13:56:07Z INFO /usr/share/ipa/html/krb.jshttp://bl-1.com/click/load/U2ILOlY2ADdTO1A9BDQ-b0231exists, skipping install of Firefox extension 2013-08-13T13:56:07Z INFO [Add missing CA DNS records] 2013-08-13T13:56:07Z ERROR Cannot connect to LDAP to add DNS records: cannot connect to u'ldapi://%2fvar%2frun%2fslapd-SPX-NET.socket': LDAP Server Down 2013-08-13T13:56:07Z INFO [Enabling persistent search in DNS] 2013-08-13T13:56:07Z DEBUG [Saving StateFile to '/var/lib/ipa/sysupgrade/sysupgrade.state' 2013-08-13T13:56:07Z DEBUG Persistent search enabled 2013-08-13T13:56:07Z DEBUG Connections set to 4 Then it goes on for a while, leading to: 2013-08-13T13:56:11Z DEBUG Process finished, return code=1 2013-08-13T13:56:11Z DEBUG stdout=Error connecting to DBus. Please verify that the message bus (D-Bus) service is running. 2013-08-13T13:56:11Z DEBUG stderr= 2013-08-13T13:56:11Z ERROR cretmonger failed to start tracking certificate: Command '/usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n auditSigningCert cert-pki-ca -c dogtag-ipa-retrieve-agent-submit -B /usr/lib64/ipa/certmonger/stop_pkicad -C /usr/lib64/ipa/certmonger/restart_pkicad auditSigningCert cert-pki-ca -P -T auditSigningCert cert-pki-ca' returned non-zero exit status 1 2013-08-13T13:56:11Z DEBUG Starting external process 2013-08-13T13:56:11Z DEBUG args=/usr/bin/certutil -L -d/var/lib/pki-ca/alias -n ocspSigningCert cert-pki-ca 2013-08-13T13:56:11Z DEBUG Process finished, return code=0 Does that help at all? Do you need more? I'm upgrading a slave today and will try just doing the --upgrade (_if_ the automatic upgrade has issues again). * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Aug 14, 2013 at 9:10 AM, Rob Crittenden rcrit...@redhat.com wrote: Bret Wortman wrote: Rob, I got past this, as you indicated, by doing that after first running: # ipa-ldap-updater --ldapi ./schema.update Using a schema.update tip file I found in a note from you after some hard core googling. Should that extra step have been necessary? No, it shouldn't be necessary. Can look in /var/log/ipaupgrade.log (likely humongous) for the original failure and post that section of the log? Updating schema is hard. We are actually completely revamping the way we handle schema changes between version which should be a lot more stable. rob _ _ *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Tue, Aug 13, 2013 at 3:39 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: I tried this, but no joy: # /usr/sbin/ipa-upgradeconfig --debug : : DEBUG: caSignedLogCert.cfg http://bl-1.com/click/load/__**VWRaa1w-b0221U28CYQNlAT4-b0231http://bl-1.com/click/load/__VWRaa1w-b0221U28CYQNlAT4-b0231 http://bl-1.com/click/load/**VWRaa1w-b0221U28CYQNlAT4-b0231http://bl-1.com/click/load/VWRaa1w-b0221U28CYQNlAT4-b0231 **__ profile validity range is 720 INFO: [Certificate renewal should stop the CA] ERROR: Unable to find certmonger request ID for auditSigning Cert INFO: The ipa-upgradeconfig command was successful # Run getcert list and sift through the output and see if you have a request tracking for nickname auditSigningCert cert-pki-ca (or similar). But I still can't connect to http://ipamaster/ipa/ui/; I get a 903 error every time, and /var/log/httpd/error_log shows, in part: [Tue Aug 13 13:07:20.786566 2013] [:error] [pid 5890] KeyError: 'ipadnszone' [Tue Aug 13 13:07:20.786717 2013] [:error] [pid 5890] ipa: INFO: br...@foo.net mailto:br...@foo.net mailto:br...@foo.net mailto:br...@foo.net: json_metadata(None, None, object=u'all'): KeyError [Tue Aug 13 13:07:21.001525 2013] [:error] [pid 5890] ipa: INFO: br...@foo.net mailto:br...@foo.net mailto:br...@foo.net mailto:br...@foo.net: json_metadata(None, None, command=u'all'): SUCCESS DNS resolution, authentication and authorization all /appear/ to be working fine. The DNS schema was not updated properly. I'd run: # ipa-ldap-updater --upgrade rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Restrict AD users from passwd
On Wed, Aug 14, 2013 at 09:19:17AM -0400, Brian Lee wrote: Hi All, Our current account management policy requires that users change their AD passwords via a special portal, however I've noticed that this can be bypassed by issuing passwd on a Linux system while logged in with AD credentials, thus changing their AD password. Any thoughts on the best way to prevent this action? What I've considered so far is removing the trust in AD, effectively creating a one-way trust, but that would limit functionality for future interoperability. Additionally, we could change the permissions for passwd on each Linux system, but this would be somewhat hackish and also complicated to enforce, since we're waiting on Foreman + Puppet to properly be integrated into Katello for our configuration management solution. Any way to restrict this via the FreeIPA UI? I think the only safe way to achieve this is to block port 464 on the AD servers for the Linux hosts. Because basically what passwd is doing here via SSSD is to change the Kerberos password. The same can be done with the kpasswd command, it does not require any privileges the user only needs to know his current password. So even if we add an option to force SSSD to reject password changes for users from trusted domains there are other ways for users to change the password which cannot be controlled by IPA. Please note that changing the AD password with kpasswd would even work without trust. HTH bye, Sumit Thanks, Brian ___ 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] Restrict AD users from passwd
Hi Sumit, Thanks for the suggestion. I'll have to give this some thought, since we have 100+ AD servers, this might not be well received by the AD team. If anyone can think of a better mousetrap than this, let me know. Thanks, Brian On Wed, Aug 14, 2013 at 9:37 AM, Sumit Bose sb...@redhat.com wrote: On Wed, Aug 14, 2013 at 09:19:17AM -0400, Brian Lee wrote: Hi All, Our current account management policy requires that users change their AD passwords via a special portal, however I've noticed that this can be bypassed by issuing passwd on a Linux system while logged in with AD credentials, thus changing their AD password. Any thoughts on the best way to prevent this action? What I've considered so far is removing the trust in AD, effectively creating a one-way trust, but that would limit functionality for future interoperability. Additionally, we could change the permissions for passwd on each Linux system, but this would be somewhat hackish and also complicated to enforce, since we're waiting on Foreman + Puppet to properly be integrated into Katello for our configuration management solution. Any way to restrict this via the FreeIPA UI? I think the only safe way to achieve this is to block port 464 on the AD servers for the Linux hosts. Because basically what passwd is doing here via SSSD is to change the Kerberos password. The same can be done with the kpasswd command, it does not require any privileges the user only needs to know his current password. So even if we add an option to force SSSD to reject password changes for users from trusted domains there are other ways for users to change the password which cannot be controlled by IPA. Please note that changing the AD password with kpasswd would even work without trust. HTH bye, Sumit Thanks, Brian ___ 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Server UI Behind Proxy
On Wed, 2013-08-14 at 09:23 +0300, Alexander Bokovoy wrote: On Wed, 14 Aug 2013, Andrew Lau wrote: Hi, I've got my FreeIPA setup in an internal infrastructure, but I want to be able to have users access the web UI externally. I tweaked the ipa-rewrite.conf so it won't redirect me to the FQDN and then tried both a nginx reverse proxy and port forwarding, both works if the client manually sets the host name of the IPA server eg. ipa01.internaldomain.local in their /etc/hosts file. However if the client tries to to use eg. ipa.externaldomain.com with the same port forwarding or nginx proxy config, it'll silently error. The docs briefly touches on this - but doesn't really give much to go on. Any suggestions? Couple considerations here. First, you may need to play with debug level to see what principal mod_auth_kerb picks up when negotiation happens. Second, using Kerberos authentication requires both sides to own Kerberos principals for authentication process to go. Browsers select HTTP/server.fqdn as their target service principal when connection to the server.fqdn. Your IPA server only has HTTP/ipa01.internaldomain.local in its keytab in /etc/httpd/conf/ipa.keytab, which means it would only be able to respond on ipa01.internaldomain.local to Kerberos auth requests. A way to fix this is by making HTTP/ipa.externaldomain.com service in IPA (ipa service-add HTTP/ipa.externaldomain.com) and then use 'ipa-getkeytab' to fetch the keytab with the key for the service. Next step would be to merge content of this keytab with /etc/httpd/conf/ipa.keytab: (echo rkt /tmp/external.keytab; echo wkt /etc/httpd/conf/ipa.keytab) |ktutil Then restart httpd -- I'm not sure mod_auth_kerb re-reads the keytab on its change. FWIW please disregard these complicated instructions, just run ipa-getkeytab on the server an pass -k /etc/httpd/conf/ipa.keytab directly. ipa-getkeytab will properly append the fetched keys to the keytab and no further, error prone, manual merging will be necessary. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Restrict AD users from passwd
On 14.8.2013 15:48, Brian Lee wrote: Hi Sumit, Thanks for the suggestion. I'll have to give this some thought, since we have 100+ AD servers, this might not be well received by the AD team. If anyone can think of a better mousetrap than this, let me know. Thanks, Brian On Wed, Aug 14, 2013 at 9:37 AM, Sumit Bose sb...@redhat.com wrote: On Wed, Aug 14, 2013 at 09:19:17AM -0400, Brian Lee wrote: Hi All, Our current account management policy requires that users change their AD passwords via a special portal, however I've noticed that this can be bypassed by issuing passwd on a Linux system while logged in with AD credentials, thus changing their AD password. Any thoughts on the best way to prevent this action? What I've considered so far is removing the trust in AD, effectively creating a one-way trust, but that would limit functionality for future interoperability. Additionally, we could change the permissions for passwd on each Linux system, but this would be somewhat hackish and also complicated to enforce, since we're waiting on Foreman + Puppet to properly be integrated into Katello for our configuration management solution. Any way to restrict this via the FreeIPA UI? I think the only safe way to achieve this is to block port 464 on the AD servers for the Linux hosts. Because basically what passwd is doing here via SSSD is to change the Kerberos password. The same can be done with the kpasswd command, it does not require any privileges the user only needs to know his current password. So even if we add an option to force SSSD to reject password changes for users from trusted domains there are other ways for users to change the password which cannot be controlled by IPA. Please note that changing the AD password with kpasswd would even work without trust. IMHO the correct approach is to enforce password policy on AD side, otherwise users can use standard Kerberos protocol and do the change anyway (i.e. effectively bypass IPA and your portal completely). AFAIK AD has some checkbox which determines if the user is allowed to change own password or not. The next question is how 'the portal' does the password change and if it will continue to work if you disallow users to change own password on AD side. -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Restrict AD users from passwd
On Wed, 2013-08-14 at 09:48 -0400, Brian Lee wrote: Hi Sumit, Thanks for the suggestion. I'll have to give this some thought, since we have 100+ AD servers, this might not be well received by the AD team. If anyone can think of a better mousetrap than this, let me know. Do you also block the 'net user' command on Windows clients ? It's the same as 'passwd' on Linux clients. I would address the problem by using proper password policies as I (now) see Petr recommended i another email. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Restrict AD users from passwd
On the AD side, they limit the potential to change the AD password by deploying a modified the msgina.dll. Otherwise, the user still has the ways to throw a wrench in the system, we're just doing our best to limit the opportunity for this action. On Wed, Aug 14, 2013 at 10:32 AM, Simo Sorce s...@redhat.com wrote: On Wed, 2013-08-14 at 09:48 -0400, Brian Lee wrote: Hi Sumit, Thanks for the suggestion. I'll have to give this some thought, since we have 100+ AD servers, this might not be well received by the AD team. If anyone can think of a better mousetrap than this, let me know. Do you also block the 'net user' command on Windows clients ? It's the same as 'passwd' on Linux clients. I would address the problem by using proper password policies as I (now) see Petr recommended i another email. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa-server-certinstall ruined pki-tomcatd startup
Hello, After installing FreeIPA I followed instructions from http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP to use globally trusted certificates for HTTP/LDAP server interface to secure other systems provisioning. Then it went out that pki-tomcatd is not able to start anymore because of this: | NFO: Deploying web application directory /var/lib/pki/pki-tomcat/webapps/ca | SSLAuthenticatorWithFallback: Creating SSL authenticator with fallback | SSLAuthenticatorWithFallback: Setting container | SSLAuthenticatorWithFallback: Initializing authenticators | SSLAuthenticatorWithFallback: Starting authenticators | 01:48:31,313 DEBUG (org.jboss.resteasy.plugins.providers.DocumentProvider:60) - Unable to retrieve ServletContext: expandEntityReferences defaults to true | 01:48:31,320 DEBUG (org.jboss.resteasy.plugins.providers.DocumentProvider:60) - Unable to retrieve ServletContext: expandEntityReferences defaults to true | Internal Database Error encountered: Could not connect to LDAP server host ipa.mydomain.com port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) Meanwhile dirsrv tells me Peer does not recognize and trust the CA that issued your certificate. I tried to fix trust by adding various certificates with certutil to /etc/dirsrv/slapd/ and /etc/pki/pki-tomcat/alias/, but nothing helped. Does anyone have a suggestion how to fix the situation? -- Best regards, Vladimir Kulev Mobile: +358400369346, +79215554422 Jabber: m...@lightoze.net Skype: lightoze ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
