[Freeipa-users] Fedora 21 and 4.0.3
Hi, I'm new to IPA - and was trying out the newest version of 4.0.3 with Fedora Server 21 testing -- it continues to die during the install at: Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/26]: creating certificate server user [2/26]: configuring certificate server instance [3/26]: stopping certificate server instance to update CS.cfg [4/26]: backing up CS.cfg [5/26]: disabling nonces [6/26]: set up CRL publishing [7/26]: starting certificate server instance --- consistently dies at step 7 and checking install log show: 2014-09-29T21:14:30Z DEBUG wait_for_open_ports: localhost [8080, 8443] timeout 300 2014-09-29T21:19:31Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 639, in run_script return_value = main_function() File /usr/sbin/ipa-server-install, line 1095, in main dm_password, subject_base=options.subject) File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 484, in configure_instance self.start_creation(runtime=210) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 367, in start_creation method() File /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line 490, in __start self.start() File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 282, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File /usr/lib/python2.7/site-packages/ipaplatform/services.py, line 193, in start instance_name, capture_output=capture_output, wait=wait) File /usr/lib/python2.7/site-packages/ipaplatform/base/services.py, line 262, in start self.wait_for_open_ports(self.service_instance(instance_name)) File /usr/lib/python2.7/site-packages/ipaplatform/base/services.py, line 228, in wait_for_open_ports self.api.env.startup_timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1153, in wait_for_open_ports raise socket.timeout() Would anyone have any ideas on finding out what is going on here? I see the timeout of 5 minutes - but why waiting on ports that are not part of IPA? Thank you Janelle -- 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 and RHEL 7
Hi again Just wondering if anyone has found a work around to get freeipa installed on RHEL 7 -- the server works fine, but it never finishes the client install and you can't force a client install either. You end up with this in the logs, which I see has been reported, but wondering if fixed? stderr=Failed to issue method call: Unit fedora-domainname.service failed to load: No such file or directory. Thanks ~J -- 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] freeipa and RHEL 7
That worked - thanks everyone!! Now I need to do my part and find a bug and report it before others do :-) ~J On 10/8/14 8:26 AM, Rob Crittenden wrote: Janelle wrote: Hi again Just wondering if anyone has found a work around to get freeipa installed on RHEL 7 -- the server works fine, but it never finishes the client install and you can't force a client install either. You end up with this in the logs, which I see has been reported, but wondering if fixed? stderr=Failed to issue method call: Unit fedora-domainname.service failed to load: No such file or directory. Thanks ~J It is being tracked in this ticket: https://fedorahosted.org/freeipa/ticket/4562 You need to modify the installer to call to use rhel-domain.service instead. I believe you need to modify /usr/lib/python2*/site-packages/ipaplatform/fedora/services.py to make the right call. 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] strange error from EL 7 install?
Happy Monday everyone... Wondering if anyone else is seeing this error since this weekend? Trying to add in a new IPA replica, which of course requires the software installed -- this is in CentOS 7 using COPR repo and : -- Finished Dependency Resolution Error: Package: pki-base-10.2.0-3.el7.centos.noarch (ipa) Requires: jackson-jaxrs-json-provider and yet, I have never had that issue until this weekend. :-( Any help? Janelle -- 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] strange error from EL 7 install?
After further investigation - it looks like the PKI base was altered/updated because even on a running server a yum update produces same error: # yum check-update Loaded plugins: fastestmirror, product-id, subscription-manager, versionlock Loading mirror speeds from cached hostfile * base: linux.mirrors.es.net * extras: mirrors.usinternet.com * updates: centos.host-engine.com pki-base.noarch 10.2.0-3.el7.centos freeipa pki-ca.noarch 10.2.0-3.el7.centos freeipa pki-server.noarch 10.2.0-3.el7.centos freeipa pki-tools.x86_64 10.2.0-3.el7.centos freeipa slapi-nis.x86_64 0.54-1.el7.centosfreeipa and: if you select yes: --- Package pki-base.noarch 0:10.2.0-3.el7.centos will be an update -- Processing Dependency: jackson-jaxrs-json-provider for package: pki-base-10.2.0-3.el7.centos.noarch -- Finished Dependency Resolution Error: Package: pki-base-10.2.0-3.el7.centos.noarch (freeipa) Requires: jackson-jaxrs-json-provider You could try using --skip-broken to work around the problem On 10/13/14 9:18 AM, Janelle wrote: Happy Monday everyone... Wondering if anyone else is seeing this error since this weekend? Trying to add in a new IPA replica, which of course requires the software installed -- this is in CentOS 7 using COPR repo and : -- Finished Dependency Resolution Error: Package: pki-base-10.2.0-3.el7.centos.noarch (ipa) Requires: jackson-jaxrs-json-provider and yet, I have never had that issue until this weekend. :-( Any help? Janelle -- 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] sysctl and/or limits.conf?
Hi again, A lot of this information has been very useful. I did have a question I could not answer. I noticed in the Deployment Recommendations docs, it says not to have any more than 4 replication agreements. Perhaps I am missing something, but I don't see how to get a replica to be a master to be able to create another replicate? Am I missing something obvious here? Thank you, ~Janelle On 10/13/14 3:18 PM, Dmitri Pal wrote: On 10/12/2014 08:07 PM, James wrote: On 12 October 2014 19:55, Janelle janellenicol...@gmail.com wrote: Hi again, I was wondering if there were any suggestions for performance of IPA and settings to sysctl and maybe limits.conf? I tried the website, but did not see anything. Have about 3000 servers that will be talking to 3-4 masters/replicas. Are there any formulas to follow? thanks If you get an answer to this, or if you know of any other performance tuning params, let me know and I'll build it in to puppet-ipa. Thanks, James I do not think it is easy automatable. Please see http://www.freeipa.org/page/Deployment_Recommendations and part about replicas. If 3000 in one datacenter then 3 is good enough or 4 if you are very LDAP heavy (some applications are like Jira for example). If you have 2 data center I would go for 2+2. -- 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] strange error from EL 7 install?
Actually, I did find a fix and forgot to post. I was able to mirror the COPR repo, and after reviewing it, found that simply removing the pki-base...fc21 directory, and regenning the repo data with createrepo, fixed the problem. It drops the version of PKI back to the 10.1 branch and that resolved the dependencies. Hope this helps, Janelle On 10/13/14 9:48 PM, Fraser Tweedale wrote: On Mon, Oct 13, 2014 at 09:52:40AM -0700, Janelle wrote: After further investigation - it looks like the PKI base was altered/updated because even on a running server a yum update produces same error: # yum check-update Loaded plugins: fastestmirror, product-id, subscription-manager, versionlock Loading mirror speeds from cached hostfile * base: linux.mirrors.es.net * extras: mirrors.usinternet.com * updates: centos.host-engine.com pki-base.noarch 10.2.0-3.el7.centos freeipa pki-ca.noarch 10.2.0-3.el7.centos freeipa pki-server.noarch 10.2.0-3.el7.centos freeipa pki-tools.x86_64 10.2.0-3.el7.centos freeipa slapi-nis.x86_64 0.54-1.el7.centosfreeipa and: if you select yes: --- Package pki-base.noarch 0:10.2.0-3.el7.centos will be an update -- Processing Dependency: jackson-jaxrs-json-provider for package: pki-base-10.2.0-3.el7.centos.noarch -- Finished Dependency Resolution Error: Package: pki-base-10.2.0-3.el7.centos.noarch (freeipa) Requires: jackson-jaxrs-json-provider You could try using --skip-broken to work around the problem Hi Janelle, Looks like the COPR moved from Dogtag 10.1 to 10.2 on 8 Oct, and 10.2 declares a dependency on Jackson which is not in EPEL. The dependency causing the probelm (jackson-jaxrs-json-provider) was introduced at commit 32d71bb. I'm not sure on the right approach to fixing this but I've copied pki-devel who will be able to help. Fraser On 10/13/14 9:18 AM, Janelle wrote: Happy Monday everyone... Wondering if anyone else is seeing this error since this weekend? Trying to add in a new IPA replica, which of course requires the software installed -- this is in CentOS 7 using COPR repo and : -- Finished Dependency Resolution Error: Package: pki-base-10.2.0-3.el7.centos.noarch (ipa) Requires: jackson-jaxrs-json-provider and yet, I have never had that issue until this weekend. :-( Any help? Janelle -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] sysctl and/or limits.conf?
Hi Rob, Thanks for that - it clears up one point - and explains why the replica manage command shows all masters, but what I don't understand is how to get the CA to a replica once it is created? I don't see anything in the docs on that. Am I missing something very obvious here? I am coming from the AD world and trying to replace it, so please excuse my ignorance in this area. thanks Janelle On 10/14/14 6:48 AM, Rob Crittenden wrote: Janelle wrote: Hi again, A lot of this information has been very useful. I did have a question I could not answer. I noticed in the Deployment Recommendations docs, it says not to have any more than 4 replication agreements. Perhaps I am missing something, but I don't see how to get a replica to be a master to be able to create another replicate? Am I missing something obvious here? Every IPA install is a master. The only distinction between servers are the optional services of DNS and a CA. So don't get confused by replica vs master. Once an IPA server is up it is a master. We don't recommend any one master to have more than 4 agreements. Each agreement adds a bit more load on the server to calculate the differences to send to each one, so you want to keep it reasonable. I'd recommend making a map of your topology to ensure that no master ends up alone, or one ends up being overloaded. You can use ipa-replica-manage to control the replication topology. By default a single agreement is set up between a new master and the one that created it. Any master can create a new master. As you do your installations be sure to have at least 2 masters with a CA on it to avoid a single point of failure. rob Thank you, ~Janelle On 10/13/14 3:18 PM, Dmitri Pal wrote: On 10/12/2014 08:07 PM, James wrote: On 12 October 2014 19:55, Janelle janellenicol...@gmail.com wrote: Hi again, I was wondering if there were any suggestions for performance of IPA and settings to sysctl and maybe limits.conf? I tried the website, but did not see anything. Have about 3000 servers that will be talking to 3-4 masters/replicas. Are there any formulas to follow? thanks If you get an answer to this, or if you know of any other performance tuning params, let me know and I'll build it in to puppet-ipa. Thanks, James I do not think it is easy automatable. Please see http://www.freeipa.org/page/Deployment_Recommendations and part about replicas. If 3000 in one datacenter then 3 is good enough or 4 if you are very LDAP heavy (some applications are like Jira for example). If you have 2 data center I would go for 2+2. -- 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 4.1 on CentOS 7? Any luck?
Hi everyone.. Well, since the fun of getting 4.0.4 on CentOS 7 - and just removing the branch of 10.2 PKI - that was easy. But trying to get 4.1 installed - it complains about needing 10.2, so I am wondering if anyone has been successful in this endeavor?? Thanks ~J -- 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] tuning for DS?
hi all.. As we head into the weekend, I hope you all take time to play and enjoy. At the same time, if you are online and have any ideas - are there any good tuning suggestions for beefing up 389ds for an environment with approx 4000 users and approx 1000 hosts? My guess is the cache needs work for the number of users, so that is where I am looking. Any ideas? ~J -- 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] strange error deleting replica?
Hi -- Has anyone seen this before? # ipa-replica-manage del kermit.xyzzy.com --force unexpected error: [Errno -2] Name or service not known ?? Very confused as to What service or name is not known? This is 4.0.5 running on CentOS 7. ~J -- 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] strange DS errors trying to tune...
Hi all.. I continue to come up with strange and unusual problems. Here is a new one - use the dbmon.sh script and trying to tune the dbcache... This is on a replica BTW First -- THIS WORKS: INCR=60 BINDDN=cn=directory manager BINDPW=asecret VERBOSE=2 dbmon.sh and I see all the info I need, BUT - now I want to tune it and get: (HOW CAN THIS BE?!?!) # ldapmodify -x -D cn=directory manager -w asecret EOF dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: 8589934592 EOF ldap_bind: Invalid credentials (49) Thanks ~J -- 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] strange DS errors trying to tune...
In this case it is the exact password and it worked in the first line but not in the second. Now to make things even more strange -- I have 8 replicas -- and 3 of them show this problem, the others do not -- WOW.. My brain is going to explode today. :-) ~J Rich Megginson mailto:rmegg...@redhat.com November 11, 2014 at 10:39 AM On 11/11/2014 11:30 AM, Janelle wrote: Hi all.. I continue to come up with strange and unusual problems. Here is a new one - use the dbmon.sh script and trying to tune the dbcache... This is on a replica BTW First -- THIS WORKS: INCR=60 BINDDN=cn=directory manager BINDPW=asecret VERBOSE=2 dbmon.sh and I see all the info I need, BUT - now I want to tune it and get: (HOW CAN THIS BE?!?!) # ldapmodify -x -D cn=directory manager -w asecret EOF dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: 8589934592 EOF ldap_bind: Invalid credentials (49) Is asecret the literal password? If not, does it contain spaces or other shell metacharacters that need to be quoted or escaped? Thanks ~J Janelle mailto:janellenicol...@gmail.com November 11, 2014 at 10:30 AM Hi all.. I continue to come up with strange and unusual problems. Here is a new one - use the dbmon.sh script and trying to tune the dbcache... This is on a replica BTW First -- THIS WORKS: INCR=60 BINDDN=cn=directory manager BINDPW=asecret VERBOSE=2 dbmon.sh and I see all the info I need, BUT - now I want to tune it and get: (HOW CAN THIS BE?!?!) # ldapmodify -x -D cn=directory manager -w asecret EOF dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: 8589934592 EOF ldap_bind: Invalid credentials (49) Thanks ~J -- 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] strange replica creation problem
Happy Monday everyone, I have a strange issue I am seeing with replica creations, but it does not seem to be consistent. Sometimes, when trying to install the replica I get errors trying to connect to the master via SSH: /[root@ipa3 ~]# ipa-replica-install /var/lib/ipa/replica-info-ipa3.xyzzy.com.gpg // //Directory Manager (existing master) password: // // //Run connection check to master// //Check connection from replica to remote master 'ipa2.xyzzy.com':// // Directory Service: Unsecure port (389): OK// // Directory Service: Secure port (636): OK// // Kerberos KDC: TCP (88): OK// // Kerberos Kpasswd: TCP (464): OK// // HTTP Server: Unsecure port (80): OK// // HTTP Server: Secure port (443): OK// // //The following list of ports use UDP protocol and would need to be// //checked manually:// // Kerberos KDC: UDP (88): SKIPPED// // Kerberos Kpasswd: UDP (464): SKIPPED// // //Connection from replica to master is OK.// //Start listening on required ports for remote master check// //Get credentials to log in to remote master// //ad...@xyzzy.com password: // // //Check SSH connection to remote master// //ad...@ipa2.xyzzy.com's password: // //ad...@ipa2.xyzzy.com's password: // //Could not SSH into remote host. Error output:// //OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013// //debug1: Reading configuration data /etc/ssh/ssh_config// //debug1: /etc/ssh/ssh_config line 51: Applying options for */ ssh via root and all the hosts - using keys - works just fine. I don't understand why this is happening on some hosts and not others. Any ideas? ~J -- 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] strange replica creation problem
I did find that as the work-around - just trying to understand why it comes up sometimes... Did you find any issues with the workings of a replica if you had to resort to this method? Thanks. ~J On 11/17/14 10:57 AM, Craig White wrote: Janelle, this may not be that useful but I found it worthwhile to resort to… –skip-conncheck When setting up the replica – pretty much for the same reason. Craig White System Administrator O623-201-8179 M602-377-9752 cid:image001.png@01CF86FE.42D51630 SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 *From:*freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Janelle *Sent:* Monday, November 17, 2014 7:43 AM *To:* freeipa-users@redhat.com *Subject:* [Freeipa-users] strange replica creation problem Happy Monday everyone, I have a strange issue I am seeing with replica creations, but it does not seem to be consistent. Sometimes, when trying to install the replica I get errors trying to connect to the master via SSH: /[root@ipa3 ~]# ipa-replica-install /var/lib/ipa/replica-info-ipa3.xyzzy.com.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'ipa2.xyzzy.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@xyzzy.com mailto:ad...@xyzzy.com password: Check SSH connection to remote master ad...@ipa2.xyzzy.com mailto:ad...@ipa2.xyzzy.com's password: ad...@ipa2.xyzzy.com mailto:ad...@ipa2.xyzzy.com's password: Could not SSH into remote host. Error output: OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 51: Applying options for */ ssh via root and all the hosts - using keys - works just fine. I don't understand why this is happening on some hosts and not others. Any ideas? ~J -- 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] strange error - disconnecting a replica?
Hi all.. Was on vacation - now I'm back. Have a new problem I thought I would run by you -- I have replica agreements between a server and 3 others. They all show up in ipa-replica-manage list, BUT when I try to disconnect one of them : ipa: INFO: Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 Any idea what this might be telling me? And any ideas on how to reduce CPU load on replicas other than to reduce the number of hosts they replicate to? Thanks ~J -- 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] strange replica install error (another one)
Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? ~J -- 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] strange replica install error (another one)
Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? ~J -- 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] strange replica install error (another one)
Hi all, just (pam)auth and nslcd It was ported from a running OpenLDAP environment to IPA. Just trying to do conversions in stages so as not to change too much all at once. Thought I could go from OpenLDAP to IPA and just use the backend of 389ds. Functionally it does work, but the load kills it. Seems like FDs are a huge problem. But all the settings documented don't see to resolve the magic: / Netscape Portable Runtime error -5971 (Process open FD table is full.)/ error. Shouldn't this increase file descriptors in conjunction with /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 389-ds itself. But I still can't get this to work, although it does not give an error. ldapmodify -x -D cn=directory manager -W EOF dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 65535 - replace: nsslapd-dtablesize nsslapd-dtablesize: 65535 - replace: nsslapd-reservedescriptors nsslapd-reservedescriptors: 100 EOF Thanks ~J On 12/4/14 7:40 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 12/04/2014 09:41 AM, Rich Megginson wrote: On 12/04/2014 08:39 AM, Rich Megginson wrote: On 12/04/2014 01:45 AM, Petr Spacek wrote: On 4.12.2014 05:02, Janelle wrote: Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. That should not happen. For crashes, we would need to look at some stack traces: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes For situations when the CPU is through the roof, that is very similar to debugging hangs: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs Sorry, forgot to mention that since this is IPA you'll also need to install the ipa-debuginfo and slapi-nis-debuginfo packages. I would also add a question about your client configuration. For example if you use SSSD with enumerate=true for your clients then yes you will get your environment to the knees pretty quickly. I assumed SSSD wasn't being used at all which begs the question: what is? nss_ldap? Is nslcd being used? What is hitting LDAP, only auth or something else (e.g. sudo, automount). rob Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? We need more information about your problem. As always, please start with information requested on http://www.freeipa.org/page/Troubleshooting#Reporting_bugs /var/log/ipa*.log from affected replica will be invaluable (along with exact package version numbers [including p11-kit] and repo configuration). -- 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] strange replica install error (another one)
On 12/4/14 8:30 AM, Alexander Bokovoy wrote: On Thu, 04 Dec 2014, Janelle wrote: Hi all, just (pam)auth and nslcd It was ported from a running OpenLDAP environment to IPA. Just trying to do conversions in stages so as not to change too much all at once. Thought I could go from OpenLDAP to IPA and just use the backend of 389ds. Functionally it does work, but the load kills it. Seems like FDs are a huge problem. But all the settings documented don't see to resolve the magic: / Netscape Portable Runtime error -5971 (Process open FD table is full.)/ error. Shouldn't this increase file descriptors in conjunction with /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 389-ds itself. But I still can't get this to work, although it does not give an error. ldapmodify -x -D cn=directory manager -W EOF dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 65535 - replace: nsslapd-dtablesize nsslapd-dtablesize: 65535 - replace: nsslapd-reservedescriptors nsslapd-reservedescriptors: 100 EOF As you said in the original messages that you are dealing with FreeIPA 4.0.5, it means you are on a system with systemd. For it to change limits you have to do it differently. See /lib/systemd/system/dirsrv@.service for detailed instructions. from /lib/systemd/system/dirsrv@.service -- # if you need to set other directives e.g. LimitNOFILE=8192 # set them in this file .include /etc/sysconfig/dirsrv.systemd And that is the file that contains the LimitNOFILE=32768 So that was done. But it still seems to not make any difference since ns-slapd itself is still code to 8192. That is the issue I am facing - I can get beyond 8192. (even if 65535 is not used - although that was the limit used with OpenLDAP and no issues) ~J -- 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] strange replica install error (another one)
To help understand the environment a bit - perhaps this will help. 1. Approx 7500 clients across 3 datacenters- all manor of *nix, ranging from AIX, Linux, HP-UX and Solaris - hence the reason why they all can't use ipa-client configs. Although that is in the plan at least for Linux systems. 2. Servers/masters/replicas = 12 (4 each in 3 datacenters). Each DC has a primary CA so the replication agreements are between the 3 servers in each DC plus 1 server is a hot-spare and used strictly for replication to the other datacenters. 3. running out of FDs because there are 100s of jobs running across all the servers that do a lot of sudo and group lookups and more have to happen. Also, approx 1100 users accessing servers in vary random ways - but just using ssh/pssh/other-tools. Not sure if this helps - but perhaps? ~Janelle On 12/4/14 8:41 AM, Ludwig Krispenz wrote: On 12/04/2014 04:56 PM, Janelle wrote: Hi all, just (pam)auth and nslcd It was ported from a running OpenLDAP environment to IPA. Just trying to do conversions in stages so as not to change too much all at once. Thought I could go from OpenLDAP to IPA and just use the backend of 389ds. Functionally it does work, but the load kills it. Seems like FDs are a huge problem. But all the settings documented don't see to resolve the magic: / Netscape Portable Runtime error -5971 (Process open FD table is full.)/ error. Shouldn't this increase file descriptors in conjunction with /etc/sysconfig/dirsrv.systemd change? FS-limits across the OS are set to 65535 - /etc/security/limits.conf, /proc, sysctl.conf -- everything but 389-ds itself. But I still can't get this to work, although it does not give an error. ldapmodify -x -D cn=directory manager -W EOF dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-maxdescriptors nsslapd-maxdescriptors: 65535 - replace: nsslapd-dtablesize nsslapd-dtablesize: 65535 - replace: nsslapd-reservedescriptors nsslapd-reservedescriptors: 100 EOF there are two problems - how to increase the connetction table size in DS I would suggest to replace nsslapd-conntablesize and restart the server, the change is not dynamic - why you are running out of file descriptors you should query cn=monitor to check the effective tablesize and the number of established connections it could be a problem of clients not well behaving and not closing connections. you could set a low value of nsslapd-idletimeout to get rid of these connections Thanks ~J On 12/4/14 7:40 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 12/04/2014 09:41 AM, Rich Megginson wrote: On 12/04/2014 08:39 AM, Rich Megginson wrote: On 12/04/2014 01:45 AM, Petr Spacek wrote: On 4.12.2014 05:02, Janelle wrote: Thanks -- still a bit strange that it did not show up on some servers - vary random and intermittent. BTW - a bit of information others might find useful. If you try to use the LDAP portion of IPA for authentication - rather than fulling installing the IPA client and using Kerberos - the servers running ds-389 do not do well in handling the load. In other words - a few hundred hosts trying to authenticate via LDAP only will send CPU through the roof and crashes the slapd process often. That should not happen. For crashes, we would need to look at some stack traces: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes For situations when the CPU is through the roof, that is very similar to debugging hangs: http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-hangs Sorry, forgot to mention that since this is IPA you'll also need to install the ipa-debuginfo and slapi-nis-debuginfo packages. I would also add a question about your client configuration. For example if you use SSSD with enumerate=true for your clients then yes you will get your environment to the knees pretty quickly. I assumed SSSD wasn't being used at all which begs the question: what is? nss_ldap? Is nslcd being used? What is hitting LDAP, only auth or something else (e.g. sudo, automount). rob Since IPA is supposed to handle all options, I guess I am disappointed. regards ~J On 12/3/14 2:56 PM, Dmitri Pal wrote: On 12/03/2014 04:40 PM, Janelle wrote: Here is a bit of baffling one on 4.0.5: Replica install p11-kit??? This is a part of the DNSSEC set of packages. Connection from master to replica is OK. Connection check OK p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration ... Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: UNWILLING_TO_PERFORM database is read-only Thoughts? We need more information about your problem. As always, please start with information requested on http://www.freeipa.org/page/Troubleshooting#Reporting_bugs /var/log/ipa*.log from affected replica will be invaluable (along
[Freeipa-users] strange problem - IPA related?
Hi all.. Not sure if this is IPA related, but here it is: 1. IPA 4.1.2 install on CentOS 7 2. IPA 4.1.2 install on Fedora 21 So both systems are systemd based - the fedora system reboots in less than 30 seconds. The CentOS system reboots and has strange timers showing that it is waiting on various targets and servoces -- having trouble tracking it donw, but the bottom line is the CentOS 7 box takes almost 10-15 minutes to reboot. Thoughts? Ideas?? I know there is something in the startup that seems to MAYBE be related to the fedora-domain vs rhel-domain settings in some of the IPA python scripts -- or maybe not. Just thought I would see if anyone else is seeing something like this. ~J -- 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] strange problem - IPA related?
Identical configurations on the same subnet - using same DNS resolvers.. Both host-based FWs disabled just because I thought that too. Time to do some more studying of systemd and all the dependencies. ~J On 12/15/14 4:34 PM, Dmitri Pal wrote: On 12/15/2014 01:28 PM, Janelle wrote: Hi all.. Not sure if this is IPA related, but here it is: 1. IPA 4.1.2 install on CentOS 7 2. IPA 4.1.2 install on Fedora 21 So both systems are systemd based - the fedora system reboots in less than 30 seconds. The CentOS system reboots and has strange timers showing that it is waiting on various targets and servoces -- having trouble tracking it donw, but the bottom line is the CentOS 7 box takes almost 10-15 minutes to reboot. Thoughts? Ideas?? I know there is something in the startup that seems to MAYBE be related to the fedora-domain vs rhel-domain settings in some of the IPA python scripts -- or maybe not. Just thought I would see if anyone else is seeing something like this. ~J DNS timeouts? FW settings? -- 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] strange problem - IPA related?
That is indeed what it was -- thank you so much. Now they both boot in about 60 seconds. Gosh, keeping up with all the little annoyances is indeed a fulltime job. The team is doing great with the product and I truly appreciate all the work and quick responses on the mailing-list. ~J On 12/16/14 12:19 AM, Patrick Hurrelmann wrote: On 15.12.2014 19:28, Janelle wrote: Hi all.. Not sure if this is IPA related, but here it is: 1. IPA 4.1.2 install on CentOS 7 2. IPA 4.1.2 install on Fedora 21 So both systems are systemd based - the fedora system reboots in less than 30 seconds. The CentOS system reboots and has strange timers showing that it is waiting on various targets and servoces -- having trouble tracking it donw, but the bottom line is the CentOS 7 box takes almost 10-15 minutes to reboot. Thoughts? Ideas?? I know there is something in the startup that seems to MAYBE be related to the fedora-domain vs rhel-domain settings in some of the IPA python scripts -- or maybe not. Just thought I would see if anyone else is seeing something like this. ~J You are probably hitting: https://bugzilla.redhat.com/show_bug.cgi?id=1071969 For me this resulted in symted error messages on bootup and slowed the boot to 15-20min. Applying the following patch corrected this: https://git.fedorahosted.org/cgit/initscripts.git/commit/?h=rhel7-branchid=3deb3b3c177dd24b22cf912cd798aeaa7e35d30b I guess this is fixed in RHEL 7.1. Best regards Patrick -- 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] dirsrv password incorrect on replicas?
Good morning/evening All, So, another strange thing I see with 4.1.2 running on FC21 (server). On some replicas if I attempt to modify the 389-ds backend, I get credential errors. Even ldapsearch fails - which as me baffled. I am trying to tune the servers but this has me confused as to what might cause something like this and where to start looking for a solution? Here is the interesting part - when the server was intially replicated, I was able to make changes to 389-ds, but after a few days, credentials now show errors: ldapsearch -x -LLL -D cn=directory manager -b cn=monitor (objectclass=*) -W Enter LDAP Password: ldap_bind: Invalid credentials (49) Thoughts? ~J -- 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] dirsrv password incorrect on replicas?
I am looking at the 2 entries in dse.ldif - and indeed they are different. If I replace the one in question with the one from the working system, it works again. I did find - replica was created on Dec 11 at noon -- and the dse.ldif file CHANGED a day later?!? Going to have OSSEC monitor the folders for changes in files to see what the heck is going on and WHAT changed it and if it happens again. thanks for the help ~J On 12/18/14 10:28 AM, Rich Megginson wrote: On 12/18/2014 09:49 AM, Janelle wrote: Good morning/evening All, So, another strange thing I see with 4.1.2 running on FC21 (server). On some replicas if I attempt to modify the 389-ds backend, I get credential errors. Even ldapsearch fails - which as me baffled. I am trying to tune the servers but this has me confused as to what might cause something like this and where to start looking for a solution? Here is the interesting part - when the server was intially replicated, I was able to make changes to 389-ds, but after a few days, credentials now show errors: ldapsearch -x -LLL -D cn=directory manager -b cn=monitor (objectclass=*) -W Enter LDAP Password: ldap_bind: Invalid credentials (49) This doesn't make any sense. Directory manager passwords are not replicated, they are local to each machine. Directory manager passwords do not expire, and the error message is definitely incorrect password not password expired. There are no internal processes that touch directory manager or its password (unless there is something in ipa but I doubt it). So I have no idea how all of a sudden directory manager password stops working. You can't recover it, you can only reset it. http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html Thoughts? ~J -- 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] dirsrv password incorrect on replicas?
I am the only one who has access to these systems, so unless I did it in my sleep.. :-) ~J On 12/19/14 12:14 AM, Ludwig Krispenz wrote: On 12/18/2014 08:16 PM, Rich Megginson wrote: On 12/18/2014 11:59 AM, Janelle wrote: I am looking at the 2 entries in dse.ldif - and indeed they are different. If I replace the one in question with the one from the working system, it works again. I'm assuming by entry you are referring to nsslapd-rootpw in cn=config. I did find - replica was created on Dec 11 at noon -- and the dse.ldif file CHANGED a day later?!? The dse.ldif file changes all the time - unique id generator state, csn generator state, replication state, etc. etc. BUT - nsslapd-rootpw SHOULD NOT CHANGE no, except someone follows the steps to change it. Janelle, could it be that someone else was working on that server, not knowing the root pw and changing it in dse.ldif ? -- 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] forcing OTP ?
Hi all, I was playing around with the OTP app in 4.x and it is really nice. I wonder if there is a way to force some hosts require to use it, but not all the hosts from a server? I want some of the servers to be locked down more securely, but others can just require a password. thanks ~J -- 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] how to configure Linux Cent Os as ipa client manual installation
Hi everyone, Happy New Year. Was following this thread and wondering about those of us with a couple of 2000-3000 servers to run ipa-client-install on? Any suggestions? Was looking around for even the basics of puppet or chef configs, but nothing exists. Any suggestions? One of the concerns I have is, even with puppet/chef, you need credentials during the install to add the client on the server. Security? ~J On 1/5/15 3:27 AM, Martin Kosek wrote: On 12/29/2014 09:54 PM, Dmitri Pal wrote: On 12/20/2014 05:02 AM, Ben .T.George wrote: Hi I was trying to configure centos as ipa client and got failed with that,. anyone please help me to configure centos as ipa client through manual configuration. Regards, Ben Sorry for a delayed response. What version of CentOS? What version of the server? Why manually? On CentOS you can use ipa-client-install and it will do the work for you. What did you do and what did not work? You can find some info here: http://www.freeipa.org/page/Troubleshooting#Client_Installation If I read correctly, you are trying to do manual configuration. This may be a tricky procedure and is not tested regularly. ipa-client-install is the way to go in most deployments as it helps you avoid the pitfalls you probably hit. Martin -- 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] Where and how are passwords stored?
On 2/12/15 7:48 AM, Rich Megginson wrote: On 02/12/2015 08:38 AM, Michael Lasevich wrote: Thank you, this is very helpful. I forgot about 'super admin', which is why I was not even seeing the values before. :-) How are the the values encrypted (or hashed?) It sounds like the password is stored in two fields(I am leaving samba out for now) - userpassword andkerberos principle key. Is userpassword a hash? Of so, what kind? Salted SHA 140 by default. You can crank this all the way up to Salted SHA 512. Where would you change it to get sha512?? ~J -- 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] a fix - fedora domain vs rhel domain
Here is the snippet with the error: 2015-01-07T14:04:57Z DEBUG Adding CA certificates to the IPA NSS database. 2015-01-07T14:04:57Z DEBUG Starting external process 2015-01-07T14:04:57Z DEBUG args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-A' '-n' 'ANOTHER.COM IPA CA' '-t' 'CT,C,C' 2015-01-07T14:04:57Z DEBUG Process finished, return code=0 2015-01-07T14:04:57Z DEBUG stdout= 2015-01-07T14:04:57Z DEBUG stderr= 2015-01-07T14:04:57Z DEBUG Starting external process 2015-01-07T14:04:57Z DEBUG args='/usr/bin/update-ca-trust' 2015-01-07T14:04:58Z DEBUG Process finished, return code=1 2015-01-07T14:04:58Z DEBUG stdout= 2015-01-07T14:04:58Z DEBUG stderr=p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute p11-kit: failed to find certificates: The device is invalid or unrecognizable p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute p11-kit: failed to find certificates: The device is invalid or unrecognizable p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute p11-kit: failed to find certificates: The device is invalid or unrecognizable p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute p11-kit: failed to find certificates: The device is invalid or unrecognizable p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute p11-kit: failed to find certificates: The device is invalid or unrecognizable 2015-01-07T14:04:58Z ERROR Could not update systemwide CA trust database: Command ''/usr/bin/update-ca-trust'' returned non-zero exit status 1 2015-01-07T14:04:58Z DEBUG Attempting to add CA certificates to the default NSS database. 2015-01-07T14:04:58Z DEBUG Starting external process 2015-01-07T14:04:58Z DEBUG args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-A' '-n' 'ANOTHER.COM IPA CA' '-t' 'CT,C,C' 2015-01-07T14:04:58Z DEBUG Process finished, return code=255 2015-01-07T14:04:58Z DEBUG stdout= 2015-01-07T14:04:58Z DEBUG stderr=certutil: could not decode certificate: SEC_ERROR_REUSED_ISSUER_AND_SERIAL: You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. 2015-01-07T14:04:58Z ERROR Failed to add ANOTHER.COM IPA CA to the default NSS database. 2015-01-07T14:04:58Z WARNING Installation failed. As this is IPA server, changes will not be rolled back. On 1/7/15 7:19 AM, Martin Kosek wrote: On 01/07/2015 02:51 PM, Janelle wrote: Hello fellow IPAers I know this has been written about before - the python scripts and fedora-domain vs rhel-domain on RHEL/CentOs 7. The question is - was there a permanent fix yet? I continue to run into it during installs and have to edit python files to get the client install to not error out duruing the server install. This is of course with CentOS 7 and IPA 4.1.2. Any options/comments? Thank you Janelle (install snippet) Done. Restarting the directory server Restarting the KDC Restarting the certificate server Sample zone file for bind has been created in /tmp/sample.zone.vTMlCB.db Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'another.com' '--server' 'ipa1.another.com' '--realm' 'ANOTHER.COM' '--hostname' 'ipa1.another.com'' returned non-zero exit status 1 Hi Janelle, Yes, this should have been resolved in https://fedorahosted.org/freeipa/ticket/4562 CCing Jan. Are you sure it is caused by this problem? Can you add a snippet of the ipaclient-install.log with the actual failures? Your install snippet does not help that much. Can you please also check that you have the right FreeIPA platform file loaded? At least giving us output from this grep should help: $ grep domainname /usr/lib/python2.7/site-packages/ipaplatform/services.py Thanks, Martin -- 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] a fix - fedora domain vs rhel domain
Indeed you are correct - it was NOT the problem. Double checking the logs - showed an old ca.crt file from a previous install (something that should be done in the uninstall jobs - remove ALL the old folders, including /etc/ipa which has old certs, etc.) Thanks for the tip to look elsewhere - I made a bad assumption. Janelle On 1/7/15 7:19 AM, Martin Kosek wrote: On 01/07/2015 02:51 PM, Janelle wrote: Hello fellow IPAers I know this has been written about before - the python scripts and fedora-domain vs rhel-domain on RHEL/CentOs 7. The question is - was there a permanent fix yet? I continue to run into it during installs and have to edit python files to get the client install to not error out duruing the server install. This is of course with CentOS 7 and IPA 4.1.2. Any options/comments? Thank you Janelle (install snippet) Done. Restarting the directory server Restarting the KDC Restarting the certificate server Sample zone file for bind has been created in /tmp/sample.zone.vTMlCB.db Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'another.com' '--server' 'ipa1.another.com' '--realm' 'ANOTHER.COM' '--hostname' 'ipa1.another.com'' returned non-zero exit status 1 Hi Janelle, Yes, this should have been resolved in https://fedorahosted.org/freeipa/ticket/4562 CCing Jan. Are you sure it is caused by this problem? Can you add a snippet of the ipaclient-install.log with the actual failures? Your install snippet does not help that much. Can you please also check that you have the right FreeIPA platform file loaded? At least giving us output from this grep should help: $ grep domainname /usr/lib/python2.7/site-packages/ipaplatform/services.py Thanks, Martin -- 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] a fix - fedora domain vs rhel domain
Hello fellow IPAers I know this has been written about before - the python scripts and fedora-domain vs rhel-domain on RHEL/CentOs 7. The question is - was there a permanent fix yet? I continue to run into it during installs and have to edit python files to get the client install to not error out duruing the server install. This is of course with CentOS 7 and IPA 4.1.2. Any options/comments? Thank you Janelle (install snippet) Done. Restarting the directory server Restarting the KDC Restarting the certificate server Sample zone file for bind has been created in /tmp/sample.zone.vTMlCB.db Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'another.com' '--server' 'ipa1.another.com' '--realm' 'ANOTHER.COM' '--hostname' 'ipa1.another.com'' returned non-zero exit status 1 -- 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] pki-tomcatd stopped responding? Won't restart?
On 3/17/15 12:14 PM, Dmitri Pal wrote:
On 03/17/2015 12:12 PM, Janelle wrote:
On 3/17/15 9:06 AM, Martin Kosek wrote:
On 03/17/2015 04:35 PM, Janelle wrote:
Hello,
I have a server - a master (has CA) - and it does not want to
restart after it
has been running sometime. pki-tomcatd keeps failing. It starts up
with these
errors, then adds a lot more. Maybe this might point you to
something that is
know or a place I can start looking?
Any ideas?
~J
Mar 17, 2015 8:21:03 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'enableOCSP' to 'false' did not find a matching property.
Mar 17, 2015 8:21:03 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp'
did not find
a matching property.
Mar 17, 2015 8:21:03 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did
not find a
matching property.
Mar 17, 2015 8:21:03 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'ocspCacheSize' to '1000' did not find a matching property.
Mar 17, 2015 8:21:03 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'ocspMinCacheEntryDuration' to '60' did not find a matching property.
Mar 17, 2015 8:21:03 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'ocspMaxCacheEntryDuration' to '120' did not find a matching property.
Mar 17, 2015 8:21:03 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'ocspTimeout' to '10' did not find a matching property.
Mar 17, 2015 8:21:03 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'strictCiphers' to 'true' did not find a matching property.
Mar 17, 2015 8:21:03 AM
org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting
property
'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a
matching property.
CCing folks from Dogtag team to know about this issue. However, I
think you
will need to provide more information before we continue with issues
- like
version of FreeIPA, pki-ca packages, what system you are running it on
(Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere
(system and
catalina.out logs are usually most interesting ones).
My bad --
CentOS 7
FreeIPA 4.1.3 from mosek
The strange thing is -- 12 other servers - 3 of which are CA masters
and no issues,
~J
Just some areas to check:
- versions of dogtag package
- versions of nss package
pki-tools-10.1.2-7.1.el7.centos.x86_64
dogtag-pki-server-theme-10.1.1-1.el7.centos.noarch
pki-server-10.1.2-7.1.el7.centos.noarch
krb5-pkinit-1.12.2-9.el7.centos.x86_64
pki-base-10.1.2-7.1.el7.centos.noarch
pki-ca-10.1.2-7.1.el7.centos.noarch
mod_nss-1.0.8-32.el7.x86_64
nss-sysinit-3.16.2.3-2.el7_0.x86_64
python-nss-0.15.0-1.el7.centos.x86_64
nss-softokn-3.16.2.3-1.el7_0.x86_64
nss-softokn-freebl-3.16.2.3-1.el7_0.x86_64
nss-tools-3.16.2.3-2.el7_0.x86_64
nss-util-3.16.2.3-1.el7_0.x86_64
nss-3.16.2.3-2.el7_0.x86_64
Anything? All the servers are identical.
~J
--
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] multiple ssh keys?
Hello, I was wondering, I don't seem to be able to put multiple SSH keys into IPA? Am I missing something? it seems to replace the one that was there instead of adding an additional. ~J -- 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] Replica install fails at client install
On 3/18/15 10:10 PM, Kim Perrin wrote:
This is about the 6th time of tried installing this replica. Each time
I run the ipa-replica-manage del and ipa-csreplica-manage del command
before trying. I also build new replica install files each time.
Obviously I can't figure out what the problem is. I've tried a variety
of things. I'm hoping someone in this community has been this before
and solved the issue.
At the end of the install I see the client install failure messages,
though it appeared as though the server install went well. However it
is clear it has not gone well because when I run 'service ipa status'
I get this
root@noc5-prd:/var/log# service ipa status
Directory Service: RUNNING
Unknown error when retrieving list of services from LDAP: {'info':
'SASL(-4): no mechanism available: ', 'desc': 'Unknown authentication
method'}
I've attached the ipareplica-install.log file. Here are some relevant
entries from the end of the log -
2015-03-19T04:33:02Z DEBUG args=/usr/sbin/ipa-client-install
--on-master --unattended --domain companyz.com --server
noc5-prd.companyz.com --realm COMPANYZ.COM
2015-03-19T04:33:02Z DEBUG stdout=
2015-03-19T04:33:02Z DEBUG stderr=Hostname: noc5prd.companyz.com
Realm: COMPANYZ.COM
DNS Domain: companyz.com
IPA Server: noc5-prd.companyz.com
BaseDN: dc=companyz,dc=com
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
trying https://noc5-prd.companyz.com/ipa/xml
trying https://noc1-prd.companyz.com/ipa/xml
Connection to https://noc1-prd.companyz.com/ipa/xml failed with [Errno
-8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in
use.
Cannot connect to the server due to generic error: cannot connect to
Gettext('any of the configured servers', domain='ipa',
localedir=None): https://noc5-prd.companyz.com/ipa/xml,
https://noc1-prd.companyz.com/ipa/xml
Installation failed. Rolling back changes.
Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to
/etc/sssd/sssd.conf.deleted
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Client uninstall complete.
2015-03-19T04:33:02Z INFO File
/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py,
line 614, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 536, in main
raise RuntimeError(Failed to configure the client)
2015-03-19T04:33:02Z INFO The ipa-replica-install command failed,
exception: RuntimeError: Failed to configure the client
Anyone have any advice?
There are 2 possibilities here. One is you have the old python package
scripts which have a bug in these files:
/usr/lib/python2.7/site-packages/ipaplatform/fedora/services.py
/usr/lib/python2.7/site-packages/ipaplatform/services.py
They most likely have fedora-domain in them and it needs to be changed
to rhel-domain. The other option is to re-install the OS and freeipa
environment, which gets you to clean packages. Deleting and
re-installing all the python packages is painful at best.
The other possibility is stale certs:
certutil -d /etc/pki/nssdb -L
You will probably see a stale cert. Remove it.
certutil -d /etc/pki/nssdb -D -n IPA CA
I have run into both of these issues about 1 million times so far.
~J
--
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] stupid question - 389-ds
Hello again, Ok, probably a stupid question. If you increase cache sizes and tune 389-ds on the backend, do those changes replicate or do you need to make them across the other servers as well? For example: dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dbcachesize nsslapd-dbcachesize: 2147483648 ~J -- 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] pki-tomcatd stopped responding? Won't restart?
On 3/17/15 9:06 AM, Martin Kosek wrote:
On 03/17/2015 04:35 PM, Janelle wrote:
Hello,
I have a server - a master (has CA) - and it does not want to restart after it
has been running sometime. pki-tomcatd keeps failing. It starts up with these
errors, then adds a lot more. Maybe this might point you to something that is
know or a place I can start looking?
Any ideas?
~J
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'enableOCSP' to 'false' did not find a matching property.
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' did not find
a matching property.
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a
matching property.
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspCacheSize' to '1000' did not find a matching property.
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspMinCacheEntryDuration' to '60' did not find a matching property.
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspMaxCacheEntryDuration' to '120' did not find a matching property.
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'ocspTimeout' to '10' did not find a matching property.
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'strictCiphers' to 'true' did not find a matching property.
Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin
WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property
'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a matching property.
CCing folks from Dogtag team to know about this issue. However, I think you
will need to provide more information before we continue with issues - like
version of FreeIPA, pki-ca packages, what system you are running it on
(Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere (system and
catalina.out logs are usually most interesting ones).
My bad --
CentOS 7
FreeIPA 4.1.3 from mosek
The strange thing is -- 12 other servers - 3 of which are CA masters and
no issues,
~J
--
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] ID Range question
Hello, I have seen this pop up a few times, but no real answers - at least none that I am finding.. I have not run into it and this was a brand new server farm with about 4000 migrated users from OpenLDAP? Is there something I might be missing when migrating? ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. and of course - the classic 1100 - 1101... # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: Posix IDs dnaType: uidNumber dnaType: gidNumber dnaNextValue: 1101 dnaMaxValue: 1100 dnaMagicRegen: -1 ~J -- 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] ID Range question
That makes perfect sense. I lost a connection to the master. I can fix that. Thank you! ~J On 3/24/15 3:26 PM, Rob Crittenden wrote: Janelle wrote: Hello, I have seen this pop up a few times, but no real answers - at least none that I am finding.. I have not run into it and this was a brand new server farm with about 4000 migrated users from OpenLDAP? Is there something I might be missing when migrating? ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. and of course - the classic 1100 - 1101... # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: Posix IDs dnaType: uidNumber dnaType: gidNumber dnaNextValue: 1101 dnaMaxValue: 1100 dnaMagicRegen: -1 I'm guessing you removed the master that spawned this one. This is the initial DNA config where max next so it should ask the master that created it for a range. See http://blog-rcritten.rhcloud.com/?p=50 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
Re: [Freeipa-users] anonymous binds limits?
For LDAP-only clients, I see an issue with performance on the dirsrv backends, and much of it has to do with 2 things: 1. Anonymous binds (1000's because of 7000+ hosts) 2. unindexed searches -- perhaps the biggest problem and working on troubleshooting that and figuring out how to fix it. Thank you ~J On 3/29/15 8:38 PM, Dmitri Pal wrote: On 03/27/2015 08:22 PM, Janelle wrote: Hello, Just wondering if there is an easy way to increase anonymous binds on the back end for non Kerberos clients? I have seen some mention of it, and that IPA has limits, can't can't find a lot of detail? Thank you ~J I am not sure I understand what you are asking. What do you mean by increase anonymous binds ? Increase timeout? Or you want to allow anonymous binds? -- 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] where to disable components?
Hello again... Looking around, but probably just not in the right place. I would like to be able to disable httpd on all but a pair of servers, so we kind of force all updates to come from a master and slave pair. Just trying to keep updates defined to 2 servers rather than all of them in an 8 server configuration. Where might I find that? Or is it possible? Will it break anything? thank you ~J -- 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] RUVs
Hello again, This is a more general question as I am new to dirsrv a bit. I have read through a lot of the docs, including 389-ds, but with regards to IPA, well, I am not 100% clear and perhaps this could help others in the future. Are there guidelines or suggestions for RUV's and cleaning and how to know when you are actually seeing a problem that needs to be fixed? In a good system, for example, my 8 servers, if there are no issues, what would I expect to see from a list-ruv? What errors would indicate the need to run a clean-ruv id? I am thinking if there was a write up or FAQ for this, it would go a long way to helping new admins with FreeIPA in understanding all of this. Just a suggestion. Thank you ~J -- 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] Unexpired pw?
Hi all, Found an odd issue and a question. If you change user pw with ipa user-mod -password and the client is configured for LDAP, then the user is not forced to change the pw on initial login. However, my other question is, can you set a user pw WITHOUT pre-expiring?! ~J -- 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] Migration mode fun and confusion
On 3/31/15 6:49 AM, Dmitri Pal wrote: On 03/31/2015 09:38 AM, Janelle wrote: Hello again, Is this a feature or a bug? Migration mode - works fine the first time. However, if you need to run it a second time because someone added either new users or groups to your LDAP config and you want to bring those over, if you re-run migration, it indeed brings all the new users over, but NOT their secondary groups, only primary. And even if you have overwrite of the GID option set. Would this be expected for some reason that I may be missing, or is it a bug? Thank you ~J Let be know if I get you right. That's it exactly. Ok - Bug. :-) Setup: - Old LDAP server - IPA Users are migrated from LDAP to IPA using migrate-ds. Everything works as expected Now you add users to LDAP and put them into some groups (that were already been migrated the first time, right?) You run migrate-ds again and the new users are migrated but group membership is lost. Is this the scenario? If yes, looks like a bug. -- 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] Migration mode fun and confusion
Hello again, Is this a feature or a bug? Migration mode - works fine the first time. However, if you need to run it a second time because someone added either new users or groups to your LDAP config and you want to bring those over, if you re-run migration, it indeed brings all the new users over, but NOT their secondary groups, only primary. And even if you have overwrite of the GID option set. Would this be expected for some reason that I may be missing, or is it a bug? Thank you ~J -- 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] What am I missing? ipaca?
On 3/23/15 4:04 AM, Martin Kosek wrote: On 03/23/2015 04:07 AM, Janelle wrote: Hello Starting to see a lot of these and wondering what I am dealign with? attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. Hm, I do not met this error yet. This looks like error from 389-ds-base, it has functions like attrlist_replace. If this is the case, can you please share a bigger section of the errors log, ideally for the whole day (if not too big)? There might be some other related error messages. CCing Ludwig and Thierry for reference. Also, what environment are we talking about, is this still FreeIPA 4.1.3@CentOS-7? Maybe the server also has a replication agreement also with CentOS-6? We need to know this also. Thanks, Martin FreeIPA 4.1.3, CentOS 7 Only CentOS 7 -- no other versions intermixed. Nothing else to give you. Sadly, it just repeats alot. No other errrors in the log. It has a replication agreement with another master - both CA's One interesting note -- this was the server that had the ipa-replica-install --setup-ca run on it from the other master. And the other master is ipa1 server. This server that has these errors is ipa2. So this is complaining(?) that the original server is doing something? [23/Mar/2015:04:13:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:23:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:23:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:23:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:28:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:28:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:28:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:38:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:38:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:38:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:43:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:43:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:43:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:53:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:53:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:53:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:58:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:58:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:58:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:00:00 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:00:00 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:00:00 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:05:02 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:05:02 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:05:02 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:08:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:08:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:08:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:13:52 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed
[Freeipa-users] What am I missing? ipaca?
Hello Starting to see a lot of these and wondering what I am dealign with? attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. ~J -- 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] issues with secondary groups? (sssd)
That was the point. The clients were not installed with IPA client install. I have 2000 clients and still working on a simple way to automate the client install with ansible or puppet. Currently just trying to get it working with simple sssd/ldap only auth. ~J On Mar 2, 2015, at 01:12, Jakub Hrozek jhro...@redhat.com wrote: On Sat, Feb 28, 2015 at 11:07:20AM -0800, Janelle wrote: Hello, I was wondering - I have searched around and seen a few questions and solutions, but nothing I try is fixing my environment. Things have been working quite well with IPA 4.0.5, simple things with auth and logins - some with full ipa-client-install configured, others just using LDAP and that is where the strangeness comes from. with full IPA client integration, secondary groups work just find, as do base commands like id and getent. However, the ldap users, never show the secondary group for their uid? Any pointers you might suggest? I have tried the sssd.conf of ldap_group_member = uniqeMember - no change. a simple secondary group is defined: dn: cn=web_users,cn=groups,cn=accounts,dc=example,dc=com cn: web_users objectClass: ipaobject objectClass: extensibleobject objectClass: top objectClass: ipausergroup objectClass: posixgroup objectClass: groupofnames objectClass: nestedgroup memberUid: user1 memberUid: user2 memberUid: user3 memberUid: user4 memberUid: user5 member: uid=user1,cn=users,cn=accounts,dc=example,dc=com member: uid=user2,cn=users,cn=accounts,dc=example,dc=com member: uid=user3,cn=users,cn=accounts,dc=example,dc=com member: uid=user4,cn=users,cn=accounts,dc=example,dc=com member: uid=user5,cn=users,cn=accounts,dc=example,dc=com and yet with debug_level = 7 -- sssd still says: [sdap_process_ghost_members] (0x0400): Group has 0 members Was the client installed with ipa-client-install? There I would suggest to just use the defaults and everything should work. Can you try again, this time with default configuration of id_provider=ipa ? You might need to clear the cache (rm /var/lib/sss/db/cache_*) if you were playing around with the schema.. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] issues with secondary groups? (sssd)
Hello, I was wondering - I have searched around and seen a few questions and solutions, but nothing I try is fixing my environment. Things have been working quite well with IPA 4.0.5, simple things with auth and logins - some with full ipa-client-install configured, others just using LDAP and that is where the strangeness comes from. with full IPA client integration, secondary groups work just find, as do base commands like id and getent. However, the ldap users, never show the secondary group for their uid? Any pointers you might suggest? I have tried the sssd.conf of ldap_group_member = uniqeMember - no change. a simple secondary group is defined: dn: cn=web_users,cn=groups,cn=accounts,dc=example,dc=com cn: web_users objectClass: ipaobject objectClass: extensibleobject objectClass: top objectClass: ipausergroup objectClass: posixgroup objectClass: groupofnames objectClass: nestedgroup memberUid: user1 memberUid: user2 memberUid: user3 memberUid: user4 memberUid: user5 member: uid=user1,cn=users,cn=accounts,dc=example,dc=com member: uid=user2,cn=users,cn=accounts,dc=example,dc=com member: uid=user3,cn=users,cn=accounts,dc=example,dc=com member: uid=user4,cn=users,cn=accounts,dc=example,dc=com member: uid=user5,cn=users,cn=accounts,dc=example,dc=com and yet with debug_level = 7 -- sssd still says: [sdap_process_ghost_members] (0x0400): Group has 0 members and id or getent of any of user1..5 just returns the primary GID. Any ideas? Tips? What else might you want to see? ~J -- 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] anonymous binds limits?
Hello, Just wondering if there is an easy way to increase anonymous binds on the back end for non Kerberos clients? I have seen some mention of it, and that IPA has limits, can't can't find a lot of detail? Thank you ~J -- 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] understanding RUVs?
Hello, When I was working with OpenLDAP, and AD - and did not deal with RUVs the way I am with 389-ds and IPA. I am trying to understand what is normal for values. If I am looking at this (and seem to have no replication problems): ipa-replica-manage list-ruv ipa001.example.com:389: 13 ipa002.example.com:389: 12 ipa003.example.com:389: 11 ipa004.example.com:389: 10 ipa005.example.com:389: 7 ipa006.example.com:389: 6 ipa007.example.com:389: 5 ipa008.example.com:389: 3 ipa009.example.com:389: 16 ipa00a.example.com:389: 17 ipa00b.example.com:389: 15 ipa00c.example.com:389: 14 ipa00d.example.com:389: 9 ipa00e.example.com:389: 8 ipa00f.example.com:389: 4 I guess I was wondering, should I be seeing all the same values or should they all be unique based on being replicated and the order they were added? Or is it telling me something else? Sorry, I guess I am still trying to wrap my head around replication metadata. Thank you ~J -- 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] group membership listing?
Hello - and happy day before Earth Day, Perhaps this is an easy one and related to replication, BUT: $ id some-user-name If I run that on every IPA master, should the listing not be identical? In other words, the listing of the uid, gid and groups, should show up in exactly the same order? uid=12345(some-user) gid=101(agroup) groups=101(agroup), 102(another), 103(another2) What if one replica listed it as: uid=12345(some-user) gid=101(agroup) groups=101(agroup), 103(another2), 102(another) But all the others listed as the first line? Is that indication of a problem? Janelle -- 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] 4.1.4 and OTP
On 4/28/15 6:44 AM, Nathaniel McCallum wrote: On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote: On 4/17/15 5:59 PM, Dmitri Pal wrote: On 04/17/2015 08:07 PM, Janelle wrote: On Apr 17, 2015, at 16:36, Dmitri Pal d...@redhat.com wrote: On 04/17/2015 04:52 PM, Janelle wrote: On 4/17/15 1:19 PM, Dmitri Pal wrote: On 04/17/2015 01:20 PM, Janelle wrote: On 4/17/15 9:53 AM, Dmitri Pal wrote: On 04/17/2015 11:16 AM, Janelle wrote: Hi, Is anyone else having issues with OTP since upgrading? For the life of me I can't get it to accept Sync for the tokens. No matter what is put in, it just keeps saying the username, password or tokens entered are incorrect. To make it simple - I am tryign this on a brand new CentOS 7.1 system with a clean/fresh install of FreeIPA 4.1.4 and yet it just refuses to work. I create a user -- configure them. They work just fine with a password. Then add a token. Sync with FreeOTP and that all works. Then going back to the web UI and do Sync OTP and it simply refuses to accept any values. And yet the same user can login to the regular web UI with their password. I have tried setting the user to both Password and OTP for auth methods. And also just OTP and nothing works. Please look in the logs to see what is going on. You would need to look at the KDC, http and DS logs on the server to sort out what is going on. Do you change the password for the user first after creating him? Can you reproduce the problem with demo instance? http://www.freeipa.org/page/Demo If you can then we can take a look at the logs right away. Hints? Am I missing a step? ~J It appears to be the UI. If I go through the steps and let it fail, I can still login using OTP to servers. I made the assumption that the error itself was not an error.. :-) ~J I am not sure I get what you are saying. Do you still see the problem or you misinterpreted the UI and now the problem is gone? If you did is there any recommendation how to improve the UI not to confuse people? The problem exists -- this is what it shows: HOWEVER, it is still WORKING. Meaning, even if you get this error, if you attempt to login with your FreeOTP token, it WORKS. ~J mime-attachment.png Does it give you this error when you use password or password and token? Can you please describe the flow of steps in more details? I start browser, go here, click here, enter this, etc. Are you using SSSD to login to servers? Is SSSD configured with IPA provider or you configured it for LDAP manually. There is a difference between LDAP and Kerberos authentication. May be the following article will help you to understand the expectations: https://access.redhat.com/documentation/en -US/Red_Hat_Enterprise_Linux/7/html/System -Level_Authentication_Guide/authconfig-addl-auth.html#enable -otp Simple. And my test made it simple. Stand up new vm running fc21/freeipa. Configure user. Add password. Add token. Login to the vm with the user created using password. Kerberos ticket assigned, all is well. Login to web interface with admin. Change user to OTP only. Go to web UI and click sync OTP. Enter username, password and 2 OTP sequences. Click sync. Error appears. Now, ssh to same vm using OTP username. Enter password + OTP value. Login successful. I can reproduce this issue with demo instance. I will file a bug later today. I think it is a bug with sync. Which token do you use time based or event based? TOTP... Hmm, makes me wonder - with HOTP fail the same? Off to try it. This should just affect TOTP. I have posted a patch that should fix this problem. Are you able to test it? https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html I shall give it a try and let you know. ~J -- 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] CA replicas on all?
Hi all, Just wondering if there are issues with running CA replicas on all the servers? Are there maybe performance issues or anything that I might not be aware of? ~Janelle -- 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] interesting Kerberos issue
Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? ~J -- 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] PWM and IPA
Hi all, Just wondering if anyone has put together a guide for integrating PWM with IPA? I know there is a section on 389-ds, but that is kind of raw-389 and not the highly modified-for-IPA 389-ds. I would like to set this up for my users, but really don't want to do it using that guide unless that is what others might suggest? Any suggestions? ~J -- 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] interesting Kerberos issue
On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH password and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J -- 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] more replication fun
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009 55402c390009
I am hoping this is a stupid question with a really simple answer that I am
simply missing?
~J
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I think
I have had replication issues 5 times. In the 6 months of working with
FreeIPA, replication issues are constant. From reading the threads, I am
not the only one in this predicament. Is there any history on why
replication is so problematic in FreeIPA?
regards
~J
--
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] more replication fun
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009 55402c390009
I am hoping this is a stupid question with a really simple answer that I
am simply missing?
~J
--
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] more replication fun
On 5/7/15 12:59 AM, thierry bordaz wrote:
On 05/07/2015 05:39 AM, Janelle wrote:
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com
wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove these?
unable to decode: {replica 9} 553ef80e00010009
55402c390009
I am hoping this is a stupid question with a really simple answer
that I am simply missing?
~J
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I
think I have had replication issues 5 times. In the 6 months of
working with FreeIPA, replication issues are constant. From reading
the threads, I am not the only one in this predicament. Is there any
history on why replication is so problematic in FreeIPA?
regards
~J
Hi Janelle,
This is a large question and I have no precise answer. My
understanding of OpenLDAP replication vs RHDS replication is that
it is not based on the same approach syncrepl vs
replica_agreement. Both are working. Replication is complex and
when I compare RHDS with others DS implementation using the same
approach (replica_agreement) I can say that RHDS is doing a good
job in terms of performance, stability and robustness.
Replication is sensitive to administrative tasks, backup-restore,
reinit, upgrade, schema update. This is possibly your case we have
seen 'unable to decode' during upgrade/cleanruv and still
investigating that bug.
thanks
thierry
All of this makes good sense - in fact, even the OpenLDAP vs 389-ds
issues and replication. Yes, in the environment I had, there were a
couple of masters, and the reset were read-only, which meant keeping in
sync - easy.
Now, I was looking through the archives and can't seem to find the
recommended way to delete one of these:
unable to decode {replica 22} 553eec6400040016 553eec6400040016
I think someone mentioned a script, but I can't find it. I have
several replicas in this state and would like to try and clean them up.
The interesting thing is - the replicas in this state seem to have a
higher CPU load as based on uptime. Interesting.
Thanks
~J
--
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] more replication fun
On 5/8/15 8:43 AM, Ludwig Krispenz wrote:
On 05/08/2015 05:30 PM, Rob Crittenden wrote:
Janelle wrote:
On 5/7/15 12:59 AM, thierry bordaz wrote:
On 05/07/2015 05:39 AM, Janelle wrote:
On 5/6/15 8:12 PM, Vaclav Adamec wrote:
Hi,
Mike Reynolds recommend cleanallruv script (IPA RUV unable to
decode
thread), if you are sure that's not any live replica server behind
this id than just try cleanallruv.pl -w X -b dc= -r 9
Vasek
On Thu, May 7, 2015 at 2:25 AM, Janelle janellenicol...@gmail.com
wrote:
Hi again..
Seems to be an ongoing theme (replication). How does one remove
these?
unable to decode: {replica 9} 553ef80e00010009
55402c390009
I am hoping this is a stupid question with a really simple answer
that I am simply missing?
~J
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Thank you Vasek,
I am curious however. I have been running OpenLDAP configs with 20 or
more servers in replication for over 5 years. In all that time, I
think I have had replication issues 5 times. In the 6 months of
working with FreeIPA, replication issues are constant. From reading
the threads, I am not the only one in this predicament. Is there any
history on why replication is so problematic in FreeIPA?
regards
~J
Hi Janelle,
This is a large question and I have no precise answer. My
understanding of OpenLDAP replication vs RHDS replication is that
it is not based on the same approach syncrepl vs
replica_agreement. Both are working. Replication is complex and
when I compare RHDS with others DS implementation using the same
approach (replica_agreement) I can say that RHDS is doing a good
job in terms of performance, stability and robustness.
Replication is sensitive to administrative tasks, backup-restore,
reinit, upgrade, schema update. This is possibly your case we have
seen 'unable to decode' during upgrade/cleanruv and still
investigating that bug.
thanks
thierry
All of this makes good sense - in fact, even the OpenLDAP vs 389-ds
issues and replication. Yes, in the environment I had, there were a
couple of masters, and the reset were read-only, which meant keeping in
sync - easy.
Now, I was looking through the archives and can't seem to find the
recommended way to delete one of these:
unable to decode {replica 22} 553eec6400040016
553eec6400040016
I think someone mentioned a script, but I can't find it. I have
several replicas in this state and would like to try and clean them up.
The interesting thing is - the replicas in this state
seehttps://www.redhat.com/archives/freeipa-users/2015-May/msg00062.htmlm
to have a
higher CPU load as based on uptime. Interesting.
Thanks
~J
See https://www.redhat.com/archives/freeipa-users/2015-May/msg00062.html
hopefully it does, if not maybe Mark can help to get rid of it
It would be nice to know if this style of RUV could be acted on by
ipa-replica-manage. I added this bit as a catch-all so no RUV would
be invisibly skipped if it didn't match the regex I wrote. If this
kind of RUV could indeed still be cleaned it would be nice to know
and we could make that possible.
I think this kind of RUV should never exist, strange enough we have a
hard time to reproduce it in the lab, but out in the real world they
seem to proliferate.
Any help to reproduce is greatly appreciated.
Ludwig
rob
That little ldapmodify - did indeed do the trick In fact, it seemed to
replicate the clean correctly and it disappeared from all my replicas
in a few seconds.
Let me see if I can reproduce in my lab.
Thank you
~J
--
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] interesting Kerberos issue
On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH password and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to kinit --kdc-hostname=IPA-server principal and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Thank you Janelle -- 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] interesting Kerberos issue
On 5/4/15 1:02 PM, Simo Sorce wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? Have you recently changed the user password ? If so this symptom may indicate you are having replication issues between your servers, and one of the client is hitting the server that didn't get the keys replicated to it. Simo. None of the above -- All the servers are replicated. The user account (a test account) has not changed PW in weeks and works everywhere else. I nee to increase some logging. I guess the strange part is as mentioned -- it works if you login directly to the 7.1 client, no matter which server it is pointed at. ~J -- 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] interesting Kerberos issue
On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Apparently I am not being clear. The user account can login all over the place with no problems -- RHEL 7.1 or 6.6. HOWEVER, on 7.1, a login provides a direct tgt, but no matter what you do on any other host using kinit (after logging in with an SSH key perhaps or as another user) and even know the password, you get this error. Again, logging in with the password, not OTP, works just fine. Confusing, ~J -- 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] more replication issues
On 5/15/15 3:30 AM, Ludwig Krispenz wrote: On 05/13/2015 06:34 PM, Janelle wrote: On 5/13/15 9:13 AM, Rich Megginson wrote: On 05/13/2015 10:04 AM, Janelle wrote: On 5/13/15 8:49 AM, Rich Megginson wrote: On 05/13/2015 09:40 AM, Janelle wrote: Recently I started seeing these crop up across my servers: slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) Does that entry exist? ldapsearch -xLLL -h consumer.host -D cn=directory manager -W -s base -b cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config Does the parent exist? ldapsearch -xLLL -h consumer.host -D cn=directory manager -W -s base -b ou=csusers,cn=config I am finding that there does seem to be a relation to the above error and a possible CSN issue: Can't locate CSN 555131e500020019 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. I guess what concerns me is what could be causing this. We don't do a lot of changes all the time. And in answer to the question above - we seem to have last the agreement somehow: No such object (32) Is there a DEL operation in the access log for cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config? maybe something like # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i Replication Manager nope -- none of the servers have it. your original message is very clear: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) this means that you have replication agreement wth SIMPLE auth which uses a nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config which does not exist on the target server of the agreement. Now you say it was never deleted, so it was probably never added, but used in the replication agreements. How do you manage and setup replication agreements ? All replicas are configred simply: ipa-replica-prepare hostname... scp .. ipa-replica-install --no-ntp --setup-ca Replica-file That is it. NTP is not set because internal NTP servers are used. All replicas are CA replicas for safety (no certs are managed) After a few days to a week the message starts popping up in logs. ~J -- 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] more replication issues
On May 15, 2015, at 08:57, Ludwig Krispenz lkris...@redhat.com wrote: On 05/15/2015 02:45 PM, Janelle wrote: On 5/15/15 3:30 AM, Ludwig Krispenz wrote: On 05/13/2015 06:34 PM, Janelle wrote: On 5/13/15 9:13 AM, Rich Megginson wrote: On 05/13/2015 10:04 AM, Janelle wrote: On 5/13/15 8:49 AM, Rich Megginson wrote: On 05/13/2015 09:40 AM, Janelle wrote: Recently I started seeing these crop up across my servers: slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) Does that entry exist? ldapsearch -xLLL -h consumer.host -D cn=directory manager -W -s base -b cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config Does the parent exist? ldapsearch -xLLL -h consumer.host -D cn=directory manager -W -s base -b ou=csusers,cn=config I am finding that there does seem to be a relation to the above error and a possible CSN issue: Can't locate CSN 555131e500020019 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. I guess what concerns me is what could be causing this. We don't do a lot of changes all the time. And in answer to the question above - we seem to have last the agreement somehow: No such object (32) Is there a DEL operation in the access log for cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config? maybe something like # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i Replication Manager nope -- none of the servers have it. your original message is very clear: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) this means that you have replication agreement wth SIMPLE auth which uses a nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config which does not exist on the target server of the agreement. Now you say it was never deleted, so it was probably never added, but used in the replication agreements. How do you manage and setup replication agreements ? All replicas are configred simply: ipa-replica-prepare hostname... scp .. ipa-replica-install --no-ntp --setup-ca Replica-file That is it. NTP is not set because internal NTP servers are used. All replicas are CA replicas for safety (no certs are managed) ok, I was a bit puzzled because ipa uses ldapprincipals and gssapi for the main suffix replication. But I just verified that after ipa-replica-install --setup-ca CA replication is setup with users in ou=csusers,cn=config and uses it as replica binddn, I have no idea why it would disappear. when Rich asked to search for a DEL, did you check this on the server that logged the message or on the endpoint of the replication agreement (it should be there), and you may have to check in the rotated access logs access.timestamp as well Checked it on ALL servers just to be sure. ~J -- 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] 4.1.4 and OTP
On May 18, 2015, at 04:31, Martin Kosek mko...@redhat.com wrote: On 05/18/2015 01:49 AM, Janelle wrote: On 4/28/15 6:44 AM, Nathaniel McCallum wrote: On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote: On 4/17/15 5:59 PM, Dmitri Pal wrote: On 04/17/2015 08:07 PM, Janelle wrote: On Apr 17, 2015, at 16:36, Dmitri Pal d...@redhat.com wrote: snip for shorter thread Simple. And my test made it simple. Stand up new vm running fc21/freeipa. Configure user. Add password. Add token. Login to the vm with the user created using password. Kerberos ticket assigned, all is well. Login to web interface with admin. Change user to OTP only. Go to web UI and click sync OTP. Enter username, password and 2 OTP sequences. Click sync. Error appears. Now, ssh to same vm using OTP username. Enter password + OTP value. Login successful. I can reproduce this issue with demo instance. I will file a bug later today. I think it is a bug with sync. Which token do you use time based or event based? TOTP... Hmm, makes me wonder - with HOTP fail the same? Off to try it. This should just affect TOTP. I have posted a patch that should fix this problem. Are you able to test it? https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html Sorry - I just got around to testing this and it does resolve the problem - HOWEVER, you took away the ability to Name the tokens? They are now assigned unique IDs?? Was this intentional? It was, we track this (half-done) change in this ticket: https://fedorahosted.org/freeipa/ticket/4456 The main problem here is that user token names share the same name space and we thus do not want to create completely arbitrary names as they would collide. Applications like FreeOTP allow users to set own labels, so this is IMO the way how to add friendly names to the OTP tokens. Martin Makes sense, my only concern is syncing tokens. Once you add a second to,en and want to sync it you have to give it a token ID, otherwise it does not know which to sync. In the past if you named it, that was easy, but it does not seem to take description field as a token name. Guess I need to tell my users it is cut/paste time, or is there another option perhaps? Also, I was wondering, looking for a way to use both FreeOTP and yubikey and wondering if anyone has tried this and possible caveats? Janelle -- 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] interesting Kerberos issue
On 5/10/15 11:57 PM, Alexander Bokovoy wrote: On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account usera they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The servers are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do kinit admin it works just fine. But if I do kinit usera I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet admin works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH password and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to kinit --kdc-hostname=IPA-server principal and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? ~J PS - sorry for the questions, still trying to wrap my head around how to get OTP working from a term session so you can get your ticket and then login to all the hosts you need without reauthenticating. -- 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] 4.1.4 and OTP
On 4/28/15 6:44 AM, Nathaniel McCallum wrote: On Fri, 2015-04-17 at 20:21 -0700, Janelle wrote: On 4/17/15 5:59 PM, Dmitri Pal wrote: On 04/17/2015 08:07 PM, Janelle wrote: On Apr 17, 2015, at 16:36, Dmitri Pal d...@redhat.com wrote: snip for shorter thread Simple. And my test made it simple. Stand up new vm running fc21/freeipa. Configure user. Add password. Add token. Login to the vm with the user created using password. Kerberos ticket assigned, all is well. Login to web interface with admin. Change user to OTP only. Go to web UI and click sync OTP. Enter username, password and 2 OTP sequences. Click sync. Error appears. Now, ssh to same vm using OTP username. Enter password + OTP value. Login successful. I can reproduce this issue with demo instance. I will file a bug later today. I think it is a bug with sync. Which token do you use time based or event based? TOTP... Hmm, makes me wonder - with HOTP fail the same? Off to try it. This should just affect TOTP. I have posted a patch that should fix this problem. Are you able to test it? https://www.redhat.com/archives/freeipa-devel/2015-April/msg00282.html Sorry - I just got around to testing this and it does resolve the problem - HOWEVER, you took away the ability to Name the tokens? They are now assigned unique IDs?? Was this intentional? ~J -- 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] interesting Kerberos issue
On May 18, 2015, at 09:47, Nathaniel McCallum npmccal...@redhat.com wrote: On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: Ok, let me ask this a different way, because maybe there is a way, and I am just not seeing it. I have 2 datacenters with typical bastions in each. I have enabled OTP and that works fine via ssh. But the user has to login to both and opening ssh tunnels is problematic at best. Using all the creativity in this list, maybe someone knows of another way to have a user authenticate from a Mac where they would only have to do it once to get their ticket? I guess I can't think of anything, but no harm in asking. Without support for the OTP pre-authentication mechanism, I don't know of any way to do this while still retaining the security properties of Kerberos. Basically, you'll have to hand over your password to a third party (which has OTP support). This is ill advised. Nathaniel Excellent point. Thanks for all the tips and advice. And of course for a great product that continues to get better. ~J -- 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] interesting Kerberos issue
On 5/18/15 7:47 AM, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 09:45 -0500, Janelle wrote: Ok, let me ask this a different way, because maybe there is a way, and I am just not seeing it. I have 2 datacenters with typical bastions in each. I have enabled OTP and that works fine via ssh. But the user has to login to both and opening ssh tunnels is problematic at best. Using all the creativity in this list, maybe someone knows of another way to have a user authenticate from a Mac where they would only have to do it once to get their ticket? I guess I can't think of anything, but no harm in asking. Without support for the OTP pre-authentication mechanism, I don't know of any way to do this while still retaining the security properties of Kerberos. Basically, you'll have to hand over your password to a third party (which has OTP support). This is ill advised. Nathaniel Going to see about installing MIT version from source on Yosemite and see what happens.. Current is 1.13.2 Will let you know ~J -- 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] more replication issues
Recently I started seeing these crop up across my servers: slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) more and more and more. When it happens, I have to re-initialize from one of the good servers and go around in a circle (I have replication in a ring, as shown in documentation examples). The list-ruv on every server matches. And yet, out of 18 masters, thisis occuring now on about half of them. Once again I am beginning to question the robustness of 389-ds and the replication problems that many of us continue to report. How do we get this to be more solid? I love this product. It really is something that RH can push, but it really needs to be rock solid and with all the replication issues, well, it seems like it is not commercially ready? Any ideas/thoughts/comments? thank you Janelle -- 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] more replication issues
On 5/13/15 8:49 AM, Rich Megginson wrote: On 05/13/2015 09:40 AM, Janelle wrote: Recently I started seeing these crop up across my servers: slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) Does that entry exist? ldapsearch -xLLL -h consumer.host -D cn=directory manager -W -s base -b cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config Does the parent exist? ldapsearch -xLLL -h consumer.host -D cn=directory manager -W -s base -b ou=csusers,cn=config I am finding that there does seem to be a relation to the above error and a possible CSN issue: Can't locate CSN 555131e500020019 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. I guess what concerns me is what could be causing this. We don't do a lot of changes all the time. And in answer to the question above - we seem to have last the agreement somehow: No such object (32) results from the first ldapsearch. however, the parent is there: dn: ou=csusers,cn=config objectClass: top objectClass: organizationalUnit ou: csusers -- 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] more replication issues
On 5/13/15 9:13 AM, Rich Megginson wrote: On 05/13/2015 10:04 AM, Janelle wrote: On 5/13/15 8:49 AM, Rich Megginson wrote: On 05/13/2015 09:40 AM, Janelle wrote: Recently I started seeing these crop up across my servers: slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) Does that entry exist? ldapsearch -xLLL -h consumer.host -D cn=directory manager -W -s base -b cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config Does the parent exist? ldapsearch -xLLL -h consumer.host -D cn=directory manager -W -s base -b ou=csusers,cn=config I am finding that there does seem to be a relation to the above error and a possible CSN issue: Can't locate CSN 555131e500020019 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. I guess what concerns me is what could be causing this. We don't do a lot of changes all the time. And in answer to the question above - we seem to have last the agreement somehow: No such object (32) Is there a DEL operation in the access log for cn=Replication Manager masterAgreement1-ipa01.example.com-pki-tomcat,ou=csusers,cn=config? maybe something like # grep DEL /var/log/dirsrv/slapd-INST/access|grep -i Replication Manager nope -- none of the servers have it. -- 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] replication again :-(
Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. regards ~J -- 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] replication again :-(
On 5/18/15 6:23 PM, Janelle wrote: Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. regards ~J A new error: [ipa03.example.com] reports: Update failed! Status: [49 - LDAP error: Invalid credentials] -- 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] 4.1.4 and OTP
On 4/17/15 9:53 AM, Dmitri Pal wrote: On 04/17/2015 11:16 AM, Janelle wrote: Hi, Is anyone else having issues with OTP since upgrading? For the life of me I can't get it to accept Sync for the tokens. No matter what is put in, it just keeps saying the username, password or tokens entered are incorrect. To make it simple - I am tryign this on a brand new CentOS 7.1 system with a clean/fresh install of FreeIPA 4.1.4 and yet it just refuses to work. I create a user -- configure them. They work just fine with a password. Then add a token. Sync with FreeOTP and that all works. Then going back to the web UI and do Sync OTP and it simply refuses to accept any values. And yet the same user can login to the regular web UI with their password. I have tried setting the user to both Password and OTP for auth methods. And also just OTP and nothing works. Please look in the logs to see what is going on. You would need to look at the KDC, http and DS logs on the server to sort out what is going on. Do you change the password for the user first after creating him? Can you reproduce the problem with demo instance? http://www.freeipa.org/page/Demo If you can then we can take a look at the logs right away. Hints? Am I missing a step? ~J It appears to be the UI. If I go through the steps and let it fail, I can still login using OTP to servers. I made the assumption that the error itself was not an error.. :-) ~J -- 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] 4.1.4 and OTP
Hi, Is anyone else having issues with OTP since upgrading? For the life of me I can't get it to accept Sync for the tokens. No matter what is put in, it just keeps saying the username, password or tokens entered are incorrect. To make it simple - I am tryign this on a brand new CentOS 7.1 system with a clean/fresh install of FreeIPA 4.1.4 and yet it just refuses to work. I create a user -- configure them. They work just fine with a password. Then add a token. Sync with FreeOTP and that all works. Then going back to the web UI and do Sync OTP and it simply refuses to accept any values. And yet the same user can login to the regular web UI with their password. I have tried setting the user to both Password and OTP for auth methods. And also just OTP and nothing works. Hints? Am I missing a step? ~J -- 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] 4.1.4 and OTP
On 4/17/15 1:19 PM, Dmitri Pal wrote: On 04/17/2015 01:20 PM, Janelle wrote: On 4/17/15 9:53 AM, Dmitri Pal wrote: On 04/17/2015 11:16 AM, Janelle wrote: Hi, Is anyone else having issues with OTP since upgrading? For the life of me I can't get it to accept Sync for the tokens. No matter what is put in, it just keeps saying the username, password or tokens entered are incorrect. To make it simple - I am tryign this on a brand new CentOS 7.1 system with a clean/fresh install of FreeIPA 4.1.4 and yet it just refuses to work. I create a user -- configure them. They work just fine with a password. Then add a token. Sync with FreeOTP and that all works. Then going back to the web UI and do Sync OTP and it simply refuses to accept any values. And yet the same user can login to the regular web UI with their password. I have tried setting the user to both Password and OTP for auth methods. And also just OTP and nothing works. Please look in the logs to see what is going on. You would need to look at the KDC, http and DS logs on the server to sort out what is going on. Do you change the password for the user first after creating him? Can you reproduce the problem with demo instance? http://www.freeipa.org/page/Demo If you can then we can take a look at the logs right away. Hints? Am I missing a step? ~J It appears to be the UI. If I go through the steps and let it fail, I can still login using OTP to servers. I made the assumption that the error itself was not an error.. :-) ~J I am not sure I get what you are saying. Do you still see the problem or you misinterpreted the UI and now the problem is gone? If you did is there any recommendation how to improve the UI not to confuse people? The problem exists -- this is what it shows: HOWEVER, it is still WORKING. Meaning, even if you get this error, if you attempt to login with your FreeOTP token, it WORKS. ~J -- 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] 4.1.4 and OTP
On 4/17/15 5:59 PM, Dmitri Pal wrote: On 04/17/2015 08:07 PM, Janelle wrote: On Apr 17, 2015, at 16:36, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 04/17/2015 04:52 PM, Janelle wrote: On 4/17/15 1:19 PM, Dmitri Pal wrote: On 04/17/2015 01:20 PM, Janelle wrote: On 4/17/15 9:53 AM, Dmitri Pal wrote: On 04/17/2015 11:16 AM, Janelle wrote: Hi, Is anyone else having issues with OTP since upgrading? For the life of me I can't get it to accept Sync for the tokens. No matter what is put in, it just keeps saying the username, password or tokens entered are incorrect. To make it simple - I am tryign this on a brand new CentOS 7.1 system with a clean/fresh install of FreeIPA 4.1.4 and yet it just refuses to work. I create a user -- configure them. They work just fine with a password. Then add a token. Sync with FreeOTP and that all works. Then going back to the web UI and do Sync OTP and it simply refuses to accept any values. And yet the same user can login to the regular web UI with their password. I have tried setting the user to both Password and OTP for auth methods. And also just OTP and nothing works. Please look in the logs to see what is going on. You would need to look at the KDC, http and DS logs on the server to sort out what is going on. Do you change the password for the user first after creating him? Can you reproduce the problem with demo instance? http://www.freeipa.org/page/Demo If you can then we can take a look at the logs right away. Hints? Am I missing a step? ~J It appears to be the UI. If I go through the steps and let it fail, I can still login using OTP to servers. I made the assumption that the error itself was not an error.. :-) ~J I am not sure I get what you are saying. Do you still see the problem or you misinterpreted the UI and now the problem is gone? If you did is there any recommendation how to improve the UI not to confuse people? The problem exists -- this is what it shows: HOWEVER, it is still WORKING. Meaning, even if you get this error, if you attempt to login with your FreeOTP token, it WORKS. ~J mime-attachment.png Does it give you this error when you use password or password and token? Can you please describe the flow of steps in more details? I start browser, go here, click here, enter this, etc. Are you using SSSD to login to servers? Is SSSD configured with IPA provider or you configured it for LDAP manually. There is a difference between LDAP and Kerberos authentication. May be the following article will help you to understand the expectations: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/authconfig-addl-auth.html#enable-otp I suspect it is some combination of flags and protocols that is confusing Simple. And my test made it simple. Stand up new vm running fc21/freeipa. Configure user. Add password. Add token. Login to the vm with the user created using password. Kerberos ticket assigned, all is well. Login to web interface with admin. Change user to OTP only. Go to web UI and click sync OTP. Enter username, password and 2 OTP sequences. Click sync. Error appears. Now, ssh to same vm using OTP username. Enter password + OTP value. Login successful. I can reproduce this issue with demo instance. I will file a bug later today. I think it is a bug with sync. Which token do you use time based or event based? TOTP... Hmm, makes me wonder - with HOTP fail the same? Off to try it. ~J PS - is there a way to sync a token from command line? I can't think of a way, but maybe... -- 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] 4.1.4 and OTP
On Apr 17, 2015, at 16:36, Dmitri Pal d...@redhat.com wrote: On 04/17/2015 04:52 PM, Janelle wrote: On 4/17/15 1:19 PM, Dmitri Pal wrote: On 04/17/2015 01:20 PM, Janelle wrote: On 4/17/15 9:53 AM, Dmitri Pal wrote: On 04/17/2015 11:16 AM, Janelle wrote: Hi, Is anyone else having issues with OTP since upgrading? For the life of me I can't get it to accept Sync for the tokens. No matter what is put in, it just keeps saying the username, password or tokens entered are incorrect. To make it simple - I am tryign this on a brand new CentOS 7.1 system with a clean/fresh install of FreeIPA 4.1.4 and yet it just refuses to work. I create a user -- configure them. They work just fine with a password. Then add a token. Sync with FreeOTP and that all works. Then going back to the web UI and do Sync OTP and it simply refuses to accept any values. And yet the same user can login to the regular web UI with their password. I have tried setting the user to both Password and OTP for auth methods. And also just OTP and nothing works. Please look in the logs to see what is going on. You would need to look at the KDC, http and DS logs on the server to sort out what is going on. Do you change the password for the user first after creating him? Can you reproduce the problem with demo instance? http://www.freeipa.org/page/Demo If you can then we can take a look at the logs right away. Hints? Am I missing a step? ~J It appears to be the UI. If I go through the steps and let it fail, I can still login using OTP to servers. I made the assumption that the error itself was not an error.. :-) ~J I am not sure I get what you are saying. Do you still see the problem or you misinterpreted the UI and now the problem is gone? If you did is there any recommendation how to improve the UI not to confuse people? The problem exists -- this is what it shows: HOWEVER, it is still WORKING. Meaning, even if you get this error, if you attempt to login with your FreeOTP token, it WORKS. ~J mime-attachment.png Does it give you this error when you use password or password and token? Can you please describe the flow of steps in more details? I start browser, go here, click here, enter this, etc. Are you using SSSD to login to servers? Is SSSD configured with IPA provider or you configured it for LDAP manually. There is a difference between LDAP and Kerberos authentication. May be the following article will help you to understand the expectations: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/authconfig-addl-auth.html#enable-otp I suspect it is some combination of flags and protocols that is confusing Simple. And my test made it simple. Stand up new vm running fc21/freeipa. Configure user. Add password. Add token. Login to the vm with the user created using password. Kerberos ticket assigned, all is well. Login to web interface with admin. Change user to OTP only. Go to web UI and click sync OTP. Enter username, password and 2 OTP sequences. Click sync. Error appears. Now, ssh to same vm using OTP username. Enter password + OTP value. Login successful. Logout. Repeat, but try JUST the password, and it fails. ??? ~J-- 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] load balancers?
Hello everyone, Probably a quiet weekend for any responses, but I will toss this out. I was wondering if anyone has had any issues with load balancers and IPA? Not with Kerberos, since I know the protocol is designed without load balancer support, but in the case of using the LDAP portion? I am curious because the load balancing within sssd is not really load balancing, but more fail-over. I am wondering what kind of experience and maybe suggestions for a good LB setup anyone might have. Thank You ~J -- 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] load balancers?
On 4/4/15 11:44 AM, Dmitri Pal wrote: On 04/04/2015 12:30 PM, Nadav Mavor wrote: i use F5 and 3 IPA servers no big issues but some notes : 1) as note you cant use it for kerberos 2) for the DNS we use group and not L/B do to the zone serial (the zone serial num is not geting sync so if you round robin you will get deferent zone num evey time and it will mess up zone sync to external dns servers) 3) for the GUI (443) make sure to use stickiness so the user wont get bounce after the login I did not quite get 2) above... Can you please describe it in more details? If you know how to make LB work with IPA's DNS and kerberos a nice HOWTO wiki page would be really welcome! On Sat, Apr 4, 2015 at 11:47 AM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: We use SASL/GSSAPI/krb5 to authenticate clients to the LDAP server. If you want to load balance by using a common DNS name in front of all servers, you will need to deal with issues with krb5 authentication. At the very least you should add keys to all servers for a principal named after the common name. However we do not test this scenario and I am not 100% sure it works correctly when you factor in that we use GSSAPI also for replication. Simo. On Sat, 2015-04-04 at 22:16 +0700, Brian Topping wrote: I believe LDAP can be load balanced without any problem. It is a TCP based protocol without persistent state between transactions so it should be just fine. The reason I brought this up - been doing some testing with different LBs and well, some of them seem to cause a lot of stuck/CLOSE_WAIT ports, while others don't. My guess is I am just incorrectly configuring the ones that are causing problems. But I guess too, I was wondering if there were any known bugs in some LBs for others, that would cause issues? ~J -- 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] multihome - single interface?
Hello, Trying to find a way on a multi-homed server to force IPA and its related apps to listen on a specific interface. I can find all kinds of info saying the services listen on all interfaces by default so there must be a way? Thank you ~J -- 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] IPA web interface always giving Your session has expired. Please re-login.
On 4/1/15 9:32 AM, Ben .T.George wrote: Hi I have re-installed verything from RHEL 7.1 DVD and current ipa version is 4.0.1 everything is working including AD trust. but my web interface always giving Your session has expired. Please re-login. i faced the issue before that time i destroyed kerbros ticket (Kdestroy) and initiated again(kinit admin). after that it got worked. but now i did all the exercises ans still not working please anyone solved this issue. or is this a known bug? if i open the page from chorm browser, i am getting another login screen like .htacess login. If i gave password, it re-appering again Regards, Ben On a related to browser issues -- has anyone else seen a user login to change their PW, any browser - from Chrome, to Firefox, etc, and with the exception of the top portion of the screen, the details of the user account are blank (white screen below main header) ? They can still use the pull down to reset the PW, but everything else seems to be missing. I have also seen this Session expired even when not using a kerberized browser, so if there is a solution -- looking forward to it. ~J -- 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] pks error??
Hello, Just wondering how you get rid of this - just kind of annoying: p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute I understand it is related to not setting up DNS, is this correct? Thank you ~J -- 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] replication again :-(
On 5/19/15 12:04 AM, thierry bordaz wrote:
On 05/19/2015 03:42 AM, Janelle wrote:
On 5/18/15 6:23 PM, Janelle wrote:
Once again, replication/sync has been lost. I really wish the
product was more stable, it is so much potential and yet.
Servers running for 6 days no issues. No new accounts or changes
(maybe a few users changing passwords) and again, 5 out of 16
servers are no longer in sync.
I can test it easily by adding an account and then waiting a few
minutes, then run ipa user-show --all username on all the
servers, and only a few of them have the account. I have now waited
15 minutes, still no luck.
Oh well.. I guess I will go look at alternatives. I had such high
hopes for this tool. Thanks so much everyone for all your help in
trying to get things stable, but for whatever reason, there is a
random loss of sync among the servers and obviously this is not
acceptable.
regards
~J
All the replicas are happy again. I found these again:
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 23} 5553e3a30017 555432430017
unable to decode {replica 24} 554d53d30018 554d54a400020018
What I also found to be interesting is that I have not deleted any
masters at all, so this was quite perplexing where the orphaned entries
came from. However I did find 3 of the replicas did not show complete
RUV lists... While most of the replicas had a list of all 16 servers, a
couple of them listed only 4 or 5. (using ipa-replica-manage list-ruv)
Once I re-initialized --from servers that showed the correct RUVS
everyone is happy again. I have tested replication by creating and
deleting accounts, changing group members and a few other things.
Everything is working fine. I have enabled additional logging.
Now we wait and when it happens again, hopefully we have something.
thanks
~Janelle
--
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] replication again :-(
On 5/19/15 1:21 AM, David Kupka wrote: On 05/19/2015 09:04 AM, thierry bordaz wrote: On 05/19/2015 03:42 AM, Janelle wrote: On 5/18/15 6:23 PM, Janelle wrote: Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. regards ~J A new error: [ipa03.example.com] reports: Update failed! Status: [49 - LDAP error: Invalid credentials] can you see the update on ipa03.example.com ? It is looking like the replica agreement from this host is failing to bind to a replica. This could explain why the replica do not receive the update (disabled account, password/certificate expiration, ...) Again logs/config would help. thierry Hello, maybe stupid question: Is time on all your replicas in sync? Usually when the time is not synced between KDC and client the ticket is rejected thus preventing login. within .5 seconds each other at most. -- 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] replication again :-(
On 5/19/15 12:17 AM, Ludwig Krispenz wrote: On 05/19/2015 08:58 AM, thierry bordaz wrote: On 05/19/2015 07:47 AM, Martin Kosek wrote: On 05/19/2015 03:23 AM, Janelle wrote: Once again, replication/sync has been lost. I really wish the product was more stable, it is so much potential and yet. Servers running for 6 days no issues. No new accounts or changes (maybe a few users changing passwords) and again, 5 out of 16 servers are no longer in sync. I can test it easily by adding an account and then waiting a few minutes, then run ipa user-show --all username on all the servers, and only a few of them have the account. I have now waited 15 minutes, still no luck. Oh well.. I guess I will go look at alternatives. I had such high hopes for this tool. Thanks so much everyone for all your help in trying to get things stable, but for whatever reason, there is a random loss of sync among the servers and obviously this is not acceptable. Hello Janelle, I am very sorry to hear about your troubles. Would you be still OK with helping us (mostly Ludwig and Thierry) investigate what is the root cause of the instability of the replication agreements? This is obviously something that should not be happening at this rate as in your deployment, so I would really like to be able to identity and fix this issue in the 389 DS. Hello Janelle, I can only join my voice to Martin to say how I am sorry to read this. Would you turn on replication logging level (8192) on the master/consumer and provide us the logs(access/error) and config (dse.ldif). The master is the instance where you can see the update and the that is linked (replica agreement) to a replica(aka consumer) where the update is not received. what puzzles me most, is that replication is working for quite some time and then breaks, so we need to find out about the dynamics which lead to that state. You reported errors about invalid credentials or about a bind dn entry not found, these credentials don't get changed by ds or entries are not deleted by ds, so what triggers these changes. also for the suggestion by Thierry to debug, we need to determine where replication breaks, if you add an account and it is propageted to some servers and not to others, where does it stop ? This depends on your replication topology, you said in anotehr post that you have a ring topology, does it mean all 16 servers are conencted in a ring only, and if two links break the topology is disconnected ? thanks thierry Let me see about getting some debug logs going to provide more info. As for topology -- yes, ring, but also within the DC - the 3 servers are connected in an internal ring. There have been no outages on the WAN connections, as I have logs showing network data at all times, so this is not an issue. If I did lose a WAN, dozens of other inter-DC apps would blow up too, and they have not. However, I guess you are right, I have not provided enough logging data to help diagnose this. Let me see what I can do. Not sure if this helps -- I do try and do all updates from a single master, never from different ones. Users are also forced to the same master to change passwords and update things. So the source of changes is always the same. Time to go do some log enabling... ~J -- 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] replication again :-(
On 5/20/15 12:54 AM, Ludwig Krispenz wrote:
On 05/20/2015 02:57 AM, Janelle wrote:
On 5/19/15 12:04 AM, thierry bordaz wrote:
On 05/19/2015 03:42 AM, Janelle wrote:
On 5/18/15 6:23 PM, Janelle wrote:
Once again, replication/sync has been lost. I really wish the
product was more stable, it is so much potential and yet.
Servers running for 6 days no issues. No new accounts or changes
(maybe a few users changing passwords) and again, 5 out of 16
servers are no longer in sync.
I can test it easily by adding an account and then waiting a few
minutes, then run ipa user-show --all username on all the
servers, and only a few of them have the account. I have now
waited 15 minutes, still no luck.
Oh well.. I guess I will go look at alternatives. I had such high
hopes for this tool. Thanks so much everyone for all your help in
trying to get things stable, but for whatever reason, there is a
random loss of sync among the servers and obviously this is not
acceptable.
regards
~J
All the replicas are happy again. I found these again:
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 23} 5553e3a30017 555432430017
unable to decode {replica 24} 554d53d30018 554d54a400020018
What I also found to be interesting is that I have not deleted any
masters at all, so this was quite perplexing where the orphaned
entries came from. However I did find 3 of the replicas did not show
complete RUV lists... While most of the replicas had a list of all 16
servers, a couple of them listed only 4 or 5. (using
ipa-replica-manage list-ruv)
so this happens out of the blue ? Did it happen at the same time, do
you know when it started ? The maxcsns in the ruv are quite old: r16:
apr,21, r23: may,14 r24: may,9 could it be that there was no change
applied to these masters for that time ?
Indeed yes, that is a correct statement. It seems to be incredibly random.
Ok, I give up - how are you finding the date in the strings? And really,
is May 14th that old?
What is odd about the Apr 21st one, is that if you see my previous
emails, I had cleaned up all of this before, so for that to re-appear
is indeed a mystery.
As of this morning, things remain clean. What will be funny, now that I
had extended logging enabled, they know we are on to them, so the
servers won't fail again. :-)
~J
--
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] replication again :-(
On 5/20/15 6:01 AM, thierry bordaz wrote:
On 05/20/2015 02:57 AM, Janelle wrote:
On 5/19/15 12:04 AM, thierry bordaz wrote:
On 05/19/2015 03:42 AM, Janelle wrote:
On 5/18/15 6:23 PM, Janelle wrote:
Once again, replication/sync has been lost. I really wish the
product was more stable, it is so much potential and yet.
Servers running for 6 days no issues. No new accounts or changes
(maybe a few users changing passwords) and again, 5 out of 16
servers are no longer in sync.
I can test it easily by adding an account and then waiting a few
minutes, then run ipa user-show --all username on all the
servers, and only a few of them have the account. I have now
waited 15 minutes, still no luck.
Oh well.. I guess I will go look at alternatives. I had such high
hopes for this tool. Thanks so much everyone for all your help in
trying to get things stable, but for whatever reason, there is a
random loss of sync among the servers and obviously this is not
acceptable.
regards
~J
All the replicas are happy again. I found these again:
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 23} 5553e3a30017 555432430017
unable to decode {replica 24} 554d53d30018 554d54a400020018
What I also found to be interesting is that I have not deleted any
masters at all, so this was quite perplexing where the orphaned
entries came from. However I did find 3 of the replicas did not show
complete RUV lists... While most of the replicas had a list of all 16
servers, a couple of them listed only 4 or 5. (using
ipa-replica-manage list-ruv)
I don't know about the orphaned entries. Did you get entries below
deleted parents ?
AFAIK all replicas are master and so have an entry {replica rid} in
the RUV. We should expect all servers having the same number of
RUVelements (16, 4 or 5). The servers with 4 or 5 may be isolated so
that they did not received updates from those with 16 RUVelements.
would you copy/paste an example of RUV with 16 and with 4-5 ?
Now, the steps to clear this were:
Removed the unable to decode with the direct ldapmodify's. This worked
across all replicas, which was nice and did not have to be repeated in
each one. In other words, entered on a single server, and it was removed
on all.
re-initialized --from=good server on the ones with the short list.
Waited 5 minutes to let everything settle, then started running tests of
adds/deletes which seemed to be just fine.
Here are 2 of the DCs
-
Node dc1-ipa1
-
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa4.example.com 389 4
-
Node dc1-ipa2
-
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
-
Node dc1-ipa3
-
dc3-ipa1.example.com 389 14
dc3-ipa2.example.com 389 13
dc3-ipa3.example.com 389 12
dc3-ipa4.example.com 389 11
dc2-ipa1.example.com 389 7
dc2-ipa2.example.com 389 6
dc2-ipa3.example.com 389 5
dc2-ipa4.example.com 389 3
dc4-ipa1.example.com 389 18
dc4-ipa2.example.com 389 19
dc4-ipa3.example.com 389 20
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa2.example.com 389 9
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 24} 554d53d30018 554d54a400020018
dc5-ipa1.example.com 389 26
dc5-ipa2.example.com 389 15
dc5-ipa3.example.com 389 17
-
Node dc1-ipa4
-
dc3-ipa1.example.com 389 14
dc3-ipa2.example.com 389 13
dc3-ipa3.example.com 389 12
dc3-ipa4.example.com 389 11
dc2-ipa1.example.com 389 7
dc2-ipa2.example.com 389 6
dc2-ipa3.example.com 389 5
dc2-ipa4.example.com 389 3
dc4-ipa1.example.com 389 18
dc4-ipa2.example.com 389 19
dc4-ipa3.example.com 389 20
dc4-ipa4.example.com 389 21
dc1-ipa1.example.com 389 10
dc1-ipa2.example.com 389 25
dc1-ipa2.example.com 389 9
dc1-ipa3.example.com 389 8
dc1-ipa4.example.com 389 4
unable to decode {replica 16} 5535647200030010 5535647200030010
unable to decode {replica 24} 554d53d30018 554d54a400020018
dc5-ipa1.example.com 389 26
dc5-ipa2.example.com 389 15
dc5-ipa3.example.com 389 17
-
Node dc2-ipa1
-
dc3-ipa1.example.com 389 14
dc3-ipa2.example.com 389 13
dc3-ipa3.example.com 389 12
dc3-ipa4.example.com 389 11
dc2-ipa1.example.com 389 7
dc2-ipa2.example.com 389 6
dc2-ipa3.example.com 389 5
dc2-ipa4.example.com 389 3
dc4-ipa1.example.com 389 18
dc4-ipa2.example.com 389 19
dc4-ipa3.example.com 389 20
dc4-ipa4.example.com 389 21
Re: [Freeipa-users] Successful Install on VB...
By default, fedora has all the ports blocked via firewalld You need to either enable the ports, or disable the firewall. PORTS='80 443 389 636 88 464' for PORT in $PORTS; do firewall-cmd --permanent --zone=public --add-port=$PORT/tcp; done PORTS='88 464 123' for PORT in $PORTS; do firewall-cmd --permanent --zone=public --add-port=$PORT/udp; done firewall-cmd --reload ~J On 6/5/15 12:50 PM, James Benson wrote: Dear all, I recently install Fedora Server 22 on a virtualbox with the ethernet bridged (can successfully ping it, ssh, etc) and I can do a kinit admin and ipa user-add as the instructions detail in the next steps, however, I cannot access the webui. Has anyone else ran into this issue? I've tried to check the services, however, they don't seem to want to start (no errors, just don't see them in the service status menu) Any help would be great as I would greatly like to use the website over commands if possible. Thank you, James -- 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] blank user screen? (web UI)
On 6/22/15 9:25 AM, Petr Vobornik wrote: On 06/22/2015 04:15 PM, Janelle wrote: On 6/22/15 5:15 AM, Petr Vobornik wrote: On 06/21/2015 08:35 AM, Janelle wrote: Hi, Sure. Just login as a normal user to the WEB UI. screen is blank: Of course, if you click on Actions - you will see those and you can click on them, but you can't do anything else. This is a vanilla server install, nothing fancy. Oh and there is no error message at all. Any browser = same results. Tried clearing cache, history, web data.. Everything. Many of my users report the same thing. This is 7.1 with IPA 4.1.7 Now the funny part - login as admin and everything works fine. But I certainly can't have everyone logging in as admin. :-) ~Janelle Do you see any error in browser console? Does this happen also to a user which doesn't have any RBAC role assigned(either directly or indrectly)? AHA -- perhaps a clue: [Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (json, line 0) [Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (login_kerberos, line 0) [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (jquery-2.0.3.min.map, line 0) ~J These errors are expected. First two happens when user is not yet authenticated. Third line is just about file for jquery debugging which is not shipped with ipa. Could you inspect other json request? Mainly the 3 which are executed on navigating to user details page (or after clicking on refresh button on the page). Does the first result of first request (of the three) contain user data as in https://pvoborni.fedorapeople.org/images/user_response_data.png I'm unable to reproduce the issue with ipa-server-4.1.0-18.el7_1.3.x86_64. Do these users have some special permissions/roles/rights? The user I did the same from is a User Administrator, however, all the other users are NOT. And if you watch closely, all the details do flash the screen, but then disappear. Refresh does nothing. The one thing - it works flawlessly for admin account. versions (I believe in the newest -- perhaps a bad idea) freeipa-client-4.1.4-1.el7.centos.x86_64 freeipa-server-4.1.4-1.el7.centos.x86_64 freeipa-python-4.1.4-1.el7.centos.x86_64 on a user screen after login - : [Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (json, line 0) [Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (login_kerberos, line 0) [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (jquery-2.0.3.min.map, line 0) [Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (json, line 0) [Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (login_kerberos, line 0) [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (jquery-2.0.3.min.map, line 0) [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (jquery-2.0.3.min.map, line 0) ~Janelle -- 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] Crazy Cert problem?
On 6/22/15 7:37 AM, Rob Crittenden wrote: Janelle wrote: On 6/17/15 2:00 PM, Rob Crittenden wrote: Janelle wrote: On 6/17/15 6:21 AM, Rob Crittenden wrote: Janelle wrote: On 6/17/15 6:14 AM, Rob Crittenden wrote: Janelle wrote: Hi, Had a server - named ipa001.example.com -- it was a replica. It died. It was re-installed. However, prior to the re-install it was saying the wonderful: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. It was rebuilt - new OS and doing a brand new ipa-server-install (NOT a replica or trying to join it back in to the existing ring of servers) and at the end of the ipa-server-install - it gives: Done. Restarting the directory server Restarting the KDC Restarting the certificate server Restarting the web server Unable to set admin password Command ''/usr/bin/ldappasswd' '-h' 'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y' '/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs' 'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned non-zero exit status 1 Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'example.com' '--server' 'ipa001.example.com' '--realm' 'example.com' '--hostname' 'ipa001.example.com'' returned non-zero exit status 1 and checking /var/log/ipaclient-install.log - the exact same TLS error But this is a brand new system, with brand new OS and the install was ipa-server-install to install a clean server. I don't understand how this is happening. There is no peer to be not trusted? What version of IPA and distro? (I don't think that probably has anything to do with it, just curious in case it does eventually matter). What does /etc/openldap/ldap.conf look like? Normally it should have TLS_CACERT /etc/ipa/ca.crt Any chance you can share the server and client install logs? rob 4.1.4 = IPA CentOS 7.1 Oooh... Found something: /etc/openldap/ldap.conf: TLS_CACERTDIR/etc/openldap/certs Going to investigate. ~J That should be fine assuming there aren't any certs in there (and on a brand new system I'd think you'd have empty NSS databases). rob So this gets interesting now... Say you have 6 IPA servers, named ipa001-ipa006.example.com -- all working fine. Something happens to 002. It dies. You ipa-replica-manage del --clean --force ipa002 to get rid of it. A period of time, say a month, goes by. You have lost a couple of other replicas for whatever reason, say 3 and 6. You decide you want to rebuild. You start with 002 - leaving the others up and running because you have users working. You firewall off 002 why you rebuild it. You reinstall OS, reinstall FreeIPA. But no matter what, when you start to configure IPA it comes up with the error of being untrusted. Now, you try the same thing on 003 and 006. SAME problem. For fun - you shutdown 005 and uninstall freeipa --unattended and then try to re-install it. Guess what - no issues. Is this somehow related to: Same domain and realm names floating around the net - so is it querying for a name somehow and one of the still running servers is saying - NO NO NO -- that CERT is revoked!!! - even though it never tries to connect to that server. Or am I just thinking far too outside the box? And this is exactly what has happened. Rebuilding one of the servers that was never REMOVED is working just fine. You just jumped to a completely different scenario: from a fresh standalone install to a replica install. We should probably pick one and solve it. I think the leap you're making is that the issue is that it notices some previous cert. A revoked service cert wouldn't have any effect as those service certs aren't in use. It very well could be finding the wrong realm based on DNS SRV records. The logs should show you what the client discovered. Things happen in multiple steps so perhaps there is a disconnect where the right server is used in some, but not all, cases. rob ALL the problems were all related. Even after building brand new servers, the problem persisted and then started cropping up with client installs. The solution traced to bad NSS packages. A simple yum downgrade nss nss-sysinit nss-tools solved it.. Something is up with the 3.18 verion and downgrading to 3.16 seems to have resolved. Should have known it would all be related to an upgrade. Sometimes a slightly older version is best. ~Janelle Can you open a bugzilla about this? rob This looks like the fix - besides downgrading: https://bugzilla.mozilla.org/show_bug.cgi?id=1132941 -- 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] Installing replica w/o CA?
Maybe this is an obvious question - but I am missign the simple answer. If you create a master and want to create 3 replicas -- creating the first replica works just fine, but I want the 2nd replica chained off the first, and NOT the master. But unless you install a CA on that first replica, you get an error. 1. install master 2. ipa-replica-prepare -- rep001 -- copy file to rep001 3. ipa-replica-install on rep001 4. ipa-replica-prepare rep002 --- does not work saying you can only create replica from master? ~J -- 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] ipa replica failure
On 6/19/15 11:22 AM, Andrew E. Bruno wrote: Hello, First time trouble shooting an ipa server failure and looking for some guidance on how best to proceed. First some background on our setup: Servers are running freeipa v4.1.0 on CentOS 7.1.1503: - ipa-server-4.1.0-18.el7.centos.3.x86_64 - 389-ds-base-1.3.3.1-16.el7_1.x86_64 3 ipa-servers, 1 first master (rep1) and 2 (rep2, rep3) replicates. The replicates were setup to be ca's (i.e. ipa-replica-install --setup-ca...) We have ~3000 user accounts (~1000 active the rest disabled). We have ~700 hosts enrolled (all installed using ipa-client-install and running sssd). Hosts clients are a mix of centos 7 and centos 6.5. We recently discovered one of our replica servers (rep2) was not responding. A quick check of the dirsrv logs /var/log/dirsrv/slapd-/errors (sanitized): PR_Accept() failed, Netscape Portable Runtime error (Process open FD table is full.) ... The server was rebooted and after coming back up had these errors in the logs: 389-Directory/1.3.3.1 B2015.118.1941 replica2:636 (/etc/dirsrv/slapd-) [16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [16/Jun/2015:10:12:33 -0400] - Serious Error---Failed to trickle, err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [16/Jun/2015:10:12:33 -0400] - Serious Error---Failed in deadlock detect (aborted at 0x0), err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [16/Jun/2015:10:12:33 -0400] - Serious Error---Failed in deadlock detect (aborted at 0x0), err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [16/Jun/2015:10:12:33 -0400] - Serious Error---Failed to checkpoint database, err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [16/Jun/2015:10:12:33 -0400] - Serious Error---Failed to checkpoint database, err=-30973 (BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery) [16/Jun/2015:10:12:33 -0400] - libdb: BDB0060 PANIC: fatal region error detected; run recovery [16/Jun/2015:10:12:33 -0400] - checkpoint_threadmain: log archive failed - BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery (-30973) [16/Jun/2015:16:24:04 -0400] - 389-Directory/1.3.3.1 B2015.118.1941 starting up [16/Jun/2015:16:24:04 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. ... [16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=XXX. Check if DB RUV needs to be updated [16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - Force update of database RUV (from CL RUV) - 5577006800030003 [16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - Force update of database RUV (from CL RUV) - 556f463200140004 [16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - Force update of database RUV (from CL RUV) - 556f4631004d0005 [16/Jun/2015:16:24:15 -0400] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 111 (Connection refused) [16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - agmt=cn=cloneAgreement1-rep2 (rep1:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () [16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated [16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - Force update of database RUV (from CL RUV) - 556f46290005005b [16/Jun/2015:16:24:15 -0400] set_krb5_creds - Could not get initial credentials for principal [ldap/rep2] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [16/Jun/2015:16:24:15 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 111 (Connection refused) [16/Jun/2015:16:24:15 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [16/Jun/2015:16:24:15 -0400] NSMMReplicationPlugin - agmt=cn=meTorep1 (rep1:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [16/Jun/2015:16:24:15 -0400] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=xxx--no CoS Templates found, which should be added before the CoS Definition. [16/Jun/2015:16:24:15 -0400] DSRetroclPlugin - delete_changerecord: could not
[Freeipa-users] blank user screen? (web UI)
Just wondering if others have run into the user login to the web-UI and with the exception of the top part of the screen and menu, all the user details go blank. This makes it hard for a user to click on add ssh key since they can't see it. Have reproduced this dozens of times on all browsers. Very confusing. There must be an answer or known fix? ~Janelle -- 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] blank user screen? (web UI)
On 6/22/15 5:15 AM, Petr Vobornik wrote: On 06/21/2015 08:35 AM, Janelle wrote: Hi, Sure. Just login as a normal user to the WEB UI. screen is blank: Of course, if you click on Actions - you will see those and you can click on them, but you can't do anything else. This is a vanilla server install, nothing fancy. Oh and there is no error message at all. Any browser = same results. Tried clearing cache, history, web data.. Everything. Many of my users report the same thing. This is 7.1 with IPA 4.1.7 Now the funny part - login as admin and everything works fine. But I certainly can't have everyone logging in as admin. :-) ~Janelle Do you see any error in browser console? Does this happen also to a user which doesn't have any RBAC role assigned(either directly or indrectly)? AHA -- perhaps a clue: [Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (json, line 0) [Error] Failed to load resource: the server responded with a status of 401 (Unauthorized) (login_kerberos, line 0) [Error] Failed to load resource: the server responded with a status of 404 (Not Found) (jquery-2.0.3.min.map, line 0) ~J -- 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] Crazy Cert problem?
On 6/17/15 2:00 PM, Rob Crittenden wrote: Janelle wrote: On 6/17/15 6:21 AM, Rob Crittenden wrote: Janelle wrote: On 6/17/15 6:14 AM, Rob Crittenden wrote: Janelle wrote: Hi, Had a server - named ipa001.example.com -- it was a replica. It died. It was re-installed. However, prior to the re-install it was saying the wonderful: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. It was rebuilt - new OS and doing a brand new ipa-server-install (NOT a replica or trying to join it back in to the existing ring of servers) and at the end of the ipa-server-install - it gives: Done. Restarting the directory server Restarting the KDC Restarting the certificate server Restarting the web server Unable to set admin password Command ''/usr/bin/ldappasswd' '-h' 'ipa001.example.com' '-ZZ' '-x' '-D' 'cn=Directory Manager' '-y' '/var/lib/ipa/tmp5Fxy2Z' '-T' '/var/lib/ipa/tmpnz0jLs' 'uid=admin,cn=users,cn=accounts,dc=example,dc=com'' returned non-zero exit status 1 Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'example.com' '--server' 'ipa001.example.com' '--realm' 'example.com' '--hostname' 'ipa001.example.com'' returned non-zero exit status 1 and checking /var/log/ipaclient-install.log - the exact same TLS error But this is a brand new system, with brand new OS and the install was ipa-server-install to install a clean server. I don't understand how this is happening. There is no peer to be not trusted? What version of IPA and distro? (I don't think that probably has anything to do with it, just curious in case it does eventually matter). What does /etc/openldap/ldap.conf look like? Normally it should have TLS_CACERT /etc/ipa/ca.crt Any chance you can share the server and client install logs? rob 4.1.4 = IPA CentOS 7.1 Oooh... Found something: /etc/openldap/ldap.conf: TLS_CACERTDIR/etc/openldap/certs Going to investigate. ~J That should be fine assuming there aren't any certs in there (and on a brand new system I'd think you'd have empty NSS databases). rob So this gets interesting now... Say you have 6 IPA servers, named ipa001-ipa006.example.com -- all working fine. Something happens to 002. It dies. You ipa-replica-manage del --clean --force ipa002 to get rid of it. A period of time, say a month, goes by. You have lost a couple of other replicas for whatever reason, say 3 and 6. You decide you want to rebuild. You start with 002 - leaving the others up and running because you have users working. You firewall off 002 why you rebuild it. You reinstall OS, reinstall FreeIPA. But no matter what, when you start to configure IPA it comes up with the error of being untrusted. Now, you try the same thing on 003 and 006. SAME problem. For fun - you shutdown 005 and uninstall freeipa --unattended and then try to re-install it. Guess what - no issues. Is this somehow related to: Same domain and realm names floating around the net - so is it querying for a name somehow and one of the still running servers is saying - NO NO NO -- that CERT is revoked!!! - even though it never tries to connect to that server. Or am I just thinking far too outside the box? And this is exactly what has happened. Rebuilding one of the servers that was never REMOVED is working just fine. You just jumped to a completely different scenario: from a fresh standalone install to a replica install. We should probably pick one and solve it. I think the leap you're making is that the issue is that it notices some previous cert. A revoked service cert wouldn't have any effect as those service certs aren't in use. It very well could be finding the wrong realm based on DNS SRV records. The logs should show you what the client discovered. Things happen in multiple steps so perhaps there is a disconnect where the right server is used in some, but not all, cases. rob ALL the problems were all related. Even after building brand new servers, the problem persisted and then started cropping up with client installs. The solution traced to bad NSS packages. A simple yum downgrade nss nss-sysinit nss-tools solved it.. Something is up with the 3.18 verion and downgrading to 3.16 seems to have resolved. Should have known it would all be related to an upgrade. Sometimes a slightly older version is best. ~Janelle -- 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
