[Freeipa-users] DM Password Change & Password Storage
Hello all! We've got 2 replicated instances of FreeIPA 4.4.0 from the EPEL repository running on fully-updated CentOS 7 instances. We're going thru an audit right now, and I have to provide some proof of certain things related to IPA to our auditors. Unfortunately, the person who originally set these up evidently did not document the Directory Manager password in our docs, so I was forced to reset this password, using the process at: http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html This was successful, and I can now bind to the DS with the new password. I'm now trying to follow the steps at: https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password A few things are rather confusing to me. I've tried Google searching without much luck either. So hopefully you guys can answer a few questions for me. 1) First off, the doc says: The following procedure is only applicable to FreeIPA 3.2.1 or older. Since FreeIPA 3.2.2 (and ticket #3594 <https://fedorahosted.org/freeipa/ticket/3594>), the procedure is automated as a part of preparing a replica info file by using ipa-replica-prepare So do I even need to perform these steps at all, considering I'm well beyond 3.2.2. We don't have any intention of running ipa-replica-prepare for the forseeable future (we shouldn't ever need to add a third directory server here). 2) The first step (Update LDAP bind password) seems to indicate you're adding the new password in clear-text to the password.conf file - this seems like a major security issue. Am I misunderstanding what is being requested here? The old password is not in this file (All my current files have is lines for "internal" and "replicationdb" 3) The next step regenerates the cacert.p12 file, but seems to do nothing with it, just leaves it sitting in /root - what should be done with this file afterward? Thanks for any help you can give! Jeremy Utley -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] FreeIPA SSL certificates installed to multiple hosts
Hello all! We're looking at replacing a lot of our currently self-signed internal SSL certificates in our infrastructure with certificates generated by the FreeIPA CA. However, I've run into something that I haven't been able to find documented as of yet, and I'm hoping some of you can point me in the right direction. Some of our internal SSL sites are load-balanced between multiple hosts, so we end up with the same SSL/Key installed to each host. For example: hostname.domain.com is hosted on hostA and hostB. Both hostA and hostB have the certs at /etc/httpd/certs/ hostname.domain.com/hostname.crt, and the private key at /etc/httpd/certs/ hostname.domain.com/hostname.key I would expect I can have both hostA and hostB be able to work with the FreeIPA certificates by adding additional ipa host-add-managedby and ipa service-add-host commands, to specify both hostA and hostB. However, from my understanding, running the "ipa-getcert request" command on hostA will put the certs on hostA only, and I'd need the same certs on both hostA and hostB. Is there a special ipa-getcert incantation that can retrieve the already-issued certificate files, and allow them to be managed by FreeIPA on both hosts? Or is there another recommended way of doing this? Thanks for any info you can give me! Jeremy Utley -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] IPA & Yubikey
Hello all! I'm quite close to reaching the ideal point with our new FreeIPA setup, but one thing that is standing in the way is 2FA. I know FreeIPA has support for Google Auth, FreeOTP, and Yubikey. We'd like to go with Yubikeys over the phone-based systems, but a lot of the docs regarding Yubikey seem to either be out-dated, or not real clear (at least to me). So I'd like to ask a few questions to make sure I'm understanding correctly. 1) It looks like the normal setup of a Yubikey is to plug it into a machine and run the "ipa otptoken-add-yubikey" command. This implies that the machine that sets up the Yubikey needs to be part of the FreeIPA domain, which presents somewhat of a problem for us, as our current IPA setup has no desktops, and is in a remote "lights-out" datacenter an hour's drive from our office. I did see a post recently in the archives of someone figuring out how to set up a Yubikey via the web interface ( https://www.redhat.com/archives/freeipa-users/2016-March/msg00114.html) - would this be viable? 2) Does the otptoken-add-yubikey command actually change the programming of the Yubikey, or does it simply read it's configuration? We have some users who are already using a Yubikey for personal stuff, and we'd like to allow those users to continue to use their existing Yubikey to auth to our IPA domain, but if the add command changes the programming of the key, that may not be possible without using the second slot, and if users are already using the second slot, they are out of luck. 3) Does Yubikey auth require talking to the outside world to function? Our IPA setup is within a secure zone, with no direct connectivity to the outside world, so if this is necessary, it would be a possible deal-breaker for these. Thanks for your time in answering these questions! Jeremy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Centos 7 IPA server, Centos 6 Clients
Was able to trace down the problem. Since this system is within a PCI zone, I need high security, and followed instructions at https://access.redhat.com/articles/1467293, and disabled TLSv1.0. Evidently, the NSS libraries on C6 do not support TLS versions higher than 1.0, because once I put TLSv1.0 back into the config, it worked again. Thanks for the help! Jeremy On Tue, Apr 5, 2016 at 5:36 PM, Rob Crittenden <rcrit...@redhat.com> wrote: > Jeremy Utley wrote: > >> Hello all! >> >> Is there any known issues with registering a CentOS 6 client with a >> CentOS 7 FreeIPA server? I just tried to register my first C6 client >> (fully updated) with our new FreeIPA infrastructure installed on C7, and >> I'm getting an NSS error: >> >> args=/usr/sbin/ipa-join -s ds02.domain.com <http://ds02.domain.com> -b >> dc=ipa,dc=domain,dc=com -d >> stdout= >> stderr=XML-RPC CALL: >> >> \r\n >> \r\n >> join\r\n >> \r\n >> \r\n >> hostname.domain.com >> <http://hostname.domain.com>\r\n >> \r\n >> \r\n >> nsosversion\r\n >> 2.6.32-573.18.1.el6.x86_64\r\n >> nshardwareplatform\r\n >> x86_64\r\n >> \r\n >> \r\n >> \r\n >> >> * About to connect() to ds02.domain.com <http://ds02.domain.com> port >> 443 (#0) >> * Trying 192.168.150.2... * Connected to ds02.domain.com >> <http://ds02.domain.com> (192.168.150.2) port 443 (#0) >> * Initializing NSS with certpath: sql:/etc/pki/nssdb >> * CAfile: /etc/ipa/ca.crt >>CApath: none >> * NSS error -12190 >> * Closing connection #0 >> libcurl failed to execute the HTTP POST transaction. SSL connect error >> >> Looking up that NSS error, it seems to indicate a SSL protocol error. >> Looking at my FreeIPA webserver configuration, I'm allowing TLSv1.0, >> TLSv1.1, TLSv1.2: >> > > Right, it is SSL_ERROR_PROTOCOL_VERSION_ALERT. Can you show the > NSSProtocols from /etc/httpd/conf.d/nss.conf on the server? > > The oddest part is that, from the client, I can use wget to connect to >> the IPA server, but can not use curl: >> >> [root@hostname ~]# wget --no-check-certificate https://ds02.domain.com >> --2016-04-05 17:42:50-- https://ds02.domain.com/ >> Resolving ds02.domain.com... 192.168.150.2 >> Connecting to ds02.domain.com >> <http://ds02.domain.com>|192.168.150.2|:443... connected. >> WARNING: cannot verify ds02.domain.com <http://ds02.domain.com>’s >> certificate, issued by “/O=IPA.DOMAIN.COM/CN=Certificate >> <http://IPA.DOMAIN.COM/CN=Certificate> Authority”: >>Self-signed certificate encountered. >> HTTP request sent, awaiting response... 301 Moved Permanently >> Location: https://ds02.domain.com/ipa/ui [following] >> >> >> [root@hostname ~]# curl -v -k https://ds02.domain.com/ >> * About to connect() to ds02.domain.com <http://ds02.domain.com> port >> 443 (#0) >> * Trying 192.168.150.2... connected >> * Connected to ds02.domain.com <http://ds02.domain.com> (192.168.150.2) >> port 443 (#0) >> * Initializing NSS with certpath: sql:/etc/pki/nssdb >> * warning: ignoring value of ssl.verifyhost >> * NSS error -12190 >> * Closing connection #0 >> * SSL connect error >> curl: (35) SSL connect error >> > > They are linked against different crypto providers (OpenSSL and NSS) > > However, the same curl command, run from another C7 host, works just >> fine. Something incompatible in the NSS libraries maybe? >> > > It might be helpful to look at the output of: > > $ openssl s_client -host ds02.domain.com -port 443 > > To test all the protocols you can do a test with each: -tls1, -tls1_1 and > -tls1_2 > > rob > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Centos 7 IPA server, Centos 6 Clients
Hello all! Is there any known issues with registering a CentOS 6 client with a CentOS 7 FreeIPA server? I just tried to register my first C6 client (fully updated) with our new FreeIPA infrastructure installed on C7, and I'm getting an NSS error: args=/usr/sbin/ipa-join -s ds02.domain.com -b dc=ipa,dc=domain,dc=com -d stdout= stderr=XML-RPC CALL: \r\n \r\n join\r\n \r\n \r\n hostname.domain.com\r\n \r\n \r\n nsosversion\r\n 2.6.32-573.18.1.el6.x86_64\r\n nshardwareplatform\r\n x86_64\r\n \r\n \r\n \r\n * About to connect() to ds02.domain.com port 443 (#0) * Trying 192.168.150.2... * Connected to ds02.domain.com (192.168.150.2) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/ipa/ca.crt CApath: none * NSS error -12190 * Closing connection #0 libcurl failed to execute the HTTP POST transaction. SSL connect error Looking up that NSS error, it seems to indicate a SSL protocol error. Looking at my FreeIPA webserver configuration, I'm allowing TLSv1.0, TLSv1.1, TLSv1.2: The oddest part is that, from the client, I can use wget to connect to the IPA server, but can not use curl: [root@hostname ~]# wget --no-check-certificate https://ds02.domain.com --2016-04-05 17:42:50-- https://ds02.domain.com/ Resolving ds02.domain.com... 192.168.150.2 Connecting to ds02.domain.com|192.168.150.2|:443... connected. WARNING: cannot verify ds02.domain.com’s certificate, issued by “/O= IPA.DOMAIN.COM/CN=Certificate Authority”: Self-signed certificate encountered. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://ds02.domain.com/ipa/ui [following] [root@hostname ~]# curl -v -k https://ds02.domain.com/ * About to connect() to ds02.domain.com port 443 (#0) * Trying 192.168.150.2... connected * Connected to ds02.domain.com (192.168.150.2) port 443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * warning: ignoring value of ssl.verifyhost * NSS error -12190 * Closing connection #0 * SSL connect error curl: (35) SSL connect error However, the same curl command, run from another C7 host, works just fine. Something incompatible in the NSS libraries maybe? Thanks for any help you can provide! Jeremy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Closing off some ports for FreeIPA
On Fri, Apr 1, 2016 at 2:57 PM, Rob Crittenden <rcrit...@redhat.com> wrote: > Jeremy Utley wrote: > >> Hello all on the list. >> >> First off, if this is documented somewhere I'm not aware of, I apologize >> for the noise. I've spent a couple of hours google searching google >> without success, so pointers to any documentation I've missed would be >> greatly appreciated! >> >> We're in the process of setting up a FreeIPA system within our >> ultra-secure PCI zone. It's currently working well, and we are very >> happy with it. However, we know that come our next audit, we're going >> to get hit on a few things, so I would like to ask about blocking off >> some additional ports (specifically 80, 389, 53). 53 I think will be >> safe to block off, as all our clients actually use a dedicated caching >> DNS system with unbound, which has been configured to forward all >> queries for the zone "ipa.domain.com <http://ipa.domain.com>" to the >> FreeIPA servers, so we should be able to block 53 from everywhere but >> the unbound servers without breakage. >> >> However, port 80 and 389 I'm not so sure about. I know most things that >> hit port 80 get redirected to 443, and 389 provides STARTTLS >> functionality, but in theory, these ports can provide unencrypted >> communications, and therefore our auditors will ask that they be closed >> off. However, in my research so far, I have not been able to find out >> what the ramifications would be to blocking these ports for the IPA >> system itself (would it fall back to using SSL on 636? Would API calls >> fail if port 80 is closed?). >> >> I also know that the ipa-client-install script will check to ensure >> these ports are open - temporarily opening them for the client setup >> will not be an issue, if we can close it back down after that. We do >> not add systems within this zone very often, so this is a minor issue. >> >> Thanks for any advice you can give! >> >> Jeremy >> >> >> > See this thread from earlier this week, > https://www.redhat.com/archives/freeipa-users/2016-March/msg00295.html > > rob > Thank you, Rob! I think that will answer my questions, and hopefully the auditors! Jeremy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Closing off some ports for FreeIPA
Hello all on the list. First off, if this is documented somewhere I'm not aware of, I apologize for the noise. I've spent a couple of hours google searching google without success, so pointers to any documentation I've missed would be greatly appreciated! We're in the process of setting up a FreeIPA system within our ultra-secure PCI zone. It's currently working well, and we are very happy with it. However, we know that come our next audit, we're going to get hit on a few things, so I would like to ask about blocking off some additional ports (specifically 80, 389, 53). 53 I think will be safe to block off, as all our clients actually use a dedicated caching DNS system with unbound, which has been configured to forward all queries for the zone "ipa.domain.com" to the FreeIPA servers, so we should be able to block 53 from everywhere but the unbound servers without breakage. However, port 80 and 389 I'm not so sure about. I know most things that hit port 80 get redirected to 443, and 389 provides STARTTLS functionality, but in theory, these ports can provide unencrypted communications, and therefore our auditors will ask that they be closed off. However, in my research so far, I have not been able to find out what the ramifications would be to blocking these ports for the IPA system itself (would it fall back to using SSL on 636? Would API calls fail if port 80 is closed?). I also know that the ipa-client-install script will check to ensure these ports are open - temporarily opening them for the client setup will not be an issue, if we can close it back down after that. We do not add systems within this zone very often, so this is a minor issue. Thanks for any advice you can give! Jeremy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
