From lkrispen at redhat.com Wed Mar 1 08:05:17 2017 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 01 Mar 2017 09:05:17 +0100 Subject: [Freeipa-users] unable to decode: {replica In-Reply-To: <22d81136-0d79-df33-a041-bbc8a70fad5e@yahoo.co.uk> References: <5907f1b4-c87b-0217-d4a3-878dcf36b395@yahoo.co.uk> <250983c1-67dc-832c-aefb-f5bf4abb1cd2@redhat.com> <22d81136-0d79-df33-a041-bbc8a70fad5e@yahoo.co.uk> Message-ID: <58B680BD.1080505@redhat.com> On 02/28/2017 07:52 PM, lejeczek wrote: > > > On 28/02/17 09:45, Petr Vobornik wrote: >> On 02/26/2017 11:35 AM, lejeczek wrote: >>> hi everyone >>> >>> I first time see: >>> >>> unable to decode: {replica 60} 586eaffd000a003c0000 >>> 586eaffd000a003c0000 >>> Replica Update Vectors: >>> .... >>> >>> on all four servers. What would be a correct troubleshooting and >>> fixing this >>> problem? >>> many thanks, >>> L. >>> >>> >>> >> >> Hello, >> >> what is the version and OS of your IPA servers and DS? >> >> $ rpm -q ipa-server freeipa-server 389-ds-base > well I run a Centos 7.x and > ~]$ rpm -q ipa-server freeipa-server 389-ds-base > ipa-server-4.4.0-14.el7.centos.4.x86_64 > package freeipa-server is not installed > 389-ds-base-1.3.5.10-15.el7_3.x86_64 > > I searched the net and archives but failed to find anything flagged as > "solved". if you expect help, you should provide a bit more information than the snippet of an error message. As Petr pointed out this looks like a problem of a corrupted RUV, but we also haven't seen these for a long time. Could you describe your deployment, what changed recently (addigng/removing replicas, crashes,.... ) A mapping of servers and replica Ids, to which server does "60" refer? Check the ruvs for all suffixes on all servers. Try cleaning the RUV, if IPA command does not work do it by ldapmodify There have been many discussions on this topic in this mailing list, look for "cleanallruv", "haunted servers",.. Ludwig > > >> >> Similar issues happened last year, you can search the archives for >> "unable to decode" but a 389-ds fix improved the situation. So if you >> have older version then maybe update and then manual cleanup of RUVs >> might help. >> > > > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -------------- next part -------------- An HTML attachment was scrubbed... URL: From keesb at ghs.com Wed Mar 1 08:10:47 2017 From: keesb at ghs.com (Kees Bakker) Date: Wed, 1 Mar 2017 09:10:47 +0100 Subject: [Freeipa-users] login/su problem on ubuntu In-Reply-To: <20170228200153.7wcg5tunckkrgmkv@hendrix> References: <20170228200153.7wcg5tunckkrgmkv@hendrix> Message-ID: <9d04192e-ab0d-16ce-7929-0ad2a901c7a2@ghs.com> Perhaps you need to add a HBAC Service for lightdm. At least, that's what I did. And also to add that service in the HBAC rules for the hosts on which the users may login. On 28-02-17 21:01, Jakub Hrozek wrote: > On Tue, Feb 28, 2017 at 06:13:42PM +0100, Karl Forner wrote: >> I just registered a new computer running ubuntu to our freeIPA system. >> Some users (all I tried except me) are not able to login using lightdm. >> >> The message on screen is "Permission denied". >> On the system the user (joe) is created, its home directory also, but it >> only contains a .kde/ subdir and a .bash_history. >> >> On my session, if I type: >> $sudo su - joe >> I get: >> su: Permission denied >> (Ignored) >> >> >> The only log file that is modified is /var/log/auth.log. >> The relevant lines during the graphical login are: >> >> Feb 28 16:44:29 nyx lightdm: pam_unix(lightdm:auth): authentication >> failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=joe >> Feb 28 16:44:41 nyx lightdm: pam_sss(lightdm:auth): authentication success; >> logname= uid=0 euid=0 tty=:0 ruser= rhost= user=joe >> Feb 28 16:44:41 nyx lightdm: pam_kwallet(lightdm:auth): pam_sm_authenticate >> Feb 28 16:44:43 nyx lightdm: pam_sss(lightdm:account): Access denied for >> user joe: 6 (Permission denied) >> Feb 28 16:44:54 nyx lightdm: pam_succeed_if(lightdm:auth): requirement >> "user ingroup nopasswdlogin" not met by user "joe" >> >> The relevant lines during the "sudo su - joe": >> Feb 28 16:48:32 nyx su[26394]: pam_sss(su:account): Access denied for user >> joe: 6 (Permission denied) > You need to enable SSSD debugging: > https://fedorahosted.org/sssd/wiki/Troubleshooting > and check the sssd logs, probably the HBAC access control is kicking you > out. > From Terry.John at coxauto.co.uk Wed Mar 1 12:25:14 2017 From: Terry.John at coxauto.co.uk (Terry John) Date: Wed, 1 Mar 2017 12:25:14 +0000 Subject: [Freeipa-users] Kerberos hanging Message-ID: I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The problem manifests itself as no authentication, and no DNS. It seems Kerberos just stops responding to requests and requests just get queued up # netstat -tuna | grep SYN_RECV Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 :88 :55440 SYN_RECV tcp 0 0 :88 :40076 SYN_RECV tcp 0 0 :88 :41525 SYN_RECV tcp 0 0 :88 :53958 SYN_RECV tcp 0 0 :88 :54240 SYN_RECV Looking at /var/log/krb5kdc.log The normal activity of AS_REQ and TGS_REC messages just stops. No error messages. Just no new messages. In /var/log/messages the named server reports messages like Mar 1 00:00:23 freeipa named[18989]: LDAP error: Can't contact LDAP server Mar 1 00:00:23 freeipa named[18989]: connection to the LDAP server was lost Mar 1 00:00:23 freeipa named[18989]: bind to LDAP server failed: Can't contact LDAP server The command "kinit" is totally unresponsive and will time out if you wait long enough. If I try to restart ipa with "service ipa restart", it hangs on the first stage, trying to stop DIRSRV. I have to do a "ps ax" and look for this line. 2758 ? Sl 2:13 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-MY-REALM -i /var/run/dirsrv/slapd-MY-REALM.pid -w /var/run/dirsrv/slapd-MY-REALM.startpid Then I have to a "kill -9" on the pid Then I can do "service ipa restart" After that it works ok for a while. "A while" may be a few minutes or several hours. The filesystem is only 58% used and "free" shows no swap in use so there seems to be plenty of RAM available. "top" shows CPU(s) 96% idle with "dirsirv" typically using about 3%CPU at most I've no idea why this keeps happening, everything looks ok then it just stops Terry John System Administrator- Cox Automotive Software E: Terry.John at coxauto.co.uk Cox Automotive group of companies within the UK comprises: Cox Automotive UK Limited (registered number: 03183918), Manheim Limited (registered number: 00448761), Cox Automotive Retail Solutions Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), and Real Time Communications Limited (registered number: 04277845). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Cox Automotive group of companies within the UK operates under various brand/trading names including Cox Automotive UK, Manheim Inspection Services, Manheim Auctions, Modix, Xtime and Closeit. V:0CF72C13B2AD From gmzgames.de at googlemail.com Wed Mar 1 13:30:26 2017 From: gmzgames.de at googlemail.com (Gerald Zabos) Date: Wed, 1 Mar 2017 14:30:26 +0100 Subject: [Freeipa-users] Kerberos hanging In-Reply-To: References: Message-ID: Hi Terry, > I've no idea why this keeps happening, everything looks ok then it just stops Check time an date on all involved servers/workstations - if the difference is more than 300 seconds , Kerberos might not work correctly. Apply the same time to all involved servers/workstations. Regards, Gerald On Wed, Mar 1, 2017 at 1:25 PM, Terry John wrote: > I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The problem manifests itself as no authentication, and no DNS. > > It seems Kerberos just stops responding to requests and requests just get queued up > # netstat -tuna | grep SYN_RECV > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 :88 :55440 SYN_RECV > tcp 0 0 :88 :40076 SYN_RECV > tcp 0 0 :88 :41525 SYN_RECV > tcp 0 0 :88 :53958 SYN_RECV > tcp 0 0 :88 :54240 SYN_RECV > > Looking at /var/log/krb5kdc.log > The normal activity of AS_REQ and TGS_REC messages just stops. No error messages. Just no new messages. > > In /var/log/messages the named server reports messages like > Mar 1 00:00:23 freeipa named[18989]: LDAP error: Can't contact LDAP server > Mar 1 00:00:23 freeipa named[18989]: connection to the LDAP server was lost > Mar 1 00:00:23 freeipa named[18989]: bind to LDAP server failed: Can't contact LDAP server > > The command "kinit" is totally unresponsive and will time out if you wait long enough. > > If I try to restart ipa with "service ipa restart", it hangs on the first stage, trying to stop DIRSRV. > I have to do a "ps ax" and look for this line. > 2758 ? Sl 2:13 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-MY-REALM -i /var/run/dirsrv/slapd-MY-REALM.pid -w /var/run/dirsrv/slapd-MY-REALM.startpid > > Then I have to a "kill -9" on the pid > Then I can do "service ipa restart" > > After that it works ok for a while. "A while" may be a few minutes or several hours. > The filesystem is only 58% used and "free" shows no swap in use so there seems to be plenty of RAM available. > "top" shows CPU(s) 96% idle with "dirsirv" typically using about 3%CPU at most > > I've no idea why this keeps happening, everything looks ok then it just stops > > Terry John > System Administrator- Cox Automotive Software > E: Terry.John at coxauto.co.uk > > > > Cox Automotive group of companies within the UK comprises: Cox Automotive UK Limited (registered number: 03183918), Manheim Limited (registered number: 00448761), Cox Automotive Retail Solutions Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), and Real Time Communications Limited (registered number: 04277845). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Cox Automotive group of companies within the UK operates under various brand/trading names including Cox Automotive UK, Manheim Inspection Services, Manheim Auctions, Modix, Xtime and Closeit. > > V:0CF72C13B2AD > > > > -- > 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 From rcritten at redhat.com Wed Mar 1 15:06:16 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 1 Mar 2017 10:06:16 -0500 Subject: [Freeipa-users] Kerberos hanging In-Reply-To: References: Message-ID: <15da9c24-52d0-0a75-5c42-bc55f53892ff@redhat.com> Terry John wrote: > I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The problem manifests itself as no authentication, and no DNS. > > It seems Kerberos just stops responding to requests and requests just get queued up > # netstat -tuna | grep SYN_RECV > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 :88 :55440 SYN_RECV > tcp 0 0 :88 :40076 SYN_RECV > tcp 0 0 :88 :41525 SYN_RECV > tcp 0 0 :88 :53958 SYN_RECV > tcp 0 0 :88 :54240 SYN_RECV > > Looking at /var/log/krb5kdc.log > The normal activity of AS_REQ and TGS_REC messages just stops. No error messages. Just no new messages. The problem isn't in Kerberos or DNS, ns-slapd is hanging. See this, http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-hangs rob From pgb205 at yahoo.com Wed Mar 1 19:18:40 2017 From: pgb205 at yahoo.com (pgb205) Date: Wed, 1 Mar 2017 19:18:40 +0000 (UTC) Subject: [Freeipa-users] replication breaks intermittently References: <1580318136.1396893.1488395920317.ref@mail.yahoo.com> Message-ID: <1580318136.1396893.1488395920317@mail.yahoo.com> [01/Mar/2017:18:19:48 +0000] agmt="cn=meTo ipa2.internal.domain" (ipa2:389) - Can't locate CSN 582301c3000d00770000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.[01/Mar/2017:18:19:48 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meToipa2.internal.domain" (ipa2:389): CSN 582301c3000d00770000 not found, we aren't as up to date, or we purged[01/Mar/2017:18:19:48 +0000] NSMMReplicationPlugin - agmt="cn=meToipa2.internal.domain" (ipa2:389): Data required to update replica has been purged. The replica must be reinitialized.[01/Mar/2017:18:19:48 +0000] NSMMReplicationPlugin - agmt="cn=meToipa2.internal.domain" (ipa2:389): Incremental update failed and requires administrator action Seeing the above in the logs after seeing problems with replication. The data entered on one replica isn't making it to others. There are no problems with connectivity between the servers and all necessary ports are open. Currently we are getting around this problem by running a script to perform force sync. Any suggestions on the things that may be setup wrong to take a look at? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.wells at bridgevine.com Wed Mar 1 21:00:56 2017 From: matt.wells at bridgevine.com (Matt Wells) Date: Wed, 1 Mar 2017 13:00:56 -0800 Subject: [Freeipa-users] IPA 4.4 CA Replications Message-ID: I have two new IPA 4.4 servers on CentOS7 installed in a lab. I built the first, joined the second and promoted it to be a master. Thus far all went well. I then ran the ipa-ca-install and when I log back in I see that it has "domain,CA" attached to it. However when I hit the main IPA page it informs me I only have one server in the CA role. Drilling down into server2 I see it does not have that role assigned. I'm certain I missed an easy step but I've been unable to locate it. Any guidance would be greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Wed Mar 1 22:46:47 2017 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 1 Mar 2017 15:46:47 -0700 Subject: [Freeipa-users] S4U for cron Message-ID: <14a9252d-de47-71d9-f040-20d9142e09df@cora.nwra.com> I'd really like to be able to do what is described here: How to Configure a cron Host for Access to Kerberos Services https://docs.oracle.com/cd/E53394_01/html/E54787/ksetup-task-10.html how far away are we from being able to do this in Linux? Thanks. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From orion at cora.nwra.com Wed Mar 1 22:47:35 2017 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 1 Mar 2017 15:47:35 -0700 Subject: [Freeipa-users] documentation or example of using S42U for NFS In-Reply-To: <90AAB443-7655-4153-8C09-A004370A2E46@cs.rutgers.edu> References: <5BCA6356-7A58-4867-BC6A-E0701F84FC1C@rutgers.edu> <90AAB443-7655-4153-8C09-A004370A2E46@cs.rutgers.edu> Message-ID: <6c30e7d0-8da6-c8a8-fb33-93d1c1975d61@cora.nwra.com> If you ever get this into a repository, I'd love to see it. Thanks. On 01/17/2017 07:44 PM, Charles Hedrick wrote: > Instructions like that are several places. But NFS is different, and I believe the configuration would be different from other services. > > I?ve given up on this approach, and have written my own utilities. I?ve actually got three. The first two assume that users who want to do cron jobs on a machine register a keytab for that machine on a secure system. I don?t want to put the actual keytab on the machine where the user is running, because if someone can become root, they can take the keytab and use it anywhere. (I?m in a computer science dept with systems run by faculty and grad students; also systems in public labs.) > > So instead, I allow users to register that they want to do cron on a specific machine by putting a keytab on a secure server, associated with their username and the hostname. I expect to write a web app to set that up. > > Credserv runs on the machine with the keytabs. It accepts a request from a server, authenticated using the host?s host key (i.e. /etc/krb5.keytab), with a username in the request. If the user has registered a keytab for that host, credserv returns a credential, locked to that IP address, with forwarding off. > > Kgetcred is the client side. It runs setuid root (so it can read /etc/krb5.keytab), though it drops privs as quickly as possible. It creates a credentials cache for the user from the credentials returned from credserv. > > This gives the best granularity of control I can come up with. > > There?s a third utility in the family: renewd. It gets the uids of all current processes, and renews credentials for all of the users. It?s more complex than you?d expect because a normal renewal (as in kinit -R or kstart) leaves a brief period of time when the credentials cache is unusable. This can result in NFS failing. I use a special approach that depends upon the details of the KEYRING implementation. It should be free of race conditions for NFS. If desired, a different approach to avoid race conditions could be used for caches located in /tmp. I haven?t written that code but there?s a comment in the source outlining it. > > I?ll be creating a git repository for the code. > > >> On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski wrote: >> >> On 01/09/2017 09:52 AM, Charles Hedrick wrote: >>> Various documentation suggests that it is possible for Gssproxy to get tickets for users who need to use NFS. This is a possible way to handle things like cron jobs. >>> >>> However while a gssproxy.conf example is given, there?s no sign of what needs to be done in freeipa to authorize it. I tried following instructions for LDAP access, but it doesn?t work. NFS seems to use a different, two-stage method for getting credentials, so that?s not a surprise. There are, not surprisingly, no useful error messages even with logging turned all the way up. >>> >>> >> >> I'm interested in this as well. All I've been able to find so far is: >> >> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/ >> >> haven't tried anything. >> >> -- >> Orion Poplawski >> Technical Manager 720-772-5637 >> NWRA, Boulder/CoRA Office FAX: 303-415-9702 >> 3380 Mitchell Lane orion at nwra.com >> Boulder, CO 80301 http://www.nwra.com > -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From cherdt at umn.edu Thu Mar 2 00:07:52 2017 From: cherdt at umn.edu (Chris Herdt) Date: Wed, 1 Mar 2017 18:07:52 -0600 Subject: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening Message-ID: I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a FreeIPA 3.0.0 master on CentOS 6.8 following the steps at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html At this step: ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir /var/lib/ipa/replica-info-replicaname.example.com.gpg I get the error: ERROR cannot connect to 'ldaps://master.example.com' I ran ipa-replica-conncheck and found that port 636 is not accessible: Port check failed! Inaccessible port(s): 636 (TCP) The port is not blocked. I'm wondering where in the configuration for FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there is a way I can specify to use port 389 for setting up the replica. Thanks! -- Chris Herdt Systems Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Thu Mar 2 02:46:54 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Wed, 1 Mar 2017 21:46:54 -0500 Subject: [Freeipa-users] How to change kerberos key lifetime? In-Reply-To: <20170217145655.GE18161@10.4.128.1> References: <20170216072250.GA6059@dkupka.usersys.redhat.com> <20170216134830.GE6059@dkupka.usersys.redhat.com> <20170217145655.GE18161@10.4.128.1> Message-ID: Hello David/Lukas Thank you for your assistance so far. I still have the problem and not even sure what to look at next. We are still seeing key expiry error from NFS even after the proposed changes. [william at silicon ~]$ ssh iron Last login: Wed Mar 1 19:26:56 2017 from silicon.eng.example.com Could not chdir to home directory /home/william: Key has expired [william at iron /]$ [rtdamgr at silicon ~]$ ssh manganese Last login: Wed Mar 1 19:26:57 2017 from silicon.eng.example.com Could not chdir to home directory /home/william: Permission denied [william at manganese /]$ [william at silicon ~]$ ssh iron Last login: Wed Mar 1 19:58:36 2017 from manganese.eng.example.com DISPLAY is manganese:2 [william at iron ~]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_800 These are the changes that I currently have on my sssd.conf [domain/eng.example.com] krb5_realm = ENG.EXAMPLE.COM krb5_server = hydrogen.eng.example.com auth_provider = krb5 krb5_renewable_lifetime = 50d krb5_renew_interval = 3600 cache_credentials = True krb5_store_password_if_offline = True According to this article, this change would ensure that the system auto renew the keys for the next 50 days. Why would this key expiry still show up? http://people.redhat.com/steved/Summits/Summit13/Summit_Handout13.pdf One side question, that is the difference between "auth_provider = krb5" and "auth_provider = ipa"? In another word, what is expected different between the two as far as IPA usage is concerned and what would make one choose one over the other? Regards, William On 17 February 2017 at 09:56, Lukas Slebodnik wrote: > On (16/02/17 18:05), William Muriithi wrote: >>> The fact that your desktops are using SSSD changes the situation dramatically. >>> >>> SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in. >>> And can be configured to renew the ticket for the user until the ticket renew >>> life time expires. >>> >>> Given this you can keep ticket life time reasonable short (~1 day) set ticket >>> renewable life time to longer period (~2 weeks) and maintain reasonable >>> security level without negative impact on user's daily work. >>> >>> Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options >>> in sssd-krb5 man page. >>> >>Thanks a lot. I did actually end up using this. Will wait for a >>couple of days and see if anybody if the situation is better and >>update you. >> >>Curious though, why isn't renewal interval setup by default? Is there >>a negative consequence of having SSSD renewing tickets by default? I >>can't think of any and hence a bit lost on explaining the default >>setup > > Desktop/laptop user usually does not need automatic renewal. > They authenticate/login/unlock screen quite often and for each > action sssd authenticate against IPA server which automatically get/renew > krb5 ticket. Unless machine is offline. > > LS From lkrispen at redhat.com Thu Mar 2 08:26:55 2017 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 02 Mar 2017 09:26:55 +0100 Subject: [Freeipa-users] replication breaks intermittently In-Reply-To: <1580318136.1396893.1488395920317@mail.yahoo.com> References: <1580318136.1396893.1488395920317.ref@mail.yahoo.com> <1580318136.1396893.1488395920317@mail.yahoo.com> Message-ID: <58B7D74F.7040201@redhat.com> On 03/01/2017 08:18 PM, pgb205 wrote: > [01/Mar/2017:18:19:48 +0000] agmt="cn=meTo ipa2.internal.domain" > (ipa2:389) - Can't locate CSN 582301c3000d00770000 in the changelog > (DB rc=-30988). If replication stops, the consumer may need to be > reinitialized. > [01/Mar/2017:18:19:48 +0000] NSMMReplicationPlugin - changelog program > - agmt="cn=meToipa2.internal.domain" (ipa2:389): CSN > 582301c3000d00770000 not found, we aren't as up to date, or we purged > [01/Mar/2017:18:19:48 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa2.internal.domain" (ipa2:389): Data required to update > replica has been purged. The replica must be reinitialized. > [01/Mar/2017:18:19:48 +0000] NSMMReplicationPlugin - > agmt="cn=meToipa2.internal.domain" (ipa2:389): Incremental update > failed and requires administrator action the timestamp in the csn: 582301c3 is from Nov,9, 2016. so it is very likely that it was trimmed from the changelog or lost during some reinitialization. could you verify to which server the replicaid '0077' == 119 refers and if it still exists > > > > > Seeing the above in the logs after seeing problems with replication. > The data entered on one replica isn't making it to others. There are > no problems with connectivity between the servers and all necessary > ports are open. Currently we are getting around this problem by > running a script to perform force sync. > > Any suggestions on the things that may be setup wrong to take a look at? > > > > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Mar 2 08:39:34 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 2 Mar 2017 09:39:34 +0100 Subject: [Freeipa-users] IPA 4.4 CA Replications In-Reply-To: References: Message-ID: On 01.03.2017 22:00, Matt Wells wrote: > I have two new IPA 4.4 servers on CentOS7 installed in a lab. I built > the first, joined the second and promoted it to be a master. Thus far > all went well. > > I then ran the ipa-ca-install and when I log back in I see that it has > "domain,CA" attached to it. However when I hit the main IPA page it > informs me I only have one server in the CA role. > Drilling down into server2 I see it does not have that role assigned. > I'm certain I missed an easy step but I've been unable to locate it. > > Any guidance would be greatly appreciated. > > Hello, can you provide more info? How did you install servers (options used), on which server you ran ipa-ca-install ? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Mar 2 08:48:29 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 2 Mar 2017 09:48:29 +0100 Subject: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening In-Reply-To: References: Message-ID: <35945c0c-e1e2-3d34-cde3-2eeae5408a15@redhat.com> On 02.03.2017 01:07, Chris Herdt wrote: > I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a > FreeIPA 3.0.0 master on CentOS 6.8 following the steps at > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html > > At this step: > ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir > /var/lib/ipa/replica-info-replicaname.example.com.gpg > > I get the error: > ERROR cannot connect to 'ldaps://master.example.com > ' > > I ran ipa-replica-conncheck and found that port 636 is not accessible: > Port check failed! Inaccessible port(s): 636 (TCP) > > The port is not blocked. I'm wondering where in the configuration for > FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there > is a way I can specify to use port 389 for setting up the replica. > > Thanks! > > -- > Chris Herdt > Systems Administrator > > Hello, this is known issue only in FreeIPA 4.4.x, this will be fixed in next minor update which should be released soon to RHEL7.3 (I don't know how fast it will be in Centos) so you can wait, or enable it manually (not nice) sorry for troubles Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From keesb at ghs.com Thu Mar 2 10:40:38 2017 From: keesb at ghs.com (Kees Bakker) Date: Thu, 2 Mar 2017 11:40:38 +0100 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> <7db8ae96-0cc6-b99a-195b-a815ba605fe4@ghs.com> <48f35842-b229-aed7-7f08-73cfada57557@gmail.com> Message-ID: <680a3dc2-5b29-2de9-0683-85d866e6b4a1@ghs.com> On 24-02-17 14:38, Brendan Kearney wrote: > On 02/24/2017 03:33 AM, Kees Bakker wrote: >> On 23-02-17 15:39, Brendan Kearney wrote: >>> On 02/23/2017 09:11 AM, Kees Bakker wrote: >>>> On 23-02-17 13:51, Brendan Kearney wrote: >>>>> On 02/23/2017 07:32 AM, Kees Bakker wrote: >>>>>> On 22-02-17 17:33, Brendan Kearney wrote: >>>>>>> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>>>>>>> On 22-02-17 14:05, Brendan Kearney wrote: >>>>>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>>>>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>>>>>>> Hey, >>>>>>>>>>>> >>>>>>>>>>>> Maybe one of the NFS users on this list could give me a hint what >>>>>>>>>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>>>>>>>>> >>>>>>>>>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>>>>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>>>>>>> >>>>>>>>>>>> However, only root can actually access the mounted contents. Any other user >>>>>>>>>>>> only sees question marks as shown below. >>>>>>>>>>>> >>>>>>>>>>>> The mount command is simple. >>>>>>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>>>>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>>>>>>> >>>>>>>>>>>> On the server side /etc/exports looks like this. >>>>>>>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>>>>>>> >>>>>>>>>>>> $ sudo mount |grep nfs >>>>>>>>>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>>>>>>> >>>>>>>>>>>> $ sudo ls -ld /nfshome >>>>>>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>>>>>>> $ sudo ls -l /nfshome >>>>>>>>>>>> total 0 >>>>>>>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>>>>>>> >>>>>>>>>>>> $ ls -l /nfshome >>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>> $ ls -l / | grep nfshome >>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>>>>>>> >>>>>>>>>>> [...] Continuing story... I've tried various things in the meantime. I've set up two test environments with virtual machines (virtualbox). * with Fedora 25; this works. * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). I also looked at the verbose output of rpc.gssd, it gives ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection getting credentials for client with uid 60001 for server srv1.example.com getting credentials for client with uid 60001 for server srv1.example.com WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com But the user really did get a TGT. $ klist Ticket cache: KEYRING:persistent:60001:60001 Default principal: keesb at EXAMPLE.COM Valid starting Expires Service principal 02-03-17 10:25:25 03-03-17 10:25:22 krbtgt/EXAMPLE.COM at EXAMPLE.COM So, still no solution for Ubuntu + freeipa + nfs. BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK. However, there is only any output when root (uid 0) does a NFS directory lookup. When a regular user tries to stat the NFS directory it does not even get to the point where id mapping is done. -- Kees From coolum.surfless at gmail.com Thu Mar 2 11:36:42 2017 From: coolum.surfless at gmail.com (Craig Warner) Date: Thu, 2 Mar 2017 21:36:42 +1000 Subject: [Freeipa-users] xrdp and free ipa Message-ID: <667A3DE4-3207-44DA-BF7C-FD1353F1AB12@gmail.com> Has anyone on the list any experience or knowledge in setting up xrdp using freeipa as authentication on Centos 7? I have little to limited experience in both. From bpk678 at gmail.com Thu Mar 2 12:34:49 2017 From: bpk678 at gmail.com (Brendan Kearney) Date: Thu, 2 Mar 2017 07:34:49 -0500 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: <680a3dc2-5b29-2de9-0683-85d866e6b4a1@ghs.com> References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> <7db8ae96-0cc6-b99a-195b-a815ba605fe4@ghs.com> <48f35842-b229-aed7-7f08-73cfada57557@gmail.com> <680a3dc2-5b29-2de9-0683-85d866e6b4a1@ghs.com> Message-ID: On 03/02/2017 05:40 AM, Kees Bakker wrote: > On 24-02-17 14:38, Brendan Kearney wrote: >> On 02/24/2017 03:33 AM, Kees Bakker wrote: >>> On 23-02-17 15:39, Brendan Kearney wrote: >>>> On 02/23/2017 09:11 AM, Kees Bakker wrote: >>>>> On 23-02-17 13:51, Brendan Kearney wrote: >>>>>> On 02/23/2017 07:32 AM, Kees Bakker wrote: >>>>>>> On 22-02-17 17:33, Brendan Kearney wrote: >>>>>>>> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>>>>>>>> On 22-02-17 14:05, Brendan Kearney wrote: >>>>>>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>>>>>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>>>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>>>>>>>> Hey, >>>>>>>>>>>>> >>>>>>>>>>>>> Maybe one of the NFS users on this list could give me a hint what >>>>>>>>>>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>>>>>>>>>> >>>>>>>>>>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>>>>>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>>>>>>>> >>>>>>>>>>>>> However, only root can actually access the mounted contents. Any other user >>>>>>>>>>>>> only sees question marks as shown below. >>>>>>>>>>>>> >>>>>>>>>>>>> The mount command is simple. >>>>>>>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>>>>>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>>>>>>>> >>>>>>>>>>>>> On the server side /etc/exports looks like this. >>>>>>>>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>>>>>>>> >>>>>>>>>>>>> $ sudo mount |grep nfs >>>>>>>>>>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>>>>>>>> >>>>>>>>>>>>> $ sudo ls -ld /nfshome >>>>>>>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>>>>>>>> $ sudo ls -l /nfshome >>>>>>>>>>>>> total 0 >>>>>>>>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>>>>>>>> >>>>>>>>>>>>> $ ls -l /nfshome >>>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>>> $ ls -l / | grep nfshome >>>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>>>>>>>> > [...] > > Continuing story... > > I've tried various things in the meantime. I've set up two test environments with virtual > machines (virtualbox). > * with Fedora 25; this works. > * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). > > I also looked at the verbose output of rpc.gssd, it gives > > ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection does the actual error message say @REALM, or did you substitute that to obscure sensitive info? if it does actually say @REALM, then you are missing a config directive somewhere, that specifies the kerberos realm. > getting credentials for client with uid 60001 for server srv1.example.com > getting credentials for client with uid 60001 for server srv1.example.com > WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com > > But the user really did get a TGT. > > $ klist > Ticket cache: KEYRING:persistent:60001:60001 > Default principal: keesb at EXAMPLE.COM > > Valid starting Expires Service principal > 02-03-17 10:25:25 03-03-17 10:25:22 krbtgt/EXAMPLE.COM at EXAMPLE.COM > > So, still no solution for Ubuntu + freeipa + nfs. > > BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK. However, > there is only any output when root (uid 0) does a NFS directory lookup. When a regular > user tries to stat the NFS directory it does not even get to the point where id mapping is > done. From Terry.John at coxauto.co.uk Wed Mar 1 14:20:52 2017 From: Terry.John at coxauto.co.uk (Terry John) Date: Wed, 1 Mar 2017 14:20:52 +0000 Subject: [Freeipa-users] Kerberos hanging In-Reply-To: References: Message-ID: Thanks for that. I have an issue with NTP but I have got around that and spent many a happy hour updating the times on my clients. The errors were in /var/log/krb5kdc.log as "clock skew too great". It's only when I got rid of them, and there were many, could I clearly see the normal operation Terry John >Check time an date on all involved servers/workstations - if the difference is more than 300 seconds , Kerberos might not work correctly. Apply the same time to all involved >servers/workstations. >Gerald >> I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The problem manifests itself as no authentication, and no DNS. >> It seems Kerberos just stops responding to requests and requests just >> get queued up # netstat -tuna | grep SYN_RECV Active Internet >> connections (servers and established) >> Proto Recv-Q Send-Q Local Address Foreign Address State >> tcp 0 0 :88 :55440 SYN_RECV >> tcp 0 0 :88 :40076 SYN_RECV >> tcp 0 0 :88 :41525 SYN_RECV >> tcp 0 0 :88 :53958 SYN_RECV >> tcp 0 0 :88 :54240 SYN_RECV >> Looking at /var/log/krb5kdc.log >> The normal activity of AS_REQ and TGS_REC messages just stops. No error messages. Just no new messages. >> In /var/log/messages the named server reports messages like Mar 1 >> 00:00:23 freeipa named[18989]: LDAP error: Can't contact LDAP server >> Mar 1 00:00:23 freeipa named[18989]: connection to the LDAP server >> was lost Mar 1 00:00:23 freeipa named[18989]: bind to LDAP server >> failed: Can't contact LDAP server >> The command "kinit" is totally unresponsive and will time out if you wait long enough. >> If I try to restart ipa with "service ipa restart", it hangs on the first stage, trying to stop DIRSRV. >> I have to do a "ps ax" and look for this line. >> 2758 ? Sl 2:13 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-MY-REALM -i /var/run/dirsrv/slapd-MY-REALM.pid -w /var/run/dirsrv/slapd-MY-REALM.startpid >> Then I have to a "kill -9" on the pid >> Then I can do "service ipa restart" >> After that it works ok for a while. "A while" may be a few minutes or several hours. >> The filesystem is only 58% used and "free" shows no swap in use so there seems to be plenty of RAM available. >> "top" shows CPU(s) 96% idle with "dirsirv" typically using about 3%CPU at most Cox Automotive group of companies within the UK comprises: Cox Automotive UK Limited (registered number: 03183918), Manheim Limited (registered number: 00448761), Cox Automotive Retail Solutions Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), and Real Time Communications Limited (registered number: 04277845). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Cox Automotive group of companies within the UK operates under various brand/trading names including Cox Automotive UK, Manheim Inspection Services, Manheim Auctions, Modix, Xtime and Closeit. V:0CF72C13B2AD From gkubok at gmail.com Thu Mar 2 02:29:22 2017 From: gkubok at gmail.com (Greg) Date: Thu, 2 Mar 2017 02:29:22 +0000 Subject: [Freeipa-users] documentation or example of using S42U for NFS In-Reply-To: <6c30e7d0-8da6-c8a8-fb33-93d1c1975d61@cora.nwra.com> References: <5BCA6356-7A58-4867-BC6A-E0701F84FC1C@rutgers.edu> <90AAB443-7655-4153-8C09-A004370A2E46@cs.rutgers.edu> <6c30e7d0-8da6-c8a8-fb33-93d1c1975d61@cora.nwra.com> Message-ID: I've been at this as well for a while now, and managed to make it work for my NFS needs (automounting user homes with password-less logons). Whether and how this would apply to cron or other services, I don't know yet, but presumably would/should work in a similar manner. My env: $ lsb_release -d Description: Red Hat Enterprise Linux Server release 7.3 (Maipo) $ rpm -q ipa-server ipa-server-4.4.0-14.el7_3.4.x86_64 $ ipa --version VERSION: 4.4.0, API_VERSION: 2.213 This is what worked for me in the end: 1. Create "nfs/nfsserver.dom.com at DOM.COM" service, and add to NFS server's /etc/krb5.keytab. 2. Create IPA "servicedelegation" rule/targets, so that they look like so: $ ipa servicedelegationrule-show ipa-nfs-delegation Delegation name: ipa-nfs-delegation Allowed Target: ipa-nfs-delegation-targets Member principals: *host*/*nfsclient*.dom.com at DOM.COM $ ipa servicedelegationtarget-show ipa-nfs-delegation-targets Delegation name: ipa-nfs-delegation-targets Member principals: *nfs*/*nfsserver*.dom.com at DOM.COM Only niggle here is IPA CLI didn't let me add "host/..." principal to the rule, or perhaps there's a default LDAP ACI of some sort and it requires a privilege/permission to be granted. The "ipa servicedelegationrule-add-member ..." command simply says "no such entry" for "host/..." type principals. Maybe IPA folks can comment. I force added it to the delegation rule via LDAP instead using this ldif: dn: cn=ipa-nfs-delegation,cn=s4u2proxy,cn=etc,dc=dom,dc=com changetype: modify add: memberPrincipal memberPrincipal: host/nfsclient.dom.com at DOM.COM The "nfs/..." principal can be added using CLI "ipa servicedelegationtarget-add-member ..." just fine. 3. Allow the "nfsclient" host to impersonate users: $ ipa host-mod nfsclient.dom.com --ok-to-auth-as-delegate=true 4. On the "nfsclient" machine, add "impersonate = true" line in the "[service/nfs-client]" section of /etc/gssproxy/gssproxy.conf. 5. Restart nfs/gssproxy/rpc services on client and server (it's probably just gssproxy on the client that needs a kick, but just to be sure). I was also religiously doing "sss_cache -E" for good measure, unmounting anything that got mounted, and clearing /var/lib/gssproxy/clients of all caches, to start as cleanly before each attempt at user logon. Obv make sure the user does not have an existing/valid ticket in their own cache ("kdestroy -A" as the user), otherwise it'll just mount successfully without delegation. I think that's it, I've messed about with the config for a long time and in many places, so there's a small chance there's something else that I did and don't remember. Gssproxy config on "nfsserver" is vanilla, as are my sssd.confs and krb5.confs on both machines, can't think of much else that I might've changed for now. So my IPA automount config now mounts users' home dirs on the "nfsclient", without any tickets or keytabs from users. There's also a "krb5_principal" option available in gssproxy.conf - I tried to set that to "nfs/nfsclient at DOM.COM" in "[service/nfs-client]" section on the "nfsclient" machine, to try and force gssproxy to use that principal instead of "host/...", but it didn't seem to work, gssproxy defaults to "host/...". Possibly mis-understanding what this option is for, and possibly "host/..." is the safer/standard option? I'm assuming it's default for a reason, or maybe just operational convenience (not having to pollute /etc/krb5.keytabs with more principals than necessary). Hope this helps. -- Thanks, Greg Kubok. On 1 March 2017 at 22:47, Orion Poplawski wrote: > If you ever get this into a repository, I'd love to see it. Thanks. > > On 01/17/2017 07:44 PM, Charles Hedrick wrote: > > Instructions like that are several places. But NFS is different, and I > believe the configuration would be different from other services. > > > > I?ve given up on this approach, and have written my own utilities. I?ve > actually got three. The first two assume that users who want to do cron > jobs on a machine register a keytab for that machine on a secure system. I > don?t want to put the actual keytab on the machine where the user is > running, because if someone can become root, they can take the keytab and > use it anywhere. (I?m in a computer science dept with systems run by > faculty and grad students; also systems in public labs.) > > > > So instead, I allow users to register that they want to do cron on a > specific machine by putting a keytab on a secure server, associated with > their username and the hostname. I expect to write a web app to set that up. > > > > Credserv runs on the machine with the keytabs. It accepts a request from > a server, authenticated using the host?s host key (i.e. /etc/krb5.keytab), > with a username in the request. If the user has registered a keytab for > that host, credserv returns a credential, locked to that IP address, with > forwarding off. > > > > Kgetcred is the client side. It runs setuid root (so it can read > /etc/krb5.keytab), though it drops privs as quickly as possible. It creates > a credentials cache for the user from the credentials returned from > credserv. > > > > This gives the best granularity of control I can come up with. > > > > There?s a third utility in the family: renewd. It gets the uids of all > current processes, and renews credentials for all of the users. It?s more > complex than you?d expect because a normal renewal (as in kinit -R or > kstart) leaves a brief period of time when the credentials cache is > unusable. This can result in NFS failing. I use a special approach that > depends upon the details of the KEYRING implementation. It should be free > of race conditions for NFS. If desired, a different approach to avoid race > conditions could be used for caches located in /tmp. I haven?t written that > code but there?s a comment in the source outlining it. > > > > I?ll be creating a git repository for the code. > > > > > >> On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski > wrote: > >> > >> On 01/09/2017 09:52 AM, Charles Hedrick wrote: > >>> Various documentation suggests that it is possible for Gssproxy to get > tickets for users who need to use NFS. This is a possible way to handle > things like cron jobs. > >>> > >>> However while a gssproxy.conf example is given, there?s no sign of > what needs to be done in freeipa to authorize it. I tried following > instructions for LDAP access, but it doesn?t work. NFS seems to use a > different, two-stage method for getting credentials, so that?s not a > surprise. There are, not surprisingly, no useful error messages even with > logging turned all the way up. > >>> > >>> > >> > >> I'm interested in this as well. All I've been able to find so far is: > >> > >> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/ > >> > >> haven't tried anything. > >> > >> -- > >> Orion Poplawski > >> Technical Manager 720-772-5637 > >> NWRA, Boulder/CoRA Office FAX: 303-415-9702 > >> 3380 Mitchell Lane orion at nwra.com > >> Boulder, CO 80301 http://www.nwra.com > > > > > -- > Orion Poplawski > Technical Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane orion at nwra.com > Boulder, CO 80301 http://www.nwra.com > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrayha at 163.com Thu Mar 2 10:40:49 2017 From: hrayha at 163.com (hao) Date: Thu, 2 Mar 2017 18:40:49 +0800 (CST) Subject: [Freeipa-users] freeipa3.0.0 can't renew certificate In-Reply-To: <5c97702.59d3.15a8d15079f.Coremail.hrayha@163.com> References: <5c97702.59d3.15a8d15079f.Coremail.hrayha@163.com> Message-ID: <450ca1f6.d8ab.15a8e9ba58e.Coremail.hrayha@163.com> now I execute getcert list?all certificate status MONITORING,but there was an error ca-error: Internal error: no response to "http://ipaserver.xxx.io:9180/ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=2&renewal=true&xml=true" At 2017-03-02 11:34:10, "hao" wrote: Hi: I have finished reading http://www.freeipa.org/page/IPA_2x_Certificate_Renewal , before execute,I stop tracking all cert in `getcert list` Now, only "issuer: CN=IPA RA,O=XXX.IO " certificate expires at 2018-02-28 08:14:38 UTC,other certificate still expires at 2017-02-15 06:10:36 UTC? I execute "for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" do /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P xxxxxx done" and all command in "http://www.freeipa.org/page/IPA_2x_Certificate_Renewal" but still no effect I've tried ?http://www.freeipa.org/page/Certmonger? ?http://www.freeipa.org/page/Howto/CA_Certificate_Renewal? ?http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master? before that?I'm not sure if there will be an error step Please help me Thank you ?????|30?????????????MUJI???????????????????>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.dimri2016 at gmail.com Thu Mar 2 13:39:41 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Thu, 2 Mar 2017 19:09:41 +0530 Subject: [Freeipa-users] Switch sudoers to IPA Message-ID: Hi List, I have sudo and normal users accessing linux systems using their private key without IPA. I have IPA fully functioning and now i want to switch the users from local file login to IPA. Any new user i create in IPA can SSH into ipa client jump boxes fine. I want to know how i can migrate existing local sudoers users to IPA. This is what i have done to achieve this: 1- Created a new user in IPA with the same name as i have in Jumpbox. 2 - Added the public key of that user in IPA. 3- Added the user to jumpbox_usergroup as my sshd.conf forces the users of this group to authenticate against the pam/sssd Now when i try to ssh into jumpbox using as i was doing before i still logs into the jumpbox via unix pam and not IPA. What should i be doing so that the "existing" local unix users can login via IPA? I am still playing with configuration to make it work but thought of asking this to you all to see if i can get a solution faster. Many Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From keesb at ghs.com Thu Mar 2 13:43:40 2017 From: keesb at ghs.com (Kees Bakker) Date: Thu, 2 Mar 2017 14:43:40 +0100 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> <7db8ae96-0cc6-b99a-195b-a815ba605fe4@ghs.com> <48f35842-b229-aed7-7f08-73cfada57557@gmail.com> <680a3dc2-5b29-2de9-0683-85d866e6b4a1@ghs.com> Message-ID: <375c316b-a1e8-028c-9fb0-31ef2c175542@ghs.com> On 02-03-17 13:34, Brendan Kearney wrote: > On 03/02/2017 05:40 AM, Kees Bakker wrote: >> On 24-02-17 14:38, Brendan Kearney wrote: >>> On 02/24/2017 03:33 AM, Kees Bakker wrote: >>>> On 23-02-17 15:39, Brendan Kearney wrote: >>>>> On 02/23/2017 09:11 AM, Kees Bakker wrote: >>>>>> On 23-02-17 13:51, Brendan Kearney wrote: >>>>>>> On 02/23/2017 07:32 AM, Kees Bakker wrote: >>>>>>>> On 22-02-17 17:33, Brendan Kearney wrote: >>>>>>>>> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>>>>>>>>> On 22-02-17 14:05, Brendan Kearney wrote: >>>>>>>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>>>>>>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>>>>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>>>>>>>>> Hey, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Maybe one of the NFS users on this list could give me a hint what >>>>>>>>>>>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>>>>>>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However, only root can actually access the mounted contents. Any other user >>>>>>>>>>>>>> only sees question marks as shown below. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The mount command is simple. >>>>>>>>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>>>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>>>>>>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>>>>>>>>> >>>>>>>>>>>>>> On the server side /etc/exports looks like this. >>>>>>>>>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>>>>>>>>> >>>>>>>>>>>>>> $ sudo mount |grep nfs >>>>>>>>>>>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>>>>>>>>> >>>>>>>>>>>>>> $ sudo ls -ld /nfshome >>>>>>>>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>>>>>>>>> $ sudo ls -l /nfshome >>>>>>>>>>>>>> total 0 >>>>>>>>>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>>>>>>>>> >>>>>>>>>>>>>> $ ls -l /nfshome >>>>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>>>> $ ls -l / | grep nfshome >>>>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>>>>>>>>> >> [...] >> >> Continuing story... >> >> I've tried various things in the meantime. I've set up two test environments with virtual >> machines (virtualbox). >> * with Fedora 25; this works. >> * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). >> >> I also looked at the verbose output of rpc.gssd, it gives >> >> ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection > does the actual error message say @REALM, or did you substitute that to obscure sensitive info? if it does actually say @REALM, then you are missing a config directive somewhere, that specifies the kerberos realm. Be assured that I'm using the real thing. >> getting credentials for client with uid 60001 for server srv1.example.com >> getting credentials for client with uid 60001 for server srv1.example.com >> WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but not for another user. Log when root is listing the NFS directory Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 ' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '*' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'srv1.example.com' is 'srv1.example.com' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'clnt1.example.com' is 'clnt1.example.com' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for CLNT1.REALM$@REALM while getting keytab entry for 'CLNT1.REALM$@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for root/clnt1.example.com at REALM while getting keytab entry for 'root/clnt1.example.com at REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for nfs/clnt1.example.com at REALM while getting keytab entry for 'nfs/clnt1.example.com at REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Success getting keytab entry for 'host/clnt1.example.com at REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using FILE:/tmp/krb5ccmachine_REALM as credentials cache for machine creds Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_REALM Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating context using fsuid 0 (save_uid 0) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating tcp client for server srv1.example.com Mar 2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: port already set to 2049 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating context with server nfs at srv1.example.com Mar 2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: serialize_krb5_ctx: lucid version! Mar 2 14:23:52 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: protocol 1 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: doing downcall lifetime_rec 74121 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'srv1.example.com' is 'srv1.example.com' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'clnt1.example.com' is 'clnt1.example.com' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for CLNT1.REALM$@REALM while getting keytab entry for 'CLNT1.REALM$@REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for root/clnt1.example.com at REALM while getting keytab entry for 'root/clnt1.example.com at REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for nfs/clnt1.example.com at REALM while getting keytab entry for 'nfs/clnt1.example.com at REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Success getting keytab entry for 'host/clnt1.example.com at REALM' Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using FILE:/tmp/krb5ccmachine_REALM as credentials cache for machine creds Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_REALM Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating context using fsuid 0 (save_uid 0) Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating tcp client for server srv1.example.com Mar 2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: port already set to 2049 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating context with server nfs at srv1.example.com Mar 2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: serialize_krb5_ctx: lucid version! Mar 2 14:23:52 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: protocol 1 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 Mar 2 14:23:52 clnt1 rpc.gssd[3612]: doing downcall lifetime_rec 74121 Mar 2 14:23:53 clnt1 rpc.gssd[3612]: destroying client /run/rpc_pipefs/nfs/clnt16 Mar 2 14:23:53 clnt1 rpc.gssd[3612]: destroying client /run/rpc_pipefs/nfs/clnt15 Log when the user is listing the directory Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=60001 enctypes=18,17,16,23,3,1,2 ' Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:24:00 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '' Mar 2 14:24:00 clnt1 rpc.gssd[3612]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection Mar 2 14:24:00 clnt1 rpc.gssd[3612]: getting credentials for client with uid 60001 for server srv1.example.com Mar 2 14:24:00 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' being considered, with preferred realm 'REALM' Mar 2 14:24:00 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' owned by 0, not 60001 Mar 2 14:24:00 clnt1 rpc.gssd[3612]: getting credentials for client with uid 60001 for server srv1.example.com Mar 2 14:24:00 clnt1 rpc.gssd[3612]: WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com Mar 2 14:24:00 clnt1 rpc.gssd[3612]: doing error downcall As an experiment I have changed ownership of /tmp/krb5ccmachine_REALM to uid 60001. And now the user can list the NFS directory. The gssd log Mar 2 14:36:40 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:36:40 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=60001 enctypes=18,17,16,23,3,1,2 ' Mar 2 14:36:40 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) Mar 2 14:36:40 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '' Mar 2 14:36:40 clnt1 rpc.gssd[3612]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection Mar 2 14:36:40 clnt1 rpc.gssd[3612]: getting credentials for client with uid 60001 for server srv1.example.com Mar 2 14:36:40 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' being considered, with preferred realm 'REALM' Mar 2 14:36:40 clnt1 rpc.gssd[3612]: CC 'FILE:/tmp/krb5ccmachine_REALM'(host/clnt1.example.com at REALM) passed all checks and has mtime of 1488448753 Mar 2 14:36:40 clnt1 rpc.gssd[3612]: using FILE:/tmp/krb5ccmachine_REALM as credentials cache for client with uid 60001 for server srv1.example.com Mar 2 14:36:40 clnt1 rpc.gssd[3612]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_REALM Mar 2 14:36:40 clnt1 rpc.gssd[3612]: creating context using fsuid 60001 (save_uid 0) Mar 2 14:36:40 clnt1 rpc.gssd[3612]: creating tcp client for server srv1.example.com Mar 2 14:36:40 clnt1 rpc.gssd[3612]: DEBUG: port already set to 2049 Mar 2 14:36:40 clnt1 rpc.gssd[3612]: creating context with server nfs at srv1.example.com Mar 2 14:36:40 clnt1 rpc.gssd[3612]: DEBUG: serialize_krb5_ctx: lucid version! Mar 2 14:36:40 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: protocol 1 Mar 2 14:36:40 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 Mar 2 14:36:40 clnt1 rpc.gssd[3612]: doing downcall lifetime_rec 73353 I'm guessing the solution must be in that area. The credentials cache must be somewhere where the user can have access to it. How would I do that? >> >> But the user really did get a TGT. >> >> $ klist >> Ticket cache: KEYRING:persistent:60001:60001 >> Default principal: keesb at EXAMPLE.COM >> >> Valid starting Expires Service principal >> 02-03-17 10:25:25 03-03-17 10:25:22 krbtgt/EXAMPLE.COM at EXAMPLE.COM >> >> So, still no solution for Ubuntu + freeipa + nfs. >> >> BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK. However, >> there is only any output when root (uid 0) does a NFS directory lookup. When a regular >> user tries to stat the NFS directory it does not even get to the point where id mapping is >> done. > > From bpk678 at gmail.com Thu Mar 2 13:55:38 2017 From: bpk678 at gmail.com (Brendan Kearney) Date: Thu, 2 Mar 2017 08:55:38 -0500 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: <375c316b-a1e8-028c-9fb0-31ef2c175542@ghs.com> References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> <7db8ae96-0cc6-b99a-195b-a815ba605fe4@ghs.com> <48f35842-b229-aed7-7f08-73cfada57557@gmail.com> <680a3dc2-5b29-2de9-0683-85d866e6b4a1@ghs.com> <375c316b-a1e8-028c-9fb0-31ef2c175542@ghs.com> Message-ID: <279be76e-97c4-8251-0848-4135544451ba@gmail.com> On 03/02/2017 08:43 AM, Kees Bakker wrote: > On 02-03-17 13:34, Brendan Kearney wrote: >> On 03/02/2017 05:40 AM, Kees Bakker wrote: >>> On 24-02-17 14:38, Brendan Kearney wrote: >>>> On 02/24/2017 03:33 AM, Kees Bakker wrote: >>>>> On 23-02-17 15:39, Brendan Kearney wrote: >>>>>> On 02/23/2017 09:11 AM, Kees Bakker wrote: >>>>>>> On 23-02-17 13:51, Brendan Kearney wrote: >>>>>>>> On 02/23/2017 07:32 AM, Kees Bakker wrote: >>>>>>>>> On 22-02-17 17:33, Brendan Kearney wrote: >>>>>>>>>> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>>>>>>>>>> On 22-02-17 14:05, Brendan Kearney wrote: >>>>>>>>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>>>>>>>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>>>>>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>>>>>>>>>> Hey, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Maybe one of the NFS users on this list could give me a hint what >>>>>>>>>>>>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>>>>>>>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, only root can actually access the mounted contents. Any other user >>>>>>>>>>>>>>> only sees question marks as shown below. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The mount command is simple. >>>>>>>>>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>>>>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>>>>>>>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On the server side /etc/exports looks like this. >>>>>>>>>>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> $ sudo mount |grep nfs >>>>>>>>>>>>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> $ sudo ls -ld /nfshome >>>>>>>>>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>>>>>>>>>> $ sudo ls -l /nfshome >>>>>>>>>>>>>>> total 0 >>>>>>>>>>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> $ ls -l /nfshome >>>>>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>>>>> $ ls -l / | grep nfshome >>>>>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>>>>>>>>>> >>> [...] >>> >>> Continuing story... >>> >>> I've tried various things in the meantime. I've set up two test environments with virtual >>> machines (virtualbox). >>> * with Fedora 25; this works. >>> * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). >>> >>> I also looked at the verbose output of rpc.gssd, it gives >>> >>> ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection >> does the actual error message say @REALM, or did you substitute that to obscure sensitive info? if it does actually say @REALM, then you are missing a config directive somewhere, that specifies the kerberos realm. > Be assured that I'm using the real thing. > >>> getting credentials for client with uid 60001 for server srv1.example.com >>> getting credentials for client with uid 60001 for server srv1.example.com >>> WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com > So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but not for another > user. > > Log when root is listing the NFS directory > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 ' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '*' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'srv1.example.com' is 'srv1.example.com' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'clnt1.example.com' is 'clnt1.example.com' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for CLNT1.REALM$@REALM while getting keytab entry for 'CLNT1.REALM$@REALM' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for root/clnt1.example.com at REALM while getting keytab entry for 'root/clnt1.example.com at REALM' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for nfs/clnt1.example.com at REALM while getting keytab entry for 'nfs/clnt1.example.com at REALM' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Success getting keytab entry for 'host/clnt1.example.com at REALM' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using FILE:/tmp/krb5ccmachine_REALM as credentials cache for machine creds > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_REALM > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating context using fsuid 0 (save_uid 0) > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating tcp client for server srv1.example.com > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: port already set to 2049 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating context with server nfs at srv1.example.com > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: serialize_krb5_ctx: lucid version! > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: protocol 1 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: doing downcall lifetime_rec 74121 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'srv1.example.com' is 'srv1.example.com' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'clnt1.example.com' is 'clnt1.example.com' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for CLNT1.REALM$@REALM while getting keytab entry for 'CLNT1.REALM$@REALM' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for root/clnt1.example.com at REALM while getting keytab entry for 'root/clnt1.example.com at REALM' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for nfs/clnt1.example.com at REALM while getting keytab entry for 'nfs/clnt1.example.com at REALM' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: Success getting keytab entry for 'host/clnt1.example.com at REALM' > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using FILE:/tmp/krb5ccmachine_REALM as credentials cache for machine creds > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_REALM > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating context using fsuid 0 (save_uid 0) > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating tcp client for server srv1.example.com > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: port already set to 2049 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: creating context with server nfs at srv1.example.com > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: serialize_krb5_ctx: lucid version! > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: protocol 1 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 > Mar 2 14:23:52 clnt1 rpc.gssd[3612]: doing downcall lifetime_rec 74121 > Mar 2 14:23:53 clnt1 rpc.gssd[3612]: destroying client /run/rpc_pipefs/nfs/clnt16 > Mar 2 14:23:53 clnt1 rpc.gssd[3612]: destroying client /run/rpc_pipefs/nfs/clnt15 > > Log when the user is listing the directory > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=60001 enctypes=18,17,16,23,3,1,2 ' > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '' > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: getting credentials for client with uid 60001 for server srv1.example.com > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' being considered, with preferred realm 'REALM' > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' owned by 0, not 60001 > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: getting credentials for client with uid 60001 for server srv1.example.com > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com > Mar 2 14:24:00 clnt1 rpc.gssd[3612]: doing error downcall > > As an experiment I have changed ownership of /tmp/krb5ccmachine_REALM to uid 60001. > And now the user can list the NFS directory. The gssd log > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=60001 enctypes=18,17,16,23,3,1,2 ' > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '' > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: getting credentials for client with uid 60001 for server srv1.example.com > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' being considered, with preferred realm 'REALM' > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: CC 'FILE:/tmp/krb5ccmachine_REALM'(host/clnt1.example.com at REALM) passed all checks and has mtime of 1488448753 > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: using FILE:/tmp/krb5ccmachine_REALM as credentials cache for client with uid 60001 for server srv1.example.com > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_REALM > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: creating context using fsuid 60001 (save_uid 0) > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: creating tcp client for server srv1.example.com > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: DEBUG: port already set to 2049 > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: creating context with server nfs at srv1.example.com > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: DEBUG: serialize_krb5_ctx: lucid version! > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: protocol 1 > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 > Mar 2 14:36:40 clnt1 rpc.gssd[3612]: doing downcall lifetime_rec 73353 > > I'm guessing the solution must be in that area. The credentials cache must be somewhere where > the user can have access to it. How would I do that? file a bug [brendan at desktop ~]$ ll /tmp/ total 36 -rw------- 1 brendan brendan 4111 Mar 2 08:22 krb5cc_1000_9GeQKj -rw------- 1 root root 579 Mar 1 10:08 krb5ccmachine_BPK2.COM users should never have, and never be required to have, access to the machines kerberos credential cache. > >>> But the user really did get a TGT. >>> >>> $ klist >>> Ticket cache: KEYRING:persistent:60001:60001 >>> Default principal: keesb at EXAMPLE.COM >>> >>> Valid starting Expires Service principal >>> 02-03-17 10:25:25 03-03-17 10:25:22 krbtgt/EXAMPLE.COM at EXAMPLE.COM >>> >>> So, still no solution for Ubuntu + freeipa + nfs. >>> >>> BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK. However, >>> there is only any output when root (uid 0) does a NFS directory lookup. When a regular >>> user tries to stat the NFS directory it does not even get to the point where id mapping is >>> done. >> From matt.wells at bridgevine.com Thu Mar 2 14:20:38 2017 From: matt.wells at bridgevine.com (Matt Wells) Date: Thu, 02 Mar 2017 14:20:38 +0000 Subject: [Freeipa-users] IPA 4.4 CA Replications In-Reply-To: References: Message-ID: Thank you for the response Martin. Server1 had no flags upon install however CA, DNS were selected during the installation. Server2 was joined and then the 'ipa-replica-install --skip-conn-check' used to join it. Manual tests of the ports showed all was good but not in the installation so I had to use the '--skip-conn-check'. Server1 - Maximum username length: 32 Home directory base: /home Default shell: /bin/sh Default users group: ipausers Default e-mail domain: lci.devdomain.com Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: FALSE Certificate Subject base: O=LCI.DEVDOMAIN.COM Password Expiration Notification (days): 4 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: nfs:NONE, MS-PAC IPA masters: server1.lci.devdomain.com, server2.lci.devdomain.com IPA CA servers: server1.lci.devdomain.com IPA NTP servers: server1.lci.devdomain.com, server2.lci.devdomain.com IPA CA renewal master: server1.lci.devdomain.com On Thu, Mar 2, 2017 at 12:39 AM Martin Basti wrote: > > > On 01.03.2017 22:00, Matt Wells wrote: > > I have two new IPA 4.4 servers on CentOS7 installed in a lab. I built the > first, joined the second and promoted it to be a master. Thus far all went > well. > > I then ran the ipa-ca-install and when I log back in I see that it has > "domain,CA" attached to it. However when I hit the main IPA page it > informs me I only have one server in the CA role. > Drilling down into server2 I see it does not have that role assigned. > I'm certain I missed an easy step but I've been unable to locate it. > > Any guidance would be greatly appreciated. > > > > Hello, > > can you provide more info? How did you install servers (options used), on > which server you ran ipa-ca-install ? > > > Martin > -- *Matt Wells* *Lead Systems Architect* -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Mar 2 14:22:41 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 2 Mar 2017 15:22:41 +0100 Subject: [Freeipa-users] IPA 4.4 CA Replications In-Reply-To: References: Message-ID: Did you run ipa-ca-install on server2 ? On 02.03.2017 15:20, Matt Wells wrote: > Thank you for the response Martin. Server1 had no flags upon install > however CA, DNS were selected during the installation. Server2 was > joined and then the 'ipa-replica-install --skip-conn-check' used to > join it. Manual tests of the ports showed all was good but not in the > installation so I had to use the '--skip-conn-check'. > Server1 - > Maximum username length: 32 > Home directory base: /home > Default shell: /bin/sh > Default users group: ipausers > Default e-mail domain: lci.devdomain.com > Search time limit: 2 > Search size limit: 100 > User search fields: uid,givenname,sn,telephonenumber,ou,title > Group search fields: cn,description > Enable migration mode: FALSE > Certificate Subject base: O=LCI.DEVDOMAIN.COM > Password Expiration Notification (days): 4 > Password plugin features: AllowNThash > SELinux user map order: > guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 > Default SELinux user: unconfined_u:s0-s0:c0.c1023 > Default PAC types: nfs:NONE, MS-PAC > IPA masters: server1.lci.devdomain.com > , server2.lci.devdomain.com > > IPA CA servers: server1.lci.devdomain.com > > IPA NTP servers: server1.lci.devdomain.com > , server2.lci.devdomain.com > > IPA CA renewal master: server1.lci.devdomain.com > > > > > On Thu, Mar 2, 2017 at 12:39 AM Martin Basti > wrote: > > > > On 01.03.2017 22:00, Matt Wells wrote: >> I have two new IPA 4.4 servers on CentOS7 installed in a lab. I >> built the first, joined the second and promoted it to be a >> master. Thus far all went well. >> >> I then ran the ipa-ca-install and when I log back in I see that >> it has "domain,CA" attached to it. However when I hit the main >> IPA page it informs me I only have one server in the CA role. >> Drilling down into server2 I see it does not have that role >> assigned. >> I'm certain I missed an easy step but I've been unable to locate >> it. >> >> Any guidance would be greatly appreciated. >> >> > > Hello, > > can you provide more info? How did you install servers (options > used), on which server you ran ipa-ca-install ? > > > Martin > > -- > *Matt Wells* > *Lead Systems Architect* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrayha at 163.com Thu Mar 2 14:48:42 2017 From: hrayha at 163.com (hao) Date: Thu, 2 Mar 2017 22:48:42 +0800 (CST) Subject: [Freeipa-users] freeipa3.0.0 can't renew certificate In-Reply-To: <450ca1f6.d8ab.15a8e9ba58e.Coremail.hrayha@163.com> References: <5c97702.59d3.15a8d15079f.Coremail.hrayha@163.com> <450ca1f6.d8ab.15a8e9ba58e.Coremail.hrayha@163.com> Message-ID: <6d54da01.10a79.15a8f7e97f0.Coremail.hrayha@163.com> this is some pic I execute all command of http://www.freeipa.org/page/IPA_2x_Certificate_Renewal this is the result ? 2017-03-02 18:40:49?"hao" ??? now I execute getcert list?all certificate status MONITORING,but there was an error ca-error: Internal error: no response to "http://ipaserver.xxx.io:9180/ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=2&renewal=true&xml=true" At 2017-03-02 11:34:10, "hao" wrote: Hi: I have finished reading http://www.freeipa.org/page/IPA_2x_Certificate_Renewal , before execute,I stop tracking all cert in `getcert list` Now, only "issuer: CN=IPA RA,O=XXX.IO " certificate expires at 2018-02-28 08:14:38 UTC,other certificate still expires at 2017-02-15 06:10:36 UTC? I execute "for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" do /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" -c dogtag-ipa-renew-agent -P xxxxxx done" and all command in "http://www.freeipa.org/page/IPA_2x_Certificate_Renewal" but still no effect I've tried ?http://www.freeipa.org/page/Certmonger? ?http://www.freeipa.org/page/Howto/CA_Certificate_Renewal? ?http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master? before that?I'm not sure if there will be an error step Please help me Thank you ?????|30?????????????MUJI???????????????????>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa1.png Type: image/png Size: 123397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa2.png Type: image/png Size: 127727 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa3.png Type: image/png Size: 82934 bytes Desc: not available URL: From Terry.John at coxauto.co.uk Thu Mar 2 15:02:00 2017 From: Terry.John at coxauto.co.uk (Terry John) Date: Thu, 2 Mar 2017 15:02:00 +0000 Subject: [Freeipa-users] Kerberos hanging In-Reply-To: <15da9c24-52d0-0a75-5c42-bc55f53892ff@redhat.com> References: <15da9c24-52d0-0a75-5c42-bc55f53892ff@redhat.com> Message-ID: >> I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The problem manifests itself as no authentication, and no DNS. >> It seems Kerberos just stops responding to requests and requests just >> get queued up # netstat -tuna | grep SYN_RECV Active Internet >> connections (servers and established) >> Proto Recv-Q Send-Q Local Address Foreign Address State >> tcp 0 0 :88 :55440 SYN_RECV >> tcp 0 0 :88 :40076 SYN_RECV >> >> Looking at /var/log/krb5kdc.log >> The normal activity of AS_REQ and TGS_REC messages just stops. No error messages. Just no new messages. >The problem isn't in Kerberos or DNS, ns-slapd is hanging. See this, http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-hangs >rob Thanks for that. I've taken a look at the stacktrace of out ns-slapd for our realm. But the stacktrace doesn't give very much. Just lots of "no debugging symbols found" and "No symbol table info available" it seems. In the list of threads there are lots of calls to functions but again "No symbol table info available." Nothing jumps out. Similarly in the access log, while there is a lot of activity nothing is obviously wrong. I didn't change the log buffering for very long, due to the predicted performance issues and did not catch it when it was faulty. For some reason, apart from once last evening the issue seems to have gone away now.. Terry Cox Automotive group of companies within the UK comprises: Cox Automotive UK Limited (registered number: 03183918), Manheim Limited (registered number: 00448761), Cox Automotive Retail Solutions Limited (registered number: 02838588), Motors.co.uk Limited (registered number: 05975777), and Real Time Communications Limited (registered number: 04277845). Each of these companies is registered in England and Wales with the registered office address of Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Cox Automotive group of companies within the UK operates under various brand/trading names including Cox Automotive UK, Manheim Inspection Services, Manheim Auctions, Modix, Xtime and Closeit. V:0CF72C13B2AD From deepak.dimri2016 at gmail.com Thu Mar 2 15:08:44 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Thu, 2 Mar 2017 20:38:44 +0530 Subject: [Freeipa-users] Local users migration into IPA Message-ID: Hello All, I have whole bunch of linux users that i want to migrate to IPA. All these users uses their ssh private keys (no passwords) to login into the linux system. What steps i should be following to migrate existing linux users seamlessly to IPA server? since the passwords are not involved i am thinking it would be rather simple exercise. This is what i was thinking : 1- Create linux user with same name in IPA 2- Add public cert for each user in IPA 3- I am assuming there is no configuration change in need on ipa clients as i can login to IPA server fine with new user if thats not the case then what configuration changes i should be doing on ipaclient? Do i need to delete local entry of the users from the ipa client for authentication to go through IPA and not locally? if so then can i anyway avoid this and rather force the user to authenticate against IPA and not locally w/out deleting the local entries? Would truly appreciate if you can provide some direction to this use case. Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Mar 2 15:10:07 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 2 Mar 2017 16:10:07 +0100 Subject: [Freeipa-users] Switch sudoers to IPA In-Reply-To: References: Message-ID: <20170302151007.piq6fxaaz26u4uyw@hendrix> On Thu, Mar 02, 2017 at 07:09:41PM +0530, deepak dimri wrote: > Hi List, > > I have sudo and normal users accessing linux systems using their private > key without IPA. I have IPA fully functioning and now i want to switch the > users from local file login to IPA. > > Any new user i create in IPA can SSH into ipa client jump boxes fine. I > want to know how i can migrate existing local sudoers users to IPA. This > is what i have done to achieve this: > > 1- Created a new user in IPA with the same name as i have in Jumpbox. > 2 - Added the public key of that user in IPA. > 3- Added the user to jumpbox_usergroup as my sshd.conf forces the users of > this group to authenticate against the pam/sssd > > Now when i try to ssh into jumpbox using as i was doing before i still logs > into the jumpbox via unix pam and not IPA. What should i be doing so that > the "existing" local unix users can login via IPA? But do you need to keep the local users around? Why not create the IPA user with the same UID as the local user and remove the local user? Typically, if there is a user both in the local files and a remote source, the system (as configured in nsswitch.conf) would first return the local user and the PAM stack then only authenticates this user using pam_unix.so From gkubok at gmail.com Thu Mar 2 15:52:46 2017 From: gkubok at gmail.com (Greg) Date: Thu, 2 Mar 2017 15:52:46 +0000 Subject: [Freeipa-users] Mapping root user over kerberised NFS (with gssproxy replacing rpcsvcgssd) Message-ID: Hi All, Kerberised NFS works well with gssproxy for IPA users, but I'm unable to map root user like I was with rpcsvcgssd. I understand gssproxy does not use idmapd anymore, and the mapping has to be done in krb5 directly (/etc/krb5.conf and/or ~/.k5login). It doesn't appear to work - any pointers would be very welcome. My env: $ lsb_release -d Description: Red Hat Enterprise Linux Server release 7.3 (Maipo) $ rpm -q ipa-client gssproxy ipa-client-4.4.0-14.el7_3.4.x86_64 gssproxy-0.4.1-13.el7.x86_64 $ ipa --version VERSION: 4.4.0, API_VERSION: 2.213 Kerberised NFS works fine for users that exist in IPA, so I won't cover that part of the config and focus on the root mapping. On the "nfsserver" machine, /etc/krb5.conf is this: includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = DOM.COM dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes default_ccache_name = KEYRING:persistent:%{uid} [realms] DOM.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt kdc = ipaserver.dom.com:88 master_kdc = ipaserver.dom.com:88 admin_server = ipaserver.dom.com:749 default_domain = dom.com auth_to_local = RULE:[2:$1/$2@$0](nfs/nfsclient.dom.com at DOM.COM )s/^.*$/root/g auth_to_local = RULE:[2:$1/$2@$0](host/nfsclient.dom.com at DOM.COM )s/^.*$/root/g auto_to_local = DEFAULT } [domain_realm] .dom.com = DOM.COM dom.com = DOM.COM And the contents of "/var/lib/sss/pubconf/krb5.include.d/localauth_plugin" are: [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so } I understand that does NOT mean default, rule, auth_to_local and k5login are disabled for "localauth", they're enabled by default transparently to my reading of krb5.conf man page (and I also confirmed k5login as working with SSH). Contents of /root/.k5login also on "nfsserver" machine: host/nfsclient.dom.com at DOM.COM nfs/nfsclient.dom.com at DOM.COM While in possession of a ticket for either of the 2 principals above, on "nfsclient" machine as root user, I can SSH password-less (and SSH-keyless of course) root to root, to "nfsserver". I can no longer SSH if I don't have either "host/..." or "nfs/..." principal on the "nfsclient". So that confirms k5login works correctly I suppose. Also shortly after mounting an NFS share on the "nfsclient" machine, I see this in NFS ID translations (not sure how to read it exactly): $ cat /proc/net/rpc/nfs4.idtoname/content gss/krb5i user 0 host/nfsclient.dom.com at DOM.COM gss/krb5i group 0 host/nfsclient.dom.com at DOM.COM And yet the directory that is mounted is seen as "nobody:nobody" by root on "nfsclient", and I can't seem to be able to convince gssproxy/nfs to map it to root on the client. My /etc/exports on "nfsserver": /exports/backup 10.11.5.0/24(rw,sec=krb5:krb5i:krb5p,no_subtree_check,no_root_squash) I also keep my "old" /etc/idmapd.conf around on "nfsserver" machine and keep idmapd running, even though in theory this is no longer used. This is its contents (and what used to work for me mapping root to root via rpcsvcgssd): [General] Domain = dom.com [Mapping] Nobody-User = nobody Nobody-Group = nobody [Translation] Method = static,sss [Static] host/nfsclient.dom.com at DOM.COM = root nfs/nfsclient.dom.com at DOM.COM = root What have I missed / what else needs to be set up where to allow gssproxy and kerberised NFS backed by IPA to map root on NFS client? -- Thanks, Greg Kubok. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cherdt at umn.edu Thu Mar 2 15:55:28 2017 From: cherdt at umn.edu (Chris Herdt) Date: Thu, 2 Mar 2017 09:55:28 -0600 Subject: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening In-Reply-To: <35945c0c-e1e2-3d34-cde3-2eeae5408a15@redhat.com> References: <35945c0c-e1e2-3d34-cde3-2eeae5408a15@redhat.com> Message-ID: On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti wrote: > > > On 02.03.2017 01:07, Chris Herdt wrote: > > I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a > FreeIPA 3.0.0 master on CentOS 6.8 following the steps at > https://access.redhat.com/documentation/en-US/Red_Hat_ > Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_ > Guide/upgrading.html > > At this step: > ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir > /var/lib/ipa/replica-info-replicaname.example.com.gpg > > I get the error: > ERROR cannot connect to 'ldaps://master.example.com' > > I ran ipa-replica-conncheck and found that port 636 is not accessible: > Port check failed! Inaccessible port(s): 636 (TCP) > > The port is not blocked. I'm wondering where in the configuration for > FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there is a > way I can specify to use port 389 for setting up the replica. > > Thanks! > > -- > Chris Herdt > Systems Administrator > > > > Hello, > this is known issue only in FreeIPA 4.4.x, this will be fixed in next > minor update which should be released soon to RHEL7.3 (I don't know how > fast it will be in Centos) > > so you can wait, or enable it manually (not nice) > > sorry for troubles > Martin > Thanks for the reply! Before attempting this in my production environment, I had set up a similar configuration in a test environment (FreeIPA 3.0.0 master on CentOS 6.8, FreeIPA 4.4.0 replica on CentOS 7.3) and the ipa-replica-install went fine. I assumed this was an issue with my FreeIPA 3.0.0 production server. To enable the fix manually, I'm assuming I'd need to install FreeIPA from source on the intended replica? If I download the 4.4.3 release from https://pagure.io/freeipa/releases, will that be sufficient? Thanks again. -- Chris Herdt Systems Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Mar 2 16:06:47 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 2 Mar 2017 17:06:47 +0100 Subject: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening In-Reply-To: References: <35945c0c-e1e2-3d34-cde3-2eeae5408a15@redhat.com> Message-ID: On 02.03.2017 16:55, Chris Herdt wrote: > > > On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti > wrote: > > > > On 02.03.2017 01:07, Chris Herdt wrote: >> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 >> from a FreeIPA 3.0.0 master on CentOS 6.8 following the steps at >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html >> >> >> At this step: >> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir >> /var/lib/ipa/replica-info-replicaname.example.com.gpg >> >> I get the error: >> ERROR cannot connect to 'ldaps://master.example.com >> ' >> >> I ran ipa-replica-conncheck and found that port 636 is not >> accessible: >> Port check failed! Inaccessible port(s): 636 (TCP) >> >> The port is not blocked. I'm wondering where in the configuration >> for FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or >> if there is a way I can specify to use port 389 for setting up >> the replica. >> >> Thanks! >> >> -- >> Chris Herdt >> Systems Administrator >> >> > > Hello, > this is known issue only in FreeIPA 4.4.x, this will be fixed in > next minor update which should be released soon to RHEL7.3 (I > don't know how fast it will be in Centos) > > so you can wait, or enable it manually (not nice) > > sorry for troubles > Martin > > > > Thanks for the reply! Before attempting this in my production > environment, I had set up a similar configuration in a test > environment (FreeIPA 3.0.0 master on CentOS 6.8, FreeIPA 4.4.0 replica > on CentOS 7.3) and the ipa-replica-install went fine. I assumed this > was an issue with my FreeIPA 3.0.0 production server. > > To enable the fix manually, I'm assuming I'd need to install FreeIPA > from source on the intended replica? If I download the 4.4.3 release > from https://pagure.io/freeipa/releases, will that be sufficient? Sorry, I probably misread what you wrote, I thought that port is closed on replica, but now I see that port is closed on 3.3.0 master, so this is something different. I'm not aware of any issue on 3.3.0 that should cause this. Could you check your configuration on 3.3.0 master? Is port opened on master? Do you have any errors in /var/log/dirsrv/slapd-*/errors log on master? Martin > > Thanks again. > > -- > Chris Herdt > Systems Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From mick.love at oxygen8.com Thu Mar 2 15:58:34 2017 From: mick.love at oxygen8.com (Mick Love) Date: Thu, 2 Mar 2017 15:58:34 +0000 Subject: [Freeipa-users] Issue with ipa-client-install v4.4.0 Message-ID: Hi, I seem to having some issue trying to install the IPA client (version 4.4.0) on Centos 7 using DNS. I can get a working install by issuing the ?server flags, but I would rather do it using SRV so we can issue the command via salt to multiple servers, and should we add another replicant. We will only need to update the SRV records rather than updating all our client servers. I am running this command, $>ipa-client-install --force-ntpd --mkhomedir --principal admin --realm= UK.INTERNAL.MYDOMAIN.COM --domain uk.internal.mydomain.com --unattended -w superhard But I keep getting this. Discovery was successful! Client hostname: portalwaf2.uk Realm: UK.INTERNAL.MYDOMAIN.COM DNS Domain: freeipa.uk.internal.mydomain.com IPA Server: ipa1.uk.internal.mydomain.com BaseDN: dc=uk,dc=internal,dc=mydomain,dc=com Synchronizing time with KDC... Attempting to sync time using ntpd. Will timeout after 15 seconds Successfully retrieved CA cert Subject: CN=Certificate Authority,O=UK.INTERNAL.MYDOMAIN.COM Issuer: CN=Certificate Authority,O=UK.INTERNAL.MYDOMAIN.COM Valid From: Fri Feb 17 12:09:04 2017 UTC Valid Until: Tue Feb 17 12:09:04 2037 UTC Enrolled in IPA realm UK.INTERNAL.MYDOMAIN.COM Created /etc/ipa/default.conf New SSSD config will be created Configured sudoers in /etc/nsswitch.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm UK.INTERNAL.MYDOMAIN.COM trying https://ipa1.uk.internal.mydomain.com/ipa/json Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 3128, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 3109, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 2818, in install api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 707, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 422, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 585, in load_plugins for package in self.packages: File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 919, in packages ipaclient.remote_plugins.get_package(self), File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py", line 118, in get_package plugins = schema.get_package(server_info, client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 543, in get_package schema = Schema(client) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 387, in __init__ fingerprint, ttl = self._fetch(client, ignore_cache=read_failed) File "/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line 413, in _fetch client.connect(verbose=False) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect conn = self.create_connection(*args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 931, in create_connection raise errors.KerberosError(message=unicode(krberr)) ipalib.errors.KerberosError: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529639066): Cannot find KDC for realm "UK.INTERNAL.MYDOMAIN.COM" Installation log: 2017-03-02T15:38:32Z DEBUG /usr/sbin/ipa-client-install was invoked with options: {'domain': 'freeipa.uk.internal.mydomain.com', 'force': False, 'krb5_offline_passwords': True, 'ip_addresses': [], 'configure_firefox': False, 'primary': False, 'realm_name': 'UK.INTERNAL.MYDOMAIN.COM', 'force_ntpd': True, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'on_master': False, 'no_nisdomain': False, 'nisdomain': None, 'ca_cert_file': None, 'principal': 'admin', 'keytab': None, 'hostname': None, 'request_cert': False, 'trust_sshfp': False, 'no_ac': False, 'unattended': True, 'all_ip_addresses': False, 'location': None, 'sssd': True, 'ntp_servers': None, 'kinit_attempts': 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True, 'force_join': True, 'firefox_dir': None, 'server': None, 'prompt_password': False, 'permit': False, 'debug': False, 'preserve_sssd': False, 'mkhomedir': True, 'uninstall': False} 2017-03-02T15:38:32Z DEBUG missing options might be asked for interactively later 2017-03-02T15:38:32Z DEBUG IPA version 4.4.0-14.el7.centos.4 2017-03-02T15:38:32Z DEBUG [IPA Discovery] 2017-03-02T15:38:32Z DEBUG Starting IPA discovery with domain= freeipa.uk.internal.mydomain.com, servers=None, hostname=portalwaf2.uk 2017-03-02T15:38:32Z DEBUG Search for LDAP SRV record in freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG Search DNS for SRV record of _ldap._ tcp.freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG DNS record found: 60 0 389 ipa1.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG DNS record found: 40 0 389 ipa2.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG [Kerberos realm search] 2017-03-02T15:38:32Z DEBUG Kerberos realm forced 2017-03-02T15:38:32Z DEBUG Search DNS for SRV record of _kerberos._ udp.freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG DNS record found: 40 0 88 ipa2.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG DNS record found: 60 0 88 ipa1.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG [LDAP server check] 2017-03-02T15:38:32Z DEBUG Verifying that ipa1.uk.internal.mydomain.com (realm UK.INTERNAL.MYDOMAIN.COM) is an IPA server 2017-03-02T15:38:32Z DEBUG Init LDAP connection to: ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG Search LDAP server for IPA base DN 2017-03-02T15:38:32Z DEBUG Check if naming context 'dc=uk,dc=internal,dc=mydomain,dc=com' is for IPA 2017-03-02T15:38:32Z DEBUG Naming context 'dc=uk,dc=internal,dc=mydomain,dc=com' is a valid IPA context 2017-03-02T15:38:32Z DEBUG Search for (objectClass=krbRealmContainer) in dc=uk,dc=internal,dc=mydomain,dc=com (sub) 2017-03-02T15:38:32Z DEBUG Found: cn=UK.INTERNAL.MYDOMAIN.COM ,cn=kerberos,dc=uk,dc=internal,dc=mydomain,dc=com 2017-03-02T15:38:32Z DEBUG Discovery result: Success; server= ipa1.uk.internal.mydomain.com, domain=freeipa.uk.internal.mydomain.com, kdc= ipa2.uk.internal.mydomain.com,ipa1.uk.internal.mydomain.com, basedn=dc=uk,dc=internal,dc=mydomain,dc=com 2017-03-02T15:38:32Z DEBUG Validated servers: ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG will use discovered domain: freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG Start searching for LDAP SRV record in " freeipa.uk.internal.mydomain.com" (Validating DNS Discovery) and its sub-domains 2017-03-02T15:38:32Z DEBUG Search DNS for SRV record of _ldap._ tcp.freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG DNS record found: 40 0 389 ipa2.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG DNS record found: 60 0 389 ipa1.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG DNS validated, enabling discovery 2017-03-02T15:38:32Z DEBUG will use discovered server: ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z INFO Discovery was successful! 2017-03-02T15:38:32Z DEBUG will use discovered realm: UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG will use discovered basedn: dc=uk,dc=internal,dc=mydomain,dc=com 2017-03-02T15:38:32Z INFO Client hostname: portalwaf2.uk 2017-03-02T15:38:32Z DEBUG Hostname source: Machine's FQDN 2017-03-02T15:38:32Z INFO Realm: UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Realm source: Discovered from LDAP DNS records in ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z INFO DNS Domain: freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG DNS Domain source: Discovered LDAP SRV records from freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z INFO IPA Server: ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG IPA Server source: Discovered from LDAP DNS records in ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z INFO BaseDN: dc=uk,dc=internal,dc=mydomain,dc=com 2017-03-02T15:38:32Z DEBUG BaseDN source: From IPA server ldap:// ipa1.uk.internal.mydomain.com:389 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Process finished, return code=5 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr=realm not found 2017-03-02T15:38:32Z INFO Synchronizing time with KDC... 2017-03-02T15:38:32Z DEBUG Search DNS for SRV record of _ntp._ udp.freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG DNS record found: 40 0 123 ipa2.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG DNS record found: 60 0 123 ipa1.uk.internal.mydomain.com. 2017-03-02T15:38:32Z INFO Attempting to sync time using ntpd. Will timeout after 15 seconds 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/bin/timeout 15 /usr/sbin/ntpd -qgc /tmp/tmplUZ6sG 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout=ntpd: time set -1.083636s 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=keyctl get_persistent @s 0 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout=540282011 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Enabling persistent keyring CCACHE 2017-03-02T15:38:32Z DEBUG Writing Kerberos configuration to /tmp/tmpEVHPqI: 2017-03-02T15:38:32Z DEBUG #File modified by ipa-client-install includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = UK.INTERNAL.MYDOMAIN.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] UK.INTERNAL.MYDOMAIN.COM = { kdc = ipa1.uk.internal.mydomain.com:88 master_kdc = ipa1.uk.internal.mydomain.com:88 admin_server = ipa1.uk.internal.mydomain.com:749 kpasswd_server = ipa1.uk.internal.mydomain.com:464 default_domain = freeipa.uk.internal.mydomain.com pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .freeipa.uk.internal.mydomain.com = UK.INTERNAL.MYDOMAIN.COM freeipa.uk.internal.mydomain.com = UK.INTERNAL.MYDOMAIN.COM portalwaf2.uk = UK.INTERNAL.MYDOMAIN.COM .uk = UK.INTERNAL.MYDOMAIN.COM uk = UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Initializing principal admin at UK.INTERNAL.MYDOMAIN.COM using password 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/bin/kinit admin at UK.INTERNAL.MYDOMAIN.COM -c /tmp/krbccxpYNsC/ccache 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout=Password for admin at UK.INTERNAL.MYDOMAIN.COM: 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG trying to retrieve CA cert via LDAP from ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG flushing ldap://ipa1.uk.internal.mydomain.com:389 from SchemaCache 2017-03-02T15:38:32Z DEBUG retrieving schema for SchemaCache url=ldap:// ipa1.uk.internal.mydomain.com:389 conn= 2017-03-02T15:38:32Z INFO Successfully retrieved CA cert Subject: CN=Certificate Authority,O=UK.INTERNAL.MYDOMAIN.COM Issuer: CN=Certificate Authority,O=UK.INTERNAL.MYDOMAIN.COM Valid From: Fri Feb 17 12:09:04 2017 UTC Valid Until: Tue Feb 17 12:09:04 2037 UTC 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/sbin/ipa-join -s ipa1.uk.internal.mydomain.com -b dc=uk,dc=internal,dc=mydomain,dc=com -h portalwaf2.uk -f 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr=Keytab successfully retrieved and stored in: /etc/krb5.keytab Certificate subject base is: O=UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z INFO Enrolled in IPA realm UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=kdestroy 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Initializing principal host/ portalwaf2.uk at UK.INTERNAL.MYDOMAIN.COM using keytab /etc/krb5.keytab 2017-03-02T15:38:32Z DEBUG using ccache /etc/ipa/.dns_ccache 2017-03-02T15:38:32Z DEBUG Attempt 1/5: success 2017-03-02T15:38:32Z DEBUG Backing up system configuration file '/etc/ipa/default.conf' 2017-03-02T15:38:32Z DEBUG -> Not backing up - '/etc/ipa/default.conf' doesn't exist 2017-03-02T15:38:32Z INFO Created /etc/ipa/default.conf 2017-03-02T15:38:32Z DEBUG Backing up system configuration file '/etc/sssd/sssd.conf' 2017-03-02T15:38:32Z DEBUG -> Not backing up - '/etc/sssd/sssd.conf' doesn't exist 2017-03-02T15:38:32Z INFO New SSSD config will be created 2017-03-02T15:38:32Z DEBUG Backing up system configuration file '/etc/nsswitch.conf' 2017-03-02T15:38:32Z DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' 2017-03-02T15:38:32Z INFO Configured sudoers in /etc/nsswitch.conf 2017-03-02T15:38:32Z INFO Configured /etc/sssd/sssd.conf 2017-03-02T15:38:32Z DEBUG Backing up system configuration file '/etc/krb5.conf' 2017-03-02T15:38:32Z DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=keyctl get_persistent @s 0 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout=540282011 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Enabling persistent keyring CCACHE 2017-03-02T15:38:32Z DEBUG Writing Kerberos configuration to /etc/krb5.conf: 2017-03-02T15:38:32Z DEBUG #File modified by ipa-client-install includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = UK.INTERNAL.MYDOMAIN.COM dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] UK.INTERNAL.MYDOMAIN.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .freeipa.uk.internal.mydomain.com = UK.INTERNAL.MYDOMAIN.COM freeipa.uk.internal.mydomain.com = UK.INTERNAL.MYDOMAIN.COM portalwaf2.uk = UK.INTERNAL.MYDOMAIN.COM .uk = UK.INTERNAL.MYDOMAIN.COM uk = UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z INFO Configured /etc/krb5.conf for IPA realm UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=keyctl search @s user ipa_session_cookie:host/portalwaf2.uk at UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Process finished, return code=1 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr=keyctl_search: Required key not available 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/bin/certutil -d /tmp/tmpKqp0s3 -N -f /tmp/tmp8JvkBZ 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/bin/certutil -d /tmp/tmpKqp0s3 -A -n CA certificate 1 -t C,, 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=keyctl search @s user ipa_session_cookie:host/portalwaf2.uk at UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Process finished, return code=1 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr=keyctl_search: Required key not available 2017-03-02T15:38:32Z DEBUG failed to find session_cookie in persistent storage for principal 'host/portalwaf2.uk at UK.INTERNAL.MYDOMAIN.COM' 2017-03-02T15:38:32Z INFO trying https://ipa1.uk.internal.mydomain.com/ipa/json2017-03-02T15:38:32Z DEBUG /usr/sbin/ipa-client-install was invoked with options: {'domain': ' freeipa.uk.internal.mydomain.com', 'force': False, 'krb5_offline_passwords': True, 'ip_addresses': [], 'configure_firefox': False, 'primary': False, 'realm_name': 'UK.INTERNAL.mydomain.COM', 'force_ntpd': True, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'on_master': False, 'no_nisdomain': False, 'nisdomain': None, 'ca_cert_file': None, 'principal': 'admin', 'keytab': None, 'hostname': None, 'request_cert': False, 'trust_sshfp': False, 'no_ac': False, 'unattended': True, 'all_ip_addresses': False, 'location': None, 'sssd': True, 'ntp_servers': None, 'kinit_attempts': 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True, 'force_join': True, 'firefox_dir': None, 'server': None, 'prompt_password': False, 'permit': False, 'debug': False, 'preserve_sssd': False, 'mkhomedir': True, 'uninstall': False} 2017-03-02T15:38:32Z DEBUG missing options might be asked for interactively later 2017-03-02T15:38:32Z DEBUG IPA version 4.4.0-14.el7.centos.4 2017-03-02T15:38:32Z DEBUG [IPA Discovery] 2017-03-02T15:38:32Z DEBUG Starting IPA discovery with domain= freeipa.uk.internal.mydomain.com, servers=None, hostname=portalwaf2.uk 2017-03-02T15:38:32Z DEBUG Search for LDAP SRV record in freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG Search DNS for SRV record of _ldap._ tcp.freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG DNS record found: 60 0 389 ipa1.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG DNS record found: 40 0 389 ipa2.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG [Kerberos realm search] 2017-03-02T15:38:32Z DEBUG Kerberos realm forced 2017-03-02T15:38:32Z DEBUG Search DNS for SRV record of _kerberos._ udp.freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG DNS record found: 40 0 88 ipa2.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG DNS record found: 60 0 88 ipa1.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG [LDAP server check] 2017-03-02T15:38:32Z DEBUG Verifying that ipa1.uk.internal.mydomain.com (realm UK.INTERNAL.MYDOMAIN.COM) is an IPA server 2017-03-02T15:38:32Z DEBUG Init LDAP connection to: ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG Search LDAP server for IPA base DN 2017-03-02T15:38:32Z DEBUG Check if naming context 'dc=uk,dc=internal,dc=mydomain,dc=com' is for IPA 2017-03-02T15:38:32Z DEBUG Naming context 'dc=uk,dc=internal,dc=mydomain,dc=com' is a valid IPA context 2017-03-02T15:38:32Z DEBUG Search for (objectClass=krbRealmContainer) in dc=uk,dc=internal,dc=mydomain,dc=com (sub) 2017-03-02T15:38:32Z DEBUG Found: cn=UK.INTERNAL.mydomain.COM ,cn=kerberos,dc=uk,dc=internal,dc=mydomain,dc=com 2017-03-02T15:38:32Z DEBUG Discovery result: Success; server= ipa1.uk.internal.mydomain.com, domain=freeipa.uk.internal.mydomain.com, kdc= ipa2.uk.internal.mydomain.com,ipa1.uk.internal.mydomain.com, basedn=dc=uk,dc=internal,dc=mydomain,dc=com 2017-03-02T15:38:32Z DEBUG Validated servers: ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG will use discovered domain: freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG Start searching for LDAP SRV record in " freeipa.uk.internal.mydomain.com" (Validating DNS Discovery) and its sub-domains 2017-03-02T15:38:32Z DEBUG Search DNS for SRV record of _ldap._ tcp.freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG DNS record found: 40 0 389 ipa2.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG DNS record found: 60 0 389 ipa1.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG DNS validated, enabling discovery 2017-03-02T15:38:32Z DEBUG will use discovered server: ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z INFO Discovery was successful! 2017-03-02T15:38:32Z DEBUG will use discovered realm: UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG will use discovered basedn: dc=uk,dc=internal,dc=mydomain,dc=com 2017-03-02T15:38:32Z INFO Client hostname: portalwaf2.uk 2017-03-02T15:38:32Z DEBUG Hostname source: Machine's FQDN 2017-03-02T15:38:32Z INFO Realm: UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Realm source: Discovered from LDAP DNS records in ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z INFO DNS Domain: freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG DNS Domain source: Discovered LDAP SRV records from freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z INFO IPA Server: ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG IPA Server source: Discovered from LDAP DNS records in ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z INFO BaseDN: dc=uk,dc=internal,dc=mydomain,dc=com 2017-03-02T15:38:32Z DEBUG BaseDN source: From IPA server ldap:// ipa1.uk.internal.mydomain.com:389 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Process finished, return code=5 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr=realm not found 2017-03-02T15:38:32Z INFO Synchronizing time with KDC... 2017-03-02T15:38:32Z DEBUG Search DNS for SRV record of _ntp._ udp.freeipa.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG DNS record found: 40 0 123 ipa2.uk.internal.mydomain.com. 2017-03-02T15:38:32Z DEBUG DNS record found: 60 0 123 ipa1.uk.internal.mydomain.com. 2017-03-02T15:38:32Z INFO Attempting to sync time using ntpd. Will timeout after 15 seconds 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/bin/timeout 15 /usr/sbin/ntpd -qgc /tmp/tmplUZ6sG 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout=ntpd: time set -1.083636s 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=keyctl get_persistent @s 0 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout=540282011 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Enabling persistent keyring CCACHE 2017-03-02T15:38:32Z DEBUG Writing Kerberos configuration to /tmp/tmpEVHPqI: 2017-03-02T15:38:32Z DEBUG #File modified by ipa-client-install includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = UK.INTERNAL.MYDOMAIN.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] UK.INTERNAL.MYDOMAIN.COM = { kdc = ipa1.uk.internal.mydomain.com:88 master_kdc = ipa1.uk.internal.mydomain.com:88 admin_server = ipa1.uk.internal.mydomain.com:749 kpasswd_server = ipa1.uk.internal.mydomain.com:464 default_domain = freeipa.uk.internal.mydomain.com pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .freeipa.uk.internal.mydomain.com = UK.INTERNAL.MYDOMAIN.COM freeipa.uk.internal.mydomain.com = UK.INTERNAL.MYDOMAIN.COM portalwaf2.uk = UK.INTERNAL.MYDOMAIN.COM .uk = UK.INTERNAL.MYDOMAIN.COM uk = UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Initializing principal admin at UK.INTERNAL.MYDOMAIN.COM using password 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/bin/kinit admin at UK.INTERNAL.MYDOMAIN.COM -c /tmp/krbccxpYNsC/ccache 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout=Password for admin at UK.INTERNAL.MYDOMAIN.COM: 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG trying to retrieve CA cert via LDAP from ipa1.uk.internal.mydomain.com 2017-03-02T15:38:32Z DEBUG flushing ldap://ipa1.uk.internal.mydomain.com:389 from SchemaCache 2017-03-02T15:38:32Z DEBUG retrieving schema for SchemaCache url=ldap:// ipa1.uk.internal.mydomain.com:389 conn= 2017-03-02T15:38:32Z INFO Successfully retrieved CA cert Subject: CN=Certificate Authority,O=UK.INTERNAL.MYDOMAIN.COM Issuer: CN=Certificate Authority,O=UK.INTERNAL.MYDOMAIN.COM Valid From: Fri Feb 17 12:09:04 2017 UTC Valid Until: Tue Feb 17 12:09:04 2037 UTC 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/sbin/ipa-join -s ipa1.uk.internal.mydomain.com -b dc=uk,dc=internal,dc=mydomain,dc=com -h portalwaf2.uk -f 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr=Keytab successfully retrieved and stored in: /etc/krb5.keytab Certificate subject base is: O=UK.INTERNAL.mydomain.COM 2017-03-02T15:38:32Z INFO Enrolled in IPA realm UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=kdestroy 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Initializing principal host/ portalwaf2.uk at UK.INTERNAL.MYDOMAIN.COM using keytab /etc/krb5.keytab 2017-03-02T15:38:32Z DEBUG using ccache /etc/ipa/.dns_ccache 2017-03-02T15:38:32Z DEBUG Attempt 1/5: success 2017-03-02T15:38:32Z DEBUG Backing up system configuration file '/etc/ipa/default.conf' 2017-03-02T15:38:32Z DEBUG -> Not backing up - '/etc/ipa/default.conf' doesn't exist 2017-03-02T15:38:32Z INFO Created /etc/ipa/default.conf 2017-03-02T15:38:32Z DEBUG Backing up system configuration file '/etc/sssd/sssd.conf' 2017-03-02T15:38:32Z DEBUG -> Not backing up - '/etc/sssd/sssd.conf' doesn't exist 2017-03-02T15:38:32Z INFO New SSSD config will be created 2017-03-02T15:38:32Z DEBUG Backing up system configuration file '/etc/nsswitch.conf' 2017-03-02T15:38:32Z DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' 2017-03-02T15:38:32Z INFO Configured sudoers in /etc/nsswitch.conf 2017-03-02T15:38:32Z INFO Configured /etc/sssd/sssd.conf 2017-03-02T15:38:32Z DEBUG Backing up system configuration file '/etc/krb5.conf' 2017-03-02T15:38:32Z DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=keyctl get_persistent @s 0 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout=540282011 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Enabling persistent keyring CCACHE 2017-03-02T15:38:32Z DEBUG Writing Kerberos configuration to /etc/krb5.conf: 2017-03-02T15:38:32Z DEBUG #File modified by ipa-client-install includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = UK.INTERNAL.MYDOMAIN.COM dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] UK.INTERNAL.MYDOMAIN.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .freeipa.uk.internal.mydomain.com = UK.INTERNAL.MYDOMAIN.COM freeipa.uk.internal.mydomain.com = UK.INTERNAL.MYDOMAIN.COM portalwaf2.uk = UK.INTERNAL.MYDOMAIN.COM .uk = UK.INTERNAL.MYDOMAIN.COM uk = UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z INFO Configured /etc/krb5.conf for IPA realm UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=keyctl search @s user ipa_session_cookie:host/portalwaf2.uk at UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Process finished, return code=1 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr=keyctl_search: Required key not available 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/bin/certutil -d /tmp/tmpKqp0s3 -N -f /tmp/tmp8JvkBZ 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=/usr/bin/certutil -d /tmp/tmpKqp0s3 -A -n CA certificate 1 -t C,, 2017-03-02T15:38:32Z DEBUG Process finished, return code=0 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr= 2017-03-02T15:38:32Z DEBUG Starting external process 2017-03-02T15:38:32Z DEBUG args=keyctl search @s user ipa_session_cookie:host/portalwaf2.uk at UK.INTERNAL.MYDOMAIN.COM 2017-03-02T15:38:32Z DEBUG Process finished, return code=1 2017-03-02T15:38:32Z DEBUG stdout= 2017-03-02T15:38:32Z DEBUG stderr=keyctl_search: Required key not available 2017-03-02T15:38:32Z DEBUG failed to find session_cookie in persistent storage for principal 'host/portalwaf2.uk at UK.INTERNAL.MYDOMAIN.COM' 2017-03-02T15:38:32Z INFO trying https://ipa1.uk.internal.mydomain.com/ipa/json Running ipa-getcert list returns: Number of certificates and requests being tracked: 0. DNS records: SRV record for FreeIPA _kerberos.freeipa.uk IN TXT "FREEIPA.UK.INTERNAL.MYDOMAIN.COM" _ldap._tcp IN SRV 60 0 389 ipa1.uk IN SRV 40 0 389 ipa2.uk _ldap._tcp.freeipa.uk IN SRV 60 0 389 ipa1.uk IN SRV 40 0 389 ipa2.uk _ldaps._tcp.freeipa.uk IN SRV 60 0 636 ipa1.uk IN SRV 40 0 636 ipa2.uk _kerberos._tcp.freeipa.uk IN SRV 60 0 464 ipa1.uk IN SRV 40 0 464 ipa2.uk _http._tcp.freeipa.uk IN SRV 60 0 80 ipa1.uk IN SRV 40 0 80 ipa2.uk _https._tcp.freeipa.uk IN SRV 60 0 443 ipa1.uk IN SRV 40 0 442 ipa2.uk _kerberos-adm._tcp.freeipa.uk IN SRV 60 0 749 ipa1.uk IN SRV 40 0 749 ipa2.uk _kerberos-master._udp.freeipa.uk IN SRV 0 0 88 ipa1.uk _kerberos._udp.freeipa.uk IN SRV 60 0 88 ipa1.uk IN SRV 40 0 88 ipa2.uk _kpasswd._udp.freeipa.uk IN SRV 60 0 464 ipa1.uk IN SRV 40 0 464 ipa2.uk _ntp._udp.freeipa.uk IN SRV 60 0 123 ipa1.uk IN SRV 40 0 123 ipa2.uk Not sure what Im getting wrong. -- Regards *Mick* -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.dimri2016 at gmail.com Thu Mar 2 16:20:41 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Thu, 2 Mar 2017 21:50:41 +0530 Subject: [Freeipa-users] Switch sudoers to IPA In-Reply-To: <20170302151007.piq6fxaaz26u4uyw@hendrix> References: <20170302151007.piq6fxaaz26u4uyw@hendrix> Message-ID: Hi Jakub, Actually that is what i am doing. i am creating the user with same UID in IPA and then if i delete the user locally then i can authenticate via IPA. Is there anyway i can do this without deleting the user? This is just to use the same GID and avoid recreation of home/directories. Many Thanks for your response! Regards, Deepak On Thu, Mar 2, 2017 at 8:40 PM, Jakub Hrozek wrote: > On Thu, Mar 02, 2017 at 07:09:41PM +0530, deepak dimri wrote: > > Hi List, > > > > I have sudo and normal users accessing linux systems using their private > > key without IPA. I have IPA fully functioning and now i want to switch > the > > users from local file login to IPA. > > > > Any new user i create in IPA can SSH into ipa client jump boxes fine. I > > want to know how i can migrate existing local sudoers users to IPA. This > > is what i have done to achieve this: > > > > 1- Created a new user in IPA with the same name as i have in Jumpbox. > > 2 - Added the public key of that user in IPA. > > 3- Added the user to jumpbox_usergroup as my sshd.conf forces the users > of > > this group to authenticate against the pam/sssd > > > > Now when i try to ssh into jumpbox using as i was doing before i still > logs > > into the jumpbox via unix pam and not IPA. What should i be doing so > that > > the "existing" local unix users can login via IPA? > > But do you need to keep the local users around? Why not create the IPA > user with the same UID as the local user and remove the local user? > > Typically, if there is a user both in the local files and a remote > source, the system (as configured in nsswitch.conf) would first return > the local user and the PAM stack then only authenticates this user using > pam_unix.so > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cherdt at umn.edu Thu Mar 2 17:25:14 2017 From: cherdt at umn.edu (Chris Herdt) Date: Thu, 2 Mar 2017 11:25:14 -0600 Subject: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening In-Reply-To: References: <35945c0c-e1e2-3d34-cde3-2eeae5408a15@redhat.com> Message-ID: On Thu, Mar 2, 2017 at 10:06 AM, Martin Basti wrote: > > > > On 02.03.2017 16:55, Chris Herdt wrote: > > > > On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti wrote: > >> >> >> On 02.03.2017 01:07, Chris Herdt wrote: >> >> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a >> FreeIPA 3.0.0 master on CentOS 6.8 following the steps at >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterp >> rise_Linux/7/html/Linux_Domain_Identity_Authentication_and_P >> olicy_Guide/upgrading.html >> >> At this step: >> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir >> /var/lib/ipa/replica-info-replicaname.example.com.gpg >> >> I get the error: >> ERROR cannot connect to 'ldaps://master.example.com' >> >> I ran ipa-replica-conncheck and found that port 636 is not accessible: >> Port check failed! Inaccessible port(s): 636 (TCP) >> >> The port is not blocked. I'm wondering where in the configuration for >> FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there is a >> way I can specify to use port 389 for setting up the replica. >> >> Thanks! >> >> -- >> Chris Herdt >> Systems Administrator >> >> >> >> Hello, >> this is known issue only in FreeIPA 4.4.x, this will be fixed in next >> minor update which should be released soon to RHEL7.3 (I don't know how >> fast it will be in Centos) >> >> so you can wait, or enable it manually (not nice) >> >> sorry for troubles >> Martin >> > > > Thanks for the reply! Before attempting this in my production environment, > I had set up a similar configuration in a test environment (FreeIPA 3.0.0 > master on CentOS 6.8, FreeIPA 4.4.0 replica on CentOS 7.3) and the > ipa-replica-install went fine. I assumed this was an issue with my FreeIPA > 3.0.0 production server. > > To enable the fix manually, I'm assuming I'd need to install FreeIPA from > source on the intended replica? If I download the 4.4.3 release from > https://pagure.io/freeipa/releases, will that be sufficient? > > Sorry, > I probably misread what you wrote, I thought that port is closed on > replica, but now I see that port is closed on 3.3.0 master, so this is > something different. I'm not aware of any issue on 3.3.0 that should cause > this. > > Could you check your configuration on 3.3.0 master? Is port opened on > master? Do you have any errors in /var/log/dirsrv/slapd-*/errors log on > master? > > Martin > When I compare the errors file on my production environment and my test environment, I do note that the LDAPS entry is missing from my production environment: production: [01/Mar/2017:17:30:07 -0600] - slapd started. Listening on All Interfaces port 389 for LDAP requests [01/Mar/2017:17:30:07 -0600] - Listening on /var/run/slapd-PROD-EXAMPLE-COM.socket for LDAPI requests test: [28/Feb/2017:13:37:50 -0600] - slapd started. Listening on All Interfaces port 389 for LDAP requests [28/Feb/2017:13:37:50 -0600] - Listening on All Interfaces port 636 for LDAPS requests [28/Feb/2017:13:37:50 -0600] - Listening on /var/run/slapd-TEST-EXAMPLE-COM.socket for LDAPI requests I'm not sure why it is missing though. Which config file(s) should I be checking? -- Chris Herdt Systems Administrator -------------- next part -------------- An HTML attachment was scrubbed... URL: From hedrick at rutgers.edu Thu Mar 2 18:15:15 2017 From: hedrick at rutgers.edu (Charles Hedrick) Date: Thu, 2 Mar 2017 18:15:15 +0000 Subject: [Freeipa-users] documentation or example of using S42U for NFS In-Reply-To: References: <5BCA6356-7A58-4867-BC6A-E0701F84FC1C@rutgers.edu> <90AAB443-7655-4153-8C09-A004370A2E46@cs.rutgers.edu> <6c30e7d0-8da6-c8a8-fb33-93d1c1975d61@cora.nwra.com> Message-ID: Thanks. That?s what I was originally looking for. However since asking it I realized that doing it without further limitations defeats the purpose of using Kerberos in the first place, since it means that anyone who becomes the user in Linux can access their files. I?m trying to make sure that users can decide which machines they?re willing to expose to access without a credential. In our department we have shared systems, which we run, student labs, which we run but that are not physically secure, and user-maintained machines. We?d like to say that normally no one can access your files without having your credentials. So if someone manages to become root on one system they don?t suddenly have access to everyone?s files. We have to relax that where users need to run cron jobs. But I?d like that relaxation to be in a controlled way. That is, I want the user to have to say that on a specific machine it?s possible to access their files based just on being their uid. But that only applies to the specific user on the specific machine. That at least restricts exposure. If S42U is turned on for NFS as described below, then anyone who becomes root can become any user, and then access any user?s files. The design documentation says: "The ACL system also provides a means of limiting which user's a ticket may be obtained for using the ipaAllowToImpersonate attribute. This is not implemented." There?s no sign of this feature in the command line tools, so I assume it?s still not implemented. Until it is I don?t think that will do what I need. Kgetcred, however, will do the job. On Mar 1, 2017, at 9:29 PM, Greg > wrote: I've been at this as well for a while now, and managed to make it work for my NFS needs (automounting user homes with password-less logons). Whether and how this would apply to cron or other services, I don't know yet, but presumably would/should work in a similar manner. My env: $ lsb_release -d Description: Red Hat Enterprise Linux Server release 7.3 (Maipo) $ rpm -q ipa-server ipa-server-4.4.0-14.el7_3.4.x86_64 $ ipa --version VERSION: 4.4.0, API_VERSION: 2.213 This is what worked for me in the end: 1. Create "nfs/nfsserver.dom.com at DOM.COM" service, and add to NFS server's /etc/krb5.keytab. 2. Create IPA "servicedelegation" rule/targets, so that they look like so: $ ipa servicedelegationrule-show ipa-nfs-delegation Delegation name: ipa-nfs-delegation Allowed Target: ipa-nfs-delegation-targets Member principals: host/nfsclient.dom.com at DOM.COM $ ipa servicedelegationtarget-show ipa-nfs-delegation-targets Delegation name: ipa-nfs-delegation-targets Member principals: nfs/nfsserver.dom.com at DOM.COM Only niggle here is IPA CLI didn't let me add "host/..." principal to the rule, or perhaps there's a default LDAP ACI of some sort and it requires a privilege/permission to be granted. The "ipa servicedelegationrule-add-member ..." command simply says "no such entry" for "host/..." type principals. Maybe IPA folks can comment. I force added it to the delegation rule via LDAP instead using this ldif: dn: cn=ipa-nfs-delegation,cn=s4u2proxy,cn=etc,dc=dom,dc=com changetype: modify add: memberPrincipal memberPrincipal: host/nfsclient.dom.com at DOM.COM The "nfs/..." principal can be added using CLI "ipa servicedelegationtarget-add-member ..." just fine. 3. Allow the "nfsclient" host to impersonate users: $ ipa host-mod nfsclient.dom.com --ok-to-auth-as-delegate=true 4. On the "nfsclient" machine, add "impersonate = true" line in the "[service/nfs-client]" section of /etc/gssproxy/gssproxy.conf. 5. Restart nfs/gssproxy/rpc services on client and server (it's probably just gssproxy on the client that needs a kick, but just to be sure). I was also religiously doing "sss_cache -E" for good measure, unmounting anything that got mounted, and clearing /var/lib/gssproxy/clients of all caches, to start as cleanly before each attempt at user logon. Obv make sure the user does not have an existing/valid ticket in their own cache ("kdestroy -A" as the user), otherwise it'll just mount successfully without delegation. I think that's it, I've messed about with the config for a long time and in many places, so there's a small chance there's something else that I did and don't remember. Gssproxy config on "nfsserver" is vanilla, as are my sssd.confs and krb5.confs on both machines, can't think of much else that I might've changed for now. So my IPA automount config now mounts users' home dirs on the "nfsclient", without any tickets or keytabs from users. There's also a "krb5_principal" option available in gssproxy.conf - I tried to set that to "nfs/nfsclient at DOM.COM" in "[service/nfs-client]" section on the "nfsclient" machine, to try and force gssproxy to use that principal instead of "host/...", but it didn't seem to work, gssproxy defaults to "host/...". Possibly mis-understanding what this option is for, and possibly "host/..." is the safer/standard option? I'm assuming it's default for a reason, or maybe just operational convenience (not having to pollute /etc/krb5.keytabs with more principals than necessary). Hope this helps. -- Thanks, Greg Kubok. On 1 March 2017 at 22:47, Orion Poplawski > wrote: If you ever get this into a repository, I'd love to see it. Thanks. On 01/17/2017 07:44 PM, Charles Hedrick wrote: > Instructions like that are several places. But NFS is different, and I believe the configuration would be different from other services. > > I?ve given up on this approach, and have written my own utilities. I?ve actually got three. The first two assume that users who want to do cron jobs on a machine register a keytab for that machine on a secure system. I don?t want to put the actual keytab on the machine where the user is running, because if someone can become root, they can take the keytab and use it anywhere. (I?m in a computer science dept with systems run by faculty and grad students; also systems in public labs.) > > So instead, I allow users to register that they want to do cron on a specific machine by putting a keytab on a secure server, associated with their username and the hostname. I expect to write a web app to set that up. > > Credserv runs on the machine with the keytabs. It accepts a request from a server, authenticated using the host?s host key (i.e. /etc/krb5.keytab), with a username in the request. If the user has registered a keytab for that host, credserv returns a credential, locked to that IP address, with forwarding off. > > Kgetcred is the client side. It runs setuid root (so it can read /etc/krb5.keytab), though it drops privs as quickly as possible. It creates a credentials cache for the user from the credentials returned from credserv. > > This gives the best granularity of control I can come up with. > > There?s a third utility in the family: renewd. It gets the uids of all current processes, and renews credentials for all of the users. It?s more complex than you?d expect because a normal renewal (as in kinit -R or kstart) leaves a brief period of time when the credentials cache is unusable. This can result in NFS failing. I use a special approach that depends upon the details of the KEYRING implementation. It should be free of race conditions for NFS. If desired, a different approach to avoid race conditions could be used for caches located in /tmp. I haven?t written that code but there?s a comment in the source outlining it. > > I?ll be creating a git repository for the code. > > >> On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski > wrote: >> >> On 01/09/2017 09:52 AM, Charles Hedrick wrote: >>> Various documentation suggests that it is possible for Gssproxy to get tickets for users who need to use NFS. This is a possible way to handle things like cron jobs. >>> >>> However while a gssproxy.conf example is given, there?s no sign of what needs to be done in freeipa to authorize it. I tried following instructions for LDAP access, but it doesn?t work. NFS seems to use a different, two-stage method for getting credentials, so that?s not a surprise. There are, not surprisingly, no useful error messages even with logging turned all the way up. >>> >>> >> >> I'm interested in this as well. All I've been able to find so far is: >> >> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/ >> >> haven't tried anything. >> >> -- >> Orion Poplawski >> Technical Manager 720-772-5637 >> NWRA, Boulder/CoRA Office FAX: 303-415-9702 >> 3380 Mitchell Lane orion at nwra.com >> Boulder, CO 80301 http://www.nwra.com > -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hedrick at rutgers.edu Thu Mar 2 18:41:24 2017 From: hedrick at rutgers.edu (Charles Hedrick) Date: Thu, 2 Mar 2017 18:41:24 +0000 Subject: [Freeipa-users] documentation or example of using S42U for NFS In-Reply-To: <6c30e7d0-8da6-c8a8-fb33-93d1c1975d61@cora.nwra.com> References: <5BCA6356-7A58-4867-BC6A-E0701F84FC1C@rutgers.edu> <90AAB443-7655-4153-8C09-A004370A2E46@cs.rutgers.edu> <6c30e7d0-8da6-c8a8-fb33-93d1c1975d61@cora.nwra.com> Message-ID: The repo is https://github.com/clhedrick/kerberos.git. There?s a README.md, and man pages for the individual programs. While I?m currently using these programs, we haven?t fully rolled out Kerberos yet. As we do, I expect we?ll want to add more features. (E.g. kgetcred / credserv need to support redundant servers.) When free ipa implements all planned features, kgetcred / credserv may not longer be needed. Rnewd and skinit still will be (though skinit should be modified to use ?kinit -n? rather than ?kgetcred -a" On Mar 1, 2017, at 5:47 PM, Orion Poplawski > wrote: If you ever get this into a repository, I'd love to see it. Thanks. On 01/17/2017 07:44 PM, Charles Hedrick wrote: Instructions like that are several places. But NFS is different, and I believe the configuration would be different from other services. I?ve given up on this approach, and have written my own utilities. I?ve actually got three. The first two assume that users who want to do cron jobs on a machine register a keytab for that machine on a secure system. I don?t want to put the actual keytab on the machine where the user is running, because if someone can become root, they can take the keytab and use it anywhere. (I?m in a computer science dept with systems run by faculty and grad students; also systems in public labs.) So instead, I allow users to register that they want to do cron on a specific machine by putting a keytab on a secure server, associated with their username and the hostname. I expect to write a web app to set that up. Credserv runs on the machine with the keytabs. It accepts a request from a server, authenticated using the host?s host key (i.e. /etc/krb5.keytab), with a username in the request. If the user has registered a keytab for that host, credserv returns a credential, locked to that IP address, with forwarding off. Kgetcred is the client side. It runs setuid root (so it can read /etc/krb5.keytab), though it drops privs as quickly as possible. It creates a credentials cache for the user from the credentials returned from credserv. This gives the best granularity of control I can come up with. There?s a third utility in the family: renewd. It gets the uids of all current processes, and renews credentials for all of the users. It?s more complex than you?d expect because a normal renewal (as in kinit -R or kstart) leaves a brief period of time when the credentials cache is unusable. This can result in NFS failing. I use a special approach that depends upon the details of the KEYRING implementation. It should be free of race conditions for NFS. If desired, a different approach to avoid race conditions could be used for caches located in /tmp. I haven?t written that code but there?s a comment in the source outlining it. I?ll be creating a git repository for the code. On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski > wrote: On 01/09/2017 09:52 AM, Charles Hedrick wrote: Various documentation suggests that it is possible for Gssproxy to get tickets for users who need to use NFS. This is a possible way to handle things like cron jobs. However while a gssproxy.conf example is given, there?s no sign of what needs to be done in freeipa to authorize it. I tried following instructions for LDAP access, but it doesn?t work. NFS seems to use a different, two-stage method for getting credentials, so that?s not a surprise. There are, not surprisingly, no useful error messages even with logging turned all the way up. I'm interested in this as well. All I've been able to find so far is: https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/ haven't tried anything. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Mar 2 20:07:25 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 2 Mar 2017 21:07:25 +0100 Subject: [Freeipa-users] Switch sudoers to IPA In-Reply-To: References: <20170302151007.piq6fxaaz26u4uyw@hendrix> Message-ID: <20170302200725.bghfr4cczibhrohd@hendrix> On Thu, Mar 02, 2017 at 09:50:41PM +0530, deepak dimri wrote: > Hi Jakub, Actually that is what i am doing. i am creating the user with > same UID in IPA and then if i delete the user locally then i can > authenticate via IPA. Is there anyway i can do this without deleting the > user? This is just to use the same GID and avoid recreation of > home/directories. I think you'd need to modify the PAM stack to keep going even if authentication against pam_unix fails. I /think/ (but haven't tested ) that modifying the lines that deal with pam_unix/pam_sss like this: auth [default=2 success=ok] pam_localuser.so auth sufficient pam_unix.so nullok try_first_pass auth [success=done ignore=ignore default=die] pam_sss.so use_first_pass could work. The other lines in the PAM auth stack and all the other stacks should be left intact. (Please keep a root shell around if you're going to tinker with PAM settings and preferably try this out on a test box first.) From william.muriithi at gmail.com Thu Mar 2 20:18:59 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 2 Mar 2017 15:18:59 -0500 Subject: [Freeipa-users] Kerberos autheticated NFS issue Message-ID: Afternoon. I have noticed below errors on a RHEL 6.8 NFS client that is using a IPA 4.4 for authentication. On some system, this error show up a lot. The connection is fine according to nmap, but the logs imply there is issue with the connection. What are some of the reason that can trigger the particular error on NFS system? Mar 2 11:50:51 manganese rpc.gssd[8336]: WARNING: can't create tcp rpc_clnt to server plutonium.eng.example.com for user with uid 0: RPC: Remote system error - No route to host Mar 2 11:50:51 manganese rpc.gssd[8336]: WARNING: can't create tcp rpc_clnt to server plutonium.eng.example.com for user with uid 0: RPC: Remote system error - No route to host Mar 2 11:52:23 manganese rpc.gssd[8336]: WARNING: can't create tcp rpc_clnt to server bromine.eng.example.com for user with uid 0: RPC: Remote system error - No route to host Mar 2 11:52:23 manganese rpc.gssd[8336]: WARNING: can't create tcp rpc_clnt to server bromine.eng.example.com for user with uid 0: RPC: Remote system error - No route to host Mar 2 11:52:26 manganese rpc.gssd[8336]: WARNING: can't create tcp rpc_clnt to server iodine.eng.example.com for user with uid 0: RPC: Remote system error - No route to host Regards, William From william.muriithi at gmail.com Thu Mar 2 20:28:38 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 2 Mar 2017 15:28:38 -0500 Subject: [Freeipa-users] LDAP based autofs map redundancy Message-ID: Afternoon, I have noticed that even when a network has two IPA for redundancy, autofs don't seem to be able to take advantage of the remaining IPA should one of the IPA goes down. Is this a know issue with LDAP based maps or is it a configuration that need to be adjusted. By the way, only about half of the systems are affected and I have noticed they have this on sssd.conf ipa_server = _srv_, hydrogen.eng.example.com It does look though like kerberos is not affected as all systems can authenticate fine, so looks like its autofs issue alone This is the error I am noticing on the logs. Mar 2 14:18:29 platinum automount[2887]: key "brad" not found in map source(s). Mar 2 14:19:18 platinum automount[2887]: bind_ldap_simple: lookup(ldap): Unable to bind to the LDAP server: (default), error Can't contact LDAP server Mar 2 14:19:21 platinum automount[2887]: bind_ldap_simple: lookup(ldap): Unable to bind to the LDAP server: (default), error Can't contact LDAP server Regards, William From jhrozek at redhat.com Thu Mar 2 20:35:48 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 2 Mar 2017 21:35:48 +0100 Subject: [Freeipa-users] LDAP based autofs map redundancy In-Reply-To: References: Message-ID: <20170302203548.zr4obwj473e6yxle@hendrix> On Thu, Mar 02, 2017 at 03:28:38PM -0500, William Muriithi wrote: > Afternoon, > > > I have noticed that even when a network has two IPA for redundancy, > autofs don't seem to be able to take advantage of the remaining IPA > should one of the IPA goes down. > > Is this a know issue with LDAP based maps or is it a configuration > that need to be adjusted. By the way, only about half of the systems > are affected and I have noticed they have this on sssd.conf > > > ipa_server = _srv_, hydrogen.eng.example.com > > It does look though like kerberos is not affected as all systems can > authenticate fine, so looks like its autofs issue alone > > This is the error I am noticing on the logs. > > Mar 2 14:18:29 platinum automount[2887]: key "brad" not found in map source(s). > Mar 2 14:19:18 platinum automount[2887]: bind_ldap_simple: > lookup(ldap): Unable to bind to the LDAP server: (default), error > Can't contact LDAP server > Mar 2 14:19:21 platinum automount[2887]: bind_ldap_simple: > lookup(ldap): Unable to bind to the LDAP server: (default), error > Can't contact LDAP server I guess /etc/nsswitch.conf uses ldap for automount and not sssd? From william.muriithi at gmail.com Thu Mar 2 20:50:20 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 2 Mar 2017 15:50:20 -0500 Subject: [Freeipa-users] Push authentication policy using IPA Message-ID: Hello, Is there currently any way one can force IPA clients (Gnome and KDE) to authenticate users before one can have Gnome based services like browser and such? I am looking for something similar to windows GPO that one can publish to force password authentication after restart or after a certain time expire without any users activity. If not, would anyone have an way of controlling RHEL based system policies in a central way? Any pointer would be appreciated Regards, William From umarzuki at gmail.com Fri Mar 3 05:20:57 2017 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Fri, 3 Mar 2017 13:20:57 +0800 Subject: [Freeipa-users] renewing cert and migrating free-ipa 3.1 Message-ID: After httpd failed to start even with "NSSEnforceValidCerts off" in /etc/httpd/conf.d/nss.conf It used to work for a while since we use this only for zimbra but today it won't start anymore. We are not using commercial certs, so which steps should I follow to renew certs? It seems CA has expired more than 2 weeks ago. # ipa-getcert list Number of certificates and requests being tracked: 7. Request ID '20130112120232': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Peer's Certificate has expired.). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM-MY/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DOMAIN.COM.MY subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY expires: 2016-12-16 16:18:27 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv DOMAIN-COM-MY track: yes auto-renew: yes Request ID '20130112120734': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Peer's Certificate has expired.). stuck: yes key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=DOMAIN.COM.MY subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY expires: 2016-12-16 16:18:27 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes # rpm -qa | grep ipa freeipa-admintools-3.1.0-2.fc18.x86_64 freeipa-server-3.1.0-2.fc18.x86_64 libipa_hbac-python-1.9.3-1.fc18.x86_64 python-iniparse-0.4-6.fc18.noarch freeipa-client-3.1.0-2.fc18.x86_64 freeipa-server-selinux-3.1.0-2.fc18.x86_64 freeipa-python-3.1.0-2.fc18.x86_64 libipa_hbac-1.9.3-1.fc18.x86_64 From harald.dunkel at aixigo.de Fri Mar 3 07:45:10 2017 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Fri, 3 Mar 2017 08:45:10 +0100 Subject: [Freeipa-users] ipa-client-install generates bad sssd.conf Message-ID: <94030dc8-6768-e826-38fa-a2e8265715ae@aixigo.de> Hi folks, running freeipa client 4.3.2-5 and sssd 1.15.0-3 on Debian Stretch ipa-client-install creates a bad sssd.conf file, e.g. [domain/example.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = stretch1.vs.example.com chpass_provider = ipa ipa_server = _srv_, ipa1.example.com dns_discovery_domain = example.com [sssd] domains = example.com services = sudo [sudo] Esp. the services for nss, pam and ssh are not setup. Is this as expected? Every helpful comment is highly appreciated. Harri From jhrozek at redhat.com Fri Mar 3 08:32:57 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 3 Mar 2017 09:32:57 +0100 Subject: [Freeipa-users] ipa-client-install generates bad sssd.conf In-Reply-To: <94030dc8-6768-e826-38fa-a2e8265715ae@aixigo.de> References: <94030dc8-6768-e826-38fa-a2e8265715ae@aixigo.de> Message-ID: <20170303083257.zkurhvg7ox4sufyu@hendrix> On Fri, Mar 03, 2017 at 08:45:10AM +0100, Harald Dunkel wrote: > Hi folks, > > running freeipa client 4.3.2-5 and sssd 1.15.0-3 on > Debian Stretch ~~~~~~~~~~~~~~ This is important I guess. Since SSSD 1.15, SSSD allows to socket-activate the services, so it is no longer required to have them explicitly listed in the services line of the sssd section. But: - there were some nasty bugs in the first version of the socket activation. We will be releasing 1.15.1 today to address those issues - the sockets must be enabled (systemctl status sssd-nss.socket). I understand Debian is doing this but I'm neither Debian user nor developer. I would suggest to ask on some Debian-specific forum or file a bug report if the resulting configurationd doesn't work. > ipa-client-install creates a bad sssd.conf file, e.g. > > [domain/example.com] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = example.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ldap_tls_cacert = /etc/ipa/ca.crt > ipa_hostname = stretch1.vs.example.com > chpass_provider = ipa > ipa_server = _srv_, ipa1.example.com > dns_discovery_domain = example.com > [sssd] > domains = example.com > services = sudo btw I find it strange that sudo is listed. I would expect either all or no services to be listed. The feature is backwards-compatible, so if you list the services explicitly, the sssd process would still start them explicitly, just as it did with previous versions. > [sudo] > > > Esp. the services for nss, pam and ssh are not setup. Is this > as expected? > > > Every helpful comment is highly appreciated. > Harri > > -- > 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 From harald.dunkel at aixigo.de Fri Mar 3 08:56:55 2017 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Fri, 3 Mar 2017 09:56:55 +0100 Subject: [Freeipa-users] ipa-client-install generates bad sssd.conf In-Reply-To: <20170303083257.zkurhvg7ox4sufyu@hendrix> References: <94030dc8-6768-e826-38fa-a2e8265715ae@aixigo.de> <20170303083257.zkurhvg7ox4sufyu@hendrix> Message-ID: Hi Jakub, On 03/03/17 09:32, Jakub Hrozek wrote: > On Fri, Mar 03, 2017 at 08:45:10AM +0100, Harald Dunkel wrote: >> Hi folks, >> >> running freeipa client 4.3.2-5 and sssd 1.15.0-3 on >> Debian Stretch > ~~~~~~~~~~~~~~ > This is important I guess. > > Since SSSD 1.15, SSSD allows to socket-activate the services, so it is > no longer required to have them explicitly listed in the services line > of the sssd section. But: > - there were some nasty bugs in the first version of the socket > activation. We will be releasing 1.15.1 today to address those > issues > - the sockets must be enabled (systemctl status sssd-nss.socket). I > understand Debian is doing this but I'm neither Debian user nor > developer. I would suggest to ask on some Debian-specific forum or > file a bug report if the resulting configurationd doesn't work. > This is systemd-only? Wouldn't it be better to create a working sssd.conf, no matter what? Regards Harri From jhrozek at redhat.com Fri Mar 3 09:14:46 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 3 Mar 2017 10:14:46 +0100 Subject: [Freeipa-users] ipa-client-install generates bad sssd.conf In-Reply-To: References: <94030dc8-6768-e826-38fa-a2e8265715ae@aixigo.de> <20170303083257.zkurhvg7ox4sufyu@hendrix> Message-ID: <20170303091446.md4myw33jcgbdpcg@hendrix> On Fri, Mar 03, 2017 at 09:56:55AM +0100, Harald Dunkel wrote: > Hi Jakub, > > On 03/03/17 09:32, Jakub Hrozek wrote: > > On Fri, Mar 03, 2017 at 08:45:10AM +0100, Harald Dunkel wrote: > >> Hi folks, > >> > >> running freeipa client 4.3.2-5 and sssd 1.15.0-3 on > >> Debian Stretch > > ~~~~~~~~~~~~~~ > > This is important I guess. > > > > Since SSSD 1.15, SSSD allows to socket-activate the services, so it is > > no longer required to have them explicitly listed in the services line > > of the sssd section. But: > > - there were some nasty bugs in the first version of the socket > > activation. We will be releasing 1.15.1 today to address those > > issues > > - the sockets must be enabled (systemctl status sssd-nss.socket). I > > understand Debian is doing this but I'm neither Debian user nor > > developer. I would suggest to ask on some Debian-specific forum or > > file a bug report if the resulting configurationd doesn't work. > > > > This is systemd-only? > > Wouldn't it be better to create a working sssd.conf, no matter > what? It is up to whoever is creating the sssd.conf. As I said, the change is backwards-compatible. If you want the services to be started by sssd, then list them in the services line. If you want to have them started on demand and have a simpler configuration, you rely on the systemd services manager. From tkrizek at redhat.com Fri Mar 3 10:22:59 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Fri, 3 Mar 2017 11:22:59 +0100 Subject: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening In-Reply-To: References: <35945c0c-e1e2-3d34-cde3-2eeae5408a15@redhat.com> Message-ID: <92f941ef-142e-1084-ecfd-66a715abc587@redhat.com> On 03/02/2017 06:25 PM, Chris Herdt wrote: > On Thu, Mar 2, 2017 at 10:06 AM, Martin Basti >wrote: > > > > > On 02.03.2017 16:55, Chris Herdt wrote: >> >> >> On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti > > wrote: >> >> >> >> On 02.03.2017 01:07, Chris Herdt wrote: >>> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS >>> 7.3 from a FreeIPA 3.0.0 master on CentOS 6.8 following the >>> steps at >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html >>> >>> >>> At this step: >>> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir >>> /var/lib/ipa/replica-info-replicaname.example.com.gpg >>> >>> I get the error: >>> ERROR cannot connect to 'ldaps://master.example.com >>> ' >>> >>> I ran ipa-replica-conncheck and found that port 636 is not >>> accessible: >>> Port check failed! Inaccessible port(s): 636 (TCP) >>> >>> The port is not blocked. I'm wondering where in the >>> configuration for FreeIPA 3.0.0 I should check the LDAPS >>> (mis)configuration, or if there is a way I can specify to >>> use port 389 for setting up the replica. >>> >>> Thanks! >>> >>> -- >>> Chris Herdt >>> Systems Administrator >>> >>> >> >> Hello, >> this is known issue only in FreeIPA 4.4.x, this will be >> fixed in next minor update which should be released soon to >> RHEL7.3 (I don't know how fast it will be in Centos) >> >> so you can wait, or enable it manually (not nice) >> >> sorry for troubles >> Martin >> >> >> >> Thanks for the reply! Before attempting this in my production >> environment, I had set up a similar configuration in a test >> environment (FreeIPA 3.0.0 master on CentOS 6.8, FreeIPA 4.4.0 >> replica on CentOS 7.3) and the ipa-replica-install went fine. I >> assumed this was an issue with my FreeIPA 3.0.0 production server. >> >> To enable the fix manually, I'm assuming I'd need to install >> FreeIPA from source on the intended replica? If I download the >> 4.4.3 release from https://pagure.io/freeipa/releases >> , will that be sufficient? > Sorry, > I probably misread what you wrote, I thought that port is closed > on replica, but now I see that port is closed on 3.3.0 master, so > this is something different. I'm not aware of any issue on 3.3.0 > that should cause this. > > Could you check your configuration on 3.3.0 master? Is port opened > on master? Do you have any errors in > /var/log/dirsrv/slapd-*/errors log on master? > > Martin > > > When I compare the errors file on my production environment and my > test environment, I do note that the LDAPS entry is missing from my > production environment: > > production: > [01/Mar/2017:17:30:07 -0600] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [01/Mar/2017:17:30:07 -0600] - Listening on > /var/run/slapd-PROD-EXAMPLE-COM.socket for LDAPI requests > > test: > [28/Feb/2017:13:37:50 -0600] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [28/Feb/2017:13:37:50 -0600] - Listening on All Interfaces port 636 > for LDAPS requests > [28/Feb/2017:13:37:50 -0600] - Listening on > /var/run/slapd-TEST-EXAMPLE-COM.socket for LDAPI requests > > I'm not sure why it is missing though. Which config file(s) should I > be checking? You can examine the file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif to check if the Directory Server has LDAP configured correctly. In particular, you're interested in: - nsslapd-security in cn=config - cn=encryption,cn=config - cn=RSA,cn=encryption,cn=config Also, you can check if the certificate for LDAPS is available in the NSS database: certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L > > > -- > Chris Herdt > Systems Administrator > > -- Tomas Krizek GPG key ID: 0xA1FBA5F7EF8C 4869 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From harald.dunkel at aixigo.de Fri Mar 3 11:02:56 2017 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Fri, 3 Mar 2017 12:02:56 +0100 Subject: [Freeipa-users] ipa-client-install generates bad sssd.conf In-Reply-To: <20170303091446.md4myw33jcgbdpcg@hendrix> References: <94030dc8-6768-e826-38fa-a2e8265715ae@aixigo.de> <20170303083257.zkurhvg7ox4sufyu@hendrix> <20170303091446.md4myw33jcgbdpcg@hendrix> Message-ID: On 03/03/17 10:14, Jakub Hrozek wrote: > On Fri, Mar 03, 2017 at 09:56:55AM +0100, Harald Dunkel wrote: >> >> This is systemd-only? >> >> Wouldn't it be better to create a working sssd.conf, no matter >> what? > > It is up to whoever is creating the sssd.conf. As I said, the change is > backwards-compatible. If you want the services to be started by sssd, > then list them in the services line. If you want to have them started on > demand and have a simpler configuration, you rely on the systemd services > manager. > Understood. I will try 1.15.1 as soon as possible. Reading ipa-client-install it appears to me that the other services haven't been omitted on purpose. I have the impression that nss and pam have simply been forgotten. sssd's ssh service is defined only if ipa-client-install is allowed to touch the ssh or sshd configuration, but I have *no* idea why there is such a correlation. Would somebody mind to look into this? Thanx very much Harri From keesb at ghs.com Fri Mar 3 13:00:43 2017 From: keesb at ghs.com (Kees Bakker) Date: Fri, 3 Mar 2017 14:00:43 +0100 Subject: [Freeipa-users] Can mount NFS, but user only gets the permission question marks In-Reply-To: <279be76e-97c4-8251-0848-4135544451ba@gmail.com> References: <0f9ff57f-8174-cd9b-16a1-564a4ce94060@ghs.com> <06e4c38d-747d-06ae-c667-ae1b133baa4a@ghs.com> <2c017c2f-eb84-473e-a7d7-842667fb727e@gmail.com> <407d4339-5403-e776-f0e6-ca539a1a1f2a@ghs.com> <3380632a-4d4b-f602-12db-2a3cb273c365@gmail.com> <7db8ae96-0cc6-b99a-195b-a815ba605fe4@ghs.com> <48f35842-b229-aed7-7f08-73cfada57557@gmail.com> <680a3dc2-5b29-2de9-0683-85d866e6b4a1@ghs.com> <375c316b-a1e8-028c-9fb0-31ef2c175542@ghs.com> <279be76e-97c4-8251-0848-4135544451ba@gmail.com> Message-ID: <7782feaa-cc88-0ec7-1bec-e34029e59588@ghs.com> On 02-03-17 14:55, Brendan Kearney wrote: > On 03/02/2017 08:43 AM, Kees Bakker wrote: >> On 02-03-17 13:34, Brendan Kearney wrote: >>> On 03/02/2017 05:40 AM, Kees Bakker wrote: >>>> On 24-02-17 14:38, Brendan Kearney wrote: >>>>> On 02/24/2017 03:33 AM, Kees Bakker wrote: >>>>>> On 23-02-17 15:39, Brendan Kearney wrote: >>>>>>> On 02/23/2017 09:11 AM, Kees Bakker wrote: >>>>>>>> On 23-02-17 13:51, Brendan Kearney wrote: >>>>>>>>> On 02/23/2017 07:32 AM, Kees Bakker wrote: >>>>>>>>>> On 22-02-17 17:33, Brendan Kearney wrote: >>>>>>>>>>> On 02/22/2017 10:26 AM, Kees Bakker wrote: >>>>>>>>>>>> On 22-02-17 14:05, Brendan Kearney wrote: >>>>>>>>>>>>> On 02/22/2017 05:23 AM, Kees Bakker wrote: >>>>>>>>>>>>>> On 21-02-17 19:49, Brendan Kearney wrote: >>>>>>>>>>>>>>> On 02/21/2017 10:57 AM, Kees Bakker wrote: >>>>>>>>>>>>>>>> Hey, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Maybe one of the NFS users on this list could give me a hint what >>>>>>>>>>>>>>>> could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've set up an NFS server and I can mount the NFS directory on my client. So, I'm >>>>>>>>>>>>>>>> guessing that setting up Kerberos principal was done correctly. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, only root can actually access the mounted contents. Any other user >>>>>>>>>>>>>>>> only sees question marks as shown below. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The mount command is simple. >>>>>>>>>>>>>>>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome >>>>>>>>>>>>>>>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017 >>>>>>>>>>>>>>>> mount.nfs: trying text-based options 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30' >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On the server side /etc/exports looks like this. >>>>>>>>>>>>>>>> /home *(rw,sync,sec=krb5i,no_subtree_check) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> $ sudo mount |grep nfs >>>>>>>>>>>>>>>> srv1.example.com:/home on /nfshome type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> $ sudo ls -ld /nfshome >>>>>>>>>>>>>>>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome >>>>>>>>>>>>>>>> $ sudo ls -l /nfshome >>>>>>>>>>>>>>>> total 0 >>>>>>>>>>>>>>>> drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> $ ls -l /nfshome >>>>>>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>>>>>> $ ls -l / | grep nfshome >>>>>>>>>>>>>>>> ls: cannot access '/nfshome': Permission denied >>>>>>>>>>>>>>>> d????????? ? ? ? ? ? nfshome >>>>>>>>>>>>>>>> >>>> [...] >>>> >>>> Continuing story... >>>> >>>> I've tried various things in the meantime. I've set up two test environments with virtual >>>> machines (virtualbox). >>>> * with Fedora 25; this works. >>>> * with Ubuntu 16.04; I'm getting the same problem (permission denied and question marks). >>>> >>>> I also looked at the verbose output of rpc.gssd, it gives >>>> >>>> ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection >>> does the actual error message say @REALM, or did you substitute that to obscure sensitive info? if it does actually say @REALM, then you are missing a config directive somewhere, that specifies the kerberos realm. >> Be assured that I'm using the real thing. >> >>>> getting credentials for client with uid 60001 for server srv1.example.com >>>> getting credentials for client with uid 60001 for server srv1.example.com >>>> WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com >> So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but not for another >> user. >> >> [...] >> >> Log when the user is listing the directory >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handling gssd upcall (/run/rpc_pipefs/nfs/clnt14) >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=60001 enctypes=18,17,16,23,3,1,2 ' >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: handling krb5 upcall (/run/rpc_pipefs/nfs/clnt14) >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '' >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal keesb at REALM in cache collection >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: getting credentials for client with uid 60001 for server srv1.example.com >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' being considered, with preferred realm 'REALM' >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: CC '/tmp/krb5ccmachine_REALM' owned by 0, not 60001 >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: getting credentials for client with uid 60001 for server srv1.example.com >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: WARNING: Failed to create krb5 context for user with uid 60001 for server srv1.example.com >> Mar 2 14:24:00 clnt1 rpc.gssd[3612]: doing error downcall >> >> [...] > file a bug > > [brendan at desktop ~]$ ll /tmp/ > total 36 > -rw------- 1 brendan brendan 4111 Mar 2 08:22 krb5cc_1000_9GeQKj > -rw------- 1 root root 579 Mar 1 10:08 krb5ccmachine_BPK2.COM > > users should never have, and never be required to have, access to the machines kerberos credential cache. That is indeed the clue. On Ubuntu the credential cache is kept in the KEYRING. But gssd isn't looking for it. If I create a credential cache in /tmp like so $ KRB5CCNAME=/tmp/krb5cc_keesb kinit the access to the NFS now succeeds. Hurray :-) $ ls -l /nfshome/ total 0 drwxr-xr-x 1 keesb keesb 116 jan 27 12:56 keesb Is it a bug of gssd? I'm not sure. I think gssd has no keyring support at all. Fedora must do things differently, because there, it seems, the /tmp file is present. How is that file created? -- Kees From umarzuki at gmail.com Fri Mar 3 13:20:41 2017 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Fri, 3 Mar 2017 21:20:41 +0800 Subject: [Freeipa-users] renewing cert and migrating free-ipa 3.1 In-Reply-To: References: Message-ID: At first ip-getcert list hows certificate error ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Peer's Certificate has expired.). but after I changed ipa server's date to before expirate date, it shows ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: couldn't connect to host). when I tried to start ipa with "service ipa start", all services would fail, so I need to start one by one systemctl start dirsrv at DOMAIN-COM-MY.service systemctl status dirsrv at DOMAIN-COM-MY.service systemctl start krb5kdc.service systemctl status krb5kdc.service systemctl start kadmin.service systemctl status kadmin.service systemctl start ipa_memcached.service systemctl status ipa_memcached.service systemctl start pki-tomcatd at pki-tomcat.service systemctl status pki-tomcatd at pki-tomcat.service # tail /var/log/messages Jan 3 17:32:26 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat... Jan 3 17:32:29 ipa systemd[1]: Started PKI Tomcat Server pki-tomcat. Jan 3 17:33:08 ipa certmonger[476]: 2016-01-03 17:33:08 [476] Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: couldn't connect to host). Jan 3 17:33:12 ipa certmonger[476]: 2016-01-03 17:33:12 [476] Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: couldn't connect to host). 2017-03-03 13:20 GMT+08:00 Umarzuki Mochlis : > After httpd failed to start even with "NSSEnforceValidCerts off" in > /etc/httpd/conf.d/nss.conf > It used to work for a while since we use this only for zimbra but > today it won't start anymore. > > We are not using commercial certs, so which steps should I follow to > renew certs? > > It seems CA has expired more than 2 weeks ago. > > # ipa-getcert list > Number of certificates and requests being tracked: 7. > Request ID '20130112120232': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl > failed to execute the HTTP POST transaction, explaining: Peer's > Certificate has expired.). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM-MY/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=DOMAIN.COM.MY > subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY > expires: 2016-12-16 16:18:27 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv > DOMAIN-COM-MY > track: yes > auto-renew: yes > Request ID '20130112120734': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl > failed to execute the HTTP POST transaction, explaining: Peer's > Certificate has expired.). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=DOMAIN.COM.MY > subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY > expires: 2016-12-16 16:18:27 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > # rpm -qa | grep ipa > freeipa-admintools-3.1.0-2.fc18.x86_64 > freeipa-server-3.1.0-2.fc18.x86_64 > libipa_hbac-python-1.9.3-1.fc18.x86_64 > python-iniparse-0.4-6.fc18.noarch > freeipa-client-3.1.0-2.fc18.x86_64 > freeipa-server-selinux-3.1.0-2.fc18.x86_64 > freeipa-python-3.1.0-2.fc18.x86_64 > libipa_hbac-1.9.3-1.fc18.x86_64 From rcritten at redhat.com Fri Mar 3 14:53:04 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 3 Mar 2017 09:53:04 -0500 Subject: [Freeipa-users] ipa-client-install generates bad sssd.conf In-Reply-To: References: <94030dc8-6768-e826-38fa-a2e8265715ae@aixigo.de> <20170303083257.zkurhvg7ox4sufyu@hendrix> <20170303091446.md4myw33jcgbdpcg@hendrix> Message-ID: <28160af8-032d-d2b6-e45d-08e6d01e3497@redhat.com> Harald Dunkel wrote: > On 03/03/17 10:14, Jakub Hrozek wrote: >> On Fri, Mar 03, 2017 at 09:56:55AM +0100, Harald Dunkel wrote: >>> >>> This is systemd-only? >>> >>> Wouldn't it be better to create a working sssd.conf, no matter >>> what? >> >> It is up to whoever is creating the sssd.conf. As I said, the change is >> backwards-compatible. If you want the services to be started by sssd, >> then list them in the services line. If you want to have them started on >> demand and have a simpler configuration, you rely on the systemd services >> manager. >> > > Understood. I will try 1.15.1 as soon as possible. > > Reading ipa-client-install it appears to me that the other > services haven't been omitted on purpose. I have the > impression that nss and pam have simply been forgotten. > > sssd's ssh service is defined only if ipa-client-install > is allowed to touch the ssh or sshd configuration, but I > have *no* idea why there is such a correlation. > > Would somebody mind to look into this? This is managed by authconfig on Fedora/RHEL systems. Not sure what Debian does in this regard. Timo? rob From rcritten at redhat.com Fri Mar 3 14:55:56 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 3 Mar 2017 09:55:56 -0500 Subject: [Freeipa-users] renewing cert and migrating free-ipa 3.1 In-Reply-To: References: Message-ID: <2bb343ae-c28f-3b5f-22c2-658b6014fa16@redhat.com> Umarzuki Mochlis wrote: > At first ip-getcert list hows certificate error > > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction, explaining: Peer's Certificate has > expired.). > > but after I changed ipa server's date to before expirate date, it shows > > ca-error: Server failed request, will retry: -504 (libcurl failed to > execute the HTTP POST transaction, explaining: couldn't connect to > host). > > when I tried to start ipa with "service ipa start", all services would > fail, so I need to start one by one > > systemctl start dirsrv at DOMAIN-COM-MY.service > systemctl status dirsrv at DOMAIN-COM-MY.service > systemctl start krb5kdc.service > systemctl status krb5kdc.service > systemctl start kadmin.service > systemctl status kadmin.service > systemctl start ipa_memcached.service > systemctl status ipa_memcached.service > systemctl start pki-tomcatd at pki-tomcat.service > systemctl status pki-tomcatd at pki-tomcat.service > > > # tail /var/log/messages > Jan 3 17:32:26 ipa systemd[1]: Starting PKI Tomcat Server pki-tomcat... > Jan 3 17:32:29 ipa systemd[1]: Started PKI Tomcat Server pki-tomcat. > Jan 3 17:33:08 ipa certmonger[476]: 2016-01-03 17:33:08 [476] Server > failed request, will retry: -504 (libcurl failed to execute the HTTP > POST transaction, explaining: couldn't connect to host). > Jan 3 17:33:12 ipa certmonger[476]: 2016-01-03 17:33:12 [476] Server > failed request, will retry: -504 (libcurl failed to execute the HTTP > POST transaction, explaining: couldn't connect to host). You want to use the getcert command, not ipa-getcert, to see the CA subsystem certificates. What you should do is: getcert list |grep expires Find a date/time that fits into a period where all certs are valid and go back in time to then (after stopping ntpd). That will hopefully fix the ipactl start issue. Once IPA is restarted, restart certmonger. rob From rakesh.rajasekharan at gmail.com Fri Mar 3 15:14:45 2017 From: rakesh.rajasekharan at gmail.com (Rakesh Rajasekharan) Date: Fri, 3 Mar 2017 20:44:45 +0530 Subject: [Freeipa-users] Freeipa 4.4 creating users with expiration Message-ID: Hello, Am using Freeipa 4.4 version . I would like to create few users only valid for few days or months. So,is there a way to create few users with a preset expiration or auto lock those accounts after a few days Thanks Rakesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at tresgeek.net Fri Mar 3 17:57:49 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Fri, 3 Mar 2017 11:57:49 -0600 (CST) Subject: [Freeipa-users] GSSAPI for second hop (SSH) Message-ID: <808043599.2118.1488563869189.JavaMail.zimbra@tresgeek.net> Hello, I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users connecting to Linux servers from their domain-joined workstations are not required to enter a password for the first connection. However, if they attempt to ssh to a second Linux machine from the first they are being prompted for a password. I've tried the following /etc/ssh/ssh_config options: GSSAPIDelegateCredentials yes GSSAPIKeyExchange yes GSSAPIRenewalForcesRekey yes GSSAPITrustDns yes And the following /etc/ssh/sshd_config options: GSSAPIAuthentication yes GSSAPIKeyExchange yes GSSAPIStoreCredentialsOnRekey yes Am I missing a step/configuration? Thanks, j From abokovoy at redhat.com Fri Mar 3 18:32:27 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 3 Mar 2017 20:32:27 +0200 Subject: [Freeipa-users] GSSAPI for second hop (SSH) In-Reply-To: <808043599.2118.1488563869189.JavaMail.zimbra@tresgeek.net> References: <808043599.2118.1488563869189.JavaMail.zimbra@tresgeek.net> Message-ID: <20170303183227.uhyffhd63tlwbnxe@redhat.com> On pe, 03 maalis 2017, Jason B. Nance wrote: >Hello, > >I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users connecting to Linux servers from their domain-joined workstations are not required to enter a password for the first connection. However, if they attempt to ssh to a second Linux machine from the first they are being prompted for a password. > >I've tried the following /etc/ssh/ssh_config options: > > GSSAPIDelegateCredentials yes > GSSAPIKeyExchange yes > GSSAPIRenewalForcesRekey yes > GSSAPITrustDns yes > >And the following /etc/ssh/sshd_config options: > > GSSAPIAuthentication yes > GSSAPIKeyExchange yes > GSSAPIStoreCredentialsOnRekey yes > >Am I missing a step/configuration? They need to allow delegation on the machine where their first hop starts, not only on your jump server. -- / Alexander Bokovoy From rharwood at redhat.com Fri Mar 3 18:53:25 2017 From: rharwood at redhat.com (Robbie Harwood) Date: Fri, 03 Mar 2017 13:53:25 -0500 Subject: [Freeipa-users] GSSAPI for second hop (SSH) In-Reply-To: <808043599.2118.1488563869189.JavaMail.zimbra@tresgeek.net> References: <808043599.2118.1488563869189.JavaMail.zimbra@tresgeek.net> Message-ID: "Jason B. Nance" writes: > I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users > connecting to Linux servers from their domain-joined workstations are > not required to enter a password for the first connection. However, > if they attempt to ssh to a second Linux machine from the first they > are being prompted for a password. What is the output if they klist on the first machine they SSH to? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From jason at tresgeek.net Fri Mar 3 19:17:30 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Fri, 3 Mar 2017 13:17:30 -0600 (CST) Subject: [Freeipa-users] GSSAPI for second hop (SSH) In-Reply-To: <20170303183227.uhyffhd63tlwbnxe@redhat.com> References: <808043599.2118.1488563869189.JavaMail.zimbra@tresgeek.net> <20170303183227.uhyffhd63tlwbnxe@redhat.com> Message-ID: <2058236501.2524.1488568650816.JavaMail.zimbra@tresgeek.net> >>I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users connecting to >>Linux servers from their domain-joined workstations are not required to enter a >>password for the first connection. However, if they attempt to ssh to a second >>Linux machine from the first they are being prompted for a password. >> >>I've tried the following /etc/ssh/ssh_config options: >> >> GSSAPIDelegateCredentials yes >> GSSAPIKeyExchange yes >> GSSAPIRenewalForcesRekey yes >> GSSAPITrustDns yes >> >>And the following /etc/ssh/sshd_config options: >> >> GSSAPIAuthentication yes >> GSSAPIKeyExchange yes >> GSSAPIStoreCredentialsOnRekey yes >> >>Am I missing a step/configuration? > They need to allow delegation on the machine where their first hop > starts, not only on your jump server. Both the first hop and subsequent servers have those settings. From jason at tresgeek.net Fri Mar 3 19:22:17 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Fri, 3 Mar 2017 13:22:17 -0600 (CST) Subject: [Freeipa-users] GSSAPI for second hop (SSH) In-Reply-To: References: <808043599.2118.1488563869189.JavaMail.zimbra@tresgeek.net> Message-ID: <1608946273.2583.1488568937674.JavaMail.zimbra@tresgeek.net> >> I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users >> connecting to Linux servers from their domain-joined workstations are >> not required to enter a password for the first connection. However, >> if they attempt to ssh to a second Linux machine from the first they >> are being prompted for a password. > > What is the output if they klist on the first machine they SSH to? [jnance at centric.com@sl1aosplmgt0001 ~]$ klist Ticket cache: KEYRING:persistent:255985:krb_ccache_TuVdBrp Default principal: jnance at CENTRIC.COM Valid starting Expires Service principal 03/03/2017 11:55:16 03/03/2017 21:47:34 krbtgt/IPA.GEN.ZONE at CENTRIC.COM renew until 03/04/2017 11:47:33 03/03/2017 11:47:34 03/03/2017 21:47:34 krbtgt/CENTRIC.COM at CENTRIC.COM renew until 03/04/2017 11:47:33 centric.com is the AD domain that ipa.gen.zone trusts. From abokovoy at redhat.com Fri Mar 3 19:56:47 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 3 Mar 2017 21:56:47 +0200 Subject: [Freeipa-users] GSSAPI for second hop (SSH) In-Reply-To: <2058236501.2524.1488568650816.JavaMail.zimbra@tresgeek.net> References: <808043599.2118.1488563869189.JavaMail.zimbra@tresgeek.net> <20170303183227.uhyffhd63tlwbnxe@redhat.com> <2058236501.2524.1488568650816.JavaMail.zimbra@tresgeek.net> Message-ID: <20170303195647.tnagl2bdjq43ouqo@redhat.com> On pe, 03 maalis 2017, Jason B. Nance wrote: >>>I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users connecting to >>>Linux servers from their domain-joined workstations are not required to enter a >>>password for the first connection. However, if they attempt to ssh to a second >>>Linux machine from the first they are being prompted for a password. >>> >>>I've tried the following /etc/ssh/ssh_config options: >>> >>> GSSAPIDelegateCredentials yes >>> GSSAPIKeyExchange yes >>> GSSAPIRenewalForcesRekey yes >>> GSSAPITrustDns yes >>> >>>And the following /etc/ssh/sshd_config options: >>> >>> GSSAPIAuthentication yes >>> GSSAPIKeyExchange yes >>> GSSAPIStoreCredentialsOnRekey yes >>> >>>Am I missing a step/configuration? > >> They need to allow delegation on the machine where their first hop >> starts, not only on your jump server. > >Both the first hop and subsequent servers have those settings. I'm not talking about servers. It starts with the client machines. If server never got delegated credentials, how could it be a client that delegates them further? That original client has to allow delegation in first place. -- / Alexander Bokovoy From jason at tresgeek.net Fri Mar 3 20:05:42 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Fri, 3 Mar 2017 14:05:42 -0600 (CST) Subject: [Freeipa-users] GSSAPI for second hop (SSH) In-Reply-To: <20170303195647.tnagl2bdjq43ouqo@redhat.com> References: <808043599.2118.1488563869189.JavaMail.zimbra@tresgeek.net> <20170303183227.uhyffhd63tlwbnxe@redhat.com> <2058236501.2524.1488568650816.JavaMail.zimbra@tresgeek.net> <20170303195647.tnagl2bdjq43ouqo@redhat.com> Message-ID: <1841066368.2828.1488571542791.JavaMail.zimbra@tresgeek.net> >>>>I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users connecting to >>>>Linux servers from their domain-joined workstations are not required to enter a >>>>password for the first connection. However, if they attempt to ssh to a second >>>>Linux machine from the first they are being prompted for a password. >>>> >>>>I've tried the following /etc/ssh/ssh_config options: >>>> >>>> GSSAPIDelegateCredentials yes >>>> GSSAPIKeyExchange yes >>>> GSSAPIRenewalForcesRekey yes >>>> GSSAPITrustDns yes >>>> >>>>And the following /etc/ssh/sshd_config options: >>>> >>>> GSSAPIAuthentication yes >>>> GSSAPIKeyExchange yes >>>> GSSAPIStoreCredentialsOnRekey yes >>>> >>>>Am I missing a step/configuration? >> >>> They need to allow delegation on the machine where their first hop >>> starts, not only on your jump server. >> >>Both the first hop and subsequent servers have those settings. > I'm not talking about servers. It starts with the client machines. > If server never got delegated credentials, how could it be a client that > delegates them further? That original client has to allow delegation > in first place. Do you know how I can validate that is working (such as, will something show up in a klist)? I'm using PuTTY 0.67 as my Windows ssh client and have the "Allow GSSAPI credential delegation" box checked, but some quick Googling is suggesting that may not be enough. Thanks for the insight. j From jason at tresgeek.net Fri Mar 3 20:29:25 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Fri, 3 Mar 2017 14:29:25 -0600 (CST) Subject: [Freeipa-users] [solved] Re: GSSAPI for second hop (SSH) In-Reply-To: <1841066368.2828.1488571542791.JavaMail.zimbra@tresgeek.net> References: <808043599.2118.1488563869189.JavaMail.zimbra@tresgeek.net> <20170303183227.uhyffhd63tlwbnxe@redhat.com> <2058236501.2524.1488568650816.JavaMail.zimbra@tresgeek.net> <20170303195647.tnagl2bdjq43ouqo@redhat.com> <1841066368.2828.1488571542791.JavaMail.zimbra@tresgeek.net> Message-ID: <306277980.3048.1488572965953.JavaMail.zimbra@tresgeek.net> >>>>>I have a FreeIPA 4.4.0 setup with Active Directory trusts. Users connecting to >>>>>Linux servers from their domain-joined workstations are not required to enter a >>>>>password for the first connection. However, if they attempt to ssh to a second >>>>>Linux machine from the first they are being prompted for a password. >>>>> >>>>>I've tried the following /etc/ssh/ssh_config options: >>>>> >>>>> GSSAPIDelegateCredentials yes >>>>> GSSAPIKeyExchange yes >>>>> GSSAPIRenewalForcesRekey yes >>>>> GSSAPITrustDns yes >>>>> >>>>>And the following /etc/ssh/sshd_config options: >>>>> >>>>> GSSAPIAuthentication yes >>>>> GSSAPIKeyExchange yes >>>>> GSSAPIStoreCredentialsOnRekey yes >>>>> >>>>>Am I missing a step/configuration? >>> >>>> They need to allow delegation on the machine where their first hop >>>> starts, not only on your jump server. >>> >>>Both the first hop and subsequent servers have those settings. > >> I'm not talking about servers. It starts with the client machines. >> If server never got delegated credentials, how could it be a client that >> delegates them further? That original client has to allow delegation >> in first place. > > Do you know how I can validate that is working (such as, will something show up > in a klist)? I'm using PuTTY 0.67 as my Windows ssh client and have the "Allow > GSSAPI credential delegation" box checked, but some quick Googling is > suggesting that may not be enough. Okay, I missed something REALLY basic. :-( In my SSH client configuration I didn't have "GSSAPIAuthentication yes", and the default is "no". The key exchange doesn't work, but gssapi-with-mic does. Here's an excerpt from "ssh -vvv": debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply debug1: Delegating credentials debug1: Delegating credentials debug1: Authentication succeeded (gssapi-with-mic). Authenticated to sl1mmgplsat0001 (via proxy). From cherdt at umn.edu Fri Mar 3 23:51:49 2017 From: cherdt at umn.edu (Chris Herdt) Date: Fri, 3 Mar 2017 17:51:49 -0600 Subject: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening In-Reply-To: <92f941ef-142e-1084-ecfd-66a715abc587@redhat.com> References: <35945c0c-e1e2-3d34-cde3-2eeae5408a15@redhat.com> <92f941ef-142e-1084-ecfd-66a715abc587@redhat.com> Message-ID: On Fri, Mar 3, 2017 at 4:22 AM, Tomas Krizek wrote: > > > On 03/02/2017 06:25 PM, Chris Herdt wrote: > > On Thu, Mar 2, 2017 at 10:06 AM, Martin Basti wrote: >> >> >> >> >> On 02.03.2017 16:55, Chris Herdt wrote: >> >> >> >> On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti wrote: >>> >>> >>> >>> On 02.03.2017 01:07, Chris Herdt wrote: >>> >>> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a FreeIPA 3.0.0 master on CentOS 6.8 following the steps at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html >>> >>> At this step: >>> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir /var/lib/ipa/replica-info-replicaname.example.com.gpg >>> >>> I get the error: >>> ERROR cannot connect to 'ldaps://master.example.com' >>> >>> I ran ipa-replica-conncheck and found that port 636 is not accessible: >>> Port check failed! Inaccessible port(s): 636 (TCP) >>> >>> The port is not blocked. I'm wondering where in the configuration for FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there is a way I can specify to use port 389 for setting up the replica. >>> >>> Thanks! >>> >>> -- >>> Chris Herdt >>> Systems Administrator >>> >>> >>> >>> Hello, >>> this is known issue only in FreeIPA 4.4.x, this will be fixed in next minor update which should be released soon to RHEL7.3 (I don't know how fast it will be in Centos) >>> >>> so you can wait, or enable it manually (not nice) >>> >>> sorry for troubles >>> Martin >> >> >> >> Thanks for the reply! Before attempting this in my production environment, I had set up a similar configuration in a test environment (FreeIPA 3.0.0 master on CentOS 6.8, FreeIPA 4.4.0 replica on CentOS 7.3) and the ipa-replica-install went fine. I assumed this was an issue with my FreeIPA 3.0.0 production server. >> >> To enable the fix manually, I'm assuming I'd need to install FreeIPA from source on the intended replica? If I download the 4.4.3 release from https://pagure.io/freeipa/releases, will that be sufficient? >> >> Sorry, >> I probably misread what you wrote, I thought that port is closed on replica, but now I see that port is closed on 3.3.0 master, so this is something different. I'm not aware of any issue on 3.3.0 that should cause this. >> >> Could you check your configuration on 3.3.0 master? Is port opened on master? Do you have any errors in /var/log/dirsrv/slapd-*/errors log on master? >> >> Martin > > > When I compare the errors file on my production environment and my test environment, I do note that the LDAPS entry is missing from my production environment: > > production: > [01/Mar/2017:17:30:07 -0600] - slapd started. Listening on All Interfaces port 389 for LDAP requests > [01/Mar/2017:17:30:07 -0600] - Listening on /var/run/slapd-PROD-EXAMPLE-COM.socket for LDAPI requests > > test: > [28/Feb/2017:13:37:50 -0600] - slapd started. Listening on All Interfaces port 389 for LDAP requests > [28/Feb/2017:13:37:50 -0600] - Listening on All Interfaces port 636 for LDAPS requests > [28/Feb/2017:13:37:50 -0600] - Listening on /var/run/slapd-TEST-EXAMPLE-COM.socket for LDAPI requests > > I'm not sure why it is missing though. Which config file(s) should I be checking? > > You can examine the file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif to check if the Directory Server has LDAP configured correctly. In particular, you're interested in: > > - nsslapd-security in cn=config > - cn=encryption,cn=config > - cn=RSA,cn=encryption,cn=config > > Also, you can check if the certificate for LDAPS is available in the NSS database: > > certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L nsslapd-security was set to off. I set it to on, but SSL failed. There were no certificates listed--which I think explains why SSL failed--when running: certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L ipa-getcert list shows several certs, including one with location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB' -- I'm not sure where this cert exists though. I assume I need to get the NSS db to recognize the Server-Cert, for example: certutil -A -d /etc/dirsrv/slapd-EXAMPLE-COM -i ? From william.muriithi at gmail.com Sat Mar 4 00:10:40 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Fri, 3 Mar 2017 19:10:40 -0500 Subject: [Freeipa-users] Can kerberos SSSD provider be used against IPA Message-ID: Hello, I just came across this document. https://www.susecon.com/doc/2015/sessions/TUT19343.pdf If you look at page 8, that diagram imply that kerberos provider can only be used against active directory back end. However, this Redhat article below recommended the solution above for an IPA setup. See the third page from the bottom. http://people.redhat.com/steved/Summits/Summit13/Summit_Handout13.pdf Would anyone be able to comment about the inconsistency? Both articles come from a reliable source, so not sure how to make of it. Regards, William From peljasz at yahoo.co.uk Sat Mar 4 12:04:50 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Sat, 4 Mar 2017 12:04:50 +0000 Subject: [Freeipa-users] unable to decode: {replica In-Reply-To: <58B680BD.1080505@redhat.com> References: <5907f1b4-c87b-0217-d4a3-878dcf36b395@yahoo.co.uk> <250983c1-67dc-832c-aefb-f5bf4abb1cd2@redhat.com> <22d81136-0d79-df33-a041-bbc8a70fad5e@yahoo.co.uk> <58B680BD.1080505@redhat.com> Message-ID: <651a9b94-938d-125c-1a6c-966e3f7b82dc@yahoo.co.uk> On 01/03/17 08:05, Ludwig Krispenz wrote: > > On 02/28/2017 07:52 PM, lejeczek wrote: >> >> >> On 28/02/17 09:45, Petr Vobornik wrote: >>> On 02/26/2017 11:35 AM, lejeczek wrote: >>>> hi everyone >>>> >>>> I first time see: >>>> >>>> unable to decode: {replica 60} 586eaffd000a003c0000 >>>> 586eaffd000a003c0000 >>>> Replica Update Vectors: >>>> .... >>>> >>>> on all four servers. What would be a correct >>>> troubleshooting and fixing this >>>> problem? >>>> many thanks, >>>> L. >>>> >>>> >>>> >>> >>> Hello, >>> >>> what is the version and OS of your IPA servers and DS? >>> >>> $ rpm -q ipa-server freeipa-server 389-ds-base >> well I run a Centos 7.x and >> ~]$ rpm -q ipa-server freeipa-server 389-ds-base >> ipa-server-4.4.0-14.el7.centos.4.x86_64 >> package freeipa-server is not installed >> 389-ds-base-1.3.5.10-15.el7_3.x86_64 >> >> I searched the net and archives but failed to find >> anything flagged as "solved". > if you expect help, you should provide a bit more > information than the snippet of an error message. As Petr > pointed out this looks like a problem of a corrupted RUV, > but we also haven't seen these for a long time. > Could you describe your deployment, what changed recently > (addigng/removing replicas, crashes,.... ) > A mapping of servers and replica Ids, to which server does > "60" refer? If I new what "60" referred to I'd have had not ask the question, most likely. I thought it something IPA itself cannot decode so how could I? I ran first - clean-dangling-ruv - which clean a lot, but during the cleanup it kept spitting out: unable to decode.. "replica 60" is nothing like a hostname or any other human, me, given reference. I thought it is obvious that these days people start with sroogle and later "mailing lists" are last resort and not the place to do shop talk, well, very rarely should be. But, I did NOT sroogle enough, I realize it now. this fails: ~]$ ipa-replica-manage clean-ruv 60 Directory Manager password: unable to decode: {replica 60} 586eaffd000a003c0000 586eaffd000a003c0000 Replica ID 60 not found but this succeeds: ~]$ ldapmodify -p 389 -h $(hostname) -D "cn=directory manager" -Y GSSAPI -a SASL/GSSAPI authentication started SASL username: admin at PRIVATE.DOM.MY SASL SSF: 56 SASL data security layer installed. dn: cn=clean 60, cn=cleanallruv, cn=tasks, cn=config objectclass: extensibleObject replica-base-dn: dc=private,dc=private,dc=my replica-id: 60 cn: clean 60 adding new entry "cn=clean 60, cn=cleanallruv, cn=tasks, cn=config" logs: 04/Mar/2017:11:59:44.643623797 +0000] NSMMReplicationPlugin - CleanAllRUV Task: launching cleanAllRUV thread... [04/Mar/2017:11:59:44.673317808 +0000] NSMMReplicationPlugin - CleanAllRUV Task (rid 60): Cleaning rid (60)... [04/Mar/2017:11:59:44.675400517 +0000] NSMMReplicationPlugin - CleanAllRUV Task (rid 60): Waiting to process all the updates from the deleted replica... [04/Mar/2017:11:59:44.677347412 +0000] NSMMReplicationPlugin - CleanAllRUV Task (rid 60): Waiting for all the replicas to be online... [04/Mar/2017:11:59:44.713849540 +0000] NSMMReplicationPlugin - CleanAllRUV Task (rid 60): Waiting for all the replicas to receive all the deleted replica updates... [04/Mar/2017:11:59:44.743398566 +0000] NSMMReplicationPlugin - CleanAllRUV Task (rid 60): Sending cleanAllRUV task to all the replicas... [04/Mar/2017:11:59:44.784880691 +0000] NSMMReplicationPlugin - CleanAllRUV Task (rid 60): Cleaning local ruv's... [04/Mar/2017:11:59:45.792197518 +0000] NSMMReplicationPlugin - CleanAllRUV Task (rid 60): Waiting for all the replicas to be cleaned... [04/Mar/2017:11:59:45.850641867 +0000] NSMMReplicationPlugin - CleanAllRUV Task (rid 60): Waiting for all the replicas to finish cleaning... [04/Mar/2017:11:59:45.881786089 +0000] NSMMReplicationPlugin - CleanAllRUV Task (rid 60): Successfully cleaned rid(60). and it is fixed. thanks! > Check the ruvs for all suffixes on all servers. > Try cleaning the RUV, if IPA command does not work do it > by ldapmodify > > There have been many discussions on this topic in this > mailing list, look for "cleanallruv", "haunted servers",.. > > Ludwig >> >> >>> >>> Similar issues happened last year, you can search the >>> archives for "unable to decode" but a 389-ds fix >>> improved the situation. So if you have older version >>> then maybe update and then manual cleanup of RUVs might >>> help. >>> >> >> >> > > -- > Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peljasz at yahoo.co.uk Sat Mar 4 14:47:32 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Sat, 4 Mar 2017 14:47:32 +0000 Subject: [Freeipa-users] slapi_ldap_bind - Error: could not send startTLS request Message-ID: hi everyone I've seemingly finely working domain, I mean it all seem fine to me, except for: [04/Mar/2017:14:26:47.439218725 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [04/Mar/2017:14:26:47.441155853 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [04/Mar/2017:14:31:47.454016982 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [04/Mar/2017:14:31:47.482477473 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [04/Mar/2017:14:36:46.458508994 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [04/Mar/2017:14:36:46.479878884 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [04/Mar/2017:14:41:47.389700728 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [04/Mar/2017:14:41:47.394379376 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) being logged quite frequently, as you can see. Setup: ipa-client-4.4.0-14.el7.centos.4.x86_64 ipa-client-common-4.4.0-14.el7.centos.4.noarch ipa-common-4.4.0-14.el7.centos.4.noarch ipa-python-compat-4.4.0-14.el7.centos.4.noarch ipa-server-4.4.0-14.el7.centos.4.x86_64 ipa-server-common-4.4.0-14.el7.centos.4.noarch ipa-server-dns-4.4.0-14.el7.centos.4.noarch Replication, users, logins, all seem normal. But above bothers me as I am afraid it may one day turn out critical and brake stuff down. This is on the first server that initiated the domain, long time ago. There is a second server which logs the same, but only a few entries then goes quiet. Third server's error log is completely free from this error. Would appreciate all help. L -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.dimri2016 at gmail.com Sat Mar 4 14:54:19 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Sat, 4 Mar 2017 20:24:19 +0530 Subject: [Freeipa-users] sudo su without password Message-ID: Hi All, In my IPA i have users authenticating using key + token and want to admin to switch to root without being prompted for the password. How can i do that in IPA? This is what i have tried - created a test user in IPA and did not give any password for this test user. I also have sudo rule configured to allow this user to switch to root. I have added !authenticate option in sudo rule. However when i login using my test user with private key +token and now when i am trying "sudo su" i am getting prompted for the password. Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.dimri2016 at gmail.com Sat Mar 4 14:56:15 2017 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Sat, 4 Mar 2017 20:26:15 +0530 Subject: [Freeipa-users] sudo su without password In-Reply-To: References: Message-ID: Never mind, i got this working after i added /usr/bin/sudo On Sat, Mar 4, 2017 at 8:24 PM, deepak dimri wrote: > Hi All, > > In my IPA i have users authenticating using key + token and want to admin > to switch to root without being prompted for the password. How can i do > that in IPA? > > This is what i have tried - created a test user in IPA and did not give > any password for this test user. I also have sudo rule configured to allow > this user to switch to root. I have added !authenticate option in sudo > rule. However when i login using my test user with private key +token and > now when i am trying "sudo su" i am getting prompted for the password. > > Thanks, > Deepak > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Sat Mar 4 16:22:26 2017 From: andrew.holway at gmail.com (Andrew Holway) Date: Sat, 4 Mar 2017 17:22:26 +0100 Subject: [Freeipa-users] Can kerberos SSSD provider be used against IPA In-Reply-To: References: Message-ID: Hi William, SSSD and FreeIPA have been developed in tandem by pretty much the same group from Redhat and are both part of the Fedora project (upstream RHEL). It's unsurprising that SUSE are not mentioning FreeIPA because it is a core component of RHEL marketed as IDM ( https://access.redhat.com/products/identity-management). SSSD can be used to authenticate against many providers. AD and IPA are just two examples. Cheers, Andrew (no I'm not affiliated with Redhat :) On 4 March 2017 at 01:10, William Muriithi wrote: > Hello, > > I just came across this document. > > https://www.susecon.com/doc/2015/sessions/TUT19343.pdf > > If you look at page 8, that diagram imply that kerberos provider can > only be used against active directory back end. > > > However, this Redhat article below recommended the solution above for > an IPA setup. See the third page from the bottom. > > http://people.redhat.com/steved/Summits/Summit13/Summit_Handout13.pdf > > Would anyone be able to comment about the inconsistency? Both articles > come from a reliable source, so not sure how to make of it. > > Regards, > William > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Sat Mar 4 18:33:57 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sat, 4 Mar 2017 19:33:57 +0100 Subject: [Freeipa-users] Can kerberos SSSD provider be used against IPA In-Reply-To: References: Message-ID: <20170304183357.7u3qacyfswahxa6f@hendrix> On Fri, Mar 03, 2017 at 07:10:40PM -0500, William Muriithi wrote: > Hello, > > I just came across this document. > > https://www.susecon.com/doc/2015/sessions/TUT19343.pdf > > If you look at page 8, that diagram imply that kerberos provider can > only be used against active directory back end. The AD and IPA authentication providers are more or less wrappers around the Kerberos provider with some extra options such as the support for enterprise principals. From tjaalton at ubuntu.com Sun Mar 5 10:47:36 2017 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Sun, 5 Mar 2017 12:47:36 +0200 Subject: [Freeipa-users] ipa-client-install generates bad sssd.conf In-Reply-To: <28160af8-032d-d2b6-e45d-08e6d01e3497@redhat.com> References: <94030dc8-6768-e826-38fa-a2e8265715ae@aixigo.de> <20170303083257.zkurhvg7ox4sufyu@hendrix> <20170303091446.md4myw33jcgbdpcg@hendrix> <28160af8-032d-d2b6-e45d-08e6d01e3497@redhat.com> Message-ID: <24226ff8-8302-c01f-1302-689c6b764535@ubuntu.com> On 03.03.2017 16:53, Rob Crittenden wrote: > Harald Dunkel wrote: >> On 03/03/17 10:14, Jakub Hrozek wrote: >>> On Fri, Mar 03, 2017 at 09:56:55AM +0100, Harald Dunkel wrote: >>>> >>>> This is systemd-only? >>>> >>>> Wouldn't it be better to create a working sssd.conf, no matter >>>> what? >>> >>> It is up to whoever is creating the sssd.conf. As I said, the change is >>> backwards-compatible. If you want the services to be started by sssd, >>> then list them in the services line. If you want to have them started on >>> demand and have a simpler configuration, you rely on the systemd services >>> manager. >>> >> >> Understood. I will try 1.15.1 as soon as possible. >> >> Reading ipa-client-install it appears to me that the other >> services haven't been omitted on purpose. I have the >> impression that nss and pam have simply been forgotten. >> >> sssd's ssh service is defined only if ipa-client-install >> is allowed to touch the ssh or sshd configuration, but I >> have *no* idea why there is such a correlation. >> >> Would somebody mind to look into this? > > This is managed by authconfig on Fedora/RHEL systems. Not sure what > Debian does in this regard. Timo? pam-auth-update configures pam, there's nothing else to be configured.. I just ran ipa-client-install on Ubuntu zesty with freeipa-client 4.4.3-3ubuntu1, and services on the newly created sssd.conf look fine: services = nss, sudo, pam, ssh -- t From william.muriithi at gmail.com Sun Mar 5 19:59:39 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Sun, 5 Mar 2017 14:59:39 -0500 Subject: [Freeipa-users] LDAP based autofs map redundancy Message-ID: Jakub, >> >> It does look though like kerberos is not affected as all systems can >> authenticate fine, so looks like its autofs issue alone >> >> This is the error I am noticing on the logs. >> >> Mar 2 14:18:29 platinum automount[2887]: key "brad" not found in map source(s). >> Mar 2 14:19:18 platinum automount[2887]: bind_ldap_simple: >> lookup(ldap): Unable to bind to the LDAP server: (default), error >> Can't contact LDAP server >> Mar 2 14:19:21 platinum automount[2887]: bind_ldap_simple: >> lookup(ldap): Unable to bind to the LDAP server: (default), error >> Can't contact LDAP server > > I guess /etc/nsswitch.conf uses ldap for automount and not sssd? > Actually no. We are using SSSD Just checked to confirm and looks like below: services: files sss netgroup: files sss publickey: nisplus automount: sss files aliases: files nisplus sudoers: files sss Regards, William *********************************** From jhrozek at redhat.com Sun Mar 5 20:53:41 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 5 Mar 2017 21:53:41 +0100 Subject: [Freeipa-users] LDAP based autofs map redundancy In-Reply-To: References: Message-ID: <20170305205341.pdqn22x47ffmvixj@hendrix> On Sun, Mar 05, 2017 at 02:59:39PM -0500, William Muriithi wrote: > Jakub, > > >> > >> It does look though like kerberos is not affected as all systems can > >> authenticate fine, so looks like its autofs issue alone > >> > >> This is the error I am noticing on the logs. > >> > >> Mar 2 14:18:29 platinum automount[2887]: key "brad" not found in map source(s). > >> Mar 2 14:19:18 platinum automount[2887]: bind_ldap_simple: > >> lookup(ldap): Unable to bind to the LDAP server: (default), error > >> Can't contact LDAP server > >> Mar 2 14:19:21 platinum automount[2887]: bind_ldap_simple: > >> lookup(ldap): Unable to bind to the LDAP server: (default), error > >> Can't contact LDAP server > > > > I guess /etc/nsswitch.conf uses ldap for automount and not sssd? > > > Actually no. We are using SSSD > > Just checked to confirm and looks like below: > > services: files sss > netgroup: files sss > publickey: nisplus > automount: sss files > aliases: files nisplus > sudoers: files sss Then I suspect automounter used to use the ldap module and then was not restarted after nsswitch.conf was set to include sss. Because the error messages like include error messages directly from libldap and I wouldn't expect to see those with sssd.. From dkupka at redhat.com Mon Mar 6 07:39:01 2017 From: dkupka at redhat.com (David Kupka) Date: Mon, 6 Mar 2017 08:39:01 +0100 Subject: [Freeipa-users] Freeipa 4.4 creating users with expiration In-Reply-To: References: Message-ID: <20170306073900.GB10339@dkupka.usersys.redhat.com> On Fri, Mar 03, 2017 at 08:44:45PM +0530, Rakesh Rajasekharan wrote: > Hello, > > Am using Freeipa 4.4 version . > > I would like to create few users only valid for few days or months. So,is > there a way to create few users with a preset expiration or auto lock those > accounts after a few days > > Thanks > Rakesh > -- > 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 Hello Rhakesh, AFAIK there's no mechanism to Lock the user account after period of time or at specified time. You need to call "ipa user-disable LOGIN" manually. You can file ticket and describe your use-case here: https://pagure.io/freeipa/new_issue -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From abokovoy at redhat.com Mon Mar 6 08:02:29 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 6 Mar 2017 10:02:29 +0200 Subject: [Freeipa-users] Freeipa 4.4 creating users with expiration In-Reply-To: <20170306073900.GB10339@dkupka.usersys.redhat.com> References: <20170306073900.GB10339@dkupka.usersys.redhat.com> Message-ID: <20170306080229.5dheabomi6bsiedc@redhat.com> On ma, 06 maalis 2017, David Kupka wrote: >On Fri, Mar 03, 2017 at 08:44:45PM +0530, Rakesh Rajasekharan wrote: >> Hello, >> >> Am using Freeipa 4.4 version . >> >> I would like to create few users only valid for few days or months. So,is >> there a way to create few users with a preset expiration or auto lock those >> accounts after a few days > >Hello Rhakesh, >AFAIK there's no mechanism to Lock the user account after period of time or at >specified time. You need to call "ipa user-disable LOGIN" manually. Actually, no. You can use krbPrincipalExpiration attribute to force account to expire. Once it is expired, both Kerberos and LDAP password bind will refuse it operating. Use --principal-expiration=DATETIME to 'ipa user-mod'. -- / Alexander Bokovoy From tkrizek at redhat.com Mon Mar 6 09:20:33 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Mon, 6 Mar 2017 10:20:33 +0100 Subject: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening In-Reply-To: References: <35945c0c-e1e2-3d34-cde3-2eeae5408a15@redhat.com> <92f941ef-142e-1084-ecfd-66a715abc587@redhat.com> Message-ID: <99c69b0d-d500-2484-6899-0c07287cbc0a@redhat.com> On 03/04/2017 12:51 AM, Chris Herdt wrote: > On Fri, Mar 3, 2017 at 4:22 AM, Tomas Krizek wrote: >> >> On 03/02/2017 06:25 PM, Chris Herdt wrote: >> >> On Thu, Mar 2, 2017 at 10:06 AM, Martin Basti wrote: >>> >>> >>> >>> On 02.03.2017 16:55, Chris Herdt wrote: >>> >>> >>> >>> On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti wrote: >>>> >>>> >>>> On 02.03.2017 01:07, Chris Herdt wrote: >>>> >>>> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a FreeIPA 3.0.0 master on CentOS 6.8 following the steps at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html >>>> >>>> At this step: >>>> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir /var/lib/ipa/replica-info-replicaname.example.com.gpg >>>> >>>> I get the error: >>>> ERROR cannot connect to 'ldaps://master.example.com' >>>> >>>> I ran ipa-replica-conncheck and found that port 636 is not accessible: >>>> Port check failed! Inaccessible port(s): 636 (TCP) >>>> >>>> The port is not blocked. I'm wondering where in the configuration for FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there is a way I can specify to use port 389 for setting up the replica. >>>> >>>> Thanks! >>>> >>>> -- >>>> Chris Herdt >>>> Systems Administrator >>>> >>>> >>>> >>>> Hello, >>>> this is known issue only in FreeIPA 4.4.x, this will be fixed in next minor update which should be released soon to RHEL7.3 (I don't know how fast it will be in Centos) >>>> >>>> so you can wait, or enable it manually (not nice) >>>> >>>> sorry for troubles >>>> Martin >>> >>> >>> Thanks for the reply! Before attempting this in my production environment, I had set up a similar configuration in a test environment (FreeIPA 3.0.0 master on CentOS 6.8, FreeIPA 4.4.0 replica on CentOS 7.3) and the ipa-replica-install went fine. I assumed this was an issue with my FreeIPA 3.0.0 production server. >>> >>> To enable the fix manually, I'm assuming I'd need to install FreeIPA from source on the intended replica? If I download the 4.4.3 release from https://pagure.io/freeipa/releases, will that be sufficient? >>> >>> Sorry, >>> I probably misread what you wrote, I thought that port is closed on replica, but now I see that port is closed on 3.3.0 master, so this is something different. I'm not aware of any issue on 3.3.0 that should cause this. >>> >>> Could you check your configuration on 3.3.0 master? Is port opened on master? Do you have any errors in /var/log/dirsrv/slapd-*/errors log on master? >>> >>> Martin >> >> When I compare the errors file on my production environment and my test environment, I do note that the LDAPS entry is missing from my production environment: >> >> production: >> [01/Mar/2017:17:30:07 -0600] - slapd started. Listening on All Interfaces port 389 for LDAP requests >> [01/Mar/2017:17:30:07 -0600] - Listening on /var/run/slapd-PROD-EXAMPLE-COM.socket for LDAPI requests >> >> test: >> [28/Feb/2017:13:37:50 -0600] - slapd started. Listening on All Interfaces port 389 for LDAP requests >> [28/Feb/2017:13:37:50 -0600] - Listening on All Interfaces port 636 for LDAPS requests >> [28/Feb/2017:13:37:50 -0600] - Listening on /var/run/slapd-TEST-EXAMPLE-COM.socket for LDAPI requests >> >> I'm not sure why it is missing though. Which config file(s) should I be checking? >> >> You can examine the file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif to check if the Directory Server has LDAP configured correctly. In particular, you're interested in: >> >> - nsslapd-security in cn=config >> - cn=encryption,cn=config >> - cn=RSA,cn=encryption,cn=config >> >> Also, you can check if the certificate for LDAPS is available in the NSS database: >> >> certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L > nsslapd-security was set to off. I set it to on, but SSL failed. > > There were no certificates listed--which I think explains why SSL > failed--when running: > certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L > > ipa-getcert list shows several certs, including one with > location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS > Certificate DB' -- I'm not sure where this cert exists though. > > I assume I need to get the NSS db to recognize the Server-Cert, for example: > certutil -A -d /etc/dirsrv/slapd-EXAMPLE-COM -i ? You need a certificate and some Directory Server configuration. The DocText for #1365858 [1] describes how to turn on LDAPS manually. Please beware, that this process was tested on IPA 4.4 and it might be a bit different for older versions. [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1365858 P.S.: Sorry for sending the message twice, Chris. I forgot to keep the list in reply. -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From iulian.roman at gmail.com Mon Mar 6 09:59:12 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Mon, 6 Mar 2017 10:59:12 +0100 Subject: [Freeipa-users] pam_hbac for aix Message-ID: Hello, Does anyone know what is the status with the support for AIX in the pam_hbac tool ? I've heard from a RH presentation that it is available, although on the project site it does not seem to be supported yet. I would like to know if there are any plans in that direction , because our migrations of thousands of AIX machines to IPA is conditioned by the availability of pam_hbac. The HBAC rules/policy design depends as well on the method you use to parse the rules. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peljasz at yahoo.co.uk Mon Mar 6 10:38:14 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Mon, 6 Mar 2017 10:38:14 +0000 Subject: [Freeipa-users] slapi_ldap_bind - Error: could not send startTLS request In-Reply-To: References: Message-ID: <27184523-9069-5816-45d8-f22690efbde0@yahoo.co.uk> On 04/03/17 14:47, lejeczek wrote: > hi everyone > I've seemingly finely working domain, I mean it all seem > fine to me, except for: > > [04/Mar/2017:14:26:47.439218725 +0000] slapi_ldap_bind - > Error: could not send startTLS request: error -1 (Can't > contact LDAP server) errno 107 (Transport endpoint is not > connected) > [04/Mar/2017:14:26:47.441155853 +0000] slapi_ldap_bind - > Error: could not send startTLS request: error -1 (Can't > contact LDAP server) errno 107 (Transport endpoint is not > connected) > [04/Mar/2017:14:31:47.454016982 +0000] slapi_ldap_bind - > Error: could not send startTLS request: error -1 (Can't > contact LDAP server) errno 107 (Transport endpoint is not > connected) > [04/Mar/2017:14:31:47.482477473 +0000] slapi_ldap_bind - > Error: could not send startTLS request: error -1 (Can't > contact LDAP server) errno 107 (Transport endpoint is not > connected) > [04/Mar/2017:14:36:46.458508994 +0000] slapi_ldap_bind - > Error: could not send startTLS request: error -1 (Can't > contact LDAP server) errno 107 (Transport endpoint is not > connected) > [04/Mar/2017:14:36:46.479878884 +0000] slapi_ldap_bind - > Error: could not send startTLS request: error -1 (Can't > contact LDAP server) errno 107 (Transport endpoint is not > connected) > [04/Mar/2017:14:41:47.389700728 +0000] slapi_ldap_bind - > Error: could not send startTLS request: error -1 (Can't > contact LDAP server) errno 107 (Transport endpoint is not > connected) > [04/Mar/2017:14:41:47.394379376 +0000] slapi_ldap_bind - > Error: could not send startTLS request: error -1 (Can't > contact LDAP server) errno 107 (Transport endpoint is not > connected) > > being logged quite frequently, as you can see. Setup: > > ipa-client-4.4.0-14.el7.centos.4.x86_64 > ipa-client-common-4.4.0-14.el7.centos.4.noarch > ipa-common-4.4.0-14.el7.centos.4.noarch > ipa-python-compat-4.4.0-14.el7.centos.4.noarch > ipa-server-4.4.0-14.el7.centos.4.x86_64 > ipa-server-common-4.4.0-14.el7.centos.4.noarch > ipa-server-dns-4.4.0-14.el7.centos.4.noarch > > Replication, users, logins, all seem normal. But above > bothers me as I am afraid it may one day turn out critical > and brake stuff down. > This is on the first server that initiated the domain, > long time ago. > There is a second server which logs the same, but only a > few entries then goes quiet. > Third server's error log is completely free from this error. > > Would appreciate all help. > L As I was afraid... more. I'm adding a replica, with arguments: --setup-dns --no-forwarders . This seems to have succeeded: ... Configured /etc/ssh/sshd_config Configuring private.ccnr.ceb.private.cam.ac.uk as NIS domain. Client configuration complete. but on the master(fist server in the domain) during replica installation I see: [06/Mar/2017:09:56:01.022636856 +0000] NSMMReplicationPlugin - agmt="cn=meToswir.priv.xx.xx.priv.xx.xx.x. (swir:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. [06/Mar/2017:09:56:01.900679757 +0000] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=meToswir.priv.xx.xx.priv.xx.xx.x. (swir:389)". [06/Mar/2017:09:56:05.287761359 +0000] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=meToswir.priv.xx.xx.priv.xx.xx.x. (swir:389)". Sent 799 entries. [06/Mar/2017:09:56:15.293584156 +0000] NSMMReplicationPlugin - agmt="cn=meToswir.priv.xx.xx.priv.xx.xx.x. (swir:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contxx. LDAP server). Will retry later. [06/Mar/2017:09:56:19.220334467 +0000] NSMMReplicationPlugin - agmt="cn=meToswir.priv.xx.xx.priv.xx.xx.x. (swir:389): Replication bind with SIMPLE auth resumed [06/Mar/2017:09:56:24.523570143 +0000] NSMMReplicationPlugin - agmt="cn=meToswir.priv.xx.xx.priv.xx.xx.x. (swir:389): Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) () [06/Mar/2017:09:56:46.295504003 +0000] NSMMReplicationPlugin - agmt="cn=meToswir.priv.xx.xx.priv.xx.xx.x. (swir:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contxx. LDAP server) () ... [06/Mar/2017:09:57:57.620175772 +0000] NSMMReplicationPlugin - agmt="cn=meToswir.priv.xx.xx.priv.xx.xx.x. (swir:389): Replication bind with GSSAPI auth resumed [06/Mar/2017:10:01:46.442346796 +0000] slapi_ldap_bind - Error: could not bind id [cn=Replication Manager cloneAgreement1-swir.priv.xx.xx.priv.xx.xx.x.pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) [06/Mar/2017:10:01:46.452580492 +0000] NSMMReplicationPlugin - agmt="cn=masterAgreement1-swir.priv.xx.xx.priv.xx.xx.x.pki-tomcat" (swir:389): Replication bind with SIMPLE auth failed: LDAP error 32 (No such object) () [06/Mar/2017:10:01:46.454557885 +0000] slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-rider.priv.xx.xx.priv.xx.xx.x.pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) [06/Mar/2017:10:01:46.456463238 +0000] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-rider.priv.xx.xx.priv.xx.xx.x.pki-tomcat" (swir:389): Replication bind with SIMPLE auth failed: LDAP error 32 (No such object) () Configured /etc/ssh/sshd_config Configuring priv.xx.xx.priv.xx.xx.x.as NIS domain. [06/Mar/2017:10:06:46.708910487 +0000] slapi_ldap_bind - Error: could not bind id [cn=Replication Manager cloneAgreement1-swir.priv.xx.xx.priv.xx.xx.x.pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) and on the other(third replica server): ... [06/Mar/2017:09:59:32.505421711 +0000] slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-dzien.priv.xx.xx.priv.xx.xx.x.pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) [06/Mar/2017:09:59:32.511853210 +0000] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-dzien.priv.xx.xx.priv.xx.xx.x.pki-tomcat" (swir:389): Replication bind with SIMPLE auth failed: LDAP error 32 (No such object) () [06/Mar/2017:10:04:31.881879230 +0000] slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-dzien.priv.xx.xx.priv.xx.xx.x.pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) [06/Mar/2017:10:09:31.775183433 +0000] slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-dzien.priv.xx.xx.priv.xx.xx.x.pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) ... ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Mar 6 11:20:05 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 6 Mar 2017 12:20:05 +0100 Subject: [Freeipa-users] pam_hbac for aix In-Reply-To: References: Message-ID: <20170306112005.jcuadnmjrzdehmq4@hendrix> On Mon, Mar 06, 2017 at 10:59:12AM +0100, Iulian Roman wrote: > Hello, > > Does anyone know what is the status with the support for AIX in the > pam_hbac tool ? I've heard from a RH presentation that it is available, > although on the project site it does not seem to be supported yet. > > I would like to know if there are any plans in that direction , because > our migrations of thousands of AIX machines to IPA is conditioned by the > availability of pam_hbac. The HBAC rules/policy design depends as well on > the method you use to parse the rules. It's in progress, but delayed due to the current work we are doing for RHEL-7.4. I've merged HP-UX support a couple of weeks ago and AIX support is next on the list. If you'd like to help with the port, any help is appreciated :-) From iulian.roman at gmail.com Mon Mar 6 11:36:20 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Mon, 6 Mar 2017 12:36:20 +0100 Subject: [Freeipa-users] pam_hbac for aix In-Reply-To: <20170306112005.jcuadnmjrzdehmq4@hendrix> References: <20170306112005.jcuadnmjrzdehmq4@hendrix> Message-ID: On Mon, Mar 6, 2017 at 12:20 PM, Jakub Hrozek wrote: > On Mon, Mar 06, 2017 at 10:59:12AM +0100, Iulian Roman wrote: > > Hello, > > > > Does anyone know what is the status with the support for AIX in the > > pam_hbac tool ? I've heard from a RH presentation that it is available, > > although on the project site it does not seem to be supported yet. > > > > I would like to know if there are any plans in that direction , because > > our migrations of thousands of AIX machines to IPA is conditioned by the > > availability of pam_hbac. The HBAC rules/policy design depends as well > on > > the method you use to parse the rules. > > It's in progress, but delayed due to the current work we are doing for > RHEL-7.4. I've merged HP-UX support a couple of weeks ago and AIX > support is next on the list. > > Any chance we can prioritize that by creating an RFE ? We have quite a big environment and it would simplify a lot the access control if we can make use of pam_hbac. > If you'd like to help with the port, any help is appreciated :-) > > I am willing to , at least with testing it on different OS versions. If there is anything else i can do , please let me know. > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Mar 6 13:04:24 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 6 Mar 2017 14:04:24 +0100 Subject: [Freeipa-users] pam_hbac for aix In-Reply-To: References: <20170306112005.jcuadnmjrzdehmq4@hendrix> Message-ID: <20170306130424.byoy7lsbd7mliasi@hendrix> On Mon, Mar 06, 2017 at 12:36:20PM +0100, Iulian Roman wrote: > On Mon, Mar 6, 2017 at 12:20 PM, Jakub Hrozek wrote: > > > On Mon, Mar 06, 2017 at 10:59:12AM +0100, Iulian Roman wrote: > > > Hello, > > > > > > Does anyone know what is the status with the support for AIX in the > > > pam_hbac tool ? I've heard from a RH presentation that it is available, > > > although on the project site it does not seem to be supported yet. > > > > > > I would like to know if there are any plans in that direction , because > > > our migrations of thousands of AIX machines to IPA is conditioned by the > > > availability of pam_hbac. The HBAC rules/policy design depends as well > > on > > > the method you use to parse the rules. > > > > It's in progress, but delayed due to the current work we are doing for > > RHEL-7.4. I've merged HP-UX support a couple of weeks ago and AIX > > support is next on the list. > > > > Any chance we can prioritize that by creating an RFE ? We have quite a > big environment and it would simplify a lot the access control if we can > make use of pam_hbac. We already have: https://github.com/jhrozek/pam_hbac/issues/74 > > > If you'd like to help with the port, any help is appreciated :-) > > > > I am willing to , at least with testing it on different OS versions. If > there is anything else i can do , please let me know. Testing patches when there are would be nice. You can subscribe to the github issue to receive updates. From mexigabacho at gmail.com Mon Mar 6 19:37:11 2017 From: mexigabacho at gmail.com (Christopher Young) Date: Mon, 6 Mar 2017 14:37:11 -0500 Subject: [Freeipa-users] Replication Issues Message-ID: I've seen similar posts, but in the interest of asking fresh and trying to understand what is going on, I thought I would ask for advice on how best to handle this situation. In the interest of providing some history: I have three (3) FreeIPA servers. Everything is running 4.4.0 now. The originals (orldc-prod-ipa01, orldc-prod-ipa02) were upgraded from the 3.x branch quite a while back. Everything had been working fine, however I ran into a replication issue (that I _think_ may have been a result of IPv6 being disabled by my default Ansible roles). I thought I had resolved that by reinitializing the 2nd replica, orldc-prod-ipa02. In any case, I feel like the replication has never been fully stable since then, and I have all types of errors in messages that indicate something is off. I had single introduced a 3rd replica such that the agreements would look like so: orldc-prod-ipa01 -> orldc-prod-ipa02 ---> bohdc-prod-ipa01 It feels like orldc-prod-ipa02 & bohdc-prod-ipa01 are out of sync. I've tried reinitializing them in order but with no positive results. At this point, I feel like I'm ready to 'bite the bullet' and tear them down quickly (remove them from IPA, delete the local DBs/directories) and rebuild them from scratch. I want to minimize my impact as much as possible (which I can somewhat do by redirecting LDAP/DNS request via my load-balancers temporarily) and do this right. (Getting to the point...) I'd like advice on the order of operations to do this. Give the errors (I'll include samples at the bottom of this message), does it make sense for me to remove the replicas on bohdc-prod-ipa01 & orldc-prod-ipa02 (in that order), wipe out any directories/residual pieces (I'd need some idea of what to do there), and then create new replicas? -OR- Should I export/backup the LDAP DB and rebuild everything from scratch. I need advice and ideas. Furthermore, if there is someone with experience in this that would be interested in making a little money on the side, let me know, because having an extra brain and set of hands would be welcome. DETAILS: ================= ERRORS I see on orldc-prod-ipa01 (the one whose LDAP DB seems the most up-to-date since my changes are usually directed at it): ------ Mar 6 14:36:24 orldc-prod-ipa01 ns-slapd: [06/Mar/2017:14:36:24.434956575 -0500] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa02:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO LDAP bind... Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO Commencing sync process Mar 6 14:36:26 orldc-prod-ipa01 ipa-dnskeysyncd: ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BIND Mar 6 14:36:27 orldc-prod-ipa01 ns-slapd: [06/Mar/2017:14:36:27.799519203 -0500] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa02:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 6 14:36:30 orldc-prod-ipa01 ns-slapd: [06/Mar/2017:14:36:30.994760069 -0500] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa02:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 6 14:36:34 orldc-prod-ipa01 ns-slapd: [06/Mar/2017:14:36:34.940115481 -0500] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa02:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of '56.10.in-addr.arpa/IN': AXFR-style IXFR started Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of '56.10.in-addr.arpa/IN': AXFR-style IXFR ended Mar 6 14:36:37 orldc-prod-ipa01 ns-slapd: [06/Mar/2017:14:36:37.977875463 -0500] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa02:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 6 14:36:40 orldc-prod-ipa01 ns-slapd: [06/Mar/2017:14:36:40.999275184 -0500] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa02:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 6 14:36:45 orldc-prod-ipa01 ns-slapd: [06/Mar/2017:14:36:45.211260414 -0500] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa02:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. ------ Errors on orldc-prod-ipa02: ------ r 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: ipa : INFO Commencing sync process Mar 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BIND Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:05.934405274 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:05.937278142 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:05.939434025 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:06.882795654 -0500] agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:06.886029272 -0500] NSMMReplicationPlugin - changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't as up to date, or we purged Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:06.888679268 -0500] NSMMReplicationPlugin - agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): Data required to update replica has been purged from the changelog. The replica must be reinitialized. Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:06.960804253 -0500] NSMMReplicationPlugin - agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa01:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:08.960622608 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:08.968927168 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:08.976952118 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:09 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:09.972315877 -0500] NSMMReplicationPlugin - agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa01:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:10.034810948 -0500] agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:10.040020359 -0500] NSMMReplicationPlugin - changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't as up to date, or we purged Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:10.042846879 -0500] NSMMReplicationPlugin - agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): Data required to update replica has been purged from the changelog. The replica must be reinitialized. Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:13.013253769 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:13.021514225 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:13.027521508 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:13.110566247 -0500] NSMMReplicationPlugin - agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa01:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:14.179819300 -0500] agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:14.188353328 -0500] NSMMReplicationPlugin - changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't as up to date, or we purged Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:14.196463928 -0500] NSMMReplicationPlugin - agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): Data required to update replica has been purged from the changelog. The replica must be reinitialized. Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:17.068292919 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:17.071241757 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: [06/Mar/2017:14:16:17.073793922 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. ------ Thanks in advance!!! -- Chris From rcritten at redhat.com Mon Mar 6 20:11:11 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 6 Mar 2017 15:11:11 -0500 Subject: [Freeipa-users] slapi_ldap_bind - Error: could not send startTLS request In-Reply-To: References: Message-ID: <2a5e833a-5c7d-3385-bf17-620cd42aa805@redhat.com> lejeczek wrote: > hi everyone > I've seemingly finely working domain, I mean it all seem fine to me, > except for: > > [04/Mar/2017:14:26:47.439218725 +0000] slapi_ldap_bind - Error: could > not send startTLS request: error -1 (Can't contact LDAP server) errno > 107 (Transport endpoint is not connected) > [04/Mar/2017:14:26:47.441155853 +0000] slapi_ldap_bind - Error: could > not send startTLS request: error -1 (Can't contact LDAP server) errno > 107 (Transport endpoint is not connected) > [04/Mar/2017:14:31:47.454016982 +0000] slapi_ldap_bind - Error: could > not send startTLS request: error -1 (Can't contact LDAP server) errno > 107 (Transport endpoint is not connected) > [04/Mar/2017:14:31:47.482477473 +0000] slapi_ldap_bind - Error: could > not send startTLS request: error -1 (Can't contact LDAP server) errno > 107 (Transport endpoint is not connected) > [04/Mar/2017:14:36:46.458508994 +0000] slapi_ldap_bind - Error: could > not send startTLS request: error -1 (Can't contact LDAP server) errno > 107 (Transport endpoint is not connected) > [04/Mar/2017:14:36:46.479878884 +0000] slapi_ldap_bind - Error: could > not send startTLS request: error -1 (Can't contact LDAP server) errno > 107 (Transport endpoint is not connected) > [04/Mar/2017:14:41:47.389700728 +0000] slapi_ldap_bind - Error: could > not send startTLS request: error -1 (Can't contact LDAP server) errno > 107 (Transport endpoint is not connected) > [04/Mar/2017:14:41:47.394379376 +0000] slapi_ldap_bind - Error: could > not send startTLS request: error -1 (Can't contact LDAP server) errno > 107 (Transport endpoint is not connected) > > being logged quite frequently, as you can see. Setup: > > ipa-client-4.4.0-14.el7.centos.4.x86_64 > ipa-client-common-4.4.0-14.el7.centos.4.noarch > ipa-common-4.4.0-14.el7.centos.4.noarch > ipa-python-compat-4.4.0-14.el7.centos.4.noarch > ipa-server-4.4.0-14.el7.centos.4.x86_64 > ipa-server-common-4.4.0-14.el7.centos.4.noarch > ipa-server-dns-4.4.0-14.el7.centos.4.noarch > > Replication, users, logins, all seem normal. But above bothers me as I > am afraid it may one day turn out critical and brake stuff down. > This is on the first server that initiated the domain, long time ago. > There is a second server which logs the same, but only a few entries > then goes quiet. > Third server's error log is completely free from this error. > > Would appreciate all help. The CA replication agreements are handled by ipa-csreplica-manage. You may have leftover agreements from previous installs there. rob From barrykfl at gmail.com Tue Mar 7 03:14:37 2017 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Tue, 7 Mar 2017 11:14:37 +0800 Subject: [Freeipa-users] Make Gpg replica fail , where cert store I should update new ? Message-ID: gpg Creating SSL certificate for the Directory Server ipa : ERROR cert validation failed for "CN=central.ABC.com,O= ABC.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.) preparation of replica failed: cannot connect to ' https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. cannot connect to ' https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. File "/usr/sbin/ipa-replica-prepare", line 490, in main() File "/usr/sbin/ipa-replica-prepare", line 361, in main export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", replica_fqdn, subject_base) File "/usr/sbin/ipa-replica-prepare", line 150, in export_certdb raise e -------------- next part -------------- An HTML attachment was scrubbed... URL: From barrykfl at gmail.com Tue Mar 7 03:35:01 2017 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Tue, 7 Mar 2017 11:35:01 +0800 Subject: [Freeipa-users] make a new server and migrate old data Message-ID: Hi: I have freeipa 3.0 server ...and want to make a new server ignore any cert related. eg I clean install a server using default free ipa server cert ..and copy dirsrv data to new. can I just copy /etc/dirsrv scheme..username /passwords and groups ? Also if I copy these to 4.0 server any issue? Regards barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From techpkiuser at gmail.com Tue Mar 7 07:08:11 2017 From: techpkiuser at gmail.com (Kaamel Periora) Date: Tue, 7 Mar 2017 12:38:11 +0530 Subject: [Freeipa-users] Padding Scheme used in Fedora Dogtag Message-ID: Dear All, It is required to identify the padding scheme used by the Fedora dogtag system. Appreciate of someone could shed some light on this requirement. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Tue Mar 7 09:16:59 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 7 Mar 2017 10:16:59 +0100 Subject: [Freeipa-users] Make Gpg replica fail , where cert store I should update new ? In-Reply-To: References: Message-ID: <8450f24d-91d7-175c-0bfd-39e0e47c3ddf@redhat.com> Hi, In IPA < 4.5, ipa-replica-prepare was using /etc/ipa/ca.crt as Certificate Authority, and this file may be outdated. Running ipa-certupdate may fix your issue. See [1] If it doesn't, you can start by identifying which certificate expired with $ sudo getcert list | egrep -e 'expires|Request ID|subject' HTH, Flo [1] https://pagure.io/freeipa/issue/6375 On 03/07/2017 04:14 AM, barrykfl at gmail.com wrote: > gpg > > Creating SSL certificate for the Directory Server > ipa : ERROR cert validation failed for "CN=central.ABC.com > ,O=ABC.COM " > ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.) > preparation of replica failed: cannot connect to > 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. > cannot connect to > 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. > File "/usr/sbin/ipa-replica-prepare", line 490, in > main() > > File "/usr/sbin/ipa-replica-prepare", line 361, in main > export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", > replica_fqdn, subject_base) > > File "/usr/sbin/ipa-replica-prepare", line 150, in export_certdb > raise e > > > From peljasz at yahoo.co.uk Tue Mar 7 09:55:52 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 7 Mar 2017 09:55:52 +0000 Subject: [Freeipa-users] consumer replica which does not show up in ruv list Message-ID: <8346bc89-6c4d-c33a-0793-0b26ae30b56c@yahoo.co.uk> hi, I presume I need to use ldapmodify/delete? I found this(obfuscated by me): cn=dzien.priv.xx.xx.priv.xx.xx.x+nsuniqueid=9e47680e-296e11e6-83a59f45-6ec26a1e,cn=masters,cn=ipa,cn=etc,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x To confirm? Would removing it fix the problem? I'm probably missing something else, aren't I? many thank, L -------------- next part -------------- An HTML attachment was scrubbed... URL: From kliu at alumni.warwick.ac.uk Tue Mar 7 11:24:33 2017 From: kliu at alumni.warwick.ac.uk (Barry) Date: Tue, 7 Mar 2017 19:24:33 +0800 Subject: [Freeipa-users] Make Gpg replica fail , where cert store I should update new ? In-Reply-To: <8450f24d-91d7-175c-0bfd-39e0e47c3ddf@redhat.com> References: <8450f24d-91d7-175c-0bfd-39e0e47c3ddf@redhat.com> Message-ID: Same as before I already follow part < 4.1 as below: https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 comdo cert is new cert / It seem I m nearly right ....HTTP server side can read trust cert BUT seem dirsrv still lacking of a ca cert to verify it ./.. but ca.crt changed to new already and imported ABC-COM...[07/Mar/2017:19:17:22 +0800] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert *.ABC.com - COMODO CA Limited of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8179 - Peer's Certificate issuer is not recognized.) 2017-03-07 17:16 GMT+08:00 Florence Blanc-Renaud : > Hi, > > In IPA < 4.5, ipa-replica-prepare was using /etc/ipa/ca.crt as Certificate > Authority, and this file may be outdated. Running ipa-certupdate may fix > your issue. See [1] > > If it doesn't, you can start by identifying which certificate expired with > $ sudo getcert list | egrep -e 'expires|Request ID|subject' > > HTH, > Flo > > [1] https://pagure.io/freeipa/issue/6375 > > On 03/07/2017 04:14 AM, barrykfl at gmail.com wrote: > >> gpg >> >> Creating SSL certificate for the Directory Server >> ipa : ERROR cert validation failed for "CN=central.ABC.com >> ,O=ABC.COM " >> ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.) >> preparation of replica failed: cannot connect to >> 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': >> (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. >> cannot connect to >> 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': >> (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. >> File "/usr/sbin/ipa-replica-prepare", line 490, in >> main() >> >> File "/usr/sbin/ipa-replica-prepare", line 361, in main >> export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", >> replica_fqdn, subject_base) >> >> File "/usr/sbin/ipa-replica-prepare", line 150, in export_certdb >> raise e >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barrykfl at gmail.com Tue Mar 7 11:37:26 2017 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Tue, 7 Mar 2017 19:37:26 +0800 Subject: [Freeipa-users] Make Gpg replica fail , where cert store I should update new ? In-Reply-To: References: <8450f24d-91d7-175c-0bfd-39e0e47c3ddf@redhat.com> Message-ID: same as as replica gpg making.////...Found this cert 2015 expired only,,? but I follow manual here: https://www.freeipa.org/page/Using_3rd_part_certificates_ for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 It imported as EXT-CA as Alias rather than sever cert by default...Is there anywhere pointing wrong ? Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI *.ABC.com ,, EXT-CA CT,C,C ABC.COM IPA CA CT,,C Server-Cert u,u,u Request ID '20160516111257': status: CA_UNREACHABLE ca-error: Server at https://central.ABC.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to ' https://central.ABC.com:443/ca/agent/ca/displayBySerial': (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not recognized.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=ABC.COM subject: CN=central.ABC.com,O=ABC.COM expires: 2015-11-23 08:42:52 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA track: yes auto-renew: yes 2017-03-07 19:24 GMT+08:00 Barry : > Same as before I already follow part < 4.1 as below: > > https://www.freeipa.org/page/Using_3rd_part_certificates_ > for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 > comdo cert is new cert / > It seem I m nearly right ....HTTP server side can read trust cert > BUT seem dirsrv still lacking of a ca cert to verify it ./.. > but ca.crt changed to new already and imported > > ABC-COM...[07/Mar/2017:19:17:22 +0800] - SSL alert: > CERT_VerifyCertificateNow: verify certificate failed for cert *.ABC.com - > COMODO CA Limited of family cn=RSA,cn=encryption,cn=config (Netscape > Portable Runtime error -8179 - Peer's Certificate issuer is not recognized.) > > > 2017-03-07 17:16 GMT+08:00 Florence Blanc-Renaud : > >> Hi, >> >> In IPA < 4.5, ipa-replica-prepare was using /etc/ipa/ca.crt as >> Certificate Authority, and this file may be outdated. Running >> ipa-certupdate may fix your issue. See [1] >> >> If it doesn't, you can start by identifying which certificate expired with >> $ sudo getcert list | egrep -e 'expires|Request ID|subject' >> >> HTH, >> Flo >> >> [1] https://pagure.io/freeipa/issue/6375 >> >> On 03/07/2017 04:14 AM, barrykfl at gmail.com wrote: >> >>> gpg >>> >>> Creating SSL certificate for the Directory Server >>> ipa : ERROR cert validation failed for "CN=central.ABC.com >>> ,O=ABC.COM " >>> ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.) >>> preparation of replica failed: cannot connect to >>> 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': >>> (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. >>> cannot connect to >>> 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': >>> (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. >>> File "/usr/sbin/ipa-replica-prepare", line 490, in >>> main() >>> >>> File "/usr/sbin/ipa-replica-prepare", line 361, in main >>> export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", >>> replica_fqdn, subject_base) >>> >>> File "/usr/sbin/ipa-replica-prepare", line 150, in export_certdb >>> raise e >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Mar 7 12:39:25 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 7 Mar 2017 13:39:25 +0100 Subject: [Freeipa-users] consumer replica which does not show up in ruv list In-Reply-To: <8346bc89-6c4d-c33a-0793-0b26ae30b56c@yahoo.co.uk> References: <8346bc89-6c4d-c33a-0793-0b26ae30b56c@yahoo.co.uk> Message-ID: <20170307123924.GA26633@dhcp129-180.brq.redhat.com> On Tue, Mar 07, 2017 at 09:55:52AM +0000, lejeczek wrote: >hi, > >I presume I need to use ldapmodify/delete? >I found this(obfuscated by me): > >cn=dzien.priv.xx.xx.priv.xx.xx.x+nsuniqueid=9e47680e-296e11e6-83a59f45-6ec26a1e,cn=masters,cn=ipa,cn=etc,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > >To confirm? Would removing it fix the problem? I'm probably missing something >else, aren't I? > >many thank, >L >-- >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 That seems like a replication conflict. Consult the following guide to solve it: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html Just a side question, how did you end up with such entry? Did you happen to upgrade multiple IPA masters at once? -- Martin Babinsky From peljasz at yahoo.co.uk Tue Mar 7 13:32:18 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 7 Mar 2017 13:32:18 +0000 Subject: [Freeipa-users] consumer replica which does not show up in ruv list In-Reply-To: <20170307123924.GA26633@dhcp129-180.brq.redhat.com> References: <8346bc89-6c4d-c33a-0793-0b26ae30b56c@yahoo.co.uk> <20170307123924.GA26633@dhcp129-180.brq.redhat.com> Message-ID: <3baedd80-ce85-4c3b-77e0-adfadb8f4825@yahoo.co.uk> On 07/03/17 12:39, Martin Babinsky wrote: > On Tue, Mar 07, 2017 at 09:55:52AM +0000, lejeczek wrote: >> hi, >> >> I presume I need to use ldapmodify/delete? >> I found this(obfuscated by me): >> >> cn=dzien.priv.xx.xx.priv.xx.xx.x+nsuniqueid=9e47680e-296e11e6-83a59f45-6ec26a1e,cn=masters,cn=ipa,cn=etc,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> >> To confirm? Would removing it fix the problem? I'm probably missing something >> else, aren't I? >> >> many thank, >> L >> -- >> 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 > > That seems like a replication conflict. Consult the following guide to solve > it: > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > > Just a side question, how did you end up with such entry? Did you happen to upgrade > multiple IPA masters at once? > I fear I was doing too few things at the same time: adding / removing replicas and at around the same time upgrading ipa*. Everything last evening. Many thanks for the pointer, I'll read through. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mareynol at redhat.com Tue Mar 7 13:45:57 2017 From: mareynol at redhat.com (Mark Reynolds) Date: Tue, 7 Mar 2017 08:45:57 -0500 Subject: [Freeipa-users] Replication Issues In-Reply-To: References: Message-ID: What version of 389-ds-base are you using? rpm -qa | grep 389-ds-base comments below.. On 03/06/2017 02:37 PM, Christopher Young wrote: > I've seen similar posts, but in the interest of asking fresh and > trying to understand what is going on, I thought I would ask for > advice on how best to handle this situation. > > In the interest of providing some history: > I have three (3) FreeIPA servers. Everything is running 4.4.0 now. > The originals (orldc-prod-ipa01, orldc-prod-ipa02) were upgraded from > the 3.x branch quite a while back. Everything had been working fine, > however I ran into a replication issue (that I _think_ may have been a > result of IPv6 being disabled by my default Ansible roles). I thought > I had resolved that by reinitializing the 2nd replica, > orldc-prod-ipa02. > > In any case, I feel like the replication has never been fully stable > since then, and I have all types of errors in messages that indicate > something is off. I had single introduced a 3rd replica such that the > agreements would look like so: > > orldc-prod-ipa01 -> orldc-prod-ipa02 ---> bohdc-prod-ipa01 > > It feels like orldc-prod-ipa02 & bohdc-prod-ipa01 are out of sync. > I've tried reinitializing them in order but with no positive results. > At this point, I feel like I'm ready to 'bite the bullet' and tear > them down quickly (remove them from IPA, delete the local > DBs/directories) and rebuild them from scratch. > > I want to minimize my impact as much as possible (which I can somewhat > do by redirecting LDAP/DNS request via my load-balancers temporarily) > and do this right. > > (Getting to the point...) > > I'd like advice on the order of operations to do this. Give the > errors (I'll include samples at the bottom of this message), does it > make sense for me to remove the replicas on bohdc-prod-ipa01 & > orldc-prod-ipa02 (in that order), wipe out any directories/residual > pieces (I'd need some idea of what to do there), and then create new > replicas? -OR- Should I export/backup the LDAP DB and rebuild > everything from scratch. > > I need advice and ideas. Furthermore, if there is someone with > experience in this that would be interested in making a little money > on the side, let me know, because having an extra brain and set of > hands would be welcome. > > DETAILS: > ================= > > > ERRORS I see on orldc-prod-ipa01 (the one whose LDAP DB seems the most > up-to-date since my changes are usually directed at it): > ------ > Mar 6 14:36:24 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:24.434956575 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO > LDAP bind... > Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO > Commencing sync process > Mar 6 14:36:26 orldc-prod-ipa01 ipa-dnskeysyncd: > ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump > is done, sychronizing with ODS and BIND > Mar 6 14:36:27 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:27.799519203 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:30 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:30.994760069 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:34 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:34.940115481 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client > 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of > '56.10.in-addr.arpa/IN': AXFR-style IXFR started > Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client > 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of > '56.10.in-addr.arpa/IN': AXFR-style IXFR ended > Mar 6 14:36:37 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:37.977875463 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:40 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:40.999275184 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:45 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:45.211260414 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > ------ These messages indicate that the replica does not have the same database as the master. So either the master or the replica needs to be reinitialized., More on this below... > > > Errors on orldc-prod-ipa02: > ------ > r 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: ipa : INFO > Commencing sync process > Mar 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: > ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump > is done, sychronizing with ODS and BIND > Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:05.934405274 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:05.937278142 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:05.939434025 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. These are harmless "errors" which have been removed in newer versions of 389-ds-base. > Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:06.882795654 -0500] > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - > Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). > If replication stops, the consumer may need to be reinitialized. > Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:06.886029272 -0500] NSMMReplicationPlugin - > changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" > (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't > as up to date, or we purged This "could" also be a known issue that is fixed in newer versions of 389-ds-base. Or this is a valid error message due to the replica being stale for a very long time and records actually being purged from the changelog before they were replicated. > Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:06.888679268 -0500] NSMMReplicationPlugin - > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): > Data required to update replica has been purged from the changelog. > The replica must be reinitialized. > Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:06.960804253 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa01:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. Okay, so your replication agreements/servers are not in sync. I suspect you created a new replica and used that to initialize a valid replica which broke things. Something like that. You need to find a "good" replica server and reinitialize the other replicas from that server. These errors needs to addressed asap, as it's halting replication for those agreements which explains the "instability" you are describing. Mark > Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:08.960622608 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:08.968927168 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:08.976952118 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:09 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:09.972315877 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa01:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:10.034810948 -0500] > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - > Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). > If replication stops, the consumer may need to be reinitialized. > Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:10.040020359 -0500] NSMMReplicationPlugin - > changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" > (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't > as up to date, or we purged > Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:10.042846879 -0500] NSMMReplicationPlugin - > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): > Data required to update replica has been purged from the changelog. > The replica must be reinitialized. > Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:13.013253769 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:13.021514225 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:13.027521508 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:13.110566247 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa01:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:14.179819300 -0500] > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - > Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). > If replication stops, the consumer may need to be reinitialized. > Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:14.188353328 -0500] NSMMReplicationPlugin - > changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" > (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't > as up to date, or we purged > Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:14.196463928 -0500] NSMMReplicationPlugin - > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): > Data required to update replica has been purged from the changelog. > The replica must be reinitialized. > Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:17.068292919 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:17.071241757 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:17.073793922 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > ------ > > > Thanks in advance!!! > > -- Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Mar 7 13:51:16 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 7 Mar 2017 08:51:16 -0500 Subject: [Freeipa-users] Make Gpg replica fail , where cert store I should update new ? In-Reply-To: References: <8450f24d-91d7-175c-0bfd-39e0e47c3ddf@redhat.com> Message-ID: barrykfl at gmail.com wrote: > same as as replica gpg making.////...Found this cert 2015 expired > only,,? but I follow manual here: > > https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 > If you are using 3rd party certs elsewhere then why not provide 3rd party certs for this replica as well? It seems like you aren't using the IPA-provided CA at all given its certs expired in 2015. rob > > It imported as EXT-CA as Alias rather than sever cert by default...Is > there anywhere pointing wrong ? > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > *.ABC.com ,, > EXT-CA CT,C,C > ABC.COM IPA > CA CT,,C > Server-Cert u,u,u > > > Request ID '20160516111257': > status: CA_UNREACHABLE > ca-error: Server at https://central.ABC.com/ipa/xml failed > request, will retry: 907 (RPC failed at server. cannot connect to > 'https://central.ABC.com:443/ca/agent/ca/displayBySerial': > (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not recognized.). > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=ABC.COM > subject: CN=central.ABC.com ,O=ABC.COM > > expires: 2015-11-23 08:42:52 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA > track: yes > auto-renew: yes > > 2017-03-07 19:24 GMT+08:00 Barry >: > > Same as before I already follow part < 4.1 as below: > > https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 > > comdo cert is new cert / > It seem I m nearly right ....HTTP server side can read trust cert > BUT seem dirsrv still lacking of a ca cert to verify it ./.. > but ca.crt changed to new already and imported > > ABC-COM...[07/Mar/2017:19:17:22 +0800] - SSL alert: > CERT_VerifyCertificateNow: verify certificate failed for cert > *.ABC.com - COMODO CA Limited of family > cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error > -8179 - Peer's Certificate issuer is not recognized.) > > > 2017-03-07 17:16 GMT+08:00 Florence Blanc-Renaud >: > > Hi, > > In IPA < 4.5, ipa-replica-prepare was using /etc/ipa/ca.crt as > Certificate Authority, and this file may be outdated. Running > ipa-certupdate may fix your issue. See [1] > > If it doesn't, you can start by identifying which certificate > expired with > $ sudo getcert list | egrep -e 'expires|Request ID|subject' > > HTH, > Flo > > [1] https://pagure.io/freeipa/issue/6375 > > > On 03/07/2017 04:14 AM, barrykfl at gmail.com > wrote: > > gpg > > Creating SSL certificate for the Directory Server > ipa : ERROR cert validation failed for > "CN=central.ABC.com > ,O=ABC.COM > " > ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has > expired.) > preparation of replica failed: cannot connect to > 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient ': > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. > cannot connect to > 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient ': > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. > File "/usr/sbin/ipa-replica-prepare", line 490, in > main() > > File "/usr/sbin/ipa-replica-prepare", line 361, in main > export_certdb(api.env.realm, ds_dir, dir, passwd_fname, > "dscert", > replica_fqdn, subject_base) > > File "/usr/sbin/ipa-replica-prepare", line 150, in > export_certdb > raise e > > > > > > > > From rcritten at redhat.com Tue Mar 7 13:52:39 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 7 Mar 2017 08:52:39 -0500 Subject: [Freeipa-users] make a new server and migrate old data In-Reply-To: References: Message-ID: barrykfl at gmail.com wrote: > Hi: > > I have freeipa 3.0 server ...and want to make a new server ignore any > cert related. > > eg I clean install a server using default free ipa server cert ..and > copy dirsrv data to new. > can I just copy /etc/dirsrv scheme..username /passwords and groups ? > > Also if I copy these to 4.0 server any issue? The documentation contains information on how to do IPA to IPA migration but it will only migrate users and groups. rob From barrykfl at gmail.com Tue Mar 7 14:08:58 2017 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Tue, 7 Mar 2017 22:08:58 +0800 Subject: [Freeipa-users] Make Gpg replica fail , where cert store I should update new ? In-Reply-To: References: <8450f24d-91d7-175c-0bfd-39e0e47c3ddf@redhat.com> Message-ID: I think I already input all ca cert and server cert certutil -d /etc/dirsrv/slapd-PKI-IPA/ -L Trust Attributes SSL,S/MIME,JAR/XPI *.wisers.com < it is the server wild card cert already EXT-CA CT,C,C 2017-03-07 21:51 GMT+08:00 Rob Crittenden : > barrykfl at gmail.com wrote: > > same as as replica gpg making.////...Found this cert 2015 expired > > only,,? but I follow manual here: > > > > https://www.freeipa.org/page/Using_3rd_part_certificates_ > for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 > > for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1> > > If you are using 3rd party certs elsewhere then why not provide 3rd > party certs for this replica as well? > > It seems like you aren't using the IPA-provided CA at all given its > certs expired in 2015. > > rob > > > > > It imported as EXT-CA as Alias rather than sever cert by default...Is > > there anywhere pointing wrong ? > > > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > *.ABC.com ,, > > EXT-CA CT,C,C > > ABC.COM IPA > > CA CT,,C > > Server-Cert u,u,u > > > > > > Request ID '20160516111257': > > status: CA_UNREACHABLE > > ca-error: Server at https://central.ABC.com/ipa/xml failed > > request, will retry: 907 (RPC failed at server. cannot connect to > > 'https://central.ABC.com:443/ca/agent/ca/displayBySerial': > > (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not recognized.). > > stuck: no > > key pair storage: > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA', > nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > > certificate: > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA', > nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=ABC.COM > > subject: CN=central.ABC.com ,O=ABC.COM > > > > expires: 2015-11-23 08:42:52 UTC > > key usage: > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv > PKI-IPA > > track: yes > > auto-renew: yes > > > > 2017-03-07 19:24 GMT+08:00 Barry > >: > > > > Same as before I already follow part < 4.1 as below: > > > > https://www.freeipa.org/page/Using_3rd_part_certificates_ > for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 > > for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1> > > comdo cert is new cert / > > It seem I m nearly right ....HTTP server side can read trust cert > > BUT seem dirsrv still lacking of a ca cert to verify it ./.. > > but ca.crt changed to new already and imported > > > > ABC-COM...[07/Mar/2017:19:17:22 +0800] - SSL alert: > > CERT_VerifyCertificateNow: verify certificate failed for cert > > *.ABC.com - COMODO CA Limited of family > > cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error > > -8179 - Peer's Certificate issuer is not recognized.) > > > > > > 2017-03-07 17:16 GMT+08:00 Florence Blanc-Renaud > >: > > > > Hi, > > > > In IPA < 4.5, ipa-replica-prepare was using /etc/ipa/ca.crt as > > Certificate Authority, and this file may be outdated. Running > > ipa-certupdate may fix your issue. See [1] > > > > If it doesn't, you can start by identifying which certificate > > expired with > > $ sudo getcert list | egrep -e 'expires|Request ID|subject' > > > > HTH, > > Flo > > > > [1] https://pagure.io/freeipa/issue/6375 > > > > > > On 03/07/2017 04:14 AM, barrykfl at gmail.com > > wrote: > > > > gpg > > > > Creating SSL certificate for the Directory Server > > ipa : ERROR cert validation failed for > > "CN=central.ABC.com > > ,O=ABC.COM > > " > > ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has > > expired.) > > preparation of replica failed: cannot connect to > > 'https://central.ABC.com:9444/ca/ee/ca/ > profileSubmitSSLClient profileSubmitSSLClient>': > > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has > expired. > > cannot connect to > > 'https://central.ABC.com:9444/ca/ee/ca/ > profileSubmitSSLClient profileSubmitSSLClient>': > > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has > expired. > > File "/usr/sbin/ipa-replica-prepare", line 490, in > > > main() > > > > File "/usr/sbin/ipa-replica-prepare", line 361, in main > > export_certdb(api.env.realm, ds_dir, dir, passwd_fname, > > "dscert", > > replica_fqdn, subject_base) > > > > File "/usr/sbin/ipa-replica-prepare", line 150, in > > export_certdb > > raise e > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Mar 7 14:17:04 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 7 Mar 2017 09:17:04 -0500 Subject: [Freeipa-users] Make Gpg replica fail , where cert store I should update new ? In-Reply-To: References: <8450f24d-91d7-175c-0bfd-39e0e47c3ddf@redhat.com> Message-ID: <47598802-8ec3-efa6-9fe6-371688e72e50@redhat.com> barrykfl at gmail.com wrote: > I think I already input all ca cert and server cert man ipa-replica-prepare rob > > > certutil -d /etc/dirsrv/slapd-PKI-IPA/ -L > Trust Attributes > > SSL,S/MIME,JAR/XPI > *.wisers.com < it is > the server wild card cert already > EXT-CA CT,C,C the combo cert CA > ABC.COM IPA CA > CT,,C > Server-Cert u,u,u > > > When I make replica it comes out error form master server > central.ABC.com ..any I missing? > > Creating SSL certificate for the dogtag Directory Server > ipa : ERROR cert validation failed for "CN=central.ABC > ROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.) > preparation of replica failed: cannot connect to > 'https://central.ABC9444/ca/ee/ca/profileSubmitSSLClient': > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. > cannot connect to > 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. > File "/usr/sbin/ipa-replica-prepare", line 490, in > > > > > > 2017-03-07 21:51 GMT+08:00 Rob Crittenden >: > > barrykfl at gmail.com wrote: > > same as as replica gpg making.////...Found this cert 2015 expired > > only,,? but I follow manual here: > > > > https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 > > > > > > > If you are using 3rd party certs elsewhere then why not provide 3rd > party certs for this replica as well? > > It seems like you aren't using the IPA-provided CA at all given its > certs expired in 2015. > > rob > > > > > It imported as EXT-CA as Alias rather than sever cert by default...Is > > there anywhere pointing wrong ? > > > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > *.ABC.com ,, > > EXT-CA CT,C,C > > ABC.COM IPA > > CA CT,,C > > Server-Cert u,u,u > > > > > > Request ID '20160516111257': > > status: CA_UNREACHABLE > > ca-error: Server at https://central.ABC.com/ipa/xml failed > > request, will retry: 907 (RPC failed at server. cannot connect to > > 'https://central.ABC.com:443/ca/agent/ca/displayBySerial > ': > > (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer is not recognized.). > > stuck: no > > key pair storage: > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > > certificate: > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=ABC.COM > > > subject: CN=central.ABC.com > ,O=ABC.COM > > > > expires: 2015-11-23 08:42:52 UTC > > key usage: > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA > > track: yes > > auto-renew: yes > > > > 2017-03-07 19:24 GMT+08:00 Barry > > >>: > > > > Same as before I already follow part < 4.1 as below: > > > > https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 > > > > > > comdo cert is new cert / > > It seem I m nearly right ....HTTP server side can read trust cert > > BUT seem dirsrv still lacking of a ca cert to verify it ./.. > > but ca.crt changed to new already and imported > > > > ABC-COM...[07/Mar/2017:19:17:22 +0800] - SSL alert: > > CERT_VerifyCertificateNow: verify certificate failed for cert > > *.ABC.com - COMODO CA Limited of family > > cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error > > -8179 - Peer's Certificate issuer is not recognized.) > > > > > > 2017-03-07 17:16 GMT+08:00 Florence Blanc-Renaud > > >>: > > > > Hi, > > > > In IPA < 4.5, ipa-replica-prepare was using /etc/ipa/ca.crt as > > Certificate Authority, and this file may be outdated. Running > > ipa-certupdate may fix your issue. See [1] > > > > If it doesn't, you can start by identifying which certificate > > expired with > > $ sudo getcert list | egrep -e 'expires|Request ID|subject' > > > > HTH, > > Flo > > > > [1] https://pagure.io/freeipa/issue/6375 > > > > > > > > On 03/07/2017 04:14 AM, barrykfl at gmail.com > > > wrote: > > > > gpg > > > > Creating SSL certificate for the Directory Server > > ipa : ERROR cert validation failed for > > "CN=central.ABC.com > > ,O=ABC.COM > > " > > ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has > > expired.) > > preparation of replica failed: cannot connect to > > > 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient > > >': > > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. > > cannot connect to > > > 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient > > >': > > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has > expired. > > File "/usr/sbin/ipa-replica-prepare", line 490, in > > > main() > > > > File "/usr/sbin/ipa-replica-prepare", line 361, in main > > export_certdb(api.env.realm, ds_dir, dir, > passwd_fname, > > "dscert", > > replica_fqdn, subject_base) > > > > File "/usr/sbin/ipa-replica-prepare", line 150, in > > export_certdb > > raise e > > > > > > > > > > > > > > > > > > From simo at redhat.com Tue Mar 7 14:25:30 2017 From: simo at redhat.com (Simo Sorce) Date: Tue, 07 Mar 2017 09:25:30 -0500 Subject: [Freeipa-users] Padding Scheme used in Fedora Dogtag In-Reply-To: References: Message-ID: <1488896730.16250.24.camel@redhat.com> On Tue, 2017-03-07 at 12:38 +0530, Kaamel Periora wrote: > Dear All, > > It is required to identify the padding scheme used by the Fedora dogtag > system. Appreciate of someone could shed some light on this requirement. Padding scheme for what exactly ? Simo. -- Simo Sorce * Red Hat, Inc * New York From b.candler at pobox.com Tue Mar 7 15:57:09 2017 From: b.candler at pobox.com (Brian Candler) Date: Tue, 7 Mar 2017 15:57:09 +0000 Subject: [Freeipa-users] Disabling OTP for sudo Message-ID: Question: can I remove the need for OTP for sudo access, when used with an account that has OTP enabled? All I could find was this mail from mid-2015: https://www.redhat.com/archives/freeipa-users/2015-July/msg00336.html It said that sssd would need some changes. I don't know how sssd itself validates the password provided (is it via Kerberos? Does it also depend on authentication indicators being implemented?) Thanks, Brian. From peljasz at yahoo.co.uk Tue Mar 7 16:29:19 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 7 Mar 2017 16:29:19 +0000 Subject: [Freeipa-users] consumer replica which does not show up in ruv list In-Reply-To: <20170307123924.GA26633@dhcp129-180.brq.redhat.com> References: <8346bc89-6c4d-c33a-0793-0b26ae30b56c@yahoo.co.uk> <20170307123924.GA26633@dhcp129-180.brq.redhat.com> Message-ID: <527673f4-e1be-735a-cf83-edba354ef2ce@yahoo.co.uk> On 07/03/17 12:39, Martin Babinsky wrote: > On Tue, Mar 07, 2017 at 09:55:52AM +0000, lejeczek wrote: >> hi, >> >> I presume I need to use ldapmodify/delete? >> I found this(obfuscated by me): >> >> cn=dzien.priv.xx.xx.priv.xx.xx.x+nsuniqueid=9e47680e-296e11e6-83a59f45-6ec26a1e,cn=masters,cn=ipa,cn=etc,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> >> To confirm? Would removing it fix the problem? I'm probably missing something >> else, aren't I? >> >> many thank, >> L >> -- >> 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 > > That seems like a replication conflict. Consult the following guide to solve > it: > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html I'm not sure whether I'm dealing with single or multi-valued DN and I should rename+keep original copy(following that doc) or simply remove that DN. > Just a side question, how did you end up with such entry? Did you happen to upgrade > multiple IPA masters at once? > From mexigabacho at gmail.com Tue Mar 7 16:29:59 2017 From: mexigabacho at gmail.com (Christopher Young) Date: Tue, 7 Mar 2017 11:29:59 -0500 Subject: [Freeipa-users] Replication Issues In-Reply-To: References: Message-ID: Thank you very much for the response! To start: ---- [root at orldc-prod-ipa01 ~]# rpm -qa 389-ds-base 389-ds-base-1.3.5.10-18.el7_3.x86_64 ---- So, I believe a good part of my problem is that I'm not _positive_ which replica is good at this point (though my directory really isn't that huge). Do you have any pointers on a good method of comparing the directory data between them? I was wondering if anyone knows of any tools to facilitate that. I was thinking that it might make sense for me to dump the DB and restore, but I really don't know that procedure. As I mentioned, my directory really isn't that large at all, however I'm not positive the best bullet-item listed method to proceed. (I know I'm not helping things :) ) Would it be acceptable to just 'assume' one of the replicas is good (taking the risk of whatever missing pieces I'll have to deal with), completely removing the others, and then rebuilding the replicas from scratch? If I go that route, what are the potential pitfalls? I want to decide on an approach and try and resolve this once and for all. Thanks again! It really is appreciated as I've been frustrated with this for a while now. -- Chris On Tue, Mar 7, 2017 at 8:45 AM, Mark Reynolds wrote: > What version of 389-ds-base are you using? > > rpm -qa | grep 389-ds-base > > > comments below.. > > On 03/06/2017 02:37 PM, Christopher Young wrote: > > I've seen similar posts, but in the interest of asking fresh and > trying to understand what is going on, I thought I would ask for > advice on how best to handle this situation. > > In the interest of providing some history: > I have three (3) FreeIPA servers. Everything is running 4.4.0 now. > The originals (orldc-prod-ipa01, orldc-prod-ipa02) were upgraded from > the 3.x branch quite a while back. Everything had been working fine, > however I ran into a replication issue (that I _think_ may have been a > result of IPv6 being disabled by my default Ansible roles). I thought > I had resolved that by reinitializing the 2nd replica, > orldc-prod-ipa02. > > In any case, I feel like the replication has never been fully stable > since then, and I have all types of errors in messages that indicate > something is off. I had single introduced a 3rd replica such that the > agreements would look like so: > > orldc-prod-ipa01 -> orldc-prod-ipa02 ---> bohdc-prod-ipa01 > > It feels like orldc-prod-ipa02 & bohdc-prod-ipa01 are out of sync. > I've tried reinitializing them in order but with no positive results. > At this point, I feel like I'm ready to 'bite the bullet' and tear > them down quickly (remove them from IPA, delete the local > DBs/directories) and rebuild them from scratch. > > I want to minimize my impact as much as possible (which I can somewhat > do by redirecting LDAP/DNS request via my load-balancers temporarily) > and do this right. > > (Getting to the point...) > > I'd like advice on the order of operations to do this. Give the > errors (I'll include samples at the bottom of this message), does it > make sense for me to remove the replicas on bohdc-prod-ipa01 & > orldc-prod-ipa02 (in that order), wipe out any directories/residual > pieces (I'd need some idea of what to do there), and then create new > replicas? -OR- Should I export/backup the LDAP DB and rebuild > everything from scratch. > > I need advice and ideas. Furthermore, if there is someone with > experience in this that would be interested in making a little money > on the side, let me know, because having an extra brain and set of > hands would be welcome. > > DETAILS: > ================= > > > ERRORS I see on orldc-prod-ipa01 (the one whose LDAP DB seems the most > up-to-date since my changes are usually directed at it): > ------ > Mar 6 14:36:24 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:24.434956575 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO > LDAP bind... > Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO > Commencing sync process > Mar 6 14:36:26 orldc-prod-ipa01 ipa-dnskeysyncd: > ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump > is done, sychronizing with ODS and BIND > Mar 6 14:36:27 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:27.799519203 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:30 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:30.994760069 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:34 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:34.940115481 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client > 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of > '56.10.in-addr.arpa/IN': AXFR-style IXFR started > Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client > 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of > '56.10.in-addr.arpa/IN': AXFR-style IXFR ended > Mar 6 14:36:37 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:37.977875463 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:40 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:40.999275184 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:36:45 orldc-prod-ipa01 ns-slapd: > [06/Mar/2017:14:36:45.211260414 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > ------ > > These messages indicate that the replica does not have the same database as > the master. So either the master or the replica needs to be reinitialized., > More on this below... > > > Errors on orldc-prod-ipa02: > ------ > r 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: ipa : INFO > Commencing sync process > Mar 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: > ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump > is done, sychronizing with ODS and BIND > Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:05.934405274 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:05.937278142 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:05.939434025 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > > These are harmless "errors" which have been removed in newer versions of > 389-ds-base. > > Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:06.882795654 -0500] > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - > Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). > If replication stops, the consumer may need to be reinitialized. > Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:06.886029272 -0500] NSMMReplicationPlugin - > changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" > (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't > as up to date, or we purged > > This "could" also be a known issue that is fixed in newer versions of > 389-ds-base. Or this is a valid error message due to the replica being > stale for a very long time and records actually being purged from the > changelog before they were replicated. > > Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:06.888679268 -0500] NSMMReplicationPlugin - > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): > Data required to update replica has been purged from the changelog. > The replica must be reinitialized. > Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:06.960804253 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa01:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > > Okay, so your replication agreements/servers are not in sync. I suspect you > created a new replica and used that to initialize a valid replica which > broke things. Something like that. You need to find a "good" replica > server and reinitialize the other replicas from that server. These errors > needs to addressed asap, as it's halting replication for those agreements > which explains the "instability" you are describing. > > Mark > > Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:08.960622608 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:08.968927168 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:08.976952118 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:09 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:09.972315877 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa01:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:10.034810948 -0500] > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - > Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). > If replication stops, the consumer may need to be reinitialized. > Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:10.040020359 -0500] NSMMReplicationPlugin - > changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" > (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't > as up to date, or we purged > Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:10.042846879 -0500] NSMMReplicationPlugin - > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): > Data required to update replica has been purged from the changelog. > The replica must be reinitialized. > Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:13.013253769 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:13.021514225 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:13.027521508 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:13.110566247 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa01:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:14.179819300 -0500] > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - > Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). > If replication stops, the consumer may need to be reinitialized. > Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:14.188353328 -0500] NSMMReplicationPlugin - > changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" > (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't > as up to date, or we purged > Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:14.196463928 -0500] NSMMReplicationPlugin - > agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): > Data required to update replica has been purged from the changelog. > The replica must be reinitialized. > Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:17.068292919 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:17.071241757 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: > [06/Mar/2017:14:16:17.073793922 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > ------ > > > Thanks in advance!!! > > -- Chris > > From zwolfinger at myemma.com Tue Mar 7 16:42:02 2017 From: zwolfinger at myemma.com (Zak Wolfinger) Date: Tue, 7 Mar 2017 10:42:02 -0600 Subject: [Freeipa-users] How to tell if a replica server is also a CA? Message-ID: <9295EEC5-F420-4DB5-99A2-C2031EBAC556@myemma.com> How can I tell if my FreeIPA 4.2.0 replica servers are also configured to be CAs? -- From lkrispen at redhat.com Tue Mar 7 16:48:29 2017 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 07 Mar 2017 17:48:29 +0100 Subject: [Freeipa-users] consumer replica which does not show up in ruv list In-Reply-To: <527673f4-e1be-735a-cf83-edba354ef2ce@yahoo.co.uk> References: <8346bc89-6c4d-c33a-0793-0b26ae30b56c@yahoo.co.uk> <20170307123924.GA26633@dhcp129-180.brq.redhat.com> <527673f4-e1be-735a-cf83-edba354ef2ce@yahoo.co.uk> Message-ID: <58BEE45D.7060607@redhat.com> On 03/07/2017 05:29 PM, lejeczek wrote: > > > On 07/03/17 12:39, Martin Babinsky wrote: >> On Tue, Mar 07, 2017 at 09:55:52AM +0000, lejeczek wrote: >>> hi, >>> >>> I presume I need to use ldapmodify/delete? >>> I found this(obfuscated by me): >>> >>> cn=dzien.priv.xx.xx.priv.xx.xx.x+nsuniqueid=9e47680e-296e11e6-83a59f45-6ec26a1e,cn=masters,cn=ipa,cn=etc,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >>> >>> >>> To confirm? Would removing it fix the problem? I'm probably missing >>> something >>> else, aren't I? >>> >>> many thank, >>> L >>> -- >>> 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 >> >> That seems like a replication conflict. Consult the following guide >> to solve >> it: >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >> > I'm not sure whether I'm dealing with single or multi-valued DN and I > should rename+keep original copy(following that doc) or simply remove > that DN. this is something which cannot be generally answered, you need to look at the specific entries. In the case of conflicts you always have entries like cn=xxxx, and cn=xxxx+nsuniqueid=nnnnnnnn-nnnnnnn-nnnnnnn-nnnnnn, and usually they are created if the same entry is added at the same time on two replicas, then they are identical and you can just delete the conflict entry. Only if you want to keep both entries you need to rename the conflict. > >> Just a side question, how did you end up with such entry? Did you >> happen to upgrade >> multiple IPA masters at once? >> > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander From rcritten at redhat.com Tue Mar 7 16:57:48 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 7 Mar 2017 11:57:48 -0500 Subject: [Freeipa-users] How to tell if a replica server is also a CA? In-Reply-To: <9295EEC5-F420-4DB5-99A2-C2031EBAC556@myemma.com> References: <9295EEC5-F420-4DB5-99A2-C2031EBAC556@myemma.com> Message-ID: <9f1f53b1-5a4b-848f-1f39-5c6242bfb3f3@redhat.com> Zak Wolfinger wrote: > How can I tell if my FreeIPA 4.2.0 replica servers are also configured to be CAs? > > Brute force way is to look in LDAP under cn=masters,cn=ipa,cn=etc,dc=example,dc=com $ ldapsearch -LLL -Y GSSAPI -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com dn The configured services for every master is listed there. rob From freeipa at jacobdevans.com Tue Mar 7 17:36:50 2017 From: freeipa at jacobdevans.com (Jake) Date: Tue, 7 Mar 2017 12:36:50 -0500 (EST) Subject: [Freeipa-users] Insufficient privileges to promote the server. (ipa replica 4.4.0 / centos7.3) Message-ID: <668496400.8316.1488908210714@vegas.jacobdevans.com> dirserv wasn't running and couldn't get running so I went to rebuild the replica and now I get this? replica is a fresh install, I removed the replica from ipa with $ ipa-replica-manage del dc1-rd-ipa02.ipa.example.com --force --cleanup on the master c05-rd-ipa01.ipa.example.com 2017-03-07T17:32:18Z DEBUG Created connection context.ldap2_85375504 2017-03-07T17:32:18Z DEBUG raw: domainlevel_get(version=u'2.213') 2017-03-07T17:32:18Z DEBUG domainlevel_get(version=u'2.213') 2017-03-07T17:32:18Z DEBUG flushing ldaps://c05-rd-ipa02.ipa.example.com from SchemaCache 2017-03-07T17:32:18Z DEBUG retrieving schema for SchemaCache url=ldaps://c05-rd-ipa02.ipa.example.com conn= 2017-03-07T17:32:18Z DEBUG raw: hostgroup_find(None, cn=u'ipaservers', version=u'2.213', host=[u'dc1-rd-ipa02.ipa.example.com']) 2017-03-07T17:32:18Z DEBUG hostgroup_find(None, cn=u'ipaservers', all=False, raw=False, version=u'2.213', no_members=True, pkey_only=False, host=(u'dc1-rd-ipa02.ipa.example.com',)) 2017-03-07T17:32:18Z DEBUG Destroyed connection context.ldap2_85375504 2017-03-07T17:32:18Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 308, in run self.validate() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 317, in validate for nothing in self._validator(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 564, in _configure next(validator) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 449, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 63, in _install for nothing in self._installer(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1712, in main promote_check(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 364, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 386, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1311, in promote_check sys.exit("\nInsufficient privileges to promote the server.") 2017-03-07T17:32:18Z DEBUG The ipa-replica-install command failed, exception: SystemExit: Insufficient privileges to promote the server. 2017-03-07T17:32:18Z ERROR Insufficient privileges to promote the server. 2017-03-07T17:32:18Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Mar 7 17:57:13 2017 From: mbasti at redhat.com (Martin Basti) Date: Tue, 7 Mar 2017 18:57:13 +0100 Subject: [Freeipa-users] Insufficient privileges to promote the server. (ipa replica 4.4.0 / centos7.3) In-Reply-To: <668496400.8316.1488908210714@vegas.jacobdevans.com> References: <668496400.8316.1488908210714@vegas.jacobdevans.com> Message-ID: <1751259a-7c2e-ef59-3f94-08941657d869@redhat.com> On 07.03.2017 18:36, Jake wrote: > dirserv wasn't running and couldn't get running so I went to rebuild > the replica and now I get this? > > replica is a fresh install, I removed the replica from ipa with > > $ ipa-replica-manage del dc1-rd-ipa02.ipa.example.com --force --cleanup > on the master c05-rd-ipa01.ipa.example.com > > 2017-03-07T17:32:18Z DEBUG Created connection context.ldap2_85375504 > 2017-03-07T17:32:18Z DEBUG raw: domainlevel_get(version=u'2.213') > 2017-03-07T17:32:18Z DEBUG domainlevel_get(version=u'2.213') > 2017-03-07T17:32:18Z DEBUG flushing > ldaps://c05-rd-ipa02.ipa.example.com from SchemaCache > 2017-03-07T17:32:18Z DEBUG retrieving schema for SchemaCache > url=ldaps://c05-rd-ipa02.ipa.example.com > conn= > 2017-03-07T17:32:18Z DEBUG raw: hostgroup_find(None, cn=u'ipaservers', > version=u'2.213', host=[u'dc1-rd-ipa02.ipa.example.com']) > 2017-03-07T17:32:18Z DEBUG hostgroup_find(None, cn=u'ipaservers', > all=False, raw=False, version=u'2.213', no_members=True, > pkey_only=False, host=(u'dc1-rd-ipa02.ipa.example.com',)) > 2017-03-07T17:32:18Z DEBUG Destroyed connection context.ldap2_85375504 > 2017-03-07T17:32:18Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, > in execute > return_value = self.run() > File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", > line 318, in run > cfgr.run() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 308, in run > self.validate() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 317, in validate > for nothing in self._validator(): > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 362, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 564, in _configure > next(validator) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 372, in __runner > self._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 449, in _handle_exception > self.__parent._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 446, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 394, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 362, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 359, in > step = lambda: next(self.__gen) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 81, in run_generator_with_yield_from > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", > line 59, in run_generator_with_yield_from > value = gen.send(prev_value) > File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", > line 63, in _install > for nothing in self._installer(self.parent): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1712, in main > promote_check(self) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 364, in decorated > func(installer) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 386, in decorated > func(installer) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", > line 1311, in promote_check > sys.exit("\nInsufficient privileges to promote the server.") > > 2017-03-07T17:32:18Z DEBUG The ipa-replica-install command failed, > exception: SystemExit: > Insufficient privileges to promote the server. > 2017-03-07T17:32:18Z ERROR > Insufficient privileges to promote the server. > 2017-03-07T17:32:18Z ERROR The ipa-replica-install command failed. See > /var/log/ipareplica-install.log for more information > > Hello, are you kinited as admin? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From freeipa at jacobdevans.com Tue Mar 7 18:57:18 2017 From: freeipa at jacobdevans.com (Jake) Date: Tue, 7 Mar 2017 13:57:18 -0500 (EST) Subject: [Freeipa-users] Insufficient privileges to promote the server. (ipa replica 4.4.0 / centos7.3) In-Reply-To: <1751259a-7c2e-ef59-3f94-08941657d869@redhat.com> References: <668496400.8316.1488908210714@vegas.jacobdevans.com> <1751259a-7c2e-ef59-3f94-08941657d869@redhat.com> Message-ID: <684206858.8411.1488913038963@lux.jacobdevans.com> dropped the '-p admin' and not it works, first time I've had that happen. Thanks From: "Martin Basti" To: "Jake" , "freeipa-users" Sent: Tuesday, March 7, 2017 12:57:13 PM Subject: Re: [Freeipa-users] Insufficient privileges to promote the server. (ipa replica 4.4.0 / centos7.3) On 07.03.2017 18:36, Jake wrote: dirserv wasn't running and couldn't get running so I went to rebuild the replica and now I get this? replica is a fresh install, I removed the replica from ipa with $ ipa-replica-manage del dc1-rd-ipa02.ipa.example.com --force --cleanup on the master c05-rd-ipa01.ipa.example.com 2017-03-07T17:32:18Z DEBUG Created connection context.ldap2_85375504 2017-03-07T17:32:18Z DEBUG raw: domainlevel_get(version=u'2.213') 2017-03-07T17:32:18Z DEBUG domainlevel_get(version=u'2.213') 2017-03-07T17:32:18Z DEBUG flushing [ ldaps://c05-rd-ipa02.ipa.example.com | ldaps://c05-rd-ipa02.ipa.example.com ] from SchemaCache 2017-03-07T17:32:18Z DEBUG retrieving schema for SchemaCache url= [ ldaps://c05-rd-ipa02.ipa.example.com | ldaps://c05-rd-ipa02.ipa.example.com ] conn= 2017-03-07T17:32:18Z DEBUG raw: hostgroup_find(None, cn=u'ipaservers', version=u'2.213', host=[u'dc1-rd-ipa02.ipa.example.com']) 2017-03-07T17:32:18Z DEBUG hostgroup_find(None, cn=u'ipaservers', all=False, raw=False, version=u'2.213', no_members=True, pkey_only=False, host=(u'dc1-rd-ipa02.ipa.example.com',)) 2017-03-07T17:32:18Z DEBUG Destroyed connection context.ldap2_85375504 2017-03-07T17:32:18Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 308, in run self.validate() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 317, in validate for nothing in self._validator(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 564, in _configure next(validator) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 449, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 63, in _install for nothing in self._installer(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1712, in main promote_check(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 364, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 386, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1311, in promote_check sys.exit("\nInsufficient privileges to promote the server.") 2017-03-07T17:32:18Z DEBUG The ipa-replica-install command failed, exception: SystemExit: Insufficient privileges to promote the server. 2017-03-07T17:32:18Z ERROR Insufficient privileges to promote the server. 2017-03-07T17:32:18Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information Hello, are you kinited as admin? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From peljasz at yahoo.co.uk Tue Mar 7 20:21:26 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 7 Mar 2017 20:21:26 +0000 Subject: [Freeipa-users] consumer replica which does not show up in ruv list In-Reply-To: <58BEE45D.7060607@redhat.com> References: <8346bc89-6c4d-c33a-0793-0b26ae30b56c@yahoo.co.uk> <20170307123924.GA26633@dhcp129-180.brq.redhat.com> <527673f4-e1be-735a-cf83-edba354ef2ce@yahoo.co.uk> <58BEE45D.7060607@redhat.com> Message-ID: On 07/03/17 16:48, Ludwig Krispenz wrote: > > On 03/07/2017 05:29 PM, lejeczek wrote: >> >> >> On 07/03/17 12:39, Martin Babinsky wrote: >>> On Tue, Mar 07, 2017 at 09:55:52AM +0000, lejeczek wrote: >>>> hi, >>>> >>>> I presume I need to use ldapmodify/delete? >>>> I found this(obfuscated by me): >>>> >>>> cn=dzien.priv.xx.xx.priv.xx.xx.x+nsuniqueid=9e47680e-296e11e6-83a59f45-6ec26a1e,cn=masters,cn=ipa,cn=etc,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >>>> >>>> >>>> To confirm? Would removing it fix the problem? I'm >>>> probably missing something >>>> else, aren't I? >>>> >>>> many thank, >>>> L >>>> -- >>>> 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 >>> >>> That seems like a replication conflict. Consult the >>> following guide to solve >>> it: >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>> >> I'm not sure whether I'm dealing with single or >> multi-valued DN and I should rename+keep original >> copy(following that doc) or simply remove that DN. > this is something which cannot be generally answered, you > need to look at the specific entries. In the case of > conflicts you always have entries like > cn=xxxx, and > cn=xxxx+nsuniqueid=nnnnnnnn-nnnnnnn-nnnnnnn-nnnnnn, of dn> > > and usually they are created if the same entry is added at > the same time on two replicas, then they are identical and > you can just delete the conflict entry. Only if you want > to keep both entries you need to rename the conflict. to confirm - I presume this should be a recursive deletion with '-r' , the whole lot, right? thx, L. >> >>> Just a side question, how did you end up with such >>> entry? Did you happen to upgrade >>> multiple IPA masters at once? >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mareynol at redhat.com Tue Mar 7 21:23:18 2017 From: mareynol at redhat.com (Mark Reynolds) Date: Tue, 7 Mar 2017 16:23:18 -0500 Subject: [Freeipa-users] Replication Issues In-Reply-To: References: Message-ID: On 03/07/2017 11:29 AM, Christopher Young wrote: > Thank you very much for the response! > > To start: > ---- > [root at orldc-prod-ipa01 ~]# rpm -qa 389-ds-base > 389-ds-base-1.3.5.10-18.el7_3.x86_64 > ---- You are on the latest version with the latest replication fixes. > > So, I believe a good part of my problem is that I'm not _positive_ > which replica is good at this point (though my directory really isn't > that huge). > > Do you have any pointers on a good method of comparing the directory > data between them? I was wondering if anyone knows of any tools to > facilitate that. I was thinking that it might make sense for me to > dump the DB and restore, but I really don't know that procedure. As I > mentioned, my directory really isn't that large at all, however I'm > not positive the best bullet-item listed method to proceed. (I know > I'm not helping things :) ) Heh, well only you know what your data should be. You can always do a db2ldif.pl on each server and compare the ldif files that are generated. Then pick the one you think is the most up to date. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html#Exporting-db2ldif Once you decide on a server, then you need to reinitialize all the other servers/replicas from the "good" one. Use " ipa-replica-manage re-initialize" for this. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html#initialize That's it. Good luck, Mark > > Would it be acceptable to just 'assume' one of the replicas is good > (taking the risk of whatever missing pieces I'll have to deal with), > completely removing the others, and then rebuilding the replicas from > scratch? > > If I go that route, what are the potential pitfalls? > > > I want to decide on an approach and try and resolve this once and for all. > > Thanks again! It really is appreciated as I've been frustrated with > this for a while now. > > -- Chris > > On Tue, Mar 7, 2017 at 8:45 AM, Mark Reynolds wrote: >> What version of 389-ds-base are you using? >> >> rpm -qa | grep 389-ds-base >> >> >> comments below.. >> >> On 03/06/2017 02:37 PM, Christopher Young wrote: >> >> I've seen similar posts, but in the interest of asking fresh and >> trying to understand what is going on, I thought I would ask for >> advice on how best to handle this situation. >> >> In the interest of providing some history: >> I have three (3) FreeIPA servers. Everything is running 4.4.0 now. >> The originals (orldc-prod-ipa01, orldc-prod-ipa02) were upgraded from >> the 3.x branch quite a while back. Everything had been working fine, >> however I ran into a replication issue (that I _think_ may have been a >> result of IPv6 being disabled by my default Ansible roles). I thought >> I had resolved that by reinitializing the 2nd replica, >> orldc-prod-ipa02. >> >> In any case, I feel like the replication has never been fully stable >> since then, and I have all types of errors in messages that indicate >> something is off. I had single introduced a 3rd replica such that the >> agreements would look like so: >> >> orldc-prod-ipa01 -> orldc-prod-ipa02 ---> bohdc-prod-ipa01 >> >> It feels like orldc-prod-ipa02 & bohdc-prod-ipa01 are out of sync. >> I've tried reinitializing them in order but with no positive results. >> At this point, I feel like I'm ready to 'bite the bullet' and tear >> them down quickly (remove them from IPA, delete the local >> DBs/directories) and rebuild them from scratch. >> >> I want to minimize my impact as much as possible (which I can somewhat >> do by redirecting LDAP/DNS request via my load-balancers temporarily) >> and do this right. >> >> (Getting to the point...) >> >> I'd like advice on the order of operations to do this. Give the >> errors (I'll include samples at the bottom of this message), does it >> make sense for me to remove the replicas on bohdc-prod-ipa01 & >> orldc-prod-ipa02 (in that order), wipe out any directories/residual >> pieces (I'd need some idea of what to do there), and then create new >> replicas? -OR- Should I export/backup the LDAP DB and rebuild >> everything from scratch. >> >> I need advice and ideas. Furthermore, if there is someone with >> experience in this that would be interested in making a little money >> on the side, let me know, because having an extra brain and set of >> hands would be welcome. >> >> DETAILS: >> ================= >> >> >> ERRORS I see on orldc-prod-ipa01 (the one whose LDAP DB seems the most >> up-to-date since my changes are usually directed at it): >> ------ >> Mar 6 14:36:24 orldc-prod-ipa01 ns-slapd: >> [06/Mar/2017:14:36:24.434956575 -0500] NSMMReplicationPlugin - >> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa02:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO >> LDAP bind... >> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO >> Commencing sync process >> Mar 6 14:36:26 orldc-prod-ipa01 ipa-dnskeysyncd: >> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump >> is done, sychronizing with ODS and BIND >> Mar 6 14:36:27 orldc-prod-ipa01 ns-slapd: >> [06/Mar/2017:14:36:27.799519203 -0500] NSMMReplicationPlugin - >> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa02:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 6 14:36:30 orldc-prod-ipa01 ns-slapd: >> [06/Mar/2017:14:36:30.994760069 -0500] NSMMReplicationPlugin - >> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa02:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 6 14:36:34 orldc-prod-ipa01 ns-slapd: >> [06/Mar/2017:14:36:34.940115481 -0500] NSMMReplicationPlugin - >> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa02:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client >> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of >> '56.10.in-addr.arpa/IN': AXFR-style IXFR started >> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client >> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of >> '56.10.in-addr.arpa/IN': AXFR-style IXFR ended >> Mar 6 14:36:37 orldc-prod-ipa01 ns-slapd: >> [06/Mar/2017:14:36:37.977875463 -0500] NSMMReplicationPlugin - >> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa02:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 6 14:36:40 orldc-prod-ipa01 ns-slapd: >> [06/Mar/2017:14:36:40.999275184 -0500] NSMMReplicationPlugin - >> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa02:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 6 14:36:45 orldc-prod-ipa01 ns-slapd: >> [06/Mar/2017:14:36:45.211260414 -0500] NSMMReplicationPlugin - >> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa02:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> ------ >> >> These messages indicate that the replica does not have the same database as >> the master. So either the master or the replica needs to be reinitialized., >> More on this below... >> >> >> Errors on orldc-prod-ipa02: >> ------ >> r 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: ipa : INFO >> Commencing sync process >> Mar 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: >> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump >> is done, sychronizing with ODS and BIND >> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:05.934405274 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:05.937278142 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:05.939434025 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> >> These are harmless "errors" which have been removed in newer versions of >> 389-ds-base. >> >> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:06.882795654 -0500] >> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >> If replication stops, the consumer may need to be reinitialized. >> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:06.886029272 -0500] NSMMReplicationPlugin - >> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >> as up to date, or we purged >> >> This "could" also be a known issue that is fixed in newer versions of >> 389-ds-base. Or this is a valid error message due to the replica being >> stale for a very long time and records actually being purged from the >> changelog before they were replicated. >> >> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:06.888679268 -0500] NSMMReplicationPlugin - >> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >> Data required to update replica has been purged from the changelog. >> The replica must be reinitialized. >> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:06.960804253 -0500] NSMMReplicationPlugin - >> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa01:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> >> Okay, so your replication agreements/servers are not in sync. I suspect you >> created a new replica and used that to initialize a valid replica which >> broke things. Something like that. You need to find a "good" replica >> server and reinitialize the other replicas from that server. These errors >> needs to addressed asap, as it's halting replication for those agreements >> which explains the "instability" you are describing. >> >> Mark >> >> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:08.960622608 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:08.968927168 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:08.976952118 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 6 14:16:09 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:09.972315877 -0500] NSMMReplicationPlugin - >> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa01:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:10.034810948 -0500] >> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >> If replication stops, the consumer may need to be reinitialized. >> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:10.040020359 -0500] NSMMReplicationPlugin - >> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >> as up to date, or we purged >> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:10.042846879 -0500] NSMMReplicationPlugin - >> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >> Data required to update replica has been purged from the changelog. >> The replica must be reinitialized. >> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:13.013253769 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:13.021514225 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:13.027521508 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:13.110566247 -0500] NSMMReplicationPlugin - >> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa01:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:14.179819300 -0500] >> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >> If replication stops, the consumer may need to be reinitialized. >> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:14.188353328 -0500] NSMMReplicationPlugin - >> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >> as up to date, or we purged >> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:14.196463928 -0500] NSMMReplicationPlugin - >> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >> Data required to update replica has been purged from the changelog. >> The replica must be reinitialized. >> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:17.068292919 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:17.071241757 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >> [06/Mar/2017:14:16:17.073793922 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> ------ >> >> >> Thanks in advance!!! >> >> -- Chris >> >> From peljasz at yahoo.co.uk Tue Mar 7 21:37:58 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 7 Mar 2017 21:37:58 +0000 Subject: [Freeipa-users] slapi_ldap_bind - Error: could not send startTLS request In-Reply-To: <2a5e833a-5c7d-3385-bf17-620cd42aa805@redhat.com> References: <2a5e833a-5c7d-3385-bf17-620cd42aa805@redhat.com> Message-ID: <3a5c6a2b-8a9e-fb2b-04a9-fe3150835804@yahoo.co.uk> On 06/03/17 20:11, Rob Crittenden wrote: > lejeczek wrote: >> hi everyone >> I've seemingly finely working domain, I mean it all seem fine to me, >> except for: >> >> [04/Mar/2017:14:26:47.439218725 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:26:47.441155853 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:31:47.454016982 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:31:47.482477473 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:36:46.458508994 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:36:46.479878884 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:41:47.389700728 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:41:47.394379376 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> >> being logged quite frequently, as you can see. Setup: >> >> ipa-client-4.4.0-14.el7.centos.4.x86_64 >> ipa-client-common-4.4.0-14.el7.centos.4.noarch >> ipa-common-4.4.0-14.el7.centos.4.noarch >> ipa-python-compat-4.4.0-14.el7.centos.4.noarch >> ipa-server-4.4.0-14.el7.centos.4.x86_64 >> ipa-server-common-4.4.0-14.el7.centos.4.noarch >> ipa-server-dns-4.4.0-14.el7.centos.4.noarch >> >> Replication, users, logins, all seem normal. But above bothers me as I >> am afraid it may one day turn out critical and brake stuff down. >> This is on the first server that initiated the domain, long time ago. >> There is a second server which logs the same, but only a few entries >> then goes quiet. >> Third server's error log is completely free from this error. >> >> Would appreciate all help. > The CA replication agreements are handled by ipa-csreplica-manage. You > may have leftover agreements from previous installs there. > > rob many thanks, should I be searching through ldap tree? If yes then where more less? $ ipa-csreplica-manage list shows only two servers, which would make sense, would add up, I think. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peljasz at yahoo.co.uk Tue Mar 7 21:48:59 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 7 Mar 2017 21:48:59 +0000 Subject: [Freeipa-users] slapi_ldap_bind - Error: could not send startTLS request In-Reply-To: <2a5e833a-5c7d-3385-bf17-620cd42aa805@redhat.com> References: <2a5e833a-5c7d-3385-bf17-620cd42aa805@redhat.com> Message-ID: <0e318ad4-f719-aed0-b35c-de911a5069a3@yahoo.co.uk> On 06/03/17 20:11, Rob Crittenden wrote: > lejeczek wrote: >> hi everyone >> I've seemingly finely working domain, I mean it all seem fine to me, >> except for: >> >> [04/Mar/2017:14:26:47.439218725 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:26:47.441155853 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:31:47.454016982 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:31:47.482477473 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:36:46.458508994 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:36:46.479878884 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:41:47.389700728 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> [04/Mar/2017:14:41:47.394379376 +0000] slapi_ldap_bind - Error: could >> not send startTLS request: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) >> >> being logged quite frequently, as you can see. Setup: >> >> ipa-client-4.4.0-14.el7.centos.4.x86_64 >> ipa-client-common-4.4.0-14.el7.centos.4.noarch >> ipa-common-4.4.0-14.el7.centos.4.noarch >> ipa-python-compat-4.4.0-14.el7.centos.4.noarch >> ipa-server-4.4.0-14.el7.centos.4.x86_64 >> ipa-server-common-4.4.0-14.el7.centos.4.noarch >> ipa-server-dns-4.4.0-14.el7.centos.4.noarch >> >> Replication, users, logins, all seem normal. But above bothers me as I >> am afraid it may one day turn out critical and brake stuff down. >> This is on the first server that initiated the domain, long time ago. >> There is a second server which logs the same, but only a few entries >> then goes quiet. >> Third server's error log is completely free from this error. >> >> Would appreciate all help. > The CA replication agreements are handled by ipa-csreplica-manage. You > may have leftover agreements from previous installs there. > > rob > I'm afraid I let over the years for some bits in the domain gone haywire. I found this: dn: cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x cn: ca objectClass: nsContainer objectClass: top dn: cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x cn: certprofiles objectClass: nsContainer objectClass: top dn: cn=caacls,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x cn: caacls objectClass: nsContainer objectClass: top dn: cn=cas+nsuniqueid=647ed0b1-b70911e6-b84df1c7-2176fa48,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x cn: cas objectClass: nsContainer objectClass: top dn: cn=cas,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x cn: cas objectClass: nsContainer objectClass: top dn: cn=IECUserRoles,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x description: User profile that includes IECUserRoles extension from request ipaCertProfileStoreIssued: TRUE cn: IECUserRoles objectClass: ipacertprofile objectClass: top dn: cn=caIPAserviceCert,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x description: Standard profile for network services ipaCertProfileStoreIssued: TRUE cn: caIPAserviceCert objectClass: ipacertprofile objectClass: top dn: ipaUniqueID=1ea0be16-fc01-11e5-a664-f04da240c1d2,cn=caacls,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x ipaMemberCertProfile: cn=caIPAserviceCert,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x ipaUniqueID: 1ea0be16-fc01-11e5-a664-f04da240c1d2 ipaEnabledFlag: TRUE hostCategory: all objectClass: ipaassociation objectClass: ipacaacl cn: hosts_services_caIPAserviceCert serviceCategory: all dn: cn=ipa,cn=cas+nsuniqueid=647ed0b1-b70911e6-b84df1c7-2176fa48,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x cn: ipa ipaCaId: 0725f730-9351-4115-aa68-ecb2f47dd805 ipaCaSubjectDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x objectClass: top objectClass: ipaca ipaCaIssuerDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x description: IPA CA dn: cn=ipa,cn=cas,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x cn: ipa ipaCaId: ed1bbc62-45c5-4d4a-96fb-0c16129dbad0 ipaCaSubjectDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x objectClass: top objectClass: ipaca ipaCaIssuerDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x description: IPA CA is this the culprit? b.w. L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mexigabacho at gmail.com Tue Mar 7 23:08:36 2017 From: mexigabacho at gmail.com (Christopher Young) Date: Tue, 7 Mar 2017 18:08:36 -0500 Subject: [Freeipa-users] Replication Issues In-Reply-To: References: Message-ID: I had attempted to do _just_ a re-initialize on orldc-prod-ipa02 (using --from orldc-prod-ipa01), but after it completes, I still end up with the same errors. What would be my next course of action? To clarify the error(s) on orldc-prod-ipa01 are: ----- Mar 7 18:04:53 orldc-prod-ipa01 ns-slapd: [07/Mar/2017:18:04:53.549127059 -0500] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa02:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. .... ----- On orldc-prod-ipa02, I get: ----- Mar 7 18:06:00 orldc-prod-ipa02 ns-slapd: [07/Mar/2017:18:06:00.290853165 -0500] NSMMReplicationPlugin - agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa01:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: [07/Mar/2017:18:06:01.715691409 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: [07/Mar/2017:18:06:01.720475590 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: [07/Mar/2017:18:06:01.728588145 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 7 18:06:04 orldc-prod-ipa02 ns-slapd: [07/Mar/2017:18:06:04.286539164 -0500] NSMMReplicationPlugin - agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" (orldc-prod-ipa01:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: [07/Mar/2017:18:06:05.328239468 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: [07/Mar/2017:18:06:05.330429534 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: [07/Mar/2017:18:06:05.333270479 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) failed. ----- I'm trying to figure out what my next step(s) would be in this situation. Would that be to completely remove those systems are replicas (orldc-prod-ipa02 and bohdc-prod-ipa01) and then completely recreate the replicas? I appreciate all the responses. I'm still trying to figure out what options to use for db2ldif, but I'm looking that up to at least try and look at the DBs. Thanks, Chris On Tue, Mar 7, 2017 at 4:23 PM, Mark Reynolds wrote: > > > On 03/07/2017 11:29 AM, Christopher Young wrote: >> Thank you very much for the response! >> >> To start: >> ---- >> [root at orldc-prod-ipa01 ~]# rpm -qa 389-ds-base >> 389-ds-base-1.3.5.10-18.el7_3.x86_64 >> ---- > You are on the latest version with the latest replication fixes. >> >> So, I believe a good part of my problem is that I'm not _positive_ >> which replica is good at this point (though my directory really isn't >> that huge). >> >> Do you have any pointers on a good method of comparing the directory >> data between them? I was wondering if anyone knows of any tools to >> facilitate that. I was thinking that it might make sense for me to >> dump the DB and restore, but I really don't know that procedure. As I >> mentioned, my directory really isn't that large at all, however I'm >> not positive the best bullet-item listed method to proceed. (I know >> I'm not helping things :) ) > Heh, well only you know what your data should be. You can always do a > db2ldif.pl on each server and compare the ldif files that are > generated. Then pick the one you think is the most up to date. > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html#Exporting-db2ldif > > Once you decide on a server, then you need to reinitialize all the other > servers/replicas from the "good" one. Use " ipa-replica-manage > re-initialize" for this. > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html#initialize > > That's it. > > Good luck, > Mark > >> >> Would it be acceptable to just 'assume' one of the replicas is good >> (taking the risk of whatever missing pieces I'll have to deal with), >> completely removing the others, and then rebuilding the replicas from >> scratch? >> >> If I go that route, what are the potential pitfalls? >> >> >> I want to decide on an approach and try and resolve this once and for all. >> >> Thanks again! It really is appreciated as I've been frustrated with >> this for a while now. >> >> -- Chris >> >> On Tue, Mar 7, 2017 at 8:45 AM, Mark Reynolds wrote: >>> What version of 389-ds-base are you using? >>> >>> rpm -qa | grep 389-ds-base >>> >>> >>> comments below.. >>> >>> On 03/06/2017 02:37 PM, Christopher Young wrote: >>> >>> I've seen similar posts, but in the interest of asking fresh and >>> trying to understand what is going on, I thought I would ask for >>> advice on how best to handle this situation. >>> >>> In the interest of providing some history: >>> I have three (3) FreeIPA servers. Everything is running 4.4.0 now. >>> The originals (orldc-prod-ipa01, orldc-prod-ipa02) were upgraded from >>> the 3.x branch quite a while back. Everything had been working fine, >>> however I ran into a replication issue (that I _think_ may have been a >>> result of IPv6 being disabled by my default Ansible roles). I thought >>> I had resolved that by reinitializing the 2nd replica, >>> orldc-prod-ipa02. >>> >>> In any case, I feel like the replication has never been fully stable >>> since then, and I have all types of errors in messages that indicate >>> something is off. I had single introduced a 3rd replica such that the >>> agreements would look like so: >>> >>> orldc-prod-ipa01 -> orldc-prod-ipa02 ---> bohdc-prod-ipa01 >>> >>> It feels like orldc-prod-ipa02 & bohdc-prod-ipa01 are out of sync. >>> I've tried reinitializing them in order but with no positive results. >>> At this point, I feel like I'm ready to 'bite the bullet' and tear >>> them down quickly (remove them from IPA, delete the local >>> DBs/directories) and rebuild them from scratch. >>> >>> I want to minimize my impact as much as possible (which I can somewhat >>> do by redirecting LDAP/DNS request via my load-balancers temporarily) >>> and do this right. >>> >>> (Getting to the point...) >>> >>> I'd like advice on the order of operations to do this. Give the >>> errors (I'll include samples at the bottom of this message), does it >>> make sense for me to remove the replicas on bohdc-prod-ipa01 & >>> orldc-prod-ipa02 (in that order), wipe out any directories/residual >>> pieces (I'd need some idea of what to do there), and then create new >>> replicas? -OR- Should I export/backup the LDAP DB and rebuild >>> everything from scratch. >>> >>> I need advice and ideas. Furthermore, if there is someone with >>> experience in this that would be interested in making a little money >>> on the side, let me know, because having an extra brain and set of >>> hands would be welcome. >>> >>> DETAILS: >>> ================= >>> >>> >>> ERRORS I see on orldc-prod-ipa01 (the one whose LDAP DB seems the most >>> up-to-date since my changes are usually directed at it): >>> ------ >>> Mar 6 14:36:24 orldc-prod-ipa01 ns-slapd: >>> [06/Mar/2017:14:36:24.434956575 -0500] NSMMReplicationPlugin - >>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>> (orldc-prod-ipa02:389): The remote replica has a different database >>> generation ID than the local database. You may have to reinitialize >>> the remote replica, or the local replica. >>> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO >>> LDAP bind... >>> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO >>> Commencing sync process >>> Mar 6 14:36:26 orldc-prod-ipa01 ipa-dnskeysyncd: >>> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump >>> is done, sychronizing with ODS and BIND >>> Mar 6 14:36:27 orldc-prod-ipa01 ns-slapd: >>> [06/Mar/2017:14:36:27.799519203 -0500] NSMMReplicationPlugin - >>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>> (orldc-prod-ipa02:389): The remote replica has a different database >>> generation ID than the local database. You may have to reinitialize >>> the remote replica, or the local replica. >>> Mar 6 14:36:30 orldc-prod-ipa01 ns-slapd: >>> [06/Mar/2017:14:36:30.994760069 -0500] NSMMReplicationPlugin - >>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>> (orldc-prod-ipa02:389): The remote replica has a different database >>> generation ID than the local database. You may have to reinitialize >>> the remote replica, or the local replica. >>> Mar 6 14:36:34 orldc-prod-ipa01 ns-slapd: >>> [06/Mar/2017:14:36:34.940115481 -0500] NSMMReplicationPlugin - >>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>> (orldc-prod-ipa02:389): The remote replica has a different database >>> generation ID than the local database. You may have to reinitialize >>> the remote replica, or the local replica. >>> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client >>> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of >>> '56.10.in-addr.arpa/IN': AXFR-style IXFR started >>> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client >>> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of >>> '56.10.in-addr.arpa/IN': AXFR-style IXFR ended >>> Mar 6 14:36:37 orldc-prod-ipa01 ns-slapd: >>> [06/Mar/2017:14:36:37.977875463 -0500] NSMMReplicationPlugin - >>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>> (orldc-prod-ipa02:389): The remote replica has a different database >>> generation ID than the local database. You may have to reinitialize >>> the remote replica, or the local replica. >>> Mar 6 14:36:40 orldc-prod-ipa01 ns-slapd: >>> [06/Mar/2017:14:36:40.999275184 -0500] NSMMReplicationPlugin - >>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>> (orldc-prod-ipa02:389): The remote replica has a different database >>> generation ID than the local database. You may have to reinitialize >>> the remote replica, or the local replica. >>> Mar 6 14:36:45 orldc-prod-ipa01 ns-slapd: >>> [06/Mar/2017:14:36:45.211260414 -0500] NSMMReplicationPlugin - >>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>> (orldc-prod-ipa02:389): The remote replica has a different database >>> generation ID than the local database. You may have to reinitialize >>> the remote replica, or the local replica. >>> ------ >>> >>> These messages indicate that the replica does not have the same database as >>> the master. So either the master or the replica needs to be reinitialized., >>> More on this below... >>> >>> >>> Errors on orldc-prod-ipa02: >>> ------ >>> r 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: ipa : INFO >>> Commencing sync process >>> Mar 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: >>> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump >>> is done, sychronizing with ODS and BIND >>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:05.934405274 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:05.937278142 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:05.939434025 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> >>> These are harmless "errors" which have been removed in newer versions of >>> 389-ds-base. >>> >>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:06.882795654 -0500] >>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>> If replication stops, the consumer may need to be reinitialized. >>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:06.886029272 -0500] NSMMReplicationPlugin - >>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>> as up to date, or we purged >>> >>> This "could" also be a known issue that is fixed in newer versions of >>> 389-ds-base. Or this is a valid error message due to the replica being >>> stale for a very long time and records actually being purged from the >>> changelog before they were replicated. >>> >>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:06.888679268 -0500] NSMMReplicationPlugin - >>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>> Data required to update replica has been purged from the changelog. >>> The replica must be reinitialized. >>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:06.960804253 -0500] NSMMReplicationPlugin - >>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>> (orldc-prod-ipa01:389): The remote replica has a different database >>> generation ID than the local database. You may have to reinitialize >>> the remote replica, or the local replica. >>> >>> Okay, so your replication agreements/servers are not in sync. I suspect you >>> created a new replica and used that to initialize a valid replica which >>> broke things. Something like that. You need to find a "good" replica >>> server and reinitialize the other replicas from that server. These errors >>> needs to addressed asap, as it's halting replication for those agreements >>> which explains the "instability" you are describing. >>> >>> Mark >>> >>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:08.960622608 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:08.968927168 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:08.976952118 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> Mar 6 14:16:09 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:09.972315877 -0500] NSMMReplicationPlugin - >>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>> (orldc-prod-ipa01:389): The remote replica has a different database >>> generation ID than the local database. You may have to reinitialize >>> the remote replica, or the local replica. >>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:10.034810948 -0500] >>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>> If replication stops, the consumer may need to be reinitialized. >>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:10.040020359 -0500] NSMMReplicationPlugin - >>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>> as up to date, or we purged >>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:10.042846879 -0500] NSMMReplicationPlugin - >>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>> Data required to update replica has been purged from the changelog. >>> The replica must be reinitialized. >>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:13.013253769 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:13.021514225 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:13.027521508 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:13.110566247 -0500] NSMMReplicationPlugin - >>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>> (orldc-prod-ipa01:389): The remote replica has a different database >>> generation ID than the local database. You may have to reinitialize >>> the remote replica, or the local replica. >>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:14.179819300 -0500] >>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>> If replication stops, the consumer may need to be reinitialized. >>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:14.188353328 -0500] NSMMReplicationPlugin - >>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>> as up to date, or we purged >>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:14.196463928 -0500] NSMMReplicationPlugin - >>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>> Data required to update replica has been purged from the changelog. >>> The replica must be reinitialized. >>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:17.068292919 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:17.071241757 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>> [06/Mar/2017:14:16:17.073793922 -0500] attrlist_replace - attr_replace >>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>> failed. >>> ------ >>> >>> >>> Thanks in advance!!! >>> >>> -- Chris >>> >>> > From mareynol at redhat.com Wed Mar 8 00:40:03 2017 From: mareynol at redhat.com (Mark Reynolds) Date: Tue, 7 Mar 2017 19:40:03 -0500 Subject: [Freeipa-users] Replication Issues In-Reply-To: References: Message-ID: <8e21c675-349b-a46c-95cb-97fd7ae165a8@redhat.com> On 03/07/2017 06:08 PM, Christopher Young wrote: > I had attempted to do _just_ a re-initialize on orldc-prod-ipa02 > (using --from orldc-prod-ipa01), but after it completes, I still end > up with the same errors. What would be my next course of action? I have no idea. Sounds like the reinit did not work if you keep getting the same errors, or you reinited the wrong server (or the wrong direction) Remember you have to reinit ALL the replicas - not just one. > > To clarify the error(s) on orldc-prod-ipa01 are: > ----- > Mar 7 18:04:53 orldc-prod-ipa01 ns-slapd: > [07/Mar/2017:18:04:53.549127059 -0500] NSMMReplicationPlugin - > agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa02:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > .... > ----- > > > On orldc-prod-ipa02, I get: > ----- > Mar 7 18:06:00 orldc-prod-ipa02 ns-slapd: > [07/Mar/2017:18:06:00.290853165 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa01:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: > [07/Mar/2017:18:06:01.715691409 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: > [07/Mar/2017:18:06:01.720475590 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: > [07/Mar/2017:18:06:01.728588145 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 7 18:06:04 orldc-prod-ipa02 ns-slapd: > [07/Mar/2017:18:06:04.286539164 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > (orldc-prod-ipa01:389): The remote replica has a different database > generation ID than the local database. You may have to reinitialize > the remote replica, or the local replica. > Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: > [07/Mar/2017:18:06:05.328239468 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: > [07/Mar/2017:18:06:05.330429534 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: > [07/Mar/2017:18:06:05.333270479 -0500] attrlist_replace - attr_replace > (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > failed. > ----- > > > I'm trying to figure out what my next step(s) would be in this > situation. Would that be to completely remove those systems are > replicas (orldc-prod-ipa02 and bohdc-prod-ipa01) and then completely > recreate the replicas? > > I appreciate all the responses. I'm still trying to figure out what > options to use for db2ldif, but I'm looking that up to at least try > and look at the DBs. > > Thanks, > > Chris > > On Tue, Mar 7, 2017 at 4:23 PM, Mark Reynolds wrote: >> >> On 03/07/2017 11:29 AM, Christopher Young wrote: >>> Thank you very much for the response! >>> >>> To start: >>> ---- >>> [root at orldc-prod-ipa01 ~]# rpm -qa 389-ds-base >>> 389-ds-base-1.3.5.10-18.el7_3.x86_64 >>> ---- >> You are on the latest version with the latest replication fixes. >>> So, I believe a good part of my problem is that I'm not _positive_ >>> which replica is good at this point (though my directory really isn't >>> that huge). >>> >>> Do you have any pointers on a good method of comparing the directory >>> data between them? I was wondering if anyone knows of any tools to >>> facilitate that. I was thinking that it might make sense for me to >>> dump the DB and restore, but I really don't know that procedure. As I >>> mentioned, my directory really isn't that large at all, however I'm >>> not positive the best bullet-item listed method to proceed. (I know >>> I'm not helping things :) ) >> Heh, well only you know what your data should be. You can always do a >> db2ldif.pl on each server and compare the ldif files that are >> generated. Then pick the one you think is the most up to date. >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html#Exporting-db2ldif >> >> Once you decide on a server, then you need to reinitialize all the other >> servers/replicas from the "good" one. Use " ipa-replica-manage >> re-initialize" for this. >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html#initialize >> >> That's it. >> >> Good luck, >> Mark >> >>> Would it be acceptable to just 'assume' one of the replicas is good >>> (taking the risk of whatever missing pieces I'll have to deal with), >>> completely removing the others, and then rebuilding the replicas from >>> scratch? >>> >>> If I go that route, what are the potential pitfalls? >>> >>> >>> I want to decide on an approach and try and resolve this once and for all. >>> >>> Thanks again! It really is appreciated as I've been frustrated with >>> this for a while now. >>> >>> -- Chris >>> >>> On Tue, Mar 7, 2017 at 8:45 AM, Mark Reynolds wrote: >>>> What version of 389-ds-base are you using? >>>> >>>> rpm -qa | grep 389-ds-base >>>> >>>> >>>> comments below.. >>>> >>>> On 03/06/2017 02:37 PM, Christopher Young wrote: >>>> >>>> I've seen similar posts, but in the interest of asking fresh and >>>> trying to understand what is going on, I thought I would ask for >>>> advice on how best to handle this situation. >>>> >>>> In the interest of providing some history: >>>> I have three (3) FreeIPA servers. Everything is running 4.4.0 now. >>>> The originals (orldc-prod-ipa01, orldc-prod-ipa02) were upgraded from >>>> the 3.x branch quite a while back. Everything had been working fine, >>>> however I ran into a replication issue (that I _think_ may have been a >>>> result of IPv6 being disabled by my default Ansible roles). I thought >>>> I had resolved that by reinitializing the 2nd replica, >>>> orldc-prod-ipa02. >>>> >>>> In any case, I feel like the replication has never been fully stable >>>> since then, and I have all types of errors in messages that indicate >>>> something is off. I had single introduced a 3rd replica such that the >>>> agreements would look like so: >>>> >>>> orldc-prod-ipa01 -> orldc-prod-ipa02 ---> bohdc-prod-ipa01 >>>> >>>> It feels like orldc-prod-ipa02 & bohdc-prod-ipa01 are out of sync. >>>> I've tried reinitializing them in order but with no positive results. >>>> At this point, I feel like I'm ready to 'bite the bullet' and tear >>>> them down quickly (remove them from IPA, delete the local >>>> DBs/directories) and rebuild them from scratch. >>>> >>>> I want to minimize my impact as much as possible (which I can somewhat >>>> do by redirecting LDAP/DNS request via my load-balancers temporarily) >>>> and do this right. >>>> >>>> (Getting to the point...) >>>> >>>> I'd like advice on the order of operations to do this. Give the >>>> errors (I'll include samples at the bottom of this message), does it >>>> make sense for me to remove the replicas on bohdc-prod-ipa01 & >>>> orldc-prod-ipa02 (in that order), wipe out any directories/residual >>>> pieces (I'd need some idea of what to do there), and then create new >>>> replicas? -OR- Should I export/backup the LDAP DB and rebuild >>>> everything from scratch. >>>> >>>> I need advice and ideas. Furthermore, if there is someone with >>>> experience in this that would be interested in making a little money >>>> on the side, let me know, because having an extra brain and set of >>>> hands would be welcome. >>>> >>>> DETAILS: >>>> ================= >>>> >>>> >>>> ERRORS I see on orldc-prod-ipa01 (the one whose LDAP DB seems the most >>>> up-to-date since my changes are usually directed at it): >>>> ------ >>>> Mar 6 14:36:24 orldc-prod-ipa01 ns-slapd: >>>> [06/Mar/2017:14:36:24.434956575 -0500] NSMMReplicationPlugin - >>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>> generation ID than the local database. You may have to reinitialize >>>> the remote replica, or the local replica. >>>> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO >>>> LDAP bind... >>>> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO >>>> Commencing sync process >>>> Mar 6 14:36:26 orldc-prod-ipa01 ipa-dnskeysyncd: >>>> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump >>>> is done, sychronizing with ODS and BIND >>>> Mar 6 14:36:27 orldc-prod-ipa01 ns-slapd: >>>> [06/Mar/2017:14:36:27.799519203 -0500] NSMMReplicationPlugin - >>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>> generation ID than the local database. You may have to reinitialize >>>> the remote replica, or the local replica. >>>> Mar 6 14:36:30 orldc-prod-ipa01 ns-slapd: >>>> [06/Mar/2017:14:36:30.994760069 -0500] NSMMReplicationPlugin - >>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>> generation ID than the local database. You may have to reinitialize >>>> the remote replica, or the local replica. >>>> Mar 6 14:36:34 orldc-prod-ipa01 ns-slapd: >>>> [06/Mar/2017:14:36:34.940115481 -0500] NSMMReplicationPlugin - >>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>> generation ID than the local database. You may have to reinitialize >>>> the remote replica, or the local replica. >>>> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client >>>> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of >>>> '56.10.in-addr.arpa/IN': AXFR-style IXFR started >>>> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client >>>> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of >>>> '56.10.in-addr.arpa/IN': AXFR-style IXFR ended >>>> Mar 6 14:36:37 orldc-prod-ipa01 ns-slapd: >>>> [06/Mar/2017:14:36:37.977875463 -0500] NSMMReplicationPlugin - >>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>> generation ID than the local database. You may have to reinitialize >>>> the remote replica, or the local replica. >>>> Mar 6 14:36:40 orldc-prod-ipa01 ns-slapd: >>>> [06/Mar/2017:14:36:40.999275184 -0500] NSMMReplicationPlugin - >>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>> generation ID than the local database. You may have to reinitialize >>>> the remote replica, or the local replica. >>>> Mar 6 14:36:45 orldc-prod-ipa01 ns-slapd: >>>> [06/Mar/2017:14:36:45.211260414 -0500] NSMMReplicationPlugin - >>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>> generation ID than the local database. You may have to reinitialize >>>> the remote replica, or the local replica. >>>> ------ >>>> >>>> These messages indicate that the replica does not have the same database as >>>> the master. So either the master or the replica needs to be reinitialized., >>>> More on this below... >>>> >>>> >>>> Errors on orldc-prod-ipa02: >>>> ------ >>>> r 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: ipa : INFO >>>> Commencing sync process >>>> Mar 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: >>>> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump >>>> is done, sychronizing with ODS and BIND >>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:05.934405274 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:05.937278142 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:05.939434025 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> >>>> These are harmless "errors" which have been removed in newer versions of >>>> 389-ds-base. >>>> >>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:06.882795654 -0500] >>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>>> If replication stops, the consumer may need to be reinitialized. >>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:06.886029272 -0500] NSMMReplicationPlugin - >>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>>> as up to date, or we purged >>>> >>>> This "could" also be a known issue that is fixed in newer versions of >>>> 389-ds-base. Or this is a valid error message due to the replica being >>>> stale for a very long time and records actually being purged from the >>>> changelog before they were replicated. >>>> >>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:06.888679268 -0500] NSMMReplicationPlugin - >>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>>> Data required to update replica has been purged from the changelog. >>>> The replica must be reinitialized. >>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:06.960804253 -0500] NSMMReplicationPlugin - >>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>> (orldc-prod-ipa01:389): The remote replica has a different database >>>> generation ID than the local database. You may have to reinitialize >>>> the remote replica, or the local replica. >>>> >>>> Okay, so your replication agreements/servers are not in sync. I suspect you >>>> created a new replica and used that to initialize a valid replica which >>>> broke things. Something like that. You need to find a "good" replica >>>> server and reinitialize the other replicas from that server. These errors >>>> needs to addressed asap, as it's halting replication for those agreements >>>> which explains the "instability" you are describing. >>>> >>>> Mark >>>> >>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:08.960622608 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:08.968927168 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:08.976952118 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> Mar 6 14:16:09 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:09.972315877 -0500] NSMMReplicationPlugin - >>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>> (orldc-prod-ipa01:389): The remote replica has a different database >>>> generation ID than the local database. You may have to reinitialize >>>> the remote replica, or the local replica. >>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:10.034810948 -0500] >>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>>> If replication stops, the consumer may need to be reinitialized. >>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:10.040020359 -0500] NSMMReplicationPlugin - >>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>>> as up to date, or we purged >>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:10.042846879 -0500] NSMMReplicationPlugin - >>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>>> Data required to update replica has been purged from the changelog. >>>> The replica must be reinitialized. >>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:13.013253769 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:13.021514225 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:13.027521508 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:13.110566247 -0500] NSMMReplicationPlugin - >>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>> (orldc-prod-ipa01:389): The remote replica has a different database >>>> generation ID than the local database. You may have to reinitialize >>>> the remote replica, or the local replica. >>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:14.179819300 -0500] >>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>>> If replication stops, the consumer may need to be reinitialized. >>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:14.188353328 -0500] NSMMReplicationPlugin - >>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>>> as up to date, or we purged >>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:14.196463928 -0500] NSMMReplicationPlugin - >>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>>> Data required to update replica has been purged from the changelog. >>>> The replica must be reinitialized. >>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:17.068292919 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:17.071241757 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>>> [06/Mar/2017:14:16:17.073793922 -0500] attrlist_replace - attr_replace >>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>> failed. >>>> ------ >>>> >>>> >>>> Thanks in advance!!! >>>> >>>> -- Chris >>>> >>>> From lkrispen at redhat.com Wed Mar 8 08:43:24 2017 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 08 Mar 2017 09:43:24 +0100 Subject: [Freeipa-users] consumer replica which does not show up in ruv list In-Reply-To: References: <8346bc89-6c4d-c33a-0793-0b26ae30b56c@yahoo.co.uk> <20170307123924.GA26633@dhcp129-180.brq.redhat.com> <527673f4-e1be-735a-cf83-edba354ef2ce@yahoo.co.uk> <58BEE45D.7060607@redhat.com> Message-ID: <58BFC42C.9080009@redhat.com> On 03/07/2017 09:21 PM, lejeczek wrote: > > > On 07/03/17 16:48, Ludwig Krispenz wrote: >> >> On 03/07/2017 05:29 PM, lejeczek wrote: >>> >>> >>> On 07/03/17 12:39, Martin Babinsky wrote: >>>> On Tue, Mar 07, 2017 at 09:55:52AM +0000, lejeczek wrote: >>>>> hi, >>>>> >>>>> I presume I need to use ldapmodify/delete? >>>>> I found this(obfuscated by me): >>>>> >>>>> cn=dzien.priv.xx.xx.priv.xx.xx.x+nsuniqueid=9e47680e-296e11e6-83a59f45-6ec26a1e,cn=masters,cn=ipa,cn=etc,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >>>>> >>>>> >>>>> To confirm? Would removing it fix the problem? I'm probably >>>>> missing something >>>>> else, aren't I? >>>>> >>>>> many thank, >>>>> L >>>>> -- >>>>> 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 >>>> >>>> That seems like a replication conflict. Consult the following guide >>>> to solve >>>> it: >>>> >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >>>> >>> I'm not sure whether I'm dealing with single or multi-valued DN and >>> I should rename+keep original copy(following that doc) or simply >>> remove that DN. >> this is something which cannot be generally answered, you need to >> look at the specific entries. In the case of conflicts you always >> have entries like >> cn=xxxx, and >> cn=xxxx+nsuniqueid=nnnnnnnn-nnnnnnn-nnnnnnn-nnnnnn, >> >> and usually they are created if the same entry is added at the same >> time on two replicas, then they are identical and you can just delete >> the conflict entry. Only if you want to keep both entries you need to >> rename the conflict. > > to confirm - I presume this should be a recursive deletion with '-r' , > the whole lot, right? I would not recommend this before examining what the "whole lot", you need to spend a bit time in examining the state of your data, if there are nodes below the conflict entries are tehy conflicts as well, can they be deleted or should they be moved to the valid entry first, .... ? > thx, > L. > >>> >>>> Just a side question, how did you end up with such entry? Did you >>>> happen to upgrade >>>> multiple IPA masters at once? >>>> >>> >> > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -------------- next part -------------- An HTML attachment was scrubbed... URL: From barrykfl at gmail.com Wed Mar 8 11:18:27 2017 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 8 Mar 2017 19:18:27 +0800 Subject: [Freeipa-users] Replica fail to create , all new cert already inside Message-ID: Hi: I already done input new cert but ipa-replica-prepare central03.ABC.com (ipa 3.0) it fail with the error as below: which "location" I should check the old cert still inside some where Below I already input CA / server cert ..and nssdb poting is right ..already spent serveral days to check where is it I also try direct use pfx for the cert directly but same error comesout...seem it still use old cert to compare. Any idea ? many thanks /var/lib/pki-ca/alias /etc/dirsrv/slapd-PKI-IPA/ /etc/dirsrv/slapd-ABC-COM/ /etc/httpd/alias/ /etc/pki/nssdb/ I use similar commands as below: and follow steps here: https web side already using new and dirsvr no error on starting only I cannot do replicas . https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 certutil -A -d /var/lib/pki-ca/alias/ -n 'EXT-CA' -t CT,C,C -a -i /root/ca.crt ipa : ERROR cert validation failed for "CN=central.ABC.com,O= ABC.COM" ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.) preparation of replica failed: cannot connect to ' https://central.ABCcom:9444/ca/ee/ca/profileSubmitSSLClient': (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. Regards Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at jacobdevans.com Tue Mar 7 15:35:07 2017 From: freeipa at jacobdevans.com (Jake) Date: Tue, 7 Mar 2017 10:35:07 -0500 (EST) Subject: [Freeipa-users] attrlist_replace - attr_replace (nsslapd-referral ???? Message-ID: <944420526.8264.1488900907850@lux.jacobdevans.com> I have no idea what this means but it is causing issues with a replica Mar 07 10:27:02 dc2-rd-ipa01.ipa.example.com ns-slapd[2266]: [07/Mar/2017:10:27:02.158131947 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://dc1-rd-ipa01.ipa.example.com:389/dc%3Dipa%2Cdc%3Dexample%2Cdc%3Dcom) failed. Mar 07 10:27:02 dc2-rd-ipa01.ipa.example.com ns-slapd[2266]: [07/Mar/2017:10:27:02.161287591 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://dc1-rd-ipa01.ipa.example.com:389/dc%3Dipa%2Cdc%3Dexample%2Cdc%3Dcom) failed. Mar 07 10:27:02 dc2-rd-ipa01.ipa.example.com ns-slapd[2266]: [07/Mar/2017:10:27:02.163705427 -0500] attrlist_replace - attr_replace (nsslapd-referral, ldap://dc1-rd-ipa01.ipa.example.com:389/dc%3Dipa%2Cdc%3Dexample%2Cdc%3Dcom) failed. dc1-rd-ipa.example.com = primary original server dc2-rd-ipa.example.com = replica Any direction is appreciated, I went and reloaded this replica and am receive this same error afterwards. All servers running 4.4.0, most were upgraded from 4.2.0 Thanks, -Jake -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ronald.Wimmer at oebb.at Wed Mar 8 13:05:14 2017 From: Ronald.Wimmer at oebb.at (Wimmer Ronald (BCC.B.SO)) Date: Wed, 8 Mar 2017 13:05:14 +0000 Subject: [Freeipa-users] External DNS and replication Message-ID: <97E471CB191D044F9F018C77836CF85B8A03E282@ARSEX004.oebb.at> Hi, I am using FreeIPA with external DNS. Is it ok to balance the requests between master and replica with DNS SRV records like this: _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net. _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net. _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa1.example.net. _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa1.example.net. _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net. _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net. _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa2.example.net. _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa2.example.net. _kerberos.example.net. 86400 IN TXT "example.net" ipa-ca.example.net. 86400 IN A 10.66.39.130 What about the "ipa-ca" entry? Regards, Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Mar 8 13:54:16 2017 From: mbasti at redhat.com (Martin Basti) Date: Wed, 8 Mar 2017 14:54:16 +0100 Subject: [Freeipa-users] External DNS and replication In-Reply-To: <97E471CB191D044F9F018C77836CF85B8A03E282@ARSEX004.oebb.at> References: <97E471CB191D044F9F018C77836CF85B8A03E282@ARSEX004.oebb.at> Message-ID: On 08.03.2017 14:05, Wimmer Ronald (BCC.B.SO) wrote: > > Hi, > > > > I am using FreeIPA with external DNS. Is it ok to balance the requests > between master and replica with DNS SRV records like this: > > > > _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. > > _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. > > _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. > > _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. > > _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net. > > _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net. > > _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa1.example.net. > > _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa1.example.net. > > > > _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. > > _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. > > _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. > > _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. > > _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net. > > _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net. > > _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa2.example.net. > > _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa2.example.net. > > > > _kerberos.example.net. 86400 IN TXT "example.net" > Looks good to me > ipa-ca.example.net. 86400 IN A 10.66.39.130 > > > > What about the ?ipa-ca? entry? > ipa-ca should contain all A/AAAA records of CA replicas IPA4.4+ support command `ipa dns-update-system-records --dry-run` to get all required records > > > > Regards, > > Ronald > > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From pgb205 at yahoo.com Wed Mar 8 14:22:36 2017 From: pgb205 at yahoo.com (pgb205) Date: Wed, 8 Mar 2017 14:22:36 +0000 (UTC) Subject: [Freeipa-users] Can't start dirsrv. Can't force reinitialize References: <1968016157.1684761.1488982956465.ref@mail.yahoo.com> Message-ID: <1968016157.1684761.1488982956465@mail.yahoo.com> ipactl startExisting service file detected!Assuming stale, cleaning and proceedingStarting Directory ServiceFailed to read data from service file: Failed to get list of services to probe status!Configured hostname this_server.domain' does not match any master server in LDAP: in /var/log/dirsrv/domain/errors [08/Mar/2017:14:13:04 +0000] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: for replica o=ipaca there were some differences between the changelog max RUV and the database RUV. ?If there are obsolete elements in the database RUV, you should remove them using the CLEANALLRUV task. ?If they are not obsolete, you should check their status to see why there are no changes from those servers in the changelog.[08/Mar/2017:14:13:04 +0000] attrlist_replace - attr_replace (nsslapd-referral, ldap://other_replica.domain:389/o%3Dipaca) failed.[08/Mar/2017:14:13:04 +0000] attrlist_replace - attr_replace (nsslapd-referral, ldap://other_replica.domain:389/o%3Dipaca) failed.[08/Mar/2017:14:13:04 +0000] - slapd started. ?Listening on All Interfaces port 389 for LDAP requests[08/Mar/2017:14:13:04 +0000] - Listening on All Interfaces port 636 for LDAPS requests[08/Mar/2017:14:13:04 +0000] - Listening on /var/run/slapd-domain.socket for LDAPI requests[08/Mar/2017:14:13:04 +0000] agmt="cn=masterAgreement1other_replica.domain-pki-tomcat" (ipa-x2:389) - Can't locate CSN 55a420ef000400290000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.[08/Mar/2017:14:13:04 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=masterAgreement1-other_replica.domain-pki-tomcat" (ipa-x2:389): CSN 55a420ef000400290000 not found, we aren't as up to date, or we purged[08/Mar/2017:14:13:04 +0000] NSMMReplicationPlugin - agmt="cn=masterAgreement1-other_replica.domain-pki-tomcat" (other_replica:389): Data required to update replica has been purged. The replica must be reinitialized.[08/Mar/2017:14:13:04 +0000] NSMMReplicationPlugin - agmt="cn=masterAgreement1-other_replica.domain-pki-tomcat" (ipa-x2:389): Incremental update failed and requires administrator action when trying to force reinitialize [root at this_replica~]# ipa-replica-manage re-initialize --from=other_replica.domainipa: WARNING: session memcached servers not runningConnection timed out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cherdt at umn.edu Wed Mar 8 15:26:42 2017 From: cherdt at umn.edu (Chris Herdt) Date: Wed, 8 Mar 2017 09:26:42 -0600 Subject: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening In-Reply-To: <99c69b0d-d500-2484-6899-0c07287cbc0a@redhat.com> References: <35945c0c-e1e2-3d34-cde3-2eeae5408a15@redhat.com> <92f941ef-142e-1084-ecfd-66a715abc587@redhat.com> <99c69b0d-d500-2484-6899-0c07287cbc0a@redhat.com> Message-ID: On Mon, Mar 6, 2017 at 3:20 AM, Tomas Krizek wrote: > On 03/04/2017 12:51 AM, Chris Herdt wrote: >> On Fri, Mar 3, 2017 at 4:22 AM, Tomas Krizek wrote: >>> >>> On 03/02/2017 06:25 PM, Chris Herdt wrote: >>> >>> On Thu, Mar 2, 2017 at 10:06 AM, Martin Basti wrote: >>>> >>>> >>>> >>>> On 02.03.2017 16:55, Chris Herdt wrote: >>>> >>>> >>>> >>>> On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 02.03.2017 01:07, Chris Herdt wrote: >>>>> >>>>> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a FreeIPA 3.0.0 master on CentOS 6.8 following the steps at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html >>>>> >>>>> At this step: >>>>> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir /var/lib/ipa/replica-info-replicaname.example.com.gpg >>>>> >>>>> I get the error: >>>>> ERROR cannot connect to 'ldaps://master.example.com' >>>>> >>>>> I ran ipa-replica-conncheck and found that port 636 is not accessible: >>>>> Port check failed! Inaccessible port(s): 636 (TCP) >>>>> >>>>> The port is not blocked. I'm wondering where in the configuration for FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there is a way I can specify to use port 389 for setting up the replica. >>>>> >>>>> Thanks! >>>>> >>>>> -- >>>>> Chris Herdt >>>>> Systems Administrator >>>>> >>>>> >>>>> >>>>> Hello, >>>>> this is known issue only in FreeIPA 4.4.x, this will be fixed in next minor update which should be released soon to RHEL7.3 (I don't know how fast it will be in Centos) >>>>> >>>>> so you can wait, or enable it manually (not nice) >>>>> >>>>> sorry for troubles >>>>> Martin >>>> >>>> >>>> Thanks for the reply! Before attempting this in my production environment, I had set up a similar configuration in a test environment (FreeIPA 3.0.0 master on CentOS 6.8, FreeIPA 4.4.0 replica on CentOS 7.3) and the ipa-replica-install went fine. I assumed this was an issue with my FreeIPA 3.0.0 production server. >>>> >>>> To enable the fix manually, I'm assuming I'd need to install FreeIPA from source on the intended replica? If I download the 4.4.3 release from https://pagure.io/freeipa/releases, will that be sufficient? >>>> >>>> Sorry, >>>> I probably misread what you wrote, I thought that port is closed on replica, but now I see that port is closed on 3.3.0 master, so this is something different. I'm not aware of any issue on 3.3.0 that should cause this. >>>> >>>> Could you check your configuration on 3.3.0 master? Is port opened on master? Do you have any errors in /var/log/dirsrv/slapd-*/errors log on master? >>>> >>>> Martin >>> >>> When I compare the errors file on my production environment and my test environment, I do note that the LDAPS entry is missing from my production environment: >>> >>> production: >>> [01/Mar/2017:17:30:07 -0600] - slapd started. Listening on All Interfaces port 389 for LDAP requests >>> [01/Mar/2017:17:30:07 -0600] - Listening on /var/run/slapd-PROD-EXAMPLE-COM.socket for LDAPI requests >>> >>> test: >>> [28/Feb/2017:13:37:50 -0600] - slapd started. Listening on All Interfaces port 389 for LDAP requests >>> [28/Feb/2017:13:37:50 -0600] - Listening on All Interfaces port 636 for LDAPS requests >>> [28/Feb/2017:13:37:50 -0600] - Listening on /var/run/slapd-TEST-EXAMPLE-COM.socket for LDAPI requests >>> >>> I'm not sure why it is missing though. Which config file(s) should I be checking? >>> >>> You can examine the file /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif to check if the Directory Server has LDAP configured correctly. In particular, you're interested in: >>> >>> - nsslapd-security in cn=config >>> - cn=encryption,cn=config >>> - cn=RSA,cn=encryption,cn=config >>> >>> Also, you can check if the certificate for LDAPS is available in the NSS database: >>> >>> certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L >> nsslapd-security was set to off. I set it to on, but SSL failed. >> >> There were no certificates listed--which I think explains why SSL >> failed--when running: >> certutil -d /etc/dirsrv/slapd-EXAMPLE-COM/ -L >> >> ipa-getcert list shows several certs, including one with >> location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS >> Certificate DB' -- I'm not sure where this cert exists though. >> >> I assume I need to get the NSS db to recognize the Server-Cert, for example: >> certutil -A -d /etc/dirsrv/slapd-EXAMPLE-COM -i ? > > You need a certificate and some Directory Server configuration. > > The DocText for #1365858 [1] describes how to turn on LDAPS manually. > Please beware, that this process was tested on IPA 4.4 and it might be a > bit different for older versions. > > [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1365858 > > P.S.: Sorry for sending the message twice, Chris. I forgot to keep the list in reply. > > -- > Tomas Krizek > > PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 > > The steps you provided worked perfectly on my FreeIPA 3.0.0 instance -- I was able to get LDAPS working and was then able to create the 4.4.0 replica without any further problems. Thanks much for your help! -- Chris Herdt Systems Administrator From mexigabacho at gmail.com Wed Mar 8 16:39:31 2017 From: mexigabacho at gmail.com (Christopher Young) Date: Wed, 8 Mar 2017 11:39:31 -0500 Subject: [Freeipa-users] Replication Issues In-Reply-To: <8e21c675-349b-a46c-95cb-97fd7ae165a8@redhat.com> References: <8e21c675-349b-a46c-95cb-97fd7ae165a8@redhat.com> Message-ID: My replication scheme has things like so: orldc-prod-ipa01 <--> orldc-prod-ipa02 <--> bohdc-prod-ipa01 I had run re-initialize on orldc-prod-ipa02 (--from orldc-prod-ipa01) AND re-initialize on bohdc-prod-ipa01 (--from orldc-prod-ipa02). That is where i'm currently at with the same errors. Any additional thoughts beyond just destroying 'orldc-prod-ipa02' and bohdc-prod-ipa01 and re-installing them as new replicas? As always, many thanks. On Tue, Mar 7, 2017 at 7:40 PM, Mark Reynolds wrote: > > > On 03/07/2017 06:08 PM, Christopher Young wrote: >> I had attempted to do _just_ a re-initialize on orldc-prod-ipa02 >> (using --from orldc-prod-ipa01), but after it completes, I still end >> up with the same errors. What would be my next course of action? > I have no idea. Sounds like the reinit did not work if you keep getting > the same errors, or you reinited the wrong server (or the wrong > direction) Remember you have to reinit ALL the replicas - not just one. >> >> To clarify the error(s) on orldc-prod-ipa01 are: >> ----- >> Mar 7 18:04:53 orldc-prod-ipa01 ns-slapd: >> [07/Mar/2017:18:04:53.549127059 -0500] NSMMReplicationPlugin - >> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa02:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> .... >> ----- >> >> >> On orldc-prod-ipa02, I get: >> ----- >> Mar 7 18:06:00 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:00.290853165 -0500] NSMMReplicationPlugin - >> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa01:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:01.715691409 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:01.720475590 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:01.728588145 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 7 18:06:04 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:04.286539164 -0500] NSMMReplicationPlugin - >> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >> (orldc-prod-ipa01:389): The remote replica has a different database >> generation ID than the local database. You may have to reinitialize >> the remote replica, or the local replica. >> Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:05.328239468 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:05.330429534 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: >> [07/Mar/2017:18:06:05.333270479 -0500] attrlist_replace - attr_replace >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >> failed. >> ----- >> >> >> I'm trying to figure out what my next step(s) would be in this >> situation. Would that be to completely remove those systems are >> replicas (orldc-prod-ipa02 and bohdc-prod-ipa01) and then completely >> recreate the replicas? >> >> I appreciate all the responses. I'm still trying to figure out what >> options to use for db2ldif, but I'm looking that up to at least try >> and look at the DBs. >> >> Thanks, >> >> Chris >> >> On Tue, Mar 7, 2017 at 4:23 PM, Mark Reynolds wrote: >>> >>> On 03/07/2017 11:29 AM, Christopher Young wrote: >>>> Thank you very much for the response! >>>> >>>> To start: >>>> ---- >>>> [root at orldc-prod-ipa01 ~]# rpm -qa 389-ds-base >>>> 389-ds-base-1.3.5.10-18.el7_3.x86_64 >>>> ---- >>> You are on the latest version with the latest replication fixes. >>>> So, I believe a good part of my problem is that I'm not _positive_ >>>> which replica is good at this point (though my directory really isn't >>>> that huge). >>>> >>>> Do you have any pointers on a good method of comparing the directory >>>> data between them? I was wondering if anyone knows of any tools to >>>> facilitate that. I was thinking that it might make sense for me to >>>> dump the DB and restore, but I really don't know that procedure. As I >>>> mentioned, my directory really isn't that large at all, however I'm >>>> not positive the best bullet-item listed method to proceed. (I know >>>> I'm not helping things :) ) >>> Heh, well only you know what your data should be. You can always do a >>> db2ldif.pl on each server and compare the ldif files that are >>> generated. Then pick the one you think is the most up to date. >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html#Exporting-db2ldif >>> >>> Once you decide on a server, then you need to reinitialize all the other >>> servers/replicas from the "good" one. Use " ipa-replica-manage >>> re-initialize" for this. >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html#initialize >>> >>> That's it. >>> >>> Good luck, >>> Mark >>> >>>> Would it be acceptable to just 'assume' one of the replicas is good >>>> (taking the risk of whatever missing pieces I'll have to deal with), >>>> completely removing the others, and then rebuilding the replicas from >>>> scratch? >>>> >>>> If I go that route, what are the potential pitfalls? >>>> >>>> >>>> I want to decide on an approach and try and resolve this once and for all. >>>> >>>> Thanks again! It really is appreciated as I've been frustrated with >>>> this for a while now. >>>> >>>> -- Chris >>>> >>>> On Tue, Mar 7, 2017 at 8:45 AM, Mark Reynolds wrote: >>>>> What version of 389-ds-base are you using? >>>>> >>>>> rpm -qa | grep 389-ds-base >>>>> >>>>> >>>>> comments below.. >>>>> >>>>> On 03/06/2017 02:37 PM, Christopher Young wrote: >>>>> >>>>> I've seen similar posts, but in the interest of asking fresh and >>>>> trying to understand what is going on, I thought I would ask for >>>>> advice on how best to handle this situation. >>>>> >>>>> In the interest of providing some history: >>>>> I have three (3) FreeIPA servers. Everything is running 4.4.0 now. >>>>> The originals (orldc-prod-ipa01, orldc-prod-ipa02) were upgraded from >>>>> the 3.x branch quite a while back. Everything had been working fine, >>>>> however I ran into a replication issue (that I _think_ may have been a >>>>> result of IPv6 being disabled by my default Ansible roles). I thought >>>>> I had resolved that by reinitializing the 2nd replica, >>>>> orldc-prod-ipa02. >>>>> >>>>> In any case, I feel like the replication has never been fully stable >>>>> since then, and I have all types of errors in messages that indicate >>>>> something is off. I had single introduced a 3rd replica such that the >>>>> agreements would look like so: >>>>> >>>>> orldc-prod-ipa01 -> orldc-prod-ipa02 ---> bohdc-prod-ipa01 >>>>> >>>>> It feels like orldc-prod-ipa02 & bohdc-prod-ipa01 are out of sync. >>>>> I've tried reinitializing them in order but with no positive results. >>>>> At this point, I feel like I'm ready to 'bite the bullet' and tear >>>>> them down quickly (remove them from IPA, delete the local >>>>> DBs/directories) and rebuild them from scratch. >>>>> >>>>> I want to minimize my impact as much as possible (which I can somewhat >>>>> do by redirecting LDAP/DNS request via my load-balancers temporarily) >>>>> and do this right. >>>>> >>>>> (Getting to the point...) >>>>> >>>>> I'd like advice on the order of operations to do this. Give the >>>>> errors (I'll include samples at the bottom of this message), does it >>>>> make sense for me to remove the replicas on bohdc-prod-ipa01 & >>>>> orldc-prod-ipa02 (in that order), wipe out any directories/residual >>>>> pieces (I'd need some idea of what to do there), and then create new >>>>> replicas? -OR- Should I export/backup the LDAP DB and rebuild >>>>> everything from scratch. >>>>> >>>>> I need advice and ideas. Furthermore, if there is someone with >>>>> experience in this that would be interested in making a little money >>>>> on the side, let me know, because having an extra brain and set of >>>>> hands would be welcome. >>>>> >>>>> DETAILS: >>>>> ================= >>>>> >>>>> >>>>> ERRORS I see on orldc-prod-ipa01 (the one whose LDAP DB seems the most >>>>> up-to-date since my changes are usually directed at it): >>>>> ------ >>>>> Mar 6 14:36:24 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:24.434956575 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO >>>>> LDAP bind... >>>>> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO >>>>> Commencing sync process >>>>> Mar 6 14:36:26 orldc-prod-ipa01 ipa-dnskeysyncd: >>>>> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump >>>>> is done, sychronizing with ODS and BIND >>>>> Mar 6 14:36:27 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:27.799519203 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:30 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:30.994760069 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:34 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:34.940115481 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client >>>>> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of >>>>> '56.10.in-addr.arpa/IN': AXFR-style IXFR started >>>>> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client >>>>> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of >>>>> '56.10.in-addr.arpa/IN': AXFR-style IXFR ended >>>>> Mar 6 14:36:37 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:37.977875463 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:40 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:40.999275184 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:36:45 orldc-prod-ipa01 ns-slapd: >>>>> [06/Mar/2017:14:36:45.211260414 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa02:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> ------ >>>>> >>>>> These messages indicate that the replica does not have the same database as >>>>> the master. So either the master or the replica needs to be reinitialized., >>>>> More on this below... >>>>> >>>>> >>>>> Errors on orldc-prod-ipa02: >>>>> ------ >>>>> r 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: ipa : INFO >>>>> Commencing sync process >>>>> Mar 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: >>>>> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump >>>>> is done, sychronizing with ODS and BIND >>>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:05.934405274 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:05.937278142 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:05.939434025 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> >>>>> These are harmless "errors" which have been removed in newer versions of >>>>> 389-ds-base. >>>>> >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:06.882795654 -0500] >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>>>> If replication stops, the consumer may need to be reinitialized. >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:06.886029272 -0500] NSMMReplicationPlugin - >>>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>>>> as up to date, or we purged >>>>> >>>>> This "could" also be a known issue that is fixed in newer versions of >>>>> 389-ds-base. Or this is a valid error message due to the replica being >>>>> stale for a very long time and records actually being purged from the >>>>> changelog before they were replicated. >>>>> >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:06.888679268 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>>>> Data required to update replica has been purged from the changelog. >>>>> The replica must be reinitialized. >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:06.960804253 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa01:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> >>>>> Okay, so your replication agreements/servers are not in sync. I suspect you >>>>> created a new replica and used that to initialize a valid replica which >>>>> broke things. Something like that. You need to find a "good" replica >>>>> server and reinitialize the other replicas from that server. These errors >>>>> needs to addressed asap, as it's halting replication for those agreements >>>>> which explains the "instability" you are describing. >>>>> >>>>> Mark >>>>> >>>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:08.960622608 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:08.968927168 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:08.976952118 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> Mar 6 14:16:09 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:09.972315877 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa01:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:10.034810948 -0500] >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>>>> If replication stops, the consumer may need to be reinitialized. >>>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:10.040020359 -0500] NSMMReplicationPlugin - >>>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>>>> as up to date, or we purged >>>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:10.042846879 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>>>> Data required to update replica has been purged from the changelog. >>>>> The replica must be reinitialized. >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:13.013253769 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:13.021514225 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:13.027521508 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:13.110566247 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" >>>>> (orldc-prod-ipa01:389): The remote replica has a different database >>>>> generation ID than the local database. You may have to reinitialize >>>>> the remote replica, or the local replica. >>>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:14.179819300 -0500] >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - >>>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB rc=-30988). >>>>> If replication stops, the consumer may need to be reinitialized. >>>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:14.188353328 -0500] NSMMReplicationPlugin - >>>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" >>>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we aren't >>>>> as up to date, or we purged >>>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:14.196463928 -0500] NSMMReplicationPlugin - >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): >>>>> Data required to update replica has been purged from the changelog. >>>>> The replica must be reinitialized. >>>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:17.068292919 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:17.071241757 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: >>>>> [06/Mar/2017:14:16:17.073793922 -0500] attrlist_replace - attr_replace >>>>> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) >>>>> failed. >>>>> ------ >>>>> >>>>> >>>>> Thanks in advance!!! >>>>> >>>>> -- Chris >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at netnerdz.se Wed Mar 8 17:06:37 2017 From: freeipa at netnerdz.se (freeipa at netnerdz.se) Date: Wed, 08 Mar 2017 18:06:37 +0100 Subject: [Freeipa-users] Issue upgrading freeipa to ipa-server-4.4.0-14.el7.centos.4.x86_64 Message-ID: Hi all! I'm trying to upgrade my ipa-server to the version in subject and hitting some bug that seems similar to https://bugzilla.redhat.com/show_bug.cgi?id=1404910 The yum upgrade process took a bit longer than expected so i ctrl+c it and executed the command ipa-server-upgrade The error message from ipa-server-upgrade is: 8<--- IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: OSError: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/dogtag.keytab' The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information [root at o-ipa01-r ~]# 8<--- The lines that indicate an error in the /var/log/ipaupgrade.log file is: 8<--- 2017-03-07T23:05:38Z DEBUG stdout=Authenticating as principal root/admin at NETNERDZ.SE with password. 2017-03-07T23:05:38Z DEBUG stderr=WARNING: no policy specified for dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE; defaulting to no policy add_principal: Principal or policy already exists while creating "dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE". 2017-03-07T23:05:38Z INFO Retrieving keytab 2017-03-07T23:05:38Z DEBUG Starting external process 2017-03-07T23:05:38Z DEBUG args=kadmin.local -q ktadd -k /etc/pki/pki-tomcat/dogtag.keytab dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE -x ipa-setup-override-restrictions 2017-03-07T23:05:48Z DEBUG Process finished, return code=0 2017-03-07T23:05:48Z DEBUG stdout=Authenticating as principal root/admin at NETNERDZ.SE with password. 2017-03-07T23:05:48Z DEBUG stderr=kadmin.local: Server error while changing dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE's key 2017-03-07T23:05:48Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2017-03-07T23:05:48Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 46, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1863, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1796, in upgrade_configuration ca.setup_lightweight_ca_key_retrieval() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1400, in setup_lightweight_ca_key_retrieval self.__setup_lightweight_ca_key_retrieval_kerberos() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1431, in __setup_lightweight_ca_key_retrieval_kerberos os.chmod(keytab, 0o600) 2017-03-07T23:05:48Z DEBUG The ipa-server-upgrade command failed, exception: OSError: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/dogtag.keytab' 2017-03-07T23:05:48Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: OSError: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/dogtag.keytab' 2017-03-07T23:05:48Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information 8<--- Here's the output from the ipa-server-upgrade command: [root at o-ipa01-r ~]# ipa-server-upgrade Upgrading IPA: [1/8]: saving configuration [2/8]: disabling listeners [3/8]: enabling DS global lock [4/8]: starting directory server [5/8]: updating schema [6/8]: upgrading server [7/8]: stopping directory server [8/8]: restoring configuration Done. Update complete Upgrading IPA services Upgrading the configuration of the IPA services [Verifying that root certificate is published] [Migrate CRL publish directory] CRL tree already moved /etc/dirsrv/slapd-NETNERDZ-SE/certmap.conf is now managed by IPA. It will be overwritten. A backup of the original will be made. [Verifying that CA proxy configuration is correct] [Verifying that KDC configuration is using ipa-kdb backend] [Fix DS schema file syntax] Syntax already fixed [Removing RA cert from DS NSS database] RA cert already removed [Enable sidgen and extdom plugins by default] [Updating HTTPD service IPA configuration] [Updating mod_nss protocol versions] Protocol versions already updated [Updating mod_nss cipher suite] [Fixing trust flags in /etc/httpd/alias] Trust flags already processed [Exporting KRA agent PEM file] KRA is not enabled [Removing self-signed CA] [Removing Dogtag 9 CA] [Checking for deprecated KDC configuration files] [Checking for deprecated backups of Samba configuration files] [Setting up Firefox extension] [Add missing CA DNS records] IPA CA DNS records already processed [Removing deprecated DNS configuration options] [Ensuring minimal number of connections] [Enabling serial autoincrement in DNS] [Updating GSSAPI configuration in DNS] [Updating pid-file configuration in DNS] [Checking global forwarding policy in named.conf to avoid conflicts with automatic empty zones] Changes to named.conf have been made, restart named [Upgrading CA schema] CA schema update complete (no changes) [Verifying that CA audit signing cert has 2 year validity] [Update certmonger certificate renewal configuration to version 5] [Enable PKIX certificate path discovery and validation] PKIX already enabled [Authorizing RA Agent to modify profiles] [Authorizing RA Agent to manage lightweight CAs] [Ensuring Lightweight CAs container exists in Dogtag database] [Adding default OCSP URI configuration] [Ensuring CA is using LDAPProfileSubsystem] [Migrating certificate profiles to LDAP] [Ensuring presence of included profiles] [Add default CA ACL] Default CA ACL already added [Set up lightweight CA key retrieval] Creating principal Retrieving keytab IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: OSError: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/dogtag.keytab' The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information [root at o-ipa01-r ~]# Everything seems to be working as normal, but this error message worries me a bit since this is my only ipa server (setting up a secondary master have been on my todo list). Can you help me troubleshoot this? Or should I just setup a replica and propagate it to primary node for all clients and then reinstall the one that have problem? Thank you in advance! //Robert From mareynol at redhat.com Wed Mar 8 19:36:10 2017 From: mareynol at redhat.com (Mark Reynolds) Date: Wed, 8 Mar 2017 14:36:10 -0500 Subject: [Freeipa-users] Replication Issues In-Reply-To: References: <8e21c675-349b-a46c-95cb-97fd7ae165a8@redhat.com> Message-ID: <1d8425d0-f69a-a183-1f1c-aaa51d97a569@redhat.com> On 03/08/2017 11:39 AM, Christopher Young wrote: > My replication scheme has things like so: > > orldc-prod-ipa01 <--> orldc-prod-ipa02 <--> bohdc-prod-ipa01 > > I had run re-initialize on orldc-prod-ipa02 (--from orldc-prod-ipa01) AND > re-initialize on bohdc-prod-ipa01 (--from orldc-prod-ipa02). Yeah if you still "The remote replica has a different database generation ID than the local database" messages then things are out of sync. Okay, I'm not an IPA guy, just DS. So lets do this the DS way... Export the replica database from orldc-prod-ipa01: # stop-dirsrv # db2ldif -r -n userroot -a /tmp/replica.ldif copy this LDIF to the other two servers and import it: # stop-dirsrv # ldif2db -n userroot -i /tmp/replica.ldif ** If you get permissions errors then temporarily disable selinux, and enable it after all the exports/imports are complete. Once this is done, go back and start all the servers: start-dirsrv Done! > > That is where i'm currently at with the same errors. > > Any additional thoughts beyond just destroying 'orldc-prod-ipa02' and > bohdc-prod-ipa01 and re-installing them as new replicas? > > As always, many thanks. > > On Tue, Mar 7, 2017 at 7:40 PM, Mark Reynolds > wrote: > > > > > > On 03/07/2017 06:08 PM, Christopher Young wrote: > >> I had attempted to do _just_ a re-initialize on orldc-prod-ipa02 > >> (using --from orldc-prod-ipa01), but after it completes, I still end > >> up with the same errors. What would be my next course of action? > > I have no idea. Sounds like the reinit did not work if you keep getting > > the same errors, or you reinited the wrong server (or the wrong > > direction) Remember you have to reinit ALL the replicas - not just one. > >> > >> To clarify the error(s) on orldc-prod-ipa01 are: > >> ----- > >> Mar 7 18:04:53 orldc-prod-ipa01 ns-slapd: > >> [07/Mar/2017:18:04:53.549127059 -0500] NSMMReplicationPlugin - > >> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >> (orldc-prod-ipa02:389): The remote replica has a different database > >> generation ID than the local database. You may have to reinitialize > >> the remote replica, or the local replica. > >> .... > >> ----- > >> > >> > >> On orldc-prod-ipa02, I get: > >> ----- > >> Mar 7 18:06:00 orldc-prod-ipa02 ns-slapd: > >> [07/Mar/2017:18:06:00.290853165 -0500] NSMMReplicationPlugin - > >> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >> (orldc-prod-ipa01:389): The remote replica has a different database > >> generation ID than the local database. You may have to reinitialize > >> the remote replica, or the local replica. > >> Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: > >> [07/Mar/2017:18:06:01.715691409 -0500] attrlist_replace - attr_replace > >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >> failed. > >> Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: > >> [07/Mar/2017:18:06:01.720475590 -0500] attrlist_replace - attr_replace > >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >> failed. > >> Mar 7 18:06:01 orldc-prod-ipa02 ns-slapd: > >> [07/Mar/2017:18:06:01.728588145 -0500] attrlist_replace - attr_replace > >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >> failed. > >> Mar 7 18:06:04 orldc-prod-ipa02 ns-slapd: > >> [07/Mar/2017:18:06:04.286539164 -0500] NSMMReplicationPlugin - > >> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >> (orldc-prod-ipa01:389): The remote replica has a different database > >> generation ID than the local database. You may have to reinitialize > >> the remote replica, or the local replica. > >> Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: > >> [07/Mar/2017:18:06:05.328239468 -0500] attrlist_replace - attr_replace > >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >> failed. > >> Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: > >> [07/Mar/2017:18:06:05.330429534 -0500] attrlist_replace - attr_replace > >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >> failed. > >> Mar 7 18:06:05 orldc-prod-ipa02 ns-slapd: > >> [07/Mar/2017:18:06:05.333270479 -0500] attrlist_replace - attr_replace > >> (nsslapd-referral, ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >> failed. > >> ----- > >> > >> > >> I'm trying to figure out what my next step(s) would be in this > >> situation. Would that be to completely remove those systems are > >> replicas (orldc-prod-ipa02 and bohdc-prod-ipa01) and then completely > >> recreate the replicas? > >> > >> I appreciate all the responses. I'm still trying to figure out what > >> options to use for db2ldif, but I'm looking that up to at least try > >> and look at the DBs. > >> > >> Thanks, > >> > >> Chris > >> > >> On Tue, Mar 7, 2017 at 4:23 PM, Mark Reynolds > wrote: > >>> > >>> On 03/07/2017 11:29 AM, Christopher Young wrote: > >>>> Thank you very much for the response! > >>>> > >>>> To start: > >>>> ---- > >>>> [root at orldc-prod-ipa01 ~]# rpm -qa 389-ds-base > >>>> 389-ds-base-1.3.5.10-18.el7_3.x86_64 > >>>> ---- > >>> You are on the latest version with the latest replication fixes. > >>>> So, I believe a good part of my problem is that I'm not _positive_ > >>>> which replica is good at this point (though my directory really isn't > >>>> that huge). > >>>> > >>>> Do you have any pointers on a good method of comparing the directory > >>>> data between them? I was wondering if anyone knows of any tools to > >>>> facilitate that. I was thinking that it might make sense for me to > >>>> dump the DB and restore, but I really don't know that procedure. As I > >>>> mentioned, my directory really isn't that large at all, however I'm > >>>> not positive the best bullet-item listed method to proceed. (I know > >>>> I'm not helping things :) ) > >>> Heh, well only you know what your data should be. You can always do a > >>> db2ldif.pl on each server and compare the ldif > files that are > >>> generated. Then pick the one you think is the most up to date. > >>> > >>> > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html#Exporting-db2ldif > >>> > >>> Once you decide on a server, then you need to reinitialize all the > other > >>> servers/replicas from the "good" one. Use " ipa-replica-manage > >>> re-initialize" for this. > >>> > >>> > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html#initialize > >>> > >>> That's it. > >>> > >>> Good luck, > >>> Mark > >>> > >>>> Would it be acceptable to just 'assume' one of the replicas is good > >>>> (taking the risk of whatever missing pieces I'll have to deal with), > >>>> completely removing the others, and then rebuilding the replicas from > >>>> scratch? > >>>> > >>>> If I go that route, what are the potential pitfalls? > >>>> > >>>> > >>>> I want to decide on an approach and try and resolve this once and > for all. > >>>> > >>>> Thanks again! It really is appreciated as I've been frustrated with > >>>> this for a while now. > >>>> > >>>> -- Chris > >>>> > >>>> On Tue, Mar 7, 2017 at 8:45 AM, Mark Reynolds > > wrote: > >>>>> What version of 389-ds-base are you using? > >>>>> > >>>>> rpm -qa | grep 389-ds-base > >>>>> > >>>>> > >>>>> comments below.. > >>>>> > >>>>> On 03/06/2017 02:37 PM, Christopher Young wrote: > >>>>> > >>>>> I've seen similar posts, but in the interest of asking fresh and > >>>>> trying to understand what is going on, I thought I would ask for > >>>>> advice on how best to handle this situation. > >>>>> > >>>>> In the interest of providing some history: > >>>>> I have three (3) FreeIPA servers. Everything is running 4.4.0 now. > >>>>> The originals (orldc-prod-ipa01, orldc-prod-ipa02) were upgraded > from > >>>>> the 3.x branch quite a while back. Everything had been working fine, > >>>>> however I ran into a replication issue (that I _think_ may have > been a > >>>>> result of IPv6 being disabled by my default Ansible roles). I > thought > >>>>> I had resolved that by reinitializing the 2nd replica, > >>>>> orldc-prod-ipa02. > >>>>> > >>>>> In any case, I feel like the replication has never been fully stable > >>>>> since then, and I have all types of errors in messages that indicate > >>>>> something is off. I had single introduced a 3rd replica such > that the > >>>>> agreements would look like so: > >>>>> > >>>>> orldc-prod-ipa01 -> orldc-prod-ipa02 ---> bohdc-prod-ipa01 > >>>>> > >>>>> It feels like orldc-prod-ipa02 & bohdc-prod-ipa01 are out of sync. > >>>>> I've tried reinitializing them in order but with no positive > results. > >>>>> At this point, I feel like I'm ready to 'bite the bullet' and tear > >>>>> them down quickly (remove them from IPA, delete the local > >>>>> DBs/directories) and rebuild them from scratch. > >>>>> > >>>>> I want to minimize my impact as much as possible (which I can > somewhat > >>>>> do by redirecting LDAP/DNS request via my load-balancers > temporarily) > >>>>> and do this right. > >>>>> > >>>>> (Getting to the point...) > >>>>> > >>>>> I'd like advice on the order of operations to do this. Give the > >>>>> errors (I'll include samples at the bottom of this message), does it > >>>>> make sense for me to remove the replicas on bohdc-prod-ipa01 & > >>>>> orldc-prod-ipa02 (in that order), wipe out any directories/residual > >>>>> pieces (I'd need some idea of what to do there), and then create new > >>>>> replicas? -OR- Should I export/backup the LDAP DB and rebuild > >>>>> everything from scratch. > >>>>> > >>>>> I need advice and ideas. Furthermore, if there is someone with > >>>>> experience in this that would be interested in making a little money > >>>>> on the side, let me know, because having an extra brain and set of > >>>>> hands would be welcome. > >>>>> > >>>>> DETAILS: > >>>>> ================= > >>>>> > >>>>> > >>>>> ERRORS I see on orldc-prod-ipa01 (the one whose LDAP DB seems > the most > >>>>> up-to-date since my changes are usually directed at it): > >>>>> ------ > >>>>> Mar 6 14:36:24 orldc-prod-ipa01 ns-slapd: > >>>>> [06/Mar/2017:14:36:24.434956575 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >>>>> (orldc-prod-ipa02:389): The remote replica has a different database > >>>>> generation ID than the local database. You may have to reinitialize > >>>>> the remote replica, or the local replica. > >>>>> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO > >>>>> LDAP bind... > >>>>> Mar 6 14:36:25 orldc-prod-ipa01 ipa-dnskeysyncd: ipa : INFO > >>>>> Commencing sync process > >>>>> Mar 6 14:36:26 orldc-prod-ipa01 ipa-dnskeysyncd: > >>>>> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump > >>>>> is done, sychronizing with ODS and BIND > >>>>> Mar 6 14:36:27 orldc-prod-ipa01 ns-slapd: > >>>>> [06/Mar/2017:14:36:27.799519203 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >>>>> (orldc-prod-ipa02:389): The remote replica has a different database > >>>>> generation ID than the local database. You may have to reinitialize > >>>>> the remote replica, or the local replica. > >>>>> Mar 6 14:36:30 orldc-prod-ipa01 ns-slapd: > >>>>> [06/Mar/2017:14:36:30.994760069 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >>>>> (orldc-prod-ipa02:389): The remote replica has a different database > >>>>> generation ID than the local database. You may have to reinitialize > >>>>> the remote replica, or the local replica. > >>>>> Mar 6 14:36:34 orldc-prod-ipa01 ns-slapd: > >>>>> [06/Mar/2017:14:36:34.940115481 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >>>>> (orldc-prod-ipa02:389): The remote replica has a different database > >>>>> generation ID than the local database. You may have to reinitialize > >>>>> the remote replica, or the local replica. > >>>>> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client > >>>>> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of > >>>>> '56.10.in-addr.arpa/IN': AXFR-style IXFR started > >>>>> Mar 6 14:36:35 orldc-prod-ipa01 named-pkcs11[32134]: client > >>>>> 10.26.250.66#49635 (56.10.in-addr.arpa): transfer of > >>>>> '56.10.in-addr.arpa/IN': AXFR-style IXFR ended > >>>>> Mar 6 14:36:37 orldc-prod-ipa01 ns-slapd: > >>>>> [06/Mar/2017:14:36:37.977875463 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >>>>> (orldc-prod-ipa02:389): The remote replica has a different database > >>>>> generation ID than the local database. You may have to reinitialize > >>>>> the remote replica, or the local replica. > >>>>> Mar 6 14:36:40 orldc-prod-ipa01 ns-slapd: > >>>>> [06/Mar/2017:14:36:40.999275184 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >>>>> (orldc-prod-ipa02:389): The remote replica has a different database > >>>>> generation ID than the local database. You may have to reinitialize > >>>>> the remote replica, or the local replica. > >>>>> Mar 6 14:36:45 orldc-prod-ipa01 ns-slapd: > >>>>> [06/Mar/2017:14:36:45.211260414 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=cloneAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >>>>> (orldc-prod-ipa02:389): The remote replica has a different database > >>>>> generation ID than the local database. You may have to reinitialize > >>>>> the remote replica, or the local replica. > >>>>> ------ > >>>>> > >>>>> These messages indicate that the replica does not have the same > database as > >>>>> the master. So either the master or the replica needs to be > reinitialized., > >>>>> More on this below... > >>>>> > >>>>> > >>>>> Errors on orldc-prod-ipa02: > >>>>> ------ > >>>>> r 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: ipa : INFO > >>>>> Commencing sync process > >>>>> Mar 6 14:16:04 orldc-prod-ipa02 ipa-dnskeysyncd: > >>>>> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump > >>>>> is done, sychronizing with ODS and BIND > >>>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:05.934405274 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:05.937278142 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> Mar 6 14:16:05 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:05.939434025 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> > >>>>> These are harmless "errors" which have been removed in newer > versions of > >>>>> 389-ds-base. > >>>>> > >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:06.882795654 -0500] > >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - > >>>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB > rc=-30988). > >>>>> If replication stops, the consumer may need to be reinitialized. > >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:06.886029272 -0500] NSMMReplicationPlugin - > >>>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" > >>>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we > aren't > >>>>> as up to date, or we purged > >>>>> > >>>>> This "could" also be a known issue that is fixed in newer > versions of > >>>>> 389-ds-base. Or this is a valid error message due to the replica > being > >>>>> stale for a very long time and records actually being purged > from the > >>>>> changelog before they were replicated. > >>>>> > >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:06.888679268 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): > >>>>> Data required to update replica has been purged from the changelog. > >>>>> The replica must be reinitialized. > >>>>> Mar 6 14:16:06 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:06.960804253 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >>>>> (orldc-prod-ipa01:389): The remote replica has a different database > >>>>> generation ID than the local database. You may have to reinitialize > >>>>> the remote replica, or the local replica. > >>>>> > >>>>> Okay, so your replication agreements/servers are not in sync. I > suspect you > >>>>> created a new replica and used that to initialize a valid > replica which > >>>>> broke things. Something like that. You need to find a "good" replica > >>>>> server and reinitialize the other replicas from that server. > These errors > >>>>> needs to addressed asap, as it's halting replication for those > agreements > >>>>> which explains the "instability" you are describing. > >>>>> > >>>>> Mark > >>>>> > >>>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:08.960622608 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:08.968927168 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> Mar 6 14:16:08 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:08.976952118 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> Mar 6 14:16:09 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:09.972315877 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >>>>> (orldc-prod-ipa01:389): The remote replica has a different database > >>>>> generation ID than the local database. You may have to reinitialize > >>>>> the remote replica, or the local replica. > >>>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:10.034810948 -0500] > >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - > >>>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB > rc=-30988). > >>>>> If replication stops, the consumer may need to be reinitialized. > >>>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:10.040020359 -0500] NSMMReplicationPlugin - > >>>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" > >>>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we > aren't > >>>>> as up to date, or we purged > >>>>> Mar 6 14:16:10 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:10.042846879 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): > >>>>> Data required to update replica has been purged from the changelog. > >>>>> The replica must be reinitialized. > >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:13.013253769 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:13.021514225 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:13.027521508 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> Mar 6 14:16:13 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:13.110566247 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=masterAgreement1-orldc-prod-ipa01.passur.local-pki-tomcat" > >>>>> (orldc-prod-ipa01:389): The remote replica has a different database > >>>>> generation ID than the local database. You may have to reinitialize > >>>>> the remote replica, or the local replica. > >>>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:14.179819300 -0500] > >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389) - > >>>>> Can't locate CSN 58bdf8f5000200070000 in the changelog (DB > rc=-30988). > >>>>> If replication stops, the consumer may need to be reinitialized. > >>>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:14.188353328 -0500] NSMMReplicationPlugin - > >>>>> changelog program - agmt="cn=meTobohdc-prod-ipa01.passur.local" > >>>>> (bohdc-prod-ipa01:389): CSN 58bdf8f5000200070000 not found, we > aren't > >>>>> as up to date, or we purged > >>>>> Mar 6 14:16:14 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:14.196463928 -0500] NSMMReplicationPlugin - > >>>>> agmt="cn=meTobohdc-prod-ipa01.passur.local" (bohdc-prod-ipa01:389): > >>>>> Data required to update replica has been purged from the changelog. > >>>>> The replica must be reinitialized. > >>>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:17.068292919 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:17.071241757 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> Mar 6 14:16:17 orldc-prod-ipa02 ns-slapd: > >>>>> [06/Mar/2017:14:16:17.073793922 -0500] attrlist_replace - > attr_replace > >>>>> (nsslapd-referral, > ldap://orldc-prod-ipa01.passur.local:389/o%3Dipaca) > >>>>> failed. > >>>>> ------ > >>>>> > >>>>> > >>>>> Thanks in advance!!! > >>>>> > >>>>> -- Chris > >>>>> > >>>>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From datakid at gmail.com Thu Mar 9 02:37:46 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Thu, 9 Mar 2017 13:37:46 +1100 Subject: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD Message-ID: Hola, On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd (via COPR) 1.15.1, which has a one way trust to an AD domain. unix.name.org -> name.org I've seen some interesting behaviour. Being part of a large organisation with a smaller nix environment and a larger Windows environment we see all the best of odd AD management behaviour (eg spaces in usernames...). Turns out some of the groups in AD have an @ symbol in them. The behavioural difference we see is: given userA in group "name @ of group" that on the FreeIPA server: [root at vmpr-freeipa.unix.name.org ~]# id userA at name.org works as expected. But on a client [root at vmpr-linuxclient1.unix.name.org ~]# id userA at name.org returns nothing. We believe it is because of the group with the @ in the name. The AD management team agreed to change the name of one group with an @ in it's name, and that has solved the problem - id userA at name.org now works on the sssd client. Putting aside the critiques of having an @ in a group name, I believe that if there isn't a bug, there is at least an inconsistency, between how FreeIPA and sssd handle this situation. This was a guess based on seeing this in the logs: (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaUserOverride)(uid=awong))][cn=Default Trust View,cn=views,cn=accounts,dc=unix,dc=name,dc=org]. (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sdap_parse_entry] (0x1000): OriginalDN: [ipaanchoruuid=:SID:S-1-5-21-55386287-1424373824-1154838474-83519,cn=Default Trust View,cn=views,cn=accounts,dc=unix,dc=name,dc=org]. (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] (0x1000): Domain unix.name.org is Active (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] (0x1000): Domain name.org is Active (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null). (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] (0x1000): Domain unix.name.org is Active (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] (0x1000): Domain name.org is Active ... (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] (0x1000): Domain unix.name.org is Active (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] (0x1000): Domain name.org is Active (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] (0x1000): Domain unix.name.org is Active (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] (0x1000): Domain name.org is Active (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [add_v1_user_data] (0x0040): find_domain_by_name failed. (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [s2n_response_to_attrs] (0x0040): add_v1_user_data failed. (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_get_user_done] (0x0040): s2n_response_to_attrs failed. The last three lines tipped off a colleague who was debugging why this userA couldn't login to anything. Since then we have created IPA over rides for the groups with @ symbols in them. This also works as a solution. It's not our preferred solution, but we are users, not managers, of the AD system. Cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ronald.Wimmer at oebb.at Thu Mar 9 08:04:24 2017 From: Ronald.Wimmer at oebb.at (Wimmer Ronald (BCC.B.SO)) Date: Thu, 9 Mar 2017 08:04:24 +0000 Subject: [Freeipa-users] External DNS and replication In-Reply-To: References: <97E471CB191D044F9F018C77836CF85B8A03E282@ARSEX004.oebb.at> Message-ID: <97E471CB191D044F9F018C77836CF85B8A03E8E1@ARSEX004.oebb.at> From: Martin Basti [mailto:mbasti at redhat.com] Sent: Mittwoch, 08. M?rz 2017 14:54 To: Wimmer Ronald (BCC.B.SO) ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] External DNS and replication On 08.03.2017 14:05, Wimmer Ronald (BCC.B.SO) wrote: Hi, I am using FreeIPA with external DNS. Is it ok to balance the requests between master and replica with DNS SRV records like this: _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net. _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net. _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa1.example.net. _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa1.example.net. _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net. _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net. _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa2.example.net. _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa2.example.net. _kerberos.example.net. 86400 IN TXT "example.net" Looks good to me ipa-ca.example.net. 86400 IN A 10.66.39.130 What about the "ipa-ca" entry? ipa-ca should contain all A/AAAA records of CA replicas IPA4.4+ support command `ipa dns-update-system-records --dry-run` to get all required records Regards, Ronald Martin Thank's a lot. In https://access.redhat.com/solutions/98043 RedHat suggest to use same weight and same priority for the SRV records. Does that make sense? I also noticed that I have no ndp record. Are IPA clients relying on that entry? Do I have to create these manually? _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipaserver1.example.net. _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipaserver2.example.net. Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Mar 9 08:52:00 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 9 Mar 2017 09:52:00 +0100 Subject: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD In-Reply-To: References: Message-ID: <20170309085200.l2mmrvpxhglxlmsp@hendrix> On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote: > Hola, > > On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd > (via COPR) 1.15.1, which has a one way trust to an AD domain. unix.name.org > -> name.org > > I've seen some interesting behaviour. > > Being part of a large organisation with a smaller nix environment and a > larger Windows environment we see all the best of odd AD management > behaviour (eg spaces in usernames...). > > Turns out some of the groups in AD have an @ symbol in them. > > The behavioural difference we see is: given userA in group "name @ of > group" that on the FreeIPA server: > > [root at vmpr-freeipa.unix.name.org ~]# id userA at name.org > > works as expected. > > But on a client > > [root at vmpr-linuxclient1.unix.name.org ~]# id userA at name.org > > returns nothing. Yes, it is a know issue: https://pagure.io/SSSD/sssd/issue/3219 There were some users who reported this works better with a modified re_expression: re_expression = ((?P.+)@(?P[^@]+$)) but I agree we should fix this by default. However, the fix must be done at both the SSSD level and the IPA extdom plugin, which also searches for the @-sign in the user and group names. > > We believe it is because of the group with the @ in the name. > > The AD management team agreed to change the name of one group with an @ in > it's name, and that has solved the problem - id userA at name.org now works on > the sssd client. > > Putting aside the critiques of having an @ in a group name, I believe that > if there isn't a bug, there is at least an inconsistency, between how > FreeIPA and sssd handle this situation. > > This was a guess based on seeing this in the logs: > > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [(&(objectClass=ipaUserOverride)(uid=awong))][cn=Default Trust > View,cn=views,cn=accounts,dc=unix,dc=name,dc=org]. > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sdap_parse_entry] > (0x1000): OriginalDN: > [ipaanchoruuid=:SID:S-1-5-21-55386287-1424373824-1154838474-83519,cn=Default > Trust View,cn=views,cn=accounts,dc=unix,dc=name,dc=org]. > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] > [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > errmsg set > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] > (0x1000): Domain unix.name.org is Active > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] > (0x1000): Domain name.org is Active > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_send] > (0x0400): Executing extended operation > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [ipa_s2n_exop_done] > (0x0400): ldap_extended_operation result: Success(0), (null). > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] > (0x1000): Domain unix.name.org is Active > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] > (0x1000): Domain name.org is Active > ... > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] > (0x1000): Domain unix.name.org is Active > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] > (0x1000): Domain name.org is Active > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] > (0x1000): Domain unix.name.org is Active > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [sss_domain_get_state] > (0x1000): Domain name.org is Active > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] [add_v1_user_data] > (0x0040): find_domain_by_name failed. > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] > [s2n_response_to_attrs] (0x0040): add_v1_user_data failed. > (Wed Mar 8 12:03:02 2017) [sssd[be[unix.name.org]]] > [ipa_s2n_get_user_done] (0x0040): s2n_response_to_attrs failed. > > > The last three lines tipped off a colleague who was debugging why this > userA couldn't login to anything. > > Since then we have created IPA over rides for the groups with @ symbols in > them. This also works as a solution. It's not our preferred solution, but > we are users, not managers, of the AD system. > > Cheers > > L. > > > > > > ------ > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper > -- > 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 From abokovoy at redhat.com Thu Mar 9 09:32:35 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 9 Mar 2017 11:32:35 +0200 Subject: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD In-Reply-To: <20170309085200.l2mmrvpxhglxlmsp@hendrix> References: <20170309085200.l2mmrvpxhglxlmsp@hendrix> Message-ID: <20170309093235.hil646gcvjlpiirp@redhat.com> On to, 09 maalis 2017, Jakub Hrozek wrote: >On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote: >> Hola, >> >> On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd >> (via COPR) 1.15.1, which has a one way trust to an AD domain. unix.name.org >> -> name.org >> >> I've seen some interesting behaviour. >> >> Being part of a large organisation with a smaller nix environment and a >> larger Windows environment we see all the best of odd AD management >> behaviour (eg spaces in usernames...). >> >> Turns out some of the groups in AD have an @ symbol in them. >> >> The behavioural difference we see is: given userA in group "name @ of >> group" that on the FreeIPA server: >> >> [root at vmpr-freeipa.unix.name.org ~]# id userA at name.org >> >> works as expected. >> >> But on a client >> >> [root at vmpr-linuxclient1.unix.name.org ~]# id userA at name.org >> >> returns nothing. > >Yes, it is a know issue: > https://pagure.io/SSSD/sssd/issue/3219 > >There were some users who reported this works better with a modified >re_expression: > re_expression = ((?P.+)@(?P[^@]+$)) >but I agree we should fix this by default. However, the fix must be done >at both the SSSD level and the IPA extdom plugin, which also searches >for the @-sign in the user and group names. Luckily, a change for extdom plugin seem to be straightforward -- search for the *last* occurence of the domain separator, not the first one. We had a similar issue with nfs idmapd code too. -- / Alexander Bokovoy -------------- next part -------------- diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index e629247..7c67fb7 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -515,7 +515,7 @@ int pack_ber_user(struct ipa_extdom_ctx *ctx, char *short_user_name = NULL; short_user_name = strdup(user_name); - if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if ((locat = strrchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { if (strcasecmp(locat+1, domain_name) == 0 ) { locat[0] = '\0'; } else { @@ -626,7 +626,7 @@ int pack_ber_group(enum response_types response_type, char *short_group_name = NULL; short_group_name = strdup(group_name); - if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { + if ((locat = strrchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { if (strcasecmp(locat+1, domain_name) == 0 ) { locat[0] = '\0'; } else { @@ -901,7 +901,7 @@ static int handle_sid_or_cert_request(struct ipa_extdom_ctx *ctx, goto done; } - sep = strchr(fq_name, SSSD_DOMAIN_SEPARATOR); + sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR); if (sep == NULL) { set_err_msg(req, "Failed to split fully qualified name"); ret = LDAP_OPERATIONS_ERROR; @@ -1023,7 +1023,7 @@ static int handle_name_request(struct ipa_extdom_ctx *ctx, char *buf = NULL; struct sss_nss_kv *kv_list = NULL; - if (strchr(name, SSSD_DOMAIN_SEPARATOR) == NULL) { + if (strrchr(name, SSSD_DOMAIN_SEPARATOR) == NULL) { ret = asprintf(&fq_name, "%s%c%s", name, SSSD_DOMAIN_SEPARATOR, domain_name); } else { From jhrozek at redhat.com Thu Mar 9 09:39:33 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 9 Mar 2017 10:39:33 +0100 Subject: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD In-Reply-To: <20170309093235.hil646gcvjlpiirp@redhat.com> References: <20170309085200.l2mmrvpxhglxlmsp@hendrix> <20170309093235.hil646gcvjlpiirp@redhat.com> Message-ID: <20170309093933.vulku5wq3mpctqao@hendrix> On Thu, Mar 09, 2017 at 11:32:35AM +0200, Alexander Bokovoy wrote: > On to, 09 maalis 2017, Jakub Hrozek wrote: > > On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote: > > > Hola, > > > > > > On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and sssd > > > (via COPR) 1.15.1, which has a one way trust to an AD domain. unix.name.org > > > -> name.org > > > > > > I've seen some interesting behaviour. > > > > > > Being part of a large organisation with a smaller nix environment and a > > > larger Windows environment we see all the best of odd AD management > > > behaviour (eg spaces in usernames...). > > > > > > Turns out some of the groups in AD have an @ symbol in them. > > > > > > The behavioural difference we see is: given userA in group "name @ of > > > group" that on the FreeIPA server: > > > > > > [root at vmpr-freeipa.unix.name.org ~]# id userA at name.org > > > > > > works as expected. > > > > > > But on a client > > > > > > [root at vmpr-linuxclient1.unix.name.org ~]# id userA at name.org > > > > > > returns nothing. > > > > Yes, it is a know issue: > > https://pagure.io/SSSD/sssd/issue/3219 > > > > There were some users who reported this works better with a modified > > re_expression: > > re_expression = ((?P.+)@(?P[^@]+$)) > > but I agree we should fix this by default. However, the fix must be done > > at both the SSSD level and the IPA extdom plugin, which also searches > > for the @-sign in the user and group names. > Luckily, a change for extdom plugin seem to be straightforward -- search > for the *last* occurence of the domain separator, not the first one. We > had a similar issue with nfs idmapd code too. Yes, the most tricky part would be testing, to make sure the new regular expression doesn't break anything. I used the one I showed to unblock some RHEL customers that were complaining and were a bit stuck, but I didn't have enough time to run all our available tests with it, that's why we didn't switch by default.. From Ronald.Wimmer at oebb.at Thu Mar 9 10:04:26 2017 From: Ronald.Wimmer at oebb.at (Wimmer Ronald (BCC.B.SO)) Date: Thu, 9 Mar 2017 10:04:26 +0000 Subject: [Freeipa-users] Potential problems when using a loadbalancer Message-ID: <97E471CB191D044F9F018C77836CF85B8A03E9CB@ARSEX004.oebb.at> Hi, what kind of challenges will I run into when I want to use a loadbalancer in front of my two IPA servers? - LDAP: Should not be a problem - Kerberos: will definitely be a challenge. Is this link the solution or am I still missing something: http://directory.fedoraproject.org/docs/389ds/howto/howto-loadbalance-gssapi.html - Certificates: I stumbled upon a RedHat Knowledgebase entry dealing with "Certificate CN not matching when using the loadbalancer's virtual name": https://access.redhat.com/solutions/547723 - What else will be a problem that needs to be solved? Any hints regarding the "what else" point would be highly appreciated! Regards, Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From keesb at ghs.com Thu Mar 9 10:12:39 2017 From: keesb at ghs.com (Kees Bakker) Date: Thu, 9 Mar 2017 11:12:39 +0100 Subject: [Freeipa-users] What is the next free IP address for a DNS record Message-ID: <3dd89442-4ce1-4e03-d9ff-3c065f062e44@ghs.com> Hey, Is there an easy way to find out what the next free IP address is when adding a new DNS A record? The web interface sorts the records alphabetically on "Record name", even in-arpa zones. For the latter it would be more convenient to sort numerically. Anyway, what methods are there to know what IP address to use when adding a new DNS record? Did I overlook something? BTW. Right now I'm dumping the JSON with ipa -vv dnsrecord-find mydomain --sizelimit=99999 --all --structured 2>&1 >/dev/null and a Python script to make a list sorted on ip address. -- Kees From harald.dunkel at aixigo.de Thu Mar 9 10:08:31 2017 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Thu, 9 Mar 2017 11:08:31 +0100 Subject: [Freeipa-users] ipa-client-install generates bad sssd.conf In-Reply-To: <24226ff8-8302-c01f-1302-689c6b764535@ubuntu.com> References: <94030dc8-6768-e826-38fa-a2e8265715ae@aixigo.de> <20170303083257.zkurhvg7ox4sufyu@hendrix> <20170303091446.md4myw33jcgbdpcg@hendrix> <28160af8-032d-d2b6-e45d-08e6d01e3497@redhat.com> <24226ff8-8302-c01f-1302-689c6b764535@ubuntu.com> Message-ID: <2ab55730-ef85-3f69-dc4f-eec972960082@aixigo.de> On 03/05/17 11:47, Timo Aaltonen wrote: > > pam-auth-update configures pam, there's nothing else to be configured.. > I just ran ipa-client-install on Ubuntu zesty with freeipa-client > 4.4.3-3ubuntu1, and services on the newly created sssd.conf look fine: > > services = nss, sudo, pam, ssh > > Do you get the same for 4.4.3-3 (the version in Debian experimental, AFAICT) on sid? I don't :-(. Command line: ipa-client-install --hostname `hostname` --no-ssh --no-sshd --no-nisdomain Regards Harri From mbasti at redhat.com Thu Mar 9 10:37:24 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 9 Mar 2017 11:37:24 +0100 Subject: [Freeipa-users] External DNS and replication In-Reply-To: <97E471CB191D044F9F018C77836CF85B8A03E8E1@ARSEX004.oebb.at> References: <97E471CB191D044F9F018C77836CF85B8A03E282@ARSEX004.oebb.at> <97E471CB191D044F9F018C77836CF85B8A03E8E1@ARSEX004.oebb.at> Message-ID: On 09.03.2017 09:04, Wimmer Ronald (BCC.B.SO) wrote: > > *From:*Martin Basti [mailto:mbasti at redhat.com] > *Sent:* Mittwoch, 08. M?rz 2017 14:54 > *To:* Wimmer Ronald (BCC.B.SO) ; > freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] External DNS and replication > > > > > > > > On 08.03.2017 14:05, Wimmer Ronald (BCC.B.SO) wrote: > > Hi, > > > > I am using FreeIPA with external DNS. Is it ok to balance the > requests between master and replica with DNS SRV records like this: > > > > _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88 > ipa1.example.net. > > _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88 > ipa1.example.net. > > _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. > > _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net. > > _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net. > > _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net. > > _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa1.example.net. > > _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa1.example.net. > > > > _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88 > ipa2.example.net. > > _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88 > ipa2.example.net. > > _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. > > _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net. > > _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net. > > _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net. > > _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa2.example.net. > > _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa2.example.net. > > > > _kerberos.example.net. 86400 IN TXT "example.net" > > Looks good to me > > > ipa-ca.example.net. 86400 IN A 10.66.39.130 > > > > What about the ?ipa-ca? entry? > > > ipa-ca should contain all A/AAAA records of CA replicas > > IPA4.4+ support command `ipa dns-update-system-records --dry-run` to > get all required records > > > > Regards, > > Ronald > > > > > Martin > > > > Thank?s a lot. In https://access.redhat.com/solutions/98043 RedHat > suggest to use same weight and same priority for the SRV records. Does > that make sense? > Priority should be same, otherwise servers with higher priority will work only as backups (preferably you should have priority 0). You can edit weight to distribute more load to beefy servers. Please note that priority and weight is handled on client side, so it will work only on clients that are processing SRV with priority and weight. Some clients may ignore it. > > > I also noticed that I have no ndp record. Are IPA clients relying on > that entry? Do I have to create these manually? > > > > _ntp._udp.example.net. 86400 IN SRV 10 50 123 > ipaserver1.example.net. > > _ntp._udp.example.net. 86400 IN SRV 10 50 123 > ipaserver2.example.net. > It depends on your system configuration on clients. This is basically used only by ipa-client-install because AFAIK ntp client doesn't support SRV lookup. Usually clients have default NTP client configured so it should work. > > > Ronald > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From mbasti at redhat.com Thu Mar 9 11:08:45 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 9 Mar 2017 12:08:45 +0100 Subject: [Freeipa-users] What is the next free IP address for a DNS record In-Reply-To: <3dd89442-4ce1-4e03-d9ff-3c065f062e44@ghs.com> References: <3dd89442-4ce1-4e03-d9ff-3c065f062e44@ghs.com> Message-ID: <91409d38-3b46-f8c1-0ce6-06f50abf93d6@redhat.com> Comments inline On 09.03.2017 11:12, Kees Bakker wrote: > Hey, > > Is there an easy way to find out what the next free IP address is when adding a new > DNS A record? The web interface sorts the records alphabetically on "Record name", > even in-arpa zones. For the latter it would be more convenient to sort numerically. No, it depends on your system. FreeIPA is not an authoritative source of IP addresses, this is job for DHCP server or any network management system. I don't think that we should sort numerically as DNS names works with bytes, so ASCII sorting is better. Nothing prevents you to use non-numeric domain with PTR RR type. > > Anyway, what methods are there to know what IP address to use when adding a new > DNS record? Did I overlook something? Usually when you are adding a new A record, you know for which host it belongs, so you should use the IP address of the host. > > BTW. Right now I'm dumping the JSON with > ipa -vv dnsrecord-find mydomain --sizelimit=99999 --all --structured 2>&1 >/dev/null > and a Python script to make a list sorted on ip address. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From mbasti at redhat.com Thu Mar 9 11:12:57 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 9 Mar 2017 12:12:57 +0100 Subject: [Freeipa-users] Potential problems when using a loadbalancer In-Reply-To: <97E471CB191D044F9F018C77836CF85B8A03E9CB@ARSEX004.oebb.at> References: <97E471CB191D044F9F018C77836CF85B8A03E9CB@ARSEX004.oebb.at> Message-ID: On 09.03.2017 11:04, Wimmer Ronald (BCC.B.SO) wrote: > > Hi, > > > > what kind of challenges will I run into when I want to use a > loadbalancer in front of my two IPA servers? > > > > - LDAP: Should not be a problem > > - Kerberos: will definitely be a challenge. > Is this link the solution or am I still missing something: > http://directory.fedoraproject.org/docs/389ds/howto/howto-loadbalance-gssapi.html > > - Certificates: I stumbled upon a RedHat Knowledgebase entry > dealing with ?Certificate CN not matching when using the > loadbalancer?s virtual name?: https://access.redhat.com/solutions/547723 > > - What else will be a problem that needs to be solved? > > > > Any hints regarding the ?what else? point would be highly appreciated! > > > > Regards, > > Ronald > > > This may help you https://www.adelton.com/freeipa/freeipa-behind-load-balancer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From barrykfl at gmail.com Thu Mar 9 11:16:41 2017 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Thu, 9 Mar 2017 19:16:41 +0800 Subject: [Freeipa-users] Create Replica fail any idea?? thz Message-ID: No expire cer prompt out ., All service ipa status oK. and 9444 port can telent Creating SSL certificate for the Directory Server preparation of replica failed: cannot connect to ' https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': (PR_END_OF_FILE_ERROR) Encountered end of file. cannot connect to ' https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': (PR_END_OF_FILE_ERROR) Encountered end of file. File "/usr/sbin/ipa-replica-prepare", line 490, in main() File "/usr/sbin/ipa-replica-prepare", line 361, in main export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", replica_fqdn, subject_base) File "/usr/sbin/ipa-replica-prepare", line 150, in export_certdb raise e -------------- next part -------------- An HTML attachment was scrubbed... URL: From keesb at ghs.com Thu Mar 9 12:19:50 2017 From: keesb at ghs.com (Kees Bakker) Date: Thu, 9 Mar 2017 13:19:50 +0100 Subject: [Freeipa-users] What is the next free IP address for a DNS record In-Reply-To: <91409d38-3b46-f8c1-0ce6-06f50abf93d6@redhat.com> References: <3dd89442-4ce1-4e03-d9ff-3c065f062e44@ghs.com> <91409d38-3b46-f8c1-0ce6-06f50abf93d6@redhat.com> Message-ID: On 09-03-17 12:08, Martin Basti wrote: > Comments inline > > > On 09.03.2017 11:12, Kees Bakker wrote: >> Hey, >> >> Is there an easy way to find out what the next free IP address is when adding a new >> DNS A record? The web interface sorts the records alphabetically on "Record name", >> even in-arpa zones. For the latter it would be more convenient to sort numerically. > No, it depends on your system. FreeIPA is not an authoritative source of > IP addresses, this is job for DHCP server or any network management system. DHCP, no. "any network management system", that would be the DNS service in our FreeIPA. > > I don't think that we should sort numerically as DNS names works with > bytes, so ASCII sorting is better. Nothing prevents you to use > non-numeric domain with PTR RR type. In this case I was referring to the reverse DNS records in the in-arpa zones. The Record Name for these zones are alway numeric, aren't they? >> Anyway, what methods are there to know what IP address to use when adding a new >> DNS record? Did I overlook something? > Usually when you are adding a new A record, you know for which host it > belongs, so you should use the IP address of the host. I'm not talking about an existing host. I want to add a _new_ host with a _new_ DNS A record. There is no IP address yet. And that's exactly my problem. What IP address to pick? FreeIPA/DNS is my authority, so to speak. But there is no simple method to find the next free IP address. In the "old days" we had a straightforward bind configuration. I'd had to edit two files, one for the domain zone and one for the in-arpa zone. But now the DNS server gets its zone information from FreeIPA (through LDAP). > >> BTW. Right now I'm dumping the JSON with >> ipa -vv dnsrecord-find mydomain --sizelimit=99999 --all --structured 2>&1 >/dev/null >> and a Python script to make a list sorted on ip address. > Martin > From tkrizek at redhat.com Thu Mar 9 12:26:38 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Thu, 9 Mar 2017 13:26:38 +0100 Subject: [Freeipa-users] What is the next free IP address for a DNS record In-Reply-To: References: <3dd89442-4ce1-4e03-d9ff-3c065f062e44@ghs.com> <91409d38-3b46-f8c1-0ce6-06f50abf93d6@redhat.com> Message-ID: <9e9218b4-18b2-15d0-3fb4-ea6862ec4798@redhat.com> On 03/09/2017 01:19 PM, Kees Bakker wrote: > On 09-03-17 12:08, Martin Basti wrote: >> Comments inline >> >> >> On 09.03.2017 11:12, Kees Bakker wrote: >>> Hey, >>> >>> Is there an easy way to find out what the next free IP address is when adding a new >>> DNS A record? The web interface sorts the records alphabetically on "Record name", >>> even in-arpa zones. For the latter it would be more convenient to sort numerically. >> No, it depends on your system. FreeIPA is not an authoritative source of >> IP addresses, this is job for DHCP server or any network management system. > DHCP, no. > "any network management system", that would be the DNS service in our FreeIPA. DNS A records only translate the hostnames to IPv4 addresses. DNS does not assign the addresses. That's something DHCP would do. If you do not use DHCP and assign the IP addresses statically, the network administrator would be the person responsible for assigning you a free IP address. -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mbasti at redhat.com Thu Mar 9 12:31:17 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 9 Mar 2017 13:31:17 +0100 Subject: [Freeipa-users] What is the next free IP address for a DNS record In-Reply-To: References: <3dd89442-4ce1-4e03-d9ff-3c065f062e44@ghs.com> <91409d38-3b46-f8c1-0ce6-06f50abf93d6@redhat.com> Message-ID: <0f38bcb9-7682-9f1b-7d45-3c5bf0f025c9@redhat.com> On 09.03.2017 13:19, Kees Bakker wrote: > On 09-03-17 12:08, Martin Basti wrote: >> Comments inline >> >> >> On 09.03.2017 11:12, Kees Bakker wrote: >>> Hey, >>> >>> Is there an easy way to find out what the next free IP address is when adding a new >>> DNS A record? The web interface sorts the records alphabetically on "Record name", >>> even in-arpa zones. For the latter it would be more convenient to sort numerically. >> No, it depends on your system. FreeIPA is not an authoritative source of >> IP addresses, this is job for DHCP server or any network management system. > DHCP, no. > "any network management system", that would be the DNS service in our FreeIPA. DNS is not suitable to be a source of unused IP addresses, that's work for DHCP, DNS has no information about network ranges. FreeIPA works in different way, you are responsible for creating and provisioning a host, assigning an IP address and then enroll the host to FreeIPA (IP address should be automatically updated in DNS). FreeIPA is so far from being a network management system. > >> I don't think that we should sort numerically as DNS names works with >> bytes, so ASCII sorting is better. Nothing prevents you to use >> non-numeric domain with PTR RR type. > In this case I was referring to the reverse DNS records in the in-arpa > zones. The Record Name for these zones are alway numeric, aren't they? https://tools.ietf.org/html/rfc2317 > >>> Anyway, what methods are there to know what IP address to use when adding a new >>> DNS record? Did I overlook something? >> Usually when you are adding a new A record, you know for which host it >> belongs, so you should use the IP address of the host. > I'm not talking about an existing host. I want to add a _new_ host > with a _new_ DNS A record. There is no IP address yet. And that's exactly > my problem. What IP address to pick? FreeIPA/DNS is my authority, so to speak. > But there is no simple method to find the next free IP address. > > In the "old days" we had a straightforward bind configuration. I'd had to edit > two files, one for the domain zone and one for the in-arpa zone. But now the > DNS server gets its zone information from FreeIPA (through LDAP). You can use AXFR from DNS to get all records from zone, sort it and check free IP addresses. But there is no standard tool for that in DNS. You have to create your own script > >>> BTW. Right now I'm dumping the JSON with >>> ipa -vv dnsrecord-find mydomain --sizelimit=99999 --all --structured 2>&1 >/dev/null >>> and a Python script to make a list sorted on ip address. >> Martin >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From keesb at ghs.com Thu Mar 9 12:33:22 2017 From: keesb at ghs.com (Kees Bakker) Date: Thu, 9 Mar 2017 13:33:22 +0100 Subject: [Freeipa-users] What is the next free IP address for a DNS record In-Reply-To: <9e9218b4-18b2-15d0-3fb4-ea6862ec4798@redhat.com> References: <3dd89442-4ce1-4e03-d9ff-3c065f062e44@ghs.com> <91409d38-3b46-f8c1-0ce6-06f50abf93d6@redhat.com> <9e9218b4-18b2-15d0-3fb4-ea6862ec4798@redhat.com> Message-ID: On 09-03-17 13:26, Tomas Krizek wrote: > On 03/09/2017 01:19 PM, Kees Bakker wrote: >> On 09-03-17 12:08, Martin Basti wrote: >>> On 09.03.2017 11:12, Kees Bakker wrote: >>>> Hey, >>>> >>>> Is there an easy way to find out what the next free IP address is when adding a new >>>> DNS A record? The web interface sorts the records alphabetically on "Record name", >>>> even in-arpa zones. For the latter it would be more convenient to sort numerically. >>> No, it depends on your system. FreeIPA is not an authoritative source of >>> IP addresses, this is job for DHCP server or any network management system. >> DHCP, no. >> "any network management system", that would be the DNS service in our FreeIPA. > DNS A records only translate the hostnames to IPv4 addresses. DNS does > not assign the addresses. That's something DHCP would do. If you do not > use DHCP and assign the IP addresses statically, the network > administrator would be the person responsible for assigning you a free > IP address. > Yes, I'm talking about static addresses. Is it really such a strange question to ask for static IP addresses? The network administrator, that would be me. From simo at redhat.com Thu Mar 9 13:07:31 2017 From: simo at redhat.com (Simo Sorce) Date: Thu, 09 Mar 2017 08:07:31 -0500 Subject: [Freeipa-users] What is the next free IP address for a DNS record In-Reply-To: References: <3dd89442-4ce1-4e03-d9ff-3c065f062e44@ghs.com> <91409d38-3b46-f8c1-0ce6-06f50abf93d6@redhat.com> <9e9218b4-18b2-15d0-3fb4-ea6862ec4798@redhat.com> Message-ID: <1489064851.4333.6.camel@redhat.com> On Thu, 2017-03-09 at 13:33 +0100, Kees Bakker wrote: > On 09-03-17 13:26, Tomas Krizek wrote: > > On 03/09/2017 01:19 PM, Kees Bakker wrote: > > > On 09-03-17 12:08, Martin Basti wrote: > > > > On 09.03.2017 11:12, Kees Bakker wrote: > > > > > Hey, > > > > > > > > > > Is there an easy way to find out what the next free IP > > > > > address is when adding a new > > > > > DNS A record? The web interface sorts the records > > > > > alphabetically on "Record name", > > > > > even in-arpa zones. For the latter it would be more > > > > > convenient to sort numerically. > > > > > > > > No, it depends on your system. FreeIPA is not an authoritative > > > > source of > > > > IP addresses, this is job for DHCP server or any network > > > > management system. > > > > > > DHCP, no. > > > "any network management system", that would be the DNS service in > > > our FreeIPA. > > > > DNS A records only translate the hostnames to IPv4 addresses. DNS > > does > > not assign the addresses. That's something DHCP would do. If you do > > not > > use DHCP and assign the IP addresses statically, the network > > administrator would be the person responsible for assigning you a > > free > > IP address. > > > > Yes, I'm talking about static addresses. Is it really such a strange > question to > ask for static IP addresses? > > The network administrator, that would be me. Would it be sufficient to you to have a command line tool to run against LDAP top list all existing IP addresses and sort them ? If so this is what I use (assuming a realm called example.com): ldapsearch -Y GSSAPI -s one -b "idnsname=example.com.,cn=dns,dc=example,dc=com" aRecord 2>/dev/null |grep "^aRecord" |sort Note: You need to be logged in (kinit'ed) with a user that has rights to see the DNS tree. HTH, Simo. From keesb at ghs.com Thu Mar 9 13:36:47 2017 From: keesb at ghs.com (Kees Bakker) Date: Thu, 9 Mar 2017 14:36:47 +0100 Subject: [Freeipa-users] What is the next free IP address for a DNS record In-Reply-To: <1489064851.4333.6.camel@redhat.com> References: <3dd89442-4ce1-4e03-d9ff-3c065f062e44@ghs.com> <91409d38-3b46-f8c1-0ce6-06f50abf93d6@redhat.com> <9e9218b4-18b2-15d0-3fb4-ea6862ec4798@redhat.com> <1489064851.4333.6.camel@redhat.com> Message-ID: On 09-03-17 14:07, Simo Sorce wrote: > On Thu, 2017-03-09 at 13:33 +0100, Kees Bakker wrote: >> On 09-03-17 13:26, Tomas Krizek wrote: >>> On 03/09/2017 01:19 PM, Kees Bakker wrote: >>>> On 09-03-17 12:08, Martin Basti wrote: >>>>> On 09.03.2017 11:12, Kees Bakker wrote: >>>>>> Hey, >>>>>> >>>>>> Is there an easy way to find out what the next free IP >>>>>> address is when adding a new >>>>>> DNS A record? The web interface sorts the records >>>>>> alphabetically on "Record name", >>>>>> even in-arpa zones. For the latter it would be more >>>>>> convenient to sort numerically. >>>>> No, it depends on your system. FreeIPA is not an authoritative >>>>> source of >>>>> IP addresses, this is job for DHCP server or any network >>>>> management system. >>>> DHCP, no. >>>> "any network management system", that would be the DNS service in >>>> our FreeIPA. >>> DNS A records only translate the hostnames to IPv4 addresses. DNS >>> does >>> not assign the addresses. That's something DHCP would do. If you do >>> not >>> use DHCP and assign the IP addresses statically, the network >>> administrator would be the person responsible for assigning you a >>> free >>> IP address. >>> >> Yes, I'm talking about static addresses. Is it really such a strange >> question to >> ask for static IP addresses? >> >> The network administrator, that would be me. > Would it be sufficient to you to have a command line tool to run > against LDAP top list all existing IP addresses and sort them ? > > If so this is what I use (assuming a realm called example.com): > > > ldapsearch -Y GSSAPI -s one -b "idnsname=example.com.,cn=dns,dc=example,dc=com" aRecord 2>/dev/null |grep "^aRecord" |sort > > Note: You need to be logged in (kinit'ed) with a user that has rights > to see the DNS tree. > Thanks. That is more or less like what I am doing, beit that I use the JSON output of ipa dnsrecord-find, and a Python script to massage the output and get a list like this: 172.16.16.87 grift 172.16.16.88 qlcmdevl 172.16.16.91 sp2 172.16.16.95 kwistbeek 172.16.16.96 keersop 172.16.16.97 lutjewad Anyway, from the answers I gather that this is what it is. Which is not a huge problem. I was just curious if there were easier methods. -- Kees From igorvt77 at gmail.com Thu Mar 9 19:05:21 2017 From: igorvt77 at gmail.com (Robert Johnson) Date: Thu, 9 Mar 2017 14:05:21 -0500 Subject: [Freeipa-users] Question about ipa user accounts and the compat container Message-ID: Hello, I am running into an odd issue haven't been able to find any information through searching on this issue online. Environment: We are currently have a IPA master running ipa-server-4.4.0-14.el7_3.4.x86_64 on a RHEL 7.3 server. We have a mix of RHEL 6.8, RHEL 7.x and Solaris 10 clients. We also have a one way trust to a windows domain. Compatibility mode is enabled. The issue I'm seeing is that when I delete an IPA domain user through the web gui, the user account doesn't appear to be removed completely from the system. I verified via "ipa user-find" that the user is no longer in the system. I also checked via "ldapsearch" that the user account doesn't exist in the "accounts" container. However, when I look in the "users, compat" container, that user still exists. This is causing problems with my Solaris clients since they are pointing to the compat tree so that we can login with the windows accounts on those servers. The Solaris client is still seeing the account as being valid and is asking the user for a password on login which fails because the account doesn't exist in the IPA domain anymore. Do I need to remove the account from the ldap compat container manually or is the IPA user delete command (through the gui and/or command line) suppose to take care of this ? Or is there is some sort of clean up process that I have to wait for to occur before this account gets removed from that container ? If so, what is the time frame ? Thank you Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Mar 9 21:06:20 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 9 Mar 2017 23:06:20 +0200 Subject: [Freeipa-users] Question about ipa user accounts and the compat container In-Reply-To: References: Message-ID: <20170309210620.kgnxbwet4n5lhdtg@redhat.com> On to, 09 maalis 2017, Robert Johnson wrote: >Hello, > >I am running into an odd issue haven't been able to find any information >through searching on this issue online. > >Environment: We are currently have a IPA master running >ipa-server-4.4.0-14.el7_3.4.x86_64 on a RHEL 7.3 server. We have a mix of >RHEL 6.8, RHEL 7.x and Solaris 10 clients. We also have a one way trust to >a windows domain. Compatibility mode is enabled. > >The issue I'm seeing is that when I delete an IPA domain user through the >web gui, the user account doesn't appear to be removed completely from the >system. I verified via "ipa user-find" that the user is no longer in the >system. I also checked via "ldapsearch" that the user account doesn't >exist in the "accounts" container. However, when I look in the "users, >compat" container, that user still exists. > >This is causing problems with my Solaris clients since they are pointing to >the compat tree so that we can login with the windows accounts on those >servers. The Solaris client is still seeing the account as being valid and >is asking the user for a password on login which fails because the account >doesn't exist in the IPA domain anymore. > >Do I need to remove the account from the ldap compat container manually or >is the IPA user delete command (through the gui and/or command line) >suppose to take care of this ? Or is there is some sort of clean up >process that I have to wait for to occur before this account gets removed >from that container ? If so, what is the time frame ? Compat tree is automatically generated. It also tracks existing objects, so any time the object is removed from the primary tree, it should be cleared from the compat tree as well. If you can reliably demonstrate the problem using http://www.freeipa.org/page/Demo (it has compat tree enabled), then feel free to open a bug. -- / Alexander Bokovoy From yamakasi.014 at gmail.com Thu Mar 9 21:51:13 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 9 Mar 2017 22:51:13 +0100 Subject: [Freeipa-users] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute Message-ID: I'm trying to add a host using Foreman to the FreeIPA realm but this doesn't work, all things seem to be fine and some other tests from people are working: The issue is reported here: http://projects.theforeman.org/issues/18850 My settings are like this: [root at ipa-01 ~]# ipa role-find --------------- 6 roles matched --------------- Role name: helpdesk Description: Helpdesk Role name: IT Security Specialist Description: IT Security Specialist Role name: IT Specialist Description: IT Specialist Role name: Security Architect Description: Security Architect Role name: Smart Proxy Host Manager Description: Smart Proxy management Role name: User Administrator Description: Responsible for creating Users and Groups ---------------------------- Number of entries returned 6 ---------------------------- [root at ipa-01 ~]# ipa role-show "Smart Proxy Host Manager" Role name: Smart Proxy Host Manager Description: Smart Proxy management Member users: foreman-proxy, foreman-realm-proxy Privileges: Smart Proxy Host Management [root at ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management" Privilege name: Smart Proxy Host Management Description: Smart Proxy Host Management Permissions: Retrieve Certificates from the CA, System: Add DNS Entries, System: Read DNS Entries, System: Remove DNS Entries, System: Update DNS Entries, System: Manage Host Certificates, System: Manage Host Enrollment Password, System: Manage Host Keytab, System: Modify Hosts, System: Remove Hosts, System: Manage Service Keytab, System: Modify Services, Add Host Enrollment Password Granting privilege to roles: Smart Proxy Host Manager [root at ipa-01 ~]# [root at ipa-01 ~]# ipa permission-find "Add Host" --------------------- 3 permissions matched --------------------- Permission name: Add Host Enrollment Password Granted rights: add Effective attributes: userpassword Bind rule type: permission Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld Type: host Permission flags: V2, SYSTEM Permission name: System: Add Hostgroups Granted rights: add Bind rule type: permission Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld Type: hostgroup Permission flags: V2, MANAGED, SYSTEM Permission name: System: Add Hosts Granted rights: add Bind rule type: permission Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld Type: host Permission flags: V2, MANAGED, SYSTEM ---------------------------- Number of entries returned 3 ---------------------------- Can anyone help me out as I'm unsure where this goes wrong. Thanks so far! Regards, Matt From igorvt77 at gmail.com Thu Mar 9 23:11:47 2017 From: igorvt77 at gmail.com (Robert Johnson) Date: Thu, 9 Mar 2017 18:11:47 -0500 Subject: [Freeipa-users] Question about ipa user accounts and the compat container In-Reply-To: <20170309210620.kgnxbwet4n5lhdtg@redhat.com> References: <20170309210620.kgnxbwet4n5lhdtg@redhat.com> Message-ID: On Thu, Mar 9, 2017 at 4:06 PM, Alexander Bokovoy wrote: > On to, 09 maalis 2017, Robert Johnson wrote: > >> Hello, >> >> I am running into an odd issue haven't been able to find any information >> through searching on this issue online. >> >> Environment: We are currently have a IPA master running >> ipa-server-4.4.0-14.el7_3.4.x86_64 on a RHEL 7.3 server. We have a mix >> of >> RHEL 6.8, RHEL 7.x and Solaris 10 clients. We also have a one way trust to >> a windows domain. Compatibility mode is enabled. >> >> The issue I'm seeing is that when I delete an IPA domain user through the >> web gui, the user account doesn't appear to be removed completely from the >> system. I verified via "ipa user-find" that the user is no longer in the >> system. I also checked via "ldapsearch" that the user account doesn't >> exist in the "accounts" container. However, when I look in the "users, >> compat" container, that user still exists. >> >> This is causing problems with my Solaris clients since they are pointing >> to >> the compat tree so that we can login with the windows accounts on those >> servers. The Solaris client is still seeing the account as being valid >> and >> is asking the user for a password on login which fails because the account >> doesn't exist in the IPA domain anymore. >> >> Do I need to remove the account from the ldap compat container manually or >> is the IPA user delete command (through the gui and/or command line) >> suppose to take care of this ? Or is there is some sort of clean up >> process that I have to wait for to occur before this account gets removed >> from that container ? If so, what is the time frame ? >> > Compat tree is automatically generated. It also tracks existing objects, > so any time the object is removed from the primary tree, it should be > cleared from the compat tree as well. > > If you can reliably demonstrate the problem using > http://www.freeipa.org/page/Demo (it has compat tree enabled), then feel > free to open a bug. > > -- > / Alexander Bokovoy > So after doing some more digging using ldapsearch, I discovered some "odd" entries. It appears that all my IPA users appear to have duplicate entries under the compat tree. So on a hunch I deleted another IPA user and one of the two entries disappeared from the container. I tried to use ldapdelete (and ldapmodify) to remove the "ghost" entry using the DN I found from the search and I get a "object not found" and then it says that it matched the base tree. If I dump the whole compat tree out to a file, the ghost objects look to be exact duplicates of the original entries (minus the guid which is different). I can't seem to find a way to remove them. Any ideas ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From techpkiuser at gmail.com Fri Mar 10 05:20:37 2017 From: techpkiuser at gmail.com (Kaamel Periora) Date: Fri, 10 Mar 2017 10:50:37 +0530 Subject: [Freeipa-users] Padding Scheme used in Fedora Dogtag In-Reply-To: <1488896730.16250.24.camel@redhat.com> References: <1488896730.16250.24.camel@redhat.com> Message-ID: its for the encryption process. On Tue, Mar 7, 2017 at 7:55 PM, Simo Sorce wrote: > On Tue, 2017-03-07 at 12:38 +0530, Kaamel Periora wrote: > > Dear All, > > > > It is required to identify the padding scheme used by the Fedora dogtag > > system. Appreciate of someone could shed some light on this requirement. > > Padding scheme for what exactly ? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Mar 10 06:16:34 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Mar 2017 08:16:34 +0200 Subject: [Freeipa-users] Question about ipa user accounts and the compat container In-Reply-To: References: <20170309210620.kgnxbwet4n5lhdtg@redhat.com> Message-ID: <20170310061634.saw7sbp2lvm7if6h@redhat.com> On to, 09 maalis 2017, Robert Johnson wrote: >On Thu, Mar 9, 2017 at 4:06 PM, Alexander Bokovoy >wrote: > >> On to, 09 maalis 2017, Robert Johnson wrote: >> >>> Hello, >>> >>> I am running into an odd issue haven't been able to find any information >>> through searching on this issue online. >>> >>> Environment: We are currently have a IPA master running >>> ipa-server-4.4.0-14.el7_3.4.x86_64 on a RHEL 7.3 server. We have a mix >>> of >>> RHEL 6.8, RHEL 7.x and Solaris 10 clients. We also have a one way trust to >>> a windows domain. Compatibility mode is enabled. >>> >>> The issue I'm seeing is that when I delete an IPA domain user through the >>> web gui, the user account doesn't appear to be removed completely from the >>> system. I verified via "ipa user-find" that the user is no longer in the >>> system. I also checked via "ldapsearch" that the user account doesn't >>> exist in the "accounts" container. However, when I look in the "users, >>> compat" container, that user still exists. >>> >>> This is causing problems with my Solaris clients since they are pointing >>> to >>> the compat tree so that we can login with the windows accounts on those >>> servers. The Solaris client is still seeing the account as being valid >>> and >>> is asking the user for a password on login which fails because the account >>> doesn't exist in the IPA domain anymore. >>> >>> Do I need to remove the account from the ldap compat container manually or >>> is the IPA user delete command (through the gui and/or command line) >>> suppose to take care of this ? Or is there is some sort of clean up >>> process that I have to wait for to occur before this account gets removed >>> from that container ? If so, what is the time frame ? >>> >> Compat tree is automatically generated. It also tracks existing objects, >> so any time the object is removed from the primary tree, it should be >> cleared from the compat tree as well. >> >> If you can reliably demonstrate the problem using >> http://www.freeipa.org/page/Demo (it has compat tree enabled), then feel >> free to open a bug. >> >> -- >> / Alexander Bokovoy >> > >So after doing some more digging using ldapsearch, I discovered some "odd" >entries. It appears that all my IPA users appear to have duplicate entries >under the compat tree. So on a hunch I deleted another IPA user and one of >the two entries disappeared from the container. I tried to use ldapdelete >(and ldapmodify) to remove the "ghost" entry using the DN I found from the >search and I get a "object not found" and then it says that it matched the >base tree. If I dump the whole compat tree out to a file, the ghost >objects look to be exact duplicates of the original entries (minus the guid >which is different). I can't seem to find a way to remove them. > >Any ideas ? Demonstrate your problem using the FreeIPA demo instance, please. Compat tree is not writable, thus you cannot delete anything from it directly. You only can delete the original entry to cause removal of a compat entry. Show how it is not removed with step by step ldapsearch/ipa CLI operations against our demo instance, please. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Mar 10 06:17:38 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 10 Mar 2017 08:17:38 +0200 Subject: [Freeipa-users] Padding Scheme used in Fedora Dogtag In-Reply-To: References: <1488896730.16250.24.camel@redhat.com> Message-ID: <20170310061738.udcme2eytiiq4bvm@redhat.com> On pe, 10 maalis 2017, Kaamel Periora wrote: >its for the encryption process. Sorry, but you need to be more detailed in what you want to achieve. Crypto libraries support multiple algorithms. What do you need to do? > >On Tue, Mar 7, 2017 at 7:55 PM, Simo Sorce wrote: > >> On Tue, 2017-03-07 at 12:38 +0530, Kaamel Periora wrote: >> > Dear All, >> > >> > It is required to identify the padding scheme used by the Fedora dogtag >> > system. Appreciate of someone could shed some light on this requirement. >> >> Padding scheme for what exactly ? >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> >-- >Manage your subscription for the Freeipa-users mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-users >Go to http://freeipa.org for more info on the project -- / Alexander Bokovoy From simo at redhat.com Fri Mar 10 07:26:26 2017 From: simo at redhat.com (Simo Sorce) Date: Fri, 10 Mar 2017 02:26:26 -0500 Subject: [Freeipa-users] Padding Scheme used in Fedora Dogtag In-Reply-To: References: <1488896730.16250.24.camel@redhat.com> Message-ID: <1489130786.7489.6.camel@redhat.com> On Fri, 2017-03-10 at 10:50 +0530, Kaamel Periora wrote: > its for the encryption process. Which process ? What protocol ? For data at rest or for secure channels ? Please be very specific, we use crypto in a multitude of places within freeIPA. Simo. > On Tue, Mar 7, 2017 at 7:55 PM, Simo Sorce wrote: > > On Tue, 2017-03-07 at 12:38 +0530, Kaamel Periora wrote: > > > Dear All, > > > > > > It is required to identify the padding scheme used by the Fedora > > dogtag > > > system. Appreciate of someone could shed some light on this > > requirement. > > > > Padding scheme for what exactly ? > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > > > From harald.dunkel at aixigo.de Fri Mar 10 12:16:42 2017 From: harald.dunkel at aixigo.de (Harald Dunkel) Date: Fri, 10 Mar 2017 13:16:42 +0100 Subject: [Freeipa-users] bad certificate used to sign freeipa Message-ID: Hi folks, I stumbled over this problem: http://openbsd-archive.7691.n7.nabble.com/Certificate-Error-quot-format-error-in-certificate-s-notAfter-field-quot-td304262.html The details don't really matter. The important point is that the root certificate used to sign freeipa's certificate appears to be unacceptable on openBSD and maybe others. What would you suggest? Is there a guideline to migrate freeipa to a new certificate authority? Every helpful comment is highly appreciated Harri From flo at redhat.com Fri Mar 10 13:06:19 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Fri, 10 Mar 2017 14:06:19 +0100 Subject: [Freeipa-users] bad certificate used to sign freeipa In-Reply-To: References: Message-ID: <00e57cfa-2ec4-84e8-0ddc-f08f31a56043@redhat.com> Hi, Which 'FreeIPA certificate' are you referring to? If you installed FreeIPA CA-less, then the root certificate was used to sign LDAP and HTTPd certificates and you can follow this page [1] to use a different CA and replace LDAP and HTTPd certs. If you installed IPA with an integrated CA, then the root certificate was used to sign IPA CA certificate, and the other certificates used by FreeIPA were signed by IPA CA. In this case you would have to replace IPA CA with [2] and then renew LDAP and HTTPd certificates [3]. Flo [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/third-party-certs-http-ldap.html [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cert-renewal.html#manual-cert-renewal-ext [3] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/replace-HTTP-LDAP-cert.html On 03/10/2017 01:16 PM, Harald Dunkel wrote: > Hi folks, > > I stumbled over this problem: > > http://openbsd-archive.7691.n7.nabble.com/Certificate-Error-quot-format-error-in-certificate-s-notAfter-field-quot-td304262.html > > The details don't really matter. The important point is that > the root certificate used to sign freeipa's certificate > appears to be unacceptable on openBSD and maybe others. > > What would you suggest? Is there a guideline to migrate > freeipa to a new certificate authority? > > > Every helpful comment is highly appreciated > Harri > From tkrizek at redhat.com Fri Mar 10 16:13:09 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Fri, 10 Mar 2017 17:13:09 +0100 Subject: [Freeipa-users] Announcing bind-dyndb-ldap 11.1 Message-ID: The FreeIPA team is proud to announce bind-dyndb-ldap version 11.1. It can be downloaded fromhttps://releases.pagure.org/bind-dyndb-ldap/ The new version has also been built for Fedora 26+: https://bodhi.fedoraproject.org/updates/FEDORA-2017-56aa9caed6 Latest news: 11.1 ==== [1] Prevent crash when server is shutting down and LDAP connection is down. https://pagure.io/bind-dyndb-ldap/issue/149 == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. == Known Issues == There are the following issues in Fedora 26+: - 1404409: Using GSSAPI authentication for 389-ds results in an error, simple bind is not affected. == Pagure migration == The bind-dyndb-ldap has been migrated from fedorahosted to https://pagure.io/bind-dyndb-ldap/ The wiki pages are currently not available and will be migrated in the upcoming weeks. == Feedback == Please provide comments, report bugs, and send any other feedback via the freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Mar 10 16:20:26 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Mar 2017 11:20:26 -0500 Subject: [Freeipa-users] Replica fail to create , all new cert already inside In-Reply-To: References: Message-ID: barrykfl at gmail.com wrote: > Hi: > > I already done input new cert but ipa-replica-prepare central03.ABC.com > (ipa 3.0) it fail with the error as below: > which "location" I should check the old cert still inside some where > > Below I already input CA / server cert ..and nssdb poting is right > ..already spent serveral days to check where is it I also try direct use > pfx for the cert directly but same error comesout...seem it still use > old cert to compare. > > Any idea ? many thanks > > /var/lib/pki-ca/alias > /etc/dirsrv/slapd-PKI-IPA/ > /etc/dirsrv/slapd-ABC-COM/ > /etc/httpd/alias/ > /etc/pki/nssdb/ > > I use similar commands as below: and follow steps here: https web side > already using new and dirsvr no error on starting only I cannot do > replicas . > > https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP#Procedure_in_IPA_.3C_4.1 > > certutil -A -d /var/lib/pki-ca/alias/ -n 'EXT-CA' -t CT,C,C -a -i > /root/ca.crt > > > ipa : ERROR cert validation failed for "CN=central.ABC.com > ,O=ABC.COM " > ((SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired.) > preparation of replica failed: cannot connect to > 'https://central.ABCcom:9444/ca/ee/ca/profileSubmitSSLClient': > (SEC_ERROR_EXPIRED_CERTIFICATE) Peer's Certificate has expired. > > Regards > > Barry > > Please stop creating new threads all for the same issue. Your CA subsystem certs are expired and you'll need to go through the renewal process to fix that. To do that you need to run `getcert list` and determine the time period where all the certs are valid, set the system time to then, restart IPA, restart certmonger. Knowing that you are using 3rd party certs instead perhaps this doesn't really matter to you. In any case you probably won't have much luck mixing and matching certificates between IPA-issued and whatever 3rd part you're using. The bottom line is you probably want to get 3rd party certs from whatever issuer provided the certs for your current master(s), stick those into PKCS#12 file(s) and pass that to ipa-replica-manage. So like I said in https://www.redhat.com/archives/freeipa-users/2017-March/msg00096.html , man ipa-replica-manage. rob From rcritten at redhat.com Fri Mar 10 16:21:54 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Mar 2017 11:21:54 -0500 Subject: [Freeipa-users] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute In-Reply-To: References: Message-ID: <950d5605-7ed1-8454-c5ae-85591899bd30@redhat.com> Matt . wrote: > I'm trying to add a host using Foreman to the FreeIPA realm but this > doesn't work, all things seem to be fine and some other tests from > people are working: > > The issue is reported here: http://projects.theforeman.org/issues/18850 > > > My settings are like this: > > > [root at ipa-01 ~]# ipa role-find > --------------- > 6 roles matched > --------------- > Role name: helpdesk > Description: Helpdesk > > Role name: IT Security Specialist > Description: IT Security Specialist > > Role name: IT Specialist > Description: IT Specialist > > Role name: Security Architect > Description: Security Architect > > Role name: Smart Proxy Host Manager > Description: Smart Proxy management > > Role name: User Administrator > Description: Responsible for creating Users and Groups > ---------------------------- > Number of entries returned 6 > ---------------------------- > [root at ipa-01 ~]# ipa role-show "Smart Proxy Host Manager" > Role name: Smart Proxy Host Manager > Description: Smart Proxy management > Member users: foreman-proxy, foreman-realm-proxy > Privileges: Smart Proxy Host Management > [root at ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management" > Privilege name: Smart Proxy Host Management > Description: Smart Proxy Host Management > Permissions: Retrieve Certificates from the CA, System: Add DNS > Entries, System: Read DNS Entries, System: Remove DNS Entries, System: > Update DNS > Entries, System: Manage Host Certificates, System: > Manage Host Enrollment Password, System: Manage Host Keytab, System: > Modify Hosts, > System: Remove Hosts, System: Manage Service Keytab, > System: Modify Services, Add Host Enrollment Password > Granting privilege to roles: Smart Proxy Host Manager > [root at ipa-01 ~]# > [root at ipa-01 ~]# ipa permission-find "Add Host" > --------------------- > 3 permissions matched > --------------------- > Permission name: Add Host Enrollment Password > Granted rights: add > Effective attributes: userpassword > Bind rule type: permission > Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld > Type: host > Permission flags: V2, SYSTEM > > Permission name: System: Add Hostgroups > Granted rights: add > Bind rule type: permission > Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld > Type: hostgroup > Permission flags: V2, MANAGED, SYSTEM > > Permission name: System: Add Hosts > Granted rights: add > Bind rule type: permission > Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld > Type: host > Permission flags: V2, MANAGED, SYSTEM > ---------------------------- > Number of entries returned 3 > ---------------------------- > > > Can anyone help me out as I'm unsure where this goes wrong. > For 'Add Host Enrollment Password' the granted rights should be write not add. add is for adding entries, not writing attributes. rob From rcritten at redhat.com Fri Mar 10 16:24:33 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Mar 2017 11:24:33 -0500 Subject: [Freeipa-users] slapi_ldap_bind - Error: could not send startTLS request In-Reply-To: <0e318ad4-f719-aed0-b35c-de911a5069a3@yahoo.co.uk> References: <2a5e833a-5c7d-3385-bf17-620cd42aa805@redhat.com> <0e318ad4-f719-aed0-b35c-de911a5069a3@yahoo.co.uk> Message-ID: lejeczek wrote: > > > On 06/03/17 20:11, Rob Crittenden wrote: >> lejeczek wrote: >>> hi everyone >>> I've seemingly finely working domain, I mean it all seem fine to me, >>> except for: >>> >>> [04/Mar/2017:14:26:47.439218725 +0000] slapi_ldap_bind - Error: could >>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>> 107 (Transport endpoint is not connected) >>> [04/Mar/2017:14:26:47.441155853 +0000] slapi_ldap_bind - Error: could >>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>> 107 (Transport endpoint is not connected) >>> [04/Mar/2017:14:31:47.454016982 +0000] slapi_ldap_bind - Error: could >>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>> 107 (Transport endpoint is not connected) >>> [04/Mar/2017:14:31:47.482477473 +0000] slapi_ldap_bind - Error: could >>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>> 107 (Transport endpoint is not connected) >>> [04/Mar/2017:14:36:46.458508994 +0000] slapi_ldap_bind - Error: could >>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>> 107 (Transport endpoint is not connected) >>> [04/Mar/2017:14:36:46.479878884 +0000] slapi_ldap_bind - Error: could >>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>> 107 (Transport endpoint is not connected) >>> [04/Mar/2017:14:41:47.389700728 +0000] slapi_ldap_bind - Error: could >>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>> 107 (Transport endpoint is not connected) >>> [04/Mar/2017:14:41:47.394379376 +0000] slapi_ldap_bind - Error: could >>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>> 107 (Transport endpoint is not connected) >>> >>> being logged quite frequently, as you can see. Setup: >>> >>> ipa-client-4.4.0-14.el7.centos.4.x86_64 >>> ipa-client-common-4.4.0-14.el7.centos.4.noarch >>> ipa-common-4.4.0-14.el7.centos.4.noarch >>> ipa-python-compat-4.4.0-14.el7.centos.4.noarch >>> ipa-server-4.4.0-14.el7.centos.4.x86_64 >>> ipa-server-common-4.4.0-14.el7.centos.4.noarch >>> ipa-server-dns-4.4.0-14.el7.centos.4.noarch >>> >>> Replication, users, logins, all seem normal. But above bothers me as I >>> am afraid it may one day turn out critical and brake stuff down. >>> This is on the first server that initiated the domain, long time ago. >>> There is a second server which logs the same, but only a few entries >>> then goes quiet. >>> Third server's error log is completely free from this error. >>> >>> Would appreciate all help. >> The CA replication agreements are handled by ipa-csreplica-manage. You >> may have leftover agreements from previous installs there. >> >> rob >> > I'm afraid I let over the years for some bits in the domain gone > haywire. I found this: > > dn: cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > cn: ca > objectClass: nsContainer > objectClass: top > > dn: cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > cn: certprofiles > objectClass: nsContainer > objectClass: top > > dn: cn=caacls,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > cn: caacls > objectClass: nsContainer > objectClass: top > > dn: > cn=cas+nsuniqueid=647ed0b1-b70911e6-b84df1c7-2176fa48,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > cn: cas > objectClass: nsContainer > objectClass: top > > dn: cn=cas,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > cn: cas > objectClass: nsContainer > objectClass: top > > dn: > cn=IECUserRoles,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > description: User profile that includes IECUserRoles extension from request > ipaCertProfileStoreIssued: TRUE > cn: IECUserRoles > objectClass: ipacertprofile > objectClass: top > > dn: > cn=caIPAserviceCert,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > description: Standard profile for network services > ipaCertProfileStoreIssued: TRUE > cn: caIPAserviceCert > objectClass: ipacertprofile > objectClass: top > > dn: > ipaUniqueID=1ea0be16-fc01-11e5-a664-f04da240c1d2,cn=caacls,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > ipaMemberCertProfile: > cn=caIPAserviceCert,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > ipaUniqueID: 1ea0be16-fc01-11e5-a664-f04da240c1d2 > ipaEnabledFlag: TRUE > hostCategory: all > objectClass: ipaassociation > objectClass: ipacaacl > cn: hosts_services_caIPAserviceCert > serviceCategory: all > > dn: > cn=ipa,cn=cas+nsuniqueid=647ed0b1-b70911e6-b84df1c7-2176fa48,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > cn: ipa > ipaCaId: 0725f730-9351-4115-aa68-ecb2f47dd805 > ipaCaSubjectDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x > objectClass: top > objectClass: ipaca > ipaCaIssuerDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x > description: IPA CA > > dn: cn=ipa,cn=cas,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x > cn: ipa > ipaCaId: ed1bbc62-45c5-4d4a-96fb-0c16129dbad0 > ipaCaSubjectDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x > objectClass: top > objectClass: ipaca > ipaCaIssuerDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x > description: IPA CA > > is this the culprit? You have some replication conflict entries in there. I see no way how this could affect a connection issue though it is something you should clean up. I'd use tcpdump/wireshark to see what is going on. It will show you if it is a simple connection failure or an SSL handshake failure. rob From yamakasi.014 at gmail.com Fri Mar 10 18:40:20 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 10 Mar 2017 19:40:20 +0100 Subject: [Freeipa-users] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute In-Reply-To: <950d5605-7ed1-8454-c5ae-85591899bd30@redhat.com> References: <950d5605-7ed1-8454-c5ae-85591899bd30@redhat.com> Message-ID: Hi Rob, Thanks, but what do you mean here ? The Foreman has a script which should be OK for it: https://github.com/theforeman/smart-proxy/blob/develop/sbin/foreman-prepare-realm Can you check this maybe ? Thanks, Matt 2017-03-10 17:21 GMT+01:00 Rob Crittenden : > Matt . wrote: >> I'm trying to add a host using Foreman to the FreeIPA realm but this >> doesn't work, all things seem to be fine and some other tests from >> people are working: >> >> The issue is reported here: http://projects.theforeman.org/issues/18850 >> >> >> My settings are like this: >> >> >> [root at ipa-01 ~]# ipa role-find >> --------------- >> 6 roles matched >> --------------- >> Role name: helpdesk >> Description: Helpdesk >> >> Role name: IT Security Specialist >> Description: IT Security Specialist >> >> Role name: IT Specialist >> Description: IT Specialist >> >> Role name: Security Architect >> Description: Security Architect >> >> Role name: Smart Proxy Host Manager >> Description: Smart Proxy management >> >> Role name: User Administrator >> Description: Responsible for creating Users and Groups >> ---------------------------- >> Number of entries returned 6 >> ---------------------------- >> [root at ipa-01 ~]# ipa role-show "Smart Proxy Host Manager" >> Role name: Smart Proxy Host Manager >> Description: Smart Proxy management >> Member users: foreman-proxy, foreman-realm-proxy >> Privileges: Smart Proxy Host Management >> [root at ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management" >> Privilege name: Smart Proxy Host Management >> Description: Smart Proxy Host Management >> Permissions: Retrieve Certificates from the CA, System: Add DNS >> Entries, System: Read DNS Entries, System: Remove DNS Entries, System: >> Update DNS >> Entries, System: Manage Host Certificates, System: >> Manage Host Enrollment Password, System: Manage Host Keytab, System: >> Modify Hosts, >> System: Remove Hosts, System: Manage Service Keytab, >> System: Modify Services, Add Host Enrollment Password >> Granting privilege to roles: Smart Proxy Host Manager >> [root at ipa-01 ~]# >> [root at ipa-01 ~]# ipa permission-find "Add Host" >> --------------------- >> 3 permissions matched >> --------------------- >> Permission name: Add Host Enrollment Password >> Granted rights: add >> Effective attributes: userpassword >> Bind rule type: permission >> Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >> Type: host >> Permission flags: V2, SYSTEM >> >> Permission name: System: Add Hostgroups >> Granted rights: add >> Bind rule type: permission >> Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >> Type: hostgroup >> Permission flags: V2, MANAGED, SYSTEM >> >> Permission name: System: Add Hosts >> Granted rights: add >> Bind rule type: permission >> Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >> Type: host >> Permission flags: V2, MANAGED, SYSTEM >> ---------------------------- >> Number of entries returned 3 >> ---------------------------- >> >> >> Can anyone help me out as I'm unsure where this goes wrong. >> > > For 'Add Host Enrollment Password' the granted rights should be write > not add. > > add is for adding entries, not writing attributes. > > rob From rcritten at redhat.com Fri Mar 10 20:20:45 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 10 Mar 2017 15:20:45 -0500 Subject: [Freeipa-users] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute In-Reply-To: References: <950d5605-7ed1-8454-c5ae-85591899bd30@redhat.com> Message-ID: Matt . wrote: > Hi Rob, > > Thanks, but what do you mean here ? The Foreman has a script which > should be OK for it: > > https://github.com/theforeman/smart-proxy/blob/develop/sbin/foreman-prepare-realm > > Can you check this maybe ? Like I said, it's wrong. add grants the ability to add new entries, not updating existing ones. The right needs to be "write". rob > > Thanks, > > Matt > > 2017-03-10 17:21 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> I'm trying to add a host using Foreman to the FreeIPA realm but this >>> doesn't work, all things seem to be fine and some other tests from >>> people are working: >>> >>> The issue is reported here: http://projects.theforeman.org/issues/18850 >>> >>> >>> My settings are like this: >>> >>> >>> [root at ipa-01 ~]# ipa role-find >>> --------------- >>> 6 roles matched >>> --------------- >>> Role name: helpdesk >>> Description: Helpdesk >>> >>> Role name: IT Security Specialist >>> Description: IT Security Specialist >>> >>> Role name: IT Specialist >>> Description: IT Specialist >>> >>> Role name: Security Architect >>> Description: Security Architect >>> >>> Role name: Smart Proxy Host Manager >>> Description: Smart Proxy management >>> >>> Role name: User Administrator >>> Description: Responsible for creating Users and Groups >>> ---------------------------- >>> Number of entries returned 6 >>> ---------------------------- >>> [root at ipa-01 ~]# ipa role-show "Smart Proxy Host Manager" >>> Role name: Smart Proxy Host Manager >>> Description: Smart Proxy management >>> Member users: foreman-proxy, foreman-realm-proxy >>> Privileges: Smart Proxy Host Management >>> [root at ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management" >>> Privilege name: Smart Proxy Host Management >>> Description: Smart Proxy Host Management >>> Permissions: Retrieve Certificates from the CA, System: Add DNS >>> Entries, System: Read DNS Entries, System: Remove DNS Entries, System: >>> Update DNS >>> Entries, System: Manage Host Certificates, System: >>> Manage Host Enrollment Password, System: Manage Host Keytab, System: >>> Modify Hosts, >>> System: Remove Hosts, System: Manage Service Keytab, >>> System: Modify Services, Add Host Enrollment Password >>> Granting privilege to roles: Smart Proxy Host Manager >>> [root at ipa-01 ~]# >>> [root at ipa-01 ~]# ipa permission-find "Add Host" >>> --------------------- >>> 3 permissions matched >>> --------------------- >>> Permission name: Add Host Enrollment Password >>> Granted rights: add >>> Effective attributes: userpassword >>> Bind rule type: permission >>> Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>> Type: host >>> Permission flags: V2, SYSTEM >>> >>> Permission name: System: Add Hostgroups >>> Granted rights: add >>> Bind rule type: permission >>> Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>> Type: hostgroup >>> Permission flags: V2, MANAGED, SYSTEM >>> >>> Permission name: System: Add Hosts >>> Granted rights: add >>> Bind rule type: permission >>> Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>> Type: host >>> Permission flags: V2, MANAGED, SYSTEM >>> ---------------------------- >>> Number of entries returned 3 >>> ---------------------------- >>> >>> >>> Can anyone help me out as I'm unsure where this goes wrong. >>> >> >> For 'Add Host Enrollment Password' the granted rights should be write >> not add. >> >> add is for adding entries, not writing attributes. >> >> rob > From orion at cora.nwra.com Fri Mar 10 22:42:26 2017 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 10 Mar 2017 15:42:26 -0700 Subject: [Freeipa-users] Add host to hostgroup in ipa-client-add Message-ID: <8fa1c33e-3b57-bd31-0eb9-555140a1a866@cora.nwra.com> I'm using ipa-client-add with --unattended and a OTP to enroll machines at install time. I'd like to be able to add them to a particular hostgroup at the same time to avoid having to do that manually later. Does this seem like a reasonable RFE? Or is there some other way to handle this? Thanks - Orion -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From yamakasi.014 at gmail.com Fri Mar 10 22:50:49 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 10 Mar 2017 23:50:49 +0100 Subject: [Freeipa-users] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute In-Reply-To: References: <950d5605-7ed1-8454-c5ae-85591899bd30@redhat.com> Message-ID: Hi Rob, Thanks for the update, the same error happens when I add a new host, so I'm lost, the same for the Foreman devs. What can I check/test further ? Thanks, Matt 2017-03-10 21:20 GMT+01:00 Rob Crittenden : > Matt . wrote: >> Hi Rob, >> >> Thanks, but what do you mean here ? The Foreman has a script which >> should be OK for it: >> >> https://github.com/theforeman/smart-proxy/blob/develop/sbin/foreman-prepare-realm >> >> Can you check this maybe ? > > Like I said, it's wrong. > > add grants the ability to add new entries, not updating existing ones. > > The right needs to be "write". > > rob > >> >> Thanks, >> >> Matt >> >> 2017-03-10 17:21 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> I'm trying to add a host using Foreman to the FreeIPA realm but this >>>> doesn't work, all things seem to be fine and some other tests from >>>> people are working: >>>> >>>> The issue is reported here: http://projects.theforeman.org/issues/18850 >>>> >>>> >>>> My settings are like this: >>>> >>>> >>>> [root at ipa-01 ~]# ipa role-find >>>> --------------- >>>> 6 roles matched >>>> --------------- >>>> Role name: helpdesk >>>> Description: Helpdesk >>>> >>>> Role name: IT Security Specialist >>>> Description: IT Security Specialist >>>> >>>> Role name: IT Specialist >>>> Description: IT Specialist >>>> >>>> Role name: Security Architect >>>> Description: Security Architect >>>> >>>> Role name: Smart Proxy Host Manager >>>> Description: Smart Proxy management >>>> >>>> Role name: User Administrator >>>> Description: Responsible for creating Users and Groups >>>> ---------------------------- >>>> Number of entries returned 6 >>>> ---------------------------- >>>> [root at ipa-01 ~]# ipa role-show "Smart Proxy Host Manager" >>>> Role name: Smart Proxy Host Manager >>>> Description: Smart Proxy management >>>> Member users: foreman-proxy, foreman-realm-proxy >>>> Privileges: Smart Proxy Host Management >>>> [root at ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management" >>>> Privilege name: Smart Proxy Host Management >>>> Description: Smart Proxy Host Management >>>> Permissions: Retrieve Certificates from the CA, System: Add DNS >>>> Entries, System: Read DNS Entries, System: Remove DNS Entries, System: >>>> Update DNS >>>> Entries, System: Manage Host Certificates, System: >>>> Manage Host Enrollment Password, System: Manage Host Keytab, System: >>>> Modify Hosts, >>>> System: Remove Hosts, System: Manage Service Keytab, >>>> System: Modify Services, Add Host Enrollment Password >>>> Granting privilege to roles: Smart Proxy Host Manager >>>> [root at ipa-01 ~]# >>>> [root at ipa-01 ~]# ipa permission-find "Add Host" >>>> --------------------- >>>> 3 permissions matched >>>> --------------------- >>>> Permission name: Add Host Enrollment Password >>>> Granted rights: add >>>> Effective attributes: userpassword >>>> Bind rule type: permission >>>> Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>>> Type: host >>>> Permission flags: V2, SYSTEM >>>> >>>> Permission name: System: Add Hostgroups >>>> Granted rights: add >>>> Bind rule type: permission >>>> Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>>> Type: hostgroup >>>> Permission flags: V2, MANAGED, SYSTEM >>>> >>>> Permission name: System: Add Hosts >>>> Granted rights: add >>>> Bind rule type: permission >>>> Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>>> Type: host >>>> Permission flags: V2, MANAGED, SYSTEM >>>> ---------------------------- >>>> Number of entries returned 3 >>>> ---------------------------- >>>> >>>> >>>> Can anyone help me out as I'm unsure where this goes wrong. >>>> >>> >>> For 'Add Host Enrollment Password' the granted rights should be write >>> not add. >>> >>> add is for adding entries, not writing attributes. >>> >>> rob >> > From abokovoy at redhat.com Sat Mar 11 05:52:58 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 11 Mar 2017 07:52:58 +0200 Subject: [Freeipa-users] Add host to hostgroup in ipa-client-add In-Reply-To: <8fa1c33e-3b57-bd31-0eb9-555140a1a866@cora.nwra.com> References: <8fa1c33e-3b57-bd31-0eb9-555140a1a866@cora.nwra.com> Message-ID: <20170311055258.cijzge3n44oyjw7q@redhat.com> On pe, 10 maalis 2017, Orion Poplawski wrote: >I'm using ipa-client-add with --unattended and a OTP to enroll machines at >install time. I'd like to be able to add them to a particular hostgroup at >the same time to avoid having to do that manually later. Does this seem like >a reasonable RFE? Or is there some other way to handle this? Use automember rules: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/automember.html -- / Alexander Bokovoy From peljasz at yahoo.co.uk Sat Mar 11 13:11:32 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Sat, 11 Mar 2017 13:11:32 +0000 Subject: [Freeipa-users] ldap tree: etc-location & ca-cas Message-ID: hi everyone my domain seems ok but I've decided to watch it closely on more regular basis and am in a process of learning the tree. I found a few +nsuniqueid and I wonder: is there a relation (surely is, but how critical) between etc-location & ca-ca? Both, location and ca have the same +nsuniqueid=647ed0ab-b70911e6-b84df1c7-2176fa48. My question would be (if I cannot do that with IPA, which I probably cannot): do I clean manually both location & ca in one go? Or there is a sequence to it? And more importantly: what should also check in the tree in relation to these two DNs? many thank, L -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at netnerdz.se Sat Mar 11 16:34:57 2017 From: freeipa at netnerdz.se (=?UTF-8?Q?Robert_S=C3=B6derlund?=) Date: Sat, 11 Mar 2017 17:34:57 +0100 Subject: [Freeipa-users] ipa migrate-ds and cn=sysaccounts,cn=etc, Message-ID: Hi all! Does 'ipa migrate-ds' support migrating users from cn=sysaccounts,cn=etc,? I tried with the arguments '--user-container=cn=sysaccounts,cn=users,cn=accounts' and '--user-objectclass=simplesecurityobject,organizationalperson' without success. I think if would be a nice feature to be able to migrate objects that isn't located in the default path. I can always fix this with ldapsearch/ldapadd but it would be nice if this was doable with ipa migrate-ds. //Robert From abokovoy at redhat.com Sat Mar 11 20:14:18 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 11 Mar 2017 22:14:18 +0200 Subject: [Freeipa-users] ipa migrate-ds and cn=sysaccounts, cn=etc, In-Reply-To: References: Message-ID: <20170311201418.4z6jprjokmnplhib@redhat.com> On la, 11 maalis 2017, Robert S?derlund wrote: >Hi all! > >Does 'ipa migrate-ds' support migrating users from >cn=sysaccounts,cn=etc,? No. >I tried with the arguments >'--user-container=cn=sysaccounts,cn=users,cn=accounts' and >'--user-objectclass=simplesecurityobject,organizationalperson' without >success. >I think if would be a nice feature to be able to migrate objects that >isn't located in the default path. sysaccounts aren't users. migrate-ds only supports migration of a limited subset objects that IPA framework knows about: users and groups. It doesn't support many other objects IPA framework knows about. Sysaccounts aren't even something IPA framework knows by itself. >I can always fix this with ldapsearch/ldapadd but it would be nice if >this was doable with ipa migrate-ds. I agree that it would be good to extend migrate-ds scope but it is currently not on the radar for many reasons. I'd rather see it extended in a programmatic way to handle all IPA framework objects and allow to specify a mapping table for them similar to how we specify --user-container and --user-objectclass (and other options). Then when sysaccounts would be managed by the IPA framework, they would become automatically available for migration. However, I personally have no available time for that in next half a year (at least). -- / Alexander Bokovoy From freeipa at netnerdz.se Sat Mar 11 20:59:26 2017 From: freeipa at netnerdz.se (=?UTF-8?Q?Robert_S=C3=B6derlund?=) Date: Sat, 11 Mar 2017 21:59:26 +0100 Subject: [Freeipa-users] ipa migrate-ds and cn=sysaccounts, cn=etc, In-Reply-To: <20170311201418.4z6jprjokmnplhib@redhat.com> References: <20170311201418.4z6jprjokmnplhib@redhat.com> Message-ID: On 2017-03-11 21:14, Alexander Bokovoy wrote: > On la, 11 maalis 2017, Robert S??derlund wrote: >> Hi all! >> >> Does 'ipa migrate-ds' support migrating users from >> cn=sysaccounts,cn=etc,? > No. > >> I tried with the arguments >> '--user-container=cn=sysaccounts,cn=users,cn=accounts' and >> '--user-objectclass=simplesecurityobject,organizationalperson' without >> success. >> I think if would be a nice feature to be able to migrate objects that >> isn't located in the default path. > sysaccounts aren't users. migrate-ds only supports migration of a > limited subset objects that IPA framework knows about: users and > groups. > It doesn't support many other objects IPA framework knows about. > Sysaccounts aren't even something IPA framework knows by itself. > >> I can always fix this with ldapsearch/ldapadd but it would be nice if >> this was doable with ipa migrate-ds. > I agree that it would be good to extend migrate-ds scope but it is > currently not on the radar for many reasons. I'd rather see it extended > in a programmatic way to handle all IPA framework objects and allow to > specify a mapping table for them similar to how we specify > --user-container and --user-objectclass (and other options). Then when > sysaccounts would be managed by the IPA framework, they would become > automatically available for migration. > > However, I personally have no available time for that in next half a > year (at least). Hi! Thank you for the feedback, when I read your answes I realize that I misunderstood the purpose of migrate-ds. My thought was that migrate-ds should work as a ldapsearch+ldapadd (with filters and the ability to remove some attrs) but without the need to dump the data to a file. Keep up the good job, freeipa is awesome :) //Robert From barrykfl at gmail.com Sun Mar 12 16:16:23 2017 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Mon, 13 Mar 2017 00:16:23 +0800 Subject: [Freeipa-users] install freeipa amazon Linux Message-ID: Hi: anyone has exp install freeipa in amazon linx base on fredora? I tried install repo myself but it fail only say no such freeipa which repo ishould use ...I already tried many difference source still fail. it seem it has its own amaz limux repo. thks barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From igorvt77 at gmail.com Sun Mar 12 17:50:54 2017 From: igorvt77 at gmail.com (Robert Johnson) Date: Sun, 12 Mar 2017 13:50:54 -0400 Subject: [Freeipa-users] Question about ipa user accounts and the compat container In-Reply-To: <20170310061634.saw7sbp2lvm7if6h@redhat.com> References: <20170309210620.kgnxbwet4n5lhdtg@redhat.com> <20170310061634.saw7sbp2lvm7if6h@redhat.com> Message-ID: On Fri, Mar 10, 2017 at 1:16 AM, Alexander Bokovoy wrote: > On to, 09 maalis 2017, Robert Johnson wrote: > >> On Thu, Mar 9, 2017 at 4:06 PM, Alexander Bokovoy >> wrote: >> >> On to, 09 maalis 2017, Robert Johnson wrote: >>> >>> Hello, >>>> >>>> I am running into an odd issue haven't been able to find any information >>>> through searching on this issue online. >>>> >>>> Environment: We are currently have a IPA master running >>>> ipa-server-4.4.0-14.el7_3.4.x86_64 on a RHEL 7.3 server. We have a mix >>>> of >>>> RHEL 6.8, RHEL 7.x and Solaris 10 clients. We also have a one way trust >>>> to >>>> a windows domain. Compatibility mode is enabled. >>>> >>>> The issue I'm seeing is that when I delete an IPA domain user through >>>> the >>>> web gui, the user account doesn't appear to be removed completely from >>>> the >>>> system. I verified via "ipa user-find" that the user is no longer in >>>> the >>>> system. I also checked via "ldapsearch" that the user account doesn't >>>> exist in the "accounts" container. However, when I look in the "users, >>>> compat" container, that user still exists. >>>> >>>> This is causing problems with my Solaris clients since they are pointing >>>> to >>>> the compat tree so that we can login with the windows accounts on those >>>> servers. The Solaris client is still seeing the account as being valid >>>> and >>>> is asking the user for a password on login which fails because the >>>> account >>>> doesn't exist in the IPA domain anymore. >>>> >>>> Do I need to remove the account from the ldap compat container manually >>>> or >>>> is the IPA user delete command (through the gui and/or command line) >>>> suppose to take care of this ? Or is there is some sort of clean up >>>> process that I have to wait for to occur before this account gets >>>> removed >>>> from that container ? If so, what is the time frame ? >>>> >>>> Compat tree is automatically generated. It also tracks existing objects, >>> so any time the object is removed from the primary tree, it should be >>> cleared from the compat tree as well. >>> >>> If you can reliably demonstrate the problem using >>> http://www.freeipa.org/page/Demo (it has compat tree enabled), then feel >>> free to open a bug. >>> >>> -- >>> / Alexander Bokovoy >>> >>> >> So after doing some more digging using ldapsearch, I discovered some "odd" >> entries. It appears that all my IPA users appear to have duplicate >> entries >> under the compat tree. So on a hunch I deleted another IPA user and one of >> the two entries disappeared from the container. I tried to use ldapdelete >> (and ldapmodify) to remove the "ghost" entry using the DN I found from the >> search and I get a "object not found" and then it says that it matched the >> base tree. If I dump the whole compat tree out to a file, the ghost >> objects look to be exact duplicates of the original entries (minus the >> guid >> which is different). I can't seem to find a way to remove them. >> >> Any ideas ? >> > Demonstrate your problem using the FreeIPA demo instance, please. > > Compat tree is not writable, thus you cannot delete anything from it > directly. You only can delete the original entry to cause removal of a > compat entry. > > Show how it is not removed with step by step ldapsearch/ipa CLI > operations against our demo instance, please. > > -- > / Alexander Bokovoy > Ok, I believe I have been able to reproduce the problem. 1) Before I created the new user, I verified by using the ldapsearch command on the compat tree that the user I was going to create didn't exist: ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" Returns nothing ldapsearch -b "cn=accounts,dc=demo1,dc=freeipa,dc=org" -h ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" Returns nothing Note: I also tried just dumping all the user objects to a file and made sure it wasn't there. 2) Next, I login to the webui and then create the new user. userlogin: 123456 First Name: Test Last Name: User and then a password. 3) Next I verified that the account was showing up in the compat tree: ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" version: 1 dn: uid=123456,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org objectClass: posixAccount objectClass: ipaOverrideTarget objectClass: top gecos: Test User cn: Test User uidNumber: 1120000053 gidNumber: 1120000053 loginShell: /bin/sh homeDirectory: /home/123456 ipaAnchorUUID:: OlNJRDpTLTEtNS0yMS0zNjIwNjU0ODcyLTY4NzE1NzE0Mi00MDUwMjk3OTIzL TEwNTM= uid: 123456 4) I delete the same user account via the webgui (full delete). 5) I then check the compat tree again and here is the result: ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" version: 1 dn: uid=123456,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org objectClass: posixAccount objectClass: ipaOverrideTarget objectClass: top gecos: Test User cn: Test User uidNumber: 1120000053 gidNumber: 1120000053 loginShell: /bin/sh homeDirectory: /home/123456 ipaAnchorUUID:: OlNJRDpTLTEtNS0yMS0zNjIwNjU0ODcyLTY4NzE1NzE0Mi00MDUwMjk3OTIzL TEwNTM= uid: 123456 The user account is still there. Now what is really weird is that if I recreate the user 123456 through the webgui and perform the ldapsearch, I see two entries. If I delete the user, it removes one of the entries and leaves the shadow one above. I can tell because the accounts look identical except for the ipaAnchorUUID attribute. - This is a problem for our Solaris systems, as the ldap client is pointing to the compat tree so when the accounts are still active in the ipa domain (ie they are in the accounts tree) I am seeing 2 entries when using the getent passwd command. Needless to say the pam_ldap module doesn't like the two entries. Now, I tried to do it again with a different account (say 111111 or 500000) and it won't reproduce the problem. This only seems to occur on the first user I created this way in the demo site you provided. In my instance, I had 2 accounts that I created that had this shadow account left in the compat tree. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sun Mar 12 18:58:46 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 12 Mar 2017 20:58:46 +0200 Subject: [Freeipa-users] Question about ipa user accounts and the compat container In-Reply-To: References: <20170309210620.kgnxbwet4n5lhdtg@redhat.com> <20170310061634.saw7sbp2lvm7if6h@redhat.com> Message-ID: <20170312185846.77vckji3lcauoapd@redhat.com> On su, 12 maalis 2017, Robert Johnson wrote: >On Fri, Mar 10, 2017 at 1:16 AM, Alexander Bokovoy >wrote: > >> On to, 09 maalis 2017, Robert Johnson wrote: >> >>> On Thu, Mar 9, 2017 at 4:06 PM, Alexander Bokovoy >>> wrote: >>> >>> On to, 09 maalis 2017, Robert Johnson wrote: >>>> >>>> Hello, >>>>> >>>>> I am running into an odd issue haven't been able to find any information >>>>> through searching on this issue online. >>>>> >>>>> Environment: We are currently have a IPA master running >>>>> ipa-server-4.4.0-14.el7_3.4.x86_64 on a RHEL 7.3 server. We have a mix >>>>> of >>>>> RHEL 6.8, RHEL 7.x and Solaris 10 clients. We also have a one way trust >>>>> to >>>>> a windows domain. Compatibility mode is enabled. >>>>> >>>>> The issue I'm seeing is that when I delete an IPA domain user through >>>>> the >>>>> web gui, the user account doesn't appear to be removed completely from >>>>> the >>>>> system. I verified via "ipa user-find" that the user is no longer in >>>>> the >>>>> system. I also checked via "ldapsearch" that the user account doesn't >>>>> exist in the "accounts" container. However, when I look in the "users, >>>>> compat" container, that user still exists. >>>>> >>>>> This is causing problems with my Solaris clients since they are pointing >>>>> to >>>>> the compat tree so that we can login with the windows accounts on those >>>>> servers. The Solaris client is still seeing the account as being valid >>>>> and >>>>> is asking the user for a password on login which fails because the >>>>> account >>>>> doesn't exist in the IPA domain anymore. >>>>> >>>>> Do I need to remove the account from the ldap compat container manually >>>>> or >>>>> is the IPA user delete command (through the gui and/or command line) >>>>> suppose to take care of this ? Or is there is some sort of clean up >>>>> process that I have to wait for to occur before this account gets >>>>> removed >>>>> from that container ? If so, what is the time frame ? >>>>> >>>>> Compat tree is automatically generated. It also tracks existing objects, >>>> so any time the object is removed from the primary tree, it should be >>>> cleared from the compat tree as well. >>>> >>>> If you can reliably demonstrate the problem using >>>> http://www.freeipa.org/page/Demo (it has compat tree enabled), then feel >>>> free to open a bug. >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >>> So after doing some more digging using ldapsearch, I discovered some "odd" >>> entries. It appears that all my IPA users appear to have duplicate >>> entries >>> under the compat tree. So on a hunch I deleted another IPA user and one of >>> the two entries disappeared from the container. I tried to use ldapdelete >>> (and ldapmodify) to remove the "ghost" entry using the DN I found from the >>> search and I get a "object not found" and then it says that it matched the >>> base tree. If I dump the whole compat tree out to a file, the ghost >>> objects look to be exact duplicates of the original entries (minus the >>> guid >>> which is different). I can't seem to find a way to remove them. >>> >>> Any ideas ? >>> >> Demonstrate your problem using the FreeIPA demo instance, please. >> >> Compat tree is not writable, thus you cannot delete anything from it >> directly. You only can delete the original entry to cause removal of a >> compat entry. >> >> Show how it is not removed with step by step ldapsearch/ipa CLI >> operations against our demo instance, please. >> >> -- >> / Alexander Bokovoy >> > >Ok, I believe I have been able to reproduce the problem. >1) Before I created the new user, I verified by using the ldapsearch >command on the compat tree that the user I was going to create didn't exist: >ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h >ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" >Returns nothing >ldapsearch -b "cn=accounts,dc=demo1,dc=freeipa,dc=org" -h >ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" >Returns nothing >Note: I also tried just dumping all the user objects to a file and made >sure it wasn't there. > >2) Next, I login to the webui and then create the new user. >userlogin: 123456 >First Name: Test >Last Name: User >and then a password. > >3) Next I verified that the account was showing up in the compat tree: >ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h >ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" >version: 1 >dn: uid=123456,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org >objectClass: posixAccount >objectClass: ipaOverrideTarget >objectClass: top >gecos: Test User >cn: Test User >uidNumber: 1120000053 >gidNumber: 1120000053 >loginShell: /bin/sh >homeDirectory: /home/123456 >ipaAnchorUUID:: >OlNJRDpTLTEtNS0yMS0zNjIwNjU0ODcyLTY4NzE1NzE0Mi00MDUwMjk3OTIzL > TEwNTM= >uid: 123456 > >4) I delete the same user account via the webgui (full delete). > >5) I then check the compat tree again and here is the result: >ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h >ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" >version: 1 >dn: uid=123456,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org >objectClass: posixAccount >objectClass: ipaOverrideTarget >objectClass: top >gecos: Test User >cn: Test User >uidNumber: 1120000053 >gidNumber: 1120000053 >loginShell: /bin/sh >homeDirectory: /home/123456 >ipaAnchorUUID:: >OlNJRDpTLTEtNS0yMS0zNjIwNjU0ODcyLTY4NzE1NzE0Mi00MDUwMjk3OTIzL > TEwNTM= >uid: 123456 > >The user account is still there. Thanks, this is helpful. >Now what is really weird is that if I recreate the user 123456 through the >webgui and perform the ldapsearch, I see two entries. If I delete the >user, it removes one of the entries and leaves the shadow one above. I can >tell because the accounts look identical except for the ipaAnchorUUID >attribute. This is a bug then. Could you please file a ticket? >- This is a problem for our Solaris systems, as the ldap client is pointing >to the compat tree so when the accounts are still active in the ipa domain >(ie they are in the accounts tree) I am seeing 2 entries when using the >getent passwd command. Needless to say the pam_ldap module doesn't like >the two entries. No, this is a wrong setup. Either you are using compat tree and have your base DN in pam_ldap config set to cn=compat,$SUFFIX, or you are using primary tree and then set base dn to cn=accounts,$SUFFIX. You shouldn't mix them in your configuration. Compat tree is just that: a tree that returns data in a format compatible with RFC2307 to clients that do not understand RFC2307bis. A second use for the compat tree is to provide unified virtual tree for clients that do not use SSSD so that both users from IPA and from trusted Active Directory forests are accessible by such 'legacy' clients. This second use case requires that you are using RFC2307 schema in your client setup and that AD users are always fully qualified (user at ad.domain). So if you have configured your client to look at $SUFFIX, it is actually expected that the client would see both entries (original one and the one from the virtual tree) because that's how they were designed. Thus, use a proper, narrow, base DN, like cn=accounts,$SUFFIX for the primary IPA tree and cn=compat,$SUFFIX for the compat tree but never $SUFFIX. SSSD clients handle this automatically. For IPA provider, SSSD automatically sets search base to cn=accounts,$SUFFIX and uses IPA-specific LDAP extended operation to query IPA servers for information about users from Active Directory forests IPA domain trusts. -- / Alexander Bokovoy From igorvt77 at gmail.com Sun Mar 12 20:04:59 2017 From: igorvt77 at gmail.com (Robert Johnson) Date: Sun, 12 Mar 2017 16:04:59 -0400 Subject: [Freeipa-users] Question about ipa user accounts and the compat container In-Reply-To: <20170312185846.77vckji3lcauoapd@redhat.com> References: <20170309210620.kgnxbwet4n5lhdtg@redhat.com> <20170310061634.saw7sbp2lvm7if6h@redhat.com> <20170312185846.77vckji3lcauoapd@redhat.com> Message-ID: Sorry I should have given some more information. We are trying to allow the user's from the trusted windows domain to login to the Solaris client and the only way I have found to have this work is by using the cn=compat,$SUFFIX for the passwd as this will force the ldap client to to use the slapi plugin on the ipa server. This required using ldapclient manual on the solaris system instead of the default profile (which uses cn=accounts for passwd). ex: ldapclient list for default profile shows: (supports IPA users just fine) NS_LDAP_SEARCH_BASEDN= $SUFFIX NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,$SUFFIX NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,$SUFFIX ldaplist list for my manual profile shows: (supports windows users just fine) NS_LDAP_SEARCH_BASEDN= $SUFFIX NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=compat,$SUFFIX NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,$SUFFIX What we were trying to do is also allow IPA created user's to login to the Solaris client in addition to the windows user's. This is where I started to run into problems with the pam_ldap module as it was detecting the duplicate entries from the "bug" above. If you are interesting in seeing this action, you can see the duplicate entries in the compat tree on the lab system right now. On Sun, Mar 12, 2017 at 2:58 PM, Alexander Bokovoy wrote: > On su, 12 maalis 2017, Robert Johnson wrote: > >> On Fri, Mar 10, 2017 at 1:16 AM, Alexander Bokovoy >> wrote: >> >> On to, 09 maalis 2017, Robert Johnson wrote: >>> >>> On Thu, Mar 9, 2017 at 4:06 PM, Alexander Bokovoy >>>> wrote: >>>> >>>> On to, 09 maalis 2017, Robert Johnson wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>>> >>>>>> I am running into an odd issue haven't been able to find any >>>>>> information >>>>>> through searching on this issue online. >>>>>> >>>>>> Environment: We are currently have a IPA master running >>>>>> ipa-server-4.4.0-14.el7_3.4.x86_64 on a RHEL 7.3 server. We have a >>>>>> mix >>>>>> of >>>>>> RHEL 6.8, RHEL 7.x and Solaris 10 clients. We also have a one way >>>>>> trust >>>>>> to >>>>>> a windows domain. Compatibility mode is enabled. >>>>>> >>>>>> The issue I'm seeing is that when I delete an IPA domain user through >>>>>> the >>>>>> web gui, the user account doesn't appear to be removed completely from >>>>>> the >>>>>> system. I verified via "ipa user-find" that the user is no longer in >>>>>> the >>>>>> system. I also checked via "ldapsearch" that the user account doesn't >>>>>> exist in the "accounts" container. However, when I look in the >>>>>> "users, >>>>>> compat" container, that user still exists. >>>>>> >>>>>> This is causing problems with my Solaris clients since they are >>>>>> pointing >>>>>> to >>>>>> the compat tree so that we can login with the windows accounts on >>>>>> those >>>>>> servers. The Solaris client is still seeing the account as being >>>>>> valid >>>>>> and >>>>>> is asking the user for a password on login which fails because the >>>>>> account >>>>>> doesn't exist in the IPA domain anymore. >>>>>> >>>>>> Do I need to remove the account from the ldap compat container >>>>>> manually >>>>>> or >>>>>> is the IPA user delete command (through the gui and/or command line) >>>>>> suppose to take care of this ? Or is there is some sort of clean up >>>>>> process that I have to wait for to occur before this account gets >>>>>> removed >>>>>> from that container ? If so, what is the time frame ? >>>>>> >>>>>> Compat tree is automatically generated. It also tracks existing >>>>>> objects, >>>>>> >>>>> so any time the object is removed from the primary tree, it should be >>>>> cleared from the compat tree as well. >>>>> >>>>> If you can reliably demonstrate the problem using >>>>> http://www.freeipa.org/page/Demo (it has compat tree enabled), then >>>>> feel >>>>> free to open a bug. >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>>> >>>>> So after doing some more digging using ldapsearch, I discovered some >>>> "odd" >>>> entries. It appears that all my IPA users appear to have duplicate >>>> entries >>>> under the compat tree. So on a hunch I deleted another IPA user and one >>>> of >>>> the two entries disappeared from the container. I tried to use >>>> ldapdelete >>>> (and ldapmodify) to remove the "ghost" entry using the DN I found from >>>> the >>>> search and I get a "object not found" and then it says that it matched >>>> the >>>> base tree. If I dump the whole compat tree out to a file, the ghost >>>> objects look to be exact duplicates of the original entries (minus the >>>> guid >>>> which is different). I can't seem to find a way to remove them. >>>> >>>> Any ideas ? >>>> >>>> Demonstrate your problem using the FreeIPA demo instance, please. >>> >>> Compat tree is not writable, thus you cannot delete anything from it >>> directly. You only can delete the original entry to cause removal of a >>> compat entry. >>> >>> Show how it is not removed with step by step ldapsearch/ipa CLI >>> operations against our demo instance, please. >>> >>> -- >>> / Alexander Bokovoy >>> >>> >> Ok, I believe I have been able to reproduce the problem. >> 1) Before I created the new user, I verified by using the ldapsearch >> command on the compat tree that the user I was going to create didn't >> exist: >> ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h >> ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" >> Returns nothing >> ldapsearch -b "cn=accounts,dc=demo1,dc=freeipa,dc=org" -h >> ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" >> Returns nothing >> Note: I also tried just dumping all the user objects to a file and made >> sure it wasn't there. >> >> 2) Next, I login to the webui and then create the new user. >> userlogin: 123456 >> First Name: Test >> Last Name: User >> and then a password. >> >> 3) Next I verified that the account was showing up in the compat tree: >> ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h >> ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" >> version: 1 >> dn: uid=123456,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org >> objectClass: posixAccount >> objectClass: ipaOverrideTarget >> objectClass: top >> gecos: Test User >> cn: Test User >> uidNumber: 1120000053 >> gidNumber: 1120000053 >> loginShell: /bin/sh >> homeDirectory: /home/123456 >> ipaAnchorUUID:: >> OlNJRDpTLTEtNS0yMS0zNjIwNjU0ODcyLTY4NzE1NzE0Mi00MDUwMjk3OTIzL >> TEwNTM= >> uid: 123456 >> >> 4) I delete the same user account via the webgui (full delete). >> >> 5) I then check the compat tree again and here is the result: >> ldapsearch -b "cn=compat,dc=demo1,dc=freeipa,dc=org" -h >> ipa.demo1.freeipa.org -s sub "(&(objectclass=*)(uid=123456))" >> version: 1 >> dn: uid=123456,cn=users,cn=compat,dc=demo1,dc=freeipa,dc=org >> objectClass: posixAccount >> objectClass: ipaOverrideTarget >> objectClass: top >> gecos: Test User >> cn: Test User >> uidNumber: 1120000053 >> gidNumber: 1120000053 >> loginShell: /bin/sh >> homeDirectory: /home/123456 >> ipaAnchorUUID:: >> OlNJRDpTLTEtNS0yMS0zNjIwNjU0ODcyLTY4NzE1NzE0Mi00MDUwMjk3OTIzL >> TEwNTM= >> uid: 123456 >> >> The user account is still there. >> > Thanks, this is helpful. > >> Now what is really weird is that if I recreate the user 123456 through the >> webgui and perform the ldapsearch, I see two entries. If I delete the >> user, it removes one of the entries and leaves the shadow one above. I >> can >> tell because the accounts look identical except for the ipaAnchorUUID >> attribute. >> > This is a bug then. Could you please file a ticket? > > - This is a problem for our Solaris systems, as the ldap client is pointing >> to the compat tree so when the accounts are still active in the ipa domain >> (ie they are in the accounts tree) I am seeing 2 entries when using the >> getent passwd command. Needless to say the pam_ldap module doesn't like >> the two entries. >> > No, this is a wrong setup. Either you are using compat tree and have your > base DN in pam_ldap config set to cn=compat,$SUFFIX, or you are using > primary tree and then set base dn to cn=accounts,$SUFFIX. You shouldn't > mix them in your configuration. > > Compat tree is just that: a tree that returns data in a format > compatible with RFC2307 to clients that do not understand RFC2307bis. A > second use for the compat tree is to provide unified virtual tree for > clients that do not use SSSD so that both users from IPA and from > trusted Active Directory forests are accessible by such 'legacy' > clients. This second use case requires that you are using RFC2307 schema > in your client setup and that AD users are always fully qualified > (user at ad.domain). > > So if you have configured your client to look at $SUFFIX, it is actually > expected that the client would see both entries (original one and the > one from the virtual tree) because that's how they were designed. Thus, > use a proper, narrow, base DN, like cn=accounts,$SUFFIX for the primary > IPA tree and cn=compat,$SUFFIX for the compat tree but never $SUFFIX. > > SSSD clients handle this automatically. For IPA provider, SSSD > automatically sets search base to cn=accounts,$SUFFIX and uses > IPA-specific LDAP extended operation to query IPA servers for > information about users from Active Directory forests IPA domain trusts. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sun Mar 12 20:45:03 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 12 Mar 2017 22:45:03 +0200 Subject: [Freeipa-users] Question about ipa user accounts and the compat container In-Reply-To: References: <20170309210620.kgnxbwet4n5lhdtg@redhat.com> <20170310061634.saw7sbp2lvm7if6h@redhat.com> <20170312185846.77vckji3lcauoapd@redhat.com> Message-ID: <20170312204503.lk72lgrgf3idhfph@redhat.com> On su, 12 maalis 2017, Robert Johnson wrote: >Sorry I should have given some more information. We are trying to allow the >user's from the trusted windows domain to login to the Solaris client and >the only way I have found to have this work is by using the >cn=compat,$SUFFIX for the passwd as this will force the ldap client to to >use the slapi plugin on the ipa server. This required using ldapclient >manual on the solaris system instead of the default profile (which uses >cn=accounts for passwd). > >ex: >ldapclient list for default profile shows: (supports IPA users just fine) >NS_LDAP_SEARCH_BASEDN= $SUFFIX >NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,$SUFFIX >NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,$SUFFIX > >ldaplist list for my manual profile shows: (supports windows users just >fine) >NS_LDAP_SEARCH_BASEDN= $SUFFIX >NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=compat,$SUFFIX >NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,$SUFFIX > >What we were trying to do is also allow IPA created user's to login to the >Solaris client in addition to the windows user's. This is where I started >to run into problems with the pam_ldap module as it was detecting the >duplicate entries from the "bug" above. Thanks for the details. So, why don't you set NS_LDAP_SEARCH_BASEDN = cn=compat,$SUFFIX? -- / Alexander Bokovoy From igorvt77 at gmail.com Sun Mar 12 23:26:06 2017 From: igorvt77 at gmail.com (Robert Johnson) Date: Sun, 12 Mar 2017 19:26:06 -0400 Subject: [Freeipa-users] Question about ipa user accounts and the compat container In-Reply-To: <20170312204503.lk72lgrgf3idhfph@redhat.com> References: <20170309210620.kgnxbwet4n5lhdtg@redhat.com> <20170310061634.saw7sbp2lvm7if6h@redhat.com> <20170312185846.77vckji3lcauoapd@redhat.com> <20170312204503.lk72lgrgf3idhfph@redhat.com> Message-ID: On Sun, Mar 12, 2017 at 4:45 PM, Alexander Bokovoy wrote: > On su, 12 maalis 2017, Robert Johnson wrote: > >> Sorry I should have given some more information. We are trying to allow >> the >> user's from the trusted windows domain to login to the Solaris client and >> the only way I have found to have this work is by using the >> cn=compat,$SUFFIX for the passwd as this will force the ldap client to to >> use the slapi plugin on the ipa server. This required using ldapclient >> manual on the solaris system instead of the default profile (which uses >> cn=accounts for passwd). >> >> ex: >> ldapclient list for default profile shows: (supports IPA users just fine) >> NS_LDAP_SEARCH_BASEDN= $SUFFIX >> NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,$SUFFIX >> NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,$SUFFIX >> >> ldaplist list for my manual profile shows: (supports windows users just >> fine) >> NS_LDAP_SEARCH_BASEDN= $SUFFIX >> NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=compat,$SUFFIX >> NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,$SUFFIX >> >> What we were trying to do is also allow IPA created user's to login to the >> Solaris client in addition to the windows user's. This is where I started >> to run into problems with the pam_ldap module as it was detecting the >> duplicate entries from the "bug" above. >> > Thanks for the details. > > So, why don't you set NS_LDAP_SEARCH_BASEDN = cn=compat,$SUFFIX? > > > -- > / Alexander Bokovoy > I tried that and I still see the same issue. I believe the problem is that the duplicate entries are located in the cn=users,cn=compat tree. The ldap client on the Solaris system isn't seeing any of the user's in the cn=accounts tree. I think this is all related to the bug above because when I preform the ldapsearch on the compat tree, I am seeing double entries for my ipa' users. Thank you for the suggestions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Mon Mar 13 02:36:43 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 13 Mar 2017 12:36:43 +1000 Subject: [Freeipa-users] bad certificate used to sign freeipa In-Reply-To: References: Message-ID: <20170313023643.GD10261@dhcp-40-8.bne.redhat.com> On Fri, Mar 10, 2017 at 01:16:42PM +0100, Harald Dunkel wrote: > Hi folks, > > I stumbled over this problem: > > http://openbsd-archive.7691.n7.nabble.com/Certificate-Error-quot-format-error-in-certificate-s-notAfter-field-quot-td304262.html > > The details don't really matter. The important point is that > the root certificate used to sign freeipa's certificate > appears to be unacceptable on openBSD and maybe others. > > What would you suggest? Is there a guideline to migrate > freeipa to a new certificate authority? > > > Every helpful comment is highly appreciated > Harri > The issue in that thread was resolved. It was caused by invalid encoding of the notAfter field. I think OpenBSD uses LibreSSL in their base system - and I guess it adheres more strictly to RFC 5280 than other implementations. As for migrating to a new CA (or merely installing a newer certificate for the original CA, with correct encoding), you can do it via ipa-cacert-mangage(1). Cheers, Fraser From rwf at loonybin.net Mon Mar 13 02:47:02 2017 From: rwf at loonybin.net (Rob Foehl) Date: Sun, 12 Mar 2017 22:47:02 -0400 (EDT) Subject: [Freeipa-users] Options for existing CA/DNS infrastructure Message-ID: I'm looking at deploying FreeIPA in a few environments with substantial DNS and/or CA infrastructure, and have some choices to make... How much trouble will I have if FreeIPA is delegated a zone like ipa.example.com with all clients in example.com or other children? (No overlap with AD-managed zones, but in at least one case autodiscovery won't be possible due to mixed clients in the parent zone.) What's the best way to play nice with existing PKI -- generate a CA CSR at installation time and sign that? Is there any provision for automatically renewing these certs, say if the external CA were to be subsumed by a dedicated Dogtag instance? Advice and experience appreciated, before I paint myself into a corner somewhere... Thanks! -Rob From abokovoy at redhat.com Mon Mar 13 06:12:21 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 13 Mar 2017 08:12:21 +0200 Subject: [Freeipa-users] Question about ipa user accounts and the compat container In-Reply-To: References: <20170309210620.kgnxbwet4n5lhdtg@redhat.com> <20170310061634.saw7sbp2lvm7if6h@redhat.com> <20170312185846.77vckji3lcauoapd@redhat.com> <20170312204503.lk72lgrgf3idhfph@redhat.com> Message-ID: <20170313061221.7nybqtntbwctcxme@redhat.com> On su, 12 maalis 2017, Robert Johnson wrote: >On Sun, Mar 12, 2017 at 4:45 PM, Alexander Bokovoy >wrote: > >> On su, 12 maalis 2017, Robert Johnson wrote: >> >>> Sorry I should have given some more information. We are trying to allow >>> the >>> user's from the trusted windows domain to login to the Solaris client and >>> the only way I have found to have this work is by using the >>> cn=compat,$SUFFIX for the passwd as this will force the ldap client to to >>> use the slapi plugin on the ipa server. This required using ldapclient >>> manual on the solaris system instead of the default profile (which uses >>> cn=accounts for passwd). >>> >>> ex: >>> ldapclient list for default profile shows: (supports IPA users just fine) >>> NS_LDAP_SEARCH_BASEDN= $SUFFIX >>> NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,$SUFFIX >>> NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,$SUFFIX >>> >>> ldaplist list for my manual profile shows: (supports windows users just >>> fine) >>> NS_LDAP_SEARCH_BASEDN= $SUFFIX >>> NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=compat,$SUFFIX >>> NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,$SUFFIX >>> >>> What we were trying to do is also allow IPA created user's to login to the >>> Solaris client in addition to the windows user's. This is where I started >>> to run into problems with the pam_ldap module as it was detecting the >>> duplicate entries from the "bug" above. >>> >> Thanks for the details. >> >> So, why don't you set NS_LDAP_SEARCH_BASEDN = cn=compat,$SUFFIX? >> > >I tried that and I still see the same issue. I believe the problem is that >the duplicate entries are located in the cn=users,cn=compat tree. The ldap >client on the Solaris system isn't seeing any of the user's in the >cn=accounts tree. I think this is all related to the bug above because >when I preform the ldapsearch on the compat tree, I am seeing double >entries for my ipa' users. I'm lost here: if you set NS_LDAP_SEARCH_BASEDN and other bases to cn=compat,$SUFFIX only, your Solaris client sees duplicate entries in cn=compat,$SUFFIX? Sorry, it would really help if you be more detailed in your explanations. If you are setting up Solaris LDAP client to always look into cn=compat,$SUFFIX, then how cn=accounts,$SUFFIX is being searched? Can you show 389-ds access log entries that demonstrate these searches? -- / Alexander Bokovoy From mbasti at redhat.com Mon Mar 13 09:06:15 2017 From: mbasti at redhat.com (Martin Basti) Date: Mon, 13 Mar 2017 10:06:15 +0100 Subject: [Freeipa-users] ldap tree: etc-location & ca-cas In-Reply-To: References: Message-ID: On 11.03.2017 14:11, lejeczek wrote: > hi everyone > > my domain seems ok but I've decided to watch it closely on more > regular basis and am in a process of learning the tree. > I found a few +nsuniqueid and I wonder: is there a relation (surely > is, but how critical) between etc-location & ca-ca? > > Both, location and ca have the same > +nsuniqueid=647ed0ab-b70911e6-b84df1c7-2176fa48. > My question would be (if I cannot do that with IPA, which I probably > cannot): do I clean manually both location & ca in one go? > Or there is a sequence to it? > And more importantly: what should also check in the tree in relation > to these two DNs? > > many thank, > L > > Hi, you have a replication conflict https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From hnehpets at yahoo.com Mon Mar 13 14:17:42 2017 From: hnehpets at yahoo.com (Stephen) Date: Mon, 13 Mar 2017 10:17:42 -0400 Subject: [Freeipa-users] Read-only replicas? Message-ID: <14C36775-1EF2-4A0A-A41B-C419043F9862@yahoo.com> Is there read-only replica support in freeipa? The use case is a dmz. Thanks... From orion at cora.nwra.com Mon Mar 13 20:00:32 2017 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 13 Mar 2017 14:00:32 -0600 Subject: [Freeipa-users] Add host to hostgroup in ipa-client-add In-Reply-To: <20170311055258.cijzge3n44oyjw7q@redhat.com> References: <8fa1c33e-3b57-bd31-0eb9-555140a1a866@cora.nwra.com> <20170311055258.cijzge3n44oyjw7q@redhat.com> Message-ID: On 03/10/2017 10:52 PM, Alexander Bokovoy wrote: > On pe, 10 maalis 2017, Orion Poplawski wrote: >> I'm using ipa-client-add with --unattended and a OTP to enroll machines at >> install time. I'd like to be able to add them to a particular hostgroup at >> the same time to avoid having to do that manually later. Does this seem like >> a reasonable RFE? Or is there some other way to handle this? > Use automember rules: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/automember.html Interesting but I don't think this will help me. After thinking about this a bit more, since I need to add the host anyway to set the OTP, I just added setting group membership to that script as well. Thanks for the info though. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From lslebodn at redhat.com Mon Mar 13 23:15:11 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 14 Mar 2017 00:15:11 +0100 Subject: [Freeipa-users] install freeipa amazon Linux In-Reply-To: References: Message-ID: <20170313231510.GA14814@10.4.128.1> On (13/03/17 00:16), barrykfl at gmail.com wrote: >Hi: > >anyone has exp install freeipa in amazon linx base on fredora? > >I tried install repo myself but it fail only say no such freeipa > >which repo ishould use ...I already tried many difference source still fail. > >it seem it has its own amaz limux repo. > According to Amazon, they have issues with packaging Samba. I'd let them to respond themselves, given they are the only ones who can respond on why they are so insisting on not packaging Samba while providing one of key infrastructure parts of AWS via Samba AD. https://forums.aws.amazon.com/thread.jspa?threadID=164971 I would recommend either to use compat tree + nslcd or use CentOS, RHEL, other distribution which has ipa-client LS From datakid at gmail.com Tue Mar 14 02:36:43 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Tue, 14 Mar 2017 13:36:43 +1100 Subject: [Freeipa-users] SSSD bug found? FreeIPA vs SSSD In-Reply-To: <20170309093933.vulku5wq3mpctqao@hendrix> References: <20170309085200.l2mmrvpxhglxlmsp@hendrix> <20170309093235.hil646gcvjlpiirp@redhat.com> <20170309093933.vulku5wq3mpctqao@hendrix> Message-ID: I am still having problems with FreeIPA/HBAC, SSSD and logging into hosts. Could this be the reason that SSSD isn't picking up the full list of groups a user belongs to? In particular, ipa hbac test says true. "id domain\\username" or "id username at domain" returns the correct groups. But the sssd_domain.com.log- shows hbac_eval_user_element returning a list of groups that doesn't include the IPA groups in the HBAC rule? (it does return the AD group that is the external group that the IPA group would register as being HBAC true, but not the matching IPA group) cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 9 March 2017 at 20:39, Jakub Hrozek wrote: > On Thu, Mar 09, 2017 at 11:32:35AM +0200, Alexander Bokovoy wrote: > > On to, 09 maalis 2017, Jakub Hrozek wrote: > > > On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote: > > > > Hola, > > > > > > > > On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and > sssd > > > > (via COPR) 1.15.1, which has a one way trust to an AD domain. > unix.name.org > > > > -> name.org > > > > > > > > I've seen some interesting behaviour. > > > > > > > > Being part of a large organisation with a smaller nix environment > and a > > > > larger Windows environment we see all the best of odd AD management > > > > behaviour (eg spaces in usernames...). > > > > > > > > Turns out some of the groups in AD have an @ symbol in them. > > > > > > > > The behavioural difference we see is: given userA in group "name @ of > > > > group" that on the FreeIPA server: > > > > > > > > [root at vmpr-freeipa.unix.name.org ~]# id userA at name.org > > > > > > > > works as expected. > > > > > > > > But on a client > > > > > > > > [root at vmpr-linuxclient1.unix.name.org ~]# id userA at name.org > > > > > > > > returns nothing. > > > > > > Yes, it is a know issue: > > > https://pagure.io/SSSD/sssd/issue/3219 > > > > > > There were some users who reported this works better with a modified > > > re_expression: > > > re_expression = ((?P.+)@(?P[^@]+$)) > > > but I agree we should fix this by default. However, the fix must be > done > > > at both the SSSD level and the IPA extdom plugin, which also searches > > > for the @-sign in the user and group names. > > Luckily, a change for extdom plugin seem to be straightforward -- search > > for the *last* occurence of the domain separator, not the first one. We > > had a similar issue with nfs idmapd code too. > > Yes, the most tricky part would be testing, to make sure the new regular > expression doesn't break anything. I used the one I showed to unblock > some RHEL customers that were complaining and were a bit stuck, but I > didn't have enough time to run all our available tests with it, that's > why we didn't switch by default.. > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Mar 14 15:25:13 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 14 Mar 2017 16:25:13 +0100 Subject: [Freeipa-users] Issue upgrading freeipa to ipa-server-4.4.0-14.el7.centos.4.x86_64 In-Reply-To: References: Message-ID: <54436d35-ce7e-9339-5caf-aa485aa1ab3f@redhat.com> On 03/08/2017 06:06 PM, freeipa at netnerdz.se wrote: > Hi all! > > I'm trying to upgrade my ipa-server to the version in subject and > hitting some bug that seems similar to > https://bugzilla.redhat.com/show_bug.cgi?id=1404910 It is unlikely that it is this bug because the version of IPA with it was never released. BUt the error indeed looks similar. > > The yum upgrade process took a bit longer than expected so i ctrl+c This is never a good idea. > it > and executed the command ipa-server-upgrade > > The error message from ipa-server-upgrade is: > 8<--- > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run > command ipa-server-upgrade manually. > Unexpected error - see /var/log/ipaupgrade.log for details: > OSError: [Errno 2] No such file or directory: > '/etc/pki/pki-tomcat/dogtag.keytab' > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > more information > [root at o-ipa01-r ~]# > 8<--- > > > The lines that indicate an error in the /var/log/ipaupgrade.log file is: > 8<--- > 2017-03-07T23:05:38Z DEBUG stdout=Authenticating as principal > root/admin at NETNERDZ.SE with password. > > 2017-03-07T23:05:38Z DEBUG stderr=WARNING: no policy specified for > dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE; defaulting to no policy > add_principal: Principal or policy already exists while creating > "dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE". > > 2017-03-07T23:05:38Z INFO Retrieving keytab > 2017-03-07T23:05:38Z DEBUG Starting external process > 2017-03-07T23:05:38Z DEBUG args=kadmin.local -q ktadd -k > /etc/pki/pki-tomcat/dogtag.keytab > dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE -x > ipa-setup-override-restrictions > 2017-03-07T23:05:48Z DEBUG Process finished, return code=0 > 2017-03-07T23:05:48Z DEBUG stdout=Authenticating as principal > root/admin at NETNERDZ.SE with password. > > 2017-03-07T23:05:48Z DEBUG stderr=kadmin.local: Server error while > changing dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE's key > > 2017-03-07T23:05:48Z ERROR IPA server upgrade failed: Inspect > /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. > 2017-03-07T23:05:48Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in > execute > return_value = self.run() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", > line 46, in run > server.upgrade() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 1863, in upgrade > upgrade_configuration() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 1796, in upgrade_configuration > ca.setup_lightweight_ca_key_retrieval() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 1400, in setup_lightweight_ca_key_retrieval > self.__setup_lightweight_ca_key_retrieval_kerberos() > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 1431, in __setup_lightweight_ca_key_retrieval_kerberos > os.chmod(keytab, 0o600) > > 2017-03-07T23:05:48Z DEBUG The ipa-server-upgrade command failed, > exception: OSError: [Errno 2] No such file or directory: > '/etc/pki/pki-tomcat/dogtag.keytab' > 2017-03-07T23:05:48Z ERROR Unexpected error - see > /var/log/ipaupgrade.log for details: > OSError: [Errno 2] No such file or directory: > '/etc/pki/pki-tomcat/dogtag.keytab' > 2017-03-07T23:05:48Z ERROR The ipa-server-upgrade command failed. See > /var/log/ipaupgrade.log for more information > 8<--- > > > Here's the output from the ipa-server-upgrade command: > [root at o-ipa01-r ~]# ipa-server-upgrade > Upgrading IPA: > [1/8]: saving configuration > [2/8]: disabling listeners > [3/8]: enabling DS global lock > [4/8]: starting directory server > [5/8]: updating schema > > [6/8]: upgrading server > [7/8]: stopping directory server > [8/8]: restoring configuration > Done. > Update complete > Upgrading IPA services > Upgrading the configuration of the IPA services > [Verifying that root certificate is published] > [Migrate CRL publish directory] > CRL tree already moved > /etc/dirsrv/slapd-NETNERDZ-SE/certmap.conf is now managed by IPA. It > will be overwritten. A backup of the original will be made. > [Verifying that CA proxy configuration is correct] > [Verifying that KDC configuration is using ipa-kdb backend] > [Fix DS schema file syntax] > Syntax already fixed > [Removing RA cert from DS NSS database] > RA cert already removed > [Enable sidgen and extdom plugins by default] > [Updating HTTPD service IPA configuration] > [Updating mod_nss protocol versions] > Protocol versions already updated > [Updating mod_nss cipher suite] > [Fixing trust flags in /etc/httpd/alias] > Trust flags already processed > [Exporting KRA agent PEM file] > KRA is not enabled > [Removing self-signed CA] > [Removing Dogtag 9 CA] > [Checking for deprecated KDC configuration files] > [Checking for deprecated backups of Samba configuration files] > [Setting up Firefox extension] > [Add missing CA DNS records] > IPA CA DNS records already processed > [Removing deprecated DNS configuration options] > [Ensuring minimal number of connections] > [Enabling serial autoincrement in DNS] > [Updating GSSAPI configuration in DNS] > [Updating pid-file configuration in DNS] > [Checking global forwarding policy in named.conf to avoid conflicts with > automatic empty zones] > Changes to named.conf have been made, restart named > [Upgrading CA schema] > CA schema update complete (no changes) > [Verifying that CA audit signing cert has 2 year validity] > [Update certmonger certificate renewal configuration to version 5] > [Enable PKIX certificate path discovery and validation] > PKIX already enabled > [Authorizing RA Agent to modify profiles] > [Authorizing RA Agent to manage lightweight CAs] > [Ensuring Lightweight CAs container exists in Dogtag database] > [Adding default OCSP URI configuration] > [Ensuring CA is using LDAPProfileSubsystem] > [Migrating certificate profiles to LDAP] > [Ensuring presence of included profiles] > [Add default CA ACL] > Default CA ACL already added > [Set up lightweight CA key retrieval] > Creating principal > Retrieving keytab > IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run > command ipa-server-upgrade manually. > Unexpected error - see /var/log/ipaupgrade.log for details: > OSError: [Errno 2] No such file or directory: > '/etc/pki/pki-tomcat/dogtag.keytab' > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > more information > [root at o-ipa01-r ~]# > > Everything seems to be working as normal, but this error message worries > me a bit since this is my only ipa server (setting up a secondary master > have been on my todo list). > Can you help me troubleshoot this? > Or should I just setup a replica and propagate it to primary node for > all clients and then reinstall the one that have problem? Might be worth to check associated pw policies. What is the password policy associated with dogtag service ( krbprincipalname=dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SEcn=services,cn=accounts,$SUFFIX and how does it look (attribute krbPwdPolicyReference) Does it point to "cn=Default Kerberos Service Password Policy,cn=services,cn=accounts,$SUFFIX", e.g. as defined in (line 45)?: https://pagure.io/freeipa/c/6f1d927467e7907fd1991f88388d96c67c9bff61 Does this policy exist? Also look to /var/log/krb5kdc.log for any interesting messages > > Thank you in advance! > //Robert > -- Petr Vobornik From pvoborni at redhat.com Tue Mar 14 15:33:35 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 14 Mar 2017 16:33:35 +0100 Subject: [Freeipa-users] Read-only replicas? In-Reply-To: <14C36775-1EF2-4A0A-A41B-C419043F9862@yahoo.com> References: <14C36775-1EF2-4A0A-A41B-C419043F9862@yahoo.com> Message-ID: <6137a6fa-8d9b-0776-aab2-601e40348729@redhat.com> On 03/13/2017 03:17 PM, Stephen wrote: > Is there read-only replica support in freeipa? The use case is a dmz. > > Thanks... > Hello Stephen, No, FreeIPA doesn't support read only replicas yet. Could you write your use case in more details in: https://pagure.io/freeipa/issue/5569 or https://bugzilla.redhat.com/show_bug.cgi?id=1291240 It will help us prioritize and know what you actually expect from the feature. Regards, -- Petr Vobornik From freeipa at netnerdz.se Tue Mar 14 15:41:53 2017 From: freeipa at netnerdz.se (=?UTF-8?Q?Robert_S=C3=B6derlund?=) Date: Tue, 14 Mar 2017 16:41:53 +0100 Subject: [Freeipa-users] Issue upgrading freeipa to ipa-server-4.4.0-14.el7.centos.4.x86_64 In-Reply-To: <54436d35-ce7e-9339-5caf-aa485aa1ab3f@redhat.com> References: <54436d35-ce7e-9339-5caf-aa485aa1ab3f@redhat.com> Message-ID: Hi! I was a bit eager to fix this so I installed a new ipa-aerver, executed ipa migrate-ds and configured the replication afterwards. Sorry not to be able to troubleshoot this further. //Robban On 2017-03-14 16:25, Petr Vobornik wrote: > On 03/08/2017 06:06 PM, freeipa at netnerdz.se wrote: >> Hi all! >> >> I'm trying to upgrade my ipa-server to the version in subject and >> hitting some bug that seems similar to >> https://bugzilla.redhat.com/show_bug.cgi?id=1404910 > > It is unlikely that it is this bug because the version of IPA with it > was never released. BUt the error indeed looks similar. > >> >> The yum upgrade process took a bit longer than expected so i ctrl+c > > This is never a good idea. > > >> it >> and executed the command ipa-server-upgrade >> >> The error message from ipa-server-upgrade is: >> 8<--- >> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run >> command ipa-server-upgrade manually. >> Unexpected error - see /var/log/ipaupgrade.log for details: >> OSError: [Errno 2] No such file or directory: >> '/etc/pki/pki-tomcat/dogtag.keytab' >> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for >> more information >> [root at o-ipa01-r ~]# >> 8<--- >> >> >> The lines that indicate an error in the /var/log/ipaupgrade.log file >> is: >> 8<--- >> 2017-03-07T23:05:38Z DEBUG stdout=Authenticating as principal >> root/admin at NETNERDZ.SE with password. >> >> 2017-03-07T23:05:38Z DEBUG stderr=WARNING: no policy specified for >> dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE; defaulting to no >> policy >> add_principal: Principal or policy already exists while creating >> "dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE". >> >> 2017-03-07T23:05:38Z INFO Retrieving keytab >> 2017-03-07T23:05:38Z DEBUG Starting external process >> 2017-03-07T23:05:38Z DEBUG args=kadmin.local -q ktadd -k >> /etc/pki/pki-tomcat/dogtag.keytab >> dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE -x >> ipa-setup-override-restrictions >> 2017-03-07T23:05:48Z DEBUG Process finished, return code=0 >> 2017-03-07T23:05:48Z DEBUG stdout=Authenticating as principal >> root/admin at NETNERDZ.SE with password. >> >> 2017-03-07T23:05:48Z DEBUG stderr=kadmin.local: Server error while >> changing dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SE's key >> >> 2017-03-07T23:05:48Z ERROR IPA server upgrade failed: Inspect >> /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. >> 2017-03-07T23:05:48Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, >> in >> execute >> return_value = self.run() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", >> line 46, in run >> server.upgrade() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >> line 1863, in upgrade >> upgrade_configuration() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >> line 1796, in upgrade_configuration >> ca.setup_lightweight_ca_key_retrieval() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line >> 1400, in setup_lightweight_ca_key_retrieval >> self.__setup_lightweight_ca_key_retrieval_kerberos() >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line >> 1431, in __setup_lightweight_ca_key_retrieval_kerberos >> os.chmod(keytab, 0o600) >> >> 2017-03-07T23:05:48Z DEBUG The ipa-server-upgrade command failed, >> exception: OSError: [Errno 2] No such file or directory: >> '/etc/pki/pki-tomcat/dogtag.keytab' >> 2017-03-07T23:05:48Z ERROR Unexpected error - see >> /var/log/ipaupgrade.log for details: >> OSError: [Errno 2] No such file or directory: >> '/etc/pki/pki-tomcat/dogtag.keytab' >> 2017-03-07T23:05:48Z ERROR The ipa-server-upgrade command failed. See >> /var/log/ipaupgrade.log for more information >> 8<--- >> >> >> Here's the output from the ipa-server-upgrade command: >> [root at o-ipa01-r ~]# ipa-server-upgrade >> Upgrading IPA: >> [1/8]: saving configuration >> [2/8]: disabling listeners >> [3/8]: enabling DS global lock >> [4/8]: starting directory server >> [5/8]: updating schema >> >> [6/8]: upgrading server >> [7/8]: stopping directory server >> [8/8]: restoring configuration >> Done. >> Update complete >> Upgrading IPA services >> Upgrading the configuration of the IPA services >> [Verifying that root certificate is published] >> [Migrate CRL publish directory] >> CRL tree already moved >> /etc/dirsrv/slapd-NETNERDZ-SE/certmap.conf is now managed by IPA. It >> will be overwritten. A backup of the original will be made. >> [Verifying that CA proxy configuration is correct] >> [Verifying that KDC configuration is using ipa-kdb backend] >> [Fix DS schema file syntax] >> Syntax already fixed >> [Removing RA cert from DS NSS database] >> RA cert already removed >> [Enable sidgen and extdom plugins by default] >> [Updating HTTPD service IPA configuration] >> [Updating mod_nss protocol versions] >> Protocol versions already updated >> [Updating mod_nss cipher suite] >> [Fixing trust flags in /etc/httpd/alias] >> Trust flags already processed >> [Exporting KRA agent PEM file] >> KRA is not enabled >> [Removing self-signed CA] >> [Removing Dogtag 9 CA] >> [Checking for deprecated KDC configuration files] >> [Checking for deprecated backups of Samba configuration files] >> [Setting up Firefox extension] >> [Add missing CA DNS records] >> IPA CA DNS records already processed >> [Removing deprecated DNS configuration options] >> [Ensuring minimal number of connections] >> [Enabling serial autoincrement in DNS] >> [Updating GSSAPI configuration in DNS] >> [Updating pid-file configuration in DNS] >> [Checking global forwarding policy in named.conf to avoid conflicts >> with >> automatic empty zones] >> Changes to named.conf have been made, restart named >> [Upgrading CA schema] >> CA schema update complete (no changes) >> [Verifying that CA audit signing cert has 2 year validity] >> [Update certmonger certificate renewal configuration to version 5] >> [Enable PKIX certificate path discovery and validation] >> PKIX already enabled >> [Authorizing RA Agent to modify profiles] >> [Authorizing RA Agent to manage lightweight CAs] >> [Ensuring Lightweight CAs container exists in Dogtag database] >> [Adding default OCSP URI configuration] >> [Ensuring CA is using LDAPProfileSubsystem] >> [Migrating certificate profiles to LDAP] >> [Ensuring presence of included profiles] >> [Add default CA ACL] >> Default CA ACL already added >> [Set up lightweight CA key retrieval] >> Creating principal >> Retrieving keytab >> IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run >> command ipa-server-upgrade manually. >> Unexpected error - see /var/log/ipaupgrade.log for details: >> OSError: [Errno 2] No such file or directory: >> '/etc/pki/pki-tomcat/dogtag.keytab' >> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for >> more information >> [root at o-ipa01-r ~]# >> >> Everything seems to be working as normal, but this error message >> worries >> me a bit since this is my only ipa server (setting up a secondary >> master >> have been on my todo list). >> Can you help me troubleshoot this? >> Or should I just setup a replica and propagate it to primary node for >> all clients and then reinstall the one that have problem? > > Might be worth to check associated pw policies. What is the password > policy associated with dogtag service ( > krbprincipalname=dogtag/o-ipa01-r.ovirt.netnerdz.se at NETNERDZ.SEcn=services,cn=accounts,$SUFFIX > and how does it look (attribute krbPwdPolicyReference) Does it point > to "cn=Default Kerberos Service Password > Policy,cn=services,cn=accounts,$SUFFIX", e.g. as defined in (line > 45)?: > https://pagure.io/freeipa/c/6f1d927467e7907fd1991f88388d96c67c9bff61 > > Does this policy exist? > > Also look to /var/log/krb5kdc.log for any interesting messages >> >> Thank you in advance! >> //Robert >> From jan.karasek at elostech.cz Tue Mar 14 16:05:29 2017 From: jan.karasek at elostech.cz (Jan =?utf-8?Q?Kar=C3=A1sek?=) Date: Tue, 14 Mar 2017 17:05:29 +0100 (CET) Subject: [Freeipa-users] Mutli site IPA scenario - DNS issue Message-ID: <1120537761.7037.1489507529953.JavaMail.zimbra@elostech.cz> Hi, please can you point me to right direction with this issue ? Scenario: Site A, Site B, IPA in Site A is already installed with DNS, CA and i want to create replica to Site B. OS: RHEL 7.3, IPA 4.4 Site A - 192.168.0.0/24 IPA_A server interfaces: eth0: 192.168.0.10 -- access for clients in Site A eth1: 192.168.10.100 -- interface to Site B domain: sitea.mylab.test Site B - 192.168.1.0/24 IPA_B server interfaces: eth0: 192.168.1.10 -- access for clients in Site B eth1: 192.168.10.200 -- interface to Site A domain: siteb.mylab.test IPA clients can reach only servers in their own site via eth0 - no access to IPA servers in other sites. Servers can communicate with each other only via eth1. I am having trouble to find out how to set DNS records for this scenario. Just now I have IPA_A installed and i want to create replica to IPA_B server. DNS for zone sitea.mylab.test: ipa_a A 192.168.0.10 ... SRV ipa_a.sitea.mylab.test So just now in DNS I have only A record for interface facing Site A. Trouble is that server in Site B (ipa_b) is not able to communicate with server in Site A (ipa_a) via 192.168.0.10 address which it gets from DNS, servers can communicate only on eth1 (192.168.10.0/24). So when I point resolv.conf on IPA_B to IPA_A and try to run ipa-replica-install --principal admin --admin-password admin_password --setup-dns --setup-ca ... I can not access IPA_A server because it is resolving to 192.168.0.10. So is this supported scenario ? What would be solution ? I can probably fix that in /etc/hosts file, but I would like to keep it all in DNS. Thank you, Jan From ianh at brownpapertickets.com Tue Mar 14 16:47:30 2017 From: ianh at brownpapertickets.com (Ian Harding) Date: Tue, 14 Mar 2017 09:47:30 -0700 Subject: [Freeipa-users] DB locks and Clean RUV Message-ID: I just updated my FreeIPA server and now the LDAP instance crashes daily at 9:15 PM. I have a lot of these in my logs : Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.781100512 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 9): Replica is not cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389)) Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.781560066 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 9): Replicas have not been cleaned yet, retrying in 14400 seconds Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.837043110 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 16): Replica is not cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389)) Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.837354975 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 16): Replicas have not been cleaned yet, retrying in 14400 seconds Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.214216609 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 7): Replica is not cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389)) Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.214609007 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 7): Replicas have not been cleaned yet, retrying in 14400 seconds Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.286618494 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 14): Replica is not cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389)) Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.287040274 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 14): Replicas have not been cleaned yet, retrying in 14400 seconds But there are apparently not any tasks running: [root at freeipa-sea log]# ipa-replica-manage list-clean-ruv Directory Manager password: No CLEANALLRUV tasks running No abort CLEANALLRUV tasks running The crash happens after: Mar 13 21:18:13 freeipa-sea ns-slapd: [13/Mar/2017:21:18:13.702716206 -0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out of db locks getting the next entry. Reduce the batch value and restart. Mar 13 21:18:15 freeipa-sea ns-slapd: [13/Mar/2017:21:18:15.303117842 -0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out of db locks getting the next entry. Reduce the batch value and restart. Mar 13 21:18:16 freeipa-sea ns-slapd: [13/Mar/2017:21:18:16.628504719 -0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out of db locks getting the next entry. Reduce the batch value and restart. Mar 13 21:18:17 freeipa-sea ns-slapd: [13/Mar/2017:21:18:17.954354140 -0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out of db locks getting the next entry. Reduce the batch value and restart. Mar 13 21:18:19 freeipa-sea ns-slapd: [13/Mar/2017:21:18:19.284145453 -0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out of db locks getting the next entry. Reduce the batch value and restart. Is there any way to get rid of the cleanallruv tasks that the system thinks are not running? Thanks! - Ian -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com From mbasti at redhat.com Tue Mar 14 18:26:18 2017 From: mbasti at redhat.com (Martin Basti) Date: Tue, 14 Mar 2017 19:26:18 +0100 Subject: [Freeipa-users] Mutli site IPA scenario - DNS issue In-Reply-To: <1120537761.7037.1489507529953.JavaMail.zimbra@elostech.cz> References: <1120537761.7037.1489507529953.JavaMail.zimbra@elostech.cz> Message-ID: <5d98ffed-d2b1-c1e1-a405-a85f18445240@redhat.com> On 14.03.2017 17:05, Jan Kar?sek wrote: > Hi, > please can you point me to right direction with this issue ? > Scenario: > Site A, Site B, IPA in Site A is already installed with DNS, CA and i want to create replica to Site B. > OS: RHEL 7.3, IPA 4.4 > > > Site A - 192.168.0.0/24 > IPA_A server interfaces: > eth0: 192.168.0.10 -- access for clients in Site A > eth1: 192.168.10.100 -- interface to Site B > domain: sitea.mylab.test > > > Site B - 192.168.1.0/24 > IPA_B server interfaces: > eth0: 192.168.1.10 -- access for clients in Site B > eth1: 192.168.10.200 -- interface to Site A > domain: siteb.mylab.test > > > IPA clients can reach only servers in their own site via eth0 - no access to IPA servers in other sites. > Servers can communicate with each other only via eth1. > I am having trouble to find out how to set DNS records for this scenario. > > Just now I have IPA_A installed and i want to create replica to IPA_B server. > DNS for zone sitea.mylab.test: > > ipa_a A 192.168.0.10 > ... SRV ipa_a.sitea.mylab.test > > So just now in DNS I have only A record for interface facing Site A. > > Trouble is that server in Site B (ipa_b) is not able to communicate with server in Site A (ipa_a) via 192.168.0.10 address which it gets from DNS, servers can communicate only on eth1 (192.168.10.0/24). > > > So when I point resolv.conf on IPA_B to IPA_A and try to run > > ipa-replica-install --principal admin --admin-password admin_password --setup-dns --setup-ca ... > > I can not access IPA_A server because it is resolving to 192.168.0.10. > > So is this supported scenario ? What would be solution ? I can probably fix that in /etc/hosts file, but I would like to keep it all in DNS. > > Thank you, > > Jan > Hello, this is really nonstandard situation for IPA I suggest to use just one IP address with IPA to makes things less complicated, can you leave only 192.168.10.{100|200} for ipaservers and allow the host subnets to communicate with the particular IPA servers? Why do you want to prevent clients to communicate with the other IPA server? You will have no backup for clients in case that one replica failed. If you just want from clients to prefer closer replica you may want to use IPA location feature https://www.freeipa.org/page/Howto/IPA_locations and just keep clients outside of location failing. If you really need to separate subnets with different IP addresses, you need DNS views for that and IPA DNS must be configured to respect that. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Tue Mar 14 18:51:58 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 14 Mar 2017 14:51:58 -0400 Subject: [Freeipa-users] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute In-Reply-To: References: <950d5605-7ed1-8454-c5ae-85591899bd30@redhat.com> Message-ID: Matt . wrote: > Hi Rob, > > Thanks for the update, the same error happens when I add a new host, > so I'm lost, the same for the Foreman devs. > > What can I check/test further ? See what 389-ds is logging in its access log. You may need to enable ACI summary debugging. See the 389-ds FAQ for instructions on how. I find it curious that there are 2 similarly named foreman users in the role. rob > > Thanks, > > Matt > > 2017-03-10 21:20 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> Hi Rob, >>> >>> Thanks, but what do you mean here ? The Foreman has a script which >>> should be OK for it: >>> >>> https://github.com/theforeman/smart-proxy/blob/develop/sbin/foreman-prepare-realm >>> >>> Can you check this maybe ? >> >> Like I said, it's wrong. >> >> add grants the ability to add new entries, not updating existing ones. >> >> The right needs to be "write". >> >> rob >> >>> >>> Thanks, >>> >>> Matt >>> >>> 2017-03-10 17:21 GMT+01:00 Rob Crittenden : >>>> Matt . wrote: >>>>> I'm trying to add a host using Foreman to the FreeIPA realm but this >>>>> doesn't work, all things seem to be fine and some other tests from >>>>> people are working: >>>>> >>>>> The issue is reported here: http://projects.theforeman.org/issues/18850 >>>>> >>>>> >>>>> My settings are like this: >>>>> >>>>> >>>>> [root at ipa-01 ~]# ipa role-find >>>>> --------------- >>>>> 6 roles matched >>>>> --------------- >>>>> Role name: helpdesk >>>>> Description: Helpdesk >>>>> >>>>> Role name: IT Security Specialist >>>>> Description: IT Security Specialist >>>>> >>>>> Role name: IT Specialist >>>>> Description: IT Specialist >>>>> >>>>> Role name: Security Architect >>>>> Description: Security Architect >>>>> >>>>> Role name: Smart Proxy Host Manager >>>>> Description: Smart Proxy management >>>>> >>>>> Role name: User Administrator >>>>> Description: Responsible for creating Users and Groups >>>>> ---------------------------- >>>>> Number of entries returned 6 >>>>> ---------------------------- >>>>> [root at ipa-01 ~]# ipa role-show "Smart Proxy Host Manager" >>>>> Role name: Smart Proxy Host Manager >>>>> Description: Smart Proxy management >>>>> Member users: foreman-proxy, foreman-realm-proxy >>>>> Privileges: Smart Proxy Host Management >>>>> [root at ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management" >>>>> Privilege name: Smart Proxy Host Management >>>>> Description: Smart Proxy Host Management >>>>> Permissions: Retrieve Certificates from the CA, System: Add DNS >>>>> Entries, System: Read DNS Entries, System: Remove DNS Entries, System: >>>>> Update DNS >>>>> Entries, System: Manage Host Certificates, System: >>>>> Manage Host Enrollment Password, System: Manage Host Keytab, System: >>>>> Modify Hosts, >>>>> System: Remove Hosts, System: Manage Service Keytab, >>>>> System: Modify Services, Add Host Enrollment Password >>>>> Granting privilege to roles: Smart Proxy Host Manager >>>>> [root at ipa-01 ~]# >>>>> [root at ipa-01 ~]# ipa permission-find "Add Host" >>>>> --------------------- >>>>> 3 permissions matched >>>>> --------------------- >>>>> Permission name: Add Host Enrollment Password >>>>> Granted rights: add >>>>> Effective attributes: userpassword >>>>> Bind rule type: permission >>>>> Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>>>> Type: host >>>>> Permission flags: V2, SYSTEM >>>>> >>>>> Permission name: System: Add Hostgroups >>>>> Granted rights: add >>>>> Bind rule type: permission >>>>> Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>>>> Type: hostgroup >>>>> Permission flags: V2, MANAGED, SYSTEM >>>>> >>>>> Permission name: System: Add Hosts >>>>> Granted rights: add >>>>> Bind rule type: permission >>>>> Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>>>> Type: host >>>>> Permission flags: V2, MANAGED, SYSTEM >>>>> ---------------------------- >>>>> Number of entries returned 3 >>>>> ---------------------------- >>>>> >>>>> >>>>> Can anyone help me out as I'm unsure where this goes wrong. >>>>> >>>> >>>> For 'Add Host Enrollment Password' the granted rights should be write >>>> not add. >>>> >>>> add is for adding entries, not writing attributes. >>>> >>>> rob >>> >> > From tyrell at jentink.net Tue Mar 14 19:10:04 2017 From: tyrell at jentink.net (Tyrell Jentink) Date: Tue, 14 Mar 2017 12:10:04 -0700 Subject: [Freeipa-users] IPA users can't log in to SDDM In-Reply-To: References: Message-ID: I have users in an AD Domain, my FreeIPA server is set up with an interforest trust, and users can log in using SSH or virtual terminals on any system joined to the IPA domain, and I have Samba authenticating against these users on another server... Things are good... Until I try logging in to the Fedora 25 KDE Respin from the desktop manager (SDDM), in which case it goes to a black screen, with an X as a cursor, but nothing else... This is my first attempt at logging a remote user in through the GUI, and KDE/SDDM is the default configuration on Fedora KDE Respin, thus the combination in question... I haven't tried anything else. Some diagnostics I have tried: If I log in to a virtual terminal and run startx, then I get KDE, regardless of the user. If I log in to SDDM/KDE using a local user, then I get KDE. If I log in to SDDM/KDE using an IPA user, I get the black screen... But, the audit and security logs show that the user successfully authenticated. Dmesg shows the user getting authenticated successfully and user contexts changing successfully. So, I'm left assuming this is a problem with SDDM somewhere, but only with remote users... And my logs aren't giving me any hints. Any ideas? Any logs in particular that I should be looking at? -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Mar 14 19:46:28 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 14 Mar 2017 21:46:28 +0200 Subject: [Freeipa-users] IPA users can't log in to SDDM In-Reply-To: References: Message-ID: <20170314194628.6b4c4s23nurbexgr@redhat.com> On ti, 14 maalis 2017, Tyrell Jentink wrote: >I have users in an AD Domain, my FreeIPA server is set up with an >interforest trust, and users can log in using SSH or virtual terminals on >any system joined to the IPA domain, and I have Samba authenticating >against these users on another server... Things are good... > >Until I try logging in to the Fedora 25 KDE Respin from the desktop manager >(SDDM), in which case it goes to a black screen, with an X as a cursor, but >nothing else... This is my first attempt at logging a remote user in >through the GUI, and KDE/SDDM is the default configuration on Fedora KDE >Respin, thus the combination in question... I haven't tried anything else. > >Some diagnostics I have tried: > >If I log in to a virtual terminal and run startx, then I get KDE, >regardless of the user. >If I log in to SDDM/KDE using a local user, then I get KDE. >If I log in to SDDM/KDE using an IPA user, I get the black screen... > But, the audit and security logs show that the user successfully >authenticated. Dmesg shows the user getting authenticated successfully and >user contexts changing successfully. > > >So, I'm left assuming this is a problem with SDDM somewhere, but only with >remote users... And my logs aren't giving me any hints. > >Any ideas? Any logs in particular that I should be looking at? "Black screen" with SDDM is a fairly known issue -- you can look at https://bugzilla.redhat.com/show_bug.cgi?id=1350107, for example. Or https://github.com/sddm/sddm/issues/756, or many other distros. It looks like SDDM is crashing internally on many conditions. The bug in Red Hat bugzilla has at least three different cases where SDDM crashes. I'd suggest you to file a bug and attach system logs to it. You can use SSSD troubleshooting guide to create SSSD debug logs (domain, pam, nss, and selinux sections at least) but also attach logs for sddm and audit. -- / Alexander Bokovoy From yamakasi.014 at gmail.com Tue Mar 14 20:11:17 2017 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 14 Mar 2017 21:11:17 +0100 Subject: [Freeipa-users] Foreman => Insufficient 'add' privilege to the 'userPassword' attribute In-Reply-To: References: <950d5605-7ed1-8454-c5ae-85591899bd30@redhat.com> Message-ID: Hi Rob, I have this solved, I think it was an issue in the foreman-proxy. The reason why there are two users in the role was to test other usernames, as you cannot use foreman-proxy for this for an example. I need to update the Foreman ticket about it. Thanks for helping out. Cheers, Matt 2017-03-14 19:51 GMT+01:00 Rob Crittenden : > Matt . wrote: >> Hi Rob, >> >> Thanks for the update, the same error happens when I add a new host, >> so I'm lost, the same for the Foreman devs. >> >> What can I check/test further ? > > See what 389-ds is logging in its access log. > > You may need to enable ACI summary debugging. See the 389-ds FAQ for > instructions on how. > > I find it curious that there are 2 similarly named foreman users in the > role. > > rob > >> >> Thanks, >> >> Matt >> >> 2017-03-10 21:20 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> Hi Rob, >>>> >>>> Thanks, but what do you mean here ? The Foreman has a script which >>>> should be OK for it: >>>> >>>> https://github.com/theforeman/smart-proxy/blob/develop/sbin/foreman-prepare-realm >>>> >>>> Can you check this maybe ? >>> >>> Like I said, it's wrong. >>> >>> add grants the ability to add new entries, not updating existing ones. >>> >>> The right needs to be "write". >>> >>> rob >>> >>>> >>>> Thanks, >>>> >>>> Matt >>>> >>>> 2017-03-10 17:21 GMT+01:00 Rob Crittenden : >>>>> Matt . wrote: >>>>>> I'm trying to add a host using Foreman to the FreeIPA realm but this >>>>>> doesn't work, all things seem to be fine and some other tests from >>>>>> people are working: >>>>>> >>>>>> The issue is reported here: http://projects.theforeman.org/issues/18850 >>>>>> >>>>>> >>>>>> My settings are like this: >>>>>> >>>>>> >>>>>> [root at ipa-01 ~]# ipa role-find >>>>>> --------------- >>>>>> 6 roles matched >>>>>> --------------- >>>>>> Role name: helpdesk >>>>>> Description: Helpdesk >>>>>> >>>>>> Role name: IT Security Specialist >>>>>> Description: IT Security Specialist >>>>>> >>>>>> Role name: IT Specialist >>>>>> Description: IT Specialist >>>>>> >>>>>> Role name: Security Architect >>>>>> Description: Security Architect >>>>>> >>>>>> Role name: Smart Proxy Host Manager >>>>>> Description: Smart Proxy management >>>>>> >>>>>> Role name: User Administrator >>>>>> Description: Responsible for creating Users and Groups >>>>>> ---------------------------- >>>>>> Number of entries returned 6 >>>>>> ---------------------------- >>>>>> [root at ipa-01 ~]# ipa role-show "Smart Proxy Host Manager" >>>>>> Role name: Smart Proxy Host Manager >>>>>> Description: Smart Proxy management >>>>>> Member users: foreman-proxy, foreman-realm-proxy >>>>>> Privileges: Smart Proxy Host Management >>>>>> [root at ipa-01 ~]# ipa privilege-show "Smart Proxy Host Management" >>>>>> Privilege name: Smart Proxy Host Management >>>>>> Description: Smart Proxy Host Management >>>>>> Permissions: Retrieve Certificates from the CA, System: Add DNS >>>>>> Entries, System: Read DNS Entries, System: Remove DNS Entries, System: >>>>>> Update DNS >>>>>> Entries, System: Manage Host Certificates, System: >>>>>> Manage Host Enrollment Password, System: Manage Host Keytab, System: >>>>>> Modify Hosts, >>>>>> System: Remove Hosts, System: Manage Service Keytab, >>>>>> System: Modify Services, Add Host Enrollment Password >>>>>> Granting privilege to roles: Smart Proxy Host Manager >>>>>> [root at ipa-01 ~]# >>>>>> [root at ipa-01 ~]# ipa permission-find "Add Host" >>>>>> --------------------- >>>>>> 3 permissions matched >>>>>> --------------------- >>>>>> Permission name: Add Host Enrollment Password >>>>>> Granted rights: add >>>>>> Effective attributes: userpassword >>>>>> Bind rule type: permission >>>>>> Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>>>>> Type: host >>>>>> Permission flags: V2, SYSTEM >>>>>> >>>>>> Permission name: System: Add Hostgroups >>>>>> Granted rights: add >>>>>> Bind rule type: permission >>>>>> Subtree: cn=hostgroups,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>>>>> Type: hostgroup >>>>>> Permission flags: V2, MANAGED, SYSTEM >>>>>> >>>>>> Permission name: System: Add Hosts >>>>>> Granted rights: add >>>>>> Bind rule type: permission >>>>>> Subtree: cn=computers,cn=accounts,dc=office,dc=ipa,dc=domain,dc=tld >>>>>> Type: host >>>>>> Permission flags: V2, MANAGED, SYSTEM >>>>>> ---------------------------- >>>>>> Number of entries returned 3 >>>>>> ---------------------------- >>>>>> >>>>>> >>>>>> Can anyone help me out as I'm unsure where this goes wrong. >>>>>> >>>>> >>>>> For 'Add Host Enrollment Password' the granted rights should be write >>>>> not add. >>>>> >>>>> add is for adding entries, not writing attributes. >>>>> >>>>> rob >>>> >>> >> > From orion at cora.nwra.com Tue Mar 14 20:37:31 2017 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 14 Mar 2017 14:37:31 -0600 Subject: [Freeipa-users] sudo sometimes doesn't work In-Reply-To: <20170130083804.lxymmsc6s33jdl2e@hendrix> References: <01415443-eac5-86c1-4dc8-fc429c39d833@cora.nwra.com> <20170130083804.lxymmsc6s33jdl2e@hendrix> Message-ID: <1b43f64c-f8f8-a47d-5985-f84b9d98e699@cora.nwra.com> On 01/30/2017 01:38 AM, Jakub Hrozek wrote: > On Fri, Jan 27, 2017 at 02:15:16PM -0700, Orion Poplawski wrote: >> EL7.3 >> Users are in active directory via AD trust with IPA server >> >> sudo is configured via files - users in our default "nwra" group can run >> certain sudo commands, e.g.: >> >> Cmnd_Alias WAKEUP = /sbin/ether-wake * >> %nwra,%visitor,%ivm ALL=NOPASSWD: WAKEUP >> >> However, sometimes when I run sudo /sbin/ether-wake I get prompted for my >> password. Other times it works fine. I've attached some logs from failed >> attempt. > > So the sudo command is successfull in the end, it 'just' prompts for a > password? No, it fails when given the password: Sorry, user USER is not allowed to execute '/sbin/ether-wake XXX' as root on HOST. Turns out I'm an idiot. Needed to run ipa-adtrust-install on all of the IPA servers and make sure things were working on all of them. Things would break depending on which ipa server the client sssd was connected to. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From tyrell at jentink.net Tue Mar 14 21:07:53 2017 From: tyrell at jentink.net (Tyrell Jentink) Date: Tue, 14 Mar 2017 14:07:53 -0700 Subject: [Freeipa-users] IPA users can't log in to SDDM In-Reply-To: <20170314194628.6b4c4s23nurbexgr@redhat.com> References: <20170314194628.6b4c4s23nurbexgr@redhat.com> Message-ID: Oh, you are quite right... It's even identified in the project scope of the original proposal to switch from KDM: "Fix the bugs affecting log in: PAM stack integration and LDAP user lists" -- https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM I'm just going to switch back to KDM... Should solve my problem. Thank you! On Tue, Mar 14, 2017 at 12:46 PM, Alexander Bokovoy wrote: > On ti, 14 maalis 2017, Tyrell Jentink wrote: > >> I have users in an AD Domain, my FreeIPA server is set up with an >> interforest trust, and users can log in using SSH or virtual terminals on >> any system joined to the IPA domain, and I have Samba authenticating >> against these users on another server... Things are good... >> >> Until I try logging in to the Fedora 25 KDE Respin from the desktop >> manager >> (SDDM), in which case it goes to a black screen, with an X as a cursor, >> but >> nothing else... This is my first attempt at logging a remote user in >> through the GUI, and KDE/SDDM is the default configuration on Fedora KDE >> Respin, thus the combination in question... I haven't tried anything else. >> >> Some diagnostics I have tried: >> >> If I log in to a virtual terminal and run startx, then I get KDE, >> regardless of the user. >> If I log in to SDDM/KDE using a local user, then I get KDE. >> If I log in to SDDM/KDE using an IPA user, I get the black screen... >> But, the audit and security logs show that the user successfully >> authenticated. Dmesg shows the user getting authenticated successfully and >> user contexts changing successfully. >> >> >> So, I'm left assuming this is a problem with SDDM somewhere, but only with >> remote users... And my logs aren't giving me any hints. >> >> Any ideas? Any logs in particular that I should be looking at? >> > "Black screen" with SDDM is a fairly known issue -- you can look at > https://bugzilla.redhat.com/show_bug.cgi?id=1350107, for example. Or > https://github.com/sddm/sddm/issues/756, or many other distros. It looks > like SDDM is crashing internally on many conditions. The bug in Red Hat > bugzilla has at least three different cases where SDDM crashes. > > I'd suggest you to file a bug and attach system logs to it. You can use > SSSD troubleshooting guide to create SSSD debug logs (domain, pam, nss, > and selinux sections at least) but also attach logs for sddm and audit. > > -- > / Alexander Bokovoy > -- Tyrell Jentink tyrell.jentink.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.rainey.ctr at nrlssc.navy.mil Tue Mar 14 21:29:58 2017 From: michael.rainey.ctr at nrlssc.navy.mil (Michael Rainey (Contractor)) Date: Tue, 14 Mar 2017 16:29:58 -0500 Subject: [Freeipa-users] Fedora 25 IPA smart card login Message-ID: Greetings, I have been working on an issue with smart card logins on a Fedora 25 system. For a short time smart card logins have been working well, but suddenly the login process has suddenly stopped working. I have verified that all appropriate certificates are installed, checked my dconf configuration, checked my PAM files, and reviewed the logs. I have noticed a few issues, but changing them to match my SL7 systems did not resolve the problem. My observation has been with my PAM files and authconfig. I have noticed that when an update occurs, authconfig will run changing my PAM files. Has IPA been integrated with authconfig or do I still need to keep the options in authconfig largely disabled and manually modify my PAM files? System Information: ------------------------------------------------------------------------ Package: freeipa-client.x86_64 4.4.3-2.fc25 PAM: ------------------------------------- smartcard-auth-ac ------------------------------------- auth required pam_env.so auth sufficient pam_sss.so allow_missing_name auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so ------------------------------------- password-auth-ac ------------------------------------- auth required pam_env.so auth [default=1 success=ok] pam_localuser.so auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so forward_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so ------------------------------------- DCONF: org.gnome.login-screen ------------------------------------- org.gnome.login-screen fallback-logo '' org.gnome.login-screen disable-user-list false org.gnome.login-screen allowed-failures 3 org.gnome.login-screen enable-smartcard-authentication true org.gnome.login-screen banner-message-enable false org.gnome.login-screen enable-password-authentication true org.gnome.login-screen disable-restart-buttons false org.gnome.login-screen logo '/usr/share/pixmaps/fedora-gdm-logo.png' org.gnome.login-screen enable-fingerprint-authentication true org.gnome.login-screen banner-message-text '' -- *Michael Rainey* Network Representative Naval Research Latoratory, Code 7320 Building 1009, Room C156 Stennis Space Center, MS 39529 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.karasek at elostech.cz Tue Mar 14 21:42:21 2017 From: jan.karasek at elostech.cz (Jan =?utf-8?Q?Kar=C3=A1sek?=) Date: Tue, 14 Mar 2017 22:42:21 +0100 (CET) Subject: [Freeipa-users] Mutli site IPA scenario - DNS issue In-Reply-To: <5d98ffed-d2b1-c1e1-a405-a85f18445240@redhat.com> References: <1120537761.7037.1489507529953.JavaMail.zimbra@elostech.cz> <5d98ffed-d2b1-c1e1-a405-a85f18445240@redhat.com> Message-ID: <1261351384.63698.1489527741420.JavaMail.zimbra@elostech.cz> Hi, this is simply because network design and we are probably not able to change that at the moment. So IPA clients are restricted to IPA servers in its own site and only IPA servers are able to do inter site communication. The plan is to add more IPA server into each site so clients will have backup servers inside the each site. Just now I am simply trying to establish first inter site replication to prove that design is possible. Jan ----- Original Message ----- From: "Martin Basti" To: "Jan Kar?sek" , "freeipa-users" Sent: Tuesday, March 14, 2017 7:26:18 PM Subject: Re: [Freeipa-users] Mutli site IPA scenario - DNS issue On 14.03.2017 17:05, Jan Kar?sek wrote: > Hi, > please can you point me to right direction with this issue ? > Scenario: > Site A, Site B, IPA in Site A is already installed with DNS, CA and i want to create replica to Site B. > OS: RHEL 7.3, IPA 4.4 > > > Site A - 192.168.0.0/24 > IPA_A server interfaces: > eth0: 192.168.0.10 -- access for clients in Site A > eth1: 192.168.10.100 -- interface to Site B > domain: sitea.mylab.test > > > Site B - 192.168.1.0/24 > IPA_B server interfaces: > eth0: 192.168.1.10 -- access for clients in Site B > eth1: 192.168.10.200 -- interface to Site A > domain: siteb.mylab.test > > > IPA clients can reach only servers in their own site via eth0 - no access to IPA servers in other sites. > Servers can communicate with each other only via eth1. > I am having trouble to find out how to set DNS records for this scenario. > > Just now I have IPA_A installed and i want to create replica to IPA_B server. > DNS for zone sitea.mylab.test: > > ipa_a A 192.168.0.10 > ... SRV ipa_a.sitea.mylab.test > > So just now in DNS I have only A record for interface facing Site A. > > Trouble is that server in Site B (ipa_b) is not able to communicate with server in Site A (ipa_a) via 192.168.0.10 address which it gets from DNS, servers can communicate only on eth1 (192.168.10.0/24). > > > So when I point resolv.conf on IPA_B to IPA_A and try to run > > ipa-replica-install --principal admin --admin-password admin_password --setup-dns --setup-ca ... > > I can not access IPA_A server because it is resolving to 192.168.0.10. > > So is this supported scenario ? What would be solution ? I can probably fix that in /etc/hosts file, but I would like to keep it all in DNS. > > Thank you, > > Jan > Hello, this is really nonstandard situation for IPA I suggest to use just one IP address with IPA to makes things less complicated, can you leave only 192.168.10.{100|200} for ipaservers and allow the host subnets to communicate with the particular IPA servers? Why do you want to prevent clients to communicate with the other IPA server? You will have no backup for clients in case that one replica failed. If you just want from clients to prefer closer replica you may want to use IPA location feature https://www.freeipa.org/page/Howto/IPA_locations and just keep clients outside of location failing. If you really need to separate subnets with different IP addresses, you need DNS views for that and IPA DNS must be configured to respect that. Martin From william.muriithi at gmail.com Tue Mar 14 22:36:33 2017 From: william.muriithi at gmail.com (William Muriithi) Date: Tue, 14 Mar 2017 18:36:33 -0400 Subject: [Freeipa-users] LDAP based autofs map redundancy In-Reply-To: References: Message-ID: Hello, To add to previous mail, I have noticed this: I had two IPA, hydrogen and lithium. lithium died and will be resetting another soon after I find why the setup isn't redundant with one IPA. But this line seem to be a lead Working: ipa_server = _srv_, hydrogen.eng.example.com Failing: ipa_server = _srv_, lithium.eng.example.com Have read on that format and seem fine from the reading. To add on that, DNS records seem to be fine too. ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.3 <<>> SRV _ldap._ tcp.eng.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;_ldap._tcp.eng.example.com. IN SRV ;; ANSWER SECTION: _ldap._tcp.eng.example.com. 86400 IN SRV 0 100 389 hydrogen.eng.example.com. _ldap._tcp.eng.example.com. 86400 IN SRV 0 100 389 lithium.eng.example.com. ;; AUTHORITY SECTION: eng.example.com. 86400 IN NS hydrogen.eng.example.com. eng.example.com. 86400 IN NS lithium.eng.example.com. ;; ADDITIONAL SECTION: lithium.eng.example.com. 1200 IN A 192.168.20.3 hydrogen.eng.example.com. 1200 IN A 192.168.20.1 ;; Query time: 1 msec ;; SERVER: 192.168.20.1#53(192.168.20.1) ;; WHEN: Tue Mar 14 18:32:44 2017 ;; MSG SIZE rcvd: 200 What could I be missing? Regards, William On 5 March 2017 at 14:59, William Muriithi wrote: > Jakub, > > >> > >> It does look though like kerberos is not affected as all systems can > >> authenticate fine, so looks like its autofs issue alone > >> > >> This is the error I am noticing on the logs. > >> > >> Mar 2 14:18:29 platinum automount[2887]: key "brad" not found in map > source(s). > >> Mar 2 14:19:18 platinum automount[2887]: bind_ldap_simple: > >> lookup(ldap): Unable to bind to the LDAP server: (default), error > >> Can't contact LDAP server > >> Mar 2 14:19:21 platinum automount[2887]: bind_ldap_simple: > >> lookup(ldap): Unable to bind to the LDAP server: (default), error > >> Can't contact LDAP server > > > > I guess /etc/nsswitch.conf uses ldap for automount and not sssd? > > > Actually no. We are using SSSD > > Just checked to confirm and looks like below: > > services: files sss > netgroup: files sss > publickey: nisplus > automount: sss files > aliases: files nisplus > sudoers: files sss > > Regards, > William > *********************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlosla1987 at gmail.com Wed Mar 15 07:18:13 2017 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Wed, 15 Mar 2017 03:18:13 -0400 Subject: [Freeipa-users] =?utf-8?q?Windows_Clients_can=C2=B4t_access_linux?= =?utf-8?q?_services_using_kerberos?= Message-ID: Hello everyone I need some help with this I have set up an IPA 4.4.3 server and I have established a forest trust relationship with Active Directory, everything looks good, after following this guide http://www.freeipa.org/index. Php? Title = Squid_Integration_with_FreeIPA_using_Single_Sign_On & redirect = no on linux clients has worked without problems but has not been so on my windows clients, I have overlooked something? How do the windows clients ticket should be register by the proxy? Thanks for your help any inside will help me . -------------- next part -------------- An HTML attachment was scrubbed... URL: From barrykfl at gmail.com Wed Mar 15 09:23:49 2017 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 15 Mar 2017 17:23:49 +0800 Subject: [Freeipa-users] any idea this error ? relate to memory? Message-ID: 8443 port already firewall open but still fail..1G memory only in web hosting..free 600 M still 2017-03-15T01:36:47Z DEBUG The ipa-server-install command failed, exception: NetworkError: cannot connect to ' https://centralaws.ABC.com:8443/ca/rest/account/login': Could not connect to centralaws.ABC.com using any address: (PR_ADDRESS_NOT_SUPPORTED_ERROR) Network address type not supported. 2017-03-15T01:36:47Z ERROR cannot connect to ' https://aws.ABC.com:8443/ca/rest/account/login': Could not connect to centralaws.ABC.com using any address: (PR_ADDRESS_NOT_SUPPORTED_ERROR) Network address type not supported. 2017-03-15T01:36:47Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information thx -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 15 09:39:47 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 15 Mar 2017 11:39:47 +0200 Subject: [Freeipa-users] any idea this error ? relate to memory? In-Reply-To: References: Message-ID: <20170315093947.lwwml5hx2x5ezzcl@redhat.com> On ke, 15 maalis 2017, barrykfl at gmail.com wrote: >8443 port already firewall open but still fail..1G memory only in web >hosting..free 600 M still > >2017-03-15T01:36:47Z DEBUG The ipa-server-install command failed, >exception: NetworkError: cannot connect to ' >https://centralaws.ABC.com:8443/ca/rest/account/login': Could not connect >to centralaws.ABC.com using any address: (PR_ADDRESS_NOT_SUPPORTED_ERROR) >Network address type not supported. >2017-03-15T01:36:47Z ERROR cannot connect to ' >https://aws.ABC.com:8443/ca/rest/account/login': Could not connect to >centralaws.ABC.com using any address: (PR_ADDRESS_NOT_SUPPORTED_ERROR) >Network address type not supported. >2017-03-15T01:36:47Z ERROR The ipa-server-install command failed. See >/var/log/ipaserver-install.log for more information PR_ADDRESS_NOT_SUPPORTED_ERROR means your kernel does not have support for IPv6, it seems. -- / Alexander Bokovoy From taraksinha09 at gmail.com Wed Mar 15 10:20:57 2017 From: taraksinha09 at gmail.com (tarak sinha) Date: Wed, 15 Mar 2017 15:50:57 +0530 Subject: [Freeipa-users] Replication issue Message-ID: Hi Guys, I have multi-muster replication IPA server, is there any way to check the status of replication from all the nodes centrally. I have encountered replication failed issue on my consumer while checking the slapd logs file. Can anyone tell me to check the status of replication whether it is failed or success. -- *Thanks,* *TN* -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Mar 15 13:17:19 2017 From: sbose at redhat.com (Sumit Bose) Date: Wed, 15 Mar 2017 14:17:19 +0100 Subject: [Freeipa-users] Fedora 25 IPA smart card login In-Reply-To: References: Message-ID: <20170315131719.GB9903@p.Speedport_W_724V_Typ_A_05011603_00_011> On Tue, Mar 14, 2017 at 04:29:58PM -0500, Michael Rainey (Contractor) wrote: > Greetings, > > I have been working on an issue with smart card logins on a Fedora 25 > system. For a short time smart card logins have been working well, but > suddenly the login process has suddenly stopped working. I have verified > that all appropriate certificates are installed, checked my dconf > configuration, checked my PAM files, and reviewed the logs. I have noticed > a few issues, but changing them to match my SL7 systems did not resolve the > problem. At the first glance the config files are looking good. Please send /var/log/secure or the PAM related journal data and the SSSD logs files with debug_level=10. If you prefer you can send them directly to me. bye, Sumit > > My observation has been with my PAM files and authconfig. I have noticed > that when an update occurs, authconfig will run changing my PAM files. Has > IPA been integrated with authconfig or do I still need to keep the options > in authconfig largely disabled and manually modify my PAM files? > > System Information: > > ------------------------------------------------------------------------ > Package: > freeipa-client.x86_64 4.4.3-2.fc25 > > PAM: > ------------------------------------- > smartcard-auth-ac > ------------------------------------- > auth required pam_env.so > auth sufficient pam_sss.so allow_missing_name > auth required pam_deny.so > > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 1000 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > > session optional pam_keyinit.so revoke > session required pam_limits.so > -session optional pam_systemd.so > session [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session required pam_unix.so > session optional pam_sss.so > > ------------------------------------- > password-auth-ac > ------------------------------------- > auth required pam_env.so > auth [default=1 success=ok] pam_localuser.so > auth [success=done ignore=ignore default=die] pam_unix.so nullok > try_first_pass > auth requisite pam_succeed_if.so uid >= 1000 quiet_success > auth sufficient pam_sss.so forward_pass > auth required pam_deny.so > > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 1000 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > password requisite pam_pwquality.so try_first_pass local_users_only > retry=3 authtok_type= > password sufficient pam_unix.so sha512 shadow nullok try_first_pass > use_authtok > password sufficient pam_sss.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > -session optional pam_systemd.so > session [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid > session required pam_unix.so > session optional pam_sss.so > > ------------------------------------- > DCONF: org.gnome.login-screen > ------------------------------------- > org.gnome.login-screen fallback-logo '' > org.gnome.login-screen disable-user-list false > org.gnome.login-screen allowed-failures 3 > org.gnome.login-screen enable-smartcard-authentication true > org.gnome.login-screen banner-message-enable false > org.gnome.login-screen enable-password-authentication true > org.gnome.login-screen disable-restart-buttons false > org.gnome.login-screen logo '/usr/share/pixmaps/fedora-gdm-logo.png' > org.gnome.login-screen enable-fingerprint-authentication true > org.gnome.login-screen banner-message-text '' > > -- > *Michael Rainey* > Network Representative > Naval Research Latoratory, Code 7320 > Building 1009, Room C156 > Stennis Space Center, MS 39529 > > -- > 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 From rcritten at redhat.com Wed Mar 15 14:20:15 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 15 Mar 2017 10:20:15 -0400 Subject: [Freeipa-users] any idea this error ? relate to memory? In-Reply-To: <20170315093947.lwwml5hx2x5ezzcl@redhat.com> References: <20170315093947.lwwml5hx2x5ezzcl@redhat.com> Message-ID: Alexander Bokovoy wrote: > On ke, 15 maalis 2017, barrykfl at gmail.com wrote: >> 8443 port already firewall open but still fail..1G memory only in web >> hosting..free 600 M still >> >> 2017-03-15T01:36:47Z DEBUG The ipa-server-install command failed, >> exception: NetworkError: cannot connect to ' >> https://centralaws.ABC.com:8443/ca/rest/account/login': Could not connect >> to centralaws.ABC.com using any address: (PR_ADDRESS_NOT_SUPPORTED_ERROR) >> Network address type not supported. >> 2017-03-15T01:36:47Z ERROR cannot connect to ' >> https://aws.ABC.com:8443/ca/rest/account/login': Could not connect to >> centralaws.ABC.com using any address: (PR_ADDRESS_NOT_SUPPORTED_ERROR) >> Network address type not supported. >> 2017-03-15T01:36:47Z ERROR The ipa-server-install command failed. See >> /var/log/ipaserver-install.log for more information > PR_ADDRESS_NOT_SUPPORTED_ERROR means your kernel does not have support > for IPv6, it seems. > I think these are basically just standard connection issues. The NSPR error is a bit misleading, it just means it tried IPv4 and failed, then IPv6 and failed and then ran out of network types to try so it gave up. But in my experience at least 1.5GB of RAM are required for an IPA install with a CA. This is the minimum size I used when developing IPA on Fedora. rob From mbasti at redhat.com Wed Mar 15 18:29:01 2017 From: mbasti at redhat.com (Martin Basti) Date: Wed, 15 Mar 2017 19:29:01 +0100 Subject: [Freeipa-users] Announcing FreeIPA 4.5.0 Message-ID: <9d9d0c43-53a6-43ae-da5c-f490716a1560@redhat.com> Release date: 2017-03-15 The FreeIPA team would like to announce FreeIPA 4.5.0 release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora 25 and Fedora 26 will be available soon in the official COPR repository: This announcement is also available at . == Highlights in 4.5.0 == === Enhancements === ==== AD User Short Names ==== Support for AD users short names has been added. Short names can be enabled from CLI by setting `ipa config-mod --domain-resolution-order="domain.test:ad.domain1.test:ad.domain2.test"` or from WebUI under ''Configuration'' tab. No manual configuration on SSSD side is required. Please note that this feature is not supported by SSSD yet and the work is tracked with * ==== FIPS 140-2 Support ==== FreeIPA server and client can be installed on FIPS enabled systems. MD5 fingerprints have been replaced with SHA256. Variable ''fips_mode'' has been added to env that indicates whether FIPS is turned on the server. Please note that FIPS 140-2 support may not work on some platforms because all dependencies of FreeIPA must support FIPS 140-2 what we cannot guarantee. (Should work with RHEL 7.4+.) The FreeIPA code itself is FIPS 140-2 compatible. * ==== Certificate Identity Mapping ==== Support for multiple certificates on Smart cards has been added. User can choose which certificate is used to authenticate. This allows to define multiple certificates per user. The same certificate can be used by different accounts, and the mapping between a certificate and an account can be done through binary match of the whole certificate or a match on custom certificate attributes (such as Subject + Issuer). * ==== Improvements for Containerization ==== AD trust and KRA can be installed in one step in containers without need to call subsequent ipa-adtrust-install and ipa-kra-install in containers. Option ''--setup-adtrust'' has been added to ''ipa-server-install'' and ''ipa-replica-install'', and option ''--setup-kra'' has been added to ''ipa-server-install''. * * ==== Semi-automatic Integration with External DNS ==== Option "--out" has been added to command "ipa dns-update-system-records". This option allows to store IPA system DNS records in nsupdate format in specified file and can be used with nsupdate command to update records on an external DNS server. For more details see this howto * === Known Issues === * CLI doesn't work after ''ipa-restore'' * AD Trust doesn't work with enabled FIPS mode * ''cert-find'' does not find all certificates without sizelimit=0 === Bug fixes === Contains all bugfixes and enhacements of 4.4.1, 4.4.2, 4.4.3 releases ==== Installers Refactoring ==== Installers code base has been migrated into modules and many code duplication has been removed. * ==== "Normal" group has been renamed to "Non-POSIX" in WebUI ==== In the web UI, the group type label "Normal" has been changed to "Non-POSIX" to be compatible with CLI options. The semantics of group types is unchanged. * ==== Build System Refactoring ==== Several improvements of FreeIPA build system have been done. In case you are package maintainer please read the following design document. * ==== LDAP Connection Management Refactoring ==== LDAP connection management has been standardized across FreeIPA and should prevent LDAP connection issues during installation and upgrades in future. * ==== Do not fail when IPA server has shortname first in /etc/hosts ==== Kerberos client library is now instructed to not attempt to canonicalize hostnames when issuing TGS requests. This improves security by avoiding DNS lookups during canonicalization and also improves robustness of service principal lookups in more complex DNS environments (clouds, containerized applications). Due to this change in behavior, care must be taken to specify correct FQDN in host/service principals as no attempt to resolve e.g. short names will be made. * ==== Replica Connection Check Improvements ==== Improved connection check reduces possibility of failure in further installation steps. Now ports on both IPv4 and IPv6 addresses are checked (if available). * ==== Replace NSS with OpenSSL ==== Should reduce number of issues related to HTTPS connections. This change was also needed to support FIPS. * ==== Fully customisable CA name ==== The CA subject name is now fully customisable, and is no longer required to be related to the certificate subject base. The ''ipa-server-instal'' and ''ipa-ca-install'' commands learned the ''--ca-subject'' and ''--subject-base'' options for configuring these values. * == Upgrading == Upgrade instructions are available on [[Upgrade]] page. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Resolved tickets == * 6764 debian: python modules should be installed under dist-packages * 6759 replica prepare broken on KDC cert export * 6755 [certs.py] - "ipa-replica-prepare" command fails when trying to unlink non-existing "tmpcert.der" file in /var/lib/ipa/ * 6750 Web page ipa/config/ssbrowser.html refers to missing ipa/config/ca.crt file * 6739 Cannot login to replica's WebUI * 6735 The ipa-managed-entries command failed, exception: AttributeError: ldap2 * 6734 vaultconfig-show throws internal error * 6731 ipa-server-install: allow to in install KRA in one step * 6730 Harden client HTTPS connections * 6724 [test_csrgen.py] - comparison test scripts not reflected changes in "openssl_base.tmpl" * 6723 ipa systemd unit should define Wants=network instead of Requires=network * 6718 SessionMaxAge in /etc/httpd/conf.d/ipa.conf introduces regression * 6717 WebUI: change structure of Identity submenu * 6714 ipaclient.csrgen depends on ipaplatform * 6713 ipa: Insufficient permission check for ca-del, ca-disable and ca-enable commands (CVE-2017-2590) * 6712 WebUI: Arbitrary certificates on {user|host|service} details pages are not displayed in WebUI * 6707 Removal of IPAConfig broke Ipsilon's FreeIPA integration * 6701 Add SHA256 fingerprints * 6698 User with ticket gets GSS failure when calling freeipa CLI command * 6694 ipa-client-install command failed, TypeError: list found * 6690 Plugin schema cache is slow * 6686 ipa-replica-install fails promotecustodia.create_replica with cert errors (untrusted) after adding externally signed CA cert * 6685 logout does not work properly * 6682 session logout should not remove ccache * 6680 kra-agent.pem file is not auto-renewed by certmonger * 6676 unable to parse cookie header * 6675 KRA_AGENT_PEM file is missing * 6674 ipactl: noise error from pki-tomcatd start * 6673 httpd unit files deletes root ccache * 6670 PKINIT upgrade process is incomplete * 6661 Move ipa session data from keyring to ccaches * 6659 ipa-backup does not include /root/kracert.p12 * 6650 [vault] Replace nss crypto with cryptography * 6648 Make ipa-cacert-manage man page more clear * 6647 batch param compatibility is incorrect * 6646 IdM Server: list all Employees with matching Smart Card * 6643 [RFE] Add ipa-whoami command * 6640 DS certificate request during replica install fails due to bytes/string mismatch * 6639 Rewrite the code handling discovery and adding of AD trust agents in AD trust installer * 6638 AD trust installer should be able to configure samba instance also without admin credentials * 6637 Build fails on Fedora 26 * 6636 UnboundLocalError during ipa-client-install * 6634 --ignore-last-of-role is not in man page * 6633 IPA replica install log shows password in plain text * 6631 Use Python warnings for development * 6630 Merge AD trust installer to server/replica install * 6629 Migrate AD trust installer on the new-style installer framework * 6625 WSGI fails with internal server error when mode != production (locked attribute) * 6623 Stageuser is missing -{add,remove}-{cert,principal} commands * 6620 Remove ipa-upgradeconfig command * 6619 krb5 1.15 broke DAL principal free * 6608 IPA server installation should check if IPv6 stack is enabled * 6607 Deprecate SSLv2 from API config * 6606 Full backup and restore prevents KRA from installing * 6601 [RFE] WebUI: Certificate Identity Mapping * 6600 Legacy client tests doesn't have tree domain role. * 6598 [webui] Show "CA replica warning" only if there one or more replicas but only 1 CA * 6597 ipapython.version.DEFAULT_PLUGINS is not configured * 6596 Update ETAs in installers * 6588 replication race condition prevents IPA to install * 6586 Minor string fixes in dsinstance.py * 6585 [RFE] nsupdate output format in dns-update-system-records command * 6584 ipa-client-install fails to get CA cert via LDAP when non-FQDN name of IPA server is first in /etc/hosts * 6578 IPA CLI will eventually stop working when invoked in parallel * 6575 ipa-replica-install fails on requesting DS cert when master is not configured with IPv6 * 6574 description of --domain and --realm is confusing * 6573 CA-less replica installation fails due to attempted cert issuance * 6570 Duplicate PKINIT certificates being tracked after restoring IPA backup on re-installed master * 6565 FreeIPA server install fails (and existing servers probably fail to start) due to changes in 'dyndb' feature on merge to upstream BIND * 6564 IPA WebUI certificates are grayed out on overview page but not on details page * 6559 [py3] switch to PY3 causes warnings from IPA schema cache * 6558 [Py3] http session cookie doesn't work under Py3 * 6551 Upgrade Samba configuration to not include keytab prefix * 6550 Refactor PKCS #7 parsing to use pyasn1_modules * 6548 [RFE] Mention ipa-backup in warning message before uninstalling IPA server * 6547 [RFE] Certificates issued by externally signed IdM CA should contain full trust chain * 6546 Delete option shouldn't be available for hosts applied to view. * 6542 [RFE] Certificate Identity Mapping * 6541 ipa-replica-install fails to import DS cert from replica file * 6540 Migration from ipa-3.0 fails due to crashing copy-schema-to-ca.py * 6539 ipa vault operations are not possible with an older server * 6538 KRA: add checks to prevent removing the last instance of KRA in topology * 6534 topology should not include A<->B segment "both" and B->A "left right" at the same time. * 6532 replica installation incorrectly sets nsds5replicabinddngroup/nsds5replicabinddngroupcheckinterval on IPA 3.x instance * 6526 remove "request certificate with subjectaltname" permission * 6522 ipa-replica-conncheck should check for open ports on all IPs resolved from hostname * 6518 Can not install IPA server when hostname is not DNS resolvable * 6514 replica install: request_service_cert doesn't raise error when certificate isuance failed * 6513 `ipa plugins` command crashes with internal error * 6512 Improve the robustness FreeIPA's i18n module and its tests * 6510 Wrong error message during failed domainlevel 0 installations without a replica file * 6508 ipa-ca-install on promoted replica hangs on creating a temporary CA admin * 6505 Make ipapython.kerberos.Principal.__repr__ show the actual principal name * 6504 Create a test for uniqueness of CA renewal master * 6503 IPA upgrade of replica without DNS fails during restart of named-pkcs11 * 6500 ipa-server-upgrade fails with AttributeError * 6498 Build system must regenerate file when template changes. * 6497 Misleading error message in replica_conn_check() * 6496 remove references to ds_newinst.pl * 6495 DNSSEC: ipa-ods-expoter.socket creates incorrect socket and breaks DNSSEC signing * 6492 Register entry points of Custodia plugins * 6490 Add local-env subcommand to ipa script * 6489 Provide legacy client test coverage with tree root domain * 6487 ipa-replica-conncheck fails randomly (race condition) * 6486 Add NTP server list to ipaplatform * 6481 Create a test for instantiating rules with service principals * 6480 Update man page for ipa-adtrust-install by removing --no-msdcs option * 6474 Remove ipaplatform dependency from ipa modules * 6472 cert-request no longer accepts CSR with extraneous data surrounding PEM data * 6469 Use xml.etree instead of lxml in odsmgr.py * 6466 [abrt] krb5-server: ipadb_change_pwd(): kdb5_util killed by SIGSEGV * 6461 LDAP Connection Management refactoring * 6460 NSSNickname enclosed in single quotes causes ipa-server-certinstall failure * 6457 ipa dnsrecord-add fails with Keyerror stack trace * 6455 Add example of RDN order for ipa-server-install --subject * 6451 Automate managed replication topology 4.4 features * 6448 Tests: Stageuser tracker creation of user with minimal values, with uid not specified * 6446 Create test for kerberos over http * 6445 Traceback seen in error_log when trustdomain-del is run * 6439 Members of nested netgroups configured in IdM cannot be seen by getent on clients * 6435 Fix zanata.xml config to skip testing ipa.pot file * 6434 Installers: perform host enrollment also in domain level 0 replica install * 6433 Refactor installer code requesting certificates * 6420 Pretty print option of pytest makes tracker fail when used in ipa console * 6419 cert-show default output does not show validity * 6417 Skip topology disconnect/last of role checks when uninstalling single domain level 1 master * 6415 replica-install creates spurious entries in cn=certificates * 6412 Create tests for certs in idoverrides feature * 6410 Tests: Verify that cert commands show CA without --all * 6409 [RFE] extend ipa-getkeytab to support other LDAP bind methods * 6406 Use common mechanism for setting up initial replication in both domain levels * 6405 unify domain level-specific mechanisms for replica's DS/HTTP keytab generation * 6402 IPA Allows Password Reuse with History value defined when admin resets the password. * 6401 Revert expected returncode in replica_promotion test * 6400 Add file_exists method as a member of transport object * 6399 Object-Signing cert is unused; don't create it * 6398 Refactor certificate inspection code to use python-cryptography * 6397 WebUI: Services are not displayed correctly after upgrade * 6396 Cleanup AD trust information after tests * 6394 WebUI: Update Patternfly and Bootstrap to newer versions * 6393 Make httpd publish CA certificate on Domain Level 1 * 6392 Installers refactoring tracker * 6388 WebUI: Adder dialog cannot be reopened in case that it is closed using ESC and dropdown field was focuseded * 6386 Use api.env.nss_dir instead of paths.IPA_NSSDB_DIR * 6384 Web UI: Lowercase "b" in the "API browser" subtab label * 6381 ipa-cacert-manage man page should mention to run ipa-certupdate * 6375 ipa-replica-install fails when replica file created after ipa-ca-install on domain level 0 * 6372 [RFE] allow managing prioritized list of trusted domains for unqualified ID resolution * 6369 [tracker] raise 389 requires when "Total init may fail if the pushed schema is rejected" is part of update * 6365 Custodia compatibility: add iSecStore.span method * 6359 test_0003_find_OCSP will never fail * 6358 ipa migrate-ds fails when it finds a referral * 6357 ipa-server-install script option --no_hbac_allow should match other options * 6354 regression: certmap.conf file is not backedup during ipa-server-upgrade * 6352 replica promotion with OTP: add additional info to ""Insufficient privileges" error message * 6347 Tests: provide trust test coverage for tree root domains * 6344 [RFE] support URI resource records * 6343 [RFE] Allow login to WebUI using Kerberos aliases/enterprise principals * 6340 IPA client ipv6 - invalid --ip-address shows traceback * 6335 Set priority as required filed in password policy * 6334 "Normal" group type in the UI is confusing * 6331 Reason is lost when CheckedIPAddress returns ValueError in ipa-client-install * 6308 [webui] Does not handle uppercase authentication indicators. * 6305 host/service-mod with --certificate= (remove all certs) does not revoke certs * 6295 cert-request is not aware of Kerberos principal aliases * 6269 cert-find --all does not show information about revocation * 6263 ipa-server-certinstall does not update all certificate stores and doesn't set proper trust permissions * 6226 ipa-replica-install in CA-less environment does not configure DS TLS - ipa-ca-install then fails on replica * 6225 [RFE] Web UI: allow Smart Card authentication - finalization * 6202 ipa-client-install - document that --server option expects FQDN * 6178 Add options to retrieve lightweight CA certificate/chain * 6169 ipa dnsforwardzone-add w/o arguments fails * 6144 RPC code should be agnostic to display layer * 6132 Broken setup if 3rd party CA certificate conflicts with system-wide CA certificate * 6128 Tests: Base tracker contains leftover attributes from host tracker * 6126 Tests: User tracker does not enable creation of user with minimal values * 6125 Tests: unaccessible variable self.attrs for entries that are not created via standard create method in Tracker * 6124 Tests: remove --force option from tracker base class * 6123 Tests: Tracker enables silent deleting and creating entries * 6114 Traceback message seen when ipa is provided with invalid configuration file name * 6088 test_installation.py tests involving KRA installation on replicas fail in domain level 0 * 6005 Create an automated test for Certs in idoverrides feature * 5949 ipa-server-install: improve prompt on interactive installation * 5935 [py3] DNSName.ToASCII broken with python3 * 5742 [RFE] [webui] Configurable page size / User config page * 5695 [RFE] FreeIPA on FIPS enabled systems * 5640 Framework does not respect sizelimit passed via webUI in some searches * 5348 [tracker] dig + dnssec does not display signature of freshly created root zone * 4821 UI drops "Unknown Error" when the ipa record in /etc/hosts changes * 4189 [RFE] Use GSS-Proxy for the HTTP service * 3461 [RFE] Extend freeipa's sudo to support selinux transition roles * 157 Python 3.2a1 in rawhide == Detailed changelog since 4.4.4 == === Jan Barta (8) === * pylint: fix bad-mcs-method-argument * pylint: fix bad-mcs-classmethod-argument * pylint: fix bad-classmethod-argument * pylint: fix old-style-class * pylint: fix redefine-in-handler * pylint: fix pointless-statement * pylint: fix unneeded-not * pylint: fix simplifiable-if-statement warnings === Alexander Bokovoy (7) === * ipaserver/dcerpc.py: use arcfour_encrypt from samba * add whoami command * pkinit: make sure to have proper dictionary for Kerberos instance on upgrade * ipa-kdb: support KDB DAL version 6.1 * ipa-kdb: search for password policies globally * adtrust: remove FILE: prefix from 'dedicated keytab file' in smb.conf * trustdomain-del: fix the way how subdomain is searched === Abhijeet Kasurde (11) === * Minor typo fix in DNS install plugin * Update warning message for replica install * Add fix for ipa plugins command * Update man page of ipa-server-install * Remove deprecated ipa-upgradeconfig command * Update warning message for ipa server uninstall * Fix for handling CalledProcessError in authconfig * Enumerate available options in IPA installer * Provide user hint about IP address in IPA install * Add fix for no-hbac-allow option in server install * Added a fix for setting Priority as required field in Password Policy Details facet === Ben Lipton (8) === * csrgen: Support encrypted private keys * csrgen: Allow overriding the CSR generation profile * csrgen: Automate full cert request flow * tests: Add tests for CSR autogeneration * csrgen: Use data_sources option to define which fields are rendered * csrgen: Add a CSR generation profile for user certificates * csrgen: Add CSR generation profile for caIPAserviceCert * csrgen: Add code to generate scripts that generate CSRs === Christian Heimes (88) === * Add PYTHON_INSTALL_EXTRA_OPTIONS and --install-layout=deb * Make pylint and jsl optional * Ignore ipapython/.DEFAULT_PLUGINS * Run test_ipaclient test suite * Chain CSR generator file loaders * Move csrgen templates into ipaclient package * Use https to get security domain from Dogtag * Cleanup certdb * Default to pkginstall=true without duplicated definitions * pylint: ignore pypi placeholders * Python build: use --build-base everywhere * Add with_wheels global to install wheel and PyPI packaging dependencies * Add placeholders for ipaplatform, ipaserver and ipatests * Add python-wheel as build requirement * Packaging: Add placeholder packages * Vault: port key wrapping to python-cryptography * Remove NSPRError exception from platform tasks * Remove import nss from test_ldap * certdb: Don't restore_context() of new NSSDB * Finish port to PyCA cryptography * Drop in-memory copy of schema zip file * Speed up client schema cache * C compilation fixes and hardening * lite-server: validate LDAP connection and cache schema * Add --without-ipatests option * Add missing include of stdint.h for uint8_t * Client-only builds with --disable-server * New lite-server implementation * Explain more performance tricks in doc string * Fix test, nested lists are no longer converted to nested tuples * Pretty print JSON in debug mode (debug level >= 2) * Convert list to tuples * Faster JSON encoder/decoder * Backup /root/kracert.p12 * Ditch version_info and use version number from ipapython.version * test_StrEnum: use int as bad type * Stable _is_null check * cryptography has deprecated serial in favor of serial_number * Enable additional warnings (BytesWarning, DeprecationWarning) * Print test env information * Clean / ignore make check artefact * ipapython: Add dependencies on version.py * pytest: set rules to find test files and functions * Fix used before assignment bug in host_port_open() * Use pytest conftest.py and drop pytest.ini * Catch ValueError raised by pytest.config.getoption() * Silence pylint import errors of ipaserver in ipalib and ipaclient * Relax check for .git to support freeipa in submodules * Ignore backup~ files like config.h.in~ * Fetch correct exception in IPA_CONFDIR test * Use env var IPA_CONFDIR to get confdir * Set explicit confdir option for global contexts * Remove import of ipaplatform.paths from test_ipalib * Remove BIN_FALSE and BIN_TRUE * Add pylint guard to import of ipaplatform in ipapython.certdb * Require python-gssapi >= 1.2.0, take 2 * Backwards compatibility with setuptools 0.9.8 * Require python-cryptography >= 1.3.1 * Wheel bundles fixes * Require python-gssapi >= 1.2.0 * Adjustments for setup requirements * wrap long line * Silence import warnings for Samba bindings * Fix Python 3 bugs discovered by pylint * Python3 pylint fixes * Add main guards to a couple of Python scripts * Break ipaplatform / ipalib import cycle of hell * Replace LooseVersion * Don't ship install subpackages with wheels * Minor fixes for IPAVersion class * Pylint: whitelist packages with extension modules * Add 'ipa localenv' subcommand * ipapython and ipatest no longer require lxml * Register entry points of Custodia plugins * Use xml.etree in ipa-client-automount script * Port ipapython.dnssec.odsmgr to xml.etree * Add install requirements to Python packages * Make api.env.nss_dir relative to api.env.confdir * Don't modify redhat_system_units * Use correct classifiers to make setup.py files PyPI compatible * Use api.env.nss_dir instead of paths.IPA_NSSDB_DIR * Add __name__ == __main__ guards to setup.pys * Remove ipapython/ipa.conf * Port all setup.py to setuptools * Replace ipaplatform's symlinks with a meta importer * Move ipa.1 man file * Add iSecStore.span * Use RSA-OAEP instead of RSA PKCS#1 v1.5 === David Kupka (20) === * rpcserver: x509_login: Handle unsuccessful certificate login gracefully * Bump required version of gssproxy to 0.7.0 * tests: Add tests for kerberos principal aliases in stageuser * tests: kerberos_principal_aliases: Deduplicate tests * tests: Stageuser-{add,remove}-cert * tests: add-remove-cert: Use harcoded certificates instead of requesting them * ipalib.x509: Handle missing SAN gracefully * stageuser: Add stageuser-{add,remove}-principal * stageuser: Add stageuser-{add,remove}-cert * build: Add missing dependency on libxmlrpc{,_util} * ipaclient: schema cache: Handle malformed server info data gracefully * schema_cache: Make handling of string compatible with python3 * installer: Stop adding distro-specific NTP servers into ntp.conf * tests: Expect krbpwdpolicyreference in result of {host,service}-{find,show} --all * password policy: Add explicit default password policy for hosts and services * ipaclient.plugins: Use api_version from internally called commands * tests: Mark 389-ds acceptance tests * tests: Mark Dogtag acceptance tests * UnsafeIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling * schema cache: Store and check info for pre-schema servers === Florence Blanc-Renaud (20) === * Installation must publish CA cert in /usr/share/ipa/html/ca.crt * IdM Server: list all Employees with matching Smart Card * ipa systemd unit should define Wants=network instead of Requires=network * Support for Certificate Identity Mapping * Define template version in certmap.conf * Fix ipa.service unit re. gssproxy * Do not configure PKI ajp redirection to use "::1" * ipa-kra-install must create directory if it does not exist * ipa-restore must stop tracking PKINIT cert in the preparation phase * Increase the timeout waiting for certificate issuance in installer * Check the result of cert request in replica installer * Fix ipa-replica-install when upgrade from ca-less to ca-full * Fix ipa migrate-ds when it finds a search reference * Fix renewal lock issues on installation * Refactor installer code requesting certificates * Use autobind instead of host keytab authentication in dogtag-ipa-ca-renew-agent * Fix ipa-cacert-manage man page * Add cert checks in ipa-server-certinstall * Fix regression introduced in ipa-certupdate * Fix ipa-certupdate for CA-less installation === Fraser Tweedale (52) === * rabase.get_certificate: make serial number arg mandatory * Extract method to map principal to princpal type * Remove redundant principal_type argument * dogtag: remove redundant property definition * ca: correctly authorise ca-del, ca-enable and ca-disable * replica install: relax domain level check for promotion * Fix reference before assignment * private_ccache: yield ccache name * Add sanity checks for use of --ca-subject and --subject-base * Indicate that ca subject / subject base uses LDAP RDN order * Allow full customisability of IPA CA subject DN * Reuse self.api when executing ca_enabled_check * dsinstance: extract function for writing certmap.conf * ipa-ca-install: add missing --subject-base option * Extract function for computing default subject base * installer: rename --subject to --subject-base * installutils: remove hardcoded subject DN assumption * Refactor and relocate set_subject_base_in_config * dsinstance: minor string fixes * Set up DS TLS on replica in CA-less topology * Remove "Request Certificate with SubjectAltName" permission * Fix DL1 replica installation in CA-less topology * certprofile-mod: correctly authorise config update * Fix regression in test suite * Add options to write lightweight CA cert or chain to file * certdb: accumulate extracted certs as list of PEMs * Add function for extracting PEM certs from PKCS #7 * cert-request: match names against principal aliases * Remove references to ds_newinst.pl * cert-request: accept CSRs with extraneous data * Ensure correct IPA CA nickname in DS and HTTP NSSDBs * Remove __main__ code from ipalib.x509 and ipalib.pkcs10 * x509: use python-cryptography to process certs * x509: use pyasn1-modules X.509 specs * x509: avoid use of nss.data_to_hex * pkcs10: remove pyasn1 PKCS #10 spec * pkcs10: use python-cryptography for CSR processing * dn: support conversion from python-cryptography Name * cert-show: show validity in default output * Do not create Object Signing certificate * Add commentary about CA deletion to plugin doc * spec: require Dogtag >= 10.3.5-6 * sudorule: add SELinux transition examples to plugin doc * Fix cert revocation when removing all certs via host/service-mod * cert-request: raise error when request fails * Make host/service cert revocation aware of lightweight CAs * cert-request: raise CertificateOperationError if CA disabled * Use Dogtag REST API for certificate requests * Add HTTPRequestError class * Allow Dogtag RestClient to perform requests without logging in * Add ca-disable and ca-enable commands * Track lightweight CAs on replica installation === Ganna Kaihorodova (7) === * Tests: Basic coverage with tree root domain * User Tracker: Test to create user with minimal values * User Tracker: creation of user with minimal values * Stage User: Test to create stage user with minimal values * Tests: Stage User Tracker implementation * Tests: Add tree root domain role in legacy client tests * Unaccessible variable self.attrs in Tracker === Jan Cholasta (106) === * spec file: always provide python package aliases * spec file: support client-only build * spec file: support build without ipatests * slapi plugins: fix CFLAGS * spec file: add unconditional python-setuptools BuildRequires * httpinstance: disable system trust module in /etc/httpd/alias * csrgen: hide cert-get-requestdata in CLI * cert: include certificate chain in cert command output * cert: add output file option to cert-request * Travis CI: run tests in development mode * backend plugins: fix crashes in development mode * vault: cache the transport certificate on client * rpc: fix crash in verbose mode * install: re-introduce option groups * install CLI: remove magic option groups * client install: split off SSSD options into a separate class * server install: remove duplicate knob definitions * install: add missing space in realm_name description * server install: remove duplicate -w option * certmap: load certificate from file in certmap-match CLI * pylint_plugins: add forbidden import checker * ipapython: fix DEFAULT_PLUGINS in version.py * config: re-add `init_config` and `config` * dns: fix `dnsrecord_add` interactive mode * server install: do not attempt to issue PKINIT cert in CA-less * compat: fix `Any` params in `batch` and `dnsrecord` * scripts, tests: explicitly set confdir in the rest of server code * server upgrade: uninstall ipa_memcached properly * server upgrade: always upgrade KRA agent PEM file * server upgrade: fix upgrade from pre-4.0 * server upgrade: fix upgrade in CA-less * client install: create /etc/ipa/nssdb with correct mode * ipaldap: preserve order of values in LDAPEntry._sync() * replica install: do not log host OTP * tests: add test for PEM certificate files with leading text * ipa-ca-install: do not fail without --subject-base and --ca-subject * cert: fix search limit handling in cert-find * dogtag: search past the first 100 certificates * ipaldap: properly escape raw binary values in LDAP filters * client install: correctly report all failures * cainstance: do not configure renewal guard * dogtaginstance: track server certificate with our renew agent * renew agent: handle non-replicated certificates * ca: fix ca-find with --pkey-only * spec file: revert to the previous Release tag * x509: use PyASN1 to parse PKCS#7 * server install: fix KRA agent PEM file not being created * spec file: do not define with_lint inside a comment * certdb: fix PKCS#12 import with empty password * server install: fix external CA install * replica install: track the RA agent certificate again * ipaclient: remove hard dependency on ipaplatform * ipaclient: move install modules to the install subpackage * ipalib: remove hard dependency on ipapython * constants: remove CACERT * ipalib: move certstore to the install subpackage * ipapython: remove hard dependency on ipaplatform * ipautil: move file encryption functions to installutils * ipautil: move kinit functions to ipalib.install * ipautil: move is_fips_enabled() to ipaplatform.tasks * ipautil: remove the timeout argument of run() * ipautil: remove get_domain_name() * ipautil: remove SHARE_DIR and PLUGIN_SHARE_DIR * certdb: use a temporary file to pass password to pk12util * certdb: move IPA NSS DB install functions to ipaclient.install * ipapython: move certmonger and sysrestore to ipalib.install * ipapython: move dnssec, p11helper and secrets to ipaserver * custodiainstance: automatic restart on config file update * paths: remove DEV_NULL * install: migrate client install to the new class hierarchy * install: allow specifying verbosity and console log format in CLI * install: migrate server installers to the new class hierarchy * install: introduce installer class hierarchy * install: fix subclassing of knob groups * install: make knob base declaration explicit * install: declare knob CLI names using the argparse convention * install: use standard Python classes to declare knob types * install: introduce updated knob constructor * install: simplify CLI option parsing * install: improve CLI positional argument handling * install: use ldaps for pkispawn in ipa-ca-install * replica install: fix DS restart failure during replica promotion * replica install: merge KRA agent cert export into KRA install * replica install: merge RA cert import into CA install * server install: do not restart httpd during CA install * install: merge all KRA install code paths into one * install: merge all CA install code paths into one * replica install: use one remote KRA host name everywhere * replica install: use one remote CA host name everywhere * spec file: bump minimal required version of 389-ds-base * pwpolicy: do not run klist on import * client: remove unused libcurl build dependency * makeapi, makeaci: do not fail on missing imports * ipaserver: remove ipalib import from setup.py * pylint: enable the import-error check * spec file: do not include BuildRequires for lint by default * spec file: clean up BuildRequires * cert: add revocation reason back to cert-find output * test_plugable: update the rest of test_init * dns: re-introduce --raw in dnsrecord-del * client: remove hard dependency on pam_krb5 * cert: fix cert-find --certificate when the cert is not in LDAP * dns: fix crash in interactive mode against old servers * dns: prompt for missing record parts in CLI * dns: normalize record type read interactively in dnsrecord_add * cli: use full name when executing a command === Lenka Doudova (23) === * Document make_delete_command method in UserTracker * Tests: Providing trust tests with tree root domain * Tests: Verify that validity info is present in cert-show and cert-find command * Add file_exists method as a member of transport object * Tests: Provide AD cleanup for legacy client tests * Tests: Provide AD cleanup for trust tests * Tests: Fix integration sudo test * Tests: Verify that cert commands show CA without --all * Tests: Certificate revocation * Tests: Remove invalid certplugin tests * Tests: Fix failing test_ipalib/test_parameters * Tests: Remove silent deleting and creating entries by tracker * Tests: Remove usage of krb5 ccache from test_ipaserver/test_ldap * Tests: Fix host attributes in ipa-join host test * Tests: Update host test with ipa-join * Tests: Add krb5kdc.service restart to integration trust tests * Tests: Remove unnecessary attributes from base tracker * Tests: Remove --force options from tracker base class * Tests: Remove SSSD restart from integration tests * Tests: Fix integration sudo tests setup and checks * Tests: Fix failing ldap.backend test * Tests: Add cleanup to integration trust tests * Tests: Fix regex errors in integration trust tests === Ludwig Krispenz (1) === * Check for conflict entries before raising domain level === Lukas Slebodnik (6) === * CONFIGURE: Improve detection of xmlrpc_c flags * CONFIGURE: Properly detect libpopt on el7 * ipa_pwd: remove unnecessary dependency on dirsrv plugins * SPEC: Fix build in mock * CONFIGURE: Update help message for jslint * CONFIGURE: Fix detection of pylint === Martin Babinsky (113) === * Try out anonymous PKINIT after it is configured * check for replica's KDC entry on master before requesting PKINIT cert * check that the master requesting PKINIT cert has KDC enabled * Make wait_for_entry raise exceptions * Move PKINIT configuration to a later stage of server/replica install * Request PKINIT cert directly from Dogtag API on first master * Make PKINIT certificate request logic consistent with other installers * idviews: correctly handle modification of non-existent view * Re-use trust domain retrieval code in certmap validators * idview: add domain_resolution_order attribute * ipaconfig: add the ability to manipulate domain resolution order * Short name resolution: introduce the required schema * ipa-managed-entries: only permit running the command on IPA master * ipa-managed-entries: use server-mode API * Allow login to WebUI using Kerberos aliases/enterprise principals * Provide basic integration tests for built-in AD trust installer * Update server/replica installer man pages * Fix erroneous short name options in ipa-adtrust-install man page * Merge AD trust configurator into replica installer * Merge AD trust configurator into server installer * expose AD trust related knobs in composite installers * Add AD trust installer interface for composite installer * check for installed dependencies when *not* in standalone mode * print the installation info only in standalone mode * adtrust.py: Use logging to emit error messages * Refactor the code searching and presenting missing trust agents * only check for netbios name when LDAP backend is connected * Refactor the code checking for missing SIDs * use the methods of the parent class to retrieve CIFS kerberos keys * httpinstance: re-use parent's methods to retrieve anonymous keytab * Make request_service_keytab into a public method * allow for more flexibility when requesting service keytab * Move AD trust installation code to a separate module * Replace exit() calls with exceptions * Remove unused variables in exception handling * ipa-adtrust-install: format the code for PEP-8 compliance * Travis CI: Upload the logs from failed jobs to transfer.sh * Explicitly handle quoting/unquoting of NSSNickname directive * Delegate directive value quoting/unquoting to separate functions * installutils: improve directive value parsing in `get_directive` * Fix the installutils.set_directive docstring * disable hostname canonicalization by Kerberos library * Travis CI: actually return non-zero exit status when the test job fails * Trim the test runner log to show only pytest failures/errors * Add license headers to the files used by Travis CI * Travis CI: use specific Python version during build * introduce install step to .travis.yml and cache pip installs * split out lint to a separate Travis job * Travis: offload test execution to a separate script * Travis CI: a separate script to run test tasks * Put the commands informing and displaying build logs on single line * travis: mark FreeIPA as python project * Bump up ipa-docker-test-runner version * Add a basic test suite for `kadmin.local` interface * Make `kadmin` family of functions return the result of ipautil.run * gracefully handle setting replica bind dn group on old masters * add missing attribute to ipaca replica during CA topology update * Revert "upgrade: add replica bind DN group check interval to CA topology config" * bindinstance: use data in named.conf to determine configuration status * Use ipa-docker-test-runner to run tests in Travis CI * Configuration file for ipa-docker-test-runner * Add 'env_confdir' to constants * Fix pep-8 transgressions in ipalib/misc.py * Make `env` and `plugins` commands local again * Revert "Add 'ipa localenv' subcommand" * Enhance __repr__ method of Principal * replication: ensure bind DN group check interval is set on replica config * upgrade: add replica bind DN group check interval to CA topology config * Improve the robustness FreeIPA's i18n module and its tests * Use common procedure to setup initial replication in both domain levels * ensure that the initial sync using GSSAPI works agains old masters * replication: refactor the code setting principals as replica bind DNs * replication: augment setup_promote_replication method * Turn replication manager group into ReplicationManager class member * Fix the naming of ipa-dnskeysyncd service principal * installutils: remove 'install_service_keytab' function * domain-level agnostic keytab retrieval in httpinstance * installers: restart DS after KDC is configured * dsinstance: use keytab retrieval method from parent class * use DM credentials to retrieve service keytab only in DLO * Service: common method for service keytab requests * Turn Kerberos-related properties to Service class members * Make service user name a class member of Service * service installers: clean up the inheritance * fix incorrect invocation of ipa-getkeytab during DL0 host enrollment * do partial host enrollment in domain level 0 replica install * Separate function to purge IPA host principals from keytab * certs: do not re-create NSS database when requesting service cert * initialize empty /etc/http/alias during server/replica install * CertDB: add API for non-destructive initialization from PKCS#12 bundle * test_ipagetkeytab: use system-wide IPA CA cert location in tests * Extend keytab retrieval test suite to cover new options * Modernize ipa-getkeytab test suite * extend ipa-getkeytab to support other LDAP bind methods * ipa-getkeytab: expose CA cert path as option * server-del: fix incorrect check for one IPA master * Revert "Fix install scripts debugging" * do not use keys() method when iterating through dictionaries * remove trailing newlines form python modules * mod_nss: use more robust quoting of NSSNickname directive * Move character escaping function to ipautil * Make Continuous installer continuous only during execution phase * use separate exception handlers for executors and validators * ipa passwd: use correct normalizer for user principals * trust-fetch-domains: contact forest DCs when fetching trust domain info * netgroup: avoid extraneous LDAP search when retrieving primary key from DN * advise: Use `name` instead of `__name__` to get plugin names * Use Travis-CI for basic sanity checks * ldapupdate: Use proper inheritance in BadSyntax exception * raise ValidationError when deprecated param is passed to command * Always fetch forest info from root DCs when establishing one-way trust * factor out `populate_remote_domain` method into module-level function * Always fetch forest info from root DCs when establishing two-way trust === Martin Basti (134) === * Become IPA 4.5.0 * Update 4.5 translations * Add copy-schema-to-ca for RHEL6 to contrib/ * Remove copy-schema-to-ca.py from master branch * pylint: bump dependency to version >= 1.6 * backup: backup anonymous keytab * tests: use --setup-kra in tests * KRA: add --setup-kra to ipa-server-install * man: add missing --setup-adtrust option to manpage * ipactl restart: log httplib failues as debug * Tests: search for disabled users * Test: DNS nsupdate from dns-update-system-records * DNS: dns-update-system-record can create nsupdate file * py3: ipa_generate_password: do not compare None and Int * py3: change_admin_password: use textual mode * py3: create DNS zonefile: use textual mode * py3: upgradeinstance: use bytes literals with LDIF operations * py3: upgradeinstance: decode data before storing them as backup... * py3: upgradeinstance: open dse.ldif in textual mode * custodia: kem.set_keys: replace too-broad exception * py3: kem.py: user bytes with ldap values * py3: custodia: basedn must be unicode * py3: configparser: use raw keyword * py3: modify_s: attribute name must be str not bytes * py3: ldapupdate: fix logging str(bytes) issue * DNSSEC: forwarders validation improvement * py3: test_ipaserver: fix BytesWarnings * py3: get_memberofindirect: fix ByteWarnings * py3: DN: fix BytesWarning * Tests: fix wait_for_replication task * py3: send Decimal number as string instead of base64 encoded value * py3: ipaldap: properly encode DNSName to bytes * py3: _convert_to_idna: fix bytes/unicode mistmatch * py3: DNS: get_record_entry_attrs: do not modify dict during iteration * py3: _ptrrecord_precallaback: use bytes with labels * py3: remove_entry_from_group: attribute name must be string * py3: base64 encoding/decoding returns always bytes don't mix it * pki-base: use pki-base-python2 as dependency * pki: add missing depedency pki-base[-python3] * py3: x509.py: return principal as unicode string * py3: tests_xmlrpc: do not call str() on bytes * py3: normalize_certificate: support both bytes and unicode * py3: strip_header: support both bytes and unicode * py3: fingerprint_hex_sha256: fix encoding/decoding * py3: fix CSR encoding inside framework * Principal: validate type of input parameter * Use dict comprehension * py3: can_read: attributelevelrights is already string * py3: get_effective_rights: values passed to ldap must be bytes * py3: ipaldap: update encode/decode methods * py3: rpcserver fix undefined variable * py3: WSGI executioners must return bytes in list * py3: session: fix r/w ccache data * Py3: Fix undefined variable * py3: rpcserver: decode input because json requires string * py3: session.py decode server name to str * Use proper logging for error messages * wait_for_entry: use only DN as parameter * py3: decode bytes for json.loads() * dogtag.py: fix exception logging of JSON data * py3: convert_attribute_members: don't use bytes as parameter for DN * py3: make_filter_from_attr: use string instead of bytes * py3: __add_acl: use standard ipaldap methods * py3: add_entry_to_group: attribute name must be string not bytes * py3: HTTPResponse has no 'dict' attribute in 'msg' * py3: _httplib_request: don't convert string to bytes * py3: cainstance: replace mkstemp with NamedTemporaryFile * py3: write CA/KRA config into file opened in text mode * py3: CA/KRA: config parser requires string * py3: ipautil: open tempfiles in text mode * py3: ldap modlist must have keys as string, not bytes * py3: open temporary ldif file in text mode * py3: service.py: replace mkstemp by NamedTemporaryFile * py3: create_cert_db: write to file in a compatible way * _resolve_records: fix assert, nameserver_ip can be none * Remove duplicated step from DS install * py3: enable py3 pylint * Py3: Fix ToASCII method * fix: regression in API version comparison * ipactl: pass api as argument to services * DNS: URI records: bump python-dns requirements * remove Knob function * KRA: don't add KRA container when KRA replica * Zanata: exlude testing ipa.pot file * client: use correct code for failed uninstall * client: use exceptions instead of return states * client: move install part to else branch * client: move install cleanup from ipa-client-install to module * client: move clean CCACHE to module * client: fix script execution * client: Remove useless except in ipa-client-install * client: move custom env variable into client module * client: extract checks from uninstall to uninstall_check * client: extract checks from install to install_check * client: move checks to client.install_check * client: make statestore and fstore consistent with server * IPAChangeConf: use constant for empty line * client: import IPAChangeConf directly instead the module * client: remove extra return from hardcode_ldap_server * client: install function: return constant not hardcoded number * client: remove unneded return from configure_ipa_conf * client: remove unneded return configure_krb5_conf * ipa-client-install: move client install to module * CI: Disable KRA install tests on DL0 * CI: use --setup-kra with replica installation * CI: extend replication layouts tests with KRA * CI: workaround: wait for dogtag before replica-prepare * Pylint: fix the rest of unused local variables * Pylint: remove unused variables in tests * Pylint: remove unused variables in ipaserver package * Pylint: remove unused variables from installers and scripts * Fix: find OSCP certificate test * Pylint: enable check for unused-variables * Remove unused variables in tests * Remove unused variables in the code * test_text: add test ipa.pot file for tests * Pylint: enable global-variable-not-assigned check * Pylint: enable cyclic-import check * Test: dont use global variable for iteration in test_cert_plugin * Use constant for user and group patterns * Fix regexp patterns in parameters to not enforce length * Add check for IP addresses into DNS installer * Fix missing config.ips in promote_check * Abstract procedures for IP address warnings * Catch DNS exceptions during emptyzones named.conf upgrade * Start named during configuration upgrade. * Tests: extend DNS cmdline tests with lowercased record type * Show warning when net/broadcast IP address is used in installer * Allow multicast addresses in A/AAAA records * Allow broadcast ip addresses * Allow network ip addresses * Fix parse errors with link-local addresses * Fix ScriptError to always return string from __str__ * Bump master IPA devel version to 4.4.90 === Martin Kosek (1) === * Update Contributors.txt === Milan Kub?k (4) === * ipatests: Fix assert_deepequal outside of pytest process * ipatests: Implement tests with CSRs requesting SAN * ipatests: Fix name property on a service tracker * ipatests: provide context manager for keytab usage in RPC tests === Michal Reznik (1) === * test_csrgen: adjusted comparison test scripts for CSRGenerator === Michal ?idek (1) === * git: Add commit template === Nathaniel McCallum (3) === * Migrate OTP import script to python-cryptography * Use RemoveOnStop to cleanup systemd sockets * Properly handle LDAP socket closures in ipa-otpd === Oleg Fayans (45) === * Test: uniqueness of certificate renewal master * Test: basic kerberos over http functionality * Test: made kinit_admin a returning function * tests: Added basic tests for certs in idoverrides * Created idview tracker * Test for installing rules with service principals * Test: integration tests for certs in idoverrides feature * Added interface to certutil * Automated ipa-replica-manage del tests * tests: Automated clean-ruv subcommand tests * Reverted the essertion for replica uninstall returncode * Test: disabled wrong client domain tests for domlevel 0 * tests: Fixed code styling in caless tests to make pep8 happy * tests: Reverted erroneous asserts in 4 tests * tests: fixed certinstall method * tests: fixed super method invocation * tests: added verbose assert to test_service_disable_doesnt_revoke * tests: Standardized replica_preparation in test_no_certs * tests: Implemented check for domainlevel before installation verification * tests: Fixed Usage of improper certs in ca-less tests * tests: fixed expects of incorrect error messages * tests: Replaced unused setUp method with install * tests: Replaced hardcoded certutil with imported from paths * tests: Enabled negative testing for cleaning replication agreements * tests: Made unapply_fixes call optional at master uninstallation * tests: Updated master and replica installation methods to enable negative testing * tests: Added necessary xfails * tests: Added necessary getkeytabs calls to fixtures * tests: Removed outdated command options test * tests: Applied correct teardown methods * tests: Fixed incorrect assert in verify_installation * tests: Adapted installation methods to utilize methods from tasks * tests: Removed call for install method from parent class * tests: Added teardown methods for server and replica installation * tests: Create a method that cleans all ipa certs * tests: Updated ipa server installation stdin text * tests: Added generation of missing certs * tests: Added basic constraints extension to the CA certs * tests: Fixed method failures during second call for the method * Xfailed a test that fails due to 6250 * Fixed segment naming in topology tests * Xfailed the tests due to a known bug with replica preparation * Changed addressing to the client hosts to be replicas * Several fixes in replica_promotion tests * Removed incorrect check for returncode === Petr ?ech (1) === * ipatests: nested netgroups (intg) === Petr Spacek (126) === * ipa_generate_password algorithm change * Remove named-pkcs11 workarounds from DNSSEC tests. * Build: forbid builds in working directories containing white spaces * Build: always use Pylint from Python version used for rest of the build * Build: specify BuildRequires for Python 3 pylint * Build: makerpms.sh generates Python 2 & 3 packages at the same time * Accept server host names resolvable only using /etc/hosts * Build: properly integrate ipa.pot into build system tests * Build: properly integrate ipasetup.py into build system * Build: properly integrate version.py into build system * Build: properly integrate loader.js into build system * Build: properly integrate freeipa.spec.in into build system * Build: properly integrate ipa-version.h.in into build system * Build: workaround bug while calling parallel make from rpmbuild * Build: remove ipa.pot from Git as it can be re-generated at any time * Build: integrate translation system tests again * Build: automatically generate list of files to be translated in configure * Build: clean in po/ removes *~ files as well * Build: support strip-po target for translations * Build: use standard infrastructure for translations * Build: fix path in ipa-ods-exporter.socket unit file * Build: fix file dependencies for make-css.sh * Build: update makerpms.sh to use same paths as rpmbuild * Build: remove incorrect use of MAINTAINERCLEANFILES * Build: enable silent build in makerpms.sh * Build: support --enable-silent-rules for Python packages * Build: workaround bug 1005235 related to Python paths in auto-generated Requires * Build: document what should be in %install section of SPEC file * Build: move web UI file installation from SPEC to Makefile.am * Build: move server directory handling from SPEC to Makefile.am * Build: move client directory handling from SPEC to Makefile.am * Update man page for ipa-adtrust-install by removing --no-msdcs option * Build: pass down %{release} from SPEC to configure * Build: update IPA_VERSION_IS_GIT_SNAPSHOT to comply with PEP440 * Build: add make srpms target * Build: IPA_VERSION_IS_GIT_SNAPSHOT re-generates version number on RPM build * Build: use POSIX 1003.1-1988 (ustar) file format for tar archives * Build: IPA_VERSION_IS_GIT_SNAPSHOT checks if source directory is Git repo * Build: remove unused and redundant code from configure.ac and po/Makefile.in * Build: fix make clean to remove build artifacts from top-level directory * Build: fix make clean for web UI * Build: add polint target for i18n tests * Build: add makeapi lint target * Build: add makeaci lint target * Build: add JS lint target * Build: add Python lint target * Build: remove obsolete instructions about BuildRequires from BUILD.txt * Build: add make rpms target and convenience script makerpms.sh * Build: fix KDC proxy installation and remove unused kdcproxy.conf * Build: remove unused dirs /var/cache/ipa/{sysupgrade,sysrestore} from SPEC * Build: do not compress manual pages at install time * Build: distribute doc directory * Build: create /var/run directories at install time * Build: integrate init and init/systemd into build system * Build: remove init/SystemV directory * Build: integrate contrib directory into build system * Build: remove ancient checks/check-ra.py * Build: integrate daemons/dnssec into build system * Build: fix distribution of daemons/ipa-slapi-plugins/topology files * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-winsync files * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-sidgen files * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-pwd-extop files * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-otp-lasttoken files * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-otp-counter files * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-exdom-extop files * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-cldap files * Build: fix distribution of ipa-slapi-plugins/common files * Build: fix distribution of daemon/ipa-kdb files * Build: fix distribution of client header file * Build: fix distribution of asn1/asn1c files * Build: fix distribution of install/REDME.schema file * Build: fix distribution of oddjob files * Build: Remove spurious EXTRA_DIST from install/share/Makefile.am * Build: cleanup unused LDIFs from install/share * Build: fix distribution of libexec scripts * Build: fix distribution and installation of update LDIFs * Web UI: Remove offline version of Web UI * Build: fix distribution of static files for web UI * Build: stop build when a step in web UI build fails * Build: fix distribution and installation of static files in top-level directory * Build: fix man page distribution * Build: fix distdir target for translations * Build: rename project from ipa-server to freeipa * Build: remove non-existing README files from Makefile.am * Build: fix Makefile.am files to separate source and build directories * Build: respect --prefix for systemdsystemunitdir * Build: fix make install in asn1 subdirectory * Build: fix ipaplatform detection for out-of-tree builds * Build: Makefiles for Python packages * Build: fix module name in ipaserver/setup.py * Build: replace hand-made Makefile with one generated by Automake * Build: move version handling from Makefile to configure * Docs: update docs about ipaplatform to match reality * Build: replace ipaplatform magic with symlinks generated by configure * Build docs: update platform selection instructions * Build: split out egg-info Makefile target from version-update target * Build: split API/ACI checks into separate Makefile targets * Build: use default error handling for PKG_CHECK_MODULES * Build: use libutil convenience library for client * Build: cleanup INI library detection * Build: modernize XMLRPC-client library detection * Build: modernize CURL library detection * Build: modernize SASL library detection * Build: modernize POPT library detection * Build: merge client/configure.ac into top-level configure.ac * Build: remove Transifex support * Build: move translations from install/po/ to top-level po/ * Build: merge install/configure.ac into top-level configure.ac * Build: merge ipatests/man/configure.ac to top-level configure.ac * Build: merge asn1/configure.ac to top-level configure.ac * Build: transform util directory to libutil convenience library * Build: promote daemons/configure.ac to top-level configure.ac * Build: adjust include paths in daemons/ipa-kdb/tests/ipa_kdb_tests.c * Build: pass down LIBDIR definition from RPM SPEC to Makefile * Build: remove deprecated AC_STDC_HEADERS macro * Build: require Python >= 2.7 * Build: remove traces of mozldap library * Build: modernize crypto library detection * Build: modernize UUID library detection * Build: modernize Kerberos library detection * Build: add missing KRB5_LIBS to daemons/ipa-otpd * Tests: print what was expected from callables in xmlrpc_tests * DNS: Improve field descriptions for SRV records * DNS: Support URI resource record type * Fix compatibility with python-dns 1.15.0 * Raise errors from service.py:_ldap_mod() by default === Petr Vobornik (6) === * permissions: add permissions for read and mod of external group members * webui: do not warn about CAs if there is only one master * webui: fixes normalization of value in attributes widget * Change README to use Markdown * Raise errors.EnvironmentError if IPA_CONFDIR var is incorrectly used * replicainstall: log ACI and LDAP errors in promotion check === Pavel Vomacka (69) === * Remove allow_constrained_delegation from gssproxy.conf * WebUI: Add support for management of user short name resolution * WebUI: add link to login page which for login using certificate * Support certificate login after installation and upgrade * TESTS WebUI: Vaults management * TESTS: Add support for sidebar with facets * TESTS: Add support for KRA in ui_driver * WebUI: add vault management * WebUI: allow to show rows with same pkey in tables * WebUI: search facet's default actions might be overriden * Add possibility to hide only one tab in sidebar * Possibility to set list of table attributes which will be added to _del command * Extend _show command after _find command in table facets * Add possibility to pass url parameter to update command of details page * Add property which allows refresh command to use url value * Added optional option in refreshing after modifying association table * Possibility to skip checking writable according to metadata * Allow to set another other_entity name * Additional option to add and del operations can be set * WebUI: Add cermapmatch module * WebUI: Add Adapter for certmap_match result table * WebUI: Possibility to choose object when API call returns list of objects * WebUI: Add possibility to turn of autoload when details.load is called * WebUI: don't change casing of Auth Indicators values * WebUI: Allow disabling lowering text in custom_checkbox_widget * Add support for custom table pagination size * Make singleton from config module * Add javascript integer validator * WebUI: Add certmap module * WebUI: Add Custom command multivalued adder dialog * WebUI: Create non editable row widget for mutlivalued widget * WebUI: Add possibility to set field always writable * WebUI: Change structure of Identity submenu * WebUI: add sizelimit:0 to cert-find * WebUI: fix incorrect behavior of ESC button on combobox * WebUI: add default on_cancel function in adder_dialog * Coverity: removed useless semicolon which ends statement earlier * Coverity: Fix possibility of access to attribute of undefined * Change activity text while loading metadata * Refactoring of rpc module * WebUI: update Patternfly and Bootstrap * WebUI: Hide incorrectly shown buttons on hosts tab in ID Views * Lowered the version of gettext * Add python-pyasn1-modules into dependencies * Adjustments for setup requirements v2 * TESTS: Update group type name * Coverity - null pointer dereference * Coverity - accessing attribute of variable which can point to null * Coverity - opens dialog which might not be created * Coverity - iterating over variable which could be null * Coverity - null pointer dereference * Coverity - true branch can't be executed * Coverity - true branch can't be executed * Coverity - removed dead code * Coverity - Accesing attribute of null * Coverity - identical code for different branches * Coverity - not initialized variable * Coverity - null pointer exception * Coverity - null pointer exception * WebUI: services without canonical name are shown correctly * WebUI: fix API Browser menu label * Add tooltip to all fields in DNS record adder dialog * WebUI: hide buttons in certificate widget according to acl * WebUI: Change group name from 'normal' to 'Non-POSIX' * WebUI: Add handling for HTTP error 404 * Add 'Restore' option to action dropdown menu * WebUI add support for sub-CAs while revoking certificates * WebUI: Fix showing certificates issued by sub-CA * Add support for additional options taken from table facet === Gabe (1) === * Allow nsaccountlock to be searched in user-find command === Simo Sorce (31) === * Store session cookie in a ccache option * Add support for searching policies in cn=accounts * Add code to retrieve results from multiple bases * Use GSS-SPNEGO if connecting locally * Limit sessions to 30 minutes by default * Remove non-sensical kdestroy on https stop * Fix session logout * Deduplicate session cookies in headers * Change session logout to kill only the cookie * Insure removal of session on identity change * Explicitly pass down ccache names for connections * Allow rpc callers to pass ccache and service names * Fix uninstall stopping ipa.service * Rationalize creation of RA and HTTPD NSS databases * Add a new user to run the framework code * Always use /etc/ipa/ca.crt as CA cert file * Simplify NSSDatabase password file handling * Separate RA cert store from the HTTP cert store * Configure HTTPD to work via Gss-Proxy * Use Anonymous user to obtain FAST armor ccache * Drop use of kinit_as_http from trust code * Generate tmpfiles config at install time * Change session handling * Use the tar Posix option for tarballs * Add compatibility code to retrieve headers * Configure Anonymous PKINIT on server install * Properly handle multiple cookies in rpc lib. * Properly handle multiple cookies in rpcclient * Support DAL version 5 and version 6 * Fix install scripts debugging * Fix error message encoding === Stanislav Laznicka (78) === * Remove pkinit from ipa-replica-prepare * Backup KDC certificate pair * Don't fail more if cert req/cert creation failed * Fix ipa-replica-prepare server-cert creation * Don't allow standalone KRA uninstalls * Add message about last KRA to WebUI Topology view * Add check to prevent removal of last KRA * Don't use weak ciphers for client HTTPS connections * We don't offer no quickies * Fix cookie with Max-Age processing * Fix CA-less upgrade * Fix replica with --setup-ca issues * Moving ipaCert from HTTPD_ALIAS_DIR * Added a PEMFileHandler for Custodia store * Refactor certmonger for OpenSSL certificates * Workaround for certmonger's "Subject" representations * Remove ipapython.nsslib as it is not used anymore * Remove NSSConnection from otptoken plugin * Remove pkcs12 handling functions from CertDB * Remove NSSConnection from Dogtag * Move publishing of CA cert to cainstance creation on master * Don't run kra.configure_instance if not necessary * Move RA agent certificate file export to a different location * Remove NSSConnection from the Python RPC module * Remove md5_fingerprints from IPA * Remove DM password files after successfull pkispawn run * Remove ra_db argument from CAInstance init * Fix ipa-server-upgrade * Use newer Certificate.serial_number in krainstance.py * Fix error in ca_cert_files validator * Don't prepend option names with additional '--' * Bump python-cryptography version in ipasetup.py.in * custodiainstance: don't use IPA-specific CertDB * Add password to certutil calls in NSSDatabase * Explicitly remove support of SSLv2/3 * Add FIPS-token password of HTTPD NSS database * Bump required python-cryptography version * Remove is_fips_enabled checks in installers and ipactl * Generate sha256 ssh pubkey fingerprints for hosts * Unify password generation across FreeIPA * Clarify meaning of --domain and --realm in installers * replicainstall: give correct error message on DL mismatch * Fix permission-find with sizelimit set * Generalize filter generation in LDAPSearch * permission-find: fix a sizelimit off-by-one bug * fix permission_find fail on low search size limit * Make get_entries() not ignore its limit arguments * Do not log DM password in ca/kra installation logs * Fix CA replica install on DL1 * Offer more general way to check domain level in replicainstall * Use same means of checking replication agreements on both DLs * replicainstall: move common checks to common_check() * Take advantage of the ca/kra code cleanup in replica installation * Use updated CA certs in replica installation * Use os.path.join instead of concatenation * Remove redundant CA cert file existance check * Use host keytab to connect to remote server on DL0 * Split install_http_certs() into two functions * First step of merging replica installation of both DLs * Properly bootstrap replica promotion api * Move the pki-tomcat restart to cainstance creation * Move httpd restart to DNS installation * Import just IPAChangeConf instead of the whole module * Added file permissions option to IPAChangeConf.newConf() * Fix to ipachangeconf docstrings * replicainstall: Unify default.conf file creation * Replaced EMPTY_LINE constant with a function call * client: Making the configure functions more readable * Moved update of DNA plugin among update plugins * Move ds.replica_populate to an update plugin * Remove redundant dsinstance restart * Fix missing file that fails DL1 replica installation * Make httpd publish its CA certificate on DL1 * Make installer quit more nicely on external CA installation * Fix test_util.test_assert_deepequal test * Pretty-print structures in assert_deepequal * Remove update_from_dict() method * Updated help/man information about hostname === Thierry Bordaz (1) === * IPA Allows Password Reuse with History value defined when admin resets the password. === Timo Aaltonen (8) === * ipaplatform/debian/paths: Add some missing values. * ipaplatform/debian/paths: Rename IPA_KEYTAB to OLD_IPA_KEYTAB. * ipaplatform/debian/paths: Add IPA_HTTPD_KDCPROXY. * ipaplatform/debian/services: Fix is_running arguments. * ipaplatform: Add Debian platform module. * client, platform: Use paths.SSH* instead of get_config_dir(). * Move ipa-otpd to $libexecdir/ipa * Purge obsolete firefox extension === Tomas Krizek (68) === * installer: update time estimates * server install: require IPv6 stack to be enabled * Add SHA256 fingerprints for certs * man: update ipa-cacert-manage * test_config: fix fips_mode key in Env * Env __setitem__: replace assert with exception * FIPS: perform replica installation check * replicainstall: add context manager for rpc client * check_remote_version: update exception and docstring * test_config: fix tests for env.fips_mode * Add fips_mode variable to env * Bump required version of bind-dyndb-ldap to 11.0-2 * bindinstance: fix named.conf parsing regexs * PEP8: fix line length for regexs in bindinstance * bump required version of BIND, bind-dyndb-ldap * named.conf template: update API for bind 9.11 * Remove obsolete serial_autoincrement from named.conf parsing * certdb: remove unused valid_months property * certdb: remove unused keysize property * Fix coverity issue * ipautil: check for open ports on all resolved IPs * replica-conncheck: improve message logging * replica-conncheck: improve error message during replicainstall * ipa-replica-conncheck: fix race condition * ipa-replica-conncheck: do not close listening ports until required * upgrade: ldap conn management * services: replace admin_conn with api.Backend.ldap2 * upgrade: do not explicitly set principal for services * Build: ignore rpmbuild for lint target * cainstance: use correct certificate for replica install check * dns: check if container exists using ldapi * ipaldap: remove do_bind from LDAPClient * gitignore: ignore tar ball * libexec scripts: ldap conn management * ldap2: modify arguments for create_connection * replicainstall: use ldap_uri in ReplicationManager * replicainstall: correct hostname in ReplicationManager * install tools: ldap conn management * ldap2: change default bind_dn * ipa-adtrust-install: ldap conn management * install: remove adhoc dis/connect from services * ldapupdate: use ldapi in LDAPUpdate * replicainstall: properly close adhoc connection in promote * install: ldap conn management * install: remove adhoc api.Backend.ldap2 (dis)connect * install: add restart_dirsrv for directory server restarts * upgradeinstance: ldap conn management * dsinstance: conn management * ldap2: change default time/size limit * cainstall: add dm_password to CA installation * replicainstall: set ldapi uri in replica promotion * dsinstance: enable ldapi and autobind in ds * install: remove dirman_pw from services * ipaldap: merge IPAdmin to LDAPClient * ipaldap: merge gssapi_bind to LDAPClient * ipaldap: merge external_bind into LDAPClient * ipaldap: merge simple_bind into LDAPClient * ipaldap: remove wait/timeout during binds * ipa: check if provided config file exists * ipa: allow relative paths for config file * Prompt for forwarder in dnsforwardzone-add * Update man/help for --server option * Update ipa-server-install man page for hostname * Add help info about certificate revocation reasons * Add log messages for IP checks during client install * Show error message for invalid IPs in client install * Keep NSS trust flags of existing certificates * Don't show error messages in bash completion === Thorsten Scherf (2) === * added ssl verification using IPA trust anchor * added help about default value for --external-ca-type option === shanyin (1) === * fix missing translation string -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From aly.khimji at gmail.com Wed Mar 15 18:50:09 2017 From: aly.khimji at gmail.com (Aly Khimji) Date: Wed, 15 Mar 2017 14:50:09 -0400 Subject: [Freeipa-users] Announcing FreeIPA 4.5.0 In-Reply-To: <9d9d0c43-53a6-43ae-da5c-f490716a1560@redhat.com> References: <9d9d0c43-53a6-43ae-da5c-f490716a1560@redhat.com> Message-ID: Congratulations on the release! Also for your continued efforts and hard work ! Aly On Mar 15, 2017 2:34 PM, "Martin Basti" wrote: > Release date: 2017-03-15 > > The FreeIPA team would like to announce FreeIPA 4.5.0 release! > > It can be downloaded from http://www.freeipa.org/page/Downloads. Builds > for > Fedora 25 and Fedora 26 will be available soon in the official COPR > repository: freeipa/freeipa-4-5/> > > > This announcement is also available at > . > > > == Highlights in 4.5.0 == > > === Enhancements === > ==== AD User Short Names ==== > Support for AD users short names has been added. Short names can be > enabled from CLI by setting `ipa config-mod > --domain-resolution-order="domain.test:ad.domain1.test:ad.domain2.test"` > or from WebUI under ''Configuration'' tab. No manual configuration on > SSSD side is required. > > Please note that this feature is not supported by SSSD yet and the work > is tracked with > * > > ==== FIPS 140-2 Support ==== > FreeIPA server and client can be installed on FIPS enabled systems. MD5 > fingerprints have been replaced with SHA256. Variable ''fips_mode'' has > been added to env that indicates whether FIPS is turned on the server. > > Please note that FIPS 140-2 support may not work on some platforms > because all dependencies of FreeIPA must support FIPS 140-2 what we > cannot guarantee. (Should work with RHEL 7.4+.) The FreeIPA code itself > is FIPS 140-2 compatible. > * > > ==== Certificate Identity Mapping ==== > Support for multiple certificates on Smart cards has been added. User > can choose which certificate is used to authenticate. This allows to > define multiple certificates per user. > The same certificate can be used by different accounts, and the mapping > between a certificate and an account can be done through binary match of > the whole certificate or a match on custom certificate attributes (such > as Subject + Issuer). > * > > ==== Improvements for Containerization ==== > AD trust and KRA can be installed in one step in containers without need > to call subsequent ipa-adtrust-install and ipa-kra-install in containers. > Option ''--setup-adtrust'' has been added to ''ipa-server-install'' and > ''ipa-replica-install'', and option ''--setup-kra'' has been added to > ''ipa-server-install''. > * > * > > ==== Semi-automatic Integration with External DNS ==== > Option "--out" has been added to command "ipa > dns-update-system-records". This option allows to store IPA system DNS > records in nsupdate format in specified file and can be used with > nsupdate command to update records on an external DNS server. For more > details see this howto > DNS_records_on_a_remote_DNS_server> > * > > === Known Issues === > * CLI doesn't work after ''ipa-restore'' > > * AD Trust doesn't work with enabled FIPS mode > > * ''cert-find'' does not find all certificates without sizelimit=0 > > > === Bug fixes === > Contains all bugfixes and enhacements of 4.4.1, 4.4.2, 4.4.3 releases > > ==== Installers Refactoring ==== > Installers code base has been migrated into modules and many code > duplication has been removed. > * > > ==== "Normal" group has been renamed to "Non-POSIX" in WebUI ==== > In the web UI, the group type label "Normal" has been changed to > "Non-POSIX" to be compatible with CLI options. The semantics of group > types is unchanged. > * > > ==== Build System Refactoring ==== > Several improvements of FreeIPA build system have been done. In case you > are package maintainer please read the following design document. > * > > ==== LDAP Connection Management Refactoring ==== > LDAP connection management has been standardized across FreeIPA and > should prevent LDAP connection issues during installation and upgrades > in future. > * > > ==== Do not fail when IPA server has shortname first in /etc/hosts ==== > Kerberos client library is now instructed to not attempt to canonicalize > hostnames when issuing TGS requests. This improves security by avoiding > DNS lookups during canonicalization and also improves robustness of > service principal lookups in more complex DNS environments (clouds, > containerized applications). Due to this change in behavior, care must > be taken to specify correct FQDN in host/service principals as no > attempt to resolve e.g. short names will be made. > * > > ==== Replica Connection Check Improvements ==== > Improved connection check reduces possibility of failure in further > installation steps. Now ports on both IPv4 and IPv6 addresses are > checked (if available). > * > > ==== Replace NSS with OpenSSL ==== > Should reduce number of issues related to HTTPS connections. This change > was also needed to support FIPS. > * > > ==== Fully customisable CA name ==== > > The CA subject name is now fully customisable, and is no longer > required to be related to the certificate subject base. The > ''ipa-server-instal'' and ''ipa-ca-install'' commands learned the > ''--ca-subject'' and ''--subject-base'' options for configuring these > values. > > * > > == Upgrading == > Upgrade instructions are available on [[Upgrade]] page. > > == Feedback == > Please provide comments, bugs and other feedback via the freeipa-users > mailing > list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa > channel on Freenode. > > > == Resolved tickets == > * 6764 debian: python modules should be installed under dist-packages > * 6759 replica prepare broken on KDC cert export > * 6755 [certs.py] - "ipa-replica-prepare" command fails when trying to > unlink non-existing "tmpcert.der" file in /var/lib/ipa/ > * 6750 Web page ipa/config/ssbrowser.html refers to missing > ipa/config/ca.crt file > * 6739 Cannot login to replica's WebUI > * 6735 The ipa-managed-entries command failed, exception: > AttributeError: ldap2 > * 6734 vaultconfig-show throws internal error > * 6731 ipa-server-install: allow to in install KRA in one step > * 6730 Harden client HTTPS connections > * 6724 [test_csrgen.py] - comparison test scripts not reflected changes > in "openssl_base.tmpl" > * 6723 ipa systemd unit should define Wants=network instead of > Requires=network > * 6718 SessionMaxAge in /etc/httpd/conf.d/ipa.conf introduces regression > * 6717 WebUI: change structure of Identity submenu > * 6714 ipaclient.csrgen depends on ipaplatform > * 6713 ipa: Insufficient permission check for ca-del, ca-disable and > ca-enable commands (CVE-2017-2590) > * 6712 WebUI: Arbitrary certificates on {user|host|service} details > pages are not displayed in WebUI > * 6707 Removal of IPAConfig broke Ipsilon's FreeIPA integration > * 6701 Add SHA256 fingerprints > * 6698 User with ticket gets GSS failure when calling freeipa CLI command > * 6694 ipa-client-install command failed, TypeError: list found > * 6690 Plugin schema cache is slow > * 6686 ipa-replica-install fails promotecustodia.create_replica with > cert errors (untrusted) after adding externally signed CA cert > * 6685 logout does not work properly > * 6682 session logout should not remove ccache > * 6680 kra-agent.pem file is not auto-renewed by certmonger > * 6676 unable to parse cookie header > * 6675 KRA_AGENT_PEM file is missing > * 6674 ipactl: noise error from pki-tomcatd start > * 6673 httpd unit files deletes root ccache > * 6670 PKINIT upgrade process is incomplete > * 6661 Move ipa session data from keyring to ccaches > * 6659 ipa-backup does not include /root/kracert.p12 > * 6650 [vault] Replace nss crypto with cryptography > * 6648 Make ipa-cacert-manage man page more clear > * 6647 batch param compatibility is incorrect > * 6646 IdM Server: list all Employees with matching Smart Card > * 6643 [RFE] Add ipa-whoami command > * 6640 DS certificate request during replica install fails due to > bytes/string mismatch > * 6639 Rewrite the code handling discovery and adding of AD trust agents > in AD trust installer > * 6638 AD trust installer should be able to configure samba instance > also without admin credentials > * 6637 Build fails on Fedora 26 > * 6636 UnboundLocalError during ipa-client-install > * 6634 --ignore-last-of-role is not in man page > * 6633 IPA replica install log shows password in plain text > * 6631 Use Python warnings for development > * 6630 Merge AD trust installer to server/replica install > * 6629 Migrate AD trust installer on the new-style installer framework > * 6625 WSGI fails with internal server error when mode != production > (locked attribute) > * 6623 Stageuser is missing -{add,remove}-{cert,principal} commands > * 6620 Remove ipa-upgradeconfig command > * 6619 krb5 1.15 broke DAL principal free > * 6608 IPA server installation should check if IPv6 stack is enabled > * 6607 Deprecate SSLv2 from API config > * 6606 Full backup and restore prevents KRA from installing > * 6601 [RFE] WebUI: Certificate Identity Mapping > * 6600 Legacy client tests doesn't have tree domain role. > * 6598 [webui] Show "CA replica warning" only if there one or more > replicas but only 1 CA > * 6597 ipapython.version.DEFAULT_PLUGINS is not configured > * 6596 Update ETAs in installers > * 6588 replication race condition prevents IPA to install > * 6586 Minor string fixes in dsinstance.py > * 6585 [RFE] nsupdate output format in dns-update-system-records command > * 6584 ipa-client-install fails to get CA cert via LDAP when non-FQDN > name of IPA server is first in /etc/hosts > * 6578 IPA CLI will eventually stop working when invoked in parallel > * 6575 ipa-replica-install fails on requesting DS cert when master is > not configured with IPv6 > * 6574 description of --domain and --realm is confusing > * 6573 CA-less replica installation fails due to attempted cert issuance > * 6570 Duplicate PKINIT certificates being tracked after restoring IPA > backup on re-installed master > * 6565 FreeIPA server install fails (and existing servers probably fail > to start) due to changes in 'dyndb' feature on merge to upstream BIND > * 6564 IPA WebUI certificates are grayed out on overview page but not on > details page > * 6559 [py3] switch to PY3 causes warnings from IPA schema cache > * 6558 [Py3] http session cookie doesn't work under Py3 > * 6551 Upgrade Samba configuration to not include keytab prefix > * 6550 Refactor PKCS #7 parsing to use pyasn1_modules > * 6548 [RFE] Mention ipa-backup in warning message before uninstalling > IPA server > * 6547 [RFE] Certificates issued by externally signed IdM CA should > contain full trust chain > * 6546 Delete option shouldn't be available for hosts applied to view. > * 6542 [RFE] Certificate Identity Mapping > * 6541 ipa-replica-install fails to import DS cert from replica file > * 6540 Migration from ipa-3.0 fails due to crashing copy-schema-to-ca.py > * 6539 ipa vault operations are not possible with an older server > * 6538 KRA: add checks to prevent removing the last instance of KRA in > topology > * 6534 topology should not include A<->B segment "both" and B->A "left > right" at the same time. > * 6532 replica installation incorrectly sets > nsds5replicabinddngroup/nsds5replicabinddngroupcheckinterval on IPA 3.x > instance > * 6526 remove "request certificate with subjectaltname" permission > * 6522 ipa-replica-conncheck should check for open ports on all IPs > resolved from hostname > * 6518 Can not install IPA server when hostname is not DNS resolvable > * 6514 replica install: request_service_cert doesn't raise error when > certificate isuance failed > * 6513 `ipa plugins` command crashes with internal error > * 6512 Improve the robustness FreeIPA's i18n module and its tests > * 6510 Wrong error message during failed domainlevel 0 installations > without a replica file > * 6508 ipa-ca-install on promoted replica hangs on creating a temporary > CA admin > * 6505 Make ipapython.kerberos.Principal.__repr__ show the actual > principal name > * 6504 Create a test for uniqueness of CA renewal master > * 6503 IPA upgrade of replica without DNS fails during restart of > named-pkcs11 > * 6500 ipa-server-upgrade fails with AttributeError > * 6498 Build system must regenerate file when template changes. > * 6497 Misleading error message in replica_conn_check() > * 6496 remove references to ds_newinst.pl > * 6495 DNSSEC: ipa-ods-expoter.socket creates incorrect socket and > breaks DNSSEC signing > * 6492 Register entry points of Custodia plugins > * 6490 Add local-env subcommand to ipa script > * 6489 Provide legacy client test coverage with tree root domain > * 6487 ipa-replica-conncheck fails randomly (race condition) > * 6486 Add NTP server list to ipaplatform > * 6481 Create a test for instantiating rules with service principals > * 6480 Update man page for ipa-adtrust-install by removing --no-msdcs > option > * 6474 Remove ipaplatform dependency from ipa modules > * 6472 cert-request no longer accepts CSR with extraneous data > surrounding PEM data > * 6469 Use xml.etree instead of lxml in odsmgr.py > * 6466 [abrt] krb5-server: ipadb_change_pwd(): kdb5_util killed by SIGSEGV > * 6461 LDAP Connection Management refactoring > * 6460 NSSNickname enclosed in single quotes causes > ipa-server-certinstall failure > * 6457 ipa dnsrecord-add fails with Keyerror stack trace > * 6455 Add example of RDN order for ipa-server-install --subject > * 6451 Automate managed replication topology 4.4 features > * 6448 Tests: Stageuser tracker creation of user with minimal values, > with uid not specified > * 6446 Create test for kerberos over http > * 6445 Traceback seen in error_log when trustdomain-del is run > * 6439 Members of nested netgroups configured in IdM cannot be seen by > getent on clients > * 6435 Fix zanata.xml config to skip testing ipa.pot file > * 6434 Installers: perform host enrollment also in domain level 0 > replica install > * 6433 Refactor installer code requesting certificates > * 6420 Pretty print option of pytest makes tracker fail when used in ipa > console > * 6419 cert-show default output does not show validity > * 6417 Skip topology disconnect/last of role checks when uninstalling > single domain level 1 master > * 6415 replica-install creates spurious entries in cn=certificates > * 6412 Create tests for certs in idoverrides feature > * 6410 Tests: Verify that cert commands show CA without --all > * 6409 [RFE] extend ipa-getkeytab to support other LDAP bind methods > * 6406 Use common mechanism for setting up initial replication in both > domain levels > * 6405 unify domain level-specific mechanisms for replica's DS/HTTP > keytab generation > * 6402 IPA Allows Password Reuse with History value defined when admin > resets the password. > * 6401 Revert expected returncode in replica_promotion test > * 6400 Add file_exists method as a member of transport object > * 6399 Object-Signing cert is unused; don't create it > * 6398 Refactor certificate inspection code to use python-cryptography > * 6397 WebUI: Services are not displayed correctly after upgrade > * 6396 Cleanup AD trust information after tests > * 6394 WebUI: Update Patternfly and Bootstrap to newer versions > * 6393 Make httpd publish CA certificate on Domain Level 1 > * 6392 Installers refactoring tracker > * 6388 WebUI: Adder dialog cannot be reopened in case that it is closed > using ESC and dropdown field was focuseded > * 6386 Use api.env.nss_dir instead of paths.IPA_NSSDB_DIR > * 6384 Web UI: Lowercase "b" in the "API browser" subtab label > * 6381 ipa-cacert-manage man page should mention to run ipa-certupdate > * 6375 ipa-replica-install fails when replica file created after > ipa-ca-install on domain level 0 > * 6372 [RFE] allow managing prioritized list of trusted domains for > unqualified ID resolution > * 6369 [tracker] raise 389 requires when "Total init may fail if the > pushed schema is rejected" is part of update > * 6365 Custodia compatibility: add iSecStore.span method > * 6359 test_0003_find_OCSP will never fail > * 6358 ipa migrate-ds fails when it finds a referral > * 6357 ipa-server-install script option --no_hbac_allow should match > other options > * 6354 regression: certmap.conf file is not backedup during > ipa-server-upgrade > * 6352 replica promotion with OTP: add additional info to ""Insufficient > privileges" error message > * 6347 Tests: provide trust test coverage for tree root domains > * 6344 [RFE] support URI resource records > * 6343 [RFE] Allow login to WebUI using Kerberos aliases/enterprise > principals > * 6340 IPA client ipv6 - invalid --ip-address shows traceback > * 6335 Set priority as required filed in password policy > * 6334 "Normal" group type in the UI is confusing > * 6331 Reason is lost when CheckedIPAddress returns ValueError in > ipa-client-install > * 6308 [webui] Does not handle uppercase authentication indicators. > * 6305 host/service-mod with --certificate= (remove all certs) does not > revoke certs > * 6295 cert-request is not aware of Kerberos principal aliases > * 6269 cert-find --all does not show information about revocation > * 6263 ipa-server-certinstall does not update all certificate stores and > doesn't set proper trust permissions > * 6226 ipa-replica-install in CA-less environment does not configure DS > TLS - ipa-ca-install then fails on replica > * 6225 [RFE] Web UI: allow Smart Card authentication - finalization > * 6202 ipa-client-install - document that --server option expects FQDN > * 6178 Add options to retrieve lightweight CA certificate/chain > * 6169 ipa dnsforwardzone-add w/o arguments fails > * 6144 RPC code should be agnostic to display layer > * 6132 Broken setup if 3rd party CA certificate conflicts with > system-wide CA certificate > * 6128 Tests: Base tracker contains leftover attributes from host tracker > * 6126 Tests: User tracker does not enable creation of user with minimal > values > * 6125 Tests: unaccessible variable self.attrs for entries that are not > created via standard create method in Tracker > * 6124 Tests: remove --force option from tracker base class > * 6123 Tests: Tracker enables silent deleting and creating entries > * 6114 Traceback message seen when ipa is provided with invalid > configuration file name > * 6088 test_installation.py tests involving KRA installation on replicas > fail in domain level 0 > * 6005 Create an automated test for Certs in idoverrides feature > * 5949 ipa-server-install: improve prompt on interactive installation > * 5935 [py3] DNSName.ToASCII broken with python3 > * 5742 [RFE] [webui] Configurable page size / User config page > * 5695 [RFE] FreeIPA on FIPS enabled systems > * 5640 Framework does not respect sizelimit passed via webUI in some > searches > * 5348 [tracker] dig + dnssec does not display signature of freshly > created root zone > * 4821 UI drops "Unknown Error" when the ipa record in /etc/hosts changes > * 4189 [RFE] Use GSS-Proxy for the HTTP service > * 3461 [RFE] Extend freeipa's sudo to support selinux transition roles > * 157 Python 3.2a1 in rawhide > > == Detailed changelog since 4.4.4 == > === Jan Barta (8) === > * pylint: fix bad-mcs-method-argument > * pylint: fix bad-mcs-classmethod-argument > * pylint: fix bad-classmethod-argument > * pylint: fix old-style-class > * pylint: fix redefine-in-handler > * pylint: fix pointless-statement > * pylint: fix unneeded-not > * pylint: fix simplifiable-if-statement warnings > > === Alexander Bokovoy (7) === > * ipaserver/dcerpc.py: use arcfour_encrypt from samba > * add whoami command > * pkinit: make sure to have proper dictionary for Kerberos instance on > upgrade > * ipa-kdb: support KDB DAL version 6.1 > * ipa-kdb: search for password policies globally > * adtrust: remove FILE: prefix from 'dedicated keytab file' in smb.conf > * trustdomain-del: fix the way how subdomain is searched > > === Abhijeet Kasurde (11) === > * Minor typo fix in DNS install plugin > * Update warning message for replica install > * Add fix for ipa plugins command > * Update man page of ipa-server-install > * Remove deprecated ipa-upgradeconfig command > * Update warning message for ipa server uninstall > * Fix for handling CalledProcessError in authconfig > * Enumerate available options in IPA installer > * Provide user hint about IP address in IPA install > * Add fix for no-hbac-allow option in server install > * Added a fix for setting Priority as required field in Password Policy > Details facet > > === Ben Lipton (8) === > * csrgen: Support encrypted private keys > * csrgen: Allow overriding the CSR generation profile > * csrgen: Automate full cert request flow > * tests: Add tests for CSR autogeneration > * csrgen: Use data_sources option to define which fields are rendered > * csrgen: Add a CSR generation profile for user certificates > * csrgen: Add CSR generation profile for caIPAserviceCert > * csrgen: Add code to generate scripts that generate CSRs > > === Christian Heimes (88) === > * Add PYTHON_INSTALL_EXTRA_OPTIONS and --install-layout=deb > * Make pylint and jsl optional > * Ignore ipapython/.DEFAULT_PLUGINS > * Run test_ipaclient test suite > * Chain CSR generator file loaders > * Move csrgen templates into ipaclient package > * Use https to get security domain from Dogtag > * Cleanup certdb > * Default to pkginstall=true without duplicated definitions > * pylint: ignore pypi placeholders > * Python build: use --build-base everywhere > * Add with_wheels global to install wheel and PyPI packaging dependencies > * Add placeholders for ipaplatform, ipaserver and ipatests > * Add python-wheel as build requirement > * Packaging: Add placeholder packages > * Vault: port key wrapping to python-cryptography > * Remove NSPRError exception from platform tasks > * Remove import nss from test_ldap > * certdb: Don't restore_context() of new NSSDB > * Finish port to PyCA cryptography > * Drop in-memory copy of schema zip file > * Speed up client schema cache > * C compilation fixes and hardening > * lite-server: validate LDAP connection and cache schema > * Add --without-ipatests option > * Add missing include of stdint.h for uint8_t > * Client-only builds with --disable-server > * New lite-server implementation > * Explain more performance tricks in doc string > * Fix test, nested lists are no longer converted to nested tuples > * Pretty print JSON in debug mode (debug level >= 2) > * Convert list to tuples > * Faster JSON encoder/decoder > * Backup /root/kracert.p12 > * Ditch version_info and use version number from ipapython.version > * test_StrEnum: use int as bad type > * Stable _is_null check > * cryptography has deprecated serial in favor of serial_number > * Enable additional warnings (BytesWarning, DeprecationWarning) > * Print test env information > * Clean / ignore make check artefact > * ipapython: Add dependencies on version.py > * pytest: set rules to find test files and functions > * Fix used before assignment bug in host_port_open() > * Use pytest conftest.py and drop pytest.ini > * Catch ValueError raised by pytest.config.getoption() > * Silence pylint import errors of ipaserver in ipalib and ipaclient > * Relax check for .git to support freeipa in submodules > * Ignore backup~ files like config.h.in~ > * Fetch correct exception in IPA_CONFDIR test > * Use env var IPA_CONFDIR to get confdir > * Set explicit confdir option for global contexts > * Remove import of ipaplatform.paths from test_ipalib > * Remove BIN_FALSE and BIN_TRUE > * Add pylint guard to import of ipaplatform in ipapython.certdb > * Require python-gssapi >= 1.2.0, take 2 > * Backwards compatibility with setuptools 0.9.8 > * Require python-cryptography >= 1.3.1 > * Wheel bundles fixes > * Require python-gssapi >= 1.2.0 > * Adjustments for setup requirements > * wrap long line > * Silence import warnings for Samba bindings > * Fix Python 3 bugs discovered by pylint > * Python3 pylint fixes > * Add main guards to a couple of Python scripts > * Break ipaplatform / ipalib import cycle of hell > * Replace LooseVersion > * Don't ship install subpackages with wheels > * Minor fixes for IPAVersion class > * Pylint: whitelist packages with extension modules > * Add 'ipa localenv' subcommand > * ipapython and ipatest no longer require lxml > * Register entry points of Custodia plugins > * Use xml.etree in ipa-client-automount script > * Port ipapython.dnssec.odsmgr to xml.etree > * Add install requirements to Python packages > * Make api.env.nss_dir relative to api.env.confdir > * Don't modify redhat_system_units > * Use correct classifiers to make setup.py files PyPI compatible > * Use api.env.nss_dir instead of paths.IPA_NSSDB_DIR > * Add __name__ == __main__ guards to setup.pys > * Remove ipapython/ipa.conf > * Port all setup.py to setuptools > * Replace ipaplatform's symlinks with a meta importer > * Move ipa.1 man file > * Add iSecStore.span > * Use RSA-OAEP instead of RSA PKCS#1 v1.5 > > === David Kupka (20) === > * rpcserver: x509_login: Handle unsuccessful certificate login gracefully > * Bump required version of gssproxy to 0.7.0 > * tests: Add tests for kerberos principal aliases in stageuser > * tests: kerberos_principal_aliases: Deduplicate tests > * tests: Stageuser-{add,remove}-cert > * tests: add-remove-cert: Use harcoded certificates instead of > requesting them > * ipalib.x509: Handle missing SAN gracefully > * stageuser: Add stageuser-{add,remove}-principal > * stageuser: Add stageuser-{add,remove}-cert > * build: Add missing dependency on libxmlrpc{,_util} > * ipaclient: schema cache: Handle malformed server info data gracefully > * schema_cache: Make handling of string compatible with python3 > * installer: Stop adding distro-specific NTP servers into ntp.conf > * tests: Expect krbpwdpolicyreference in result of > {host,service}-{find,show} --all > * password policy: Add explicit default password policy for hosts and > services > * ipaclient.plugins: Use api_version from internally called commands > * tests: Mark 389-ds acceptance tests > * tests: Mark Dogtag acceptance tests > * UnsafeIPAddress: Implement __(g|s)etstate__ and to ensure proper > (un)pickling > * schema cache: Store and check info for pre-schema servers > > === Florence Blanc-Renaud (20) === > * Installation must publish CA cert in /usr/share/ipa/html/ca.crt > * IdM Server: list all Employees with matching Smart Card > * ipa systemd unit should define Wants=network instead of Requires=network > * Support for Certificate Identity Mapping > * Define template version in certmap.conf > * Fix ipa.service unit re. gssproxy > * Do not configure PKI ajp redirection to use "::1" > * ipa-kra-install must create directory if it does not exist > * ipa-restore must stop tracking PKINIT cert in the preparation phase > * Increase the timeout waiting for certificate issuance in installer > * Check the result of cert request in replica installer > * Fix ipa-replica-install when upgrade from ca-less to ca-full > * Fix ipa migrate-ds when it finds a search reference > * Fix renewal lock issues on installation > * Refactor installer code requesting certificates > * Use autobind instead of host keytab authentication in > dogtag-ipa-ca-renew-agent > * Fix ipa-cacert-manage man page > * Add cert checks in ipa-server-certinstall > * Fix regression introduced in ipa-certupdate > * Fix ipa-certupdate for CA-less installation > > === Fraser Tweedale (52) === > * rabase.get_certificate: make serial number arg mandatory > * Extract method to map principal to princpal type > * Remove redundant principal_type argument > * dogtag: remove redundant property definition > * ca: correctly authorise ca-del, ca-enable and ca-disable > * replica install: relax domain level check for promotion > * Fix reference before assignment > * private_ccache: yield ccache name > * Add sanity checks for use of --ca-subject and --subject-base > * Indicate that ca subject / subject base uses LDAP RDN order > * Allow full customisability of IPA CA subject DN > * Reuse self.api when executing ca_enabled_check > * dsinstance: extract function for writing certmap.conf > * ipa-ca-install: add missing --subject-base option > * Extract function for computing default subject base > * installer: rename --subject to --subject-base > * installutils: remove hardcoded subject DN assumption > * Refactor and relocate set_subject_base_in_config > * dsinstance: minor string fixes > * Set up DS TLS on replica in CA-less topology > * Remove "Request Certificate with SubjectAltName" permission > * Fix DL1 replica installation in CA-less topology > * certprofile-mod: correctly authorise config update > * Fix regression in test suite > * Add options to write lightweight CA cert or chain to file > * certdb: accumulate extracted certs as list of PEMs > * Add function for extracting PEM certs from PKCS #7 > * cert-request: match names against principal aliases > * Remove references to ds_newinst.pl > * cert-request: accept CSRs with extraneous data > * Ensure correct IPA CA nickname in DS and HTTP NSSDBs > * Remove __main__ code from ipalib.x509 and ipalib.pkcs10 > * x509: use python-cryptography to process certs > * x509: use pyasn1-modules X.509 specs > * x509: avoid use of nss.data_to_hex > * pkcs10: remove pyasn1 PKCS #10 spec > * pkcs10: use python-cryptography for CSR processing > * dn: support conversion from python-cryptography Name > * cert-show: show validity in default output > * Do not create Object Signing certificate > * Add commentary about CA deletion to plugin doc > * spec: require Dogtag >= 10.3.5-6 > * sudorule: add SELinux transition examples to plugin doc > * Fix cert revocation when removing all certs via host/service-mod > * cert-request: raise error when request fails > * Make host/service cert revocation aware of lightweight CAs > * cert-request: raise CertificateOperationError if CA disabled > * Use Dogtag REST API for certificate requests > * Add HTTPRequestError class > * Allow Dogtag RestClient to perform requests without logging in > * Add ca-disable and ca-enable commands > * Track lightweight CAs on replica installation > > === Ganna Kaihorodova (7) === > * Tests: Basic coverage with tree root domain > * User Tracker: Test to create user with minimal values > * User Tracker: creation of user with minimal values > * Stage User: Test to create stage user with minimal values > * Tests: Stage User Tracker implementation > * Tests: Add tree root domain role in legacy client tests > * Unaccessible variable self.attrs in Tracker > > === Jan Cholasta (106) === > * spec file: always provide python package aliases > * spec file: support client-only build > * spec file: support build without ipatests > * slapi plugins: fix CFLAGS > * spec file: add unconditional python-setuptools BuildRequires > * httpinstance: disable system trust module in /etc/httpd/alias > * csrgen: hide cert-get-requestdata in CLI > * cert: include certificate chain in cert command output > * cert: add output file option to cert-request > * Travis CI: run tests in development mode > * backend plugins: fix crashes in development mode > * vault: cache the transport certificate on client > * rpc: fix crash in verbose mode > * install: re-introduce option groups > * install CLI: remove magic option groups > * client install: split off SSSD options into a separate class > * server install: remove duplicate knob definitions > * install: add missing space in realm_name description > * server install: remove duplicate -w option > * certmap: load certificate from file in certmap-match CLI > * pylint_plugins: add forbidden import checker > * ipapython: fix DEFAULT_PLUGINS in version.py > * config: re-add `init_config` and `config` > * dns: fix `dnsrecord_add` interactive mode > * server install: do not attempt to issue PKINIT cert in CA-less > * compat: fix `Any` params in `batch` and `dnsrecord` > * scripts, tests: explicitly set confdir in the rest of server code > * server upgrade: uninstall ipa_memcached properly > * server upgrade: always upgrade KRA agent PEM file > * server upgrade: fix upgrade from pre-4.0 > * server upgrade: fix upgrade in CA-less > * client install: create /etc/ipa/nssdb with correct mode > * ipaldap: preserve order of values in LDAPEntry._sync() > * replica install: do not log host OTP > * tests: add test for PEM certificate files with leading text > * ipa-ca-install: do not fail without --subject-base and --ca-subject > * cert: fix search limit handling in cert-find > * dogtag: search past the first 100 certificates > * ipaldap: properly escape raw binary values in LDAP filters > * client install: correctly report all failures > * cainstance: do not configure renewal guard > * dogtaginstance: track server certificate with our renew agent > * renew agent: handle non-replicated certificates > * ca: fix ca-find with --pkey-only > * spec file: revert to the previous Release tag > * x509: use PyASN1 to parse PKCS#7 > * server install: fix KRA agent PEM file not being created > * spec file: do not define with_lint inside a comment > * certdb: fix PKCS#12 import with empty password > * server install: fix external CA install > * replica install: track the RA agent certificate again > * ipaclient: remove hard dependency on ipaplatform > * ipaclient: move install modules to the install subpackage > * ipalib: remove hard dependency on ipapython > * constants: remove CACERT > * ipalib: move certstore to the install subpackage > * ipapython: remove hard dependency on ipaplatform > * ipautil: move file encryption functions to installutils > * ipautil: move kinit functions to ipalib.install > * ipautil: move is_fips_enabled() to ipaplatform.tasks > * ipautil: remove the timeout argument of run() > * ipautil: remove get_domain_name() > * ipautil: remove SHARE_DIR and PLUGIN_SHARE_DIR > * certdb: use a temporary file to pass password to pk12util > * certdb: move IPA NSS DB install functions to ipaclient.install > * ipapython: move certmonger and sysrestore to ipalib.install > * ipapython: move dnssec, p11helper and secrets to ipaserver > * custodiainstance: automatic restart on config file update > * paths: remove DEV_NULL > * install: migrate client install to the new class hierarchy > * install: allow specifying verbosity and console log format in CLI > * install: migrate server installers to the new class hierarchy > * install: introduce installer class hierarchy > * install: fix subclassing of knob groups > * install: make knob base declaration explicit > * install: declare knob CLI names using the argparse convention > * install: use standard Python classes to declare knob types > * install: introduce updated knob constructor > * install: simplify CLI option parsing > * install: improve CLI positional argument handling > * install: use ldaps for pkispawn in ipa-ca-install > * replica install: fix DS restart failure during replica promotion > * replica install: merge KRA agent cert export into KRA install > * replica install: merge RA cert import into CA install > * server install: do not restart httpd during CA install > * install: merge all KRA install code paths into one > * install: merge all CA install code paths into one > * replica install: use one remote KRA host name everywhere > * replica install: use one remote CA host name everywhere > * spec file: bump minimal required version of 389-ds-base > * pwpolicy: do not run klist on import > * client: remove unused libcurl build dependency > * makeapi, makeaci: do not fail on missing imports > * ipaserver: remove ipalib import from setup.py > * pylint: enable the import-error check > * spec file: do not include BuildRequires for lint by default > * spec file: clean up BuildRequires > * cert: add revocation reason back to cert-find output > * test_plugable: update the rest of test_init > * dns: re-introduce --raw in dnsrecord-del > * client: remove hard dependency on pam_krb5 > * cert: fix cert-find --certificate when the cert is not in LDAP > * dns: fix crash in interactive mode against old servers > * dns: prompt for missing record parts in CLI > * dns: normalize record type read interactively in dnsrecord_add > * cli: use full name when executing a command > > === Lenka Doudova (23) === > * Document make_delete_command method in UserTracker > * Tests: Providing trust tests with tree root domain > * Tests: Verify that validity info is present in cert-show and cert-find > command > * Add file_exists method as a member of transport object > * Tests: Provide AD cleanup for legacy client tests > * Tests: Provide AD cleanup for trust tests > * Tests: Fix integration sudo test > * Tests: Verify that cert commands show CA without --all > * Tests: Certificate revocation > * Tests: Remove invalid certplugin tests > * Tests: Fix failing test_ipalib/test_parameters > * Tests: Remove silent deleting and creating entries by tracker > * Tests: Remove usage of krb5 ccache from test_ipaserver/test_ldap > * Tests: Fix host attributes in ipa-join host test > * Tests: Update host test with ipa-join > * Tests: Add krb5kdc.service restart to integration trust tests > * Tests: Remove unnecessary attributes from base tracker > * Tests: Remove --force options from tracker base class > * Tests: Remove SSSD restart from integration tests > * Tests: Fix integration sudo tests setup and checks > * Tests: Fix failing ldap.backend test > * Tests: Add cleanup to integration trust tests > * Tests: Fix regex errors in integration trust tests > > === Ludwig Krispenz (1) === > * Check for conflict entries before raising domain level > > === Lukas Slebodnik (6) === > * CONFIGURE: Improve detection of xmlrpc_c flags > * CONFIGURE: Properly detect libpopt on el7 > * ipa_pwd: remove unnecessary dependency on dirsrv plugins > * SPEC: Fix build in mock > * CONFIGURE: Update help message for jslint > * CONFIGURE: Fix detection of pylint > > === Martin Babinsky (113) === > * Try out anonymous PKINIT after it is configured > * check for replica's KDC entry on master before requesting PKINIT cert > * check that the master requesting PKINIT cert has KDC enabled > * Make wait_for_entry raise exceptions > * Move PKINIT configuration to a later stage of server/replica install > * Request PKINIT cert directly from Dogtag API on first master > * Make PKINIT certificate request logic consistent with other installers > * idviews: correctly handle modification of non-existent view > * Re-use trust domain retrieval code in certmap validators > * idview: add domain_resolution_order attribute > * ipaconfig: add the ability to manipulate domain resolution order > * Short name resolution: introduce the required schema > * ipa-managed-entries: only permit running the command on IPA master > * ipa-managed-entries: use server-mode API > * Allow login to WebUI using Kerberos aliases/enterprise principals > * Provide basic integration tests for built-in AD trust installer > * Update server/replica installer man pages > * Fix erroneous short name options in ipa-adtrust-install man page > * Merge AD trust configurator into replica installer > * Merge AD trust configurator into server installer > * expose AD trust related knobs in composite installers > * Add AD trust installer interface for composite installer > * check for installed dependencies when *not* in standalone mode > * print the installation info only in standalone mode > * adtrust.py: Use logging to emit error messages > * Refactor the code searching and presenting missing trust agents > * only check for netbios name when LDAP backend is connected > * Refactor the code checking for missing SIDs > * use the methods of the parent class to retrieve CIFS kerberos keys > * httpinstance: re-use parent's methods to retrieve anonymous keytab > * Make request_service_keytab into a public method > * allow for more flexibility when requesting service keytab > * Move AD trust installation code to a separate module > * Replace exit() calls with exceptions > * Remove unused variables in exception handling > * ipa-adtrust-install: format the code for PEP-8 compliance > * Travis CI: Upload the logs from failed jobs to transfer.sh > * Explicitly handle quoting/unquoting of NSSNickname directive > * Delegate directive value quoting/unquoting to separate functions > * installutils: improve directive value parsing in `get_directive` > * Fix the installutils.set_directive docstring > * disable hostname canonicalization by Kerberos library > * Travis CI: actually return non-zero exit status when the test job fails > * Trim the test runner log to show only pytest failures/errors > * Add license headers to the files used by Travis CI > * Travis CI: use specific Python version during build > * introduce install step to .travis.yml and cache pip installs > * split out lint to a separate Travis job > * Travis: offload test execution to a separate script > * Travis CI: a separate script to run test tasks > * Put the commands informing and displaying build logs on single line > * travis: mark FreeIPA as python project > * Bump up ipa-docker-test-runner version > * Add a basic test suite for `kadmin.local` interface > * Make `kadmin` family of functions return the result of ipautil.run > * gracefully handle setting replica bind dn group on old masters > * add missing attribute to ipaca replica during CA topology update > * Revert "upgrade: add replica bind DN group check interval to CA > topology config" > * bindinstance: use data in named.conf to determine configuration status > * Use ipa-docker-test-runner to run tests in Travis CI > * Configuration file for ipa-docker-test-runner > * Add 'env_confdir' to constants > * Fix pep-8 transgressions in ipalib/misc.py > * Make `env` and `plugins` commands local again > * Revert "Add 'ipa localenv' subcommand" > * Enhance __repr__ method of Principal > * replication: ensure bind DN group check interval is set on replica config > * upgrade: add replica bind DN group check interval to CA topology config > * Improve the robustness FreeIPA's i18n module and its tests > * Use common procedure to setup initial replication in both domain levels > * ensure that the initial sync using GSSAPI works agains old masters > * replication: refactor the code setting principals as replica bind DNs > * replication: augment setup_promote_replication method > * Turn replication manager group into ReplicationManager class member > * Fix the naming of ipa-dnskeysyncd service principal > * installutils: remove 'install_service_keytab' function > * domain-level agnostic keytab retrieval in httpinstance > * installers: restart DS after KDC is configured > * dsinstance: use keytab retrieval method from parent class > * use DM credentials to retrieve service keytab only in DLO > * Service: common method for service keytab requests > * Turn Kerberos-related properties to Service class members > * Make service user name a class member of Service > * service installers: clean up the inheritance > * fix incorrect invocation of ipa-getkeytab during DL0 host enrollment > * do partial host enrollment in domain level 0 replica install > * Separate function to purge IPA host principals from keytab > * certs: do not re-create NSS database when requesting service cert > * initialize empty /etc/http/alias during server/replica install > * CertDB: add API for non-destructive initialization from PKCS#12 bundle > * test_ipagetkeytab: use system-wide IPA CA cert location in tests > * Extend keytab retrieval test suite to cover new options > * Modernize ipa-getkeytab test suite > * extend ipa-getkeytab to support other LDAP bind methods > * ipa-getkeytab: expose CA cert path as option > * server-del: fix incorrect check for one IPA master > * Revert "Fix install scripts debugging" > * do not use keys() method when iterating through dictionaries > * remove trailing newlines form python modules > * mod_nss: use more robust quoting of NSSNickname directive > * Move character escaping function to ipautil > * Make Continuous installer continuous only during execution phase > * use separate exception handlers for executors and validators > * ipa passwd: use correct normalizer for user principals > * trust-fetch-domains: contact forest DCs when fetching trust domain info > * netgroup: avoid extraneous LDAP search when retrieving primary key from > DN > * advise: Use `name` instead of `__name__` to get plugin names > * Use Travis-CI for basic sanity checks > * ldapupdate: Use proper inheritance in BadSyntax exception > * raise ValidationError when deprecated param is passed to command > * Always fetch forest info from root DCs when establishing one-way trust > * factor out `populate_remote_domain` method into module-level function > * Always fetch forest info from root DCs when establishing two-way trust > > === Martin Basti (134) === > * Become IPA 4.5.0 > * Update 4.5 translations > * Add copy-schema-to-ca for RHEL6 to contrib/ > * Remove copy-schema-to-ca.py from master branch > * pylint: bump dependency to version >= 1.6 > * backup: backup anonymous keytab > * tests: use --setup-kra in tests > * KRA: add --setup-kra to ipa-server-install > * man: add missing --setup-adtrust option to manpage > * ipactl restart: log httplib failues as debug > * Tests: search for disabled users > * Test: DNS nsupdate from dns-update-system-records > * DNS: dns-update-system-record can create nsupdate file > * py3: ipa_generate_password: do not compare None and Int > * py3: change_admin_password: use textual mode > * py3: create DNS zonefile: use textual mode > * py3: upgradeinstance: use bytes literals with LDIF operations > * py3: upgradeinstance: decode data before storing them as backup... > * py3: upgradeinstance: open dse.ldif in textual mode > * custodia: kem.set_keys: replace too-broad exception > * py3: kem.py: user bytes with ldap values > * py3: custodia: basedn must be unicode > * py3: configparser: use raw keyword > * py3: modify_s: attribute name must be str not bytes > * py3: ldapupdate: fix logging str(bytes) issue > * DNSSEC: forwarders validation improvement > * py3: test_ipaserver: fix BytesWarnings > * py3: get_memberofindirect: fix ByteWarnings > * py3: DN: fix BytesWarning > * Tests: fix wait_for_replication task > * py3: send Decimal number as string instead of base64 encoded value > * py3: ipaldap: properly encode DNSName to bytes > * py3: _convert_to_idna: fix bytes/unicode mistmatch > * py3: DNS: get_record_entry_attrs: do not modify dict during iteration > * py3: _ptrrecord_precallaback: use bytes with labels > * py3: remove_entry_from_group: attribute name must be string > * py3: base64 encoding/decoding returns always bytes don't mix it > * pki-base: use pki-base-python2 as dependency > * pki: add missing depedency pki-base[-python3] > * py3: x509.py: return principal as unicode string > * py3: tests_xmlrpc: do not call str() on bytes > * py3: normalize_certificate: support both bytes and unicode > * py3: strip_header: support both bytes and unicode > * py3: fingerprint_hex_sha256: fix encoding/decoding > * py3: fix CSR encoding inside framework > * Principal: validate type of input parameter > * Use dict comprehension > * py3: can_read: attributelevelrights is already string > * py3: get_effective_rights: values passed to ldap must be bytes > * py3: ipaldap: update encode/decode methods > * py3: rpcserver fix undefined variable > * py3: WSGI executioners must return bytes in list > * py3: session: fix r/w ccache data > * Py3: Fix undefined variable > * py3: rpcserver: decode input because json requires string > * py3: session.py decode server name to str > * Use proper logging for error messages > * wait_for_entry: use only DN as parameter > * py3: decode bytes for json.loads() > * dogtag.py: fix exception logging of JSON data > * py3: convert_attribute_members: don't use bytes as parameter for DN > * py3: make_filter_from_attr: use string instead of bytes > * py3: __add_acl: use standard ipaldap methods > * py3: add_entry_to_group: attribute name must be string not bytes > * py3: HTTPResponse has no 'dict' attribute in 'msg' > * py3: _httplib_request: don't convert string to bytes > * py3: cainstance: replace mkstemp with NamedTemporaryFile > * py3: write CA/KRA config into file opened in text mode > * py3: CA/KRA: config parser requires string > * py3: ipautil: open tempfiles in text mode > * py3: ldap modlist must have keys as string, not bytes > * py3: open temporary ldif file in text mode > * py3: service.py: replace mkstemp by NamedTemporaryFile > * py3: create_cert_db: write to file in a compatible way > * _resolve_records: fix assert, nameserver_ip can be none > * Remove duplicated step from DS install > * py3: enable py3 pylint > * Py3: Fix ToASCII method > * fix: regression in API version comparison > * ipactl: pass api as argument to services > * DNS: URI records: bump python-dns requirements > * remove Knob function > * KRA: don't add KRA container when KRA replica > * Zanata: exlude testing ipa.pot file > * client: use correct code for failed uninstall > * client: use exceptions instead of return states > * client: move install part to else branch > * client: move install cleanup from ipa-client-install to module > * client: move clean CCACHE to module > * client: fix script execution > * client: Remove useless except in ipa-client-install > * client: move custom env variable into client module > * client: extract checks from uninstall to uninstall_check > * client: extract checks from install to install_check > * client: move checks to client.install_check > * client: make statestore and fstore consistent with server > * IPAChangeConf: use constant for empty line > * client: import IPAChangeConf directly instead the module > * client: remove extra return from hardcode_ldap_server > * client: install function: return constant not hardcoded number > * client: remove unneded return from configure_ipa_conf > * client: remove unneded return configure_krb5_conf > * ipa-client-install: move client install to module > * CI: Disable KRA install tests on DL0 > * CI: use --setup-kra with replica installation > * CI: extend replication layouts tests with KRA > * CI: workaround: wait for dogtag before replica-prepare > * Pylint: fix the rest of unused local variables > * Pylint: remove unused variables in tests > * Pylint: remove unused variables in ipaserver package > * Pylint: remove unused variables from installers and scripts > * Fix: find OSCP certificate test > * Pylint: enable check for unused-variables > * Remove unused variables in tests > * Remove unused variables in the code > * test_text: add test ipa.pot file for tests > * Pylint: enable global-variable-not-assigned check > * Pylint: enable cyclic-import check > * Test: dont use global variable for iteration in test_cert_plugin > * Use constant for user and group patterns > * Fix regexp patterns in parameters to not enforce length > * Add check for IP addresses into DNS installer > * Fix missing config.ips in promote_check > * Abstract procedures for IP address warnings > * Catch DNS exceptions during emptyzones named.conf upgrade > * Start named during configuration upgrade. > * Tests: extend DNS cmdline tests with lowercased record type > * Show warning when net/broadcast IP address is used in installer > * Allow multicast addresses in A/AAAA records > * Allow broadcast ip addresses > * Allow network ip addresses > * Fix parse errors with link-local addresses > * Fix ScriptError to always return string from __str__ > * Bump master IPA devel version to 4.4.90 > > === Martin Kosek (1) === > * Update Contributors.txt > > === Milan Kub?k (4) === > * ipatests: Fix assert_deepequal outside of pytest process > * ipatests: Implement tests with CSRs requesting SAN > * ipatests: Fix name property on a service tracker > * ipatests: provide context manager for keytab usage in RPC tests > > === Michal Reznik (1) === > * test_csrgen: adjusted comparison test scripts for CSRGenerator > > === Michal ?idek (1) === > * git: Add commit template > > === Nathaniel McCallum (3) === > * Migrate OTP import script to python-cryptography > * Use RemoveOnStop to cleanup systemd sockets > * Properly handle LDAP socket closures in ipa-otpd > > === Oleg Fayans (45) === > * Test: uniqueness of certificate renewal master > * Test: basic kerberos over http functionality > * Test: made kinit_admin a returning function > * tests: Added basic tests for certs in idoverrides > * Created idview tracker > * Test for installing rules with service principals > * Test: integration tests for certs in idoverrides feature > * Added interface to certutil > * Automated ipa-replica-manage del tests > * tests: Automated clean-ruv subcommand tests > * Reverted the essertion for replica uninstall returncode > * Test: disabled wrong client domain tests for domlevel 0 > * tests: Fixed code styling in caless tests to make pep8 happy > * tests: Reverted erroneous asserts in 4 tests > * tests: fixed certinstall method > * tests: fixed super method invocation > * tests: added verbose assert to test_service_disable_doesnt_revoke > * tests: Standardized replica_preparation in test_no_certs > * tests: Implemented check for domainlevel before installation verification > * tests: Fixed Usage of improper certs in ca-less tests > * tests: fixed expects of incorrect error messages > * tests: Replaced unused setUp method with install > * tests: Replaced hardcoded certutil with imported from paths > * tests: Enabled negative testing for cleaning replication agreements > * tests: Made unapply_fixes call optional at master uninstallation > * tests: Updated master and replica installation methods to enable > negative testing > * tests: Added necessary xfails > * tests: Added necessary getkeytabs calls to fixtures > * tests: Removed outdated command options test > * tests: Applied correct teardown methods > * tests: Fixed incorrect assert in verify_installation > * tests: Adapted installation methods to utilize methods from tasks > * tests: Removed call for install method from parent class > * tests: Added teardown methods for server and replica installation > * tests: Create a method that cleans all ipa certs > * tests: Updated ipa server installation stdin text > * tests: Added generation of missing certs > * tests: Added basic constraints extension to the CA certs > * tests: Fixed method failures during second call for the method > * Xfailed a test that fails due to 6250 > * Fixed segment naming in topology tests > * Xfailed the tests due to a known bug with replica preparation > * Changed addressing to the client hosts to be replicas > * Several fixes in replica_promotion tests > * Removed incorrect check for returncode > > === Petr ?ech (1) === > * ipatests: nested netgroups (intg) > > === Petr Spacek (126) === > * ipa_generate_password algorithm change > * Remove named-pkcs11 workarounds from DNSSEC tests. > * Build: forbid builds in working directories containing white spaces > * Build: always use Pylint from Python version used for rest of the build > * Build: specify BuildRequires for Python 3 pylint > * Build: makerpms.sh generates Python 2 & 3 packages at the same time > * Accept server host names resolvable only using /etc/hosts > * Build: properly integrate ipa.pot into build system tests > * Build: properly integrate ipasetup.py into build system > * Build: properly integrate version.py into build system > * Build: properly integrate loader.js into build system > * Build: properly integrate freeipa.spec.in into build system > * Build: properly integrate ipa-version.h.in into build system > * Build: workaround bug while calling parallel make from rpmbuild > * Build: remove ipa.pot from Git as it can be re-generated at any time > * Build: integrate translation system tests again > * Build: automatically generate list of files to be translated in configure > * Build: clean in po/ removes *~ files as well > * Build: support strip-po target for translations > * Build: use standard infrastructure for translations > * Build: fix path in ipa-ods-exporter.socket unit file > * Build: fix file dependencies for make-css.sh > * Build: update makerpms.sh to use same paths as rpmbuild > * Build: remove incorrect use of MAINTAINERCLEANFILES > * Build: enable silent build in makerpms.sh > * Build: support --enable-silent-rules for Python packages > * Build: workaround bug 1005235 related to Python paths in > auto-generated Requires > * Build: document what should be in %install section of SPEC file > * Build: move web UI file installation from SPEC to Makefile.am > * Build: move server directory handling from SPEC to Makefile.am > * Build: move client directory handling from SPEC to Makefile.am > * Update man page for ipa-adtrust-install by removing --no-msdcs option > * Build: pass down %{release} from SPEC to configure > * Build: update IPA_VERSION_IS_GIT_SNAPSHOT to comply with PEP440 > * Build: add make srpms target > * Build: IPA_VERSION_IS_GIT_SNAPSHOT re-generates version number on RPM > build > * Build: use POSIX 1003.1-1988 (ustar) file format for tar archives > * Build: IPA_VERSION_IS_GIT_SNAPSHOT checks if source directory is Git repo > * Build: remove unused and redundant code from configure.ac and > po/Makefile.in > * Build: fix make clean to remove build artifacts from top-level directory > * Build: fix make clean for web UI > * Build: add polint target for i18n tests > * Build: add makeapi lint target > * Build: add makeaci lint target > * Build: add JS lint target > * Build: add Python lint target > * Build: remove obsolete instructions about BuildRequires from BUILD.txt > * Build: add make rpms target and convenience script makerpms.sh > * Build: fix KDC proxy installation and remove unused kdcproxy.conf > * Build: remove unused dirs /var/cache/ipa/{sysupgrade,sysrestore} from > SPEC > * Build: do not compress manual pages at install time > * Build: distribute doc directory > * Build: create /var/run directories at install time > * Build: integrate init and init/systemd into build system > * Build: remove init/SystemV directory > * Build: integrate contrib directory into build system > * Build: remove ancient checks/check-ra.py > * Build: integrate daemons/dnssec into build system > * Build: fix distribution of daemons/ipa-slapi-plugins/topology files > * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-winsync files > * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-sidgen files > * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-pwd-extop files > * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-otp-lasttoken > files > * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-otp-counter > files > * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-exdom-extop > files > * Build: fix distribution of daemons/ipa-slapi-plugins/ipa-cldap files > * Build: fix distribution of ipa-slapi-plugins/common files > * Build: fix distribution of daemon/ipa-kdb files > * Build: fix distribution of client header file > * Build: fix distribution of asn1/asn1c files > * Build: fix distribution of install/REDME.schema file > * Build: fix distribution of oddjob files > * Build: Remove spurious EXTRA_DIST from install/share/Makefile.am > * Build: cleanup unused LDIFs from install/share > * Build: fix distribution of libexec scripts > * Build: fix distribution and installation of update LDIFs > * Web UI: Remove offline version of Web UI > * Build: fix distribution of static files for web UI > * Build: stop build when a step in web UI build fails > * Build: fix distribution and installation of static files in top-level > directory > * Build: fix man page distribution > * Build: fix distdir target for translations > * Build: rename project from ipa-server to freeipa > * Build: remove non-existing README files from Makefile.am > * Build: fix Makefile.am files to separate source and build directories > * Build: respect --prefix for systemdsystemunitdir > * Build: fix make install in asn1 subdirectory > * Build: fix ipaplatform detection for out-of-tree builds > * Build: Makefiles for Python packages > * Build: fix module name in ipaserver/setup.py > * Build: replace hand-made Makefile with one generated by Automake > * Build: move version handling from Makefile to configure > * Docs: update docs about ipaplatform to match reality > * Build: replace ipaplatform magic with symlinks generated by configure > * Build docs: update platform selection instructions > * Build: split out egg-info Makefile target from version-update target > * Build: split API/ACI checks into separate Makefile targets > * Build: use default error handling for PKG_CHECK_MODULES > * Build: use libutil convenience library for client > * Build: cleanup INI library detection > * Build: modernize XMLRPC-client library detection > * Build: modernize CURL library detection > * Build: modernize SASL library detection > * Build: modernize POPT library detection > * Build: merge client/configure.ac into top-level configure.ac > * Build: remove Transifex support > * Build: move translations from install/po/ to top-level po/ > * Build: merge install/configure.ac into top-level configure.ac > * Build: merge ipatests/man/configure.ac to top-level configure.ac > * Build: merge asn1/configure.ac to top-level configure.ac > * Build: transform util directory to libutil convenience library > * Build: promote daemons/configure.ac to top-level configure.ac > * Build: adjust include paths in daemons/ipa-kdb/tests/ipa_kdb_tests.c > * Build: pass down LIBDIR definition from RPM SPEC to Makefile > * Build: remove deprecated AC_STDC_HEADERS macro > * Build: require Python >= 2.7 > * Build: remove traces of mozldap library > * Build: modernize crypto library detection > * Build: modernize UUID library detection > * Build: modernize Kerberos library detection > * Build: add missing KRB5_LIBS to daemons/ipa-otpd > * Tests: print what was expected from callables in xmlrpc_tests > * DNS: Improve field descriptions for SRV records > * DNS: Support URI resource record type > * Fix compatibility with python-dns 1.15.0 > * Raise errors from service.py:_ldap_mod() by default > > === Petr Vobornik (6) === > * permissions: add permissions for read and mod of external group members > * webui: do not warn about CAs if there is only one master > * webui: fixes normalization of value in attributes widget > * Change README to use Markdown > * Raise errors.EnvironmentError if IPA_CONFDIR var is incorrectly used > * replicainstall: log ACI and LDAP errors in promotion check > > === Pavel Vomacka (69) === > * Remove allow_constrained_delegation from gssproxy.conf > * WebUI: Add support for management of user short name resolution > * WebUI: add link to login page which for login using certificate > * Support certificate login after installation and upgrade > * TESTS WebUI: Vaults management > * TESTS: Add support for sidebar with facets > * TESTS: Add support for KRA in ui_driver > * WebUI: add vault management > * WebUI: allow to show rows with same pkey in tables > * WebUI: search facet's default actions might be overriden > * Add possibility to hide only one tab in sidebar > * Possibility to set list of table attributes which will be added to > _del command > * Extend _show command after _find command in table facets > * Add possibility to pass url parameter to update command of details page > * Add property which allows refresh command to use url value > * Added optional option in refreshing after modifying association table > * Possibility to skip checking writable according to metadata > * Allow to set another other_entity name > * Additional option to add and del operations can be set > * WebUI: Add cermapmatch module > * WebUI: Add Adapter for certmap_match result table > * WebUI: Possibility to choose object when API call returns list of objects > * WebUI: Add possibility to turn of autoload when details.load is called > * WebUI: don't change casing of Auth Indicators values > * WebUI: Allow disabling lowering text in custom_checkbox_widget > * Add support for custom table pagination size > * Make singleton from config module > * Add javascript integer validator > * WebUI: Add certmap module > * WebUI: Add Custom command multivalued adder dialog > * WebUI: Create non editable row widget for mutlivalued widget > * WebUI: Add possibility to set field always writable > * WebUI: Change structure of Identity submenu > * WebUI: add sizelimit:0 to cert-find > * WebUI: fix incorrect behavior of ESC button on combobox > * WebUI: add default on_cancel function in adder_dialog > * Coverity: removed useless semicolon which ends statement earlier > * Coverity: Fix possibility of access to attribute of undefined > * Change activity text while loading metadata > * Refactoring of rpc module > * WebUI: update Patternfly and Bootstrap > * WebUI: Hide incorrectly shown buttons on hosts tab in ID Views > * Lowered the version of gettext > * Add python-pyasn1-modules into dependencies > * Adjustments for setup requirements v2 > * TESTS: Update group type name > * Coverity - null pointer dereference > * Coverity - accessing attribute of variable which can point to null > * Coverity - opens dialog which might not be created > * Coverity - iterating over variable which could be null > * Coverity - null pointer dereference > * Coverity - true branch can't be executed > * Coverity - true branch can't be executed > * Coverity - removed dead code > * Coverity - Accesing attribute of null > * Coverity - identical code for different branches > * Coverity - not initialized variable > * Coverity - null pointer exception > * Coverity - null pointer exception > * WebUI: services without canonical name are shown correctly > * WebUI: fix API Browser menu label > * Add tooltip to all fields in DNS record adder dialog > * WebUI: hide buttons in certificate widget according to acl > * WebUI: Change group name from 'normal' to 'Non-POSIX' > * WebUI: Add handling for HTTP error 404 > * Add 'Restore' option to action dropdown menu > * WebUI add support for sub-CAs while revoking certificates > * WebUI: Fix showing certificates issued by sub-CA > * Add support for additional options taken from table facet > > === Gabe (1) === > * Allow nsaccountlock to be searched in user-find command > > === Simo Sorce (31) === > * Store session cookie in a ccache option > * Add support for searching policies in cn=accounts > * Add code to retrieve results from multiple bases > * Use GSS-SPNEGO if connecting locally > * Limit sessions to 30 minutes by default > * Remove non-sensical kdestroy on https stop > * Fix session logout > * Deduplicate session cookies in headers > * Change session logout to kill only the cookie > * Insure removal of session on identity change > * Explicitly pass down ccache names for connections > * Allow rpc callers to pass ccache and service names > * Fix uninstall stopping ipa.service > * Rationalize creation of RA and HTTPD NSS databases > * Add a new user to run the framework code > * Always use /etc/ipa/ca.crt as CA cert file > * Simplify NSSDatabase password file handling > * Separate RA cert store from the HTTP cert store > * Configure HTTPD to work via Gss-Proxy > * Use Anonymous user to obtain FAST armor ccache > * Drop use of kinit_as_http from trust code > * Generate tmpfiles config at install time > * Change session handling > * Use the tar Posix option for tarballs > * Add compatibility code to retrieve headers > * Configure Anonymous PKINIT on server install > * Properly handle multiple cookies in rpc lib. > * Properly handle multiple cookies in rpcclient > * Support DAL version 5 and version 6 > * Fix install scripts debugging > * Fix error message encoding > > === Stanislav Laznicka (78) === > * Remove pkinit from ipa-replica-prepare > * Backup KDC certificate pair > * Don't fail more if cert req/cert creation failed > * Fix ipa-replica-prepare server-cert creation > * Don't allow standalone KRA uninstalls > * Add message about last KRA to WebUI Topology view > * Add check to prevent removal of last KRA > * Don't use weak ciphers for client HTTPS connections > * We don't offer no quickies > * Fix cookie with Max-Age processing > * Fix CA-less upgrade > * Fix replica with --setup-ca issues > * Moving ipaCert from HTTPD_ALIAS_DIR > * Added a PEMFileHandler for Custodia store > * Refactor certmonger for OpenSSL certificates > * Workaround for certmonger's "Subject" representations > * Remove ipapython.nsslib as it is not used anymore > * Remove NSSConnection from otptoken plugin > * Remove pkcs12 handling functions from CertDB > * Remove NSSConnection from Dogtag > * Move publishing of CA cert to cainstance creation on master > * Don't run kra.configure_instance if not necessary > * Move RA agent certificate file export to a different location > * Remove NSSConnection from the Python RPC module > * Remove md5_fingerprints from IPA > * Remove DM password files after successfull pkispawn run > * Remove ra_db argument from CAInstance init > * Fix ipa-server-upgrade > * Use newer Certificate.serial_number in krainstance.py > * Fix error in ca_cert_files validator > * Don't prepend option names with additional '--' > * Bump python-cryptography version in ipasetup.py.in > * custodiainstance: don't use IPA-specific CertDB > * Add password to certutil calls in NSSDatabase > * Explicitly remove support of SSLv2/3 > * Add FIPS-token password of HTTPD NSS database > * Bump required python-cryptography version > * Remove is_fips_enabled checks in installers and ipactl > * Generate sha256 ssh pubkey fingerprints for hosts > * Unify password generation across FreeIPA > * Clarify meaning of --domain and --realm in installers > * replicainstall: give correct error message on DL mismatch > * Fix permission-find with sizelimit set > * Generalize filter generation in LDAPSearch > * permission-find: fix a sizelimit off-by-one bug > * fix permission_find fail on low search size limit > * Make get_entries() not ignore its limit arguments > * Do not log DM password in ca/kra installation logs > * Fix CA replica install on DL1 > * Offer more general way to check domain level in replicainstall > * Use same means of checking replication agreements on both DLs > * replicainstall: move common checks to common_check() > * Take advantage of the ca/kra code cleanup in replica installation > * Use updated CA certs in replica installation > * Use os.path.join instead of concatenation > * Remove redundant CA cert file existance check > * Use host keytab to connect to remote server on DL0 > * Split install_http_certs() into two functions > * First step of merging replica installation of both DLs > * Properly bootstrap replica promotion api > * Move the pki-tomcat restart to cainstance creation > * Move httpd restart to DNS installation > * Import just IPAChangeConf instead of the whole module > * Added file permissions option to IPAChangeConf.newConf() > * Fix to ipachangeconf docstrings > * replicainstall: Unify default.conf file creation > * Replaced EMPTY_LINE constant with a function call > * client: Making the configure functions more readable > * Moved update of DNA plugin among update plugins > * Move ds.replica_populate to an update plugin > * Remove redundant dsinstance restart > * Fix missing file that fails DL1 replica installation > * Make httpd publish its CA certificate on DL1 > * Make installer quit more nicely on external CA installation > * Fix test_util.test_assert_deepequal test > * Pretty-print structures in assert_deepequal > * Remove update_from_dict() method > * Updated help/man information about hostname > > === Thierry Bordaz (1) === > * IPA Allows Password Reuse with History value defined when admin resets > the password. > > === Timo Aaltonen (8) === > * ipaplatform/debian/paths: Add some missing values. > * ipaplatform/debian/paths: Rename IPA_KEYTAB to OLD_IPA_KEYTAB. > * ipaplatform/debian/paths: Add IPA_HTTPD_KDCPROXY. > * ipaplatform/debian/services: Fix is_running arguments. > * ipaplatform: Add Debian platform module. > * client, platform: Use paths.SSH* instead of get_config_dir(). > * Move ipa-otpd to $libexecdir/ipa > * Purge obsolete firefox extension > > === Tomas Krizek (68) === > * installer: update time estimates > * server install: require IPv6 stack to be enabled > * Add SHA256 fingerprints for certs > * man: update ipa-cacert-manage > * test_config: fix fips_mode key in Env > * Env __setitem__: replace assert with exception > * FIPS: perform replica installation check > * replicainstall: add context manager for rpc client > * check_remote_version: update exception and docstring > * test_config: fix tests for env.fips_mode > * Add fips_mode variable to env > * Bump required version of bind-dyndb-ldap to 11.0-2 > * bindinstance: fix named.conf parsing regexs > * PEP8: fix line length for regexs in bindinstance > * bump required version of BIND, bind-dyndb-ldap > * named.conf template: update API for bind 9.11 > * Remove obsolete serial_autoincrement from named.conf parsing > * certdb: remove unused valid_months property > * certdb: remove unused keysize property > * Fix coverity issue > * ipautil: check for open ports on all resolved IPs > * replica-conncheck: improve message logging > * replica-conncheck: improve error message during replicainstall > * ipa-replica-conncheck: fix race condition > * ipa-replica-conncheck: do not close listening ports until required > * upgrade: ldap conn management > * services: replace admin_conn with api.Backend.ldap2 > * upgrade: do not explicitly set principal for services > * Build: ignore rpmbuild for lint target > * cainstance: use correct certificate for replica install check > * dns: check if container exists using ldapi > * ipaldap: remove do_bind from LDAPClient > * gitignore: ignore tar ball > * libexec scripts: ldap conn management > * ldap2: modify arguments for create_connection > * replicainstall: use ldap_uri in ReplicationManager > * replicainstall: correct hostname in ReplicationManager > * install tools: ldap conn management > * ldap2: change default bind_dn > * ipa-adtrust-install: ldap conn management > * install: remove adhoc dis/connect from services > * ldapupdate: use ldapi in LDAPUpdate > * replicainstall: properly close adhoc connection in promote > * install: ldap conn management > * install: remove adhoc api.Backend.ldap2 (dis)connect > * install: add restart_dirsrv for directory server restarts > * upgradeinstance: ldap conn management > * dsinstance: conn management > * ldap2: change default time/size limit > * cainstall: add dm_password to CA installation > * replicainstall: set ldapi uri in replica promotion > * dsinstance: enable ldapi and autobind in ds > * install: remove dirman_pw from services > * ipaldap: merge IPAdmin to LDAPClient > * ipaldap: merge gssapi_bind to LDAPClient > * ipaldap: merge external_bind into LDAPClient > * ipaldap: merge simple_bind into LDAPClient > * ipaldap: remove wait/timeout during binds > * ipa: check if provided config file exists > * ipa: allow relative paths for config file > * Prompt for forwarder in dnsforwardzone-add > * Update man/help for --server option > * Update ipa-server-install man page for hostname > * Add help info about certificate revocation reasons > * Add log messages for IP checks during client install > * Show error message for invalid IPs in client install > * Keep NSS trust flags of existing certificates > * Don't show error messages in bash completion > > === Thorsten Scherf (2) === > * added ssl verification using IPA trust anchor > * added help about default value for --external-ca-type option > > === shanyin (1) === > * fix missing translation string > > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlosla1987 at gmail.com Wed Mar 15 19:11:05 2017 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Wed, 15 Mar 2017 15:11:05 -0400 Subject: [Freeipa-users] =?utf-8?q?Windows_Clients_can=C2=B4t_access_linux?= =?utf-8?q?_services_using_kerberos?= In-Reply-To: References: Message-ID: still trying to understand why windows clients do not pass the authentication on a kerberized proxy in a scheme where there is forests trust, I assumed that in a forests trust to cross-authentication between realms was established automatically, i am wrong about this ? i am using freeipa 4.4.3 and i can access to any linux host enrolled in IPA with my windows credentials, the sso work just fine from any linux host any idea what i am missing ? Thanks in advance 2017-03-15 3:18 GMT-04:00 Carlos Ra?l Laguna : > Hello everyone I need some help with this I have set up an IPA 4.4.3 > server and I have established a forest trust relationship with Active > Directory, everything looks good, after following this guide > http://www.freeipa.org/index. Php? Title = Squid_Integration_with_FreeIPA_using_Single_Sign_On > & redirect = no on linux clients has worked without problems but has not > been so on my windows clients, I have overlooked something? How do the > windows clients ticket should be register by the proxy? Thanks for your > help any inside will help me . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Mar 15 20:12:58 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 15 Mar 2017 21:12:58 +0100 Subject: [Freeipa-users] Announcing SSSD 1.15.2 Message-ID: <20170315201258.tqoio6n47ccakww3@hendrix> SSSD 1.15.2 =========== The SSSD team is proud to announce the release of version 1.15.2 of the System Security Services Daemon. The tarball can be downloaded from https://releases.pagure.org/SSSD/sssd/ RPM packages will be made available for Fedora shortly. Feedback -------- Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users Highlights ---------- * It is now possible to configure certain parameters of a trusted domain in a configuration file sub-section. In particular, it is now possible to configure which Active Directory DCs the SSSD talks to with a configuration like this:: [domain/ipa.test] # IPA domain configuration. This domain trusts a Windows domain win.test [domain/ipa.test/win.test] ad_server = dc.win.test * Several issues related to socket-activating the NSS service, especially if SSSD was configured to use a non-privileged userm were fixed. The NSS service now doesn't change the ownership of its log files to avoid triggering a name-service lookup while the NSS service is not running yet. Additionally, the NSS service is started before any other service to make sure username resolution works and the other service can resolve the SSSD user correctly. * A new option "cache_first" allows the administrator to change the way multiple domains are searched. When this option is enabled, SSSD will first try to "pin" the requested name or ID to a domain by searching the entries that are already cached and contact the domain that contains the cached entry first. Previously, SSSD would check the cache and the remote server for each domain. This option brings performance benefit for setups that use multiple domains (even auto-discovered trusted domains), especially for ID lookups that would previously iterate over all domains. Please note that this option must be enabled with care as the administrator must ensure that the ID space of domains does not overlap. * The SSSD D-Bus interface gained two new methods: "FindByNameAndCertificate" and "ListByCertificate". These methods will be used primarily by IPA and `mod_lookup_identity to correctly match multple users who use the same certificate for Smart Card login. * A bug where SSSD did not properly sanitize a username with a newline character in it was fixed. Packaging Changes ----------------- None in this release Documentation Changes --------------------- * A new option "cache_first" was added. Please see the Highlights section for more details * The "override_homedir" option supports a new template expansion "l" that expands to the first letter of username Tickets Fixed ------------- Please note that due to a bug in the pagure.io tracker, some tickets that have dependencies set to other tickets cannot be closed at the moment. * - Newline characters (\n) must be sanitized before LDAP requests take place * - sssd-secrets doesn't exit on idle * - sssd ignores entire groups from proxy provider if one member is listed twice * - when group is invalidated using sss_cache dataExpireTimestamp entry in the domain and timestamps cache are inconsistent * - [RFE] Add more flexible templating for override_homedir config option * - Make it possible to configure AD subdomain in the server mode * - chown in ExecStartPre of sssd-nss.service hangs forever * - Login time increases strongly if more than one domain is configured * - use the sss_parse_inp request in other responders than dbus Detailed Changelog ------------------ * Fabiano Fid?ncio (7): * RESPONDER: Wrap up the code to setup the idle timeout * SECRETS: Shutdown the responder in case it becomes idle * CACHE_REQ: Move cache_req_next_domain() into a new tevent request * CACHE_REQ: Check the caches first * NSS: Don't set SocketUser/SocketGroup as "sssd" in sssd-nss.socket * NSS: Ensure the NSS socket is started before any other services' sockets * NSS: Don't call chown on NSS service's ExecStartPre * Ignacio Reguero (1): * UTIL: first letter of user name template for override_homedir * Jakub Hrozek (9): * Updating the version for the 1.15.2 release * Allow manual start for sssd-ifp * NSS: Fix invalidating memory cache for subdomain users * UTIL: Add a new macro SAFEALIGN_MEMCPY_CHECK * UTIL: Add a generic iobuf module * BUILD: Detect libcurl during configure * UTIL: Add a libtevent libcurl wrapper * TESTS: test the curl wrapper with a command-line tool * Updating the translations for the 1.15.2 release * Justin Stephenson (1): * MAN: Add dyndns_auth option * Lukas Slebodnik (3): * test_secrets: Fail in child if sssd_secrets cannot start * test_utils: Add test coverage for %l in override_homedir * util-test: Extend unit test for sss_filter_sanitize_ex * Michal ?idek (4): * data_provider: Fix typo in DEBUG message * SUBDOMAINS: Configurable search bases * SUBDOMAINS: Allow options ad(_backup)_server * MAN: Add trusted domain section man entry * Pavel B?ezina (4): * cache_req: use rctx as memory context during midpoint refresh * CACHE_REQ: Make "cache_req_{create_and_,}add_result()" more generic * CACHE_REQ: Move result manipulation into a separate module * CACHE_REQ: shortcut if object is found * Petr ?ech (2): * sss_cache: User/groups invalidation in domain cache * PROXY: Remove duplicit users from group * Sumit Bose (7): * sysdb: allow multiple results for searches by certificate * cache_req: allow multiple matches for searches by certificate * ifp: add ListByCertificate * ifp: add FindByNameAndCertificate * PAM: allow muliple users mapped to a certificate * nss: ensure that SSS_NSS_GETNAMEBYCERT only returns a unique match * IPA: get overrides for all users found by certificate * Thorsten Scherf (1): * Fixed typo in debug output * Victor Tapia (1): * UTIL: Sanitize newline and carriage return characters. From dag at sonsorol.org Wed Mar 15 22:32:42 2017 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 15 Mar 2017 18:32:42 -0400 Subject: [Freeipa-users] replica install seems to hang forever when "--setup-ca" is enabled - any advice? Message-ID: <58C9C10A.2030106@sonsorol.org> Any tips for diving into this a bit more to troubleshoot? For the 1st time I'm setting up an ipa-server 4.4 replica with CA features enabled but the replica install seems to hang forever here: ... ... ... Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds [1/27]: creating certificate server user [2/27]: configuring certificate server instance [3/27]: stopping certificate server instance to update CS.cfg [4/27]: backing up CS.cfg [5/27]: disabling nonces [6/27]: set up CRL publishing [7/27]: enable PKIX certificate path discovery and validation [8/27]: starting certificate server instance < no output after this > The replica-install.log file ends here: ... ... ... 2017-03-15T22:16:05Z DEBUG Starting external process 2017-03-15T22:16:05Z DEBUG args=/bin/systemctl is-active pki-tomcatd at pki-tomcat.service 2017-03-15T22:16:05Z DEBUG Process finished, return code=0 2017-03-15T22:16:05Z DEBUG stdout=active 2017-03-15T22:16:05Z DEBUG stderr= 2017-03-15T22:16:05Z DEBUG wait_for_open_ports: localhost [8080, 8443] timeout 300 2017-03-15T22:16:06Z DEBUG Waiting until the CA is running 2017-03-15T22:16:06Z DEBUG request POST http://deawilidmp001.XXX.org:8080/ca/admin/ca/getStatus 2017-03-15T22:16:06Z DEBUG request body '' I've confirmed that SELINUX is disabled, there is no firewall and the AWS Security Groups are allowing TCP:8080 and TCP:8443 to the replica instance. The systemctl command also verifies that pki-tomcatd at pki-tomcat.service is "active" as well. Any tips for debugging further? Regards, Chris From ftweedal at redhat.com Thu Mar 16 00:34:22 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 16 Mar 2017 10:34:22 +1000 Subject: [Freeipa-users] replica install seems to hang forever when "--setup-ca" is enabled - any advice? In-Reply-To: <58C9C10A.2030106@sonsorol.org> References: <58C9C10A.2030106@sonsorol.org> Message-ID: <20170316003422.GS10261@dhcp-40-8.bne.redhat.com> On Wed, Mar 15, 2017 at 06:32:42PM -0400, Chris Dagdigian wrote: > > Any tips for diving into this a bit more to troubleshoot? > > For the 1st time I'm setting up an ipa-server 4.4 replica with CA features > enabled but the replica install seems to hang forever here: > > ... > ... > ... > Done configuring directory server (dirsrv). > Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 > seconds > [1/27]: creating certificate server user > [2/27]: configuring certificate server instance > [3/27]: stopping certificate server instance to update CS.cfg > [4/27]: backing up CS.cfg > [5/27]: disabling nonces > [6/27]: set up CRL publishing > [7/27]: enable PKIX certificate path discovery and validation > [8/27]: starting certificate server instance > > < no output after this > > > > The replica-install.log file ends here: > > ... > ... > ... > 2017-03-15T22:16:05Z DEBUG Starting external process > 2017-03-15T22:16:05Z DEBUG args=/bin/systemctl is-active > pki-tomcatd at pki-tomcat.service > 2017-03-15T22:16:05Z DEBUG Process finished, return code=0 > 2017-03-15T22:16:05Z DEBUG stdout=active > > 2017-03-15T22:16:05Z DEBUG stderr= > 2017-03-15T22:16:05Z DEBUG wait_for_open_ports: localhost [8080, 8443] > timeout 300 > 2017-03-15T22:16:06Z DEBUG Waiting until the CA is running > 2017-03-15T22:16:06Z DEBUG request POST > http://deawilidmp001.XXX.org:8080/ca/admin/ca/getStatus > 2017-03-15T22:16:06Z DEBUG request body '' > > > > > I've confirmed that SELINUX is disabled, there is no firewall and the AWS > Security Groups are allowing TCP:8080 and TCP:8443 to the replica instance. > The systemctl command also verifies that > pki-tomcatd at pki-tomcat.service is "active" as well. > > > Any tips for debugging further? > Could you please provide the /var/log/pki/pki-tomcat/ca/debug log file? Thanks, Fraser From datakid at gmail.com Thu Mar 16 00:36:57 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Thu, 16 Mar 2017 11:36:57 +1100 Subject: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1 Message-ID: I'm experiencing issues with HBAC and I think it's a bug in sssd. Not sure if better to report to here or sssd mailing list. Also sssd in pagure is bare and I didn't want to sully the blank slate. ( https://pagure.io/sssd/issues ) The details: env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR On the IPA server: - "ipa hbactest ..." returns TRUE, so everything seems set up correctly. When I try to login to the test client, I get denied. On the test client: - hbac_eval_user_element is returning a wrong value. This is seen in sssd_domain.log, it's returning 25. My test user is in 37 groups. This is seen on the IPA server via id username. On the test client id username returns 36 groups, the one missing is an IPA (not AD) group that was made for HBAC rules. I have sanitized logs available. - taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb '(objectclass=user)' and finding the record in question shows the same 36 groups available. The missing group shouldn't affect ability to login via HBAC - getent group (groupname) works as expected. Also worth noting that the group missing from id username shows that user in getent. For reference, on the client the sssd service was stopped, the cache deleted, and the service started again the night before after which the server wasn't accessed by anyone. I find that this is necessary for the cache to populate. Should I put in a bug report against SSSD or FreeIPA? While HBAC is in FreeIPA, I think that this is an issue in SSSD (specifically ? cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Mar 16 08:05:58 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 16 Mar 2017 09:05:58 +0100 Subject: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1 In-Reply-To: References: Message-ID: <20170316080558.z4yvuupcaetboa4z@hendrix> On Thu, Mar 16, 2017 at 11:36:57AM +1100, Lachlan Musicman wrote: > I'm experiencing issues with HBAC and I think it's a bug in sssd. Not sure > if better to report to here or sssd mailing list. Also sssd in pagure is > bare and I didn't want to sully the blank slate. ( > https://pagure.io/sssd/issues ) > > The details: > > env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR > > On the IPA server: > > - "ipa hbactest ..." returns TRUE, so everything seems set up correctly. > > > When I try to login to the test client, I get denied. > > On the test client: > > - hbac_eval_user_element is returning a wrong value. This is seen in > sssd_domain.log, it's returning 25. My test user is in 37 groups. This is > seen on the IPA server via id username. On the test client id username > returns 36 groups, the one missing is an IPA (not AD) group that was made > for HBAC rules. I have sanitized logs available. > > - taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb > '(objectclass=user)' and finding the record in question shows the same 36 > groups available. The missing group shouldn't affect ability to login via > HBAC > > - getent group (groupname) works as expected. Also worth noting that the > group missing from id username shows that user in getent. > > For reference, on the client the sssd service was stopped, the cache > deleted, and the service started again the night before after which the > server wasn't accessed by anyone. I find that this is necessary for the > cache to populate. > > Should I put in a bug report against SSSD or FreeIPA? > > While HBAC is in FreeIPA, I think that this is an issue in SSSD > (specifically ? Yes, SSSD. I remember you had some intermittent issues in the past, is this one reproducable? From mbasti at redhat.com Thu Mar 16 08:29:12 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 16 Mar 2017 09:29:12 +0100 Subject: [Freeipa-users] replica install seems to hang forever when "--setup-ca" is enabled - any advice? In-Reply-To: <20170316003422.GS10261@dhcp-40-8.bne.redhat.com> References: <58C9C10A.2030106@sonsorol.org> <20170316003422.GS10261@dhcp-40-8.bne.redhat.com> Message-ID: On 16.03.2017 01:34, Fraser Tweedale wrote: > On Wed, Mar 15, 2017 at 06:32:42PM -0400, Chris Dagdigian wrote: >> Any tips for diving into this a bit more to troubleshoot? >> >> For the 1st time I'm setting up an ipa-server 4.4 replica with CA features >> enabled but the replica install seems to hang forever here: >> >> ... >> ... >> ... >> Done configuring directory server (dirsrv). >> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 >> seconds >> [1/27]: creating certificate server user >> [2/27]: configuring certificate server instance >> [3/27]: stopping certificate server instance to update CS.cfg >> [4/27]: backing up CS.cfg >> [5/27]: disabling nonces >> [6/27]: set up CRL publishing >> [7/27]: enable PKIX certificate path discovery and validation >> [8/27]: starting certificate server instance >> >> < no output after this > >> >> >> The replica-install.log file ends here: >> >> ... >> ... >> ... >> 2017-03-15T22:16:05Z DEBUG Starting external process >> 2017-03-15T22:16:05Z DEBUG args=/bin/systemctl is-active >> pki-tomcatd at pki-tomcat.service >> 2017-03-15T22:16:05Z DEBUG Process finished, return code=0 >> 2017-03-15T22:16:05Z DEBUG stdout=active >> >> 2017-03-15T22:16:05Z DEBUG stderr= >> 2017-03-15T22:16:05Z DEBUG wait_for_open_ports: localhost [8080, 8443] >> timeout 300 >> 2017-03-15T22:16:06Z DEBUG Waiting until the CA is running >> 2017-03-15T22:16:06Z DEBUG request POST >> http://deawilidmp001.XXX.org:8080/ca/admin/ca/getStatus >> 2017-03-15T22:16:06Z DEBUG request body '' >> >> >> >> >> I've confirmed that SELINUX is disabled, there is no firewall and the AWS >> Security Groups are allowing TCP:8080 and TCP:8443 to the replica instance. >> The systemctl command also verifies that >> pki-tomcatd at pki-tomcat.service is "active" as well. >> >> >> Any tips for debugging further? >> > Could you please provide the /var/log/pki/pki-tomcat/ca/debug log > file? > > Thanks, > Fraser > Could it be this? https://pagure.io/freeipa/issue/6766 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From datakid at gmail.com Thu Mar 16 08:56:58 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Thu, 16 Mar 2017 19:56:58 +1100 Subject: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1 In-Reply-To: <20170316080558.z4yvuupcaetboa4z@hendrix> References: <20170316080558.z4yvuupcaetboa4z@hendrix> Message-ID: Yes. What I do would you like? Current debug levels are at 8 L. On 16 Mar. 2017 7:06 pm, "Jakub Hrozek" wrote: > On Thu, Mar 16, 2017 at 11:36:57AM +1100, Lachlan Musicman wrote: > > I'm experiencing issues with HBAC and I think it's a bug in sssd. Not > sure > > if better to report to here or sssd mailing list. Also sssd in pagure is > > bare and I didn't want to sully the blank slate. ( > > https://pagure.io/sssd/issues ) > > > > The details: > > > > env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR > > > > On the IPA server: > > > > - "ipa hbactest ..." returns TRUE, so everything seems set up correctly. > > > > > > When I try to login to the test client, I get denied. > > > > On the test client: > > > > - hbac_eval_user_element is returning a wrong value. This is seen in > > sssd_domain.log, it's returning 25. My test user is in 37 groups. This is > > seen on the IPA server via id username. On the test client id username > > returns 36 groups, the one missing is an IPA (not AD) group that was made > > for HBAC rules. I have sanitized logs available. > > > > - taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb > > '(objectclass=user)' and finding the record in question shows the same 36 > > groups available. The missing group shouldn't affect ability to login via > > HBAC > > > > - getent group (groupname) works as expected. Also worth noting that the > > group missing from id username shows that user in getent. > > > > For reference, on the client the sssd service was stopped, the cache > > deleted, and the service started again the night before after which the > > server wasn't accessed by anyone. I find that this is necessary for the > > cache to populate. > > > > Should I put in a bug report against SSSD or FreeIPA? > > > > While HBAC is in FreeIPA, I think that this is an issue in SSSD > > (specifically ? > > Yes, SSSD. > > I remember you had some intermittent issues in the past, is this one > reproducable? > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Mar 16 09:09:30 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 16 Mar 2017 10:09:30 +0100 Subject: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1 In-Reply-To: References: <20170316080558.z4yvuupcaetboa4z@hendrix> Message-ID: <20170316090930.3z7j43rsptpigmag@hendrix> On Thu, Mar 16, 2017 at 07:56:58PM +1100, Lachlan Musicman wrote: > Yes. What I do would you like? Current debug levels are at 8 Logs and id output from the server and the client at the same time.. From dag at sonsorol.org Thu Mar 16 11:29:00 2017 From: dag at sonsorol.org (Chris Dagdigian) Date: Thu, 16 Mar 2017 07:29:00 -0400 Subject: [Freeipa-users] replica install seems to hang forever when "--setup-ca" is enabled - any advice? In-Reply-To: References: <58C9C10A.2030106@sonsorol.org> <20170316003422.GS10261@dhcp-40-8.bne.redhat.com> Message-ID: <58CA76FC.6080703@sonsorol.org> That looks exactly like my issue, thanks! Will monitor that ticket. Much appreciated. Martin Basti wrote: > > Could it be this? > https://pagure.io/freeipa/issue/6766 > From ianh at brownpapertickets.com Thu Mar 16 18:14:40 2017 From: ianh at brownpapertickets.com (Ian Harding) Date: Thu, 16 Mar 2017 11:14:40 -0700 Subject: [Freeipa-users] Manual Cleanup Message-ID: <64100809-8ca2-ea1b-e2fe-dc38740ffb8a@brownpapertickets.com> I've made some progress. But I have one zombie replication agreement to kill, I just don't know the syntax. freeipa-dal.bpt.rocks does not exist. I want all references to it to go away. How would I do that with ldapmodify? Thanks! [root at freeipa-sea slapd-BPT-ROCKS]# ldapsearch -D "cn=directory manager" -w ... -b "o=ipaca" "(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" nscpentrywsi # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: cn: replica nscpentrywsi: createTimestamp: 20160814234939Z nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=c onfig nscpentrywsi: modifyTimestamp: 20170316181544Z nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-freei pa-sea.bpt.rocks-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-free ipa-dal.bpt.rocks-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-seat tlenfs.bpt.rocks-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaId: 1065 nscpentrywsi: nsDS5ReplicaName: b21a1f1e-627911e6-93e6ef4b-69dcc2d1 nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsState:: KQQAAAAAAABO1spYAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAAAAA == nscpentrywsi: nsds5replicabinddngroup: cn=replication managers,cn=sysaccounts, cn=etc,dc=bpt,dc=rocks nscpentrywsi: nsds5replicabinddngroupcheckinterval: 60 nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: numSubordinates: 2 nscpentrywsi: nsds50ruv: {replicageneration} 57c291d9000004290000 nscpentrywsi: nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389} 57f84 0bf000004290000 58cad667000004290000 nscpentrywsi: nsds50ruv: {replica 1290 ldap://seattlenfs.bpt.rocks:389} nscpentrywsi: nsds50ruv: {replica 1295 ldap://freeipa-dal.bpt.rocks:389} nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-freeipa-sea.bpt.rocks-p ki-tomcat;seattlenfs.bpt.rocks;389;unavailable nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-seattlenfs.bpt.rocks-p ki-tomcat;seattlenfs.bpt.rocks;389;unavailable nscpentrywsi: nsruvReplicaLastModified: {replica 1065 ldap://freeipa-sea.bpt.r ocks:389} 58cad63d nscpentrywsi: nsruvReplicaLastModified: {replica 1290 ldap://seattlenfs.bpt.ro cks:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://freeipa-dal.bpt.r ocks:389} 00000000 nscpentrywsi: nsds5ReplicaChangeCount: 15993 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage del freeipa-dal.bpt.rocks --forceDirectory Manager password: 'freeipa-sea.bpt.rocks' has no replication agreement for 'freeipa-dal.bpt.rocks' [root at freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list seattlenfs.bpt.rocks: master freeipa-dal.bpt.rocks: master freeipa-sea.bpt.rocks: master [root at freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list freeipa-sea.bpt.rocks seattlenfs.bpt.rocks: replica [root at freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage list Directory Manager password: seattlenfs.bpt.rocks: master freeipa-dal.bpt.rocks: CA not configured freeipa-sea.bpt.rocks: master From jim.kilborn at swri.org Thu Mar 16 20:24:42 2017 From: jim.kilborn at swri.org (Kilborn, Jim) Date: Thu, 16 Mar 2017 20:24:42 +0000 Subject: [Freeipa-users] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT Message-ID: <376fef4142a14b15be882de7ed3b2999@MBX256.adm.swri.edu> Greetings, My first post to the forum. We are running centos7 with freeipa. Syncing from AD, with one linux replica. The ipa clients are getting installed by puppet. All the clients are performing fine, except one. I am getting slow ssh logins to one host, as well as slow 'id' and 'who', etc. I turned up the sss-debuglevel to 6, and compared the slow client to another, and I am seeing a section in the logs that is unique to the slow system, basically its doing a SSS_PAM_ACCT_MGMT, and I don't have any clue why. Same user logging in to both clients, one client does the SSS_PAM_ACCT_MGMT, followed by the SSS_PAM_OPEN_SESSION. While the other client only does SSS_PAM_OPEN_SESSION, and is much faster. (1 second vs 2-8 seconds) It seems the SSS_PAM_ACCT_MGMT is the slow culprit, and I don't know why its running. Any idea what would cause this or where I should look? Below are the log for a good fast client, followed by the log from the slow client. Thanks!! Good Client [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=nobody at ipa.mydomain.org] [sysdb_get_real_name] (0x0040): Cannot find user [nobody at ipa.mydomain.org] in cache [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][1][name=myusername at ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][1][name=myusername at ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=myusername at ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_pam_handler] (0x0100): Got request with the following data [pam_print_data] (0x0100): command: SSS_PAM_OPEN_SESSION [pam_print_data] (0x0100): domain: ipa.mydomain.org [pam_print_data] (0x0100): user: myusername at ipa.mydomain.org [pam_print_data] (0x0100): service: sshd [pam_print_data] (0x0100): tty: ssh [pam_print_data] (0x0100): ruser: [pam_print_data] (0x0100): rhost: myhost.mydomain.org [pam_print_data] (0x0100): authtok type: 0 [pam_print_data] (0x0100): newauthtok type: 0 [pam_print_data] (0x0100): priv: 1 [pam_print_data] (0x0100): cli_pid: 26697 [pam_print_data] (0x0100): logon name: not set Bad Client [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=nobody at ipa.mydomain.org] [sysdb_get_real_name] (0x0040): Cannot find user [nobody at ipa.mydomain.org] in cache [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][1][name=myusername at ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_get_account_info_handler] (0x0200): Got request for [0x1][BE_REQ_USER][1][name=myusername at ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=myusername at ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_pam_handler] (0x0100): Got request with the following data [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT [pam_print_data] (0x0100): domain: ipa.mydomain.org [pam_print_data] (0x0100): user: myusername at ipa.mydomain.org [pam_print_data] (0x0100): service: sshd [pam_print_data] (0x0100): tty: ssh [pam_print_data] (0x0100): ruser: [pam_print_data] (0x0100): rhost: myhost at mydomain.org [pam_print_data] (0x0100): authtok type: 0 [pam_print_data] (0x0100): newauthtok type: 0 [pam_print_data] (0x0100): priv: 1 [pam_print_data] (0x0100): cli_pid: 183633 [pam_print_data] (0x0100): logon name: not set [ipa_hostgroup_info_done] (0x0200): Dereferenced host group: darkjedi [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [sysdb_delete_entry] (0x0080): sysdb_delete_ts_entry failed: 0 [hbac_get_category] (0x0200): Category is set to 'all'. [get_ipa_groupname] (0x0020): Expected cn in RDN, got uid [hbac_user_attrs_to_rule] (0x0020): [uid=slurm,cn=users,cn=accounts,dc=ipa,dc=mydomain,dc=org] does not map to either a user or group. Skipping [hbac_get_category] (0x0200): Category is set to 'all'. [hbac_get_category] (0x0200): Category is set to 'all'. [get_ipa_groupname] (0x0020): Expected groups second component, got privileges [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got privileges [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected groups second component, got permissions [get_ipa_groupname] (0x0020): Expected cn in RDN, got ipaUniqueID [get_ipa_groupname] (0x0020): Expected cn in RDN, got ipaUniqueID [hbac_evaluate] (0x0100): [< hbac_evaluate() [hbac_evaluate] (0x0100): The rule [darkjedi-access] did not match. [hbac_evaluate] (0x0100): ALLOWED by rule [Infrastructure]. [hbac_evaluate] (0x0100): hbac_evaluate() >] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [Infrastructure] [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=myusername at ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_pam_handler] (0x0100): Got request with the following data [pam_print_data] (0x0100): command: SSS_PAM_OPEN_SESSION [pam_print_data] (0x0100): domain: ipa.mydomain.org [pam_print_data] (0x0100): user: myusername at ipa.mydomain.org [pam_print_data] (0x0100): service: sshd [pam_print_data] (0x0100): tty: ssh [pam_print_data] (0x0100): ruser: [pam_print_data] (0x0100): rhost: myhost at mydomain.org [pam_print_data] (0x0100): authtok type: 0 [pam_print_data] (0x0100): newauthtok type: 0 [pam_print_data] (0x0100): priv: 1 [pam_print_data] (0x0100): cli_pid: 183633 [pam_print_data] (0x0100): logon name: not set [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][1][name=myusername at ipa.mydomain.org] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=users,cn=ipa.mydomain.org,cn=sysdb [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][1][idnumber=1051800710] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=groups,cn=ipa.mydomain.org,cn=sysdb [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=myusername at ipa.mydomain.org,cn=groups,cn=ipa.mydomain.org,cn=sysdb [cid:image002.png at 01D29E69.6E7C99E0] Jim Kilborn, Principal Technical Specialist Information Technology, Division 18 Southwest Research Institute Office (210) 522-2739 jim.kilborn at swri.org [cid:image004.png at 01D29D66.A9B19BE0] [cid:image005.png at 01D29D66.A9B19BE0] [cid:image006.png at 01D29D66.A9B19BE0] [cid:image007.png at 01D29D66.A9B19BE0] Advanced science. Applied technology. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 16036 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 15917 bytes Desc: image005.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 16148 bytes Desc: image006.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 16048 bytes Desc: image007.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 7084 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 176 bytes Desc: image003.png URL: From datakid at gmail.com Thu Mar 16 21:35:42 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Fri, 17 Mar 2017 08:35:42 +1100 Subject: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1 In-Reply-To: <20170316090930.3z7j43rsptpigmag@hendrix> References: <20170316080558.z4yvuupcaetboa4z@hendrix> <20170316090930.3z7j43rsptpigmag@hendrix> Message-ID: Which logs do you want from the server? ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 16 March 2017 at 20:09, Jakub Hrozek wrote: > On Thu, Mar 16, 2017 at 07:56:58PM +1100, Lachlan Musicman wrote: > > Yes. What I do would you like? Current debug levels are at 8 > > Logs and id output from the server and the client at the same time.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From datakid at gmail.com Fri Mar 17 02:20:17 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Fri, 17 Mar 2017 13:20:17 +1100 Subject: [Freeipa-users] Adjusting nsslapd-cachememsize Message-ID: While going through the logs on the FreeIPA server, I noticed this: WARNING: changelog: entry cache size 2097152 B is less than db size 12804096 B; We recommend to increase the entry cache size nsslapd-cachememsize. I have found a number of documents: What it is: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Database_Attributes_under_cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_database_cnplugins_cnconfig-nsslapd_cachememsize.html How to tune it: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/memoryusage.html etc etc. I have no idea of what the secret password is for the "cn=directory manager" and can't find any information about where I might find it or where or when it might have been set anywhere. I have found a number of likely candidates, but none have worked. I found this page: https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password but I'd prefer to not change the password if possible. cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at rha-ltd.co.uk Fri Mar 17 06:50:34 2017 From: bob at rha-ltd.co.uk (Bob Hinton) Date: Fri, 17 Mar 2017 06:50:34 +0000 Subject: [Freeipa-users] shadow netgroups with wrong domains - sudo problem Message-ID: Morning, We have a collection of hosts within prod1.local.lan. However, the domain section of the shadow netgroups for the hosts is mgmt.prod.local.lan. This seems to prevent sudo rules working on these hosts unless they specify all hosts - -sh-4.2$ getent netgroup oepp_hosts oepp_hosts (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) -sh-4.2$ hostname oeppredis001.z4.prod1.local.lan -sh-4.2$ nisdomainname local.lan -sh-4.2$ domainname local.lan The VMs associated with these hosts have recently been migrated and re-enrolled against a new IPA server. The originals all had netgroup domains of local.lan so something must have gone wrong in the migration process. Is there a way to correct the netgroup domains of these hosts, or is the only option to run ipa-client-install --uninstall followed by ipa-client-install to reattach them ? Many thanks Bob From slaznick at redhat.com Fri Mar 17 07:25:19 2017 From: slaznick at redhat.com (Standa Laznicka) Date: Fri, 17 Mar 2017 08:25:19 +0100 Subject: [Freeipa-users] Manual Cleanup In-Reply-To: <64100809-8ca2-ea1b-e2fe-dc38740ffb8a@brownpapertickets.com> References: <64100809-8ca2-ea1b-e2fe-dc38740ffb8a@brownpapertickets.com> Message-ID: <6b6daa5e-870b-b29d-493f-d9e49229f10b@redhat.com> Hello Ian, You could do: `ipa-replica-manage del freeipa-dal.bpt.rocks --force --cleanup` Then you may need to check again for the master with `ipa-replica-manage list`. If it's not there anymore, check whether some RUVs are still in place with `ipa-replica-manage list-ruv`. The last command should get you RUVs on both CA and domain suffixes if you're using FreeIPA >= 4.3.2 (hope I got the .z number right). If you see that there's some RUVs left for the wrong host, try calling `ipa-replica-manage clean-ruv ` which should remove the RUV (no matter the suffix - CA or domain - just give it the number and it should work given FreeIPA >= 4.3.2 is used). HTH, Standa On 03/16/2017 07:14 PM, Ian Harding wrote: > I've made some progress. But I have one zombie replication agreement to > kill, I just don't know the syntax. > > freeipa-dal.bpt.rocks does not exist. I want all references to it to go > away. > > How would I do that with ldapmodify? > > Thanks! > > > [root at freeipa-sea slapd-BPT-ROCKS]# ldapsearch -D "cn=directory > manager" -w ... -b "o=ipaca" > "(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" > nscpentrywsi > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: > (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: createTimestamp: 20160814234939Z > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication > Plugin,cn=plugins,cn=c > onfig > nscpentrywsi: modifyTimestamp: 20170316181544Z > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager > cloneAgreement1-freei > pa-sea.bpt.rocks-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager > masterAgreement1-free > ipa-dal.bpt.rocks-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager > masterAgreement1-seat > tlenfs.bpt.rocks-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaId: 1065 > nscpentrywsi: nsDS5ReplicaName: b21a1f1e-627911e6-93e6ef4b-69dcc2d1 > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsState:: > KQQAAAAAAABO1spYAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAAAAA > == > nscpentrywsi: nsds5replicabinddngroup: cn=replication > managers,cn=sysaccounts, > cn=etc,dc=bpt,dc=rocks > nscpentrywsi: nsds5replicabinddngroupcheckinterval: 60 > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: numSubordinates: 2 > nscpentrywsi: nsds50ruv: {replicageneration} 57c291d9000004290000 > nscpentrywsi: nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389} > 57f84 > 0bf000004290000 58cad667000004290000 > nscpentrywsi: nsds50ruv: {replica 1290 ldap://seattlenfs.bpt.rocks:389} > nscpentrywsi: nsds50ruv: {replica 1295 ldap://freeipa-dal.bpt.rocks:389} > nscpentrywsi: nsds5agmtmaxcsn: > o=ipaca;cloneAgreement1-freeipa-sea.bpt.rocks-p > ki-tomcat;seattlenfs.bpt.rocks;389;unavailable > nscpentrywsi: nsds5agmtmaxcsn: > o=ipaca;masterAgreement1-seattlenfs.bpt.rocks-p > ki-tomcat;seattlenfs.bpt.rocks;389;unavailable > nscpentrywsi: nsruvReplicaLastModified: {replica 1065 > ldap://freeipa-sea.bpt.r > ocks:389} 58cad63d > nscpentrywsi: nsruvReplicaLastModified: {replica 1290 > ldap://seattlenfs.bpt.ro > cks:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 > ldap://freeipa-dal.bpt.r > ocks:389} 00000000 > nscpentrywsi: nsds5ReplicaChangeCount: 15993 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > [root at freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage del > freeipa-dal.bpt.rocks --forceDirectory Manager password: > > 'freeipa-sea.bpt.rocks' has no replication agreement for > 'freeipa-dal.bpt.rocks' > [root at freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list > seattlenfs.bpt.rocks: master > freeipa-dal.bpt.rocks: master > freeipa-sea.bpt.rocks: master > [root at freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list > freeipa-sea.bpt.rocks > seattlenfs.bpt.rocks: replica > [root at freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage list > Directory Manager password: > > seattlenfs.bpt.rocks: master > freeipa-dal.bpt.rocks: CA not configured > freeipa-sea.bpt.rocks: master > From jhrozek at redhat.com Fri Mar 17 08:20:03 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 17 Mar 2017 09:20:03 +0100 Subject: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1 In-Reply-To: References: <20170316080558.z4yvuupcaetboa4z@hendrix> <20170316090930.3z7j43rsptpigmag@hendrix> Message-ID: <20170317082003.dna4use36y2jd5aj@hendrix> On Fri, Mar 17, 2017 at 08:35:42AM +1100, Lachlan Musicman wrote: > Which logs do you want from the server? NSS and domain From jhrozek at redhat.com Fri Mar 17 08:40:18 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 17 Mar 2017 09:40:18 +0100 Subject: [Freeipa-users] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT In-Reply-To: <376fef4142a14b15be882de7ed3b2999@MBX256.adm.swri.edu> References: <376fef4142a14b15be882de7ed3b2999@MBX256.adm.swri.edu> Message-ID: <20170317084018.upjjm65mlm4r3mvy@hendrix> On Thu, Mar 16, 2017 at 08:24:42PM +0000, Kilborn, Jim wrote: > Greetings, > > My first post to the forum. > > We are running centos7 with freeipa. Syncing from AD, with one linux replica. > The ipa clients are getting installed by puppet. All the clients are performing fine, except one. I am getting slow ssh logins to one host, as well as slow 'id' and 'who', etc. > > I turned up the sss-debuglevel to 6, and compared the slow client to another, and I am seeing a section in the logs that is unique to the slow system, basically its doing a SSS_PAM_ACCT_MGMT, and I don't have any clue why. Same user logging in to both clients, one client does the SSS_PAM_ACCT_MGMT, followed by the SSS_PAM_OPEN_SESSION. While the other client only does SSS_PAM_OPEN_SESSION, and is much faster. (1 second vs 2-8 seconds) > It seems the SSS_PAM_ACCT_MGMT is the slow culprit, and I don't know why its running. > > Any idea what would cause this or where I should look? The timestamps from the logs are missing, so it's not clear which call is taking long. No server lookups should be performed in the account phase, though, so I can only think of the selinux label setting in libselinux, which is also done in the account phase to be taking long. can you try to disable the selinux provider for a test? selinux_provider=none btw why is the 'fast' client not running the account phase at all? Is pam_sss in the account stack in the PAM configuration? Is the access_provider set to anything else than IPA in the sssd.conf file? From jhrozek at redhat.com Fri Mar 17 08:41:51 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 17 Mar 2017 09:41:51 +0100 Subject: [Freeipa-users] shadow netgroups with wrong domains - sudo problem In-Reply-To: References: Message-ID: <20170317084151.es4gclhtu4drsnv2@hendrix> On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote: > Morning, > > We have a collection of hosts within prod1.local.lan. However, the > domain section of the shadow netgroups for the hosts is > mgmt.prod.local.lan. This seems to prevent sudo rules working on these > hosts unless they specify all hosts - > > -sh-4.2$ getent netgroup oepp_hosts > oepp_hosts > (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) > (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) > (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) > (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) > (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) > -sh-4.2$ hostname > oeppredis001.z4.prod1.local.lan > -sh-4.2$ nisdomainname > local.lan > -sh-4.2$ domainname > local.lan > > The VMs associated with these hosts have recently been migrated and > re-enrolled against a new IPA server. The originals all had netgroup > domains of local.lan so something must have gone wrong in the migration > process. Is there a way to correct the netgroup domains of these hosts, > or is the only option to run ipa-client-install --uninstall followed by > ipa-client-install to reattach them ? Did you remove the sssd cache after the migration? rm -f /var/lib/sss/db/*.ldb (please make sure the clients can reach the server or maybe mv the cache instead of rm so you can restore cached credentials if something goes wrong..) From bob at rha-ltd.co.uk Fri Mar 17 08:45:57 2017 From: bob at rha-ltd.co.uk (Bob Hinton) Date: Fri, 17 Mar 2017 08:45:57 +0000 Subject: [Freeipa-users] Adjusting nsslapd-cachememsize In-Reply-To: References: Message-ID: <72121513-e631-617a-172d-4634dde7360e@rha-ltd.co.uk> Hi Lachlan, This is probably a complete hack, but the way I've changed nsslapd-cachememsize in the past is - On each ipa replica in turn - 1. ipactl stop 2. vim /etc/dirsrv/slapd-DOMAIN/dse.ldif - (where DOMAIN is your server's domain/realm - not sure which) find and change the value of nsslapd-cachememsize 3. ipactl start This seemed to work in that it made the error messages go away and it made heavily loaded servers more stable. However, I've not tried this on a recent version of ipa so it may no longer work or not be needed any more. Regards Bob On 17/03/2017 02:20, Lachlan Musicman wrote: > While going through the logs on the FreeIPA server, I noticed this: > > > WARNING: changelog: entry cache size 2097152 B is less than db size > 12804096 B; We recommend to increase the entry cache size > nsslapd-cachememsize. > > > I have found a number of documents: > > What it is: > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Database_Attributes_under_cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_database_cnplugins_cnconfig-nsslapd_cachememsize.html > > How to tune it: > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/memoryusage.html > > > etc etc. > > I have no idea of what the secret password is for the "cn=directory > manager" and can't find any information about where I might find it or > where or when it might have been set anywhere. I have found a number > of likely candidates, but none have worked. > > I found this page: > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > but I'd prefer to not change the password if possible. > > cheers > L. > > > > ------ > The most dangerous phrase in the language is, "We've always done it > this way." > > - Grace Hopper > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Mar 17 09:32:43 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Mar 2017 10:32:43 +0100 Subject: [Freeipa-users] Adjusting nsslapd-cachememsize In-Reply-To: References: Message-ID: <183bb521-e5d4-39e3-77bf-711aa9132d7a@redhat.com> On 03/17/2017 03:20 AM, Lachlan Musicman wrote: > While going through the logs on the FreeIPA server, I noticed this: > > > WARNING: changelog: entry cache size 2097152 B is less than db size 12804096 B; > We recommend to increase the entry cache size nsslapd-cachememsize. > > > I have found a number of documents: > > What it is: > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Database_Attributes_under_cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_database_cnplugins_cnconfig-nsslapd_cachememsize.html > > How to tune it: > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/memoryusage.html > > > etc etc. > > I have no idea of what the secret password is for the "cn=directory manager" and > can't find any information about where I might find it or where or when it might > have been set anywhere. I have found a number of likely candidates, but none > have worked. When you install a first IPA server, run ipa-kra-install, or install a replica (before 4.4 replica promotion) you typically write that password. I.e. in ipa-server-install you provide 2 passwords, one for directory manager second for admin user. > > I found this page: > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > but I'd prefer to not change the password if possible. > > cheers > L. > > > > ------ > The most dangerous phrase in the language is, "We've always done it this way." > > - Grace Hopper > > > -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. From bob at rha-ltd.co.uk Fri Mar 17 10:40:52 2017 From: bob at rha-ltd.co.uk (Bob Hinton) Date: Fri, 17 Mar 2017 10:40:52 +0000 Subject: [Freeipa-users] shadow netgroups with wrong domains - sudo problem In-Reply-To: <20170317084151.es4gclhtu4drsnv2@hendrix> References: <20170317084151.es4gclhtu4drsnv2@hendrix> Message-ID: <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> On 17/03/2017 08:41, Jakub Hrozek wrote: > On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote: >> Morning, >> >> We have a collection of hosts within prod1.local.lan. However, the >> domain section of the shadow netgroups for the hosts is >> mgmt.prod.local.lan. This seems to prevent sudo rules working on these >> hosts unless they specify all hosts - >> >> -sh-4.2$ getent netgroup oepp_hosts >> oepp_hosts >> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) >> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) >> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) >> -sh-4.2$ hostname >> oeppredis001.z4.prod1.local.lan >> -sh-4.2$ nisdomainname >> local.lan >> -sh-4.2$ domainname >> local.lan >> >> The VMs associated with these hosts have recently been migrated and >> re-enrolled against a new IPA server. The originals all had netgroup >> domains of local.lan so something must have gone wrong in the migration >> process. Is there a way to correct the netgroup domains of these hosts, >> or is the only option to run ipa-client-install --uninstall followed by >> ipa-client-install to reattach them ? > Did you remove the sssd cache after the migration? > rm -f /var/lib/sss/db/*.ldb > > (please make sure the clients can reach the server or maybe mv the cache > instead of rm so you can restore cached credentials if something goes > wrong..) > Hi Jakub, I've now tried removing the sssd cache on one of the offending servers and it's not made any difference. getent netgroup oepp_hosts when run from any host enrolled to the new IPA servers, including the IPA masters themselves produces the results with "mgmt.prod" included and the same thing run on any of the pre-migrated servers that are still commissioned produces them without, so I assume that the netgroup domain information is coming from the IPA masters rather than the local host. Thanks Bob From lslebodn at redhat.com Fri Mar 17 12:48:57 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 17 Mar 2017 13:48:57 +0100 Subject: [Freeipa-users] shadow netgroups with wrong domains - sudo problem In-Reply-To: <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> Message-ID: <20170317124857.GA3281@10.4.128.1> On (17/03/17 10:40), Bob Hinton wrote: >On 17/03/2017 08:41, Jakub Hrozek wrote: >> On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote: >>> Morning, >>> >>> We have a collection of hosts within prod1.local.lan. However, the >>> domain section of the shadow netgroups for the hosts is >>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these >>> hosts unless they specify all hosts - >>> >>> -sh-4.2$ getent netgroup oepp_hosts >>> oepp_hosts >>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>> -sh-4.2$ hostname >>> oeppredis001.z4.prod1.local.lan >>> -sh-4.2$ nisdomainname >>> local.lan >>> -sh-4.2$ domainname >>> local.lan >>> >>> The VMs associated with these hosts have recently been migrated and >>> re-enrolled against a new IPA server. The originals all had netgroup >>> domains of local.lan so something must have gone wrong in the migration >>> process. Is there a way to correct the netgroup domains of these hosts, >>> or is the only option to run ipa-client-install --uninstall followed by >>> ipa-client-install to reattach them ? >> Did you remove the sssd cache after the migration? >> rm -f /var/lib/sss/db/*.ldb >> >> (please make sure the clients can reach the server or maybe mv the cache >> instead of rm so you can restore cached credentials if something goes >> wrong..) >> >Hi Jakub, > >I've now tried removing the sssd cache on one of the offending servers >and it's not made any difference. > >getent netgroup oepp_hosts > >when run from any host enrolled to the new IPA servers, including the >IPA masters themselves produces the results with "mgmt.prod" included >and the same thing run on any of the pre-migrated servers that are still >commissioned produces them without, so I assume that the netgroup domain >information is coming from the IPA masters rather than the local host. > Could you provide content of LDIF from IPA server? For this netgroup/hostgroup LS From bob at rha-ltd.co.uk Fri Mar 17 13:52:17 2017 From: bob at rha-ltd.co.uk (Bob Hinton) Date: Fri, 17 Mar 2017 13:52:17 +0000 Subject: [Freeipa-users] shadow netgroups with wrong domains - sudo problem In-Reply-To: <20170317124857.GA3281@10.4.128.1> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> Message-ID: <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> On 17/03/2017 12:48, Lukas Slebodnik wrote: > On (17/03/17 10:40), Bob Hinton wrote: >> On 17/03/2017 08:41, Jakub Hrozek wrote: >>> On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote: >>>> Morning, >>>> >>>> We have a collection of hosts within prod1.local.lan. However, the >>>> domain section of the shadow netgroups for the hosts is >>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these >>>> hosts unless they specify all hosts - >>>> >>>> -sh-4.2$ getent netgroup oepp_hosts >>>> oepp_hosts >>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>> -sh-4.2$ hostname >>>> oeppredis001.z4.prod1.local.lan >>>> -sh-4.2$ nisdomainname >>>> local.lan >>>> -sh-4.2$ domainname >>>> local.lan >>>> >>>> The VMs associated with these hosts have recently been migrated and >>>> re-enrolled against a new IPA server. The originals all had netgroup >>>> domains of local.lan so something must have gone wrong in the migration >>>> process. Is there a way to correct the netgroup domains of these hosts, >>>> or is the only option to run ipa-client-install --uninstall followed by >>>> ipa-client-install to reattach them ? >>> Did you remove the sssd cache after the migration? >>> rm -f /var/lib/sss/db/*.ldb >>> >>> (please make sure the clients can reach the server or maybe mv the cache >>> instead of rm so you can restore cached credentials if something goes >>> wrong..) >>> >> Hi Jakub, >> >> I've now tried removing the sssd cache on one of the offending servers >> and it's not made any difference. >> >> getent netgroup oepp_hosts >> >> when run from any host enrolled to the new IPA servers, including the >> IPA masters themselves produces the results with "mgmt.prod" included >> and the same thing run on any of the pre-migrated servers that are still >> commissioned produces them without, so I assume that the netgroup domain >> information is coming from the IPA masters rather than the local host. >> > Could you provide content of LDIF from IPA server? > For this netgroup/hostgroup > > LS Hi Jakub, I extracted the following from the userRoot ldif produced by "ipa-backup --data". It appears to have the incorrect domain set against nisDomainName. Could this be changed with ldapmodify ? Thanks Bob # entry-id: 1485 dn: cn=oepp_hosts,cn=ng,cn=alt,dc=local,dc=lan ipaUniqueID: 186461fa-f91d-11e6-b43d-06642ebde14b modifyTimestamp: 20170222163643Z createTimestamp: 20170222163643Z modifiersName: cn=Managed Entries,cn=plugins,cn=config creatorsName: cn=Managed Entries,cn=plugins,cn=config mepManagedBy: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan description: ipaNetgroup oepp_hosts memberHost: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan cn: oepp_hosts nisDomainName: mgmt.prod.local.lan objectClass: ipanisnetgroup objectClass: ipaobject objectClass: mepManagedEntry objectClass: ipaAssociation objectClass: top nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10 From lslebodn at redhat.com Fri Mar 17 14:01:56 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 17 Mar 2017 15:01:56 +0100 Subject: [Freeipa-users] shadow netgroups with wrong domains - sudo problem In-Reply-To: <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> Message-ID: <20170317140156.GC3625@10.4.128.1> On (17/03/17 13:52), Bob Hinton wrote: >On 17/03/2017 12:48, Lukas Slebodnik wrote: >> On (17/03/17 10:40), Bob Hinton wrote: >>> On 17/03/2017 08:41, Jakub Hrozek wrote: >>>> On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote: >>>>> Morning, >>>>> >>>>> We have a collection of hosts within prod1.local.lan. However, the >>>>> domain section of the shadow netgroups for the hosts is >>>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these >>>>> hosts unless they specify all hosts - >>>>> >>>>> -sh-4.2$ getent netgroup oepp_hosts >>>>> oepp_hosts >>>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>>> -sh-4.2$ hostname >>>>> oeppredis001.z4.prod1.local.lan >>>>> -sh-4.2$ nisdomainname >>>>> local.lan >>>>> -sh-4.2$ domainname >>>>> local.lan >>>>> >>>>> The VMs associated with these hosts have recently been migrated and >>>>> re-enrolled against a new IPA server. The originals all had netgroup >>>>> domains of local.lan so something must have gone wrong in the migration >>>>> process. Is there a way to correct the netgroup domains of these hosts, >>>>> or is the only option to run ipa-client-install --uninstall followed by >>>>> ipa-client-install to reattach them ? >>>> Did you remove the sssd cache after the migration? >>>> rm -f /var/lib/sss/db/*.ldb >>>> >>>> (please make sure the clients can reach the server or maybe mv the cache >>>> instead of rm so you can restore cached credentials if something goes >>>> wrong..) >>>> >>> Hi Jakub, >>> >>> I've now tried removing the sssd cache on one of the offending servers >>> and it's not made any difference. >>> >>> getent netgroup oepp_hosts >>> >>> when run from any host enrolled to the new IPA servers, including the >>> IPA masters themselves produces the results with "mgmt.prod" included >>> and the same thing run on any of the pre-migrated servers that are still >>> commissioned produces them without, so I assume that the netgroup domain >>> information is coming from the IPA masters rather than the local host. >>> >> Could you provide content of LDIF from IPA server? >> For this netgroup/hostgroup >> >> LS > >Hi Jakub, > >I extracted the following from the userRoot ldif produced by "ipa-backup >--data". > >It appears to have the incorrect domain set against nisDomainName. Could >this be changed with ldapmodify ? > >Thanks > >Bob > ># entry-id: 1485 >dn: cn=oepp_hosts,cn=ng,cn=alt,dc=local,dc=lan >ipaUniqueID: 186461fa-f91d-11e6-b43d-06642ebde14b >modifyTimestamp: 20170222163643Z >createTimestamp: 20170222163643Z >modifiersName: cn=Managed Entries,cn=plugins,cn=config >creatorsName: cn=Managed Entries,cn=plugins,cn=config >mepManagedBy: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan >description: ipaNetgroup oepp_hosts >memberHost: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan >cn: oepp_hosts >nisDomainName: mgmt.prod.local.lan And value of this attribute is an explanation to your question why there is a different domain in netgroups. >objectClass: ipanisnetgroup >objectClass: ipaobject >objectClass: mepManagedEntry >objectClass: ipaAssociation >objectClass: top >nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10 LS From jim.kilborn at swri.org Fri Mar 17 15:27:48 2017 From: jim.kilborn at swri.org (Kilborn, Jim) Date: Fri, 17 Mar 2017 15:27:48 +0000 Subject: [Freeipa-users] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT In-Reply-To: <20170317084018.upjjm65mlm4r3mvy@hendrix> References: <376fef4142a14b15be882de7ed3b2999@MBX256.adm.swri.edu> <20170317084018.upjjm65mlm4r3mvy@hendrix> Message-ID: <89488596879749129d83a1afa5b282f5@MBX256.adm.swri.edu> Jakub, Thanks for the response... I already had the selinux_provider=none in the sssd.conf Tthe sssd.conf is identical on both clients, with the exception of ipa_hostname [domain/ipa.mydomain.org] selinux_provider = none cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.mydomain.org id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = darkjedi-master01.div18.swri.edu chpass_provider = ipa ipa_server = _srv_, div18auth1.ipa.mydomain.org, div18auth2.ipa.mydomain.org dns_discovery_domain = ipa.mydomain.org [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = ipa.mydomain.org [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] I verified the all the files in /etc/pam.d are the same on both clients using the checksum of the files. I turned logging up to 8 on both clients, and everything is fine until this part appears. Can't figure out why the slow host receives an extra request. The sssd_be client process is getting this request from where? After it finished up the SSS_PAM_ACCT_MGMT request, the slow client runs the SSS_PAM_OPEN_SESSION, which is fast, just like the fast client. Its wasting time in the SSS_PAM_ACCT_MGMT request, and I don't understand why that request is being received by sssd_be. Slow Client (Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] (0x0100): Got request with the following data (Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT <- Why does the slow client get this request first? Fast Client (Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] (0x0100): Got request with the following data (Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] (0x0100): command: SSS_PAM_OPEN_SESSION Also ipa version is 4.4.0 Regards, Jim > Greetings, > > My first post to the forum. > > We are running centos7 with freeipa. Syncing from AD, with one linux replica. > The ipa clients are getting installed by puppet. All the clients are performing fine, except one. I am getting slow ssh logins to one host, as well as slow 'id' and 'who', etc. > > I turned up the sss-debuglevel to 6, and compared the slow client to > another, and I am seeing a section in the logs that is unique to the slow system, basically its doing a SSS_PAM_ACCT_MGMT, and I don't have any clue why. Same user logging in to both clients, one client does the SSS_PAM_ACCT_MGMT, followed by the SSS_PAM_OPEN_SESSION. While the other client only does SSS_PAM_OPEN_SESSION, and is much faster. (1 second vs 2-8 seconds) It seems the SSS_PAM_ACCT_MGMT is the slow culprit, and I don't know why its running. > > Any idea what would cause this or where I should look? The timestamps from the logs are missing, so it's not clear which call is taking long. No server lookups should be performed in the account phase, though, so I can only think of the selinux label setting in libselinux, which is also done in the account phase to be taking long. can you try to disable the selinux provider for a test? selinux_provider=none btw why is the 'fast' client not running the account phase at all? Is pam_sss in the account stack in the PAM configuration? Is the access_provider set to anything else than IPA in the sssd.conf file? -- 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 From pvoborni at redhat.com Fri Mar 17 17:22:36 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 17 Mar 2017 18:22:36 +0100 Subject: [Freeipa-users] Manual Cleanup In-Reply-To: <64100809-8ca2-ea1b-e2fe-dc38740ffb8a@brownpapertickets.com> References: <64100809-8ca2-ea1b-e2fe-dc38740ffb8a@brownpapertickets.com> Message-ID: On 03/16/2017 07:14 PM, Ian Harding wrote: > I've made some progress. But I have one zombie replication agreement to > kill, I just don't know the syntax. The output listed below is not replication agreement. But there is reference to RUV. > > freeipa-dal.bpt.rocks does not exist. I want all references to it to go > away. > > How would I do that with ldapmodify? I wouldn't delete the entry below because cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config is a container for CA replication agreements and it should stay there. Btw, there should also be one for "domain" replication agreements. But in general, you could use ldapdelete command. If you want to investigate pure ldap data, then information about IPA masters is also stored in cn=masters,cn=ipa,cn=etc,dc=example,dc=test . This is the place where ipa server-find gets its info. > > Thanks! > > > [root at freeipa-sea slapd-BPT-ROCKS]# ldapsearch -D "cn=directory > manager" -w ... -b "o=ipaca" > "(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" > nscpentrywsi > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: > (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: createTimestamp: 20160814234939Z > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication > Plugin,cn=plugins,cn=c > onfig > nscpentrywsi: modifyTimestamp: 20170316181544Z > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager > cloneAgreement1-freei > pa-sea.bpt.rocks-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager > masterAgreement1-free > ipa-dal.bpt.rocks-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager > masterAgreement1-seat > tlenfs.bpt.rocks-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaId: 1065 > nscpentrywsi: nsDS5ReplicaName: b21a1f1e-627911e6-93e6ef4b-69dcc2d1 > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsState:: > KQQAAAAAAABO1spYAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAAAAA > == > nscpentrywsi: nsds5replicabinddngroup: cn=replication > managers,cn=sysaccounts, > cn=etc,dc=bpt,dc=rocks > nscpentrywsi: nsds5replicabinddngroupcheckinterval: 60 > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: numSubordinates: 2 > nscpentrywsi: nsds50ruv: {replicageneration} 57c291d9000004290000 > nscpentrywsi: nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389} > 57f84 > 0bf000004290000 58cad667000004290000 > nscpentrywsi: nsds50ruv: {replica 1290 ldap://seattlenfs.bpt.rocks:389} > nscpentrywsi: nsds50ruv: {replica 1295 ldap://freeipa-dal.bpt.rocks:389} > nscpentrywsi: nsds5agmtmaxcsn: > o=ipaca;cloneAgreement1-freeipa-sea.bpt.rocks-p > ki-tomcat;seattlenfs.bpt.rocks;389;unavailable > nscpentrywsi: nsds5agmtmaxcsn: > o=ipaca;masterAgreement1-seattlenfs.bpt.rocks-p > ki-tomcat;seattlenfs.bpt.rocks;389;unavailable > nscpentrywsi: nsruvReplicaLastModified: {replica 1065 > ldap://freeipa-sea.bpt.r > ocks:389} 58cad63d > nscpentrywsi: nsruvReplicaLastModified: {replica 1290 > ldap://seattlenfs.bpt.ro > cks:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 > ldap://freeipa-dal.bpt.r > ocks:389} 00000000 > nscpentrywsi: nsds5ReplicaChangeCount: 15993 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > [root at freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage del > freeipa-dal.bpt.rocks --forceDirectory Manager password: > > 'freeipa-sea.bpt.rocks' has no replication agreement for > 'freeipa-dal.bpt.rocks' > [root at freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list > seattlenfs.bpt.rocks: master > freeipa-dal.bpt.rocks: master > freeipa-sea.bpt.rocks: master > [root at freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list > freeipa-sea.bpt.rocks > seattlenfs.bpt.rocks: replica > [root at freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage list > Directory Manager password: > > seattlenfs.bpt.rocks: master > freeipa-dal.bpt.rocks: CA not configured > freeipa-sea.bpt.rocks: master > -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. From jstephen at redhat.com Fri Mar 17 18:12:24 2017 From: jstephen at redhat.com (Justin Stephenson) Date: Fri, 17 Mar 2017 14:12:24 -0400 Subject: [Freeipa-users] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT In-Reply-To: <89488596879749129d83a1afa5b282f5@MBX256.adm.swri.edu> References: <376fef4142a14b15be882de7ed3b2999@MBX256.adm.swri.edu> <20170317084018.upjjm65mlm4r3mvy@hendrix> <89488596879749129d83a1afa5b282f5@MBX256.adm.swri.edu> Message-ID: On 03/17/2017 11:27 AM, Kilborn, Jim wrote: > Jakub, > > Thanks for the response... > > I already had the selinux_provider=none in the sssd.conf > Tthe sssd.conf is identical on both clients, with the exception of ipa_hostname > > > [domain/ipa.mydomain.org] > selinux_provider = none > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = ipa.mydomain.org > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ldap_tls_cacert = /etc/ipa/ca.crt > ipa_hostname = darkjedi-master01.div18.swri.edu > chpass_provider = ipa > ipa_server = _srv_, div18auth1.ipa.mydomain.org, div18auth2.ipa.mydomain.org > dns_discovery_domain = ipa.mydomain.org > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > domains = ipa.mydomain.org > [nss] > homedir_substring = /home > [pam] > [sudo] > [autofs] > [ssh] > [pac] > [ifp] > > I verified the all the files in /etc/pam.d are the same on both clients using the checksum of the files. > > I turned logging up to 8 on both clients, and everything is fine until this part appears. Can't figure out why the slow host receives an extra request. The sssd_be client process is getting this request from where? It is expected for the login process to make a call into pam_acct_mgmt() which should trigger pam_sss in the 'account' section of the PAM stack for IPA users. This behavior is dependent on the PAM stack configuration, I would say the system that never calls SSS_PAM_ACCT_MGMT is the non-working one in this case. I understand you said they are the exact same, but I would suggest checking closely the 'account' section in /etc/pam.d/sshd and /etc/pam.d/password-auth. In the version you are running, the password-auth account section should look similar to: account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so > After it finished up the SSS_PAM_ACCT_MGMT request, the slow client runs the SSS_PAM_OPEN_SESSION, which is fast, just like the fast client. Its wasting time in the SSS_PAM_ACCT_MGMT request, and I don't understand why that request is being received by sssd_be. Is it possible a local user exists with the same name that you are trying to login as? In this case that may cause the pam_sss line entry in the PAM stack to never be reached(they would 'succeed' the account section in one of the previous modules). > > Slow Client > (Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] (0x0100): Got request with the following data > (Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] (0x0100): command: SSS_PAM_ACCT_MGMT <- Why does the slow client get this request first? > > Fast Client > (Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] (0x0100): Got request with the following data > (Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] (0x0100): command: SSS_PAM_OPEN_SESSION > > > Also ipa version is 4.4.0 > > > Regards, > Jim > >> Greetings, >> >> My first post to the forum. >> >> We are running centos7 with freeipa. Syncing from AD, with one linux replica. >> The ipa clients are getting installed by puppet. All the clients are performing fine, except one. I am getting slow ssh logins to one host, as well as slow 'id' and 'who', etc. >> >> I turned up the sss-debuglevel to 6, and compared the slow client to >> another, and I am seeing a section in the logs that is unique to the slow system, basically its doing a SSS_PAM_ACCT_MGMT, and I don't have any clue why. Same user logging in to both clients, one client does the SSS_PAM_ACCT_MGMT, followed by the SSS_PAM_OPEN_SESSION. While the other client only does SSS_PAM_OPEN_SESSION, and is much faster. (1 second vs 2-8 seconds) It seems the SSS_PAM_ACCT_MGMT is the slow culprit, and I don't know why its running. >> >> Any idea what would cause this or where I should look? > > The timestamps from the logs are missing, so it's not clear which call is taking long. No server lookups should be performed in the account phase, though, so I can only think of the selinux label setting in libselinux, which is also done in the account phase to be taking long. > > can you try to disable the selinux provider for a test? > selinux_provider=none > btw why is the 'fast' client not running the account phase at all? Is pam_sss in the account stack in the PAM configuration? Is the access_provider set to anything else than IPA in the sssd.conf file? > > -- > 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 > From marc.boorshtein at tremolosecurity.com Fri Mar 17 19:00:48 2017 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Fri, 17 Mar 2017 15:00:48 -0400 Subject: [Freeipa-users] different apis for adding "local" users to groups vs adding users from cft? Message-ID: I've got the api integrated for all local users and am looking at if there are any differences between that and if my ipa domain is in a CFT with an AD domain. Right now I'm using "group_add_member", should that work for users coming from a trusted forest as well? Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com Twitter - @mlbiam / @tremolosecurity From jim.kilborn at swri.org Fri Mar 17 19:27:25 2017 From: jim.kilborn at swri.org (Kilborn, Jim) Date: Fri, 17 Mar 2017 19:27:25 +0000 Subject: [Freeipa-users] Slow logins on one ipa client- due to SSS_PAM_ACCT_MGMT In-Reply-To: References: <376fef4142a14b15be882de7ed3b2999@MBX256.adm.swri.edu> <20170317084018.upjjm65mlm4r3mvy@hendrix> <89488596879749129d83a1afa5b282f5@MBX256.adm.swri.edu> Message-ID: Justin, I verified that the pam.d files were as you documented, and they were the same between the two clients. However, I forgot that I had a local user defined that matched the account name. That was stupid of me. I removed the local user, and now it is doing the SSS_PAM_ACCT_MGMT, so at least I'm not chasing that anymore. The client speed is still much different, so I need to compare the logs again and see where its taking up so much time. Hopefully it will be more apparent now. Much Thanks !! Regards, Jim > -----Original Message----- > From: Justin Stephenson [mailto:jstephen at redhat.com] > Sent: Friday, March 17, 2017 1:12 PM > To: Kilborn, Jim ; Jakub Hrozek > ; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Slow logins on one ipa client- due to > SSS_PAM_ACCT_MGMT > > On 03/17/2017 11:27 AM, Kilborn, Jim wrote: > > Jakub, > > > > Thanks for the response... > > > > I already had the selinux_provider=none in the sssd.conf > > Tthe sssd.conf is identical on both clients, with the exception of > ipa_hostname > > > > > > [domain/ipa.mydomain.org] > > selinux_provider = none > > cache_credentials = True > > krb5_store_password_if_offline = True > > ipa_domain = ipa.mydomain.org > > id_provider = ipa > > auth_provider = ipa > > access_provider = ipa > > ldap_tls_cacert = /etc/ipa/ca.crt > > ipa_hostname = darkjedi-master01.div18.swri.edu > > chpass_provider = ipa > > ipa_server = _srv_, div18auth1.ipa.mydomain.org, > div18auth2.ipa.mydomain.org > > dns_discovery_domain = ipa.mydomain.org > > [sssd] > > services = nss, sudo, pam, ssh > > config_file_version = 2 > > domains = ipa.mydomain.org > > [nss] > > homedir_substring = /home > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > [ifp] > > > > I verified the all the files in /etc/pam.d are the same on both clients using > the checksum of the files. > > > > I turned logging up to 8 on both clients, and everything is fine until this part > appears. Can't figure out why the slow host receives an extra request. The > sssd_be client process is getting this request from where? > > It is expected for the login process to make a call into pam_acct_mgmt() > which should trigger pam_sss in the 'account' section of the PAM stack > for IPA users. This behavior is dependent on the PAM stack > configuration, I would say the system that never calls > SSS_PAM_ACCT_MGMT > is the non-working one in this case. > > I understand you said they are the exact same, but I would suggest > checking closely the 'account' section in /etc/pam.d/sshd and > /etc/pam.d/password-auth. > > In the version you are running, the password-auth account section should > look similar to: > > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 1000 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > > After it finished up the SSS_PAM_ACCT_MGMT request, the slow client > runs the SSS_PAM_OPEN_SESSION, which is fast, just like the fast client. Its > wasting time in the SSS_PAM_ACCT_MGMT request, and I don't understand > why that request is being received by sssd_be. > > Is it possible a local user exists with the same name that you are > trying to login as? In this case that may cause the pam_sss line entry > in the PAM stack to never be reached(they would 'succeed' the account > section in one of the previous modules). > > > > > Slow Client > > (Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] > (0x0100): Got request with the following data > > (Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] > (0x0100): command: SSS_PAM_ACCT_MGMT <- Why does the slow client > get this request first? > > > > Fast Client > > (Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] > (0x0100): Got request with the following data > > (Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] > (0x0100): command: SSS_PAM_OPEN_SESSION > > > > > > Also ipa version is 4.4.0 > > > > > > Regards, > > Jim > > > >> Greetings, > >> > >> My first post to the forum. > >> > >> We are running centos7 with freeipa. Syncing from AD, with one linux > replica. > >> The ipa clients are getting installed by puppet. All the clients are > performing fine, except one. I am getting slow ssh logins to one host, as well > as slow 'id' and 'who', etc. > >> > >> I turned up the sss-debuglevel to 6, and compared the slow client to > >> another, and I am seeing a section in the logs that is unique to the slow > system, basically its doing a SSS_PAM_ACCT_MGMT, and I don't have any > clue why. Same user logging in to both clients, one client does the > SSS_PAM_ACCT_MGMT, followed by the SSS_PAM_OPEN_SESSION. While > the other client only does SSS_PAM_OPEN_SESSION, and is much faster. (1 > second vs 2-8 seconds) It seems the SSS_PAM_ACCT_MGMT is the slow > culprit, and I don't know why its running. > >> > >> Any idea what would cause this or where I should look? > > > > The timestamps from the logs are missing, so it's not clear which call is > taking long. No server lookups should be performed in the account phase, > though, so I can only think of the selinux label setting in libselinux, which is > also done in the account phase to be taking long. > > > > can you try to disable the selinux provider for a test? > > selinux_provider=none > > btw why is the 'fast' client not running the account phase at all? Is pam_sss > in the account stack in the PAM configuration? Is the access_provider set to > anything else than IPA in the sssd.conf file? > > > > -- > > 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 > > From bob at rha-ltd.co.uk Fri Mar 17 21:52:22 2017 From: bob at rha-ltd.co.uk (Bob Hinton) Date: Fri, 17 Mar 2017 21:52:22 +0000 Subject: [Freeipa-users] shadow netgroups with wrong domains - sudo problem In-Reply-To: <20170317140156.GC3625@10.4.128.1> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> <20170317140156.GC3625@10.4.128.1> Message-ID: On 17/03/2017 14:01, Lukas Slebodnik wrote: > On (17/03/17 13:52), Bob Hinton wrote: >> On 17/03/2017 12:48, Lukas Slebodnik wrote: >>> On (17/03/17 10:40), Bob Hinton wrote: >>>> On 17/03/2017 08:41, Jakub Hrozek wrote: >>>>> On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote: >>>>>> Morning, >>>>>> >>>>>> We have a collection of hosts within prod1.local.lan. However, the >>>>>> domain section of the shadow netgroups for the hosts is >>>>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these >>>>>> hosts unless they specify all hosts - >>>>>> >>>>>> -sh-4.2$ getent netgroup oepp_hosts >>>>>> oepp_hosts >>>>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> -sh-4.2$ hostname >>>>>> oeppredis001.z4.prod1.local.lan >>>>>> -sh-4.2$ nisdomainname >>>>>> local.lan >>>>>> -sh-4.2$ domainname >>>>>> local.lan >>>>>> >>>>>> The VMs associated with these hosts have recently been migrated and >>>>>> re-enrolled against a new IPA server. The originals all had netgroup >>>>>> domains of local.lan so something must have gone wrong in the migration >>>>>> process. Is there a way to correct the netgroup domains of these hosts, >>>>>> or is the only option to run ipa-client-install --uninstall followed by >>>>>> ipa-client-install to reattach them ? >>>>> Did you remove the sssd cache after the migration? >>>>> rm -f /var/lib/sss/db/*.ldb >>>>> >>>>> (please make sure the clients can reach the server or maybe mv the cache >>>>> instead of rm so you can restore cached credentials if something goes >>>>> wrong..) >>>>> >>>> Hi Jakub, >>>> >>>> I've now tried removing the sssd cache on one of the offending servers >>>> and it's not made any difference. >>>> >>>> getent netgroup oepp_hosts >>>> >>>> when run from any host enrolled to the new IPA servers, including the >>>> IPA masters themselves produces the results with "mgmt.prod" included >>>> and the same thing run on any of the pre-migrated servers that are still >>>> commissioned produces them without, so I assume that the netgroup domain >>>> information is coming from the IPA masters rather than the local host. >>>> >>> Could you provide content of LDIF from IPA server? >>> For this netgroup/hostgroup >>> >>> LS >> Hi Jakub, >> >> I extracted the following from the userRoot ldif produced by "ipa-backup >> --data". >> >> It appears to have the incorrect domain set against nisDomainName. Could >> this be changed with ldapmodify ? >> >> Thanks >> >> Bob >> >> # entry-id: 1485 >> dn: cn=oepp_hosts,cn=ng,cn=alt,dc=local,dc=lan >> ipaUniqueID: 186461fa-f91d-11e6-b43d-06642ebde14b >> modifyTimestamp: 20170222163643Z >> createTimestamp: 20170222163643Z >> modifiersName: cn=Managed Entries,cn=plugins,cn=config >> creatorsName: cn=Managed Entries,cn=plugins,cn=config >> mepManagedBy: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan >> description: ipaNetgroup oepp_hosts >> memberHost: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan >> cn: oepp_hosts >> nisDomainName: mgmt.prod.local.lan > And value of this attribute is an explanation to your question > why there is a different domain in netgroups. > >> objectClass: ipanisnetgroup >> objectClass: ipaobject >> objectClass: mepManagedEntry >> objectClass: ipaAssociation >> objectClass: top >> nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10 > LS > Hi Jakub, I've tried using ldapsearch to retrieve this record but the results don't include the nisDomainName field. Can you give me any pointers how to access this attribute so I can edit it ? Many thanks Bob From amessina at messinet.com Sat Mar 18 05:00:18 2017 From: amessina at messinet.com (Anthony Joseph Messina) Date: Sat, 18 Mar 2017 00:00:18 -0500 Subject: [Freeipa-users] FreeIPA default_ccache_name in systemd-nspawn container Message-ID: <3006482.amxPaI0Hu3@linux-ws1.messinet.com> I've been running freeipa-server-4.x.x.fc25.x86_64 in systemd-nspawn selinux- wrapped full OS containers for a while. After upgrading to F25 on the host, systemd disabled access to the KEYRING ccache type from nspawn containers since the kernel keyring isn't namespaced. So anything that needs to get a keytab results in something like the following. -bash-4.3# kinit kinit: Invalid UID in persistent keyring name while getting default ccache dnf upgrades end up failing until I 'export KRB5CCNAME=FILE:/tmp/whatever' and manually upgrade as if I performed an offline upgrade. Other than that, no issues to report. Are there any concerns if I switch the krb5.com default_ccache_name on the freeipa systemd-nspawn servers to MEMORY or FILE? Which would be preferred? Thanks for the advice. -A -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 From abokovoy at redhat.com Sat Mar 18 06:24:13 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 18 Mar 2017 08:24:13 +0200 Subject: [Freeipa-users] FreeIPA default_ccache_name in systemd-nspawn container In-Reply-To: <3006482.amxPaI0Hu3@linux-ws1.messinet.com> References: <3006482.amxPaI0Hu3@linux-ws1.messinet.com> Message-ID: <20170318062413.52lkzjzavfzsfgnj@redhat.com> On la, 18 maalis 2017, Anthony Joseph Messina wrote: >I've been running freeipa-server-4.x.x.fc25.x86_64 in systemd-nspawn selinux- >wrapped full OS containers for a while. > >After upgrading to F25 on the host, systemd disabled access to the KEYRING >ccache type from nspawn containers since the kernel keyring isn't namespaced. >So anything that needs to get a keytab results in something like the >following. > >-bash-4.3# kinit >kinit: Invalid UID in persistent keyring name while getting default ccache > >dnf upgrades end up failing until I 'export KRB5CCNAME=FILE:/tmp/whatever' and >manually upgrade as if I performed an offline upgrade. > >Other than that, no issues to report. > >Are there any concerns if I switch the krb5.com default_ccache_name on the >freeipa systemd-nspawn servers to MEMORY or FILE? Which would be preferred? No concerns for FILE. KEYRING uses kernel keyring which is *not* namespaced so you are seeing the same kernel keyring in the container that a user with the same UID sees outside of it. Don't use MEMORY ccache type, it is storing credentials in the process address space. Its purpose is to allow applications to have temporary ccaches they don't want to back with files. -- / Alexander Bokovoy From abokovoy at redhat.com Sat Mar 18 06:27:29 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 18 Mar 2017 08:27:29 +0200 Subject: [Freeipa-users] different apis for adding "local" users to groups vs adding users from cft? In-Reply-To: References: Message-ID: <20170318062729.shcc4uwjqrnhnvsf@redhat.com> On pe, 17 maalis 2017, Marc Boorshtein wrote: >I've got the api integrated for all local users and am looking at if >there are any differences between that and if my ipa domain is in a >CFT with an AD domain. Right now I'm using "group_add_member", should >that work for users coming from a trusted forest as well? EPARSE, but I'll try to understand what are you trying to achieve. If you were using ipa group-add-member external_group --external user at AD.DOMAIN to add AD users as external members of a group, you continue using the same command on API level: api.Command.group_add_member(u'external_group', external=u'user at AD.DOMAIN'}) Same with JSON-RPC. -- / Alexander Bokovoy From amessina at messinet.com Sat Mar 18 06:34:12 2017 From: amessina at messinet.com (Anthony Joseph Messina) Date: Sat, 18 Mar 2017 01:34:12 -0500 Subject: [Freeipa-users] FreeIPA default_ccache_name in systemd-nspawn container In-Reply-To: <20170318062413.52lkzjzavfzsfgnj@redhat.com> References: <3006482.amxPaI0Hu3@linux-ws1.messinet.com> <20170318062413.52lkzjzavfzsfgnj@redhat.com> Message-ID: <3298886.P3ENvBYIuV@linux-ws1.messinet.com> On Saturday, March 18, 2017 1:24:13 AM CDT Alexander Bokovoy wrote: > On la, 18 maalis 2017, Anthony Joseph Messina wrote: > >I've been running freeipa-server-4.x.x.fc25.x86_64 in systemd-nspawn > >selinux- wrapped full OS containers for a while. > > > >After upgrading to F25 on the host, systemd disabled access to the KEYRING > >ccache type from nspawn containers since the kernel keyring isn't > >namespaced. So anything that needs to get a keytab results in something > >like the following. > > > >-bash-4.3# kinit > >kinit: Invalid UID in persistent keyring name while getting default ccache > > > >dnf upgrades end up failing until I 'export KRB5CCNAME=FILE:/tmp/whatever' > >and manually upgrade as if I performed an offline upgrade. > > > >Other than that, no issues to report. > > > >Are there any concerns if I switch the krb5.com default_ccache_name on the > >freeipa systemd-nspawn servers to MEMORY or FILE? Which would be > >preferred? > No concerns for FILE. KEYRING uses kernel keyring which is *not* > namespaced so you are seeing the same kernel keyring in the container > that a user with the same UID sees outside of it. > > Don't use MEMORY ccache type, it is storing credentials in the process > address space. Its purpose is to allow applications to have temporary > ccaches they don't want to back with files. Thank you Alexander. -A -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 From bob at rha-ltd.co.uk Sat Mar 18 13:13:15 2017 From: bob at rha-ltd.co.uk (Bob Hinton) Date: Sat, 18 Mar 2017 13:13:15 +0000 Subject: [Freeipa-users] shadow netgroups with wrong domains - sudo problem In-Reply-To: <20170317140156.GC3625@10.4.128.1> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> <20170317140156.GC3625@10.4.128.1> Message-ID: On 17/03/2017 14:01, Lukas Slebodnik wrote: > On (17/03/17 13:52), Bob Hinton wrote: >> On 17/03/2017 12:48, Lukas Slebodnik wrote: >>> On (17/03/17 10:40), Bob Hinton wrote: >>>> On 17/03/2017 08:41, Jakub Hrozek wrote: >>>>> On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote: >>>>>> Morning, >>>>>> >>>>>> We have a collection of hosts within prod1.local.lan. However, the >>>>>> domain section of the shadow netgroups for the hosts is >>>>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these >>>>>> hosts unless they specify all hosts - >>>>>> >>>>>> -sh-4.2$ getent netgroup oepp_hosts >>>>>> oepp_hosts >>>>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> -sh-4.2$ hostname >>>>>> oeppredis001.z4.prod1.local.lan >>>>>> -sh-4.2$ nisdomainname >>>>>> local.lan >>>>>> -sh-4.2$ domainname >>>>>> local.lan >>>>>> >>>>>> The VMs associated with these hosts have recently been migrated and >>>>>> re-enrolled against a new IPA server. The originals all had netgroup >>>>>> domains of local.lan so something must have gone wrong in the migration >>>>>> process. Is there a way to correct the netgroup domains of these hosts, >>>>>> or is the only option to run ipa-client-install --uninstall followed by >>>>>> ipa-client-install to reattach them ? >>>>> Did you remove the sssd cache after the migration? >>>>> rm -f /var/lib/sss/db/*.ldb >>>>> >>>>> (please make sure the clients can reach the server or maybe mv the cache >>>>> instead of rm so you can restore cached credentials if something goes >>>>> wrong..) >>>>> >>>> Hi Jakub, >>>> >>>> I've now tried removing the sssd cache on one of the offending servers >>>> and it's not made any difference. >>>> >>>> getent netgroup oepp_hosts >>>> >>>> when run from any host enrolled to the new IPA servers, including the >>>> IPA masters themselves produces the results with "mgmt.prod" included >>>> and the same thing run on any of the pre-migrated servers that are still >>>> commissioned produces them without, so I assume that the netgroup domain >>>> information is coming from the IPA masters rather than the local host. >>>> >>> Could you provide content of LDIF from IPA server? >>> For this netgroup/hostgroup >>> >>> LS >> Hi Jakub, >> >> I extracted the following from the userRoot ldif produced by "ipa-backup >> --data". >> >> It appears to have the incorrect domain set against nisDomainName. Could >> this be changed with ldapmodify ? >> >> Thanks >> >> Bob >> >> # entry-id: 1485 >> dn: cn=oepp_hosts,cn=ng,cn=alt,dc=local,dc=lan >> ipaUniqueID: 186461fa-f91d-11e6-b43d-06642ebde14b >> modifyTimestamp: 20170222163643Z >> createTimestamp: 20170222163643Z >> modifiersName: cn=Managed Entries,cn=plugins,cn=config >> creatorsName: cn=Managed Entries,cn=plugins,cn=config >> mepManagedBy: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan >> description: ipaNetgroup oepp_hosts >> memberHost: cn=oepp_hosts,cn=hostgroups,cn=accounts,dc=local,dc=lan >> cn: oepp_hosts >> nisDomainName: mgmt.prod.local.lan > And value of this attribute is an explanation to your question > why there is a different domain in netgroups. > >> objectClass: ipanisnetgroup >> objectClass: ipaobject >> objectClass: mepManagedEntry >> objectClass: ipaAssociation >> objectClass: top >> nsUniqueId: f834f7a7-f91c11e6-a7d5eda5-d52d2b10 > LS Hi Jakub, Having looked into this in more detail and I think the route of the problem is that the first master created was ipa001.mgmt.prod.local.lan and therefore mgmt.prod.local.lan seems to have been taken as the default domain for netgroups even though both the domain and realm were set as local.lan. In the original configuration the first master was ipa001.local.lan. It was eventually replaced with ipa001.mgmt.prod.local.lan via replication but that original base level seems to have stuck. Can this base setting of mgmt.prod.local.lan somehow be changed to local.lan so that newly created netgroups get this as their nisdomain ? Thanks Bob From bob at rha-ltd.co.uk Sat Mar 18 15:11:43 2017 From: bob at rha-ltd.co.uk (Bob Hinton) Date: Sat, 18 Mar 2017 15:11:43 +0000 Subject: [Freeipa-users] default nisdomain appears to be derived from hostname of first master rather than set to domain or realm. Bug ? In-Reply-To: <20170317140156.GC3625@10.4.128.1> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> <20170317140156.GC3625@10.4.128.1> Message-ID: <3c26ec58-bef5-8d0e-f0b8-8b24242cb036@rha-ltd.co.uk> Hi, The first IPA master we built was ipa001.local.lan. We have since created a number of subdomains of local.lan and have created a number of replicas. The current configuration has two clusters of IPA replicas - ipa001.mgmt.prod.local.lan to ipa003.mgmt.prod.local.lan and ipa001.mgmt.paas.local.lan to ipa003.mgmt.paas.local.lan We've recently commenced migrating some of the existing systems to a new environment and for various reasons have started with a fresh master - ipa001.mgmt.prod.local.lan. Quite a lot of sudo rules don't work in the new environment. As far as I can tell this is because the shadow netgroups have a nisdomain of mgmt.prod.local.lan instead of local.lan. I would have thought that the nisdomain should be set to either the domain or realm i.e. local.lan rather than seemingly taken from the network portion of the first master mgmt.prod.local.lan. Is this correct ? Is there a way to change the default nisdomain ? Rebuilding all the new IPA masters and migrating all the data again would be a lot of work. Many thanks Bob Hinton From abokovoy at redhat.com Sat Mar 18 17:03:49 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 18 Mar 2017 19:03:49 +0200 Subject: [Freeipa-users] default nisdomain appears to be derived from hostname of first master rather than set to domain or realm. Bug ? In-Reply-To: <3c26ec58-bef5-8d0e-f0b8-8b24242cb036@rha-ltd.co.uk> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> <20170317140156.GC3625@10.4.128.1> <3c26ec58-bef5-8d0e-f0b8-8b24242cb036@rha-ltd.co.uk> Message-ID: <20170318170349.t5ezspxr5zqmwf6r@redhat.com> On la, 18 maalis 2017, Bob Hinton wrote: >Hi, > >The first IPA master we built was ipa001.local.lan. We have since >created a number of subdomains of local.lan and have created a number of >replicas. The current configuration has two clusters of IPA replicas - >ipa001.mgmt.prod.local.lan to ipa003.mgmt.prod.local.lan and >ipa001.mgmt.paas.local.lan to ipa003.mgmt.paas.local.lan > >We've recently commenced migrating some of the existing systems to a new >environment and for various reasons have started with a fresh master - >ipa001.mgmt.prod.local.lan. > >Quite a lot of sudo rules don't work in the new environment. As far as I >can tell this is because the shadow netgroups have a nisdomain of >mgmt.prod.local.lan instead of local.lan. > >I would have thought that the nisdomain should be set to either the >domain or realm i.e. local.lan rather than seemingly taken from the >network portion of the first master mgmt.prod.local.lan. Is this correct ? > >Is there a way to change the default nisdomain ? Rebuilding all the new >IPA masters and migrating all the data again would be a lot of work. The code that handles 'ipa netgroup-add' defaults to IPA domain as default NIS domain name. You can change that by explicitly adding '--nisdomain=specific.nis.domain' to 'ipa netgroup-add'. You can change it for existing netgroups by specifying --nisdomain option to 'ipa netgroup-mod'. -- / Alexander Bokovoy From bob at rha-ltd.co.uk Sat Mar 18 17:28:03 2017 From: bob at rha-ltd.co.uk (Bob Hinton) Date: Sat, 18 Mar 2017 17:28:03 +0000 Subject: [Freeipa-users] default nisdomain appears to be derived from hostname of first master rather than set to domain or realm. Bug ? In-Reply-To: <20170318170349.t5ezspxr5zqmwf6r@redhat.com> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> <20170317140156.GC3625@10.4.128.1> <3c26ec58-bef5-8d0e-f0b8-8b24242cb036@rha-ltd.co.uk> <20170318170349.t5ezspxr5zqmwf6r@redhat.com> Message-ID: On 18/03/2017 17:03, Alexander Bokovoy wrote: > On la, 18 maalis 2017, Bob Hinton wrote: >> Hi, >> >> The first IPA master we built was ipa001.local.lan. We have since >> created a number of subdomains of local.lan and have created a number of >> replicas. The current configuration has two clusters of IPA replicas - >> ipa001.mgmt.prod.local.lan to ipa003.mgmt.prod.local.lan and >> ipa001.mgmt.paas.local.lan to ipa003.mgmt.paas.local.lan >> >> We've recently commenced migrating some of the existing systems to a new >> environment and for various reasons have started with a fresh master - >> ipa001.mgmt.prod.local.lan. >> >> Quite a lot of sudo rules don't work in the new environment. As far as I >> can tell this is because the shadow netgroups have a nisdomain of >> mgmt.prod.local.lan instead of local.lan. >> >> I would have thought that the nisdomain should be set to either the >> domain or realm i.e. local.lan rather than seemingly taken from the >> network portion of the first master mgmt.prod.local.lan. Is this >> correct ? >> >> Is there a way to change the default nisdomain ? Rebuilding all the new >> IPA masters and migrating all the data again would be a lot of work. > The code that handles 'ipa netgroup-add' defaults to IPA domain as > default NIS domain name. You can change that by explicitly adding > '--nisdomain=specific.nis.domain' to 'ipa netgroup-add'. You can change > it for existing netgroups by specifying --nisdomain option to 'ipa > netgroup-mod'. > Hi Alexander, Thanks for the information. Unfortunately, it's the shadow netgroups created for hostgroups that are the problem. These aren't visible so can I modify them with "ipa netgroup-mod" ? Also the default NIS domain name doesn't match the IPA domain on our system, which is why I'm wondering if we've hit a bug. This is IPA version 4.4.0. Many thanks Bob From arequipeno at gmail.com Sat Mar 18 16:58:35 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Sat, 18 Mar 2017 11:58:35 -0500 Subject: [Freeipa-users] Use SQLite format NSS database? Message-ID: Can IPA 4.4 (on CentOS 7) use a SQLite format NSS database in /etc/httpd/alias? I would presumably have to prepend "sql:" to the NSSCertificateDatabase setting in nss.conf. Anything else? -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From abokovoy at redhat.com Sat Mar 18 19:09:20 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 18 Mar 2017 21:09:20 +0200 Subject: [Freeipa-users] default nisdomain appears to be derived from hostname of first master rather than set to domain or realm. Bug ? In-Reply-To: References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> <20170317140156.GC3625@10.4.128.1> <3c26ec58-bef5-8d0e-f0b8-8b24242cb036@rha-ltd.co.uk> <20170318170349.t5ezspxr5zqmwf6r@redhat.com> Message-ID: <20170318190920.zdx77vtdzrgnczio@redhat.com> On la, 18 maalis 2017, Bob Hinton wrote: >On 18/03/2017 17:03, Alexander Bokovoy wrote: >> On la, 18 maalis 2017, Bob Hinton wrote: >>> Hi, >>> >>> The first IPA master we built was ipa001.local.lan. We have since >>> created a number of subdomains of local.lan and have created a number of >>> replicas. The current configuration has two clusters of IPA replicas - >>> ipa001.mgmt.prod.local.lan to ipa003.mgmt.prod.local.lan and >>> ipa001.mgmt.paas.local.lan to ipa003.mgmt.paas.local.lan >>> >>> We've recently commenced migrating some of the existing systems to a new >>> environment and for various reasons have started with a fresh master - >>> ipa001.mgmt.prod.local.lan. >>> >>> Quite a lot of sudo rules don't work in the new environment. As far as I >>> can tell this is because the shadow netgroups have a nisdomain of >>> mgmt.prod.local.lan instead of local.lan. >>> >>> I would have thought that the nisdomain should be set to either the >>> domain or realm i.e. local.lan rather than seemingly taken from the >>> network portion of the first master mgmt.prod.local.lan. Is this >>> correct ? >>> >>> Is there a way to change the default nisdomain ? Rebuilding all the new >>> IPA masters and migrating all the data again would be a lot of work. >> The code that handles 'ipa netgroup-add' defaults to IPA domain as >> default NIS domain name. You can change that by explicitly adding >> '--nisdomain=specific.nis.domain' to 'ipa netgroup-add'. You can change >> it for existing netgroups by specifying --nisdomain option to 'ipa >> netgroup-mod'. >> >Hi Alexander, > >Thanks for the information. Unfortunately, it's the shadow netgroups >created for hostgroups that are the problem. These aren't visible so can >I modify them with "ipa netgroup-mod" ? Also the default NIS domain name >doesn't match the IPA domain on our system, which is why I'm wondering >if we've hit a bug. This is IPA version 4.4.0. Got you. No, this is not a bug, you can fix your setup by specifying a different nisDomainName in the NGP HGP template definition. This would change default nisDomainName for new netgroups. For existing ones you would need to go and change nisDomainName attribute manually. You can do both of these operations with ipa-ldap-updater tool. 1. Changing default nisDomainName in the NGP HGP template. First, check what nisDomainName value is in the template. Let's assume your domain suffix is dc=example,dc=com below. I'll replace it with $DOMAINDN in the output for brevity. ----- # export DOMAINDN='dc=example,dc=com' # ldapsearch -H `cat /etc/ipa/default.conf |grep ldap_uri|cut -d' ' -f3` -b "cn=NGP HGP Template,cn=Templates,cn=Managed Entries,cn=etc,$DOMAINDN" SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # NGP HGP Template, Templates, Managed Entries, etc, example.com dn: cn=NGP HGP Template,cn=Templates,cn=Managed Entries,cn=etc,$DOMAINDN objectClass: mepTemplateEntry objectClass: top cn: NGP HGP Template mepRDNAttr: cn mepStaticAttr: ipaUniqueId: autogenerate mepStaticAttr: objectclass: ipanisnetgroup mepStaticAttr: objectclass: ipaobject mepStaticAttr: nisDomainName: example.com mepMappedAttr: cn: $cn mepMappedAttr: memberHost: $dn mepMappedAttr: description: ipaNetgroup $cn # search result search: 3 result: 0 Success # numResponses: 2 # numEntries: 1 ----- You can see 'mepStaticAttr: nisDomainName: example.com' there. This is the attribute and the value we should replace. Now create an update file that replaces nisDomainName with a new one. ----- # cat 80-change-nisdomainname.update dn: cn=NGP HGP Template,cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX replace:mepStaticAttr:nisDomainName: example.com::nisDomainName: newexample.com ----- In the update file above $SUFFIX is one of variables recognized by ipa-ldap-updater tool. Read its man page for more details. Run the tool: ----- # ipa-ldap-updater ./80-change-nisdomainname.update Update complete The ipa-ldap-updater command was successful ----- Now you can use the same ldapsearch command to verify that nisDomainName was changed in the template definition. 2. Change nisDomainName in the MEP entries. Since NGP HGP template uses mepStaticAttr to define nisDomainName attribute in the MEP entries generated with the help of this template, you need to change individual entries now. To do so you can gather DNs of the entries and create an update file that changes all of them in one go: ----- # ldapsearch -Q -H `cat /etc/ipa/default.conf |grep ldap_uri|cut -d' ' -f3` \ -b cn=ng,cn=alt,$DOMAINDN \ '(&(nisDomainName=example.com)(objectclass=mepManagedEntry))' -LL dn |\ grep dn: | cut -d: -f2- |\ xargs -n1 printf "dn: %s\nreplace:nisDomainName: example.com::newexample.com\n\n" ----- The pipeline above looks through entries in cn=ng,cn=alt,$DOMAINDN that were generated by MEP plugin (objectclass=mepManagedEntry) and has nisDomainName set to example.com. For these entries their DNs printed out and their values used to construct two new lines per each output. This would generate output similar to what I have below: ----- dn: cn=myhostgroup,cn=ng,cn=alt,dc=xs,dc=example,dc=com replace:nisDomainName: example.com::myexample.com ----- If you redirect the output to a file named NN-some-name.update where NN is between 00 and 90 (this is not documented in the man page, sorry), then you can supply this file to ipa-ldap-updater similar how we did it in the step 1. -- / Alexander Bokovoy From bob at jackland.demon.co.uk Sat Mar 18 21:49:20 2017 From: bob at jackland.demon.co.uk (Bob Hinton) Date: Sat, 18 Mar 2017 21:49:20 +0000 Subject: [Freeipa-users] default nisdomain appears to be derived from hostname of first master rather than set to domain or realm [SOLVED] In-Reply-To: <20170318190920.zdx77vtdzrgnczio@redhat.com> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> <20170317140156.GC3625@10.4.128.1> <3c26ec58-bef5-8d0e-f0b8-8b24242cb036@rha-ltd.co.uk> <20170318170349.t5ezspxr5zqmwf6r@redhat.com> <20170318190920.zdx77vtdzrgnczio@redhat.com> Message-ID: On 18/03/2017 19:09, Alexander Bokovoy wrote: > On la, 18 maalis 2017, Bob Hinton wrote: >> On 18/03/2017 17:03, Alexander Bokovoy wrote: >>> On la, 18 maalis 2017, Bob Hinton wrote: >>>> Hi, >>>> >>>> The first IPA master we built was ipa001.local.lan. We have since >>>> created a number of subdomains of local.lan and have created a >>>> number of >>>> replicas. The current configuration has two clusters of IPA replicas - >>>> ipa001.mgmt.prod.local.lan to ipa003.mgmt.prod.local.lan and >>>> ipa001.mgmt.paas.local.lan to ipa003.mgmt.paas.local.lan >>>> >>>> We've recently commenced migrating some of the existing systems to >>>> a new >>>> environment and for various reasons have started with a fresh master - >>>> ipa001.mgmt.prod.local.lan. >>>> >>>> Quite a lot of sudo rules don't work in the new environment. As far >>>> as I >>>> can tell this is because the shadow netgroups have a nisdomain of >>>> mgmt.prod.local.lan instead of local.lan. >>>> >>>> I would have thought that the nisdomain should be set to either the >>>> domain or realm i.e. local.lan rather than seemingly taken from the >>>> network portion of the first master mgmt.prod.local.lan. Is this >>>> correct ? >>>> >>>> Is there a way to change the default nisdomain ? Rebuilding all the >>>> new >>>> IPA masters and migrating all the data again would be a lot of work. >>> The code that handles 'ipa netgroup-add' defaults to IPA domain as >>> default NIS domain name. You can change that by explicitly adding >>> '--nisdomain=specific.nis.domain' to 'ipa netgroup-add'. You can change >>> it for existing netgroups by specifying --nisdomain option to 'ipa >>> netgroup-mod'. >>> >> Hi Alexander, >> >> Thanks for the information. Unfortunately, it's the shadow netgroups >> created for hostgroups that are the problem. These aren't visible so can >> I modify them with "ipa netgroup-mod" ? Also the default NIS domain name >> doesn't match the IPA domain on our system, which is why I'm wondering >> if we've hit a bug. This is IPA version 4.4.0. > Got you. No, this is not a bug, you can fix your setup by specifying a > different nisDomainName in the NGP HGP template definition. This would > change default nisDomainName for new netgroups. For existing ones you > would need to go and change nisDomainName attribute manually. > > You can do both of these operations with ipa-ldap-updater tool. > > 1. Changing default nisDomainName in the NGP HGP template. > > First, check what > nisDomainName value is in the template. Let's assume your domain suffix > is dc=example,dc=com below. I'll replace it with $DOMAINDN in the output > for brevity. > > ----- > # export DOMAINDN='dc=example,dc=com' > # ldapsearch -H `cat /etc/ipa/default.conf |grep ldap_uri|cut -d' ' > -f3` -b "cn=NGP HGP Template,cn=Templates,cn=Managed > Entries,cn=etc,$DOMAINDN" > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > # extended LDIF > # > # LDAPv3 > # base Entries,cn=etc,$DOMAINDN> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # NGP HGP Template, Templates, Managed Entries, etc, example.com > dn: cn=NGP HGP Template,cn=Templates,cn=Managed Entries,cn=etc,$DOMAINDN > objectClass: mepTemplateEntry > objectClass: top > cn: NGP HGP Template > mepRDNAttr: cn > mepStaticAttr: ipaUniqueId: autogenerate > mepStaticAttr: objectclass: ipanisnetgroup > mepStaticAttr: objectclass: ipaobject > mepStaticAttr: nisDomainName: example.com > mepMappedAttr: cn: $cn > mepMappedAttr: memberHost: $dn > mepMappedAttr: description: ipaNetgroup $cn > > # search result > search: 3 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > ----- > > You can see 'mepStaticAttr: nisDomainName: example.com' there. This is > the attribute and the value we should replace. > > Now create an update file that replaces nisDomainName with a new one. > > ----- > # cat 80-change-nisdomainname.update dn: cn=NGP HGP > Template,cn=Templates,cn=Managed Entries,cn=etc,$SUFFIX > replace:mepStaticAttr:nisDomainName: example.com::nisDomainName: > newexample.com > ----- > > In the update file above $SUFFIX is one of variables recognized by > ipa-ldap-updater tool. Read its man page for more details. > > Run the tool: > > ----- > # ipa-ldap-updater ./80-change-nisdomainname.update > Update complete > The ipa-ldap-updater command was successful > ----- > > Now you can use the same ldapsearch command to verify that nisDomainName > was changed in the template definition. > > 2. Change nisDomainName in the MEP entries. > > Since NGP HGP template uses mepStaticAttr to define nisDomainName > attribute in the MEP entries generated with the help of this template, > you need to change individual entries now. To do so you can gather DNs > of the entries and create an update file that changes all of them in one > go: > > ----- > # ldapsearch -Q -H `cat /etc/ipa/default.conf |grep ldap_uri|cut -d' ' > -f3` \ > -b cn=ng,cn=alt,$DOMAINDN \ > > '(&(nisDomainName=example.com)(objectclass=mepManagedEntry))' -LL dn |\ > grep dn: | cut -d: -f2- |\ > xargs -n1 printf "dn: %s\nreplace:nisDomainName: > example.com::newexample.com\n\n" > ----- > > The pipeline above looks through entries in cn=ng,cn=alt,$DOMAINDN that > were generated by MEP plugin (objectclass=mepManagedEntry) and has > nisDomainName set to example.com. For these entries their DNs printed > out and their values used to construct two new lines per each output. > This would generate output similar to what I have below: > > ----- > dn: cn=myhostgroup,cn=ng,cn=alt,dc=xs,dc=example,dc=com > replace:nisDomainName: example.com::myexample.com > > ----- > > If you redirect the output to a file named NN-some-name.update where NN > is between 00 and 90 (this is not documented in the man page, sorry), > then you can supply this file to ipa-ldap-updater similar how we did it > in the step 1. > Hi Alexander, Worked a treat. Sudo rules for all the affected hostgroups now works. Many thanks. Bob From ianh at brownpapertickets.com Sun Mar 19 06:31:00 2017 From: ianh at brownpapertickets.com (Ian Harding) Date: Sat, 18 Mar 2017 23:31:00 -0700 Subject: [Freeipa-users] Manual Cleanup In-Reply-To: <6b6daa5e-870b-b29d-493f-d9e49229f10b@redhat.com> References: <64100809-8ca2-ea1b-e2fe-dc38740ffb8a@brownpapertickets.com> <6b6daa5e-870b-b29d-493f-d9e49229f10b@redhat.com> Message-ID: <0506d5ae-ac82-c1d2-9f72-3982936abe97@brownpapertickets.com> On 03/17/2017 12:25 AM, Standa Laznicka wrote: > Hello Ian, > > You could do: > `ipa-replica-manage del freeipa-dal.bpt.rocks --force --cleanup` > I have done this, it warns me that I should be careful, I say yes, and it returns almost immediately. The master still shows up [root at freeipa-sea ianh]# ipa-replica-manage del freeipa-dal.bpt.rocks --force --cleanup Cleaning a master is irreversible. This should not normally be require, so use cautiously. Continue to clean master? [no]: yes > Then you may need to check again for the master with `ipa-replica-manage > list`. If it's not there anymore, check whether some RUVs are still in > place with `ipa-replica-manage list-ruv`. > > The last command should get you RUVs on both CA and domain suffixes if > you're using FreeIPA >= 4.3.2 (hope I got the .z number right). If you > see that there's some RUVs left for the wrong host, try calling > `ipa-replica-manage clean-ruv ` which should remove the RUV (no > matter the suffix - CA or domain - just give it the number and it should > work given FreeIPA >= 4.3.2 is used). > There aren't any dangling RUV that I can see but the 'master' record is still there. [root at freeipa-sea ianh]# ipa-replica-manage list seattlenfs.bpt.rocks: master freeipa-dal.bpt.rocks: master freeipa-sea.bpt.rocks: master [root at freeipa-sea ianh]# ipa-replica-manage list freeipa-sea.bpt.rocks seattlenfs.bpt.rocks: replica [root at freeipa-sea ianh]# ipa-replica-manage list seattlenfs.bpt.rocks freeipa-sea.bpt.rocks: replica [root at freeipa-sea ianh]# ipa-replica-manage list-ruv Directory Manager password: Replica Update Vectors: freeipa-sea.bpt.rocks:389: 20 seattlenfs.bpt.rocks:389: 21 Certificate Server Replica Update Vectors: freeipa-sea.bpt.rocks:389: 1065 seattlenfs.bpt.rocks:389: 1290 Thanks for your help, but I think I need some ldapdelete magic. Does this mean anything to you? I manually removed every reference to freeipa-dal from dse.ldif and started the directory server I still see this: [root at freeipa-sea ianh]# ldapsearch -D "cn=directory manager" -W -b cn=config | grep freeipa-dal Enter LDAP Password: nsslapd-referral: ldap://freeipa-dal.bpt.rocks:389/o%3Dipaca I have to think it is stored somewhere else when the server is offline in a database file and gets inserted into the DSE at startup? I found a mess of references to freeipa-dal in this section. Is there a way to make it go away? [root at freeipa-sea ianh]# ldapsearch -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks' | grep freeipa-dalEnter LDAP Password: # freeipa-dal.bpt.rocks + f0b9918f-6a5011e6-a4bad0d8-a4feaa1b, masters, ipa, et dn: cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn cn: freeipa-dal.bpt.rocks # CA + 5148cf38-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b9918f-6a dn: cn=CA+nsuniqueid=5148cf38-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.ro # KDC + 5148cf40-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b9918f-6 dn: cn=KDC+nsuniqueid=5148cf40-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.r # KPASSWD + 5148cf41-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b991 dn: cn=KPASSWD+nsuniqueid=5148cf41-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.b # MEMCACHE + 5148cf42-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b99 dn: cn=MEMCACHE+nsuniqueid=5148cf42-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal. # HTTP + 5148cf45-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b9918f- dn: cn=HTTP+nsuniqueid=5148cf45-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt. # OTPD + 5148cf46-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b9918f- dn: cn=OTPD+nsuniqueid=5148cf46-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt. # DNS + 9cfb790e-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b9918f-6 dn: cn=DNS+nsuniqueid=9cfb790e-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.r # DNSKeySync + 9cfb791b-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b [root at freeipa-sea ianh]# > HTH, > Standa > > On 03/16/2017 07:14 PM, Ian Harding wrote: >> I've made some progress. But I have one zombie replication agreement to >> kill, I just don't know the syntax. >> >> freeipa-dal.bpt.rocks does not exist. I want all references to it to go >> away. >> >> How would I do that with ldapmodify? >> >> Thanks! >> >> >> [root at freeipa-sea slapd-BPT-ROCKS]# ldapsearch -D "cn=directory >> manager" -w ... -b "o=ipaca" >> "(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" >> >> nscpentrywsi >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: >> (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) >> >> # requesting: nscpentrywsi >> # >> >> # replica, o\3Dipaca, mapping tree, config >> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config >> nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config >> nscpentrywsi: cn: replica >> nscpentrywsi: createTimestamp: 20160814234939Z >> nscpentrywsi: creatorsName: cn=directory manager >> nscpentrywsi: modifiersName: cn=Multimaster Replication >> Plugin,cn=plugins,cn=c >> onfig >> nscpentrywsi: modifyTimestamp: 20170316181544Z >> nscpentrywsi: nsDS5Flags: 1 >> nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager >> cloneAgreement1-freei >> pa-sea.bpt.rocks-pki-tomcat,ou=csusers,cn=config >> nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager >> masterAgreement1-free >> ipa-dal.bpt.rocks-pki-tomcat,ou=csusers,cn=config >> nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager >> masterAgreement1-seat >> tlenfs.bpt.rocks-pki-tomcat,ou=csusers,cn=config >> nscpentrywsi: nsDS5ReplicaId: 1065 >> nscpentrywsi: nsDS5ReplicaName: b21a1f1e-627911e6-93e6ef4b-69dcc2d1 >> nscpentrywsi: nsDS5ReplicaRoot: o=ipaca >> nscpentrywsi: nsDS5ReplicaType: 3 >> nscpentrywsi: nsState:: >> KQQAAAAAAABO1spYAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAAAAA >> == >> nscpentrywsi: nsds5replicabinddngroup: cn=replication >> managers,cn=sysaccounts, >> cn=etc,dc=bpt,dc=rocks >> nscpentrywsi: nsds5replicabinddngroupcheckinterval: 60 >> nscpentrywsi: objectClass: top >> nscpentrywsi: objectClass: nsDS5Replica >> nscpentrywsi: objectClass: extensibleobject >> nscpentrywsi: numSubordinates: 2 >> nscpentrywsi: nsds50ruv: {replicageneration} 57c291d9000004290000 >> nscpentrywsi: nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389} >> 57f84 >> 0bf000004290000 58cad667000004290000 >> nscpentrywsi: nsds50ruv: {replica 1290 ldap://seattlenfs.bpt.rocks:389} >> nscpentrywsi: nsds50ruv: {replica 1295 ldap://freeipa-dal.bpt.rocks:389} >> nscpentrywsi: nsds5agmtmaxcsn: >> o=ipaca;cloneAgreement1-freeipa-sea.bpt.rocks-p >> ki-tomcat;seattlenfs.bpt.rocks;389;unavailable >> nscpentrywsi: nsds5agmtmaxcsn: >> o=ipaca;masterAgreement1-seattlenfs.bpt.rocks-p >> ki-tomcat;seattlenfs.bpt.rocks;389;unavailable >> nscpentrywsi: nsruvReplicaLastModified: {replica 1065 >> ldap://freeipa-sea.bpt.r >> ocks:389} 58cad63d >> nscpentrywsi: nsruvReplicaLastModified: {replica 1290 >> ldap://seattlenfs.bpt.ro >> cks:389} 00000000 >> nscpentrywsi: nsruvReplicaLastModified: {replica 1295 >> ldap://freeipa-dal.bpt.r >> ocks:389} 00000000 >> nscpentrywsi: nsds5ReplicaChangeCount: 15993 >> nscpentrywsi: nsds5replicareapactive: 0 >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> [root at freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage del >> freeipa-dal.bpt.rocks --forceDirectory Manager password: >> >> 'freeipa-sea.bpt.rocks' has no replication agreement for >> 'freeipa-dal.bpt.rocks' >> [root at freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list >> seattlenfs.bpt.rocks: master >> freeipa-dal.bpt.rocks: master >> freeipa-sea.bpt.rocks: master >> [root at freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list >> freeipa-sea.bpt.rocks >> seattlenfs.bpt.rocks: replica >> [root at freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage list >> Directory Manager password: >> >> seattlenfs.bpt.rocks: master >> freeipa-dal.bpt.rocks: CA not configured >> freeipa-sea.bpt.rocks: master >> > -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com From marc.boorshtein at tremolosecurity.com Sun Mar 19 13:53:38 2017 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Sun, 19 Mar 2017 13:53:38 +0000 Subject: [Freeipa-users] different apis for adding "local" users to groups vs adding users from cft? In-Reply-To: <20170318062729.shcc4uwjqrnhnvsf@redhat.com> References: <20170318062729.shcc4uwjqrnhnvsf@redhat.com> Message-ID: As of yet I haven't tried using the json rpc with a cft. freeipa is on its own. i'll give it a try and if it doesn't work this will point me in the right direction. Thanks On Sat, Mar 18, 2017 at 2:27 AM Alexander Bokovoy wrote: > On pe, 17 maalis 2017, Marc Boorshtein wrote: > >I've got the api integrated for all local users and am looking at if > >there are any differences between that and if my ipa domain is in a > >CFT with an AD domain. Right now I'm using "group_add_member", should > >that work for users coming from a trusted forest as well? > EPARSE, but I'll try to understand what are you trying to achieve. > > If you were using > ipa group-add-member external_group --external user at AD.DOMAIN > to add AD users as external members of a group, you continue using the > same command on API level: > > api.Command.group_add_member(u'external_group', > external=u'user at AD.DOMAIN'}) > > Same with JSON-RPC. > > > -- > / Alexander Bokovoy > -- Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 Twitter - @mlbiam / @tremolosecurity -------------- next part -------------- An HTML attachment was scrubbed... URL: From datakid at gmail.com Sun Mar 19 21:58:09 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Mon, 20 Mar 2017 08:58:09 +1100 Subject: [Freeipa-users] Errors in IPA logs Message-ID: Hi, I've reported a bug against SSSD and Lukas has pointed to a number of FreeIPA errors in our logs. I've can't find any information on how I might fix these errors or what I might do to mitigate them. Any pointers appreciated: First error: [sssd[be[unixdev.domain.org.au]]] [ipa_sudo_fetch_rules_done] (0x0040): Received 1 sudo rules [sssd[be[unixdev.domain.org.au]]] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such attribute](16)[attribute 'member': no matching attribute value while deleting attribute on 'name= ipa_bioinf_staff at unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb'] [sssd[be[unixdev.domain.org.au]]] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute] [sssd[be[unixdev.domain.org.au]]] [sysdb_update_members_ex] (0x0020): Could not remove member [SimpsonLachlan at domain.org.au] from group [name= ipa_bioinf_staff at unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb]. Skipping Second error is long list of errors that look like [sssd[be]] [get_ipa_groupname] (0x0020): Expected cn in second component, got OU [sssd[be]] [get_ipa_groupname] (0x0020): Expected groups second component, got Users I don't know enough about AD to speak meaningfully to these, but a quick google shows that a group can have cn=Users as it's second component ( see here for example https://technet.microsoft.com/en-us/library/dn579255%28v=ws.11%29.aspx ) Is there an LDAP query that I need to define or add to the IPA server? cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwf at loonybin.net Mon Mar 20 01:22:15 2017 From: rwf at loonybin.net (Rob Foehl) Date: Sun, 19 Mar 2017 21:22:15 -0400 (EDT) Subject: [Freeipa-users] Options for existing CA/DNS infrastructure In-Reply-To: References: Message-ID: On Sun, 12 Mar 2017, Rob Foehl wrote: > What's the best way to play nice with existing PKI -- generate a CA CSR at > installation time and sign that? Is there any provision for automatically > renewing these certs, say if the external CA were to be subsumed by a > dedicated Dogtag instance? I'm guessing the complete lack of a response does not bode well for this idea... Ideally, I'd rather not manage an external CA at all; existing use cases are service certificates and a handful of user or device-specific client certs. I've been digging into the sub-CA support a bit more, and it might be possible to cover everything within FreeIPA, possibly adding otherwise-unused principals as needed. The lingering question, then: what to do with the existing CA? I've found a few threads suggesting it may be possible to wedge an existing cert/key into a new IPA instance at install time, but they're all light on specifics. Any other ideas for a smooth transition from this CA to one entirely owned by FreeIPA, maybe within 3 years or so? ;) -Rob From jhrozek at redhat.com Mon Mar 20 08:29:26 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 20 Mar 2017 09:29:26 +0100 Subject: [Freeipa-users] shadow netgroups with wrong domains - sudo problem In-Reply-To: <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> Message-ID: <20170320082926.ju45syjirzhsoogq@hendrix> On Fri, Mar 17, 2017 at 01:52:17PM +0000, Bob Hinton wrote: > On 17/03/2017 12:48, Lukas Slebodnik wrote: > > On (17/03/17 10:40), Bob Hinton wrote: > >> On 17/03/2017 08:41, Jakub Hrozek wrote: > >>> On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote: > >>>> Morning, > >>>> > >>>> We have a collection of hosts within prod1.local.lan. However, the > >>>> domain section of the shadow netgroups for the hosts is > >>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these > >>>> hosts unless they specify all hosts - > >>>> > >>>> -sh-4.2$ getent netgroup oepp_hosts > >>>> oepp_hosts > >>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) > >>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) > >>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) > >>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) > >>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) > >>>> -sh-4.2$ hostname > >>>> oeppredis001.z4.prod1.local.lan > >>>> -sh-4.2$ nisdomainname > >>>> local.lan > >>>> -sh-4.2$ domainname > >>>> local.lan > >>>> > >>>> The VMs associated with these hosts have recently been migrated and > >>>> re-enrolled against a new IPA server. The originals all had netgroup > >>>> domains of local.lan so something must have gone wrong in the migration > >>>> process. Is there a way to correct the netgroup domains of these hosts, > >>>> or is the only option to run ipa-client-install --uninstall followed by > >>>> ipa-client-install to reattach them ? > >>> Did you remove the sssd cache after the migration? > >>> rm -f /var/lib/sss/db/*.ldb > >>> > >>> (please make sure the clients can reach the server or maybe mv the cache > >>> instead of rm so you can restore cached credentials if something goes > >>> wrong..) > >>> > >> Hi Jakub, > >> > >> I've now tried removing the sssd cache on one of the offending servers > >> and it's not made any difference. > >> > >> getent netgroup oepp_hosts > >> > >> when run from any host enrolled to the new IPA servers, including the > >> IPA masters themselves produces the results with "mgmt.prod" included > >> and the same thing run on any of the pre-migrated servers that are still > >> commissioned produces them without, so I assume that the netgroup domain > >> information is coming from the IPA masters rather than the local host. > >> > > Could you provide content of LDIF from IPA server? > > For this netgroup/hostgroup > > > > LS > > Hi Jakub, > > I extracted the following from the userRoot ldif produced by "ipa-backup > --data". > > It appears to have the incorrect domain set against nisDomainName. Could > this be changed with ldapmodify ? Sorry, I'm not sure. I hope someone with better insight into the IPA framework knows. From dkupka at redhat.com Mon Mar 20 08:29:41 2017 From: dkupka at redhat.com (David Kupka) Date: Mon, 20 Mar 2017 09:29:41 +0100 Subject: [Freeipa-users] Options for existing CA/DNS infrastructure In-Reply-To: References: Message-ID: <20170320082941.GB26690@dkupka.usersys.redhat.com> On Sun, Mar 12, 2017 at 10:47:02PM -0400, Rob Foehl wrote: > I'm looking at deploying FreeIPA in a few environments with substantial DNS > and/or CA infrastructure, and have some choices to make... > > How much trouble will I have if FreeIPA is delegated a zone like > ipa.example.com with all clients in example.com or other children? (No > overlap with AD-managed zones, but in at least one case autodiscovery won't > be possible due to mixed clients in the parent zone.) > > What's the best way to play nice with existing PKI -- generate a CA CSR at > installation time and sign that? Is there any provision for automatically > renewing these certs, say if the external CA were to be subsumed by a > dedicated Dogtag instance? > > Advice and experience appreciated, before I paint myself into a corner > somewhere... Thanks! > > -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 Hello Rob, FreeIPA can be deployed in environment with existing DNS and/or CA server. IIRC you have following options: - regarding DNS: -- Delegate DNS zone for FreeIPA. It will then manage the zone and add records there. Obviously, it will not add records for clients in other zones. -- Don't setup DNS in FreeIPA and keep managing all records in your current DNS server. There's plan to integrate with external DNS servers [1] but nothing was done yet. - regarding CA: -- install CA-less FreeIPA - you need to issue certificates for HTTPD and 389-DS with your certificate server and provide those when installing FreeIPA server -- install FreeIPA with CA certificate signed with external CA. Use --external-ca option. The installation will be interupted to let you sign generated CSR. FreeIPA will then issue all needed certificates. -- install FreeIPA with self-signed CA certificate. This is default but then you need to distribute the certificate to all clients. Certmonger [2] is configured during ipa-server-install to track and renew certificates. [1] https://www.freeipa.org/page/V4/External_DNS_integration_with_installer [2] https://pagure.io/certmonger -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From bob at rha-ltd.co.uk Mon Mar 20 08:35:33 2017 From: bob at rha-ltd.co.uk (Bob Hinton) Date: Mon, 20 Mar 2017 08:35:33 +0000 Subject: [Freeipa-users] shadow netgroups with wrong domains - sudo problem [SOLVED] In-Reply-To: <20170320082926.ju45syjirzhsoogq@hendrix> References: <20170317084151.es4gclhtu4drsnv2@hendrix> <133d1e38-757f-f363-b38d-aff78b362abf@rha-ltd.co.uk> <20170317124857.GA3281@10.4.128.1> <29d0ee7b-5d7b-4faa-50ed-d1cb41245f9d@rha-ltd.co.uk> <20170320082926.ju45syjirzhsoogq@hendrix> Message-ID: <69622ed5-5649-0680-fa28-9b8cc833cfca@rha-ltd.co.uk> On 20/03/2017 08:29, Jakub Hrozek wrote: > On Fri, Mar 17, 2017 at 01:52:17PM +0000, Bob Hinton wrote: >> On 17/03/2017 12:48, Lukas Slebodnik wrote: >>> On (17/03/17 10:40), Bob Hinton wrote: >>>> On 17/03/2017 08:41, Jakub Hrozek wrote: >>>>> On Fri, Mar 17, 2017 at 06:50:34AM +0000, Bob Hinton wrote: >>>>>> Morning, >>>>>> >>>>>> We have a collection of hosts within prod1.local.lan. However, the >>>>>> domain section of the shadow netgroups for the hosts is >>>>>> mgmt.prod.local.lan. This seems to prevent sudo rules working on these >>>>>> hosts unless they specify all hosts - >>>>>> >>>>>> -sh-4.2$ getent netgroup oepp_hosts >>>>>> oepp_hosts >>>>>> (oeppsdas001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppsdas002.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppservice001.z2.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppredis002.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> (oeppredis001.z4.prod1.local.lan,-,mgmt.prod.local.lan) >>>>>> -sh-4.2$ hostname >>>>>> oeppredis001.z4.prod1.local.lan >>>>>> -sh-4.2$ nisdomainname >>>>>> local.lan >>>>>> -sh-4.2$ domainname >>>>>> local.lan >>>>>> >>>>>> The VMs associated with these hosts have recently been migrated and >>>>>> re-enrolled against a new IPA server. The originals all had netgroup >>>>>> domains of local.lan so something must have gone wrong in the migration >>>>>> process. Is there a way to correct the netgroup domains of these hosts, >>>>>> or is the only option to run ipa-client-install --uninstall followed by >>>>>> ipa-client-install to reattach them ? >>>>> Did you remove the sssd cache after the migration? >>>>> rm -f /var/lib/sss/db/*.ldb >>>>> >>>>> (please make sure the clients can reach the server or maybe mv the cache >>>>> instead of rm so you can restore cached credentials if something goes >>>>> wrong..) >>>>> >>>> Hi Jakub, >>>> >>>> I've now tried removing the sssd cache on one of the offending servers >>>> and it's not made any difference. >>>> >>>> getent netgroup oepp_hosts >>>> >>>> when run from any host enrolled to the new IPA servers, including the >>>> IPA masters themselves produces the results with "mgmt.prod" included >>>> and the same thing run on any of the pre-migrated servers that are still >>>> commissioned produces them without, so I assume that the netgroup domain >>>> information is coming from the IPA masters rather than the local host. >>>> >>> Could you provide content of LDIF from IPA server? >>> For this netgroup/hostgroup >>> >>> LS >> Hi Jakub, >> >> I extracted the following from the userRoot ldif produced by "ipa-backup >> --data". >> >> It appears to have the incorrect domain set against nisDomainName. Could >> this be changed with ldapmodify ? > Sorry, I'm not sure. I hope someone with better insight into the IPA > framework knows. Morning Jakub, I sent a related post "default nisdomain appears to be derived from hostname of first master rather than set to domain or realm" and Alexander Bukovoy explained how to fix this. Many Thanks Bob Hinton From mbasti at redhat.com Mon Mar 20 08:38:19 2017 From: mbasti at redhat.com (Martin Basti) Date: Mon, 20 Mar 2017 09:38:19 +0100 Subject: [Freeipa-users] Errors in IPA logs In-Reply-To: References: Message-ID: <9dc27850-dfa0-9f06-c025-28c930613597@redhat.com> On 19.03.2017 22:58, Lachlan Musicman wrote: > Hi, > > I've reported a bug against SSSD and Lukas has pointed to a number of > FreeIPA errors in our logs. > I've can't find any information on how I might fix these errors or > what I might do to mitigate them. Any pointers appreciated: > > First error: > > [sssd[be[unixdev.domain.org.au ]]] > [ipa_sudo_fetch_rules_done] (0x0040): Received 1 sudo rules > > [sssd[be[unixdev.domain.org.au ]]] > [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such > attribute](16)[attribute 'member': no matching attribute value while > deleting attribute on 'name=ipa_bioinf_staff at unixdev.domain.org.au > ,cn=groups,cn=unixdev.domain.org.au > ,cn=sysdb'] > > [sssd[be[unixdev.domain.org.au ]]] > [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No > such attribute] > > [sssd[be[unixdev.domain.org.au ]]] > [sysdb_update_members_ex] (0x0020): Could not remove member > [SimpsonLachlan at domain.org.au ] > from group [name=ipa_bioinf_staff at unixdev.domain.org.au > ,cn=groups,cn=unixdev.domain.org.au > ,cn=sysdb]. Skipping > > > > Second error is long list of errors that look like > > > [sssd[be]] [get_ipa_groupname] (0x0020): Expected cn in second > component, got OU > > [sssd[be]] [get_ipa_groupname] (0x0020): Expected groups second > component, got Users > > > I don't know enough about AD to speak meaningfully to these, but a > quick google shows that a group can have cn=Users as it's second > component ( see here for example > https://technet.microsoft.com/en-us/library/dn579255%28v=ws.11%29.aspx ) > > Is there an LDAP query that I need to define or add to the IPA server? > > cheers > L. > > > > ------ > The most dangerous phrase in the language is, "We've always done it > this way." > > - Grace Hopper > > Hello, can you describe your deployment more? Your DNs doesn't look like created by FreeIPA This is not how FreeIPA's DIT looks 'name=ipa_bioinf_staff at unixdev.domain.org.au ,cn=groups,cn=unixdev.domain.org.au ,cn=sysdb' Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From dkupka at redhat.com Mon Mar 20 09:00:27 2017 From: dkupka at redhat.com (David Kupka) Date: Mon, 20 Mar 2017 10:00:27 +0100 Subject: [Freeipa-users] Use SQLite format NSS database? In-Reply-To: References: Message-ID: <20170320090027.GC26690@dkupka.usersys.redhat.com> On Sat, Mar 18, 2017 at 11:58:35AM -0500, Ian Pilcher wrote: > Can IPA 4.4 (on CentOS 7) use a SQLite format NSS database in > /etc/httpd/alias? > > I would presumably have to prepend "sql:" to the NSSCertificateDatabase > setting in nss.conf. > > Anything else? > > -- > ======================================================================== > Ian Pilcher arequipeno at gmail.com > -------- "I grew up before Mark Zuckerberg invented friendship" -------- > ======================================================================== > > -- > 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 Hello Ian, I'm not sure but I guess there will be surprises on the way. First of all you need to migrate the DB to SQL format (1). Then you will have two DBs in alias directory one in old and one in new format. This is probably not what you want because then you can easily end up with two different sets of certificates and hard to find errors. So it's probably better to remove old DB (cert8.db, key3.db and secmod.db). But then you'll break ipa-certupdate, ipa-server-certinstall and probably others because they use the old format. Prefixing 'sql:' to HTTPD_ALIAS_DIR in /usr/lib/ptyhon2.7/site-packages/ipaplatform/base/paths.py might help but I never tried. Generally I would not recommend touching this on production system. Why do you want to change the database format? (1) certutil -d sql:HTTPD_ALIAS_DIR --upgrade-merge --source-dir HTTPD_ALIAS_DIR --upgrade-id 1 -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From datakid at gmail.com Mon Mar 20 09:16:48 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Mon, 20 Mar 2017 20:16:48 +1100 Subject: [Freeipa-users] Errors in IPA logs In-Reply-To: <9dc27850-dfa0-9f06-c025-28c930613597@redhat.com> References: <9dc27850-dfa0-9f06-c025-28c930613597@redhat.com> Message-ID: On 20 March 2017 at 19:38, Martin Basti wrote: > On 19.03.2017 22:58, Lachlan Musicman wrote: > > Hi, > > I've reported a bug against SSSD and Lukas has pointed to a number of > FreeIPA errors in our logs. > I've can't find any information on how I might fix these errors or what I > might do to mitigate them. Any pointers appreciated: > > First error: > > [sssd[be[unixdev.domain.org.au]]] [ipa_sudo_fetch_rules_done] (0x0040): > Received 1 sudo rules > > [sssd[be[unixdev.domain.org.au]]] [sysdb_mod_group_member] (0x0080): > ldb_modify failed: [No such attribute](16)[attribute 'member': no matching > attribute value while deleting attribute on 'name=ipa_bioinf_staff@ > unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb'] > > [sssd[be[unixdev.domain.org.au]]] [sysdb_error_to_errno] (0x0020): LDB > returned unexpected error: [No such attribute] > > [sssd[be[unixdev.domain.org.au]]] [sysdb_update_members_ex] (0x0020): > Could not remove member [SimpsonLachlan at domain.org.au] from group [name= > ipa_bioinf_staff at unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb]. > Skipping > > > > Second error is long list of errors that look like > > > [sssd[be]] [get_ipa_groupname] (0x0020): Expected cn in second component, > got OU > > [sssd[be]] [get_ipa_groupname] (0x0020): Expected groups second component, > got Users > > > I don't know enough about AD to speak meaningfully to these, but a quick > google shows that a group can have cn=Users as it's second component ( see > here for example https://technet.microsoft.com/ > en-us/library/dn579255%28v=ws.11%29.aspx ) > > Is there an LDAP query that I need to define or add to the IPA server? > > cheers > L. > > > Hello, > > can you describe your deployment more? Your DNs doesn't look like created > by FreeIPA > This is not how FreeIPA's DIT looks 'name=ipa_bioinf_staff@ > unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb' > DNS isn't done by FreeIPA - it's all in AD. With a one way trust and all users and groups managed by AD - except for overrides and external groups for HBAC - everything is in AD. As for the FreeIPA DIT - that is a group created in FreeIPA (through the GUI iirc). I haven't done anything particularly special to make it look like that (with the domain inside the cn). Unless it's a strange confluence of configurations that has created a situation that would make that happen. cheers L. So, wrt to your question, what can I give you/what were you after? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Mar 20 09:28:49 2017 From: mbasti at redhat.com (Martin Basti) Date: Mon, 20 Mar 2017 05:28:49 -0400 (EDT) Subject: [Freeipa-users] Errors in IPA logs In-Reply-To: References: <9dc27850-dfa0-9f06-c025-28c930613597@redhat.com> Message-ID: <1648689877.3942248.1490002129577.JavaMail.zimbra@redhat.com> ----- Original Message ----- From: "Lachlan Musicman" To: "Martin Basti" Cc: freeipa-users at redhat.com Sent: Monday, March 20, 2017 5:16:48 AM Subject: Re: [Freeipa-users] Errors in IPA logs On 20 March 2017 at 19:38, Martin Basti wrote: > On 19.03.2017 22:58, Lachlan Musicman wrote: > > Hi, > > I've reported a bug against SSSD and Lukas has pointed to a number of > FreeIPA errors in our logs. > I've can't find any information on how I might fix these errors or what I > might do to mitigate them. Any pointers appreciated: > > First error: > > [sssd[be[unixdev.domain.org.au]]] [ipa_sudo_fetch_rules_done] (0x0040): > Received 1 sudo rules > > [sssd[be[unixdev.domain.org.au]]] [sysdb_mod_group_member] (0x0080): > ldb_modify failed: [No such attribute](16)[attribute 'member': no matching > attribute value while deleting attribute on 'name=ipa_bioinf_staff@ > unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb'] > > [sssd[be[unixdev.domain.org.au]]] [sysdb_error_to_errno] (0x0020): LDB > returned unexpected error: [No such attribute] > > [sssd[be[unixdev.domain.org.au]]] [sysdb_update_members_ex] (0x0020): > Could not remove member [SimpsonLachlan at domain.org.au] from group [name= > ipa_bioinf_staff at unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb]. > Skipping > > > > Second error is long list of errors that look like > > > [sssd[be]] [get_ipa_groupname] (0x0020): Expected cn in second component, > got OU > > [sssd[be]] [get_ipa_groupname] (0x0020): Expected groups second component, > got Users > > > I don't know enough about AD to speak meaningfully to these, but a quick > google shows that a group can have cn=Users as it's second component ( see > here for example https://technet.microsoft.com/ > en-us/library/dn579255%28v=ws.11%29.aspx ) > > Is there an LDAP query that I need to define or add to the IPA server? > > cheers > L. > > > Hello, > > can you describe your deployment more? Your DNs doesn't look like created > by FreeIPA > This is not how FreeIPA's DIT looks 'name=ipa_bioinf_staff@ > unixdev.domain.org.au,cn=groups,cn=unixdev.domain.org.au,cn=sysdb' > DNS isn't done by FreeIPA - it's all in AD. With a one way trust and all users and groups managed by AD - except for overrides and external groups for HBAC - everything is in AD. As for the FreeIPA DIT - that is a group created in FreeIPA (through the GUI iirc). I haven't done anything particularly special to make it look like that (with the domain inside the cn). Unless it's a strange confluence of configurations that has created a situation that would make that happen. cheers L. So, wrt to your question, what can I give you/what were you after? Ah sorry the DN is from SSSD cache, so that's why it looks different. So why Lukas redirects you to FreeIPA? You posted only SSSD logs. From artem.golubev at expcapital.com Mon Mar 20 11:55:37 2017 From: artem.golubev at expcapital.com (Artem Golubev) Date: Mon, 20 Mar 2017 14:55:37 +0300 Subject: [Freeipa-users] Certificate Access issue Message-ID: Good day! We use freeipa server 4.3.1, we usually grant access via ssh keys to linux clients. We currently face the following issue with access on certificate: when we add certificate to user's account, user is not able to login via ssh. How can we solve this problem? We would like to have a possibility to access linux clients via ssh keys and access to other resources using certificates. Hope to receive a reply from you soon. Best regards. *?* *?Artem Golubev* System Administrator *(exp)capital limited* -------------- next part -------------- An HTML attachment was scrubbed... URL: From aebruno2 at buffalo.edu Mon Mar 20 13:52:43 2017 From: aebruno2 at buffalo.edu (Andrew E. Bruno) Date: Mon, 20 Mar 2017 09:52:43 -0400 Subject: [Freeipa-users] upgrade ipa-server fails changing dogtag key Message-ID: <20170320135243.ay7r6kvcs4a7ikxs@dead.ccr.buffalo.edu> When yum updating our ipa-server running CentOS 7.3.1611 from ipa-server-4.4.0-14.el7.centos.1.1.x86_64 to ipa-server-4.4.0-14.el7.centos.6.x86_64 we got this error: IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: OSError: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/dogtag.keytab' The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information Inspecting /var/log/ipaupgrade.log shows this error: 2017-03-20T12:58:41Z DEBUG Process finished, return code=0 2017-03-20T12:58:41Z DEBUG stdout=Authenticating as principal root/admin at REALM with password. 2017-03-20T12:58:41Z DEBUG stderr=kadmin.local: Server error while changing dogtag/host at REAM's key 2017-03-20T12:58:41Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2017-03-20T12:58:41Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 46, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1863, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1796, in upgrade_configuration ca.setup_lightweight_ca_key_retrieval() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1400, in setup_lightweight_ca_key_retrieval self.__setup_lightweight_ca_key_retrieval_kerberos() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1431, in __setup_lightweight_ca_key_retrieval_kerberos os.chmod(keytab, 0o600) 2017-03-20T12:58:41Z DEBUG The ipa-server-upgrade command failed, exception: OSError: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/dogtag.keytab' The ipa services came back up (kinit is working and can login to the console). This seems related to [1,2]. Checked to ensure that dogtag service points to the default service password policy per [1]: $ ipa service-show --all dogtag/host krbpwdpolicyreference: cn=Default Service Password Policy,cn=services,cn=accounts,dc=REALM However when listing all the pwpolicies this doesn't seem to exist anywhere? We only have a single global pwpolicy: $ ipa pwpolicy-find Group: global_policy ---------------------------- Number of entries returned 1 ---------------------------- Could this be related to the error? Any pointers on how to trouble shoot? Thanks in advance. --Andrew [1] https://www.redhat.com/archives/freeipa-users/2017-March/msg00178.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1404910 From abokovoy at redhat.com Mon Mar 20 14:39:37 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Mar 2017 16:39:37 +0200 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: References: Message-ID: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> On ma, 20 maalis 2017, Artem Golubev wrote: >Good day! > >We use freeipa server 4.3.1, we usually grant access via ssh keys to linux >clients. >We currently face the following issue with access on certificate: when we >add certificate to user's account, user is not able to login via ssh. >How can we solve this problem? We would like to have a possibility to >access linux clients via ssh keys and access to other resources using >certificates. You need to provide logs, obviously. Start with level 3 debug logs in sshd, and debug_level=9 in sssd. Also show user's entry (as in 'ipa user-show --raw --all username'). When you access SSH with ssh keys, SSSD is involved in account and session phases of PAM authentication. This means either user does not exist to sshd (it would then don't exist on system level at all) or something prevents session phase from success. In session phase SSSD does verify HBAC rules, for example. See https://fedorahosted.org/sssd/wiki/Troubleshooting for troubleshooting instructions. -- / Alexander Bokovoy From iulian.roman at gmail.com Mon Mar 20 14:47:32 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Mon, 20 Mar 2017 15:47:32 +0100 Subject: [Freeipa-users] compat and nested groups for Unix system Message-ID: Hello, I noticed that nested group feature do not work with the unix ldap clients (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. If i use the cn=compat and change the mapping the nested groups are listed properly. My question is if it is allowed to mix the compat and accounts cn for the userbasedn and groupbasedn on the same unix ldap client ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Mar 20 15:00:28 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Mar 2017 17:00:28 +0200 Subject: [Freeipa-users] compat and nested groups for Unix system In-Reply-To: References: Message-ID: <20170320150028.v47bhnnjibzg6w63@redhat.com> On ma, 20 maalis 2017, Iulian Roman wrote: >Hello, > >I noticed that nested group feature do not work with the unix ldap clients >(AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. If >i use the cn=compat and change the mapping the nested groups are listed >properly. Compat tree implements RFC2307 schema which doesn't have nested groups. Main tree in FreeIPA uses RFC2307bis schema which supports nested groups. On AIX, IBM officially supports only AIX, RFC2307, and RFC2307AIX schemas. AIX's automounter does support RFC2307bis automount maps but the rest of the system does not support RFC2307bis. In particular, AIX does not understand member attribute dereference. >My question is if it is allowed to mix the compat and accounts cn for the >userbasedn and groupbasedn on the same unix ldap client ? No, not really. You are messing it up something that your client does not understand. -- / Alexander Bokovoy From sbose at redhat.com Mon Mar 20 15:10:05 2017 From: sbose at redhat.com (Sumit Bose) Date: Mon, 20 Mar 2017 16:10:05 +0100 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: References: Message-ID: <20170320151005.GA32020@p.Speedport_W_724V_Typ_A_05011603_00_011> On Mon, Mar 20, 2017 at 02:55:37PM +0300, Artem Golubev wrote: > Good day! > > We use freeipa server 4.3.1, we usually grant access via ssh keys to linux > clients. > We currently face the following issue with access on certificate: when we > add certificate to user's account, user is not able to login via ssh. > How can we solve this problem? We would like to have a possibility to > access linux clients via ssh keys and access to other resources using > certificates. I guess this is https://pagure.io/SSSD/sssd/issue/2977 which should be fixed in recent version of SSSD. Which version of SSSD are you using and which platform/OS? HTH bye, Sumit > > Hope to receive a reply from you soon. > Best regards. > *?* > > *?Artem Golubev* > System Administrator > *(exp)capital limited* > -- > 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 From lslebodn at redhat.com Mon Mar 20 15:11:18 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 20 Mar 2017 16:11:18 +0100 Subject: [Freeipa-users] compat and nested groups for Unix system In-Reply-To: <20170320150028.v47bhnnjibzg6w63@redhat.com> References: <20170320150028.v47bhnnjibzg6w63@redhat.com> Message-ID: <20170320151117.GB9347@10.4.128.1> On (20/03/17 17:00), Alexander Bokovoy wrote: >On ma, 20 maalis 2017, Iulian Roman wrote: >> Hello, >> >> I noticed that nested group feature do not work with the unix ldap clients >> (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. If >> i use the cn=compat and change the mapping the nested groups are listed >> properly. >Compat tree implements RFC2307 schema which doesn't have nested groups. > >Main tree in FreeIPA uses RFC2307bis schema which supports nested >groups. > But "Compat tree" is generated from "Main tree". Therefore users must have the same groups in both cases. LS From arequipeno at gmail.com Mon Mar 20 15:12:00 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Mon, 20 Mar 2017 10:12:00 -0500 Subject: [Freeipa-users] Use SQLite format NSS database? In-Reply-To: <20170320090027.GC26690@dkupka.usersys.redhat.com> References: <20170320090027.GC26690@dkupka.usersys.redhat.com> Message-ID: <7e0f2b18-3ee7-198d-0ab9-f50144b3a3da@gmail.com> On 03/20/2017 04:00 AM, David Kupka wrote: > Generally I would not recommend touching this on production system. > Why do you want to change the database format? My FreeIPA server also acts as a reverse proxy/TLS endpoint for my home sprinkler system (https://opensprinkler.com/), allowing me to securely connect to the sprinkler controller from my cell phone when I'm out in the yard (out of WiFi range). Since free 1-year TLS certificates seem to be a thing of the past, I'm working on automating the retrieval of 90-day certificates from Let's Encrypt. My current update script has to stop Apache before updating the certificate in the NSS database. It's hardly the end of the world, but it would have been nice to be able to load the new certificate into the database and just send a SIGHUP to the daemon. -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From lslebodn at redhat.com Mon Mar 20 15:14:47 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 20 Mar 2017 16:14:47 +0100 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> References: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> Message-ID: <20170320151447.GC9347@10.4.128.1> On (20/03/17 16:39), Alexander Bokovoy wrote: >On ma, 20 maalis 2017, Artem Golubev wrote: >> Good day! >> >> We use freeipa server 4.3.1, we usually grant access via ssh keys to linux >> clients. >> We currently face the following issue with access on certificate: when we >> add certificate to user's account, user is not able to login via ssh. >> How can we solve this problem? We would like to have a possibility to >> access linux clients via ssh keys and access to other resources using >> certificates. >You need to provide logs, obviously. Start with level 3 debug logs in >sshd, and debug_level=9 in sssd. Also show user's entry (as in 'ipa >user-show --raw --all username'). > >When you access SSH with ssh keys, SSSD is involved in account and >session phases of PAM authentication. This means either user does not >exist to sshd (it would then don't exist on system level at all) or >something prevents session phase from success. In session phase SSSD >does verify HBAC rules, for example. > >See https://fedorahosted.org/sssd/wiki/Troubleshooting for >troubleshooting instructions. > The most important is to know version of sssd. Because one related bug is already fixed. https://pagure.io/SSSD/sssd/issue/2977 LS From iulian.roman at gmail.com Mon Mar 20 15:20:52 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Mon, 20 Mar 2017 16:20:52 +0100 Subject: [Freeipa-users] compat and nested groups for Unix system In-Reply-To: <20170320150028.v47bhnnjibzg6w63@redhat.com> References: <20170320150028.v47bhnnjibzg6w63@redhat.com> Message-ID: On Mon, Mar 20, 2017 at 4:00 PM, Alexander Bokovoy wrote: > On ma, 20 maalis 2017, Iulian Roman wrote: > >> Hello, >> >> I noticed that nested group feature do not work with the unix ldap clients >> (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. >> If >> i use the cn=compat and change the mapping the nested groups are listed >> properly. >> > Compat tree implements RFC2307 schema which doesn't have nested groups. > Correct, but although the groups under the compat tree do not have the nestedgroup object class attribute, whenever i change the group membership via WEB UI, the compat tree group membership is automatically updated (new memberUid is added). What i've done was a sort of workaround and map the AIX groups attribute to the memberUid which seems to work properly. > Main tree in FreeIPA uses RFC2307bis schema which supports nested > groups. > > Any plans to support RFC2307AIX schema ? > On AIX, IBM officially supports only AIX, RFC2307, and RFC2307AIX > schemas. AIX's automounter does support RFC2307bis automount maps but > the rest of the system does not support RFC2307bis. In particular, AIX > does not understand member attribute dereference. > > > My question is if it is allowed to mix the compat and accounts cn for the >> userbasedn and groupbasedn on the same unix ldap client ? >> > No, not really. You are messing it up something that your client > does not understand. > As i explained above, i could use the basic attributes in the compat tree for groups in order to update the AIX "groups" attribute (based on memberuid list). Is there anything which can break the functionality if the compat tree is used instead of the main/accounts tree or it is a fortunate coincidence that this setup works ? > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Mar 20 15:24:39 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Mar 2017 17:24:39 +0200 Subject: [Freeipa-users] compat and nested groups for Unix system In-Reply-To: References: <20170320150028.v47bhnnjibzg6w63@redhat.com> Message-ID: <20170320152439.xmkqgb6lqavp4tvf@redhat.com> On ma, 20 maalis 2017, Iulian Roman wrote: >On Mon, Mar 20, 2017 at 4:00 PM, Alexander Bokovoy >wrote: > >> On ma, 20 maalis 2017, Iulian Roman wrote: >> >>> Hello, >>> >>> I noticed that nested group feature do not work with the unix ldap clients >>> (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. >>> If >>> i use the cn=compat and change the mapping the nested groups are listed >>> properly. >>> >> Compat tree implements RFC2307 schema which doesn't have nested groups. >> >Correct, but although the groups under the compat tree do not have the >nestedgroup object class attribute, whenever i change the group membership >via WEB UI, the compat tree group membership is automatically updated (new >memberUid is added). What i've done was a sort of workaround and map the >AIX groups attribute to the memberUid which seems to work properly. memberUid is uidNumber of corresponding user, not a group identifier. Perhaps, you are trying to explain something else? >> Main tree in FreeIPA uses RFC2307bis schema which supports nested >> groups. >> > Any plans to support RFC2307AIX schema ? No. > >> On AIX, IBM officially supports only AIX, RFC2307, and RFC2307AIX >> schemas. AIX's automounter does support RFC2307bis automount maps but >> the rest of the system does not support RFC2307bis. In particular, AIX >> does not understand member attribute dereference. >> >> >> My question is if it is allowed to mix the compat and accounts cn for the >>> userbasedn and groupbasedn on the same unix ldap client ? >>> >> No, not really. You are messing it up something that your client >> does not understand. >> >As i explained above, i could use the basic attributes in the compat tree >for groups in order to update the AIX "groups" attribute (based on >memberuid list). Is there anything which can break the functionality if the >compat tree is used instead of the main/accounts tree or it is a fortunate >coincidence that this setup works ? Why you don't use compat tree for both users and groups in AIX? This is how it was designed to be used. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Mar 20 15:33:09 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Mar 2017 17:33:09 +0200 Subject: [Freeipa-users] compat and nested groups for Unix system In-Reply-To: <20170320151117.GB9347@10.4.128.1> References: <20170320150028.v47bhnnjibzg6w63@redhat.com> <20170320151117.GB9347@10.4.128.1> Message-ID: <20170320153309.j2pl7qb77hagaurr@redhat.com> On ma, 20 maalis 2017, Lukas Slebodnik wrote: >On (20/03/17 17:00), Alexander Bokovoy wrote: >>On ma, 20 maalis 2017, Iulian Roman wrote: >>> Hello, >>> >>> I noticed that nested group feature do not work with the unix ldap clients >>> (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. If >>> i use the cn=compat and change the mapping the nested groups are listed >>> properly. >>Compat tree implements RFC2307 schema which doesn't have nested groups. >> >>Main tree in FreeIPA uses RFC2307bis schema which supports nested >>groups. >> >But "Compat tree" is generated from "Main tree". >Therefore users must have the same groups in both cases. They are, for POSIX groups. RFC2307bis allows you to have arbitrary nested groups, RFC2307 only handles POSIX groups. -- / Alexander Bokovoy From mbasti at redhat.com Mon Mar 20 15:37:44 2017 From: mbasti at redhat.com (Martin Basti) Date: Mon, 20 Mar 2017 16:37:44 +0100 Subject: [Freeipa-users] Use SQLite format NSS database? In-Reply-To: <7e0f2b18-3ee7-198d-0ab9-f50144b3a3da@gmail.com> References: <20170320090027.GC26690@dkupka.usersys.redhat.com> <7e0f2b18-3ee7-198d-0ab9-f50144b3a3da@gmail.com> Message-ID: <10267991-490f-c09e-a8e8-d6f4b17519b9@redhat.com> On 20.03.2017 16:12, Ian Pilcher wrote: > On 03/20/2017 04:00 AM, David Kupka wrote: >> Generally I would not recommend touching this on production system. >> Why do you want to change the database format? > > My FreeIPA server also acts as a reverse proxy/TLS endpoint for my > home sprinkler system (https://opensprinkler.com/), allowing me to > securely connect to the sprinkler controller from my cell phone when > I'm out in the yard (out of WiFi range). > > Since free 1-year TLS certificates seem to be a thing of the past, I'm > working on automating the retrieval of 90-day certificates from Let's > Encrypt. > > My current update script has to stop Apache before updating the > certificate in the NSS database. It's hardly the end of the world, but > it would have been nice to be able to load the new certificate into the > database and just send a SIGHUP to the daemon. > Might this help for Lets encrypt ? https://github.com/freeipa/freeipa-letsencrypt Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 847 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Mon Mar 20 16:02:55 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 20 Mar 2017 12:02:55 -0400 Subject: [Freeipa-users] Use SQLite format NSS database? In-Reply-To: <10267991-490f-c09e-a8e8-d6f4b17519b9@redhat.com> References: <20170320090027.GC26690@dkupka.usersys.redhat.com> <7e0f2b18-3ee7-198d-0ab9-f50144b3a3da@gmail.com> <10267991-490f-c09e-a8e8-d6f4b17519b9@redhat.com> Message-ID: Martin Basti wrote: > > > On 20.03.2017 16:12, Ian Pilcher wrote: >> On 03/20/2017 04:00 AM, David Kupka wrote: >>> Generally I would not recommend touching this on production system. >>> Why do you want to change the database format? >> >> My FreeIPA server also acts as a reverse proxy/TLS endpoint for my >> home sprinkler system (https://opensprinkler.com/), allowing me to >> securely connect to the sprinkler controller from my cell phone when >> I'm out in the yard (out of WiFi range). >> >> Since free 1-year TLS certificates seem to be a thing of the past, I'm >> working on automating the retrieval of 90-day certificates from Let's >> Encrypt. >> >> My current update script has to stop Apache before updating the >> certificate in the NSS database. It's hardly the end of the world, but >> it would have been nice to be able to load the new certificate into the >> database and just send a SIGHUP to the daemon. >> > > Might this help for Lets encrypt ? > https://github.com/freeipa/freeipa-letsencrypt I think his concern may be around warnings that the NSS BDB databases should only be updated when quiet. In the case of mod_nss it explicitly opens the database read-only so I think you'd be safe updating the certificate. A SIGHUP may indeed be sufficient to load the new cert, just haven't had a chance to test it this morning. rob From iulian.roman at gmail.com Mon Mar 20 16:12:50 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Mon, 20 Mar 2017 17:12:50 +0100 Subject: [Freeipa-users] compat and nested groups for Unix system In-Reply-To: <20170320152439.xmkqgb6lqavp4tvf@redhat.com> References: <20170320150028.v47bhnnjibzg6w63@redhat.com> <20170320152439.xmkqgb6lqavp4tvf@redhat.com> Message-ID: On Mon, Mar 20, 2017 at 4:24 PM, Alexander Bokovoy wrote: > On ma, 20 maalis 2017, Iulian Roman wrote: > >> On Mon, Mar 20, 2017 at 4:00 PM, Alexander Bokovoy >> wrote: >> >> On ma, 20 maalis 2017, Iulian Roman wrote: >>> >>> Hello, >>>> >>>> I noticed that nested group feature do not work with the unix ldap >>>> clients >>>> (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. >>>> If >>>> i use the cn=compat and change the mapping the nested groups are listed >>>> properly. >>>> >>>> Compat tree implements RFC2307 schema which doesn't have nested groups. >>> >>> Correct, but although the groups under the compat tree do not have the >> nestedgroup object class attribute, whenever i change the group membership >> via WEB UI, the compat tree group membership is automatically updated (new >> memberUid is added). What i've done was a sort of workaround and map the >> AIX groups attribute to the memberUid which seems to work properly. >> > memberUid is uidNumber of corresponding user, not a group identifier. > Perhaps, you are trying to explain something else? > Ok, maybe i have to explain it more clearly as it was confusing: in order to get the user list attribute for an ldap group in AIX , you use some .map files, which map the ldap attributes to the AIX attributes. For the 2307schema, to get the user list of a group you have to map the AIX *_users_ *attribute to the _memberuid_ ldap attribute. For compat tree, in the file ipagroup.map i've mapped the AIX _users_ attribute to the _memberuid_ ipa/ldap attribute and therefore i have the list of the users for that particular group. Having the user list which are members to a group translates to having the group list of the users (if we invert the logic). Does that make more sense now ? > > Main tree in FreeIPA uses RFC2307bis schema which supports nested >>> groups. >>> >>> Any plans to support RFC2307AIX schema ? >> > No. > > >> On AIX, IBM officially supports only AIX, RFC2307, and RFC2307AIX >>> schemas. AIX's automounter does support RFC2307bis automount maps but >>> the rest of the system does not support RFC2307bis. In particular, AIX >>> does not understand member attribute dereference. >>> >>> >>> My question is if it is allowed to mix the compat and accounts cn for the >>> >>>> userbasedn and groupbasedn on the same unix ldap client ? >>>> >>>> No, not really. You are messing it up something that your client >>> does not understand. >>> >>> As i explained above, i could use the basic attributes in the compat tree >> for groups in order to update the AIX "groups" attribute (based on >> memberuid list). Is there anything which can break the functionality if >> the >> compat tree is used instead of the main/accounts tree or it is a >> fortunate >> coincidence that this setup works ? >> > Why you don't use compat tree for both users and groups in AIX? This is > how it was designed to be used. > Actually the compat tree was the default one configured by the ldap client, but checking the ldap structure seemed more logical to use the default ipa ldap tree which is used as well for Linux. Moreover i did not understood what is exactly the purpose of the compat tree and i was quite confused . Apart from that i missed some krb* related attributes for the user, but probably i have to re-evaluate that and use compat tree for both users and groups, if that's what it was designed for. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iulian.roman at gmail.com Mon Mar 20 16:23:31 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Mon, 20 Mar 2017 17:23:31 +0100 Subject: [Freeipa-users] ldap connector from IIQ to ipa Message-ID: Hello, We do plan to integrate IPA with IdentityIQ (sailpoint) for user provisioning. Because IPA does abstract all the ldap commands via new set of commands and APIs, i am not sure if the standard ldap connector is the right option and if it is supported ( taking into consideration that a simple user creation does update/create more ldap containers). Could you please clarify if updating IPA via standard ldap commands is supported but not necessarily a best practice or it is an absolute NO ? Thank You ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Mar 20 16:31:46 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 20 Mar 2017 18:31:46 +0200 Subject: [Freeipa-users] compat and nested groups for Unix system In-Reply-To: References: <20170320150028.v47bhnnjibzg6w63@redhat.com> <20170320152439.xmkqgb6lqavp4tvf@redhat.com> Message-ID: <20170320163146.w2bbpihu52ktxkt7@redhat.com> On ma, 20 maalis 2017, Iulian Roman wrote: >On Mon, Mar 20, 2017 at 4:24 PM, Alexander Bokovoy >wrote: > >> On ma, 20 maalis 2017, Iulian Roman wrote: >> >>> On Mon, Mar 20, 2017 at 4:00 PM, Alexander Bokovoy >>> wrote: >>> >>> On ma, 20 maalis 2017, Iulian Roman wrote: >>>> >>>> Hello, >>>>> >>>>> I noticed that nested group feature do not work with the unix ldap >>>>> clients >>>>> (AIX) if the default groupbasedn (cn=groups,cn=accounts,dc=...) is used. >>>>> If >>>>> i use the cn=compat and change the mapping the nested groups are listed >>>>> properly. >>>>> >>>>> Compat tree implements RFC2307 schema which doesn't have nested groups. >>>> >>>> Correct, but although the groups under the compat tree do not have the >>> nestedgroup object class attribute, whenever i change the group membership >>> via WEB UI, the compat tree group membership is automatically updated (new >>> memberUid is added). What i've done was a sort of workaround and map the >>> AIX groups attribute to the memberUid which seems to work properly. >>> >> memberUid is uidNumber of corresponding user, not a group identifier. >> Perhaps, you are trying to explain something else? >> >Ok, maybe i have to explain it more clearly as it was confusing: >in order to get the user list attribute for an ldap group in AIX , you use >some .map files, which map the ldap attributes to the AIX attributes. For >the 2307schema, to get the user list of a group you have to map the >AIX *_users_ >*attribute to the _memberuid_ ldap attribute. For compat tree, in the file >ipagroup.map i've mapped the AIX _users_ attribute to the _memberuid_ >ipa/ldap attribute and therefore i have the list of the users for that >particular group. Having the user list which are members to a group >translates to having the group list of the users (if we invert the logic). >Does that make more sense now ? According to my research from several years ago following two maps were enough to get AIX to work with primary IPA tree: #IPAuser.map file keyobjectclass SEC_CHAR posixaccount s # The following attributes are required by AIX to be functional username SEC_CHAR uid s id SEC_INT uidnumber s pgrp SEC_CHAR gidnumber s home SEC_CHAR homedirectory s shell SEC_CHAR loginshell s gecos SEC_CHAR gecos s spassword SEC_CHAR userpassword s lastupdate SEC_INT shadowlastchange s #IPAgroup.map file groupname SEC_CHAR cn s id SEC_INT gidNumber s users SEC_LIST member m This will make AIX to interpret native IPA users properly. If you expect AD users from trusted AD domains to be usable as well, you'd need to switch to compat tree and use RFC2307 mapping files. >> Why you don't use compat tree for both users and groups in AIX? This is >> how it was designed to be used. >> >Actually the compat tree was the default one configured by the ldap client, >but checking the ldap structure seemed more logical to use the default ipa >ldap tree which is used as well for Linux. Moreover i did not understood >what is exactly the purpose of the compat tree and i was quite confused . >Apart from that i missed some krb* related attributes for the user, but >probably i have to re-evaluate that and use compat tree for both users and >groups, if that's what it was designed for. It depends on what you need to do. You shouldn't need to have access to kerberos attributes from client side at all. -- / Alexander Bokovoy From datakid at gmail.com Mon Mar 20 21:14:57 2017 From: datakid at gmail.com (Lachlan Musicman) Date: Tue, 21 Mar 2017 08:14:57 +1100 Subject: [Freeipa-users] Adjusting nsslapd-cachememsize In-Reply-To: <72121513-e631-617a-172d-4634dde7360e@rha-ltd.co.uk> References: <72121513-e631-617a-172d-4634dde7360e@rha-ltd.co.uk> Message-ID: Directly editing the lse.ldif didn't work. ipactl start hangs on pki-tomcatd. I think I've broken it. I seem to recall ldap not liking being edited by hand. cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 17 March 2017 at 19:45, Bob Hinton wrote: > Hi Lachlan, > > This is probably a complete hack, but the way I've changed > nsslapd-cachememsize in the past is - > > On each ipa replica in turn - > > 1. ipactl stop > 2. vim /etc/dirsrv/slapd-DOMAIN/dse.ldif - (where DOMAIN is your > server's domain/realm - not sure which) find and change the value of > nsslapd-cachememsize > 3. ipactl start > > This seemed to work in that it made the error messages go away and it made > heavily loaded servers more stable. However, I've not tried this on a > recent version of ipa so it may no longer work or not be needed any more. > > Regards > > Bob > > On 17/03/2017 02:20, Lachlan Musicman wrote: > > While going through the logs on the FreeIPA server, I noticed this: > > > WARNING: changelog: entry cache size 2097152 B is less than db size > 12804096 B; We recommend to increase the entry cache size > nsslapd-cachememsize. > > > I have found a number of documents: > > What it is: https://access.redhat.com/documentation/en-US/Red_Hat_ > Directory_Server/8.0/html/Configuration_and_Command_ > Reference/Configuration_Command_File_Reference-Database_Attributes_under_ > cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_ > database_cnplugins_cnconfig-nsslapd_cachememsize.html > > How to tune it: https://access.redhat.com/documentation/en-US/Red_Hat_ > Directory_Server/8.1/html/Administration_Guide/memoryusage.html > > > etc etc. > > I have no idea of what the secret password is for the "cn=directory > manager" and can't find any information about where I might find it or > where or when it might have been set anywhere. I have found a number of > likely candidates, but none have worked. > > I found this page: > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > but I'd prefer to not change the password if possible. > > cheers > L. > > > > ------ > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Mar 20 22:34:18 2017 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 20 Mar 2017 16:34:18 -0600 Subject: [Freeipa-users] Adjusting nsslapd-cachememsize In-Reply-To: References: <72121513-e631-617a-172d-4634dde7360e@rha-ltd.co.uk> Message-ID: <034f5973-db08-41e4-93bf-644fa130da63@redhat.com> On 03/20/2017 03:14 PM, Lachlan Musicman wrote: > Directly editing the lse.ldif didn't work. ipactl start hangs on > pki-tomcatd. I think I've broken it. I seem to recall ldap not liking > being edited by hand. You have to make sure dirsrv is not running before you edit dse.ldif. Not sure if ipactl stop will wait until all services are not running. > > cheers > L. > > ------ > The most dangerous phrase in the language is, "We've always done it > this way." > > - Grace Hopper > > On 17 March 2017 at 19:45, Bob Hinton > wrote: > > Hi Lachlan, > > This is probably a complete hack, but the way I've changed > nsslapd-cachememsize in the past is - > > On each ipa replica in turn - > > 1. ipactl stop > 2. vim /etc/dirsrv/slapd-DOMAIN/dse.ldif - (where DOMAIN is > your server's domain/realm - not sure which) find and change > the value of nsslapd-cachememsize > 3. ipactl start > > This seemed to work in that it made the error messages go away and > it made heavily loaded servers more stable. However, I've not > tried this on a recent version of ipa so it may no longer work or > not be needed any more. > > Regards > > Bob > > > On 17/03/2017 02:20, Lachlan Musicman wrote: >> While going through the logs on the FreeIPA server, I noticed this: >> >> >> WARNING: changelog: entry cache size 2097152 B is less than db >> size 12804096 B; We recommend to increase the entry cache size >> nsslapd-cachememsize. >> >> >> I have found a number of documents: >> >> What it is: >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Database_Attributes_under_cnNetscapeRoot_cnldbm_database_cnplugins_cnconfig_and_cnUserRoot_cnldbm_database_cnplugins_cnconfig-nsslapd_cachememsize.html >> >> >> How to tune it: >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/memoryusage.html >> >> >> >> etc etc. >> >> I have no idea of what the secret password is for the >> "cn=directory manager" and can't find any information about where >> I might find it or where or when it might have been set anywhere. >> I have found a number of likely candidates, but none have worked. >> >> I found this page: >> >> https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password >> >> >> but I'd prefer to not change the password if possible. >> >> cheers >> L. >> >> >> >> ------ >> The most dangerous phrase in the language is, "We've always done >> it this way." >> >> - Grace Hopper >> >> > > > > From dkupka at redhat.com Tue Mar 21 06:45:57 2017 From: dkupka at redhat.com (David Kupka) Date: Tue, 21 Mar 2017 07:45:57 +0100 Subject: [Freeipa-users] ldap connector from IIQ to ipa In-Reply-To: References: Message-ID: <20170321064557.GA11832@dkupka.usersys.redhat.com> On Mon, Mar 20, 2017 at 05:23:31PM +0100, Iulian Roman wrote: > Hello, > > We do plan to integrate IPA with IdentityIQ (sailpoint) for user > provisioning. Because IPA does abstract all the ldap commands via new set > of commands and APIs, i am not sure if the standard ldap connector is the > right option and if it is supported ( taking into consideration that a > simple user creation does update/create more ldap containers). > > Could you please clarify if updating IPA via standard ldap commands is > supported but not necessarily a best practice or it is an absolute NO ? > > Thank You ! > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project Hello! We have staging area for this purpose. You can create and update user entries there and once the entry is complete you can call stageuser-activate to create user entry with using values from stageuser entry. You can find description of the feature and examples on design page [1]. [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From taraksinha09 at gmail.com Tue Mar 21 11:21:31 2017 From: taraksinha09 at gmail.com (tarak sinha) Date: Tue, 21 Mar 2017 16:51:31 +0530 Subject: [Freeipa-users] (no subject) Message-ID: Hi All, I am getting following below error from my 2 nodes, Could anyone tell me what's the issue and how can resolve it. tail -f /var/log/dirsrv/slapd-EXPERTCITY-COM/errors 1) 6711e6-bf06e7fb-7c0c06d0, CSN 584b3f2a0001006b0000): Server is unwilling to perform (53). Will retry later. [21/Mar/2017:04:16:34 -0700] NSMMReplicationPlugin - agmt="cn= meToauthmgr1.ops.example.com" (authmgr1:389): Consumer failed to replay change (uniqueid 492d6707-be6711e6-bf06e7fb-7c0c06d0, CSN 584b3f2a0001006b0000): Server is unwilling to perform (53). Will retry later. [21/Mar/2017:04:16:39 -0700] NSMMReplicationPlugin - agmt="cn= meToauthmgr1.ops.example.com" (authmgr1:389): Consumer failed to replay change (uniqueid 492d6707-be6711e6-bf06e7fb-7c0c06d0, CSN 584b3f2a0001006b0000): Server is unwilling to perform (53). Will retry later. [21/Mar/2017:04:16:44 -0700] NSMMReplicationPlugin - agmt="cn= meToauthmgr1.ops.expertcity.com" (authmgr1:389): Consumer failed to replay change (uniqueid 492d6707-be6711e6-bf06e7fb-7c0c06d0, CSN 584b3f2a0001006b0000): Server is unwilling to perform (53). Will retry later. Second Node 2) [20/Mar/2017:14:02:13 -0700] NSMMReplicationPlugin - agmt="cn= meToauthmgr1.ops.expertcity.com" (authmgr1:389): Replication bind with GSSAPI auth resumed [20/Mar/2017:17:39:07 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 77): Replica is not cleaned yet (agmt="cn=meToauthmgr1.las.expertcity.com" (authmgr1:389)) [20/Mar/2017:17:39:07 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 77): Replicas have not been cleaned yet, retrying in 14400 seconds [20/Mar/2017:21:39:07 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 77): Replica is not cleaned yet (agmt="cn=meToauthmgr1.las.expertcity.com" (authmgr1:389)) [20/Mar/2017:21:39:07 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 77): Replicas have not been cleaned yet, retrying in 14400 seconds [21/Mar/2017:01:39:08 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 77): Replica is not cleaned yet (agmt="cn=meToauthmgr1.las.expertcity.com" (authmgr1:389)) [21/Mar/2017:01:39:08 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 77): Replicas have not been cleaned yet, retrying in 14400 seconds -- *Thanks,* *TN* -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.karasek at elostech.cz Tue Mar 21 13:41:57 2017 From: jan.karasek at elostech.cz (Jan =?utf-8?Q?Kar=C3=A1sek?=) Date: Tue, 21 Mar 2017 14:41:57 +0100 (CET) Subject: [Freeipa-users] Missing user's primary group after ipa migrate-ds Message-ID: <1913908580.964155.1490103717171.JavaMail.zimbra@elostech.cz> Hi, because HW failure(only one replica left - without CA and unfortunately without backup) we have decided to build fresh new IPA servers and move users and groups from old IPA server with ipa migrate-ds command. It's quite small use case just about 100 users and couple of groups. I was able successfully import users and groups into new server with: ipa-new# ipa -d migrate-ds ldap://ipa-old.example.com --user-container=cn=users,cn=accounts,dc=example,dc=com --group-container=cn=groups,cn=accounts,dc=example,dc=com Users and all groups were imported but all user's primary groups are missing. ipa-new# id user uid=891500508(user) gid=891500508 groups=891500508,1471200000(admins) No reply with: getent group 891500508 getent group user also: ipa-new# su user Password: /usr/bin/id: cannot find name for group ID 891500508 When creating new user it works correctly: ipa-new# ipa user-add tester ..... uid=1471200001(tester) gid=1471200001(tester) groups=1471200001(tester) getent group tester tester:*:1471200001: getent group tester tester:*:1471200001: ldapsearch doesn't show any user's primary groups in cn=groups,cn=accounts,dc=example,dc=com. It shows just the primary group of newly created user- tester + other non primary groups. Am I doing something wrong ? How to fix this ? Import primary groups manually with ldapmodify or can I create them with ipa group-add ? Thanks, Jan Jan Kar?sek ELOS Technologies s.r.o. Americk? 36 120 00 Praha 2 tel. +420 607 008 891 e-mail: jan.karasek at elostech.cz www.elostech.cz "Tento e-mail a v?echny p?ipojen? soubory obsahuj? d?v?rn? informace, kter? mohou b?t chr?n?ny z?konem. Je ur?en pouze uveden?mu p??jemci a dal??m osob?m, kter? jsou jmenovit? uvedeny jako p??jemci. Jestli?e nejste opr?vn?n? p??jemce, pak jak?koliv forma zve?ejn?n?, reprodukce, kop?rov?n?, distribuce nebo ???en? je p??sn? zak?z?na. Pokud jste obdr?el tento e-mail omylem, oznamte to, pros?m, neprodlen? jeho odesilateli a pak jej vyma?te. ELOS Technologies s.r.o. neru?? za bezchybn? a ?pln? p?enos zas?lan?ch informaci, ani za zpo?d?n? nebo p?eru?en? p?enosu a ani za ?kody zp?soben? pou?it?m nebo d?v?rou v tyto informace." From arequipeno at gmail.com Tue Mar 21 13:58:26 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Tue, 21 Mar 2017 08:58:26 -0500 Subject: [Freeipa-users] Use SQLite format NSS database? In-Reply-To: References: <20170320090027.GC26690@dkupka.usersys.redhat.com> <7e0f2b18-3ee7-198d-0ab9-f50144b3a3da@gmail.com> <10267991-490f-c09e-a8e8-d6f4b17519b9@redhat.com> Message-ID: <4ecea35c-0b5a-76b8-384f-4beca3ab46c7@gmail.com> On 03/20/2017 11:02 AM, Rob Crittenden wrote: > I think his concern may be around warnings that the NSS BDB databases > should only be updated when quiet. In the case of mod_nss it explicitly > opens the database read-only so I think you'd be safe updating the > certificate. You are correct about my concern. I should have noticed that mod_nss is opening the database read-only, based on the file permissions if nothing else. Based on this, I should be able to do something with symlinks to make a copy of the database, do my updates, rename the symlink to make the updated database "live", and SIGHUP (or restart if necessary) Apache. Thanks! -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From artem.golubev at expcapital.com Tue Mar 21 14:08:24 2017 From: artem.golubev at expcapital.com (Artem Golubev) Date: Tue, 21 Mar 2017 17:08:24 +0300 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: <20170320151447.GC9347@10.4.128.1> References: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> <20170320151447.GC9347@10.4.128.1> Message-ID: We use sssd version 1.13.4 on our linux clients A user from ipa successfully authorizes on a linux client via ssh without a certificate. But then if we add a certificate - connection gets lost. Please find logs in attached files Thank you in advance *Artem Golubev* System Administrator *(exp)capital limited* On 20 March 2017 at 18:14, Lukas Slebodnik wrote: > On (20/03/17 16:39), Alexander Bokovoy wrote: > >On ma, 20 maalis 2017, Artem Golubev wrote: > >> Good day! > >> > >> We use freeipa server 4.3.1, we usually grant access via ssh keys to > linux > >> clients. > >> We currently face the following issue with access on certificate: when > we > >> add certificate to user's account, user is not able to login via ssh. > >> How can we solve this problem? We would like to have a possibility to > >> access linux clients via ssh keys and access to other resources using > >> certificates. > >You need to provide logs, obviously. Start with level 3 debug logs in > >sshd, and debug_level=9 in sssd. Also show user's entry (as in 'ipa > >user-show --raw --all username'). > > > >When you access SSH with ssh keys, SSSD is involved in account and > >session phases of PAM authentication. This means either user does not > >exist to sshd (it would then don't exist on system level at all) or > >something prevents session phase from success. In session phase SSSD > >does verify HBAC rules, for example. > > > >See https://fedorahosted.org/sssd/wiki/Troubleshooting for > >troubleshooting instructions. > > > The most important is to know version of sssd. > Because one related bug is already fixed. > https://pagure.io/SSSD/sssd/issue/2977 > > LS > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sshd_log Type: application/octet-stream Size: 375 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd_ssh_log Type: application/octet-stream Size: 2766 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: user-show Type: application/octet-stream Size: 3212 bytes Desc: not available URL: From abokovoy at redhat.com Tue Mar 21 14:29:56 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Mar 2017 16:29:56 +0200 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: References: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> <20170320151447.GC9347@10.4.128.1> Message-ID: <20170321142956.np5ennly755lpqt3@redhat.com> On ti, 21 maalis 2017, Artem Golubev wrote: >We use sssd version 1.13.4 on our linux clients >A user from ipa successfully authorizes on a linux client via ssh without a >certificate. But then if we add a certificate - connection gets lost. If Lukas is correct, 1.13.4 does not have the fix for broken certificate-as-ssh public key: $ git tag --contains 60787fb44924e84a0c7ddfe9d5e62e64ea1edcd1 sssd-1_13_90 sssd-1_13_91 sssd-1_14_0 sssd-1_14_0_alpha1 sssd-1_14_0_beta1 sssd-1_14_1 sssd-1_14_2 sssd-1_15_0 sssd-1_15_1 sssd-1_15_2 So the issue is fixed only in 1.14+ if we would be counting released versions. -- / Alexander Bokovoy From lslebodn at redhat.com Tue Mar 21 15:23:25 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 21 Mar 2017 16:23:25 +0100 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: <20170321142956.np5ennly755lpqt3@redhat.com> References: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> <20170320151447.GC9347@10.4.128.1> <20170321142956.np5ennly755lpqt3@redhat.com> Message-ID: <20170321152325.GA23981@10.4.128.1> On (21/03/17 16:29), Alexander Bokovoy wrote: >On ti, 21 maalis 2017, Artem Golubev wrote: >> We use sssd version 1.13.4 on our linux clients >> A user from ipa successfully authorizes on a linux client via ssh without a >> certificate. But then if we add a certificate - connection gets lost. >If Lukas is correct, 1.13.4 does not have the fix for broken >certificate-as-ssh public key: > It has. https://pagure.io/SSSD/sssd/issue/2977#comment-222198 https://pagure.io/SSSD/sssd/c/4dbb3bec93cda57e8336847dff0822f31425004d It will be part of upstream release 1.13.5 LS From abokovoy at redhat.com Tue Mar 21 15:35:25 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 21 Mar 2017 17:35:25 +0200 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: <20170321152325.GA23981@10.4.128.1> References: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> <20170320151447.GC9347@10.4.128.1> <20170321142956.np5ennly755lpqt3@redhat.com> <20170321152325.GA23981@10.4.128.1> Message-ID: <20170321153525.7rebcy2eelij6cdz@redhat.com> On ti, 21 maalis 2017, Lukas Slebodnik wrote: >On (21/03/17 16:29), Alexander Bokovoy wrote: >>On ti, 21 maalis 2017, Artem Golubev wrote: >>> We use sssd version 1.13.4 on our linux clients >>> A user from ipa successfully authorizes on a linux client via ssh without a >>> certificate. But then if we add a certificate - connection gets lost. >>If Lukas is correct, 1.13.4 does not have the fix for broken >>certificate-as-ssh public key: >> >It has. >https://pagure.io/SSSD/sssd/issue/2977#comment-222198 >https://pagure.io/SSSD/sssd/c/4dbb3bec93cda57e8336847dff0822f31425004d > >It will be part of upstream release 1.13.5 That's my point -- it is *not* part of 1.13.4, therefore, this is the problem Artem sees. Artem, what is your Linux distribution? Can you move to a newer version? -- / Alexander Bokovoy From Paul.Brennan at itec.suny.edu Tue Mar 21 15:42:14 2017 From: Paul.Brennan at itec.suny.edu (Brennan, Paul J) Date: Tue, 21 Mar 2017 15:42:14 +0000 Subject: [Freeipa-users] Original master lost, cannot create additional CA clones Message-ID: <6FB2F9495EBCAB469F1F3B0E0FA02107B9E65B0B@itxxmb001.exhosted.itec.suny.edu> Hi all, Some time ago, I encountered issues requiring my first IPA master to be re-initialized, which failed, forcing me to remove it from the domain. While those original issues have since been resolved, I am having difficulty replacing the system. I can create a new replica, but I cannot use the '--setup-ca' option, nor can I run 'ipa-ca-install'. I have been working on this for quite some time, and seem to be going in circles. Any help would be greatly appreciated. (host and domain names have been modified) ipasrv001 was the original master, installed using an external CA, no DNS and no NTP. DNS and NTP are already provided in my environment. ipasrv201 is a replica installed with --setup-ca, which has since been re-configured as the new CA master following this guide: https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0 I have also pointed cs-replication to this system from all other replicas. I used ipasrv201 to generate new replica-info for ipasrv001. These systems are Enterprise Linux 6.8. Current software versions are as follows: ---------------------------------------------------------------------------------------------------- [root at ipasrv001 ~]# rpm -qa --queryformat='%{NAME} %{VERSION}-%{RELEASE}\n' ipa-server pki-ca 389-ds-base java-1.7.0-openjdk certmonger certmonger 0.77.5-2.el6 pki-ca 9.0.3-50.el6_8 389-ds-base 1.2.11.15-75.el6_8 java-1.7.0-openjdk 1.7.0.111-2.6.7.2.0.1.el6_8 ipa-server 3.0.0-50.el6_8.3 ---------------------------------------------------------------------------------------------------- I receive the following error when attempting to create a new replica: ---------------------------------------------------------------------------------------------------- [root at ipasrv001 ~]# ipa-replica-install --no-ntp --setup-ca --skip-conncheck replica-info-ipasrv001.example.com.gpg Directory Manager (existing master) password: Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: creating pki-ca instance [3/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipasrv001.example.com -cs_port 9445 -client_certdb_dir /tmp/tmp-BDfli8 -client_certdb_pwd XXXXXXXX -preop_pin SoawlFdqmJKt79OSoy1O -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=EXAMPLE.COM,OU=IPA -ldap_host ipasrv001.example.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM,OU=IPA -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM,OU=IPA -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM,OU=IPA -ca_server_cert_subject_name CN=ipasrv001.example.com,O=EXAMPLE.COM,OU=IPA -ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM,OU=IPA -ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM,OU=IPA -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname ipasrv201.example.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://ipasrv201.example.com:443' returned non-zero exit status 255 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed ---------------------------------------------------------------------------------------------------- In /var/log/ipareplica-install.log, I see the following: ---------------------------------------------------------------------------------------------------- ############################################# Attempting to connect to: ipasrv001.example.com:9445 Connected. Posting Query = https://ipasrv001.example.com:9445//ca/admin/console/config/wizard?p=5&subsystem=CA&session_id=-1815206698136119192&xml=true RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 RESPONSE HEADER: Date: Fri, 17 Mar 2017 15:50:34 GMT RESPONSE HEADER: Connection: close Exception in SecurityDomainLoginPanel(): java.lang.Exception: Invalid clone_uri ERROR: ConfigureSubCA: SecurityDomainLoginPanel() failure ERROR: unable to create CA ####################################################################### 2017-03-17T15:50:35Z DEBUG stderr=java.lang.Exception: Invalid clone_uri at ConfigureCA.SecurityDomainLoginPanel(ConfigureCA.java:392) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1179) at ConfigureCA.main(ConfigureCA.java:1663) ---------------------------------------------------------------------------------------------------- In /var/log/pki-ca/debug, I see: ---------------------------------------------------------------------------------------------------- Could not get or build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate at com.netscape.ca.CertificateAuthority.initSigUnit(CertificateAuthority.java:1285) at com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:262) ---------------------------------------------------------------------------------------------------- In /var/log/pki-ca/catalina.out I see: ---------------------------------------------------------------------------------------------------- CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| ---------------------------------------------------------------------------------------------------- I have tried deploying a new replica to freshly installed systems, and the same problem occurs. I have backups from when IPA was first installed, if any config files or certificates need to be brought back. I can provide further log excerpts if needed. Thank you in advance, Paul Brennan -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Tue Mar 21 16:02:36 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 21 Mar 2017 17:02:36 +0100 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: <20170321153525.7rebcy2eelij6cdz@redhat.com> References: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> <20170320151447.GC9347@10.4.128.1> <20170321142956.np5ennly755lpqt3@redhat.com> <20170321152325.GA23981@10.4.128.1> <20170321153525.7rebcy2eelij6cdz@redhat.com> Message-ID: <20170321160236.GB23981@10.4.128.1> On (21/03/17 17:35), Alexander Bokovoy wrote: >On ti, 21 maalis 2017, Lukas Slebodnik wrote: >> On (21/03/17 16:29), Alexander Bokovoy wrote: >> > On ti, 21 maalis 2017, Artem Golubev wrote: >> > > We use sssd version 1.13.4 on our linux clients >> > > A user from ipa successfully authorizes on a linux client via ssh without a >> > > certificate. But then if we add a certificate - connection gets lost. >> > If Lukas is correct, 1.13.4 does not have the fix for broken >> > certificate-as-ssh public key: >> > >> It has. >> https://pagure.io/SSSD/sssd/issue/2977#comment-222198 >> https://pagure.io/SSSD/sssd/c/4dbb3bec93cda57e8336847dff0822f31425004d >> >> It will be part of upstream release 1.13.5 >That's my point -- it is *not* part of 1.13.4, therefore, this is the >problem Artem sees. > >Artem, what is your Linux distribution? Can you move to a newer version? > I would gues ubuntu :-) You might file a bug to your distribution to backport patch from the ticket https://pagure.io/SSSD/sssd/issue/2977 LS From artem.golubev at expcapital.com Tue Mar 21 16:26:25 2017 From: artem.golubev at expcapital.com (Artem Golubev) Date: Tue, 21 Mar 2017 19:26:25 +0300 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: <032601d2a25e$22c706e0$685514a0$@expcapital.com> References: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> <20170320151447.GC9347@10.4.128.1> <20170321142956.np5ennly755lpqt3@redhat.com> <20170321152325.GA23981@10.4.128.1> <20170321153525.7rebcy2eelij6cdz@redhat.com> <20170321160236.GB23981@10.4.128.1> <032601d2a25e$22c706e0$685514a0$@expcapital.com> Message-ID: yep, Ubuntu 16.04.2 *Artem Golubev* System Administrator *(exp)capital limited* On 21 March 2017 at 19:13, Vasily Yanov wrote: > Hi Lukas, > > You are right :) Ubuntu 16.04. > > -----Original Message----- > From: Lukas Slebodnik [mailto:lslebodn at redhat.com] > Sent: Tuesday, March 21, 2017 7:03 PM > To: Alexander Bokovoy > Cc: freeipa-users at redhat.com; Artem Golubev ; > IT Team > Subject: Re: [Freeipa-users] Certificate Access issue > > On (21/03/17 17:35), Alexander Bokovoy wrote: > >On ti, 21 maalis 2017, Lukas Slebodnik wrote: > >> On (21/03/17 16:29), Alexander Bokovoy wrote: > >> > On ti, 21 maalis 2017, Artem Golubev wrote: > >> > > We use sssd version 1.13.4 on our linux clients A user from ipa > >> > > successfully authorizes on a linux client via ssh without a > >> > > certificate. But then if we add a certificate - connection gets > lost. > >> > If Lukas is correct, 1.13.4 does not have the fix for broken > >> > certificate-as-ssh public key: > >> > > >> It has. > >> https://pagure.io/SSSD/sssd/issue/2977#comment-222198 > >> https://pagure.io/SSSD/sssd/c/4dbb3bec93cda57e8336847dff0822f31425004 > >> d > >> > >> It will be part of upstream release 1.13.5 > >That's my point -- it is *not* part of 1.13.4, therefore, this is the > >problem Artem sees. > > > >Artem, what is your Linux distribution? Can you move to a newer version? > > > I would gues ubuntu :-) > > You might file a bug to your distribution to backport patch from the > ticket https://pagure.io/SSSD/sssd/issue/2977 > > LS > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Mar 21 19:26:39 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 21 Mar 2017 15:26:39 -0400 Subject: [Freeipa-users] Use SQLite format NSS database? In-Reply-To: <4ecea35c-0b5a-76b8-384f-4beca3ab46c7@gmail.com> References: <20170320090027.GC26690@dkupka.usersys.redhat.com> <7e0f2b18-3ee7-198d-0ab9-f50144b3a3da@gmail.com> <10267991-490f-c09e-a8e8-d6f4b17519b9@redhat.com> <4ecea35c-0b5a-76b8-384f-4beca3ab46c7@gmail.com> Message-ID: Ian Pilcher wrote: > On 03/20/2017 11:02 AM, Rob Crittenden wrote: >> I think his concern may be around warnings that the NSS BDB databases >> should only be updated when quiet. In the case of mod_nss it explicitly >> opens the database read-only so I think you'd be safe updating the >> certificate. > > You are correct about my concern. I should have noticed that mod_nss > is opening the database read-only, based on the file permissions if > nothing else. > > Based on this, I should be able to do something with symlinks to make a > copy of the database, do my updates, rename the symlink to make the > updated database "live", and SIGHUP (or restart if necessary) Apache. Um, this _might_ work. Each httpd worker will have an fd open to the NSS database files so you'd want to do this rather carefully. In order for NSS to see a newly added certificate it will need to reopen the database. I'm fairly certain a SIGHUP will cause all the children to be respawned so except for those actually serving a request at the time the new certs should be available. rob From arequipeno at gmail.com Tue Mar 21 20:05:35 2017 From: arequipeno at gmail.com (Ian Pilcher) Date: Tue, 21 Mar 2017 15:05:35 -0500 Subject: [Freeipa-users] Use SQLite format NSS database? In-Reply-To: References: <20170320090027.GC26690@dkupka.usersys.redhat.com> <7e0f2b18-3ee7-198d-0ab9-f50144b3a3da@gmail.com> <10267991-490f-c09e-a8e8-d6f4b17519b9@redhat.com> <4ecea35c-0b5a-76b8-384f-4beca3ab46c7@gmail.com> Message-ID: <95617694-9008-7445-ee59-e86346abdc4f@gmail.com> On 03/21/2017 02:26 PM, Rob Crittenden wrote: > Um, this _might_ work. Each httpd worker will have an fd open to the NSS > database files so you'd want to do this rather carefully. I'm no expert on this stuff, but my understanding is that any file descriptors will continue to point to the older database files until a worker is restarted or it closes and reopens a file for some reason (which I have no reason to believe mod_nss does). Even if a worker does do this for some reason, the /etc/httpd/alias symlink can be changed atomically, so it will only be an issue if a worker reopens an NSS database at the same time that the symlink is being updated -- thus getting inconsistent versions of secmod.db, cert8.db, or key3.db. If this happens, NSS will presumably return SEC_ERROR_ALIENS_ATTACKING, or something similarly inaccurate and non- useful. (Even this wouldn't be an issue if NSS used openat() like a library that actually cares about ... security, but I digress.) > In order for NSS to see a newly added certificate it will need to reopen > the database. I'm fairly certain a SIGHUP will cause all the children to > be respawned so except for those actually serving a request at the time > the new certs should be available. I'll check on SIGHUP. Even if it doesn't work, a complete restart is much easier to coordinate than shutting down Apache, updating the database, and restarting it. -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From zarko at etcfstab.com Wed Mar 22 04:38:58 2017 From: zarko at etcfstab.com (Z D) Date: Wed, 22 Mar 2017 04:38:58 +0000 Subject: [Freeipa-users] IPA domain level is 1, so replica prepare fails (new installation) Message-ID: Hallo, I have a problem to prepare the replica. Environment: OS: Newly installed EL7.3 IPA Server: Newly installed ipa-server 4.4.0 The error: # ipa-replica-prepare Replica creation using 'ipa-replica-prepare' to generate replica file is supported only in 0-level IPA domain. The current IPA domain level is 1 and thus the replica must be created by promoting an existing IPA client. To set up a replica use the following procedure: 1.) set up a client on the host using 'ipa-client-install' 2.) promote the client to replica running 'ipa-replica-install' *without* replica file specified 'ipa-replica-prepare' is allowed only in domain level 0 The ipa-replica-prepare command failed. Any explanation for this and possible resolution, thanks, Zarko -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Wed Mar 22 06:09:52 2017 From: dkupka at redhat.com (David Kupka) Date: Wed, 22 Mar 2017 07:09:52 +0100 Subject: [Freeipa-users] Original master lost, cannot create additional CA clones In-Reply-To: <6FB2F9495EBCAB469F1F3B0E0FA02107B9E65B0B@itxxmb001.exhosted.itec.suny.edu> References: <6FB2F9495EBCAB469F1F3B0E0FA02107B9E65B0B@itxxmb001.exhosted.itec.suny.edu> Message-ID: <20170322060951.GB10737@dkupka.usersys.redhat.com> On Tue, Mar 21, 2017 at 03:42:14PM +0000, Brennan, Paul J wrote: > Hi all, > Some time ago, I encountered issues requiring my first IPA master to be re-initialized, which failed, forcing me to remove it from the domain. While those original issues have since been resolved, I am having difficulty replacing the system. I can create a new replica, but I cannot use the '--setup-ca' option, nor can I run 'ipa-ca-install'. I have been working on this for quite some time, and seem to be going in circles. Any help would be greatly appreciated. > > (host and domain names have been modified) > ipasrv001 was the original master, installed using an external CA, no DNS and no NTP. DNS and NTP are already provided in my environment. > ipasrv201 is a replica installed with --setup-ca, which has since been re-configured as the new CA master following this guide: > https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0 > I have also pointed cs-replication to this system from all other replicas. I used ipasrv201 to generate new replica-info for ipasrv001. > > These systems are Enterprise Linux 6.8. Current software versions are as follows: > ---------------------------------------------------------------------------------------------------- > [root at ipasrv001 ~]# rpm -qa --queryformat='%{NAME} %{VERSION}-%{RELEASE}\n' ipa-server pki-ca 389-ds-base java-1.7.0-openjdk certmonger > certmonger 0.77.5-2.el6 > pki-ca 9.0.3-50.el6_8 > 389-ds-base 1.2.11.15-75.el6_8 > java-1.7.0-openjdk 1.7.0.111-2.6.7.2.0.1.el6_8 > ipa-server 3.0.0-50.el6_8.3 > ---------------------------------------------------------------------------------------------------- > > I receive the following error when attempting to create a new replica: > ---------------------------------------------------------------------------------------------------- > [root at ipasrv001 ~]# ipa-replica-install --no-ntp --setup-ca --skip-conncheck replica-info-ipasrv001.example.com.gpg > Directory Manager (existing master) password: > > Configuring directory server for the CA (pkids): Estimated time 30 seconds > [1/3]: creating directory server user > [2/3]: creating directory server instance > [3/3]: restarting directory server > Done configuring directory server for the CA (pkids). > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds > [1/17]: creating certificate server user > [2/17]: creating pki-ca instance > [3/17]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipasrv001.example.com -cs_port 9445 -client_certdb_dir /tmp/tmp-BDfli8 -client_certdb_pwd XXXXXXXX -preop_pin SoawlFdqmJKt79OSoy1O -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=EXAMPLE.COM,OU=IPA -ldap_host ipasrv001.example.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM,OU=IPA -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM,OU=IPA -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM,OU=IPA -ca_server_cert_subject_name CN=ipasrv001.example.com,O=EXAMPLE.COM,OU=IPA -ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM,OU=IPA -ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM,OU=IPA -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname ipasrv201.example.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://ipasrv201.example.com:443' returned non-zero exit status 255 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > ---------------------------------------------------------------------------------------------------- > > In /var/log/ipareplica-install.log, I see the following: > ---------------------------------------------------------------------------------------------------- > ############################################# > Attempting to connect to: ipasrv001.example.com:9445 > Connected. > Posting Query = https://ipasrv001.example.com:9445//ca/admin/console/config/wizard?p=5&subsystem=CA&session_id=-1815206698136119192&xml=true > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 > RESPONSE HEADER: Date: Fri, 17 Mar 2017 15:50:34 GMT > RESPONSE HEADER: Connection: close > Exception in SecurityDomainLoginPanel(): java.lang.Exception: Invalid clone_uri > ERROR: ConfigureSubCA: SecurityDomainLoginPanel() failure > ERROR: unable to create CA > > ####################################################################### > > 2017-03-17T15:50:35Z DEBUG stderr=java.lang.Exception: Invalid clone_uri > at ConfigureCA.SecurityDomainLoginPanel(ConfigureCA.java:392) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1179) > at ConfigureCA.main(ConfigureCA.java:1663) > ---------------------------------------------------------------------------------------------------- > > In /var/log/pki-ca/debug, I see: > ---------------------------------------------------------------------------------------------------- > Could not get or build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate > at com.netscape.ca.CertificateAuthority.initSigUnit(CertificateAuthority.java:1285) > at com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:262) > ---------------------------------------------------------------------------------------------------- > > In /var/log/pki-ca/catalina.out I see: > ---------------------------------------------------------------------------------------------------- > CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| > ---------------------------------------------------------------------------------------------------- > > I have tried deploying a new replica to freshly installed systems, and the same problem occurs. I have backups from when IPA was first installed, if any config files or certificates need to be brought back. I can provide further log excerpts if needed. > > Thank you in advance, > Paul Brennan > > -- > 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 Hello Paul, is there a reason you run ipa-replica-install with --skip-conncheck option? Does it fail with the same error when you run with connection check? There might be some closed ports on ipasrv201's firewall that cause this fail and connection check would discover this. But it's just my wild guess. -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From dkupka at redhat.com Wed Mar 22 06:15:04 2017 From: dkupka at redhat.com (David Kupka) Date: Wed, 22 Mar 2017 07:15:04 +0100 Subject: [Freeipa-users] IPA domain level is 1, so replica prepare fails (new installation) In-Reply-To: References: Message-ID: <20170322061503.GC10737@dkupka.usersys.redhat.com> On Wed, Mar 22, 2017 at 04:38:58AM +0000, Z D wrote: > Hallo, I have a problem to prepare the replica. > > Environment: > > OS: Newly installed EL7.3 > > IPA Server: Newly installed ipa-server 4.4.0 > > The error: > > # ipa-replica-prepare > Replica creation using 'ipa-replica-prepare' to generate replica file > is supported only in 0-level IPA domain. > The current IPA domain level is 1 and thus the replica must > be created by promoting an existing IPA client. > To set up a replica use the following procedure: > 1.) set up a client on the host using 'ipa-client-install' > 2.) promote the client to replica running 'ipa-replica-install' > *without* replica file specified > 'ipa-replica-prepare' is allowed only in domain level 0 > The ipa-replica-prepare command failed. > > Any explanation for this and possible resolution, thanks, Zarko > > -- > 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 Hello Zarko, as already described in the output you've posted ipa-replica-prepare is no longer used when domain level is above 0. Since domain level 1 new replica is first joined to FreeIPA domain as client using ipa-client-install and then promoted to replica using ipa-replica-install. You can find out more about Replica Promotion on design page [1]. [1] https://www.freeipa.org/page/V4/Replica_Promotion -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From dkupka at redhat.com Wed Mar 22 07:06:36 2017 From: dkupka at redhat.com (David Kupka) Date: Wed, 22 Mar 2017 08:06:36 +0100 Subject: [Freeipa-users] IPA domain level is 1, so replica prepare fails (new installation) In-Reply-To: References: Message-ID: <20170322070635.GD10737@dkupka.usersys.redhat.com> On Wed, Mar 22, 2017 at 04:38:58AM +0000, Z D wrote: > Hallo, I have a problem to prepare the replica. > > Environment: > > OS: Newly installed EL7.3 > > IPA Server: Newly installed ipa-server 4.4.0 > > The error: > > # ipa-replica-prepare > Replica creation using 'ipa-replica-prepare' to generate replica file > is supported only in 0-level IPA domain. > The current IPA domain level is 1 and thus the replica must > be created by promoting an existing IPA client. > To set up a replica use the following procedure: > 1.) set up a client on the host using 'ipa-client-install' > 2.) promote the client to replica running 'ipa-replica-install' > *without* replica file specified > 'ipa-replica-prepare' is allowed only in domain level 0 > The ipa-replica-prepare command failed. > > Any explanation for this and possible resolution, thanks, Zarko > > -- > 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 You can also look into RHEL documentation: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From zarko at etcfstab.com Wed Mar 22 07:17:50 2017 From: zarko at etcfstab.com (Z D) Date: Wed, 22 Mar 2017 07:17:50 +0000 Subject: [Freeipa-users] IPA domain level is 1, so replica prepare fails (new installation) In-Reply-To: <20170322070635.GD10737@dkupka.usersys.redhat.com> References: , <20170322070635.GD10737@dkupka.usersys.redhat.com> Message-ID: Thank you David. ________________________________ From: David Kupka Sent: Wednesday, March 22, 2017 12:06 AM To: Z D Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA domain level is 1, so replica prepare fails (new installation) On Wed, Mar 22, 2017 at 04:38:58AM +0000, Z D wrote: > Hallo, I have a problem to prepare the replica. > > Environment: > > OS: Newly installed EL7.3 > > IPA Server: Newly installed ipa-server 4.4.0 > > The error: > > # ipa-replica-prepare > Replica creation using 'ipa-replica-prepare' to generate replica file > is supported only in 0-level IPA domain. > The current IPA domain level is 1 and thus the replica must > be created by promoting an existing IPA client. > To set up a replica use the following procedure: > 1.) set up a client on the host using 'ipa-client-install' > 2.) promote the client to replica running 'ipa-replica-install' > *without* replica file specified > 'ipa-replica-prepare' is allowed only in domain level 0 > The ipa-replica-prepare command failed. > > Any explanation for this and possible resolution, thanks, Zarko > > -- > 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 You can also look into RHEL documentation: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html -- David Kupka -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ronald.Wimmer at oebb.at Wed Mar 22 08:33:28 2017 From: Ronald.Wimmer at oebb.at (Wimmer Ronald (BCC.B.SO)) Date: Wed, 22 Mar 2017 08:33:28 +0000 Subject: [Freeipa-users] AD-Trust Replica Message-ID: <97E471CB191D044F9F018C77836CF85B8A04748B@ARSEX004.oebb.at> Hi, do I have to setup the AD-trust on the Replica as well? Or is it just the master server where it has to be set up? Regards, Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Wed Mar 22 09:16:47 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 22 Mar 2017 10:16:47 +0100 Subject: [Freeipa-users] AD-Trust Replica In-Reply-To: <97E471CB191D044F9F018C77836CF85B8A04748B@ARSEX004.oebb.at> References: <97E471CB191D044F9F018C77836CF85B8A04748B@ARSEX004.oebb.at> Message-ID: On 03/22/2017 09:33 AM, Wimmer Ronald (BCC.B.SO) wrote: > Hi, > > > > do I have to setup the AD-trust on the Replica as well? Or is it just > the master server where it has to be set up? > > > > Regards, > > Ronald > > > > > Hi, the following chapter may help you understand the different roles for an IdM master wrt AD trust (normal IdM master, trust agent or trust controller): https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-controller-agent Flo From Ronald.Wimmer at oebb.at Wed Mar 22 12:46:32 2017 From: Ronald.Wimmer at oebb.at (Wimmer Ronald (BCC.B.SO)) Date: Wed, 22 Mar 2017 12:46:32 +0000 Subject: [Freeipa-users] AD-Trust Replica In-Reply-To: References: <97E471CB191D044F9F018C77836CF85B8A04748B@ARSEX004.oebb.at> Message-ID: <97E471CB191D044F9F018C77836CF85B8A04798F@ARSEX004.oebb.at> Shouldn't the replica be seen as a master. I know that the trust does not have to be set up twice but should the samba configuration considering ad trust not be identical to the master? What about the trust-specific DNS entries? Regards, Ronald From abokovoy at redhat.com Wed Mar 22 13:11:38 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 22 Mar 2017 15:11:38 +0200 Subject: [Freeipa-users] AD-Trust Replica In-Reply-To: <97E471CB191D044F9F018C77836CF85B8A04798F@ARSEX004.oebb.at> References: <97E471CB191D044F9F018C77836CF85B8A04748B@ARSEX004.oebb.at> <97E471CB191D044F9F018C77836CF85B8A04798F@ARSEX004.oebb.at> Message-ID: <20170322131138.3jynq4jlf2lpwwkm@redhat.com> On ke, 22 maalis 2017, Wimmer Ronald (BCC.B.SO) wrote: >Shouldn't the replica be seen as a master. I know that the trust does >not have to be set up twice but should the samba configuration >considering ad trust not be identical to the master? What about the >trust-specific DNS entries? Please read the documentation linked in the previous response. We have different roles w.r.t. trust to AD and they exist for a reason. -- / Alexander Bokovoy From Paul.Brennan at itec.suny.edu Wed Mar 22 14:21:35 2017 From: Paul.Brennan at itec.suny.edu (Brennan, Paul J) Date: Wed, 22 Mar 2017 14:21:35 +0000 Subject: [Freeipa-users] Original master lost, cannot create additional CA clones In-Reply-To: <20170322060951.GB10737@dkupka.usersys.redhat.com> References: <6FB2F9495EBCAB469F1F3B0E0FA02107B9E65B0B@itxxmb001.exhosted.itec.suny.edu>, <20170322060951.GB10737@dkupka.usersys.redhat.com> Message-ID: <6FB2F9495EBCAB469F1F3B0E0FA02107B9E661F0@itxxmb001.exhosted.itec.suny.edu> Hi David, These two servers and in separate datacenters, and my networking team closed port 80 at the perimeter on me. If I run with the conncheck, the replica install will fail because of this: ---------------------------------------------------------------------------------------------------- [root at ipasrv001 ~]# ipa-replica-install --no-ntp --setup-ca replica-info-ipasrv001.itec.suny.edu.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'ipasrv201.itec.suny.edu': 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): FAILED HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK Port check failed! Inaccessible port(s): 80 (TCP) Connection check failed! Please fix your network settings according to error messages above. If the check results are not valid it can be skipped with --skip-conncheck parameter. ---------------------------------------------------------------------------------------------------- I have manually verified the ipasrv201 can reach ipasrv001 via ports 389, 636, 88, 464, 443, and 7389 tcp. There is another replica, ipasrv003, in the same datacenter as ipasrv001. These two servers can communicate over port 80/tcp, and I have tried preparing the replica info from ipasrv003 without success. (Same failure with ca-setup.) I have also tried disabling the local firewall an ipasrv001 in case the install was attempting to access a port listening on the external interface (as opposed to loopback). At this point, I believe the network is inconsequential to the problem. Thank you for the input, Paul Brennan ________________________________________ From: David Kupka [dkupka at redhat.com] Sent: Wednesday, March 22, 2017 2:09 AM To: Brennan, Paul J Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Original master lost, cannot create additional CA clones On Tue, Mar 21, 2017 at 03:42:14PM +0000, Brennan, Paul J wrote: > Hi all, > Some time ago, I encountered issues requiring my first IPA master to be re-initialized, which failed, forcing me to remove it from the domain. While those original issues have since been resolved, I am having difficulty replacing the system. I can create a new replica, but I cannot use the '--setup-ca' option, nor can I run 'ipa-ca-install'. I have been working on this for quite some time, and seem to be going in circles. Any help would be greatly appreciated. > > (host and domain names have been modified) > ipasrv001 was the original master, installed using an external CA, no DNS and no NTP. DNS and NTP are already provided in my environment. > ipasrv201 is a replica installed with --setup-ca, which has since been re-configured as the new CA master following this guide: > https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0 > I have also pointed cs-replication to this system from all other replicas. I used ipasrv201 to generate new replica-info for ipasrv001. > > These systems are Enterprise Linux 6.8. Current software versions are as follows: > ---------------------------------------------------------------------------------------------------- > [root at ipasrv001 ~]# rpm -qa --queryformat='%{NAME} %{VERSION}-%{RELEASE}\n' ipa-server pki-ca 389-ds-base java-1.7.0-openjdk certmonger > certmonger 0.77.5-2.el6 > pki-ca 9.0.3-50.el6_8 > 389-ds-base 1.2.11.15-75.el6_8 > java-1.7.0-openjdk 1.7.0.111-2.6.7.2.0.1.el6_8 > ipa-server 3.0.0-50.el6_8.3 > ---------------------------------------------------------------------------------------------------- > > I receive the following error when attempting to create a new replica: > ---------------------------------------------------------------------------------------------------- > [root at ipasrv001 ~]# ipa-replica-install --no-ntp --setup-ca --skip-conncheck replica-info-ipasrv001.example.com.gpg > Directory Manager (existing master) password: > > Configuring directory server for the CA (pkids): Estimated time 30 seconds > [1/3]: creating directory server user > [2/3]: creating directory server instance > [3/3]: restarting directory server > Done configuring directory server for the CA (pkids). > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds > [1/17]: creating certificate server user > [2/17]: creating pki-ca instance > [3/17]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipasrv001.example.com -cs_port 9445 -client_certdb_dir /tmp/tmp-BDfli8 -client_certdb_pwd XXXXXXXX -preop_pin SoawlFdqmJKt79OSoy1O -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=EXAMPLE.COM,OU=IPA -ldap_host ipasrv001.example.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM,OU=IPA -ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM,OU=IPA -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM,OU=IPA -ca_server_cert_subject_name CN=ipasrv001.example.com,O=EXAMPLE.COM,OU=IPA -ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM,OU=IPA -ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM,OU=IPA -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname ipasrv201.example.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://ipasrv201.example.com:443' returned non-zero exit status 255 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > ---------------------------------------------------------------------------------------------------- > > In /var/log/ipareplica-install.log, I see the following: > ---------------------------------------------------------------------------------------------------- > ############################################# > Attempting to connect to: ipasrv001.example.com:9445 > Connected. > Posting Query = https://ipasrv001.example.com:9445//ca/admin/console/config/wizard?p=5&subsystem=CA&session_id=-1815206698136119192&xml=true > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 > RESPONSE HEADER: Date: Fri, 17 Mar 2017 15:50:34 GMT > RESPONSE HEADER: Connection: close > Exception in SecurityDomainLoginPanel(): java.lang.Exception: Invalid clone_uri > ERROR: ConfigureSubCA: SecurityDomainLoginPanel() failure > ERROR: unable to create CA > > ####################################################################### > > 2017-03-17T15:50:35Z DEBUG stderr=java.lang.Exception: Invalid clone_uri > at ConfigureCA.SecurityDomainLoginPanel(ConfigureCA.java:392) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1179) > at ConfigureCA.main(ConfigureCA.java:1663) > ---------------------------------------------------------------------------------------------------- > > In /var/log/pki-ca/debug, I see: > ---------------------------------------------------------------------------------------------------- > Could not get or build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate > at com.netscape.ca.CertificateAuthority.initSigUnit(CertificateAuthority.java:1285) > at com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:262) > ---------------------------------------------------------------------------------------------------- > > In /var/log/pki-ca/catalina.out I see: > ---------------------------------------------------------------------------------------------------- > CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| > ---------------------------------------------------------------------------------------------------- > > I have tried deploying a new replica to freshly installed systems, and the same problem occurs. I have backups from when IPA was first installed, if any config files or certificates need to be brought back. I can provide further log excerpts if needed. > > Thank you in advance, > Paul Brennan > > -- > 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 Hello Paul, is there a reason you run ipa-replica-install with --skip-conncheck option? Does it fail with the same error when you run with connection check? There might be some closed ports on ipasrv201's firewall that cause this fail and connection check would discover this. But it's just my wild guess. -- David Kupka From dan at cazena.com Wed Mar 22 14:56:22 2017 From: dan at cazena.com (Dan Dietterich) Date: Wed, 22 Mar 2017 14:56:22 +0000 Subject: [Freeipa-users] Possible to fully proxy AD <-> FreeIPA? Message-ID: I am trying to understand if it is possible to NAT between a network running Active Directory (AD) and a network running FreeIPA and have one-way trust from FreeIPA to the AD. My hypothesis is that it is not possible, for two reasons. First, I understand that Kerberos uses several techniques (ip addresses in the protocol, reverse DNS lookups) to make sure there is no "man in the middle." The proxy is a man in the middle. Second, I understand that FreeIPA retrieves the layout of domain controllers (DC) from the initial AD DC it builds the trust with. The addresses returned are valid in the AD network and are not translated into the FreeIPA network. FreeIPA will not be able to route to those IP addresses. I have read about proxying Kerberos protocol over https (https://web.mit.edu/kerberos/krb5-devel/doc/admin/https.html) I have read about proxying LDAP (https://wiki.samba.org/index.php/OpenLDAP_as_proxy_to_AD) I do not know all of the protocols used to operate AD <-> FreeIPA trust, so I'm not sure there is even software available to do such a thing. Thanks for any insight! Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.golubev at expcapital.com Wed Mar 22 15:08:32 2017 From: artem.golubev at expcapital.com (Artem Golubev) Date: Wed, 22 Mar 2017 18:08:32 +0300 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: References: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> <20170320151447.GC9347@10.4.128.1> <20170321142956.np5ennly755lpqt3@redhat.com> <20170321152325.GA23981@10.4.128.1> <20170321153525.7rebcy2eelij6cdz@redhat.com> <20170321160236.GB23981@10.4.128.1> <032601d2a25e$22c706e0$685514a0$@expcapital.com> Message-ID: Guys, we have updated the system to 1.15.0 version and this fixed the issue Thank you all ;-) *Artem Golubev* System Administrator *(exp)capital limited* On 21 March 2017 at 19:26, Artem Golubev wrote: > yep, Ubuntu 16.04.2 > > *Artem Golubev* > System Administrator > *(exp)capital limited* > > On 21 March 2017 at 19:13, Vasily Yanov > wrote: > >> Hi Lukas, >> >> You are right :) Ubuntu 16.04. >> >> -----Original Message----- >> From: Lukas Slebodnik [mailto:lslebodn at redhat.com] >> Sent: Tuesday, March 21, 2017 7:03 PM >> To: Alexander Bokovoy >> Cc: freeipa-users at redhat.com; Artem Golubev > >; IT Team >> Subject: Re: [Freeipa-users] Certificate Access issue >> >> On (21/03/17 17:35), Alexander Bokovoy wrote: >> >On ti, 21 maalis 2017, Lukas Slebodnik wrote: >> >> On (21/03/17 16:29), Alexander Bokovoy wrote: >> >> > On ti, 21 maalis 2017, Artem Golubev wrote: >> >> > > We use sssd version 1.13.4 on our linux clients A user from ipa >> >> > > successfully authorizes on a linux client via ssh without a >> >> > > certificate. But then if we add a certificate - connection gets >> lost. >> >> > If Lukas is correct, 1.13.4 does not have the fix for broken >> >> > certificate-as-ssh public key: >> >> > >> >> It has. >> >> https://pagure.io/SSSD/sssd/issue/2977#comment-222198 >> >> https://pagure.io/SSSD/sssd/c/4dbb3bec93cda57e8336847dff0822f31425004 >> >> d >> >> >> >> It will be part of upstream release 1.13.5 >> >That's my point -- it is *not* part of 1.13.4, therefore, this is the >> >problem Artem sees. >> > >> >Artem, what is your Linux distribution? Can you move to a newer version? >> > >> I would gues ubuntu :-) >> >> You might file a bug to your distribution to backport patch from the >> ticket https://pagure.io/SSSD/sssd/issue/2977 >> >> LS >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 22 15:50:29 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 22 Mar 2017 17:50:29 +0200 Subject: [Freeipa-users] Possible to fully proxy AD <-> FreeIPA? In-Reply-To: References: Message-ID: <20170322155029.zymluxkx4gj4zllg@redhat.com> On ke, 22 maalis 2017, Dan Dietterich wrote: >I am trying to understand if it is possible to NAT between a network >running Active Directory (AD) and a network running FreeIPA and have >one-way trust from FreeIPA to the AD. > >My hypothesis is that it is not possible, for two reasons. First, I >understand that Kerberos uses several techniques (ip addresses in the >protocol, reverse DNS lookups) to make sure there is no "man in the >middle." The proxy is a man in the middle. Second, I understand that >FreeIPA retrieves the layout of domain controllers (DC) from the >initial AD DC it builds the trust with. The addresses returned are >valid in the AD network and are not translated into the FreeIPA >network. FreeIPA will not be able to route to those IP addresses. I don't think this configuration will work. Specifically, discovery of DCs closest to a client with CLDAP ping (done by all Windows clients and SSSD) is required in Active Directory environment and indeed NATingn AD network will not allow IPA masters to access AD DCs. >I have read about proxying Kerberos protocol over https >(https://web.mit.edu/kerberos/krb5-devel/doc/admin/https.html) It is irrelevant here. Sure, IPA provides Kerberos proxy by default already and you may use it but aside from Kerberos, we need access to LDAP and DCE RPC services on AD side. These cannot be proxied in a sane way. >I have read about proxying LDAP (https://wiki.samba.org/index.php/OpenLDAP_as_proxy_to_AD) Both 389-ds and OpenLDAP have backends to proxy LDAP requests to another servers. However, this is not helpful in the case of AD because none of those support proxying CLDAP (LDAP over UDP) which is key part of DC discovery in AD. Also, there is no way to force such proxy to rewrite addresses as you correctly noted. -- / Alexander Bokovoy From michael.van.de.borne at gmail.com Wed Mar 22 16:30:34 2017 From: michael.van.de.borne at gmail.com (=?UTF-8?Q?Micha=c3=abl_Van_de_Borne?=) Date: Wed, 22 Mar 2017 17:30:34 +0100 Subject: [Freeipa-users] Data Provider is offline Message-ID: Hi all, So I have 2 Centos7 hosts, with same sssd and nsswitch configs. One does find the users in IPA, and the other doesn't. Looks like the Data Provider is offline. I sent the SIGUSR2 signal to sssd which is supposed to bring him online. Didn't help. The hosts can resolve the IPA server hostname. SElinux is enforced. Iptables is disabled. here's my sssd.conf [domain/vgt.vito.be] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = vgt.vito.be id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = epoddev8.vgt.vito.be chpass_provider = ipa ipa_server = _srv_, epoddev5.vgt.vito.be ldap_tls_cacert = /etc/ipa/ca.crt debug_level = 7 [sssd] services = nss, sudo, pam, ssh domains = vgt.vito.be [nss] homedir_substring = /home debug_level = 7 [pam] [sudo] [autofs] [ssh] [pac] [ifp] here's the log of sssd_nss.log (Wed Mar 22 16:27:22 2017) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected! (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17][SSS_NSS_GETPWNAM] with input [vdbornem]. (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'vdbornem' matched without domain, user is vdbornem (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [vdbornem] from [] (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [vdbornem at vgt.vito.be] (Wed Mar 22 16:27:22 2017) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a LOCAL view, continuing with provided values. (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f7ffd1d1880:1:vdbornem at vgt.vito.be@vgt.vito.be] (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [vgt.vito.be][0x1][BE_REQ_USER][1][name=vdbornem at vgt.vito.be:-] (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f7ffd1d1880:1:vdbornem at vgt.vito.be@vgt.vito.be] (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline] (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 5, Failed to get reply from Data Provider Will try to return what we have in cache (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f7ffd1d1880:1:vdbornem at vgt.vito.be@vgt.vito.be] (Wed Mar 22 16:27:22 2017) [sssd[nss]] [client_recv] (0x0200): Client disconnected! Any ideas appreciated. Thank you, Cheers, m. -- *Micha?l Van de Borne* Free Bird Computing SPRL - G?rant 104 rue d'Azebois, 6230 Thim?on *Tel:* +32(0)472 695716 *Skype:* mikemowgli *TVA:* BE0637.834.386 Linkedin profile -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Mar 22 16:51:31 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 22 Mar 2017 17:51:31 +0100 Subject: [Freeipa-users] Data Provider is offline In-Reply-To: References: Message-ID: <20170322165131.5ww3huiendh6suef@hendrix> On Wed, Mar 22, 2017 at 05:30:34PM +0100, Micha?l Van de Borne wrote: > Hi all, > > So I have 2 Centos7 hosts, with same sssd and nsswitch configs. > One does find the users in IPA, and the other doesn't. > Looks like the Data Provider is offline. > I sent the SIGUSR2 signal to sssd which is supposed to bring him online. > Didn't help. > The hosts can resolve the IPA server hostname. SElinux is enforced. Iptables > is disabled. > > here's my sssd.conf > > [domain/vgt.vito.be] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = vgt.vito.be > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = epoddev8.vgt.vito.be > chpass_provider = ipa > ipa_server = _srv_, epoddev5.vgt.vito.be > ldap_tls_cacert = /etc/ipa/ca.crt > debug_level = 7 > [sssd] > services = nss, sudo, pam, ssh > domains = vgt.vito.be > [nss] > homedir_substring = /home > debug_level = 7 > [pam] > [sudo] > [autofs] > [ssh] > [pac] > [ifp] > > > here's the log of sssd_nss.log > > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [accept_fd_handler] (0x0400): Client > connected! > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): > Received client version [1]. > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): > Offered version [1]. > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running > command [17][SSS_NSS_GETPWNAM] with input [vdbornem]. > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_parse_name_for_domains] > (0x0200): name 'vdbornem' matched without domain, user is vdbornem > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [vdbornem] from [] > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [vdbornem at vgt.vito.be] > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a > LOCAL view, continuing with provided values. > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_issue_request] (0x0400): > Issuing request for [0x7f7ffd1d1880:1:vdbornem at vgt.vito.be@vgt.vito.be] > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): > Creating request for > [vgt.vito.be][0x1][BE_REQ_USER][1][name=vdbornem at vgt.vito.be:-] > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): > Entering request [0x7f7ffd1d1880:1:vdbornem at vgt.vito.be@vgt.vito.be] > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data > Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline] > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): > Unable to get information from Data Provider > Error: 3, 5, Failed to get reply from Data Provider > Will try to return what we have in cache > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_req_destructor] (0x0400): > Deleting request: [0x7f7ffd1d1880:1:vdbornem at vgt.vito.be@vgt.vito.be] > (Wed Mar 22 16:27:22 2017) [sssd[nss]] [client_recv] (0x0200): Client > disconnected! Restart sssd, which starts from a clean slate, then look for the first occurence of "Going offline" or "Not working" in the logs, then check which operation triggered that.. From peljasz at yahoo.co.uk Wed Mar 22 18:12:25 2017 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 22 Mar 2017 18:12:25 +0000 Subject: [Freeipa-users] slapi_ldap_bind - Error: could not send startTLS request In-Reply-To: References: <2a5e833a-5c7d-3385-bf17-620cd42aa805@redhat.com> <0e318ad4-f719-aed0-b35c-de911a5069a3@yahoo.co.uk> Message-ID: On 10/03/17 16:24, Rob Crittenden wrote: > lejeczek wrote: >> >> On 06/03/17 20:11, Rob Crittenden wrote: >>> lejeczek wrote: >>>> hi everyone >>>> I've seemingly finely working domain, I mean it all seem fine to me, >>>> except for: >>>> >>>> [04/Mar/2017:14:26:47.439218725 +0000] slapi_ldap_bind - Error: could >>>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>>> 107 (Transport endpoint is not connected) >>>> [04/Mar/2017:14:26:47.441155853 +0000] slapi_ldap_bind - Error: could >>>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>>> 107 (Transport endpoint is not connected) >>>> [04/Mar/2017:14:31:47.454016982 +0000] slapi_ldap_bind - Error: could >>>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>>> 107 (Transport endpoint is not connected) >>>> [04/Mar/2017:14:31:47.482477473 +0000] slapi_ldap_bind - Error: could >>>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>>> 107 (Transport endpoint is not connected) >>>> [04/Mar/2017:14:36:46.458508994 +0000] slapi_ldap_bind - Error: could >>>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>>> 107 (Transport endpoint is not connected) >>>> [04/Mar/2017:14:36:46.479878884 +0000] slapi_ldap_bind - Error: could >>>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>>> 107 (Transport endpoint is not connected) >>>> [04/Mar/2017:14:41:47.389700728 +0000] slapi_ldap_bind - Error: could >>>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>>> 107 (Transport endpoint is not connected) >>>> [04/Mar/2017:14:41:47.394379376 +0000] slapi_ldap_bind - Error: could >>>> not send startTLS request: error -1 (Can't contact LDAP server) errno >>>> 107 (Transport endpoint is not connected) >>>> >>>> being logged quite frequently, as you can see. Setup: >>>> >>>> ipa-client-4.4.0-14.el7.centos.4.x86_64 >>>> ipa-client-common-4.4.0-14.el7.centos.4.noarch >>>> ipa-common-4.4.0-14.el7.centos.4.noarch >>>> ipa-python-compat-4.4.0-14.el7.centos.4.noarch >>>> ipa-server-4.4.0-14.el7.centos.4.x86_64 >>>> ipa-server-common-4.4.0-14.el7.centos.4.noarch >>>> ipa-server-dns-4.4.0-14.el7.centos.4.noarch >>>> >>>> Replication, users, logins, all seem normal. But above bothers me as I >>>> am afraid it may one day turn out critical and brake stuff down. >>>> This is on the first server that initiated the domain, long time ago. >>>> There is a second server which logs the same, but only a few entries >>>> then goes quiet. >>>> Third server's error log is completely free from this error. >>>> >>>> Would appreciate all help. >>> The CA replication agreements are handled by ipa-csreplica-manage. You >>> may have leftover agreements from previous installs there. >>> >>> rob >>> >> I'm afraid I let over the years for some bits in the domain gone >> haywire. I found this: >> >> dn: cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> cn: ca >> objectClass: nsContainer >> objectClass: top >> >> dn: cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> cn: certprofiles >> objectClass: nsContainer >> objectClass: top >> >> dn: cn=caacls,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> cn: caacls >> objectClass: nsContainer >> objectClass: top >> >> dn: >> cn=cas+nsuniqueid=647ed0b1-b70911e6-b84df1c7-2176fa48,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> cn: cas >> objectClass: nsContainer >> objectClass: top >> >> dn: cn=cas,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> cn: cas >> objectClass: nsContainer >> objectClass: top >> >> dn: >> cn=IECUserRoles,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> description: User profile that includes IECUserRoles extension from request >> ipaCertProfileStoreIssued: TRUE >> cn: IECUserRoles >> objectClass: ipacertprofile >> objectClass: top >> >> dn: >> cn=caIPAserviceCert,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> description: Standard profile for network services >> ipaCertProfileStoreIssued: TRUE >> cn: caIPAserviceCert >> objectClass: ipacertprofile >> objectClass: top >> >> dn: >> ipaUniqueID=1ea0be16-fc01-11e5-a664-f04da240c1d2,cn=caacls,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> ipaMemberCertProfile: >> cn=caIPAserviceCert,cn=certprofiles,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> ipaUniqueID: 1ea0be16-fc01-11e5-a664-f04da240c1d2 >> ipaEnabledFlag: TRUE >> hostCategory: all >> objectClass: ipaassociation >> objectClass: ipacaacl >> cn: hosts_services_caIPAserviceCert >> serviceCategory: all >> >> dn: >> cn=ipa,cn=cas+nsuniqueid=647ed0b1-b70911e6-b84df1c7-2176fa48,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> cn: ipa >> ipaCaId: 0725f730-9351-4115-aa68-ecb2f47dd805 >> ipaCaSubjectDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x >> objectClass: top >> objectClass: ipaca >> ipaCaIssuerDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x >> description: IPA CA >> >> dn: cn=ipa,cn=cas,cn=ca,dc=priv,dc=xx.dc=xx.dc=priv,dc=xx,dc=xx,dc=x >> cn: ipa >> ipaCaId: ed1bbc62-45c5-4d4a-96fb-0c16129dbad0 >> ipaCaSubjectDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x >> objectClass: top >> objectClass: ipaca >> ipaCaIssuerDN: CN=Certificate Authority,O=PRIVATE.xx.xx.PRIVATE.xx.xx.x >> description: IPA CA >> >> is this the culprit? > You have some replication conflict entries in there. I see no way how > this could affect a connection issue though it is something you should > clean up. > > I'd use tcpdump/wireshark to see what is going on. It will show you if > it is a simple connection failure or an SSL handshake failure. > > rob tcpdump shows this(snippet): 18:07:13.181976 IP 10.5.6.100.37860 > 10.5.6.49.ldap: Flags [.], ack 3661, win 266, options [nop,nop,TS val 942379968 ecr 522552901], length 0 18:07:13.182234 IP 10.5.6.49.49750 > 10.5.6.100.ldap: Flags [.], ack 4260, win 288, options [nop,nop,TS val 522557957 ecr 942369708], length 0 18:07:13.182337 IP 10.5.6.49.ldap > 10.5.6.100.37860: Flags [.], ack 2392, win 253, options [nop,nop,TS val 522557957 ecr 942369772], length 0 [22/Mar/2017:18:01:50.979626277 +0000] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) 18:07:18.237961 IP 10.5.6.100.ldap > 10.5.6.49.49750: Flags [.], ack 3627, win 278, options [nop,nop,TS val 942385024 ecr 522557957], length 0 18:07:18.237964 IP 10.5.6.100.37860 > 10.5.6.49.ldap: Flags [.], ack 3661, win 266, options [nop,nop,TS val 942385024 ecr 522557957], length 0 I wonder if it is possible to make slapd log a bit more.. telling? Does the snippet shed any light on what is working wrong? (I'll be a novice tcpdumper) b.w. L From m3freak at thesandhufamily.ca Wed Mar 22 19:29:06 2017 From: m3freak at thesandhufamily.ca (Ranbir) Date: Wed, 22 Mar 2017 15:29:06 -0400 Subject: [Freeipa-users] One kerberos realm, two dns zones and SSHFP records Message-ID: <1490210946.2324.130.camel@thesandhufamily.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Everyone, I'm using a fully updated CentOS 7.3 environment for two IPA servers. I have one kerberos realm, one dns zone with the same name as the kerberos realm and another dns zone with a different name. DNS is managed by IPA. For the sake of this message: realm: REALM.IPA dnszone1: realm.ipa dnszone2: random.ipa When I join a server that's going into the realm.ipa dns zone to the IPA domain, SSHFP records for that server get automatically created in realm.ipa. But, when I do the same for a server going into the random.ipa dns zone, the SSHFP aren't automatically created. I have to do add the SSHFP records manually after the client install completes. Why are SSHFP records not added automatically for the second dns zone and I how can I fix this situation? Thanks in advance. Ranbir - -- Ranbir -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJY0tCCAAoJEN7T/ly5z1dik3cP/0Xx0Vk0cIfbloYJuVb1ffMH mJzKg3BaSEasWL3mJSsgPQS7CZWFi6PgBZLc79nwJhve1tAZC5+pMwVZwY9F7U9a liZdK1l7a0agpDwnupISdih5PG6TGNEfVjHezKKwnDgjUWMOqak7BM3KIffjhNzc SpuZHUDuY8QD2DeyO8iuuJjt+BUiWJ+Weh1OJq4UKWT68wALc/TbdtLi5OWlFtnV rClTbOhPvm8I4Md3DT0vDdhKqPiUvBGPKgse7HZIN9G4W6/wpM3hU1+ETYgXWqIX yRSK0rjjxfrWKIqRUB1sCKLlkdd+wMaRa/uCnRgvRhYjYUrwyPaH11N41lvE7zUz ccJnaZXkDcIWW9wkAQxx3XXx5vHR33VTS13nkZv4QsHSoJOXcqrsr+Q1r28WmLcZ wb3osINWIEmFCX6knZVRZLDhAefHz+FVsJwzsh6iCdqar+LzFvR0hRUJ0Fepxs8M bkKEZ3LztTtDssX+AO7CqkMZSQ5DHiT9Yo1gHXr2zTEt3qzxyuE0GjMyXzBWyMV4 TpOXoRVQMUvEEV2ecpEATBEKghqXOMqhSeGAObfdlEKADTt11u8ONxwutFYPxybD Sxfd6yvg2/QvB8GYgLMkENuJWdwbFYrlb3GQ04TKjcW6TklcRyjsI8x/Wg3LjofQ AEtlIGyrGau9jPaeHYwd =mJn4 -----END PGP SIGNATURE----- From michael.van.de.borne at gmail.com Wed Mar 22 19:54:09 2017 From: michael.van.de.borne at gmail.com (=?UTF-8?Q?Micha=c3=abl_Van_de_Borne?=) Date: Wed, 22 Mar 2017 20:54:09 +0100 Subject: [Freeipa-users] Data Provider is offline In-Reply-To: <20170322165131.5ww3huiendh6suef@hendrix> References: <20170322165131.5ww3huiendh6suef@hendrix> Message-ID: Thank you, this pointed me to a new direction. So here was the problem (but I still don't know what caused it): In the logs, I found that, when starting, sssd would try to kinit -kt /etc/krb5.keytab host/epoddev8.vgt.vito.be at VGT.VITO.BE And that would throw: kinit: Program lacks support for encryption type while getting initial credentials So I ran klist -ke on each node (the one properly working, and the failing one) and both showed the same encryption types: (aes256-cts-hmac-sha1-96) (aes128-cts-hmac-sha1-96) (des3-cbc-sha1) (arcfour-hmac) I began to think the issue was not about the encryption type, but a corrupted krb5.keytab. So I generated a new one using: ipa-join -h epoddev8.vgt.vito.be -s epoddev5.vgt.vito.be That gave me a new krb5.keytab, but kinit on it gave me: kinit: Password incorrect while getting initial credentials I didn't know what to do at this point and frustration was too big, so I just un-enroll and re-enrolled th host, and everything worked. Really frustrating not to know what the problem was... Let's consider the problem is solved, but if anybody has an idea of what was going around... Cheers, m. -- *Micha?l Van de Borne* Free Bird Computing SPRL - G?rant 104 rue d'Azebois, 6230 Thim?on *Tel:* +32(0)472 695716 *Skype:* mikemowgli *TVA:* BE0637.834.386 Linkedin profile Le 22-03-17 ? 17:51, Jakub Hrozek a ?crit : > On Wed, Mar 22, 2017 at 05:30:34PM +0100, Micha?l Van de Borne wrote: >> Hi all, >> >> So I have 2 Centos7 hosts, with same sssd and nsswitch configs. >> One does find the users in IPA, and the other doesn't. >> Looks like the Data Provider is offline. >> I sent the SIGUSR2 signal to sssd which is supposed to bring him online. >> Didn't help. >> The hosts can resolve the IPA server hostname. SElinux is enforced. Iptables >> is disabled. >> >> here's my sssd.conf >> >> [domain/vgt.vito.be] >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = vgt.vito.be >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = epoddev8.vgt.vito.be >> chpass_provider = ipa >> ipa_server = _srv_, epoddev5.vgt.vito.be >> ldap_tls_cacert = /etc/ipa/ca.crt >> debug_level = 7 >> [sssd] >> services = nss, sudo, pam, ssh >> domains = vgt.vito.be >> [nss] >> homedir_substring = /home >> debug_level = 7 >> [pam] >> [sudo] >> [autofs] >> [ssh] >> [pac] >> [ifp] >> >> >> here's the log of sssd_nss.log >> >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [accept_fd_handler] (0x0400): Client >> connected! >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): >> Received client version [1]. >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): >> Offered version [1]. >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running >> command [17][SSS_NSS_GETPWNAM] with input [vdbornem]. >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_parse_name_for_domains] >> (0x0200): name 'vdbornem' matched without domain, user is vdbornem >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0100): >> Requesting info for [vdbornem] from [] >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): >> Requesting info for [vdbornem at vgt.vito.be] >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a >> LOCAL view, continuing with provided values. >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_issue_request] (0x0400): >> Issuing request for [0x7f7ffd1d1880:1:vdbornem at vgt.vito.be@vgt.vito.be] >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): >> Creating request for >> [vgt.vito.be][0x1][BE_REQ_USER][1][name=vdbornem at vgt.vito.be:-] >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): >> Entering request [0x7f7ffd1d1880:1:vdbornem at vgt.vito.be@vgt.vito.be] >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data >> Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline] >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): >> Unable to get information from Data Provider >> Error: 3, 5, Failed to get reply from Data Provider >> Will try to return what we have in cache >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [sss_dp_req_destructor] (0x0400): >> Deleting request: [0x7f7ffd1d1880:1:vdbornem at vgt.vito.be@vgt.vito.be] >> (Wed Mar 22 16:27:22 2017) [sssd[nss]] [client_recv] (0x0200): Client >> disconnected! > Restart sssd, which starts from a clean slate, then look for the first > occurence of "Going offline" or "Not working" in the logs, then check > which operation triggered that.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Thu Mar 23 07:14:10 2017 From: dkupka at redhat.com (David Kupka) Date: Thu, 23 Mar 2017 08:14:10 +0100 Subject: [Freeipa-users] One kerberos realm, two dns zones and SSHFP records In-Reply-To: <1490210946.2324.130.camel@thesandhufamily.ca> References: <1490210946.2324.130.camel@thesandhufamily.ca> Message-ID: <20170323071410.GA5066@dkupka.usersys.redhat.com> On Wed, Mar 22, 2017 at 03:29:06PM -0400, Ranbir wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Everyone, > > I'm using a fully updated CentOS 7.3 environment for two IPA servers. I > have one kerberos realm, one dns zone with the same name as the > kerberos realm and another dns zone with a different name. DNS is > managed by IPA. For the sake of this message: > > realm: REALM.IPA > dnszone1: realm.ipa > dnszone2: random.ipa > > When I join a server that's going into the realm.ipa dns zone to the > IPA domain, SSHFP records for that server get automatically created in > realm.ipa. But, when I do the same for a server going into the > random.ipa dns zone, the SSHFP aren't automatically created. I have to > do add the SSHFP records manually after the client install completes. > > Why are SSHFP records not added automatically for the second dns zone > and I how can I fix this situation? > > Thanks in advance. > > Ranbir > > > - -- > Ranbir > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCgAGBQJY0tCCAAoJEN7T/ly5z1dik3cP/0Xx0Vk0cIfbloYJuVb1ffMH > mJzKg3BaSEasWL3mJSsgPQS7CZWFi6PgBZLc79nwJhve1tAZC5+pMwVZwY9F7U9a > liZdK1l7a0agpDwnupISdih5PG6TGNEfVjHezKKwnDgjUWMOqak7BM3KIffjhNzc > SpuZHUDuY8QD2DeyO8iuuJjt+BUiWJ+Weh1OJq4UKWT68wALc/TbdtLi5OWlFtnV > rClTbOhPvm8I4Md3DT0vDdhKqPiUvBGPKgse7HZIN9G4W6/wpM3hU1+ETYgXWqIX > yRSK0rjjxfrWKIqRUB1sCKLlkdd+wMaRa/uCnRgvRhYjYUrwyPaH11N41lvE7zUz > ccJnaZXkDcIWW9wkAQxx3XXx5vHR33VTS13nkZv4QsHSoJOXcqrsr+Q1r28WmLcZ > wb3osINWIEmFCX6knZVRZLDhAefHz+FVsJwzsh6iCdqar+LzFvR0hRUJ0Fepxs8M > bkKEZ3LztTtDssX+AO7CqkMZSQ5DHiT9Yo1gHXr2zTEt3qzxyuE0GjMyXzBWyMV4 > TpOXoRVQMUvEEV2ecpEATBEKghqXOMqhSeGAObfdlEKADTt11u8ONxwutFYPxybD > Sxfd6yvg2/QvB8GYgLMkENuJWdwbFYrlb3GQ04TKjcW6TklcRyjsI8x/Wg3LjofQ > AEtlIGyrGau9jPaeHYwd > =mJn4 > -----END PGP SIGNATURE----- > > -- > 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 Hello Ranbir, are other records (A, AAAA, PTR, ...) created for the client in random.ipa and just SSHFP missing? Is the domain random.ipa properly delegated? Is sshd installed and keys generated on client in random.ipa? -- David Kupka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From mbasti at redhat.com Thu Mar 23 09:34:34 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 23 Mar 2017 10:34:34 +0100 Subject: [Freeipa-users] One kerberos realm, two dns zones and SSHFP records In-Reply-To: <1490210946.2324.130.camel@thesandhufamily.ca> References: <1490210946.2324.130.camel@thesandhufamily.ca> Message-ID: On 03/22/2017 08:29 PM, Ranbir wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Everyone, > > I'm using a fully updated CentOS 7.3 environment for two IPA servers. I > have one kerberos realm, one dns zone with the same name as the > kerberos realm and another dns zone with a different name. DNS is > managed by IPA. For the sake of this message: > > realm: REALM.IPA > dnszone1: realm.ipa > dnszone2: random.ipa > > When I join a server that's going into the realm.ipa dns zone to the > IPA domain, SSHFP records for that server get automatically created in > realm.ipa. But, when I do the same for a server going into the > random.ipa dns zone, the SSHFP aren't automatically created. I have to > do add the SSHFP records manually after the client install completes. > > Why are SSHFP records not added automatically for the second dns zone > and I how can I fix this situation? > > Thanks in advance. > > Ranbir > > > - -- > Ranbir > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCgAGBQJY0tCCAAoJEN7T/ly5z1dik3cP/0Xx0Vk0cIfbloYJuVb1ffMH > mJzKg3BaSEasWL3mJSsgPQS7CZWFi6PgBZLc79nwJhve1tAZC5+pMwVZwY9F7U9a > liZdK1l7a0agpDwnupISdih5PG6TGNEfVjHezKKwnDgjUWMOqak7BM3KIffjhNzc > SpuZHUDuY8QD2DeyO8iuuJjt+BUiWJ+Weh1OJq4UKWT68wALc/TbdtLi5OWlFtnV > rClTbOhPvm8I4Md3DT0vDdhKqPiUvBGPKgse7HZIN9G4W6/wpM3hU1+ETYgXWqIX > yRSK0rjjxfrWKIqRUB1sCKLlkdd+wMaRa/uCnRgvRhYjYUrwyPaH11N41lvE7zUz > ccJnaZXkDcIWW9wkAQxx3XXx5vHR33VTS13nkZv4QsHSoJOXcqrsr+Q1r28WmLcZ > wb3osINWIEmFCX6knZVRZLDhAefHz+FVsJwzsh6iCdqar+LzFvR0hRUJ0Fepxs8M > bkKEZ3LztTtDssX+AO7CqkMZSQ5DHiT9Yo1gHXr2zTEt3qzxyuE0GjMyXzBWyMV4 > TpOXoRVQMUvEEV2ecpEATBEKghqXOMqhSeGAObfdlEKADTt11u8ONxwutFYPxybD > Sxfd6yvg2/QvB8GYgLMkENuJWdwbFYrlb3GQ04TKjcW6TklcRyjsI8x/Wg3LjofQ > AEtlIGyrGau9jPaeHYwd > =mJn4 > -----END PGP SIGNATURE----- > Do you have enabled dynamic-updates in random.ipa. zone? Could you check nsupdate output in /var/log/ipaclient-install.log ? From mbasti at redhat.com Thu Mar 23 18:15:52 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 23 Mar 2017 19:15:52 +0100 Subject: [Freeipa-users] Announcing FreeIPA 4.4.4 Message-ID: <03a0c3e1-a1f6-638f-e550-abff5f8c846f@redhat.com> Release date: 2017-03-23 The FreeIPA team would like to announce FreeIPA 4.4.4 release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora 24 will be available in the official COPR repository . This announcement is also available at. == Highlights in 4.4.4 == === Enhancements === === Known Issues === === Bug fixes === FreeIPA 4.4.4 is a stabilization release for the features delivered as a part of 4.4.0. == Upgrading == Upgrade instructions are available on [[Upgrade]] page. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Resolved tickets == * 6776 krb5 1.15 broke DAL principal free * 6738 Ipa-kra-install fails with weird output when backspace is used during typing Directory Manager password * 6713 ipa: Insufficient permission check for ca-del, ca-disable and ca-enable commands (CVE-2017-2590) * 6647 batch param compatibility is incorrect * 6608 IPA server installation should check if IPv6 stack is enabled * 6600 Legacy client tests doesn't have tree domain role. * 6588 replication race condition prevents IPA to install * 6575 ipa-replica-install fails on requesting DS cert when master is not configured with IPv6 * 6070 ipa-replica-install fails to install when resolv.conf incomplete entries == Detailed changelog since 4.4.3 == === Alexander Bokovoy (1) === * ipa-kdb: support KDB DAL version 6.1 === David Kupka (1) === * ipapython.ipautil.nolog_replace: Do not replace empty value === Florence Blanc-Renaud (1) === * Do not configure PKI ajp redirection to use "::1" === Fraser Tweedale (2) === * ca: correctly authorise ca-del, ca-enable and ca-disable * Set up DS TLS on replica in CA-less topology === Ganna Kaihorodova (1) === * Tests: Add tree root domain role in legacy client tests === Jan Cholasta (1) === * compat: fix `Any` params in `batch` and `dnsrecord` === Martin Basti (7) === * Become IPA 4.4.4 * Update Contributors.txt * FreeIPA 4.4.4 translations * Bump python-dns to improve processing of non-complete resolv.conf * Use proper logging for error messages * Wait until HTTPS principal entry is replicated to replica * wait_for_entry: use only DN as parameter === Stanislav Laznicka (2) === * Add debug log in case cookie retrieval went wrong * Fix cookie with Max-Age processing === Tomas Krizek (1) === * server install: require IPv6 stack to be enabled === Thorsten Scherf (1) === * added ssl verification using IPA trust anchor -------------- next part -------------- An HTML attachment was scrubbed... URL: From graziee at gmail.com Thu Mar 23 18:38:47 2017 From: graziee at gmail.com (grace rante thompson) Date: Thu, 23 Mar 2017 11:38:47 -0700 Subject: [Freeipa-users] Authenticating windows users Message-ID: Hi, We are primarily linux/osx shop and we currently have FreeIPA/IDM (ver 4.2) as our master. I will need to add a handful of windows machines and been trying to figure out how to authenticate our windows users with FreeIPA/IDM. Is this even possible? I know Global Catalogs may not happen anytime soon (sad face). I'm open to -all- ideas, even if it is a paid solution (not sure if centrify and the likes can sync up to FreeIPA/IDM). thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From graziee at gmail.com Thu Mar 23 18:48:10 2017 From: graziee at gmail.com (grace rante thompson) Date: Thu, 23 Mar 2017 11:48:10 -0700 Subject: [Freeipa-users] Authenticating windows users In-Reply-To: <594422541.3454.1490294776166.JavaMail.zimbra@tresgeek.net> References: <594422541.3454.1490294776166.JavaMail.zimbra@tresgeek.net> Message-ID: Thanks Jason, but those documents need AD as the primary authenticator. This is not the case for us. On Thu, Mar 23, 2017 at 11:46 AM, Jason B. Nance wrote: > We are primarily linux/osx shop and we currently have FreeIPA/IDM (ver > 4.2) as our master. I will need to add a handful of windows machines and > been trying to figure out how to authenticate our windows users with > FreeIPA/IDM. Is this even possible? I know Global Catalogs may not happen > anytime soon (sad face). I'm open to -all- ideas, even if it is a paid > solution (not sure if centrify and the likes can sync up to FreeIPA/IDM). > > I would start here: > > https://www.freeipa.org/page/Windows_authentication_against_FreeIPA > > https://www.freeipa.org/page/Implementing_FreeIPA_in_a_ > mixed_Environment_(Windows/Linux)_-_Step_by_step > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From loris at lgs.com.ve Thu Mar 23 18:53:33 2017 From: loris at lgs.com.ve (Loris Santamaria) Date: Thu, 23 Mar 2017 14:53:33 -0400 Subject: [Freeipa-users] Authenticating windows users In-Reply-To: References: Message-ID: <1490295213.15110.7.camel@lgs.com.ve> Hi,? this is not a scalable solution in any way but it may work for you if you just have a couple of windows machines: https://www.redhat.com/archives/freeipa-users/2013-September/msg00226.h tml Loris El jue, 23-03-2017 a las 11:38 -0700, grace rante thompson escribi?: > Hi,? > > We are primarily linux/osx shop and we currently have FreeIPA/IDM > (ver 4.2) as our master. I will need to add a handful of windows > machines and been trying to figure out how to authenticate our > windows users with FreeIPA/IDM. Is this even possible? I know Global > Catalogs may not happen anytime soon (sad face).? I'm open to -all- > ideas, even if it is a paid solution (not sure if centrify and the > likes can sync up to FreeIPA/IDM).? > > thanks > > > --? Loris Santamaria???linux user #70506???xmpp:loris at lgs.com.ve Links Global Services, C.A.????????????http://www.lgs.com.ve Tel: 0286 952.06.87??Cel: 0414 095.00.10??sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Mar 23 19:06:58 2017 From: mbasti at redhat.com (Martin Basti) Date: Thu, 23 Mar 2017 20:06:58 +0100 Subject: [Freeipa-users] Announcing FreeIPA 4.3.3 Message-ID: Release date: 2017-03-23 The FreeIPA team would like to announce FreeIPA 4.3.3 release! It can be downloaded from http://www.freeipa.org/page/Downloads. Please note that this is the last upstream release of FreeIPA 4.3.x branch. This announcement is also available at . == Highlights in 4.3.3 == === Enhancements === === Known Issues === === Bug fixes === FreeIPA 4.3.3 is a stabilization release for the features delivered as a part of 4.3.0. There are more than 20 bug-fixes which details can be seen in the list of resolved tickets below. == Upgrading == Upgrade instructions are available on [[Upgrade]] page. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Resolved tickets == * 6774 FreeIPA client <= 4.4 fail to parse 4.5 cookies * 6561 CVE-2016-7030 freeipa: ipa: DoS attack against kerberized services by abusing password policy * 6560 CVE-2016-9575 freeipa: ipa: Insufficient permission check in certprofile-mod * 6485 Document make_delete_command method in UserTracker * 6378 Tests: Fix failing sudo test * 6317 backport #6213 Incorrect test for DNSForwardPolicyConflictWithEmptyZone warning in test_xmlrpc/test_dns_plugin * 6316 backport #6199 Received ACIError instead of DuplicatedError in stageuser_tests * 6311 Fix or remove the `LDAPUpdate.update_from_dict` method * 6287 Refer to nodes in TestWrongClientDomain replica promotion tests as replicas * 6284 Tests: avoid skipping tests because of missing files when running as outoftree * 6278 Use OAEP padding with custodia (to avoid CVE-2016-6298) * 6262 Fix integration sudo tests setup and checks * 6254 kinit_admin raises an exception if server uninstallation is called from test teardown with server not installed * 6244 build: add python-libsss_nss_idmap and python-sss to BuildRequires * 6205 The ipa-server-upgrade command failed when named-pkcs11 does not happen to run during dnf upgrade * 6177 ca-less test are broken - invalid usage of ipautil.run * 6167 Incorrect domainlevel info in tests * 6166 Subsequent external CA installation fails * 6147 Failing automember tests due to manager output normalization * 6134 Command "ipa-replica-prepare" not allowed to create line replication topology * 6120 ipa-adtrust-install: when running with --netbios-name="", the NetBIOS name is changed without notification * 6076 Mulitple domain Active Directory Trust conflict * 6056 custodia.conf and server.keys file is world-readable. * 6016 ipa-ca-install on replica tries to connect to master:8443 * 5696 Add conflicts with bind-chroot to spec. == Detailed changelog since 4.3.2 == === Alexander Bokovoy (5) === * ipa-kdb: search for password policies globally * ipa-kdb: simplify trusted domain parent search * trust: make sure ID range is created for the child domain even if it exists * trust: automatically resolve DNS trust conflicts for triangle trusts * ipaserver/dcerpc: reformat to make the code closer to pep8 === Christian Heimes (3) === * Use RSA-OAEP instead of RSA PKCS#1 v1.5 * Secure permissions of Custodia server.keys * RedHatCAService should wait for local Dogtag instance === David Kupka (1) === * password policy: Add explicit default password policy for hosts and services === Fraser Tweedale (2) === * certprofile-mod: correctly authorise config update * cert-revoke: fix permission check bypass (CVE-2016-5404) === Ganna Kaihorodova (1) === * Fix for integration tests replication layouts === Jan Cholasta (2) === * Revert "spec: add conflict with bind-chroot to freeipa-server-dns" * install: fix external CA cert validation === Lenka Doudova (7) === * Document make_delete_command method in UserTracker * Tests: Fix integration sudo test * Tests: Fix integration sudo tests setup and checks * Tests: Avoid skipping tests due to missing files * Raise error when running ipa-adtrust-install with empty netbios--name * Tests: Fix failing automember tests * Tests: Remove DNS configuration from trust tests === Martin Babinsky (1) === * add python-libsss_nss_idmap and python-sss to BuildRequires === Martin Basti (5) === * Become IPA 4.3.3 * Update Contributors.txt * Raise DuplicatedEnrty error when user exists in delete_container * Catch DNS exceptions during emptyzones named.conf upgrade * Start named during configuration upgrade. === Oleg Fayans (3) === * Changed addressing to the client hosts to be replicas * Disabled raiseonerr in kinit call during topology level check * Fixed incorrect domainlevel determination in tests === Peter Lacko (1) === * Test URIs in certificate. === Petr Spacek (3) === * Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin * DNS server upgrade: do not fail when DNS server did not respond * Fix ipa-replica-prepare's error message about missing local CA instance === Petr Vobornik (1) === * ca-less tests: fix getting cert in pem format from nssdb === Stanislav Laznicka (3) === * Add debug log in case cookie retrieval went wrong * Fix cookie with Max-Age processing * Remove update_from_dict() method === Tomas Krizek (1) === * Keep NSS trust flags of existing certificates -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at tresgeek.net Thu Mar 23 18:46:16 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Thu, 23 Mar 2017 13:46:16 -0500 (CDT) Subject: [Freeipa-users] Authenticating windows users In-Reply-To: References: Message-ID: <594422541.3454.1490294776166.JavaMail.zimbra@tresgeek.net> > We are primarily linux/osx shop and we currently have FreeIPA/IDM (ver 4.2) as > our master. I will need to add a handful of windows machines and been trying to > figure out how to authenticate our windows users with FreeIPA/IDM. Is this even > possible? I know Global Catalogs may not happen anytime soon (sad face). I'm > open to -all- ideas, even if it is a paid solution (not sure if centrify and > the likes can sync up to FreeIPA/IDM). I would start here: https://www.freeipa.org/page/Windows_authentication_against_FreeIPA https://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at tresgeek.net Thu Mar 23 18:52:45 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Thu, 23 Mar 2017 13:52:45 -0500 (CDT) Subject: [Freeipa-users] Authenticating windows users In-Reply-To: References: <594422541.3454.1490294776166.JavaMail.zimbra@tresgeek.net> Message-ID: <2024599693.3536.1490295165870.JavaMail.zimbra@tresgeek.net> > Thanks Jason, but those documents need AD as the primary authenticator. This is > not the case for us. I think you need to read them a bit closer. Very first line of first link says: "This article describes direct integration between FreeIPA and Windows machine, i.e. without involving Active Directory server." > On Thu, Mar 23, 2017 at 11:46 AM, Jason B. Nance < [ mailto:jason at tresgeek.net | > jason at tresgeek.net ] > wrote: >>> We are primarily linux/osx shop and we currently have FreeIPA/IDM (ver 4.2) as >>> our master. I will need to add a handful of windows machines and been trying to >>> figure out how to authenticate our windows users with FreeIPA/IDM. Is this even >>> possible? I know Global Catalogs may not happen anytime soon (sad face). I'm >>> open to -all- ideas, even if it is a paid solution (not sure if centrify and >>> the likes can sync up to FreeIPA/IDM). >> I would start here: >> [ https://www.freeipa.org/page/Windows_authentication_against_FreeIPA | >> https://www.freeipa.org/page/Windows_authentication_against_FreeIPA ] >> [ >> https://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step >> | >> https://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step >> ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at sudo.nz Thu Mar 23 22:51:34 2017 From: list at sudo.nz (Dagan) Date: Thu, 23 Mar 2017 22:51:34 +0000 Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x Message-ID: <535BEF94-7EE4-4D90-AB61-C409544E2115@sudo.nz> Hi, I am hoping someone will be able to help answer some questions about migrations. I have been asked to look at upgrading an existing FreeIPA installation on CentOS 6 (3.0.0) to a new installation on CentOS 7 with a recent stable release (4.4.0). The existing CentOS 6 installation does not manage DNS or have a CA that is being used (though the may be installed. It's primarily for user authentication and user group management. There are only a small number of users, groups, and hosts to migrate - less than 100 of each. But the data is used for LDAP integration in various applications so it needs to be consistent. Would it be recommended to do a straight LDIF type export and import of the data, and configure the new FreeIPA installation for the new access/sudo rules? Would that risk leaving behind any data I would need to know about? We are planning to review the sudo rules, host access lists etc as part of the migration work. So leaving behind some data may not be a blocker to upgrade. Any suggestions or links welcome. Cheers, Dagan McGregor From zak.peirce at zoom.us Thu Mar 23 23:54:20 2017 From: zak.peirce at zoom.us (Zak Peirce) Date: Thu, 23 Mar 2017 16:54:20 -0700 Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x In-Reply-To: <535BEF94-7EE4-4D90-AB61-C409544E2115@sudo.nz> References: <535BEF94-7EE4-4D90-AB61-C409544E2115@sudo.nz> Message-ID: <1846e5f04c6e755a06b65ec347609097@mail.gmail.com> I am looking to take this same journey. I found this guide, it seems like it covers all the bases https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/h tml/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrade-6-to-7.h tml -Zak -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dagan Sent: Thursday, March 23, 2017 3:52 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x Hi, I am hoping someone will be able to help answer some questions about migrations. I have been asked to look at upgrading an existing FreeIPA installation on CentOS 6 (3.0.0) to a new installation on CentOS 7 with a recent stable release (4.4.0). The existing CentOS 6 installation does not manage DNS or have a CA that is being used (though the may be installed. It's primarily for user authentication and user group management. There are only a small number of users, groups, and hosts to migrate - less than 100 of each. But the data is used for LDAP integration in various applications so it needs to be consistent. Would it be recommended to do a straight LDIF type export and import of the data, and configure the new FreeIPA installation for the new access/sudo rules? Would that risk leaving behind any data I would need to know about? We are planning to review the sudo rules, host access lists etc as part of the migration work. So leaving behind some data may not be a blocker to upgrade. Any suggestions or links welcome. Cheers, Dagan McGregor -- 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 From rstory at tislabs.com Fri Mar 24 00:25:32 2017 From: rstory at tislabs.com (Robert Story) Date: Thu, 23 Mar 2017 20:25:32 -0400 Subject: [Freeipa-users] replication mess Message-ID: <20170323202532.7764633b@ispx.vb.futz.org> Hello, we have 2 auth servers with a replication agreement. Turns out that auth-2 had network issues that went unnoticed from some time after a reboot. This wasn't discovered until after a yum update on auth-1 this morning. Now my logfile is filling up with this message: [23/Mar/2017:10:33:58.923454036 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): CSN 586175b0000000600000 not found, we aren't as up to date, or we purged I'm not quite sure how to proceed. auth-2 network was fixed, and yum updated as well. Here are the replication error messages on auth-1 from today. You can see where it came up after the yum update around 08:56, and where auth-2 came up around 10:33. [23/Mar/2017:08:56:13.006916824 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=XXX. Check if DB RUV needs to be updated [23/Mar/2017:08:56:13.107849258 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated [23/Mar/2017:08:56:17.107916747 -0400] NSMMReplicationPlugin - agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:08:56:17.222567755 -0400] NSMMReplicationPlugin - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:09:42:22.306319176 -0400] NSMMReplicationPlugin - ruv_compare_ruv: the max CSN [58d3852e000000600000] from RUV [database RUV] is larger than the max CSN [58d381ab000000600000] from RUV [changelog max RUV] for element [{replica 96 ldap://auth-1.XXX:389} 585cae49000000600000 58d3852e000000600000] [23/Mar/2017:09:42:22.336995007 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data for replica o=ipaca does not match the data in the changelog. Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. [23/Mar/2017:09:42:54.126984585 -0400] NSMMReplicationPlugin - agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:09:44:43.187606945 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-NETSEC/cldb/509e3886-c88911e6-bead9c0e-906bed50.sema; NSPR error - -5943 [23/Mar/2017:09:45:13.525102119 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-NETSEC/cldb/f377a685-c8cb11e6-bead9c0e-906bed50.sema; NSPR error - -5943 [23/Mar/2017:09:45:13.971420939 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=XXX. Check if DB RUV needs to be updated [23/Mar/2017:09:45:14.024029592 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated [23/Mar/2017:09:45:19.314736866 -0400] NSMMReplicationPlugin - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:09:46:30.253821850 -0400] NSMMReplicationPlugin - agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:09:48:39.269006200 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-NETSEC/cldb/509e3886-c88911e6-bead9c0e-906bed50.sema; NSPR error - -5943 [23/Mar/2017:09:49:26.639767435 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-NETSEC/cldb/f377a685-c8cb11e6-bead9c0e-906bed50.sema; NSPR error - -5943 [23/Mar/2017:09:49:26.762324568 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=XXX. Check if DB RUV needs to be updated [23/Mar/2017:09:49:26.813931624 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated [23/Mar/2017:09:49:37.397494832 -0400] NSMMReplicationPlugin - agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:09:49:37.756217644 -0400] NSMMReplicationPlugin - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:09:51:06.555004134 -0400] NSMMReplicationPlugin - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:09:51:06.616444861 -0400] NSMMReplicationPlugin - agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:10:27:26.076130103 -0400] NSMMReplicationPlugin - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:10:27:26.208080067 -0400] NSMMReplicationPlugin - agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [23/Mar/2017:10:33:47.546474913 -0400] NSMMReplicationPlugin - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Replication bind with SIMPLE auth resumed [23/Mar/2017:10:33:47.588128814 -0400] NSMMReplicationPlugin - agmt="cn=meToauth-2.XXX" (auth-2:389): Replication bind with GSSAPI auth resumed [23/Mar/2017:10:33:50.852781071 -0400] NSMMReplicationPlugin - [S] Schema agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389) must not be overwritten (set replication log for additional info) [23/Mar/2017:10:33:51.089308587 -0400] NSMMReplicationPlugin - [S] Schema agmt="cn=meToauth-2.XXX" (auth-2:389) must not be overwritten (set replication log for additional info) [23/Mar/2017:10:33:53.444495512 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): CSN 586175b0000000600000 not found, we aren't as up to date, or we purged [23/Mar/2017:10:33:53.501394903 -0400] NSMMReplicationPlugin - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): Data required to update replica has been purged from the changelog. The replica must be reinitialized. [23/Mar/2017:10:33:58.923454036 -0400] NSMMReplicationPlugin - changelog program - agmt="cn=masterAgreement1-auth-2.XXX-pki-tomcat" (auth-2:389): CSN 586175b0000000600000 not found, we aren't as up to date, or we purged I tried to re-initialize auth-2: auth-2 # ipa-replica-manage re-initialize --from=auth-1.XXX Directory Manager password: ipa: INFO: Setting agreement cn=meToauth-2.XXX,cn=replica,cn=dc\=XXX,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn=meToauth-2.XXX,cn=replica,cn=dc\=XXX,cn=mapping tree,cn=config Update in progress, 6 seconds elapsed Update succeeded but the errors continue on auth-1. Any suggestions on how to fix this would be greatly appreciated. Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From ianh at brownpapertickets.com Fri Mar 24 05:10:04 2017 From: ianh at brownpapertickets.com (Ian Harding) Date: Thu, 23 Mar 2017 22:10:04 -0700 Subject: [Freeipa-users] Funny Looking Records Message-ID: <05d4f07f-8c64-6d15-87bf-a97edd4dd96e@brownpapertickets.com> I have some funny looking records left over from a deleted replica. I think this is why I see it in the list of servers and can't delete the server. ldapsearch -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks' dn ## These records have the name of the deleted server in them ## dn: cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=CA+nsuniqueid=5148cf38-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=KDC+nsuniqueid=5148cf40-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=KPASSWD+nsuniqueid=5148cf41-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=MEMCACHE+nsuniqueid=5148cf42-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=HTTP+nsuniqueid=5148cf45-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=OTPD+nsuniqueid=5148cf46-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=DNS+nsuniqueid=9cfb790e-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks How can I make them go away? -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com From mbabinsk at redhat.com Fri Mar 24 07:28:46 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 24 Mar 2017 08:28:46 +0100 Subject: [Freeipa-users] Funny Looking Records In-Reply-To: <05d4f07f-8c64-6d15-87bf-a97edd4dd96e@brownpapertickets.com> References: <05d4f07f-8c64-6d15-87bf-a97edd4dd96e@brownpapertickets.com> Message-ID: <20170324072844.GB3928@dhcp129-180.brq.redhat.com> On Thu, Mar 23, 2017 at 10:10:04PM -0700, Ian Harding wrote: >I have some funny looking records left over from a deleted replica. I >think this is why I see it in the list of servers and can't delete the >server. > >ldapsearch -D 'cn=Directory Manager' -W -b >'cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks' dn > >## These records have the name of the deleted server in them ## > > >dn: >cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks >dn: >cn=CA+nsuniqueid=5148cf38-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks >dn: >cn=KDC+nsuniqueid=5148cf40-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks >dn: >cn=KPASSWD+nsuniqueid=5148cf41-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks >dn: >cn=MEMCACHE+nsuniqueid=5148cf42-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks >dn: >cn=HTTP+nsuniqueid=5148cf45-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks >dn: >cn=OTPD+nsuniqueid=5148cf46-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks >dn: >cn=DNS+nsuniqueid=9cfb790e-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks > >How can I make them go away? > >-- >Ian Harding >IT Director >Brown Paper Tickets >1-800-838-3006 ext 7186 >http://www.brownpapertickets.com > >-- >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 These are replication conflicts, please consult https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html on how to handle them. -- Martin Babinsky From slaznick at redhat.com Fri Mar 24 08:32:56 2017 From: slaznick at redhat.com (Standa Laznicka) Date: Fri, 24 Mar 2017 09:32:56 +0100 Subject: [Freeipa-users] Authenticating windows users In-Reply-To: <2024599693.3536.1490295165870.JavaMail.zimbra@tresgeek.net> References: <594422541.3454.1490294776166.JavaMail.zimbra@tresgeek.net> <2024599693.3536.1490295165870.JavaMail.zimbra@tresgeek.net> Message-ID: <467a7e0e-0f50-2399-7b75-8976c8347885@redhat.com> I changed the text emphasis so that this is more clear in the future, thanks for noticing. On 03/23/2017 07:52 PM, Jason B. Nance wrote: > > Thanks Jason, but those documents need AD as the primary > authenticator. This is not the case for us. > > I think you need to read them a bit closer. Very first line of first > link says: > > "This article describes direct integration between FreeIPA and Windows > machine, i.e. without involving Active Directory server." > > > > On Thu, Mar 23, 2017 at 11:46 AM, Jason B. Nance > > wrote: > > We are primarily linux/osx shop and we currently have > FreeIPA/IDM (ver 4.2) as our master. I will need to add a > handful of windows machines and been trying to figure out > how to authenticate our windows users with FreeIPA/IDM. Is > this even possible? I know Global Catalogs may not happen > anytime soon (sad face). I'm open to -all- ideas, even if > it is a paid solution (not sure if centrify and the likes > can sync up to FreeIPA/IDM). > > I would start here: > > https://www.freeipa.org/page/Windows_authentication_against_FreeIPA > > https://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at collective-sense.com Fri Mar 24 09:13:34 2017 From: md at collective-sense.com (Maciej Drobniuch) Date: Fri, 24 Mar 2017 10:13:34 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <54387995-42a5-56a0-7d17-a4f69c9b06b3@stroeder.com> References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> <20170211130612.vyytog6wmgz23ufw@redhat.com> <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> <20170211151139.sxoqupkh6i7corpp@redhat.com> <54387995-42a5-56a0-7d17-a4f69c9b06b3@stroeder.com> Message-ID: Hi All, I'm trying to integrate Freeipa with jenkins and ldap auth plugin. The thing with the Freeipa LDAP server is: * Only Directory Manager can read userPassword field (not sure yet how to create a sysaccount which can read the field. ldifs are welcome ;) * The userPassword field contains the password in salted SHA (SSHA) format. >From what I've observed the standard LDAP auth functions do not do the SSHA or any other type of calculations. The password is compared to the plain text that's usually(in a typical OpenLDAP server) stored in the userPassword field(correct me if I'm wrong) * I've managed to integrate CACTI with freeipa by base64 decoding the userPassword field then calculating the salted hash and comparing to the userPassword field. (php code modification was required). * I think the only way is to modify the jenkins LDAP plugin (?). The problem: * I don't want to use sssd PAM because we have OTP enabled and that would annoy users(?) additionally it's causing some unidentified build issues BTW> Can I disable OTP per server? * I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not connected to the principal(no control over them yet) * I want simple LDAP auth ;-) Ideas & suggestions are welcome! M. On Sat, Feb 11, 2017 at 4:28 PM, Michael Str?der wrote: > Alexander Bokovoy wrote: > > On la, 11 helmi 2017, Michael Str?der wrote: > >> Alexander Bokovoy wrote: > >>> On la, 11 helmi 2017, Harald Dunkel wrote: > >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: > >>>>> On la, 11 helmi 2017, Michael Str?der wrote: > >>>>>> > >>>>>> (Personally I'd avoid going through PAM.) > >>>>> Any specific reason for not using pam_sss? Remember, with SSSD > involved > >>>>> you get also authentication for trusted users from Active Directory > >>>>> realms. You don't get that with generic LDAP way. Also, you'd be more > >>>>> efficient in terms of utilising LDAP connections. > >>>>> > >>>> > >>>> I would prefer if the users are not allowed to login into a > >>>> shell on the Jenkins server. Surely this restriction can be > >>>> implemented with pam as well. > >>> > >>> Yes, you can use HBAC rules to prevent them from access to the host. > >> > >> But this introduces a hard dependency on host system administration > which I personally > >> always try to avoid. > >> > >> As said: Your mileage may vary. > > > > So we are talking about FreeIPA and a system enrolled to FreeIPA. This > > system is already managed in FreeIPA. > > Please don't get me wrong. Of course I assume that the original poster > wants to integrate > Jenkins with FreeIPA and make use of users and their group membership > already maintained > therein. > > Let's further assume that the service (here Jenkins) might be operated by > another team > than the system - not so unusual case at my customers' sites - relying on > defining HBAC > rules for the system's sssd might not be feasible. > > > Your mileage may vary, indeed, but I'd rather re-use what is available > > to you than implement a parallel infrastructure, including reliability > > aspects. > > Of course we both agree on the benefits of using what's already available. > > > Anyway, I think we are distancing away from the original topic. > > Especially since we both can only make rough assumptions about > requirements and > operational constraints of the original poster. > > Ciao, Michael. > > > -- > 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 > -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Mar 24 09:46:26 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Mar 2017 11:46:26 +0200 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> <20170211130612.vyytog6wmgz23ufw@redhat.com> <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> <20170211151139.sxoqupkh6i7corpp@redhat.com> <54387995-42a5-56a0-7d17-a4f69c9b06b3@stroeder.com> Message-ID: <20170324094626.s7rp3uhxvy7y3mcv@redhat.com> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >Hi All, > >I'm trying to integrate Freeipa with jenkins and ldap auth plugin. > >The thing with the Freeipa LDAP server is: >* Only Directory Manager can read userPassword field (not sure yet how to >create a sysaccount which can read the field. ldifs are welcome ;) This is absolutely not needed. You should configure Jenkins to perform LDAP bind with user password against IPA LDAP server, that's all. This is supported by acegi security framework that Jenkins LDAP plugin is using. For example, https://github.com/jenkinsci/ldap-plugin/blob/master/src/main/resources/hudson/security/LDAPBindSecurityRealm.groovy actually uses org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 which does support normal LDAP bind. I think it is, in fact, a default setup for Jenkins LDAP auth plugin, so you actually needed to do something to disable this path. >* The userPassword field contains the password in salted SHA (SSHA) format. >From what I've observed the standard LDAP auth functions do not do the SSHA >or any other type of calculations. The password is compared to the plain >text that's usually(in a typical OpenLDAP server) stored in the >userPassword field(correct me if I'm wrong) >* I've managed to integrate CACTI with freeipa by base64 decoding the >userPassword field then calculating the salted hash and comparing to the >userPassword field. (php code modification was required). >* I think the only way is to modify the jenkins LDAP plugin (?). > >The problem: >* I don't want to use sssd PAM because we have OTP enabled and that would >annoy users(?) additionally it's causing some unidentified build issues >BTW> Can I disable OTP per server? >* I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not >connected to the principal(no control over them yet) >* I want simple LDAP auth ;-) So use simple LDAP bind. > >Ideas & suggestions are welcome! > >M. > >On Sat, Feb 11, 2017 at 4:28 PM, Michael Str?der >wrote: > >> Alexander Bokovoy wrote: >> > On la, 11 helmi 2017, Michael Str?der wrote: >> >> Alexander Bokovoy wrote: >> >>> On la, 11 helmi 2017, Harald Dunkel wrote: >> >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: >> >>>>> On la, 11 helmi 2017, Michael Str?der wrote: >> >>>>>> >> >>>>>> (Personally I'd avoid going through PAM.) >> >>>>> Any specific reason for not using pam_sss? Remember, with SSSD >> involved >> >>>>> you get also authentication for trusted users from Active Directory >> >>>>> realms. You don't get that with generic LDAP way. Also, you'd be more >> >>>>> efficient in terms of utilising LDAP connections. >> >>>>> >> >>>> >> >>>> I would prefer if the users are not allowed to login into a >> >>>> shell on the Jenkins server. Surely this restriction can be >> >>>> implemented with pam as well. >> >>> >> >>> Yes, you can use HBAC rules to prevent them from access to the host. >> >> >> >> But this introduces a hard dependency on host system administration >> which I personally >> >> always try to avoid. >> >> >> >> As said: Your mileage may vary. >> > >> > So we are talking about FreeIPA and a system enrolled to FreeIPA. This >> > system is already managed in FreeIPA. >> >> Please don't get me wrong. Of course I assume that the original poster >> wants to integrate >> Jenkins with FreeIPA and make use of users and their group membership >> already maintained >> therein. >> >> Let's further assume that the service (here Jenkins) might be operated by >> another team >> than the system - not so unusual case at my customers' sites - relying on >> defining HBAC >> rules for the system's sssd might not be feasible. >> >> > Your mileage may vary, indeed, but I'd rather re-use what is available >> > to you than implement a parallel infrastructure, including reliability >> > aspects. >> >> Of course we both agree on the benefits of using what's already available. >> >> > Anyway, I think we are distancing away from the original topic. >> >> Especially since we both can only make rough assumptions about >> requirements and >> operational constraints of the original poster. >> >> Ciao, Michael. >> >> >> -- >> 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 >> > > > >-- >Best regards > >Maciej Drobniuch >Network Security Engineer >Collective-Sense,LLC -- / Alexander Bokovoy From md at collective-sense.com Fri Mar 24 10:27:11 2017 From: md at collective-sense.com (Maciej Drobniuch) Date: Fri, 24 Mar 2017 11:27:11 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <20170324094626.s7rp3uhxvy7y3mcv@redhat.com> References: <20170210140704.GB114812@mother.pipebreaker.pl> <2b972ff1-c8c6-b469-bc23-b213c6f51d68@aixigo.de> <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> <20170211130612.vyytog6wmgz23ufw@redhat.com> <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> <20170211151139.sxoqupkh6i7corpp@redhat.com> <54387995-42a5-56a0-7d17-a4f69c9b06b3@stroeder.com> <20170324094626.s7rp3uhxvy7y3mcv@redhat.com> Message-ID: Hi Alex, Even while using LDAP a browser (jxplorer) I can not login with the following user DN uid=admin,cn=users,cn=accounts,dc=mydomain,dc=com javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials] Only the Directory Manager cn and pwd works. Any ideas what am I doing wrong? Thanks! On Fri, Mar 24, 2017 at 10:46 AM, Alexander Bokovoy wrote: > On pe, 24 maalis 2017, Maciej Drobniuch wrote: > >> Hi All, >> >> I'm trying to integrate Freeipa with jenkins and ldap auth plugin. >> >> The thing with the Freeipa LDAP server is: >> * Only Directory Manager can read userPassword field (not sure yet how to >> create a sysaccount which can read the field. ldifs are welcome ;) >> > This is absolutely not needed. You should configure Jenkins to perform > LDAP bind with user password against IPA LDAP server, that's all. This > is supported by acegi security framework that Jenkins LDAP plugin is > using. For example, > https://github.com/jenkinsci/ldap-plugin/blob/master/src/mai > n/resources/hudson/security/LDAPBindSecurityRealm.groovy > actually uses > org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 which > does support normal LDAP bind. > > I think it is, in fact, a default setup for Jenkins LDAP auth plugin, so > you actually needed to do something to disable this path. > > > * The userPassword field contains the password in salted SHA (SSHA) format. >> From what I've observed the standard LDAP auth functions do not do the >> SSHA >> or any other type of calculations. The password is compared to the plain >> text that's usually(in a typical OpenLDAP server) stored in the >> userPassword field(correct me if I'm wrong) >> * I've managed to integrate CACTI with freeipa by base64 decoding the >> userPassword field then calculating the salted hash and comparing to the >> userPassword field. (php code modification was required). >> * I think the only way is to modify the jenkins LDAP plugin (?). >> >> The problem: >> * I don't want to use sssd PAM because we have OTP enabled and that would >> annoy users(?) additionally it's causing some unidentified build issues >> BTW> Can I disable OTP per server? >> * I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not >> connected to the principal(no control over them yet) >> * I want simple LDAP auth ;-) >> > So use simple LDAP bind. > > > >> Ideas & suggestions are welcome! >> >> M. >> >> On Sat, Feb 11, 2017 at 4:28 PM, Michael Str?der >> wrote: >> >> Alexander Bokovoy wrote: >>> > On la, 11 helmi 2017, Michael Str?der wrote: >>> >> Alexander Bokovoy wrote: >>> >>> On la, 11 helmi 2017, Harald Dunkel wrote: >>> >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: >>> >>>>> On la, 11 helmi 2017, Michael Str?der wrote: >>> >>>>>> >>> >>>>>> (Personally I'd avoid going through PAM.) >>> >>>>> Any specific reason for not using pam_sss? Remember, with SSSD >>> involved >>> >>>>> you get also authentication for trusted users from Active Directory >>> >>>>> realms. You don't get that with generic LDAP way. Also, you'd be >>> more >>> >>>>> efficient in terms of utilising LDAP connections. >>> >>>>> >>> >>>> >>> >>>> I would prefer if the users are not allowed to login into a >>> >>>> shell on the Jenkins server. Surely this restriction can be >>> >>>> implemented with pam as well. >>> >>> >>> >>> Yes, you can use HBAC rules to prevent them from access to the host. >>> >> >>> >> But this introduces a hard dependency on host system administration >>> which I personally >>> >> always try to avoid. >>> >> >>> >> As said: Your mileage may vary. >>> > >>> > So we are talking about FreeIPA and a system enrolled to FreeIPA. This >>> > system is already managed in FreeIPA. >>> >>> Please don't get me wrong. Of course I assume that the original poster >>> wants to integrate >>> Jenkins with FreeIPA and make use of users and their group membership >>> already maintained >>> therein. >>> >>> Let's further assume that the service (here Jenkins) might be operated by >>> another team >>> than the system - not so unusual case at my customers' sites - relying on >>> defining HBAC >>> rules for the system's sssd might not be feasible. >>> >>> > Your mileage may vary, indeed, but I'd rather re-use what is available >>> > to you than implement a parallel infrastructure, including reliability >>> > aspects. >>> >>> Of course we both agree on the benefits of using what's already >>> available. >>> >>> > Anyway, I think we are distancing away from the original topic. >>> >>> Especially since we both can only make rough assumptions about >>> requirements and >>> operational constraints of the original poster. >>> >>> Ciao, Michael. >>> >>> >>> -- >>> 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 >>> >>> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-Sense,LLC >> > > -- > / Alexander Bokovoy > -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Mar 24 10:57:19 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Mar 2017 12:57:19 +0200 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: References: <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> <20170211130612.vyytog6wmgz23ufw@redhat.com> <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> <20170211151139.sxoqupkh6i7corpp@redhat.com> <54387995-42a5-56a0-7d17-a4f69c9b06b3@stroeder.com> <20170324094626.s7rp3uhxvy7y3mcv@redhat.com> Message-ID: <20170324105719.rahus6yvrm7yhhp4@redhat.com> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >Hi Alex, > >Even while using LDAP a browser (jxplorer) I can not login with the >following user DN >uid=admin,cn=users,cn=accounts,dc=mydomain,dc=com > >javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid >Credentials] > >Only the Directory Manager cn and pwd works. >Any ideas what am I doing wrong? LDAP error code 49 means you actually trying to authenticate using LDAP bind but your credentials aren't correct. I don't understand how jxplorer use is relevant to Jenkins plugin setup, though. jxplorer does not use the same Java stack (acegi security) as Jenkins. I cannot test jxplorer on Fedora 25 machine because it fails to launch with Wayland. > >Thanks! > >On Fri, Mar 24, 2017 at 10:46 AM, Alexander Bokovoy >wrote: > >> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >> >>> Hi All, >>> >>> I'm trying to integrate Freeipa with jenkins and ldap auth plugin. >>> >>> The thing with the Freeipa LDAP server is: >>> * Only Directory Manager can read userPassword field (not sure yet how to >>> create a sysaccount which can read the field. ldifs are welcome ;) >>> >> This is absolutely not needed. You should configure Jenkins to perform >> LDAP bind with user password against IPA LDAP server, that's all. This >> is supported by acegi security framework that Jenkins LDAP plugin is >> using. For example, >> https://github.com/jenkinsci/ldap-plugin/blob/master/src/mai >> n/resources/hudson/security/LDAPBindSecurityRealm.groovy >> actually uses >> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 which >> does support normal LDAP bind. >> >> I think it is, in fact, a default setup for Jenkins LDAP auth plugin, so >> you actually needed to do something to disable this path. >> >> >> * The userPassword field contains the password in salted SHA (SSHA) format. >>> From what I've observed the standard LDAP auth functions do not do the >>> SSHA >>> or any other type of calculations. The password is compared to the plain >>> text that's usually(in a typical OpenLDAP server) stored in the >>> userPassword field(correct me if I'm wrong) >>> * I've managed to integrate CACTI with freeipa by base64 decoding the >>> userPassword field then calculating the salted hash and comparing to the >>> userPassword field. (php code modification was required). >>> * I think the only way is to modify the jenkins LDAP plugin (?). >>> >>> The problem: >>> * I don't want to use sssd PAM because we have OTP enabled and that would >>> annoy users(?) additionally it's causing some unidentified build issues >>> BTW> Can I disable OTP per server? >>> * I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not >>> connected to the principal(no control over them yet) >>> * I want simple LDAP auth ;-) >>> >> So use simple LDAP bind. >> >> >> >>> Ideas & suggestions are welcome! >>> >>> M. >>> >>> On Sat, Feb 11, 2017 at 4:28 PM, Michael Str?der >>> wrote: >>> >>> Alexander Bokovoy wrote: >>>> > On la, 11 helmi 2017, Michael Str?der wrote: >>>> >> Alexander Bokovoy wrote: >>>> >>> On la, 11 helmi 2017, Harald Dunkel wrote: >>>> >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: >>>> >>>>> On la, 11 helmi 2017, Michael Str?der wrote: >>>> >>>>>> >>>> >>>>>> (Personally I'd avoid going through PAM.) >>>> >>>>> Any specific reason for not using pam_sss? Remember, with SSSD >>>> involved >>>> >>>>> you get also authentication for trusted users from Active Directory >>>> >>>>> realms. You don't get that with generic LDAP way. Also, you'd be >>>> more >>>> >>>>> efficient in terms of utilising LDAP connections. >>>> >>>>> >>>> >>>> >>>> >>>> I would prefer if the users are not allowed to login into a >>>> >>>> shell on the Jenkins server. Surely this restriction can be >>>> >>>> implemented with pam as well. >>>> >>> >>>> >>> Yes, you can use HBAC rules to prevent them from access to the host. >>>> >> >>>> >> But this introduces a hard dependency on host system administration >>>> which I personally >>>> >> always try to avoid. >>>> >> >>>> >> As said: Your mileage may vary. >>>> > >>>> > So we are talking about FreeIPA and a system enrolled to FreeIPA. This >>>> > system is already managed in FreeIPA. >>>> >>>> Please don't get me wrong. Of course I assume that the original poster >>>> wants to integrate >>>> Jenkins with FreeIPA and make use of users and their group membership >>>> already maintained >>>> therein. >>>> >>>> Let's further assume that the service (here Jenkins) might be operated by >>>> another team >>>> than the system - not so unusual case at my customers' sites - relying on >>>> defining HBAC >>>> rules for the system's sssd might not be feasible. >>>> >>>> > Your mileage may vary, indeed, but I'd rather re-use what is available >>>> > to you than implement a parallel infrastructure, including reliability >>>> > aspects. >>>> >>>> Of course we both agree on the benefits of using what's already >>>> available. >>>> >>>> > Anyway, I think we are distancing away from the original topic. >>>> >>>> Especially since we both can only make rough assumptions about >>>> requirements and >>>> operational constraints of the original poster. >>>> >>>> Ciao, Michael. >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> Collective-Sense,LLC >>> >> >> -- >> / Alexander Bokovoy >> > > > >-- >Best regards > >Maciej Drobniuch >Network Security Engineer >Collective-Sense,LLC -- / Alexander Bokovoy From christophe.trefois at uni.lu Fri Mar 24 10:58:34 2017 From: christophe.trefois at uni.lu (Christophe TREFOIS) Date: Fri, 24 Mar 2017 10:58:34 +0000 Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x In-Reply-To: <1846e5f04c6e755a06b65ec347609097@mail.gmail.com> References: <535BEF94-7EE4-4D90-AB61-C409544E2115@sudo.nz> <1846e5f04c6e755a06b65ec347609097@mail.gmail.com> Message-ID: <9BE76508-A614-461B-A4D3-D8C765FF4721@uni.lu> I?m not expert but I think ipa-replica-prepare is depcrecated in 4.4 as the procedure become more simple. I think setting up a new cluster of CentOS 7.3 machines and setting up replicas against the old cluster is sufficient. What do the experts say? -- Dr Christophe Trefois, Dipl.-Ing. Technical Specialist / Post-Doc UNIVERSIT? DU LUXEMBOURG LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE Campus Belval | House of Biomedicine 6, avenue du Swing L-4367 Belvaux T: +352 46 66 44 6124 F: +352 46 66 44 6949 http://www.uni.lu/lcsb ---- This message is confidential and may contain privileged information. It is intended for the named recipient only. If you receive it in error please notify me and permanently delete the original message and any copies. ---- > On 24 Mar 2017, at 00:54, Zak Peirce wrote: > > I am looking to take this same journey. I found this guide, it seems like > it covers all the bases > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/h > tml/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrade-6-to-7.h > tml > > > -Zak > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dagan > Sent: Thursday, March 23, 2017 3:52 PM > To: freeipa-users at redhat.com > Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x > > Hi, > > I am hoping someone will be able to help answer some questions about > migrations. > > I have been asked to look at upgrading an existing FreeIPA installation on > CentOS 6 (3.0.0) to a new installation on CentOS 7 with a recent stable > release (4.4.0). > > The existing CentOS 6 installation does not manage DNS or have a CA that > is being used (though the may be installed. It's primarily for user > authentication and user group management. > > There are only a small number of users, groups, and hosts to migrate - > less than 100 of each. > But the data is used for LDAP integration in various applications so it > needs to be consistent. > > Would it be recommended to do a straight LDIF type export and import of > the data, and configure the new FreeIPA installation for the new > access/sudo rules? > > Would that risk leaving behind any data I would need to know about? > > We are planning to review the sudo rules, host access lists etc as part of > the migration work. So leaving behind some data may not be a blocker to > upgrade. > > Any suggestions or links welcome. > > Cheers, > Dagan McGregor > > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3509 bytes Desc: not available URL: From slaznick at redhat.com Fri Mar 24 11:39:22 2017 From: slaznick at redhat.com (Standa Laznicka) Date: Fri, 24 Mar 2017 12:39:22 +0100 Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x In-Reply-To: <9BE76508-A614-461B-A4D3-D8C765FF4721@uni.lu> References: <535BEF94-7EE4-4D90-AB61-C409544E2115@sudo.nz> <1846e5f04c6e755a06b65ec347609097@mail.gmail.com> <9BE76508-A614-461B-A4D3-D8C765FF4721@uni.lu> Message-ID: While I don't consider myself an expert, I should note that ipa-replica-prepare has not been deprecated. The proposed solution to follow https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrade-6-to-7.html is indeed the correct one. Not to be confused about ipa-replica-prepare: this command shall not be used on domain level 1 machines since the replication is solved in a smarter and more automatic way. The command would not work on domain level 1 anyway. HTH, Standa On 03/24/2017 11:58 AM, Christophe TREFOIS wrote: > I?m not expert but I think ipa-replica-prepare is depcrecated in 4.4 > as the procedure become more simple. > > I think setting up a new cluster of CentOS 7.3 machines and setting up > replicas against the old cluster is sufficient. > > What do the experts say? > > -- > > Dr Christophe Trefois, Dipl.-Ing. > Technical Specialist / Post-Doc > > UNIVERSIT? DU LUXEMBOURG > > LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE > Campus Belval | House of Biomedicine > 6, avenue du Swing > L-4367 Belvaux > T:+352 46 66 44 6124 > F:+352 46 66 44 6949 > http://www.uni.lu/lcsb > > Facebook Twitter > Google Plus > Linkedin > skype > > > ---- > This message is confidential and may contain privileged information. > It is intended for the named recipient only. > If you receive it in error please notify me and permanently delete the > original message and any copies. > ---- > > >> On 24 Mar 2017, at 00:54, Zak Peirce > > wrote: >> >> I am looking to take this same journey. I found this guide, it seems >> like >> it covers all the bases >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/h >> tml/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrade-6-to-7.h >> tml >> >> >> -Zak >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dagan >> Sent: Thursday, March 23, 2017 3:52 PM >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x >> >> Hi, >> >> I am hoping someone will be able to help answer some questions about >> migrations. >> >> I have been asked to look at upgrading an existing FreeIPA >> installation on >> CentOS 6 (3.0.0) to a new installation on CentOS 7 with a recent stable >> release (4.4.0). >> >> The existing CentOS 6 installation does not manage DNS or have a CA that >> is being used (though the may be installed. It's primarily for user >> authentication and user group management. >> >> There are only a small number of users, groups, and hosts to migrate - >> less than 100 of each. >> But the data is used for LDAP integration in various applications so it >> needs to be consistent. >> >> Would it be recommended to do a straight LDIF type export and import of >> the data, and configure the new FreeIPA installation for the new >> access/sudo rules? >> >> Would that risk leaving behind any data I would need to know about? >> >> We are planning to review the sudo rules, host access lists etc as >> part of >> the migration work. So leaving behind some data may not be a blocker to >> upgrade. >> >> Any suggestions or links welcome. >> >> Cheers, >> Dagan McGregor >> >> >> >> >> -- >> 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Mar 24 12:28:03 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Mar 2017 14:28:03 +0200 Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x In-Reply-To: <9BE76508-A614-461B-A4D3-D8C765FF4721@uni.lu> References: <535BEF94-7EE4-4D90-AB61-C409544E2115@sudo.nz> <1846e5f04c6e755a06b65ec347609097@mail.gmail.com> <9BE76508-A614-461B-A4D3-D8C765FF4721@uni.lu> Message-ID: <20170324122803.6s3xmqf26ct3czr3@redhat.com> On pe, 24 maalis 2017, Christophe TREFOIS wrote: >I?m not expert but I think ipa-replica-prepare is depcrecated in 4.4 as >the procedure become more simple. No, it is not deprecated, that's not true. We have now a concept of 'domain level' which drives certain features. DL 0 uses traditional method to deploy replicas, DL 1 uses a new one. If you are making new replica in DL 0 environment, even with new FreeIPA version, you'd continue using ipa-replica-prepare. For DL 1 environment you would be using new method -- enroll an IPA client and then promote it to be a replica. -- / Alexander Bokovoy From christophe.trefois at uni.lu Fri Mar 24 12:30:44 2017 From: christophe.trefois at uni.lu (Christophe TREFOIS) Date: Fri, 24 Mar 2017 12:30:44 +0000 Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x In-Reply-To: <20170324122803.6s3xmqf26ct3czr3@redhat.com> References: <535BEF94-7EE4-4D90-AB61-C409544E2115@sudo.nz> <1846e5f04c6e755a06b65ec347609097@mail.gmail.com> <9BE76508-A614-461B-A4D3-D8C765FF4721@uni.lu> <20170324122803.6s3xmqf26ct3czr3@redhat.com> Message-ID: Ok, thanks for clearing that up Alex :) -- Dr Christophe Trefois, Dipl.-Ing. Technical Specialist / Post-Doc UNIVERSIT? DU LUXEMBOURG LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE Campus Belval | House of Biomedicine 6, avenue du Swing L-4367 Belvaux T: +352 46 66 44 6124 F: +352 46 66 44 6949 http://www.uni.lu/lcsb ---- This message is confidential and may contain privileged information. It is intended for the named recipient only. If you receive it in error please notify me and permanently delete the original message and any copies. ---- > On 24 Mar 2017, at 13:28, Alexander Bokovoy wrote: > > On pe, 24 maalis 2017, Christophe TREFOIS wrote: >> I?m not expert but I think ipa-replica-prepare is depcrecated in 4.4 as >> the procedure become more simple. > No, it is not deprecated, that's not true. We have now a concept of > 'domain level' which drives certain features. DL 0 uses traditional > method to deploy replicas, DL 1 uses a new one. If you are making new > replica in DL 0 environment, even with new FreeIPA version, you'd > continue using ipa-replica-prepare. For DL 1 environment you would be > using new method -- enroll an IPA client and then promote it to be a > replica. > > -- > / Alexander Bokovoy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3509 bytes Desc: not available URL: From md at collective-sense.com Fri Mar 24 13:00:03 2017 From: md at collective-sense.com (Maciej Drobniuch) Date: Fri, 24 Mar 2017 14:00:03 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <20170324105719.rahus6yvrm7yhhp4@redhat.com> References: <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> <20170211130612.vyytog6wmgz23ufw@redhat.com> <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> <20170211151139.sxoqupkh6i7corpp@redhat.com> <54387995-42a5-56a0-7d17-a4f69c9b06b3@stroeder.com> <20170324094626.s7rp3uhxvy7y3mcv@redhat.com> <20170324105719.rahus6yvrm7yhhp4@redhat.com> Message-ID: I see now what you mean. The SSHA decoding is handled on the client side by using acegi not on the ldap server side... Am I inline with this? I'm logging in with cn=Directory Manager (no issues) but it fails with the user dn(jxplorer) I'll try figure this out with the jenkins mailing list. Thanks Alex. On Fri, Mar 24, 2017 at 11:57 AM, Alexander Bokovoy wrote: > On pe, 24 maalis 2017, Maciej Drobniuch wrote: > >> Hi Alex, >> >> Even while using LDAP a browser (jxplorer) I can not login with the >> following user DN >> uid=admin,cn=users,cn=accounts,dc=mydomain,dc=com >> >> javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid >> Credentials] >> >> Only the Directory Manager cn and pwd works. >> Any ideas what am I doing wrong? >> > LDAP error code 49 means you actually trying to authenticate using LDAP > bind but your credentials aren't correct. > > I don't understand how jxplorer use is relevant to Jenkins plugin setup, > though. jxplorer does not use the same Java stack (acegi security) as > Jenkins. > > I cannot test jxplorer on Fedora 25 machine because it fails to launch > with Wayland. > > > >> Thanks! >> >> On Fri, Mar 24, 2017 at 10:46 AM, Alexander Bokovoy >> wrote: >> >> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >>> >>> Hi All, >>>> >>>> I'm trying to integrate Freeipa with jenkins and ldap auth plugin. >>>> >>>> The thing with the Freeipa LDAP server is: >>>> * Only Directory Manager can read userPassword field (not sure yet how >>>> to >>>> create a sysaccount which can read the field. ldifs are welcome ;) >>>> >>>> This is absolutely not needed. You should configure Jenkins to perform >>> LDAP bind with user password against IPA LDAP server, that's all. This >>> is supported by acegi security framework that Jenkins LDAP plugin is >>> using. For example, >>> https://github.com/jenkinsci/ldap-plugin/blob/master/src/mai >>> n/resources/hudson/security/LDAPBindSecurityRealm.groovy >>> actually uses >>> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 which >>> does support normal LDAP bind. >>> >>> I think it is, in fact, a default setup for Jenkins LDAP auth plugin, so >>> you actually needed to do something to disable this path. >>> >>> >>> * The userPassword field contains the password in salted SHA (SSHA) >>> format. >>> >>>> From what I've observed the standard LDAP auth functions do not do the >>>> SSHA >>>> or any other type of calculations. The password is compared to the plain >>>> text that's usually(in a typical OpenLDAP server) stored in the >>>> userPassword field(correct me if I'm wrong) >>>> * I've managed to integrate CACTI with freeipa by base64 decoding the >>>> userPassword field then calculating the salted hash and comparing to the >>>> userPassword field. (php code modification was required). >>>> * I think the only way is to modify the jenkins LDAP plugin (?). >>>> >>>> The problem: >>>> * I don't want to use sssd PAM because we have OTP enabled and that >>>> would >>>> annoy users(?) additionally it's causing some unidentified build issues >>>> BTW> Can I disable OTP per server? >>>> * I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not >>>> connected to the principal(no control over them yet) >>>> * I want simple LDAP auth ;-) >>>> >>>> So use simple LDAP bind. >>> >>> >>> >>> Ideas & suggestions are welcome! >>>> >>>> M. >>>> >>>> On Sat, Feb 11, 2017 at 4:28 PM, Michael Str?der >>>> wrote: >>>> >>>> Alexander Bokovoy wrote: >>>> >>>>> > On la, 11 helmi 2017, Michael Str?der wrote: >>>>> >> Alexander Bokovoy wrote: >>>>> >>> On la, 11 helmi 2017, Harald Dunkel wrote: >>>>> >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: >>>>> >>>>> On la, 11 helmi 2017, Michael Str?der wrote: >>>>> >>>>>> >>>>> >>>>>> (Personally I'd avoid going through PAM.) >>>>> >>>>> Any specific reason for not using pam_sss? Remember, with SSSD >>>>> involved >>>>> >>>>> you get also authentication for trusted users from Active >>>>> Directory >>>>> >>>>> realms. You don't get that with generic LDAP way. Also, you'd be >>>>> more >>>>> >>>>> efficient in terms of utilising LDAP connections. >>>>> >>>>> >>>>> >>>> >>>>> >>>> I would prefer if the users are not allowed to login into a >>>>> >>>> shell on the Jenkins server. Surely this restriction can be >>>>> >>>> implemented with pam as well. >>>>> >>> >>>>> >>> Yes, you can use HBAC rules to prevent them from access to the >>>>> host. >>>>> >> >>>>> >> But this introduces a hard dependency on host system administration >>>>> which I personally >>>>> >> always try to avoid. >>>>> >> >>>>> >> As said: Your mileage may vary. >>>>> > >>>>> > So we are talking about FreeIPA and a system enrolled to FreeIPA. >>>>> This >>>>> > system is already managed in FreeIPA. >>>>> >>>>> Please don't get me wrong. Of course I assume that the original poster >>>>> wants to integrate >>>>> Jenkins with FreeIPA and make use of users and their group membership >>>>> already maintained >>>>> therein. >>>>> >>>>> Let's further assume that the service (here Jenkins) might be operated >>>>> by >>>>> another team >>>>> than the system - not so unusual case at my customers' sites - relying >>>>> on >>>>> defining HBAC >>>>> rules for the system's sssd might not be feasible. >>>>> >>>>> > Your mileage may vary, indeed, but I'd rather re-use what is >>>>> available >>>>> > to you than implement a parallel infrastructure, including >>>>> reliability >>>>> > aspects. >>>>> >>>>> Of course we both agree on the benefits of using what's already >>>>> available. >>>>> >>>>> > Anyway, I think we are distancing away from the original topic. >>>>> >>>>> Especially since we both can only make rough assumptions about >>>>> requirements and >>>>> operational constraints of the original poster. >>>>> >>>>> Ciao, Michael. >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Best regards >>>> >>>> Maciej Drobniuch >>>> Network Security Engineer >>>> Collective-Sense,LLC >>>> >>>> >>> -- >>> / Alexander Bokovoy >>> >>> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-Sense,LLC >> > > -- > / Alexander Bokovoy > -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Mar 24 13:06:14 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 24 Mar 2017 15:06:14 +0200 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: References: <20170211130612.vyytog6wmgz23ufw@redhat.com> <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> <20170211151139.sxoqupkh6i7corpp@redhat.com> <54387995-42a5-56a0-7d17-a4f69c9b06b3@stroeder.com> <20170324094626.s7rp3uhxvy7y3mcv@redhat.com> <20170324105719.rahus6yvrm7yhhp4@redhat.com> Message-ID: <20170324130614.epezx4istuo22u3v@redhat.com> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >I see now what you mean. > >The SSHA decoding is handled on the client side by using acegi not on the >ldap server side... > >Am I inline with this? No, you are not. There are multiple LDAP authentication providers (authenticators) in Acegi Security framework. When using org.acegisecurity.providers.ldap.authenticator.BindAuthenticator, it does actual LDAP bind against LDAP server and never checks the password by itself. Successful LDAP bind is considered a successful password check. Jenkins extends BindAuthenticator code with a very small wrapper to allow better error messaging. It is called BindAuthenticator2. But it doesn't change the fact that it uses LDAP bind. I believe it is actually a default configuration in Jenkins ldap auth plugin. However, LDAP servers may require that LDAP bind is executed over a secure channel because your password is passed to LDAP server in clear text form. Such secure channel has to be established either with LDAP StartTLS (preferred) or by using LDAPS protocol. I guess what you have is a situation where both LDAP StartTLS and LDAPS aren't in use. > >I'm logging in with cn=Directory Manager (no issues) but it fails with the >user dn(jxplorer) > >I'll try figure this out with the jenkins mailing list. > >Thanks Alex. > > >On Fri, Mar 24, 2017 at 11:57 AM, Alexander Bokovoy >wrote: > >> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >> >>> Hi Alex, >>> >>> Even while using LDAP a browser (jxplorer) I can not login with the >>> following user DN >>> uid=admin,cn=users,cn=accounts,dc=mydomain,dc=com >>> >>> javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid >>> Credentials] >>> >>> Only the Directory Manager cn and pwd works. >>> Any ideas what am I doing wrong? >>> >> LDAP error code 49 means you actually trying to authenticate using LDAP >> bind but your credentials aren't correct. >> >> I don't understand how jxplorer use is relevant to Jenkins plugin setup, >> though. jxplorer does not use the same Java stack (acegi security) as >> Jenkins. >> >> I cannot test jxplorer on Fedora 25 machine because it fails to launch >> with Wayland. >> >> >> >>> Thanks! >>> >>> On Fri, Mar 24, 2017 at 10:46 AM, Alexander Bokovoy >>> wrote: >>> >>> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >>>> >>>> Hi All, >>>>> >>>>> I'm trying to integrate Freeipa with jenkins and ldap auth plugin. >>>>> >>>>> The thing with the Freeipa LDAP server is: >>>>> * Only Directory Manager can read userPassword field (not sure yet how >>>>> to >>>>> create a sysaccount which can read the field. ldifs are welcome ;) >>>>> >>>>> This is absolutely not needed. You should configure Jenkins to perform >>>> LDAP bind with user password against IPA LDAP server, that's all. This >>>> is supported by acegi security framework that Jenkins LDAP plugin is >>>> using. For example, >>>> https://github.com/jenkinsci/ldap-plugin/blob/master/src/mai >>>> n/resources/hudson/security/LDAPBindSecurityRealm.groovy >>>> actually uses >>>> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 which >>>> does support normal LDAP bind. >>>> >>>> I think it is, in fact, a default setup for Jenkins LDAP auth plugin, so >>>> you actually needed to do something to disable this path. >>>> >>>> >>>> * The userPassword field contains the password in salted SHA (SSHA) >>>> format. >>>> >>>>> From what I've observed the standard LDAP auth functions do not do the >>>>> SSHA >>>>> or any other type of calculations. The password is compared to the plain >>>>> text that's usually(in a typical OpenLDAP server) stored in the >>>>> userPassword field(correct me if I'm wrong) >>>>> * I've managed to integrate CACTI with freeipa by base64 decoding the >>>>> userPassword field then calculating the salted hash and comparing to the >>>>> userPassword field. (php code modification was required). >>>>> * I think the only way is to modify the jenkins LDAP plugin (?). >>>>> >>>>> The problem: >>>>> * I don't want to use sssd PAM because we have OTP enabled and that >>>>> would >>>>> annoy users(?) additionally it's causing some unidentified build issues >>>>> BTW> Can I disable OTP per server? >>>>> * I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not >>>>> connected to the principal(no control over them yet) >>>>> * I want simple LDAP auth ;-) >>>>> >>>>> So use simple LDAP bind. >>>> >>>> >>>> >>>> Ideas & suggestions are welcome! >>>>> >>>>> M. >>>>> >>>>> On Sat, Feb 11, 2017 at 4:28 PM, Michael Str?der >>>>> wrote: >>>>> >>>>> Alexander Bokovoy wrote: >>>>> >>>>>> > On la, 11 helmi 2017, Michael Str?der wrote: >>>>>> >> Alexander Bokovoy wrote: >>>>>> >>> On la, 11 helmi 2017, Harald Dunkel wrote: >>>>>> >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: >>>>>> >>>>> On la, 11 helmi 2017, Michael Str?der wrote: >>>>>> >>>>>> >>>>>> >>>>>> (Personally I'd avoid going through PAM.) >>>>>> >>>>> Any specific reason for not using pam_sss? Remember, with SSSD >>>>>> involved >>>>>> >>>>> you get also authentication for trusted users from Active >>>>>> Directory >>>>>> >>>>> realms. You don't get that with generic LDAP way. Also, you'd be >>>>>> more >>>>>> >>>>> efficient in terms of utilising LDAP connections. >>>>>> >>>>> >>>>>> >>>> >>>>>> >>>> I would prefer if the users are not allowed to login into a >>>>>> >>>> shell on the Jenkins server. Surely this restriction can be >>>>>> >>>> implemented with pam as well. >>>>>> >>> >>>>>> >>> Yes, you can use HBAC rules to prevent them from access to the >>>>>> host. >>>>>> >> >>>>>> >> But this introduces a hard dependency on host system administration >>>>>> which I personally >>>>>> >> always try to avoid. >>>>>> >> >>>>>> >> As said: Your mileage may vary. >>>>>> > >>>>>> > So we are talking about FreeIPA and a system enrolled to FreeIPA. >>>>>> This >>>>>> > system is already managed in FreeIPA. >>>>>> >>>>>> Please don't get me wrong. Of course I assume that the original poster >>>>>> wants to integrate >>>>>> Jenkins with FreeIPA and make use of users and their group membership >>>>>> already maintained >>>>>> therein. >>>>>> >>>>>> Let's further assume that the service (here Jenkins) might be operated >>>>>> by >>>>>> another team >>>>>> than the system - not so unusual case at my customers' sites - relying >>>>>> on >>>>>> defining HBAC >>>>>> rules for the system's sssd might not be feasible. >>>>>> >>>>>> > Your mileage may vary, indeed, but I'd rather re-use what is >>>>>> available >>>>>> > to you than implement a parallel infrastructure, including >>>>>> reliability >>>>>> > aspects. >>>>>> >>>>>> Of course we both agree on the benefits of using what's already >>>>>> available. >>>>>> >>>>>> > Anyway, I think we are distancing away from the original topic. >>>>>> >>>>>> Especially since we both can only make rough assumptions about >>>>>> requirements and >>>>>> operational constraints of the original poster. >>>>>> >>>>>> Ciao, Michael. >>>>>> >>>>>> >>>>>> -- >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Best regards >>>>> >>>>> Maciej Drobniuch >>>>> Network Security Engineer >>>>> Collective-Sense,LLC >>>>> >>>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >>> >>> >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> Collective-Sense,LLC >>> >> >> -- >> / Alexander Bokovoy >> > > > >-- >Best regards > >Maciej Drobniuch >Network Security Engineer >Collective-Sense,LLC -- / Alexander Bokovoy From michael at stroeder.com Fri Mar 24 14:48:57 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Fri, 24 Mar 2017 15:48:57 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: References: <688efd50-6b2a-2ba8-2993-c30b2b18a1c8@stroeder.com> <20170211105740.hhw34i4blkhtvzyv@redhat.com> <20170211130612.vyytog6wmgz23ufw@redhat.com> <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> <20170211151139.sxoqupkh6i7corpp@redhat.com> <54387995-42a5-56a0-7d17-a4f69c9b06b3@stroeder.com> <20170324094626.s7rp3uhxvy7y3mcv@redhat.com> <20170324105719.rahus6yvrm7yhhp4@redhat.com> Message-ID: <49f6dd33-ffc9-baae-8020-a50dcf74c557@stroeder.com> Maciej Drobniuch wrote: > I see now what you mean. > > The SSHA decoding is handled on the client side by using acegi not on the ldap server > side... No, Jenkins sends a bind request with the user's bind-DN and clear-text password. Password check is done server-side. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From md at collective-sense.com Fri Mar 24 15:14:18 2017 From: md at collective-sense.com (Maciej Drobniuch) Date: Fri, 24 Mar 2017 16:14:18 +0100 Subject: [Freeipa-users] Jenkins integration? In-Reply-To: <20170324130614.epezx4istuo22u3v@redhat.com> References: <20170211130612.vyytog6wmgz23ufw@redhat.com> <54638d97-497e-928f-1ba6-ec589c340b91@stroeder.com> <20170211151139.sxoqupkh6i7corpp@redhat.com> <54387995-42a5-56a0-7d17-a4f69c9b06b3@stroeder.com> <20170324094626.s7rp3uhxvy7y3mcv@redhat.com> <20170324105719.rahus6yvrm7yhhp4@redhat.com> <20170324130614.epezx4istuo22u3v@redhat.com> Message-ID: Just tried with LDAPs over jxplorer and jenkins. Unfortunately it's not working. The master jenkins release supports ipa auto detection. https://gerrit-review.googlesource.com/#/c/94925/ I will give it a try. On Fri, Mar 24, 2017 at 2:06 PM, Alexander Bokovoy wrote: > On pe, 24 maalis 2017, Maciej Drobniuch wrote: > >> I see now what you mean. >> >> The SSHA decoding is handled on the client side by using acegi not on the >> ldap server side... >> >> Am I inline with this? >> > No, you are not. There are multiple LDAP authentication providers > (authenticators) in Acegi Security framework. When using > org.acegisecurity.providers.ldap.authenticator.BindAuthenticator, it > does actual LDAP bind against LDAP server and never checks the password > by itself. Successful LDAP bind is considered a successful password > check. Jenkins extends BindAuthenticator code with a very small wrapper > to allow better error messaging. It is called BindAuthenticator2. But it > doesn't change the fact that it uses LDAP bind. > > I believe it is actually a default configuration in Jenkins ldap auth > plugin. However, LDAP servers may require that LDAP bind is executed > over a secure channel because your password is passed to LDAP server in > clear text form. Such secure channel has to be established either with > LDAP StartTLS (preferred) or by using LDAPS protocol. > > I guess what you have is a situation where both LDAP StartTLS and LDAPS > aren't in use. > > > >> I'm logging in with cn=Directory Manager (no issues) but it fails with the >> user dn(jxplorer) >> >> I'll try figure this out with the jenkins mailing list. >> >> Thanks Alex. >> >> >> On Fri, Mar 24, 2017 at 11:57 AM, Alexander Bokovoy >> wrote: >> >> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >>> >>> Hi Alex, >>>> >>>> Even while using LDAP a browser (jxplorer) I can not login with the >>>> following user DN >>>> uid=admin,cn=users,cn=accounts,dc=mydomain,dc=com >>>> >>>> javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid >>>> Credentials] >>>> >>>> Only the Directory Manager cn and pwd works. >>>> Any ideas what am I doing wrong? >>>> >>>> LDAP error code 49 means you actually trying to authenticate using LDAP >>> bind but your credentials aren't correct. >>> >>> I don't understand how jxplorer use is relevant to Jenkins plugin setup, >>> though. jxplorer does not use the same Java stack (acegi security) as >>> Jenkins. >>> >>> I cannot test jxplorer on Fedora 25 machine because it fails to launch >>> with Wayland. >>> >>> >>> >>> Thanks! >>>> >>>> On Fri, Mar 24, 2017 at 10:46 AM, Alexander Bokovoy < >>>> abokovoy at redhat.com> >>>> wrote: >>>> >>>> On pe, 24 maalis 2017, Maciej Drobniuch wrote: >>>> >>>>> >>>>> Hi All, >>>>> >>>>>> >>>>>> I'm trying to integrate Freeipa with jenkins and ldap auth plugin. >>>>>> >>>>>> The thing with the Freeipa LDAP server is: >>>>>> * Only Directory Manager can read userPassword field (not sure yet how >>>>>> to >>>>>> create a sysaccount which can read the field. ldifs are welcome ;) >>>>>> >>>>>> This is absolutely not needed. You should configure Jenkins to perform >>>>>> >>>>> LDAP bind with user password against IPA LDAP server, that's all. This >>>>> is supported by acegi security framework that Jenkins LDAP plugin is >>>>> using. For example, >>>>> https://github.com/jenkinsci/ldap-plugin/blob/master/src/mai >>>>> n/resources/hudson/security/LDAPBindSecurityRealm.groovy >>>>> actually uses >>>>> org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 >>>>> which >>>>> does support normal LDAP bind. >>>>> >>>>> I think it is, in fact, a default setup for Jenkins LDAP auth plugin, >>>>> so >>>>> you actually needed to do something to disable this path. >>>>> >>>>> >>>>> * The userPassword field contains the password in salted SHA (SSHA) >>>>> format. >>>>> >>>>> From what I've observed the standard LDAP auth functions do not do the >>>>>> SSHA >>>>>> or any other type of calculations. The password is compared to the >>>>>> plain >>>>>> text that's usually(in a typical OpenLDAP server) stored in the >>>>>> userPassword field(correct me if I'm wrong) >>>>>> * I've managed to integrate CACTI with freeipa by base64 decoding the >>>>>> userPassword field then calculating the salted hash and comparing to >>>>>> the >>>>>> userPassword field. (php code modification was required). >>>>>> * I think the only way is to modify the jenkins LDAP plugin (?). >>>>>> >>>>>> The problem: >>>>>> * I don't want to use sssd PAM because we have OTP enabled and that >>>>>> would >>>>>> annoy users(?) additionally it's causing some unidentified build >>>>>> issues >>>>>> BTW> Can I disable OTP per server? >>>>>> * I can not integrate Kerberos/GSSAPI/SPNEGO because the PCs are not >>>>>> connected to the principal(no control over them yet) >>>>>> * I want simple LDAP auth ;-) >>>>>> >>>>>> So use simple LDAP bind. >>>>>> >>>>> >>>>> >>>>> >>>>> Ideas & suggestions are welcome! >>>>> >>>>>> >>>>>> M. >>>>>> >>>>>> On Sat, Feb 11, 2017 at 4:28 PM, Michael Str?der < >>>>>> michael at stroeder.com> >>>>>> wrote: >>>>>> >>>>>> Alexander Bokovoy wrote: >>>>>> >>>>>> > On la, 11 helmi 2017, Michael Str?der wrote: >>>>>>> >> Alexander Bokovoy wrote: >>>>>>> >>> On la, 11 helmi 2017, Harald Dunkel wrote: >>>>>>> >>>> On 02/11/17 11:57, Alexander Bokovoy wrote: >>>>>>> >>>>> On la, 11 helmi 2017, Michael Str?der wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> (Personally I'd avoid going through PAM.) >>>>>>> >>>>> Any specific reason for not using pam_sss? Remember, with SSSD >>>>>>> involved >>>>>>> >>>>> you get also authentication for trusted users from Active >>>>>>> Directory >>>>>>> >>>>> realms. You don't get that with generic LDAP way. Also, you'd >>>>>>> be >>>>>>> more >>>>>>> >>>>> efficient in terms of utilising LDAP connections. >>>>>>> >>>>> >>>>>>> >>>> >>>>>>> >>>> I would prefer if the users are not allowed to login into a >>>>>>> >>>> shell on the Jenkins server. Surely this restriction can be >>>>>>> >>>> implemented with pam as well. >>>>>>> >>> >>>>>>> >>> Yes, you can use HBAC rules to prevent them from access to the >>>>>>> host. >>>>>>> >> >>>>>>> >> But this introduces a hard dependency on host system >>>>>>> administration >>>>>>> which I personally >>>>>>> >> always try to avoid. >>>>>>> >> >>>>>>> >> As said: Your mileage may vary. >>>>>>> > >>>>>>> > So we are talking about FreeIPA and a system enrolled to FreeIPA. >>>>>>> This >>>>>>> > system is already managed in FreeIPA. >>>>>>> >>>>>>> Please don't get me wrong. Of course I assume that the original >>>>>>> poster >>>>>>> wants to integrate >>>>>>> Jenkins with FreeIPA and make use of users and their group membership >>>>>>> already maintained >>>>>>> therein. >>>>>>> >>>>>>> Let's further assume that the service (here Jenkins) might be >>>>>>> operated >>>>>>> by >>>>>>> another team >>>>>>> than the system - not so unusual case at my customers' sites - >>>>>>> relying >>>>>>> on >>>>>>> defining HBAC >>>>>>> rules for the system's sssd might not be feasible. >>>>>>> >>>>>>> > Your mileage may vary, indeed, but I'd rather re-use what is >>>>>>> available >>>>>>> > to you than implement a parallel infrastructure, including >>>>>>> reliability >>>>>>> > aspects. >>>>>>> >>>>>>> Of course we both agree on the benefits of using what's already >>>>>>> available. >>>>>>> >>>>>>> > Anyway, I think we are distancing away from the original topic. >>>>>>> >>>>>>> Especially since we both can only make rough assumptions about >>>>>>> requirements and >>>>>>> operational constraints of the original poster. >>>>>>> >>>>>>> Ciao, Michael. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Best regards >>>>>> >>>>>> Maciej Drobniuch >>>>>> Network Security Engineer >>>>>> Collective-Sense,LLC >>>>>> >>>>>> >>>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Best regards >>>> >>>> Maciej Drobniuch >>>> Network Security Engineer >>>> Collective-Sense,LLC >>>> >>>> >>> -- >>> / Alexander Bokovoy >>> >>> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-Sense,LLC >> > > -- > / Alexander Bokovoy > -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From graziee at gmail.com Fri Mar 24 15:58:06 2017 From: graziee at gmail.com (grace rante thompson) Date: Fri, 24 Mar 2017 08:58:06 -0700 Subject: [Freeipa-users] Authenticating windows users In-Reply-To: <2024599693.3536.1490295165870.JavaMail.zimbra@tresgeek.net> References: <594422541.3454.1490294776166.JavaMail.zimbra@tresgeek.net> <2024599693.3536.1490295165870.JavaMail.zimbra@tresgeek.net> Message-ID: sorry, I guess I should have been more clear that we needed more than just Kerberos. Somebody suggested pGina so I'll give it a shot. thanks On Thu, Mar 23, 2017 at 11:52 AM, Jason B. Nance wrote: > Thanks Jason, but those documents need AD as the primary authenticator. > This is not the case for us. > > I think you need to read them a bit closer. Very first line of first link > says: > > "This article describes direct integration between FreeIPA and Windows > machine, i.e. without involving Active Directory server." > > > > On Thu, Mar 23, 2017 at 11:46 AM, Jason B. Nance > wrote: > >> We are primarily linux/osx shop and we currently have FreeIPA/IDM (ver >> 4.2) as our master. I will need to add a handful of windows machines and >> been trying to figure out how to authenticate our windows users with >> FreeIPA/IDM. Is this even possible? I know Global Catalogs may not happen >> anytime soon (sad face). I'm open to -all- ideas, even if it is a paid >> solution (not sure if centrify and the likes can sync up to FreeIPA/IDM). >> >> I would start here: >> >> https://www.freeipa.org/page/Windows_authentication_against_FreeIPA >> >> https://www.freeipa.org/page/Implementing_FreeIPA_in_a_ >> mixed_Environment_(Windows/Linux)_-_Step_by_step >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at tresgeek.net Fri Mar 24 16:10:15 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Fri, 24 Mar 2017 11:10:15 -0500 (CDT) Subject: [Freeipa-users] Authenticating windows users In-Reply-To: References: <594422541.3454.1490294776166.JavaMail.zimbra@tresgeek.net> <2024599693.3536.1490295165870.JavaMail.zimbra@tresgeek.net> Message-ID: <1721673430.1925.1490371815246.JavaMail.zimbra@tresgeek.net> That, too, is in the first document I linked, plus it also lists the option of standing up a Samba 4 to emulate an AD domain that trusts FreeIPA. From: "grace rante thompson" To: "Jason Nance" Cc: freeipa-users at redhat.com Sent: Friday, March 24, 2017 10:58:06 AM Subject: Re: [Freeipa-users] Authenticating windows users sorry, I guess I should have been more clear that we needed more than just Kerberos. Somebody suggested pGina so I'll give it a shot. thanks On Thu, Mar 23, 2017 at 11:52 AM, Jason B. Nance < [ mailto:jason at tresgeek.net | jason at tresgeek.net ] > wrote: BQ_BEGIN Thanks Jason, but those documents need AD as the primary authenticator. This is not the case for us. I think you need to read them a bit closer. Very first line of first link says: "This article describes direct integration between FreeIPA and Windows machine, i.e. without involving Active Directory server." BQ_BEGIN On Thu, Mar 23, 2017 at 11:46 AM, Jason B. Nance < [ mailto:jason at tresgeek.net | jason at tresgeek.net ] > wrote: BQ_BEGIN BQ_BEGIN We are primarily linux/osx shop and we currently have FreeIPA/IDM (ver 4.2) as our master. I will need to add a handful of windows machines and been trying to figure out how to authenticate our windows users with FreeIPA/IDM. Is this even possible? I know Global Catalogs may not happen anytime soon (sad face). I'm open to -all- ideas, even if it is a paid solution (not sure if centrify and the likes can sync up to FreeIPA/IDM). BQ_END I would start here: [ https://www.freeipa.org/page/Windows_authentication_against_FreeIPA | https://www.freeipa.org/page/Windows_authentication_against_FreeIPA ] [ https://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step | https://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step ] BQ_END BQ_END BQ_END -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen at winteltosh.de Fri Mar 24 17:27:14 2017 From: jochen at winteltosh.de (Jochen Demmer) Date: Fri, 24 Mar 2017 18:27:14 +0100 Subject: [Freeipa-users] FreeNAS Corral integration Message-ID: <3f3b0fe3-a79f-722a-870a-2d82d4783149@winteltosh.de> Hi, FreeNAS Corral is out and it supports FreeIPA. Isn't that great? Has someone tried it? My first attempt brought the users visible but I wasn't able to give a user admin Status for Corral. I wonder if and how I can set privileges for a user if he may login via SSH/WebGUI. Regarding the user's home Corral set it as <>@<>. I worked this around by symlinking to the actual home which just is <>. Sad thing is e.g. that I give the users a specific shell in FreeIPA. Some shells aren't supported though in Corral, for instance zsh. This leads to not being able to login via ssh. Are there any best practices or workarounds? Thanks for your time in advance. Jochen Demmer From zarko at etcfstab.com Fri Mar 24 21:23:59 2017 From: zarko at etcfstab.com (Z D) Date: Fri, 24 Mar 2017 21:23:59 +0000 Subject: [Freeipa-users] Automount location design Message-ID: Hi there, We've been looking to add indirect maps for users home directories, and did the next. 1. There is the automount location (named "global") with one map "auto_home", it has keys (they are username) and mount info is :/path 2. The idea is that this is "global location" 3. Another location (named "userdirs") has auto.master map with key = "/home" and mount info is like "ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com" 4. It was added with command: ipa automountkey-add userdirs auto.master --key=/home --info=ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com 5. All work as expected, the issue is that below command shows error. ipa automountlocation-tofiles userdirs ipa: ERROR: ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com: automount map not found Is there any concern with such design? Thanks Zarko -------------- next part -------------- An HTML attachment was scrubbed... URL: From shiela at securitycompass.com Fri Mar 24 21:31:11 2017 From: shiela at securitycompass.com (Shiela Spaleta) Date: Fri, 24 Mar 2017 17:31:11 -0400 Subject: [Freeipa-users] Directory Manager password is correct but IPA-replica-prepare command fails with Invalid Credentials Message-ID: I can successfully bind as the Directory Manager, but when I use the same password to create a replica prep file I get an "Invalid Credentials" error. How is this possible? I'm running FreeIPA v3.0 on Centos 6 and created replica's successfully in the past. I tested the Directory Manager password by using it change the admin user's password: ldappasswd -D 'cn=directory manager' -W -S uid=admin,cn=users,cn=accounts ,dc=domain,dc=com and that was successful (tested by getting a ticket as admin user with new pwd). But when I try to create a replica file: # ipa-replica-prepare ipa2.shiela.com Preparing replica for ipa2.shiela.com from ipa1.shiela.com preparation of replica failed: Insufficient access: Invalid credentials Insufficient access: Invalid credentials File "/usr/sbin/ipa-replica-prepare", line 529, in main() File "/usr/sbin/ipa-replica-prepare", line 391, in main update_pki_admin_password(dirman_password) File "/usr/sbin/ipa-replica-prepare", line 247, in update_pki_admin_password bind_pw=dirman_password File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in connect conn = self.create_connection(*args, **kw) File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line 846, in create_connection self.handle_errors(e) File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line 712, in handle_errors raise errors.ACIError(info="%s %s" % (info, desc)) If anyone can shed light on this I would be grateful. I've checked /var/log/dirsrv/PKI-IPA but it has not been any more helpful. Shiela -------------- next part -------------- An HTML attachment was scrubbed... URL: From zarko at etcfstab.com Fri Mar 24 21:32:43 2017 From: zarko at etcfstab.com (Z D) Date: Fri, 24 Mar 2017 21:32:43 +0000 Subject: [Freeipa-users] Automount location design In-Reply-To: References: Message-ID: OS is EL7.3 and ipa-serveris 4.4.0 ________________________________ From: Z D Sent: Friday, March 24, 2017 2:23:59 PM To: freeipa-users at redhat.com Subject: Automount location design Hi there, We've been looking to add indirect maps for users home directories, and did the next. 1. There is the automount location (named "global") with one map "auto_home", it has keys (they are username) and mount info is :/path 2. The idea is that this is "global location" 3. Another location (named "userdirs") has auto.master map with key = "/home" and mount info is like "ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com" 4. It was added with command: ipa automountkey-add userdirs auto.master --key=/home --info=ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com 5. All work as expected, the issue is that below command shows error. ipa automountlocation-tofiles userdirs ipa: ERROR: ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com: automount map not found Is there any concern with such design? Thanks Zarko -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Mar 24 22:21:47 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 24 Mar 2017 18:21:47 -0400 Subject: [Freeipa-users] Directory Manager password is correct but IPA-replica-prepare command fails with Invalid Credentials In-Reply-To: References: Message-ID: Shiela Spaleta wrote: > I can successfully bind as the Directory Manager, but when I use the > same password to create a replica prep file I get an "Invalid > Credentials" error. How is this possible? > > I'm running FreeIPA v3.0 on Centos 6 and created replica's successfully > in the past. > > I tested the Directory Manager password by using it change the admin > user's password: > > ldappasswd -D 'cn=directory manager' -W -S > uid=admin,cn=users,cn=accounts,dc=domain,dc=com > > and that was successful (tested by getting a ticket as admin user with > new pwd). > > But when I try to create a replica file: > > # ipa-replica-prepare ipa2.shiela.com > > > Preparing replica for ipa2.shiela.com > from ipa1.shiela.com > preparation of replica failed: Insufficient access: Invalid credentials > Insufficient access: Invalid credentials > File "/usr/sbin/ipa-replica-prepare", line 529, in > main() > > File "/usr/sbin/ipa-replica-prepare", line 391, in main > update_pki_admin_password(dirman_password) > > File "/usr/sbin/ipa-replica-prepare", line 247, in > update_pki_admin_password > bind_pw=dirman_password > > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in > connect > conn = self.create_connection(*args, **kw) > > File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", > line 846, in create_connection > self.handle_errors(e) > > File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", > line 712, in handle_errors > raise errors.ACIError(info="%s %s" % (info, desc)) > > If anyone can shed light on this I would be grateful. I've checked > /var/log/dirsrv/PKI-IPA but it has not been any more helpful. > admin != Directory Manager. Try running kdestroy, then ipa-replica-prepare. You'll be prompted for the DM password, that should work. rob From rcritten at redhat.com Fri Mar 24 22:32:01 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 24 Mar 2017 18:32:01 -0400 Subject: [Freeipa-users] Automount location design In-Reply-To: References: Message-ID: <6b9f8186-3d43-0a0b-4d69-2d3d81e23bd7@redhat.com> Z D wrote: > Hi there, > > We've been looking to add indirect maps for users home directories, and > did the next. > > 1. There is the automount location (named "global") with one map > "auto_home", it has keys (they are username) and mount info is > :/path > > 2. The idea is that this is "global location" > > 3. Another location (named "userdirs") has auto.master map with key = > "/home" and mount info is like > "ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com" > > 4. It was added with command: > > ipa automountkey-add userdirs auto.master --key=/home > --info=ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com > > 5. All work as expected, the issue is that below command shows error. > > ipa automountlocation-tofiles userdirs > ipa: ERROR: > ldap:automountmapname=auto_home,cn=global,cn=automount,dc=comp,dc=com: > automount map not found > > Is there any concern with such design? Arguably it's a deficiency in automountlocation-tofiles. I was having a hard time wrapping my head around things when I wrote the automount support oh-so-long-ago so I hacked that command up to try to see what was being created in a file-like setting. It is, to say the least, very simplistic code. It doesn't parse the automountinformation attribute, it assumes it is pointing to a key entry. It doesn't understand the ldap: prefix. I don't believe this prefix is required but it looks like you're trying to share the same map between two locations which we never intended. rob So if this From tkent at xetus.com Fri Mar 24 23:55:38 2017 From: tkent at xetus.com (Terence Kent) Date: Fri, 24 Mar 2017 16:55:38 -0700 Subject: [Freeipa-users] First-class support for the docker image Message-ID: <4389a74e-eac2-abed-e531-b07f0680cb3a@gmail.com> Hello, We've been using the FreeIPA docker image for a few years now with great success. I really can't overstate how much we get by using a container deployment for FreeIPA. We can now easily test anything from version upgrades to orchestration code against either test data and our production data set. That, and we get all the typical docker goodness (we can easily move the container between hosts, change the underlying OS independently, etc, etc). That said, lots of the work in the freeipa docker image's gitrepo are things that seem like they belong in the freeipa main codebase. We've had to trace through the freeipa-container source from time to time to diagnose issues and we see situations where the docker build file actually modifies python code using text replaces. This seems both easily breakable and like a lot more work than just modifying the source file to optionally support whatever a containerized environment needs. Is there a reason to keep container support out of the main freeipa project? Best, Terence From shiela at securitycompass.com Sat Mar 25 22:45:05 2017 From: shiela at securitycompass.com (Shiela Spaleta) Date: Sat, 25 Mar 2017 18:45:05 -0400 Subject: [Freeipa-users] Directory Manager password is correct but IPA-replica-prepare command fails with Invalid Credentials In-Reply-To: References: Message-ID: Thanks for your quick reply. What I mean is I am supplying the DM password when prompted following ipa-replica-prepare. I only mentioned the admin user password change to prove that the DM password I have is correct/valid. Otherwise I could not have run this command (and other ldapsearch commands) successfully -> ldappasswd -D 'cn=directory manager' -W -S uid=admin,cn=users,cn=accounts,dc=example,dc=com. I just wanted to show that I've tested the DM password by binding with it (ldapsearch or ldappasswd), and it works, but using it with ipa-replica-prepare fails. Sorry, I should have picked better examples to explain my problem more clearly. Sincerely, *Shiela Spaleta* *Senior System Administrator* *Security Compass* *p: *+1 (888) 777-2211 x171 *m:* +1 (647) 539-6366 On Fri, Mar 24, 2017 at 6:21 PM, Rob Crittenden wrote: > Shiela Spaleta wrote: > > I can successfully bind as the Directory Manager, but when I use the > > same password to create a replica prep file I get an "Invalid > > Credentials" error. How is this possible? > > > > I'm running FreeIPA v3.0 on Centos 6 and created replica's successfully > > in the past. > > > > I tested the Directory Manager password by using it change the admin > > user's password: > > > > ldappasswd -D 'cn=directory manager' -W -S > > uid=admin,cn=users,cn=accounts,dc=domain,dc=com > > > > and that was successful (tested by getting a ticket as admin user with > > new pwd). > > > > But when I try to create a replica file: > > > > # ipa-replica-prepare ipa2.shiela.com > > > > > > Preparing replica for ipa2.shiela.com > > from ipa1.shiela.com > > preparation of replica failed: Insufficient access: Invalid credentials > > Insufficient access: Invalid credentials > > File "/usr/sbin/ipa-replica-prepare", line 529, in > > main() > > > > File "/usr/sbin/ipa-replica-prepare", line 391, in main > > update_pki_admin_password(dirman_password) > > > > File "/usr/sbin/ipa-replica-prepare", line 247, in > > update_pki_admin_password > > bind_pw=dirman_password > > > > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in > > connect > > conn = self.create_connection(*args, **kw) > > > > File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", > > line 846, in create_connection > > self.handle_errors(e) > > > > File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", > > line 712, in handle_errors > > raise errors.ACIError(info="%s %s" % (info, desc)) > > > > If anyone can shed light on this I would be grateful. I've checked > > /var/log/dirsrv/PKI-IPA but it has not been any more helpful. > > > > admin != Directory Manager. > > Try running kdestroy, then ipa-replica-prepare. You'll be prompted for > the DM password, that should work. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at sudo.nz Sun Mar 26 22:28:17 2017 From: list at sudo.nz (Dagan) Date: Sun, 26 Mar 2017 22:28:17 +0000 Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x In-Reply-To: <9BE76508-A614-461B-A4D3-D8C765FF4721@uni.lu> References: <535BEF94-7EE4-4D90-AB61-C409544E2115@sudo.nz> <1846e5f04c6e755a06b65ec347609097@mail.gmail.com> <9BE76508-A614-461B-A4D3-D8C765FF4721@uni.lu> Message-ID: <329CDBE5-F295-46CA-8E27-8F8E4094B47F@sudo.nz> Hi, Do you mean by installing FreeIPA using freeipa-replica-install and manually adding using CLI to add replica agreements with the old cluster? Or relying on newer replica management? What command options would be needed for the installation in that scenario? I can see in Google results for improvement in the replica management, but not much on which commands to run to make it work in my case. Cheers, Dagan McGregor On 24 March 2017 11:58:34 PM NZDT, Christophe TREFOIS wrote: >I?m not expert but I think ipa-replica-prepare is depcrecated in 4.4 as >the procedure become more simple. > >I think setting up a new cluster of CentOS 7.3 machines and setting up >replicas against the old cluster is sufficient. > >What do the experts say? >-- > >Dr Christophe Trefois, Dipl.-Ing. >Technical Specialist / Post-Doc > >UNIVERSIT? DU LUXEMBOURG > >LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE >Campus Belval | House of Biomedicine >6, avenue du Swing >L-4367 Belvaux >T: +352 46 66 44 6124 >F: +352 46 66 44 6949 >http://www.uni.lu/lcsb > > > > >---- >This message is confidential and may contain privileged information. >It is intended for the named recipient only. >If you receive it in error please notify me and permanently delete the >original message and any copies. >---- > > > >> On 24 Mar 2017, at 00:54, Zak Peirce wrote: >> >> I am looking to take this same journey. I found this guide, it seems >like >> it covers all the bases >> >> >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/h >> >tml/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrade-6-to-7.h >> tml >> >> >> -Zak >> >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dagan >> Sent: Thursday, March 23, 2017 3:52 PM >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x >> >> Hi, >> >> I am hoping someone will be able to help answer some questions about >> migrations. >> >> I have been asked to look at upgrading an existing FreeIPA >installation on >> CentOS 6 (3.0.0) to a new installation on CentOS 7 with a recent >stable >> release (4.4.0). >> >> The existing CentOS 6 installation does not manage DNS or have a CA >that >> is being used (though the may be installed. It's primarily for user >> authentication and user group management. >> >> There are only a small number of users, groups, and hosts to migrate >- >> less than 100 of each. >> But the data is used for LDAP integration in various applications so >it >> needs to be consistent. >> >> Would it be recommended to do a straight LDIF type export and import >of >> the data, and configure the new FreeIPA installation for the new >> access/sudo rules? >> >> Would that risk leaving behind any data I would need to know about? >> >> We are planning to review the sudo rules, host access lists etc as >part of >> the migration work. So leaving behind some data may not be a blocker >to >> upgrade. >> >> Any suggestions or links welcome. >> >> Cheers, >> Dagan McGregor >> >> >> >> >> -- >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at sudo.nz Sun Mar 26 22:52:56 2017 From: list at sudo.nz (Dagan) Date: Sun, 26 Mar 2017 22:52:56 +0000 Subject: [Freeipa-users] FreeIPA no CA: Which certs are used for LDAPS and web UI? Message-ID: <17E22F16-9CB2-4091-B7F3-66F8C0DA88FF@sudo.nz> Hi, I have been asked to look at configuring our new FreeIPA environment using existing externally signed wildcard SSL certificates if possible. I see in the documentation options to specify --dirsrv-cert-file and --http-cert-file with relevant passwords. If we configure these options, are they used as the LDAPS and web UI SSL certificates? If not, are there other command options to specify those as external certificates? Do wildcard certificates cause any problems with FreeIPA? Cheers, Dagan McGregor From list at sudo.nz Sun Mar 26 23:06:42 2017 From: list at sudo.nz (Dagan) Date: Sun, 26 Mar 2017 23:06:42 +0000 Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x In-Reply-To: <20170324122803.6s3xmqf26ct3czr3@redhat.com> References: <535BEF94-7EE4-4D90-AB61-C409544E2115@sudo.nz> <1846e5f04c6e755a06b65ec347609097@mail.gmail.com> <9BE76508-A614-461B-A4D3-D8C765FF4721@uni.lu> <20170324122803.6s3xmqf26ct3czr3@redhat.com> Message-ID: Thanks for this information Alexander. I just had a look at the domain levels page. This is very useful to know. Cheers, Dagan McGregor On 25 March 2017 1:28:03 AM NZDT, Alexander Bokovoy wrote: >On pe, 24 maalis 2017, Christophe TREFOIS wrote: >>I?m not expert but I think ipa-replica-prepare is depcrecated in 4.4 >as >>the procedure become more simple. >No, it is not deprecated, that's not true. We have now a concept of >'domain level' which drives certain features. DL 0 uses traditional >method to deploy replicas, DL 1 uses a new one. If you are making new >replica in DL 0 environment, even with new FreeIPA version, you'd >continue using ipa-replica-prepare. For DL 1 environment you would be >using new method -- enroll an IPA client and then promote it to be a >replica. > >-- >/ Alexander Bokovoy > >-- >Manage your subscription for the Freeipa-users mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-users >Go to http://freeipa.org for more info on the project From list at sudo.nz Sun Mar 26 23:08:02 2017 From: list at sudo.nz (Dagan) Date: Sun, 26 Mar 2017 23:08:02 +0000 Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x In-Reply-To: References: <535BEF94-7EE4-4D90-AB61-C409544E2115@sudo.nz> <1846e5f04c6e755a06b65ec347609097@mail.gmail.com> <9BE76508-A614-461B-A4D3-D8C765FF4721@uni.lu> Message-ID: <97A7705D-69E9-4F77-9779-C7E68A36B712@sudo.nz> Thanks for the clarification Standa. Cheers, Dagan McGregor On 25 March 2017 12:39:22 AM NZDT, Standa Laznicka wrote: >While I don't consider myself an expert, I should note that >ipa-replica-prepare has not been deprecated. The proposed solution to >follow > >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrade-6-to-7.html > >is indeed the correct one. > >Not to be confused about ipa-replica-prepare: this command shall not be > >used on domain level 1 machines since the replication is >solved in a smarter and more automatic way. The command would not work >on domain level 1 anyway. > >HTH, >Standa > >On 03/24/2017 11:58 AM, Christophe TREFOIS wrote: >> I?m not expert but I think ipa-replica-prepare is depcrecated in 4.4 >> as the procedure become more simple. >> >> I think setting up a new cluster of CentOS 7.3 machines and setting >up >> replicas against the old cluster is sufficient. >> >> What do the experts say? >> >> -- >> >> Dr Christophe Trefois, Dipl.-Ing. >> Technical Specialist / Post-Doc >> >> UNIVERSIT? DU LUXEMBOURG >> >> LUXEMBOURG CENTRE FOR SYSTEMS BIOMEDICINE >> Campus Belval | House of Biomedicine >> 6, avenue du Swing >> L-4367 Belvaux >> T:+352 46 66 44 6124 >> F:+352 46 66 44 6949 >> http://www.uni.lu/lcsb >> >> Facebook Twitter >> Google Plus >> Linkedin >> skype >> >> >> ---- >> This message is confidential and may contain privileged information. >> It is intended for the named recipient only. >> If you receive it in error please notify me and permanently delete >the >> original message and any copies. >> ---- >> >> >>> On 24 Mar 2017, at 00:54, Zak Peirce >> > wrote: >>> >>> I am looking to take this same journey. I found this guide, it >seems >>> like >>> it covers all the bases >>> >>> >https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/h >>> >tml/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrade-6-to-7.h >>> tml >>> >>> >>> -Zak >>> >>> -----Original Message----- >>> From: freeipa-users-bounces at redhat.com >>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dagan >>> Sent: Thursday, March 23, 2017 3:52 PM >>> To: freeipa-users at redhat.com >>> Subject: [Freeipa-users] Migration from FreeIPA 3.0 to 4.x >>> >>> Hi, >>> >>> I am hoping someone will be able to help answer some questions about >>> migrations. >>> >>> I have been asked to look at upgrading an existing FreeIPA >>> installation on >>> CentOS 6 (3.0.0) to a new installation on CentOS 7 with a recent >stable >>> release (4.4.0). >>> >>> The existing CentOS 6 installation does not manage DNS or have a CA >that >>> is being used (though the may be installed. It's primarily for user >>> authentication and user group management. >>> >>> There are only a small number of users, groups, and hosts to migrate >- >>> less than 100 of each. >>> But the data is used for LDAP integration in various applications so >it >>> needs to be consistent. >>> >>> Would it be recommended to do a straight LDIF type export and import >of >>> the data, and configure the new FreeIPA installation for the new >>> access/sudo rules? >>> >>> Would that risk leaving behind any data I would need to know about? >>> >>> We are planning to review the sudo rules, host access lists etc as >>> part of >>> the migration work. So leaving behind some data may not be a blocker >to >>> upgrade. >>> >>> Any suggestions or links welcome. >>> >>> Cheers, >>> Dagan McGregor >>> >>> >>> >>> >>> -- >>> 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 >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwf at loonybin.net Mon Mar 27 00:18:27 2017 From: rwf at loonybin.net (Rob Foehl) Date: Sun, 26 Mar 2017 20:18:27 -0400 (EDT) Subject: [Freeipa-users] Options for existing CA/DNS infrastructure In-Reply-To: <20170320082941.GB26690@dkupka.usersys.redhat.com> References: <20170320082941.GB26690@dkupka.usersys.redhat.com> Message-ID: On Mon, 20 Mar 2017, David Kupka wrote: > FreeIPA can be deployed in environment with existing DNS and/or CA server. > IIRC you have following options: None of the documentation I've managed to find thus far addresses the general question of which option(s) to choose, and why; in particular, the "Deployment Recommendations" page just presents the options without actually recommending one over another. What's missing is how they behave in the real world, and which tradeoffs cause the least trouble. Maybe that question is too general... Here's a few specifics that fell out of a bunch of experimentation: Is there any utility in installing DNS and delegating a zone to FreeIPA if none of the clients will live in that zone? Is there any current or planned method for absorbing an existing CA cert into a (newly) FreeIPA-installed Dogtag instance that'd allow for continued issuance of a variety of client and service certs from FreeIPA, without having to manage an external CA? -Rob From ftweedal at redhat.com Mon Mar 27 03:04:33 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 27 Mar 2017 13:04:33 +1000 Subject: [Freeipa-users] FreeIPA no CA: Which certs are used for LDAPS and web UI? In-Reply-To: <17E22F16-9CB2-4091-B7F3-66F8C0DA88FF@sudo.nz> References: <17E22F16-9CB2-4091-B7F3-66F8C0DA88FF@sudo.nz> Message-ID: <20170327030433.GC10261@dhcp-40-8.bne.redhat.com> On Sun, Mar 26, 2017 at 10:52:56PM +0000, Dagan wrote: > Hi, > > I have been asked to look at configuring our new FreeIPA environment using existing externally signed wildcard SSL certificates if possible. > > I see in the documentation options to specify --dirsrv-cert-file and --http-cert-file with relevant passwords. > > If we configure these options, are they used as the LDAPS and web UI SSL certificates? > Hi Dagan, Yes, that is how you specify the LDAP and HTTP certificates. > If not, are there other command options to specify those as external certificates? > > Do wildcard certificates cause any problems with FreeIPA? > Wildcard certs will work fine. Cheers, Fraser From vasily.yanov at expcapital.com Tue Mar 21 16:13:31 2017 From: vasily.yanov at expcapital.com (Vasily Yanov) Date: Tue, 21 Mar 2017 19:13:31 +0300 Subject: [Freeipa-users] Certificate Access issue In-Reply-To: <20170321160236.GB23981@10.4.128.1> References: <20170320143937.zl5wcdonzxwbb7aa@redhat.com> <20170320151447.GC9347@10.4.128.1> <20170321142956.np5ennly755lpqt3@redhat.com> <20170321152325.GA23981@10.4.128.1> <20170321153525.7rebcy2eelij6cdz@redhat.com> <20170321160236.GB23981@10.4.128.1> Message-ID: <032601d2a25e$22c706e0$685514a0$@expcapital.com> Hi Lukas, You are right :) Ubuntu 16.04. -----Original Message----- From: Lukas Slebodnik [mailto:lslebodn at redhat.com] Sent: Tuesday, March 21, 2017 7:03 PM To: Alexander Bokovoy Cc: freeipa-users at redhat.com; Artem Golubev ; IT Team Subject: Re: [Freeipa-users] Certificate Access issue On (21/03/17 17:35), Alexander Bokovoy wrote: >On ti, 21 maalis 2017, Lukas Slebodnik wrote: >> On (21/03/17 16:29), Alexander Bokovoy wrote: >> > On ti, 21 maalis 2017, Artem Golubev wrote: >> > > We use sssd version 1.13.4 on our linux clients A user from ipa >> > > successfully authorizes on a linux client via ssh without a >> > > certificate. But then if we add a certificate - connection gets lost. >> > If Lukas is correct, 1.13.4 does not have the fix for broken >> > certificate-as-ssh public key: >> > >> It has. >> https://pagure.io/SSSD/sssd/issue/2977#comment-222198 >> https://pagure.io/SSSD/sssd/c/4dbb3bec93cda57e8336847dff0822f31425004 >> d >> >> It will be part of upstream release 1.13.5 >That's my point -- it is *not* part of 1.13.4, therefore, this is the >problem Artem sees. > >Artem, what is your Linux distribution? Can you move to a newer version? > I would gues ubuntu :-) You might file a bug to your distribution to backport patch from the ticket https://pagure.io/SSSD/sssd/issue/2977 LS From sys-admin at camgian.com Fri Mar 24 15:26:31 2017 From: sys-admin at camgian.com (System Administration Team) Date: Fri, 24 Mar 2017 15:26:31 +0000 Subject: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in Message-ID: >From old threads back in August 2016 I have been able to get closer to installing freeipa server as a subCA to our in house rootCA https://www.redhat.com/archives/freeipa-users/2016-August/msg00269.html Running the initial install command ipa-server-install --external-ca --domain=camgian.com --hostname=ipasrvr.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian Microsystems,L=Starkville,ST=Mississippi,C=US' I am provided with /root/ipa.csr that I can signed with our rootCA But when I run the subsequent command it fails to find the certificate in the chain. ipa-server-install --external-ca --domain=camgian.com --hostname=ipasrvr.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian Microsystems,L=Starkville,ST=Mississippi,C=US' --external-cert-file=/etc/pki/tls/certs/ipasrvr.cert.pem --external-cert-file=/etc/pki/tls/certs/ca.cert.pem It fails at: ipa.ipapython.install.cli.install_tool(Server): ERROR IPA CA certificate not found in /etc/pki/tls/certs/ipasrvr.cert.pem, /etc/pki/tls/certs/ca.cert.pem ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information Any help in the correct direction to resolve this will be greatly appreciated. Clark -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Mon Mar 27 07:21:01 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 27 Mar 2017 17:21:01 +1000 Subject: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in In-Reply-To: References: Message-ID: <20170327072101.GD10261@dhcp-40-8.bne.redhat.com> On Fri, Mar 24, 2017 at 03:26:31PM +0000, System Administration Team wrote: > >From old threads back in August 2016 I have been able to get closer to installing freeipa server as a subCA to our in house rootCA > > https://www.redhat.com/archives/freeipa-users/2016-August/msg00269.html > > Running the initial install command > > ipa-server-install --external-ca --domain=camgian.com --hostname=ipasrvr.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian Microsystems,L=Starkville,ST=Mississippi,C=US' > > I am provided with /root/ipa.csr that I can signed with our rootCA > > But when I run the subsequent command it fails to find the certificate in the chain. > > ipa-server-install --external-ca --domain=camgian.com --hostname=ipasrvr.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian Microsystems,L=Starkville,ST=Mississippi,C=US' --external-cert-file=/etc/pki/tls/certs/ipasrvr.cert.pem --external-cert-file=/etc/pki/tls/certs/ca.cert.pem > > It fails at: > > ipa.ipapython.install.cli.install_tool(Server): ERROR IPA CA certificate not found in /etc/pki/tls/certs/ipasrvr.cert.pem, /etc/pki/tls/certs/ca.cert.pem > ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information > > Any help in the correct direction to resolve this will be greatly appreciated. > > Clark > > Does the subject distinguished name in the signed certificate exactly match what was in the CSR? From mbasti at redhat.com Mon Mar 27 10:23:15 2017 From: mbasti at redhat.com (Martin Basti) Date: Mon, 27 Mar 2017 12:23:15 +0200 Subject: [Freeipa-users] First-class support for the docker image In-Reply-To: <4389a74e-eac2-abed-e531-b07f0680cb3a@gmail.com> References: <4389a74e-eac2-abed-e531-b07f0680cb3a@gmail.com> Message-ID: <5ca7d62a-d49c-aca4-52f0-db299fef5578@redhat.com> On 03/25/2017 12:55 AM, Terence Kent wrote: > Hello, > > We've been using the FreeIPA docker image for a few years now with > great success. I really can't overstate how much we get by using a > container deployment for FreeIPA. We can now easily test anything from > version upgrades to orchestration code against either test data and > our production data set. That, and we get all the typical docker > goodness (we can easily move the container between hosts, change the > underlying OS independently, etc, etc). > > That said, lots of the work in the freeipa docker image's gitrepo are > things that seem like they belong in the freeipa main codebase. We've > had to trace through the freeipa-container source from time to time to > diagnose issues and we see situations where the docker build file > actually modifies python code using text replaces. > > This seems both easily breakable and like a lot more work than just > modifying the source file to optionally support whatever a > containerized environment needs. Is there a reason to keep container > support out of the main freeipa project? > > Best, > Terence > Hello, we have plans to update FreeIPA codebase to avoid hacks in Docker, but we had more prioritized tasks to do. However we are looking forward to merging community patches to have synchronized FreeIPA code base and containerized FreeIPA It was separated due rapid FreeIPA container development to make it possible to work ASAP without waiting for FreeIPA core. Martin From sys-admin at camgian.com Mon Mar 27 16:19:42 2017 From: sys-admin at camgian.com (System Administration Team) Date: Mon, 27 Mar 2017 16:19:42 +0000 Subject: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in In-Reply-To: <20170327072101.GD10261@dhcp-40-8.bne.redhat.com> References: <20170327072101.GD10261@dhcp-40-8.bne.redhat.com> Message-ID: Fraser, I cannot pass the DN or CN as part of the subject on the command line ipa-server-install Ipa-server-install appears to set the CN to 'Certificate Authority' from the openssl output. I believe the preferred for a subCA should be the FQDN of the subCA server which is the ipa install. The final error when I try to run ipa-server-install: ipa.ipapython.install.cli.install_tool(Server): ERROR IPA CA certificate not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information Thank You Clark > > Does the subject distinguished name in the signed certificate exactly match what was in the CSR? 2017-03-27 IPA Install [root at ipa certs]# ipa-server-install --external-ca --domain=camgian.com --hostname=ipa.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian Microsystems,L=Starkville,ST=Mississippi,C=US,mail=' The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will set up the IPA Server. This includes: * Configure a stand-alone CA (dogtag) for certificate management * Configure the Network Time Daemon (ntpd) * Create and configure an instance of Directory Server * Create and configure a Kerberos Key Distribution Center (KDC) * Configure Apache (httpd) To accept the default shown in brackets, press the Enter key. Do you want to configure integrated DNS (BIND)? [no]: Certain directory server operations require an administrative user. This user is referred to as the Directory Manager and has full access to the Directory for system management tasks and will be added to the instance of directory server created for IPA. The password must be at least 8 characters long. Directory Manager password: Password (confirm): The IPA server requires an administrative user, named 'admin'. This user is a regular system account used for IPA server administration. IPA admin password: Password (confirm): The IPA Master Server will be configured with: Hostname: ipa.camgian.com IP address(es): 192.168.200.3 Domain name: camgian.com Realm name: CAMGIAN.COM Continue to configure the system with these values? [no]: yes The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv). Estimated time: 1 minute [1/47]: creating directory server user [2/47]: creating directory server instance [3/47]: updating configuration in dse.ldif [4/47]: restarting directory server [5/47]: adding default schema [6/47]: enabling memberof plugin [7/47]: enabling winsync plugin [8/47]: configuring replication version plugin [9/47]: enabling IPA enrollment plugin [10/47]: enabling ldapi [11/47]: configuring uniqueness plugin [12/47]: configuring uuid plugin [13/47]: configuring modrdn plugin [14/47]: configuring DNS plugin [15/47]: enabling entryUSN plugin [16/47]: configuring lockout plugin [17/47]: configuring topology plugin [18/47]: creating indices [19/47]: enabling referential integrity plugin [20/47]: configuring certmap.conf [21/47]: configure autobind for root [22/47]: configure new location for managed entries [23/47]: configure dirsrv ccache [24/47]: enabling SASL mapping fallback [25/47]: restarting directory server [26/47]: adding sasl mappings to the directory [27/47]: adding default layout [28/47]: adding delegation layout [29/47]: creating container for managed entries [30/47]: configuring user private groups [31/47]: configuring netgroups from hostgroups [32/47]: creating default Sudo bind user [33/47]: creating default Auto Member layout [34/47]: adding range check plugin [35/47]: creating default HBAC rule allow_all [36/47]: adding sasl mappings to the directory [37/47]: adding entries for topology management [38/47]: initializing group membership [39/47]: adding master entry [40/47]: initializing domain level [41/47]: configuring Posix uid/gid generation [42/47]: adding replication acis [43/47]: enabling compatibility plugin [44/47]: activating sidgen plugin [45/47]: activating extdom plugin [46/47]: tuning directory server [47/47]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds [1/8]: creating certificate server user [2/8]: configuring certificate server instance The next step is to get /root/ipa.csr signed by your CA and re-run /usr/sbin/ipa-server-install as: /usr/sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate [root at ipa certs]# [root at ipa certs]# openssl req -in /root/ipa.csr -noout -text Certificate Request: Data: Version: 0 (0x0) Subject: mail=, C=US, ST=Mississippi, L=Starkville, O=Camgian Microsystems, OU=IT, CN=Certificate Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Non Repudiation, Certificate Sign, CRL Sign Signature Algorithm: sha256WithRSAEncryption [root at ipa certs]# Sign ipa.csr root at rootCA:~/ca# openssl ca -config openssl.cnf -policy policy_loose -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in /home/camgian/ipa.csr -out intermediate/certs/ipa.cert.pem Using configuration from openssl.cnf Enter pass phrase for /root/ca/private/ca.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4099 (0x1003) Validity Not Before: Mar 27 15:49:18 2017 GMT Not After : Mar 25 15:49:18 2027 GMT Subject: countryName = US stateOrProvinceName = Mississippi localityName = Starkville organizationName = Camgian Microsystems organizationalUnitName = IT commonName = Certificate Authority X509v3 extensions: X509v3 Subject Key Identifier: D3:FC:DE:2B:F8:5B:50:9B:31:68:92:D0:06:31:1B:F9:EB:63:B5:6A X509v3 Authority Key Identifier: keyid:60:1B:78:1A:BD:3C:97:78:A6:04:72:A0:FA:6E:11:48:55:B0:5B:40 X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign Certificate is to be certified until Mar 25 15:49:18 2027 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated root at rootCA:~/ca# root at rootCA:~/ca# openssl x509 -noout -text -in /root/ca/intermediate/certs/ipa.cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 4099 (0x1003) Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Mississippi, L=Starkville, O=Camgian Microsystems, OU=IT, CN=Camgian Microsystems Root CA/emailAddress= Validity Not Before: Mar 27 15:49:18 2017 GMT Not After : Mar 25 15:49:18 2027 GMT Subject: C=US, ST=Mississippi, L=Starkville, O=Camgian Microsystems, OU=IT, CN=Certificate Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: D3:FC:DE:2B:F8:5B:50:9B:31:68:92:D0:06:31:1B:F9:EB:63:B5:6A X509v3 Authority Key Identifier: keyid:60:1B:78:1A:BD:3C:97:78:A6:04:72:A0:FA:6E:11:48:55:B0:5B:40 X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign Signature Algorithm: sha256WithRSAEncryption root at rootCA:~/ca# [root at ipa certs]# ipa-server-install --domain=camgian.com --hostname=ipa.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian Microsystems,L=Starkville,ST=Mississippi,C=US,mail=' --external-cert-file=/etc/pki/tls/certs/ipa.cert.pem --external-cert-file=/etc/pki/tls/certs/ca.cert.pem The log file for this installation can be found in /var/log/ipaserver-install.log Directory Manager password: ============================================================================== This program will set up the IPA Server. This includes: * Configure a stand-alone CA (dogtag) for certificate management * Configure the Network Time Daemon (ntpd) * Create and configure an instance of Directory Server * Create and configure a Kerberos Key Distribution Center (KDC) * Configure Apache (httpd) ipa.ipapython.install.cli.install_tool(Server): ERROR IPA CA certificate not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information [root at ipa certs]# From david.goudet at lyra-network.com Mon Mar 27 16:34:24 2017 From: david.goudet at lyra-network.com (David Goudet) Date: Mon, 27 Mar 2017 18:34:24 +0200 (CEST) Subject: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address Message-ID: <1957299510.33604866.1490632464222.JavaMail.zimbra@lyra-network.com> Hi, Thanks to dyndns_update=True parameter, SSSD service on client machine updating host DNS entry in FreeIPA. Everything is fine on machines which have only one IP adress on network interface. I have problem with machines which have more that one IP address on network interface: if machine have two IP address, SSSD update host DNS entry with these two IP address. To reproduce the problem: Host have -IP1- and i add -IP2- ip addr add -IP2-/26 dev em1 ip addr list: em1: mtu 1496 qdisc mq state UP qlen 1000 link/ether xxxx inet -IP1-/26 brd XXXX scope global em1 inet -IP2-/26 scope global secondary em1 valid_lft forever preferred_lft forever DNS resolution (dig) before restarting sssd returns only -IP1-. After restarting sssd returns -IP1- & -IP2- In dyndns_update manpage, we have "The IP address of the IPA LDAP connection is used for the updates", what does it means? Is it IP address of the DNS server (used to update the DNS entry)? or is it IP address on client machine used during LDAP TCP bind (-IP1- in my case)? dyndns_update (boolean) Optional. This option tells SSSD to automatically update the DNS server built into FreeIPA v2 with the IP address of this client. The update is secured using GSS-TSIG. The IP address of the IPA LDAP connection is used for the updates, if it is not otherwise specified by using the ?dyndns_iface? option. Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on client machine? Is it possible to configure SSSD to update DNS with only IP address "primary" in ip addr list or which is used to FreeIPA server communication (-IP1- used on TCP binding)? My environment is: Client: Centos 7.2 sssd-common-1.13.0-40.el7_2.12.x86_64 sssd-ipa-1.13.0-40.el7_2.12.x86_64 sssd-1.13.0-40.el7_2.12.x86_64 sssd-client-1.13.0-40.el7_2.12.x86_64 FreeIPA server: Centos 6.7 ipa-server-3.0.0-47.el6.centos.2.x86_64 bind-9.8.2-0.30.rc1.el6_6.3.x86_64 bind-utils-9.8.2-0.37.rc1.el6_7.7.x86_64 bind-libs-9.8.2-0.37.rc1.el6_7.7.x86_64 rpcbind-0.2.0-11.el6_7.x86_64 bind-libs-9.8.2-0.30.rc1.el6_6.3.x86_64 rpcbind-0.2.0-11.el6.x86_64 bind-dyndb-ldap-2.3-8.el6.x86_64 bind-9.8.2-0.37.rc1.el6_7.7.x86_64 SSSD configuration on client: [domain/] debug_level=18 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt chpass_provider = ipa dyndns_update = True ipa_server = _srv_, ds01., ds01. dns_discovery_domain = Named FreeIPA logs: ------------------- Mar 27 17:03:57 ds01. named[6607]: client -IP1-#36331: updating zone '/IN': deleting rrset at '' A Mar 27 17:03:57 ds01. named[6607]: update_record (psearch) failed, dn 'idnsName=2,idnsname=.in-addr.arpa.,cn=dns,dc=yyy,dc=xxx' change type 0x4. Records can be outdated, run `rndc reload`: not found Mar 27 17:03:57 ds01. named[6607]: zone /IN: sending notifies (serial 1490615011) Mar 27 17:03:57 ds01. named[6607]: client -IP1-#46187: updating zone '/IN': deleting rrset at '.' AAAA Mar 27 17:03:57 ds01. named[6607]: client -IP1-#54691: updating zone '/IN': adding an RR at '.' A Mar 27 17:03:57 ds01. named[6607]: client -IP1-#54691: updating zone '/IN': adding an RR at '.' A Mar 27 17:03:57 ds01. named[6607]: zone .in-addr.arpa/IN: sending notifies (serial 1490627037) Mar 27 17:04:02 ds01. named[6607]: zone /IN: sending notifies (serial 1490627038) SSSD trace log on client during sssd restart: ----------------------- (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [ipa_dyndns_update_send] (0x0400): Performing update (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_is_address] (0x4000): [.] does not look like an IP address (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_step] (0x2000): Querying DNS (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of '.' in DNS (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [request_watch_destructor] (0x0400): Deleting request watch (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_is_address] (0x4000): [.] does not look like an IP address (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_step] (0x2000): Querying DNS (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve AAAA record of '.' in DNS (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [request_watch_destructor] (0x0400): Deleting request watch (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [resolv_gethostbyname_next] (0x0100): No more hosts databases to retry (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_dyndns_addrs_diff] (0x1000): Address on localhost only: -IP2- (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [sdap_dyndns_dns_addrs_done] (0x0400): Detected IP addresses change, will perform an update (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [nsupdate_msg_create_common] (0x0200): Creating update message for realm []. (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- realm update delete .. in A send update delete .. in AAAA send update add .. 1200 in A -IP2- update add .. 1200 in A -IP1- send -- End nsupdate message -- .. (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [nsupdate_msg_create_common] (0x0200): Creating update message for server [ds01.] and realm []. (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- server ds01. realm update delete .. in A send update delete .. in AAAA send update add .. 1200 in A -IP2- update add .. 1200 in A -IP1- send -- End nsupdate message -- (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [20631] (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [child_handler_setup] (0x2000): Signal handler set up for pid [20631] (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete (Mon Mar 27 17:03:56 2017) [sssd[be[]]] [be_nsupdate_args] (0x0200): nsupdate auth type: GSS-TSIG setup_system() Thank you for your help! -- David GOUDET LYRA NETWORK IT Operations service Tel : +33 (0)5 32 09 09 74 | Poste : 574 From tkrizek at redhat.com Mon Mar 27 17:20:23 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Mon, 27 Mar 2017 19:20:23 +0200 Subject: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in In-Reply-To: References: <20170327072101.GD10261@dhcp-40-8.bne.redhat.com> Message-ID: <016ac7e9-a496-3192-cdd5-0d7b3360e4eb@redhat.com> On 03/27/2017 06:19 PM, System Administration Team wrote: > [root at ipa certs]# openssl req -in /root/ipa.csr -noout -text > Certificate Request: > Data: > Version: 0 (0x0) > Subject: mail=, C=US, ST=Mississippi, L=Starkville, O=Camgian Microsystems, OU=IT, CN=Certificate Authority > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > > Exponent: 65537 (0x10001) > Attributes: > Requested Extensions: > X509v3 Basic Constraints: critical > CA:TRUE > X509v3 Key Usage: critical > Digital Signature, Non Repudiation, Certificate Sign, CRL Sign > Signature Algorithm: sha256WithRSAEncryption > > [root at ipa certs]# > > Sign ipa.csr > > root at rootCA:~/ca# openssl ca -config openssl.cnf -policy policy_loose -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in /home/camgian/ipa.csr -out intermediate/certs/ipa.cert.pem Using configuration from openssl.cnf Enter pass phrase for /root/ca/private/ca.key.pem: > Check that the request matches the signature Signature ok Certificate Details: > Serial Number: 4099 (0x1003) > Validity > Not Before: Mar 27 15:49:18 2017 GMT > Not After : Mar 25 15:49:18 2027 GMT > Subject: > countryName = US > stateOrProvinceName = Mississippi > localityName = Starkville > organizationName = Camgian Microsystems > organizationalUnitName = IT > commonName = Certificate Authority The signed certificate's Subject field seems to be missing the mail=. Perhaps the signing rules do not permit this field? > [root at ipa certs]# ipa-server-install --domain=camgian.com --hostname=ipa.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian Microsystems,L=Starkville,ST=Mississippi,C=US,mail=' --external-cert-file=/etc/pki/tls/certs/ipa.cert.pem --external-cert-file=/etc/pki/tls/certs/ca.cert.pem I believe you can't force IPA to use a different subject at the second step of setting up external CA. I think it's only used to generate the CSR in the first step. > ipa.ipapython.install.cli.install_tool(Server): ERROR IPA CA certificate not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem > ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information The installation most likely fails because mail= is expected to be a part of the signed certificate's subject field. -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From sys-admin at camgian.com Mon Mar 27 19:40:20 2017 From: sys-admin at camgian.com (System Administration Team) Date: Mon, 27 Mar 2017 19:40:20 +0000 Subject: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in In-Reply-To: <016ac7e9-a496-3192-cdd5-0d7b3360e4eb@redhat.com> References: <20170327072101.GD10261@dhcp-40-8.bne.redhat.com> <016ac7e9-a496-3192-cdd5-0d7b3360e4eb@redhat.com> Message-ID: -----Original Message----- From: Tomas Krizek [mailto:tkrizek at redhat.com] Sent: Monday, March 27, 2017 12:20 PM To: System Administration Team ; Fraser Tweedale Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in On 03/27/2017 06:19 PM, System Administration Team wrote: > [root at ipa certs]# openssl req -in /root/ipa.csr -noout -text > Certificate Request: > Data: > Version: 0 (0x0) > Subject: mail=, C=US, ST=Mississippi, L=Starkville, O=Camgian Microsystems, OU=IT, CN=Certificate Authority > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > > Exponent: 65537 (0x10001) > Attributes: > Requested Extensions: > X509v3 Basic Constraints: critical > CA:TRUE > X509v3 Key Usage: critical > Digital Signature, Non Repudiation, Certificate Sign, CRL Sign > Signature Algorithm: sha256WithRSAEncryption > > [root at ipa certs]# > > Sign ipa.csr > > root at rootCA:~/ca# openssl ca -config openssl.cnf -policy policy_loose -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in /home/camgian/ipa.csr -out intermediate/certs/ipa.cert.pem Using configuration from openssl.cnf Enter pass phrase for /root/ca/private/ca.key.pem: > Check that the request matches the signature Signature ok Certificate Details: > Serial Number: 4099 (0x1003) > Validity > Not Before: Mar 27 15:49:18 2017 GMT > Not After : Mar 25 15:49:18 2027 GMT > Subject: > countryName = US > stateOrProvinceName = Mississippi > localityName = Starkville > organizationName = Camgian Microsystems > organizationalUnitName = IT > commonName = Certificate Authority The signed certificate's Subject field seems to be missing the mail=. Perhaps the signing rules do not permit this field? I removed this field so it would not be archived in this list since I now get Porn Spam from Kim when I post to it. > [root at ipa certs]# ipa-server-install --domain=camgian.com > --hostname=ipa.camgian.com --realm=CAMGIAN.COM --subject > 'OU=IT,O=Camgian > Microsystems,L=Starkville,ST=Mississippi,C=US,mail=' > --external-cert-file=/etc/pki/tls/certs/ipa.cert.pem > --external-cert-file=/etc/pki/tls/certs/ca.cert.pem I believe you can't force IPA to use a different subject at the second step of setting up external CA. I think it's only used to generate the CSR in the first step. I have tried both ways.... >From the logfile below it looks like it is picking up the CN from my ROOT CA rather than the CN from IPA-SERVER-Install it looks like... [root at ipa certs]# ipa-server-install --external-cert-file=/etc/pki/tls/certs/ipa.cert.pem --external-cert-file=/etc/pki/tls/certs/ca.cert.pem The log file for this installation can be found in /var/log/ipaserver-install.log Directory Manager password: ============================================================================== This program will set up the IPA Server. This includes: * Configure a stand-alone CA (dogtag) for certificate management * Configure the Network Time Daemon (ntpd) * Create and configure an instance of Directory Server * Create and configure a Kerberos Key Distribution Center (KDC) * Configure Apache (httpd) ipa.ipapython.install.cli.install_tool(Server): ERROR IPA CA certificate not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information [root at ipa certs]# FROM Log File: 2017-03-27T19:34:45Z DEBUG stderr= 2017-03-27T19:34:45Z DEBUG Starting external process 2017-03-27T19:34:45Z DEBUG args=/usr/bin/certutil -d /tmp/tmpHEVPYc -M -n E=,CN=Camgian Microsystems Root CA,OU=IT,O=Camgian Microsystems,L=Starkville,ST=Mississippi,C=US -t C,, 2017-03-27T19:34:45Z DEBUG Process finished, return code=0 2017-03-27T19:34:45Z DEBUG stdout= 2017-03-27T19:34:45Z DEBUG stderr= 2017-03-27T19:34:45Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 308, in run self.validate() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 317, in validate for nothing in self._validator(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 564, in _configure next(validator) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 449, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 63, in _install for nothing in self._installer(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 1355, in main install_check(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 267, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 600, in install_check ca.install_check(False, None, options) File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line 73, in install_check options.external_cert_files, options.subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 1039, in load_external_cert "IPA CA certificate not found in %s" % (", ".join(files))) 2017-03-27T19:34:45Z DEBUG The ipa-server-install command failed, exception: ScriptError: IPA CA certificate not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem 2017-03-27T19:34:45Z ERROR IPA CA certificate not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem 2017-03-27T19:34:45Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information [root at ipa certs]# > ipa.ipapython.install.cli.install_tool(Server): ERROR IPA CA certificate not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem > ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information The installation most likely fails because mail= is expected to be a part of the signed certificate's subject field. -- Tomas Krizek PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869 From jhrozek at redhat.com Mon Mar 27 19:40:45 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 27 Mar 2017 21:40:45 +0200 Subject: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address In-Reply-To: <1957299510.33604866.1490632464222.JavaMail.zimbra@lyra-network.com> References: <1957299510.33604866.1490632464222.JavaMail.zimbra@lyra-network.com> Message-ID: <20170327194045.upov74ythihflwby@hendrix> On Mon, Mar 27, 2017 at 06:34:24PM +0200, David Goudet wrote: > Hi, > > Thanks to dyndns_update=True parameter, SSSD service on client machine updating host DNS entry in FreeIPA. > Everything is fine on machines which have only one IP adress on network interface. > I have problem with machines which have more that one IP address on network interface: if machine have two IP address, SSSD update host DNS entry with these two IP address. > > To reproduce the problem: > Host have -IP1- and i add -IP2- > ip addr add -IP2-/26 dev em1 > > ip addr list: > em1: mtu 1496 qdisc mq state UP qlen 1000 > link/ether xxxx > inet -IP1-/26 brd XXXX scope global em1 > inet -IP2-/26 scope global secondary em1 > valid_lft forever preferred_lft forever > > DNS resolution (dig) before restarting sssd returns only -IP1-. After restarting sssd returns -IP1- & -IP2- > > In dyndns_update manpage, we have "The IP address of the IPA LDAP connection is used for the updates", what does it means? Is it IP address of the DNS server (used to update the DNS entry)? or is it IP address on client machine used during LDAP TCP bind (-IP1- in my case)? > > dyndns_update (boolean) > Optional. This option tells SSSD to automatically update the DNS server built into FreeIPA v2 with the IP address of this client. > The update is secured using GSS-TSIG. The IP address of the IPA LDAP connection is used for the updates, if it is not otherwise > specified by using the ?dyndns_iface? option. > > Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on client machine? Looks like this was a deliberate change: https://pagure.io/SSSD/sssd/issue/2558 but to be honest, I forgot why exactly we did this. Martin, do you know? > Is it possible to configure SSSD to update DNS with only IP address "primary" in ip addr list or which is used to FreeIPA server communication (-IP1- used on TCP binding)? Only if the IP addresses are of different families (v4/v6), then it's possible to restrict one of the families. From schogan at us.ibm.com Mon Mar 27 20:52:18 2017 From: schogan at us.ibm.com (Sean Hogan) Date: Mon, 27 Mar 2017 13:52:18 -0700 Subject: [Freeipa-users] Sudo Rule flag limitations Message-ID: Hello, I was wondering how possible it would be to allow sudo commands with certain flags but not the actual command Case in point: If a user requests sudo fdisk -l to view partitions can this be set without giving access to sudo fdisk /dev/sda ? Would the sudo rule have to deny fdisk /dev/sda but allow fdisk -l? Not really sure how that would work. ipa-client-3.0.0-50.el6.1.x86_64 ipa-server-selinux-3.0.0-50.el6.1.x86_64 ipa-server-3.0.0-50.el6.1.x86_64 sssd-ipa-1.13.3-22.el6_8.4.x86_64 python-libipa_hbac-1.13.3-22.el6_8.4.x86_64 ipa-admintools-3.0.0-50.el6.1.x86_64 python-iniparse-0.3.1-2.1.el6.noarch Thank you Sean Hogan -------------- next part -------------- An HTML attachment was scrubbed... URL: From schogan at us.ibm.com Mon Mar 27 21:50:50 2017 From: schogan at us.ibm.com (Sean Hogan) Date: Mon, 27 Mar 2017 14:50:50 -0700 Subject: [Freeipa-users] Sudo Rule flag limitations In-Reply-To: References: Message-ID: Disregard .. I figured it out just added /usr/bin fdisk -l to command list run as user root and applied the command to sudo rule Running as expected where sudo fdisk /dev/sda fails but sudo fdisk -l works Sean Hogan From: Sean Hogan/Durham/IBM at IBMUS To: freeipa-users Date: 03/27/2017 01:55 PM Subject: [Freeipa-users] Sudo Rule flag limitations Sent by: freeipa-users-bounces at redhat.com Hello, I was wondering how possible it would be to allow sudo commands with certain flags but not the actual command Case in point: If a user requests sudo fdisk -l to view partitions can this be set without giving access to sudo fdisk /dev/sda ? Would the sudo rule have to deny fdisk /dev/sda but allow fdisk -l? Not really sure how that would work. ipa-client-3.0.0-50.el6.1.x86_64 ipa-server-selinux-3.0.0-50.el6.1.x86_64 ipa-server-3.0.0-50.el6.1.x86_64 sssd-ipa-1.13.3-22.el6_8.4.x86_64 python-libipa_hbac-1.13.3-22.el6_8.4.x86_64 ipa-admintools-3.0.0-50.el6.1.x86_64 python-iniparse-0.3.1-2.1.el6.noarch Thank you Sean Hogan -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: image/gif Size: 45 bytes Desc: not available URL: From ftweedal at redhat.com Mon Mar 27 23:35:28 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 28 Mar 2017 09:35:28 +1000 Subject: [Freeipa-users] Configuring freeipa 4.4 as a subCA to in-house rootCA : ERROR IPA CA certificate not found in In-Reply-To: References: <20170327072101.GD10261@dhcp-40-8.bne.redhat.com> Message-ID: <20170327233528.GF10261@dhcp-40-8.bne.redhat.com> Hi Clark, On Mon, Mar 27, 2017 at 04:19:42PM +0000, System Administration Team wrote: > Fraser, > > I cannot pass the DN or CN as part of the subject on the command line ipa-server-install > > Ipa-server-install appears to set the CN to 'Certificate Authority' from the openssl output. > The ability to control this was added in v4.5: http://www.freeipa.org/page/Releases/4.5.0#Fully_customisable_CA_name But, the Subject DN in the CSR is advisory; we have no control over what the external CA actually does. FreeIPA requires the signed cert to match what was in the CSR. > I believe the preferred for a subCA should be the FQDN of the subCA server which is the ipa install. > It doesn't matter, as long as it's different from other CAs. > The final error when I try to run ipa-server-install: > > ipa.ipapython.install.cli.install_tool(Server): ERROR IPA CA certificate not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem > ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information > This is consistent with the signed cert having a different Subject DN from what IPA expects (which is what it put into the CSR). Cheers, Fraser > Thank You > > Clark > > > > > > Does the subject distinguished name in the signed certificate exactly match what was in the CSR? > > > 2017-03-27 IPA Install > > [root at ipa certs]# ipa-server-install --external-ca --domain=camgian.com --hostname=ipa.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian Microsystems,L=Starkville,ST=Mississippi,C=US,mail=' > > The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== > This program will set up the IPA Server. > > This includes: > * Configure a stand-alone CA (dogtag) for certificate management > * Configure the Network Time Daemon (ntpd) > * Create and configure an instance of Directory Server > * Create and configure a Kerberos Key Distribution Center (KDC) > * Configure Apache (httpd) > > To accept the default shown in brackets, press the Enter key. > > Do you want to configure integrated DNS (BIND)? [no]: > > Certain directory server operations require an administrative user. > This user is referred to as the Directory Manager and has full access to the Directory for system management tasks and will be added to the instance of directory server created for IPA. > The password must be at least 8 characters long. > > Directory Manager password: > Password (confirm): > > The IPA server requires an administrative user, named 'admin'. > This user is a regular system account used for IPA server administration. > > IPA admin password: > Password (confirm): > > > The IPA Master Server will be configured with: > Hostname: ipa.camgian.com > IP address(es): 192.168.200.3 > Domain name: camgian.com > Realm name: CAMGIAN.COM > > Continue to configure the system with these values? [no]: yes > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv). Estimated time: 1 minute > [1/47]: creating directory server user > [2/47]: creating directory server instance > [3/47]: updating configuration in dse.ldif > [4/47]: restarting directory server > [5/47]: adding default schema > [6/47]: enabling memberof plugin > [7/47]: enabling winsync plugin > [8/47]: configuring replication version plugin > [9/47]: enabling IPA enrollment plugin > [10/47]: enabling ldapi > [11/47]: configuring uniqueness plugin > [12/47]: configuring uuid plugin > [13/47]: configuring modrdn plugin > [14/47]: configuring DNS plugin > [15/47]: enabling entryUSN plugin > [16/47]: configuring lockout plugin > [17/47]: configuring topology plugin > [18/47]: creating indices > [19/47]: enabling referential integrity plugin > [20/47]: configuring certmap.conf > [21/47]: configure autobind for root > [22/47]: configure new location for managed entries > [23/47]: configure dirsrv ccache > [24/47]: enabling SASL mapping fallback > [25/47]: restarting directory server > [26/47]: adding sasl mappings to the directory > [27/47]: adding default layout > [28/47]: adding delegation layout > [29/47]: creating container for managed entries > [30/47]: configuring user private groups > [31/47]: configuring netgroups from hostgroups > [32/47]: creating default Sudo bind user > [33/47]: creating default Auto Member layout > [34/47]: adding range check plugin > [35/47]: creating default HBAC rule allow_all > [36/47]: adding sasl mappings to the directory > [37/47]: adding entries for topology management > [38/47]: initializing group membership > [39/47]: adding master entry > [40/47]: initializing domain level > [41/47]: configuring Posix uid/gid generation > [42/47]: adding replication acis > [43/47]: enabling compatibility plugin > [44/47]: activating sidgen plugin > [45/47]: activating extdom plugin > [46/47]: tuning directory server > [47/47]: configuring directory to start on boot Done configuring directory server (dirsrv). > Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds > [1/8]: creating certificate server user > [2/8]: configuring certificate server instance The next step is to get /root/ipa.csr signed by your CA and re-run /usr/sbin/ipa-server-install as: > /usr/sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate > [root at ipa certs]# > > > [root at ipa certs]# openssl req -in /root/ipa.csr -noout -text Certificate Request: > Data: > Version: 0 (0x0) > Subject: mail=, C=US, ST=Mississippi, L=Starkville, O=Camgian Microsystems, OU=IT, CN=Certificate Authority > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > > Exponent: 65537 (0x10001) > Attributes: > Requested Extensions: > X509v3 Basic Constraints: critical > CA:TRUE > X509v3 Key Usage: critical > Digital Signature, Non Repudiation, Certificate Sign, CRL Sign > Signature Algorithm: sha256WithRSAEncryption > > [root at ipa certs]# > > Sign ipa.csr > > root at rootCA:~/ca# openssl ca -config openssl.cnf -policy policy_loose -extensions v3_intermediate_ca -days 3650 -notext -md sha256 -in /home/camgian/ipa.csr -out intermediate/certs/ipa.cert.pem Using configuration from openssl.cnf Enter pass phrase for /root/ca/private/ca.key.pem: > Check that the request matches the signature Signature ok Certificate Details: > Serial Number: 4099 (0x1003) > Validity > Not Before: Mar 27 15:49:18 2017 GMT > Not After : Mar 25 15:49:18 2027 GMT > Subject: > countryName = US > stateOrProvinceName = Mississippi > localityName = Starkville > organizationName = Camgian Microsystems > organizationalUnitName = IT > commonName = Certificate Authority > X509v3 extensions: > X509v3 Subject Key Identifier: > D3:FC:DE:2B:F8:5B:50:9B:31:68:92:D0:06:31:1B:F9:EB:63:B5:6A > X509v3 Authority Key Identifier: > keyid:60:1B:78:1A:BD:3C:97:78:A6:04:72:A0:FA:6E:11:48:55:B0:5B:40 > > X509v3 Basic Constraints: critical > CA:TRUE, pathlen:0 > X509v3 Key Usage: critical > Digital Signature, Certificate Sign, CRL Sign Certificate is to be certified until Mar 25 15:49:18 2027 GMT (3650 days) Sign the certificate? [y/n]:y > > > 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated root at rootCA:~/ca# > > > root at rootCA:~/ca# openssl x509 -noout -text -in /root/ca/intermediate/certs/ipa.cert.pem > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 4099 (0x1003) > Signature Algorithm: sha256WithRSAEncryption > Issuer: C=US, ST=Mississippi, L=Starkville, O=Camgian Microsystems, OU=IT, CN=Camgian Microsystems Root CA/emailAddress= > Validity > Not Before: Mar 27 15:49:18 2017 GMT > Not After : Mar 25 15:49:18 2027 GMT > Subject: C=US, ST=Mississippi, L=Starkville, O=Camgian Microsystems, OU=IT, CN=Certificate Authority > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Subject Key Identifier: > D3:FC:DE:2B:F8:5B:50:9B:31:68:92:D0:06:31:1B:F9:EB:63:B5:6A > X509v3 Authority Key Identifier: > keyid:60:1B:78:1A:BD:3C:97:78:A6:04:72:A0:FA:6E:11:48:55:B0:5B:40 > > X509v3 Basic Constraints: critical > CA:TRUE, pathlen:0 > X509v3 Key Usage: critical > Digital Signature, Certificate Sign, CRL Sign > Signature Algorithm: sha256WithRSAEncryption > > root at rootCA:~/ca# > > [root at ipa certs]# ipa-server-install --domain=camgian.com --hostname=ipa.camgian.com --realm=CAMGIAN.COM --subject 'OU=IT,O=Camgian Microsystems,L=Starkville,ST=Mississippi,C=US,mail=' --external-cert-file=/etc/pki/tls/certs/ipa.cert.pem --external-cert-file=/etc/pki/tls/certs/ca.cert.pem > > The log file for this installation can be found in /var/log/ipaserver-install.log Directory Manager password: > > ============================================================================== > This program will set up the IPA Server. > > This includes: > * Configure a stand-alone CA (dogtag) for certificate management > * Configure the Network Time Daemon (ntpd) > * Create and configure an instance of Directory Server > * Create and configure a Kerberos Key Distribution Center (KDC) > * Configure Apache (httpd) > > ipa.ipapython.install.cli.install_tool(Server): ERROR IPA CA certificate not found in /etc/pki/tls/certs/ipa.cert.pem, /etc/pki/tls/certs/ca.cert.pem > ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information > [root at ipa certs]# From Rolf.Linder at united-security-providers.ch Tue Mar 28 09:30:39 2017 From: Rolf.Linder at united-security-providers.ch (Linder, Rolf) Date: Tue, 28 Mar 2017 09:30:39 +0000 Subject: [Freeipa-users] ipa-replica-manage failing to delete a node Message-ID: <05F6BD8355A37841B972214B1A29B52FBA9F2E5C@uspEXCH02.u-s-p.local> Hello First, we really would like to thank the developers / community for the great work doing with FreeIPA! At our company, we're using a CentOS7 based FreeIPA installation (uspidm01 primary and uspidm02 replica) and it worked like a charm the last couple of months. Last week we suffered a severe outage (DNS related) and are still suffering from this on. We have a similar issue as reported by https://bugzilla.redhat.com/show_bug.cgi?id=826677 (upstream https://pagure.io/freeipa/issue/2797) https://www.redhat.com/archives/freeipa-users/2013-May/msg00034.html https://www.redhat.com/archives/freeipa-users/2012-June/msg00382.html mainly our synchronization stopped with uspidm02 (replica) logging: "[27/Mar/2017:11:57:39.756880208 +0200] NSMMReplicationPlugin - agmt="cn=meTouspidm01.[domainname].[tld]" (uspidm01:389): Data required to update replica has been purged from the changelog. The replica must be reinitialized." We tried to re-initialize using "ipa-replica-manage re-initialize --from uspidm01.[domain].[tld]" but this failed. After this we headed for a "clean" first remove then add again solution (knowing that we will temporarily loss the replica and loss any unsynchronized changes). We followed upstream documentation from RedHat (see below) on this. Unfortunately, the "ipa-replica-manage list" command still lists both servers (uspidm01 and uspidm02). The error given by a forced removal using "ipa-replica-manage del --no-lookup --force --cleanup uspidm02.[domain].[tld]" is Cleaning a master is irreversible. This should not normally be require, so use cautiously. Continue to clean master? [no]: yes unexpected error: This entry already exists we then tried to further debug the python code used (ipa-replica-manage) and could identify using PDB that the function "replica_cleanup" from "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py" complains about duplicate entries: /usr/lib/python2.7/site-packages/ipaserver/install/replication.py(1203)replica_cleanup() -> self.conn.delete_entry(entry) (Pdb) n DuplicateEntry: Duplicat...exists',) > /usr/lib/python2.7/site-packages/ipaserver/install/replication.py(1203)replica_cleanup() -> self.conn.delete_entry(entry) (Pdb) n > /usr/lib/python2.7/site-packages/ipaserver/install/replication.py(1204)replica_cleanup() -> except errors.NotFound: (Pdb) n > /usr/lib/python2.7/site-packages/ipaserver/install/replication.py(1206)replica_cleanup() -> except Exception, e: ... Using LDAPSearch we can confirm there are still entries listed for the ghost/offline server uspidm02 (which seems the reason why ipa-replica-manage still lists it). But we cannot identify where a duplicate entry is exactly. As long as there are entries for this host, it can not be added again (a ipa-server cannot be removed using "ipa host-del" and adding a new also fails). Our situation for now is we're having a "read-only" IDM solution since any modification (password change, adding new servers, ...) fails. Adding a new replica (new name) is also failing. We suspect if we could clean up the ghost replica entry we should be able to restore IDM / replica again. Any help would be greatly appreciated!! Best regards, Rolf Documentation used: Uninstallation: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/replica-uninstall.html New installation: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html Versions in use: initially both servers were updated to ipa-server-4.4.0-14.el7.centos.6.x86_64, uspidm01 was rollbacked to ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 (eliminating any upgrade issues) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5507 bytes Desc: not available URL: From mbasti at redhat.com Tue Mar 28 10:15:45 2017 From: mbasti at redhat.com (Martin Basti) Date: Tue, 28 Mar 2017 12:15:45 +0200 Subject: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address In-Reply-To: <20170327194045.upov74ythihflwby@hendrix> References: <1957299510.33604866.1490632464222.JavaMail.zimbra@lyra-network.com> <20170327194045.upov74ythihflwby@hendrix> Message-ID: On 03/27/2017 09:40 PM, Jakub Hrozek wrote: > On Mon, Mar 27, 2017 at 06:34:24PM +0200, David Goudet wrote: >> Hi, >> >> Thanks to dyndns_update=True parameter, SSSD service on client machine updating host DNS entry in FreeIPA. >> Everything is fine on machines which have only one IP adress on network interface. >> I have problem with machines which have more that one IP address on network interface: if machine have two IP address, SSSD update host DNS entry with these two IP address. >> >> To reproduce the problem: >> Host have -IP1- and i add -IP2- >> ip addr add -IP2-/26 dev em1 >> >> ip addr list: >> em1: mtu 1496 qdisc mq state UP qlen 1000 >> link/ether xxxx >> inet -IP1-/26 brd XXXX scope global em1 >> inet -IP2-/26 scope global secondary em1 >> valid_lft forever preferred_lft forever >> >> DNS resolution (dig) before restarting sssd returns only -IP1-. After restarting sssd returns -IP1- & -IP2- >> >> In dyndns_update manpage, we have "The IP address of the IPA LDAP connection is used for the updates", what does it means? Is it IP address of the DNS server (used to update the DNS entry)? or is it IP address on client machine used during LDAP TCP bind (-IP1- in my case)? >> >> dyndns_update (boolean) >> Optional. This option tells SSSD to automatically update the DNS server built into FreeIPA v2 with the IP address of this client. >> The update is secured using GSS-TSIG. The IP address of the IPA LDAP connection is used for the updates, if it is not otherwise >> specified by using the ?dyndns_iface? option. >> >> Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on client machine? IIRC we added this to support multiple interfaces (user can choose which one to use) and to update both IPv6 (AAAA) and IPv4 (A) records. IPA/SSSD cannot reliably determine which IP address to use, it is all or none from interface. With the previous behavior users want to use different/more addresses than the one which has been detected from LDAP connection and it was not possible previously. Do you have set dyndns_iface in sssd.conf? Martin > Looks like this was a deliberate change: > https://pagure.io/SSSD/sssd/issue/2558 > but to be honest, I forgot why exactly we did this. Martin, do you know? > >> Is it possible to configure SSSD to update DNS with only IP address "primary" in ip addr list or which is used to FreeIPA server communication (-IP1- used on TCP binding)? > Only if the IP addresses are of different families (v4/v6), then it's > possible to restrict one of the families. From bret.wortman at damascusgrp.com Tue Mar 28 12:45:29 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 28 Mar 2017 08:45:29 -0400 Subject: [Freeipa-users] Migrate IPA cluster F21 -> C7 Message-ID: I'm studying the best way to migrate out IPA servers (there are two) from F21 to C7. I _think_ the sequence of steps I need to perform is: 1. Build new C7 IPA server (ipa-c) and enable replication to it. 2. Migrate CA functions from our existing CA server (ipa-a) to this new one (ipa-c). 3. Upgrade ipa-b to C7 and enable replication to it. 4. Either upgrade ipa-a and have a third ipa server or discard the vm in favor of the two now in service. Am I missing anything? Making this harder than it needs to be? Our F21 servers are using IPA 4.1.4-1 (and pki-ca 10.2.1-3) so I'm not if replication across versions is supported between these and IPA 4.4.0 (pki-ca 10.3.3). -- *Bret Wortman* Damascus Products ph/fax: 1-855-644-2783 Wrap Buddies InDemand at http://bwortman.us/2ieQN4t -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Mar 28 13:15:39 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 28 Mar 2017 09:15:39 -0400 Subject: [Freeipa-users] Migrate IPA cluster F21 -> C7 In-Reply-To: References: Message-ID: <29d717e8-dee1-47a2-96ff-dde6727ba0a3@redhat.com> Bret Wortman wrote: > I'm studying the best way to migrate out IPA servers (there are two) > from F21 to C7. I _think_ the sequence of steps I need to perform is: > > 1. Build new C7 IPA server (ipa-c) and enable replication to it. > 2. Migrate CA functions from our existing CA server (ipa-a) to this > new one (ipa-c). > 3. Upgrade ipa-b to C7 and enable replication to it. > 4. Either upgrade ipa-a and have a third ipa server or discard the > vm in favor of the two now in service. > > Am I missing anything? Making this harder than it needs to be? > > Our F21 servers are using IPA 4.1.4-1 (and pki-ca 10.2.1-3) so I'm not > if replication across versions is supported between these and IPA 4.4.0 > (pki-ca 10.3.3). This looks fine. I'd ensure there are at least 2 IPA Masters installed with a CA in order to avoid a single point of failure. rob From jochen at jochen.org Tue Mar 28 16:13:02 2017 From: jochen at jochen.org (Jochen Hein) Date: Tue, 28 Mar 2017 18:13:02 +0200 Subject: [Freeipa-users] ipa-replica-manage failing to delete a node In-Reply-To: <05F6BD8355A37841B972214B1A29B52FBA9F2E5C@uspEXCH02.u-s-p.local> (Rolf Linder's message of "Tue, 28 Mar 2017 09:30:39 +0000") References: <05F6BD8355A37841B972214B1A29B52FBA9F2E5C@uspEXCH02.u-s-p.local> Message-ID: <838tnptm5t.fsf@jochen.org> "Linder, Rolf" writes: > mainly our synchronization stopped with uspidm02 (replica) logging: > > "[27/Mar/2017:11:57:39.756880208 +0200] NSMMReplicationPlugin - > agmt="cn=meTouspidm01.[domainname].[tld]" (uspidm01:389): Data > required to update replica has been purged from the changelog. The > replica must be reinitialized." > > We tried to re-initialize using "ipa-replica-manage re-initialize > --from uspidm01.[domain].[tld]" but this failed. After this we headed > for a "clean" first remove then add again solution (knowing that we > will temporarily loss the replica and loss any unsynchronized > changes). I had these messages too, and also failed to get it running with ipa-replicate-manage. But later I realiazed that the failing replica was a CA replica, and using ipa-careplica-manage I could reinitialize the replica. I found it also mildly confusing, which server was ok and which server needed the replica reinitialized. Could we add a hint to the log what the admin needs to do? Something like: ,---- | Data required to update replica has been purged from the | changelog. The replica must be reinitialized. | Use "ipa-(ca)?replica-manage ... --from " on "". `---- Jochen -- This space is intentionally left blank. From jason at tresgeek.net Tue Mar 28 16:59:27 2017 From: jason at tresgeek.net (Jason B. Nance) Date: Tue, 28 Mar 2017 11:59:27 -0500 (CDT) Subject: [Freeipa-users] Trying To Debug AD Trust Quirks Message-ID: <1990909073.2684.1490720367196.JavaMail.zimbra@tresgeek.net> Hello, I'm using AD trusts with FreeIPA 4.4.0 and am having a heck of a time with strange behavior. Some examples include: - Trust user's home directory sporadically getting set to '/' instead of /home/domain/user - Trust user losing HBAC privileges (granted via group membership) - Trust user losing sudo privileges (granted via group membership) - OS logging that trust user's account has expired when it hasn't I'm currently unable to predict/reproduce occurrences of these issues. I can say that they aren't tied to a specific user or host. For example, a user will login to a host without any issues and then later that same user's home directory (as reported by getent) will suddenly be set to / instead of /home/... My first step, of course, is to gather logs. Should I be focusing on the SSSD on the client or on the IPA servers? I'm not entirely clear how/where lots of this data get assigned/queried. My other question is if there is a way to pin down a client to [temporarily] use a specific IPA server and specific AD server (even if it means a firewall rule that only allows the host to communicate with one IPA and one AD host). Thanks, j From iulian.roman at gmail.com Tue Mar 28 21:09:49 2017 From: iulian.roman at gmail.com (Iulian Roman) Date: Tue, 28 Mar 2017 23:09:49 +0200 Subject: [Freeipa-users] staging area and group membership Message-ID: Hello, Is it possible to directly add a user to certain groups when the user is defined in staging area ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcnt at use.startmail.com Tue Mar 28 23:48:08 2017 From: jcnt at use.startmail.com (Josh) Date: Tue, 28 Mar 2017 19:48:08 -0400 Subject: [Freeipa-users] 389-console and IPA Message-ID: Greetings, I wonder if possible to use 389-console with default IPA installation on REHL 7. Primarily reason is to alter log settings https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Configuring_Logs.html#Viewing_and_Configuring_Log_Files-Defining_a_Log_File_Rotation_Policy without using command line tools https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnconfig-nsslapd_accesslog_maxlogsize_Access_Log_Maximum_Log_Size Regards, Josh. From barrykfl at gmail.com Wed Mar 29 02:43:06 2017 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 29 Mar 2017 10:43:06 +0800 Subject: [Freeipa-users] MAKE Freeipa replica not work now Message-ID: Hi all: 9444 port can be telnet ...Any idea ? the log show below as I don't have more idea... If I plan to migrate to same version of server what I have to copy ? as I saw step of migration also similar to replica so now stuck on the steps. Any Manual copy steps ? as I copy and paste the LDAP of ABC.com and slapd_PKI ..It cannot start up ...can I just move slapd_ABC.com 's ldif other ignored ? many thks Preparing replica for central.ABC.com from central.wisers.com Creating SSL certificate for the Directory Server preparation of replica failed: cannot connect to ' https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': (PR_END_OF_FILE_ERROR) Encountered end of file. cannot connect to ' https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': (PR_END_OF_FILE_ERROR) Encountered end of file. File "/usr/sbin/ipa-replica-prepare", line 490, in main() File "/usr/sbin/ipa-replica-prepare", line 361, in main export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", replica_fqdn, subject_base) File "/usr/sbin/ipa-replica-prepare", line 150, in export_certdb raise e -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Mar 29 07:41:52 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 29 Mar 2017 09:41:52 +0200 Subject: [Freeipa-users] Trying To Debug AD Trust Quirks In-Reply-To: <1990909073.2684.1490720367196.JavaMail.zimbra@tresgeek.net> References: <1990909073.2684.1490720367196.JavaMail.zimbra@tresgeek.net> Message-ID: <20170329074152.ms3fhzu5mudficgn@hendrix> On Tue, Mar 28, 2017 at 11:59:27AM -0500, Jason B. Nance wrote: > Hello, > > I'm using AD trusts with FreeIPA 4.4.0 and am having a heck of a time with strange behavior. Some examples include: > > - Trust user's home directory sporadically getting set to '/' instead of /home/domain/user > - Trust user losing HBAC privileges (granted via group membership) > - Trust user losing sudo privileges (granted via group membership) > - OS logging that trust user's account has expired when it hasn't > > I'm currently unable to predict/reproduce occurrences of these issues. I can say that they aren't tied to a specific user or host. For example, a user will login to a host without any issues and then later that same user's home directory (as reported by getent) will suddenly be set to / instead of /home/... > > My first step, of course, is to gather logs. Should I be focusing on the SSSD on the client or on the IPA servers? I'm not entirely clear how/where lots of this data get assigned/queried. > > My other question is if there is a way to pin down a client to [temporarily] use a specific IPA server and specific AD server (even if it means a firewall rule that only allows the host to communicate with one IPA and one AD host). Normally time-correlated logs from both the server's domain and nss sections of sssd.conf and the client's domain section are a good start. From jhrozek at redhat.com Wed Mar 29 07:45:12 2017 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 29 Mar 2017 09:45:12 +0200 Subject: [Freeipa-users] Trying To Debug AD Trust Quirks In-Reply-To: <1990909073.2684.1490720367196.JavaMail.zimbra@tresgeek.net> References: <1990909073.2684.1490720367196.JavaMail.zimbra@tresgeek.net> Message-ID: <20170329074512.cpuchwlidmh2usqu@hendrix> On Tue, Mar 28, 2017 at 11:59:27AM -0500, Jason B. Nance wrote: > My other question is if there is a way to pin down a client to > [temporarily] use a specific IPA server using the ipa_server directive in sssd.conf > and specific AD server (even if > it means a firewall rule that only allows the host to communicate with > one IPA and one AD host). the clients don't talk to ADs to resolve user information, only the servers do. The clients only talk to AD DCs for authentication (to make this a bit more complex, the authentication also involves parsing a Kerberos PAC blob by the authentication helper in SSSD which also includes the group memberships). And unfortunately until RHEL-7.4 and SSSD 1.15 are out, then pinning the SSSD on the IDM servers to a specific AD DC is only possible by modifying the DNS SRV records or creating an AD site for the IDM server. From ronaldw at ronzo.at Wed Mar 29 08:42:28 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Wed, 29 Mar 2017 10:42:28 +0200 Subject: [Freeipa-users] Register IPA-Clients within AD domain Message-ID: <51e8333e-37f3-9b91-f8db-344e60a180bc@ronzo.at> Hi, the documentation states "[...] Client machines do not need to be in the same domain as FreeIPA servers. For example, FreeIPA may be a domain ipa.example.com and clients in domain clients.example.com, there just need to be a clear mapping between DNS domain and Kerberos realm. [...]" Can clients be registered properly if the clients.example.com domain is an existing Active Directory domain which - of course - already has _kerberos entries in DNS? Regards, Ronald From ronaldw at ronzo.at Wed Mar 29 08:47:01 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Wed, 29 Mar 2017 10:47:01 +0200 Subject: [Freeipa-users] SSSD setting memcache_timeout on ipa master Message-ID: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> Hi, yesterday I suddenly was unable to use the webinterface of my ipa master. SSH login (with root user) did not work also. When I uncommented the setting "memcache_timeout = 600" in the sssd config file of the master everything seemed to work fine again. (my ipa setup has a trust to AD) Can anybody explain why this was happening? Regards, Ronald From abokovoy at redhat.com Wed Mar 29 09:06:56 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 29 Mar 2017 12:06:56 +0300 Subject: [Freeipa-users] Register IPA-Clients within AD domain In-Reply-To: <51e8333e-37f3-9b91-f8db-344e60a180bc@ronzo.at> References: <51e8333e-37f3-9b91-f8db-344e60a180bc@ronzo.at> Message-ID: <20170329090656.cwhpcpp6olq3i4it@redhat.com> On ke, 29 maalis 2017, Ronald Wimmer wrote: >Hi, > >the documentation states "[...] Client machines do not need to be in >the same domain as FreeIPA servers. For example, FreeIPA may be a >domain ipa.example.com and clients in domain clients.example.com, >there just need to be a clear mapping between DNS domain and Kerberos >realm. [...]" > >Can clients be registered properly if the clients.example.com domain >is an existing Active Directory domain which - of course - already has >_kerberos entries in DNS? Read http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain There are also higher level description at http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/ -- / Alexander Bokovoy From ronaldw at ronzo.at Wed Mar 29 09:28:53 2017 From: ronaldw at ronzo.at (Ronald Wimmer) Date: Wed, 29 Mar 2017 11:28:53 +0200 Subject: [Freeipa-users] Register IPA-Clients within AD domain In-Reply-To: <20170329090656.cwhpcpp6olq3i4it@redhat.com> References: <51e8333e-37f3-9b91-f8db-344e60a180bc@ronzo.at> <20170329090656.cwhpcpp6olq3i4it@redhat.com> Message-ID: <21e77ebd-0d34-0f65-3744-b08f30e59ff6@ronzo.at> On 2017-03-29 11:06, Alexander Bokovoy wrote: > On ke, 29 maalis 2017, Ronald Wimmer wrote: >> [...] > Read > http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain > There are also higher level description at > http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/ Thanks a lot! From bret.wortman at damascusgrp.com Wed Mar 29 10:22:04 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 29 Mar 2017 06:22:04 -0400 Subject: [Freeipa-users] Migrate IPA cluster F21 -> C7 In-Reply-To: References: Message-ID: <87bb7f8e-efab-040b-ee78-e8f049d2ba1a@damascusgrp.com> I've tried googling but keep coming up with beer recipes. How do you suggest adding the replica CA? I'm piecing together the options I want on my ipa-server-install command and am trying to understand the CA-related options. Thanks! Bret On 03/28/2017 08:45 AM, Bret Wortman wrote: > I'm studying the best way to migrate out IPA servers (there are two) > from F21 to C7. I _think_ the sequence of steps I need to perform is: > > 1. Build new C7 IPA server (ipa-c) and enable replication to it. > 2. Migrate CA functions from our existing CA server (ipa-a) to > this new one (ipa-c). > 3. Upgrade ipa-b to C7 and enable replication to it. > 4. Either upgrade ipa-a and have a third ipa server or discard the > vm in favor of the two now in service. > > Am I missing anything? Making this harder than it needs to be? > > Our F21 servers are using IPA 4.1.4-1 (and pki-ca 10.2.1-3) so I'm not > if replication across versions is supported between these and IPA > 4.4.0 (pki-ca 10.3.3). > > > -- > *Bret Wortman* > Damascus Products > ph/fax: 1-855-644-2783 > Wrap Buddies InDemand at http://bwortman.us/2ieQN4t -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Wed Mar 29 11:39:54 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 29 Mar 2017 07:39:54 -0400 Subject: [Freeipa-users] Migrate IPA cluster F21 -> C7 In-Reply-To: <87bb7f8e-efab-040b-ee78-e8f049d2ba1a@damascusgrp.com> References: <87bb7f8e-efab-040b-ee78-e8f049d2ba1a@damascusgrp.com> Message-ID: <72a822dc-1eb4-de8f-332a-347a333110fa@damascusgrp.com> Never mind. Lost my mind. ipa-replica-install followed by ipa-ca-install appears to be the ticket. Bret On 03/29/2017 06:22 AM, Bret Wortman wrote: > > I've tried googling but keep coming up with beer recipes. > > How do you suggest adding the replica CA? I'm piecing together the > options I want on my ipa-server-install command and am trying to > understand the CA-related options. > > Thanks! > > > Bret > > > > On 03/28/2017 08:45 AM, Bret Wortman wrote: >> I'm studying the best way to migrate out IPA servers (there are two) >> from F21 to C7. I _think_ the sequence of steps I need to perform is: >> >> 1. Build new C7 IPA server (ipa-c) and enable replication to it. >> 2. Migrate CA functions from our existing CA server (ipa-a) to >> this new one (ipa-c). >> 3. Upgrade ipa-b to C7 and enable replication to it. >> 4. Either upgrade ipa-a and have a third ipa server or discard >> the vm in favor of the two now in service. >> >> Am I missing anything? Making this harder than it needs to be? >> >> Our F21 servers are using IPA 4.1.4-1 (and pki-ca 10.2.1-3) so I'm >> not if replication across versions is supported between these and IPA >> 4.4.0 (pki-ca 10.3.3). >> >> >> -- >> *Bret Wortman* >> Damascus Products >> ph/fax: 1-855-644-2783 >> Wrap Buddies InDemand at >> http://bwortman.us/2ieQN4t > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.klima at vig.cz Wed Mar 29 12:02:42 2017 From: david.klima at vig.cz (=?iso-8859-1?Q?Kl=EDma_David?=) Date: Wed, 29 Mar 2017 12:02:42 +0000 Subject: [Freeipa-users] Extending FreeIPA with custom atribute (ipa-server-4.4.0) Message-ID: Hi, can anybody help me with extending the FreeIPA Server? I have few custom attributes in DS schema. I would like to be able to change the new attributes added via the JSON API and thus via the CLI tool. Today I updated from version ipa-server-4.2.0 to ipa-server-4.4.0 from standart RHEL repo and I see plugin directory is on another location /usr/lib/python2.7/site-packages/ipaclient/plugins (old location was in version 4.2.0 /usr/lib/python2.7/site-packages/ipalib/plugins/) and my old CLI extension stopped working with this error message: ipa: ERROR: ImportError: No module named plugins There is no documentation about that, or some examples. Can you anybody help me rewrite this simple code to working with new API version? from ipalib.plugins import user from ipalib.parameters import Int from ipalib.parameters import Str from ipalib import _ user.user.takes_params = user.user.takes_params + ( Str('mailroutingaddress?', cli_name='mailroutingaddress', label=_('Mail routing address'), ), ) [root at ipa-03 plugins]# rpm -qa | grep ipa-server ipa-server-4.4.0-12.el7.x86_64 ipa-server-common-4.4.0-12.el7.noarch ipa-server-dns-4.4.0-12.el7.noarch https://serverfault.com/questions/809810/minimal-example-of-extending-already-existing-api-and-cli-call-in-freeipa-4 Thank you a lot! David From rcritten at redhat.com Wed Mar 29 13:53:25 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Mar 2017 09:53:25 -0400 Subject: [Freeipa-users] Migrate IPA cluster F21 -> C7 In-Reply-To: <72a822dc-1eb4-de8f-332a-347a333110fa@damascusgrp.com> References: <87bb7f8e-efab-040b-ee78-e8f049d2ba1a@damascusgrp.com> <72a822dc-1eb4-de8f-332a-347a333110fa@damascusgrp.com> Message-ID: <324cc0fb-011c-30be-a425-07937135d80f@redhat.com> Bret Wortman wrote: > Never mind. Lost my mind. > > ipa-replica-install followed by ipa-ca-install appears to be the ticket. Or you can do it in one step by passing --setup-ca to ipa-replica-install rob > > > Bret > > > On 03/29/2017 06:22 AM, Bret Wortman wrote: >> >> I've tried googling but keep coming up with beer recipes. >> >> How do you suggest adding the replica CA? I'm piecing together the >> options I want on my ipa-server-install command and am trying to >> understand the CA-related options. >> >> Thanks! >> >> >> Bret >> >> >> >> On 03/28/2017 08:45 AM, Bret Wortman wrote: >>> I'm studying the best way to migrate out IPA servers (there are two) >>> from F21 to C7. I _think_ the sequence of steps I need to perform is: >>> >>> 1. Build new C7 IPA server (ipa-c) and enable replication to it. >>> 2. Migrate CA functions from our existing CA server (ipa-a) to >>> this new one (ipa-c). >>> 3. Upgrade ipa-b to C7 and enable replication to it. >>> 4. Either upgrade ipa-a and have a third ipa server or discard >>> the vm in favor of the two now in service. >>> >>> Am I missing anything? Making this harder than it needs to be? >>> >>> Our F21 servers are using IPA 4.1.4-1 (and pki-ca 10.2.1-3) so I'm >>> not if replication across versions is supported between these and IPA >>> 4.4.0 (pki-ca 10.3.3). >>> >>> >>> -- >>> *Bret Wortman* >>> Damascus Products >>> ph/fax: 1-855-644-2783 >>> Wrap Buddies InDemand at >>> http://bwortman.us/2ieQN4t >> > > > From bret.wortman at damascusgrp.com Wed Mar 29 13:55:28 2017 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 29 Mar 2017 09:55:28 -0400 Subject: [Freeipa-users] Migrate IPA cluster F21 -> C7 In-Reply-To: <324cc0fb-011c-30be-a425-07937135d80f@redhat.com> References: <87bb7f8e-efab-040b-ee78-e8f049d2ba1a@damascusgrp.com> <72a822dc-1eb4-de8f-332a-347a333110fa@damascusgrp.com> <324cc0fb-011c-30be-a425-07937135d80f@redhat.com> Message-ID: <692b1c2c-b4a6-57b6-40a2-79a3fd4522d6@damascusgrp.com> I saw as I was working through it, and it's in fact what I did. Migrating the last server to CentOS right now. Thanks for the help! On 03/29/2017 09:53 AM, Rob Crittenden wrote: > Bret Wortman wrote: >> Never mind. Lost my mind. >> >> ipa-replica-install followed by ipa-ca-install appears to be the ticket. > Or you can do it in one step by passing --setup-ca to ipa-replica-install > > rob > >> >> Bret >> >> >> On 03/29/2017 06:22 AM, Bret Wortman wrote: >>> I've tried googling but keep coming up with beer recipes. >>> >>> How do you suggest adding the replica CA? I'm piecing together the >>> options I want on my ipa-server-install command and am trying to >>> understand the CA-related options. >>> >>> Thanks! >>> >>> >>> Bret >>> >>> >>> >>> On 03/28/2017 08:45 AM, Bret Wortman wrote: >>>> I'm studying the best way to migrate out IPA servers (there are two) >>>> from F21 to C7. I _think_ the sequence of steps I need to perform is: >>>> >>>> 1. Build new C7 IPA server (ipa-c) and enable replication to it. >>>> 2. Migrate CA functions from our existing CA server (ipa-a) to >>>> this new one (ipa-c). >>>> 3. Upgrade ipa-b to C7 and enable replication to it. >>>> 4. Either upgrade ipa-a and have a third ipa server or discard >>>> the vm in favor of the two now in service. >>>> >>>> Am I missing anything? Making this harder than it needs to be? >>>> >>>> Our F21 servers are using IPA 4.1.4-1 (and pki-ca 10.2.1-3) so I'm >>>> not if replication across versions is supported between these and IPA >>>> 4.4.0 (pki-ca 10.3.3). >>>> >>>> >>>> -- >>>> *Bret Wortman* >>>> Damascus Products >>>> ph/fax: 1-855-644-2783 >>>> Wrap Buddies InDemand at >>>> http://bwortman.us/2ieQN4t >> >> From Rolf.Linder at united-security-providers.ch Wed Mar 29 14:19:59 2017 From: Rolf.Linder at united-security-providers.ch (Linder, Rolf) Date: Wed, 29 Mar 2017 14:19:59 +0000 Subject: [Freeipa-users] ipa-replica-manage failing to delete a node In-Reply-To: <838tnptm5t.fsf@jochen.org> References: <05F6BD8355A37841B972214B1A29B52FBA9F2E5C@uspEXCH02.u-s-p.local> <838tnptm5t.fsf@jochen.org> Message-ID: <05F6BD8355A37841B972214B1A29B52FBA9F3ED8@uspEXCH02.u-s-p.local> Thanks jochen for your response! So far, we could quite well identify whos the master and the replica and identify how and where we should re-initialize. Still there is good news at our side, we could further identify an issue and by fixing that (see below) also remove the replica and reinstall it. We had to "isolate" the second server (it was still reachable by ICMP ping) and were then able to just execute "ipa-replica-manage del uspidm02.[domain].[tld] --force --cleanup" and afterwards add it again. After a small duplicate RUV issue (documented at https://access.redhat.com/solutions/2741521) we're now up again and have a running IdM setup. Still, at our end there's one question left: for now, we have different passwords for the "admin" user and the directory manager password. Is this normal? Or do we have a broken setup now? Best regards, Rolf Ps: here's what we did to fix our issue: 1. copied uspidm01 and run isolated (offline) tests => we could identify this way all is well 2. after already doing reboots on uspidm02 disconnected that server and removed it on uspidm01 via ipa-replica-manage 3. by this identified an error in hosts entry of uspidm01 (listing uspidm02 with a wrong ip conflicting DNS information) 4. reinstalled uspidm02 according documentation from redhat -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5507 bytes Desc: not available URL: From mareynol at redhat.com Wed Mar 29 14:30:37 2017 From: mareynol at redhat.com (Mark Reynolds) Date: Wed, 29 Mar 2017 10:30:37 -0400 Subject: [Freeipa-users] 389-console and IPA In-Reply-To: References: Message-ID: <3cb3e29e-88a9-861f-c386-3861f8f92e91@redhat.com> On 03/28/2017 07:48 PM, Josh wrote: > Greetings, > > I wonder if possible to use 389-console with default IPA installation > on REHL 7. This should be technically possible, but it has its risks... You would need to install the 389-admin/console packages, then you would have to register your DS instance using register-ds-admin.pl - which adds the "o=netscaperoot" suffix/backend to the server. This backend is what the console uses to render the UI. I've never tried this with IPA before, and it would have other implications. You'd have to exclude the o=netscaperoot suffix from the retro changelog, and possibly other plugin adjustments as well. Sorry I don't know IPA that well, so perhaps others on this list could comment on other pitfalls you might run into with the added backend. > > Primarily reason is to alter log settings Really this isn't that hard from the CLI perspective. You could write a simple shell script for changing log levels - I could help you with that if need be. Mark > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Configuring_Logs.html#Viewing_and_Configuring_Log_Files-Defining_a_Log_File_Rotation_Policy > > > without using command line tools > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnconfig-nsslapd_accesslog_maxlogsize_Access_Log_Maximum_Log_Size > > > Regards, > Josh. > From rcritten at redhat.com Wed Mar 29 17:39:20 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 29 Mar 2017 13:39:20 -0400 Subject: [Freeipa-users] MAKE Freeipa replica not work now In-Reply-To: References: Message-ID: <14e60b50-126b-edd0-970f-3e05ebe8a66b@redhat.com> barrykfl at gmail.com wrote: > Hi all: > > 9444 port can be telnet ...Any idea ? the log show below as I don't have > more idea... If I plan to > migrate to same version of server what I have to copy ? as I saw > step of migration also similar to replica so now stuck on the steps. > Any Manual copy steps ? as I copy and paste the LDAP of ABC.com > and slapd_PKI ..It cannot start up ...can I just move slapd_ABC.com > 's ldif other ignored ? many thks I'm not quite sure I follow. It seems there is a bit of history we're missing here. What is it you're trying to do? It sounds like more than just stand up another master. > Preparing replica for central.ABC.com from > central.wisers.com > Creating SSL certificate for the Directory Server > preparation of replica failed: cannot connect to > 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': > (PR_END_OF_FILE_ERROR) Encountered end of file. > cannot connect to > 'https://central.ABC.com:9444/ca/ee/ca/profileSubmitSSLClient': > (PR_END_OF_FILE_ERROR) Encountered end of file. > File "/usr/sbin/ipa-replica-prepare", line 490, in > main() > > File "/usr/sbin/ipa-replica-prepare", line 361, in main > export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", > replica_fqdn, subject_base) > > File "/usr/sbin/ipa-replica-prepare", line 150, in export_certdb > raise e What version of IPA? You'll want to check the dogtag logs for more details, the location depends on the version. rob From jcnt at use.startmail.com Wed Mar 29 18:05:57 2017 From: jcnt at use.startmail.com (Josh) Date: Wed, 29 Mar 2017 14:05:57 -0400 Subject: [Freeipa-users] 389-console and IPA In-Reply-To: <3cb3e29e-88a9-861f-c386-3861f8f92e91@redhat.com> References: <3cb3e29e-88a9-861f-c386-3861f8f92e91@redhat.com> Message-ID: <25db9b7c-bd7a-3081-efec-7e155b9a31b7@use.startmail.com> Hi Mark, Thanks for responding. Essentially I would like to change access log file size from 100Meg to 10Meg and change number of log files down to 5 for example. Regards, Josh. On 03/29/2017 10:30 AM, Mark Reynolds wrote: > > On 03/28/2017 07:48 PM, Josh wrote: >> Greetings, >> >> I wonder if possible to use 389-console with default IPA installation >> on REHL 7. > This should be technically possible, but it has its risks... You would > need to install the 389-admin/console packages, then you would have to > register your DS instance using register-ds-admin.pl - which adds the > "o=netscaperoot" suffix/backend to the server. This backend is what the > console uses to render the UI. > > I've never tried this with IPA before, and it would have other > implications. You'd have to exclude the o=netscaperoot suffix from the > retro changelog, and possibly other plugin adjustments as well. Sorry I > don't know IPA that well, so perhaps others on this list could comment > on other pitfalls you might run into with the added backend. >> Primarily reason is to alter log settings > Really this isn't that hard from the CLI perspective. You could write > a simple shell script for changing log levels - I could help you with > that if need be. > > Mark >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Configuring_Logs.html#Viewing_and_Configuring_Log_Files-Defining_a_Log_File_Rotation_Policy >> >> >> without using command line tools >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnconfig-nsslapd_accesslog_maxlogsize_Access_Log_Maximum_Log_Size >> >> >> Regards, >> Josh. >> From mareynol at redhat.com Wed Mar 29 20:55:12 2017 From: mareynol at redhat.com (Mark Reynolds) Date: Wed, 29 Mar 2017 16:55:12 -0400 Subject: [Freeipa-users] 389-console and IPA In-Reply-To: <25db9b7c-bd7a-3081-efec-7e155b9a31b7@use.startmail.com> References: <3cb3e29e-88a9-861f-c386-3861f8f92e91@redhat.com> <25db9b7c-bd7a-3081-efec-7e155b9a31b7@use.startmail.com> Message-ID: <31058ab2-4981-7fba-bbf4-7be71a80d9d2@redhat.com> On 03/29/2017 02:05 PM, Josh wrote: > Hi Mark, > > Thanks for responding. > > Essentially I would like to change access log file size from 100Meg to > 10Meg and change number of log files down to 5 for example. All you need to do is something like: ldapmodify -p PORT -h HOST - D "cn=directory manager" -w PASSWORD dn: cn=config changetype: modify replace: ATTR ATTR: NEWVALUE Example ldapmodify -p 389 -h localhost - D "cn=directory manager" -w SECRET123 dn: cn=config changetype: modify replace: nsslapd-accesslog-maxlogsize nsslapd-accesslog-maxlogsize: 10 Here are the attributes in question you are probably interested in: nsslapd-accesslog-maxlogsize nsslapd-accesslog-maxlogsperdir nsslapd-errorlog-level See this link for the log levels: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/error-logs.html#error-logs-levels HTH, Mark > > Regards, > Josh. > > On 03/29/2017 10:30 AM, Mark Reynolds wrote: >> >> On 03/28/2017 07:48 PM, Josh wrote: >>> Greetings, >>> >>> I wonder if possible to use 389-console with default IPA installation >>> on REHL 7. >> This should be technically possible, but it has its risks... You would >> need to install the 389-admin/console packages, then you would have to >> register your DS instance using register-ds-admin.pl - which adds the >> "o=netscaperoot" suffix/backend to the server. This backend is what the >> console uses to render the UI. >> >> I've never tried this with IPA before, and it would have other >> implications. You'd have to exclude the o=netscaperoot suffix from the >> retro changelog, and possibly other plugin adjustments as well. Sorry I >> don't know IPA that well, so perhaps others on this list could comment >> on other pitfalls you might run into with the added backend. >>> Primarily reason is to alter log settings >> Really this isn't that hard from the CLI perspective. You could write >> a simple shell script for changing log levels - I could help you with >> that if need be. >> >> Mark >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Configuring_Logs.html#Viewing_and_Configuring_Log_Files-Defining_a_Log_File_Rotation_Policy >>> >>> >>> >>> without using command line tools >>> >>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnconfig-nsslapd_accesslog_maxlogsize_Access_Log_Maximum_Log_Size >>> >>> >>> >>> Regards, >>> Josh. >>> > From cherdt at umn.edu Wed Mar 29 21:58:53 2017 From: cherdt at umn.edu (Chris Herdt) Date: Wed, 29 Mar 2017 16:58:53 -0500 Subject: [Freeipa-users] Why is port 80 needed for replication? Message-ID: I'm curious as to why HTTP (port 80) is needed for IPA server replication, particularly since HTTPS (port 443) is also used. What unencrypted data is exchanged? Chris From abokovoy at redhat.com Thu Mar 30 06:25:15 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 30 Mar 2017 09:25:15 +0300 Subject: [Freeipa-users] Why is port 80 needed for replication? In-Reply-To: References: Message-ID: <20170330062515.vhz7qhgnbcqkhofb@redhat.com> On ke, 29 maalis 2017, Chris Herdt wrote: >I'm curious as to why HTTP (port 80) is needed for IPA server >replication, particularly since HTTPS (port 443) is also used. What >unencrypted data is exchanged? Because you need to access OCSP endpoint without going into chicken and egg problem of trusting or not a certificate: # openssl x509 -in /etc/ipa/ca.crt -noout -ocsp_uri http://ipa-ca.example.com/ca/ocsp See https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol -- / Alexander Bokovoy From lslebodn at redhat.com Fri Mar 31 11:35:22 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 31 Mar 2017 13:35:22 +0200 Subject: [Freeipa-users] SSSD setting memcache_timeout on ipa master In-Reply-To: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> References: <43e1449a-0746-29a8-f6b2-4044185b9ac5@ronzo.at> Message-ID: <20170331113521.GH10135@10.4.128.1> On (29/03/17 10:47), Ronald Wimmer wrote: >Hi, > >yesterday I suddenly was unable to use the webinterface of my ipa master. SSH >login (with root user) did not work also. > >When I uncommented the setting "memcache_timeout = 600" in the sssd config >file of the master everything seemed to work fine again. (my ipa setup has a >trust to AD) > I doubt it had anything to do memcache_timeout. I would say that restart of sssd helped. But it difficult to say without log files. either sssd logs or at least /var/log/secure (journald for pam). LS From lslebodn at redhat.com Fri Mar 31 14:38:51 2017 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 31 Mar 2017 16:38:51 +0200 Subject: [Freeipa-users] 389-console and IPA In-Reply-To: <25db9b7c-bd7a-3081-efec-7e155b9a31b7@use.startmail.com> References: <3cb3e29e-88a9-861f-c386-3861f8f92e91@redhat.com> <25db9b7c-bd7a-3081-efec-7e155b9a31b7@use.startmail.com> Message-ID: <20170331143850.GN10135@10.4.128.1> On (29/03/17 14:05), Josh wrote: >Hi Mark, > >Thanks for responding. > >Essentially I would like to change access log file size from 100Meg to 10Meg >and change number of log files down to 5 for example. > If you are a vi-user then you can try to use ldapvi. It can even shouw you ldif which can be used with ldapmodify. LS From terencekent at gmail.com Fri Mar 31 16:30:35 2017 From: terencekent at gmail.com (Terence Kent) Date: Fri, 31 Mar 2017 09:30:35 -0700 Subject: [Freeipa-users] First-class support for the docker image In-Reply-To: <5ca7d62a-d49c-aca4-52f0-db299fef5578@redhat.com> References: <4389a74e-eac2-abed-e531-b07f0680cb3a@gmail.com> <5ca7d62a-d49c-aca4-52f0-db299fef5578@redhat.com> Message-ID: Martin, Thanks for the response! I'm glad to hear that it's just a time/resource issue, not that you wanted to keep the container work separate for some reason. If we can find time, I'll see we can have some our folks help out on the efforts! Best, Terence P.S. Maybe someday FreeIPA can be reduced to a set of connected containers for the various services, and just orchestration script for management. How clean would that be! On Mon, Mar 27, 2017 at 3:23 AM, Martin Basti wrote: > > > On 03/25/2017 12:55 AM, Terence Kent wrote: > >> Hello, >> >> We've been using the FreeIPA docker image for a few years now with great >> success. I really can't overstate how much we get by using a container >> deployment for FreeIPA. We can now easily test anything from version >> upgrades to orchestration code against either test data and our production >> data set. That, and we get all the typical docker goodness (we can easily >> move the container between hosts, change the underlying OS independently, >> etc, etc). >> >> That said, lots of the work in the freeipa docker image's gitrepo are >> things that seem like they belong in the freeipa main codebase. We've had >> to trace through the freeipa-container source from time to time to diagnose >> issues and we see situations where the docker build file actually modifies >> python code using text replaces. >> >> This seems both easily breakable and like a lot more work than just >> modifying the source file to optionally support whatever a containerized >> environment needs. Is there a reason to keep container support out of the >> main freeipa project? >> >> Best, >> Terence >> >> > > Hello, > > we have plans to update FreeIPA codebase to avoid hacks in Docker, but we > had more prioritized tasks to do. However we are looking forward to > merging community patches to have synchronized FreeIPA code base and > containerized FreeIPA > > It was separated due rapid FreeIPA container development to make it > possible to work ASAP without waiting for FreeIPA core. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Fri Mar 31 22:07:16 2017 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 31 Mar 2017 16:07:16 -0600 Subject: [Freeipa-users] ipa_add_ad_memberships_get_next errors Message-ID: <6fe285ba-12e7-f677-0447-92a92b2a7aa4@cora.nwra.com> I'm seeing messages like this: (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external group memberships even after all groups have been looked up on the LDAP server. and wondering it is anything to worry about. Some context: (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] (0x2000): Search groups with filter: (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] (0x2000): No such entry (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] (0x2000): Search groups with filter: (&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com)) (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs] (0x2000): No such DN in the timestamp cache: name=nwra at nwra.com,cn=groups,cn=nwra.com,cn=sysdb (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_merge_res_ts_attrs] (0x2000): TS cache doesn't contain this DN, skipping (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server] (0x2000): Searching 10.10.41.4:389 (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=nwra,dc=com]. (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [posixGroup] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTSecurityIdentifier] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaExternalMember] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 17 (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_op_add] (0x2000): New operation 17 timeout 6 (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7fc2ae9e9d90], connected[1], ops[0x7fc2aea403c0], ldap[0x7fc2ae9b60b0] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7fc2ae9e9d90], connected[1], ops[0x7fc2aea403c0], ldap[0x7fc2ae9b60b0] (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_op_destructor] (0x2000): Operation 17 finished (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 0 results. (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] (0x2000): Search groups with filter: (&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com)) (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sysdb_cache_search_groups] (0x2000): No such entry (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external group memberships even after all groups have been looked up on the LDAP server. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From orion at cora.nwra.com Fri Mar 31 23:08:13 2017 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 31 Mar 2017 17:08:13 -0600 Subject: [Freeipa-users] subdomain errors Message-ID: <6043cbf5-f052-25fd-b565-411084cdd2b1@cora.nwra.com> I seem to be having some issues with users/groups that may be leading to errors in the subdomain status. Can anyone parse this for me? (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_initgr_get_overrides_step] (0x0040): The group name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute objectSIDString, error! (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides failed [22]. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): DP Error is OK on failed request? (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_initgr_get_overrides_step] (0x0040): The group name=USER at nwra.com,cn=groups,cn=nwra.com,cn=sysdb has no UUID attribute objectSIDString, error! (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups overrides failed [22]. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [22]: Invalid argument. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): DP Error is OK on failed request? (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sdap_ad_tokengroups_get_posix_members] (0x0080): Domain not found for SID S-1-5-32-545 (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [sysdb_set_entry_attr] (0x0080): Cannot set ts attrs for name=USER at ad.nwra.com,cn=users,cn=ad.nwra.com,cn=sysdb (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved external group memberships even after all groups have been looked up on the LDAP server. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] (0x0080): Sudomain lookup failed, will try to reset sudomain.. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [be_fo_reset_svc] (0x0080): Cannot retrieve service [ad.nwra.com] (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): DP Error is OK on failed request? (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] (0x0080): Sudomain lookup failed, will try to reset sudomain.. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [be_fo_reset_svc] (0x0080): Cannot retrieve service [ad.nwra.com] (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [1432158270]: Subdomain is inactive. (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [dp_reply_std_set] (0x0080): DP Error is OK on failed request? (Fri Mar 31 16:54:26 2017) [sssd[be[nwra.com]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com