From sbose at redhat.com Tue Nov 1 09:08:13 2016 From: sbose at redhat.com (Sumit Bose) Date: Tue, 1 Nov 2016 10:08:13 +0100 Subject: [Freeipa-users] SSH as Root on CentOS 7 fails In-Reply-To: <568EA196-3F34-4C80-8C5C-198E81E8DE57@gmail.com> References: <568EA196-3F34-4C80-8C5C-198E81E8DE57@gmail.com> Message-ID: <20161101090813.GJ3049@p.Speedport_W_724V_Typ_A_05011603_00_009> On Mon, Oct 31, 2016 at 04:17:08PM -0400, Geordie Grindle wrote: > > Hello, > > I?m unable to ssh as ?root? onto any of my new CentOS 7 hosts. I?ve always been able to do so on CentOS6.x > > We normally have the file ?/root/.k5login? listing the designated system admins? principals. Once on a CentOS 7, an admin can ?ksu? and become root as we expected. > > We are using puppet and Foreman to build our hosts so they are in every way we can think of, identical, except for the O/s version. > > I?ve confirmed forward and reverse DNS and that the ?kvno? number matches what?s reported by ?klist -k?. > > I enabled "LogLevel DEBUG? in sshd_config and restarted sshd on a CentOS7 host: > > Oct 31 19:22:36 someserver sshd[12378]: debug1: userauth-request for user testuser service ssh-connection method none [preauth] > Oct 31 19:22:36 someserver sshd[12378]: debug1: attempt 0 failures 0 [preauth] > Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: initializing for "testuser" > Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: setting PAM_RHOST to "someserver.test.com" > Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: setting PAM_TTY to "ssh" > Oct 31 19:22:36 someserver sshd[12378]: debug1: userauth-request for user testuser service ssh-connection method gssapi-with-mic [preauth] > Oct 31 19:22:36 someserver sshd[12378]: debug1: attempt 1 failures 0 [preauth] > Oct 31 19:22:36 someserver sshd[12378]: Postponed gssapi-with-mic for testuser from 10.0.0.55 port 36383 ssh2 [preauth] > Oct 31 19:22:36 someserver sshd[12378]: debug1: Received some client credentials > Oct 31 19:22:36 someserver sshd[12378]: Authorized to testuser, krb5 principal testuser at TEST.COM (ssh_gssapi_krb5_cmdok) > > ################ > > Oct 31 19:35:42 someserver sshd[12409]: debug1: userauth-request for user root service ssh-connection method none [preauth] > Oct 31 19:35:42 someserver sshd[12409]: debug1: attempt 0 failures 0 [preauth] > Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: initializing for "root" > Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: setting PAM_RHOST to "someserver.test.com" > Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: setting PAM_TTY to "ssh" > Oct 31 19:35:42 someserver sshd[12409]: debug1: userauth-request for user root service ssh-connection method gssapi-with-mic [preauth] > Oct 31 19:35:42 someserver sshd[12409]: debug1: attempt 1 failures 0 [preauth] > Oct 31 19:35:42 someserver sshd[12409]: Postponed gssapi-with-mic for root from 10.0.0.55 port 36384 ssh2 [preauth] > Oct 31 19:35:42 someserver sshd[12409]: debug1: Received some client credentials > Oct 31 19:35:42 someserver sshd[12409]: Failed gssapi-with-mic for root from 10.0.0.55 port 36384 ssh2 > ... > Oct 31 19:35:42 someserver sshd[12577]: debug1: userauth-request for user root service ssh-connection method gssapi-with-mic [preauth] > Oct 31 19:35:42 someserver sshd[12577]: debug1: attempt 4 failures 1 [preauth] > > Appreciate any thoughts or suggestions you have. Which version of SSSD are you using. SSSD provides a localauth plugin to make matching the Kerberos principal and the provided login name more easy. It creates a configuration snippet for krb5.conf in /var/lib/sss/pubconf/krb5.include.d/localauth_plugin and the content should typically look like [plugins] localauth = { module = sssd:/usr/lib/sssd/modules/sssd_krb5_localauth_plugin.so } Some versions of SSSD added a 'enable_only = sssd' line which disables the .k5login checks. If you have this line in the localauth_plugin file I would recommend to check if a newer version of SSSD is available for your platform which do not create the line. As an alternative you can just remove the line from the file. But since SSSD will recreate the file at startup you should make it immutable with chattr and the 'i' option. HTH bye, Sumit > > Yours, > Geordie Grindle > > > -- > 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 freeipa at jacobdevans.com Tue Nov 1 22:41:41 2016 From: freeipa at jacobdevans.com (Jake) Date: Tue, 1 Nov 2016 18:41:41 -0400 (EDT) Subject: [Freeipa-users] HBAC Troubleshooting (IPA 4.2) Message-ID: <306018521.27004.1478040101921@vegas.jacobdevans.com> Hey All, I'm having some issues tracing HBAC policies, it seems whenever I disable the allow_all policy, I'm no longer able to access services I have allowed in my more-specific hbac policy. What are the troubleshooting steps (logs) I can run on the client to see what is being denied and by what policy, Is this all done with sssd? Thank You, -Jake -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at jacobdevans.com Tue Nov 1 22:48:31 2016 From: freeipa at jacobdevans.com (Jake) Date: Tue, 1 Nov 2016 18:48:31 -0400 (EDT) Subject: [Freeipa-users] Allow external AD users on webui In-Reply-To: <20161031075936.msdjg655wak5qnry@redhat.com> References: <58873534.735532.1477897496520.JavaMail.zimbra@casalogic.dk> <20161031073314.so2svmdfadwgkh3y@redhat.com> <117848539.736498.1477900274602.JavaMail.zimbra@casalogic.dk> <20161031075936.msdjg655wak5qnry@redhat.com> Message-ID: <1357601994.27082.1478040511071@vegas.jacobdevans.com> Sorry for the late reply, I've seen this on the mailing list a few times and wondered it myself....this was my solution: IPA has an option to use RADIUS password, which you can also override the username. So for those users that are allowed to manage IPA, we have google-auth and freeradius gateways setup with a user-override. for example. jevans at ipa.example.com has radius user of jevans at ad.example.com I log into the webui with jevans at ipa.example.com with my password for jevans at ad.example.com (and in my case, I add my google auth OTP) Does this help? -Jake ----- Original Message ----- From: "Alexander Bokovoy" To: "Troels Hansen" Cc: "freeipa-users" Sent: Monday, October 31, 2016 3:59:36 AM Subject: Re: [Freeipa-users] Allow external AD users on webui On ma, 31 loka 2016, Troels Hansen wrote: >----- On Oct 31, 2016, at 8:33 AM, Alexander Bokovoy abokovoy at redhat.com wrote: > > >> You make it sound as if it is a done deal. It is not, there is a number >> of changes that yet not figured out how to do in an efficient way. >> >> It is in our pipeline for 4.5. It is understandable that people ask for >> this feature. It is also should be clear to you had it been a simple >> thing, it would have been implemented already. >> >> If you want to see a progress, subscribe to the ticket. > >Hi Alexander > >It was in no way a critics of the FreeIPA team. I'm well aware of the >work being out into this product from the core team, and appreciate >every new release, but also not really able to help much with the >development, only testing and feedback. That's why I asked you to subscribe to the ticket. Once the changes will be ready, you could help with testing them. -- / 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 freeipa at jacobdevans.com Tue Nov 1 22:44:46 2016 From: freeipa at jacobdevans.com (Jake) Date: Tue, 1 Nov 2016 18:44:46 -0400 (EDT) Subject: [Freeipa-users] Service discovery and selection for IPA Message-ID: <208221012.27037.1478040286563@lux.jacobdevans.com> Hey All, Quick question on IPA Service discover and selection (ldap/kerberos in ad trust). Do IPA clients ping results of SRV records to determine which server they send requests (for ldap/kerberos specifically)? I have 8 AD Domain controllers, 2 in each location, and 4 ipa servers (2 in each of 2 locations), it seems the ipa servers rarely choose the local ad controllers, is there a way to adjust this? Must I setup something like geo-dns with different service weights per subnet? Thanks! ~Jake -------------- next part -------------- An HTML attachment was scrubbed... URL: From datakid at gmail.com Tue Nov 1 23:04:45 2016 From: datakid at gmail.com (Lachlan Musicman) Date: Wed, 2 Nov 2016 10:04:45 +1100 Subject: [Freeipa-users] HBAC Troubleshooting (IPA 4.2) In-Reply-To: <306018521.27004.1478040101921@vegas.jacobdevans.com> References: <306018521.27004.1478040101921@vegas.jacobdevans.com> Message-ID: Jake, I've seen this behaviour and am still struggling to find a solution. The version of underlying OS and sssd are useful to know fwiw. To trouble shoot HBAC: - in *target machine* sssd.conf, add debug_level=7 to each stanza (can go as high as 9, but I believe 7 will be sufficient) - restart sssd - clear logs in /var/log/sssd/ either by deleting or by logrotate - make an attempt to login/perform allowed action that gets denied - read logs to see what happened - I like to run `ipa hbactest --user= --host= --service` on the IPA node to confirm that the HBAC rules are correct - I sometimes also install ipa-tools on the target host and confirm that the above command gives same and correct answer - note that successful results from this command may not translate to successful application of HBAC on the target host in reality. cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 2 November 2016 at 09:41, Jake wrote: > Hey All, > I'm having some issues tracing HBAC policies, it seems whenever I disable > the allow_all policy, I'm no longer able to access services I have allowed > in my more-specific hbac policy. > > What are the troubleshooting steps (logs) I can run on the client to see > what is being denied and by what policy, Is this all done with sssd? > > Thank You, > -Jake > > > -- > 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 freeipa at jacobdevans.com Tue Nov 1 23:24:49 2016 From: freeipa at jacobdevans.com (Jake) Date: Tue, 1 Nov 2016 19:24:49 -0400 (EDT) Subject: [Freeipa-users] HBAC Troubleshooting (IPA 4.2) In-Reply-To: References: <306018521.27004.1478040101921@vegas.jacobdevans.com> Message-ID: <1867336570.27204.1478042689238@vegas.jacobdevans.com> Details: ipa-client-install --version 4.2.0 sssd --version 1.13.0 krb5-config --version Kerberos 5 release 1.13.2 cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) I hope this helps, also can I disable the allow-all rule per-host? Thanks, Jake From: "Lachlan Musicman" Cc: "freeipa-users" Sent: Tuesday, November 1, 2016 7:04:45 PM Subject: Re: [Freeipa-users] HBAC Troubleshooting (IPA 4.2) Jake, I've seen this behaviour and am still struggling to find a solution. The version of underlying OS and sssd are useful to know fwiw. To trouble shoot HBAC: - in *target machine* sssd.conf, add debug_level=7 to each stanza (can go as high as 9, but I believe 7 will be sufficient) - restart sssd - clear logs in /var/log/sssd/ either by deleting or by logrotate - make an attempt to login/perform allowed action that gets denied - read logs to see what happened - I like to run `ipa hbactest --user= --host= --service` on the IPA node to confirm that the HBAC rules are correct - I sometimes also install ipa-tools on the target host and confirm that the above command gives same and correct answer - note that successful results from this command may not translate to successful application of HBAC on the target host in reality. cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 2 November 2016 at 09:41, Jake < [ mailto:freeipa at jacobdevans.com | freeipa at jacobdevans.com ] > wrote: Hey All, I'm having some issues tracing HBAC policies, it seems whenever I disable the allow_all policy, I'm no longer able to access services I have allowed in my more-specific hbac policy. What are the troubleshooting steps (logs) I can run on the client to see what is being denied and by what policy, Is this all done with sssd? Thank You, -Jake -- Manage your subscription for the Freeipa-users mailing list: [ https://www.redhat.com/mailman/listinfo/freeipa-users | https://www.redhat.com/mailman/listinfo/freeipa-users ] Go to [ http://freeipa.org/ | 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 tjaalton at ubuntu.com Wed Nov 2 04:39:35 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Wed, 2 Nov 2016 06:39:35 +0200 Subject: [Freeipa-users] Contributing translations, modules (was Re: help) In-Reply-To: References: Message-ID: <536714ad-50a1-dc44-62e4-1a23ec353ea7@ubuntu.com> On 02.11.2016 03:03, ?? wrote: > Hello Timo Aaltonen, > I got your mail information from the changelog file of the freeipa > deb package. I'm using freeipa on Ubuntu, and having a test and research > with the function of freeipa. At the same time, I have carried on the > chinese translation to the web interface, also added own log module in > web interface, which can record our operation. However, For these > changes I don't know how to interact with the organization or community. > Whether I need to join an organization or community? Who should I > contact with? Please help me. Thank you! Hi, freeipa upstream would be your contact, you can try freeipa-users first, here's how to contribute: http://www.freeipa.org/page/Contribute and here's where you can join the list: https://www.redhat.com/mailman/listinfo/freeipa-users I've CC'd this reply there. -- t From jhrozek at redhat.com Wed Nov 2 08:46:51 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 2 Nov 2016 09:46:51 +0100 Subject: [Freeipa-users] Service discovery and selection for IPA In-Reply-To: <208221012.27037.1478040286563@lux.jacobdevans.com> References: <208221012.27037.1478040286563@lux.jacobdevans.com> Message-ID: <20161102084651.jqnkdc2gdlovxzpo@hendrix> On Tue, Nov 01, 2016 at 06:44:46PM -0400, Jake wrote: > Hey All, > Quick question on IPA Service discover and selection (ldap/kerberos in ad trust). > > Do IPA clients ping results of SRV records to determine which server they send requests (for ldap/kerberos specifically)? > > I have 8 AD Domain controllers, 2 in each location, and 4 ipa servers (2 in each of 2 locations), it seems the ipa servers rarely choose the local ad controllers, is there a way to adjust this? Must I setup something like geo-dns with different service weights per subnet? Please note that the identity lookups of AD users are mostly done by SSSD on the IPA masters and the IPA clients read the AD user data from the IPA masters. So I would make sure that the IPA masters are assigned to a local site, then SSSD should prefer DCs from that site. The DNS queries and the discovery should be visible in the SSSD domain logs on the IPA masters. Authentication is done by calling libkrb5 on the clients which is not site-aware. From arequipeno at gmail.com Wed Nov 2 14:54:31 2016 From: arequipeno at gmail.com (Ian Pilcher) Date: Wed, 2 Nov 2016 09:54:31 -0500 Subject: [Freeipa-users] How to clear DNS cache Message-ID: I am running FreeIPA 3.0.0 on CentOS 6. I appear to have stale records for for smtp.gmail.com in my cache, which are preventing me from sending email. I've been unable to figure out how to delete these records, which seem to be stored in LDAP. Any assistance/pointers appreciated. Thanks! -- ======================================================================== Ian Pilcher arequipeno at gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== From askstack at yahoo.com Wed Nov 2 19:07:07 2016 From: askstack at yahoo.com (Ask Stack) Date: Wed, 2 Nov 2016 19:07:07 +0000 (UTC) Subject: [Freeipa-users] /etc/ipa/default.conf on clients References: <1650961303.675208.1478113627546.ref@mail.yahoo.com> Message-ID: <1650961303.675208.1478113627546@mail.yahoo.com> I need to migrate ipa server from host rhel6.local to? host rhel7.local and retire host rhel6.local . For the existing clients, do I need to change /etc/ipa/default.conf ? Do I even need this file if sssd is working on the clients?Thanks. The current default.conf has two lines pointing to rhel6.local.?#File modified by ipa-client-install [global] basedn = realm = domain = server = rhel6.local xmlrpc_uri = https://rhel6.local/ipa/xml enable_ra = True -------------- next part -------------- An HTML attachment was scrubbed... URL: From peljasz at yahoo.co.uk Wed Nov 2 21:45:13 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 2 Nov 2016 21:45:13 +0000 Subject: [Freeipa-users] how to revert ipa-adtrust-install... In-Reply-To: <7d742171-ce87-aff0-5aef-903f109abc94@redhat.com> References: <1ec82d0c-1350-feb3-4da5-a022eb7ac5e5@yahoo.co.uk> <20160915191709.6vk7y3gidzxoicen@redhat.com> <98df2894-d5c7-082c-8fe8-77ece9474301@yahoo.co.uk> <20160915200055.qpx7gma722tjcfxk@redhat.com> <57DB1487.4000500@redhat.com> <7d742171-ce87-aff0-5aef-903f109abc94@redhat.com> Message-ID: <6bd2fe5d-40c4-f31c-bb3e-e32b0cab6f03@yahoo.co.uk> On 19/09/16 08:49, Martin Babinsky wrote: > On 09/17/2016 12:43 PM, lejeczek wrote: >> >> >> On 15/09/16 22:37, Rob Crittenden wrote: >>> What do you mean control? If you don't want ipactl to >>> manage the smb >>> service, look for an entry in >>> cn=masters,cn=ipa,cn=etc,dc=example,dc=com and delete it >>> if you find it. >>> >>> rob >> all I find there is: >> >> objectClass: nsContainer >> objectClass: top >> cn: masters >> > does the same pertain winbind? Does IPA need/use winbind if Samba under IPA is not the case? > You must perform subtree search and search for the entry > named 'cn=ADTRUST', like so: > > """ > ldapsearch -Y GSSAPI -b > 'cn=masters,cn=ipa,cn=etc,dc=ipa,dc=test' '(cn=ADTRUST)' > SASL/GSSAPI authentication started > SASL username: admin at IPA.TEST > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with > scope subtree > # filter: (cn=ADTRUST) > # requesting: ALL > # > > # ADTRUST, master1.ipa.test, masters, ipa, etc, ipa.test > dn: > cn=ADTRUST,cn=master1.ipa.test,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=test > > objectClass: ipaConfigObject > objectClass: nsContainer > objectClass: top > ipaConfigString: startOrder 60 > ipaConfigString: enabledService > cn: ADTRUST > > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > """ > > Then remove the "ipaConfigString: enabledService" > attribute from the entry to tell "ipactl" that it should > not control this service anymore: > > [root at master1 ~]# ldapmodify -Y GSSAPI > SASL/GSSAPI authentication started > SASL username: admin at IPA.TEST > SASL SSF: 56 > SASL data security layer installed. > dn: > cn=ADTRUST,cn=master1.ipa.test,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=test > > changetype: modify > delete: ipaConfigString > ipaConfigString: enabledService > > modifying entry > "cn=ADTRUST,cn=master1.ipa.test,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=test" > > > If you then do "ipactl restart" and "ipactl status", it > should not display smb.service anymore and you are free to > use them as you wish. > From mbasti at redhat.com Thu Nov 3 08:09:38 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Nov 2016 09:09:38 +0100 Subject: [Freeipa-users] How to clear DNS cache In-Reply-To: References: Message-ID: <75611358-c4d9-a14a-9c69-a9ca5de10331@redhat.com> On 02.11.2016 15:54, Ian Pilcher wrote: > I am running FreeIPA 3.0.0 on CentOS 6. I appear to have stale records > for for smtp.gmail.com in my cache, which are preventing me from sending > email. Can you check? https://deepthought.isc.org/article/AA-01002/0/How-do-I-flush-or-delete-incorrect-records-from-my-recursive-server-cache.html > > I've been unable to figure out how to delete these records, which seem > to be stored in LDAP. if those record are managed by freeIPA, you can use webUI or ipa dnsrecord-mod/del commands > > Any assistance/pointers appreciated. > > Thanks! > Martin From mbasti at redhat.com Thu Nov 3 08:12:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Nov 2016 09:12:01 +0100 Subject: [Freeipa-users] /etc/ipa/default.conf on clients In-Reply-To: <1650961303.675208.1478113627546@mail.yahoo.com> References: <1650961303.675208.1478113627546.ref@mail.yahoo.com> <1650961303.675208.1478113627546@mail.yahoo.com> Message-ID: On 02.11.2016 20:07, Ask Stack wrote: > > I need to migrate ipa server from host rhel6.local to host rhel7.local > and retire host rhel6.local . > For the existing clients, do I need to change /etc/ipa/default.conf ? > Do I even need this file if sssd is working on the clients? > Thanks. > > The current default.conf has two lines pointing to rhel6.local. > #File modified by ipa-client-install > [global] > basedn = > realm = > domain = > server = rhel6.local > xmlrpc_uri = https://rhel6.local/ipa/xml > enable_ra = True > > > Hello, this file is required for `ipa` commands on client Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Nov 3 09:30:25 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 3 Nov 2016 10:30:25 +0100 Subject: [Freeipa-users] dns_tkey_negotiategss: failure GSSAPI error [...] Message stream modified. In-Reply-To: References: Message-ID: On 27.10.2016 21:47, Tyrell Jentink wrote: > Thank you Petr! I found the problem, but quite by accident... There may > be a Best Practice at hand that I wasn't aware of... > > I still have the Windows AD server sitting on the side, serving as DHCP > server and waiting patiently for my Cross Realm Trust; That server will > forward DNS requests to the IPA server, and return a non-authoritative > answer. Occasionally, that server will seemingly loose track of the IPA > server, and stop returning results... And that happened while I was trying > to follow through with your request for info... So as a quick work around, > I simply dropped the AD server from my resolv.conf... > > And then performed your requests, without errors. I ran the DNS Update > from the ipa-server-install script, and that worked without errors. I > added the AD server back into resolv.conf, and everything failed again. I > put the AD server as the SECOND name server in resolv.conf, and the errors > went away. So I've clearly identified the problem. > > I uninstalled the client, and reinstalled the client, and everything went > cleanly. > > To prevent this problem in the future... I will be changing the DHCP > options to list the IPA DNS first for the Linux clients, and the AD DNS > first for Windows clients; I still want the AD DNS server in the list, as a > fallback. Is this plan the best practice here? Well, the ordering of the servers does not matter as long as they can resolve records properly. The key problem is > answer. Occasionally, that server will seemingly loose track of the IPA > server, and stop returning results... And that happened while I was trying ... It should just work if you fix this. I hope it helps. Petr Spacek @ Red Hat > > On Wed, Oct 26, 2016 at 11:36 PM, Petr Spacek wrote: > >> On 27.10.2016 04:43, Tyrell Jentink wrote: >>>> 2016-10-26T23:30:40Z DEBUG Writing nsupdate commands to >>>>> /etc/ipa/.dns_update.txt: >>>>> 2016-10-26T23:30:40Z DEBUG debug >>>>> >>>>> update delete trainmaster.ipa.rxrhouse.net. IN A >>>>> show >>>>> send >>>>> >>>>> update delete trainmaster.ipa.rxrhouse.net. IN AAAA >>>>> show >>>>> send >>>>> >>>>> update add trainmaster.ipa.rxrhouse.net. 1200 IN A 10.42.0.100 >>>>> show >>>>> send >>>>> >>>>> 2016-10-26T23:30:40Z DEBUG Starting external process >>>>> 2016-10-26T23:30:40Z DEBUG args=/usr/bin/nsupdate -g >>>>> /etc/ipa/.dns_update.txt >>>>> 2016-10-26T23:30:40Z DEBUG Process finished, return code=1 >>>>> 2016-10-26T23:30:40Z DEBUG stdout=Outgoing update query: >>>>> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0 >>>>> ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 >>>>> ;; UPDATE SECTION: >>>>> trainmaster.ipa.rxrhouse.net. 0 ANY A >>>>> >>>>> Outgoing update query: >>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39562 >>>>> ;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >>>>> ;; QUESTION SECTION: >>>>> ;3107127915.sig-ipa-pdc.ipa.rxrhouse.net. ANY TKEY >>>>> >>>>> ;; ADDITIONAL SECTION: >>>>> 3107127915.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig. >> 1477524640 >> [...] >>>>> >>>>> 2016-10-26T23:30:40Z DEBUG stderr=Reply from SOA query: >>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38738 >>>>> ;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, >> ADDITIONAL: 0 >>>>> ;; QUESTION SECTION: >>>>> ;trainmaster.ipa.rxrhouse.net. IN SOA >>>>> >>>>> ;; AUTHORITY SECTION: >>>>> ipa.rxrhouse.net. 0 IN SOA >> ipa-pdc.ipa.rxrhouse.net. >>>>> hostmaster.ipa.rxrhouse.net. 1477524446 3600 900 1209600 3600 >>>>> >>>>> Found zone name: ipa.rxrhouse.net >>>>> The master is: ipa-pdc.ipa.rxrhouse.net >>>>> start_gssrequest >>>>> Found realm from ticket: IPA.RXRHOUSE.NET >>>>> send_gssrequest >>>>> recvmsg reply from GSS-TSIG query >>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39562 >>>>> ;; flags: qr; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >>>>> ;; QUESTION SECTION: >>>>> ;3107127915.sig-ipa-pdc.ipa.rxrhouse.net. ANY TKEY >>>>> >>>>> ;; ANSWER SECTION: >>>>> 3107127915.sig-ipa-pdc.ipa.rxrhouse.net. 0 ANY TKEY gss-tsig. >> 1466301805 >>>>> 1466388205 3 NOERROR 101 >>>>> YGMGCSqGSIb3EgECAgMAflQwUqADAgEFoQMCAR6kERgPMjAxNjA2MTkw >>>>> MjAzMjVapQUCAwHGkaYDAgEpqREbD0FELlJYUkhPVVNFLk5FVKoUMBKg >>>>> AwIBAaELMAkbB2FkLXBkYyQ= >>>>> 0 >>>>> >>>>> dns_tkey_negotiategss: failure GSSAPI error: Major = Unspecified GSS >>>>> failure. Minor code may provide more information, Minor = Message >> stream >>>>> modified. >>>>> >>>>> 2016-10-26T23:30:40Z DEBUG nsupdate failed: Command >> '/usr/bin/nsupdate -g >>>>> /etc/ipa/.dns_update.txt' returned non-zero exit status 1 >>>>> 2016-10-26T23:30:40Z ERROR Failed to update DNS records. >>>>> 2016-10-26T23:30:40Z DEBUG DNS resolver: Query: >>>>> trainmaster.ipa.rxrhouse.net IN A >>>>> 2016-10-26T23:30:40Z DEBUG DNS resolver: No record. >>>>> 2016-10-26T23:30:40Z DEBUG DNS resolver: Query: >>>>> trainmaster.ipa.rxrhouse.net IN AAAA >>>>> 2016-10-26T23:30:40Z DEBUG DNS resolver: No record. >>>>> 2016-10-26T23:30:40Z DEBUG DNS resolver: Query: >> 100.0.42.10.in-addr.arpa. >>>>> IN PTR >>>>> 2016-10-26T23:30:40Z DEBUG DNS resolver: No record. >>>>> 2016-10-26T23:30:40Z WARNING Missing A/AAAA record(s) for host >>>>> trainmaster.ipa.rxrhouse.net: 10.42.0.100. >>>>> 2016-10-26T23:30:40Z WARNING Missing reverse record(s) for >> address(es): >>>>> 10.42.0.100. >>>>> >>> -- Full logs can be found here: http://pastebin.com/90dG9Ffu >>> >>> - For grins, I decided to test: >>> kinit admin >>> id admin >>> getent passwd admin >>> on the client, and all of those all made valid responses... So >>> authentication is working, I just can't update DNS records. >>> >>> >>> So that's what I've tried, and where I'm at... My client machines >> running >>> modern client software can NOT update DNS records, complaining about >> GSSAPI >>> "Message Stream Modified" errors... And I have no idea how to >> troubleshoot >>> that... Any ideas? >> >> Interesting, I haven't seen this one :-) >> >> There is something fishy in GSSAPI negotiation between the client and DNS >> server. >> >> I would try this (and watch out for suspicious messages along the way): >> >> 1) To be sure, please double-check that ipa-pdc.ipa.rxrhouse.net. resolves >> (from the client) to correct IP address of IPA DNS server. >> >> 2) Verify that Kerberos ticket for the DNS server can be obtained: >> $ kinit -k >> $ kvno DNS/ipa-pdc.ipa.rxrhouse.net >> $ klist # it should list Kerberos ticket for ipa-pdc.ipa.rxrhouse.net >> >> 3) Create a plain text file with update message content: >> cat > /tmp/dnsupdate <<> debug >> update delete trainmaster.ipa.rxrhouse.net. IN A >> send >> EOF >> >> 4) call nsupdate on it >> $ KRB5_TRACE=/dev/stdout nsupdate -g /tmp/dnsupdate >> >> Does it produce the same error? (It should, but with more debuginfo.) >> >> >> What version of server and client packages are you using? >> >> -- >> Petr^2 Spacek From peljasz at yahoo.co.uk Thu Nov 3 13:42:55 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 3 Nov 2016 13:42:55 +0000 Subject: [Freeipa-users] CSN not found Message-ID: <4c238a79-e31d-6a7e-ab78-66a6f6f5fe13@yahoo.co.uk> hi everybody my three IPAs have gone haywire, two things I recall: one - one server was on ScientificL with slightly lower minor version of IPA, two - another server (of the two identical CEntOSes) had skewed time. Not all there servers are in time-sync and all run same version of IPA but replication broke with errors like: $ ipa-replica-manage re-initialize --from rider --force .. [03/Nov/2016:13:21:08 +0000] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=dc=xx,dc=xx,dc=dc=xx,dc=xx,dc=x does not exist [03/Nov/2016:13:21:08 +0000] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=dc=xx,dc=xx,dc=dc=xx,dc=xx,dc=x does not exist [03/Nov/2016:13:21:09 +0000] agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389) - Can't locate CSN 581b120f000500040000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): CSN 581b120f000500040000 not found, we aren't as up to date, or we purged [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): Data required to update replica has been purged. The replica must be reinitialized. [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): Incremental update failed and requires administrator action I did dbscan -f /var.../cb941....db on all three servers and greped but cannot see that 581b120f000500040000 where to troubleshoot? many thanks. L From raul at dias.com.br Thu Nov 3 13:48:45 2016 From: raul at dias.com.br (Raul Dias) Date: Thu, 3 Nov 2016 11:48:45 -0200 Subject: [Freeipa-users] Stuck at DNS install process Message-ID: Hello, I am trying to setup a test environment for FreeIPA. I have installed Fedora Server 24 in a VMWare Workstation machine and updated it. There are 2 ethernets: 1 - ens33 -> bridge to the host (dhcp) 2 - ens34 -> Internal (vmware) network for testing the ens34 has: 3: ens34: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:0c:29:ab:26:59 brd ff:ff:ff:ff:ff:ff inet 10.101.1.1/24 brd 10.101.1.255 scope global ens34 valid_lft forever preferred_lft forever inet6 fe80::e88e:21e6:c273:5178/64 scope link valid_lft forever preferred_lft forever Setting up FreeIPA with: # ipa-server-install -a secret123 -p secret123 --domain=chaosnet --realm=CHAOSNET --hostname server.chaosnet --setup-dns -v ... Enter the IP address to use, or press Enter to finish. Please provide the IP address to be used for this host name: 10.101.1.1 ipa : DEBUG Starting external process ipa : DEBUG args=/sbin/ip -family inet -oneline address show ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout=1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 2: ens33 inet 192.168.1.148/24 brd 192.168.1.255 scope global dynamic ens33\ valid_lft 11552sec preferred_lft 11552sec 3: ens34 inet 10.101.1.1/24 brd 10.101.1.255 scope global ens34\ valid_lft forever preferred_lft forever ipa : DEBUG stderr= Please provide the IP address to be used for this host name: -----8<---- If I enter my IPs: 10.101.1.1, 10.101.1.1/24, 192.168.1.148, 192.168.1.148/24 it will ask again for the IP address. If I enter anything else, it will detect it is not my IP and complain. Am I missing something? A package maybe? Or is it a bug (or me)? # dnf list | grep freeipa freeipa-admintools.noarch 4.3.2-2.fc24 @updates freeipa-client.x86_64 4.3.2-2.fc24 @updates freeipa-client-common.noarch 4.3.2-2.fc24 @updates freeipa-common.noarch 4.3.2-2.fc24 @updates freeipa-server.x86_64 4.3.2-2.fc24 @updates freeipa-server-common.noarch 4.3.2-2.fc24 @updates freeipa-server-dns.noarch 4.3.2-2.fc24 @updates freeipa-server-trust-ad.x86_64 4.3.2-2.fc24 @updates freeipa-python-compat.noarch 4.3.2-2.fc24 updates Thanks for your help, -rsd -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Nov 3 14:12:04 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Nov 2016 15:12:04 +0100 Subject: [Freeipa-users] Stuck at DNS install process In-Reply-To: References: Message-ID: <24a79c07-f45f-74f7-f304-c8ea690e88f0@redhat.com> On 03.11.2016 14:48, Raul Dias wrote: > Hello, > > I am trying to setup a test environment for FreeIPA. > > I have installed Fedora Server 24 in a VMWare Workstation machine and > updated it. > There are 2 ethernets: > 1 - ens33 -> bridge to the host (dhcp) > 2 - ens34 -> Internal (vmware) network for testing > > the ens34 has: > 3: ens34: mtu 1500 qdisc > fq_codel state UP group default qlen 1000 > link/ether 00:0c:29:ab:26:59 brd ff:ff:ff:ff:ff:ff > inet 10.101.1.1/24 brd 10.101.1.255 scope global ens34 > valid_lft forever preferred_lft forever > inet6 fe80::e88e:21e6:c273:5178/64 scope link > valid_lft forever preferred_lft forever > > Setting up FreeIPA with: > # ipa-server-install -a secret123 -p secret123 --domain=chaosnet > --realm=CHAOSNET --hostname server.chaosnet --setup-dns -v > ... > Enter the IP address to use, or press Enter to finish. > Please provide the IP address to be used for this host name: 10.101.1.1 > ipa : DEBUG Starting external process > ipa : DEBUG args=/sbin/ip -family inet -oneline address show > ipa : DEBUG Process finished, return code=0 > ipa : DEBUG stdout=1: lo inet 127.0.0.1/8 scope host > lo\ valid_lft forever preferred_lft forever > 2: ens33 inet 192.168.1.148/24 brd 192.168.1.255 scope global > dynamic ens33\ valid_lft 11552sec preferred_lft 11552sec > 3: ens34 inet 10.101.1.1/24 brd 10.101.1.255 scope global > ens34\ valid_lft forever preferred_lft forever > > ipa : DEBUG stderr= > Please provide the IP address to be used for this host name: > -----8<---- > > If I enter my IPs: 10.101.1.1, 10.101.1.1/24, 192.168.1.148, > 192.168.1.148/24 > it will ask again for the IP address. > If I enter anything else, it will detect it is not my IP and complain. > > Am I missing something? A package maybe? Or is it a bug (or me)? > > # dnf list | grep freeipa > freeipa-admintools.noarch 4.3.2-2.fc24 @updates > freeipa-client.x86_64 4.3.2-2.fc24 @updates > freeipa-client-common.noarch 4.3.2-2.fc24 @updates > freeipa-common.noarch 4.3.2-2.fc24 @updates > freeipa-server.x86_64 4.3.2-2.fc24 @updates > freeipa-server-common.noarch 4.3.2-2.fc24 @updates > freeipa-server-dns.noarch 4.3.2-2.fc24 @updates > freeipa-server-trust-ad.x86_64 4.3.2-2.fc24 @updates > freeipa-python-compat.noarch 4.3.2-2.fc24 updates > > > Thanks for your help, > -rsd > > > > > > > > > > Hello, have you tried just press enter twice? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mareynol at redhat.com Thu Nov 3 14:16:13 2016 From: mareynol at redhat.com (Mark Reynolds) Date: Thu, 3 Nov 2016 10:16:13 -0400 Subject: [Freeipa-users] CSN not found In-Reply-To: <4c238a79-e31d-6a7e-ab78-66a6f6f5fe13@yahoo.co.uk> References: <4c238a79-e31d-6a7e-ab78-66a6f6f5fe13@yahoo.co.uk> Message-ID: <65afd1fd-9737-17bf-8af1-47d855f1f53c@redhat.com> On 11/03/2016 09:42 AM, lejeczek wrote: > hi everybody > > my three IPAs have gone haywire, two things I recall: one - one server > was on ScientificL with slightly lower minor version of IPA, two - > another server (of the two identical CEntOSes) had skewed time. > Not all there servers are in time-sync and all run same version of IPA > but replication broke with errors like: > > > $ ipa-replica-manage re-initialize --from rider --force > > .. > [03/Nov/2016:13:21:08 +0000] NSACLPlugin - The ACL target > cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=dc=xx,dc=xx,dc=dc=xx,dc=xx,dc=x > does not exist > [03/Nov/2016:13:21:08 +0000] NSACLPlugin - The ACL target > cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=dc=xx,dc=xx,dc=dc=xx,dc=xx,dc=x > does not exist > [03/Nov/2016:13:21:09 +0000] agmt="cn=meToswir.xx.xx.xx.xx.x" > (swir:389) - Can't locate CSN 581b120f000500040000 in the changelog > (DB rc=-30988). If replication stops, the consumer may need to be > reinitialized. > [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - changelog program > - agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): CSN > 581b120f000500040000 not found, we aren't as up to date, or we purged > [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - > agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): Data required to update > replica has been purged. The replica must be reinitialized. > [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - > agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): Incremental update failed > and requires administrator action > > I did dbscan -f /var.../cb941....db on all three servers and greped > but cannot see that 581b120f000500040000 > > where to troubleshoot? What version of 389 do you have: rpm -qa | grep 389-ds-base Did you check the changelog database for 581b120f000500040000: dbscan -f /var/lib/dirsrv/slapd-INSTANCE/db/changelogdb What about the access logs? Do you see the CSN there? I've seen this issue before where a CSN is missing, which breaks the replication agreements, but the CSN does get added to the changelog after a few seconds. The only way to fix replication is to restart the server, or disable/enable the replication agreements(basically restart them). Thanks, Mark > many thanks. > L > From tsdrach at gmail.com Thu Nov 3 14:35:30 2016 From: tsdrach at gmail.com (Taras Drach) Date: Thu, 3 Nov 2016 16:35:30 +0200 Subject: [Freeipa-users] FreeIPA - AD trust - SSH Public Keys Message-ID: <7A48CD90-0463-4EE3-A525-BBF6C023BF7F@gmail.com> Hello everyone! I want to implement next scheme: 1. Use AD as place for user management 2. Store ssh public keys in AD 3. Use FreeIPA as sudo/hbac provider for AD groups for authentication and authorisation on the linux hosts 4. Use trusts roadmap (do not want to synchronise) My configuration is: AD domain - test.loc - windows server 2012 r2 IPA domain - ipa.test.loc - ipa-server 4.2.0 on centos 7 (ipa-server.x86_64 4.2.0-15.0.1.el7.centos.19 @updates) At this moment everything fine except SSH public keys. I tried to use override and it works fine (I can login to linux host with AD user with public key), but I have to create view in ipa for each user from AD. It is not my goal and its also create inconveniences. I found that there are several ways to achieve desired configuration: 1. Extend AD scheme with sshPublicKey attribute 2. Use altSecurityIdentities attribute from AD At this moment I can obtain ssh public key from ipa for user by sss_ssh_authorizedkeys -d ipa.test.loc user or sss_ssh_authorizedkeys user, because ipa.test.loc is default domain But I can?t receive key for AD user using this command sss_ssh_authorizedkeys -d test.loc At this moment I try to obtain key via altSecurityIdentities, and I see this key in sssd debug log when I run sss_ssh_authorizedkeys, but I can not see public key on stdout Here is the part if log - Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'dc01.test.loc' as 'working' (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #1 (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [dc=test,dc=loc] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.148 (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=rr)(objectclass=user)(sAMAccountName=*)(objectSID=*))][dc=test,dc=loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altSecurityIdentities] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5 (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 5 timeout 6 (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_done] (0x4000): caching successful connection after 1 notifies (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [be_run_unconditional_online_cb] (0x0400): Running unconditional online callbacks. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f48ff3d7440], connected[1], ops[0x7f48ff3d5ce0], ldap[0x7f48ff3bf360] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=rr,CN=Users,DC=test,DC=loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [whenChanged] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [uSNChanged] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [name] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectGUID] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [userAccountControl] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [primaryGroupID] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectSid] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [accountExpires] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [sAMAccountName] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [userPrincipalName] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [altSecurityIdentities] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f48ff3d7440], connected[1], ops[0x7f48ff3d5ce0], ldap[0x7f48ff3bf360] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://ForestDnsZones.test.loc/DC=ForestDnsZones,DC=test,DC=loc (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f48ff3d7440], connected[1], ops[0x7f48ff3d5ce0], ldap[0x7f48ff3bf360] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://DomainDnsZones.test.loc/DC=DomainDnsZones,DC=test,DC=loc (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f48ff3d7440], connected[1], ops[0x7f48ff3d5ce0], ldap[0x7f48ff3bf360] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://test.loc/CN=Configuration,DC=test,DC=loc (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f48ff3d7440], connected[1], ops[0x7f48ff3d5ce0], ldap[0x7f48ff3bf360] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 5 finished (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Request included referrals which were ignored. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Ref: ldap://ForestDnsZones.test.loc/DC=ForestDnsZones,DC=test,DC=loc (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Ref: ldap://DomainDnsZones.test.loc/DC=DomainDnsZones,DC=test,DC=loc (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Ref: ldap://test.loc/CN=Configuration,DC=test,DC=loc (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_search_user_process] (0x0400): Search for users, returned 1 results. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_search_user_process] (0x4000): Retrieved total 1 users (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Save user (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_get_primary_name] (0x0400): Processing object rr at test.loc (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Processing user rr at test.loc (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x1000): Mapping user [rr at test.loc] objectSID [S-1-5-21-237804563-1161820721-801220523-1106] to unix ID (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x2000): Adding originalDN [CN=rr,CN=Users,DC=test,DC=loc] to attributes of [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Original memberOf is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20161103142350.0Z] to attributes of [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Adding user principal [rr at SLT.LOC] to attributes of [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowLastChange is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMin is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMax is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowWarning is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowInactive is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowExpire is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowFlag is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): krbLastPwdChange is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): krbPasswordExpiration is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): pwdAttribute is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedService is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding adAccountExpires [9223372036854775807] to attributes of [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding adUserAccountControl [66048] to attributes of [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): nsAccountLock is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedHost is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginDisabled is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginExpirationTime is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginAllowedTimeMap is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): authType is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): userCertificate is not available for [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding altSecurityIdentities [ssh-rsa\20AAAAB3NzaC1yc2EAAAADAQABAAABAQDQydFCKx/r5idp3U0EY0fMJdu0eHNuIc6xvZudQJm/mbf3TflLNH+mj/Jr7yQaPj0C6z7V8my+D0f6JK1cCntxfhLQto92xUZhhKoLHVO34f5DhC5etqZ4EtaD6j9QuXYc5U8GovHgzmdH+JSeIOSpSqFzTkFR6sSmhjypfCDPCP8JKHxwI9LJvfgCRv0qKJBjELhUpZYUW3Mrcpp+bJcX8Iuz0QPDkO2VdqIcwapC+h6AhdH+Sm6PjG8FplH6/5SDlQ2LOVTnY4xMuS48RXzgtJImN+o7syrxjPTQU5/PWXiIH/Hawa6n75kREv6B4AHtQKxqDoxhNdzQ1+xiLs4H\20user at test.loc] to attributes of [rr at test.loc]. (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add lowercased aliases (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Storing info for user rr at test.loc (Thu Nov 3 14:24:33 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 1) Here is my sssd.conf for ipa domain domain/ipa.test.loc] debug_level = 0xfff0 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.test.loc id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipa42.ipa.test.loc chpass_provider = ipa ipa_server = ipa42.ipa.test.loc ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt create_homedir = True ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities ldap_user_ssh_public_key = altSecurityIdentities ldap_id_mapping = False -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: Message signed with OpenPGP using GPGMail URL: From raul at dias.com.br Thu Nov 3 14:52:11 2016 From: raul at dias.com.br (Raul Dias) Date: Thu, 3 Nov 2016 12:52:11 -0200 Subject: [Freeipa-users] Stuck at DNS install process In-Reply-To: <24a79c07-f45f-74f7-f304-c8ea690e88f0@redhat.com> References: <24a79c07-f45f-74f7-f304-c8ea690e88f0@redhat.com> Message-ID: <410c9f16-a003-37c3-0884-125545952518@dias.com.br> Yes. It worked! Thanks. -rsd On 03/11/2016 12:12, Martin Basti wrote: > > > > On 03.11.2016 14:48, Raul Dias wrote: >> Hello, >> >> I am trying to setup a test environment for FreeIPA. >> >> I have installed Fedora Server 24 in a VMWare Workstation machine and >> updated it. >> There are 2 ethernets: >> 1 - ens33 -> bridge to the host (dhcp) >> 2 - ens34 -> Internal (vmware) network for testing >> >> the ens34 has: >> 3: ens34: mtu 1500 qdisc >> fq_codel state UP group default qlen 1000 >> link/ether 00:0c:29:ab:26:59 brd ff:ff:ff:ff:ff:ff >> inet 10.101.1.1/24 brd 10.101.1.255 scope global ens34 >> valid_lft forever preferred_lft forever >> inet6 fe80::e88e:21e6:c273:5178/64 scope link >> valid_lft forever preferred_lft forever >> >> Setting up FreeIPA with: >> # ipa-server-install -a secret123 -p secret123 --domain=chaosnet >> --realm=CHAOSNET --hostname server.chaosnet --setup-dns -v >> ... >> Enter the IP address to use, or press Enter to finish. >> Please provide the IP address to be used for this host name: 10.101.1.1 >> ipa : DEBUG Starting external process >> ipa : DEBUG args=/sbin/ip -family inet -oneline address show >> ipa : DEBUG Process finished, return code=0 >> ipa : DEBUG stdout=1: lo inet 127.0.0.1/8 scope host >> lo\ valid_lft forever preferred_lft forever >> 2: ens33 inet 192.168.1.148/24 brd 192.168.1.255 scope global >> dynamic ens33\ valid_lft 11552sec preferred_lft 11552sec >> 3: ens34 inet 10.101.1.1/24 brd 10.101.1.255 scope global >> ens34\ valid_lft forever preferred_lft forever >> >> ipa : DEBUG stderr= >> Please provide the IP address to be used for this host name: >> -----8<---- >> >> If I enter my IPs: 10.101.1.1, 10.101.1.1/24, 192.168.1.148, >> 192.168.1.148/24 >> it will ask again for the IP address. >> If I enter anything else, it will detect it is not my IP and complain. >> >> Am I missing something? A package maybe? Or is it a bug (or me)? >> >> # dnf list | grep freeipa >> freeipa-admintools.noarch 4.3.2-2.fc24 @updates >> freeipa-client.x86_64 4.3.2-2.fc24 @updates >> freeipa-client-common.noarch 4.3.2-2.fc24 @updates >> freeipa-common.noarch 4.3.2-2.fc24 @updates >> freeipa-server.x86_64 4.3.2-2.fc24 @updates >> freeipa-server-common.noarch 4.3.2-2.fc24 @updates >> freeipa-server-dns.noarch 4.3.2-2.fc24 @updates >> freeipa-server-trust-ad.x86_64 4.3.2-2.fc24 @updates >> freeipa-python-compat.noarch 4.3.2-2.fc24 updates >> >> >> Thanks for your help, >> -rsd >> >> >> >> >> >> >> >> >> >> > > > Hello, have you tried just press enter twice? > > Martin -- Att. Raul Dias -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Nov 3 15:05:31 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 3 Nov 2016 16:05:31 +0100 Subject: [Freeipa-users] FreeIPA - AD trust - SSH Public Keys In-Reply-To: <7A48CD90-0463-4EE3-A525-BBF6C023BF7F@gmail.com> References: <7A48CD90-0463-4EE3-A525-BBF6C023BF7F@gmail.com> Message-ID: <20161103150531.GF28597@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, Nov 03, 2016 at 04:35:30PM +0200, Taras Drach wrote: > Hello everyone! > > I want to implement next scheme: > > 1. Use AD as place for user management > 2. Store ssh public keys in AD > 3. Use FreeIPA as sudo/hbac provider for AD groups for authentication and authorisation on the linux hosts > 4. Use trusts roadmap (do not want to synchronise) > > My configuration is: > AD domain - test.loc - windows server 2012 r2 > IPA domain - ipa.test.loc - ipa-server 4.2.0 on centos 7 (ipa-server.x86_64 4.2.0-15.0.1.el7.centos.19 @updates) > > At this moment everything fine except SSH public keys. > > I tried to use override and it works fine (I can login to linux host with AD user with public key), but I have to create view in ipa for each user from AD. It is not my goal and its also create inconveniences. > > I found that there are several ways to achieve desired configuration: > 1. Extend AD scheme with sshPublicKey attribute > 2. Use altSecurityIdentities attribute from AD > > At this moment I can obtain ssh public key from ipa for user by > sss_ssh_authorizedkeys -d ipa.test.loc user or > sss_ssh_authorizedkeys user, because ipa.test.loc is default domain > > But I can?t receive key for AD user using this command > sss_ssh_authorizedkeys -d test.loc > > At this moment I try to obtain key via altSecurityIdentities, and I see this key in sssd debug log when I run sss_ssh_authorizedkeys, but I can not see public key on stdout > Here is the part if log > - ... > > > Here is my sssd.conf for ipa domain > > domain/ipa.test.loc] > debug_level = 0xfff0 > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = ipa.test.loc > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = ipa42.ipa.test.loc > chpass_provider = ipa > ipa_server = ipa42.ipa.test.loc > ipa_server_mode = True > ldap_tls_cacert = /etc/ipa/ca.crt > create_homedir = True > ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities SSH public keys must must be stored with the attribute name 'sshPublicKey' in SSSD's cache, please try ldap_user_extra_attrs = sshPublicKey:altSecurityIdentities > ldap_user_ssh_public_key = altSecurityIdentities > ldap_id_mapping = False > > > HTH bye, Sumit From mbasti at redhat.com Thu Nov 3 15:11:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 3 Nov 2016 16:11:00 +0100 Subject: [Freeipa-users] Stuck at DNS install process In-Reply-To: <410c9f16-a003-37c3-0884-125545952518@dias.com.br> References: <24a79c07-f45f-74f7-f304-c8ea690e88f0@redhat.com> <410c9f16-a003-37c3-0884-125545952518@dias.com.br> Message-ID: <414f50ca-7642-dc72-5696-e00ef39e33cf@redhat.com> Feel free to contribute by commenting https://github.com/freeipa/freeipa/pull/207 and make IPA UX better :) On 03.11.2016 15:52, Raul Dias wrote: > > Yes. It worked! > > Thanks. > > -rsd > > > On 03/11/2016 12:12, Martin Basti wrote: >> >> >> >> On 03.11.2016 14:48, Raul Dias wrote: >>> Hello, >>> >>> I am trying to setup a test environment for FreeIPA. >>> >>> I have installed Fedora Server 24 in a VMWare Workstation machine >>> and updated it. >>> There are 2 ethernets: >>> 1 - ens33 -> bridge to the host (dhcp) >>> 2 - ens34 -> Internal (vmware) network for testing >>> >>> the ens34 has: >>> 3: ens34: mtu 1500 qdisc >>> fq_codel state UP group default qlen 1000 >>> link/ether 00:0c:29:ab:26:59 brd ff:ff:ff:ff:ff:ff >>> inet 10.101.1.1/24 brd 10.101.1.255 scope global ens34 >>> valid_lft forever preferred_lft forever >>> inet6 fe80::e88e:21e6:c273:5178/64 scope link >>> valid_lft forever preferred_lft forever >>> >>> Setting up FreeIPA with: >>> # ipa-server-install -a secret123 -p secret123 >>> --domain=chaosnet --realm=CHAOSNET --hostname server.chaosnet >>> --setup-dns -v >>> ... >>> Enter the IP address to use, or press Enter to finish. >>> Please provide the IP address to be used for this host name: 10.101.1.1 >>> ipa : DEBUG Starting external process >>> ipa : DEBUG args=/sbin/ip -family inet -oneline address show >>> ipa : DEBUG Process finished, return code=0 >>> ipa : DEBUG stdout=1: lo inet 127.0.0.1/8 scope host >>> lo\ valid_lft forever preferred_lft forever >>> 2: ens33 inet 192.168.1.148/24 brd 192.168.1.255 scope global >>> dynamic ens33\ valid_lft 11552sec preferred_lft 11552sec >>> 3: ens34 inet 10.101.1.1/24 brd 10.101.1.255 scope global >>> ens34\ valid_lft forever preferred_lft forever >>> >>> ipa : DEBUG stderr= >>> Please provide the IP address to be used for this host name: >>> -----8<---- >>> >>> If I enter my IPs: 10.101.1.1, 10.101.1.1/24, 192.168.1.148, >>> 192.168.1.148/24 >>> it will ask again for the IP address. >>> If I enter anything else, it will detect it is not my IP and complain. >>> >>> Am I missing something? A package maybe? Or is it a bug (or me)? >>> >>> # dnf list | grep freeipa >>> freeipa-admintools.noarch 4.3.2-2.fc24 @updates >>> freeipa-client.x86_64 4.3.2-2.fc24 @updates >>> freeipa-client-common.noarch 4.3.2-2.fc24 @updates >>> freeipa-common.noarch 4.3.2-2.fc24 @updates >>> freeipa-server.x86_64 4.3.2-2.fc24 @updates >>> freeipa-server-common.noarch 4.3.2-2.fc24 @updates >>> freeipa-server-dns.noarch 4.3.2-2.fc24 @updates >>> freeipa-server-trust-ad.x86_64 4.3.2-2.fc24 @updates >>> freeipa-python-compat.noarch 4.3.2-2.fc24 updates >>> >>> >>> Thanks for your help, >>> -rsd >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> Hello, have you tried just press enter twice? >> >> Martin > > -- > Att. Raul Dias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsdrach at gmail.com Thu Nov 3 15:23:06 2016 From: tsdrach at gmail.com (Taras Drach) Date: Thu, 3 Nov 2016 17:23:06 +0200 Subject: [Freeipa-users] FreeIPA - AD trust - SSH Public Keys In-Reply-To: <20161103150531.GF28597@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <7A48CD90-0463-4EE3-A525-BBF6C023BF7F@gmail.com> <20161103150531.GF28597@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <98E0A883-9571-44D8-ADB5-7B9B90540EB7@gmail.com> Thank for reply, Unfortunately sssd won?t start with this configuration Here is part of log (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sdap_extend_map] (0x0200): 1 extra attributes (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sdap_extend_map] (0x0010): Attribute sshPublicKey (altSecurityIdentities in LDAP) is already used by SSSD, please choose a different cache name (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [load_backend_module] (0x0010): Error (1432158241) in module (ipa) initialization (sssm_ipa_id_init)! (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [be_process_init] (0x0010): fatal error initializing data providers (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sbus_remove_watch] (0x2000): 0x7f8183df2640/0x7f8183df2420 Config changes: ldap_user_extra_attrs = sshPublicKey:altSecurityIdentities # ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities ldap_user_ssh_public_key = altSecurityIdentities ldap_id_mapping = False > On Nov 3, 2016, at 5:05 PM, Sumit Bose wrote: > > sshPublicKey: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: Message signed with OpenPGP using GPGMail URL: From peljasz at yahoo.co.uk Thu Nov 3 16:49:56 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 3 Nov 2016 16:49:56 +0000 Subject: [Freeipa-users] CSN not found In-Reply-To: <65afd1fd-9737-17bf-8af1-47d855f1f53c@redhat.com> References: <4c238a79-e31d-6a7e-ab78-66a6f6f5fe13@yahoo.co.uk> <65afd1fd-9737-17bf-8af1-47d855f1f53c@redhat.com> Message-ID: On 03/11/16 14:16, Mark Reynolds wrote: > > On 11/03/2016 09:42 AM, lejeczek wrote: >> hi everybody >> >> my three IPAs have gone haywire, two things I recall: one - one server >> was on ScientificL with slightly lower minor version of IPA, two - >> another server (of the two identical CEntOSes) had skewed time. >> Not all there servers are in time-sync and all run same version of IPA here I meant: Now all there.... >> but replication broke with errors like: >> >> >> $ ipa-replica-manage re-initialize --from rider --force >> >> .. >> [03/Nov/2016:13:21:08 +0000] NSACLPlugin - The ACL target >> cn=casigningcert >> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=dc=xx,dc=xx,dc=dc=xx,dc=xx,dc=x >> does not exist >> [03/Nov/2016:13:21:08 +0000] NSACLPlugin - The ACL target >> cn=casigningcert >> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=dc=xx,dc=xx,dc=dc=xx,dc=xx,dc=x >> does not exist >> [03/Nov/2016:13:21:09 +0000] agmt="cn=meToswir.xx.xx.xx.xx.x" >> (swir:389) - Can't locate CSN 581b120f000500040000 in the changelog >> (DB rc=-30988). If replication stops, the consumer may need to be >> reinitialized. >> [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - changelog program >> - agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): CSN >> 581b120f000500040000 not found, we aren't as up to date, or we purged >> [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - >> agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): Data required to update >> replica has been purged. The replica must be reinitialized. >> [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - >> agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): Incremental update failed >> and requires administrator action >> >> I did dbscan -f /var.../cb941....db on all three servers and greped >> but cannot see that 581b120f000500040000 >> >> where to troubleshoot? > What version of 389 do you have: > > rpm -qa | grep 389-ds-base > > Did you check the changelog database for 581b120f000500040000: > > dbscan -f /var/lib/dirsrv/slapd-INSTANCE/db/changelogdb results of above scan do not look like that CSN form reported in dirsrv's error log, it is: .. =116156 =116157 =116158 .. > > What about the access logs? Do you see the CSN there? > > I've seen this issue before where a CSN is missing, which breaks the > replication agreements, but the CSN does get added to the changelog > after a few seconds. The only way to fix replication is to restart the > server, or disable/enable the replication agreements(basically restart > them). restarting is not possible for the systemctl start ipa fails, though system start dirsrv at ... succeeds what would be correct process of removing repl agreements? I'm trying disconnect/del but am not sure if this is the way. > Thanks, > Mark >> many thanks. >> L >> From askstack at yahoo.com Thu Nov 3 17:02:13 2016 From: askstack at yahoo.com (Ask Stack) Date: Thu, 3 Nov 2016 17:02:13 +0000 (UTC) Subject: [Freeipa-users] /etc/ipa/default.conf on clients In-Reply-To: References: <1650961303.675208.1478113627546.ref@mail.yahoo.com> <1650961303.675208.1478113627546@mail.yahoo.com> Message-ID: <1132882435.592351.1478192533625@mail.yahoo.com> Thank you, Martin. On Thursday, November 3, 2016 4:12 AM, Martin Basti wrote: On 02.11.2016 20:07, Ask Stack wrote: I need to migrate ipa server from host rhel6.local to? host rhel7.local and retire host rhel6.local . For the existing clients, do I need to change /etc/ipa/default.conf ? Do I even need this file if sssd is working on the clients? Thanks. The current default.conf has two lines pointing to rhel6.local.? #File modified by ipa-client-install [global] basedn = realm = domain = server = rhel6.local xmlrpc_uri = https://rhel6.local/ipa/xml enable_ra = True Hello, this file is required for `ipa`? commands on client Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mareynol at redhat.com Thu Nov 3 19:58:00 2016 From: mareynol at redhat.com (Mark Reynolds) Date: Thu, 3 Nov 2016 15:58:00 -0400 Subject: [Freeipa-users] CSN not found In-Reply-To: References: <4c238a79-e31d-6a7e-ab78-66a6f6f5fe13@yahoo.co.uk> <65afd1fd-9737-17bf-8af1-47d855f1f53c@redhat.com> Message-ID: On 11/03/2016 12:49 PM, lejeczek wrote: > > > On 03/11/16 14:16, Mark Reynolds wrote: >> >> On 11/03/2016 09:42 AM, lejeczek wrote: >>> hi everybody >>> >>> my three IPAs have gone haywire, two things I recall: one - one server >>> was on ScientificL with slightly lower minor version of IPA, two - >>> another server (of the two identical CEntOSes) had skewed time. >>> Not all there servers are in time-sync and all run same version of IPA > here I meant: Now all there.... >>> but replication broke with errors like: >>> >>> >>> $ ipa-replica-manage re-initialize --from rider --force >>> >>> .. >>> [03/Nov/2016:13:21:08 +0000] NSACLPlugin - The ACL target >>> cn=casigningcert >>> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=dc=xx,dc=xx,dc=dc=xx,dc=xx,dc=x >>> >>> does not exist >>> [03/Nov/2016:13:21:08 +0000] NSACLPlugin - The ACL target >>> cn=casigningcert >>> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=dc=xx,dc=xx,dc=dc=xx,dc=xx,dc=x >>> >>> does not exist >>> [03/Nov/2016:13:21:09 +0000] agmt="cn=meToswir.xx.xx.xx.xx.x" >>> (swir:389) - Can't locate CSN 581b120f000500040000 in the changelog >>> (DB rc=-30988). If replication stops, the consumer may need to be >>> reinitialized. >>> [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - changelog program >>> - agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): CSN >>> 581b120f000500040000 not found, we aren't as up to date, or we purged >>> [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - >>> agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): Data required to update >>> replica has been purged. The replica must be reinitialized. >>> [03/Nov/2016:13:21:09 +0000] NSMMReplicationPlugin - >>> agmt="cn=meToswir.xx.xx.xx.xx.x" (swir:389): Incremental update failed >>> and requires administrator action >>> >>> I did dbscan -f /var.../cb941....db on all three servers and greped >>> but cannot see that 581b120f000500040000 >>> >>> where to troubleshoot? >> What version of 389 do you have: >> >> rpm -qa | grep 389-ds-base >> >> Did you check the changelog database for 581b120f000500040000: >> >> dbscan -f /var/lib/dirsrv/slapd-INSTANCE/db/changelogdb > results of above scan do not look like that CSN form reported in > dirsrv's error log, it is: > .. > =116156 > =116157 > =116158 > .. That doesn't look quite right, Just to confirm you should be doing something like dbscan -f /var/lib/dirsrv/slapd-master_1/db/changelogdb/fe665489-a13011e6-acbab8c1-43b12a38_581a3c41000000010000.db | grep 581b120f000500040000 >> >> What about the access logs? Do you see the CSN there? Did you check the DS access logs?? >> >> I've seen this issue before where a CSN is missing, which breaks the >> replication agreements, but the CSN does get added to the changelog >> after a few seconds. The only way to fix replication is to restart the >> server, or disable/enable the replication agreements(basically restart >> them). > restarting is not possible for the systemctl start ipa fails, though > system start dirsrv at ... succeeds I meant restart the directory server, not freeipa: # restart-dirsrv > what would be correct process of removing repl agreements? You don't delete them, you just disable and re-enable them: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10.1/html/Administration_Guide/disabling-replication.html > I'm trying disconnect/del but am not sure if this is the way. > >> Thanks, >> Mark >>> many thanks. >>> L >>> > From frli at paloaltonetworks.com Thu Nov 3 23:58:15 2016 From: frli at paloaltonetworks.com (Frank Li) Date: Thu, 3 Nov 2016 23:58:15 +0000 Subject: [Freeipa-users] any work around for generating CSR to be signed by Microsoft AD CA? Message-ID: I?m aware of the bug filed here but the work around as documented did not work: https://bugzilla.redhat.com/show_bug.cgi?id=1322963 Looking at this ticket: https://fedorahosted.org/freeipa/ticket/5799 It seems that it won?t be fixed until freeipa 4.5. Is there any workaround currently in freeipa 4.2/4.3 to somehow manually generate a CSR that can be recognized by Microsoft ? the ipa-server-install was able to generate a CSR for rootCA signing if one specifies --external-ca-type ms-cs, which works for MS AD CA. but no such option exist for ipa-cacert-manage. details below: I?m trying to upgrade our current IPA installation from self-signed to be signed by the CA operated by IT. So I followed the procedure here to generate the CSR to be signed: http://www.freeipa.org/page/V4/CA_certificate_renewal However, when I submitted the CSR to be signed, the Microsoft Windows 2012R2 ADCA rejected the CSR with this error: Certificate not issued (Denied) Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certi olicy: ipaCSRExport/PANW_Subordinate Certification Authority. The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE) 1401.5098.0:<2016/11/3, 11:11:3>: 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE) 1401.5602.0:<2016/11/3, 11:11:3>: 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE) 1401.16709.0:<2016/11/3, 11:11:3>: 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE) Certificate Request Processor: The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE) Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate Services policy: ipaCSREx nate Certification Authority. here is the what CSR looks like(with keys taken out): Certificate Request: Data: Version: 0 (0x0) Subject: O=XYZ.LOCAL, CN=Certificate Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: Attributes: friendlyName :unable to print attribute Requested Extensions: X509v3 Key Usage: Digital Signature, Non Repudiation, Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: C9:8C:B7:B1:9D:4B:02:E2:74:FD:59:3E:1C:FC:9C:C9:98:EE:81:BD 1.3.6.1.4.1.311.20.2: ...i.p.a.C.S.R.E.x.p.o.r.t Signature Algorithm: sha256WithRSAEncryption I tried the workaround documented on the webpage and asked the CSR to be process via command line certreq. Same error. I?ve also tried this workaround: https://bugzilla.redhat.com/show_bug.cgi?id=1322963 where I manually generated the cert via certutil: # echo -e -n '\x1E\x0A\x00\x53\x00\x75\x00\x62\x00\x43\x00\x41' >ext-value # certutil -R -d /etc/pki/pki-tomcat/alias -f <(grep -Po '(?<=internal=).*' /etc/pki/pki-tomcat/password.conf) -k 'caSigningCert cert-pki-ca' --extGeneric=1.3.6.1.4.1.311.20.2:not-critical:ext-value -o ipa.csr -a which didn?t work either. I?m running IPA version 4.2.0 on Centos 7.2.1511 ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64 Also, If run the ipa-server-install ?external-ca --external-ca-type ms-cs on a test box, it?ll generate a CSR that works, the only difference been that the X509V3 extentions are not there. Exponent: 65537 (0x10001) Attributes: a0:00 so I?m not sure if the same logic that?s used in ipa-server-install can be used in ipa-cacert-manage to generate the renew CSR Please help to generate a correct CSR for Microsoft Windows 2012R2 CA to recognize and sign so I can chain the existing self-signed CA to it. Thanks. -- Efficiency is Intelligent Laziness -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Fri Nov 4 02:59:15 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 3 Nov 2016 22:59:15 -0400 Subject: [Freeipa-users] Kerberos enabled NFS error (Key has expired) Message-ID: Hello I have NFS server that has been working fine with "sec=sys" for years but changed it last weekend to use "sec=krb5" last weekend. Since then, users have been randomly complaining that they are seeing the below error: [alexl at manganese /<7>dtop/simulation/vhdl_example]$ ll /projects/sparrow/meng ls: cannot access /projects/sparrow/meng: Key has expired When I login and try to list the content of the same directory, all works fine. What is the root cause of this error? I have been googling for a week, but haven't found any solution so far. Would appreciate any advice Regards, William From william.muriithi at gmail.com Fri Nov 4 04:55:22 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Fri, 4 Nov 2016 00:55:22 -0400 Subject: [Freeipa-users] Kerberos enabled NFS error (Key has expired) In-Reply-To: References: Message-ID: Morning, I did forget to post the version of software I am using: ipa client: sssd-ipa-1.11.6-30.el6_6.4.x86_64 ipa-client-3.0.0-50.el6_8.3.x86_64 ipa server: ipa-server-4.2.0-15.0.1.el7.centos.18.x86_64 sssd-ipa-1.13.0-40.el7_2.12.x86_64 I have seen discussion of a bug where the key wasn't being renewed but that was back in 2012, so don't look very relevant. William On 3 November 2016 at 22:59, William Muriithi wrote: > Hello > > I have NFS server that has been working fine with "sec=sys" for years > but changed it last weekend to use "sec=krb5" last weekend. Since > then, users have been randomly complaining that they are seeing the > below error: > > [alexl at manganese /<7>dtop/simulation/vhdl_example]$ ll /projects/sparrow/meng > > ls: cannot access /projects/sparrow/meng: Key has expired > > When I login and try to list the content of the same directory, all > works fine. What is the root cause of this error? I have been > googling for a week, but haven't found any solution so far. > > Would appreciate any advice > > Regards, > > William From sbose at redhat.com Fri Nov 4 10:51:26 2016 From: sbose at redhat.com (Sumit Bose) Date: Fri, 4 Nov 2016 11:51:26 +0100 Subject: [Freeipa-users] FreeIPA - AD trust - SSH Public Keys In-Reply-To: <98E0A883-9571-44D8-ADB5-7B9B90540EB7@gmail.com> References: <7A48CD90-0463-4EE3-A525-BBF6C023BF7F@gmail.com> <20161103150531.GF28597@p.Speedport_W_724V_Typ_A_05011603_00_009> <98E0A883-9571-44D8-ADB5-7B9B90540EB7@gmail.com> Message-ID: <20161104105126.GI28597@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, Nov 03, 2016 at 05:23:06PM +0200, Taras Drach wrote: > Thank for reply, > > Unfortunately sssd won?t start with this configuration > > Here is part of log > > (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sdap_extend_map] (0x0200): 1 extra attributes > (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sdap_extend_map] (0x0010): Attribute sshPublicKey (altSecurityIdentities in LDAP) is already used by SSSD, please choose a different cache name Can you check if ldap_user_extra_attrs = originalADsshPublicKey:altSecurityIdentities works any better? bye, Sumit > (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [load_backend_module] (0x0010): Error (1432158241) in module (ipa) initialization (sssm_ipa_id_init)! > (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [be_process_init] (0x0010): fatal error initializing data providers > (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sbus_remove_watch] (0x2000): 0x7f8183df2640/0x7f8183df2420 > > Config changes: > > ldap_user_extra_attrs = sshPublicKey:altSecurityIdentities > # ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities > ldap_user_ssh_public_key = altSecurityIdentities > ldap_id_mapping = False > > > On Nov 3, 2016, at 5:05 PM, Sumit Bose wrote: > > > > sshPublicKey: > From jamesaharrisonuk at yahoo.co.uk Fri Nov 4 11:04:28 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Fri, 4 Nov 2016 11:04:28 +0000 (UTC) Subject: [Freeipa-users] Remove AD domain in auth commands References: <893721809.382437.1478257468370.ref@mail.yahoo.com> Message-ID: <893721809.382437.1478257468370@mail.yahoo.com> Hello, I've installed FreeIPA 4.2 master using Centos and I have a Windows 2012R2 with its AD schema emulating a Windows 2012 system I have established a trust between the two and it appears to work. I can reference a user on the AD domain, but the only way is to add the AD domain. The only way to ssh to the master IPA server is like this: ssh "x_xxxx at IPAWIN.LOCAL"@10.10.10.10 Another example is using kinit: I have to do the following to get a credential:kinit x_xxxx at IPAWIN.LOCAL Ideally I would not need or use the "@IPAWIN.LOCAL". Can anyone help? Best regards,James Harrison -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Nov 4 11:12:46 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 4 Nov 2016 12:12:46 +0100 Subject: [Freeipa-users] Remove AD domain in auth commands In-Reply-To: <893721809.382437.1478257468370@mail.yahoo.com> References: <893721809.382437.1478257468370.ref@mail.yahoo.com> <893721809.382437.1478257468370@mail.yahoo.com> Message-ID: <20161104111246.6eqcddwdjkv4srpi@hendrix> On Fri, Nov 04, 2016 at 11:04:28AM +0000, James Harrison wrote: > Hello, > I've installed FreeIPA 4.2 master using Centos and I have a Windows 2012R2 with its AD schema emulating a Windows 2012 system > I have established a trust between the two and it appears to work. I can reference a user on the AD domain, but the only way is to add the AD domain. > > The only way to ssh to the master IPA server is like this: > > ssh "x_xxxx at IPAWIN.LOCAL"@10.10.10.10 > Another example is using kinit: > I have to do the following to get a credential:kinit x_xxxx at IPAWIN.LOCAL > Ideally I would not need or use the "@IPAWIN.LOCAL". > > Can anyone help? > Best regards,James Harrison Currently the only way is to use default_domain_suffix. This might change in the upcoming version of sssd (1.15) From b.candler at pobox.com Fri Nov 4 11:32:30 2016 From: b.candler at pobox.com (Brian Candler) Date: Fri, 4 Nov 2016 11:32:30 +0000 Subject: [Freeipa-users] mkhomedir difference between ipa master and ipa replica Message-ID: <9d1942f4-050e-e9c2-7e51-1fdcd9bff1fa@pobox.com> I have set up freeipa using CentOS 7 and the default 4.2.0 packages. I found that on the master, the user's home directory is created automatically, but on the replicas it is not. Looking into the contents of /etc/pam.d, the following files are different: fingerprint-auth-ac password-auth-ac smartcard-auth-ac system-auth-ac (two examples below). The replicas don't have the line which invokes pam_oddjob_mkhomedir.so I notice that both ipa-server-install and ipa-replica-install have the following option: --mkhomedir create home directories for users on their first login but I did not supply this option in either case. I believe the actual options I gave were: ipa-server-install --setup-dns ipa-replica-install --setup-ca --setup-dns --forwarder x.x.x.x /var/lib/ipa/replica-info-*.gpg respectively. Is this expected behaviour, or should I raise a ticket? Thanks, Brian Candler. --- fingerprint-auth-ac 2016-11-04 11:23:08.000000000 +0000 +++ fingerprint-auth-ac.replica 2016-11-04 11:23:19.000000000 +0000 @@ -16,7 +16,6 @@ session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so -session optional pam_oddjob_mkhomedir.so umask=0022 skel=/etc/skel 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 --- system-auth-ac 2016-11-04 11:24:13.000000000 +0000 +++ system-auth-ac.replica 2016-11-04 11:24:26.000000000 +0000 @@ -22,7 +22,6 @@ session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so -session optional pam_oddjob_mkhomedir.so umask=0022 skel=/etc/skel 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsdrach at gmail.com Fri Nov 4 11:41:40 2016 From: tsdrach at gmail.com (Taras Drach) Date: Fri, 4 Nov 2016 13:41:40 +0200 Subject: [Freeipa-users] FreeIPA - AD trust - SSH Public Keys In-Reply-To: <20161104105126.GI28597@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <7A48CD90-0463-4EE3-A525-BBF6C023BF7F@gmail.com> <20161103150531.GF28597@p.Speedport_W_724V_Typ_A_05011603_00_009> <98E0A883-9571-44D8-ADB5-7B9B90540EB7@gmail.com> <20161104105126.GI28597@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <3E3714FB-73BF-4A9E-A5C8-755ADC57DF25@gmail.com> Hello Sumit, I?ve tried to use this attr, but still no success Also I found the solutions where sss_ssh_authorizedkeys replaced with custom scripts for queuing ldap and get necessary attribute I think there is hardcoded ?sshPublicKey" in sss_ssh_authorizedkeys. Is there any other way to create some kind of mapping in IPA for this attribute? I see that AD attribute requested and printed its content in the log, but still sss_ssh_authorizedkeys did not print this key to stdout Full trace of sss_ssh_authorizedkeys -d test.loc rr == (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_get_account_info] (0x0200): Got request for [0x1][1][name=rr] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_req_set_domain] (0x0400): Changing request domain from [ipa.test.loc] to [test.loc] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaUserOverride)(uid=rr))]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.4 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaUserOverride)(uid=rr))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=test,dc=loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 6 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 6 timeout 60 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de1415190], ldap[0x7f0de13e8be0] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 6 finished (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaUserOverride)(uid=rr))]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_server_status] (0x1000): Status of server 'dc01.test.loc' is 'working' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_port_status] (0x1000): Port status of port 389 for server 'dc01.test.loc' is 'working' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolve_srv_send] (0x0200): The status of SRV lookup is expired (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [collapse_srv_lookup] (0x0100): Need to refresh SRV lookup for domain Default-First-Site-Name._sites.test.loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_srv_plugin_send] (0x0400): About to find domain controllers (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_get_dc_servers_send] (0x0400): Looking up domain controllers in domain test.loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[(nil)], ldap[0x7f0de13e8be0] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_done] (0x1000): Using TTL [600] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [request_watch_destructor] (0x0400): Deleting request watch (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got answer. Processing... (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got 1 servers (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_get_dc_servers_done] (0x0400): Found 1 domain controllers in domain test.loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_srv_plugin_dcs_done] (0x0400): About to locate suitable site (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_connect_host_send] (0x0400): Resolving host dc01.test.loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_is_address] (0x4000): [dc01.test.loc] does not look like an IP address (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying files (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'dc01.test.loc' in files (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying files (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'dc01.test.loc' in files (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying DNS (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'dc01.test.loc' in DNS (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [request_watch_destructor] (0x0400): Deleting request watch (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_connect_host_resolv_done] (0x0400): Connecting to ldap://dc01.test.loc:389 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sss_ldap_init_send] (0x4000): Using file descriptor [27] for LDAP connection. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://dc01.test.loc:389/??base] with fd [27]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_connect_host_done] (0x0400): Successful connection to ldap://dc01.test.loc:389 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.148 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(DnsDomain=test.loc)(NtVer=\14\00\00\00))][]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [netlogon] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 1 timeout 6 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1417710], connected[1], ops[0x7f0de1411070], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: []. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [netlogon] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1417710], connected[1], ops[0x7f0de1411070], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 1 finished (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f0de1417710], connected[1], ops[(nil)], ldap[0x7f0de13fc080], destructor_lock[0], release_memory[0] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_get_client_site_done] (0x0400): Found site: Default-First-Site-Name (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_srv_plugin_site_done] (0x0400): About to discover primary and backup servers (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_servers_send] (0x0400): Looking up primary servers (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'Default-First-Site-Name._sites.test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.Default-First-Site-Name._sites.test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_done] (0x1000): Using TTL [600] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [request_watch_destructor] (0x0400): Deleting request watch (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got answer. Processing... (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got 1 servers (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_servers_primary_done] (0x0400): Looking up backup servers (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_done] (0x1000): Using TTL [600] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [request_watch_destructor] (0x0400): Deleting request watch (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got answer. Processing... (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got 1 servers (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_srv_plugin_servers_done] (0x0400): Got 1 primary and 1 backup servers (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_add_server_to_list] (0x0400): Inserted primary server 'dc01.test.loc:389' to service 'test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_add_server_to_list] (0x0400): Server 'dc01.test.loc:389' for service 'test.loc' is already present (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'test.loc' as 'resolved' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_server_status] (0x1000): Status of server 'dc01.test.loc' is 'name not resolved' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_is_address] (0x4000): [dc01.test.loc] does not look like an IP address (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying files (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'dc01.test.loc' in files (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [set_server_common_status] (0x0100): Marking server 'dc01.test.loc' as 'resolving name' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying files (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'dc01.test.loc' in files (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying DNS (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'dc01.test.loc' in DNS (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [request_watch_destructor] (0x0400): Deleting request watch (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [set_server_common_status] (0x0100): Marking server 'dc01.test.loc' as 'name resolved' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_resolve_server_process] (0x0200): Found address for server dc01.test.loc: [10.100.0.148] TTL 2108 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://dc01.test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_resolve_callback] (0x0100): Constructed GC uri 'ldap://dc01.test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sss_ldap_init_send] (0x4000): Using file descriptor [27] for LDAP connection. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://dc01.test.loc:389/??base] with fd [27]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.148 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 1 timeout 6 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13fc730], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: []. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [currentTime] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [subschemaSubentry] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [dsServiceName] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultNamingContext] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [schemaNamingContext] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [configurationNamingContext] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [rootDomainNamingContext] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPPolicies] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [highestCommittedUSN] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [dnsHostName] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [ldapServiceName] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [serverName] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedCapabilities] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [isSynchronized] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [isGlobalCatalogReady] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [domainFunctionality] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [forestFunctionality] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [domainControllerFunctionality] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13fc730], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 1 finished (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_rootdse_done] (0x2000): Got rootdse (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 16849 (int: 16849) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level to [6] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/ipa42.ipa.test.loc, AWS.SLT.LOC, 86400) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service test.loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'test.loc' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_server_status] (0x1000): Status of server 'dc01.test.loc' is 'name resolved' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_server_status] (0x1000): Status of server 'dc01.test.loc' is 'name resolved' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_resolve_server_process] (0x0200): Found address for server dc01.test.loc: [10.100.0.148] TTL 2108 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [create_tgt_req_send_buffer] (0x0400): buffer size: 57 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [31250] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [child_handler_setup] (0x2000): Signal handler set up for pid [31250] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[(nil)], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [write_pipe_handler] (0x0400): All data has been sent! (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [child_sig_handler] (0x1000): Waiting for child [31250]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [child_sig_handler] (0x0100): child [31250] finished successfully. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [read_pipe_handler] (0x0400): EOF received, client finished (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_AWS.SLT.LOC], expired on [1478344941] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1478259441 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: host/ipa42.ipa.test.loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_WORKING. Called from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv: 2036 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'dc01.test.loc' as 'working' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [set_server_common_status] (0x0100): Marking server 'dc01.test.loc' as 'working' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'dc01.test.loc' as 'working' (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_done] (0x2000): Old USN: 16844, New USN: 16849 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #1 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [dc=test,dc=loc] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.148 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=rr)(objectclass=user)(sAMAccountName=*)(objectSID=*))][dc=test,dc=loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altSecurityIdentities] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 5 timeout 6 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_done] (0x4000): caching successful connection after 1 notifies (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_run_unconditional_online_cb] (0x0400): Running unconditional online callbacks. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=rr,CN=Users,DC=test,DC=loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [whenChanged] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [uSNChanged] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [name] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectGUID] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [userAccountControl] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [primaryGroupID] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectSid] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [accountExpires] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [sAMAccountName] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [userPrincipalName] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [altSecurityIdentities] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://ForestDnsZones.test.loc/DC=ForestDnsZones,DC=test,DC=loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://DomainDnsZones.test.loc/DC=DomainDnsZones,DC=test,DC=loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://test.loc/CN=Configuration,DC=test,DC=loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 5 finished (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Request included referrals which were ignored. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Ref: ldap://ForestDnsZones.test.loc/DC=ForestDnsZones,DC=test,DC=loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Ref: ldap://DomainDnsZones.test.loc/DC=DomainDnsZones,DC=test,DC=loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Ref: ldap://test.loc/CN=Configuration,DC=test,DC=loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_search_user_process] (0x0400): Search for users, returned 1 results. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_search_user_process] (0x4000): Retrieved total 1 users (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Save user (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_primary_name] (0x0400): Processing object rr at test.loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Processing user rr at test.loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x1000): Mapping user [rr at test.loc] objectSID [S-1-5-21-237804563-1161820721-801220523-1106] to unix ID (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x2000): Adding originalDN [CN=rr,CN=Users,DC=test,DC=loc] to attributes of [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Original memberOf is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20161103142350.0Z] to attributes of [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Adding user principal [rr at SLT.LOC] to attributes of [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowLastChange is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMin is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMax is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowWarning is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowInactive is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowExpire is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowFlag is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): krbLastPwdChange is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): krbPasswordExpiration is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): pwdAttribute is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedService is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding adAccountExpires [9223372036854775807] to attributes of [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding adUserAccountControl [66048] to attributes of [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): nsAccountLock is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedHost is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginDisabled is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginExpirationTime is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginAllowedTimeMap is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): authType is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): userCertificate is not available for [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding originalADsshPublicKey [ssh-rsa\20AAAAB3NzaC1yc2EAAAADAQABAAABAQDQydFCKx/r5idp3U0EY0fMJdu0eHNuIc6xvZudQJm/mbf3TflLNH+mj/Jr7yQaPj0C6z7V8my+D0f6JK1cCntxfhLQto92xUZhhKoLHVO34f5DhC5etqZ4EtaD6j9QuXYc5U8GovHgzmdH+JSeIOSpSqFzTkFR6sSmhjypfCDPCP8JKHxwI9LJvfgCRv0qKJBjELhUpZYUW3Mrcpp+bJcX8Iuz0QPDkO2VdqIcwapC+h6AhdH+Sm6PjG8FplH6/5SDlQ2LOVTnY4xMuS48RXzgtJImN+o7syrxjPTQU5/PWXiIH/Hawa6n75kREv6B4AHtQKxqDoxhNdzQ1+xiLs4H\20user at test.loc] to attributes of [rr at test.loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add lowercased aliases (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Storing info for user rr at test.loc (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1434da0 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1434ed0 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1434da0 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1434ed0 "ltdb_timeout" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1434da0 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sysdb_search_by_name] (0x0400): No such entry (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 2) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1445110 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1435ae0 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1445110 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1435ae0 "ltdb_timeout" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1445110 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sysdb_search_by_name] (0x0400): No such entry (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de143b020 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de13f5b20 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de143b020 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de13f5b20 "ltdb_timeout" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de143b020 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sysdb_search_user_by_uid] (0x0400): No such entry (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1445690 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1444c50 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1445690 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1444c50 "ltdb_timeout" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1445690 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 3) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1440550 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1435c90 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1440550 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1435c90 "ltdb_timeout" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1440550 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1445d20 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de13f5b20 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1445d20 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de13f5b20 "ltdb_timeout" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1445d20 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_users] (0x4000): User 0 processed! (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_users_done] (0x4000): Saving 1 Users - Done (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_done] (0x4000): releasing operation connection (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de13fa1b0 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de13fa2e0 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de13fa1b0 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de13fa2e0 "ltdb_timeout" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de13fa1b0 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [apply_subdomain_homedir] (0x4000): Missing homedir of rr at test.loc. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1419a10 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1435570 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1419a10 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1435570 "ltdb_timeout" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1419a10 "ltdb_callback" (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-237804563-1161820721-801220523-1106))]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.4 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-237804563-1161820721-801220523-1106))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=test,dc=loc]. (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 7 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 7 timeout 60 (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[(nil)], ldap[0x7f0de13fc080] (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ipa_subdom_reset_timeouts_cb] (0x4000): Resetting last_refreshed and disabled_until. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de1415190], ldap[0x7f0de13e8be0] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 7 finished (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-237804563-1161820721-801220523-1106))]. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de13fa4e0 (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1419d50 (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de13fa4e0 "ltdb_callback" (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1419d50 "ltdb_timeout" (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de13fa4e0 "ltdb_callback" (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.4 (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectClass=ipaexternalgroup][dc=ipa,dc=test,dc=loc]. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 8 timeout 60 (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=ab,cn=groups,cn=compat,dc=ipa,dc=test,dc=loc]. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaAnchorUUID] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=Default SMB Group,cn=groups,cn=compat,dc=ipa,dc=test,dc=loc]. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaAnchorUUID] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=editors,cn=groups,cn=compat,dc=ipa,dc=test,dc=loc]. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaAnchorUUID] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=admins,cn=groups,cn=compat,dc=ipa,dc=test,dc=loc]. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaAnchorUUID] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberUid] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 8 finished (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ipa_get_ext_groups_done] (0x0400): [4] external groups found. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1444a10 (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1444b40 (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1444a10 "ltdb_callback" (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1444b40 "ltdb_timeout" (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1444a10 "ltdb_callback" (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1444a10 (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de14457f0 (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1444a10 "ltdb_callback" (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de14457f0 "ltdb_timeout" (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1444a10 "ltdb_callback" (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [find_ipa_ext_memberships] (0x4000): SID [S-1-5-21-237804563-1161820721-801220523-1106] not found in ext group hash. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [find_ipa_ext_memberships] (0x0400): No external groupmemberships found. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ipa_add_ext_groups_step] (0x4000): No external groups memberships found. (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[(nil)], ldap[0x7f0de13e8be0] (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > On Nov 4, 2016, at 12:51 PM, Sumit Bose wrote: > > On Thu, Nov 03, 2016 at 05:23:06PM +0200, Taras Drach wrote: >> Thank for reply, >> >> Unfortunately sssd won?t start with this configuration >> >> Here is part of log >> >> (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sdap_extend_map] (0x0200): 1 extra attributes >> (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sdap_extend_map] (0x0010): Attribute sshPublicKey (altSecurityIdentities in LDAP) is already used by SSSD, please choose a different cache name > > Can you check if > > ldap_user_extra_attrs = originalADsshPublicKey:altSecurityIdentities > > works any better? > > bye, > Sumit > >> (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [load_backend_module] (0x0010): Error (1432158241) in module (ipa) initialization (sssm_ipa_id_init)! >> (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [be_process_init] (0x0010): fatal error initializing data providers >> (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sbus_remove_watch] (0x2000): 0x7f8183df2640/0x7f8183df2420 >> >> Config changes: >> >> ldap_user_extra_attrs = sshPublicKey:altSecurityIdentities >> # ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities >> ldap_user_ssh_public_key = altSecurityIdentities >> ldap_id_mapping = False >> >>> On Nov 3, 2016, at 5:05 PM, Sumit Bose wrote: >>> >>> sshPublicKey: >> > > From b.candler at pobox.com Fri Nov 4 11:52:44 2016 From: b.candler at pobox.com (Brian Candler) Date: Fri, 4 Nov 2016 11:52:44 +0000 Subject: [Freeipa-users] mkhomedir difference between ipa master and ipa replica In-Reply-To: <9d1942f4-050e-e9c2-7e51-1fdcd9bff1fa@pobox.com> References: <9d1942f4-050e-e9c2-7e51-1fdcd9bff1fa@pobox.com> Message-ID: <90b71dd2-da83-f043-15e8-796de6239e81@pobox.com> On 04/11/2016 11:32, Brian Candler wrote: > > I notice that both ipa-server-install and ipa-replica-install have the > following option: > > --mkhomedir create home directories for users on their > first login > > but I did not supply this option in either case. I believe the actual > options I gave were: > > ipa-server-install --setup-dns > ipa-replica-install --setup-ca --setup-dns --forwarder x.x.x.x > /var/lib/ipa/replica-info-*.gpg > > respectively. Is this expected behaviour, or should I raise a ticket? > Supplementary note for the benefit of the list: I tried manually updating the replica machines' PAM configurations to match, but I then got this error org.freedesktop.DBus.Error.ServiceUnknown: The name com.redhat.oddjob_mkhomedir was not provided by any .service files Last login: Fri Nov 4 11:36:07 2016 from x.x.x.x Could not chdir to home directory /home/brian.candler: No such file or directory All the machines had the same packages installed, including the "oddjob-mkhomedir" package. But the slaves were missing a single symlink. Solution was: ln -s /usr/lib/systemd/system/oddjobd.service /etc/systemd/system/multi-user.target.wants/oddjobd.service Regards, Brian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Nov 4 12:20:56 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 4 Nov 2016 13:20:56 +0100 Subject: [Freeipa-users] mkhomedir difference between ipa master and ipa replica In-Reply-To: <90b71dd2-da83-f043-15e8-796de6239e81@pobox.com> References: <9d1942f4-050e-e9c2-7e51-1fdcd9bff1fa@pobox.com> <90b71dd2-da83-f043-15e8-796de6239e81@pobox.com> Message-ID: On 11/04/2016 12:52 PM, Brian Candler wrote: > On 04/11/2016 11:32, Brian Candler wrote: >> >> I notice that both ipa-server-install and ipa-replica-install have the >> following option: >> >> --mkhomedir create home directories for users on their first login >> >> but I did not supply this option in either case. I believe the actual options >> I gave were: >> >> ipa-server-install --setup-dns >> ipa-replica-install --setup-ca --setup-dns --forwarder x.x.x.x >> /var/lib/ipa/replica-info-*.gpg >> >> respectively. Is this expected behaviour, or should I raise a ticket? >> > Supplementary note for the benefit of the list: I tried manually updating the > replica machines' PAM configurations to match, but I then got this error > > org.freedesktop.DBus.Error.ServiceUnknown: The name com.redhat.oddjob_mkhomedir > was not provided by any .service files > Last login: Fri Nov 4 11:36:07 2016 from x.x.x.x > Could not chdir to home directory /home/brian.candler: No such file or directory > > All the machines had the same packages installed, including the > "oddjob-mkhomedir" package. But the slaves were missing a single symlink. > Solution was: > > ln -s /usr/lib/systemd/system/oddjobd.service > /etc/systemd/system/multi-user.target.wants/oddjobd.service > > Regards, > > Brian. > Both server and replica should pass this option to client installer which is executed as a part of server or replica installation. Before filing bugs, it would be good to check what/if something happened. Client installer configures creation of home dir in standard way. Meaning it calls something like: # authconfig --enablemkhomedir --update You can check with what options authconfig was called by: # cat /var/log/ipaclient-install.log | grep authconfig if --enablemkhomedir is not there then it is possible that something else enabled it. -- Petr Vobornik From solerm at unicc.org Fri Nov 4 12:22:40 2016 From: solerm at unicc.org (SOLER SANGUESA Miguel) Date: Fri, 4 Nov 2016 12:22:40 +0000 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds Message-ID: <9f086449c4524caf96baab9efa8f24f2@ICCM01.GMS05.unicc.org> Hello, I'm updating the topic, because I have the same problem with: $ ipa --version VERSION: 4.2.0, API_VERSION: 2.156 On RHEL 7.2 For Opera and Chrome (latest versions) the pop up appears, but not in Firefox (last version). The configuration is in /var/log/httpd/access_log: ... # Protect /ipa and everything below it in webspace with Apache Kerberos auth AuthType GSSAPI AuthName "Kerberos Login" GssapiCredStore keytab:/etc/httpd/conf/ipa.keytab GssapiCredStore client_keytab:/etc/httpd/conf/ipa.keytab GssapiDelegCcacheDir /var/run/httpd/ipa/clientcaches GssapiUseS4U2Proxy on Require valid-user ErrorDocument 401 /ipa/errors/unauthorized.html WSGIProcessGroup ipa WSGIApplicationGroup ipa ... It can not be deleted because it is used when it is used the console commands, but has anyone a workaround to disable it on the web GUI? Thanks & Regards. ______________________________ Miguel Soler Sang?esa -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Nov 4 13:24:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 4 Nov 2016 14:24:47 +0100 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds In-Reply-To: <9f086449c4524caf96baab9efa8f24f2@ICCM01.GMS05.unicc.org> References: <9f086449c4524caf96baab9efa8f24f2@ICCM01.GMS05.unicc.org> Message-ID: <3b405a52-f0ab-733f-8e10-76f77e9236e1@redhat.com> On 04.11.2016 13:22, SOLER SANGUESA Miguel wrote: > > Hello, > > I?m updating the topic, because I have the same problem with: > > $ ipa --version > > VERSION: 4.2.0, API_VERSION: 2.156 > > On RHEL 7.2 > > For Opera and Chrome (latest versions) the pop up appears, but not in > Firefox (last version). The configuration is in /var/log/httpd/access_log: > > ? > > # Protect /ipa and everything below it in webspace with Apache > Kerberos auth > > > > AuthType GSSAPI > > AuthName "Kerberos Login" > > GssapiCredStore keytab:/etc/httpd/conf/ipa.keytab > > GssapiCredStore client_keytab:/etc/httpd/conf/ipa.keytab > > GssapiDelegCcacheDir /var/run/httpd/ipa/clientcaches > > GssapiUseS4U2Proxy on > > Require valid-user > > ErrorDocument 401 /ipa/errors/unauthorized.html > > WSGIProcessGroup ipa > > WSGIApplicationGroup ipa > > > > ? > > It can not be deleted because it is used when it is used the console > commands, but has anyone a workaround to disable it on the web GUI? > > Thanks & Regards. > > ______________________________ > > *Miguel Soler Sang?esa* > > > Hello, this was fixed in RHEL7.3, is not possible to backport fix in RHEL7.2, as it requires newer version of mod_gssapi Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.candler at pobox.com Fri Nov 4 13:42:40 2016 From: b.candler at pobox.com (Brian Candler) Date: Fri, 4 Nov 2016 13:42:40 +0000 Subject: [Freeipa-users] mkhomedir difference between ipa master and ipa replica In-Reply-To: References: <9d1942f4-050e-e9c2-7e51-1fdcd9bff1fa@pobox.com> <90b71dd2-da83-f043-15e8-796de6239e81@pobox.com> Message-ID: <578f5c8a-6dab-313b-0099-dab859f1fc62@pobox.com> On 04/11/2016 12:20, Petr Vobornik wrote: > You can check with what options authconfig was called by: > # cat /var/log/ipaclient-install.log | grep authconfig > > if --enablemkhomedir is not there then it is possible that something > else enabled it. It's not there: $ sudo cat /var/log/ipaclient-install.log | grep authconfig [sudo] password for brian.candler: 2016-10-27T15:30:44Z DEBUG args='/usr/sbin/authconfig' '--enablesssdauth' '--update' '--enablesssd' 2016-10-27T15:30:44Z DEBUG args='/usr/sbin/authconfig' '--update' '--nisdomain' 'ipa.example.com' And: $ sudo cat /var/log/ipaclient-install.log | grep mkhome 2016-10-27T15:30:38Z DEBUG /usr/sbin/ipa-client-install was invoked with options: {'domain': 'ipa.example.com', 'force': False, 'krb5_offline_passwords': True, 'ip_addresses': [], 'configure_firefox': False, 'primary': False, 'realm_name': 'IPA.EXAMPLE.COM', 'force_ntpd': False, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'on_master': True, 'no_nisdomain': False, 'nisdomain': None, 'ca_cert_file': None, 'principal': None, 'keytab': None, 'hostname': 'ipa-1.int.example.com', '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': False, 'firefox_dir': None, 'server': ['ipa-1.int.example.com'], 'prompt_password': False, 'permit': False, 'debug': False, 'preserve_sssd': False, 'mkhomedir': False, 'uninstall': False} This server has been through several iterations of ipa-server-install / ipa-server-uninstall. It is possible that one of the earlier incantations was done with --mkhomedir, since I didn't do the first one. Next time I do a fresh, clean IPA install I will check the PAM configuration. (Although in that case, perhaps ipa-server-uninstall is not cleaning up fully after itself?) Regards, Brian. From pvoborni at redhat.com Fri Nov 4 14:00:21 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 4 Nov 2016 15:00:21 +0100 Subject: [Freeipa-users] mkhomedir difference between ipa master and ipa replica In-Reply-To: <578f5c8a-6dab-313b-0099-dab859f1fc62@pobox.com> References: <9d1942f4-050e-e9c2-7e51-1fdcd9bff1fa@pobox.com> <90b71dd2-da83-f043-15e8-796de6239e81@pobox.com> <578f5c8a-6dab-313b-0099-dab859f1fc62@pobox.com> Message-ID: <47e15084-b4bb-e269-b5dc-4c1af35d1f41@redhat.com> On 11/04/2016 02:42 PM, Brian Candler wrote: > On 04/11/2016 12:20, Petr Vobornik wrote: >> You can check with what options authconfig was called by: >> # cat /var/log/ipaclient-install.log | grep authconfig >> >> if --enablemkhomedir is not there then it is possible that something >> else enabled it. > > It's not there: > > $ sudo cat /var/log/ipaclient-install.log | grep authconfig > [sudo] password for brian.candler: > 2016-10-27T15:30:44Z DEBUG args='/usr/sbin/authconfig' > '--enablesssdauth' '--update' '--enablesssd' > 2016-10-27T15:30:44Z DEBUG args='/usr/sbin/authconfig' '--update' > '--nisdomain' 'ipa.example.com' > > And: > > $ sudo cat /var/log/ipaclient-install.log | grep mkhome > 2016-10-27T15:30:38Z DEBUG /usr/sbin/ipa-client-install was invoked with > options: {'domain': 'ipa.example.com', 'force': False, > 'krb5_offline_passwords': True, 'ip_addresses': [], 'configure_firefox': > False, 'primary': False, 'realm_name': 'IPA.EXAMPLE.COM', 'force_ntpd': > False, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, > 'on_master': True, 'no_nisdomain': False, 'nisdomain': None, > 'ca_cert_file': None, 'principal': None, 'keytab': None, 'hostname': > 'ipa-1.int.example.com', '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': False, 'firefox_dir': None, 'server': > ['ipa-1.int.example.com'], 'prompt_password': False, 'permit': False, > 'debug': False, 'preserve_sssd': False, 'mkhomedir': False, 'uninstall': > False} > > This server has been through several iterations of ipa-server-install / > ipa-server-uninstall. It is possible that one of the earlier > incantations was done with --mkhomedir, since I didn't do the first one. > > Next time I do a fresh, clean IPA install I will check the PAM > configuration. > (Although in that case, perhaps ipa-server-uninstall is > not cleaning up fully after itself?) That may be possible. > > Regards, > > Brian. > -- Petr Vobornik From julliot at ljll.math.upmc.fr Fri Nov 4 14:09:50 2016 From: julliot at ljll.math.upmc.fr (Sebastien Julliot) Date: Fri, 4 Nov 2016 15:09:50 +0100 Subject: [Freeipa-users] Setting sssd for webui In-Reply-To: References: Message-ID: <3f0aac57-6324-2119-a7b7-f623b312db96@ljll.math.upmc.fr> Hello everyone, As I explained you some time ago, I have been skirting the ipa's limitation to setting pre-hashed passwords by using ldappasswd. (I know you guys think it's wrong. In this case the hashes come from an other ldap which, for intern reasons, we can not synchronize with otherwise than by frequent ldif extractions. So it's the only solution to have unified passwords) To have the kerberos key generated, I can ask the users to do an ldapsearch or to ssh on a machine with sssd enabled. Yet, as most users will mainly want to use the WebUi, I am looking for a way to have them able to connect to it without needing to do an ldapsearch first. To be precise, I set the userPassword field using ldappasswd, and delete the krbprincipalkey. Do you see any way to make the webui directly authenticable ? Thanks, Sebastien Julliot. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From sbose at redhat.com Fri Nov 4 14:25:27 2016 From: sbose at redhat.com (Sumit Bose) Date: Fri, 4 Nov 2016 15:25:27 +0100 Subject: [Freeipa-users] FreeIPA - AD trust - SSH Public Keys In-Reply-To: <3E3714FB-73BF-4A9E-A5C8-755ADC57DF25@gmail.com> References: <7A48CD90-0463-4EE3-A525-BBF6C023BF7F@gmail.com> <20161103150531.GF28597@p.Speedport_W_724V_Typ_A_05011603_00_009> <98E0A883-9571-44D8-ADB5-7B9B90540EB7@gmail.com> <20161104105126.GI28597@p.Speedport_W_724V_Typ_A_05011603_00_009> <3E3714FB-73BF-4A9E-A5C8-755ADC57DF25@gmail.com> Message-ID: <20161104142527.GJ28597@p.Speedport_W_724V_Typ_A_05011603_00_009> On Fri, Nov 04, 2016 at 01:41:40PM +0200, Taras Drach wrote: > Hello Sumit, > I?ve tried to use this attr, but still no success > > Also I found the solutions where sss_ssh_authorizedkeys replaced with custom scripts for queuing ldap and get necessary attribute > I think there is hardcoded ?sshPublicKey" in sss_ssh_authorizedkeys. yes, sshPublicKey is hardcoded but originalADsshPublicKey should be handled as well. I just found that there is a bug which prevents the ssh responder to handle it as expected. In general the attribute names in SSSD's cache are hardcoded. What is configurable is which server side LDAP attributed is stored in a specific cache attribute (all the ldap_user_* and ldap_group_* attributes can be used for this. ldap_user_extra_attrs is special to allow to stored arbitrary attributes in the cache. But since the hardcoded cache attributes typically have special use-cases they cannot be overridden, this is why you have seen the error message with sshPublicKey. originalADsshPublicKey has some special instal use-case as well, but currently it is not in the list of attributes which is checked. Nevertheless there is the bug I mentioned earlier which make the lookup fail as well. The intended way to solve all this is to use "ldap_user_ssh_public_key = altSecurityIdentities" which I expect to work in the case where the client is joined directly to an AD domain. With IPA and trust this is unfortunately a bit different. The ldap_user_ssh_public_key will only change the attribute name for the IPA domain but not for the trusted AD domain because options are not inherited by default. Additionally changing the attribute name for the IPA domain will prevent SSSD from reading the SSH keys stored in the IPA server. The proper solution would be domain specific configuration options which is tracked by https://fedorahosted.org/sssd/ticket/2599 . Nevertheless I try to fix the bug I mentioned earlier and will prepare a test-build with a fix at the beginning of the next week. HTH bye, Sumit > Is there any other way to create some kind of mapping in IPA for this attribute? > I see that AD attribute requested and printed its content in the log, but still sss_ssh_authorizedkeys did not print this key to stdout > > Full trace of > sss_ssh_authorizedkeys -d test.loc rr > == > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_get_account_info] (0x0200): Got request for [0x1][1][name=rr] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_req_set_domain] (0x0400): Changing request domain from [ipa.test.loc] to [test.loc] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaUserOverride)(uid=rr))]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.4 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaUserOverride)(uid=rr))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=test,dc=loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 6 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 6 timeout 60 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de1415190], ldap[0x7f0de13e8be0] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 6 finished > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaUserOverride)(uid=rr))]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] (0x4000): beginning to connect > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_server_status] (0x1000): Status of server 'dc01.test.loc' is 'working' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_port_status] (0x1000): Port status of port 389 for server 'dc01.test.loc' is 'working' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolve_srv_send] (0x0200): The status of SRV lookup is expired > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [collapse_srv_lookup] (0x0100): Need to refresh SRV lookup for domain Default-First-Site-Name._sites.test.loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_srv_plugin_send] (0x0400): About to find domain controllers > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_get_dc_servers_send] (0x0400): Looking up domain controllers in domain test.loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[(nil)], ldap[0x7f0de13e8be0] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_done] (0x1000): Using TTL [600] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [request_watch_destructor] (0x0400): Deleting request watch > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got answer. Processing... > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got 1 servers > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_get_dc_servers_done] (0x0400): Found 1 domain controllers in domain test.loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_srv_plugin_dcs_done] (0x0400): About to locate suitable site > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_connect_host_send] (0x0400): Resolving host dc01.test.loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_is_address] (0x4000): [dc01.test.loc] does not look like an IP address > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying files > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'dc01.test.loc' in files > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying files > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'dc01.test.loc' in files > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying DNS > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'dc01.test.loc' in DNS > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [request_watch_destructor] (0x0400): Deleting request watch > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_connect_host_resolv_done] (0x0400): Connecting to ldap://dc01.test.loc:389 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sss_ldap_init_send] (0x4000): Using file descriptor [27] for LDAP connection. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://dc01.test.loc:389/??base] with fd [27]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_connect_host_done] (0x0400): Successful connection to ldap://dc01.test.loc:389 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.148 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(DnsDomain=test.loc)(NtVer=\14\00\00\00))][]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [netlogon] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 1 timeout 6 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1417710], connected[1], ops[0x7f0de1411070], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: []. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [netlogon] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1417710], connected[1], ops[0x7f0de1411070], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 1 finished > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f0de1417710], connected[1], ops[(nil)], ldap[0x7f0de13fc080], destructor_lock[0], release_memory[0] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_get_client_site_done] (0x0400): Found site: Default-First-Site-Name > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_srv_plugin_site_done] (0x0400): About to discover primary and backup servers > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_servers_send] (0x0400): Looking up primary servers > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'Default-First-Site-Name._sites.test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.Default-First-Site-Name._sites.test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_done] (0x1000): Using TTL [600] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [request_watch_destructor] (0x0400): Deleting request watch > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got answer. Processing... > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got 1 servers > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_servers_primary_done] (0x0400): Looking up backup servers > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_getsrv_done] (0x1000): Using TTL [600] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [request_watch_destructor] (0x0400): Deleting request watch > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got answer. Processing... > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_discover_srv_done] (0x0400): Got 1 servers > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_srv_plugin_servers_done] (0x0400): Got 1 primary and 1 backup servers > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_add_server_to_list] (0x0400): Inserted primary server 'dc01.test.loc:389' to service 'test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_add_server_to_list] (0x0400): Server 'dc01.test.loc:389' for service 'test.loc' is already present > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'test.loc' as 'resolved' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_server_status] (0x1000): Status of server 'dc01.test.loc' is 'name not resolved' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_is_address] (0x4000): [dc01.test.loc] does not look like an IP address > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying files > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'dc01.test.loc' in files > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [set_server_common_status] (0x0100): Marking server 'dc01.test.loc' as 'resolving name' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying files > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'dc01.test.loc' in files > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_step] (0x2000): Querying DNS > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'dc01.test.loc' in DNS > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [request_watch_destructor] (0x0400): Deleting request watch > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [set_server_common_status] (0x0100): Marking server 'dc01.test.loc' as 'name resolved' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_resolve_server_process] (0x1000): Saving the first resolved server > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_resolve_server_process] (0x0200): Found address for server dc01.test.loc: [10.100.0.148] TTL 2108 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://dc01.test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_resolve_callback] (0x0100): Constructed GC uri 'ldap://dc01.test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sss_ldap_init_send] (0x4000): Using file descriptor [27] for LDAP connection. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://dc01.test.loc:389/??base] with fd [27]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.148 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 1 timeout 6 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13fc730], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: []. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [currentTime] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [subschemaSubentry] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [dsServiceName] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultNamingContext] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [schemaNamingContext] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [configurationNamingContext] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [rootDomainNamingContext] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPPolicies] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [highestCommittedUSN] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [dnsHostName] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [ldapServiceName] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [serverName] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedCapabilities] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [isSynchronized] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [isGlobalCatalogReady] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [domainFunctionality] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [forestFunctionality] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [domainControllerFunctionality] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13fc730], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 1 finished > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_rootdse_done] (0x2000): Got rootdse > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 16849 (int: 16849) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level to [6] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/ipa42.ipa.test.loc, AWS.SLT.LOC, 86400) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service test.loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'test.loc' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_server_status] (0x1000): Status of server 'dc01.test.loc' is 'name resolved' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_server_status] (0x1000): Status of server 'dc01.test.loc' is 'name resolved' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_resolve_server_process] (0x1000): Saving the first resolved server > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_resolve_server_process] (0x0200): Found address for server dc01.test.loc: [10.100.0.148] TTL 2108 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [create_tgt_req_send_buffer] (0x0400): buffer size: 57 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [31250] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [child_handler_setup] (0x2000): Signal handler set up for pid [31250] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[(nil)], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [write_pipe_handler] (0x0400): All data has been sent! > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [child_sig_handler] (0x1000): Waiting for child [31250]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [child_sig_handler] (0x0100): child [31250] finished successfully. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [read_pipe_handler] (0x0400): EOF received, client finished > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_AWS.SLT.LOC], expired on [1478344941] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1478259441 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: host/ipa42.ipa.test.loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_WORKING. Called from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv: 2036 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'dc01.test.loc' as 'working' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [set_server_common_status] (0x0100): Marking server 'dc01.test.loc' as 'working' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'dc01.test.loc' as 'working' > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_done] (0x2000): Old USN: 16844, New USN: 16849 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #1 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [dc=test,dc=loc] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.148 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=rr)(objectclass=user)(sAMAccountName=*)(objectSID=*))][dc=test,dc=loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altSecurityIdentities] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 5 timeout 6 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_done] (0x4000): caching successful connection after 1 notifies > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_run_unconditional_online_cb] (0x0400): Running unconditional online callbacks. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=rr,CN=Users,DC=test,DC=loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [whenChanged] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [uSNChanged] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [name] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectGUID] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [userAccountControl] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [primaryGroupID] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectSid] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [accountExpires] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [sAMAccountName] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [userPrincipalName] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [altSecurityIdentities] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://ForestDnsZones.test.loc/DC=ForestDnsZones,DC=test,DC=loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://DomainDnsZones.test.loc/DC=DomainDnsZones,DC=test,DC=loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://test.loc/CN=Configuration,DC=test,DC=loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 5 finished > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Request included referrals which were ignored. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Ref: ldap://ForestDnsZones.test.loc/DC=ForestDnsZones,DC=test,DC=loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Ref: ldap://DomainDnsZones.test.loc/DC=DomainDnsZones,DC=test,DC=loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [generic_ext_search_handler] (0x4000): Ref: ldap://test.loc/CN=Configuration,DC=test,DC=loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_search_user_process] (0x0400): Search for users, returned 1 results. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_search_user_process] (0x4000): Retrieved total 1 users > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Save user > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_primary_name] (0x0400): Processing object rr at test.loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Processing user rr at test.loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x1000): Mapping user [rr at test.loc] objectSID [S-1-5-21-237804563-1161820721-801220523-1106] to unix ID > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x2000): Adding originalDN [CN=rr,CN=Users,DC=test,DC=loc] to attributes of [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Original memberOf is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20161103142350.0Z] to attributes of [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Adding user principal [rr at SLT.LOC] to attributes of [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowLastChange is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMin is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMax is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowWarning is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowInactive is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowExpire is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowFlag is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): krbLastPwdChange is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): krbPasswordExpiration is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): pwdAttribute is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedService is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding adAccountExpires [9223372036854775807] to attributes of [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding adUserAccountControl [66048] to attributes of [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): nsAccountLock is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedHost is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginDisabled is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginExpirationTime is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginAllowedTimeMap is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): authType is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): userCertificate is not available for [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding originalADsshPublicKey [ssh-rsa\20AAAAB3NzaC1yc2EAAAADAQABAAABAQDQydFCKx/r5idp3U0EY0fMJdu0eHNuIc6xvZudQJm/mbf3TflLNH+mj/Jr7yQaPj0C6z7V8my+D0f6JK1cCntxfhLQto92xUZhhKoLHVO34f5DhC5etqZ4EtaD6j9QuXYc5U8GovHgzmdH+JSeIOSpSqFzTkFR6sSmhjypfCDPCP8JKHxwI9LJvfgCRv0qKJBjELhUpZYUW3Mrcpp+bJcX8Iuz0QPDkO2VdqIcwapC+h6AhdH+Sm6PjG8FplH6/5SDlQ2LOVTnY4xMuS48RXzgtJImN+o7syrxjPTQU5/PWXiIH/Hawa6n75kREv6B4AHtQKxqDoxhNdzQ1+xiLs4H\20user at test.loc] to attributes of [rr at test.loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add lowercased aliases > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_user] (0x0400): Storing info for user rr at test.loc > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1434da0 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1434ed0 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1434da0 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1434ed0 "ltdb_timeout" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1434da0 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sysdb_search_by_name] (0x0400): No such entry > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 2) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1445110 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1435ae0 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1445110 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1435ae0 "ltdb_timeout" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1445110 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sysdb_search_by_name] (0x0400): No such entry > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de143b020 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de13f5b20 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de143b020 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de13f5b20 "ltdb_timeout" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de143b020 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sysdb_search_user_by_uid] (0x0400): No such entry > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1445690 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1444c50 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1445690 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1444c50 "ltdb_timeout" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1445690 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 3) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1440550 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1435c90 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1440550 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1435c90 "ltdb_timeout" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1440550 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 3) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1445d20 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de13f5b20 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1445d20 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de13f5b20 "ltdb_timeout" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1445d20 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_save_users] (0x4000): User 0 processed! > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_users_done] (0x4000): Saving 1 Users - Done > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de13fa1b0 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de13fa2e0 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de13fa1b0 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de13fa2e0 "ltdb_timeout" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de13fa1b0 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [apply_subdomain_homedir] (0x4000): Missing homedir of rr at test.loc. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 0) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): start ldb transaction (nesting: 1) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1419a10 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1435570 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1419a10 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1435570 "ltdb_timeout" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1419a10 "ltdb_callback" > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-237804563-1161820721-801220523-1106))]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.4 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-237804563-1161820721-801220523-1106))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=test,dc=loc]. > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 7 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 7 timeout 60 > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de1411070], connected[1], ops[(nil)], ldap[0x7f0de13fc080] > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Fri Nov 4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [ipa_subdom_reset_timeouts_cb] (0x4000): Resetting last_refreshed and disabled_until. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de1415190], ldap[0x7f0de13e8be0] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 7 finished > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-237804563-1161820721-801220523-1106))]. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de13fa4e0 > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1419d50 > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de13fa4e0 "ltdb_callback" > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1419d50 "ltdb_timeout" > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de13fa4e0 "ltdb_callback" > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] (0x2000): Searching 10.100.0.4 > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectClass=ipaexternalgroup][dc=ipa,dc=test,dc=loc]. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): New operation 8 timeout 60 > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=ab,cn=groups,cn=compat,dc=ipa,dc=test,dc=loc]. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaAnchorUUID] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=Default SMB Group,cn=groups,cn=compat,dc=ipa,dc=test,dc=loc]. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaAnchorUUID] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=editors,cn=groups,cn=compat,dc=ipa,dc=test,dc=loc]. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaAnchorUUID] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=admins,cn=groups,cn=compat,dc=ipa,dc=test,dc=loc]. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [gidNumber] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaAnchorUUID] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberUid] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de13eb710], ldap[0x7f0de13e8be0] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] (0x2000): Operation 8 finished > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ipa_get_ext_groups_done] (0x0400): [4] external groups found. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1444a10 > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de1444b40 > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1444a10 "ltdb_callback" > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de1444b40 "ltdb_timeout" > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1444a10 "ltdb_callback" > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f0de1444a10 > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f0de14457f0 > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Running timer event 0x7f0de1444a10 "ltdb_callback" > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Destroying timer event 0x7f0de14457f0 "ltdb_timeout" > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ldb] (0x4000): Ending timer event 0x7f0de1444a10 "ltdb_callback" > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [find_ipa_ext_memberships] (0x4000): SID [S-1-5-21-237804563-1161820721-801220523-1106] not found in ext group hash. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [find_ipa_ext_memberships] (0x0400): No external groupmemberships found. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [ipa_add_ext_groups_step] (0x4000): No external groups memberships found. > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[(nil)], ldap[0x7f0de13e8be0] > (Fri Nov 4 11:22:22 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > > > > On Nov 4, 2016, at 12:51 PM, Sumit Bose wrote: > > > > On Thu, Nov 03, 2016 at 05:23:06PM +0200, Taras Drach wrote: > >> Thank for reply, > >> > >> Unfortunately sssd won?t start with this configuration > >> > >> Here is part of log > >> > >> (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sdap_extend_map] (0x0200): 1 extra attributes > >> (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sdap_extend_map] (0x0010): Attribute sshPublicKey (altSecurityIdentities in LDAP) is already used by SSSD, please choose a different cache name > > > > Can you check if > > > > ldap_user_extra_attrs = originalADsshPublicKey:altSecurityIdentities > > > > works any better? > > > > bye, > > Sumit > > > >> (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [load_backend_module] (0x0010): Error (1432158241) in module (ipa) initialization (sssm_ipa_id_init)! > >> (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [be_process_init] (0x0010): fatal error initializing data providers > >> (Thu Nov 3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sbus_remove_watch] (0x2000): 0x7f8183df2640/0x7f8183df2420 > >> > >> Config changes: > >> > >> ldap_user_extra_attrs = sshPublicKey:altSecurityIdentities > >> # ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities > >> ldap_user_ssh_public_key = altSecurityIdentities > >> ldap_id_mapping = False > >> > >>> On Nov 3, 2016, at 5:05 PM, Sumit Bose wrote: > >>> > >>> sshPublicKey: > >> > > > > > From alessandro.demaria at gmail.com Fri Nov 4 15:52:58 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Fri, 4 Nov 2016 15:52:58 +0000 Subject: [Freeipa-users] ipalib: SEC_ERROR_UNTRUSTED_ISSUER Message-ID: Hello, I have a FreeIPA installation that is working very nicely, we already have configured many hosts and so far we are quite happy with it. I was trying to connect Ansible to fetch hosts from FreeIPA using the freeipa.py script ( https://github.com/ansible/ansible/blob/devel/contrib/inventory/freeipa.py) Unfortunately when I run it, I get the following: *ipa: ERROR: cert validation failed for "CN=id1.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.)* *ipa: ERROR: cert validation failed for "CN=id2.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.)* *Traceback (most recent call last):* * File "./freeipa.py", line 82, in * * api = initialize()* * File "./freeipa.py", line 17, in initialize* * api.Backend.rpcclient.connect()* * File "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line 66, in connect* * conn = self.create_connection(*args, **kw)* * File "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", line 939, in create_connection* * error=', '.join(urls))* *ipalib.errors.NetworkError: cannot connect to 'any of the configured servers': https://id1.prod .**xxxxxxxx**.com/ipa/json, https://id2.prod .**xxxxxxxx**.com/ipa/json* If I curl the URL, it works just fine ( I imported the CA Certificate in the system directory /etc/ssl/certs). I have run `openssl s_client` connect and downloaded the remote certificate locally, then I run: # openssl verify cert.pem # *id1.prod.**xxxxxxxx**.com.pem*: OK Would you help me figure out what's going on? -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Fri Nov 4 16:14:32 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 4 Nov 2016 17:14:32 +0100 Subject: [Freeipa-users] Setting sssd for webui In-Reply-To: <3f0aac57-6324-2119-a7b7-f623b312db96@ljll.math.upmc.fr> References: <3f0aac57-6324-2119-a7b7-f623b312db96@ljll.math.upmc.fr> Message-ID: On 11/04/2016 03:09 PM, Sebastien Julliot wrote: > Hello everyone, > > As I explained you some time ago, I have been skirting the ipa's > limitation to setting pre-hashed passwords by using ldappasswd. (I know > you guys think it's wrong. In this case the hashes come from an other > ldap which, for intern reasons, we can not synchronize with otherwise > than by frequent ldif extractions. So it's the only solution to have > unified passwords) > > To have the kerberos key generated, I can ask the users to do an > ldapsearch or to ssh on a machine with sssd enabled. > Yet, as most users will mainly want to use the WebUi, I am looking for a > way to have them able to connect to it without needing to do an > ldapsearch first. > > To be precise, I set the userPassword field using ldappasswd, and delete > the krbprincipalkey. > > Do you see any way to make the webui directly authenticable ? > > Thanks, > Sebastien Julliot. > Not sure what you want exactly. But if you want users to do simple ldap bind with username and password and nothing else then they can use migration page: https://ipa.demo1.freeipa.org/ipa/migration/index.html -- Petr Vobornik From william.muriithi at gmail.com Sun Nov 6 01:18:13 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Sat, 5 Nov 2016 21:18:13 -0400 Subject: [Freeipa-users] Kerberos enabled NFS error (Key has expired) In-Reply-To: References: Message-ID: On 3 November 2016 at 22:59, William Muriithi wrote: > Hello > > I have NFS server that has been working fine with "sec=sys" for years > but changed it last weekend to use "sec=krb5" last weekend. Since > then, users have been randomly complaining that they are seeing the > below error: > > [alexl at manganese /<7>dtop/simulation/vhdl_example]$ ll /projects/sparrow/meng > > ls: cannot access /projects/sparrow/meng: Key has expired > > When I login and try to list the content of the same directory, all > works fine. What is the root cause of this error? I have been > googling for a week, but haven't found any solution so far. Posting this to help anyone who may have the same problem and end up coming across this post. The problem was the script was changing user through su. This mean they didn't have any kerberos key after on that host as su bypassed proper authentication When the user used his username to ssh to the host and then run the script, the problem went away Regards, William From william.muriithi at gmail.com Sun Nov 6 01:32:11 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Sat, 5 Nov 2016 21:32:11 -0400 Subject: [Freeipa-users] query for key with hostname from automap Message-ID: Hello I have a system using automount for home directories and the automount maps are on FreeIPA. Is there a way I can query the username assigned to a certain host? Essentially, if I have a hostname xyz.example.com, what would be the process that I would need to query the keys living on that host? Nothing under "ipa help automount" seem to meet my need and wonder if anybody has come across such a problem Thanks William From raul at dias.com.br Sun Nov 6 05:06:13 2016 From: raul at dias.com.br (Raul Dias) Date: Sun, 6 Nov 2016 03:06:13 -0200 Subject: [Freeipa-users] FreeIPA + DHCP-LDAP - Fedora 24 - broken Message-ID: Hello, It seems that DHCP with LDAP on Fedora 24 (FreeIPA) is broken. Can anyone confirm? Doing an strace -e trace=network does not show any attempt to connect to the ldap server. OTOH, the same config on a Ubuntu 16.10 works fine. -rsd From prasun.gera at gmail.com Mon Nov 7 00:31:38 2016 From: prasun.gera at gmail.com (Prasun Gera) Date: Sun, 6 Nov 2016 19:31:38 -0500 Subject: [Freeipa-users] Package naming conflicts with update to RHEL 7.3 Message-ID: Getting this in yum check all after update to 7.3 ipa-client-4.4.0-12.el7.x86_64 has installed conflicts freeipa-client: ipa-client-4.4.0-12.el7.x86_64 ipa-client-common-4.4.0-12.el7.noarch has installed conflicts freeipa-client-common: ipa-client-common-4.4.0-12.el7.noarch ipa-common-4.4.0-12.el7.noarch has installed conflicts freeipa-common: ipa-common-4.4.0-12.el7.noarch ipa-python-compat-4.4.0-12.el7.noarch has installed conflicts freeipa-python-compat: ipa-python-compat-4.4.0-12.el7.noarch -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Nov 7 07:10:37 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 7 Nov 2016 08:10:37 +0100 Subject: [Freeipa-users] FreeIPA + DHCP-LDAP - Fedora 24 - broken In-Reply-To: References: Message-ID: On 6.11.2016 06:06, Raul Dias wrote: > Hello, > > It seems that DHCP with LDAP on Fedora 24 (FreeIPA) is broken. > > Can anyone confirm? > > Doing an strace -e trace=network does not show any attempt to connect to the > ldap server. > > OTOH, the same config on a Ubuntu 16.10 works fine. Hello, AFAIK DHCP support was never part of official FreeIPA builds. What are you trying to achieve and where did you get the builds? We need to know exact software versions and configuration. For further hints how to report bugs please see http://www.freeipa.org/page/Troubleshooting#Reporting_bugs -- Petr^2 Spacek From th at casalogic.dk Mon Nov 7 07:28:45 2016 From: th at casalogic.dk (Troels Hansen) Date: Mon, 7 Nov 2016 08:28:45 +0100 (CET) Subject: [Freeipa-users] SUDO and group lookup in AD trust In-Reply-To: <20160905072639.ifofnqwuvcxv54tx@hendrix> References: <2050149863.1012561.1471958268423.JavaMail.zimbra@casalogic.dk> <1042341051.13710.1472117452652.JavaMail.zimbra@casalogic.dk> <20160825204152.GA6360@10.4.128.1> <20160826055407.sok4s6c7ehtwoe3q@hendrix> <20160902072757.GA6086@10.4.128.1> <20160902075629.djs3yy22zk4p3kiz@hendrix> <793201723.148000.1473058924080.JavaMail.zimbra@casalogic.dk> <20160905072639.ifofnqwuvcxv54tx@hendrix> Message-ID: <1848186029.802525.1478503725298.JavaMail.zimbra@casalogic.dk> Hi there, I can see that RHEL 7.3 have left beta, and wanted to check this shiny new release that should fix a lot of the problems and current quirks we have, so I went through the release notes on SSSD in RHEL 7.3 and can't see any patched being added since end September, and in particular a patch for RHBZ# 1371152 in the SSSD 1.14 release ? >> Will RHEL7.3 have the currently working SSSD 1.14.1 from jhrozek's COPR repo >> (test build >> https://copr.fedorainfracloud.org/coprs/jhrozek/sssd-principal-test/) > > Not 1.14.1, but 7.3 will have the patch I put in my COPR repo (that's in > general how RHEL works, we can rebase only up to a certain point and then > we cherry-pick selected approved patches to avoid breaking RHEL with some > unrelated upstream change..) From mbabinsk at redhat.com Mon Nov 7 08:12:02 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 7 Nov 2016 09:12:02 +0100 Subject: [Freeipa-users] Package naming conflicts with update to RHEL 7.3 In-Reply-To: References: Message-ID: On 11/07/2016 01:31 AM, Prasun Gera wrote: > Getting this in yum check all after update to 7.3 > > ipa-client-4.4.0-12.el7.x86_64 has installed conflicts freeipa-client: > ipa-client-4.4.0-12.el7.x86_64 > ipa-client-common-4.4.0-12.el7.noarch has installed conflicts > freeipa-client-common: ipa-client-common-4.4.0-12.el7.noarch > ipa-common-4.4.0-12.el7.noarch has installed conflicts freeipa-common: > ipa-common-4.4.0-12.el7.noarch > ipa-python-compat-4.4.0-12.el7.noarch has installed conflicts > freeipa-python-compat: ipa-python-compat-4.4.0-12.el7.noarch > > > Hi Prasun, That is a false positive caused by a bug in yum, see https://bugzilla.redhat.com/show_bug.cgi?id=1370134 -- Martin^3 Babinsky From jhrozek at redhat.com Mon Nov 7 09:01:24 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 7 Nov 2016 10:01:24 +0100 Subject: [Freeipa-users] SUDO and group lookup in AD trust In-Reply-To: <1848186029.802525.1478503725298.JavaMail.zimbra@casalogic.dk> References: <2050149863.1012561.1471958268423.JavaMail.zimbra@casalogic.dk> <1042341051.13710.1472117452652.JavaMail.zimbra@casalogic.dk> <20160825204152.GA6360@10.4.128.1> <20160826055407.sok4s6c7ehtwoe3q@hendrix> <20160902072757.GA6086@10.4.128.1> <20160902075629.djs3yy22zk4p3kiz@hendrix> <793201723.148000.1473058924080.JavaMail.zimbra@casalogic.dk> <20160905072639.ifofnqwuvcxv54tx@hendrix> <1848186029.802525.1478503725298.JavaMail.zimbra@casalogic.dk> Message-ID: <20161107090124.6qnbyhb64y6js2fs@hendrix> On Mon, Nov 07, 2016 at 08:28:45AM +0100, Troels Hansen wrote: > Hi there, I can see that RHEL 7.3 have left beta, and wanted to check this shiny new release that should fix a lot of the problems and current quirks we have, so I went through the release notes on SSSD in RHEL 7.3 and can't see any patched being added since end September, and in particular a patch for RHBZ# 1371152 in the SSSD 1.14 release ? I'm not completely sure which release notes are you referring to, but this bug was fixed in sssd-1.14.0-32.el7. It's also listed in the changelog: * Fri Sep 2 2016 Jakub Hrozek - 1.14.0-32 - Resolves: rhbz#1371152 - SSSD qualifies principal twice in IPA-AD trust if the principal attribute doesn't exist on the AD side From th at casalogic.dk Mon Nov 7 09:12:20 2016 From: th at casalogic.dk (Troels Hansen) Date: Mon, 7 Nov 2016 10:12:20 +0100 (CET) Subject: [Freeipa-users] SUDO and group lookup in AD trust In-Reply-To: <20161107090124.6qnbyhb64y6js2fs@hendrix> References: <2050149863.1012561.1471958268423.JavaMail.zimbra@casalogic.dk> <20160826055407.sok4s6c7ehtwoe3q@hendrix> <20160902072757.GA6086@10.4.128.1> <20160902075629.djs3yy22zk4p3kiz@hendrix> <793201723.148000.1473058924080.JavaMail.zimbra@casalogic.dk> <20160905072639.ifofnqwuvcxv54tx@hendrix> <1848186029.802525.1478503725298.JavaMail.zimbra@casalogic.dk> <20161107090124.6qnbyhb64y6js2fs@hendrix> Message-ID: <1954876015.804297.1478509940125.JavaMail.zimbra@casalogic.dk> > I'm not completely sure which release notes are you referring to, but > this bug was fixed in sssd-1.14.0-32.el7. It's also listed in the > changelog: > > * Fri Sep 2 2016 Jakub Hrozek - 1.14.0-32 > - Resolves: rhbz#1371152 - SSSD qualifies principal twice in IPA-AD trust > if the principal attribute doesn't exist on the > AD side I was checking the changelog on: https://access.redhat.com/downloads/content/rhel---7/x86_64/2456/sssd/1.14.0-43.el7/x86_64/fd431d51/package-changelog Apparently they have a "feature" that truncates the view of the release log to the last 10(-ish) entries..... From mbabinsk at redhat.com Mon Nov 7 10:56:52 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 7 Nov 2016 11:56:52 +0100 Subject: [Freeipa-users] ipalib: SEC_ERROR_UNTRUSTED_ISSUER In-Reply-To: References: Message-ID: <8fa56583-45d5-5d0d-6800-f5abba6312ac@redhat.com> On 11/04/2016 04:52 PM, Alessandro De Maria wrote: > Hello, > > I have a FreeIPA installation that is working very nicely, we already > have configured many hosts and so far we are quite happy with it. > > I was trying to connect Ansible to fetch hosts from FreeIPA using the > freeipa.py script > (https://github.com/ansible/ansible/blob/devel/contrib/inventory/freeipa.py) > > Unfortunately when I run it, I get the following: > > *ipa: ERROR: cert validation failed for > "CN=id1.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM > " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's > certificate issuer has been marked as not trusted by the user.)* > *ipa: ERROR: cert validation failed for > "CN=id2.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM > " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's > certificate issuer has been marked as not trusted by the user.)* > *Traceback (most recent call last):* > * File "./freeipa.py", line 82, in * > * api = initialize()* > * File "./freeipa.py", line 17, in initialize* > * api.Backend.rpcclient.connect()* > * File "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line 66, > in connect* > * conn = self.create_connection(*args, **kw)* > * File "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", line 939, in > create_connection* > * error=', '.join(urls))* > *ipalib.errors.NetworkError: cannot connect to 'any of the configured > servers': https://id1.prod.**xxxxxxxx**.com/ipa/json, > https://id2.prod.**xxxxxxxx**.com/ipa/json* > > > If I curl the URL, it works just fine ( I imported the CA Certificate in > the system directory /etc/ssl/certs). > > I have run `openssl s_client` connect and downloaded the remote > certificate locally, then I run: > > # openssl verify cert.pem > # *id1.prod.**xxxxxxxx**.com.pem*: OK > > > Would you help me figure out what's going on? > > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com > > Hi Alessandro, this error can mean that the CA certificate in IPA NSS database has wrong trust flags set. Please make sure that there is IPA CA certificate present on /etc/httpd/alias and it has trust flags CT,C,C like this: # certutil -L -d /etc/httpd/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ipaCert u,u,u Server-Cert u,u,u <$REALM> IPA CA CT,C,C -- Martin^3 Babinsky From jamesaharrisonuk at yahoo.co.uk Mon Nov 7 11:05:38 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Mon, 7 Nov 2016 11:05:38 +0000 (UTC) Subject: [Freeipa-users] Remove AD domain in auth commands In-Reply-To: <893721809.382437.1478257468370@mail.yahoo.com> References: <893721809.382437.1478257468370.ref@mail.yahoo.com> <893721809.382437.1478257468370@mail.yahoo.com> Message-ID: <151311567.3441657.1478516739115@mail.yahoo.com> Anyone ? Sent from Yahoo Mail on Android On Fri, 4 Nov, 2016 at 11:04, James Harrison wrote: Hello, I've installed FreeIPA 4.2 master using Centos and I have a Windows 2012R2 with its AD schema emulating a Windows 2012 system I have established a trust between the two and it appears to work. I can reference a user on the AD domain, but the only way is to add the AD domain. The only way to ssh to the master IPA server is like this: ssh "x_xxxx at IPAWIN.LOCAL"@10.10.10.10 Another example is using kinit: I have to do the following to get a credential:kinit x_xxxx at IPAWIN.LOCAL Ideally I would not need or use the "@IPAWIN.LOCAL". Can anyone help? Best regards,James Harrison -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Nov 7 11:48:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 7 Nov 2016 12:48:03 +0100 Subject: [Freeipa-users] Remove AD domain in auth commands In-Reply-To: <151311567.3441657.1478516739115@mail.yahoo.com> References: <893721809.382437.1478257468370.ref@mail.yahoo.com> <893721809.382437.1478257468370@mail.yahoo.com> <151311567.3441657.1478516739115@mail.yahoo.com> Message-ID: <79031dea-0310-c65e-1f3d-5fde75ca6435@redhat.com> AFAIK Jakub already answered that https://www.redhat.com/archives/freeipa-users/2016-November/msg00031.html On 07.11.2016 12:05, James Harrison wrote: > Anyone ? > > Sent from Yahoo Mail on Android > > > On Fri, 4 Nov, 2016 at 11:04, James Harrison > wrote: > > Hello, > > I've installed FreeIPA 4.2 master using Centos and I have a > Windows 2012R2 with its AD schema emulating a Windows 2012 system > > I have established a trust between the two and it appears to work. > I can reference a user on the AD domain, but the only way is to > add the AD domain. > > The only way to ssh to the master IPA server is like this: > > ssh "x_xxxx at IPAWIN.LOCAL"@10.10.10.10 > > Another example is using kinit: > > I have to do the following to get a credential: > kinit x_xxxx at IPAWIN.LOCAL > > Ideally I would not need or use the "@IPAWIN.LOCAL". > > Can anyone help? > > Best regards, > James Harrison > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.dejaeghere at gmail.com Mon Nov 7 13:50:21 2016 From: david.dejaeghere at gmail.com (David Dejaeghere) Date: Mon, 7 Nov 2016 14:50:21 +0100 Subject: [Freeipa-users] ipa-cacert-manage install failing with subject public key info mismatch In-Reply-To: References: Message-ID: Can somebody help us how to move ahead with this issue? It seems like nobody is picking this up? Kind Regards, David 2016-10-26 13:43 GMT+02:00 David Dejaeghere : > Does anybody have a clue on how to continue with this? > > Kind Regards, > > David > > 2016-10-24 10:10 GMT+02:00 David Dejaeghere : > >> These are both the subjects for the old and new root ca cert. >> >> Subject: "CN=tokio-PAPRIKA-CA,DC=tokio,DC=local" >> Subject Public Key Info: >> Public Key Algorithm: PKCS #1 RSA Encryption >> RSA Public Key: >> Modulus: >> d5:51:19:a0:7e:2f:b6:4b:cb:71:42:cb:38:bc:50:0a: >> 18:16:58:07:11:c6:d3:ea:66:91:a8:52:02:54:93:28: >> 78:a1:89:36:7a:0f:1e:2a:35:8a:da:85:05:c4:fe:de: >> e8:6a:e8:fd:1b:89:44:8f:8c:62:d6:56:f7:9e:16:d5: >> fd:b4:44:65:71:4f:1a:7d:d6:28:2d:5e:ad:c9:da:60: >> 54:98:02:87:d9:43:62:ab:1b:93:c1:af:0b:b9:80:2e: >> 08:f0:65:46:bf:de:78:c5:d2:19:b8:07:52:d6:01:ab: >> d0:b2:7d:0a:7f:9f:fa:e8:8c:55:86:e0:d3:d5:ef:e7: >> ad:6a:12:a2:b8:75:be:93:c2:05:df:99:a9:d8:a2:cc: >> 7c:2b:49:d6:a3:65:0c:c8:ef:c3:a4:b6:f6:86:1d:c2: >> 56:56:1b:0d:70:7a:67:15:49:2f:b7:92:8e:2a:94:57: >> 53:26:ef:9a:af:89:fe:cb:1e:e7:ac:72:9a:cd:b4:22: >> b1:22:02:fd:95:23:e0:65:d0:36:e8:e1:88:2b:35:02: >> 99:1c:ee:84:10:80:84:a8:e5:61:04:6b:a3:6b:da:c5: >> 49:36:ef:f6:48:09:2c:0d:7c:b2:52:4f:a6:72:cc:e6: >> 30:b5:dd:a0:5b:0e:96:49:78:9d:1e:27:4e:02:40:a1 >> Exponent: 65537 (0x10001) >> >> Subject: DC=local, DC=tokio, CN=tokio-PAPRIKA-CA >> Subject Public Key Info: >> Public Key Algorithm: rsaEncryption >> Public-Key: (2048 bit) >> Modulus: >> 00:ae:32:35:fa:b5:f4:2d:b8:0c:c3:d9:b0:9f:a8: >> 5d:21:90:58:a9:79:79:7d:85:7e:f1:f2:36:9d:ef: >> 9f:8c:a8:3a:bf:57:5c:2e:6b:5d:2e:91:ba:c6:b7: >> b2:b1:dd:45:de:e6:d4:fe:01:f4:d2:bd:99:9f:9a: >> 71:1d:d4:e4:a7:cd:9e:f3:36:a7:a0:73:55:6b:04: >> 66:ab:c3:63:b3:41:06:ac:c8:c8:3a:4c:eb:83:78: >> 6e:e8:b6:0f:94:fa:a8:7e:7d:89:44:d1:bd:be:14: >> df:0c:ce:4d:b4:e6:0a:e2:d7:84:95:4b:a1:3e:53: >> c9:04:3f:7b:de:1b:fd:7b:b5:b0:69:3b:f9:f2:b5: >> a7:fe:6d:9d:62:6e:9a:fc:1e:32:69:ad:4c:ae:e3: >> 61:dd:92:99:34:4b:bf:6b:02:88:18:88:a2:0f:ca: >> e8:6e:91:f0:e6:2e:4d:83:f6:05:7e:ed:f2:f1:3e: >> b2:36:3f:de:3f:db:93:73:5b:60:ee:8c:48:e0:c0: >> 4c:0e:6a:63:1a:16:af:9e:28:93:40:39:23:bf:d0: >> 77:9c:b7:80:d3:c3:42:d8:27:db:d7:4b:e5:3f:b4: >> d2:ad:57:c2:01:73:c8:45:26:f1:00:93:50:3e:cf: >> 7a:2d:25:d5:43:b6:a7:75:a1:ef:58:f9:c9:11:e8: >> 09:1d >> Exponent: 65537 (0x10001) >> >> 2016-10-24 5:49 GMT+02:00 Fil Di Noto : >> >>> Hi, >>> >>> Can you give an example of what's different between the two subjects? >>> >>> On Sun, Oct 23, 2016 at 9:03 AM, David Dejaeghere < >>> david.dejaeghere at gmail.com> wrote: >>> >>>> Does somebody have an idea how to replace our certificates when the new >>>> ROOT ca certificate has a different subject? >>>> The UI is down because of this. >>>> >>>> 2016-10-19 11:42 GMT+02:00 David Dejaeghere >>> >: >>>> >>>>> Hello, >>>>> >>>>> When installing FreeIPA we used the CA from our Windows servers. >>>>> This one recently expired and we created a new one. It seems that the >>>>> new root CA has another subject name and this seems to be an issue when we >>>>> want to install new certs on our FreeIPA hosts. >>>>> >>>>> ipa-cacert-manage install certnew.pem -n mycert -t C,, >>>>> >>>>> Installing CA certificate, please wait >>>>> Failed to install the certificate: subject public key info mismatch >>>>> >>>>> After validating the subjects are indeed different. >>>>> >>>>> How can we replace the required certs for dirsrv and http when the ca >>>>> is not installable? >>>>> >>>>> Kind Regards, >>>>> >>>>> David >>>>> >>>>> >>>>> >>>> >>>> -- >>>> 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 artemiev at itsirius.su Mon Nov 7 14:09:48 2016 From: artemiev at itsirius.su (artemiev at itsirius.su) Date: Mon, 7 Nov 2016 18:09:48 +0400 (MSK) Subject: [Freeipa-users] Problem with IPA installation. Message-ID: <1318399080.7491.1478527788477.JavaMail.zimbra@itsirius.su> I try to install IPA 4.2 on RedHat 7. It crashes with following messages: Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds [1/28]: creating certificate server user [2/28]: configuring certificate server instance ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA instance: Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmphBBJam'' returned non-zero exit status 1 ipa.ipaserver.install.cainstance.CAInstance: CRITICAL See the installation logs and the following files/directories for more information: ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki-ca-install.log ipa.ipaserver.install.cainstance.CAInstance: CRITICAL /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration failed. ipa.ipapython.install.cli.install_tool(Server): ERROR CA configuration failed. I tried google, but solutions, that seem to work for others, doesn't work for me. Logs of ipa-server-install and files from /var/log/pki (all two of them) are attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-ca-spawn.20161107165710.log Type: text/x-log Size: 56133 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-server-upgrade-10.2.5.log Type: text/x-log Size: 143 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaserver-install.log Type: text/x-log Size: 196825 bytes Desc: not available URL: From rcritten at redhat.com Mon Nov 7 14:30:55 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 7 Nov 2016 09:30:55 -0500 Subject: [Freeipa-users] query for key with hostname from automap In-Reply-To: References: Message-ID: <5820901F.1060403@redhat.com> William Muriithi wrote: > Hello > > I have a system using automount for home directories and the automount > maps are on FreeIPA. > > Is there a way I can query the username assigned to a certain host? > Essentially, if I have a hostname xyz.example.com, what would be the > process that I would need to query the keys living on that host? > > Nothing under "ipa help automount" seem to meet my need and wonder if > anybody has come across such a problem The data is there but it isn't expected to be searchable like you want. I seem to recall that autofs has a browse mode, you might try that. Or perhaps you can cobble together what you want by looking at the NFS sources using exportfs. rob From alessandro.demaria at gmail.com Mon Nov 7 15:36:15 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Mon, 7 Nov 2016 15:36:15 +0000 Subject: [Freeipa-users] ipalib: SEC_ERROR_UNTRUSTED_ISSUER In-Reply-To: <8fa56583-45d5-5d0d-6800-f5abba6312ac@redhat.com> References: <8fa56583-45d5-5d0d-6800-f5abba6312ac@redhat.com> Message-ID: Hi Martin, this is the output from the id1 host: certutil -L -d /etc/httpd/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Signing-Cert u,u,u ipaCert u,u,u Server-Cert u,u,u PROD.XXXXXXXXXXXXX.COM IPA CA CT,C,C looks just like you suggested. Any other suggestion? On 7 November 2016 at 10:56, Martin Babinsky wrote: > On 11/04/2016 04:52 PM, Alessandro De Maria wrote: > >> Hello, >> >> I have a FreeIPA installation that is working very nicely, we already >> have configured many hosts and so far we are quite happy with it. >> >> I was trying to connect Ansible to fetch hosts from FreeIPA using the >> freeipa.py script >> (https://github.com/ansible/ansible/blob/devel/contrib/inven >> tory/freeipa.py) >> >> Unfortunately when I run it, I get the following: >> >> *ipa: ERROR: cert validation failed for >> "CN=id1.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM >> " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's >> certificate issuer has been marked as not trusted by the user.)* >> *ipa: ERROR: cert validation failed for >> "CN=id2.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM >> " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's >> certificate issuer has been marked as not trusted by the user.)* >> *Traceback (most recent call last):* >> * File "./freeipa.py", line 82, in * >> * api = initialize()* >> * File "./freeipa.py", line 17, in initialize* >> * api.Backend.rpcclient.connect()* >> * File "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line 66, >> in connect* >> * conn = self.create_connection(*args, **kw)* >> * File "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", line 939, in >> create_connection* >> * error=', '.join(urls))* >> *ipalib.errors.NetworkError: cannot connect to 'any of the configured >> servers': https://id1.prod.**xxxxxxxx**.com/ipa/json, >> https://id2.prod.**xxxxxxxx**.com/ipa/json* >> >> >> If I curl the URL, it works just fine ( I imported the CA Certificate in >> the system directory /etc/ssl/certs). >> >> I have run `openssl s_client` connect and downloaded the remote >> certificate locally, then I run: >> >> # openssl verify cert.pem >> # *id1.prod.**xxxxxxxx**.com.pem*: OK >> >> >> Would you help me figure out what's going on? >> >> >> >> -- >> Alessandro De Maria >> alessandro.demaria at gmail.com >> >> >> > Hi Alessandro, > > this error can mean that the CA certificate in IPA NSS database has wrong > trust flags set. Please make sure that there is IPA CA certificate present > on /etc/httpd/alias and it has trust flags CT,C,C like this: > > # certutil -L -d /etc/httpd/alias/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > ipaCert u,u,u > Server-Cert u,u,u > <$REALM> IPA CA CT,C,C > > -- > Martin^3 Babinsky > > -- > 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 > -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.demaria at gmail.com Mon Nov 7 15:45:34 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Mon, 7 Nov 2016 15:45:34 +0000 Subject: [Freeipa-users] ipalib: SEC_ERROR_UNTRUSTED_ISSUER In-Reply-To: References: <8fa56583-45d5-5d0d-6800-f5abba6312ac@redhat.com> Message-ID: Hi Martin, I tried from the host I am executing the script from, and I get: certutil -L -d /etc/httpd/alias/ certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. >From the FreeIPA server, as I said previously, I get: certutil -L -d /etc/httpd/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Signing-Cert u,u,u ipaCert u,u,u Server-Cert u,u,u PROD.XXXXXXXXXXXXX.COM IPA CA CT,C,C >From the FreeIPA server, I seem to be able to run the script, so we are definitely on the right track. How do I get the /etc/httpd/alias/ in sync across these hosts? can I copy it, or is there a way to regenerate it? Regards Alessandro On 7 November 2016 at 15:36, Alessandro De Maria < alessandro.demaria at gmail.com> wrote: > Hi Martin, this is the output from the id1 host: > > certutil -L -d /etc/httpd/alias/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > Signing-Cert u,u,u > ipaCert u,u,u > Server-Cert u,u,u > PROD.XXXXXXXXXXXXX.COM IPA CA CT,C,C > > > looks just like you suggested. Any other suggestion? > > On 7 November 2016 at 10:56, Martin Babinsky wrote: > >> On 11/04/2016 04:52 PM, Alessandro De Maria wrote: >> >>> Hello, >>> >>> I have a FreeIPA installation that is working very nicely, we already >>> have configured many hosts and so far we are quite happy with it. >>> >>> I was trying to connect Ansible to fetch hosts from FreeIPA using the >>> freeipa.py script >>> (https://github.com/ansible/ansible/blob/devel/contrib/inven >>> tory/freeipa.py) >>> >>> Unfortunately when I run it, I get the following: >>> >>> *ipa: ERROR: cert validation failed for >>> "CN=id1.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM >>> " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's >>> certificate issuer has been marked as not trusted by the user.)* >>> *ipa: ERROR: cert validation failed for >>> "CN=id2.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM >>> " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's >>> certificate issuer has been marked as not trusted by the user.)* >>> *Traceback (most recent call last):* >>> * File "./freeipa.py", line 82, in * >>> * api = initialize()* >>> * File "./freeipa.py", line 17, in initialize* >>> * api.Backend.rpcclient.connect()* >>> * File "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line 66, >>> in connect* >>> * conn = self.create_connection(*args, **kw)* >>> * File "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", line 939, in >>> create_connection* >>> * error=', '.join(urls))* >>> *ipalib.errors.NetworkError: cannot connect to 'any of the configured >>> servers': https://id1.prod.**xxxxxxxx**.com/ipa/json, >>> https://id2.prod.**xxxxxxxx**.com/ipa/json* >>> >>> >>> If I curl the URL, it works just fine ( I imported the CA Certificate in >>> the system directory /etc/ssl/certs). >>> >>> I have run `openssl s_client` connect and downloaded the remote >>> certificate locally, then I run: >>> >>> # openssl verify cert.pem >>> # *id1.prod.**xxxxxxxx**.com.pem*: OK >>> >>> >>> Would you help me figure out what's going on? >>> >>> >>> >>> -- >>> Alessandro De Maria >>> alessandro.demaria at gmail.com >>> >>> >>> >> Hi Alessandro, >> >> this error can mean that the CA certificate in IPA NSS database has wrong >> trust flags set. Please make sure that there is IPA CA certificate present >> on /etc/httpd/alias and it has trust flags CT,C,C like this: >> >> # certutil -L -d /etc/httpd/alias/ >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> ipaCert u,u,u >> Server-Cert u,u,u >> <$REALM> IPA CA CT,C,C >> >> -- >> Martin^3 Babinsky >> >> -- >> 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 >> > > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com > -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From raul at dias.com.br Mon Nov 7 16:45:02 2016 From: raul at dias.com.br (Raul Dias) Date: Mon, 7 Nov 2016 14:45:02 -0200 Subject: [Freeipa-users] FreeIPA + DHCP-LDAP - Fedora 24 - broken In-Reply-To: References: Message-ID: <309dcd97-8598-2d28-608d-024e20f04a2c@dias.com.br> You are right, This might be more a Fedora issue than FreeIPA. I am hoping that someone else is also using DHCP with LDAP (specially with FreeIPA). I am using the IPA-dhcp plugin: https://github.com/jefferyharrell/IPA-dhcp ldapsearch -x shows the entries are fine in the LDAP. Stracing dhcpd shows that it is not making any connection to the LDAP, while it shows an error message. On Fedora 24 (updated), I am using dhcp-server-4.3.4.fc24 /etc/dhcp/dhcpd.conf: ldap-server "10.101.1.1"; #or localhost, or any interface ip or ns name ldap-port 389; ldap-base-dn "cn=dhcp,dc=dias,dc=com,dc=br"; ldap-method static; ldap-debug-file "/var/log/dhcp-ldap-startup.log"; The STDERR output acts as if it were talking to the LDAP server: Cannot find host LDAP entry server.dias.com.br (&(objectClass=dhcpServer)(cn=server.dias.com.br)) As the output of ldapsearch, the entry is there: # server.dias.com.br, dhcp, dias.com.br dn: cn=server.dias.com.br,cn=dhcp,dc=dias,dc=com,dc=br objectClass: dhcpserver objectClass: top dhcpServiceDN: cn=dhcp,dc=dias,dc=com,dc=br cn: server.dias.com.br dhcpStatements: authoritative Using the same config on a ubuntu host, it works fine, which makes me wonder that dhcpd in Fedora 24 does not work at all with LDAP. Or maybe this is a reflection of some FreeIPA server way of life configuration, like sssd. -rsd On 07/11/2016 05:10, Petr Spacek wrote: > On 6.11.2016 06:06, Raul Dias wrote: >> Hello, >> >> It seems that DHCP with LDAP on Fedora 24 (FreeIPA) is broken. >> >> Can anyone confirm? >> >> Doing an strace -e trace=network does not show any attempt to connect to the >> ldap server. >> >> OTOH, the same config on a Ubuntu 16.10 works fine. > Hello, > > AFAIK DHCP support was never part of official FreeIPA builds. What are you > trying to achieve and where did you get the builds? > > We need to know exact software versions and configuration. For further hints > how to report bugs please see > http://www.freeipa.org/page/Troubleshooting#Reporting_bugs > From jamesaharrisonuk at yahoo.co.uk Mon Nov 7 20:11:58 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Mon, 7 Nov 2016 20:11:58 +0000 (UTC) Subject: [Freeipa-users] Remove AD domain in auth commands In-Reply-To: <79031dea-0310-c65e-1f3d-5fde75ca6435@redhat.com> References: <893721809.382437.1478257468370.ref@mail.yahoo.com> <893721809.382437.1478257468370@mail.yahoo.com> <151311567.3441657.1478516739115@mail.yahoo.com> <79031dea-0310-c65e-1f3d-5fde75ca6435@redhat.com> Message-ID: <1400554330.12480.1478549518491@mail.yahoo.com> Hello Sorry didn't explain. The ipa is the default domain, but I also want to use the Windows domain to authenticate, but I want the OS to detect what realm to use in the ssh command. Thanks On Mon, 7 Nov, 2016 at 11:48, Martin Basti wrote: AFAIK Jakub already answered thathttps://www.redhat.com/archives/freeipa-users/2016-November/msg00031.html On 07.11.2016 12:05, James Harrison wrote: Anyone ? Sent from Yahoo Mail on Android On Fri, 4 Nov, 2016 at 11:04, James Harrison wrote: Hello, I've installed FreeIPA 4.2 master using Centos and I have a Windows 2012R2 with its AD schema emulating a Windows 2012 system I have established a trust between the two and it appears to work. I can reference a user on the AD domain, but the only way is to add the AD domain. The only way to ssh to the master IPA server is like this: ssh "x_xxxx at IPAWIN.LOCAL"@10.10.10.10 Another example is using kinit: I have to do the following to get a credential: kinit x_xxxx at IPAWIN.LOCAL Ideally I would not need or use the "@IPAWIN.LOCAL". Can anyone help? Best regards, James Harrison -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Nov 8 07:56:41 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 8 Nov 2016 08:56:41 +0100 Subject: [Freeipa-users] ipalib: SEC_ERROR_UNTRUSTED_ISSUER In-Reply-To: References: <8fa56583-45d5-5d0d-6800-f5abba6312ac@redhat.com> Message-ID: <7c5ea164-c992-8903-47bb-29d000ee1841@redhat.com> On 11/07/2016 04:45 PM, Alessandro De Maria wrote: > Hi Martin, > > I tried from the host I am executing the script from, and I get: > certutil -L -d /etc/httpd/alias/ > certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The > certificate/key database is in an old, unsupported format. > > > From the FreeIPA server, as I said previously, I get: > > certutil -L -d /etc/httpd/alias/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > Signing-Cert u,u,u > ipaCert u,u,u > Server-Cert u,u,u > PROD.XXXXXXXXXXXXX.COM IPA CA > CT,C,C > > > From the FreeIPA server, I seem to be able to run the script, so we are > definitely on the right track. > How do I get the /etc/httpd/alias/ in sync across these hosts? can I > copy it, or is there a way to regenerate it? > > Regards > Alessandro > > On 7 November 2016 at 15:36, Alessandro De Maria > > wrote: > > Hi Martin, this is the output from the id1 host: > > certutil -L -d /etc/httpd/alias/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > Signing-Cert u,u,u > ipaCert u,u,u > Server-Cert u,u,u > PROD.XXXXXXXXXXXXX.COM IPA CA > CT,C,C > > > looks just like you suggested. Any other suggestion? > > On 7 November 2016 at 10:56, Martin Babinsky > wrote: > > On 11/04/2016 04:52 PM, Alessandro De Maria wrote: > > Hello, > > I have a FreeIPA installation that is working very nicely, > we already > have configured many hosts and so far we are quite happy > with it. > > I was trying to connect Ansible to fetch hosts from FreeIPA > using the > freeipa.py script > (https://github.com/ansible/ansible/blob/devel/contrib/inventory/freeipa.py > ) > > Unfortunately when I run it, I get the following: > > *ipa: ERROR: cert validation failed for > "CN=id1.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM > > " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's > certificate issuer has been marked as not trusted by the user.)* > *ipa: ERROR: cert validation failed for > "CN=id2.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM > > " ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's > certificate issuer has been marked as not trusted by the user.)* > *Traceback (most recent call last):* > * File "./freeipa.py", line 82, in * > * api = initialize()* > * File "./freeipa.py", line 17, in initialize* > * api.Backend.rpcclient.connect()* > * File > "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line 66, > in connect* > * conn = self.create_connection(*args, **kw)* > * File "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", > line 939, in > create_connection* > * error=', '.join(urls))* > *ipalib.errors.NetworkError: cannot connect to 'any of the > configured > servers': https://id1.prod.**xxxxxxxx**.com/ipa/json, > https://id2.prod.**xxxxxxxx**.com/ipa/json* > > > If I curl the URL, it works just fine ( I imported the CA > Certificate in > the system directory /etc/ssl/certs). > > I have run `openssl s_client` connect and downloaded the remote > certificate locally, then I run: > > # openssl verify cert.pem > # *id1.prod.**xxxxxxxx**.com.pem*: OK > > > Would you help me figure out what's going on? > > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com > > > > > > > Hi Alessandro, > > this error can mean that the CA certificate in IPA NSS database > has wrong trust flags set. Please make sure that there is IPA CA > certificate present on /etc/httpd/alias and it has trust flags > CT,C,C like this: > > # certutil -L -d /etc/httpd/alias/ > > Certificate Nickname > Trust Attributes > > SSL,S/MIME,JAR/XPI > > ipaCert u,u,u > Server-Cert u,u,u > <$REALM> IPA CA CT,C,C > > -- > Martin^3 Babinsky > > -- > 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 > > > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com > > > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com Alessandro, I have just realized that this may be client-side problem. On the executor you may need to import CA certificate from IPA server to local /etc/ipa/nssdb and/or copy it into /etc/ipa/ca.crt as PEM file. Or you can just enroll the node as IPA client and it will set up all this stuff for you. -- Martin^3 Babinsky From mbabinsk at redhat.com Tue Nov 8 07:57:57 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 8 Nov 2016 08:57:57 +0100 Subject: [Freeipa-users] Remove AD domain in auth commands In-Reply-To: <1400554330.12480.1478549518491@mail.yahoo.com> References: <893721809.382437.1478257468370.ref@mail.yahoo.com> <893721809.382437.1478257468370@mail.yahoo.com> <151311567.3441657.1478516739115@mail.yahoo.com> <79031dea-0310-c65e-1f3d-5fde75ca6435@redhat.com> <1400554330.12480.1478549518491@mail.yahoo.com> Message-ID: <1e49e75a-946a-ca92-5995-161bd1917c08@redhat.com> On 11/07/2016 09:11 PM, James Harrison wrote: > Hello > Sorry didn't explain. The ipa is the default domain, but I also want to > use the Windows domain to authenticate, but I want the OS to detect what > realm to use in the ssh command. > > Thanks > > On Mon, 7 Nov, 2016 at 11:48, Martin Basti > wrote: > > AFAIK Jakub already answered that > https://www.redhat.com/archives/freeipa-users/2016-November/msg00031.html > > On 07.11.2016 12:05, James Harrison wrote: >> Anyone ? >> >> Sent from Yahoo Mail on Android >> >> >> On Fri, 4 Nov, 2016 at 11:04, James Harrison >> wrote: >> Hello, >> >> I've installed FreeIPA 4.2 master using Centos and I have a >> Windows 2012R2 with its AD schema emulating a Windows 2012 system >> >> I have established a trust between the two and it appears to >> work. I can reference a user on the AD domain, but the only >> way is to add the AD domain. >> >> The only way to ssh to the master IPA server is like this: >> >> ssh "x_xxxx at IPAWIN.LOCAL"@10.10.10.10 >> >> Another example is using kinit: >> >> I have to do the following to get a credential: >> kinit x_xxxx at IPAWIN.LOCAL >> >> Ideally I would not need or use the "@IPAWIN.LOCAL". >> >> Can anyone help? >> >> Best regards, >> James Harrison >> >> >> > > > Hi James, as Jakub pointed out you may have to wait for the next release of SSSD for this to work. -- Martin^3 Babinsky From zhenglei at kylinos.cn Tue Nov 8 08:33:01 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Tue, 8 Nov 2016 16:33:01 +0800 Subject: [Freeipa-users] Configuring httpd error when selinux is permissive Message-ID: Hello everyone, I have been setting up freeipa(its version is 4.3.1) on Ubuntu. Selinux is enable, and its mode is permissive. I met a problem at configuring the httpd process, but the process won't be interrupted. The configuration information is as follows: Configuring the web interface (httpd). Estimated time: 1 minute [1/20]: setting mod_nss port to 443 [2/20]: setting mod_nss cipher suite [3/20]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2 [4/20]: setting mod_nss password file [5/20]: enabling mod_nss renegotiate [6/20]: adding URL rewriting rules [7/20]: configuring httpd [8/20]: configure certmonger for renewals [9/20]: setting up httpd keytab [10/20]: setting up ssl [11/20]: importing CA certificates from LDAP [12/20]: publish CA cert [13/20]: clean up any existing httpd ccache [14/20]: configuring SELinux for httpd ipa.ipaplatform.redhat.tasks: ERROR Cannot get SELinux boolean 'httpd_run_ipa': Command '/usr/sbin/getsebool httpd_run_ipa' returned non-zero exit status 255 WARNING: Could not set SELinux booleans: httpd_can_network_connect=on httpd_run_ipa=on httpd_manage_ipa=on The web interface may not function correctly until the booleans are successfully changed with the command: /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_run_ipa=on httpd_manage_ipa=on Try updating the policycoreutils and selinux-policy packages. [15/20]: create KDC proxy user [16/20]: create KDC proxy config [17/20]: enable KDC proxy [18/20]: restarting httpd [19/20]: configuring httpd to start on boot [20/20]: enabling oddjobd Done configuring the web interface (httpd). Is there anyone can help me? Thanks! ------------------ ?? ?????????? -------------------------- ?????? ?? ???18684703229 ???zhenglei at kylinos.cn ??????????????? ?????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From umarzuki at gmail.com Tue Nov 8 08:42:27 2016 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Tue, 8 Nov 2016 16:42:27 +0800 Subject: [Freeipa-users] Configuring httpd error when selinux is permissive In-Reply-To: References: Message-ID: 2016-11-08 16:33 GMT+08:00 ?? : > Hello everyone, > I have been setting up freeipa(its version is 4.3.1) on Ubuntu. Selinux is > enable, and its mode is permissive. I met a problem at configuring the httpd > process, but the process won't be interrupted. The configuration information > is as follows: > Configuring the web interface (httpd). Estimated time: 1 minute > [1/20]: setting mod_nss port to 443 > [2/20]: setting mod_nss cipher suite > [3/20]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2 > [4/20]: setting mod_nss password file > [5/20]: enabling mod_nss renegotiate > [6/20]: adding URL rewriting rules > [7/20]: configuring httpd > [8/20]: configure certmonger for renewals > [9/20]: setting up httpd keytab > [10/20]: setting up ssl > [11/20]: importing CA certificates from LDAP > [12/20]: publish CA cert > [13/20]: clean up any existing httpd ccache > [14/20]: configuring SELinux for httpd > ipa.ipaplatform.redhat.tasks: ERROR Cannot get SELinux boolean > 'httpd_run_ipa': Command '/usr/sbin/getsebool httpd_run_ipa' returned > non-zero exit status 255 > WARNING: Could not set SELinux booleans: httpd_can_network_connect=on > httpd_run_ipa=on httpd_manage_ipa=on > > The web interface may not function correctly until > the booleans are successfully changed with the command: > /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_run_ipa=on > httpd_manage_ipa=on > Try updating the policycoreutils and selinux-policy packages. > [15/20]: create KDC proxy user > [16/20]: create KDC proxy config > [17/20]: enable KDC proxy > [18/20]: restarting httpd > [19/20]: configuring httpd to start on boot > [20/20]: enabling oddjobd > Done configuring the web interface (httpd). > Is there anyone can help me? > > Thanks! > -- > 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 Hi, Have you tried the suggested setsebool command? From zhenglei at kylinos.cn Tue Nov 8 08:57:22 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Tue, 8 Nov 2016 16:57:22 +0800 Subject: [Freeipa-users] Configuring httpd error when selinux is permissive In-Reply-To: References: Message-ID: Command returns the result: root at ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_run_ipa=on httpd_manage_ipa=on Cannot set persistent booleans without managed policy. root at ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/getsebool httpd_run_ipa Error getting active value for httpd_run_ipa root at ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/getsebool httpd_can_network_connect httpd_can_network_connect --> off root at ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/getsebool httpd_manage_ipa httpd_manage_ipa --> off I want the result is not to appear error in the configuration process information. ------------------ ?? ?????????? -------------------------- ?????? ?? ???18684703229 ???zhenglei at kylinos.cn ??????????????? ?????????????????????? ------------------ Original ------------------ From: "Umarzuki Mochlis"; Date: Tue, Nov 8, 2016 04:42 PM To: "??"; Cc: "freeipa-users"; Subject: Re: [Freeipa-users] Configuring httpd error when selinux is permissive 2016-11-08 16:33 GMT+08:00 ?? : > Hello everyone, > I have been setting up freeipa(its version is 4.3.1) on Ubuntu. Selinux is > enable, and its mode is permissive. I met a problem at configuring the httpd > process, but the process won't be interrupted. The configuration information > is as follows: > Configuring the web interface (httpd). Estimated time: 1 minute > [1/20]: setting mod_nss port to 443 > [2/20]: setting mod_nss cipher suite > [3/20]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2 > [4/20]: setting mod_nss password file > [5/20]: enabling mod_nss renegotiate > [6/20]: adding URL rewriting rules > [7/20]: configuring httpd > [8/20]: configure certmonger for renewals > [9/20]: setting up httpd keytab > [10/20]: setting up ssl > [11/20]: importing CA certificates from LDAP > [12/20]: publish CA cert > [13/20]: clean up any existing httpd ccache > [14/20]: configuring SELinux for httpd > ipa.ipaplatform.redhat.tasks: ERROR Cannot get SELinux boolean > 'httpd_run_ipa': Command '/usr/sbin/getsebool httpd_run_ipa' returned > non-zero exit status 255 > WARNING: Could not set SELinux booleans: httpd_can_network_connect=on > httpd_run_ipa=on httpd_manage_ipa=on > > The web interface may not function correctly until > the booleans are successfully changed with the command: > /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_run_ipa=on > httpd_manage_ipa=on > Try updating the policycoreutils and selinux-policy packages. > [15/20]: create KDC proxy user > [16/20]: create KDC proxy config > [17/20]: enable KDC proxy > [18/20]: restarting httpd > [19/20]: configuring httpd to start on boot > [20/20]: enabling oddjobd > Done configuring the web interface (httpd). > Is there anyone can help me? > > Thanks! > -- > 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 Hi, Have you tried the suggested setsebool command? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.demaria at gmail.com Tue Nov 8 09:13:10 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Tue, 8 Nov 2016 09:13:10 +0000 Subject: [Freeipa-users] ipalib: SEC_ERROR_UNTRUSTED_ISSUER In-Reply-To: <7c5ea164-c992-8903-47bb-29d000ee1841@redhat.com> References: <8fa56583-45d5-5d0d-6800-f5abba6312ac@redhat.com> <7c5ea164-c992-8903-47bb-29d000ee1841@redhat.com> Message-ID: Hello Martin, still no luck unfortunately. The client is an ubuntu 14.04 server, and I believe it is enrolled already. The /etc/ipa/ca.pem is correct and already installed, and I even added it to the /etc/ssl/certs directory (which is why my curl command in the first email does not complain) Commands like *kinit* work just fine, and I have never experienced a problem which would make me doubt of the enrollment of this client. I run the following commands: # mkdir /etc/ipa/nssdb # certutil -A -d /etc/ipa/nssdb -n 'PROD.XXXXXXXXX.COM IPA CA' -t CT,C,C -a < /etc/ipa/ca.crt # chmod +r /etc/ipa/nssdb/* # certutil -L -d /etc/ipa/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI PROD.XXXXXXXX.COM IPA CA CT,C,C But I am still unable to run the script. Is there anything else I need to do? Do I need to restart some components? Any log I could look into? Thank you On 8 November 2016 at 07:56, Martin Babinsky wrote: > On 11/07/2016 04:45 PM, Alessandro De Maria wrote: > >> Hi Martin, >> >> I tried from the host I am executing the script from, and I get: >> certutil -L -d /etc/httpd/alias/ >> certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The >> certificate/key database is in an old, unsupported format. >> >> >> From the FreeIPA server, as I said previously, I get: >> >> certutil -L -d /etc/httpd/alias/ >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> Signing-Cert u,u,u >> ipaCert u,u,u >> Server-Cert u,u,u >> PROD.XXXXXXXXXXXXX.COM IPA CA >> CT,C,C >> >> >> From the FreeIPA server, I seem to be able to run the script, so we are >> definitely on the right track. >> How do I get the /etc/httpd/alias/ in sync across these hosts? can I >> copy it, or is there a way to regenerate it? >> >> Regards >> Alessandro >> >> On 7 November 2016 at 15:36, Alessandro De Maria >> > >> wrote: >> >> Hi Martin, this is the output from the id1 host: >> >> certutil -L -d /etc/httpd/alias/ >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> Signing-Cert u,u,u >> ipaCert u,u,u >> Server-Cert u,u,u >> PROD.XXXXXXXXXXXXX.COM IPA CA >> CT,C,C >> >> >> looks just like you suggested. Any other suggestion? >> >> On 7 November 2016 at 10:56, Martin Babinsky > > wrote: >> >> On 11/04/2016 04:52 PM, Alessandro De Maria wrote: >> >> Hello, >> >> I have a FreeIPA installation that is working very nicely, >> we already >> have configured many hosts and so far we are quite happy >> with it. >> >> I was trying to connect Ansible to fetch hosts from FreeIPA >> using the >> freeipa.py script >> (https://github.com/ansible/ansible/blob/devel/contrib/inven >> tory/freeipa.py >> > tory/freeipa.py>) >> >> >> Unfortunately when I run it, I get the following: >> >> *ipa: ERROR: cert validation failed for >> "CN=id1.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM >> >> " ((SEC_ERROR_UNTRUSTED_ISSUER) >> Peer's >> certificate issuer has been marked as not trusted by the >> user.)* >> *ipa: ERROR: cert validation failed for >> "CN=id2.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM >> >> " ((SEC_ERROR_UNTRUSTED_ISSUER) >> Peer's >> certificate issuer has been marked as not trusted by the >> user.)* >> *Traceback (most recent call last):* >> * File "./freeipa.py", line 82, in * >> * api = initialize()* >> * File "./freeipa.py", line 17, in initialize* >> * api.Backend.rpcclient.connect()* >> * File >> "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line >> 66, >> in connect* >> * conn = self.create_connection(*args, **kw)* >> * File "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", >> line 939, in >> create_connection* >> * error=', '.join(urls))* >> *ipalib.errors.NetworkError: cannot connect to 'any of the >> configured >> servers': https://id1.prod.**xxxxxxxx**.com/ipa/json, >> https://id2.prod.**xxxxxxxx**.com/ipa/json* >> >> >> If I curl the URL, it works just fine ( I imported the CA >> Certificate in >> the system directory /etc/ssl/certs). >> >> I have run `openssl s_client` connect and downloaded the >> remote >> certificate locally, then I run: >> >> # openssl verify cert.pem >> # *id1.prod.**xxxxxxxx**.com.pem*: OK >> >> >> Would you help me figure out what's going on? >> >> >> >> -- >> Alessandro De Maria >> alessandro.demaria at gmail.com >> >> > > >> >> >> >> Hi Alessandro, >> >> this error can mean that the CA certificate in IPA NSS database >> has wrong trust flags set. Please make sure that there is IPA CA >> certificate present on /etc/httpd/alias and it has trust flags >> CT,C,C like this: >> >> # certutil -L -d /etc/httpd/alias/ >> >> Certificate Nickname >> Trust Attributes >> >> SSL,S/MIME,JAR/XPI >> >> ipaCert u,u,u >> Server-Cert u,u,u >> <$REALM> IPA CA >> CT,C,C >> >> -- >> Martin^3 Babinsky >> >> -- >> 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 >> >> >> >> >> -- >> Alessandro De Maria >> alessandro.demaria at gmail.com >> >> >> >> >> -- >> Alessandro De Maria >> alessandro.demaria at gmail.com >> > > Alessandro, > > I have just realized that this may be client-side problem. On the executor > you may need to import CA certificate from IPA server to local > /etc/ipa/nssdb and/or copy it into /etc/ipa/ca.crt as PEM file. > > Or you can just enroll the node as IPA client and it will set up all this > stuff for you. > > -- > Martin^3 Babinsky > -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.karasek at elostech.cz Tue Nov 8 13:41:51 2016 From: jan.karasek at elostech.cz (Jan =?utf-8?Q?Kar=C3=A1sek?=) Date: Tue, 8 Nov 2016 14:41:51 +0100 (CET) Subject: [Freeipa-users] AD trust and UPN issue In-Reply-To: <1912109710.2898761.1462891454156.JavaMail.zimbra@elostech.cz> References: <1912109710.2898761.1462891454156.JavaMail.zimbra@elostech.cz> Message-ID: <723193512.415229.1478612511540.JavaMail.zimbra@elostech.cz> Hi, I can configrm that UPN issue is fixed in RHEL 7.3. That is great, thank you a lot. It looks like solution came with sssd 1.14.x right ? Anybody knows if there are plans to implement it into RHEL 6.x (ipa-client) ? Currently my ipa-clients on RHEL 6.8 (sssd 1.13.3.-22) are not able to handle that. Thanks, Jan ---------------------------------------------------------------------- From: "Jan Kar?sek" To: freeipa-users at redhat.com Sent: Tuesday, May 10, 2016 4:44:14 PM Subject: AD trust and UPN issue Hi, thank you for the answer. I have already tried that workaround and still no luck. At the moment this is showstopper for us on two different projects at two different customers. Any chance to get it patch before 7.3 arrives ? Thanks, Jan ---------------------------------------------------------------------- Date: Tue, 10 May 2016 14:38:01 +0200 From: Jakub Hrozek To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Fwd: AD trust and UPN issue Message-ID: <20160510123801.GE4011 at hendrix> Content-Type: text/plain; charset=iso-8859-1 On Tue, May 10, 2016 at 02:17:07PM +0200, Jan Kar?sek wrote: > Hi all, > I have lab environment with IPA server and trust to Active directory. > IPA server is in a.example.com. > AD DC is in example.com. > We have also child AD subdomain ext.examle.com. > Everything is fine until the users in AD domain ext.example.com gets the UPN suffix of the root AD domain - example.com - which is pretty common scenario. > Example: > user at ext.examaple.com is set in AD with UPN user at example.com > > In this situation I am not able to login into my linux box with user at example.com > I have seen some open tickets on this issue 3559 and others, and they are marked as fixed in IPA 4.2 ... but I not sure if its already fixed in current packages. > Currently I am testing on RHEL7 with ipa-server-4.2.0-15.el7_2.6.1.x86_64 and the same situation is on Fedora 23 with freeipa-server-4.2.4-1.fc23.x86_64. > I have default settings - no changes in krb5.conf and sssd.conf after ipa trust-add. > Also I have found the workaround to set in krb5.conf (see topic: Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues in RH archive ) - add another realm just with EXT.EXAMPLE.COM = { kdc = ad.ext.example.com:88 } - but no effect. > Could you please confirm, that its possible to use IPA with different UPN suffix for users in AD than the domain name in which they are exists ? Is there any additional configuration needed to fix this scenario ? In general no, not until 7.3. But it might work with a workaround. Can you try setting: ldap_user_principal = nosuchattr subdomain_inherit = ldap_user_principal in sssd.conf's domain section on the server? (Yes, server, not client..) This should work without the workaround starting with 7.3.. Jan K ----- Original Message ----- From: "freeipa-users-request" To: freeipa-users at redhat.com Sent: Tuesday, May 10, 2016 4:23:56 PM Subject: Freeipa-users Digest, Vol 94, Issue 63 ---------------------------------------------------------------------- Date: Tue, 10 May 2016 14:38:01 +0200 From: Jakub Hrozek To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Fwd: AD trust and UPN issue Message-ID: <20160510123801.GE4011 at hendrix> Content-Type: text/plain; charset=iso-8859-1 On Tue, May 10, 2016 at 02:17:07PM +0200, Jan Kar?sek wrote: > Hi all, > I have lab environment with IPA server and trust to Active directory. > IPA server is in a.example.com. > AD DC is in example.com. > We have also child AD subdomain ext.examle.com. > Everything is fine until the users in AD domain ext.example.com gets the UPN suffix of the root AD domain - example.com - which is pretty common scenario. > Example: > user at ext.examaple.com is set in AD with UPN user at example.com > > In this situation I am not able to login into my linux box with user at example.com > I have seen some open tickets on this issue 3559 and others, and they are marked as fixed in IPA 4.2 ... but I not sure if its already fixed in current packages. > Currently I am testing on RHEL7 with ipa-server-4.2.0-15.el7_2.6.1.x86_64 and the same situation is on Fedora 23 with freeipa-server-4.2.4-1.fc23.x86_64. > I have default settings - no changes in krb5.conf and sssd.conf after ipa trust-add. > Also I have found the workaround to set in krb5.conf (see topic: Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues in RH archive ) - add another realm just with EXT.EXAMPLE.COM = { kdc = ad.ext.example.com:88 } - but no effect. > Could you please confirm, that its possible to use IPA with different UPN suffix for users in AD than the domain name in which they are exists ? Is there any additional configuration needed to fix this scenario ? In general no, not until 7.3. But it might work with a workaround. Can you try setting: ldap_user_principal = nosuchattr subdomain_inherit = ldap_user_principal in sssd.conf's domain section on the server? (Yes, server, not client..) This should work without the workaround starting with 7.3.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Tue Nov 8 13:53:15 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 8 Nov 2016 14:53:15 +0100 Subject: [Freeipa-users] Configuring httpd error when selinux is permissive In-Reply-To: References: Message-ID: <20161108135314.GJ1874@10.4.128.1> On (08/11/16 16:57), ?? wrote: >Command returns the result: >root at ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_run_ipa=on httpd_manage_ipa=on >Cannot set persistent booleans without managed policy. > >root at ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/getsebool httpd_run_ipa >Error getting active value for httpd_run_ipa > Then it just mean that selinux-policy on ununtu does not contain such boolean. You have few options: * create your own SELinux rules * backport SELinux rules from upstream/fedora * Use freeIPA with SELinux on different distribution. * use freeIPA without SELinux on ubuntu (IIRC the default is Apparmor) LS From peljasz at yahoo.co.uk Tue Nov 8 13:57:07 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 8 Nov 2016 13:57:07 +0000 Subject: [Freeipa-users] system to pick up pa user-mod --uid change - how long? Message-ID: <438af81b-25be-92e2-d3ac-c9d1d803a826@yahoo.co.uk> hello I've changed an uid of a.user but system: $ id a.user - still shows old id. When is the system supposed to notice that change? thanks L. From peljasz at yahoo.co.uk Tue Nov 8 14:19:28 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 8 Nov 2016 14:19:28 +0000 Subject: [Freeipa-users] attrlist_replace - attr_replace : failed Message-ID: hi everyone I have a three servers which seemingly!? work but all three log: attrlist_replace - attr_replace (nsslapd-referral, ldap://swir.xx.xx and swir.xx.xx is the server which ipa-replica-prepared and on it I see: attrlist_replace - attr_replace (nsslapd-referral, ldap://whale.xx.xx ... Error: could not bind id [cn=Replication Manager masterAgreement1-swir.xx.xx-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) where is it going wrong? many thanks L. From rcritten at redhat.com Tue Nov 8 14:55:48 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 8 Nov 2016 09:55:48 -0500 Subject: [Freeipa-users] ipalib: SEC_ERROR_UNTRUSTED_ISSUER In-Reply-To: References: <8fa56583-45d5-5d0d-6800-f5abba6312ac@redhat.com> <7c5ea164-c992-8903-47bb-29d000ee1841@redhat.com> Message-ID: <5821E774.9060306@redhat.com> Alessandro De Maria wrote: > Hello Martin, > > still no luck unfortunately. > > The client is an ubuntu 14.04 server, and I believe it is enrolled already. > > The /etc/ipa/ca.pem is correct and already installed, and I even added > it to the /etc/ssl/certs directory (which is why my curl command in the > first email does not complain) The client normally uses /etc/ipa/nssdb for NSS. I'm not sure how this is handled on Ubuntu clients but you'll need to confirm that whatever Ubuntu uses exists and has the IPA CA certificate installed. rob > > Commands like /kinit/ work just fine, and I have never experienced a > problem which would make me doubt of the enrollment of this client. > > > I run the following commands: > # mkdir /etc/ipa/nssdb > # certutil -A -d /etc/ipa/nssdb -n 'PROD.XXXXXXXXX.COM > IPA CA' -t CT,C,C -a < /etc/ipa/ca.crt > # chmod +r /etc/ipa/nssdb/* > # certutil -L -d /etc/ipa/nssdb > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > PROD.XXXXXXXX.COM IPA CA > CT,C,C > > But I am still unable to run the script. > Is there anything else I need to do? Do I need to restart some > components? Any log I could look into? > > Thank you > > > On 8 November 2016 at 07:56, Martin Babinsky > wrote: > > On 11/07/2016 04:45 PM, Alessandro De Maria wrote: > > Hi Martin, > > I tried from the host I am executing the script from, and I get: > certutil -L -d /etc/httpd/alias/ > certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The > certificate/key database is in an old, unsupported format. > > > >From the FreeIPA server, as I said previously, I get: > > certutil -L -d /etc/httpd/alias/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > Signing-Cert u,u,u > ipaCert u,u,u > Server-Cert u,u,u > PROD.XXXXXXXXXXXXX.COM > > IPA CA > CT,C,C > > > >From the FreeIPA server, I seem to be able to run the script, so we are > definitely on the right track. > How do I get the /etc/httpd/alias/ in sync across these hosts? can I > copy it, or is there a way to regenerate it? > > Regards > Alessandro > > On 7 November 2016 at 15:36, Alessandro De Maria > > >> wrote: > > Hi Martin, this is the output from the id1 host: > > certutil -L -d /etc/httpd/alias/ > > Certificate Nickname > Trust > Attributes > > SSL,S/MIME,JAR/XPI > > Signing-Cert > u,u,u > ipaCert > u,u,u > Server-Cert > u,u,u > PROD.XXXXXXXXXXXXX.COM > IPA CA > CT,C,C > > > looks just like you suggested. Any other suggestion? > > On 7 November 2016 at 10:56, Martin Babinsky > > >> > wrote: > > On 11/04/2016 04:52 PM, Alessandro De Maria wrote: > > Hello, > > I have a FreeIPA installation that is working very > nicely, > we already > have configured many hosts and so far we are quite happy > with it. > > I was trying to connect Ansible to fetch hosts from > FreeIPA > using the > freeipa.py script > > (https://github.com/ansible/ansible/blob/devel/contrib/inventory/freeipa.py > > > >) > > > Unfortunately when I run it, I get the following: > > *ipa: ERROR: cert validation failed for > "CN=id1.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM > > > " > ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's > certificate issuer has been marked as not trusted by > the user.)* > *ipa: ERROR: cert validation failed for > "CN=id2.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM > > > " > ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's > certificate issuer has been marked as not trusted by > the user.)* > *Traceback (most recent call last):* > * File "./freeipa.py", line 82, in * > * api = initialize()* > * File "./freeipa.py", line 17, in initialize* > * api.Backend.rpcclient.connect()* > * File > > "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line 66, > in connect* > * conn = self.create_connection(*args, **kw)* > * File > "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", > line 939, in > create_connection* > * error=', '.join(urls))* > *ipalib.errors.NetworkError: cannot connect to 'any > of the > configured > servers': https://id1.prod.**xxxxxxxx**.com/ipa/json, > https://id2.prod.**xxxxxxxx**.com/ipa/json* > > > If I curl the URL, it works just fine ( I imported > the CA > Certificate in > the system directory /etc/ssl/certs). > > I have run `openssl s_client` connect and downloaded > the remote > certificate locally, then I run: > > # openssl verify cert.pem > # *id1.prod.**xxxxxxxx**.com.pem*: OK > > > Would you help me figure out what's going on? > > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com > > > > > >> > > > > Hi Alessandro, > > this error can mean that the CA certificate in IPA NSS > database > has wrong trust flags set. Please make sure that there > is IPA CA > certificate present on /etc/httpd/alias and it has trust > flags > CT,C,C like this: > > # certutil -L -d /etc/httpd/alias/ > > Certificate Nickname > Trust Attributes > > SSL,S/MIME,JAR/XPI > > ipaCert > u,u,u > Server-Cert > u,u,u > <$REALM> IPA CA > CT,C,C > > -- > Martin^3 Babinsky > > -- > 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 > > > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com > > > > > > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com > > > > > > Alessandro, > > I have just realized that this may be client-side problem. On the > executor you may need to import CA certificate from IPA server to > local /etc/ipa/nssdb and/or copy it into /etc/ipa/ca.crt as PEM file. > > Or you can just enroll the node as IPA client and it will set up all > this stuff for you. > > -- > Martin^3 Babinsky > > > > > -- > Alessandro De Maria > alessandro.demaria at gmail.com > > From mbasti at redhat.com Tue Nov 8 14:59:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 8 Nov 2016 15:59:00 +0100 Subject: [Freeipa-users] system to pick up pa user-mod --uid change - how long? In-Reply-To: <438af81b-25be-92e2-d3ac-c9d1d803a826@yahoo.co.uk> References: <438af81b-25be-92e2-d3ac-c9d1d803a826@yahoo.co.uk> Message-ID: <4f6cd87a-d254-7fd5-1429-aa3c6639362d@redhat.com> On 08.11.2016 14:57, lejeczek wrote: > hello > > I've changed an uid of a.user but system: $ id a.user - still shows > old id. > When is the system supposed to notice that change? > > thanks > L. > Hello, you probably need to erase SSSD cache on client, sss_cache -E if I remember correctly Martin From b.candler at pobox.com Tue Nov 8 15:09:35 2016 From: b.candler at pobox.com (Brian Candler) Date: Tue, 8 Nov 2016 15:09:35 +0000 Subject: [Freeipa-users] system to pick up pa user-mod --uid change - how long? In-Reply-To: <438af81b-25be-92e2-d3ac-c9d1d803a826@yahoo.co.uk> References: <438af81b-25be-92e2-d3ac-c9d1d803a826@yahoo.co.uk> Message-ID: <8b9c9b22-112d-bd4e-81b9-3b83bde199b5@pobox.com> On 08/11/2016 13:57, lejeczek wrote: > I've changed an uid of a.user but system: $ id a.user - still shows > old id. > When is the system supposed to notice that change? You might want to force the cache to expire early. Try: sss_cache -U or sss_cache -u (I'm afraid I don't know what the automatic expiry time is) From craig.mcniel at pearson.com Tue Nov 8 15:11:50 2016 From: craig.mcniel at pearson.com (McNiel, Craig) Date: Tue, 8 Nov 2016 09:11:50 -0600 Subject: [Freeipa-users] Determine if hosts are still active. Message-ID: I'm running IPA 4.2 in SSO in a highly dynamic AWS EC2 environment. Is there a way to tell if a host that has joined the domain is still active using an LDAP query so that I can determine hosts that have been torn down and no longer exist and remove them from the directory? I have looked at several different attributes in LDAP but, none of them seem to provide any information on the last time the host authenticated or communicated with an IPA master. Thanks ! Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From peljasz at yahoo.co.uk Tue Nov 8 16:02:18 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 8 Nov 2016 16:02:18 +0000 Subject: [Freeipa-users] CSN not found In-Reply-To: References: <4c238a79-e31d-6a7e-ab78-66a6f6f5fe13@yahoo.co.uk> <65afd1fd-9737-17bf-8af1-47d855f1f53c@redhat.com> Message-ID: <80288bed-43a8-da28-9d63-51072791d42b@yahoo.co.uk> On 03/11/16 19:58, Mark Reynolds wrote: >>> dbscan -f /var/lib/dirsrv/slapd-INSTANCE/db/changelogdb >> >results of above scan do not look like that CSN form reported in >> >dirsrv's error log, it is: >> >.. >> >=116156 >> >=116157 >> >=116158 >> >.. > That doesn't look quite right, Just to confirm you should be doing > something like > > dbscan -f > /var/lib/dirsrv/slapd-master_1/db/changelogdb/fe665489-a13011e6-acbab8c1-43b12a38_581a3c41000000010000.db > | grep 581b120f000500040000 I don't see any xxxxxx.db in /var/lib/dirsrv/slapd-master_1/db/changelogdb but there are these: 16c9da9e-a54611e6-80ab82b9-81e5c5a8_57459622000000600000.db 16c9da9e-a54611e6-80ab82b9-81e5c5a8.sema DBVERSION e71ad28c-a54511e6-80ab82b9-81e5c5a8_574595c8000000040000.db e71ad28c-a54511e6-80ab82b9-81e5c5a8.sema in /var/lib/dirsrv/slapd-master_1/cldb and if I scant those: cldb]$ for _F in .db; do dbscan -f $_F | grep 57480d6d000000250000; done there is nothing (on the replica that complains but also nothing on all members) cldb]$ ll ../db/changelog/ total 2260 -rw-------. 1 dirsrv dirsrv 16384 Nov 8 00:02 aci.db -rw-------. 1 dirsrv dirsrv 40960 Nov 8 15:52 ancestorid.db -rw-------. 1 dirsrv dirsrv 40960 Nov 8 15:52 changenumber.db -rw-------. 1 dirsrv dirsrv 16384 Nov 8 00:02 cn.db -rw-------. 1 dirsrv dirsrv 51 Nov 8 00:02 DBVERSION -rw-------. 1 dirsrv dirsrv 303104 Nov 8 15:52 entryrdn.db -rw-------. 1 dirsrv dirsrv 40960 Nov 8 15:52 entryusn.db -rw-------. 1 dirsrv dirsrv 1523712 Nov 8 15:52 id2entry.db -rw-------. 1 dirsrv dirsrv 90112 Nov 8 15:52 nsuniqueid.db -rw-------. 1 dirsrv dirsrv 16384 Nov 8 15:52 numsubordinates.db -rw-------. 1 dirsrv dirsrv 90112 Nov 8 15:52 objectclass.db -rw-------. 1 dirsrv dirsrv 40960 Nov 8 15:52 parentid.db -rw-------. 1 dirsrv dirsrv 16384 Nov 8 00:02 seeAlso.db -rw-------. 1 dirsrv dirsrv 65536 Nov 8 15:52 targetuniqueid.db it's centOS 7 with IPA ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 >>> >> >>> >>What about the access logs? Do you see the CSN there? > Did you check the DS access logs?? From askstack at yahoo.com Tue Nov 8 16:13:05 2016 From: askstack at yahoo.com (Ask Stack) Date: Tue, 8 Nov 2016 16:13:05 +0000 (UTC) Subject: [Freeipa-users] What is the use of /etc/krb5.conf? References: <1065494049.632733.1478621585379.ref@mail.yahoo.com> Message-ID: <1065494049.632733.1478621585379@mail.yahoo.com> I thought /etc/krb5.conf controls which kerberos server the clients talk to. As a test, I removed /etc/krb5.conf and rebooted the client. After reboot, I can still log in and "kinit user" . Removing /etc/krb5.keytab, however would stop user from logging in and sssd to start. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Tue Nov 8 16:56:06 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 8 Nov 2016 17:56:06 +0100 Subject: [Freeipa-users] What is the use of /etc/krb5.conf? In-Reply-To: <1065494049.632733.1478621585379@mail.yahoo.com> References: <1065494049.632733.1478621585379.ref@mail.yahoo.com> <1065494049.632733.1478621585379@mail.yahoo.com> Message-ID: <07467670-4693-1441-48c4-ba302c02a80c@redhat.com> On 11/08/2016 05:13 PM, Ask Stack wrote: > I thought /etc/krb5.conf controls which kerberos server the clients talk > to. > > As a test, I removed /etc/krb5.conf and rebooted the client. After > reboot, I can still log in and "kinit user" . > Removing /etc/krb5.keytab, however would stop user from logging in and > sssd to start. > > > /etc/krb5.conf configures Kerberos client library: it instructs the client about which realm it should use, whether to use dns discovery or use static list of KDC and mapping between DNS domains and realms. Read `man krb5.conf' for more info. sssd stores plenty of information about Kerberos realm in its own configuration (realm, DNS discovery etc.) so it can authenticate the user even without valid krb5.conf (as you observed). However, to pull in user info from authoritative source (IPA LDAP), sssd authenticates against IPA as the host principal using /etc/krb5.keytab, that's why it stopped working and refused to start after you removed it. -- Martin^3 Babinsky From peljasz at yahoo.co.uk Tue Nov 8 18:41:14 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 8 Nov 2016 18:41:14 +0000 Subject: [Freeipa-users] SRV (mixed?) records Message-ID: hi everyone when I look at my domain I see something which seems inconsistent to me (eg. work5 is not part of the domain, was --uninstalled) Do these record need fixing? I'm asking becuase one of the servers, despite the fact the ipa dns related toolkit(on that server) shows zone & records, to dig/host/etc. presents nothing, empty responses!?? $ ipa dnsrecord-find xx.xx.xx.xx.x. Record name: @ NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. Record name: _kerberos TXT record: .xx.xx..xx.xx.x Record name: _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs SRV record: 0 100 88 rider, 0 100 88 work5 Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs SRV record: 0 100 389 rider, 0 100 389 work5 Record name: _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs SRV record: 0 100 88 rider, 0 100 88 work5 Record name: _kerberos._tcp.dc._msdcs SRV record: 0 100 88 rider, 0 100 88 work5 Record name: _ldap._tcp.dc._msdcs SRV record: 0 100 389 rider, 0 100 389 work5 Record name: _kerberos._udp.dc._msdcs SRV record: 0 100 88 rider, 0 100 88 work5 Record name: _kerberos._tcp SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 88 swir Record name: _kerberos-master._tcp SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 88 swir Record name: _kpasswd._tcp SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100 464 whale Record name: _ldap._tcp SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 whale, 0 100 389 rider Record name: _kerberos._udp SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 88 swir Record name: _kerberos-master._udp SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 88 swir Record name: _kpasswd._udp SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100 464 whale Record name: _ntp._udp SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 123 whale, 0 100 123 swir thanks. L. From mbasti at redhat.com Tue Nov 8 19:37:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 8 Nov 2016 20:37:07 +0100 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: References: Message-ID: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> On 08.11.2016 19:41, lejeczek wrote: > hi everyone > when I look at my domain I see something which seems inconsistent to > me (eg. work5 is not part of the domain, was --uninstalled) > Do these record need fixing? > I'm asking becuase one of the servers, despite the fact the ipa dns > related toolkit(on that server) shows zone & records, to dig/host/etc. > presents nothing, empty responses!?? > > $ ipa dnsrecord-find xx.xx.xx.xx.x. > Record name: @ > NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., > dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. > > Record name: _kerberos > TXT record: .xx.xx..xx.xx.x > > Record name: _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs > SRV record: 0 100 88 rider, 0 100 88 work5 > > Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs > SRV record: 0 100 389 rider, 0 100 389 work5 > > Record name: _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs > SRV record: 0 100 88 rider, 0 100 88 work5 > > Record name: _kerberos._tcp.dc._msdcs > SRV record: 0 100 88 rider, 0 100 88 work5 > > Record name: _ldap._tcp.dc._msdcs > SRV record: 0 100 389 rider, 0 100 389 work5 > > Record name: _kerberos._udp.dc._msdcs > SRV record: 0 100 88 rider, 0 100 88 work5 > > Record name: _kerberos._tcp > SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 88 > swir > > Record name: _kerberos-master._tcp > SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 88 > swir > > Record name: _kpasswd._tcp > SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100 > 464 whale > > Record name: _ldap._tcp > SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 whale, 0 100 > 389 rider > > Record name: _kerberos._udp > SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 88 > swir > > Record name: _kerberos-master._udp > SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 88 > swir > > Record name: _kpasswd._udp > SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100 > 464 whale > > Record name: _ntp._udp > SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 123 whale, 0 100 > 123 swir > > thanks. > L. > Hello, if server work5 is uninstalled, then work5 SRV records should be removed. Martin From alessandro.demaria at gmail.com Tue Nov 8 20:27:17 2016 From: alessandro.demaria at gmail.com (Alessandro De Maria) Date: Tue, 8 Nov 2016 20:27:17 +0000 Subject: [Freeipa-users] ipalib: SEC_ERROR_UNTRUSTED_ISSUER In-Reply-To: <5821E774.9060306@redhat.com> References: <8fa56583-45d5-5d0d-6800-f5abba6312ac@redhat.com> <7c5ea164-c992-8903-47bb-29d000ee1841@redhat.com> <5821E774.9060306@redhat.com> Message-ID: Thank you Rob and Martin, the correct place on Ubuntu seems to be: /etc/pki/nssdb/ This directory does not seem to be initialised by the *ipa-client-install* tool. Now my script still doesn't work, but offer brand new errors :) Thank you On 8 November 2016 at 14:55, Rob Crittenden wrote: > Alessandro De Maria wrote: > > Hello Martin, > > > > still no luck unfortunately. > > > > The client is an ubuntu 14.04 server, and I believe it is enrolled > already. > > > > The /etc/ipa/ca.pem is correct and already installed, and I even added > > it to the /etc/ssl/certs directory (which is why my curl command in the > > first email does not complain) > > The client normally uses /etc/ipa/nssdb for NSS. I'm not sure how this > is handled on Ubuntu clients but you'll need to confirm that whatever > Ubuntu uses exists and has the IPA CA certificate installed. > > rob > > > > > Commands like /kinit/ work just fine, and I have never experienced a > > problem which would make me doubt of the enrollment of this client. > > > > > > I run the following commands: > > # mkdir /etc/ipa/nssdb > > # certutil -A -d /etc/ipa/nssdb -n 'PROD.XXXXXXXXX.COM > > IPA CA' -t CT,C,C -a < /etc/ipa/ca.crt > > # chmod +r /etc/ipa/nssdb/* > > # certutil -L -d /etc/ipa/nssdb > > > > Certificate Nickname Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > PROD.XXXXXXXX.COM IPA CA > > CT,C,C > > > > But I am still unable to run the script. > > Is there anything else I need to do? Do I need to restart some > > components? Any log I could look into? > > > > Thank you > > > > > > On 8 November 2016 at 07:56, Martin Babinsky > > wrote: > > > > On 11/07/2016 04:45 PM, Alessandro De Maria wrote: > > > > Hi Martin, > > > > I tried from the host I am executing the script from, and I get: > > certutil -L -d /etc/httpd/alias/ > > certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The > > certificate/key database is in an old, unsupported format. > > > > > > >From the FreeIPA server, as I said previously, I get: > > > > certutil -L -d /etc/httpd/alias/ > > > > Certificate Nickname > Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > Signing-Cert > u,u,u > > ipaCert > u,u,u > > Server-Cert > u,u,u > > PROD.XXXXXXXXXXXXX.COM > > > > IPA CA > > CT,C,C > > > > > > >From the FreeIPA server, I seem to be able to run the script, > so we are > > definitely on the right track. > > How do I get the /etc/httpd/alias/ in sync across these hosts? > can I > > copy it, or is there a way to regenerate it? > > > > Regards > > Alessandro > > > > On 7 November 2016 at 15:36, Alessandro De Maria > > > > > > >> wrote: > > > > Hi Martin, this is the output from the id1 host: > > > > certutil -L -d /etc/httpd/alias/ > > > > Certificate Nickname > > Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > > > Signing-Cert > > u,u,u > > ipaCert > > u,u,u > > Server-Cert > > u,u,u > > PROD.XXXXXXXXXXXXX.COM > > IPA CA > > CT,C,C > > > > > > looks just like you suggested. Any other suggestion? > > > > On 7 November 2016 at 10:56, Martin Babinsky > > > > >> > > wrote: > > > > On 11/04/2016 04:52 PM, Alessandro De Maria wrote: > > > > Hello, > > > > I have a FreeIPA installation that is working very > > nicely, > > we already > > have configured many hosts and so far we are quite > happy > > with it. > > > > I was trying to connect Ansible to fetch hosts from > > FreeIPA > > using the > > freeipa.py script > > > > (https://github.com/ansible/ansible/blob/devel/contrib/ > inventory/freeipa.py > > inventory/freeipa.py> > > > > inventory/freeipa.py > > inventory/freeipa.py>>) > > > > > > Unfortunately when I run it, I get the following: > > > > *ipa: ERROR: cert validation failed for > > "CN=id1.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM > > > > > > " > > ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's > > certificate issuer has been marked as not trusted by > > the user.)* > > *ipa: ERROR: cert validation failed for > > "CN=id2.prod.**xxxxxxxx**.com,O=PROD.xxxxxxxx.COM > > > > > > " > > ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's > > certificate issuer has been marked as not trusted by > > the user.)* > > *Traceback (most recent call last):* > > * File "./freeipa.py", line 82, in * > > * api = initialize()* > > * File "./freeipa.py", line 17, in initialize* > > * api.Backend.rpcclient.connect()* > > * File > > > > "/usr/lib/python2.7/dist-packages/ipalib/backend.py", line 66, > > in connect* > > * conn = self.create_connection(*args, **kw)* > > * File > > "/usr/lib/python2.7/dist-packages/ipalib/rpc.py", > > line 939, in > > create_connection* > > * error=', '.join(urls))* > > *ipalib.errors.NetworkError: cannot connect to 'any > > of the > > configured > > servers': https://id1.prod.**xxxxxxxx**. > com/ipa/json, > > https://id2.prod.**xxxxxxxx**.com/ipa/json* > > > > > > If I curl the URL, it works just fine ( I imported > > the CA > > Certificate in > > the system directory /etc/ssl/certs). > > > > I have run `openssl s_client` connect and downloaded > > the remote > > certificate locally, then I run: > > > > # openssl verify cert.pem > > # *id1.prod.**xxxxxxxx**.com.pem*: OK > > > > > > Would you help me figure out what's going on? > > > > > > > > -- > > Alessandro De Maria > > alessandro.demaria at gmail.com > > > > > > > > > > > > >> > > > > > > > > Hi Alessandro, > > > > this error can mean that the CA certificate in IPA NSS > > database > > has wrong trust flags set. Please make sure that there > > is IPA CA > > certificate present on /etc/httpd/alias and it has trust > > flags > > CT,C,C like this: > > > > # certutil -L -d /etc/httpd/alias/ > > > > Certificate Nickname > > Trust Attributes > > > > SSL,S/MIME,JAR/XPI > > > > ipaCert > > u,u,u > > Server-Cert > > u,u,u > > <$REALM> IPA CA > > CT,C,C > > > > -- > > Martin^3 Babinsky > > > > -- > > 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 > > > > > > > > > > -- > > Alessandro De Maria > > alessandro.demaria at gmail.com > > > > > > > > > > > > > > > > -- > > Alessandro De Maria > > alessandro.demaria at gmail.com > > > > > > > > > > > > Alessandro, > > > > I have just realized that this may be client-side problem. On the > > executor you may need to import CA certificate from IPA server to > > local /etc/ipa/nssdb and/or copy it into /etc/ipa/ca.crt as PEM file. > > > > Or you can just enroll the node as IPA client and it will set up all > > this stuff for you. > > > > -- > > Martin^3 Babinsky > > > > > > > > > > -- > > Alessandro De Maria > > alessandro.demaria at gmail.com > > > > > > -- Alessandro De Maria alessandro.demaria at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhenglei at kylinos.cn Wed Nov 9 01:14:07 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Wed, 9 Nov 2016 09:14:07 +0800 Subject: [Freeipa-users] Configuring httpd error when selinux ispermissive In-Reply-To: <20161108135314.GJ1874@10.4.128.1> References: <20161108135314.GJ1874@10.4.128.1> Message-ID: I will try to your solutions. Thanks! ------------------ ?? ?????????? -------------------------- ?????? ?? ???18684703229 ???zhenglei at kylinos.cn ??????????????? ?????????????????????? ------------------ Original ------------------ From: "Lukas Slebodnik"; Date: Tue, Nov 8, 2016 09:53 PM To: "??"; Cc: "Umarzuki Mochlis"; "freeipa-users"; Subject: Re: [Freeipa-users] Configuring httpd error when selinux ispermissive On (08/11/16 16:57), ?? wrote: >Command returns the result: >root at ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_run_ipa=on httpd_manage_ipa=on >Cannot set persistent booleans without managed policy. > >root at ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/getsebool httpd_run_ipa >Error getting active value for httpd_run_ipa > Then it just mean that selinux-policy on ununtu does not contain such boolean. You have few options: * create your own SELinux rules * backport SELinux rules from upstream/fedora * Use freeIPA with SELinux on different distribution. * use freeIPA without SELinux on ubuntu (IIRC the default is Apparmor) LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhenglei at kylinos.cn Wed Nov 9 01:45:01 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Wed, 9 Nov 2016 09:45:01 +0800 Subject: [Freeipa-users] Configuring httpd error when selinux ispermissive In-Reply-To: <20161108135314.GJ1874@10.4.128.1> References: <20161108135314.GJ1874@10.4.128.1> Message-ID: Yes, the problem is solved after I added the httpd_run_ipa boolean to the selinux-policy on Ubuntu. Thank you! ------------------ ?? ?????????? -------------------------- ?????? ?? ???18684703229 ???zhenglei at kylinos.cn ??????????????? ?????????????????????? ------------------ Original ------------------ From: "Lukas Slebodnik"; Date: Tue, Nov 8, 2016 09:53 PM To: "??"; Cc: "Umarzuki Mochlis"; "freeipa-users"; Subject: Re: [Freeipa-users] Configuring httpd error when selinux ispermissive On (08/11/16 16:57), ?? wrote: >Command returns the result: >root at ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/setsebool -P httpd_can_network_connect=on httpd_run_ipa=on httpd_manage_ipa=on >Cannot set persistent booleans without managed policy. > >root at ipaserver:/tmp/freeipa-4.3.1# /usr/sbin/getsebool httpd_run_ipa >Error getting active value for httpd_run_ipa > Then it just mean that selinux-policy on ununtu does not contain such boolean. You have few options: * create your own SELinux rules * backport SELinux rules from upstream/fedora * Use freeIPA with SELinux on different distribution. * use freeIPA without SELinux on ubuntu (IIRC the default is Apparmor) LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Nov 9 07:46:21 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 9 Nov 2016 08:46:21 +0100 Subject: [Freeipa-users] FreeIPA + DHCP-LDAP - Fedora 24 - broken In-Reply-To: <309dcd97-8598-2d28-608d-024e20f04a2c@dias.com.br> References: <309dcd97-8598-2d28-608d-024e20f04a2c@dias.com.br> Message-ID: On 7.11.2016 17:45, Raul Dias wrote: > You are right, > > This might be more a Fedora issue than FreeIPA. I am hoping that someone else > is also using DHCP with LDAP (specially with FreeIPA). > > I am using the IPA-dhcp plugin: https://github.com/jefferyharrell/IPA-dhcp > > ldapsearch -x shows the entries are fine in the LDAP. > > Stracing dhcpd shows that it is not making any connection to the LDAP, while > it shows an error message. > > On Fedora 24 (updated), I am using dhcp-server-4.3.4.fc24 > > /etc/dhcp/dhcpd.conf: > ldap-server "10.101.1.1"; #or localhost, or any interface ip or ns name > ldap-port 389; > ldap-base-dn "cn=dhcp,dc=dias,dc=com,dc=br"; > ldap-method static; > ldap-debug-file "/var/log/dhcp-ldap-startup.log"; > > The STDERR output acts as if it were talking to the LDAP server: > > Cannot find host LDAP entry server.dias.com.br > (&(objectClass=dhcpServer)(cn=server.dias.com.br)) > > As the output of ldapsearch, the entry is there: > # server.dias.com.br, dhcp, dias.com.br > dn: cn=server.dias.com.br,cn=dhcp,dc=dias,dc=com,dc=br > objectClass: dhcpserver > objectClass: top > dhcpServiceDN: cn=dhcp,dc=dias,dc=com,dc=br > cn: server.dias.com.br > dhcpStatements: authoritative > > Using the same config on a ubuntu host, it works fine, which makes me wonder > that dhcpd in Fedora 24 does not work at all with LDAP. Do you mean that dhcpd on Ubuntu is configured against the very same FreeIPA server? Are you sure that dhcpd is using the same credentials to BIND to LDAP? There might be an access control issue if different hosts use different credentials or so. It would help if you described how you bound to LDAP using ldapsearch. Petr^2 Spacek > > Or maybe this is a reflection of some FreeIPA server way of life > configuration, like sssd. > > -rsd > > > On 07/11/2016 05:10, Petr Spacek wrote: >> On 6.11.2016 06:06, Raul Dias wrote: >>> Hello, >>> >>> It seems that DHCP with LDAP on Fedora 24 (FreeIPA) is broken. >>> >>> Can anyone confirm? >>> >>> Doing an strace -e trace=network does not show any attempt to connect to the >>> ldap server. >>> >>> OTOH, the same config on a Ubuntu 16.10 works fine. >> Hello, >> >> AFAIK DHCP support was never part of official FreeIPA builds. What are you >> trying to achieve and where did you get the builds? >> >> We need to know exact software versions and configuration. For further hints >> how to report bugs please see >> http://www.freeipa.org/page/Troubleshooting#Reporting_bugs >> > -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 9 07:47:50 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 9 Nov 2016 08:47:50 +0100 Subject: [Freeipa-users] attrlist_replace - attr_replace : failed In-Reply-To: References: Message-ID: <7664acda-2ac3-72ef-b9fb-9939b7318a53@redhat.com> On 8.11.2016 15:19, lejeczek wrote: > hi everyone > > I have a three servers which seemingly!? work but all three log: > > attrlist_replace - attr_replace (nsslapd-referral, ldap://swir.xx.xx > > and swir.xx.xx is the server which ipa-replica-prepared and on it I see: > > attrlist_replace - attr_replace (nsslapd-referral, ldap://whale.xx.xx > ... > Error: could not bind id [cn=Replication Manager > masterAgreement1-swir.xx.xx-pki-tomcat,ou=csusers,cn=config] authentication > mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) > > where is it going wrong? You redacted too much of the log but from what I can see, I guess that it is this: http://www.freeipa.org/page/Troubleshooting#Obsolete_RUV_records -- Petr^2 Spacek From peljasz at yahoo.co.uk Wed Nov 9 11:15:36 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 9 Nov 2016 11:15:36 +0000 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> Message-ID: <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> On 08/11/16 19:37, Martin Basti wrote: > > > On 08.11.2016 19:41, lejeczek wrote: >> hi everyone >> when I look at my domain I see something which seems >> inconsistent to me (eg. work5 is not part of the domain, >> was --uninstalled) >> Do these record need fixing? >> I'm asking becuase one of the servers, despite the fact >> the ipa dns related toolkit(on that server) shows zone & >> records, to dig/host/etc. presents nothing, empty >> responses!?? >> >> $ ipa dnsrecord-find xx.xx.xx.xx.x. >> Record name: @ >> NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., >> dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. >> >> Record name: _kerberos >> TXT record: .xx.xx..xx.xx.x >> >> Record name: >> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs >> SRV record: 0 100 88 rider, 0 100 88 work5 >> >> Record name: >> _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs >> SRV record: 0 100 389 rider, 0 100 389 work5 >> >> Record name: >> _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs >> SRV record: 0 100 88 rider, 0 100 88 work5 >> >> Record name: _kerberos._tcp.dc._msdcs >> SRV record: 0 100 88 rider, 0 100 88 work5 >> >> Record name: _ldap._tcp.dc._msdcs >> SRV record: 0 100 389 rider, 0 100 389 work5 >> >> Record name: _kerberos._udp.dc._msdcs >> SRV record: 0 100 88 rider, 0 100 88 work5 >> >> Record name: _kerberos._tcp >> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 >> rider, 0 100 88 swir >> >> Record name: _kerberos-master._tcp >> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 >> rider, 0 100 88 swir >> >> Record name: _kpasswd._tcp >> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 >> dzien, 0 100 464 whale >> >> Record name: _ldap._tcp >> SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 >> whale, 0 100 389 rider >> >> Record name: _kerberos._udp >> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 >> rider, 0 100 88 swir >> >> Record name: _kerberos-master._udp >> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 >> rider, 0 100 88 swir >> >> Record name: _kpasswd._udp >> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 >> dzien, 0 100 464 whale >> >> Record name: _ntp._udp >> SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 123 >> whale, 0 100 123 swir >> >> thanks. >> L. >> > > > Hello, > > if server work5 is uninstalled, then work5 SRV records > should be removed. > > Martin Martin, would you be able suggest a way to troubleshoot that problem that one (only) server (rider) seems to present no data for the whole domain? Remaining servers correctly respond to any queries. One curious thing is that I $rndc trace 6; and (I see debug level changed in journalctl) I do not see anything in the logs when I query. Zone allows any to query it. From prasun.gera at gmail.com Wed Nov 9 11:43:52 2016 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 9 Nov 2016 06:43:52 -0500 Subject: [Freeipa-users] Package naming conflicts with update to RHEL 7.3 In-Reply-To: References: Message-ID: Thanks Martin. That bug report is private. I take it that it's not very serious ? On Mon, Nov 7, 2016 at 3:12 AM, Martin Babinsky wrote: > On 11/07/2016 01:31 AM, Prasun Gera wrote: > >> Getting this in yum check all after update to 7.3 >> >> ipa-client-4.4.0-12.el7.x86_64 has installed conflicts freeipa-client: >> ipa-client-4.4.0-12.el7.x86_64 >> ipa-client-common-4.4.0-12.el7.noarch has installed conflicts >> freeipa-client-common: ipa-client-common-4.4.0-12.el7.noarch >> ipa-common-4.4.0-12.el7.noarch has installed conflicts freeipa-common: >> ipa-common-4.4.0-12.el7.noarch >> ipa-python-compat-4.4.0-12.el7.noarch has installed conflicts >> freeipa-python-compat: ipa-python-compat-4.4.0-12.el7.noarch >> >> >> >> > Hi Prasun, > > That is a false positive caused by a bug in yum, see > https://bugzilla.redhat.com/show_bug.cgi?id=1370134 > > -- > Martin^3 Babinsky > > -- > 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 prasun.gera at gmail.com Wed Nov 9 11:53:01 2016 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 9 Nov 2016 06:53:01 -0500 Subject: [Freeipa-users] IDM server doesn't boot after update to RHEL 7.3 Message-ID: It looks like something is messed up in the systemd configuration after 7.3. My system doesn't boot at all. The boot screen would display the message: "Failed to register match for Disconnected message: Connection timed out". After some trial and error, I've managed to boot it. Here's what works right now: 1) Boot into system rescue target with debug shell 2) start sssd 3) isolate graphical.target I have a replica which I haven't upgraded to 7.3 yet. So I can compare the two systems to isolate the problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Nov 9 12:43:01 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 9 Nov 2016 13:43:01 +0100 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> Message-ID: <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> On 09.11.2016 12:15, lejeczek wrote: > > > On 08/11/16 19:37, Martin Basti wrote: >> >> >> On 08.11.2016 19:41, lejeczek wrote: >>> hi everyone >>> when I look at my domain I see something which seems inconsistent to >>> me (eg. work5 is not part of the domain, was --uninstalled) >>> Do these record need fixing? >>> I'm asking becuase one of the servers, despite the fact the ipa dns >>> related toolkit(on that server) shows zone & records, to >>> dig/host/etc. presents nothing, empty responses!?? >>> >>> $ ipa dnsrecord-find xx.xx.xx.xx.x. >>> Record name: @ >>> NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., >>> dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. >>> >>> Record name: _kerberos >>> TXT record: .xx.xx..xx.xx.x >>> >>> Record name: _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs >>> SRV record: 0 100 88 rider, 0 100 88 work5 >>> >>> Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs >>> SRV record: 0 100 389 rider, 0 100 389 work5 >>> >>> Record name: _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs >>> SRV record: 0 100 88 rider, 0 100 88 work5 >>> >>> Record name: _kerberos._tcp.dc._msdcs >>> SRV record: 0 100 88 rider, 0 100 88 work5 >>> >>> Record name: _ldap._tcp.dc._msdcs >>> SRV record: 0 100 389 rider, 0 100 389 work5 >>> >>> Record name: _kerberos._udp.dc._msdcs >>> SRV record: 0 100 88 rider, 0 100 88 work5 >>> >>> Record name: _kerberos._tcp >>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>> 88 swir >>> >>> Record name: _kerberos-master._tcp >>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>> 88 swir >>> >>> Record name: _kpasswd._tcp >>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 >>> 100 464 whale >>> >>> Record name: _ldap._tcp >>> SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 whale, 0 >>> 100 389 rider >>> >>> Record name: _kerberos._udp >>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>> 88 swir >>> >>> Record name: _kerberos-master._udp >>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>> 88 swir >>> >>> Record name: _kpasswd._udp >>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 >>> 100 464 whale >>> >>> Record name: _ntp._udp >>> SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 123 whale, 0 >>> 100 123 swir >>> >>> thanks. >>> L. >>> >> >> >> Hello, >> >> if server work5 is uninstalled, then work5 SRV records should be >> removed. >> >> Martin > > Martin, would you be able suggest a way to troubleshoot that problem > that one (only) server (rider) seems to present no data for the whole > domain? Remaining servers correctly respond to any queries. One > curious thing is that I $rndc trace 6; and (I see debug level changed > in journalctl) I do not see anything in the logs when I query. > Zone allows any to query it. > > What dig @rider command returns for SRV queries? From peljasz at yahoo.co.uk Wed Nov 9 13:11:09 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 9 Nov 2016 13:11:09 +0000 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> Message-ID: On 09/11/16 12:43, Martin Basti wrote: > > > On 09.11.2016 12:15, lejeczek wrote: >> >> >> On 08/11/16 19:37, Martin Basti wrote: >>> >>> >>> On 08.11.2016 19:41, lejeczek wrote: >>>> hi everyone >>>> when I look at my domain I see something which seems >>>> inconsistent to me (eg. work5 is not part of the >>>> domain, was --uninstalled) >>>> Do these record need fixing? >>>> I'm asking becuase one of the servers, despite the fact >>>> the ipa dns related toolkit(on that server) shows zone >>>> & records, to dig/host/etc. presents nothing, empty >>>> responses!?? >>>> >>>> $ ipa dnsrecord-find xx.xx.xx.xx.x. >>>> Record name: @ >>>> NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., >>>> dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. >>>> >>>> Record name: _kerberos >>>> TXT record: .xx.xx..xx.xx.x >>>> >>>> Record name: >>>> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs >>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>> >>>> Record name: >>>> _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs >>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>> >>>> Record name: >>>> _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs >>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>> >>>> Record name: _kerberos._tcp.dc._msdcs >>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>> >>>> Record name: _ldap._tcp.dc._msdcs >>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>> >>>> Record name: _kerberos._udp.dc._msdcs >>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>> >>>> Record name: _kerberos._tcp >>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 >>>> rider, 0 100 88 swir >>>> >>>> Record name: _kerberos-master._tcp >>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 >>>> rider, 0 100 88 swir >>>> >>>> Record name: _kpasswd._tcp >>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 >>>> 464 dzien, 0 100 464 whale >>>> >>>> Record name: _ldap._tcp >>>> SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 >>>> 389 whale, 0 100 389 rider >>>> >>>> Record name: _kerberos._udp >>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 >>>> rider, 0 100 88 swir >>>> >>>> Record name: _kerberos-master._udp >>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 >>>> rider, 0 100 88 swir >>>> >>>> Record name: _kpasswd._udp >>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 >>>> 464 dzien, 0 100 464 whale >>>> >>>> Record name: _ntp._udp >>>> SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 >>>> 123 whale, 0 100 123 swir >>>> >>>> thanks. >>>> L. >>>> >>> >>> >>> Hello, >>> >>> if server work5 is uninstalled, then work5 SRV records >>> should be removed. >>> >>> Martin >> >> Martin, would you be able suggest a way to troubleshoot >> that problem that one (only) server (rider) seems to >> present no data for the whole domain? Remaining servers >> correctly respond to any queries. One curious thing is >> that I $rndc trace 6; and (I see debug level changed in >> journalctl) I do not see anything in the logs when I query. >> Zone allows any to query it. >> >> > > What dig @rider command returns for SRV queries? > don't mind SRV records for now, it returns no record at all, it forwards and caches but not for the domain itself. on rider (suffice I point to other member server and records are there) $ dig +qr any .xx.xx..xx.xx.x. @10.5.6.100 ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> +qr any .xx.xx..xx.xx.x. @10.5.6.100 ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36196 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;.xx.xx..xx.xx.x. IN ANY ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36196 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;.xx.xx..xx.xx.x. IN ANY ;; AUTHORITY SECTION: .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. 1478696070 1800 900 604800 3600 ;; Query time: 5 msec ;; SERVER: 10.5.6.100#53(10.5.6.100) ;; WHEN: Wed Nov 09 12:56:16 GMT 2016 ;; MSG SIZE rcvd: 120 I obfuscated FQDNs but it seems like it forwards to a parent domain (to which it's supposed, by dnsforwardzone) And like I mentioned earlier, I do dnszone-find, etc. (on rider) it's all there. From dag at sonsorol.org Wed Nov 9 13:39:52 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 09 Nov 2016 08:39:52 -0500 Subject: [Freeipa-users] guidance and strategies for supporting production use including dev/test IPA systems? Message-ID: <58232728.1010202@sonsorol.org> Thanks to support from folks on this list I have a 3-node multi-site replicating FreeIPA system supporting a number of 1-way trusts to various AD Forests. Testing has gone well and it's clear that this "POC" will soon transition to production. Because of the importance of this system to our environment I'm trying to flesh out a proper strategy for testing upgrades and updates in a way that lets us keep our system highly available and online. And seeing how rapidly this software is being developed w/ new features and how dependent we are on the most recent version (or how badly I want to try the version in RHEL-BETA-3) I think this is a system we will possibly be upgrading somewhat often ... I understand that replicas can run newer versions of IPA/IDM than the master so that is one path by which we can carefully test updates and patches but I don't think that covers all the scenarios ... Can anyone share strategies or war stories for how testing is done in support of production IPA/IDM environments? Especially when Trusts need to be set up with many external AD systems? Do people run discrete standalone dev/test IPA domains/realms to create isolated environments or is there some other good strategy that allows testing to be done within the same domain/realm? Thanks! -Chris From mbasti at redhat.com Wed Nov 9 13:48:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 9 Nov 2016 14:48:07 +0100 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> Message-ID: <7175c75c-9f16-86ae-e1c2-aba6825506b7@redhat.com> On 09.11.2016 14:11, lejeczek wrote: > > > On 09/11/16 12:43, Martin Basti wrote: >> >> >> On 09.11.2016 12:15, lejeczek wrote: >>> >>> >>> On 08/11/16 19:37, Martin Basti wrote: >>>> >>>> >>>> On 08.11.2016 19:41, lejeczek wrote: >>>>> hi everyone >>>>> when I look at my domain I see something which seems inconsistent >>>>> to me (eg. work5 is not part of the domain, was --uninstalled) >>>>> Do these record need fixing? >>>>> I'm asking becuase one of the servers, despite the fact the ipa >>>>> dns related toolkit(on that server) shows zone & records, to >>>>> dig/host/etc. presents nothing, empty responses!?? >>>>> >>>>> $ ipa dnsrecord-find xx.xx.xx.xx.x. >>>>> Record name: @ >>>>> NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., >>>>> dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. >>>>> >>>>> Record name: _kerberos >>>>> TXT record: .xx.xx..xx.xx.x >>>>> >>>>> Record name: >>>>> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>> >>>>> Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>> >>>>> Record name: >>>>> _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs >>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>> >>>>> Record name: _kerberos._tcp.dc._msdcs >>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>> >>>>> Record name: _ldap._tcp.dc._msdcs >>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>> >>>>> Record name: _kerberos._udp.dc._msdcs >>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>> >>>>> Record name: _kerberos._tcp >>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 >>>>> 100 88 swir >>>>> >>>>> Record name: _kerberos-master._tcp >>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 >>>>> 100 88 swir >>>>> >>>>> Record name: _kpasswd._tcp >>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 >>>>> 100 464 whale >>>>> >>>>> Record name: _ldap._tcp >>>>> SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 whale, 0 >>>>> 100 389 rider >>>>> >>>>> Record name: _kerberos._udp >>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 >>>>> 100 88 swir >>>>> >>>>> Record name: _kerberos-master._udp >>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 >>>>> 100 88 swir >>>>> >>>>> Record name: _kpasswd._udp >>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 >>>>> 100 464 whale >>>>> >>>>> Record name: _ntp._udp >>>>> SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 123 whale, 0 >>>>> 100 123 swir >>>>> >>>>> thanks. >>>>> L. >>>>> >>>> >>>> >>>> Hello, >>>> >>>> if server work5 is uninstalled, then work5 SRV records should be >>>> removed. >>>> >>>> Martin >>> >>> Martin, would you be able suggest a way to troubleshoot that problem >>> that one (only) server (rider) seems to present no data for the >>> whole domain? Remaining servers correctly respond to any queries. >>> One curious thing is that I $rndc trace 6; and (I see debug level >>> changed in journalctl) I do not see anything in the logs when I query. >>> Zone allows any to query it. >>> >>> >> >> What dig @rider command returns for SRV queries? >> > don't mind SRV records for now, it returns no record at all, it > forwards and caches but not for the domain itself. > on rider (suffice I point to other member server and records are there) > > $ dig +qr any .xx.xx..xx.xx.x. @10.5.6.100 > > ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> +qr any .xx.xx..xx.xx.x. > @10.5.6.100 > ;; global options: +cmd > ;; Sending: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36196 > ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;.xx.xx..xx.xx.x. IN ANY > > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36196 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;.xx.xx..xx.xx.x. IN ANY > > ;; AUTHORITY SECTION: > .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. > 1478696070 1800 900 604800 3600 > > ;; Query time: 5 msec > ;; SERVER: 10.5.6.100#53(10.5.6.100) > ;; WHEN: Wed Nov 09 12:56:16 GMT 2016 > ;; MSG SIZE rcvd: 120 > > I obfuscated FQDNs but it seems like it forwards to a parent domain > (to which it's supposed, by dnsforwardzone) > And like I mentioned earlier, I do dnszone-find, etc. (on rider) it's > all there. > > > I'm lost now, I don't understand you, you told me that resolving on 'rider' server doesn't work, then you write me that it is expected because you have fowardzone set, but you cannot have forwardzone and master zone for the same domain, IPA doesn't allow it, so I have no idea what is not working for you. (You didn't make it easier by obfuscating output) Martin From lslebodn at redhat.com Wed Nov 9 14:21:04 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 9 Nov 2016 15:21:04 +0100 Subject: [Freeipa-users] system to pick up pa user-mod --uid change - how long? In-Reply-To: <8b9c9b22-112d-bd4e-81b9-3b83bde199b5@pobox.com> References: <438af81b-25be-92e2-d3ac-c9d1d803a826@yahoo.co.uk> <8b9c9b22-112d-bd4e-81b9-3b83bde199b5@pobox.com> Message-ID: <20161109142104.GF19424@10.4.128.1> On (08/11/16 15:09), Brian Candler wrote: >On 08/11/2016 13:57, lejeczek wrote: >> I've changed an uid of a.user but system: $ id a.user - still shows old >> id. >> When is the system supposed to notice that change? > >You might want to force the cache to expire early. Try: > > sss_cache -U > >or > > sss_cache -u > >(I'm afraid I don't know what the automatic expiry time is) > In worst case, it would be a 1.5 hour by default. That's the reason why there is an utility sss_cache LS From peljasz at yahoo.co.uk Wed Nov 9 14:33:13 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 9 Nov 2016 14:33:13 +0000 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <7175c75c-9f16-86ae-e1c2-aba6825506b7@redhat.com> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> <7175c75c-9f16-86ae-e1c2-aba6825506b7@redhat.com> Message-ID: <93c10ec6-08d5-e943-6e09-fa2b1defccc3@yahoo.co.uk> On 09/11/16 13:48, Martin Basti wrote: > > > On 09.11.2016 14:11, lejeczek wrote: >> >> >> On 09/11/16 12:43, Martin Basti wrote: >>> >>> >>> On 09.11.2016 12:15, lejeczek wrote: >>>> >>>> >>>> On 08/11/16 19:37, Martin Basti wrote: >>>>> >>>>> >>>>> On 08.11.2016 19:41, lejeczek wrote: >>>>>> hi everyone >>>>>> when I look at my domain I see something which seems >>>>>> inconsistent to me (eg. work5 is not part of the >>>>>> domain, was --uninstalled) >>>>>> Do these record need fixing? >>>>>> I'm asking becuase one of the servers, despite the >>>>>> fact the ipa dns related toolkit(on that server) >>>>>> shows zone & records, to dig/host/etc. presents >>>>>> nothing, empty responses!?? >>>>>> >>>>>> $ ipa dnsrecord-find xx.xx.xx.xx.x. >>>>>> Record name: @ >>>>>> NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., >>>>>> dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. >>>>>> >>>>>> Record name: _kerberos >>>>>> TXT record: .xx.xx..xx.xx.x >>>>>> >>>>>> Record name: >>>>>> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>> >>>>>> Record name: >>>>>> _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>> >>>>>> Record name: >>>>>> _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs >>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>> >>>>>> Record name: _kerberos._tcp.dc._msdcs >>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>> >>>>>> Record name: _ldap._tcp.dc._msdcs >>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>> >>>>>> Record name: _kerberos._udp.dc._msdcs >>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>> >>>>>> Record name: _kerberos._tcp >>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 >>>>>> 88 rider, 0 100 88 swir >>>>>> >>>>>> Record name: _kerberos-master._tcp >>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 >>>>>> 88 rider, 0 100 88 swir >>>>>> >>>>>> Record name: _kpasswd._tcp >>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 >>>>>> 464 dzien, 0 100 464 whale >>>>>> >>>>>> Record name: _ldap._tcp >>>>>> SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 >>>>>> 389 whale, 0 100 389 rider >>>>>> >>>>>> Record name: _kerberos._udp >>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 >>>>>> 88 rider, 0 100 88 swir >>>>>> >>>>>> Record name: _kerberos-master._udp >>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 >>>>>> 88 rider, 0 100 88 swir >>>>>> >>>>>> Record name: _kpasswd._udp >>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 >>>>>> 464 dzien, 0 100 464 whale >>>>>> >>>>>> Record name: _ntp._udp >>>>>> SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 >>>>>> 123 whale, 0 100 123 swir >>>>>> >>>>>> thanks. >>>>>> L. >>>>>> >>>>> >>>>> >>>>> Hello, >>>>> >>>>> if server work5 is uninstalled, then work5 SRV records >>>>> should be removed. >>>>> >>>>> Martin >>>> >>>> Martin, would you be able suggest a way to troubleshoot >>>> that problem that one (only) server (rider) seems to >>>> present no data for the whole domain? Remaining servers >>>> correctly respond to any queries. One curious thing is >>>> that I $rndc trace 6; and (I see debug level changed in >>>> journalctl) I do not see anything in the logs when I >>>> query. >>>> Zone allows any to query it. >>>> >>>> >>> >>> What dig @rider command returns for SRV queries? >>> >> don't mind SRV records for now, it returns no record at >> all, it forwards and caches but not for the domain itself. >> on rider (suffice I point to other member server and >> records are there) >> >> $ dig +qr any .xx.xx..xx.xx.x. @10.5.6.100 >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> +qr any >> .xx.xx..xx.xx.x. @10.5.6.100 >> ;; global options: +cmd >> ;; Sending: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36196 >> ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, >> ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;.xx.xx..xx.xx.x. IN ANY >> >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36196 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, >> ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;.xx.xx..xx.xx.x. IN ANY >> >> ;; AUTHORITY SECTION: >> .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. >> hostmaster.xx.xx.x. 1478696070 1800 900 604800 3600 >> >> ;; Query time: 5 msec >> ;; SERVER: 10.5.6.100#53(10.5.6.100) >> ;; WHEN: Wed Nov 09 12:56:16 GMT 2016 >> ;; MSG SIZE rcvd: 120 >> >> I obfuscated FQDNs but it seems like it forwards to a >> parent domain (to which it's supposed, by dnsforwardzone) >> And like I mentioned earlier, I do dnszone-find, etc. (on >> rider) it's all there. >> >> >> > > I'm lost now, I don't understand you, you told me that > resolving on 'rider' server doesn't work, then you write > me that it is expected because you have fowardzone set, > but you cannot have forwardzone and master zone for the > same domain, IPA doesn't allow it, so I have no idea what > is not working for you. (You didn't make it easier by > obfuscating output) > > Martin no no, sorry, I mean - it forwards whereas is should be authoritative for it's own FQDN. I realize it is not obvious after I obfuscated the output, but here: ;; AUTHORITY SECTION: .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. 1478696070 1800 900 604800 3600 this looks like the only domain with is dnsforwardzone, everything else is dnszone parent.xx.xx. - is the only forward private.my.parent.xx.xx - it is IPA domain & dnszone I query private.my.parent.xx.xx and I get response as above. From mbasti at redhat.com Wed Nov 9 14:35:26 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 9 Nov 2016 15:35:26 +0100 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <93c10ec6-08d5-e943-6e09-fa2b1defccc3@yahoo.co.uk> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> <7175c75c-9f16-86ae-e1c2-aba6825506b7@redhat.com> <93c10ec6-08d5-e943-6e09-fa2b1defccc3@yahoo.co.uk> Message-ID: <00de4a04-a55b-1154-8ae7-1e92fc90986a@redhat.com> On 09.11.2016 15:33, lejeczek wrote: > > > On 09/11/16 13:48, Martin Basti wrote: >> >> >> On 09.11.2016 14:11, lejeczek wrote: >>> >>> >>> On 09/11/16 12:43, Martin Basti wrote: >>>> >>>> >>>> On 09.11.2016 12:15, lejeczek wrote: >>>>> >>>>> >>>>> On 08/11/16 19:37, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08.11.2016 19:41, lejeczek wrote: >>>>>>> hi everyone >>>>>>> when I look at my domain I see something which seems >>>>>>> inconsistent to me (eg. work5 is not part of the domain, was >>>>>>> --uninstalled) >>>>>>> Do these record need fixing? >>>>>>> I'm asking becuase one of the servers, despite the fact the ipa >>>>>>> dns related toolkit(on that server) shows zone & records, to >>>>>>> dig/host/etc. presents nothing, empty responses!?? >>>>>>> >>>>>>> $ ipa dnsrecord-find xx.xx.xx.xx.x. >>>>>>> Record name: @ >>>>>>> NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., >>>>>>> dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. >>>>>>> >>>>>>> Record name: _kerberos >>>>>>> TXT record: .xx.xx..xx.xx.x >>>>>>> >>>>>>> Record name: >>>>>>> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>> >>>>>>> Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>>> >>>>>>> Record name: >>>>>>> _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs >>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>> >>>>>>> Record name: _kerberos._tcp.dc._msdcs >>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>> >>>>>>> Record name: _ldap._tcp.dc._msdcs >>>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>>> >>>>>>> Record name: _kerberos._udp.dc._msdcs >>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>> >>>>>>> Record name: _kerberos._tcp >>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 >>>>>>> 100 88 swir >>>>>>> >>>>>>> Record name: _kerberos-master._tcp >>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 >>>>>>> 100 88 swir >>>>>>> >>>>>>> Record name: _kpasswd._tcp >>>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, >>>>>>> 0 100 464 whale >>>>>>> >>>>>>> Record name: _ldap._tcp >>>>>>> SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 whale, >>>>>>> 0 100 389 rider >>>>>>> >>>>>>> Record name: _kerberos._udp >>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 >>>>>>> 100 88 swir >>>>>>> >>>>>>> Record name: _kerberos-master._udp >>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 >>>>>>> 100 88 swir >>>>>>> >>>>>>> Record name: _kpasswd._udp >>>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, >>>>>>> 0 100 464 whale >>>>>>> >>>>>>> Record name: _ntp._udp >>>>>>> SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 123 whale, >>>>>>> 0 100 123 swir >>>>>>> >>>>>>> thanks. >>>>>>> L. >>>>>>> >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> if server work5 is uninstalled, then work5 SRV records should be >>>>>> removed. >>>>>> >>>>>> Martin >>>>> >>>>> Martin, would you be able suggest a way to troubleshoot that >>>>> problem that one (only) server (rider) seems to present no data >>>>> for the whole domain? Remaining servers correctly respond to any >>>>> queries. One curious thing is that I $rndc trace 6; and (I see >>>>> debug level changed in journalctl) I do not see anything in the >>>>> logs when I query. >>>>> Zone allows any to query it. >>>>> >>>>> >>>> >>>> What dig @rider command returns for SRV queries? >>>> >>> don't mind SRV records for now, it returns no record at all, it >>> forwards and caches but not for the domain itself. >>> on rider (suffice I point to other member server and records are there) >>> >>> $ dig +qr any .xx.xx..xx.xx.x. @10.5.6.100 >>> >>> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> +qr any >>> .xx.xx..xx.xx.x. @10.5.6.100 >>> ;; global options: +cmd >>> ;; Sending: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36196 >>> ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;.xx.xx..xx.xx.x. IN ANY >>> >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36196 >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;.xx.xx..xx.xx.x. IN ANY >>> >>> ;; AUTHORITY SECTION: >>> .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. >>> 1478696070 1800 900 604800 3600 >>> >>> ;; Query time: 5 msec >>> ;; SERVER: 10.5.6.100#53(10.5.6.100) >>> ;; WHEN: Wed Nov 09 12:56:16 GMT 2016 >>> ;; MSG SIZE rcvd: 120 >>> >>> I obfuscated FQDNs but it seems like it forwards to a parent domain >>> (to which it's supposed, by dnsforwardzone) >>> And like I mentioned earlier, I do dnszone-find, etc. (on rider) >>> it's all there. >>> >>> >>> >> >> I'm lost now, I don't understand you, you told me that resolving on >> 'rider' server doesn't work, then you write me that it is expected >> because you have fowardzone set, but you cannot have forwardzone and >> master zone for the same domain, IPA doesn't allow it, so I have no >> idea what is not working for you. (You didn't make it easier by >> obfuscating output) >> >> Martin > > no no, sorry, I mean - it forwards whereas is should be authoritative > for it's own FQDN. > I realize it is not obvious after I obfuscated the output, but here: > > ;; AUTHORITY SECTION: > .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. > 1478696070 1800 900 604800 3600 > > this looks like the only domain with is dnsforwardzone, everything > else is dnszone > > parent.xx.xx. - is the only forward > private.my.parent.xx.xx - it is IPA domain & dnszone > > I query private.my.parent.xx.xx and I get response as above. Do you have proper zone delegation from parent zone? NS and A glue records? How your named.conf looks? Martin From askstack at yahoo.com Wed Nov 9 15:49:09 2016 From: askstack at yahoo.com (Ask Stack) Date: Wed, 9 Nov 2016 15:49:09 +0000 (UTC) Subject: [Freeipa-users] What is the use of /etc/krb5.conf? In-Reply-To: <07467670-4693-1441-48c4-ba302c02a80c@redhat.com> References: <1065494049.632733.1478621585379.ref@mail.yahoo.com> <1065494049.632733.1478621585379@mail.yahoo.com> <07467670-4693-1441-48c4-ba302c02a80c@redhat.com> Message-ID: <1670350630.468878.1478706549993@mail.yahoo.com> Thanks Martin, and I always forget I can man a conf file. On Tuesday, November 8, 2016 12:09 PM, Martin Babinsky wrote: On 11/08/2016 05:13 PM, Ask Stack wrote: > I thought /etc/krb5.conf controls which kerberos server the clients talk > to. > > As a test, I removed /etc/krb5.conf and rebooted the client. After > reboot, I can still log in and "kinit user" . > Removing /etc/krb5.keytab, however would stop user from logging in and > sssd to start. > > > /etc/krb5.conf configures Kerberos client library: it instructs the client about which realm it should use, whether to use dns discovery or use static list of KDC and mapping between DNS domains and realms. Read `man krb5.conf' for more info. sssd stores plenty of information about Kerberos realm in its own configuration (realm, DNS discovery etc.) so it can authenticate the user even without valid krb5.conf (as you observed). However, to pull in user info from authoritative source (IPA LDAP), sssd authenticates against IPA as the host principal using /etc/krb5.keytab, that's why it stopped working and refused to start after you removed it. -- Martin^3 Babinsky -- 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 peljasz at yahoo.co.uk Wed Nov 9 15:57:15 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 9 Nov 2016 15:57:15 +0000 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <00de4a04-a55b-1154-8ae7-1e92fc90986a@redhat.com> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> <7175c75c-9f16-86ae-e1c2-aba6825506b7@redhat.com> <93c10ec6-08d5-e943-6e09-fa2b1defccc3@yahoo.co.uk> <00de4a04-a55b-1154-8ae7-1e92fc90986a@redhat.com> Message-ID: <822f5ce5-524c-49f4-5eda-4a65a17f4a75@yahoo.co.uk> On 09/11/16 14:35, Martin Basti wrote: > > > On 09.11.2016 15:33, lejeczek wrote: >> >> >> On 09/11/16 13:48, Martin Basti wrote: >>> >>> >>> On 09.11.2016 14:11, lejeczek wrote: >>>> >>>> >>>> On 09/11/16 12:43, Martin Basti wrote: >>>>> >>>>> >>>>> On 09.11.2016 12:15, lejeczek wrote: >>>>>> >>>>>> >>>>>> On 08/11/16 19:37, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08.11.2016 19:41, lejeczek wrote: >>>>>>>> hi everyone >>>>>>>> when I look at my domain I see something which >>>>>>>> seems inconsistent to me (eg. work5 is not part of >>>>>>>> the domain, was --uninstalled) >>>>>>>> Do these record need fixing? >>>>>>>> I'm asking becuase one of the servers, despite the >>>>>>>> fact the ipa dns related toolkit(on that server) >>>>>>>> shows zone & records, to dig/host/etc. presents >>>>>>>> nothing, empty responses!?? >>>>>>>> >>>>>>>> $ ipa dnsrecord-find xx.xx.xx.xx.x. >>>>>>>> Record name: @ >>>>>>>> NS record: swir.xx.xx.xx.xx.x., >>>>>>>> rider.xx.xx.xx.xx.x., >>>>>>>> dzien.xx.xx.xx.xx.x., >>>>>>>> whale.xx.xx.xx.xx.x. >>>>>>>> >>>>>>>> Record name: _kerberos >>>>>>>> TXT record: .xx.xx..xx.xx.x >>>>>>>> >>>>>>>> Record name: >>>>>>>> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>> >>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>> >>>>>>>> Record name: >>>>>>>> _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>>>> >>>>>>>> Record name: >>>>>>>> _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>> >>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>> >>>>>>>> Record name: _kerberos._tcp.dc._msdcs >>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>> >>>>>>>> Record name: _ldap._tcp.dc._msdcs >>>>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>>>> >>>>>>>> Record name: _kerberos._udp.dc._msdcs >>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>> >>>>>>>> Record name: _kerberos._tcp >>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 >>>>>>>> 88 rider, 0 100 88 swir >>>>>>>> >>>>>>>> Record name: _kerberos-master._tcp >>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 >>>>>>>> 88 rider, 0 100 88 swir >>>>>>>> >>>>>>>> Record name: _kpasswd._tcp >>>>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 >>>>>>>> 100 464 dzien, 0 100 464 whale >>>>>>>> >>>>>>>> Record name: _ldap._tcp >>>>>>>> SRV record: 0 100 389 swir, 0 100 389 dzien, 0 >>>>>>>> 100 389 whale, 0 100 389 rider >>>>>>>> >>>>>>>> Record name: _kerberos._udp >>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 >>>>>>>> 88 rider, 0 100 88 swir >>>>>>>> >>>>>>>> Record name: _kerberos-master._udp >>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 >>>>>>>> 88 rider, 0 100 88 swir >>>>>>>> >>>>>>>> Record name: _kpasswd._udp >>>>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 >>>>>>>> 100 464 dzien, 0 100 464 whale >>>>>>>> >>>>>>>> Record name: _ntp._udp >>>>>>>> SRV record: 0 100 123 dzien, 0 100 123 rider, 0 >>>>>>>> 100 123 whale, 0 100 123 swir >>>>>>>> >>>>>>>> thanks. >>>>>>>> L. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> if server work5 is uninstalled, then work5 SRV >>>>>>> records should be removed. >>>>>>> >>>>>>> Martin >>>>>> >>>>>> Martin, would you be able suggest a way to >>>>>> troubleshoot that problem that one (only) server >>>>>> (rider) seems to present no data for the whole >>>>>> domain? Remaining servers correctly respond to any >>>>>> queries. One curious thing is that I $rndc trace 6; >>>>>> and (I see debug level changed in journalctl) I do >>>>>> not see anything in the logs when I query. >>>>>> Zone allows any to query it. >>>>>> >>>>>> >>>>> >>>>> What dig @rider command returns for SRV queries? >>>>> >>>> don't mind SRV records for now, it returns no record at >>>> all, it forwards and caches but not for the domain itself. >>>> on rider (suffice I point to other member server and >>>> records are there) >>>> >>>> $ dig +qr any .xx.xx..xx.xx.x. @10.5.6.100 >>>> >>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> +qr any >>>> .xx.xx..xx.xx.x. @10.5.6.100 >>>> ;; global options: +cmd >>>> ;; Sending: >>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36196 >>>> ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, >>>> ADDITIONAL: 1 >>>> >>>> ;; OPT PSEUDOSECTION: >>>> ; EDNS: version: 0, flags:; udp: 4096 >>>> ;; QUESTION SECTION: >>>> ;.xx.xx..xx.xx.x. IN ANY >>>> >>>> ;; Got answer: >>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36196 >>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, >>>> ADDITIONAL: 1 >>>> >>>> ;; OPT PSEUDOSECTION: >>>> ; EDNS: version: 0, flags:; udp: 4096 >>>> ;; QUESTION SECTION: >>>> ;.xx.xx..xx.xx.x. IN ANY >>>> >>>> ;; AUTHORITY SECTION: >>>> .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. >>>> hostmaster.xx.xx.x. 1478696070 1800 900 604800 3600 >>>> >>>> ;; Query time: 5 msec >>>> ;; SERVER: 10.5.6.100#53(10.5.6.100) >>>> ;; WHEN: Wed Nov 09 12:56:16 GMT 2016 >>>> ;; MSG SIZE rcvd: 120 >>>> >>>> I obfuscated FQDNs but it seems like it forwards to a >>>> parent domain (to which it's supposed, by dnsforwardzone) >>>> And like I mentioned earlier, I do dnszone-find, etc. >>>> (on rider) it's all there. >>>> >>>> >>>> >>> >>> I'm lost now, I don't understand you, you told me that >>> resolving on 'rider' server doesn't work, then you write >>> me that it is expected because you have fowardzone set, >>> but you cannot have forwardzone and master zone for the >>> same domain, IPA doesn't allow it, so I have no idea >>> what is not working for you. (You didn't make it easier >>> by obfuscating output) >>> >>> Martin >> >> no no, sorry, I mean - it forwards whereas is should be >> authoritative for it's own FQDN. >> I realize it is not obvious after I obfuscated the >> output, but here: >> >> ;; AUTHORITY SECTION: >> .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. >> hostmaster.xx.xx.x. 1478696070 1800 900 604800 3600 >> >> this looks like the only domain with is dnsforwardzone, >> everything else is dnszone >> >> parent.xx.xx. - is the only forward >> private.my.parent.xx.xx - it is IPA domain & dnszone >> >> I query private.my.parent.xx.xx and I get response as above. > > Do you have proper zone delegation from parent zone? NS > and A glue records? no, I don't have any dealings with "parent" domain, I forward to there so only those queries could go directly to NSes instead of to ROOTs. I do not really on that "parent" - I call it parent for only "logistically/visually" it appears as parent. > > How your named.conf looks? Exactly the same as on the other three servers(IPA generated), I diffed it, only these are (respectively) different: fake_mname, sasl_user I think that one server simply forwards (to that dnsforwardzone) as if it had not any own zones, but why?? Would it be in the LDAP? > > Martin From julliot at ljll.math.upmc.fr Wed Nov 9 16:12:48 2016 From: julliot at ljll.math.upmc.fr (=?UTF-8?Q?S=c3=a9bastien_Julliot?=) Date: Wed, 9 Nov 2016 17:12:48 +0100 Subject: [Freeipa-users] Setting "preserve" as default action when deleting in webUI In-Reply-To: <55650f44-97f4-b3e0-9907-7521a2f886ca@redhat.com> References: <5f607850-9623-254e-1609-02fd922117c0@ljll.math.upmc.fr> <4b88fa7e-4df2-ba82-0591-94f8ac37ac59@redhat.com> <55650f44-97f4-b3e0-9907-7521a2f886ca@redhat.com> Message-ID: <173ca750-3c99-0d7b-b23b-dc7f402596bc@ljll.math.upmc.fr> Hello Pavel, Yes I did. "PRESERVE.JS WAS EXECUTED" is printed in my browser's console, and yet "delete" ("supprimer", in French) is still the default. (as you can see in linked image) Le 31/10/2016 ? 16:18, Pavel Vomacka a ?crit : > Hello Sebastien, > > I tried your plugin and it works correctly. Default value is Preserve > with your plugin. Did you copy your plugin into > /var/share/ipa/ui/js/plugins/plugin_name/plugin_name.js ? That should > be enough. > > > On 10/28/2016 12:14 AM, Sebastien Julliot wrote: >> Hello guys, >> >> >> Thank you for your answers. First, I was able to modify the minified js >> to change the default. Ugly solution, but it works for now. >> >> I am trying to write a plugin but it seems that I missed something here >> since, despite being executed, the default is not changed .. >> >> Here is my code, freely inspired of what I think I understood of your >> 'association_search_fix.js' example: >> >> define([ >> >> 'freeipa/ipa', >> >> 'freeipa/user', >> >> ], >> >> function(IPA, user) { >> >> exp = {}; >> >> >> exp.orig_create_active_user_del_dialog = >> IPA.user.create_active_user_del_dialog; >> >> IPA.user.create_active_user_del_dialog = function(dialog) { >> >> dialog.deleter_dialog_create_content(); >> >> dialog.option_layout = IPA.fluid_layout({ >> >> label_cls: 'col-sm-3', >> >> widget_cls: 'col-sm-9' >> >> }); >> >> dialog.option_radio = IPA.radio_widget({ >> >> name: 'preserve', >> >> label: '@i18n:objects.user.delete_mode', >> >> options: [ >> >> { label: '@i18n:objects.user.mode_delete', value: >> 'false' }, >> >> { label: '@i18n:objects.user.mode_preserve', value: >> 'true' } >> >> ], >> >> default_value: 'true' >> >> }); >> >> var html = dialog.option_layout.create([dialog.option_radio]); >> >> dialog.container.append(html); >> >> dialog.option_radio.set_value(['']); >> >> return dialog; >> >> }; >> >> //exp.orig_create_active_user_del_dialog = >> IPA.user.create_active_user_del_dialog; >> >> console.log('PRESERVE.JS WAS EXECUTED'); >> >> return exp; >> >> }); >> >> I checked that disabling the comment or not does not change anything. >> >> >> Can you see what I missed here ? >> >> >> Thanks a lot, >> >> Sebastien Julliot. >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture du 2016-11-09 17-10-14.png Type: image/png Size: 86252 bytes Desc: not available URL: From raul at dias.com.br Wed Nov 9 18:28:48 2016 From: raul at dias.com.br (Raul Dias) Date: Wed, 9 Nov 2016 16:28:48 -0200 Subject: [Freeipa-users] FreeIPA + DHCP-LDAP - Fedora 24 - broken In-Reply-To: <3f15e65f-26f1-e9a6-0e98-83b1ca346d0f@dias.com.br> References: <3f15e65f-26f1-e9a6-0e98-83b1ca346d0f@dias.com.br> Message-ID: > Do you mean that dhcpd on Ubuntu is configured against the very same FreeIPA > server? yes. Testing both on VMs with a private network. > Are you sure that dhcpd is using the same credentials to BIND to LDAP? There > might be an access control issue if different hosts use different credentials > or so. It would help if you described how you bound to LDAP using ldapsearch. Yes. To make sure, I using the ipa admin credentials. On both hosts I can do a $ ldapsearch -x and retrieve the ldif info. running on both: $ strace -e trace=network dhcpd -d I get this line on the Ubuntu host: socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 5 setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0 connect(5, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("192.168.1.138")}, 16) = 0 On the Fedora host (FreeIPA server), there is no try to connect to. I thought that it might be trying to use a socket, but still no try even with an outside IP as host. There is one difference between Fedora and Ubuntu dhcpds. On Ubuntu, there is a separated ldap package to dhcp-server (isc-dhcp-server-ldap). On Fedora it is supposedly merged on the same binary on dhcp-server (dhcp-server-4.3.4-3.fc24.x86_64). That's why it would be a good start for me to know that someone else uses dhcpd with ldap on Fedora. -rsd From bpk678 at gmail.com Thu Nov 10 00:14:35 2016 From: bpk678 at gmail.com (Brendan Kearney) Date: Wed, 9 Nov 2016 19:14:35 -0500 Subject: [Freeipa-users] bind-dyndb-ldap and replication requirements Message-ID: i am asking this for a friend who is trying to figure out how to get bind-dyndb-ldap working against openldap on ubuntu. she does not have replication between two or more ldap instances, and needs to figure out the minimum requirements for bind-dyndb-ldap. i have been trying to help her, but i am unsure about what is needed, as i have n-way multi master replication working already. can anyone provide what the replication requirements are for bind-dyndb-ldap? currently, the SyncRepl module is loaded and the overlay is created and configured for the mdb. i have tried to help get olcServerID and olcMirrorMode set in cn=config and olcDatabase={2}mdb,cn=config respectively, but some errors were encountered there. is there a best practices doc that we can review? the environment, as best i can tell is ubuntu, openldap 2.4.42 and bind 9. exact os and bind versions are not known right now. thanks, brendan kearney From dkupka at redhat.com Thu Nov 10 05:43:07 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 10 Nov 2016 06:43:07 +0100 Subject: [Freeipa-users] bind-dyndb-ldap and replication requirements In-Reply-To: References: Message-ID: <7b3e060f-b485-bd1d-6704-af1b41e34769@redhat.com> On 10/11/16 01:14, Brendan Kearney wrote: > i am asking this for a friend who is trying to figure out how to get > bind-dyndb-ldap working against openldap on ubuntu. she does not have > replication between two or more ldap instances, and needs to figure out > the minimum requirements for bind-dyndb-ldap. i have been trying to > help her, but i am unsure about what is needed, as i have n-way multi > master replication working already. > > can anyone provide what the replication requirements are for > bind-dyndb-ldap? currently, the SyncRepl module is loaded and the > overlay is created and configured for the mdb. i have tried to help get > olcServerID and olcMirrorMode set in cn=config and > olcDatabase={2}mdb,cn=config respectively, but some errors were > encountered there. is there a best practices doc that we can review? > > the environment, as best i can tell is ubuntu, openldap 2.4.42 and bind > 9. exact os and bind versions are not known right now. > > thanks, > > brendan kearney > Hello Brendan, I don't have any experience with running OpenLDAP + bind-dyndb-ldap but quick web search showed me this: https://blogs.mindspew-age.com/2013/06/07/bind-dns-openldap-mdb-dynamic-domainsub-domain-configuration-of-dns/ The article is about CentOS 6 and more than 3 years old but still might be helpful because it's mainly about Bind 9 configuration. -- David Kupka From matrix.zj at qq.com Thu Nov 10 06:11:54 2016 From: matrix.zj at qq.com (=?ISO-8859-1?B?TWF0cml4?=) Date: Thu, 10 Nov 2016 14:11:54 +0800 Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed (-2)[Local error]' Message-ID: Hi, I have installed sssd in a RHEL5 client. ipa-client/sssd version: ipa-client-2.1.3-7.el5 sssd-client-1.5.1-71.el5 sssd-1.5.1-71.el5 sssd failed to get ipa user info with 'ldap_sasl_bind failed (-2)[Local error]'. (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/client02.stg.example.net (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (1): ldap_sasl_bind failed (-2)[Local error] (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (7): Waiting for child [11117]. (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (4): child [11117] finished successfully. I have tried to google to find root cause. some link explained it should be something wrong with dns. I have double confirmed it. # nslookup client02.stg.example.net Server: 10.2.1.21 Address: 10.2.1.21#53 Name: client02.stg.example.net Address: 10.2.3.32 # nslookup 10.2.3.32 Server: 10.2.1.21 Address: 10.2.1.21#53 32.3.2.10.in-addr.arpa name = client02.stg.example.net. # nslookup ipaslave.stg.example.net Server: 10.2.1.21 Address: 10.2.1.21#53 Name: ipaslave.stg.example.net Address: 10.2.1.250 # nslookup 10.2.1.250 Server: 10.2.1.21 Address: 10.2.1.21#53 250.1.2.10.in-addr.arpa name = ipaslave.stg.example.net. Any hints or troubleshooting ideas would be appreciated. Matrix -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Nov 10 06:51:31 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 10 Nov 2016 07:51:31 +0100 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <822f5ce5-524c-49f4-5eda-4a65a17f4a75@yahoo.co.uk> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> <7175c75c-9f16-86ae-e1c2-aba6825506b7@redhat.com> <93c10ec6-08d5-e943-6e09-fa2b1defccc3@yahoo.co.uk> <00de4a04-a55b-1154-8ae7-1e92fc90986a@redhat.com> <822f5ce5-524c-49f4-5eda-4a65a17f4a75@yahoo.co.uk> Message-ID: <7be13418-72c1-8ceb-be00-244f9c241913@redhat.com> On 9.11.2016 16:57, lejeczek wrote: > > > On 09/11/16 14:35, Martin Basti wrote: >> >> >> On 09.11.2016 15:33, lejeczek wrote: >>> >>> >>> On 09/11/16 13:48, Martin Basti wrote: >>>> >>>> >>>> On 09.11.2016 14:11, lejeczek wrote: >>>>> >>>>> >>>>> On 09/11/16 12:43, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 09.11.2016 12:15, lejeczek wrote: >>>>>>> >>>>>>> >>>>>>> On 08/11/16 19:37, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08.11.2016 19:41, lejeczek wrote: >>>>>>>>> hi everyone >>>>>>>>> when I look at my domain I see something which seems inconsistent to >>>>>>>>> me (eg. work5 is not part of the domain, was --uninstalled) >>>>>>>>> Do these record need fixing? >>>>>>>>> I'm asking becuase one of the servers, despite the fact the ipa dns >>>>>>>>> related toolkit(on that server) shows zone & records, to >>>>>>>>> dig/host/etc. presents nothing, empty responses!?? >>>>>>>>> >>>>>>>>> $ ipa dnsrecord-find xx.xx.xx.xx.x. >>>>>>>>> Record name: @ >>>>>>>>> NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., >>>>>>>>> dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. >>>>>>>>> >>>>>>>>> Record name: _kerberos >>>>>>>>> TXT record: .xx.xx..xx.xx.x >>>>>>>>> >>>>>>>>> Record name: _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>> >>>>>>>>> Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>>>>> >>>>>>>>> Record name: _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>> >>>>>>>>> Record name: _kerberos._tcp.dc._msdcs >>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>> >>>>>>>>> Record name: _ldap._tcp.dc._msdcs >>>>>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>>>>> >>>>>>>>> Record name: _kerberos._udp.dc._msdcs >>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>> >>>>>>>>> Record name: _kerberos._tcp >>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>> 88 swir >>>>>>>>> >>>>>>>>> Record name: _kerberos-master._tcp >>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>> 88 swir >>>>>>>>> >>>>>>>>> Record name: _kpasswd._tcp >>>>>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100 >>>>>>>>> 464 whale >>>>>>>>> >>>>>>>>> Record name: _ldap._tcp >>>>>>>>> SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 whale, 0 100 >>>>>>>>> 389 rider >>>>>>>>> >>>>>>>>> Record name: _kerberos._udp >>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>> 88 swir >>>>>>>>> >>>>>>>>> Record name: _kerberos-master._udp >>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>> 88 swir >>>>>>>>> >>>>>>>>> Record name: _kpasswd._udp >>>>>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100 >>>>>>>>> 464 whale >>>>>>>>> >>>>>>>>> Record name: _ntp._udp >>>>>>>>> SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 123 whale, 0 >>>>>>>>> 100 123 swir >>>>>>>>> >>>>>>>>> thanks. >>>>>>>>> L. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> if server work5 is uninstalled, then work5 SRV records should be removed. >>>>>>>> >>>>>>>> Martin >>>>>>> >>>>>>> Martin, would you be able suggest a way to troubleshoot that problem >>>>>>> that one (only) server (rider) seems to present no data for the whole >>>>>>> domain? Remaining servers correctly respond to any queries. One curious >>>>>>> thing is that I $rndc trace 6; and (I see debug level changed in >>>>>>> journalctl) I do not see anything in the logs when I query. >>>>>>> Zone allows any to query it. >>>>>>> >>>>>>> >>>>>> >>>>>> What dig @rider command returns for SRV queries? >>>>>> >>>>> don't mind SRV records for now, it returns no record at all, it forwards >>>>> and caches but not for the domain itself. >>>>> on rider (suffice I point to other member server and records are there) >>>>> >>>>> $ dig +qr any .xx.xx..xx.xx.x. @10.5.6.100 >>>>> >>>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> +qr any .xx.xx..xx.xx.x. >>>>> @10.5.6.100 >>>>> ;; global options: +cmd >>>>> ;; Sending: >>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36196 >>>>> ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >>>>> >>>>> ;; OPT PSEUDOSECTION: >>>>> ; EDNS: version: 0, flags:; udp: 4096 >>>>> ;; QUESTION SECTION: >>>>> ;.xx.xx..xx.xx.x. IN ANY >>>>> >>>>> ;; Got answer: >>>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36196 >>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >>>>> >>>>> ;; OPT PSEUDOSECTION: >>>>> ; EDNS: version: 0, flags:; udp: 4096 >>>>> ;; QUESTION SECTION: >>>>> ;.xx.xx..xx.xx.x. IN ANY >>>>> >>>>> ;; AUTHORITY SECTION: >>>>> .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. >>>>> 1478696070 1800 900 604800 3600 >>>>> >>>>> ;; Query time: 5 msec >>>>> ;; SERVER: 10.5.6.100#53(10.5.6.100) >>>>> ;; WHEN: Wed Nov 09 12:56:16 GMT 2016 >>>>> ;; MSG SIZE rcvd: 120 >>>>> >>>>> I obfuscated FQDNs but it seems like it forwards to a parent domain (to >>>>> which it's supposed, by dnsforwardzone) >>>>> And like I mentioned earlier, I do dnszone-find, etc. (on rider) it's all >>>>> there. >>>>> >>>>> >>>>> >>>> >>>> I'm lost now, I don't understand you, you told me that resolving on >>>> 'rider' server doesn't work, then you write me that it is expected because >>>> you have fowardzone set, but you cannot have forwardzone and master zone >>>> for the same domain, IPA doesn't allow it, so I have no idea what is not >>>> working for you. (You didn't make it easier by obfuscating output) >>>> >>>> Martin >>> >>> no no, sorry, I mean - it forwards whereas is should be authoritative for >>> it's own FQDN. >>> I realize it is not obvious after I obfuscated the output, but here: >>> >>> ;; AUTHORITY SECTION: >>> .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. 1478696070 >>> 1800 900 604800 3600 >>> >>> this looks like the only domain with is dnsforwardzone, everything else is >>> dnszone >>> >>> parent.xx.xx. - is the only forward >>> private.my.parent.xx.xx - it is IPA domain & dnszone >>> >>> I query private.my.parent.xx.xx and I get response as above. >> >> Do you have proper zone delegation from parent zone? NS and A glue records? > > no, I don't have any dealings with "parent" domain, I forward to there so only > those queries could go directly to NSes instead of to ROOTs. > I do not really on that "parent" - I call it parent for only > "logistically/visually" it appears as parent. >> >> How your named.conf looks? > > Exactly the same as on the other three servers(IPA generated), I diffed it, > only these are (respectively) different: fake_mname, sasl_user > I think that one server simply forwards (to that dnsforwardzone) as if it had > not any own zones, but why?? Would it be in the LDAP? Do you have 'forwarders' statement in your named.conf? If you have it, we might see a situation where LDAP plugin does not load/connect to LDAP for whatever reason and only the global forwarding works. Alternatively it might be a problem described in https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5.NozonesfromLDAPareloaded -- Petr^2 Spacek From pspacek at redhat.com Thu Nov 10 06:59:02 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 10 Nov 2016 07:59:02 +0100 Subject: [Freeipa-users] bind-dyndb-ldap and replication requirements In-Reply-To: <7b3e060f-b485-bd1d-6704-af1b41e34769@redhat.com> References: <7b3e060f-b485-bd1d-6704-af1b41e34769@redhat.com> Message-ID: <760eb801-3d82-ce9d-e819-48c0ba5499c7@redhat.com> On 10.11.2016 06:43, David Kupka wrote: > On 10/11/16 01:14, Brendan Kearney wrote: >> i am asking this for a friend who is trying to figure out how to get >> bind-dyndb-ldap working against openldap on ubuntu. she does not have >> replication between two or more ldap instances, and needs to figure out >> the minimum requirements for bind-dyndb-ldap. i have been trying to >> help her, but i am unsure about what is needed, as i have n-way multi >> master replication working already. >> >> can anyone provide what the replication requirements are for >> bind-dyndb-ldap? currently, the SyncRepl module is loaded and the >> overlay is created and configured for the mdb. i have tried to help get >> olcServerID and olcMirrorMode set in cn=config and >> olcDatabase={2}mdb,cn=config respectively, but some errors were >> encountered there. is there a best practices doc that we can review? >> >> the environment, as best i can tell is ubuntu, openldap 2.4.42 and bind >> 9. exact os and bind versions are not known right now. >> >> thanks, >> >> brendan kearney >> > > Hello Brendan, > I don't have any experience with running OpenLDAP + bind-dyndb-ldap but quick > web search showed me this: > > https://blogs.mindspew-age.com/2013/06/07/bind-dns-openldap-mdb-dynamic-domainsub-domain-configuration-of-dns/ > > > The article is about CentOS 6 and more than 3 years old but still might be > helpful because it's mainly about Bind 9 configuration. This article is not applicable to new versions of bind-dyndb-ldap, the new versions require SyncRepl. Any OpenLDAP article about setting SyncRepl provider will suffice, bind-dyndb-ldap does not require anything special on OpenLDAP side. You can use following command to test if SyncRepl works and access control is correct: $ ldapsearch -h ldap.example.com -D "uid=bind-user,cn=users,${BASE}" -w root4lab -E sync=rp -b "cn=dns,${BASE}" '(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))' -- Petr^2 Spacek From matrix.zj at qq.com Thu Nov 10 09:22:26 2016 From: matrix.zj at qq.com (=?ISO-8859-1?B?TWF0cml4?=) Date: Thu, 10 Nov 2016 17:22:26 +0800 Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed (-2)[Localerror]' Message-ID: debug steps have been tried: 1 kinit is workable: # /usr/kerberos/bin/kinit -k host/client02.stg.example.net at EXAMPLE.NET # /usr/kerberos/bin/klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: host/client02.stg.example.net at EXAMPLE.NET Valid starting Expires Service principal 11/10/16 09:18:00 11/11/16 09:17:35 krbtgt/EXAMPLE.NET at EXAMPLE.NET Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached 2 ldapwhoami with krb auth failed. # ldapwhoami -Y GSSAPI -h ipaslave.stg.example.net SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Mutual authentication failed) Matrix ------------------ Original ------------------ From: "Matrix";; Date: Thu, Nov 10, 2016 02:11 PM To: "freeipa-users"; Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed (-2)[Localerror]' Hi, I have installed sssd in a RHEL5 client. ipa-client/sssd version: ipa-client-2.1.3-7.el5 sssd-client-1.5.1-71.el5 sssd-1.5.1-71.el5 sssd failed to get ipa user info with 'ldap_sasl_bind failed (-2)[Local error]'. (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/client02.stg.example.net (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (1): ldap_sasl_bind failed (-2)[Local error] (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (7): Waiting for child [11117]. (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (4): child [11117] finished successfully. I have tried to google to find root cause. some link explained it should be something wrong with dns. I have double confirmed it. # nslookup client02.stg.example.net Server: 10.2.1.21 Address: 10.2.1.21#53 Name: client02.stg.example.net Address: 10.2.3.32 # nslookup 10.2.3.32 Server: 10.2.1.21 Address: 10.2.1.21#53 32.3.2.10.in-addr.arpa name = client02.stg.example.net. # nslookup ipaslave.stg.example.net Server: 10.2.1.21 Address: 10.2.1.21#53 Name: ipaslave.stg.example.net Address: 10.2.1.250 # nslookup 10.2.1.250 Server: 10.2.1.21 Address: 10.2.1.21#53 250.1.2.10.in-addr.arpa name = ipaslave.stg.example.net. Any hints or troubleshooting ideas would be appreciated. Matrix -------------- next part -------------- An HTML attachment was scrubbed... URL: From peljasz at yahoo.co.uk Thu Nov 10 10:32:14 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 10 Nov 2016 10:32:14 +0000 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <7be13418-72c1-8ceb-be00-244f9c241913@redhat.com> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> <7175c75c-9f16-86ae-e1c2-aba6825506b7@redhat.com> <93c10ec6-08d5-e943-6e09-fa2b1defccc3@yahoo.co.uk> <00de4a04-a55b-1154-8ae7-1e92fc90986a@redhat.com> <822f5ce5-524c-49f4-5eda-4a65a17f4a75@yahoo.co.uk> <7be13418-72c1-8ceb-be00-244f9c241913@redhat.com> Message-ID: <5cce48e6-8312-bdf1-a85e-feaec4dd2b31@yahoo.co.uk> On 10/11/16 06:51, Petr Spacek wrote: > On 9.11.2016 16:57, lejeczek wrote: >> >> On 09/11/16 14:35, Martin Basti wrote: >>> >>> On 09.11.2016 15:33, lejeczek wrote: >>>> >>>> On 09/11/16 13:48, Martin Basti wrote: >>>>> >>>>> On 09.11.2016 14:11, lejeczek wrote: >>>>>> >>>>>> On 09/11/16 12:43, Martin Basti wrote: >>>>>>> >>>>>>> On 09.11.2016 12:15, lejeczek wrote: >>>>>>>> >>>>>>>> On 08/11/16 19:37, Martin Basti wrote: >>>>>>>>> >>>>>>>>> On 08.11.2016 19:41, lejeczek wrote: >>>>>>>>>> hi everyone >>>>>>>>>> when I look at my domain I see something which seems inconsistent to >>>>>>>>>> me (eg. work5 is not part of the domain, was --uninstalled) >>>>>>>>>> Do these record need fixing? >>>>>>>>>> I'm asking becuase one of the servers, despite the fact the ipa dns >>>>>>>>>> related toolkit(on that server) shows zone & records, to >>>>>>>>>> dig/host/etc. presents nothing, empty responses!?? >>>>>>>>>> >>>>>>>>>> $ ipa dnsrecord-find xx.xx.xx.xx.x. >>>>>>>>>> Record name: @ >>>>>>>>>> NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., >>>>>>>>>> dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. >>>>>>>>>> >>>>>>>>>> Record name: _kerberos >>>>>>>>>> TXT record: .xx.xx..xx.xx.x >>>>>>>>>> >>>>>>>>>> Record name: _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>>> >>>>>>>>>> Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>>>>>> >>>>>>>>>> Record name: _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>>> >>>>>>>>>> Record name: _kerberos._tcp.dc._msdcs >>>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>>> >>>>>>>>>> Record name: _ldap._tcp.dc._msdcs >>>>>>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>>>>>> >>>>>>>>>> Record name: _kerberos._udp.dc._msdcs >>>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>>> >>>>>>>>>> Record name: _kerberos._tcp >>>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>>> 88 swir >>>>>>>>>> >>>>>>>>>> Record name: _kerberos-master._tcp >>>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>>> 88 swir >>>>>>>>>> >>>>>>>>>> Record name: _kpasswd._tcp >>>>>>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100 >>>>>>>>>> 464 whale >>>>>>>>>> >>>>>>>>>> Record name: _ldap._tcp >>>>>>>>>> SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 whale, 0 100 >>>>>>>>>> 389 rider >>>>>>>>>> >>>>>>>>>> Record name: _kerberos._udp >>>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>>> 88 swir >>>>>>>>>> >>>>>>>>>> Record name: _kerberos-master._udp >>>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>>> 88 swir >>>>>>>>>> >>>>>>>>>> Record name: _kpasswd._udp >>>>>>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100 >>>>>>>>>> 464 whale >>>>>>>>>> >>>>>>>>>> Record name: _ntp._udp >>>>>>>>>> SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 123 whale, 0 >>>>>>>>>> 100 123 swir >>>>>>>>>> >>>>>>>>>> thanks. >>>>>>>>>> L. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> if server work5 is uninstalled, then work5 SRV records should be removed. >>>>>>>>> >>>>>>>>> Martin >>>>>>>> Martin, would you be able suggest a way to troubleshoot that problem >>>>>>>> that one (only) server (rider) seems to present no data for the whole >>>>>>>> domain? Remaining servers correctly respond to any queries. One curious >>>>>>>> thing is that I $rndc trace 6; and (I see debug level changed in >>>>>>>> journalctl) I do not see anything in the logs when I query. >>>>>>>> Zone allows any to query it. >>>>>>>> >>>>>>>> >>>>>>> What dig @rider command returns for SRV queries? >>>>>>> >>>>>> don't mind SRV records for now, it returns no record at all, it forwards >>>>>> and caches but not for the domain itself. >>>>>> on rider (suffice I point to other member server and records are there) >>>>>> >>>>>> $ dig +qr any .xx.xx..xx.xx.x. @10.5.6.100 >>>>>> >>>>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> +qr any .xx.xx..xx.xx.x. >>>>>> @10.5.6.100 >>>>>> ;; global options: +cmd >>>>>> ;; Sending: >>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36196 >>>>>> ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >>>>>> >>>>>> ;; OPT PSEUDOSECTION: >>>>>> ; EDNS: version: 0, flags:; udp: 4096 >>>>>> ;; QUESTION SECTION: >>>>>> ;.xx.xx..xx.xx.x. IN ANY >>>>>> >>>>>> ;; Got answer: >>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36196 >>>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >>>>>> >>>>>> ;; OPT PSEUDOSECTION: >>>>>> ; EDNS: version: 0, flags:; udp: 4096 >>>>>> ;; QUESTION SECTION: >>>>>> ;.xx.xx..xx.xx.x. IN ANY >>>>>> >>>>>> ;; AUTHORITY SECTION: >>>>>> .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. >>>>>> 1478696070 1800 900 604800 3600 >>>>>> >>>>>> ;; Query time: 5 msec >>>>>> ;; SERVER: 10.5.6.100#53(10.5.6.100) >>>>>> ;; WHEN: Wed Nov 09 12:56:16 GMT 2016 >>>>>> ;; MSG SIZE rcvd: 120 >>>>>> >>>>>> I obfuscated FQDNs but it seems like it forwards to a parent domain (to >>>>>> which it's supposed, by dnsforwardzone) >>>>>> And like I mentioned earlier, I do dnszone-find, etc. (on rider) it's all >>>>>> there. >>>>>> >>>>>> >>>>>> >>>>> I'm lost now, I don't understand you, you told me that resolving on >>>>> 'rider' server doesn't work, then you write me that it is expected because >>>>> you have fowardzone set, but you cannot have forwardzone and master zone >>>>> for the same domain, IPA doesn't allow it, so I have no idea what is not >>>>> working for you. (You didn't make it easier by obfuscating output) >>>>> >>>>> Martin >>>> no no, sorry, I mean - it forwards whereas is should be authoritative for >>>> it's own FQDN. >>>> I realize it is not obvious after I obfuscated the output, but here: >>>> >>>> ;; AUTHORITY SECTION: >>>> .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. 1478696070 >>>> 1800 900 604800 3600 >>>> >>>> this looks like the only domain with is dnsforwardzone, everything else is >>>> dnszone >>>> >>>> parent.xx.xx. - is the only forward >>>> private.my.parent.xx.xx - it is IPA domain & dnszone >>>> >>>> I query private.my.parent.xx.xx and I get response as above. >>> Do you have proper zone delegation from parent zone? NS and A glue records? >> no, I don't have any dealings with "parent" domain, I forward to there so only >> those queries could go directly to NSes instead of to ROOTs. >> I do not really on that "parent" - I call it parent for only >> "logistically/visually" it appears as parent. >>> How your named.conf looks? >> Exactly the same as on the other three servers(IPA generated), I diffed it, >> only these are (respectively) different: fake_mname, sasl_user >> I think that one server simply forwards (to that dnsforwardzone) as if it had >> not any own zones, but why?? Would it be in the LDAP? > Do you have 'forwarders' statement in your named.conf? forward first; forwarders { }; > > If you have it, we might see a situation where LDAP plugin does not > load/connect to LDAP for whatever reason and only the global forwarding works. > > Alternatively it might be a problem described in > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5.NozonesfromLDAPareloaded it's a freaking bingo! 0 master zones from LDAP instance 'ipa' loaded (0 zones defined, 0 inactive, 0 failed to load) 0 master zones is suspicious number, please check access control instructions on LDAP server now, well.. how to fix it? $ ipa privilege-show 'DNS Servers' --all --raw dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x cn: DNS Servers description: DNS Servers member: krbprincipalname=DNS/swir..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x member: krbprincipalname=ipa-dnskeysyncd/swir..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x member: krbprincipalname=DNS/whale..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x member: krbprincipalname=ipa-dnskeysyncd/whale..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x member: krbprincipalname=DNS/dzien..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x member: krbprincipalname=ipa-dnskeysyncd/dzien..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x memberof: cn=System: Read DNS Configuration,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x memberof: cn=System: Write DNS Configuration,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x memberof: cn=System: Add DNS Entries,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x memberof: cn=System: Manage DNSSEC keys,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x memberof: cn=System: Manage DNSSEC metadata,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x memberof: cn=System: Read DNS Entries,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x memberof: cn=System: Remove DNS Entries,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x memberof: cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x objectClass: top objectClass: groupofnames objectClass: nestedgroup From sbose at redhat.com Thu Nov 10 10:32:43 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 10 Nov 2016 11:32:43 +0100 Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed (-2)[Localerror]' In-Reply-To: References: Message-ID: <20161110103243.GB19211@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, Nov 10, 2016 at 05:22:26PM +0800, Matrix wrote: > debug steps have been tried: > > 1 kinit is workable: > # /usr/kerberos/bin/kinit -k host/client02.stg.example.net at EXAMPLE.NET > > # /usr/kerberos/bin/klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: host/client02.stg.example.net at EXAMPLE.NET > > Valid starting Expires Service principal > 11/10/16 09:18:00 11/11/16 09:17:35 krbtgt/EXAMPLE.NET at EXAMPLE.NET > > Kerberos 4 ticket cache: /tmp/tkt0 > klist: You have no tickets cached > > 2 ldapwhoami with krb auth failed. > > # ldapwhoami -Y GSSAPI -h ipaslave.stg.example.net > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Mutual authentication failed) > Have you made sure that canonicalizing is disabled, i.e. /etc/krb5.conf: [libdefaults] ... rdns = false ... /etc/openldap/ldap.conf ... SASL_NOCANON on ... HTH bye, Sumit > > Matrix > > ------------------ Original ------------------ > From: "Matrix";; > Date: Thu, Nov 10, 2016 02:11 PM > To: "freeipa-users"; > > Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed (-2)[Localerror]' > > > > Hi, > > I have installed sssd in a RHEL5 client. > > ipa-client/sssd version: > ipa-client-2.1.3-7.el5 > sssd-client-1.5.1-71.el5 > sssd-1.5.1-71.el5 > > sssd failed to get ipa user info with 'ldap_sasl_bind failed (-2)[Local error]'. > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/client02.stg.example.net > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (1): ldap_sasl_bind failed (-2)[Local error] > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (7): Waiting for child [11117]. > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (4): child [11117] finished successfully. > > I have tried to google to find root cause. some link explained it should be something wrong with dns. I have double confirmed it. > > # nslookup client02.stg.example.net > Server: 10.2.1.21 > Address: 10.2.1.21#53 > > Name: client02.stg.example.net > Address: 10.2.3.32 > > > # nslookup 10.2.3.32 > Server: 10.2.1.21 > Address: 10.2.1.21#53 > > 32.3.2.10.in-addr.arpa name = client02.stg.example.net. > > > # nslookup ipaslave.stg.example.net > Server: 10.2.1.21 > Address: 10.2.1.21#53 > > Name: ipaslave.stg.example.net > Address: 10.2.1.250 > > # nslookup 10.2.1.250 > Server: 10.2.1.21 > Address: 10.2.1.21#53 > > 250.1.2.10.in-addr.arpa name = ipaslave.stg.example.net. > > Any hints or troubleshooting ideas would be appreciated. > > Matrix > -- > 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 pspacek at redhat.com Thu Nov 10 10:44:47 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 10 Nov 2016 11:44:47 +0100 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <5cce48e6-8312-bdf1-a85e-feaec4dd2b31@yahoo.co.uk> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> <7175c75c-9f16-86ae-e1c2-aba6825506b7@redhat.com> <93c10ec6-08d5-e943-6e09-fa2b1defccc3@yahoo.co.uk> <00de4a04-a55b-1154-8ae7-1e92fc90986a@redhat.com> <822f5ce5-524c-49f4-5eda-4a65a17f4a75@yahoo.co.uk> <7be13418-72c1-8ceb-be00-244f9c241913@redhat.com> <5cce48e6-8312-bdf1-a85e-feaec4dd2b31@yahoo.co.uk> Message-ID: <92fc5696-1468-c820-b947-46140bdf1f82@redhat.com> On 10.11.2016 11:32, lejeczek wrote: > > > On 10/11/16 06:51, Petr Spacek wrote: >> On 9.11.2016 16:57, lejeczek wrote: >>> >>> On 09/11/16 14:35, Martin Basti wrote: >>>> >>>> On 09.11.2016 15:33, lejeczek wrote: >>>>> >>>>> On 09/11/16 13:48, Martin Basti wrote: >>>>>> >>>>>> On 09.11.2016 14:11, lejeczek wrote: >>>>>>> >>>>>>> On 09/11/16 12:43, Martin Basti wrote: >>>>>>>> >>>>>>>> On 09.11.2016 12:15, lejeczek wrote: >>>>>>>>> >>>>>>>>> On 08/11/16 19:37, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> On 08.11.2016 19:41, lejeczek wrote: >>>>>>>>>>> hi everyone >>>>>>>>>>> when I look at my domain I see something which seems inconsistent to >>>>>>>>>>> me (eg. work5 is not part of the domain, was --uninstalled) >>>>>>>>>>> Do these record need fixing? >>>>>>>>>>> I'm asking becuase one of the servers, despite the fact the ipa dns >>>>>>>>>>> related toolkit(on that server) shows zone & records, to >>>>>>>>>>> dig/host/etc. presents nothing, empty responses!?? >>>>>>>>>>> >>>>>>>>>>> $ ipa dnsrecord-find xx.xx.xx.xx.x. >>>>>>>>>>> Record name: @ >>>>>>>>>>> NS record: swir.xx.xx.xx.xx.x., rider.xx.xx.xx.xx.x., >>>>>>>>>>> dzien.xx.xx.xx.xx.x., whale.xx.xx.xx.xx.x. >>>>>>>>>>> >>>>>>>>>>> Record name: _kerberos >>>>>>>>>>> TXT record: .xx.xx..xx.xx.x >>>>>>>>>>> >>>>>>>>>>> Record name: >>>>>>>>>>> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>>>> >>>>>>>>>>> Record name: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>>>>>>> >>>>>>>>>>> Record name: >>>>>>>>>>> _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs >>>>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>>>> >>>>>>>>>>> Record name: _kerberos._tcp.dc._msdcs >>>>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>>>> >>>>>>>>>>> Record name: _ldap._tcp.dc._msdcs >>>>>>>>>>> SRV record: 0 100 389 rider, 0 100 389 work5 >>>>>>>>>>> >>>>>>>>>>> Record name: _kerberos._udp.dc._msdcs >>>>>>>>>>> SRV record: 0 100 88 rider, 0 100 88 work5 >>>>>>>>>>> >>>>>>>>>>> Record name: _kerberos._tcp >>>>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>>>> 88 swir >>>>>>>>>>> >>>>>>>>>>> Record name: _kerberos-master._tcp >>>>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>>>> 88 swir >>>>>>>>>>> >>>>>>>>>>> Record name: _kpasswd._tcp >>>>>>>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100 >>>>>>>>>>> 464 whale >>>>>>>>>>> >>>>>>>>>>> Record name: _ldap._tcp >>>>>>>>>>> SRV record: 0 100 389 swir, 0 100 389 dzien, 0 100 389 whale, 0 100 >>>>>>>>>>> 389 rider >>>>>>>>>>> >>>>>>>>>>> Record name: _kerberos._udp >>>>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>>>> 88 swir >>>>>>>>>>> >>>>>>>>>>> Record name: _kerberos-master._udp >>>>>>>>>>> SRV record: 0 100 88 whale, 0 100 88 dzien, 0 100 88 rider, 0 100 >>>>>>>>>>> 88 swir >>>>>>>>>>> >>>>>>>>>>> Record name: _kpasswd._udp >>>>>>>>>>> SRV record: 0 100 464 rider, 0 100 464 swir, 0 100 464 dzien, 0 100 >>>>>>>>>>> 464 whale >>>>>>>>>>> >>>>>>>>>>> Record name: _ntp._udp >>>>>>>>>>> SRV record: 0 100 123 dzien, 0 100 123 rider, 0 100 123 whale, 0 >>>>>>>>>>> 100 123 swir >>>>>>>>>>> >>>>>>>>>>> thanks. >>>>>>>>>>> L. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> if server work5 is uninstalled, then work5 SRV records should be >>>>>>>>>> removed. >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>> Martin, would you be able suggest a way to troubleshoot that problem >>>>>>>>> that one (only) server (rider) seems to present no data for the whole >>>>>>>>> domain? Remaining servers correctly respond to any queries. One curious >>>>>>>>> thing is that I $rndc trace 6; and (I see debug level changed in >>>>>>>>> journalctl) I do not see anything in the logs when I query. >>>>>>>>> Zone allows any to query it. >>>>>>>>> >>>>>>>>> >>>>>>>> What dig @rider command returns for SRV queries? >>>>>>>> >>>>>>> don't mind SRV records for now, it returns no record at all, it forwards >>>>>>> and caches but not for the domain itself. >>>>>>> on rider (suffice I point to other member server and records are there) >>>>>>> >>>>>>> $ dig +qr any .xx.xx..xx.xx.x. @10.5.6.100 >>>>>>> >>>>>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> +qr any .xx.xx..xx.xx.x. >>>>>>> @10.5.6.100 >>>>>>> ;; global options: +cmd >>>>>>> ;; Sending: >>>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36196 >>>>>>> ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >>>>>>> >>>>>>> ;; OPT PSEUDOSECTION: >>>>>>> ; EDNS: version: 0, flags:; udp: 4096 >>>>>>> ;; QUESTION SECTION: >>>>>>> ;.xx.xx..xx.xx.x. IN ANY >>>>>>> >>>>>>> ;; Got answer: >>>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36196 >>>>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >>>>>>> >>>>>>> ;; OPT PSEUDOSECTION: >>>>>>> ; EDNS: version: 0, flags:; udp: 4096 >>>>>>> ;; QUESTION SECTION: >>>>>>> ;.xx.xx..xx.xx.x. IN ANY >>>>>>> >>>>>>> ;; AUTHORITY SECTION: >>>>>>> .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. >>>>>>> 1478696070 1800 900 604800 3600 >>>>>>> >>>>>>> ;; Query time: 5 msec >>>>>>> ;; SERVER: 10.5.6.100#53(10.5.6.100) >>>>>>> ;; WHEN: Wed Nov 09 12:56:16 GMT 2016 >>>>>>> ;; MSG SIZE rcvd: 120 >>>>>>> >>>>>>> I obfuscated FQDNs but it seems like it forwards to a parent domain (to >>>>>>> which it's supposed, by dnsforwardzone) >>>>>>> And like I mentioned earlier, I do dnszone-find, etc. (on rider) it's all >>>>>>> there. >>>>>>> >>>>>>> >>>>>>> >>>>>> I'm lost now, I don't understand you, you told me that resolving on >>>>>> 'rider' server doesn't work, then you write me that it is expected because >>>>>> you have fowardzone set, but you cannot have forwardzone and master zone >>>>>> for the same domain, IPA doesn't allow it, so I have no idea what is not >>>>>> working for you. (You didn't make it easier by obfuscating output) >>>>>> >>>>>> Martin >>>>> no no, sorry, I mean - it forwards whereas is should be authoritative for >>>>> it's own FQDN. >>>>> I realize it is not obvious after I obfuscated the output, but here: >>>>> >>>>> ;; AUTHORITY SECTION: >>>>> .xx.xx.x. 3600 IN SOA ipreg.xxx.xx.xx.x. hostmaster.xx.xx.x. 1478696070 >>>>> 1800 900 604800 3600 >>>>> >>>>> this looks like the only domain with is dnsforwardzone, everything else is >>>>> dnszone >>>>> >>>>> parent.xx.xx. - is the only forward >>>>> private.my.parent.xx.xx - it is IPA domain & dnszone >>>>> >>>>> I query private.my.parent.xx.xx and I get response as above. >>>> Do you have proper zone delegation from parent zone? NS and A glue records? >>> no, I don't have any dealings with "parent" domain, I forward to there so only >>> those queries could go directly to NSes instead of to ROOTs. >>> I do not really on that "parent" - I call it parent for only >>> "logistically/visually" it appears as parent. >>>> How your named.conf looks? >>> Exactly the same as on the other three servers(IPA generated), I diffed it, >>> only these are (respectively) different: fake_mname, sasl_user >>> I think that one server simply forwards (to that dnsforwardzone) as if it had >>> not any own zones, but why?? Would it be in the LDAP? >> Do you have 'forwarders' statement in your named.conf? > forward first; > forwarders { }; > >> >> If you have it, we might see a situation where LDAP plugin does not >> load/connect to LDAP for whatever reason and only the global forwarding works. >> >> Alternatively it might be a problem described in >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a5.NozonesfromLDAPareloaded >> > it's a freaking bingo! > > 0 master zones from LDAP instance 'ipa' loaded (0 zones defined, 0 inactive, 0 > failed to load) > 0 master zones is suspicious number, please check access control instructions > on LDAP server > > now, well.. how to fix it? > > $ ipa privilege-show 'DNS Servers' --all --raw > dn: cn=DNS Servers,cn=privileges,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > cn: DNS Servers > description: DNS Servers > member: > krbprincipalname=DNS/swir..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > > member: > krbprincipalname=ipa-dnskeysyncd/swir..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > > member: > krbprincipalname=DNS/whale..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > > member: > krbprincipalname=ipa-dnskeysyncd/whale..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > > member: > krbprincipalname=DNS/dzien..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > > member: > krbprincipalname=ipa-dnskeysyncd/dzien..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > > memberof: cn=System: Read DNS > Configuration,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > memberof: cn=System: Write DNS > Configuration,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > memberof: cn=System: Add DNS > Entries,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > memberof: cn=System: Manage DNSSEC > keys,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > memberof: cn=System: Manage DNSSEC > metadata,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > memberof: cn=System: Read DNS > Entries,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > memberof: cn=System: Remove DNS > Entries,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > memberof: cn=System: Update DNS > Entries,cn=permissions,cn=pbac,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x > objectClass: top > objectClass: groupofnames > objectClass: nestedgroup This is non-standard situation so it asks for non-standard commands. I would try: $ ipa privilege-mod 'DNS Servers' --addattr=member=krbprincipalname=DNS/rider..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x' $ ipa privilege-mod 'DNS Servers' --addattr=member=krbprincipalname=ipa-dnskeysyncd/rider..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x' Be very careful when constructing these DNs, --addattr do not validate the input! -- Petr^2 Spacek From matrix.zj at qq.com Thu Nov 10 10:48:54 2016 From: matrix.zj at qq.com (=?ISO-8859-1?B?TWF0cml4?=) Date: Thu, 10 Nov 2016 18:48:54 +0800 Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed(-2)[Localerror]' In-Reply-To: <20161110103243.GB19211@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161110103243.GB19211@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: Hi, Sumit Thanks for your reply I have tried. still failed # cat /etc/openldap/ldap.conf | grep -v ^# URI ldap://ipaslave.stg.example.net BASE dc=example,dc=net TLS_CACERT /etc/ipa/ca.crt SASL_MECH GSSAPI TLS_REQCERT allow SASL_NOCANON on # cat /etc/krb5.conf| grep rdns rdns = false Matrix ------------------ Original ------------------ From: "Sumit Bose";; Date: Thu, Nov 10, 2016 06:32 PM To: "freeipa-users"; Subject: Re: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed(-2)[Localerror]' On Thu, Nov 10, 2016 at 05:22:26PM +0800, Matrix wrote: > debug steps have been tried: > > 1 kinit is workable: > # /usr/kerberos/bin/kinit -k host/client02.stg.example.net at EXAMPLE.NET > > # /usr/kerberos/bin/klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: host/client02.stg.example.net at EXAMPLE.NET > > Valid starting Expires Service principal > 11/10/16 09:18:00 11/11/16 09:17:35 krbtgt/EXAMPLE.NET at EXAMPLE.NET > > Kerberos 4 ticket cache: /tmp/tkt0 > klist: You have no tickets cached > > 2 ldapwhoami with krb auth failed. > > # ldapwhoami -Y GSSAPI -h ipaslave.stg.example.net > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Mutual authentication failed) > Have you made sure that canonicalizing is disabled, i.e. /etc/krb5.conf: [libdefaults] ... rdns = false ... /etc/openldap/ldap.conf ... SASL_NOCANON on ... HTH bye, Sumit > > Matrix > > ------------------ Original ------------------ > From: "Matrix";; > Date: Thu, Nov 10, 2016 02:11 PM > To: "freeipa-users"; > > Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed (-2)[Localerror]' > > > > Hi, > > I have installed sssd in a RHEL5 client. > > ipa-client/sssd version: > ipa-client-2.1.3-7.el5 > sssd-client-1.5.1-71.el5 > sssd-1.5.1-71.el5 > > sssd failed to get ipa user info with 'ldap_sasl_bind failed (-2)[Local error]'. > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/client02.stg.example.net > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (1): ldap_sasl_bind failed (-2)[Local error] > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (7): Waiting for child [11117]. > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (4): child [11117] finished successfully. > > I have tried to google to find root cause. some link explained it should be something wrong with dns. I have double confirmed it. > > # nslookup client02.stg.example.net > Server: 10.2.1.21 > Address: 10.2.1.21#53 > > Name: client02.stg.example.net > Address: 10.2.3.32 > > > # nslookup 10.2.3.32 > Server: 10.2.1.21 > Address: 10.2.1.21#53 > > 32.3.2.10.in-addr.arpa name = client02.stg.example.net. > > > # nslookup ipaslave.stg.example.net > Server: 10.2.1.21 > Address: 10.2.1.21#53 > > Name: ipaslave.stg.example.net > Address: 10.2.1.250 > > # nslookup 10.2.1.250 > Server: 10.2.1.21 > Address: 10.2.1.21#53 > > 250.1.2.10.in-addr.arpa name = ipaslave.stg.example.net. > > Any hints or troubleshooting ideas would be appreciated. > > Matrix > -- > 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 peljasz at yahoo.co.uk Thu Nov 10 11:08:05 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 10 Nov 2016 11:08:05 +0000 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <92fc5696-1468-c820-b947-46140bdf1f82@redhat.com> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> <7175c75c-9f16-86ae-e1c2-aba6825506b7@redhat.com> <93c10ec6-08d5-e943-6e09-fa2b1defccc3@yahoo.co.uk> <00de4a04-a55b-1154-8ae7-1e92fc90986a@redhat.com> <822f5ce5-524c-49f4-5eda-4a65a17f4a75@yahoo.co.uk> <7be13418-72c1-8ceb-be00-244f9c241913@redhat.com> <5cce48e6-8312-bdf1-a85e-feaec4dd2b31@yahoo.co.uk> <92fc5696-1468-c820-b947-46140bdf1f82@redhat.com> Message-ID: <4911d331-4f65-15ea-4433-7a838343df85@yahoo.co.uk> On 10/11/16 10:44, Petr Spacek wrote: > This is non-standard situation so it asks for non-standard commands. > > I would try: > $ ipa privilege-mod 'DNS Servers' > --addattr=member=krbprincipalname=DNS/rider..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x' > $ ipa privilege-mod 'DNS Servers' > --addattr=member=krbprincipalname=ipa-dnskeysyncd/rider..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x' > > Be very careful when constructing these DNs, --addattr do not validate the input! well, I realize these can be trivial trifles, but man, you saved the... week! And to finish (hopefully) - maybe even more of a puzzle: how it happened? This box member was fine, suddenly (I was recovering/reconnecting replication agreements), maybe not suddenly, but when I noticed at some point, it did that. It lost those ldap bits? many! thanks L. From sbose at redhat.com Thu Nov 10 11:13:32 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 10 Nov 2016 12:13:32 +0100 Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed(-2)[Localerror]' In-Reply-To: References: <20161110103243.GB19211@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <20161110111332.GC19211@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, Nov 10, 2016 at 06:48:54PM +0800, Matrix wrote: > Hi, Sumit > > Thanks for your reply > > I have tried. still failed Do you see any related messages on the LDAP server side? bye, Sumit > > # cat /etc/openldap/ldap.conf | grep -v ^# > > URI ldap://ipaslave.stg.example.net > BASE dc=example,dc=net > TLS_CACERT /etc/ipa/ca.crt > SASL_MECH GSSAPI > TLS_REQCERT allow > SASL_NOCANON on > > > # cat /etc/krb5.conf| grep rdns > rdns = false > > Matrix > > ------------------ Original ------------------ > From: "Sumit Bose";; > Date: Thu, Nov 10, 2016 06:32 PM > To: "freeipa-users"; > > Subject: Re: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed(-2)[Localerror]' > > > > On Thu, Nov 10, 2016 at 05:22:26PM +0800, Matrix wrote: > > debug steps have been tried: > > > > 1 kinit is workable: > > # /usr/kerberos/bin/kinit -k host/client02.stg.example.net at EXAMPLE.NET > > > > # /usr/kerberos/bin/klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: host/client02.stg.example.net at EXAMPLE.NET > > > > Valid starting Expires Service principal > > 11/10/16 09:18:00 11/11/16 09:17:35 krbtgt/EXAMPLE.NET at EXAMPLE.NET > > > > Kerberos 4 ticket cache: /tmp/tkt0 > > klist: You have no tickets cached > > > > 2 ldapwhoami with krb auth failed. > > > > # ldapwhoami -Y GSSAPI -h ipaslave.stg.example.net > > SASL/GSSAPI authentication started > > ldap_sasl_interactive_bind_s: Local error (-2) > > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Mutual authentication failed) > > > > Have you made sure that canonicalizing is disabled, i.e. > /etc/krb5.conf: > [libdefaults] > ... > rdns = false > ... > > /etc/openldap/ldap.conf > ... > SASL_NOCANON on > ... > > HTH > > bye, > Sumit > > > > > Matrix > > > > ------------------ Original ------------------ > > From: "Matrix";; > > Date: Thu, Nov 10, 2016 02:11 PM > > To: "freeipa-users"; > > > > Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed (-2)[Localerror]' > > > > > > > > Hi, > > > > I have installed sssd in a RHEL5 client. > > > > ipa-client/sssd version: > > ipa-client-2.1.3-7.el5 > > sssd-client-1.5.1-71.el5 > > sssd-1.5.1-71.el5 > > > > sssd failed to get ipa user info with 'ldap_sasl_bind failed (-2)[Local error]'. > > > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/client02.stg.example.net > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (1): ldap_sasl_bind failed (-2)[Local error] > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (7): Waiting for child [11117]. > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (4): child [11117] finished successfully. > > > > I have tried to google to find root cause. some link explained it should be something wrong with dns. I have double confirmed it. > > > > # nslookup client02.stg.example.net > > Server: 10.2.1.21 > > Address: 10.2.1.21#53 > > > > Name: client02.stg.example.net > > Address: 10.2.3.32 > > > > > > # nslookup 10.2.3.32 > > Server: 10.2.1.21 > > Address: 10.2.1.21#53 > > > > 32.3.2.10.in-addr.arpa name = client02.stg.example.net. > > > > > > # nslookup ipaslave.stg.example.net > > Server: 10.2.1.21 > > Address: 10.2.1.21#53 > > > > Name: ipaslave.stg.example.net > > Address: 10.2.1.250 > > > > # nslookup 10.2.1.250 > > Server: 10.2.1.21 > > Address: 10.2.1.21#53 > > > > 250.1.2.10.in-addr.arpa name = ipaslave.stg.example.net. > > > > Any hints or troubleshooting ideas would be appreciated. > > > > Matrix > > > -- > > 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 From matrix.zj at qq.com Thu Nov 10 11:19:09 2016 From: matrix.zj at qq.com (=?ISO-8859-1?B?TWF0cml4?=) Date: Thu, 10 Nov 2016 19:19:09 +0800 Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bindfailed(-2)[Localerror]' In-Reply-To: <20161110111332.GC19211@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161110103243.GB19211@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161110111332.GC19211@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: Hi, Sumit I have checked, and did not find anything more: error logs from /var/log/dirsrv/slapd-EXAMPLE-NET/access: ....... [10/Nov/2016:10:46:58 +0000] conn=816560 fd=189 slot=189 connection from 10.2.3.32 to 10.2.1.250 [10/Nov/2016:10:46:58 +0000] conn=816560 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [10/Nov/2016:10:46:58 +0000] conn=816560 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [10/Nov/2016:10:46:58 +0000] conn=816560 op=-1 fd=189 closed - B1 ....... Matrix ------------------ Original ------------------ From: "Sumit Bose";; Date: Thu, Nov 10, 2016 07:13 PM To: "Matrix"; Cc: "Sumit Bose"; "freeipa-users"; Subject: Re: [Freeipa-users] sssd failed with 'ldap_sasl_bindfailed(-2)[Localerror]' On Thu, Nov 10, 2016 at 06:48:54PM +0800, Matrix wrote: > Hi, Sumit > > Thanks for your reply > > I have tried. still failed Do you see any related messages on the LDAP server side? bye, Sumit > > # cat /etc/openldap/ldap.conf | grep -v ^# > > URI ldap://ipaslave.stg.example.net > BASE dc=example,dc=net > TLS_CACERT /etc/ipa/ca.crt > SASL_MECH GSSAPI > TLS_REQCERT allow > SASL_NOCANON on > > > # cat /etc/krb5.conf| grep rdns > rdns = false > > Matrix > > ------------------ Original ------------------ > From: "Sumit Bose";; > Date: Thu, Nov 10, 2016 06:32 PM > To: "freeipa-users"; > > Subject: Re: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed(-2)[Localerror]' > > > > On Thu, Nov 10, 2016 at 05:22:26PM +0800, Matrix wrote: > > debug steps have been tried: > > > > 1 kinit is workable: > > # /usr/kerberos/bin/kinit -k host/client02.stg.example.net at EXAMPLE.NET > > > > # /usr/kerberos/bin/klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: host/client02.stg.example.net at EXAMPLE.NET > > > > Valid starting Expires Service principal > > 11/10/16 09:18:00 11/11/16 09:17:35 krbtgt/EXAMPLE.NET at EXAMPLE.NET > > > > Kerberos 4 ticket cache: /tmp/tkt0 > > klist: You have no tickets cached > > > > 2 ldapwhoami with krb auth failed. > > > > # ldapwhoami -Y GSSAPI -h ipaslave.stg.example.net > > SASL/GSSAPI authentication started > > ldap_sasl_interactive_bind_s: Local error (-2) > > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Mutual authentication failed) > > > > Have you made sure that canonicalizing is disabled, i.e. > /etc/krb5.conf: > [libdefaults] > ... > rdns = false > ... > > /etc/openldap/ldap.conf > ... > SASL_NOCANON on > ... > > HTH > > bye, > Sumit > > > > > Matrix > > > > ------------------ Original ------------------ > > From: "Matrix";; > > Date: Thu, Nov 10, 2016 02:11 PM > > To: "freeipa-users"; > > > > Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed (-2)[Localerror]' > > > > > > > > Hi, > > > > I have installed sssd in a RHEL5 client. > > > > ipa-client/sssd version: > > ipa-client-2.1.3-7.el5 > > sssd-client-1.5.1-71.el5 > > sssd-1.5.1-71.el5 > > > > sssd failed to get ipa user info with 'ldap_sasl_bind failed (-2)[Local error]'. > > > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/client02.stg.example.net > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (1): ldap_sasl_bind failed (-2)[Local error] > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (7): Waiting for child [11117]. > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (4): child [11117] finished successfully. > > > > I have tried to google to find root cause. some link explained it should be something wrong with dns. I have double confirmed it. > > > > # nslookup client02.stg.example.net > > Server: 10.2.1.21 > > Address: 10.2.1.21#53 > > > > Name: client02.stg.example.net > > Address: 10.2.3.32 > > > > > > # nslookup 10.2.3.32 > > Server: 10.2.1.21 > > Address: 10.2.1.21#53 > > > > 32.3.2.10.in-addr.arpa name = client02.stg.example.net. > > > > > > # nslookup ipaslave.stg.example.net > > Server: 10.2.1.21 > > Address: 10.2.1.21#53 > > > > Name: ipaslave.stg.example.net > > Address: 10.2.1.250 > > > > # nslookup 10.2.1.250 > > Server: 10.2.1.21 > > Address: 10.2.1.21#53 > > > > 250.1.2.10.in-addr.arpa name = ipaslave.stg.example.net. > > > > Any hints or troubleshooting ideas would be appreciated. > > > > Matrix > > > -- > > 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 pspacek at redhat.com Thu Nov 10 11:44:59 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 10 Nov 2016 12:44:59 +0100 Subject: [Freeipa-users] SRV (mixed?) records In-Reply-To: <4911d331-4f65-15ea-4433-7a838343df85@yahoo.co.uk> References: <67c28882-9666-b74e-a124-94761f34a078@redhat.com> <7f811a5f-8220-9472-b059-88bbc454a1d2@yahoo.co.uk> <01954171-fcac-885b-1a91-04852f07d20e@redhat.com> <7175c75c-9f16-86ae-e1c2-aba6825506b7@redhat.com> <93c10ec6-08d5-e943-6e09-fa2b1defccc3@yahoo.co.uk> <00de4a04-a55b-1154-8ae7-1e92fc90986a@redhat.com> <822f5ce5-524c-49f4-5eda-4a65a17f4a75@yahoo.co.uk> <7be13418-72c1-8ceb-be00-244f9c241913@redhat.com> <5cce48e6-8312-bdf1-a85e-feaec4dd2b31@yahoo.co.uk> <92fc5696-1468-c820-b947-46140bdf1f82@redhat.com> <4911d331-4f65-15ea-4433-7a838343df85@yahoo.co.uk> Message-ID: <0aa233be-00bf-83fb-e9f1-b7107745181a@redhat.com> On 10.11.2016 12:08, lejeczek wrote: > > > On 10/11/16 10:44, Petr Spacek wrote: >> This is non-standard situation so it asks for non-standard commands. >> >> I would try: >> $ ipa privilege-mod 'DNS Servers' >> --addattr=member=krbprincipalname=DNS/rider..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x' >> >> $ ipa privilege-mod 'DNS Servers' >> --addattr=member=krbprincipalname=ipa-dnskeysyncd/rider..xx.xx..xx.xx.x at .xx.xx..xx.xx.x,cn=services,cn=xxcounts,dc=,dc=xx,dc=xx,dc=,dc=xx,dc=xx,dc=x' >> >> >> Be very careful when constructing these DNs, --addattr do not validate the >> input! > > well, I realize these can be trivial trifles, but man, you saved the... week! > And to finish (hopefully) - maybe even more of a puzzle: how it happened? > This box member was fine, suddenly (I was recovering/reconnecting replication > agreements), maybe not suddenly, but when I noticed at some point, it did > that. It lost those ldap bits? Good question! I really do not know. You may dig into /var/log/dirsrv/* and look for modifications in the privilege LDAP entry but that is the only advice I have. Please let us know if you found out how it happened. -- Petr^2 Spacek From jamesaharrisonuk at yahoo.co.uk Thu Nov 10 12:00:10 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Thu, 10 Nov 2016 12:00:10 +0000 (UTC) Subject: [Freeipa-users] Specify different ssh port for ipa-conncheck References: <934372659.2113411.1478779210721.ref@mail.yahoo.com> Message-ID: <934372659.2113411.1478779210721@mail.yahoo.com> Hi All,We use port 2234 for all sshd connections on our systems. It looks loke ipa-conncheck uses port 22. Can this be changed to use 2234? This would be for replicas and clients I presume. This is quite urgent. Many thanks,James Harrison -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesaharrisonuk at yahoo.co.uk Thu Nov 10 12:12:15 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Thu, 10 Nov 2016 12:12:15 +0000 (UTC) Subject: [Freeipa-users] Specify different ssh port for ipa-conncheck In-Reply-To: <934372659.2113411.1478779210721@mail.yahoo.com> References: <934372659.2113411.1478779210721.ref@mail.yahoo.com> <934372659.2113411.1478779210721@mail.yahoo.com> Message-ID: <2050156004.2099650.1478779935937@mail.yahoo.com> We get the below message for replica machines and Ive seen it for client machines too: [root at pul-lv-ipa-02 bin]# /root/bin/freeipa-replica-install.sh /var/lib/ipa/replica-info-$(hostname -f).gpg Using reverse zone(s) 23.10.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'aaaaaa.aaaa.com ': ?? Directory Service: Unsecure port (389): OK ?? Directory Service: Secure port (636): OK ?? Kerberos KDC: TCP (88): OK ?? Kerberos Kpasswd: TCP (464): OK ?? HTTP Server: Unsecure port (80): OK ?? HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: ?? Kerberos KDC: UDP (88): SKIPPED ?? Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master Check SSH connection to remote master Could not SSH into remote host. Error output: ??? OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 ??? debug1: Reading configuration data /etc/ssh/ssh_config ??? debug1: /etc/ssh/ssh_config line 56: Applying options for * ??? debug1: Connecting to aaaaaa.aaaa.com [10.23.45.88] port 22. ??? debug1: connect to address 10.23.45.88 port 22: Connection refused ??? ssh: connect to host pul-lv-ipa-01.int.worldfirst.com port 22: Connection refused Could not SSH to remote host. ipa.ipapython.install.cli.install_tool(Replica): ERROR??? 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. From: James Harrison To: "freeipa-users at redhat.com" Sent: Thursday, 10 November 2016, 12:00 Subject: Specify different ssh port for ipa-conncheck Hi All,We use port 2234 for all sshd connections on our systems. It looks loke ipa-conncheck uses port 22. Can this be changed to use 2234? This would be for replicas and clients I presume. This is quite urgent. Many thanks,James Harrison -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Nov 10 12:15:31 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 10 Nov 2016 13:15:31 +0100 Subject: [Freeipa-users] Specify different ssh port for ipa-conncheck In-Reply-To: <934372659.2113411.1478779210721@mail.yahoo.com> References: <934372659.2113411.1478779210721.ref@mail.yahoo.com> <934372659.2113411.1478779210721@mail.yahoo.com> Message-ID: <9a432887-3550-89b6-c27f-4d4134ab0d1f@redhat.com> On 10.11.2016 13:00, James Harrison wrote: > Hi All, > We use port 2234 for all sshd connections on our systems. > > It looks loke ipa-conncheck uses port 22. > > Can this be changed to use 2234? This would be for replicas and > clients I presume. > > This is quite urgent. > > Many thanks, > James Harrison > > > > Hello, maybe is possible to use local ssh config and manually set port per host http://nerderati.com/2011/03/17/simplify-your-life-with-an-ssh-config-file/ if not then it is not possible to change SSH port without changing ipa-conncheck code You didn't specify version of IPA, so in master git branch related code is in ipa-replica-conncheck, class SshExec.__call__ Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sambitnayak at gmail.com Thu Nov 10 15:23:39 2016 From: sambitnayak at gmail.com (Sambit Nayak) Date: Thu, 10 Nov 2016 20:53:39 +0530 Subject: [Freeipa-users] Fwd: Deployment query In-Reply-To: References: Message-ID: Hi everyone, Requesting answers to some queries regarding FreeIPA deployment. Here is a short description of the deployment scenario. User/group identities are present in multiple identity/authentication sources - such as Windows AD, LDAP/Kerberos. The identity source servers - such as Windows AD Domain Controller - could be in multiple data centers across WAN/internet. Goal is to make a set of Linux (client) hosts access and authenticate such identities. The Linux client hosts could be in a separate data center from one or more such identity sources. Will a SSSD/FreeIPA based deployment work here? - Set up a FreeIPA server (and possibly replicas) in the Linux hosts data center, and set up the Linux hosts to use SSSD and be enrolled in the FreeIPA realm - Set up cross-forest trusts between FreeIPA and (one or more) Windows AD forests. - If FreeIPA server and Windows AD domain controllers have their system clock synchronized (NTP or otherwise), then would it work even though for some reason, the local time zone on the servers have been configured differently? For instance, local time zone on FreeIPA server is America/New_York and that on Windows AD DC is in Europe/London, but their system clock are set to UTC. I understand its better to have servers always set their clock set to UTC, but still just to be sure, hence asking. Plus, this FreeIPA webpage says time zone settings on FreeIPA and WindowsAD must be same : https://www.freeipa.org/page/Active_Directory_trust_setup# Date.2Ftime_settings > Date/time settings > > Make sure both timezone settings and date/time settings on both servers match. And yes, system clock on Linux client hosts running SSSD will also be same as on FreeIPA server. - SSSD on FreeIPA-enrolled Linux hosts can identify/authenticate identities from Windows AD through FreeIPA trust. But what about identities in other stores - like simple LDAP, or another Kerberos realm? Can FreeIPA act as a "single channel" to all Linux SSSD client hosts for such identities, or does SSSD on the individual Linux hosts have to directly interact with the non-Windows AD identity sources? I read some information that FreeIPA server itself can have "trust" with Windows AD realms only as of now, hence asking... - Regarding connectivity between FreeIPA server (and/or SSSD Linux client hosts) and the identity source servers (Windows AD DC, etc.), it will be through something like VPN over WAN/internet. Will that be advisable? Thanks & Regards, Sambit -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnstong at westmancom.com Thu Nov 10 15:55:14 2016 From: johnstong at westmancom.com (Graham Johnston) Date: Thu, 10 Nov 2016 15:55:14 +0000 Subject: [Freeipa-users] Certificate renewal - not the CA though Message-ID: <82C0CE81789FE64D8F4D1526319182971179D1F1@MSG6.westman.int> Hi, We are just about to come up on two years of having our freeipa instance in place. We are running version 4.2 on CentOS 7.2. We are using the internal/default CA configuration from the install. Our monitoring system just notified me that the server certificate used when accessing the admin web portal will expire in December. I can't seem to find information about whether this cert just auto renews in the background somehow or not. I can see lots of information about CA renewal but as my CA is not set to expire until 2022 I'm not worried about that. Can someone put my mind at ease, or point me to the documentation I can't seem to find. Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong at westmancom.com P think green; don't print this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Nov 10 16:29:20 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 10 Nov 2016 11:29:20 -0500 Subject: [Freeipa-users] Certificate renewal - not the CA though In-Reply-To: <82C0CE81789FE64D8F4D1526319182971179D1F1@MSG6.westman.int> References: <82C0CE81789FE64D8F4D1526319182971179D1F1@MSG6.westman.int> Message-ID: <5824A060.70505@redhat.com> Graham Johnston wrote: > Hi, > > > > We are just about to come up on two years of having our freeipa instance > in place. We are running version 4.2 on CentOS 7.2. We are using the > internal/default CA configuration from the install. > > > > Our monitoring system just notified me that the server certificate used > when accessing the admin web portal will expire in December. I can?t > seem to find information about whether this cert just auto renews in the > background somehow or not. I can see lots of information about CA > renewal but as my CA is not set to expire until 2022 I?m not worried > about that. The CA has a number of subsystems that also have certificates that will likely be expiring in December as well. Run getcert list to see them all. > Can someone put my mind at ease, or point me to the documentation I > can?t seem to find. certmonger _should_ renew them automatically for you. To force a renewal attempt the easiest thing to do is to restart the certmonger process. It may be close enough to renewal time that it'll just go ahead and try. Watch the status in getcert list. rob From peljasz at yahoo.co.uk Thu Nov 10 17:00:27 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 10 Nov 2016 17:00:27 +0000 Subject: [Freeipa-users] slapi_ldap_bind - Error: could not bind id .... Message-ID: <46eda631-1632-1b0b-c719-413da1c83682@yahoo.co.uk> hello you IPA addicts.. with a hope driven by previous (extremely) positive experience I'd like to ask for some help with: [10/Nov/2016:16:54:53 +0000] slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-swir.xx.xx.xx.xx.x-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) this is one server (out of four) that logs it. I thinks it has to do with replication? This entry gets logged ~every few minutes. Servers seems to work, but how to look for some more obvious symptoms of something being wrong/broken? many thanks. L From pvoborni at redhat.com Thu Nov 10 17:35:09 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 10 Nov 2016 18:35:09 +0100 Subject: [Freeipa-users] IDM server doesn't boot after update to RHEL 7.3 In-Reply-To: References: Message-ID: On 11/09/2016 12:53 PM, Prasun Gera wrote: > It looks like something is messed up in the systemd configuration after 7.3. My > system doesn't boot at all. The boot screen would display the message: "Failed > to register match for Disconnected message: Connection timed out". After some > trial and error, I've managed to boot it. Here's what works right now: 1) Boot > into system rescue target with debug shell 2) start sssd 3) isolate graphical.target > > I have a replica which I haven't upgraded to 7.3 yet. So I can compare the two > systems to isolate the problem. > I'm afraid that without more info(messages/journal) nobody will be able to help. But based on the description it seems that it didn't even get to step where IPA is started. -- Petr Vobornik From pvoborni at redhat.com Thu Nov 10 17:40:46 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 10 Nov 2016 18:40:46 +0100 Subject: [Freeipa-users] Package naming conflicts with update to RHEL 7.3 In-Reply-To: References: Message-ID: <716aac5c-d2d5-bb03-6cb5-0ad3db203dce@redhat.com> On 11/09/2016 12:43 PM, Prasun Gera wrote: > Thanks Martin. That bug report is private. Fixed, it's public now. > I take it that it's not very serious ? Should not affect IPA functionality. > > On Mon, Nov 7, 2016 at 3:12 AM, Martin Babinsky > wrote: > > On 11/07/2016 01:31 AM, Prasun Gera wrote: > > Getting this in yum check all after update to 7.3 > > ipa-client-4.4.0-12.el7.x86_64 has installed conflicts freeipa-client: > ipa-client-4.4.0-12.el7.x86_64 > ipa-client-common-4.4.0-12.el7.noarch has installed conflicts > freeipa-client-common: ipa-client-common-4.4.0-12.el7.noarch > ipa-common-4.4.0-12.el7.noarch has installed conflicts freeipa-common: > ipa-common-4.4.0-12.el7.noarch > ipa-python-compat-4.4.0-12.el7.noarch has installed conflicts > freeipa-python-compat: ipa-python-compat-4.4.0-12.el7.noarch > > > > > Hi Prasun, > > That is a false positive caused by a bug in yum, see > https://bugzilla.redhat.com/show_bug.cgi?id=1370134 > > > -- > Martin^3 Babinsky > > -- > 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 > > > > -- Petr Vobornik From pvoborni at redhat.com Thu Nov 10 17:48:49 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 10 Nov 2016 18:48:49 +0100 Subject: [Freeipa-users] guidance and strategies for supporting production use including dev/test IPA systems? In-Reply-To: <58232728.1010202@sonsorol.org> References: <58232728.1010202@sonsorol.org> Message-ID: On 11/09/2016 02:39 PM, Chris Dagdigian wrote: > > Thanks to support from folks on this list I have a 3-node multi-site > replicating FreeIPA system supporting a number of 1-way trusts to > various AD Forests. Testing has gone well and it's clear that this "POC" > will soon transition to production. > > Because of the importance of this system to our environment I'm trying > to flesh out a proper strategy for testing upgrades and updates in a way > that lets us keep our system highly available and online. > > And seeing how rapidly this software is being developed w/ new features > and how dependent we are on the most recent version (or how badly I want > to try the version in RHEL-BETA-3) I think this is a system we will > possibly be upgrading somewhat often ... > > I understand that replicas can run newer versions of IPA/IDM than the > master so that is one path by which we can carefully test updates and > patches but I don't think that covers all the scenarios ... But be careful how much you want to test using this method. Setting up a new replica in prod environment should not be used as a playground. Usually new version of IPA modify some existing data in LDAP - schema change, add of some value here and there to support new features. Since IPA use master-master replication then all these changes are replicated to all other replicas(the older ones). It is fine because the changes are backwards compatible but they cannot be undone by removing the new replica. > > Can anyone share strategies or war stories for how testing is done in > support of production IPA/IDM environments? Especially when Trusts need > to be set up with many external AD systems? > > Do people run discrete standalone dev/test IPA domains/realms to create > isolated environments or is there some other good strategy that allows > testing to be done within the same domain/realm? > > Thanks! > > -Chris > -- Petr Vobornik From prasun.gera at gmail.com Thu Nov 10 17:53:33 2016 From: prasun.gera at gmail.com (Prasun Gera) Date: Thu, 10 Nov 2016 12:53:33 -0500 Subject: [Freeipa-users] IDM server doesn't boot after update to RHEL 7.3 In-Reply-To: References: Message-ID: Yes, from my experiments, it gets stuck at some point where it has to start avahi. And it fails to start it because it is dependent on something that is not started yet (which is started when sssd is started). Googling for that error pointed took me to http://www.calculate-linux.org/boards/15/topics/26673, which seems to be somewhat related I think. I'll post the journal messages soon. Is there some sort of a systemd diff utility which can compare the start sequence of services from two different systems ? Since my replica is on 7.2, which afaik works fine, doing a diff between the two might highlight if something has changed in the start sequence. On Thu, Nov 10, 2016 at 12:35 PM, Petr Vobornik wrote: > On 11/09/2016 12:53 PM, Prasun Gera wrote: > > It looks like something is messed up in the systemd configuration after > 7.3. My > > system doesn't boot at all. The boot screen would display the message: > "Failed > > to register match for Disconnected message: Connection timed out". After > some > > trial and error, I've managed to boot it. Here's what works right now: > 1) Boot > > into system rescue target with debug shell 2) start sssd 3) isolate > graphical.target > > > > I have a replica which I haven't upgraded to 7.3 yet. So I can compare > the two > > systems to isolate the problem. > > > > I'm afraid that without more info(messages/journal) nobody will be able > to help. > > But based on the description it seems that it didn't even get to step > where IPA is started. > > -- > Petr Vobornik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesaharrisonuk at yahoo.co.uk Thu Nov 10 18:59:09 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Thu, 10 Nov 2016 18:59:09 +0000 (UTC) Subject: [Freeipa-users] Specify different ssh port for ipa-conncheck In-Reply-To: <9a432887-3550-89b6-c27f-4d4134ab0d1f@redhat.com> References: <934372659.2113411.1478779210721.ref@mail.yahoo.com> <934372659.2113411.1478779210721@mail.yahoo.com> <9a432887-3550-89b6-c27f-4d4134ab0d1f@redhat.com> Message-ID: <1839022181.2713161.1478804349185@mail.yahoo.com> Hello.Thanks for your help Martin that worked. James Harrison? On Thu, 10 Nov, 2016 at 12:15, Martin Basti wrote: On 10.11.2016 13:00, James Harrison wrote: Hi All, We use port 2234 for all sshd connections on our systems. It looks loke ipa-conncheck uses port 22. Can this be changed to use 2234? This would be for replicas and clients I presume. This is quite urgent. Many thanks, James Harrison Hello, maybe is possible to use local ssh config and manually set port per host http://nerderati.com/2011/03/17/simplify-your-life-with-an-ssh-config-file/ if not then it is not possible to change SSH port without changing ipa-conncheck code You didn't specify version of IPA, so in master git branch related code is in ipa-replica-conncheck, class SshExec.__call__ Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvomacka at redhat.com Fri Nov 11 09:31:33 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Fri, 11 Nov 2016 10:31:33 +0100 Subject: [Freeipa-users] Setting "preserve" as default action when deleting in webUI In-Reply-To: <173ca750-3c99-0d7b-b23b-dc7f402596bc@ljll.math.upmc.fr> References: <5f607850-9623-254e-1609-02fd922117c0@ljll.math.upmc.fr> <4b88fa7e-4df2-ba82-0591-94f8ac37ac59@redhat.com> <55650f44-97f4-b3e0-9907-7521a2f886ca@redhat.com> <173ca750-3c99-0d7b-b23b-dc7f402596bc@ljll.math.upmc.fr> Message-ID: Hello Sebastien, It's really weird, I tried it again using exactly the same code as you sent earlier and it works. Just for information which version of FreeIPA do you use? It should not be a problem, but I really can't find anything bad in your solution. On 11/09/2016 05:12 PM, S?bastien Julliot wrote: > Hello Pavel, > > > Yes I did. "PRESERVE.JS WAS EXECUTED" is printed in my browser's > console, and yet "delete" ("supprimer", in French) is still the > default. (as you can see in linked image) > > > Le 31/10/2016 ? 16:18, Pavel Vomacka a ?crit : >> Hello Sebastien, >> >> I tried your plugin and it works correctly. Default value is Preserve >> with your plugin. Did you copy your plugin into >> /var/share/ipa/ui/js/plugins/plugin_name/plugin_name.js ? That should >> be enough. >> >> >> On 10/28/2016 12:14 AM, Sebastien Julliot wrote: >>> Hello guys, >>> >>> >>> Thank you for your answers. First, I was able to modify the minified js >>> to change the default. Ugly solution, but it works for now. >>> >>> I am trying to write a plugin but it seems that I missed something here >>> since, despite being executed, the default is not changed .. >>> >>> Here is my code, freely inspired of what I think I understood of your >>> 'association_search_fix.js' example: >>> >>> define([ >>> >>> 'freeipa/ipa', >>> >>> 'freeipa/user', >>> >>> ], >>> >>> function(IPA, user) { >>> >>> exp = {}; >>> >>> >>> exp.orig_create_active_user_del_dialog = >>> IPA.user.create_active_user_del_dialog; >>> >>> IPA.user.create_active_user_del_dialog = function(dialog) { >>> >>> dialog.deleter_dialog_create_content(); >>> >>> dialog.option_layout = IPA.fluid_layout({ >>> >>> label_cls: 'col-sm-3', >>> >>> widget_cls: 'col-sm-9' >>> >>> }); >>> >>> dialog.option_radio = IPA.radio_widget({ >>> >>> name: 'preserve', >>> >>> label: '@i18n:objects.user.delete_mode', >>> >>> options: [ >>> >>> { label: '@i18n:objects.user.mode_delete', value: >>> 'false' }, >>> >>> { label: '@i18n:objects.user.mode_preserve', value: >>> 'true' } >>> >>> ], >>> >>> default_value: 'true' >>> >>> }); >>> >>> var html = dialog.option_layout.create([dialog.option_radio]); >>> >>> dialog.container.append(html); >>> >>> dialog.option_radio.set_value(['']); >>> >>> return dialog; >>> >>> }; >>> >>> //exp.orig_create_active_user_del_dialog = >>> IPA.user.create_active_user_del_dialog; >>> >>> console.log('PRESERVE.JS WAS EXECUTED'); >>> >>> return exp; >>> >>> }); >>> >>> I checked that disabling the comment or not does not change anything. >>> >>> >>> Can you see what I missed here ? >>> >>> >>> Thanks a lot, >>> >>> Sebastien Julliot. >>> >>> -- Pavel^3 Vomacka From jpazdziora at redhat.com Fri Nov 11 09:52:22 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 11 Nov 2016 10:52:22 +0100 Subject: [Freeipa-users] What is the use of /etc/krb5.conf? In-Reply-To: <1065494049.632733.1478621585379@mail.yahoo.com> References: <1065494049.632733.1478621585379.ref@mail.yahoo.com> <1065494049.632733.1478621585379@mail.yahoo.com> Message-ID: <20161111095222.GT560@redhat.com> On Tue, Nov 08, 2016 at 04:13:05PM +0000, Ask Stack wrote: > I thought /etc/krb5.conf controls which kerberos server the clients talk to. It can do that but the libraries can also get the information from DNS, which is what it does when you don't have krb5.conf and try to kinit. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From deepak_dimri at hotmail.com Sun Nov 13 15:33:52 2016 From: deepak_dimri at hotmail.com (Deepak Dimri) Date: Sun, 13 Nov 2016 15:33:52 +0000 Subject: [Freeipa-users] URL is changing on the browser Message-ID: Hi All, I have my IPA servers hosted in the AWS private subnets and i can access them using AWS elb URL from public internet just fine. The problem is that when i enter https:///index.htl (dummy index.html hosted on IPA) i can access index.html just fine but when i try https:///ipa/ui then i am getting redirected to https:///ipa/ui which is resulting to "This site can't be reached" error. What should i be doing to access IPA server(s) uri when they running behind the load balancer or proxy servers? Thanks for your great support! Best regards Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhenglei at kylinos.cn Mon Nov 14 03:09:46 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Mon, 14 Nov 2016 11:09:46 +0800 Subject: [Freeipa-users] How to verify user with proxy server Message-ID: Hello everyone, I had already successfully verified user with otp. But I don't know how to verify user with proxy server, is there anyone know about it? There is no a complete solution on the website. Thanks! ------------------ ?? ?????????? -------------------------- ?????? ?? ???18684703229 ???zhenglei at kylinos.cn ??????????????? ?????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak_dimri at hotmail.com Mon Nov 14 06:23:29 2016 From: deepak_dimri at hotmail.com (Deepak Dimri) Date: Mon, 14 Nov 2016 06:23:29 +0000 Subject: [Freeipa-users] IPA UI not working behind Load Balancer Message-ID: Hi All, I have my IPA servers hosted in the AWS private subnets and i can access them using AWS elb URL from public internet just fine. The problem is that when i enter https:///index.htl (dummy index.html hosted on IPA) i can access index.html just fine but when i try https:///ipa/ui then i am getting redirected to [https:///ipa/ui]https:///ipa/ui which is resulting to "This site can't be reached" error. I followed this link https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name but it did not help either.. What should i be doing to access IPA server(s) uri when they running behind the load balancer or proxy servers? Thanks for your great support! Best regards Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.dimri2016 at gmail.com Mon Nov 14 06:52:44 2016 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Mon, 14 Nov 2016 12:22:44 +0530 Subject: [Freeipa-users] IPA UI not accessible behind the load blancer Message-ID: Hi All, I have my IPA servers hosted in the AWS private subnets and i can access them using AWS elastic load balancer(elb) URL from public internet just fine. The problem is that when i enter https:///index.htl (dummy index.html hosted on IPA) i can access index.html just fine but when i try https:///ipa/ui then i am getting redirected to [https:// /ipa/ui]https:///ipa/ui which is resulting to "This site can't be reached" error. I followed this link https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name but it did not help either.. What should i be doing to access IPA server(s) uri when they running behind the load balancer or proxy servers? Thanks for your great support! Best regards Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From artemiev at itsirius.su Mon Nov 14 07:27:32 2016 From: artemiev at itsirius.su (artemiev at itsirius.su) Date: Mon, 14 Nov 2016 11:27:32 +0400 (MSK) Subject: [Freeipa-users] =?utf-8?b?0KHQvtC30LTQsNC9INC/0YDQvtGE0LjQu9GM?= =?utf-8?b?INC+0LHRidC10LPQviDQtNC+0YHRgtGD0L/QsDogZnJpcGEg0L/RgNC10LQ=?= =?utf-8?b?0L7RgdGC0LDQstC70LXQvdC+INCyINC+0LHRidC40Lkg0LTQvtGB0YLRg9C/?= =?utf-8?b?INC/0L7Qu9GM0LfQvtCy0LDRgtC10LvQtdC8IGFydGVtaWV2QGl0c2lyaXVz?= =?utf-8?b?LnN1?= Message-ID: <800002375.20887.1479108452105.JavaMail.zimbra@itsirius.su> artemiev at itsirius.su ??????(?) ?????? ? ?fripa? ??? freeipa-users at redhat.com ????? ???????: fripa (????? ?????) ????????: artemiev at itsirius.su ??????????: freeipa-users at redhat.com ????: ??????????? ??????????? ????????: ??? ???????? ?????, ????? ??????? ????? ??????: https://zimbra.itsirius.su:443/service/extuserprov/?p=0_83f4e93bbf121a2a02814c7f3d7965c6be279122_6169643d33363a66376137346230342d343166312d346133352d623163612d3735353565306437353832613b6669643d333a3337363b656d61696c3d32343a667265656970612d7573657273407265646861742e636f6d3b. ?? ?????? ?????????? ?? ???????? ?????, ??? ??? ??????? ? ????? ?????? ???????? ????? ?????????? ??????? ???????????? ??? ? ??????. ???? ?? ??? ??????? ????? ??????, ???????? ????? ??? ????? ? ???? ??????? ??????: https://zimbra.itsirius.su:443?virtualacctdomain=itsirius.su *~*~*~*~*~*~*~*~*~* -------------- next part -------------- An HTML attachment was scrubbed... URL: From artemiev at itsirius.su Mon Nov 14 07:33:13 2016 From: artemiev at itsirius.su (artemiev at itsirius.su) Date: Mon, 14 Nov 2016 11:33:13 +0400 (MSK) Subject: [Freeipa-users] =?utf-8?b?0J7RgtC80LXQvdC10L0g0L/RgNC+0YTQuNC7?= =?utf-8?b?0Ywg0L7QsdGJ0LXQs9C+INC00L7RgdGC0YPQv9CwOiBmcmlwYSDQvtC/0YM=?= =?utf-8?b?0LHQu9C40LrQvtCy0LDQvdC+OiBhcnRlbWlldkBpdHNpcml1cy5zdQ==?= Message-ID: <1924448751.20920.1479108793726.JavaMail.zimbra@itsirius.su> ??????? ????????? ??????? ?????? ???????: fripa ---------------------------------------------- ????? ???????: fripa (????? ?????) ????????: artemiev at itsirius.su ? ????: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: xml/x-zimbra-share Size: 344 bytes Desc: not available URL: From mbasti at redhat.com Mon Nov 14 07:49:34 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 14 Nov 2016 08:49:34 +0100 Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: References: Message-ID: On 13.11.2016 16:33, Deepak Dimri wrote: > > Hi All, > > > I have my IPA servers hosted in the AWS private subnets and i can > access them using AWS elb URL from public internet just fine. The > problem is that when i enter https:///index.htl (dummy > index.html hosted on IPA) i can access index.html just fine but when > i try https:///ipa/ui then i am getting redirected to > https:///ipa/ui > which is resulting to > "This site can't be reached" error. > > > What should i be doing to access IPA server(s) uri when they running > behind the load balancer or proxy servers? > > > Thanks for your great support! > > > Best regards > > Deepak > > > > Hello, this may help you https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at 0xc0dedbad.com Mon Nov 14 08:38:22 2016 From: freeipa at 0xc0dedbad.com (Peter Fern) Date: Mon, 14 Nov 2016 19:38:22 +1100 Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: References: Message-ID: <74505d62-357e-0dcb-2ab5-ae0f0c2d575c@0xc0dedbad.com> On 14/11/16 18:49, Martin Basti wrote: > Hello, > > this may help you > > https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name > https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy > > I'd be interested to hear from anyone who has a working recipe for HA/load-balancing (with HAProxy preferably). Cookie rewriting is doable, but I can't see a way to rewrite the referrer for multiple backend hosts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From th at casalogic.dk Mon Nov 14 09:39:30 2016 From: th at casalogic.dk (Troels Hansen) Date: Mon, 14 Nov 2016 10:39:30 +0100 (CET) Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: <74505d62-357e-0dcb-2ab5-ae0f0c2d575c@0xc0dedbad.com> References: <74505d62-357e-0dcb-2ab5-ae0f0c2d575c@0xc0dedbad.com> Message-ID: <23084521.863767.1479116370701.JavaMail.zimbra@casalogic.dk> ----- On Nov 14, 2016, at 9:38 AM, Peter Fern wrote: > I'd be interested to hear from anyone who has a working recipe for > HA/load-balancing (with HAProxy preferably). Cookie rewriting is doable, but I > can't see a way to rewrite the referrer for multiple backend hosts. One (quite hack-ish) way of doing it could be: 2 apache vhosts, one pointing to one IPA server, set up like https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name SSLProxyEngine on ProxyPass / https://ipa.int.example.com/ ProxyPassReverse / https://ipa.int.example.com/ ProxyPassReverseCookieDomain ipa.int.example.com webipa.example.com RequestHeader edit Referer ^https://webipa\.example\.com/ https://ipa.int.example.com/ Then set up a second HA using HAproxy or Apache (with sticky session) pointing to the two Apache IPA vhosts. Thoug, not quite sure what will happen if you hit a down IPA server, but you should be able to configure that in the HA... -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.dimri2016 at gmail.com Mon Nov 14 10:09:57 2016 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Mon, 14 Nov 2016 15:39:57 +0530 Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: References: Message-ID: Hi Martin, Thank you so much for your reply. I am kinda stuck with this issue with no headway! I have AWS ELB pointing to my IPA Servers fine - basically ELB is allowing me to access IPA servers externally. As per the link you shared i need a front end proxy configured with mod_ssl does that i need to introduce a front end proxy in between ELB and IPA? i tried installing mod_ssl on the IPA Server itself and made the changes in ssl.conf as suggested in the link but that did not help. My setup is simple i want to access ipa/ui from my AWS ELB URL. really appreciate your support Best Regards, Deepak On Mon, Nov 14, 2016 at 1:19 PM, Martin Basti wrote: > > > On 13.11.2016 16:33, Deepak Dimri wrote: > > Hi All, > > > I have my IPA servers hosted in the AWS private subnets and i can access > them using AWS elb URL from public internet just fine. The problem is that > when i enter https:///index.htl (dummy index.html hosted on IPA) i > can access index.html just fine but when i try https:///ipa/ui then > i am getting redirected to https:///ipa/ui which > is resulting to "This site can't be reached" error. > > > What should i be doing to access IPA server(s) uri when they running > behind the load balancer or proxy servers? > > > Thanks for your great support! > > > Best regards > > Deepak > > > > > Hello, > > this may help you > > https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name > https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy > > -- > 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 freeipa at 0xc0dedbad.com Mon Nov 14 10:11:15 2016 From: freeipa at 0xc0dedbad.com (Peter Fern) Date: Mon, 14 Nov 2016 21:11:15 +1100 Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: <23084521.863767.1479116370701.JavaMail.zimbra@casalogic.dk> References: <74505d62-357e-0dcb-2ab5-ae0f0c2d575c@0xc0dedbad.com> <23084521.863767.1479116370701.JavaMail.zimbra@casalogic.dk> Message-ID: <503e2524-3781-f41a-976f-d26860668cc9@0xc0dedbad.com> On 14/11/16 20:39, Troels Hansen wrote: > > > ----- On Nov 14, 2016, at 9:38 AM, Peter Fern > wrote: > > > I'd be interested to hear from anyone who has a working recipe for > HA/load-balancing (with HAProxy preferably). Cookie rewriting is > doable, but I can't see a way to rewrite the referrer for multiple > backend hosts. > > > One (quite hack-ish) way of doing it could be: > 2 apache vhosts, one pointing to one IPA server, set up like > https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name > > SSLProxyEngine on > ProxyPass / https://ipa.int.example.com/ > ProxyPassReverse / https://ipa.int.example.com/ > ProxyPassReverseCookieDomain ipa.int.example.com webipa.example.com > RequestHeader edit Referer ^https://webipa\.example\.com/ https://ipa.int.example.com/ > > Then set up a second HA using HAproxy or Apache (with sticky session) > pointing to the two Apache IPA vhosts. > Thoug, not quite sure what will happen if you hit a down IPA server, > but you should be able to configure that in the HA... Ah, good thought - I hadn't considered hacking the referrer on the Apache side. I used only the RequestHeader edit on the Apache server for each IPA server, since it can co-exist with direct access, and did the cookie rewriting on the HAProxy side, since that should only happen when accessed via the balancer. Appears to be working with some quick testing. Below is my HAProxy backend, in case it helps someone: backend ipa-ssl # Rewrite cookie domain acl ipa1_int_cookie_dom res.hdr(Set-cookie) -m sub Domain=ipa1.int.example.com rspirep ^(Set-Cookie:.*)\ Domain=ipa1.int.example.com(.*) \1\ Domain=ipa.example.com\2 if ipa1_int_cookie_dom acl ipa2_int_cookie_dom res.hdr(Set-cookie) -m sub Domain=ipa2.int.example.com rspirep ^(Set-Cookie:.*)\ Domain=ipa2.int.example.com(.*) \1\ Domain=ipa.example.com\2 if ipa2_int_cookie_dom # Sticky sessions cookie ipa_session prefix nocache server ipa1 ipa1.int.example.com:443 check cookie ipa1 ssl ca-file /etc/ipa/ca.crt server ipa2 ipa2.int.example.com:443 check cookie ipa2 ssl ca-file /etc/ipa/ca.crt -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon Nov 14 11:00:57 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 14 Nov 2016 12:00:57 +0100 Subject: [Freeipa-users] IPA UI not accessible behind the load blancer In-Reply-To: References: Message-ID: <30ce363e-12c3-5393-8379-1790d1d0d2e8@redhat.com> On 11/14/2016 07:52 AM, deepak dimri wrote: > Hi All, > > > I have my IPA servers hosted in the AWS private subnets and i can access them > using AWS elastic load balancer(elb) URL from public internet just fine. The > problem is that when i enter https:///index.htl (dummy index.html hosted > on IPA) i can access index.html just fine but when i try > https:///ipa/ui then i am getting redirected to > [https:///ipa/ui]https:///ipa/ui > which is resulting to "This site can't be reached" error. > > > I followed this link > https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name but it > did not help either.. > > > What should i be doing to access IPA server(s) uri when they running behind the > load balancer or proxy servers? > > > Thanks for your great support! > > > Best regards > > Deepak > Look into /etc/httpd/conf.d/ipa-rewrite.conf There are lines: # By default forward all requests to /ipa. If you don't want IPA # to be the default on your web server comment this line out. ${AUTOREDIR}RewriteRule ^/$$ https://$FQDN/ipa/ui [L,NC,R=301] # Redirect to the fully-qualified hostname. Not redirecting to secure # port so configuration files can be retrieved without requiring SSL. RewriteCond %{HTTP_HOST} !^$FQDN$$ [NC] RewriteRule ^/ipa/(.*) http://$FQDN/ipa/$$1 [L,R=301] Which most likely causes the redirection. -- Petr Vobornik From pvoborni at redhat.com Mon Nov 14 11:08:12 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 14 Nov 2016 12:08:12 +0100 Subject: [Freeipa-users] How to verify user with proxy server In-Reply-To: References: Message-ID: <04320952-158c-2f2b-e2d6-07bc9740e04c@redhat.com> On 11/14/2016 04:09 AM, ?? wrote: > Hello everyone, > > I had already successfully verified user with otp. But I don't know how to > verify user with proxy server, is there anyone know about it? There is no a > complete solution on the website. > > Thanks! > Could you describe your use case in more details? If you are asking about how to access IPA behind proxy, then checkout: https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy Or other proxy threads on this list. -- Petr Vobornik From jpazdziora at redhat.com Mon Nov 14 12:26:01 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 14 Nov 2016 13:26:01 +0100 Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: References: Message-ID: <20161114122601.GJ560@redhat.com> On Mon, Nov 14, 2016 at 08:49:34AM +0100, Martin Basti wrote: > On 13.11.2016 16:33, Deepak Dimri wrote: > > > > I have my IPA servers hosted in the AWS private subnets and i can access > > them using AWS elb URL from public internet just fine. The problem is > > that when i enter https:///index.htl (dummy index.html hosted on > > IPA) i can access index.html just fine but when i try > > https:///ipa/ui then i am getting redirected to > > https:///ipa/ui > > which is resulting to > > "This site can't be reached" error. > > > > What should i be doing to access IPA server(s) uri when they running > > behind the load balancer or proxy servers? > > this may help you > > https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name > https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy For the AWS case, wouldn't it be easier to just have the IPA server use the public hostname from the very beginning? You can always put appropriate records to /etc/hosts to shortcut the IPA->IPA traffic to never leave the machine. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From deepak_dimri at hotmail.com Mon Nov 14 18:20:28 2016 From: deepak_dimri at hotmail.com (Deepak Dimri) Date: Mon, 14 Nov 2016 18:20:28 +0000 Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: <20161114122601.GJ560@redhat.com> References: , <20161114122601.GJ560@redhat.com> Message-ID: we discussed the options internally and finally decided to host ipa within the private subnets - our security team wast too comfortable to expose ipa servers on to the public network. Sent from my iPhone > On 14-Nov-2016, at 17:56, Jan Pazdziora wrote: > >> On Mon, Nov 14, 2016 at 08:49:34AM +0100, Martin Basti wrote: >>> On 13.11.2016 16:33, Deepak Dimri wrote: >>> >>> I have my IPA servers hosted in the AWS private subnets and i can access >>> them using AWS elb URL from public internet just fine. The problem is >>> that when i enter https:///index.htl (dummy index.html hosted on >>> IPA) i can access index.html just fine but when i try >>> https:///ipa/ui then i am getting redirected to >>> https:///ipa/ui >>> which is resulting to >>> "This site can't be reached" error. >>> >>> What should i be doing to access IPA server(s) uri when they running >>> behind the load balancer or proxy servers? >> >> this may help you >> >> https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name >> https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy > > For the AWS case, wouldn't it be easier to just have the IPA server > use the public hostname from the very beginning? You can always put > appropriate records to /etc/hosts to shortcut the IPA->IPA traffic to > never leave the machine. > > -- > Jan Pazdziora > Senior Principal Software Engineer, Identity Management Engineering, Red Hat From dag at sonsorol.org Mon Nov 14 19:03:16 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Mon, 14 Nov 2016 14:03:16 -0500 Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: References: , <20161114122601.GJ560@redhat.com> Message-ID: <582A0A74.2030706@sonsorol.org> I'm still interested in this topic as our IPA servers are on private AWS subnets and it would be really nice to have an internal AWS ALB or ELB be the user-facing interface so we can route traffic between IPA systems and only "advertise" a single hostname for access. Plus it would be great to put the load balancer name into the various sssd.conf and krb5.conf client files since our internal DNS-based service discovery has some brittleness that is outside my control to fix. I played with this for a short time and hit the "IPA redirects to it's internal FQDN" problem as well. Now that this appears to be a somewhat simple tweak to the httpd.conf type files I may start playing around with putting private IPA systems behind a private AWS load balancer Chris Deepak Dimri wrote: > we discussed the options internally and finally decided to host ipa within the private subnets - our security team wast too comfortable to expose ipa servers on to the public network. From deepak_dimri at hotmail.com Tue Nov 15 01:11:55 2016 From: deepak_dimri at hotmail.com (Deepak Dimri) Date: Tue, 15 Nov 2016 01:11:55 +0000 Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: <582A0A74.2030706@sonsorol.org> References: , <20161114122601.GJ560@redhat.com> , <582A0A74.2030706@sonsorol.org> Message-ID: hi chris, i have the setup working fine with ELB -> apache reverse proxy on Fedora (public subnet) -> ipa (private subnet). i want to use ubuntu instead of Fedora for the reverse proxy and i am unable to make the reverse proxy works on unbuntu with all the configurations we need for ipa. it would be really nice if someone can shareb documented configurations steps for the ubuntu as well - simiar to the what is given in the link that martin had shared regards, deepak Sent from my iPhone > On 15-Nov-2016, at 00:33, Chris Dagdigian wrote: > > > I'm still interested in this topic as our IPA servers are on private AWS subnets and it would be really nice to have an internal AWS ALB or ELB be the user-facing interface so we can route traffic between IPA systems and only "advertise" a single hostname for access. Plus it would be great to put the load balancer name into the various sssd.conf and krb5.conf client files since our internal DNS-based service discovery has some brittleness that is outside my control to fix. > > I played with this for a short time and hit the "IPA redirects to it's internal FQDN" problem as well. Now that this appears to be a somewhat simple tweak to the httpd.conf type files I may start playing around with putting private IPA systems behind a private AWS load balancer > > Chris > > > > Deepak Dimri wrote: >> we discussed the options internally and finally decided to host ipa within the private subnets - our security team wast too comfortable to expose ipa servers on to the public network. > From zhenglei at kylinos.cn Tue Nov 15 08:38:41 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Tue, 15 Nov 2016 16:38:41 +0800 Subject: [Freeipa-users] How to verify user with proxy server In-Reply-To: <04320952-158c-2f2b-e2d6-07bc9740e04c@redhat.com> References: <04320952-158c-2f2b-e2d6-07bc9740e04c@redhat.com> Message-ID: Thanks for your reply. I may not have described clearly. My use case is that I have a freeipa user that uses password auth type by default, and I want to use radius auth tpye to verify user according to 3rd-party radius server. ------------------ ?? ?????????? -------------------------- ?????? ?? ???18684703229 ???zhenglei at kylinos.cn ??????????????? ?????????????????????? ------------------ Original ------------------ From: "Petr Vobornik"; Date: Mon, Nov 14, 2016 07:08 PM To: "??"; "freeipa-users"; Subject: Re: [Freeipa-users] How to verify user with proxy server On 11/14/2016 04:09 AM, ?? wrote: > Hello everyone, > > I had already successfully verified user with otp. But I don't know how to > verify user with proxy server, is there anyone know about it? There is no a > complete solution on the website. > > Thanks! > Could you describe your use case in more details? If you are asking about how to access IPA behind proxy, then checkout: https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy Or other proxy threads on this list. -- Petr Vobornik -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Nov 15 08:58:24 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 15 Nov 2016 09:58:24 +0100 Subject: [Freeipa-users] How to verify user with proxy server In-Reply-To: References: <04320952-158c-2f2b-e2d6-07bc9740e04c@redhat.com> Message-ID: On 11/15/2016 09:38 AM, ?? wrote: > Thanks for your reply. I may not have described clearly. My use case is that I > have a freeipa user that uses password auth type by default, and I want to use > radius auth tpye to verify user according to 3rd-party radius server. FreeIPA is able to use 3rd-pardy RADIUS server for authentication. This is covered in: * https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/otp.html#migrating-proprietary-otp * http://www.freeipa.org/page/V4/OTP > > > > > > ------------------ > ?? > ?????????? > -------------------------- > ?????? ?? > ???18684703229 > ???zhenglei at kylinos.cn > ??????????????? > ?????????????????????? > ------------------ Original ------------------ > *From: * "Petr Vobornik"; > *Date: * Mon, Nov 14, 2016 07:08 PM > *To: * "??"; "freeipa-users"; > *Subject: * Re: [Freeipa-users] How to verify user with proxy server > On 11/14/2016 04:09 AM, ?? wrote: > > Hello everyone, > > > > I had already successfully verified user with otp. But I don't know how to > > verify user with proxy server, is there anyone know about it? There is no a > > complete solution on the website. > > > > Thanks! > > > > Could you describe your use case in more details? > > If you are asking about how to access IPA behind proxy, then checkout: > https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name > https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy > > Or other proxy threads on this list. > -- > Petr Vobornik > -- Petr Vobornik From tba at statsbiblioteket.dk Tue Nov 15 12:17:43 2016 From: tba at statsbiblioteket.dk (Tony Brian Albers) Date: Tue, 15 Nov 2016 12:17:43 +0000 Subject: [Freeipa-users] krb5 and nfsv4 not working right Message-ID: <15fad8b4-38da-948d-5af6-813e2b926f09@statsbiblioteket.dk> Hi guys, I've followed every guide I can find on this subject. What I'm trying to is to get our home directories which are shared via NFS from the FreeIPA server mounted via autofs on the clients. The client is kact-man-001 and the FreeIPA server is kact-adm-001 /etc/exports: I've done the ipa-client-install and the ipa-client-automount However, when I log in, my homedir is mounted as expected but what I get in the messages log is: Nov 15 12:52:25 kact-man-001 gssproxy: gssproxy[770]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found A lot! /etc/krb5.conf is default from the FreeIPA installation: default_ccache_name = KEYRING:persistent:%{uid} The autofs setup looks like this: --------------------------------------------------------- [root at kact-adm-001 log]# ipa automountmap-find Location: default ------------------------ 3 automount maps matched ------------------------ Map: auto.direct Map: auto.home Map: auto.master ---------------------------- Number of entries returned 3 ---------------------------- [root at kact-adm-001 log]# [root at kact-adm-001 log]# ipa automountkey-find Location: default Map: auto.home ----------------------- 1 automount key matched ----------------------- Key: * Mount information: -fstype=nfs4,rw,sec=krb5,rsize=8192,wsize=8192 kact-adm-001.kact.sblokalnet:/data/home/& ---------------------------- Number of entries returned 1 ---------------------------- [root at kact-adm-001 log]# --------------------------------------------------------- Now, the BAD thing is, trying to copy a large file to the automounted dir on the client just hangs: [tba at pc588 images]$ scp NAS4Free-x64-LiveUSB-10.3.0.3.2987.img.gz tba-sb at kact-man-001.kact.sblokalnet:. tba-sb at kact-man-001.kact.sblokalnet's password: NAS4Free-x64-LiveUSB-10.3.0.3.2987.img.gz 100% 281MB 93.6MB/s 00:03 [hangs] And my logged in session on the client hangs if I try to do ls in my homedir: [tba at pc588 ~]$ ssh tba-sb at kact-man-001.kact.sblokalnet tba-sb at kact-man-001.kact.sblokalnet's password: Last login: Tue Nov 15 13:07:12 2016 from pc588.sb.statsbiblioteket.dk -sh-4.2$ -sh-4.2$ -sh-4.2$ pwd /home/tba-sb -sh-4.2$ hostname kact-man-001 -sh-4.2$ -sh-4.2$ ls [hangs] And I see a huge amount of the GSS failures in the messages file on the client. Any suggestions? TIA -- Best regards, Tony Albers Systems administrator, IT-development State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. Tel: +45 2566 2383 / +45 8946 2316 From Leo.Baltus at npo.nl Tue Nov 15 12:47:59 2016 From: Leo.Baltus at npo.nl (Leo Baltus) Date: Tue, 15 Nov 2016 13:47:59 +0100 Subject: [Freeipa-users] ipa-server-install & certificates Message-ID: <20161115124759.GA3346@omroep.nl> Hi, (first time user, firts post on this ML) I am setting up ipa-server on a fresh CentOS-7 system. After running: /usr/sbin/ipa-server-install -U --realm XXXYYYYY.NL --domain xxxyyyyy.nl \ --admin-password foobarxy --ds-password foobarxy \ --idstart 5000 \ --no-ntp Connecting my Chrome browser to this machine results in a 'Your connection is not private' errorpage. And no option to go the insecure way. Now I have my own CA, created a certifcate keypair with it and I would like to import this keypair together with my CA to add trust. Following http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP ipa-cacert-manage -p foobarxy -n NICKNAME -t C,, install myca.crt ipa-certupdate ipa-server-certinstall -w -d mysite.key mysite.crt after running ipa-certupdate again I get: trying https://lab-k1.xxxyyyyy.nl/ipa/json Forwarding 'ca_is_enabled' to json server 'https://lab-k1.xxxyyyyy.nl/ipa/json' cert validation failed for "CN=Object Signing Cert,O=XXXYYYYY.NL" ((SEC_ERROR_INADEQUATE_KEY_USAGE) Certificate key usage inadequate for attempted operation.) On other attempts I get a timeout on ipa-certupdate: Resubmitting certmonger request '20161115122715' timed out, please check the request manually Any idea what is going on? Am I using the right docs? versions: ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 krb5-libs-1.13.2-12.el7_2.x86_64 krb5-pkinit-1.13.2-12.el7_2.x86_64 krb5-server-1.13.2-12.el7_2.x86_64 krb5-workstation-1.13.2-12.el7_2.x86_64 libsss_nss_idmap-1.13.0-40.el7_2.12.x86_64 mod_nss-1.0.11-6.el7.x86_64 nss-3.21.0-9.el7_2.x86_64 nss-softokn-3.16.2.3-14.2.el7_2.x86_64 nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 nss-sysinit-3.21.0-9.el7_2.x86_64 nss-tools-3.21.0-9.el7_2.x86_64 nss-util-3.21.0-2.2.el7_2.x86_64 nss_compat_ossl-0.9.6-8.el7.x86_64 openssl-1.0.1e-51.el7_2.7.x86_64 openssl-libs-1.0.1e-51.el7_2.7.x86_64 pam_krb5-2.4.8-4.el7.x86_64 pki-base-10.2.5-10.el7_2.noarch pki-ca-10.2.5-10.el7_2.noarch pki-kra-10.2.5-10.el7_2.noarch pki-server-10.2.5-10.el7_2.noarch pki-tools-10.2.5-10.el7_2.x86_64 python-nss-0.16.0-3.el7.x86_64 sssd-krb5-1.13.0-40.el7_2.12.x86_64 sssd-krb5-common-1.13.0-40.el7_2.12.x86_64 -- Leo Baltus From christoph.hoesler at inovex.de Tue Nov 15 13:06:32 2016 From: christoph.hoesler at inovex.de (=?UTF-8?Q?Christoph_H=C3=B6sler?=) Date: Tue, 15 Nov 2016 13:06:32 +0000 Subject: [Freeipa-users] State of External Users feature Message-ID: The documentation about "External Users in FreeIPA" ( http://www.freeipa.org/page/External_Users_in_IPA) has not been updated for quite some time. What is the current state of this feature? Is it still on the roadmap? Best regards, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesaharrisonuk at yahoo.co.uk Tue Nov 15 14:33:26 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Tue, 15 Nov 2016 14:33:26 +0000 (UTC) Subject: [Freeipa-users] Differences between "ipa-replica-manage connect --winsync..." and ipa-adtrust-install ... ipa trust-add... References: <1219074499.762321.1479220406724.ref@mail.yahoo.com> Message-ID: <1219074499.762321.1479220406724@mail.yahoo.com> Hello,Are there any differences between establishing a Replication Agreement using "ipa-replica-manage connect --winsync"? and establishing an AD Trust Relationship using the commands? ipa-adtrust-install ...? ipa trust-add ... Are they used together or are they different methods to accomplish the same goal: to get AD user accounts? Which one is preferred? Best regards,James Harrison -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Nov 15 14:38:55 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 15 Nov 2016 15:38:55 +0100 Subject: [Freeipa-users] Differences between "ipa-replica-manage connect --winsync..." and ipa-adtrust-install ... ipa trust-add... In-Reply-To: <1219074499.762321.1479220406724@mail.yahoo.com> References: <1219074499.762321.1479220406724.ref@mail.yahoo.com> <1219074499.762321.1479220406724@mail.yahoo.com> Message-ID: <1e4b617a-b11a-d74a-527a-bd1a6ce02708@redhat.com> On 15.11.2016 15:33, James Harrison wrote: > Hello, > Are there any differences between establishing a Replication Agreement > using "ipa-replica-manage connect --winsync" and establishing an AD > Trust Relationship using the commands ipa-adtrust-install ... ipa > trust-add ... > > Are they used together or are they different methods to accomplish the > same goal: to get AD user accounts? Which one is preferred? > > Best regards, > James Harrison > > Hello, you may find answers here https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/introduction.html AD Trust method is preferred Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ataoltamer at gmail.com Tue Nov 15 14:45:25 2016 From: ataoltamer at gmail.com (Tamer Ataol) Date: Tue, 15 Nov 2016 17:45:25 +0300 Subject: [Freeipa-users] Wrong timestamp on ipaclient-install.log file and authentication problem Message-ID: Hi, I am trying to make ipa-client-install work on Ubuntu 14.04.5. Everything works except it doesn't get ldap users from IPA Master. I dig issue a little bit and found out that ipaclient-install.log under /var/log/ directory uses wrong timestamp. Ubuntu's date is correct, it is set to Istanbul time. But in the log file UTC is used. 3 hours behind the servers time. I am thinking this issue is the cause of not getting the ldap users from the FreeIPA Master. IPA client cannot synchronize with the master because it uses UTC. I couldn't find any other issue. What can make FreeIPA Client use a different time than the server's? Java and Python gives Istanbul time in the server. So they are correct. Also I restarted rsyslogd. Nothing changed. Another thing I want to mention is that I installed Ubuntu form netboot image and installed ubuntu-desktop, freeipa-client and ssh on top of that. And Ubuntu is set to Turkish. Strangely when I install Ubuntu from Live CD in English this issue never happens and FreeIPA Client works perfectly. But I need to use netboot and Turkish as I need to install many computers for Turkish users. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkrizek at redhat.com Tue Nov 15 14:57:59 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Tue, 15 Nov 2016 15:57:59 +0100 Subject: [Freeipa-users] ipa-server-install & certificates In-Reply-To: <20161115124759.GA3346@omroep.nl> References: <20161115124759.GA3346@omroep.nl> Message-ID: <9b04ecea-4fec-9356-3425-577a30dc52ae@redhat.com> On 11/15/2016 01:47 PM, Leo Baltus wrote: > Hi, > > (first time user, firts post on this ML) > > I am setting up ipa-server on a fresh CentOS-7 system. > > After running: > > /usr/sbin/ipa-server-install -U --realm XXXYYYYY.NL --domain xxxyyyyy.nl \ > --admin-password foobarxy --ds-password foobarxy \ > --idstart 5000 \ > --no-ntp > > Connecting my Chrome browser to this machine results in a 'Your > connection is not private' errorpage. And no option to go the > insecure way. > > Now I have my own CA, created a certifcate keypair with it and I would > like to import this keypair together with my CA to add trust. > > Following http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > ipa-cacert-manage -p foobarxy -n NICKNAME -t C,, install myca.crt > ipa-certupdate > ipa-server-certinstall -w -d mysite.key mysite.crt > > after running ipa-certupdate again I get: > > trying https://lab-k1.xxxyyyyy.nl/ipa/json > Forwarding 'ca_is_enabled' to json server 'https://lab-k1.xxxyyyyy.nl/ipa/json' > cert validation failed for "CN=Object Signing Cert,O=XXXYYYYY.NL" ((SEC_ERROR_INADEQUATE_KEY_USAGE) Certificate key usage inadequate for attempted operation.) > > On other attempts I get a timeout on ipa-certupdate: > Resubmitting certmonger request '20161115122715' timed out, please check the request manually > > Any idea what is going on? Am I using the right docs? > > versions: > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 > krb5-libs-1.13.2-12.el7_2.x86_64 > krb5-pkinit-1.13.2-12.el7_2.x86_64 > krb5-server-1.13.2-12.el7_2.x86_64 > krb5-workstation-1.13.2-12.el7_2.x86_64 > libsss_nss_idmap-1.13.0-40.el7_2.12.x86_64 > mod_nss-1.0.11-6.el7.x86_64 > nss-3.21.0-9.el7_2.x86_64 > nss-softokn-3.16.2.3-14.2.el7_2.x86_64 > nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 > nss-sysinit-3.21.0-9.el7_2.x86_64 > nss-tools-3.21.0-9.el7_2.x86_64 > nss-util-3.21.0-2.2.el7_2.x86_64 > nss_compat_ossl-0.9.6-8.el7.x86_64 > openssl-1.0.1e-51.el7_2.7.x86_64 > openssl-libs-1.0.1e-51.el7_2.7.x86_64 > pam_krb5-2.4.8-4.el7.x86_64 > pki-base-10.2.5-10.el7_2.noarch > pki-ca-10.2.5-10.el7_2.noarch > pki-kra-10.2.5-10.el7_2.noarch > pki-server-10.2.5-10.el7_2.noarch > pki-tools-10.2.5-10.el7_2.x86_64 > python-nss-0.16.0-3.el7.x86_64 > sssd-krb5-1.13.0-40.el7_2.12.x86_64 > sssd-krb5-common-1.13.0-40.el7_2.12.x86_64 > Hi, can you check if your certificate can be used for an SSL server? You can use the following command openssl x509 -purpose -in mysite.crt -- Tomas Krizek From Leo.Baltus at npo.nl Tue Nov 15 15:39:29 2016 From: Leo.Baltus at npo.nl (Leo Baltus) Date: Tue, 15 Nov 2016 16:39:29 +0100 Subject: [Freeipa-users] ipa-server-install & certificates In-Reply-To: <9b04ecea-4fec-9356-3425-577a30dc52ae@redhat.com> References: <20161115124759.GA3346@omroep.nl> <9b04ecea-4fec-9356-3425-577a30dc52ae@redhat.com> Message-ID: <20161115153929.GB3346@omroep.nl> Op 15/11/2016 om 15:57:59 +0100, schreef Tomas Krizek: > On 11/15/2016 01:47 PM, Leo Baltus wrote: > > Hi, > > > > (first time user, firts post on this ML) > > > > I am setting up ipa-server on a fresh CentOS-7 system. > > > > After running: > > > > /usr/sbin/ipa-server-install -U --realm XXXYYYYY.NL --domain xxxyyyyy.nl \ > > --admin-password foobarxy --ds-password foobarxy \ > > --idstart 5000 \ > > --no-ntp > > > > Connecting my Chrome browser to this machine results in a 'Your > > connection is not private' errorpage. And no option to go the > > insecure way. > > > > Now I have my own CA, created a certifcate keypair with it and I would > > like to import this keypair together with my CA to add trust. > > > > Following http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > > > ipa-cacert-manage -p foobarxy -n NICKNAME -t C,, install myca.crt > > ipa-certupdate > > ipa-server-certinstall -w -d mysite.key mysite.crt > > > > after running ipa-certupdate again I get: > > > > trying https://lab-k1.xxxyyyyy.nl/ipa/json > > Forwarding 'ca_is_enabled' to json server 'https://lab-k1.xxxyyyyy.nl/ipa/json' > > cert validation failed for "CN=Object Signing Cert,O=XXXYYYYY.NL" ((SEC_ERROR_INADEQUATE_KEY_USAGE) Certificate key usage inadequate for attempted operation.) > > > > On other attempts I get a timeout on ipa-certupdate: > > Resubmitting certmonger request '20161115122715' timed out, please check the request manually > > > > Any idea what is going on? Am I using the right docs? > > > > versions: > > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 > > krb5-libs-1.13.2-12.el7_2.x86_64 > > krb5-pkinit-1.13.2-12.el7_2.x86_64 > > krb5-server-1.13.2-12.el7_2.x86_64 > > krb5-workstation-1.13.2-12.el7_2.x86_64 > > libsss_nss_idmap-1.13.0-40.el7_2.12.x86_64 > > mod_nss-1.0.11-6.el7.x86_64 > > nss-3.21.0-9.el7_2.x86_64 > > nss-softokn-3.16.2.3-14.2.el7_2.x86_64 > > nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 > > nss-sysinit-3.21.0-9.el7_2.x86_64 > > nss-tools-3.21.0-9.el7_2.x86_64 > > nss-util-3.21.0-2.2.el7_2.x86_64 > > nss_compat_ossl-0.9.6-8.el7.x86_64 > > openssl-1.0.1e-51.el7_2.7.x86_64 > > openssl-libs-1.0.1e-51.el7_2.7.x86_64 > > pam_krb5-2.4.8-4.el7.x86_64 > > pki-base-10.2.5-10.el7_2.noarch > > pki-ca-10.2.5-10.el7_2.noarch > > pki-kra-10.2.5-10.el7_2.noarch > > pki-server-10.2.5-10.el7_2.noarch > > pki-tools-10.2.5-10.el7_2.x86_64 > > python-nss-0.16.0-3.el7.x86_64 > > sssd-krb5-1.13.0-40.el7_2.12.x86_64 > > sssd-krb5-common-1.13.0-40.el7_2.12.x86_64 > > > Hi, > > can you check if your certificate can be used for an SSL server? You can use > the following command > > openssl x509 -purpose -in mysite.crt > Certificate purposes: SSL client : Yes SSL client CA : No SSL server : Yes SSL server CA : No -- Leo Baltus, internetbeheerder NPO ICT Internet Services Bart de Graaffweg 2, 1217 ZL Hilversum servicedesk at omroep.nl, 035-6773555 From mbabinsk at redhat.com Tue Nov 15 15:58:26 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 15 Nov 2016 16:58:26 +0100 Subject: [Freeipa-users] Wrong timestamp on ipaclient-install.log file and authentication problem In-Reply-To: References: Message-ID: On 11/15/2016 03:45 PM, Tamer Ataol wrote: > Hi, > > I am trying to make ipa-client-install work on Ubuntu 14.04.5. > Everything works except it doesn't get ldap users from IPA Master. I dig > issue a little bit and found out that ipaclient-install.log under > /var/log/ directory uses wrong timestamp. Ubuntu's date is correct, it > is set to Istanbul time. But in the log file UTC is used. 3 hours behind > the servers time. I am thinking this issue is the cause of not getting > the ldap users from the FreeIPA Master. IPA client cannot synchronize > with the master because it uses UTC. I couldn't find any other issue. > > What can make FreeIPA Client use a different time than the server's? > Java and Python gives Istanbul time in the server. So they are correct. > Also I restarted rsyslogd. Nothing changed. > > Another thing I want to mention is that I installed Ubuntu form netboot > image and installed ubuntu-desktop, freeipa-client and ssh on top of > that. And Ubuntu is set to Turkish. Strangely when I install Ubuntu from > Live CD in English this issue never happens and FreeIPA Client works > perfectly. But I need to use netboot and Turkish as I need to install > many computers for Turkish users. > > Thanks. > > > IIRC the IPA logs always have UTC timestamps because it makes debugging issues across different timezones easier. Also the timestamp format used in the logging module should not influence the client function. If you suspect that timesync is an issue you need to compare the client and server time directly, not based on logs. If your master has NTP running and is configured as NTP server (that should be always the case unless you gave '--no-ntp' option during master install), the client will use it as a source of time. I would inspect ipaclient-install logs for errors and also look into https://fedorahosted.org/sssd/wiki/Troubleshooting because user lookup on the client is mainly done by sssd unless configured otherwise. -- Martin^3 Babinsky From dag at sonsorol.org Tue Nov 15 16:32:47 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Tue, 15 Nov 2016 11:32:47 -0500 Subject: [Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads? Message-ID: <582B38AF.6010407@sonsorol.org> Got a porn spam today that had a subject header of: > Re: [Freeipa-users] URL is changing on the browser Have to admit that got through my spam filter and got me to open the email. It's clear that it was not a list message; looks like something may be mining the public list archives to pull email addresses and plausible sounding subject lines. Mildly interested if anyone else got an email like this? -Chris From mbasti at redhat.com Tue Nov 15 17:02:00 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 15 Nov 2016 18:02:00 +0100 Subject: [Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads? In-Reply-To: <582B38AF.6010407@sonsorol.org> References: <582B38AF.6010407@sonsorol.org> Message-ID: <9518896f-2be2-85a8-17e7-16ca5851e613@redhat.com> On 15.11.2016 17:32, Chris Dagdigian wrote: > > > Got a porn spam today that had a subject header of: > >> Re: [Freeipa-users] URL is changing on the browser > > Have to admit that got through my spam filter and got me to open the > email. > > It's clear that it was not a list message; looks like something may be > mining the public list archives to pull email addresses and plausible > sounding subject lines. > > Mildly interested if anyone else got an email like this? > > -Chris > > We are receiving those emails as well (different subjects, domains, but the same content) From datakid at gmail.com Wed Nov 16 00:46:32 2016 From: datakid at gmail.com (Lachlan Musicman) Date: Wed, 16 Nov 2016 11:46:32 +1100 Subject: [Freeipa-users] Shadow Utils appears in sssd.conf Message-ID: I don't know what I've done wrong, but when I use ipa-client-install on a new host to add to my one way trust domain, I now have a [domain/shadowutils] stanza. This first happened a couple of weeks ago, I saw this bug and thought "it will be solved soon". https://bugzilla.redhat.com/show_bug.cgi?id=1369118 The report says it's been resolved in a recent advisory but I'm still seeing the error. Is it because I'm using sssd 1.14.2-1 from COPR instead of the centrally supplied sssd? 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 datakid at gmail.com Wed Nov 16 00:56:12 2016 From: datakid at gmail.com (Lachlan Musicman) Date: Wed, 16 Nov 2016 11:56:12 +1100 Subject: [Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads? In-Reply-To: <9518896f-2be2-85a8-17e7-16ca5851e613@redhat.com> References: <582B38AF.6010407@sonsorol.org> <9518896f-2be2-85a8-17e7-16ca5851e613@redhat.com> Message-ID: Gah, just happened to me. Wasn't porn, but was someone called Kimi and the only content was "Heeey Lachlan, how's it going?" L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 16 November 2016 at 04:02, Martin Basti wrote: > > > On 15.11.2016 17:32, Chris Dagdigian wrote: > >> >> >> Got a porn spam today that had a subject header of: >> >> Re: [Freeipa-users] URL is changing on the browser >>> >> >> Have to admit that got through my spam filter and got me to open the >> email. >> >> It's clear that it was not a list message; looks like something may be >> mining the public list archives to pull email addresses and plausible >> sounding subject lines. >> >> Mildly interested if anyone else got an email like this? >> >> -Chris >> >> >> We are receiving those emails as well (different subjects, domains, but > the same content) > > > -- > 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 schogan at us.ibm.com Wed Nov 16 02:24:38 2016 From: schogan at us.ibm.com (Sean Hogan) Date: Tue, 15 Nov 2016 19:24:38 -0700 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server Message-ID: Hello, I am starting to see some issues with a few RHEL7 boxes I have been enrolling to my RHEL 6 IPA server regarding encryption. RHEL 7 client Red Hat Enterprise Linux Server release 7.1 (Maipo) sssd-ipa-1.12.2-58.el7_1.18.x86_64 ipa-client-4.1.0-18.el7_1.4.x86_64 RHEL 6 Server Red Hat Enterprise Linux Server release 6.8 (Santiago) sssd-ipa-1.13.3-22.el6_8.4.x86_64 ipa-server-3.0.0-50.el6.1.x86_64 The RHEL 7 client shows this in messages Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support for encryption type Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP connection. I am also not seeing host certs for them on the ipa server but I do see them on the local box. [root at server1 pam.d]# ktutil ktutil: rkt /etc/krb5.keytab ktutil: l slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 1 host/server1.ipa.local at IPA.LOCAL 2 1 host/server1.ipa.local at IPA.LOCAL 3 1 host/server1.ipa.local at IPA.LOCAL 4 1 host/server1.ipa.local at IPA.LOCAL ktutil: I have one RHEL 7 box with no issues as it was just enrolled (missing host certs in IPA though) and I compared and IPA ID login with a box not working Work type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="janedoe" exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh res=failed' vs Works type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit acct="janedoe" exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh res=success' Its almost as if the pam files are not being read? Sean Hogan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0D184914.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0D992031.gif Type: image/gif Size: 1650 bytes Desc: not available URL: From tba at statsbiblioteket.dk Wed Nov 16 06:44:49 2016 From: tba at statsbiblioteket.dk (Tony Brian Albers) Date: Wed, 16 Nov 2016 06:44:49 +0000 Subject: [Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads? In-Reply-To: References: <582B38AF.6010407@sonsorol.org> <9518896f-2be2-85a8-17e7-16ca5851e613@redhat.com> Message-ID: Hehe, just you wait Lachlan ;) /tony On 11/16/2016 01:56 AM, Lachlan Musicman wrote: > Gah, just happened to me. Wasn't porn, but was someone called Kimi and > the only content was "Heeey Lachlan, how's it going?" > > L. > > ------ > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper > > On 16 November 2016 at 04:02, Martin Basti > wrote: > > > > On 15.11.2016 17:32, Chris Dagdigian wrote: > > > > Got a porn spam today that had a subject header of: > > Re: [Freeipa-users] URL is changing on the browser > > > Have to admit that got through my spam filter and got me to open > the email. > > It's clear that it was not a list message; looks like something > may be mining the public list archives to pull email addresses > and plausible sounding subject lines. > > Mildly interested if anyone else got an email like this? > > -Chris > > > We are receiving those emails as well (different subjects, domains, > but the same content) > > > -- > 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, Tony Albers Systems administrator, IT-development State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. Tel: +45 2566 2383 / +45 8946 2316 From th at casalogic.dk Wed Nov 16 06:50:35 2016 From: th at casalogic.dk (Troels Hansen) Date: Wed, 16 Nov 2016 07:50:35 +0100 (CET) Subject: [Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads? In-Reply-To: <582B38AF.6010407@sonsorol.org> References: <582B38AF.6010407@sonsorol.org> Message-ID: <1128316271.883726.1479279035680.JavaMail.zimbra@casalogic.dk> ----- On Nov 15, 2016, at 5:32 PM, Chris Dagdigian dag at sonsorol.org wrote: > Got a porn spam today that had a subject header of: > >> Re: [Freeipa-users] URL is changing on the browser > > Have to admit that got through my spam filter and got me to open the email. > > It's clear that it was not a list message; looks like something may be > mining the public list archives to pull email addresses and plausible > sounding subject lines. > > Mildly interested if anyone else got an email like this? > Yep, received such one as well. Subject looks like its a reply to the message you just sent. From BJB at jndata.dk Wed Nov 16 07:27:10 2016 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Wed, 16 Nov 2016 07:27:10 +0000 Subject: [Freeipa-users] krb5 and nfsv4 not working right In-Reply-To: <15fad8b4-38da-948d-5af6-813e2b926f09@statsbiblioteket.dk> References: <15fad8b4-38da-948d-5af6-813e2b926f09@statsbiblioteket.dk> Message-ID: <89213DDB84447F44A8E8950A5C2185E0482EB005@SJN01013.jnmain00.corp.jndata.net> Try inserting this in /etc/gssproxy/gssproxy.conf: cred_store = ccache:FILE:/tmp/krb5cc_%U /etc/gssproxy/gssproxy.conf: [service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/tmp/krb5cc_%U cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab cred_usage = initiate allow_any_uid = yes trusted = yes euid = 0 Regards, Bjarne Blichfeldt -----Original Message----- From: Tony Brian Albers [mailto:tba at statsbiblioteket.dk] Sent: 15. november 2016 13:18 To: freeipa-users at redhat.com Subject: [Freeipa-users] krb5 and nfsv4 not working right Hi guys, I've followed every guide I can find on this subject. What I'm trying to is to get our home directories which are shared via NFS from the FreeIPA server mounted via autofs on the clients. The client is kact-man-001 and the FreeIPA server is kact-adm-001 /etc/exports: I've done the ipa-client-install and the ipa-client-automount However, when I log in, my homedir is mounted as expected but what I get in the messages log is: Nov 15 12:52:25 kact-man-001 gssproxy: gssproxy[770]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found A lot! /etc/krb5.conf is default from the FreeIPA installation: default_ccache_name = KEYRING:persistent:%{uid} The autofs setup looks like this: --------------------------------------------------------- [root at kact-adm-001 log]# ipa automountmap-find Location: default ------------------------ 3 automount maps matched ------------------------ Map: auto.direct Map: auto.home Map: auto.master ---------------------------- Number of entries returned 3 ---------------------------- [root at kact-adm-001 log]# [root at kact-adm-001 log]# ipa automountkey-find Location: default Map: auto.home ----------------------- 1 automount key matched ----------------------- Key: * Mount information: -fstype=nfs4,rw,sec=krb5,rsize=8192,wsize=8192 kact-adm-001.kact.sblokalnet:/data/home/& ---------------------------- Number of entries returned 1 ---------------------------- [root at kact-adm-001 log]# --------------------------------------------------------- Now, the BAD thing is, trying to copy a large file to the automounted dir on the client just hangs: [tba at pc588 images]$ scp NAS4Free-x64-LiveUSB-10.3.0.3.2987.img.gz tba-sb at kact-man-001.kact.sblokalnet:. tba-sb at kact-man-001.kact.sblokalnet's password: NAS4Free-x64-LiveUSB-10.3.0.3.2987.img.gz 100% 281MB 93.6MB/s 00:03 [hangs] And my logged in session on the client hangs if I try to do ls in my homedir: [tba at pc588 ~]$ ssh tba-sb at kact-man-001.kact.sblokalnet tba-sb at kact-man-001.kact.sblokalnet's password: Last login: Tue Nov 15 13:07:12 2016 from pc588.sb.statsbiblioteket.dk -sh-4.2$ -sh-4.2$ -sh-4.2$ pwd /home/tba-sb -sh-4.2$ hostname kact-man-001 -sh-4.2$ -sh-4.2$ ls [hangs] And I see a huge amount of the GSS failures in the messages file on the client. Any suggestions? TIA -- Best regards, Tony Albers Systems administrator, IT-development State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. Tel: +45 2566 2383 / +45 8946 2316 From lslebodn at redhat.com Wed Nov 16 08:39:05 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 16 Nov 2016 09:39:05 +0100 Subject: [Freeipa-users] Shadow Utils appears in sssd.conf In-Reply-To: References: Message-ID: <20161116083905.GA16665@10.4.128.1> On (16/11/16 11:46), Lachlan Musicman wrote: >I don't know what I've done wrong, but when I use ipa-client-install on a >new host to add to my one way trust domain, I now have a >[domain/shadowutils] stanza. > >This first happened a couple of weeks ago, I saw this bug and thought "it >will be solved soon". > >https://bugzilla.redhat.com/show_bug.cgi?id=1369118 > >The report says it's been resolved in a recent advisory but I'm still >seeing the error. > It was fixed by reverting upstream commit which introduced such seature. https://git.fedorahosted.org/cgit/sssd.git/commit/?id=59744cff6edb106ae799b2321cb8731edadf409a >Is it because I'm using sssd 1.14.2-1 from COPR instead of the centrally >supplied sssd? > Yes, theis feature is still available in upstream/fedora. A) "domain/shadowutils" should not cause any problems. If yes then it should be also reproducible on fedora please filae a bug. B) It does not happen with SELinux in enforcing mode. Another reason for "setenforce 1" :-) LS From daniel.paessens at hpe.com Wed Nov 16 09:04:52 2016 From: daniel.paessens at hpe.com (Paessens, Daniel) Date: Wed, 16 Nov 2016 09:04:52 +0000 Subject: [Freeipa-users] Actions for a stolen/compromised IPA Client Message-ID: Currently am I looking for a workable solution for the following situation: Let's say that an ipa client has been stolen (or compromised). What can we do to block all access from it, towards IPA (and rest) For example if we use the command "ipa host-disable" it's noticed that IPA users are no longer able to login into the system. But if you log into the system as root. Then you can still run (successfully) the command kinit, and optain a ticket for it. Even if you delete the host from the directory, the behavior remains the same. Can this anyhow be blocked. Regards, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Nov 16 09:22:07 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 16 Nov 2016 10:22:07 +0100 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: References: Message-ID: <20161116092207.sgfqdomuhhs62v4x@hendrix> On Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: > > > Hello, > > > I am starting to see some issues with a few RHEL7 boxes I have been > enrolling to my RHEL 6 IPA server regarding encryption. > > > RHEL 7 client > Red Hat Enterprise Linux Server release 7.1 (Maipo) > sssd-ipa-1.12.2-58.el7_1.18.x86_64 > ipa-client-4.1.0-18.el7_1.4.x86_64 > > RHEL 6 Server > Red Hat Enterprise Linux Server release 6.8 (Santiago) > sssd-ipa-1.13.3-22.el6_8.4.x86_64 > ipa-server-3.0.0-50.el6.1.x86_64 > > > The RHEL 7 client shows this in messages > > Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support > for encryption type Could you post a more verbose ldap_child log (debug_level=10 includes KRB5_TRACE-level messages) so that we see what kind of crypto was used? > Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize > credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity check > failed. Unable to create GSSAPI-encrypted LDAP connection. > > I am also not seeing host certs for them on the ipa server but I do see > them on the local box. > > [root at server1 pam.d]# ktutil Can you run klist -ke as well to see what encryption types are included in the keytab? Is it possible to run "kinit -k" on the client? > ktutil: rkt /etc/krb5.keytab > ktutil: l > slot KVNO Principal > ---- ---- > --------------------------------------------------------------------- > 1 1 host/server1.ipa.local at IPA.LOCAL > 2 1 host/server1.ipa.local at IPA.LOCAL > 3 1 host/server1.ipa.local at IPA.LOCAL > 4 1 host/server1.ipa.local at IPA.LOCAL > ktutil: > > > I have one RHEL 7 box with no issues as it was just enrolled (missing host > certs in IPA though) and I compared and IPA ID login with a box not > working > Work > type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0 > auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 > msg='op=PAM:authentication grantors=? acct="janedoe" exe="/usr/sbin/sshd" > hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh res=failed' > > vs > > Works > type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0 > auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 > msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit acct="janedoe" > exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh > res=success' > > Its almost as if the pam files are not being read? > > > > 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 From jhrozek at redhat.com Wed Nov 16 09:22:57 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 16 Nov 2016 10:22:57 +0100 Subject: [Freeipa-users] Shadow Utils appears in sssd.conf In-Reply-To: <20161116083905.GA16665@10.4.128.1> References: <20161116083905.GA16665@10.4.128.1> Message-ID: <20161116092257.d3h5v6hodbnpi55j@hendrix> On Wed, Nov 16, 2016 at 09:39:05AM +0100, Lukas Slebodnik wrote: > On (16/11/16 11:46), Lachlan Musicman wrote: > >I don't know what I've done wrong, but when I use ipa-client-install on a > >new host to add to my one way trust domain, I now have a > >[domain/shadowutils] stanza. > > > >This first happened a couple of weeks ago, I saw this bug and thought "it > >will be solved soon". > > > >https://bugzilla.redhat.com/show_bug.cgi?id=1369118 > > > >The report says it's been resolved in a recent advisory but I'm still > >seeing the error. > > > It was fixed by reverting upstream commit which > introduced such seature. > https://git.fedorahosted.org/cgit/sssd.git/commit/?id=59744cff6edb106ae799b2321cb8731edadf409a > > >Is it because I'm using sssd 1.14.2-1 from COPR instead of the centrally > >supplied sssd? > > > Yes, theis feature is still available in upstream/fedora. > > A) "domain/shadowutils" should not cause any problems. > If yes then it should be also reproducible on fedora > please filae a bug. > > B) It does not happen with SELinux in enforcing mode. > Another reason for "setenforce 1" :-) Also, we're going to remove this domain in favor of new domain type with id_provider=files in the next release. From mbabinsk at redhat.com Wed Nov 16 09:29:53 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 16 Nov 2016 10:29:53 +0100 Subject: [Freeipa-users] Actions for a stolen/compromised IPA Client In-Reply-To: References: Message-ID: <8f1b5270-a0a1-1f81-5956-982396531f31@redhat.com> On 11/16/2016 10:04 AM, Paessens, Daniel wrote: > Currently am I looking for a workable solution for the following situation: > Let's say that an ipa client has been stolen (or compromised). What > can we do to block all access from it, towards IPA (and rest) > For example if we use the command "ipa host-disable" it's noticed > that IPA users are no longer able to login into the system. But if you > log into the system as root. Then you can still run (successfully) the > command kinit, and optain a ticket for it. > Even if you delete the host from the directory, the behavior remains > the same. > Can this anyhow be blocked. > Regards, > Daniel > > > Hi Daniel, host-disable removes the host kerberos keys and certificates from LDAP as you correctly observer. This means that all services on the compromised host stop working. SSSD will also stop working since it uses the now invalid host keytab to perform user lookup, that's why ssh'ing to host as IPA user stops working. However, there is nothing preventing the attacker to try to kinit as admin directly without sssd on the machine, which can potentialy lead to DoS attack on the admin user. So if you realize that the host was compromised it is best to first run hist-disable and then block all traffic from that host on ports 88 tcp/udp (Kerberos), 464 tcp/udp (kadmin), 749 tcp/udp (kpasswd IIRC) and LDAP(S) ports (389, 636 tcp). -- Martin^3 Babinsky From daniel.paessens at hpe.com Wed Nov 16 09:57:34 2016 From: daniel.paessens at hpe.com (Paessens, Daniel) Date: Wed, 16 Nov 2016 09:57:34 +0000 Subject: [Freeipa-users] Actions for a stolen/compromised IPA Client In-Reply-To: <8f1b5270-a0a1-1f81-5956-982396531f31@redhat.com> References: <8f1b5270-a0a1-1f81-5956-982396531f31@redhat.com> Message-ID: Indeed the kinit keeps working correctly. If you give a good password it retrieves the tokens correctly. Thus it's not only DOS, but also an potentional brutal password retriever as well. Blocking on firewall level,ok, but what if you use DHCP. It's more difficult to protect it, through that way. Daniel -----Original Message----- From: Martin Babinsky [mailto:mbabinsk at redhat.com] Sent: Wednesday, November 16, 2016 10:30 AM To: Paessens, Daniel ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Actions for a stolen/compromised IPA Client On 11/16/2016 10:04 AM, Paessens, Daniel wrote: > Currently am I looking for a workable solution for the following situation: > Let's say that an ipa client has been stolen (or compromised). > What can we do to block all access from it, towards IPA (and rest) > For example if we use the command "ipa host-disable" it's noticed > that IPA users are no longer able to login into the system. But if you > log into the system as root. Then you can still run (successfully) the > command kinit, and optain a ticket for it. > Even if you delete the host from the directory, the behavior > remains the same. > Can this anyhow be blocked. > Regards, > Daniel > > > Hi Daniel, host-disable removes the host kerberos keys and certificates from LDAP as you correctly observer. This means that all services on the compromised host stop working. SSSD will also stop working since it uses the now invalid host keytab to perform user lookup, that's why ssh'ing to host as IPA user stops working. However, there is nothing preventing the attacker to try to kinit as admin directly without sssd on the machine, which can potentialy lead to DoS attack on the admin user. So if you realize that the host was compromised it is best to first run hist-disable and then block all traffic from that host on ports 88 tcp/udp (Kerberos), 464 tcp/udp (kadmin), 749 tcp/udp (kpasswd IIRC) and LDAP(S) ports (389, 636 tcp). -- Martin^3 Babinsky From mbabinsk at redhat.com Wed Nov 16 11:20:33 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 16 Nov 2016 12:20:33 +0100 Subject: [Freeipa-users] [Freeipa-devel] pam_winbind(sshd:auth): pam_get_item returned a password In-Reply-To: References: Message-ID: <65e02b93-dc4e-0569-9ac0-322226f07439@redhat.com> On 11/16/2016 10:41 AM, rajat gupta wrote: > > I am using FreeIPA version 4.4.0 and Active Directory trust setup. on > Active Directory side I am using UPN suffix. > > Following are my setup. > > AD DOMANIN :- corp.addomain.com > UPN suffix :- username at mydomain.com > IPA DOMAIN :- ipa.ipadomain.local > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local > > > I am able to login with AD user on IPA server. But on IPA clinet i am > not able to login i am getting the login message "Access denied". I have > enabled the debug_level on sssd.conf on ipa client. > > below are some logs.. > ================ > /var/log/secure > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=x.x.x.x user=rg1989 > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received for > user e600336: 6 (Permission denied) > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting > password (0x00000010) > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > pam_get_item returned a password > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): internal > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for rg1989 from > x.x.x.x. port 48842 ssh2 > ================ > > ================ > krb5_child.log > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [false] UPN > [Rajat.Gupta at MYDOMAIN.COM ] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [k5c_precreate_ccache] (0x4000): Recreating ccache > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [find_principal_in_keytab] (0x4000): Trying to find principal > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] > (0x1000): Principal matched to the sample > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [check_fast_ccache] (0x0200): FAST TGT is still valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] > (0x2000): Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > Will perform online auth > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN.COM ] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending > request (164 bytes) to MYDOMAIN.COM > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying > AS request with master KDC > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending > request (164 bytes) to MYDOMAIN.COM (master) > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > (0x0200): Received error code 1432158228 > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [false] UPN > [Rajat.Gupta at MYDOMAIN.COM ] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [k5c_precreate_ccache] (0x4000): Recreating ccache > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [find_principal_in_keytab] (0x4000): Trying to find principal > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] > (0x1000): Principal matched to the sample > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [check_fast_ccache] (0x0200): FAST TGT is still valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] > (0x2000): Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > Will perform online auth > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN.COM ] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending > request (164 bytes) to MYDOMAIN.COM > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying > AS request with master KDC > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending > request (164 bytes) to MYDOMAIN.COM (master) > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > (0x0200): Received error code 1432158228 > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [true] UPN > [Rajat.Gupta at MYDOMAIN.COM ] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > (0x0200): Already user [1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] > (0x2000): Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > Will perform offline auth > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [create_empty_ccache] (0x1000): Existing ccache still valid, reusing > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [pack_response_packet] (0x2000): response packet size: [53] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > (0x1000): total buffer size: [52] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [true] UPN > [Rajat.Gupta at MYDOMAIN.COM ] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > (0x0200): Already user [1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] > (0x2000): Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > Will perform pre-auth > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN.COM ] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending > request (164 bytes) to MYDOMAIN.COM > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying > AS request with master KDC > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending > request (164 bytes) to MYDOMAIN.COM (master) > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > pre-auth. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > (0x1000): total buffer size: [160] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [true] UPN > [Rajat.Gupta at MYDOMAIN.COM ] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > (0x0200): Already user [1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] > (0x2000): Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > Will perform offline auth > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [create_empty_ccache] (0x1000): Existing ccache still valid, reusing > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [pack_response_packet] (0x2000): response packet size: [53] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > krb5_child completed successfully > > ======================= > > Can you please help me to fix this, > > /Rajat > > Hi Rajat, Please subscribe to and use freeipa-users at redhat.com for requesting help/troubleshooting assistance. freeipa-devel list is focused mainly on technical discussions involving FreeIPA developers and community contributors to FreeIPA source code. -- Martin^3 Babinsky From rajat.linux at gmail.com Wed Nov 16 11:33:41 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Wed, 16 Nov 2016 12:33:41 +0100 Subject: [Freeipa-users] Fwd: [Freeipa-devel] pam_winbind(sshd:auth): pam_get_item returned a password In-Reply-To: <65e02b93-dc4e-0569-9ac0-322226f07439@redhat.com> References: <65e02b93-dc4e-0569-9ac0-322226f07439@redhat.com> Message-ID: > > Hi, > > I am using FreeIPA version 4.4.0 and Active Directory trust setup. on > Active Directory side I am using UPN suffix. > > Following are my setup. > > AD DOMANIN :- corp.addomain.com > UPN suffix :- username at mydomain.com > > IPA DOMAIN :- ipa.ipadomain.local > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local > > > I am able to login with AD user on IPA server. But on IPA clinet i am > not able to login i am getting the login message "Access denied". I have > enabled the debug_level on sssd.conf on ipa client. > > below are some logs.. > ================ > /var/log/secure > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=x.x.x.x user=rg1989 > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received for > user e600336: 6 (Permission denied) > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting > password (0x00000010) > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > pam_get_item returned a password > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): internal > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for rg1989 from > x.x.x.x. port 48842 ssh2 > ================ > > ================ > krb5_child.log > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [false] UPN > [Rajat.Gupta at MYDOMAIN.COM ] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [k5c_precreate_ccache] (0x4000): Recreating ccache > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [find_principal_in_keytab] (0x4000): Trying to find principal > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] > (0x1000): Principal matched to the sample > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [check_fast_ccache] (0x0200): FAST TGT is still valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] > (0x2000): Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > Will perform online auth > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN.COM ] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending > request (164 bytes) to MYDOMAIN.COM > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying > AS request with master KDC > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending > request (164 bytes) to MYDOMAIN.COM (master) > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > (0x0200): Received error code 1432158228 > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [false] UPN > [Rajat.Gupta at MYDOMAIN.COM ] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [k5c_precreate_ccache] (0x4000): Recreating ccache > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [find_principal_in_keytab] (0x4000): Trying to find principal > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] > (0x1000): Principal matched to the sample > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [check_fast_ccache] (0x0200): FAST TGT is still valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] > (0x2000): Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > Will perform online auth > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN.COM ] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending > request (164 bytes) to MYDOMAIN.COM > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying > AS request with master KDC > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending > request (164 bytes) to MYDOMAIN.COM (master) > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > (0x0200): Received error code 1432158228 > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [true] UPN > [Rajat.Gupta at MYDOMAIN.COM ] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > (0x0200): Already user [1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] > (0x2000): Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > Will perform offline auth > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [create_empty_ccache] (0x1000): Existing ccache still valid, reusing > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [pack_response_packet] (0x2000): response packet size: [53] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > (0x1000): total buffer size: [52] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [true] UPN > [Rajat.Gupta at MYDOMAIN.COM ] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > (0x0200): Already user [1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] > (0x2000): Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > Will perform pre-auth > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN.COM ] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending > request (164 bytes) to MYDOMAIN.COM > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying > AS request with master KDC > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending > request (164 bytes) to MYDOMAIN.COM (master) > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > pre-auth. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > (0x1000): total buffer size: [160] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [true] UPN > [Rajat.Gupta at MYDOMAIN.COM ] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > (0x0200): Already user [1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] > (0x2000): Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > Will perform offline auth > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [create_empty_ccache] (0x1000): Existing ccache still valid, reusing > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [pack_response_packet] (0x2000): response packet size: [53] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > krb5_child completed successfully > > ======================= > > Can you please help me to fix this, > > /Rajat > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajat.linux at gmail.com Wed Nov 16 11:49:59 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Wed, 16 Nov 2016 12:49:59 +0100 Subject: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item returned a password Message-ID: I am using FreeIPA version 4.4.0 Active Directory trust setup. And on Active Directory side I am using UPN suffix. Following are my domain setup. AD DOMANIN :- corp.addomain.com UPN suffix :- username at mydomain.com IPA DOMAIN :- ipa.ipadomain.local IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local I am able to login with AD user on IPA server. But on IPA clinet i am not able to login i am getting the login message "Access denied". I have enabled the debug_level on sssd.conf on ipa clinet. below are some logs.. ================ /var/log/secure Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989 Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received for user e600336: 6 (Permission denied) Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting password (0x00000010) Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): pam_get_item returned a password Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): internal module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 from x.x.x.x. port 48842 ssh2 ================ ================ krb5_child.log (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] (0x4000): Response sent. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): krb5_child completed successfully (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): krb5_child started. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] (0x1000): total buffer size: [159] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] (0x0200): Switch user to [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1007656917] and is not active and TGT is valid. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] (0x1000): Principal matched to the sample (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] (0x0200): Trying to become user [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): Running as [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] (0x2000): Running as [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): Will perform online auth (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MYDOMAIN.COM] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting initial credentials for Rajat.Gupta at MYDOMAIN.COM (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: Retrieving host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM \@MYDOMAIN.COM at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: -1765328243/Matching credential not found (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending request (164 bytes) to MYDOMAIN.COM (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying AS request with master KDC (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting initial credentials for Rajat.Gupta at MYDOMAIN.COM (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: Retrieving host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM \@MYDOMAIN.COM at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: -1765328243/Matching credential not found (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending request (164 bytes) to MYDOMAIN.COM (master) (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] (0x0200): Received error code 1432158228 (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [pack_response_packet] (0x2000): response packet size: [4] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] (0x4000): Response sent. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): krb5_child completed successfully (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): krb5_child started. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] (0x1000): total buffer size: [159] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] (0x0200): Switch user to [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1007656917] and is not active and TGT is valid. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] (0x1000): Principal matched to the sample (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] (0x0200): Trying to become user [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): Running as [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] (0x2000): Running as [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): Will perform online auth (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MYDOMAIN.COM] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting initial credentials for Rajat.Gupta at MYDOMAIN.COM (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: Retrieving host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM \@MYDOMAIN.COM at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: -1765328243/Matching credential not found (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending request (164 bytes) to MYDOMAIN.COM (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying AS request with master KDC (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting initial credentials for Rajat.Gupta at MYDOMAIN.COM (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: Retrieving host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM \@MYDOMAIN.COM at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: -1765328243/Matching credential not found (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending request (164 bytes) to MYDOMAIN.COM (master) (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] (0x0200): Received error code 1432158228 (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [pack_response_packet] (0x2000): response packet size: [4] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] (0x4000): Response sent. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): krb5_child completed successfully (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): krb5_child started. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] (0x1000): total buffer size: [159] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] enterprise principal [false] offline [true] UPN [Rajat.Gupta at MYDOMAIN.COM] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] (0x0200): Switch user to [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1007656917] and is not active and TGT is valid. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] (0x0200): Trying to become user [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): Running as [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] (0x0200): Trying to become user [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] (0x0200): Already user [1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] (0x2000): Running as [1007656917][1007656917]. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): Will perform offline auth (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] (0x0200): Received error code 0 (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [pack_response_packet] (0x2000): response packet size: [53] (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] (0x4000): Response sent. (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): krb5_child completed successfully (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): krb5_child started. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] (0x1000): total buffer size: [52] (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] enterprise principal [false] offline [true] UPN [Rajat.Gupta at MYDOMAIN.COM] (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] (0x0200): Trying to become user [1007656917][1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): Running as [1007656917][1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] (0x0200): Trying to become user [1007656917][1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] (0x0200): Already user [1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] (0x2000): Running as [1007656917][1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): Will perform pre-auth (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MYDOMAIN.COM] (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting initial credentials for Rajat.Gupta at MYDOMAIN.COM (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending request (164 bytes) to MYDOMAIN.COM (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying AS request with master KDC (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting initial credentials for Rajat.Gupta at MYDOMAIN.COM (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending request (164 bytes) to MYDOMAIN.COM (master) (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328230} during pre-auth. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] (0x0200): Received error code 0 (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [pack_response_packet] (0x2000): response packet size: [4] (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] (0x4000): Response sent. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): krb5_child completed successfully (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): krb5_child started. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] (0x1000): total buffer size: [160] (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] enterprise principal [false] offline [true] UPN [Rajat.Gupta at MYDOMAIN.COM] (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] (0x0200): Switch user to [1007656917][1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1007656917] and is not active and TGT is valid. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] (0x0200): Trying to become user [1007656917][1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): Running as [1007656917][1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] (0x0200): Trying to become user [1007656917][1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] (0x0200): Already user [1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] (0x2000): Running as [1007656917][1007656917]. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): Will perform offline auth (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] (0x0200): Received error code 0 (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [pack_response_packet] (0x2000): response packet size: [53] (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] (0x4000): Response sent. (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): krb5_child completed successfully ======================= Can you please help me to fix this, -------------- next part -------------- An HTML attachment was scrubbed... URL: From BJB at jndata.dk Wed Nov 16 11:56:05 2016 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Wed, 16 Nov 2016 11:56:05 +0000 Subject: [Freeipa-users] Client x.x.xx - RFC 1918 response from Internet in /var/log/messages Message-ID: <89213DDB84447F44A8E8950A5C2185E0482EB1EE@SJN01013.jnmain00.corp.jndata.net> Just updated a couple of free-ipa servers to: ipa-server-dns-4.4.0-12.el7.noarch redhat-release-server-7.3-7.el7.x86_64 Before the update, I resolved the issue with RFC messages by: /etc/named.conf: options { disable-empty-zone "10.in-addr.arpa."; : Now after the update the RFS messages has returned. I read in the changelog for 4.4 that this issue was resolved. What did I miss? Venlig hilsen Bjarne Blichfeldt Infrastructure Services Direkte +4563636119 Mobile +4521593270 BJB at jndata.dk [cid:image005.png at 01D24008.CA6EF0F0] JN Data A/S * Havsteensvej 4 * 4000 Roskilde Telefon 63 63 63 63/ Fax 63 63 63 64 www.jndata.dk [cid:image006.png at 01D24008.CA6EF0F0] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 410 bytes Desc: image005.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 5487 bytes Desc: image006.png URL: From sbose at redhat.com Wed Nov 16 12:01:59 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 16 Nov 2016 13:01:59 +0100 Subject: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item returned a password In-Reply-To: References: Message-ID: <20161116120159.GL28171@p.Speedport_W_724V_Typ_A_05011603_00_009> On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote: > I am using FreeIPA version 4.4.0 Active Directory trust setup. And on > Active Directory side I am using UPN suffix. > Following are my domain setup. > > AD DOMANIN :- corp.addomain.com > UPN suffix :- username at mydomain.com > IPA DOMAIN :- ipa.ipadomain.local > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local When you call 'ipa trust-find' on the IPA server do you see the mydomain.com UPN suffix listed, like e.g.: # ipa trust-find --------------- 1 trust matched --------------- Realm-Name: ad.devel Domain NetBIOS name: AD Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199 Trust type: Active Directory domain UPN suffixes: alt.alt, alt.upn.suffix SSSD 1.14 and above on the IPA client should enable enterprise principal support automatically if UPN suffixes are found on the server but according to (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM] it is not. If the UPN suffixes are not know on the server, calling 'ipa trust-fetch-domains' might help to get them. If there are still no UPN suffixes available on the server you can switch on enterprise principal on the client manually by adding 'krb5_use_enterprise_principal = True' in the [domain/...] section of sssd.conf. You have to set it manually as well if you are using older versions of SSSD. HTH bye, Sumit > > > I am able to login with AD user on IPA server. But on IPA clinet i am not > able to login i am getting the login message "Access denied". I have > enabled the debug_level on sssd.conf on ipa clinet. > > below are some logs.. > ================ > /var/log/secure > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989 > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received for > user e600336: 6 (Permission denied) > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting > password (0x00000010) > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > pam_get_item returned a password > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): internal > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 from > x.x.x.x. port 48842 ssh2 > ================ > > ================ > krb5_child.log > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [k5c_precreate_ccache] (0x4000): Recreating ccache > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [find_principal_in_keytab] (0x4000): Trying to find principal > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] > (0x1000): Principal matched to the sample > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [check_fast_ccache] > (0x0200): FAST TGT is still valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): Will > perform online auth > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending > request (164 bytes) to MYDOMAIN.COM > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying AS > request with master KDC > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending > request (164 bytes) to MYDOMAIN.COM (master) > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > (0x0200): Received error code 1432158228 > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [k5c_precreate_ccache] (0x4000): Recreating ccache > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [find_principal_in_keytab] (0x4000): Trying to find principal > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] > (0x1000): Principal matched to the sample > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [check_fast_ccache] > (0x0200): FAST TGT is still valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): Will > perform online auth > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending > request (164 bytes) to MYDOMAIN.COM > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying AS > request with master KDC > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: Retrieving > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > \@MYDOMAIN.COM at X-CACHECONF: from > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > -1765328243/Matching credential not found > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending > request (164 bytes) to MYDOMAIN.COM (master) > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > (0x0200): Received error code 1432158228 > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [true] UPN [Rajat.Gupta at MYDOMAIN.COM] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > (0x0200): Already user [1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): Will > perform offline auth > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [create_empty_ccache] > (0x1000): Existing ccache still valid, reusing > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [pack_response_packet] (0x2000): response packet size: [53] > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > (0x1000): total buffer size: [52] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [true] UPN [Rajat.Gupta at MYDOMAIN.COM] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > (0x0200): Already user [1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): Will > perform pre-auth > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending > request (164 bytes) to MYDOMAIN.COM > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying AS > request with master KDC > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending > request (164 bytes) to MYDOMAIN.COM (master) > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > pre-auth. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > (0x1000): total buffer size: [160] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [true] UPN [Rajat.Gupta at MYDOMAIN.COM] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > (0x0200): Switch user to [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > (0x0200): Trying to become user [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > (0x0200): Already user [1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] (0x2000): > Running as [1007656917][1007656917]. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): Will > perform offline auth > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [create_empty_ccache] > (0x1000): Existing ccache still valid, reusing > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [pack_response_packet] (0x2000): response packet size: [53] > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > krb5_child completed successfully > > ======================= > Can you please help me to fix this, > -- > 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 stijn.deweirdt at ugent.be Wed Nov 16 13:01:09 2016 From: stijn.deweirdt at ugent.be (Stijn De Weirdt) Date: Wed, 16 Nov 2016 14:01:09 +0100 Subject: [Freeipa-users] minimise impact compromised host Message-ID: hi all, we are looking how to configure whatever relevant policy to minimise the impact of compromised IPA hosts (ie servers with a valid host keytab). in particular, it looks like it possible to retrieve any user token once you have access to a valid host keytab. we're aware that the default IPA policies are wide open, but we are looking how to limit this. for us, there's no need that a hostkeytab can retrieve tokens for anything except the services on that host. stijn From sbose at redhat.com Wed Nov 16 13:25:00 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 16 Nov 2016 14:25:00 +0100 Subject: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item returned a password In-Reply-To: <20161116120159.GL28171@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161116120159.GL28171@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <20161116132500.GO28171@p.Speedport_W_724V_Typ_A_05011603_00_009> On Wed, Nov 16, 2016 at 01:01:59PM +0100, Sumit Bose wrote: > On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote: > > I am using FreeIPA version 4.4.0 Active Directory trust setup. And on > > Active Directory side I am using UPN suffix. > > Following are my domain setup. > > > > AD DOMANIN :- corp.addomain.com > > UPN suffix :- username at mydomain.com > > IPA DOMAIN :- ipa.ipadomain.local > > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local > > When you call 'ipa trust-find' on the IPA server do you see the > mydomain.com UPN suffix listed, like e.g.: > > # ipa trust-find > --------------- > 1 trust matched > --------------- > Realm-Name: ad.devel > Domain NetBIOS name: AD > Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199 > Trust type: Active Directory domain > UPN suffixes: alt.alt, alt.upn.suffix > > SSSD 1.14 and above on the IPA client should enable enterprise principal > support automatically if UPN suffixes are found on the server but according to > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM] > > it is not. If the UPN suffixes are not know on the server, calling 'ipa > trust-fetch-domains' might help to get them. If there are still no UPN suffixes > available on the server you can switch on enterprise principal on the client > manually by adding 'krb5_use_enterprise_principal = True' in the [domain/...] > section of sssd.conf. You have to set it manually as well if you are using > older versions of SSSD. > > HTH > > bye, > Sumit > > > > > > > I am able to login with AD user on IPA server. But on IPA clinet i am not > > able to login i am getting the login message "Access denied". I have > > enabled the debug_level on sssd.conf on ipa clinet. > > > > below are some logs.. > > ================ > > /var/log/secure > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989 > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received for > > user e600336: 6 (Permission denied) > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting > > password (0x00000010) By the way, why do you have pam_winbind in the PAM configuration? bye, Sumit > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > > pam_get_item returned a password > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): internal > > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 from > > x.x.x.x. port 48842 ssh2 > > ================ > > > > ================ > > krb5_child.log > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > (0x1000): total buffer size: [159] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > (0x0200): Switch user to [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > (0x0200): Switch user to [0][0]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [find_principal_in_keytab] (0x4000): Trying to find principal > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] > > (0x1000): Principal matched to the sample > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [check_fast_ccache] > > (0x0200): FAST TGT is still valid. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): Will > > perform online auth > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] > > (0x1000): Attempting to get a TGT > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST armor > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: Retrieving > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > \@MYDOMAIN.COM at X-CACHECONF: from > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > -1765328243/Matching credential not found > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending > > request (164 bytes) to MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying AS > > request with master KDC > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST armor > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: Retrieving > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > \@MYDOMAIN.COM at X-CACHECONF: from > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > -1765328243/Matching credential not found > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending > > request (164 bytes) to MYDOMAIN.COM (master) > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > (0x0200): Received error code 1432158228 > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [pack_response_packet] (0x2000): response packet size: [4] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > (0x1000): total buffer size: [159] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > (0x0200): Switch user to [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > (0x0200): Switch user to [0][0]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [find_principal_in_keytab] (0x4000): Trying to find principal > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] > > (0x1000): Principal matched to the sample > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [check_fast_ccache] > > (0x0200): FAST TGT is still valid. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): Will > > perform online auth > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] > > (0x1000): Attempting to get a TGT > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST armor > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: Retrieving > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > \@MYDOMAIN.COM at X-CACHECONF: from > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > -1765328243/Matching credential not found > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending > > request (164 bytes) to MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying AS > > request with master KDC > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST armor > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: Retrieving > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > \@MYDOMAIN.COM at X-CACHECONF: from > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > -1765328243/Matching credential not found > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending > > request (164 bytes) to MYDOMAIN.COM (master) > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > (0x0200): Received error code 1432158228 > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [pack_response_packet] (0x2000): response packet size: [4] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > (0x1000): total buffer size: [159] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [true] UPN [Rajat.Gupta at MYDOMAIN.COM] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > (0x0200): Switch user to [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > (0x0200): Switch user to [0][0]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > (0x0200): Already user [1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): Will > > perform offline auth > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [create_empty_ccache] > > (0x1000): Existing ccache still valid, reusing > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > (0x0200): Received error code 0 > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [pack_response_packet] (0x2000): response packet size: [53] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > (0x1000): total buffer size: [52] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [true] UPN [Rajat.Gupta at MYDOMAIN.COM] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > (0x0200): Already user [1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): Will > > perform pre-auth > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] > > (0x1000): Attempting to get a TGT > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending > > request (164 bytes) to MYDOMAIN.COM > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying AS > > request with master KDC > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending > > request (164 bytes) to MYDOMAIN.COM (master) > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] > > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > > pre-auth. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > (0x0200): Received error code 0 > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [pack_response_packet] (0x2000): response packet size: [4] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > (0x1000): total buffer size: [160] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [true] UPN [Rajat.Gupta at MYDOMAIN.COM] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > (0x0200): Switch user to [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > (0x0200): Switch user to [0][0]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > (0x0200): Already user [1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): Will > > perform offline auth > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [create_empty_ccache] > > (0x1000): Existing ccache still valid, reusing > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > (0x0200): Received error code 0 > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [pack_response_packet] (0x2000): response packet size: [53] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > krb5_child completed successfully > > > > ======================= > > Can you please help me to fix this, > > > -- > > 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 From rajat.linux at gmail.com Wed Nov 16 13:31:52 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Wed, 16 Nov 2016 14:31:52 +0100 Subject: [Freeipa-users] Freeipa-users Digest, Vol 100, Issue 48 In-Reply-To: References: Message-ID: Thanks, It is working for few user but not for every one. I have cleared the sssd cache as well. ===================== /var/log/secure Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=146.213.0.134 user=kb1980 Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): received for user kb1980: 6 (Permission denied) Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): getting password (0x00000010) Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): pam_get_item returned a password Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): internal module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'kb1980') Nov 16 14:06:39 ipa-clinet1 sshd[6852]: Failed password for kb1980 from 146.213.0.134 port 51114 ssh2 Nov 16 14:06:48 ipa-clinet1 sshd[6852]: Connection closed by 146.213.0.134 [preauth] Nov 16 14:07:07 ipa-clinet1 sshd[3677]: pam_unix(sshd:session): session closed for user kb1980 ======================== krb5_child.log (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): krb5_child started. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [unpack_buffer] (0x1000): total buffer size: [54] (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [unpack_buffer] (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true] enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] (0x0200): Trying to become user [1007628631][1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x2000): Running as [1007628631][1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] (0x0200): Trying to become user [1007628631][1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] (0x0200): Already user [1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_setup] (0x2000): Running as [1007628631][1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): Will perform pre-auth (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MYDOMAIN COM] (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.872554: Getting initial credentials for karan.b at MYDOMAIN COM (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.874607: Sending request (167 bytes) to MYDOMAIN COM (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898179: Retrying AS request with master KDC (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898221: Getting initial credentials for karan.b at MYDOMAIN COM (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898291: Sending request (167 bytes) to MYDOMAIN COM (master) (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328230} during pre-auth. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_send_data] (0x0200): Received error code 0 (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [pack_response_packet] (0x2000): response packet size: [4] (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_send_data] (0x4000): Response sent. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): krb5_child completed successfully (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): krb5_child started. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] (0x1000): total buffer size: [159] (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true] enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1007628631] old_ccname: [KEYRING:persistent:1007628631] keytab: [/etc/krb5.keytab] (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [switch_creds] (0x0200): Switch user to [1007628631][1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1007628631] and is not active and TGT is valid. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] (0x0200): Trying to become user [1007628631][1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x2000): Running as [1007628631][1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] (0x0200): Trying to become user [1007628631][1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] (0x0200): Already user [1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_setup] (0x2000): Running as [1007628631][1007628631]. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): Will perform offline auth (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_send_data] (0x0200): Received error code 0 (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [pack_response_packet] (0x2000): response packet size: [53] (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_send_data] (0x4000): Response sent. (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): krb5_child completed successfully (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): krb5_child started. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [unpack_buffer] (0x1000): total buffer size: [54] (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [unpack_buffer] (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true] enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] (0x0200): Trying to become user [1007628631][1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x2000): Running as [1007628631][1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] (0x0200): Trying to become user [1007628631][1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] (0x0200): Already user [1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_setup] (0x2000): Running as [1007628631][1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): Will perform pre-auth (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MYDOMAIN COM] (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.494908: Getting initial credentials for karan.b at MYDOMAIN COM (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.496903: Sending request (167 bytes) to MYDOMAIN COM (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.497962: Retrying AS request with master KDC (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.497985: Getting initial credentials for karan.b at MYDOMAIN COM (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.498026: Sending request (167 bytes) to MYDOMAIN COM (master) (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328230} during pre-auth. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_send_data] (0x0200): Received error code 0 (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [pack_response_packet] (0x2000): response packet size: [4] (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_send_data] (0x4000): Response sent. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): krb5_child completed successfully (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): krb5_child started. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] (0x1000): total buffer size: [159] (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true] enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1007628631] old_ccname: [KEYRING:persistent:1007628631] keytab: [/etc/krb5.keytab] (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [switch_creds] (0x0200): Switch user to [1007628631][1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1007628631] and is not active and TGT is valid. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] (0x0200): Trying to become user [1007628631][1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x2000): Running as [1007628631][1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] (0x0200): Trying to become user [1007628631][1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] (0x0200): Already user [1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_setup] (0x2000): Running as [1007628631][1007628631]. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): Will perform offline auth (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_send_data] (0x0200): Received error code 0 (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [pack_response_packet] (0x2000): response packet size: [53] (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_send_data] (0x4000): Response sent. (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): krb5_child completed successfully On Wed, Nov 16, 2016 at 1:02 PM, wrote: > Send Freeipa-users mailing list submissions to > freeipa-users at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-users > or, via email, send a message with subject or body 'help' to > freeipa-users-request at redhat.com > > You can reach the person managing the list at > freeipa-users-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-users digest..." > > > Today's Topics: > > 1. Client x.x.xx - RFC 1918 response from Internet in > /var/log/messages (Bjarne Blichfeldt) > 2. Re: pam_winbind(sshd:auth): pam_get_item returned a password > (Sumit Bose) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Nov 2016 11:56:05 +0000 > From: Bjarne Blichfeldt > To: "freeipa-users at redhat.com" > Subject: [Freeipa-users] Client x.x.xx - RFC 1918 response from > Internet in /var/log/messages > Message-ID: > <89213DDB84447F44A8E8950A5C2185E0482EB1EE at SJN01013.jnmain00. > corp.jndata.net> > > Content-Type: text/plain; charset="us-ascii" > > Just updated a couple of free-ipa servers to: > ipa-server-dns-4.4.0-12.el7.noarch > redhat-release-server-7.3-7.el7.x86_64 > > Before the update, I resolved the issue with RFC messages by: > /etc/named.conf: > options { > disable-empty-zone "10.in-addr.arpa."; > : > > Now after the update the RFS messages has returned. I read in the > changelog for 4.4 that this issue was resolved. > What did I miss? > > > > > > > Venlig hilsen > > > Bjarne Blichfeldt > > > Infrastructure Services > > > > Direkte +4563636119 > > > Mobile +4521593270 > > > BJB at jndata.dk > > [cid:image005.png at 01D24008.CA6EF0F0] > > JN Data A/S > > * > > Havsteensvej 4 > > * > > 4000 Roskilde > > > Telefon 63 63 63 63/ Fax 63 63 63 64 > > > www.jndata.dk > > > [cid:image006.png at 01D24008.CA6EF0F0] > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20161116/46aeee39/attachment.html> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image005.png > Type: image/png > Size: 410 bytes > Desc: image005.png > URL: attachments/20161116/46aeee39/attachment.png> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image006.png > Type: image/png > Size: 5487 bytes > Desc: image006.png > URL: attachments/20161116/46aeee39/attachment-0001.png> > > ------------------------------ > > Message: 2 > Date: Wed, 16 Nov 2016 13:01:59 +0100 > From: Sumit Bose > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item > returned a password > Message-ID: > <20161116120159.GL28171 at p.Speedport_W_724V_Typ_A_05011603_00_009> > Content-Type: text/plain; charset=us-ascii > > On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote: > > I am using FreeIPA version 4.4.0 Active Directory trust setup. And on > > Active Directory side I am using UPN suffix. > > Following are my domain setup. > > > > AD DOMANIN :- corp.addomain.com > > UPN suffix :- username at mydomain.com > > IPA DOMAIN :- ipa.ipadomain.local > > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local > > When you call 'ipa trust-find' on the IPA server do you see the > mydomain.com UPN suffix listed, like e.g.: > > # ipa trust-find > --------------- > 1 trust matched > --------------- > Realm-Name: ad.devel > Domain NetBIOS name: AD > Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199 > Trust type: Active Directory domain > UPN suffixes: alt.alt, alt.upn.suffix > > SSSD 1.14 and above on the IPA client should enable enterprise principal > support automatically if UPN suffixes are found on the server but > according to > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM > ] > > it is not. If the UPN suffixes are not know on the server, calling 'ipa > trust-fetch-domains' might help to get them. If there are still no UPN > suffixes > available on the server you can switch on enterprise principal on the > client > manually by adding 'krb5_use_enterprise_principal = True' in the > [domain/...] > section of sssd.conf. You have to set it manually as well if you are using > older versions of SSSD. > > HTH > > bye, > Sumit > > > > > > > I am able to login with AD user on IPA server. But on IPA clinet i am not > > able to login i am getting the login message "Access denied". I have > > enabled the debug_level on sssd.conf on ipa clinet. > > > > below are some logs.. > > ================ > > /var/log/secure > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): > authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989 > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received for > > user e600336: 6 (Permission denied) > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting > > password (0x00000010) > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > > pam_get_item returned a password > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): internal > > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 from > > x.x.x.x. port 48842 ssh2 > > ================ > > > > ================ > > krb5_child.log > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > (0x1000): total buffer size: [159] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [false] UPN [ > Rajat.Gupta at MYDOMAIN.COM] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > (0x0200): Switch user to [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > (0x0200): Switch user to [0][0]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [find_principal_in_keytab] (0x4000): Trying to find principal > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] > > (0x1000): Principal matched to the sample > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [check_fast_ccache] > > (0x0200): FAST TGT is still valid. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] > (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > [true] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > Will > > perform online auth > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] > > (0x1000): Attempting to get a TGT > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST armor > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: Retrieving > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > \@MYDOMAIN.COM at X-CACHECONF: from > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > -1765328243/Matching credential not found > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending > > request (164 bytes) to MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying AS > > request with master KDC > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST armor > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: Retrieving > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > \@MYDOMAIN.COM at X-CACHECONF: from > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > -1765328243/Matching credential not found > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending > > request (164 bytes) to MYDOMAIN.COM (master) > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > (0x0200): Received error code 1432158228 > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [pack_response_packet] (0x2000): response packet size: [4] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > (0x1000): total buffer size: [159] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [false] UPN [ > Rajat.Gupta at MYDOMAIN.COM] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > (0x0200): Switch user to [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > (0x0200): Switch user to [0][0]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [find_principal_in_keytab] (0x4000): Trying to find principal > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] > > (0x1000): Principal matched to the sample > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [check_fast_ccache] > > (0x0200): FAST TGT is still valid. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] > (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > [true] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > Will > > perform online auth > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] > > (0x1000): Attempting to get a TGT > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST armor > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: Retrieving > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > \@MYDOMAIN.COM at X-CACHECONF: from > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > -1765328243/Matching credential not found > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending > > request (164 bytes) to MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying AS > > request with master KDC > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST armor > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: Retrieving > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > \@MYDOMAIN.COM at X-CACHECONF: from > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > -1765328243/Matching credential not found > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending > > request (164 bytes) to MYDOMAIN.COM (master) > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > (0x0200): Received error code 1432158228 > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [pack_response_packet] (0x2000): response packet size: [4] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > (0x1000): total buffer size: [159] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [true] UPN [ > Rajat.Gupta at MYDOMAIN.COM] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > (0x0200): Switch user to [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > (0x0200): Switch user to [0][0]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > (0x0200): Already user [1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] > (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > Will > > perform offline auth > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [create_empty_ccache] > > (0x1000): Existing ccache still valid, reusing > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > (0x0200): Received error code 0 > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [pack_response_packet] (0x2000): response packet size: [53] > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > (0x1000): total buffer size: [52] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [true] UPN [ > Rajat.Gupta at MYDOMAIN.COM] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > (0x0200): Already user [1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] > (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > Will > > perform pre-auth > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] > > (0x1000): Attempting to get a TGT > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending > > request (164 bytes) to MYDOMAIN.COM > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying AS > > request with master KDC > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending > > request (164 bytes) to MYDOMAIN.COM (master) > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] > > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > > pre-auth. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > (0x0200): Received error code 0 > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [pack_response_packet] (0x2000): response packet size: [4] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > (0x1000): total buffer size: [160] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [true] UPN [ > Rajat.Gupta at MYDOMAIN.COM] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > (0x0200): Switch user to [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > (0x0200): Switch user to [0][0]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > (0x0200): Trying to become user [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > (0x0200): Already user [1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] > (0x2000): > > Running as [1007656917][1007656917]. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > Will > > perform offline auth > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [create_empty_ccache] > > (0x1000): Existing ccache still valid, reusing > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > (0x0200): Received error code 0 > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [pack_response_packet] (0x2000): response packet size: [53] > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > krb5_child completed successfully > > > > ======================= > > Can you please help me to fix this, > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > > > ------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > End of Freeipa-users Digest, Vol 100, Issue 48 > ********************************************** > -- *Rajat Gupta * -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Nov 16 13:33:17 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Nov 2016 14:33:17 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: References: Message-ID: On 16.11.2016 14:01, Stijn De Weirdt wrote: > hi all, > > we are looking how to configure whatever relevant policy to minimise the > impact of compromised IPA hosts (ie servers with a valid host keytab). > > in particular, it looks like it possible to retrieve any user token once > you have access to a valid host keytab. > > we're aware that the default IPA policies are wide open, but we are > looking how to limit this. for us, there's no need that a hostkeytab can > retrieve tokens for anything except the services on that host. What "token" do you have in mind? -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 16 13:35:34 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Nov 2016 14:35:34 +0100 Subject: [Freeipa-users] Client x.x.xx - RFC 1918 response from Internet in /var/log/messages In-Reply-To: <89213DDB84447F44A8E8950A5C2185E0482EB1EE@SJN01013.jnmain00.corp.jndata.net> References: <89213DDB84447F44A8E8950A5C2185E0482EB1EE@SJN01013.jnmain00.corp.jndata.net> Message-ID: <6620537c-79ee-dc7d-b076-0359ac4d290f@redhat.com> On 16.11.2016 12:56, Bjarne Blichfeldt wrote: > Just updated a couple of free-ipa servers to: > ipa-server-dns-4.4.0-12.el7.noarch > redhat-release-server-7.3-7.el7.x86_64 > > Before the update, I resolved the issue with RFC messages by: > /etc/named.conf: > options { > disable-empty-zone "10.in-addr.arpa."; > : > > Now after the update the RFS messages has returned. I read in the changelog for 4.4 that this issue was resolved. > What did I miss? This sort of misconfiguration is described on https://deepthought.isc.org/article/AA-00204/0/What-does-RFC-1918-response-from-Internet-for-0.0.0.10.IN-ADDR.ARPA-mean.html Please follow advices on ISC web to fix this. You are most probably sending your queries to the public Internet instead of your internal network. -- Petr^2 Spacek From mbabinsk at redhat.com Wed Nov 16 13:41:34 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 16 Nov 2016 14:41:34 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: References: Message-ID: On 11/16/2016 02:33 PM, Petr Spacek wrote: > On 16.11.2016 14:01, Stijn De Weirdt wrote: >> hi all, >> >> we are looking how to configure whatever relevant policy to minimise the >> impact of compromised IPA hosts (ie servers with a valid host keytab). >> >> in particular, it looks like it possible to retrieve any user token once >> you have access to a valid host keytab. >> >> we're aware that the default IPA policies are wide open, but we are >> looking how to limit this. for us, there's no need that a hostkeytab can >> retrieve tokens for anything except the services on that host. > > What "token" do you have in mind? > We discussed this in another thread. In the case that the host is compromised/stolen/hijacked, you can host-disable it to invalidate the keytab stored there but this does not prevent anyone logged on that host to bruteforce/DOS user accounts by trying to guess their Kerberos keys by repeated kinit. -- Martin^3 Babinsky From stijn.deweirdt at ugent.be Wed Nov 16 13:55:42 2016 From: stijn.deweirdt at ugent.be (Stijn De Weirdt) Date: Wed, 16 Nov 2016 14:55:42 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: References: Message-ID: >> we are looking how to configure whatever relevant policy to minimise the >> impact of compromised IPA hosts (ie servers with a valid host keytab). >> >> in particular, it looks like it possible to retrieve any user token once >> you have access to a valid host keytab. >> >> we're aware that the default IPA policies are wide open, but we are >> looking how to limit this. for us, there's no need that a hostkeytab can >> retrieve tokens for anything except the services on that host. > > What "token" do you have in mind? > service tokens, like HTTP/fqdn at REALM should work, but i expect in the following example that the kvno part fails kinit -kt /etc/krb5.keytab kvno a_valid_user stijn From rajat.linux at gmail.com Wed Nov 16 14:06:34 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Wed, 16 Nov 2016 15:06:34 +0100 Subject: [Freeipa-users] Freeipa-users Digest, Vol 100, Issue 49 In-Reply-To: References: Message-ID: Hi sumit, you mean to say these? ]# grep pam_winbind /etc/pam.d/password-auth auth sufficient pam_winbind.so use_first_pass account [default=bad success=ok user_unknown=ignore] pam_winbind.so password sufficient pam_winbind.so use_authtok session optional pam_winbind.so On Wed, Nov 16, 2016 at 2:32 PM, wrote: > Send Freeipa-users mailing list submissions to > freeipa-users at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-users > or, via email, send a message with subject or body 'help' to > freeipa-users-request at redhat.com > > You can reach the person managing the list at > freeipa-users-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-users digest..." > > > Today's Topics: > > 1. minimise impact compromised host (Stijn De Weirdt) > 2. Re: pam_winbind(sshd:auth): pam_get_item returned a password > (Sumit Bose) > 3. Re: Freeipa-users Digest, Vol 100, Issue 48 (rajat gupta) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Nov 2016 14:01:09 +0100 > From: Stijn De Weirdt > To: freeipa-users at redhat.com > Subject: [Freeipa-users] minimise impact compromised host > Message-ID: > Content-Type: text/plain; charset=utf-8 > > hi all, > > we are looking how to configure whatever relevant policy to minimise the > impact of compromised IPA hosts (ie servers with a valid host keytab). > > in particular, it looks like it possible to retrieve any user token once > you have access to a valid host keytab. > > we're aware that the default IPA policies are wide open, but we are > looking how to limit this. for us, there's no need that a hostkeytab can > retrieve tokens for anything except the services on that host. > > > stijn > > > > ------------------------------ > > Message: 2 > Date: Wed, 16 Nov 2016 14:25:00 +0100 > From: Sumit Bose > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item > returned a password > Message-ID: > <20161116132500.GO28171 at p.Speedport_W_724V_Typ_A_05011603_00_009> > Content-Type: text/plain; charset=us-ascii > > On Wed, Nov 16, 2016 at 01:01:59PM +0100, Sumit Bose wrote: > > On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote: > > > I am using FreeIPA version 4.4.0 Active Directory trust setup. And on > > > Active Directory side I am using UPN suffix. > > > Following are my domain setup. > > > > > > AD DOMANIN :- corp.addomain.com > > > UPN suffix :- username at mydomain.com > > > IPA DOMAIN :- ipa.ipadomain.local > > > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local > > > > When you call 'ipa trust-find' on the IPA server do you see the > > mydomain.com UPN suffix listed, like e.g.: > > > > # ipa trust-find > > --------------- > > 1 trust matched > > --------------- > > Realm-Name: ad.devel > > Domain NetBIOS name: AD > > Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199 > > Trust type: Active Directory domain > > UPN suffixes: alt.alt, alt.upn.suffix > > > > SSSD 1.14 and above on the IPA client should enable enterprise principal > > support automatically if UPN suffixes are found on the server but > according to > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM > ] > > > > it is not. If the UPN suffixes are not know on the server, calling 'ipa > > trust-fetch-domains' might help to get them. If there are still no UPN > suffixes > > available on the server you can switch on enterprise principal on the > client > > manually by adding 'krb5_use_enterprise_principal = True' in the > [domain/...] > > section of sssd.conf. You have to set it manually as well if you are > using > > older versions of SSSD. > > > > HTH > > > > bye, > > Sumit > > > > > > > > > > > I am able to login with AD user on IPA server. But on IPA clinet i am > not > > > able to login i am getting the login message "Access denied". I have > > > enabled the debug_level on sssd.conf on ipa clinet. > > > > > > below are some logs.. > > > ================ > > > /var/log/secure > > > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): > authentication > > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989 > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received > for > > > user e600336: 6 (Permission denied) > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting > > > password (0x00000010) > > By the way, why do you have pam_winbind in the PAM configuration? > > bye, > Sumit > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > > > pam_get_item returned a password > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > internal > > > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 > from > > > x.x.x.x. port 48842 ssh2 > > > ================ > > > > > > ================ > > > krb5_child.log > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): > > > krb5_child completed successfully > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > > krb5_child started. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > (0x1000): total buffer size: [159] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [false] UPN [ > Rajat.Gupta at MYDOMAIN.COM] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > > (0x0200): Switch user to [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > > (0x0200): Switch user to [0][0]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] > > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [find_principal_in_keytab] (0x4000): Trying to find principal > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] > > > (0x1000): Principal matched to the sample > > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [check_fast_ccache] > > > (0x0200): FAST TGT is still valid. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] > (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > from environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > [true] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > Will > > > perform online auth > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] > > > (0x1000): Attempting to get a TGT > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [get_and_save_tgt] > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST > armor > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: > Retrieving > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > -1765328243/Matching credential not found > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending > > > request (164 bytes) to MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying > AS > > > request with master KDC > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST > armor > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: > Retrieving > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > -1765328243/Matching credential not found > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [get_and_save_tgt] > > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] > > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > > (0x0200): Received error code 1432158228 > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [pack_response_packet] (0x2000): response packet size: [4] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > > krb5_child completed successfully > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > > krb5_child started. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > (0x1000): total buffer size: [159] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [false] UPN [ > Rajat.Gupta at MYDOMAIN.COM] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > > (0x0200): Switch user to [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > > (0x0200): Switch user to [0][0]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] > > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [find_principal_in_keytab] (0x4000): Trying to find principal > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] > > > (0x1000): Principal matched to the sample > > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [check_fast_ccache] > > > (0x0200): FAST TGT is still valid. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] > (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > from environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > [true] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > Will > > > perform online auth > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] > > > (0x1000): Attempting to get a TGT > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [get_and_save_tgt] > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST > armor > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: > Retrieving > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > -1765328243/Matching credential not found > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending > > > request (164 bytes) to MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying > AS > > > request with master KDC > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST > armor > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: > Retrieving > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > -1765328243/Matching credential not found > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [get_and_save_tgt] > > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] > > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > > (0x0200): Received error code 1432158228 > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [pack_response_packet] (0x2000): response packet size: [4] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > > krb5_child completed successfully > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > > krb5_child started. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > (0x1000): total buffer size: [159] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [true] UPN [ > Rajat.Gupta at MYDOMAIN.COM] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > > (0x0200): Switch user to [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > > (0x0200): Switch user to [0][0]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > (0x0200): Already user [1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] > (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > from environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > Will > > > perform offline auth > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > [create_empty_ccache] > > > (0x1000): Existing ccache still valid, reusing > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > > (0x0200): Received error code 0 > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [pack_response_packet] (0x2000): response packet size: [53] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > > krb5_child completed successfully > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > > krb5_child started. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > > (0x1000): total buffer size: [52] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > > (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [true] UPN [ > Rajat.Gupta at MYDOMAIN.COM] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > (0x0200): Already user [1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] > (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > from environment. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > environment. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > Will > > > perform pre-auth > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] > > > (0x1000): Attempting to get a TGT > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [get_and_save_tgt] > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending > > > request (164 bytes) to MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying > AS > > > request with master KDC > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [get_and_save_tgt] > > > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > > > pre-auth. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > > (0x0200): Received error code 0 > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [pack_response_packet] (0x2000): response packet size: [4] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > > krb5_child completed successfully > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > > krb5_child started. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > (0x1000): total buffer size: [160] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [true] UPN [ > Rajat.Gupta at MYDOMAIN.COM] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > > (0x0200): Switch user to [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > > (0x0200): Switch user to [0][0]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > (0x0200): Already user [1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] > (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > from environment. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > environment. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > Will > > > perform offline auth > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > [create_empty_ccache] > > > (0x1000): Existing ccache still valid, reusing > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > > (0x0200): Received error code 0 > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [pack_response_packet] (0x2000): response packet size: [53] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > > krb5_child completed successfully > > > > > > ======================= > > > Can you please help me to fix this, > > > > > -- > > > 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 > > > > ------------------------------ > > Message: 3 > Date: Wed, 16 Nov 2016 14:31:52 +0100 > From: rajat gupta > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Freeipa-users Digest, Vol 100, Issue 48 > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thanks, It is working for few user but not for every one. I have cleared > the sssd cache as well. > ===================== > /var/log/secure > > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=146.213.0.134 > user=kb1980 > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): received for > user kb1980: 6 (Permission denied) > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): getting > password (0x00000010) > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): > pam_get_item returned a password > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): internal > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'kb1980') > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: Failed password for kb1980 from > 146.213.0.134 port 51114 ssh2 > Nov 16 14:06:48 ipa-clinet1 sshd[6852]: Connection closed by 146.213.0.134 > [preauth] > Nov 16 14:07:07 ipa-clinet1 sshd[3677]: pam_unix(sshd:session): session > closed for user kb1980 > > ======================== > krb5_child.log > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [unpack_buffer] > (0x1000): total buffer size: [54] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [unpack_buffer] > (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] > (0x0200): Already user [1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_setup] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): Will > perform pre-auth > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN COM] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.872554: Getting > initial credentials for karan.b at MYDOMAIN COM > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.874607: Sending > request (167 bytes) to MYDOMAIN COM > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898179: Retrying AS > request with master KDC > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898221: Getting > initial credentials for karan.b at MYDOMAIN COM > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898291: Sending > request (167 bytes) to MYDOMAIN COM (master) > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [get_and_save_tgt] > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > pre-auth. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007628631] old_ccname: > [KEYRING:persistent:1007628631] keytab: [/etc/krb5.keytab] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [switch_creds] > (0x0200): Switch user to [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007628631] and is not active and TGT is valid. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] > (0x0200): Already user [1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_setup] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): Will > perform offline auth > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [create_empty_ccache] > (0x1000): Existing ccache still valid, reusing > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [pack_response_packet] (0x2000): response packet size: [53] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [unpack_buffer] > (0x1000): total buffer size: [54] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [unpack_buffer] > (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] > (0x0200): Already user [1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_setup] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): Will > perform pre-auth > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN COM] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.494908: Getting > initial credentials for karan.b at MYDOMAIN COM > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.496903: Sending > request (167 bytes) to MYDOMAIN COM > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.497962: Retrying AS > request with master KDC > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.497985: Getting > initial credentials for karan.b at MYDOMAIN COM > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.498026: Sending > request (167 bytes) to MYDOMAIN COM (master) > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [get_and_save_tgt] > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > pre-auth. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007628631] old_ccname: > [KEYRING:persistent:1007628631] keytab: [/etc/krb5.keytab] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [switch_creds] > (0x0200): Switch user to [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is > [KEYRING:persistent:1007628631] and is not active and TGT is valid. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] > (0x0200): Already user [1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_setup] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): Will > perform offline auth > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [create_empty_ccache] > (0x1000): Existing ccache still valid, reusing > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [pack_response_packet] (0x2000): response packet size: [53] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): > krb5_child completed successfully > > On Wed, Nov 16, 2016 at 1:02 PM, wrote: > > > Send Freeipa-users mailing list submissions to > > freeipa-users at redhat.com > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.redhat.com/mailman/listinfo/freeipa-users > > or, via email, send a message with subject or body 'help' to > > freeipa-users-request at redhat.com > > > > You can reach the person managing the list at > > freeipa-users-owner at redhat.com > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Freeipa-users digest..." > > > > > > Today's Topics: > > > > 1. Client x.x.xx - RFC 1918 response from Internet in > > /var/log/messages (Bjarne Blichfeldt) > > 2. Re: pam_winbind(sshd:auth): pam_get_item returned a password > > (Sumit Bose) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 16 Nov 2016 11:56:05 +0000 > > From: Bjarne Blichfeldt > > To: "freeipa-users at redhat.com" > > Subject: [Freeipa-users] Client x.x.xx - RFC 1918 response from > > Internet in /var/log/messages > > Message-ID: > > <89213DDB84447F44A8E8950A5C2185E0482EB1EE at SJN01013.jnmain00. > > corp.jndata.net> > > > > Content-Type: text/plain; charset="us-ascii" > > > > Just updated a couple of free-ipa servers to: > > ipa-server-dns-4.4.0-12.el7.noarch > > redhat-release-server-7.3-7.el7.x86_64 > > > > Before the update, I resolved the issue with RFC messages by: > > /etc/named.conf: > > options { > > disable-empty-zone "10.in-addr.arpa."; > > : > > > > Now after the update the RFS messages has returned. I read in the > > changelog for 4.4 that this issue was resolved. > > What did I miss? > > > > > > > > > > > > > > Venlig hilsen > > > > > > Bjarne Blichfeldt > > > > > > Infrastructure Services > > > > > > > > Direkte +4563636119 > > > > > > Mobile +4521593270 > > > > > > BJB at jndata.dk > > > > [cid:image005.png at 01D24008.CA6EF0F0] > > > > JN Data A/S > > > > * > > > > Havsteensvej 4 > > > > * > > > > 4000 Roskilde > > > > > > Telefon 63 63 63 63/ Fax 63 63 63 64 > > > > > > www.jndata.dk > > > > > > [cid:image006.png at 01D24008.CA6EF0F0] > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > attachments/20161116/46aeee39/attachment.html> > > -------------- next part -------------- > > A non-text attachment was scrubbed... > > Name: image005.png > > Type: image/png > > Size: 410 bytes > > Desc: image005.png > > URL: > attachments/20161116/46aeee39/attachment.png> > > -------------- next part -------------- > > A non-text attachment was scrubbed... > > Name: image006.png > > Type: image/png > > Size: 5487 bytes > > Desc: image006.png > > URL: > attachments/20161116/46aeee39/attachment-0001.png> > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 16 Nov 2016 13:01:59 +0100 > > From: Sumit Bose > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item > > returned a password > > Message-ID: > > <20161116120159.GL28171 at p.Speedport_W_724V_Typ_A_ > 05011603_00_009> > > Content-Type: text/plain; charset=us-ascii > > > > On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote: > > > I am using FreeIPA version 4.4.0 Active Directory trust setup. And on > > > Active Directory side I am using UPN suffix. > > > Following are my domain setup. > > > > > > AD DOMANIN :- corp.addomain.com > > > UPN suffix :- username at mydomain.com > > > IPA DOMAIN :- ipa.ipadomain.local > > > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local > > > > When you call 'ipa trust-find' on the IPA server do you see the > > mydomain.com UPN suffix listed, like e.g.: > > > > # ipa trust-find > > --------------- > > 1 trust matched > > --------------- > > Realm-Name: ad.devel > > Domain NetBIOS name: AD > > Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199 > > Trust type: Active Directory domain > > UPN suffixes: alt.alt, alt.upn.suffix > > > > SSSD 1.14 and above on the IPA client should enable enterprise principal > > support automatically if UPN suffixes are found on the server but > > according to > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [false] UPN [ > Rajat.Gupta at MYDOMAIN.COM > > ] > > > > it is not. If the UPN suffixes are not know on the server, calling 'ipa > > trust-fetch-domains' might help to get them. If there are still no UPN > > suffixes > > available on the server you can switch on enterprise principal on the > > client > > manually by adding 'krb5_use_enterprise_principal = True' in the > > [domain/...] > > section of sssd.conf. You have to set it manually as well if you are > using > > older versions of SSSD. > > > > HTH > > > > bye, > > Sumit > > > > > > > > > > > I am able to login with AD user on IPA server. But on IPA clinet i am > not > > > able to login i am getting the login message "Access denied". I have > > > enabled the debug_level on sssd.conf on ipa clinet. > > > > > > below are some logs.. > > > ================ > > > /var/log/secure > > > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): > > authentication > > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989 > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received > for > > > user e600336: 6 (Permission denied) > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting > > > password (0x00000010) > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > > > pam_get_item returned a password > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > internal > > > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 > from > > > x.x.x.x. port 48842 ssh2 > > > ================ > > > > > > ================ > > > krb5_child.log > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): > > > krb5_child completed successfully > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > > krb5_child started. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > (0x1000): total buffer size: [159] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [false] UPN [ > > Rajat.Gupta at MYDOMAIN.COM] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > > (0x0200): Switch user to [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > > (0x0200): Switch user to [0][0]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] > > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [find_principal_in_keytab] (0x4000): Trying to find principal > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] > > > (0x1000): Principal matched to the sample > > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [check_fast_ccache] > > > (0x0200): FAST TGT is still valid. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] > > (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [set_lifetime_options] (0x0100): Cannot read > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > from environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > > [true] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > Will > > > perform online auth > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] > > > (0x1000): Attempting to get a TGT > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [get_and_save_tgt] > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST > armor > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: > Retrieving > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > -1765328243/Matching credential not found > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending > > > request (164 bytes) to MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying > AS > > > request with master KDC > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST > armor > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: > Retrieving > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > -1765328243/Matching credential not found > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > [get_and_save_tgt] > > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] > > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > > (0x0200): Received error code 1432158228 > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > [pack_response_packet] (0x2000): response packet size: [4] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > > krb5_child completed successfully > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > > krb5_child started. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > (0x1000): total buffer size: [159] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [false] UPN [ > > Rajat.Gupta at MYDOMAIN.COM] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > > (0x0200): Switch user to [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > > (0x0200): Switch user to [0][0]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] > > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [find_principal_in_keytab] (0x4000): Trying to find principal > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] > > > (0x1000): Principal matched to the sample > > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [check_fast_ccache] > > > (0x0200): FAST TGT is still valid. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] > > (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [set_lifetime_options] (0x0100): Cannot read > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > from environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > > [true] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > Will > > > perform online auth > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] > > > (0x1000): Attempting to get a TGT > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [get_and_save_tgt] > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST > armor > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: > Retrieving > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > -1765328243/Matching credential not found > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending > > > request (164 bytes) to MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying > AS > > > request with master KDC > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST > armor > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: > Retrieving > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > -1765328243/Matching credential not found > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > [get_and_save_tgt] > > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] > > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > "] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > > (0x0200): Received error code 1432158228 > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > [pack_response_packet] (0x2000): response packet size: [4] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > > krb5_child completed successfully > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > > krb5_child started. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > (0x1000): total buffer size: [159] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [true] UPN [ > > Rajat.Gupta at MYDOMAIN.COM] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > > (0x0200): Switch user to [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > > (0x0200): Switch user to [0][0]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > (0x0200): Already user [1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] > > (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [set_lifetime_options] (0x0100): Cannot read > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > from environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > environment. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > Will > > > perform offline auth > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [create_empty_ccache] > > > (0x1000): Existing ccache still valid, reusing > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > > (0x0200): Received error code 0 > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [pack_response_packet] (0x2000): response packet size: [53] > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > > krb5_child completed successfully > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > > krb5_child started. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > > (0x1000): total buffer size: [52] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > > (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [true] UPN [ > > Rajat.Gupta at MYDOMAIN.COM] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > (0x0200): Already user [1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] > > (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [set_lifetime_options] (0x0100): Cannot read > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > from environment. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > environment. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > Will > > > perform pre-auth > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] > > > (0x1000): Attempting to get a TGT > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [get_and_save_tgt] > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending > > > request (164 bytes) to MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying > AS > > > request with master KDC > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > [get_and_save_tgt] > > > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > > > pre-auth. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > > (0x0200): Received error code 0 > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > [pack_response_packet] (0x2000): response packet size: [4] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > > krb5_child completed successfully > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > > krb5_child started. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > (0x1000): total buffer size: [160] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [true] UPN [ > > Rajat.Gupta at MYDOMAIN.COM] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > > (0x0200): Switch user to [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > > (0x0200): Switch user to [0][0]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > (0x0200): Already user [1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] > > (0x2000): > > > Running as [1007656917][1007656917]. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [set_lifetime_options] (0x0100): Cannot read > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > from environment. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > environment. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > Will > > > perform offline auth > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [create_empty_ccache] > > > (0x1000): Existing ccache still valid, reusing > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > > (0x0200): Received error code 0 > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [pack_response_packet] (0x2000): response packet size: [53] > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > > krb5_child completed successfully > > > > > > ======================= > > > Can you please help me to fix this, > > > > > -- > > > Manage your subscription for the Freeipa-users mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go to http://freeipa.org for more info on the project > > > > > > > > ------------------------------ > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > End of Freeipa-users Digest, Vol 100, Issue 48 > > ********************************************** > > > > > > -- > > *Rajat Gupta * > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20161116/ae006992/attachment.html> > > ------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > End of Freeipa-users Digest, Vol 100, Issue 49 > ********************************************** > -- *Rajat Gupta * -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Nov 16 14:10:49 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 16 Nov 2016 15:10:49 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: References: Message-ID: <20161116141049.GP28171@p.Speedport_W_724V_Typ_A_05011603_00_009> On Wed, Nov 16, 2016 at 02:41:34PM +0100, Martin Babinsky wrote: > On 11/16/2016 02:33 PM, Petr Spacek wrote: > > On 16.11.2016 14:01, Stijn De Weirdt wrote: > > > hi all, > > > > > > we are looking how to configure whatever relevant policy to minimise the > > > impact of compromised IPA hosts (ie servers with a valid host keytab). > > > > > > in particular, it looks like it possible to retrieve any user token once > > > you have access to a valid host keytab. > > > > > > we're aware that the default IPA policies are wide open, but we are > > > looking how to limit this. for us, there's no need that a hostkeytab can > > > retrieve tokens for anything except the services on that host. > > > > What "token" do you have in mind? > > > We discussed this in another thread. > > In the case that the host is compromised/stolen/hijacked, you can > host-disable it to invalidate the keytab stored there but this does not > prevent anyone logged on that host to bruteforce/DOS user accounts by trying > to guess their Kerberos keys by repeated kinit. But the password policy should at least mitigate this by blocking the account for some time after a number of wrong password are used. bye, Sumit > > -- > Martin^3 Babinsky > > -- > 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 mbabinsk at redhat.com Wed Nov 16 14:17:21 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 16 Nov 2016 15:17:21 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: <20161116141049.GP28171@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161116141049.GP28171@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <58bf51db-12f7-6269-f219-96236a8b6a07@redhat.com> On 11/16/2016 03:10 PM, Sumit Bose wrote: > On Wed, Nov 16, 2016 at 02:41:34PM +0100, Martin Babinsky wrote: >> On 11/16/2016 02:33 PM, Petr Spacek wrote: >>> On 16.11.2016 14:01, Stijn De Weirdt wrote: >>>> hi all, >>>> >>>> we are looking how to configure whatever relevant policy to minimise the >>>> impact of compromised IPA hosts (ie servers with a valid host keytab). >>>> >>>> in particular, it looks like it possible to retrieve any user token once >>>> you have access to a valid host keytab. >>>> >>>> we're aware that the default IPA policies are wide open, but we are >>>> looking how to limit this. for us, there's no need that a hostkeytab can >>>> retrieve tokens for anything except the services on that host. >>> >>> What "token" do you have in mind? >>> >> We discussed this in another thread. >> >> In the case that the host is compromised/stolen/hijacked, you can >> host-disable it to invalidate the keytab stored there but this does not >> prevent anyone logged on that host to bruteforce/DOS user accounts by trying >> to guess their Kerberos keys by repeated kinit. > > But the password policy should at least mitigate this by blocking the > account for some time after a number of wrong password are used. > > bye, > Sumit > Yes after (by default 6 IIRC) failed attempts it should lock out the account making brute-forcing the credentials highly impractical. It will, however, prevent a legitimate authentication of that user against the IPA master where the lockout is in place. >> >> -- >> Martin^3 Babinsky >> >> -- >> 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 > -- Martin^3 Babinsky From sbose at redhat.com Wed Nov 16 14:19:12 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 16 Nov 2016 15:19:12 +0100 Subject: [Freeipa-users] Freeipa-users Digest, Vol 100, Issue 49 In-Reply-To: References: Message-ID: <20161116141912.GQ28171@p.Speedport_W_724V_Typ_A_05011603_00_009> On Wed, Nov 16, 2016 at 03:06:34PM +0100, rajat gupta wrote: > Hi sumit, > > you mean to say these? > > ]# grep pam_winbind /etc/pam.d/password-auth > auth sufficient pam_winbind.so use_first_pass > account [default=bad success=ok user_unknown=ignore] pam_winbind.so > password sufficient pam_winbind.so use_authtok > session optional pam_winbind.so yes, in general pam_winbind is not needed on IPA clients, is there a reason why you added it? Btw, please try to reply to the thread, otherwise is it hard to find you replies. bye, Sumit > > > On Wed, Nov 16, 2016 at 2:32 PM, wrote: > > > Send Freeipa-users mailing list submissions to > > freeipa-users at redhat.com > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.redhat.com/mailman/listinfo/freeipa-users > > or, via email, send a message with subject or body 'help' to > > freeipa-users-request at redhat.com > > > > You can reach the person managing the list at > > freeipa-users-owner at redhat.com > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Freeipa-users digest..." > > > > > > Today's Topics: > > > > 1. minimise impact compromised host (Stijn De Weirdt) > > 2. Re: pam_winbind(sshd:auth): pam_get_item returned a password > > (Sumit Bose) > > 3. Re: Freeipa-users Digest, Vol 100, Issue 48 (rajat gupta) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 16 Nov 2016 14:01:09 +0100 > > From: Stijn De Weirdt > > To: freeipa-users at redhat.com > > Subject: [Freeipa-users] minimise impact compromised host > > Message-ID: > > Content-Type: text/plain; charset=utf-8 > > > > hi all, > > > > we are looking how to configure whatever relevant policy to minimise the > > impact of compromised IPA hosts (ie servers with a valid host keytab). > > > > in particular, it looks like it possible to retrieve any user token once > > you have access to a valid host keytab. > > > > we're aware that the default IPA policies are wide open, but we are > > looking how to limit this. for us, there's no need that a hostkeytab can > > retrieve tokens for anything except the services on that host. > > > > > > stijn > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 16 Nov 2016 14:25:00 +0100 > > From: Sumit Bose > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item > > returned a password > > Message-ID: > > <20161116132500.GO28171 at p.Speedport_W_724V_Typ_A_05011603_00_009> > > Content-Type: text/plain; charset=us-ascii > > > > On Wed, Nov 16, 2016 at 01:01:59PM +0100, Sumit Bose wrote: > > > On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote: > > > > I am using FreeIPA version 4.4.0 Active Directory trust setup. And on > > > > Active Directory side I am using UPN suffix. > > > > Following are my domain setup. > > > > > > > > AD DOMANIN :- corp.addomain.com > > > > UPN suffix :- username at mydomain.com > > > > IPA DOMAIN :- ipa.ipadomain.local > > > > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local > > > > > > When you call 'ipa trust-find' on the IPA server do you see the > > > mydomain.com UPN suffix listed, like e.g.: > > > > > > # ipa trust-find > > > --------------- > > > 1 trust matched > > > --------------- > > > Realm-Name: ad.devel > > > Domain NetBIOS name: AD > > > Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199 > > > Trust type: Active Directory domain > > > UPN suffixes: alt.alt, alt.upn.suffix > > > > > > SSSD 1.14 and above on the IPA client should enable enterprise principal > > > support automatically if UPN suffixes are found on the server but > > according to > > > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > enterprise principal [false] offline [false] UPN [Rajat.Gupta at MYDOMAIN.COM > > ] > > > > > > it is not. If the UPN suffixes are not know on the server, calling 'ipa > > > trust-fetch-domains' might help to get them. If there are still no UPN > > suffixes > > > available on the server you can switch on enterprise principal on the > > client > > > manually by adding 'krb5_use_enterprise_principal = True' in the > > [domain/...] > > > section of sssd.conf. You have to set it manually as well if you are > > using > > > older versions of SSSD. > > > > > > HTH > > > > > > bye, > > > Sumit > > > > > > > > > > > > > > > I am able to login with AD user on IPA server. But on IPA clinet i am > > not > > > > able to login i am getting the login message "Access denied". I have > > > > enabled the debug_level on sssd.conf on ipa clinet. > > > > > > > > below are some logs.. > > > > ================ > > > > /var/log/secure > > > > > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): > > authentication > > > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989 > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received > > for > > > > user e600336: 6 (Permission denied) > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting > > > > password (0x00000010) > > > > By the way, why do you have pam_winbind in the PAM configuration? > > > > bye, > > Sumit > > > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > > > > pam_get_item returned a password > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > > internal > > > > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 > > from > > > > x.x.x.x. port 48842 ssh2 > > > > ================ > > > > > > > > ================ > > > > krb5_child.log > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [159] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > > enterprise principal [false] offline [false] UPN [ > > Rajat.Gupta at MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > > > (0x0200): Switch user to [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > > > (0x0200): Switch user to [0][0]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] > > > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [find_principal_in_keytab] (0x4000): Trying to find principal > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] > > > > (0x1000): Principal matched to the sample > > > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [check_fast_ccache] > > > > (0x0200): FAST TGT is still valid. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] > > (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [set_lifetime_options] (0x0100): Cannot read > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > > from environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > > environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > > [true] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > Will > > > > perform online auth > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] > > > > (0x1000): Attempting to get a TGT > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [get_and_save_tgt] > > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST > > armor > > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: > > Retrieving > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > > -1765328243/Matching credential not found > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending > > > > request (164 bytes) to MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying > > AS > > > > request with master KDC > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST > > armor > > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: > > Retrieving > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > > -1765328243/Matching credential not found > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending > > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [get_and_save_tgt] > > > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > > "] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] > > > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > > "] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > > > (0x0200): Received error code 1432158228 > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [pack_response_packet] (0x2000): response packet size: [4] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [159] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > > enterprise principal [false] offline [false] UPN [ > > Rajat.Gupta at MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > > > (0x0200): Switch user to [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > > > (0x0200): Switch user to [0][0]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] > > > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [find_principal_in_keytab] (0x4000): Trying to find principal > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] > > > > (0x1000): Principal matched to the sample > > > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [check_fast_ccache] > > > > (0x0200): FAST TGT is still valid. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] > > (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [set_lifetime_options] (0x0100): Cannot read > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > > from environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > > environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > > [true] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > Will > > > > perform online auth > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] > > > > (0x1000): Attempting to get a TGT > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [get_and_save_tgt] > > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST > > armor > > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: > > Retrieving > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > > -1765328243/Matching credential not found > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending > > > > request (164 bytes) to MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying > > AS > > > > request with master KDC > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST > > armor > > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: > > Retrieving > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > > -1765328243/Matching credential not found > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending > > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [get_and_save_tgt] > > > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > > "] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] > > > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > > "] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > > > (0x0200): Received error code 1432158228 > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [pack_response_packet] (0x2000): response packet size: [4] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [159] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > > enterprise principal [false] offline [true] UPN [ > > Rajat.Gupta at MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > > > (0x0200): Switch user to [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > > > (0x0200): Switch user to [0][0]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > > (0x0200): Already user [1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] > > (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > > [set_lifetime_options] (0x0100): Cannot read > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > > from environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > > environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > Will > > > > perform offline auth > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > [create_empty_ccache] > > > > (0x1000): Existing ccache still valid, reusing > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > > > (0x0200): Received error code 0 > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > > [pack_response_packet] (0x2000): response packet size: [53] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [52] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > > > (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] > > > > enterprise principal [false] offline [true] UPN [ > > Rajat.Gupta at MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > > (0x0200): Already user [1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] > > (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [set_lifetime_options] (0x0100): Cannot read > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > > from environment. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > > environment. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > Will > > > > perform pre-auth > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] > > > > (0x1000): Attempting to get a TGT > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [get_and_save_tgt] > > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending > > > > request (164 bytes) to MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying > > AS > > > > request with master KDC > > > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending > > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [get_and_save_tgt] > > > > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > > > > pre-auth. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > > > (0x0200): Received error code 0 > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [pack_response_packet] (0x2000): response packet size: [4] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [160] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > > enterprise principal [false] offline [true] UPN [ > > Rajat.Gupta at MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > > > (0x0200): Switch user to [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > > > (0x0200): Switch user to [0][0]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > > (0x0200): Already user [1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] > > (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > > [set_lifetime_options] (0x0100): Cannot read > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > > from environment. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > > environment. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > Will > > > > perform offline auth > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > [create_empty_ccache] > > > > (0x1000): Existing ccache still valid, reusing > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > > > (0x0200): Received error code 0 > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > > [pack_response_packet] (0x2000): response packet size: [53] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > > > > > ======================= > > > > Can you please help me to fix this, > > > > > > > -- > > > > 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 > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 16 Nov 2016 14:31:52 +0100 > > From: rajat gupta > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] Freeipa-users Digest, Vol 100, Issue 48 > > Message-ID: > > > mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Thanks, It is working for few user but not for every one. I have cleared > > the sssd cache as well. > > ===================== > > /var/log/secure > > > > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): authentication > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=146.213.0.134 > > user=kb1980 > > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): received for > > user kb1980: 6 (Permission denied) > > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): getting > > password (0x00000010) > > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): > > pam_get_item returned a password > > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): internal > > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'kb1980') > > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: Failed password for kb1980 from > > 146.213.0.134 port 51114 ssh2 > > Nov 16 14:06:48 ipa-clinet1 sshd[6852]: Connection closed by 146.213.0.134 > > [preauth] > > Nov 16 14:07:07 ipa-clinet1 sshd[3677]: pam_unix(sshd:session): session > > closed for user kb1980 > > > > ======================== > > krb5_child.log > > > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [unpack_buffer] > > (0x1000): total buffer size: [54] > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [unpack_buffer] > > (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true] > > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] > > (0x0200): Trying to become user [1007628631][1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x2000): > > Running as [1007628631][1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] > > (0x0200): Trying to become user [1007628631][1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] > > (0x0200): Already user [1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_setup] (0x2000): > > Running as [1007628631][1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): Will > > perform pre-auth > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [tgt_req_child] > > (0x1000): Attempting to get a TGT > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [get_and_save_tgt] > > (0x0400): Attempting kinit for realm [MYDOMAIN COM] > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.872554: Getting > > initial credentials for karan.b at MYDOMAIN COM > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.874607: Sending > > request (167 bytes) to MYDOMAIN COM > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898179: Retrying AS > > request with master KDC > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898221: Getting > > initial credentials for karan.b at MYDOMAIN COM > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898291: Sending > > request (167 bytes) to MYDOMAIN COM (master) > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [get_and_save_tgt] > > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > > pre-auth. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_send_data] > > (0x0200): Received error code 0 > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > > [pack_response_packet] (0x2000): response packet size: [4] > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > > (0x1000): total buffer size: [159] > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true] > > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > > (0x0100): ccname: [KEYRING:persistent:1007628631] old_ccname: > > [KEYRING:persistent:1007628631] keytab: [/etc/krb5.keytab] > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [switch_creds] > > (0x0200): Switch user to [1007628631][1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [switch_creds] > > (0x0200): Switch user to [0][0]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > [KEYRING:persistent:1007628631] and is not active and TGT is valid. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] > > (0x0200): Trying to become user [1007628631][1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x2000): > > Running as [1007628631][1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] > > (0x0200): Trying to become user [1007628631][1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] > > (0x0200): Already user [1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_setup] (0x2000): > > Running as [1007628631][1007628631]. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): Will > > perform offline auth > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [create_empty_ccache] > > (0x1000): Existing ccache still valid, reusing > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_send_data] > > (0x0200): Received error code 0 > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > > [pack_response_packet] (0x2000): response packet size: [53] > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [unpack_buffer] > > (0x1000): total buffer size: [54] > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [unpack_buffer] > > (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true] > > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] > > (0x0200): Trying to become user [1007628631][1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x2000): > > Running as [1007628631][1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] > > (0x0200): Trying to become user [1007628631][1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] > > (0x0200): Already user [1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_setup] (0x2000): > > Running as [1007628631][1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): Will > > perform pre-auth > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [tgt_req_child] > > (0x1000): Attempting to get a TGT > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [get_and_save_tgt] > > (0x0400): Attempting kinit for realm [MYDOMAIN COM] > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.494908: Getting > > initial credentials for karan.b at MYDOMAIN COM > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.496903: Sending > > request (167 bytes) to MYDOMAIN COM > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.497962: Retrying AS > > request with master KDC > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.497985: Getting > > initial credentials for karan.b at MYDOMAIN COM > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.498026: Sending > > request (167 bytes) to MYDOMAIN COM (master) > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [get_and_save_tgt] > > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > > pre-auth. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_send_data] > > (0x0200): Received error code 0 > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > > [pack_response_packet] (0x2000): response packet size: [4] > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): > > krb5_child completed successfully > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): > > krb5_child started. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > > (0x1000): total buffer size: [159] > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true] > > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > > (0x0100): ccname: [KEYRING:persistent:1007628631] old_ccname: > > [KEYRING:persistent:1007628631] keytab: [/etc/krb5.keytab] > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [switch_creds] > > (0x0200): Switch user to [1007628631][1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [switch_creds] > > (0x0200): Switch user to [0][0]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > [KEYRING:persistent:1007628631] and is not active and TGT is valid. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] > > (0x0200): Trying to become user [1007628631][1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x2000): > > Running as [1007628631][1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] > > (0x0200): Trying to become user [1007628631][1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] > > (0x0200): Already user [1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_setup] (0x2000): > > Running as [1007628631][1007628631]. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): Will > > perform offline auth > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [create_empty_ccache] > > (0x1000): Existing ccache still valid, reusing > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_send_data] > > (0x0200): Received error code 0 > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > > [pack_response_packet] (0x2000): response packet size: [53] > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_send_data] > > (0x4000): Response sent. > > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): > > krb5_child completed successfully > > > > On Wed, Nov 16, 2016 at 1:02 PM, wrote: > > > > > Send Freeipa-users mailing list submissions to > > > freeipa-users at redhat.com > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > or, via email, send a message with subject or body 'help' to > > > freeipa-users-request at redhat.com > > > > > > You can reach the person managing the list at > > > freeipa-users-owner at redhat.com > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of Freeipa-users digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Client x.x.xx - RFC 1918 response from Internet in > > > /var/log/messages (Bjarne Blichfeldt) > > > 2. Re: pam_winbind(sshd:auth): pam_get_item returned a password > > > (Sumit Bose) > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Wed, 16 Nov 2016 11:56:05 +0000 > > > From: Bjarne Blichfeldt > > > To: "freeipa-users at redhat.com" > > > Subject: [Freeipa-users] Client x.x.xx - RFC 1918 response from > > > Internet in /var/log/messages > > > Message-ID: > > > <89213DDB84447F44A8E8950A5C2185E0482EB1EE at SJN01013.jnmain00. > > > corp.jndata.net> > > > > > > Content-Type: text/plain; charset="us-ascii" > > > > > > Just updated a couple of free-ipa servers to: > > > ipa-server-dns-4.4.0-12.el7.noarch > > > redhat-release-server-7.3-7.el7.x86_64 > > > > > > Before the update, I resolved the issue with RFC messages by: > > > /etc/named.conf: > > > options { > > > disable-empty-zone "10.in-addr.arpa."; > > > : > > > > > > Now after the update the RFS messages has returned. I read in the > > > changelog for 4.4 that this issue was resolved. > > > What did I miss? > > > > > > > > > > > > > > > > > > > > > Venlig hilsen > > > > > > > > > Bjarne Blichfeldt > > > > > > > > > Infrastructure Services > > > > > > > > > > > > Direkte +4563636119 > > > > > > > > > Mobile +4521593270 > > > > > > > > > BJB at jndata.dk > > > > > > [cid:image005.png at 01D24008.CA6EF0F0] > > > > > > JN Data A/S > > > > > > * > > > > > > Havsteensvej 4 > > > > > > * > > > > > > 4000 Roskilde > > > > > > > > > Telefon 63 63 63 63/ Fax 63 63 63 64 > > > > > > > > > www.jndata.dk > > > > > > > > > [cid:image006.png at 01D24008.CA6EF0F0] > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: > > attachments/20161116/46aeee39/attachment.html> > > > -------------- next part -------------- > > > A non-text attachment was scrubbed... > > > Name: image005.png > > > Type: image/png > > > Size: 410 bytes > > > Desc: image005.png > > > URL: > > attachments/20161116/46aeee39/attachment.png> > > > -------------- next part -------------- > > > A non-text attachment was scrubbed... > > > Name: image006.png > > > Type: image/png > > > Size: 5487 bytes > > > Desc: image006.png > > > URL: > > attachments/20161116/46aeee39/attachment-0001.png> > > > > > > ------------------------------ > > > > > > Message: 2 > > > Date: Wed, 16 Nov 2016 13:01:59 +0100 > > > From: Sumit Bose > > > To: freeipa-users at redhat.com > > > Subject: Re: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item > > > returned a password > > > Message-ID: > > > <20161116120159.GL28171 at p.Speedport_W_724V_Typ_A_ > > 05011603_00_009> > > > Content-Type: text/plain; charset=us-ascii > > > > > > On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote: > > > > I am using FreeIPA version 4.4.0 Active Directory trust setup. And on > > > > Active Directory side I am using UPN suffix. > > > > Following are my domain setup. > > > > > > > > AD DOMANIN :- corp.addomain.com > > > > UPN suffix :- username at mydomain.com > > > > IPA DOMAIN :- ipa.ipadomain.local > > > > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local > > > > > > When you call 'ipa trust-find' on the IPA server do you see the > > > mydomain.com UPN suffix listed, like e.g.: > > > > > > # ipa trust-find > > > --------------- > > > 1 trust matched > > > --------------- > > > Realm-Name: ad.devel > > > Domain NetBIOS name: AD > > > Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199 > > > Trust type: Active Directory domain > > > UPN suffixes: alt.alt, alt.upn.suffix > > > > > > SSSD 1.14 and above on the IPA client should enable enterprise principal > > > support automatically if UPN suffixes are found on the server but > > > according to > > > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > enterprise principal [false] offline [false] UPN [ > > Rajat.Gupta at MYDOMAIN.COM > > > ] > > > > > > it is not. If the UPN suffixes are not know on the server, calling 'ipa > > > trust-fetch-domains' might help to get them. If there are still no UPN > > > suffixes > > > available on the server you can switch on enterprise principal on the > > > client > > > manually by adding 'krb5_use_enterprise_principal = True' in the > > > [domain/...] > > > section of sssd.conf. You have to set it manually as well if you are > > using > > > older versions of SSSD. > > > > > > HTH > > > > > > bye, > > > Sumit > > > > > > > > > > > > > > > I am able to login with AD user on IPA server. But on IPA clinet i am > > not > > > > able to login i am getting the login message "Access denied". I have > > > > enabled the debug_level on sssd.conf on ipa clinet. > > > > > > > > below are some logs.. > > > > ================ > > > > /var/log/secure > > > > > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): > > > authentication > > > > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989 > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received > > for > > > > user e600336: 6 (Permission denied) > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting > > > > password (0x00000010) > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > > > > pam_get_item returned a password > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): > > internal > > > > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') > > > > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 > > from > > > > x.x.x.x. port 48842 ssh2 > > > > ================ > > > > > > > > ================ > > > > krb5_child.log > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [159] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > > enterprise principal [false] offline [false] UPN [ > > > Rajat.Gupta at MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] > > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > > > (0x0200): Switch user to [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] > > > > (0x0200): Switch user to [0][0]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] > > > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [find_principal_in_keytab] (0x4000): Trying to find principal > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] > > > > (0x1000): Principal matched to the sample > > > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [check_fast_ccache] > > > > (0x0200): FAST TGT is still valid. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] > > > (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [set_lifetime_options] (0x0100): Cannot read > > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > > from environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > > environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > > > [true] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > > Will > > > > perform online auth > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] > > > > (0x1000): Attempting to get a TGT > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [get_and_save_tgt] > > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST > > armor > > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: > > Retrieving > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > > -1765328243/Matching credential not found > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending > > > > request (164 bytes) to MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying > > AS > > > > request with master KDC > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST > > armor > > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: > > Retrieving > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > > -1765328243/Matching credential not found > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending > > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > [get_and_save_tgt] > > > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > > "] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] > > > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > > "] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > > > (0x0200): Received error code 1432158228 > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] > > > > [pack_response_packet] (0x2000): response packet size: [4] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [159] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > > enterprise principal [false] offline [false] UPN [ > > > Rajat.Gupta at MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] > > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > > > (0x0200): Switch user to [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] > > > > (0x0200): Switch user to [0][0]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [k5c_precreate_ccache] (0x4000): Recreating ccache > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] > > > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > > > > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [find_principal_in_keytab] (0x4000): Trying to find principal > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] > > > > (0x1000): Principal matched to the sample > > > > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [check_fast_ccache] > > > > (0x0200): FAST TGT is still valid. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] > > > (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [set_lifetime_options] (0x0100): Cannot read > > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > > from environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > > environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > > > [true] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > > Will > > > > perform online auth > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] > > > > (0x1000): Attempting to get a TGT > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [get_and_save_tgt] > > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST > > armor > > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: > > Retrieving > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > > -1765328243/Matching credential not found > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending > > > > request (164 bytes) to MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying > > AS > > > > request with master KDC > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST > > armor > > > > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: > > Retrieving > > > > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> > > > > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM > > > > \@MYDOMAIN.COM at X-CACHECONF: from > > > > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: > > > > -1765328243/Matching credential not found > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending > > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > [get_and_save_tgt] > > > > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > > "] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] > > > > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM > > "] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > > > (0x0200): Received error code 1432158228 > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] > > > > [pack_response_packet] (0x2000): response packet size: [4] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [159] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > > enterprise principal [false] offline [true] UPN [ > > > Rajat.Gupta at MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] > > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > > > (0x0200): Switch user to [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] > > > > (0x0200): Switch user to [0][0]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] > > > > (0x0200): Already user [1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] > > > (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > > [set_lifetime_options] (0x0100): Cannot read > > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > > from environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > > environment. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > > Will > > > > perform offline auth > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > [create_empty_ccache] > > > > (0x1000): Existing ccache still valid, reusing > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > > > (0x0200): Received error code 0 > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] > > > > [pack_response_packet] (0x2000): response packet size: [53] > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [52] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] > > > > (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] > > > > enterprise principal [false] offline [true] UPN [ > > > Rajat.Gupta at MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] > > > > (0x0200): Already user [1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] > > > (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [set_lifetime_options] (0x0100): Cannot read > > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > > from environment. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > > environment. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > > Will > > > > perform pre-auth > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] > > > > (0x1000): Attempting to get a TGT > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [get_and_save_tgt] > > > > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending > > > > request (164 bytes) to MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying > > AS > > > > request with master KDC > > > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting > > > > initial credentials for Rajat.Gupta at MYDOMAIN.COM > > > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending > > > > request (164 bytes) to MYDOMAIN.COM (master) > > > > > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > [get_and_save_tgt] > > > > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > > > > pre-auth. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > > > (0x0200): Received error code 0 > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] > > > > [pack_response_packet] (0x2000): response packet size: [4] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [160] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] > > > > enterprise principal [false] offline [true] UPN [ > > > Rajat.Gupta at MYDOMAIN.COM] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] > > > > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: > > > > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > > > (0x0200): Switch user to [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] > > > > (0x0200): Switch user to [0][0]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > > [k5c_check_old_ccache] (0x4000): Ccache_file is > > > > [KEYRING:persistent:1007656917] and is not active and TGT is valid. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > > (0x0200): Trying to become user [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] > > > > (0x0200): Already user [1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] > > > (0x2000): > > > > Running as [1007656917][1007656917]. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > > [set_lifetime_options] (0x0100): Cannot read > > > [SSSD_KRB5_RENEWABLE_LIFETIME] > > > > from environment. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > > > environment. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > > Will > > > > perform offline auth > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > [create_empty_ccache] > > > > (0x1000): Existing ccache still valid, reusing > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > > > (0x0200): Received error code 0 > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] > > > > [pack_response_packet] (0x2000): response packet size: [53] > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] > > > > (0x4000): Response sent. > > > > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): > > > > krb5_child completed successfully > > > > > > > > ======================= > > > > Can you please help me to fix this, > > > > > > > -- > > > > Manage your subscription for the Freeipa-users mailing list: > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > Go to http://freeipa.org for more info on the project > > > > > > > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > End of Freeipa-users Digest, Vol 100, Issue 48 > > > ********************************************** > > > > > > > > > > > -- > > > > *Rajat Gupta * > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > attachments/20161116/ae006992/attachment.html> > > > > ------------------------------ > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > End of Freeipa-users Digest, Vol 100, Issue 49 > > ********************************************** > > > > > > -- > > *Rajat Gupta * > -- > 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 sbose at redhat.com Wed Nov 16 14:24:50 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 16 Nov 2016 15:24:50 +0100 Subject: [Freeipa-users] Freeipa-users Digest, Vol 100, Issue 48 In-Reply-To: References: Message-ID: <20161116142450.GR28171@p.Speedport_W_724V_Typ_A_05011603_00_009> On Wed, Nov 16, 2016 at 02:31:52PM +0100, rajat gupta wrote: > Thanks, It is working for few user but not for every one. I have cleared > the sssd cache as well. > ===================== > /var/log/secure > > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=146.213.0.134 > user=kb1980 > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): received for > user kb1980: 6 (Permission denied) > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): getting > password (0x00000010) > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): > pam_get_item returned a password > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): internal > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'kb1980') > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: Failed password for kb1980 from > 146.213.0.134 port 51114 ssh2 > Nov 16 14:06:48 ipa-clinet1 sshd[6852]: Connection closed by 146.213.0.134 > [preauth] > Nov 16 14:07:07 ipa-clinet1 sshd[3677]: pam_unix(sshd:session): session > closed for user kb1980 > > ======================== > krb5_child.log > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [unpack_buffer] > (0x1000): total buffer size: [54] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [unpack_buffer] > (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] ... > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] ... > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [unpack_buffer] > (0x1000): total buffer size: [54] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [unpack_buffer] > (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] ... > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] As you can see all attempts where done while SSSD is offline ("offline [true]") and enterprise principal is still set to 'false' so it is expected that authentication fails as long as there are no cached credentials, i.e. the user once authenticated successful and 'cache_credentials = True' is set in sssd.conf. Please check in the domain log why SSSD is offline and make sure enterprise principal is set to 'True' as described in my last email. HTH bye, Sumit From stijn.deweirdt at ugent.be Wed Nov 16 14:33:05 2016 From: stijn.deweirdt at ugent.be (Stijn De Weirdt) Date: Wed, 16 Nov 2016 15:33:05 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: References: Message-ID: hi martin, >>> we are looking how to configure whatever relevant policy to minimise the >>> impact of compromised IPA hosts (ie servers with a valid host keytab). >>> >>> in particular, it looks like it possible to retrieve any user token once >>> you have access to a valid host keytab. >>> >>> we're aware that the default IPA policies are wide open, but we are >>> looking how to limit this. for us, there's no need that a hostkeytab can >>> retrieve tokens for anything except the services on that host. >> >> What "token" do you have in mind? >> > We discussed this in another thread. this is a different question: what can we do such that compromised host can do a little as possible if the admin doesn't (yet) know the host is compromised. the default policy allows way too much. how to clean it up once you know the host is compromised is the subject of the other thread. stijn > > In the case that the host is compromised/stolen/hijacked, you can > host-disable it to invalidate the keytab stored there but this does not > prevent anyone logged on that host to bruteforce/DOS user accounts by > trying to guess their Kerberos keys by repeated kinit. > From bnordgren at fs.fed.us Wed Nov 16 15:39:09 2016 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Wed, 16 Nov 2016 15:39:09 +0000 Subject: [Freeipa-users] Actions for a stolen/compromised IPA Client In-Reply-To: References: <8f1b5270-a0a1-1f81-5956-982396531f31@redhat.com> Message-ID: Ummm, Kinit should work from any host, whether that host is part of the domain or not. It contains no inherent knowledge of any passwords. If it succeeds, then you either picked a bad password, stored the password in a plaintext file, or an actual authorized user ran it. It seems that it would make more sense to fret about how to somehow revoke any TGTs already issued to that machine. Kinit authenticates the person running it, not the host it is running from. In your example, it successfully authenticated you because you know your admin password. If an attacker knows your admin password, focusing on your one compromised host is _not_ where you should be spending your energies. Bryce -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Paessens, Daniel Sent: Wednesday, November 16, 2016 2:58 AM To: Martin Babinsky ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Actions for a stolen/compromised IPA Client Indeed the kinit keeps working correctly. If you give a good password it retrieves the tokens correctly. Thus it's not only DOS, but also an potentional brutal password retriever as well. Blocking on firewall level,ok, but what if you use DHCP. It's more difficult to protect it, through that way. Daniel -----Original Message----- From: Martin Babinsky [mailto:mbabinsk at redhat.com] Sent: Wednesday, November 16, 2016 10:30 AM To: Paessens, Daniel ; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Actions for a stolen/compromised IPA Client On 11/16/2016 10:04 AM, Paessens, Daniel wrote: > Currently am I looking for a workable solution for the following situation: > Let's say that an ipa client has been stolen (or compromised). > What can we do to block all access from it, towards IPA (and rest) > For example if we use the command "ipa host-disable" it's noticed > that IPA users are no longer able to login into the system. But if you > log into the system as root. Then you can still run (successfully) the > command kinit, and optain a ticket for it. > Even if you delete the host from the directory, the behavior > remains the same. > Can this anyhow be blocked. > Regards, > Daniel > > > Hi Daniel, host-disable removes the host kerberos keys and certificates from LDAP as you correctly observer. This means that all services on the compromised host stop working. SSSD will also stop working since it uses the now invalid host keytab to perform user lookup, that's why ssh'ing to host as IPA user stops working. However, there is nothing preventing the attacker to try to kinit as admin directly without sssd on the machine, which can potentialy lead to DoS attack on the admin user. So if you realize that the host was compromised it is best to first run hist-disable and then block all traffic from that host on ports 88 tcp/udp (Kerberos), 464 tcp/udp (kadmin), 749 tcp/udp (kpasswd IIRC) and LDAP(S) ports (389, 636 tcp). -- Martin^3 Babinsky -- 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 This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From jbaird at follett.com Wed Nov 16 15:40:18 2016 From: jbaird at follett.com (Baird, Josh) Date: Wed, 16 Nov 2016 15:40:18 +0000 Subject: [Freeipa-users] IPA 4.4 and Trust Agents/Controllers Message-ID: Hi, I'm currently testing an IPA 4.3 (RHEL 7.2) to IPA 4.4 (RHEL 7.3) upgrade and had a few questions about the concept of trust agents/controllers. Prior to IPA 4.4, were all IPA masters (that 'ipa-adtrust-install' was ran on) considered 'trust controllers'? In my lab, the upgrade automatically provisioned my IPA masters as controllers (not agents). Is this the default behavior? The official recommendation appears to be to minimize the number of trust controllers. Given an IPA deployment with two masters in each location, is the recommendation to only have 1 of these configured as a 'trust controller' and the other as a 'trust agent'? What happens if all 'trust controllers' become unavailable, but 'trust agents' remain available? Will the trust between IPA and AD be broken? Thanks, Josh From pspacek at redhat.com Wed Nov 16 15:53:41 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Nov 2016 16:53:41 +0100 Subject: [Freeipa-users] IPA 4.4 and Trust Agents/Controllers In-Reply-To: References: Message-ID: <37bec4bb-1cfd-36a1-b7a5-8718190def69@redhat.com> On 16.11.2016 16:40, Baird, Josh wrote: > Hi, > > I'm currently testing an IPA 4.3 (RHEL 7.2) to IPA 4.4 (RHEL 7.3) upgrade and had a few questions about the concept of trust agents/controllers. > > Prior to IPA 4.4, were all IPA masters (that 'ipa-adtrust-install' was ran on) considered 'trust controllers'? In my lab, the upgrade automatically provisioned my IPA masters as controllers (not agents). Is this the default behavior? I would recommend to read https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/creating-trusts.html#trust-controller-agent > The official recommendation appears to be to minimize the number of trust controllers. Given an IPA deployment with two masters in each location, is the recommendation to only have 1 of these configured as a 'trust controller' and the other as a 'trust agent'? > > What happens if all 'trust controllers' become unavailable, but 'trust agents' remain available? Will the trust between IPA and AD be broken? ... Trust controllers can be used for trust management operations, such as adding trust agreements and enabling or disabling separate domains from a trusted forest to access IdM resources. Additionally, AD domain controllers contact trust controllers when validating the trust. If I'm not mistaken, temporary unavailability of trust controller should not break the trust as it is used only for trust management operations. -- Petr^2 Spacek From pspacek at redhat.com Wed Nov 16 15:54:26 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Nov 2016 16:54:26 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: References: Message-ID: <520773e2-752d-8f4b-b770-3e079f2a7045@redhat.com> On 16.11.2016 15:33, Stijn De Weirdt wrote: > hi martin, > >>>> we are looking how to configure whatever relevant policy to minimise the >>>> impact of compromised IPA hosts (ie servers with a valid host keytab). >>>> >>>> in particular, it looks like it possible to retrieve any user token once >>>> you have access to a valid host keytab. >>>> >>>> we're aware that the default IPA policies are wide open, but we are >>>> looking how to limit this. for us, there's no need that a hostkeytab can >>>> retrieve tokens for anything except the services on that host. >>> >>> What "token" do you have in mind? >>> >> We discussed this in another thread. > this is a different question: what can we do such that compromised host > can do a little as possible if the admin doesn't (yet) know the host is > compromised. > > the default policy allows way too much. For any useful advice we need more details. What are the operations you want to disable? Petr^2 Spacek > > how to clean it up once you know the host is compromised is the subject > of the other thread. > > stijn > >> >> In the case that the host is compromised/stolen/hijacked, you can >> host-disable it to invalidate the keytab stored there but this does not >> prevent anyone logged on that host to bruteforce/DOS user accounts by >> trying to guess their Kerberos keys by repeated kinit. >> > -- Petr^2 Spacek From schogan at us.ibm.com Wed Nov 16 16:14:20 2016 From: schogan at us.ibm.com (Sean Hogan) Date: Wed, 16 Nov 2016 09:14:20 -0700 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: <20161116092207.sgfqdomuhhs62v4x@hendrix> References: <20161116092207.sgfqdomuhhs62v4x@hendrix> Message-ID: Hi Jakub, Thanks... here is output klist -ke [root at server1 rusers]# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) kinit -k odd though as kinit -k seems to fail but kinit with admin seems to work indicating I can hit the KDC even though kinit -k says I cannot? [root at server1 pam.d]# kinit -k server1 kinit: Keytab contains no suitable keys for server1 at IPA.LOCAL while getting initial credentials [root at server1 pam.d]# kinit -k server1.IPA.LOCAL kinit: Keytab contains no suitable keys for server1.IPA.LOCAL at IPA.LOCAL while getting initial credentials [root at server1 pam.d]# kinit admin Password for admin at ipa.local: [root at server1 pam.d]# [root at server1 pam.d]# klist Ticket cache: KEYRING:persistent:1111111111:1111111111 Default principal: admin at IPA.LOCAL Valid starting Expires Service principal 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/IPA.LOCAL at IPA.LOCAL [root at server1 pam.d]# ktutil ktutil: rkt /etc/krb5.keytab ktutil: l slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 1 host/server1.ipa.local at IPA.LOCAL 2 1 host/server1.ipa.local at IPA.LOCAL 3 1 host/server1.ipa.local at IPA.LOCAL 4 1 host/server1.ipa.local at IPA.LOCAL Added debug_level = 10 on the domain section of sssd.conf and restarted is all I see [root at server1 sssd]# cat ldap_child.log (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18951]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program lacks support for encryption type (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18954]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program lacks support for encryption type (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18956]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program lacks support for encryption type (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18957]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program lacks support for encryption type (Wed Nov 16 10:58:02 2016) [[sssd[ldap_child[18958]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program lacks support for encryption type (Wed Nov 16 10:59:26 2016) [[sssd[ldap_child[18977]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program lacks support for encryption type Additonal: [root at server1 rusers]# systemctl -l status sssd.service sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) Drop-In: /etc/systemd/system/sssd.service.d ??journal.conf Active: active (running) since Wed 2016-11-16 10:30:43 EST; 17s ago Process: 3041 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS) Main PID: 3042 (sssd) CGroup: /system.slice/sssd.service ??3042 /usr/sbin/sssd -D -f ??3043 /usr/libexec/sssd/sssd_be --domain ipa.local --uid 0 --gid 0 --debug-to-files ??3044 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files ??3045 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files ??3046 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files ??3047 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files ??3048 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files Nov 16 10:30:43 server1.ipa.local sssd[3042]: Starting up Nov 16 10:30:43 server1.ipa.local sssd[be[ipa.local]][3043]: Starting up Nov 16 10:30:43 server1.ipa.local sssd[sudo][3045]: Starting up Nov 16 10:30:43 server1.ipa.local sssd[pam][3046]: Starting up Nov 16 10:30:43 server1.ipa.local sssd[nss][3044]: Starting up Nov 16 10:30:43 server1.ipa.local sssd[ssh][3047]: Starting up Nov 16 10:30:43 server1.ipa.local sssd[pac][3048]: Starting up Nov 16 10:30:43 server1.ipa.local systemd[1]: Started System Security Services Daemon. Nov 16 10:30:55 server1.ipa.local [sssd[ldap_child[3055]]][3055]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP connection. [root at server1 rusers]# Seeing this in /var/log/sssd/sssd_ipa.local.log (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [be_process_init] (0x0010): fatal error initializing data providers (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [main] (0x0010): Could not initialize backend [14] (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [select_principal_from_keytab] (0x0010): Failed to read keytab [default]: Bad address (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [load_backend_module] (0x0010): Error (14) in module (ipa) initialization (sssm_ipa_id_init)! This is also strange but might be side effect I assume.. we mount NFS v4 home dir with automount for central homes and profiles.. on the boxes having this issue some of the IDs show just the UID numbers/GID numebrs where some of the IDs actually show the UID name/GID name. We have over 2k servers showing the UID name/GID name with no issues.. just the boxes having this issue. Sean Hogan From: Jakub Hrozek To: freeipa-users at redhat.com Date: 11/16/2016 02:29 AM Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server Sent by: freeipa-users-bounces at redhat.com On Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: > > > Hello, > > > I am starting to see some issues with a few RHEL7 boxes I have been > enrolling to my RHEL 6 IPA server regarding encryption. > > > RHEL 7 client > Red Hat Enterprise Linux Server release 7.1 (Maipo) > sssd-ipa-1.12.2-58.el7_1.18.x86_64 > ipa-client-4.1.0-18.el7_1.4.x86_64 > > RHEL 6 Server > Red Hat Enterprise Linux Server release 6.8 (Santiago) > sssd-ipa-1.13.3-22.el6_8.4.x86_64 > ipa-server-3.0.0-50.el6.1.x86_64 > > > The RHEL 7 client shows this in messages > > Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support > for encryption type Could you post a more verbose ldap_child log (debug_level=10 includes KRB5_TRACE-level messages) so that we see what kind of crypto was used? > Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize > credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity check > failed. Unable to create GSSAPI-encrypted LDAP connection. > > I am also not seeing host certs for them on the ipa server but I do see > them on the local box. > > [root at server1 pam.d]# ktutil Can you run klist -ke as well to see what encryption types are included in the keytab? Is it possible to run "kinit -k" on the client? > ktutil: rkt /etc/krb5.keytab > ktutil: l > slot KVNO Principal > ---- ---- > --------------------------------------------------------------------- > 1 1 host/server1.ipa.local at IPA.LOCAL > 2 1 host/server1.ipa.local at IPA.LOCAL > 3 1 host/server1.ipa.local at IPA.LOCAL > 4 1 host/server1.ipa.local at IPA.LOCAL > ktutil: > > > I have one RHEL 7 box with no issues as it was just enrolled (missing host > certs in IPA though) and I compared and IPA ID login with a box not > working > NOT Work > type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0 > auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 > msg='op=PAM:authentication grantors=? acct="janedoe" exe="/usr/sbin/sshd" > hostname=10.10.10.10 addr=10.10.10.9 terminal=ssh res=failed' > > vs > > Works > type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0 > auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 > msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit acct="janedoe" > exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh > res=success' > > Its almost as if the pam files are not being read? > > > > 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 -- 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: 0C304740.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0C635313.gif Type: image/gif Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From schogan at us.ibm.com Wed Nov 16 16:23:35 2016 From: schogan at us.ibm.com (Sean Hogan) Date: Wed, 16 Nov 2016 09:23:35 -0700 Subject: [Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads? In-Reply-To: References: <582B38AF.6010407@sonsorol.org><9518896f-2be2-85a8-17e7-16ca5851e613@redhat.com> Message-ID: Yes... just got 2 of them from same address.. kimi rachel Sean Hogan From: Tony Brian Albers To: "freeipa-users at redhat.com" Date: 11/15/2016 11:54 PM Subject: Re: [Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads? Sent by: freeipa-users-bounces at redhat.com Hehe, just you wait Lachlan ;) /tony On 11/16/2016 01:56 AM, Lachlan Musicman wrote: > Gah, just happened to me. Wasn't porn, but was someone called Kimi and > the only content was "Heeey Lachlan, how's it going?" > > L. > > ------ > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper > > On 16 November 2016 at 04:02, Martin Basti > wrote: > > > > On 15.11.2016 17:32, Chris Dagdigian wrote: > > > > Got a porn spam today that had a subject header of: > > Re: [Freeipa-users] URL is changing on the browser > > > Have to admit that got through my spam filter and got me to open > the email. > > It's clear that it was not a list message; looks like something > may be mining the public list archives to pull email addresses > and plausible sounding subject lines. > > Mildly interested if anyone else got an email like this? > > -Chris > > > We are receiving those emails as well (different subjects, domains, > but the same content) > > > -- > 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, Tony Albers Systems administrator, IT-development State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. Tel: +45 2566 2383 / +45 8946 2316 -- 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: 09123238.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 09140206.gif Type: image/gif Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Nov 16 16:32:58 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 16 Nov 2016 17:32:58 +0100 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: References: <20161116092207.sgfqdomuhhs62v4x@hendrix> Message-ID: <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> On 11/16/2016 05:14 PM, Sean Hogan wrote: > Hi Jakub, > > Thanks... here is output > > > *klist -ke* > [root at server1 rusers]# klist -ke > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) > 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) > 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) > 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) > > > > *kinit -k odd though as kinit -k seems to fail but kinit with admin > seems to work indicating I can hit the KDC even though kinit -k says I > cannot?* > > [root at server1 pam.d]# kinit -k server1 > kinit: Keytab contains no suitable keys for server1 at IPA.LOCAL while > getting initial credentials > [root at server1 pam.d]# kinit -k server1.IPA.LOCAL > kinit: Keytab contains no suitable keys for server1.IPA.LOCAL at IPA.LOCAL > while getting initial credentials You need to specify full principal name as printed from klist command, i.e. kinit -k /etc/krb5.keytab host/server1.ipa.local > [root at server1 pam.d]# kinit admin > Password for admin at ipa.local: > [root at server1 pam.d]# > [root at server1 pam.d]# klist > Ticket cache: KEYRING:persistent:1111111111:1111111111 > Default principal: admin at IPA.LOCAL > > Valid starting Expires Service principal > 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/IPA.LOCAL at IPA.LOCAL > > [root at server1 pam.d]# ktutil > ktutil: rkt /etc/krb5.keytab > ktutil: l > slot KVNO Principal > ---- ---- > --------------------------------------------------------------------- > 1 1 host/server1.ipa.local at IPA.LOCAL > 2 1 host/server1.ipa.local at IPA.LOCAL > 3 1 host/server1.ipa.local at IPA.LOCAL > 4 1 host/server1.ipa.local at IPA.LOCAL > > > > *Added debug_level = 10 on the domain section of sssd.conf and restarted > is all I see* > [root at server1 sssd]# cat ldap_child.log > (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18951]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18954]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18956]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18957]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > (Wed Nov 16 10:58:02 2016) [[sssd[ldap_child[18958]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > (Wed Nov 16 10:59:26 2016) [[sssd[ldap_child[18977]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > > > > > *Additonal:* > > [root at server1 rusers]# systemctl -l status sssd.service > sssd.service - System Security Services Daemon > Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) > Drop-In: /etc/systemd/system/sssd.service.d > ??journal.conf > Active: active (running) since Wed 2016-11-16 10:30:43 EST; 17s ago > Process: 3041 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS) > Main PID: 3042 (sssd) > CGroup: /system.slice/sssd.service > ??3042 /usr/sbin/sssd -D -f > ??3043 /usr/libexec/sssd/sssd_be --domain ipa.local --uid 0 --gid 0 > --debug-to-files > ??3044 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files > ??3045 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files > ??3046 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files > ??3047 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files > ??3048 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files > > Nov 16 10:30:43 server1.ipa.local sssd[3042]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[be[ipa.local]][3043]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[sudo][3045]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[pam][3046]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[nss][3044]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[ssh][3047]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[pac][3048]: Starting up > Nov 16 10:30:43 server1.ipa.local systemd[1]: Started System Security > Services Daemon. > Nov 16 10:30:55 server1.ipa.local [sssd[ldap_child[3055]]][3055]: Failed > to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: > Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP > connection. > [root at server1 rusers]# > > Seeing this in /var/log/sssd/sssd_ipa.local.log > > (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [be_process_init] > (0x0010): fatal error initializing data providers > (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [main] (0x0010): Could > not initialize backend [14] > (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] > [select_principal_from_keytab] (0x0010): Failed to read keytab > [default]: Bad address > (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [load_backend_module] > (0x0010): Error (14) in module (ipa) initialization (sssm_ipa_id_init)! > > This is also strange but might be side effect I assume.. we mount NFS v4 > home dir with automount for central homes and profiles.. on the boxes > having this issue some of the IDs show just the UID numbers/GID numebrs > where some of the IDs actually show the UID name/GID name. We have over > 2k servers showing the UID name/GID name with no issues.. just the boxes > having this issue. > > > > Sean Hogan > > > > > > > Inactive hide details for Jakub Hrozek ---11/16/2016 02:29:52 AM---On > Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: Jakub Hrozek > ---11/16/2016 02:29:52 AM---On Tue, Nov 15, 2016 at 07:24:38PM -0700, > Sean Hogan wrote: > > > From: Jakub Hrozek > To: freeipa-users at redhat.com > Date: 11/16/2016 02:29 AM > Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server > Sent by: freeipa-users-bounces at redhat.com > > ------------------------------------------------------------------------ > > > > On Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: >> >> >> Hello, >> >> >> I am starting to see some issues with a few RHEL7 boxes I have been >> enrolling to my RHEL 6 IPA server regarding encryption. >> >> >> RHEL 7 client >> Red Hat Enterprise Linux Server release 7.1 (Maipo) >> sssd-ipa-1.12.2-58.el7_1.18.x86_64 >> ipa-client-4.1.0-18.el7_1.4.x86_64 >> >> RHEL 6 Server >> Red Hat Enterprise Linux Server release 6.8 (Santiago) >> sssd-ipa-1.13.3-22.el6_8.4.x86_64 >> ipa-server-3.0.0-50.el6.1.x86_64 >> >> >> The RHEL 7 client shows this in messages >> >> Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support >> for encryption type > > Could you post a more verbose ldap_child log (debug_level=10 includes > KRB5_TRACE-level messages) so that we see what kind of crypto was used? > >> Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize >> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity > check >> failed. Unable to create GSSAPI-encrypted LDAP connection. >> >> I am also not seeing host certs for them on the ipa server but I do see >> them on the local box. >> >> [root at server1 pam.d]# ktutil > > Can you run klist -ke as well to see what encryption types are included > in the keytab? > > Is it possible to run "kinit -k" on the client? > >> ktutil: rkt /etc/krb5.keytab >> ktutil: l >> slot KVNO Principal >> ---- ---- >> --------------------------------------------------------------------- >> 1 1 host/server1.ipa.local at IPA.LOCAL >> 2 1 host/server1.ipa.local at IPA.LOCAL >> 3 1 host/server1.ipa.local at IPA.LOCAL >> 4 1 host/server1.ipa.local at IPA.LOCAL >> ktutil: >> >> >> I have one RHEL 7 box with no issues as it was just enrolled (missing host >> certs in IPA though) and I compared and IPA ID login with a box not >> working >> *NOT Work* >> type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0 >> auid=4294967295 ses=4294967295 > subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >> msg='op=PAM:authentication grantors=? acct="janedoe" exe="/usr/sbin/sshd" >> hostname=10.10.10.10 addr=10.10.10.9 terminal=ssh res=failed' >> >> vs >> >> Works >> type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0 >> auid=4294967295 ses=4294967295 > subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >> msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit acct="janedoe" >> exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh >> res=success' >> >> Its almost as if the pam files are not being read? >> >> >> >> 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 > > -- > 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 > > > > > > -- Martin^3 Babinsky From stijn.deweirdt at ugent.be Wed Nov 16 16:47:12 2016 From: stijn.deweirdt at ugent.be (Stijn De Weirdt) Date: Wed, 16 Nov 2016 17:47:12 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: <520773e2-752d-8f4b-b770-3e079f2a7045@redhat.com> References: <520773e2-752d-8f4b-b770-3e079f2a7045@redhat.com> Message-ID: >> this is a different question: what can we do such that compromised host >> can do a little as possible if the admin doesn't (yet) know the host is >> compromised. >> >> the default policy allows way too much. > > For any useful advice we need more details. > > What are the operations you want to disable? at the very least, "kvno userlogin" should fail (i.e. access to a host keytab shouldn't permit retrieval of arbitrary user token). i'm assuming that retrieval of service tokens for another host is already not possible? (ie if you have keyatb of fqdn1, you shouldn't be able to retrieve a token for SERVICE/fqdn2 at REALM). stijn > > Petr^2 Spacek > > >> >> how to clean it up once you know the host is compromised is the subject >> of the other thread. >> >> stijn >> >>> >>> In the case that the host is compromised/stolen/hijacked, you can >>> host-disable it to invalidate the keytab stored there but this does not >>> prevent anyone logged on that host to bruteforce/DOS user accounts by >>> trying to guess their Kerberos keys by repeated kinit. >>> >> > > From rcritten at redhat.com Wed Nov 16 16:55:14 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Nov 2016 11:55:14 -0500 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: References: <520773e2-752d-8f4b-b770-3e079f2a7045@redhat.com> Message-ID: <582C8F72.7020203@redhat.com> Stijn De Weirdt wrote: >>> this is a different question: what can we do such that compromised host >>> can do a little as possible if the admin doesn't (yet) know the host is >>> compromised. >>> >>> the default policy allows way too much. >> >> For any useful advice we need more details. >> >> What are the operations you want to disable? > at the very least, "kvno userlogin" should fail (i.e. access to a host > keytab shouldn't permit retrieval of arbitrary user token). > > i'm assuming that retrieval of service tokens for another host is > already not possible? (ie if you have keyatb of fqdn1, you shouldn't be > able to retrieve a token for SERVICE/fqdn2 at REALM). To be more precise you get a service ticket. I'm not sure what the exposure is here. rob From Dan.Finkelstein at high5games.com Wed Nov 16 16:46:41 2016 From: Dan.Finkelstein at high5games.com (Dan.Finkelstein at high5games.com) Date: Wed, 16 Nov 2016 16:46:41 +0000 Subject: [Freeipa-users] Disabling Anonymous Binds (LDAP) Message-ID: <8F863F5E-1F26-49F5-AA81-FD12FCEFF395@high5games.com> I've seen some discussion in the (distant) past about disabling anonymous binds to the LDAP component of IPA, and I'm wondering if there's a preferred method to do it. Further, are there any known problems with disabling anonymous binds when using FreeIPA? The only modern documentation I can find is here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html, and I'm curious if FreeIPA has a different way. Thanks, Dan [id:image001.jpg at 01D1C26F.0E28FA60] Daniel Alex Finkelstein| Lead Dev Ops Engineer Dan.Finkelstein at h5g.com | 212.604.3447 One World Trade Center, New York, NY 10007 www.high5games.com Play High 5 Casino and Shake the Sky Follow us on: Facebook, Twitter, YouTube, Linkedin This message and any attachments may contain confidential or privileged information and are only for the use of the intended recipient of this message. If you are not the intended recipient, please notify the sender by return email, and delete or destroy this and all copies of this message and all attachments. Any unauthorized disclosure, use, distribution, or reproduction of this message or any attachments is prohibited and may be unlawful. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 4334 bytes Desc: image001.jpg URL: From schogan at us.ibm.com Wed Nov 16 16:56:59 2016 From: schogan at us.ibm.com (Sean Hogan) Date: Wed, 16 Nov 2016 09:56:59 -0700 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> References: <20161116092207.sgfqdomuhhs62v4x@hendrix> <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> Message-ID: Sorry.. listing ouput of klist -e and klist -ke... but kinit -k does not seem to be working if I have it right.. kinit -kt is more promising but still fails Klists [root at server1 read]# klist -e Ticket cache: KEYRING:persistent:111111111:11111111111 Default principal: admin at ipa.local Valid starting Expires Service principal 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/ipa.local at IPA.LOCAL Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 [root at server1 read]# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) Kinits [root at server1 read]# kinit -k /etc/krb5.keytab host/server1.ipa.local Extra arguments (starting with "host/server1.ipa.local"). Usage: kinit [-V] [-l lifetime] [-s start_time] [-r renewable_life] [-f | -F] [-p | -P] -n [-a | -A] [-C] [-E] [-v] [-R] [-k [-i|-t keytab_file]] [-c cachename] [-S service_name] [-T ticket_armor_cache] [-X [=]] [principal] options: -V verbose -l lifetime -s start time -r renewable lifetime -f forwardable -F not forwardable -p proxiable -P not proxiable -n anonymous -a include addresses -A do not include addresses -v validate -R renew -C canonicalize -E client is enterprise principal name -k use keytab -i use default client keytab (with -k) -t filename of keytab to use -c Kerberos 5 cache name -S service -T armor credential cache -X [=] [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local kinit: Cannot contact any KDC for realm 'IPA.LOCAL' while getting initial credentials [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local kinit: Program lacks support for encryption type while getting initial credentials Sean Hogan From: Martin Babinsky To: Sean Hogan/Durham/IBM at IBMUS, Jakub Hrozek Cc: freeipa-users at redhat.com Date: 11/16/2016 09:33 AM Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server On 11/16/2016 05:14 PM, Sean Hogan wrote: > Hi Jakub, > > Thanks... here is output > > > *klist -ke* > [root at server1 rusers]# klist -ke > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) > 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) > 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) > 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) > > > > *kinit -k odd though as kinit -k seems to fail but kinit with admin > seems to work indicating I can hit the KDC even though kinit -k says I > cannot?* > > [root at server1 pam.d]# kinit -k server1 > kinit: Keytab contains no suitable keys for server1 at IPA.LOCAL while > getting initial credentials > [root at server1 pam.d]# kinit -k server1.IPA.LOCAL > kinit: Keytab contains no suitable keys for server1.IPA.LOCAL at IPA.LOCAL > while getting initial credentials You need to specify full principal name as printed from klist command, i.e. kinit -k /etc/krb5.keytab host/server1.ipa.local > [root at server1 pam.d]# kinit admin > Password for admin at ipa.local: > [root at server1 pam.d]# > [root at server1 pam.d]# klist > Ticket cache: KEYRING:persistent:1111111111:1111111111 > Default principal: admin at IPA.LOCAL > > Valid starting Expires Service principal > 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/IPA.LOCAL at IPA.LOCAL > > [root at server1 pam.d]# ktutil > ktutil: rkt /etc/krb5.keytab > ktutil: l > slot KVNO Principal > ---- ---- > --------------------------------------------------------------------- > 1 1 host/server1.ipa.local at IPA.LOCAL > 2 1 host/server1.ipa.local at IPA.LOCAL > 3 1 host/server1.ipa.local at IPA.LOCAL > 4 1 host/server1.ipa.local at IPA.LOCAL > > > > *Added debug_level = 10 on the domain section of sssd.conf and restarted > is all I see* > [root at server1 sssd]# cat ldap_child.log > (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18951]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18954]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18956]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18957]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > (Wed Nov 16 10:58:02 2016) [[sssd[ldap_child[18958]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > (Wed Nov 16 10:59:26 2016) [[sssd[ldap_child[18977]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program > lacks support for encryption type > > > > > *Additonal:* > > [root at server1 rusers]# systemctl -l status sssd.service > sssd.service - System Security Services Daemon > Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) > Drop-In: /etc/systemd/system/sssd.service.d > ??journal.conf > Active: active (running) since Wed 2016-11-16 10:30:43 EST; 17s ago > Process: 3041 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS) > Main PID: 3042 (sssd) > CGroup: /system.slice/sssd.service > ??3042 /usr/sbin/sssd -D -f > ??3043 /usr/libexec/sssd/sssd_be --domain ipa.local --uid 0 --gid 0 > --debug-to-files > ??3044 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files > ??3045 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files > ??3046 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files > ??3047 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files > ??3048 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files > > Nov 16 10:30:43 server1.ipa.local sssd[3042]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[be[ipa.local]][3043]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[sudo][3045]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[pam][3046]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[nss][3044]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[ssh][3047]: Starting up > Nov 16 10:30:43 server1.ipa.local sssd[pac][3048]: Starting up > Nov 16 10:30:43 server1.ipa.local systemd[1]: Started System Security > Services Daemon. > Nov 16 10:30:55 server1.ipa.local [sssd[ldap_child[3055]]][3055]: Failed > to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: > Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP > connection. > [root at server1 rusers]# > > Seeing this in /var/log/sssd/sssd_ipa.local.log > > (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [be_process_init] > (0x0010): fatal error initializing data providers > (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [main] (0x0010): Could > not initialize backend [14] > (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] > [select_principal_from_keytab] (0x0010): Failed to read keytab > [default]: Bad address > (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [load_backend_module] > (0x0010): Error (14) in module (ipa) initialization (sssm_ipa_id_init)! > > This is also strange but might be side effect I assume.. we mount NFS v4 > home dir with automount for central homes and profiles.. on the boxes > having this issue some of the IDs show just the UID numbers/GID numebrs > where some of the IDs actually show the UID name/GID name. We have over > 2k servers showing the UID name/GID name with no issues.. just the boxes > having this issue. > > > > Sean Hogan > > > > > > > Inactive hide details for Jakub Hrozek ---11/16/2016 02:29:52 AM---On > Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: Jakub Hrozek > ---11/16/2016 02:29:52 AM---On Tue, Nov 15, 2016 at 07:24:38PM -0700, > Sean Hogan wrote: > > > From: Jakub Hrozek > To: freeipa-users at redhat.com > Date: 11/16/2016 02:29 AM > Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server > Sent by: freeipa-users-bounces at redhat.com > > ------------------------------------------------------------------------ > > > > On Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: >> >> >> Hello, >> >> >> I am starting to see some issues with a few RHEL7 boxes I have been >> enrolling to my RHEL 6 IPA server regarding encryption. >> >> >> RHEL 7 client >> Red Hat Enterprise Linux Server release 7.1 (Maipo) >> sssd-ipa-1.12.2-58.el7_1.18.x86_64 >> ipa-client-4.1.0-18.el7_1.4.x86_64 >> >> RHEL 6 Server >> Red Hat Enterprise Linux Server release 6.8 (Santiago) >> sssd-ipa-1.13.3-22.el6_8.4.x86_64 >> ipa-server-3.0.0-50.el6.1.x86_64 >> >> >> The RHEL 7 client shows this in messages >> >> Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support >> for encryption type > > Could you post a more verbose ldap_child log (debug_level=10 includes > KRB5_TRACE-level messages) so that we see what kind of crypto was used? > >> Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize >> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity > check >> failed. Unable to create GSSAPI-encrypted LDAP connection. >> >> I am also not seeing host certs for them on the ipa server but I do see >> them on the local box. >> >> [root at server1 pam.d]# ktutil > > Can you run klist -ke as well to see what encryption types are included > in the keytab? > > Is it possible to run "kinit -k" on the client? > >> ktutil: rkt /etc/krb5.keytab >> ktutil: l >> slot KVNO Principal >> ---- ---- >> --------------------------------------------------------------------- >> 1 1 host/server1.ipa.local at IPA.LOCAL >> 2 1 host/server1.ipa.local at IPA.LOCAL >> 3 1 host/server1.ipa.local at IPA.LOCAL >> 4 1 host/server1.ipa.local at IPA.LOCAL >> ktutil: >> >> >> I have one RHEL 7 box with no issues as it was just enrolled (missing host >> certs in IPA though) and I compared and IPA ID login with a box not >> working >> *NOT Work* >> type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0 >> auid=4294967295 ses=4294967295 > subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >> msg='op=PAM:authentication grantors=? acct="janedoe" exe="/usr/sbin/sshd" >> hostname=10.10.10.10 addr=10.10.10.9 terminal=ssh res=failed' >> >> vs >> >> Works >> type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0 >> auid=4294967295 ses=4294967295 > subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >> msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit acct="janedoe" >> exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh >> res=success' >> >> Its almost as if the pam files are not being read? >> >> >> >> 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 > > -- > 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 > > > > > > -- Martin^3 Babinsky -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 07029235.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 07006434.gif Type: image/gif Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From pspacek at redhat.com Wed Nov 16 16:59:02 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Nov 2016 17:59:02 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: References: <520773e2-752d-8f4b-b770-3e079f2a7045@redhat.com> Message-ID: <5a26a1d4-e702-f428-22f2-b742d661bcc3@redhat.com> On 16.11.2016 17:47, Stijn De Weirdt wrote: >>> this is a different question: what can we do such that compromised host >>> can do a little as possible if the admin doesn't (yet) know the host is >>> compromised. >>> >>> the default policy allows way too much. >> >> For any useful advice we need more details. >> >> What are the operations you want to disable? > at the very least, "kvno userlogin" should fail (i.e. access to a host > keytab shouldn't permit retrieval of arbitrary user token). I think that this is misunderstanding. "kvno userlogin" does not allow the attacker to do anything. The result of kvno command is a service ticket for particular principal (user, host). The attacker can use this service ticket *for authentication to the particular principal* (user, host). So the only thing the attacker can do is to prove its identity to given (user, host). This exactly matches capabilities the attacker already has - the full control over the host. Please see https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request for further details on this. Does it explain the situation? Petr^2 Spacek > > i'm assuming that retrieval of service tokens for another host is > already not possible? (ie if you have keyatb of fqdn1, you shouldn't be > able to retrieve a token for SERVICE/fqdn2 at REALM). > > stijn > >> >> Petr^2 Spacek >> >> >>> >>> how to clean it up once you know the host is compromised is the subject >>> of the other thread. >>> >>> stijn >>> >>>> >>>> In the case that the host is compromised/stolen/hijacked, you can >>>> host-disable it to invalidate the keytab stored there but this does not >>>> prevent anyone logged on that host to bruteforce/DOS user accounts by >>>> trying to guess their Kerberos keys by repeated kinit. >>>> >>> >> >> > -- Petr^2 Spacek From stijn.deweirdt at ugent.be Wed Nov 16 17:26:42 2016 From: stijn.deweirdt at ugent.be (Stijn De Weirdt) Date: Wed, 16 Nov 2016 18:26:42 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: <5a26a1d4-e702-f428-22f2-b742d661bcc3@redhat.com> References: <520773e2-752d-8f4b-b770-3e079f2a7045@redhat.com> <5a26a1d4-e702-f428-22f2-b742d661bcc3@redhat.com> Message-ID: hi petr, >>>> this is a different question: what can we do such that compromised host >>>> can do a little as possible if the admin doesn't (yet) know the host is >>>> compromised. >>>> >>>> the default policy allows way too much. >>> >>> For any useful advice we need more details. >>> >>> What are the operations you want to disable? >> at the very least, "kvno userlogin" should fail (i.e. access to a host >> keytab shouldn't permit retrieval of arbitrary user token). > > I think that this is misunderstanding. i'll spend some more time rereading and getting a better understanding (again ;) > > "kvno userlogin" does not allow the attacker to do anything. The result of > kvno command is a service ticket for particular principal (user, host). > > The attacker can use this service ticket *for authentication to the particular > principal* (user, host). > > So the only thing the attacker can do is to prove its identity to given (user, > host). This exactly matches capabilities the attacker already has - the full > control over the host. hhmm, ok. is there a way to let e.g. klist show this? it now says 'userlogin at REALM' in the 'Service principal' column. for the (user,host) combo i expected to see a userlogin/fqdn at REALM, like other service tokens. anyway, clearly i'm missing something here. stijn > > Please see > https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request > for further details on this. > > Does it explain the situation? > > Petr^2 Spacek > >> >> i'm assuming that retrieval of service tokens for another host is >> already not possible? (ie if you have keyatb of fqdn1, you shouldn't be >> able to retrieve a token for SERVICE/fqdn2 at REALM). >> >> stijn >> >>> >>> Petr^2 Spacek >>> >>> >>>> >>>> how to clean it up once you know the host is compromised is the subject >>>> of the other thread. >>>> >>>> stijn >>>> >>>>> >>>>> In the case that the host is compromised/stolen/hijacked, you can >>>>> host-disable it to invalidate the keytab stored there but this does not >>>>> prevent anyone logged on that host to bruteforce/DOS user accounts by >>>>> trying to guess their Kerberos keys by repeated kinit. >>>>> >>>> >>> >>> >> > > From mbasti at redhat.com Wed Nov 16 17:47:06 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Nov 2016 18:47:06 +0100 Subject: [Freeipa-users] Disabling Anonymous Binds (LDAP) In-Reply-To: <8F863F5E-1F26-49F5-AA81-FD12FCEFF395@high5games.com> References: <8F863F5E-1F26-49F5-AA81-FD12FCEFF395@high5games.com> Message-ID: On 16.11.2016 17:46, Dan.Finkelstein at high5games.com wrote: > > I've seen some discussion in the (distant) past about disabling > anonymous binds to the LDAP component of IPA, and I'm wondering if > there's a preferred method to do it. Further, are there any known > problems with disabling anonymous binds when using FreeIPA? The only > modern documentation I can find is here: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html, > and I'm curious if FreeIPA has a different way. > > Thanks, > > Dan > > id:image001.jpg at 01D1C26F.0E28FA60 > > *Daniel Alex Finkelstein*| Lead Dev Ops Engineer > > _Dan.Finkelstein at h5g.com _ | 212.604.3447 > > One World Trade Center, New York, NY 10007 > > www.high5games.com > > Play High 5 Casino and > Shake the Sky > > Follow us on: Facebook , Twitter > , YouTube > , Linkedin > > > // > > /This message and any attachments may contain confidential or > privileged information and are only for the use of the intended > recipient of this message. If you are not the intended recipient, > please notify the sender by return email, and delete or destroy this > and all copies of this message and all attachments. Any unauthorized > disclosure, use, distribution, or reproduction of this message or any > attachments is prohibited and may be unlawful./ > > > It depends on your FreeIPA version, 3.x is explained in link you posted, 4.x has a permission for this. Sa what is your freeIPA version? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 4334 bytes Desc: not available URL: From mbasti at redhat.com Wed Nov 16 17:49:10 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Nov 2016 18:49:10 +0100 Subject: [Freeipa-users] Disabling Anonymous Binds (LDAP) In-Reply-To: References: <8F863F5E-1F26-49F5-AA81-FD12FCEFF395@high5games.com> Message-ID: <85318d9a-4f3c-9716-1962-68addeb64a48@redhat.com> On 16.11.2016 18:47, Martin Basti wrote: > > > > On 16.11.2016 17:46, Dan.Finkelstein at high5games.com wrote: >> >> I've seen some discussion in the (distant) past about disabling >> anonymous binds to the LDAP component of IPA, and I'm wondering if >> there's a preferred method to do it. Further, are there any known >> problems with disabling anonymous binds when using FreeIPA? The only >> modern documentation I can find is here: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html, >> and I'm curious if FreeIPA has a different way. >> >> Thanks, >> >> Dan >> >> id:image001.jpg at 01D1C26F.0E28FA60 >> >> *Daniel Alex Finkelstein*| Lead Dev Ops Engineer >> >> _Dan.Finkelstein at h5g.com _ | 212.604.3447 >> >> One World Trade Center, New York, NY 10007 >> >> www.high5games.com >> >> Play High 5 Casino and >> Shake the Sky >> >> Follow us on: Facebook , Twitter >> , YouTube >> , Linkedin >> >> >> // >> >> /This message and any attachments may contain confidential or >> privileged information and are only for the use of the intended >> recipient of this message. If you are not the intended recipient, >> please notify the sender by return email, and delete or destroy this >> and all copies of this message and all attachments. Any unauthorized >> disclosure, use, distribution, or reproduction of this message or any >> attachments is prohibited and may be unlawful./ >> >> >> > It depends on your FreeIPA version, 3.x is explained in link you > posted, 4.x has a permission for this. > > Sa what is your freeIPA version? > > Martin > > And I forgot to add, those should be disabled by default in IPA 4.x -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 4334 bytes Desc: not available URL: From mbabinsk at redhat.com Wed Nov 16 17:54:24 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 16 Nov 2016 18:54:24 +0100 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: References: <20161116092207.sgfqdomuhhs62v4x@hendrix> <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> Message-ID: On 11/16/2016 05:56 PM, Sean Hogan wrote: > Sorry.. listing ouput of klist -e and klist -ke... but kinit -k does not > seem to be working if I have it right.. kinit -kt is more promising but > still fails > > > *Klists* > > [root at server1 read]# klist -e > Ticket cache: KEYRING:persistent:111111111:11111111111 > Default principal: admin at ipa.local > > Valid starting Expires Service principal > 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/ipa.local at IPA.LOCAL > Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 > > > [root at server1 read]# klist -ke > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) > 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) > 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) > 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) > > > > *Kinits * > > [root at server1 read]# kinit -k /etc/krb5.keytab host/server1.ipa.local Sorry it should read 'kinit -kt /etc/krb5.keytab host/server1.ipa.local' > Extra arguments (starting with "host/server1.ipa.local"). > Usage: kinit [-V] [-l lifetime] [-s start_time] > [-r renewable_life] [-f | -F] [-p | -P] -n [-a | -A] [-C] > [-E] > [-v] [-R] [-k [-i|-t keytab_file]] [-c cachename] > [-S service_name] [-T ticket_armor_cache] > [-X [=]] [principal] > > options: -V verbose > -l lifetime > -s start time > -r renewable lifetime > -f forwardable > -F not forwardable > -p proxiable > -P not proxiable > -n anonymous > -a include addresses > -A do not include addresses > -v validate > -R renew > -C canonicalize > -E client is enterprise principal name > -k use keytab > -i use default client keytab (with -k) > -t filename of keytab to use > -c Kerberos 5 cache name > -S service > -T armor credential cache > -X [=] > > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Cannot contact any KDC for realm 'IPA.LOCAL' while getting > initial credentials > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Program lacks support for encryption type while getting initial > credentials > > > Sean Hogan > > > > > > > > Inactive hide details for Martin Babinsky ---11/16/2016 09:33:08 AM---On > 11/16/2016 05:14 PM, Sean Hogan wrote: > Hi Jakub,Martin Babinsky > ---11/16/2016 09:33:08 AM---On 11/16/2016 05:14 PM, Sean Hogan wrote: > > Hi Jakub, > > From: Martin Babinsky > To: Sean Hogan/Durham/IBM at IBMUS, Jakub Hrozek > Cc: freeipa-users at redhat.com > Date: 11/16/2016 09:33 AM > Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server > > ------------------------------------------------------------------------ > > > > On 11/16/2016 05:14 PM, Sean Hogan wrote: >> Hi Jakub, >> >> Thanks... here is output >> >> >> *klist -ke* >> [root at server1 rusers]# klist -ke >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> ---- >> -------------------------------------------------------------------------- >> 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) >> 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) >> 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) >> 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) >> >> >> >> *kinit -k odd though as kinit -k seems to fail but kinit with admin >> seems to work indicating I can hit the KDC even though kinit -k says I >> cannot?* >> >> [root at server1 pam.d]# kinit -k server1 >> kinit: Keytab contains no suitable keys for server1 at IPA.LOCAL while >> getting initial credentials >> [root at server1 pam.d]# kinit -k server1.IPA.LOCAL >> kinit: Keytab contains no suitable keys for server1.IPA.LOCAL at IPA.LOCAL >> while getting initial credentials > You need to specify full principal name as printed from klist command, > i.e. kinit -k /etc/krb5.keytab host/server1.ipa.local > >> [root at server1 pam.d]# kinit admin >> Password for admin at ipa.local: >> [root at server1 pam.d]# >> [root at server1 pam.d]# klist >> Ticket cache: KEYRING:persistent:1111111111:1111111111 >> Default principal: admin at IPA.LOCAL >> >> Valid starting Expires Service principal >> 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/IPA.LOCAL at IPA.LOCAL >> >> [root at server1 pam.d]# ktutil >> ktutil: rkt /etc/krb5.keytab >> ktutil: l >> slot KVNO Principal >> ---- ---- >> --------------------------------------------------------------------- >> 1 1 host/server1.ipa.local at IPA.LOCAL >> 2 1 host/server1.ipa.local at IPA.LOCAL >> 3 1 host/server1.ipa.local at IPA.LOCAL >> 4 1 host/server1.ipa.local at IPA.LOCAL >> >> >> >> *Added debug_level = 10 on the domain section of sssd.conf and restarted >> is all I see* >> [root at server1 sssd]# cat ldap_child.log >> (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18951]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18954]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18956]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18957]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:58:02 2016) [[sssd[ldap_child[18958]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:59:26 2016) [[sssd[ldap_child[18977]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> >> >> >> >> *Additonal:* >> >> [root at server1 rusers]# systemctl -l status sssd.service >> sssd.service - System Security Services Daemon >> Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) >> Drop-In: /etc/systemd/system/sssd.service.d >> ??journal.conf >> Active: active (running) since Wed 2016-11-16 10:30:43 EST; 17s ago >> Process: 3041 ExecStart=/usr/sbin/sssd -D -f (code=exited, > status=0/SUCCESS) >> Main PID: 3042 (sssd) >> CGroup: /system.slice/sssd.service >> ??3042 /usr/sbin/sssd -D -f >> ??3043 /usr/libexec/sssd/sssd_be --domain ipa.local --uid 0 --gid 0 >> --debug-to-files >> ??3044 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files >> ??3045 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files >> ??3046 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files >> ??3047 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files >> ??3048 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files >> >> Nov 16 10:30:43 server1.ipa.local sssd[3042]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[be[ipa.local]][3043]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[sudo][3045]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[pam][3046]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[nss][3044]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[ssh][3047]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[pac][3048]: Starting up >> Nov 16 10:30:43 server1.ipa.local systemd[1]: Started System Security >> Services Daemon. >> Nov 16 10:30:55 server1.ipa.local [sssd[ldap_child[3055]]][3055]: Failed >> to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: >> Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP >> connection. >> [root at server1 rusers]# >> >> Seeing this in /var/log/sssd/sssd_ipa.local.log >> >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [be_process_init] >> (0x0010): fatal error initializing data providers >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [main] (0x0010): Could >> not initialize backend [14] >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] >> [select_principal_from_keytab] (0x0010): Failed to read keytab >> [default]: Bad address >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [load_backend_module] >> (0x0010): Error (14) in module (ipa) initialization (sssm_ipa_id_init)! >> >> This is also strange but might be side effect I assume.. we mount NFS v4 >> home dir with automount for central homes and profiles.. on the boxes >> having this issue some of the IDs show just the UID numbers/GID numebrs >> where some of the IDs actually show the UID name/GID name. We have over >> 2k servers showing the UID name/GID name with no issues.. just the boxes >> having this issue. >> >> >> >> Sean Hogan >> >> >> >> >> >> >> Inactive hide details for Jakub Hrozek ---11/16/2016 02:29:52 AM---On >> Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: Jakub Hrozek >> ---11/16/2016 02:29:52 AM---On Tue, Nov 15, 2016 at 07:24:38PM -0700, >> Sean Hogan wrote: > >> >> From: Jakub Hrozek >> To: freeipa-users at redhat.com >> Date: 11/16/2016 02:29 AM >> Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server >> Sent by: freeipa-users-bounces at redhat.com >> >> ------------------------------------------------------------------------ >> >> >> >> On Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: >>> >>> >>> Hello, >>> >>> >>> I am starting to see some issues with a few RHEL7 boxes I have been >>> enrolling to my RHEL 6 IPA server regarding encryption. >>> >>> >>> RHEL 7 client >>> Red Hat Enterprise Linux Server release 7.1 (Maipo) >>> sssd-ipa-1.12.2-58.el7_1.18.x86_64 >>> ipa-client-4.1.0-18.el7_1.4.x86_64 >>> >>> RHEL 6 Server >>> Red Hat Enterprise Linux Server release 6.8 (Santiago) >>> sssd-ipa-1.13.3-22.el6_8.4.x86_64 >>> ipa-server-3.0.0-50.el6.1.x86_64 >>> >>> >>> The RHEL 7 client shows this in messages >>> >>> Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support >>> for encryption type >> >> Could you post a more verbose ldap_child log (debug_level=10 includes >> KRB5_TRACE-level messages) so that we see what kind of crypto was used? >> >>> Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize >>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >> check >>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>> >>> I am also not seeing host certs for them on the ipa server but I do see >>> them on the local box. >>> >>> [root at server1 pam.d]# ktutil >> >> Can you run klist -ke as well to see what encryption types are included >> in the keytab? >> >> Is it possible to run "kinit -k" on the client? >> >>> ktutil: rkt /etc/krb5.keytab >>> ktutil: l >>> slot KVNO Principal >>> ---- ---- >>> --------------------------------------------------------------------- >>> 1 1 host/server1.ipa.local at IPA.LOCAL >>> 2 1 host/server1.ipa.local at IPA.LOCAL >>> 3 1 host/server1.ipa.local at IPA.LOCAL >>> 4 1 host/server1.ipa.local at IPA.LOCAL >>> ktutil: >>> >>> >>> I have one RHEL 7 box with no issues as it was just enrolled (missing > host >>> certs in IPA though) and I compared and IPA ID login with a box not >>> working >>> *NOT Work* >>> type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0 >>> auid=4294967295 ses=4294967295 >> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>> msg='op=PAM:authentication grantors=? acct="janedoe" exe="/usr/sbin/sshd" >>> hostname=10.10.10.10 addr=10.10.10.9 terminal=ssh res=failed' >>> >>> vs >>> >>> Works >>> type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0 >>> auid=4294967295 ses=4294967295 >> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>> msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit > acct="janedoe" >>> exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh >>> res=success' >>> >>> Its almost as if the pam files are not being read? >>> >>> >>> >>> 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 >> >> -- >> 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 >> >> >> >> >> >> > > > -- > Martin^3 Babinsky > > > > -- Martin^3 Babinsky From pspacek at redhat.com Wed Nov 16 17:58:38 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Nov 2016 18:58:38 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: References: <520773e2-752d-8f4b-b770-3e079f2a7045@redhat.com> <5a26a1d4-e702-f428-22f2-b742d661bcc3@redhat.com> Message-ID: On 16.11.2016 18:26, Stijn De Weirdt wrote: > hi petr, > >>>>> this is a different question: what can we do such that compromised host >>>>> can do a little as possible if the admin doesn't (yet) know the host is >>>>> compromised. >>>>> >>>>> the default policy allows way too much. >>>> >>>> For any useful advice we need more details. >>>> >>>> What are the operations you want to disable? >>> at the very least, "kvno userlogin" should fail (i.e. access to a host >>> keytab shouldn't permit retrieval of arbitrary user token). >> >> I think that this is misunderstanding. > i'll spend some more time rereading and getting a better understanding > (again ;) > >> >> "kvno userlogin" does not allow the attacker to do anything. The result of >> kvno command is a service ticket for particular principal (user, host). >> >> The attacker can use this service ticket *for authentication to the particular >> principal* (user, host). >> >> So the only thing the attacker can do is to prove its identity to given (user, >> host). This exactly matches capabilities the attacker already has - the full >> control over the host. > hhmm, ok. is there a way to let e.g. klist show this? it now says > 'userlogin at REALM' in the 'Service principal' column. for the (user,host) > combo i expected to see a userlogin/fqdn at REALM, like other service tokens. > > anyway, clearly i'm missing something here. The important field is 'Default principal:' which is above the list of tickets. It contains name of the principal "who you are". Rest of the list shows just service tickets which are used to authenticate you to the services listed in the list. It just means that you tried to contact them some time ago (or called kvno explicitly). Please go and read some articles about Kerberos protocol, e.g. the Wikipedia article I linked below. It will explain a lot of things. Petr^2 Spacek > > > stijn > >> >> Please see >> https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request >> for further details on this. >> >> Does it explain the situation? >> >> Petr^2 Spacek >> >>> >>> i'm assuming that retrieval of service tokens for another host is >>> already not possible? (ie if you have keyatb of fqdn1, you shouldn't be >>> able to retrieve a token for SERVICE/fqdn2 at REALM). >>> >>> stijn >>> >>>> >>>> Petr^2 Spacek >>>> >>>> >>>>> >>>>> how to clean it up once you know the host is compromised is the subject >>>>> of the other thread. >>>>> >>>>> stijn >>>>> >>>>>> >>>>>> In the case that the host is compromised/stolen/hijacked, you can >>>>>> host-disable it to invalidate the keytab stored there but this does not >>>>>> prevent anyone logged on that host to bruteforce/DOS user accounts by >>>>>> trying to guess their Kerberos keys by repeated kinit. >>>>>> >>>>> >>>> >>>> >>> >> >> -- Petr^2 Spacek From Dan.Finkelstein at high5games.com Wed Nov 16 18:01:07 2016 From: Dan.Finkelstein at high5games.com (Dan.Finkelstein at high5games.com) Date: Wed, 16 Nov 2016 18:01:07 +0000 Subject: [Freeipa-users] Disabling Anonymous Binds (LDAP) In-Reply-To: References: <8F863F5E-1F26-49F5-AA81-FD12FCEFF395@high5games.com> Message-ID: <6E6DC47F-86E8-421E-A3FD-7CD2E3C5BC97@high5games.com> I'm on FreeIPA 4.x [id:image001.jpg at 01D1C26F.0E28FA60] Daniel Alex Finkelstein| Lead Dev Ops Engineer Dan.Finkelstein at h5g.com | 212.604.3447 One World Trade Center, New York, NY 10007 www.high5games.com Play High 5 Casino and Shake the Sky Follow us on: Facebook, Twitter, YouTube, Linkedin This message and any attachments may contain confidential or privileged information and are only for the use of the intended recipient of this message. If you are not the intended recipient, please notify the sender by return email, and delete or destroy this and all copies of this message and all attachments. Any unauthorized disclosure, use, distribution, or reproduction of this message or any attachments is prohibited and may be unlawful. From: Martin Basti Date: Wednesday, November 16, 2016 at 12:47 To: Dan Finkelstein , "freeipa-users at redhat.com" Subject: Re: [Freeipa-users] Disabling Anonymous Binds (LDAP) On 16.11.2016 17:46, Dan.Finkelstein at high5games.com wrote: I've seen some discussion in the (distant) past about disabling anonymous binds to the LDAP component of IPA, and I'm wondering if there's a preferred method to do it. Further, are there any known problems with disabling anonymous binds when using FreeIPA? The only modern documentation I can find is here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html, and I'm curious if FreeIPA has a different way. Thanks, Dan [cid:image002.jpg at 01D24009.7DC9DBB0] Daniel Alex Finkelstein| Lead Dev Ops Engineer Dan.Finkelstein at h5g.com | 212.604.3447 One World Trade Center, New York, NY 10007 www.high5games.com Play High 5 Casino and Shake the Sky Follow us on: Facebook, Twitter, YouTube, Linkedin This message and any attachments may contain confidential or privileged information and are only for the use of the intended recipient of this message. If you are not the intended recipient, please notify the sender by return email, and delete or destroy this and all copies of this message and all attachments. Any unauthorized disclosure, use, distribution, or reproduction of this message or any attachments is prohibited and may be unlawful. It depends on your FreeIPA version, 3.x is explained in link you posted, 4.x has a permission for this. Sa what is your freeIPA version? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 4334 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 4335 bytes Desc: image002.jpg URL: From schogan at us.ibm.com Wed Nov 16 18:13:49 2016 From: schogan at us.ibm.com (Sean Hogan) Date: Wed, 16 Nov 2016 11:13:49 -0700 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: References: <20161116092207.sgfqdomuhhs62v4x@hendrix> <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> Message-ID: Yes sir... I added the kinit kts in the previous thinking it was needed. > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Cannot contact any KDC for realm 'IPA.LOCAL' while getting > initial credentials > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Program lacks support for encryption type while getting initial > credentials Sean Hogan From: Martin Babinsky To: Sean Hogan/Durham/IBM at IBMUS Cc: freeipa-users at redhat.com, Jakub Hrozek Date: 11/16/2016 10:54 AM Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server On 11/16/2016 05:56 PM, Sean Hogan wrote: > Sorry.. listing ouput of klist -e and klist -ke... but kinit -k does not > seem to be working if I have it right.. kinit -kt is more promising but > still fails > > > *Klists* > > [root at server1 read]# klist -e > Ticket cache: KEYRING:persistent:111111111:11111111111 > Default principal: admin at ipa.local > > Valid starting Expires Service principal > 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/ipa.local at IPA.LOCAL > Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 > > > [root at server1 read]# klist -ke > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) > 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) > 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) > 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) > > > > *Kinits * > > [root at server1 read]# kinit -k /etc/krb5.keytab host/server1.ipa.local Sorry it should read 'kinit -kt /etc/krb5.keytab host/server1.ipa.local' > Extra arguments (starting with "host/server1.ipa.local"). > Usage: kinit [-V] [-l lifetime] [-s start_time] > [-r renewable_life] [-f | -F] [-p | -P] -n [-a | -A] [-C] > [-E] > [-v] [-R] [-k [-i|-t keytab_file]] [-c cachename] > [-S service_name] [-T ticket_armor_cache] > [-X [=]] [principal] > > options: -V verbose > -l lifetime > -s start time > -r renewable lifetime > -f forwardable > -F not forwardable > -p proxiable > -P not proxiable > -n anonymous > -a include addresses > -A do not include addresses > -v validate > -R renew > -C canonicalize > -E client is enterprise principal name > -k use keytab > -i use default client keytab (with -k) > -t filename of keytab to use > -c Kerberos 5 cache name > -S service > -T armor credential cache > -X [=] > > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Cannot contact any KDC for realm 'IPA.LOCAL' while getting > initial credentials > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Program lacks support for encryption type while getting initial > credentials > > > Sean Hogan > > > > > > > > Inactive hide details for Martin Babinsky ---11/16/2016 09:33:08 AM---On > 11/16/2016 05:14 PM, Sean Hogan wrote: > Hi Jakub,Martin Babinsky > ---11/16/2016 09:33:08 AM---On 11/16/2016 05:14 PM, Sean Hogan wrote: > > Hi Jakub, > > From: Martin Babinsky > To: Sean Hogan/Durham/IBM at IBMUS, Jakub Hrozek > Cc: freeipa-users at redhat.com > Date: 11/16/2016 09:33 AM > Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server > > ------------------------------------------------------------------------ > > > > On 11/16/2016 05:14 PM, Sean Hogan wrote: >> Hi Jakub, >> >> Thanks... here is output >> >> >> *klist -ke* >> [root at server1 rusers]# klist -ke >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> ---- >> -------------------------------------------------------------------------- >> 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) >> 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) >> 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) >> 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) >> >> >> >> *kinit -k odd though as kinit -k seems to fail but kinit with admin >> seems to work indicating I can hit the KDC even though kinit -k says I >> cannot?* >> >> [root at server1 pam.d]# kinit -k server1 >> kinit: Keytab contains no suitable keys for server1 at IPA.LOCAL while >> getting initial credentials >> [root at server1 pam.d]# kinit -k server1.IPA.LOCAL >> kinit: Keytab contains no suitable keys for server1.IPA.LOCAL at IPA.LOCAL >> while getting initial credentials > You need to specify full principal name as printed from klist command, > i.e. kinit -k /etc/krb5.keytab host/server1.ipa.local > >> [root at server1 pam.d]# kinit admin >> Password for admin at ipa.local: >> [root at server1 pam.d]# >> [root at server1 pam.d]# klist >> Ticket cache: KEYRING:persistent:1111111111:1111111111 >> Default principal: admin at IPA.LOCAL >> >> Valid starting Expires Service principal >> 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/IPA.LOCAL at IPA.LOCAL >> >> [root at server1 pam.d]# ktutil >> ktutil: rkt /etc/krb5.keytab >> ktutil: l >> slot KVNO Principal >> ---- ---- >> --------------------------------------------------------------------- >> 1 1 host/server1.ipa.local at IPA.LOCAL >> 2 1 host/server1.ipa.local at IPA.LOCAL >> 3 1 host/server1.ipa.local at IPA.LOCAL >> 4 1 host/server1.ipa.local at IPA.LOCAL >> >> >> >> *Added debug_level = 10 on the domain section of sssd.conf and restarted >> is all I see* >> [root at server1 sssd]# cat ldap_child.log >> (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18951]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18954]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18956]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18957]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:58:02 2016) [[sssd[ldap_child[18958]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:59:26 2016) [[sssd[ldap_child[18977]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> >> >> >> >> *Additonal:* >> >> [root at server1 rusers]# systemctl -l status sssd.service >> sssd.service - System Security Services Daemon >> Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) >> Drop-In: /etc/systemd/system/sssd.service.d >> ??journal.conf >> Active: active (running) since Wed 2016-11-16 10:30:43 EST; 17s ago >> Process: 3041 ExecStart=/usr/sbin/sssd -D -f (code=exited, > status=0/SUCCESS) >> Main PID: 3042 (sssd) >> CGroup: /system.slice/sssd.service >> ??3042 /usr/sbin/sssd -D -f >> ??3043 /usr/libexec/sssd/sssd_be --domain ipa.local --uid 0 --gid 0 >> --debug-to-files >> ??3044 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files >> ??3045 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files >> ??3046 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files >> ??3047 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files >> ??3048 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files >> >> Nov 16 10:30:43 server1.ipa.local sssd[3042]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[be[ipa.local]][3043]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[sudo][3045]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[pam][3046]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[nss][3044]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[ssh][3047]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[pac][3048]: Starting up >> Nov 16 10:30:43 server1.ipa.local systemd[1]: Started System Security >> Services Daemon. >> Nov 16 10:30:55 server1.ipa.local [sssd[ldap_child[3055]]][3055]: Failed >> to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: >> Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP >> connection. >> [root at server1 rusers]# >> >> Seeing this in /var/log/sssd/sssd_ipa.local.log >> >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [be_process_init] >> (0x0010): fatal error initializing data providers >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [main] (0x0010): Could >> not initialize backend [14] >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] >> [select_principal_from_keytab] (0x0010): Failed to read keytab >> [default]: Bad address >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [load_backend_module] >> (0x0010): Error (14) in module (ipa) initialization (sssm_ipa_id_init)! >> >> This is also strange but might be side effect I assume.. we mount NFS v4 >> home dir with automount for central homes and profiles.. on the boxes >> having this issue some of the IDs show just the UID numbers/GID numebrs >> where some of the IDs actually show the UID name/GID name. We have over >> 2k servers showing the UID name/GID name with no issues.. just the boxes >> having this issue. >> >> >> >> Sean Hogan >> >> >> >> >> >> >> Inactive hide details for Jakub Hrozek ---11/16/2016 02:29:52 AM---On >> Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: Jakub Hrozek >> ---11/16/2016 02:29:52 AM---On Tue, Nov 15, 2016 at 07:24:38PM -0700, >> Sean Hogan wrote: > >> >> From: Jakub Hrozek >> To: freeipa-users at redhat.com >> Date: 11/16/2016 02:29 AM >> Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server >> Sent by: freeipa-users-bounces at redhat.com >> >> ------------------------------------------------------------------------ >> >> >> >> On Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: >>> >>> >>> Hello, >>> >>> >>> I am starting to see some issues with a few RHEL7 boxes I have been >>> enrolling to my RHEL 6 IPA server regarding encryption. >>> >>> >>> RHEL 7 client >>> Red Hat Enterprise Linux Server release 7.1 (Maipo) >>> sssd-ipa-1.12.2-58.el7_1.18.x86_64 >>> ipa-client-4.1.0-18.el7_1.4.x86_64 >>> >>> RHEL 6 Server >>> Red Hat Enterprise Linux Server release 6.8 (Santiago) >>> sssd-ipa-1.13.3-22.el6_8.4.x86_64 >>> ipa-server-3.0.0-50.el6.1.x86_64 >>> >>> >>> The RHEL 7 client shows this in messages >>> >>> Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support >>> for encryption type >> >> Could you post a more verbose ldap_child log (debug_level=10 includes >> KRB5_TRACE-level messages) so that we see what kind of crypto was used? >> >>> Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize >>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >> check >>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>> >>> I am also not seeing host certs for them on the ipa server but I do see >>> them on the local box. >>> >>> [root at server1 pam.d]# ktutil >> >> Can you run klist -ke as well to see what encryption types are included >> in the keytab? >> >> Is it possible to run "kinit -k" on the client? >> >>> ktutil: rkt /etc/krb5.keytab >>> ktutil: l >>> slot KVNO Principal >>> ---- ---- >>> --------------------------------------------------------------------- >>> 1 1 host/server1.ipa.local at IPA.LOCAL >>> 2 1 host/server1.ipa.local at IPA.LOCAL >>> 3 1 host/server1.ipa.local at IPA.LOCAL >>> 4 1 host/server1.ipa.local at IPA.LOCAL >>> ktutil: >>> >>> >>> I have one RHEL 7 box with no issues as it was just enrolled (missing > host >>> certs in IPA though) and I compared and IPA ID login with a box not >>> working >>> *NOT Work* >>> type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0 >>> auid=4294967295 ses=4294967295 >> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>> msg='op=PAM:authentication grantors=? acct="janedoe" exe="/usr/sbin/sshd" >>> hostname=10.10.10.10 addr=10.10.10.9 terminal=ssh res=failed' >>> >>> vs >>> >>> Works >>> type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0 >>> auid=4294967295 ses=4294967295 >> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>> msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit > acct="janedoe" >>> exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh >>> res=success' >>> >>> Its almost as if the pam files are not being read? >>> >>> >>> >>> 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 >> >> -- >> 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 >> >> >> >> >> >> > > > -- > Martin^3 Babinsky > > > > -- Martin^3 Babinsky -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 10691934.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 10161734.gif Type: image/gif Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From schogan at us.ibm.com Wed Nov 16 19:36:19 2016 From: schogan at us.ibm.com (Sean Hogan) Date: Wed, 16 Nov 2016 12:36:19 -0700 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: References: <20161116092207.sgfqdomuhhs62v4x@hendrix><14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> Message-ID: update.. I decided to unenroll the box and remove it from IPA totally. I enrolled it again and the box is now working as expected. However I did check if server1 now has a host certificate loaded in IPA and it does not. I have not had to do anything extra in getting a host cert loaded into IPA with the RHEL 6 boxes so is there a step I am not doing in getting a host cert loaded into IPA from a rhel 7 client to a RHEL 6 server? I guess I can do it manual but if I do that certmonger will not auto renew them right? [root at ipa1 ~]# ipa host-find server1 -------------- 1 host matched -------------- Host name: server1.ipa.local Principal name: host/server1.ipa.local at IPA.LOCAL Password: False Keytab: True Managed by: server1.ipa.local SSH public key fingerprint: 12:95:CC:REMOVED (ssh-ed25519), 33:B9:74:26::REMOVED (ssh-rsa), 52:F3:DD:REMOVED (ecdsa-sha2-nistp256) Where for a RHEL 6 box I see this [root at ipa1 ~]# ipa host-find server2 -------------- 1 host matched -------------- Host name: server2.ipa.local Certificate: MIIDpjCCAo6gAwIBAgICANQwDQYJKoZIhvcNAQELBQAwNzEVMBMGA1UEChMMV0 REMOVED THE REST Principal name: host/server2.ipa.local at IPA.LOCAL Password: False Member of host-groups: bob Indirect Member of HBAC rule: bob2, bob1 Keytab: True Managed by: server2.ipa.local Subject: CN=server2.ipa.local,O=IPA.LOCAL Serial Number: 212 Serial Number (hex): 0xD4 Issuer: CN=Certificate Authority,O=IPA.LOCAL Not Before: Tue Jul 26 20:48:58 2016 UTC Not After: Fri Jul 27 20:48:58 2018 UTC Fingerprint (MD5): 1f:b7:8f:REMOVED Fingerprint (SHA1): d3:2f:f:REMOVED SSH public key fingerprint: 1B:26:REMOVED (ssh-dss), 2D:66:D7:REMOVED (ssh-rsa) Sean Hogan From: Sean Hogan/Durham/IBM at IBMUS To: Martin Babinsky Cc: freeipa-users at redhat.com Date: 11/16/2016 11:31 AM Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server Sent by: freeipa-users-bounces at redhat.com Yes sir... I added the kinit kts in the previous thinking it was needed. > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Cannot contact any KDC for realm 'IPA.LOCAL' while getting > initial credentials > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Program lacks support for encryption type while getting initial > credentials Sean Hogan Inactive hide details for Martin Babinsky ---11/16/2016 10:54:32 AM---On 11/16/2016 05:56 PM, Sean Hogan wrote: > Sorry.. listiMartin Babinsky ---11/16/2016 10:54:32 AM---On 11/16/2016 05:56 PM, Sean Hogan wrote: > Sorry.. listing ouput of klist -e and klist -ke... but k From: Martin Babinsky To: Sean Hogan/Durham/IBM at IBMUS Cc: freeipa-users at redhat.com, Jakub Hrozek Date: 11/16/2016 10:54 AM Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server On 11/16/2016 05:56 PM, Sean Hogan wrote: > Sorry.. listing ouput of klist -e and klist -ke... but kinit -k does not > seem to be working if I have it right.. kinit -kt is more promising but > still fails > > > *Klists* > > [root at server1 read]# klist -e > Ticket cache: KEYRING:persistent:111111111:11111111111 > Default principal: admin at ipa.local > > Valid starting Expires Service principal > 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/ipa.local at IPA.LOCAL > Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 > > > [root at server1 read]# klist -ke > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) > 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) > 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) > 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) > > > > *Kinits * > > [root at server1 read]# kinit -k /etc/krb5.keytab host/server1.ipa.local Sorry it should read 'kinit -kt /etc/krb5.keytab host/server1.ipa.local' > Extra arguments (starting with "host/server1.ipa.local"). > Usage: kinit [-V] [-l lifetime] [-s start_time] > [-r renewable_life] [-f | -F] [-p | -P] -n [-a | -A] [-C] > [-E] > [-v] [-R] [-k [-i|-t keytab_file]] [-c cachename] > [-S service_name] [-T ticket_armor_cache] > [-X [=]] [principal] > > options: -V verbose > -l lifetime > -s start time > -r renewable lifetime > -f forwardable > -F not forwardable > -p proxiable > -P not proxiable > -n anonymous > -a include addresses > -A do not include addresses > -v validate > -R renew > -C canonicalize > -E client is enterprise principal name > -k use keytab > -i use default client keytab (with -k) > -t filename of keytab to use > -c Kerberos 5 cache name > -S service > -T armor credential cache > -X [=] > > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Cannot contact any KDC for realm 'IPA.LOCAL' while getting > initial credentials > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Program lacks support for encryption type while getting initial > credentials > > > Sean Hogan > > > > > > > > Inactive hide details for Martin Babinsky ---11/16/2016 09:33:08 AM---On > 11/16/2016 05:14 PM, Sean Hogan wrote: > Hi Jakub,Martin Babinsky > ---11/16/2016 09:33:08 AM---On 11/16/2016 05:14 PM, Sean Hogan wrote: > > Hi Jakub, > > From: Martin Babinsky > To: Sean Hogan/Durham/IBM at IBMUS, Jakub Hrozek > Cc: freeipa-users at redhat.com > Date: 11/16/2016 09:33 AM > Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server > > ------------------------------------------------------------------------ > > > > On 11/16/2016 05:14 PM, Sean Hogan wrote: >> Hi Jakub, >> >> Thanks... here is output >> >> >> *klist -ke* >> [root at server1 rusers]# klist -ke >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> ---- >> -------------------------------------------------------------------------- >> 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) >> 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) >> 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) >> 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) >> >> >> >> *kinit -k odd though as kinit -k seems to fail but kinit with admin >> seems to work indicating I can hit the KDC even though kinit -k says I >> cannot?* >> >> [root at server1 pam.d]# kinit -k server1 >> kinit: Keytab contains no suitable keys for server1 at IPA.LOCAL while >> getting initial credentials >> [root at server1 pam.d]# kinit -k server1.IPA.LOCAL >> kinit: Keytab contains no suitable keys for server1.IPA.LOCAL at IPA.LOCAL >> while getting initial credentials > You need to specify full principal name as printed from klist command, > i.e. kinit -k /etc/krb5.keytab host/server1.ipa.local > >> [root at server1 pam.d]# kinit admin >> Password for admin at ipa.local: >> [root at server1 pam.d]# >> [root at server1 pam.d]# klist >> Ticket cache: KEYRING:persistent:1111111111:1111111111 >> Default principal: admin at IPA.LOCAL >> >> Valid starting Expires Service principal >> 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/IPA.LOCAL at IPA.LOCAL >> >> [root at server1 pam.d]# ktutil >> ktutil: rkt /etc/krb5.keytab >> ktutil: l >> slot KVNO Principal >> ---- ---- >> --------------------------------------------------------------------- >> 1 1 host/server1.ipa.local at IPA.LOCAL >> 2 1 host/server1.ipa.local at IPA.LOCAL >> 3 1 host/server1.ipa.local at IPA.LOCAL >> 4 1 host/server1.ipa.local at IPA.LOCAL >> >> >> >> *Added debug_level = 10 on the domain section of sssd.conf and restarted >> is all I see* >> [root at server1 sssd]# cat ldap_child.log >> (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18951]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18954]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18956]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18957]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:58:02 2016) [[sssd[ldap_child[18958]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> (Wed Nov 16 10:59:26 2016) [[sssd[ldap_child[18977]]]] >> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >> lacks support for encryption type >> >> >> >> >> *Additonal:* >> >> [root at server1 rusers]# systemctl -l status sssd.service >> sssd.service - System Security Services Daemon >> Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) >> Drop-In: /etc/systemd/system/sssd.service.d >> ??journal.conf >> Active: active (running) since Wed 2016-11-16 10:30:43 EST; 17s ago >> Process: 3041 ExecStart=/usr/sbin/sssd -D -f (code=exited, > status=0/SUCCESS) >> Main PID: 3042 (sssd) >> CGroup: /system.slice/sssd.service >> ??3042 /usr/sbin/sssd -D -f >> ??3043 /usr/libexec/sssd/sssd_be --domain ipa.local --uid 0 --gid 0 >> --debug-to-files >> ??3044 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files >> ??3045 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files >> ??3046 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files >> ??3047 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files >> ??3048 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files >> >> Nov 16 10:30:43 server1.ipa.local sssd[3042]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[be[ipa.local]][3043]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[sudo][3045]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[pam][3046]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[nss][3044]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[ssh][3047]: Starting up >> Nov 16 10:30:43 server1.ipa.local sssd[pac][3048]: Starting up >> Nov 16 10:30:43 server1.ipa.local systemd[1]: Started System Security >> Services Daemon. >> Nov 16 10:30:55 server1.ipa.local [sssd[ldap_child[3055]]][3055]: Failed >> to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: >> Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP >> connection. >> [root at server1 rusers]# >> >> Seeing this in /var/log/sssd/sssd_ipa.local.log >> >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [be_process_init] >> (0x0010): fatal error initializing data providers >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [main] (0x0010): Could >> not initialize backend [14] >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] >> [select_principal_from_keytab] (0x0010): Failed to read keytab >> [default]: Bad address >> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [load_backend_module] >> (0x0010): Error (14) in module (ipa) initialization (sssm_ipa_id_init)! >> >> This is also strange but might be side effect I assume.. we mount NFS v4 >> home dir with automount for central homes and profiles.. on the boxes >> having this issue some of the IDs show just the UID numbers/GID numebrs >> where some of the IDs actually show the UID name/GID name. We have over >> 2k servers showing the UID name/GID name with no issues.. just the boxes >> having this issue. >> >> >> >> Sean Hogan >> >> >> >> >> >> >> Inactive hide details for Jakub Hrozek ---11/16/2016 02:29:52 AM---On >> Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: Jakub Hrozek >> ---11/16/2016 02:29:52 AM---On Tue, Nov 15, 2016 at 07:24:38PM -0700, >> Sean Hogan wrote: > >> >> From: Jakub Hrozek >> To: freeipa-users at redhat.com >> Date: 11/16/2016 02:29 AM >> Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server >> Sent by: freeipa-users-bounces at redhat.com >> >> ------------------------------------------------------------------------ >> >> >> >> On Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: >>> >>> >>> Hello, >>> >>> >>> I am starting to see some issues with a few RHEL7 boxes I have been >>> enrolling to my RHEL 6 IPA server regarding encryption. >>> >>> >>> RHEL 7 client >>> Red Hat Enterprise Linux Server release 7.1 (Maipo) >>> sssd-ipa-1.12.2-58.el7_1.18.x86_64 >>> ipa-client-4.1.0-18.el7_1.4.x86_64 >>> >>> RHEL 6 Server >>> Red Hat Enterprise Linux Server release 6.8 (Santiago) >>> sssd-ipa-1.13.3-22.el6_8.4.x86_64 >>> ipa-server-3.0.0-50.el6.1.x86_64 >>> >>> >>> The RHEL 7 client shows this in messages >>> >>> Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support >>> for encryption type >> >> Could you post a more verbose ldap_child log (debug_level=10 includes >> KRB5_TRACE-level messages) so that we see what kind of crypto was used? >> >>> Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize >>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >> check >>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>> >>> I am also not seeing host certs for them on the ipa server but I do see >>> them on the local box. >>> >>> [root at server1 pam.d]# ktutil >> >> Can you run klist -ke as well to see what encryption types are included >> in the keytab? >> >> Is it possible to run "kinit -k" on the client? >> >>> ktutil: rkt /etc/krb5.keytab >>> ktutil: l >>> slot KVNO Principal >>> ---- ---- >>> --------------------------------------------------------------------- >>> 1 1 host/server1.ipa.local at IPA.LOCAL >>> 2 1 host/server1.ipa.local at IPA.LOCAL >>> 3 1 host/server1.ipa.local at IPA.LOCAL >>> 4 1 host/server1.ipa.local at IPA.LOCAL >>> ktutil: >>> >>> >>> I have one RHEL 7 box with no issues as it was just enrolled (missing > host >>> certs in IPA though) and I compared and IPA ID login with a box not >>> working >>> *NOT Work* >>> type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0 >>> auid=4294967295 ses=4294967295 >> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>> msg='op=PAM:authentication grantors=? acct="janedoe" exe="/usr/sbin/sshd" >>> hostname=10.10.10.10 addr=10.10.10.9 terminal=ssh res=failed' >>> >>> vs >>> >>> Works >>> type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0 >>> auid=4294967295 ses=4294967295 >> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>> msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit > acct="janedoe" >>> exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh >>> res=success' >>> >>> Its almost as if the pam files are not being read? >>> >>> >>> >>> 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 >> >> -- >> 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 >> >> >> >> >> >> > > > -- > Martin^3 Babinsky > > > > -- Martin^3 Babinsky -- 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: 07937694.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 07059559.gif Type: image/gif Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From rcritten at redhat.com Wed Nov 16 20:54:38 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 16 Nov 2016 15:54:38 -0500 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: References: <20161116092207.sgfqdomuhhs62v4x@hendrix> <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> Message-ID: <582CC78E.6000801@redhat.com> Sean Hogan wrote: > update.. > > I decided to unenroll the box and remove it from IPA totally. I enrolled > it again and the box is now working as expected. However I did check if > server1 now has a host certificate loaded in IPA and it does not. > I have not had to do anything extra in getting a host cert loaded into > IPA with the RHEL 6 boxes so is there a step I am not doing in getting a > host cert loaded into IPA from a rhel 7 client to a RHEL 6 server? I > guess I can do it manual but if I do that certmonger will not auto renew > them right? In IPA 4.something ipa-client-install dropped getting a host certificate by default. There is an option, --request-cert, if you want to continue that behavior. Getting a server cert for the host was intended to be future-proofing and a convenience but we never used it for anything and never got any reports that anyone else had either (except to notice it isn't there anymore). So yeah, you can either un-enroll and re-enroll with the option or manually request one using ipa-getcert and it will be renewed automatically in both cases. rob > [root at ipa1 ~]# ipa host-find server1 > -------------- > 1 host matched > -------------- > Host name: server1.ipa.local > Principal name: host/server1.ipa.local at IPA.LOCAL > Password: False > Keytab: True > Managed by: server1.ipa.local > SSH public key fingerprint: 12:95:CC:*REMOVED* > (ssh-ed25519), > 33:B9:74:26::*REMOVED* > (ssh-rsa), > 52:F3:DD:*REMOVED* > (ecdsa-sha2-nistp256) > > > Where for a RHEL 6 box I see this > > > [root at ipa1 ~]# ipa host-find server2 > -------------- > 1 host matched > -------------- > Host name: server2.ipa.local > Certificate: MIIDpjCCAo6gAwIBAgICANQwDQYJKoZIhvcNAQELBQAwNzEVMBMGA1UEChMMV0 > *REMOVED THE REST* > Principal name: host/server2.ipa.local at IPA.LOCAL > Password: False > Member of host-groups: bob > Indirect Member of HBAC rule: bob2, bob1 > Keytab: True > Managed by: server2.ipa.local > Subject: CN=server2.ipa.local,O=IPA.LOCAL > Serial Number: 212 > Serial Number (hex): 0xD4 > Issuer: CN=Certificate Authority,O=IPA.LOCAL > Not Before: Tue Jul 26 20:48:58 2016 UTC > Not After: Fri Jul 27 20:48:58 2018 UTC > Fingerprint (MD5): 1f:b7:8f:*REMOVED* > Fingerprint (SHA1): d3:2f:f:*REMOVED* > SSH public key fingerprint: 1B:26:*REMOVED * > (ssh-dss), > 2D:66:D7:*REMOVED* > (ssh-rsa) > > > > > Sean Hogan > > > > > > > > Inactive hide details for Sean Hogan---11/16/2016 11:31:33 AM---Yes > sir... I added the kinit kts in the previous thinking it waSean > Hogan---11/16/2016 11:31:33 AM---Yes sir... I added the kinit kts in the > previous thinking it was needed. > [root at server1 read]# kini > > From: Sean Hogan/Durham/IBM at IBMUS > To: Martin Babinsky > Cc: freeipa-users at redhat.com > Date: 11/16/2016 11:31 AM > Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server > Sent by: freeipa-users-bounces at redhat.com > > ------------------------------------------------------------------------ > > > > Yes sir... I added the kinit kts in the previous thinking it was needed. > >> [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local >> kinit: Cannot contact any KDC for realm 'IPA.LOCAL' while getting >> initial credentials >> [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local >> kinit: Program lacks support for encryption type while getting initial >> credentials > > > > Sean Hogan > > > > > > > Inactive hide details for Martin Babinsky ---11/16/2016 10:54:32 AM---On > 11/16/2016 05:56 PM, Sean Hogan wrote: > Sorry.. listiMartin Babinsky > ---11/16/2016 10:54:32 AM---On 11/16/2016 05:56 PM, Sean Hogan wrote: > > Sorry.. listing ouput of klist -e and klist -ke... but k > > From: Martin Babinsky > To: Sean Hogan/Durham/IBM at IBMUS > Cc: freeipa-users at redhat.com, Jakub Hrozek > Date: 11/16/2016 10:54 AM > Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server > ------------------------------------------------------------------------ > > > > On 11/16/2016 05:56 PM, Sean Hogan wrote: >> Sorry.. listing ouput of klist -e and klist -ke... but kinit -k does not >> seem to be working if I have it right.. kinit -kt is more promising but >> still fails >> >> >> *Klists* >> >> [root at server1 read]# klist -e >> Ticket cache: KEYRING:persistent:111111111:11111111111 >> Default principal: admin at ipa.local >> >> Valid starting Expires Service principal >> 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/ipa.local at IPA.LOCAL >> Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 >> >> >> [root at server1 read]# klist -ke >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Principal >> ---- >> -------------------------------------------------------------------------- >> 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) >> 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) >> 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) >> 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) >> >> >> >> *Kinits * >> >> [root at server1 read]# kinit -k /etc/krb5.keytab host/server1.ipa.local > Sorry it should read 'kinit -kt /etc/krb5.keytab host/server1.ipa.local' > >> Extra arguments (starting with "host/server1.ipa.local"). >> Usage: kinit [-V] [-l lifetime] [-s start_time] >> [-r renewable_life] [-f | -F] [-p | -P] -n [-a | -A] [-C] >> [-E] >> [-v] [-R] [-k [-i|-t keytab_file]] [-c cachename] >> [-S service_name] [-T ticket_armor_cache] >> [-X [=]] [principal] >> >> options: -V verbose >> -l lifetime >> -s start time >> -r renewable lifetime >> -f forwardable >> -F not forwardable >> -p proxiable >> -P not proxiable >> -n anonymous >> -a include addresses >> -A do not include addresses >> -v validate >> -R renew >> -C canonicalize >> -E client is enterprise principal name >> -k use keytab >> -i use default client keytab (with -k) >> -t filename of keytab to use >> -c Kerberos 5 cache name >> -S service >> -T armor credential cache >> -X [=] >> >> [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local >> kinit: Cannot contact any KDC for realm 'IPA.LOCAL' while getting >> initial credentials >> [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local >> kinit: Program lacks support for encryption type while getting initial >> credentials >> >> >> Sean Hogan >> >> >> >> >> >> >> >> Inactive hide details for Martin Babinsky ---11/16/2016 09:33:08 AM---On >> 11/16/2016 05:14 PM, Sean Hogan wrote: > Hi Jakub,Martin Babinsky >> ---11/16/2016 09:33:08 AM---On 11/16/2016 05:14 PM, Sean Hogan wrote: > >> Hi Jakub, >> >> From: Martin Babinsky >> To: Sean Hogan/Durham/IBM at IBMUS, Jakub Hrozek >> Cc: freeipa-users at redhat.com >> Date: 11/16/2016 09:33 AM >> Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server >> >> ------------------------------------------------------------------------ >> >> >> >> On 11/16/2016 05:14 PM, Sean Hogan wrote: >>> Hi Jakub, >>> >>> Thanks... here is output >>> >>> >>> *klist -ke* >>> [root at server1 rusers]# klist -ke >>> Keytab name: FILE:/etc/krb5.keytab >>> KVNO Principal >>> ---- >>> > -------------------------------------------------------------------------- >>> 1 host/server1.ipa.local at IPA.LOCAL (aes256-cts-hmac-sha1-96) >>> 1 host/server1.ipa.local at IPA.LOCAL (aes128-cts-hmac-sha1-96) >>> 1 host/server1.ipa.local at IPA.LOCAL (des3-cbc-sha1) >>> 1 host/server1.ipa.local at IPA.LOCAL (arcfour-hmac) >>> >>> >>> >>> *kinit -k odd though as kinit -k seems to fail but kinit with admin >>> seems to work indicating I can hit the KDC even though kinit -k says I >>> cannot?* >>> >>> [root at server1 pam.d]# kinit -k server1 >>> kinit: Keytab contains no suitable keys for server1 at IPA.LOCAL while >>> getting initial credentials >>> [root at server1 pam.d]# kinit -k server1.IPA.LOCAL >>> kinit: Keytab contains no suitable keys for server1.IPA.LOCAL at IPA.LOCAL >>> while getting initial credentials >> You need to specify full principal name as printed from klist command, >> i.e. kinit -k /etc/krb5.keytab host/server1.ipa.local >> >>> [root at server1 pam.d]# kinit admin >>> Password for admin at ipa.local: >>> [root at server1 pam.d]# >>> [root at server1 pam.d]# klist >>> Ticket cache: KEYRING:persistent:1111111111:1111111111 >>> Default principal: admin at IPA.LOCAL >>> >>> Valid starting Expires Service principal >>> 11/16/2016 10:44:02 11/17/2016 10:43:54 krbtgt/IPA.LOCAL at IPA.LOCAL >>> >>> [root at server1 pam.d]# ktutil >>> ktutil: rkt /etc/krb5.keytab >>> ktutil: l >>> slot KVNO Principal >>> ---- ---- >>> --------------------------------------------------------------------- >>> 1 1 host/server1.ipa.local at IPA.LOCAL >>> 2 1 host/server1.ipa.local at IPA.LOCAL >>> 3 1 host/server1.ipa.local at IPA.LOCAL >>> 4 1 host/server1.ipa.local at IPA.LOCAL >>> >>> >>> >>> *Added debug_level = 10 on the domain section of sssd.conf and restarted >>> is all I see* >>> [root at server1 sssd]# cat ldap_child.log >>> (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18951]]]] >>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >>> lacks support for encryption type >>> (Wed Nov 16 10:57:50 2016) [[sssd[ldap_child[18954]]]] >>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >>> lacks support for encryption type >>> (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18956]]]] >>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >>> lacks support for encryption type >>> (Wed Nov 16 10:57:56 2016) [[sssd[ldap_child[18957]]]] >>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >>> lacks support for encryption type >>> (Wed Nov 16 10:58:02 2016) [[sssd[ldap_child[18958]]]] >>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >>> lacks support for encryption type >>> (Wed Nov 16 10:59:26 2016) [[sssd[ldap_child[18977]]]] >>> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Program >>> lacks support for encryption type >>> >>> >>> >>> >>> *Additonal:* >>> >>> [root at server1 rusers]# systemctl -l status sssd.service >>> sssd.service - System Security Services Daemon >>> Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) >>> Drop-In: /etc/systemd/system/sssd.service.d >>> ??journal.conf >>> Active: active (running) since Wed 2016-11-16 10:30:43 EST; 17s ago >>> Process: 3041 ExecStart=/usr/sbin/sssd -D -f (code=exited, >> status=0/SUCCESS) >>> Main PID: 3042 (sssd) >>> CGroup: /system.slice/sssd.service >>> ??3042 /usr/sbin/sssd -D -f >>> ??3043 /usr/libexec/sssd/sssd_be --domain ipa.local --uid 0 --gid 0 >>> --debug-to-files >>> ??3044 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files >>> ??3045 /usr/libexec/sssd/sssd_sudo --uid 0 --gid 0 --debug-to-files >>> ??3046 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files >>> ??3047 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --debug-to-files >>> ??3048 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --debug-to-files >>> >>> Nov 16 10:30:43 server1.ipa.local sssd[3042]: Starting up >>> Nov 16 10:30:43 server1.ipa.local sssd[be[ipa.local]][3043]: Starting up >>> Nov 16 10:30:43 server1.ipa.local sssd[sudo][3045]: Starting up >>> Nov 16 10:30:43 server1.ipa.local sssd[pam][3046]: Starting up >>> Nov 16 10:30:43 server1.ipa.local sssd[nss][3044]: Starting up >>> Nov 16 10:30:43 server1.ipa.local sssd[ssh][3047]: Starting up >>> Nov 16 10:30:43 server1.ipa.local sssd[pac][3048]: Starting up >>> Nov 16 10:30:43 server1.ipa.local systemd[1]: Started System Security >>> Services Daemon. >>> Nov 16 10:30:55 server1.ipa.local [sssd[ldap_child[3055]]][3055]: Failed >>> to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: >>> Decrypt integrity check failed. Unable to create GSSAPI-encrypted LDAP >>> connection. >>> [root at server1 rusers]# >>> >>> Seeing this in /var/log/sssd/sssd_ipa.local.log >>> >>> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [be_process_init] >>> (0x0010): fatal error initializing data providers >>> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [main] (0x0010): Could >>> not initialize backend [14] >>> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] >>> [select_principal_from_keytab] (0x0010): Failed to read keytab >>> [default]: Bad address >>> (Tue Nov 15 20:04:39 2016) [sssd[be[ipa.local]]] [load_backend_module] >>> (0x0010): Error (14) in module (ipa) initialization (sssm_ipa_id_init)! >>> >>> This is also strange but might be side effect I assume.. we mount NFS v4 >>> home dir with automount for central homes and profiles.. on the boxes >>> having this issue some of the IDs show just the UID numbers/GID numebrs >>> where some of the IDs actually show the UID name/GID name. We have over >>> 2k servers showing the UID name/GID name with no issues.. just the boxes >>> having this issue. >>> >>> >>> >>> Sean Hogan >>> >>> >>> >>> >>> >>> >>> Inactive hide details for Jakub Hrozek ---11/16/2016 02:29:52 AM---On >>> Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: Jakub Hrozek >>> ---11/16/2016 02:29:52 AM---On Tue, Nov 15, 2016 at 07:24:38PM -0700, >>> Sean Hogan wrote: > >>> >>> From: Jakub Hrozek >>> To: freeipa-users at redhat.com >>> Date: 11/16/2016 02:29 AM >>> Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server >>> Sent by: freeipa-users-bounces at redhat.com >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> On Tue, Nov 15, 2016 at 07:24:38PM -0700, Sean Hogan wrote: >>>> >>>> >>>> Hello, >>>> >>>> >>>> I am starting to see some issues with a few RHEL7 boxes I have been >>>> enrolling to my RHEL 6 IPA server regarding encryption. >>>> >>>> >>>> RHEL 7 client >>>> Red Hat Enterprise Linux Server release 7.1 (Maipo) >>>> sssd-ipa-1.12.2-58.el7_1.18.x86_64 >>>> ipa-client-4.1.0-18.el7_1.4.x86_64 >>>> >>>> RHEL 6 Server >>>> Red Hat Enterprise Linux Server release 6.8 (Santiago) >>>> sssd-ipa-1.13.3-22.el6_8.4.x86_64 >>>> ipa-server-3.0.0-50.el6.1.x86_64 >>>> >>>> >>>> The RHEL 7 client shows this in messages >>>> >>>> Nov 15 21:13:02 server1 [sssd[ldap_child[26640]]]: Program lacks support >>>> for encryption type >>> >>> Could you post a more verbose ldap_child log (debug_level=10 includes >>> KRB5_TRACE-level messages) so that we see what kind of crypto was used? >>> >>>> Nov 15 18:08:51 server1 [sssd[ldap_child[7774]]]: Failed to initialize >>>> credentials using keytab [MEMORY:/etc/krb5.keytab]: Decrypt integrity >>> check >>>> failed. Unable to create GSSAPI-encrypted LDAP connection. >>>> >>>> I am also not seeing host certs for them on the ipa server but I do see >>>> them on the local box. >>>> >>>> [root at server1 pam.d]# ktutil >>> >>> Can you run klist -ke as well to see what encryption types are included >>> in the keytab? >>> >>> Is it possible to run "kinit -k" on the client? >>> >>>> ktutil: rkt /etc/krb5.keytab >>>> ktutil: l >>>> slot KVNO Principal >>>> ---- ---- >>>> --------------------------------------------------------------------- >>>> 1 1 host/server1.ipa.local at IPA.LOCAL >>>> 2 1 host/server1.ipa.local at IPA.LOCAL >>>> 3 1 host/server1.ipa.local at IPA.LOCAL >>>> 4 1 host/server1.ipa.local at IPA.LOCAL >>>> ktutil: >>>> >>>> >>>> I have one RHEL 7 box with no issues as it was just enrolled (missing >> host >>>> certs in IPA though) and I compared and IPA ID login with a box not >>>> working >>>> *NOT Work* >>>> type=USER_AUTH msg=audit(1479259242.032:23532): pid=25040 uid=0 >>>> auid=4294967295 ses=4294967295 >>> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>>> msg='op=PAM:authentication grantors=? acct="janedoe" > exe="/usr/sbin/sshd" >>>> hostname=10.10.10.10 addr=10.10.10.9 terminal=ssh res=failed' >>>> >>>> vs >>>> >>>> Works >>>> type=USER_ACCT msg=audit(1479259478.378:709): pid=4721 uid=0 >>>> auid=4294967295 ses=4294967295 >>> subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>>> msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit >> acct="janedoe" >>>> exe="/usr/sbin/sshd" hostname=10.10.10.10 addr=10.10.10.10 terminal=ssh >>>> res=success' >>>> >>>> Its almost as if the pam files are not being read? >>>> >>>> >>>> >>>> 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 >>> >>> -- >>> 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 >>> >>> >>> >>> >>> >>> >> >> >> -- >> Martin^3 Babinsky >> >> >> >> > > > -- > Martin^3 Babinsky > > > > -- > 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 jhrozek at redhat.com Wed Nov 16 21:37:55 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 16 Nov 2016 22:37:55 +0100 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: References: <20161116092207.sgfqdomuhhs62v4x@hendrix> <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> Message-ID: <20161116213755.b72r3uyybhtsy2sj@hendrix> On Wed, Nov 16, 2016 at 09:56:59AM -0700, Sean Hogan wrote: > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Program lacks support for encryption type while getting initial > credentials OK, now there's at least the same error from kinit as sssd is generating. Can you runs this command prepended with KRB5_TRACE=/dev/stderr and perhaps also check the KDC logs for the same time? But frankly I don't know offhand what enctypes are supported by the RHEL-6 server's KDC.. From schogan at us.ibm.com Wed Nov 16 22:34:07 2016 From: schogan at us.ibm.com (Sean Hogan) Date: Wed, 16 Nov 2016 15:34:07 -0700 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: <20161116213755.b72r3uyybhtsy2sj@hendrix> References: <20161116092207.sgfqdomuhhs62v4x@hendrix> <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> <20161116213755.b72r3uyybhtsy2sj@hendrix> Message-ID: Hi Jakub, I ended up re-enrolling the box and it is behaving as expected except I am not getting a host cert. Robert indicated auto host cert no longer avail with rhel 7 but using the --request -cert option on enroll to get a host cert if I wanted one. I did so and get this in the install log 2016-11-16T22:00:53Z DEBUG Starting external process 2016-11-16T22:00:53Z DEBUG args='/bin/systemctl' 'is-active' 'certmonger.service' 2016-11-16T22:00:53Z DEBUG Process finished, return code=0 2016-11-16T22:00:53Z DEBUG stdout=active 2016-11-16T22:00:53Z DEBUG stderr= 2016-11-16T22:00:53Z ERROR certmonger request for host certificate failed Maybe this is an issue with RHEL 7(4.x) client hitting a RHEL 6 (3.x) IPA server? As for crypto on RHEL 6 IPA I have (if this is what you looking for). However this is modified version as it took me a while to get this list to pass tenable scans by modding the dse files. [root at ipa1 ~]# nmap --script ssl-enum-ciphers -p 636 `hostname` Starting Nmap 5.51 ( http://nmap.org ) at 2016-11-16 17:25 EST Nmap scan report for ipa1.ipa.local Host is up (0.000087s latency). PORT STATE SERVICE 636/tcp open ldapssl | ssl-enum-ciphers: | TLSv1.2 | Ciphers (14) | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA | TLS_DHE_RSA_WITH_AES_128_CBC_SHA | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | TLS_RSA_WITH_AES_128_CBC_SHA | TLS_RSA_WITH_AES_128_CBC_SHA256 | TLS_RSA_WITH_AES_128_GCM_SHA256 | TLS_RSA_WITH_AES_256_CBC_SHA | TLS_RSA_WITH_AES_256_CBC_SHA256 | Compressors (1) |_ uncompressed Sean Hogan From: Jakub Hrozek To: Sean Hogan/Durham/IBM at IBMUS Cc: Martin Babinsky , freeipa-users at redhat.com Date: 11/16/2016 02:38 PM Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server On Wed, Nov 16, 2016 at 09:56:59AM -0700, Sean Hogan wrote: > [root at server1 read]# kinit -kt /etc/krb5.keytab host/server1.ipa.local > kinit: Program lacks support for encryption type while getting initial > credentials OK, now there's at least the same error from kinit as sssd is generating. Can you runs this command prepended with KRB5_TRACE=/dev/stderr and perhaps also check the KDC logs for the same time? But frankly I don't know offhand what enctypes are supported by the RHEL-6 server's KDC.. -------------- 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: From mbasti at redhat.com Wed Nov 16 22:52:25 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Nov 2016 23:52:25 +0100 Subject: [Freeipa-users] Disabling Anonymous Binds (LDAP) In-Reply-To: <6E6DC47F-86E8-421E-A3FD-7CD2E3C5BC97@high5games.com> References: <8F863F5E-1F26-49F5-AA81-FD12FCEFF395@high5games.com> <6E6DC47F-86E8-421E-A3FD-7CD2E3C5BC97@high5games.com> Message-ID: <962016cb-6ead-0569-1e28-49b3c94659f7@redhat.com> So annonymous bind should be disabled can you try ldapsearch without any login information? On 16.11.2016 19:01, Dan.Finkelstein at high5games.com wrote: > > I'm on FreeIPA 4.x > > id:image001.jpg at 01D1C26F.0E28FA60 > > *Daniel Alex Finkelstein*| Lead Dev Ops Engineer > > _Dan.Finkelstein at h5g.com _ | 212.604.3447 > > One World Trade Center, New York, NY 10007 > > www.high5games.com > > Play High 5 Casino and > Shake the Sky > > Follow us on: Facebook , Twitter > , YouTube > , Linkedin > > > // > > /This message and any attachments may contain confidential or > privileged information and are only for the use of the intended > recipient of this message. If you are not the intended recipient, > please notify the sender by return email, and delete or destroy this > and all copies of this message and all attachments. Any unauthorized > disclosure, use, distribution, or reproduction of this message or any > attachments is prohibited and may be unlawful./ > > *From: *Martin Basti > *Date: *Wednesday, November 16, 2016 at 12:47 > *To: *Dan Finkelstein , > "freeipa-users at redhat.com" > *Subject: *Re: [Freeipa-users] Disabling Anonymous Binds (LDAP) > > On 16.11.2016 17:46, Dan.Finkelstein at high5games.com > wrote: > > I've seen some discussion in the (distant) past about disabling > anonymous binds to the LDAP component of IPA, and I'm wondering if > there's a preferred method to do it. Further, are there any known > problems with disabling anonymous binds when using FreeIPA? The > only modern documentation I can find is here: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html, > and I'm curious if FreeIPA has a different way. > > Thanks, > > Dan > > > > *Daniel Alex Finkelstein*| Lead Dev Ops Engineer > > _Dan.Finkelstein at h5g.com _ | > 212.604.3447 > > One World Trade Center, New York, NY 10007 > > www.high5games.com > > Play High 5 Casino and > Shake the Sky > > Follow us on: Facebook , > Twitter , YouTube > , Linkedin > > > // > > /This message and any attachments may contain confidential or > privileged information and are only for the use of the intended > recipient of this message. If you are not the intended recipient, > please notify the sender by return email, and delete or destroy > this and all copies of this message and all attachments. Any > unauthorized disclosure, use, distribution, or reproduction of > this message or any attachments is prohibited and may be unlawful./ > > > > It depends on your FreeIPA version, 3.x is explained in link you > posted, 4.x has a permission for this. > > Sa what is your freeIPA version? > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 4334 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 4335 bytes Desc: not available URL: From zhenglei at kylinos.cn Thu Nov 17 01:01:01 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Thu, 17 Nov 2016 09:01:01 +0800 Subject: [Freeipa-users] How to verify user with proxy server In-Reply-To: References: <04320952-158c-2f2b-e2d6-07bc9740e04c@redhat.com> Message-ID: Hi Petr, I have already successfully verified the freeipa user's login process by using 3rd-party RADIUS server for otp auth type. But I have a question that if there is no single radius auth type for a freeipa user. In other words, the 3rd-pardy RADIUS server simply provides a way for otp auth type, which means they need to be used in combination, because I have failed to use single radius auth type for a freeipa user by using 3rd-party RADIUS server. I don't know if I understand correctly. Thanks! ------------------ ?? ?????????? -------------------------- ?????? ?? ???18684703229 ???zhenglei at kylinos.cn ??????????????? ?????????????????????? ------------------ Original ------------------ From: "Petr Vobornik"; Date: Tue, Nov 15, 2016 04:58 PM To: "??"; "freeipa-users"; Subject: Re: [Freeipa-users] How to verify user with proxy server On 11/15/2016 09:38 AM, ?? wrote: > Thanks for your reply. I may not have described clearly. My use case is that I > have a freeipa user that uses password auth type by default, and I want to use > radius auth tpye to verify user according to 3rd-party radius server. FreeIPA is able to use 3rd-pardy RADIUS server for authentication. This is covered in: * https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/otp.html#migrating-proprietary-otp * http://www.freeipa.org/page/V4/OTP > > > > > > ------------------ > ?? > ?????????? > -------------------------- > ?????? ?? > ???18684703229 > ???zhenglei at kylinos.cn > ??????????????? > ?????????????????????? > ------------------ Original ------------------ > *From: * "Petr Vobornik"; > *Date: * Mon, Nov 14, 2016 07:08 PM > *To: * "??"; "freeipa-users"; > *Subject: * Re: [Freeipa-users] How to verify user with proxy server > On 11/14/2016 04:09 AM, ?? wrote: > > Hello everyone, > > > > I had already successfully verified user with otp. But I don't know how to > > verify user with proxy server, is there anyone know about it? There is no a > > complete solution on the website. > > > > Thanks! > > > > Could you describe your use case in more details? > > If you are asking about how to access IPA behind proxy, then checkout: > https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name > https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy > > Or other proxy threads on this list. > -- > Petr Vobornik > -- Petr Vobornik -------------- next part -------------- An HTML attachment was scrubbed... URL: From morgan at marodin.it Thu Nov 17 11:09:13 2016 From: morgan at marodin.it (Morgan Marodin) Date: Thu, 17 Nov 2016 12:09:13 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade Message-ID: Hello. This morning I've tried to upgrade my IPA server, but the upgrade failed, and now the service doesn't start! :( If I try lo launch the upgrade manually this is the output: *[root at mlv-ipa01 download]# ipa-server-upgradeUpgrading 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 configurationDone.Update completeUpgrading IPA servicesUpgrading the configuration of the IPA services[Verifying that root certificate is published][Migrate CRL publish directory]CRL tree already moved[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 enabledIPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.Unexpected error - see /var/log/ipaupgrade.log for details:CalledProcessError: Command '/bin/systemctl start httpd.service' returned non-zero exit status 1The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information* These are error logs of Apache: *[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] [pid 5664] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)[Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664] NSSSessionCacheTimeout is deprecated. Ignoring.[Thu Nov 17 11:48:45.830910 2016] [:error] [pid 5664] Certificate not found: 'Server-Cert'* The problem seems to be the *Server-Cert *that could not be found. But if I try to execute the certutil command manually I can see it: *[root at mlv-ipa01 log]# certutil -L -d /etc/httpd/alias/Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPISigning-Cert u,u,uipaCert u,u,uServer-Cert Pu,u,uIPA.MYDOMAIN.COM IPA CA CT,C,C* Could you help me? What could I try to do to restart my service? Thanks, Morgan -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.candler at pobox.com Thu Nov 17 12:00:07 2016 From: b.candler at pobox.com (Brian Candler) Date: Thu, 17 Nov 2016 12:00:07 +0000 Subject: [Freeipa-users] Disabling Anonymous Binds (LDAP) In-Reply-To: <8F863F5E-1F26-49F5-AA81-FD12FCEFF395@high5games.com> References: <8F863F5E-1F26-49F5-AA81-FD12FCEFF395@high5games.com> Message-ID: <079a9de5-050f-01f2-2638-b1a7fd39dcc0@pobox.com> On 16/11/2016 16:46, Dan.Finkelstein at high5games.com wrote: > I've seen some discussion in the (distant) past about disabling > anonymous binds to the LDAP component of IPA, and I'm wondering if > there's a preferred method to do it. Further, are there any known > problems with disabling anonymous binds when using FreeIPA? The only > modern documentation I can find is here: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html, > and I'm curious if FreeIPA has a different way. FWIW, I see the same here. Installed ipa-server under CentOS 7 (which gave me freeipa 4.2.0), and found anonymous binds allowed: tested by "ldapsearch -x ..." I was able to disable anonymous bind (and also disable unencrypted queries) by changing the cn=config entry: |dn: cn=config| |changetype: modify| |replace: nsslapd-allow-anonymous-access| |nsslapd-allow-anonymous-access: rootdse| |-| |replace: nsslapd-minssf| |nsslapd-minssf: 56| I don't think this replicated from master to slave though, and I ended up doing it on slaves as well. If there is an "official" way to disable anon bind on FreeIPA 4.x, I would like to know it. Thanks, Brian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Thu Nov 17 13:39:54 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 17 Nov 2016 14:39:54 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: Message-ID: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> On 11/17/2016 12:09 PM, Morgan Marodin wrote: > Hello. > > This morning I've tried to upgrade my IPA server, but the upgrade > failed, and now the service doesn't start! :( > > If I try lo launch the upgrade manually this is the output: > /[root at mlv-ipa01 download]# 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 > [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 > 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: > CalledProcessError: Command '/bin/systemctl start httpd.service' > returned non-zero exit status 1 > The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > more information/ > > These are error logs of Apache: > /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] [pid 5664] AH01232: > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664] > NSSSessionCacheTimeout is deprecated. Ignoring. > [Thu Nov 17 11:48:45.830910 2016] [:error] [pid 5664] Certificate not > found: 'Server-Cert'/ > > The problem seems to be the /Server-Cert /that could not be found. > But if I try to execute the certutil command manually I can see it:/ > [root at mlv-ipa01 log]# certutil -L -d /etc/httpd/alias/ > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > Signing-Cert u,u,u > ipaCert u,u,u > Server-Cert Pu,u,u > IPA.MYDOMAIN.COM IPA > CA CT,C,C/ > > Could you help me? > What could I try to do to restart my service? > Hi, I would first make sure that httpd is using /etc/httpd/alias as NSS DB (check the directive NSSCertificateDatabase in /etc/httpd/conf.d/nss.conf). Then it may be a file permission issue: the NSS DB should belong to root:apache (the relevant files are cert8.db, key3.db and secmod.db). You should also find a pwdfile.txt in the same directory, containing the NSS DB password. Check that the password is valid using certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt (if the command succeeds then the password in pwdfile is OK). You can also enable mod-nss debug in /etc/httpd/conf/nss.conf by setting "LogLevel debug", and check the output in /var/log/httpd/error_log. HTH, Flo. > Thanks, Morgan > > From sbose at redhat.com Thu Nov 17 14:09:19 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 17 Nov 2016 15:09:19 +0100 Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bindfailed(-2)[Localerror]' In-Reply-To: References: <20161110103243.GB19211@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161110111332.GC19211@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <20161117140919.GV28171@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, Nov 10, 2016 at 07:19:09PM +0800, Matrix wrote: > Hi, Sumit > > I have checked, and did not find anything more: > > error logs from /var/log/dirsrv/slapd-EXAMPLE-NET/access: > ....... > [10/Nov/2016:10:46:58 +0000] conn=816560 fd=189 slot=189 connection from 10.2.3.32 to 10.2.1.250 > [10/Nov/2016:10:46:58 +0000] conn=816560 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI > [10/Nov/2016:10:46:58 +0000] conn=816560 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress > [10/Nov/2016:10:46:58 +0000] conn=816560 op=-1 fd=189 closed - B1 Sorry, I still have no idea, maybe running ldapwhoami with '-d -1' might help to identify which step is failing. bye, Sumit > > ....... > > Matrix > > > ------------------ Original ------------------ > From: "Sumit Bose";; > Date: Thu, Nov 10, 2016 07:13 PM > To: "Matrix"; > Cc: "Sumit Bose"; "freeipa-users"; > Subject: Re: [Freeipa-users] sssd failed with 'ldap_sasl_bindfailed(-2)[Localerror]' > > > > On Thu, Nov 10, 2016 at 06:48:54PM +0800, Matrix wrote: > > Hi, Sumit > > > > Thanks for your reply > > > > I have tried. still failed > > Do you see any related messages on the LDAP server side? > > bye, > Sumit > > > > > # cat /etc/openldap/ldap.conf | grep -v ^# > > > > URI ldap://ipaslave.stg.example.net > > BASE dc=example,dc=net > > TLS_CACERT /etc/ipa/ca.crt > > SASL_MECH GSSAPI > > TLS_REQCERT allow > > SASL_NOCANON on > > > > > > # cat /etc/krb5.conf| grep rdns > > rdns = false > > > > Matrix > > > > ------------------ Original ------------------ > > From: "Sumit Bose";; > > Date: Thu, Nov 10, 2016 06:32 PM > > To: "freeipa-users"; > > > > Subject: Re: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed(-2)[Localerror]' > > > > > > > > On Thu, Nov 10, 2016 at 05:22:26PM +0800, Matrix wrote: > > > debug steps have been tried: > > > > > > 1 kinit is workable: > > > # /usr/kerberos/bin/kinit -k host/client02.stg.example.net at EXAMPLE.NET > > > > > > # /usr/kerberos/bin/klist > > > Ticket cache: FILE:/tmp/krb5cc_0 > > > Default principal: host/client02.stg.example.net at EXAMPLE.NET > > > > > > Valid starting Expires Service principal > > > 11/10/16 09:18:00 11/11/16 09:17:35 krbtgt/EXAMPLE.NET at EXAMPLE.NET > > > > > > Kerberos 4 ticket cache: /tmp/tkt0 > > > klist: You have no tickets cached > > > > > > 2 ldapwhoami with krb auth failed. > > > > > > # ldapwhoami -Y GSSAPI -h ipaslave.stg.example.net > > > SASL/GSSAPI authentication started > > > ldap_sasl_interactive_bind_s: Local error (-2) > > > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Mutual authentication failed) > > > > > > > Have you made sure that canonicalizing is disabled, i.e. > > /etc/krb5.conf: > > [libdefaults] > > ... > > rdns = false > > ... > > > > /etc/openldap/ldap.conf > > ... > > SASL_NOCANON on > > ... > > > > HTH > > > > bye, > > Sumit > > > > > > > > Matrix > > > > > > ------------------ Original ------------------ > > > From: "Matrix";; > > > Date: Thu, Nov 10, 2016 02:11 PM > > > To: "freeipa-users"; > > > > > > Subject: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed (-2)[Localerror]' > > > > > > > > > > > > Hi, > > > > > > I have installed sssd in a RHEL5 client. > > > > > > ipa-client/sssd version: > > > ipa-client-2.1.3-7.el5 > > > sssd-client-1.5.1-71.el5 > > > sssd-1.5.1-71.el5 > > > > > > sssd failed to get ipa user info with 'ldap_sasl_bind failed (-2)[Local error]'. > > > > > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/client02.stg.example.net > > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (1): ldap_sasl_bind failed (-2)[Local error] > > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (7): Waiting for child [11117]. > > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] (4): child [11117] finished successfully. > > > > > > I have tried to google to find root cause. some link explained it should be something wrong with dns. I have double confirmed it. > > > > > > # nslookup client02.stg.example.net > > > Server: 10.2.1.21 > > > Address: 10.2.1.21#53 > > > > > > Name: client02.stg.example.net > > > Address: 10.2.3.32 > > > > > > > > > # nslookup 10.2.3.32 > > > Server: 10.2.1.21 > > > Address: 10.2.1.21#53 > > > > > > 32.3.2.10.in-addr.arpa name = client02.stg.example.net. > > > > > > > > > # nslookup ipaslave.stg.example.net > > > Server: 10.2.1.21 > > > Address: 10.2.1.21#53 > > > > > > Name: ipaslave.stg.example.net > > > Address: 10.2.1.250 > > > > > > # nslookup 10.2.1.250 > > > Server: 10.2.1.21 > > > Address: 10.2.1.21#53 > > > > > > 250.1.2.10.in-addr.arpa name = ipaslave.stg.example.net. > > > > > > Any hints or troubleshooting ideas would be appreciated. > > > > > > Matrix > > > > > -- > > > 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 From BJB at jndata.dk Thu Nov 17 14:09:14 2016 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Thu, 17 Nov 2016 14:09:14 +0000 Subject: [Freeipa-users] Client x.x.xx - RFC 1918 response from Internet in /var/log/messages In-Reply-To: <6620537c-79ee-dc7d-b076-0359ac4d290f@redhat.com> References: <89213DDB84447F44A8E8950A5C2185E0482EB1EE@SJN01013.jnmain00.corp.jndata.net> <6620537c-79ee-dc7d-b076-0359ac4d290f@redhat.com> Message-ID: <89213DDB84447F44A8E8950A5C2185E0482EB66D@SJN01013.jnmain00.corp.jndata.net> Excellent - thanks. I was missing some forward statements for a few private segments. Venlig hilsen Bjarne Blichfeldt -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: 16. november 2016 14:36 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Client x.x.xx - RFC 1918 response from Internet in /var/log/messages On 16.11.2016 12:56, Bjarne Blichfeldt wrote: > Just updated a couple of free-ipa servers to: > ipa-server-dns-4.4.0-12.el7.noarch > redhat-release-server-7.3-7.el7.x86_64 > > Before the update, I resolved the issue with RFC messages by: > /etc/named.conf: > options { > disable-empty-zone "10.in-addr.arpa."; > : > > Now after the update the RFS messages has returned. I read in the changelog for 4.4 that this issue was resolved. > What did I miss? This sort of misconfiguration is described on https://deepthought.isc.org/article/AA-00204/0/What-does-RFC-1918-response-from-Internet-for-0.0.0.10.IN-ADDR.ARPA-mean.html Please follow advices on ISC web to fix this. You are most probably sending your queries to the public Internet instead of your internal network. -- Petr^2 Spacek -- 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 morgan at marodin.it Thu Nov 17 14:25:33 2016 From: morgan at marodin.it (Morgan Marodin) Date: Thu, 17 Nov 2016 15:25:33 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> Message-ID: Hi Florence. Thanks for your support. Yes, httpd is using /etc/httpd/alias as NSS DB. And seems that all permissions and certificates are good: *[root at mlv-ipa01 ~]# ls -l /etc/httpd/alias/total 184-r--r--r-- 1 root root 1345 Sep 7 2015 cacert.asc-rw-rw---- 1 root apache 65536 Nov 17 11:06 cert8.db-rw-r-----. 1 root apache 65536 Sep 4 2015 cert8.db.orig-rw-------. 1 root root 4833 Sep 4 2015 install.log-rw-rw---- 1 root apache 16384 Nov 17 11:06 key3.db-rw-r-----. 1 root apache 16384 Sep 4 2015 key3.db.origlrwxrwxrwx 1 root root 24 Nov 17 10:24 libnssckbi.so -> /usr/lib64/libnssckbi.so-rw-rw---- 1 root apache 20 Sep 7 2015 pwdfile.txt-rw-rw---- 1 root apache 16384 Sep 7 2015 secmod.db-rw-r-----. 1 root apache 16384 Sep 4 2015 secmod.db.orig* And password validations seems ok, too: *[root at mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txtcertutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"< 0> rsa **************************************** NSS Certificate DB:Server-Cert< 1> rsa **************************************** NSS Certificate DB:Signing-Cert< 2> rsa **************************************** NSS Certificate DB:ipaCert* Enabling mod-nss debug I can see these logs: *[root at mlv-ipa01 ~]# tail -f /var/log/httpd/error_log[Thu Nov 17 15:05:10.807603 2016] [suexec:notice] [pid 10660] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)[Thu Nov 17 15:05:10.807958 2016] [:warn] [pid 10660] NSSSessionCacheTimeout is deprecated. Ignoring.[Thu Nov 17 15:05:10.807991 2016] [:debug] [pid 10660] nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com -> Server-Cert[Thu Nov 17 15:05:11.002664 2016] [:info] [pid 10660] Configuring server for SSL protocol[Thu Nov 17 15:05:11.002817 2016] [:debug] [pid 10660] nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0[Thu Nov 17 15:05:11.002838 2016] [:debug] [pid 10660] nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1[Thu Nov 17 15:05:11.002847 2016] [:debug] [pid 10660] nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2[Thu Nov 17 15:05:11.002856 2016] [:debug] [pid 10660] nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum)[Thu Nov 17 15:05:11.002876 2016] [:debug] [pid 10660] nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum)[Thu Nov 17 15:05:11.003099 2016] [:debug] [pid 10660] nss_engine_init.c(906): Disabling TLS Session Tickets[Thu Nov 17 15:05:11.003198 2016] [:debug] [pid 10660] nss_engine_init.c(916): Enabling DHE key exchange[Thu Nov 17 15:05:11.003313 2016] [:debug] [pid 10660] nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL ciphers [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha][Thu Nov 17 15:05:11.003469 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: rsa_null_md5[Thu Nov 17 15:05:11.003483 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: rsa_null_sha[Thu Nov 17 15:05:11.003491 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: rsa_rc4_40_md5[Thu Nov 17 15:05:11.003509 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: rsa_rc4_128_md5[Thu Nov 17 15:05:11.003632 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: rsa_rc4_128_sha[Thu Nov 17 15:05:11.003740 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: rsa_rc2_40_md5[Thu Nov 17 15:05:11.003747 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: rsa_des_sha[Thu Nov 17 15:05:11.003802 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: rsa_3des_sha[Thu Nov 17 15:05:11.003902 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: dhe_rsa_des_sha[Thu Nov 17 15:05:11.004001 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: rsa_aes_128_sha[Thu Nov 17 15:05:11.004167 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: rsa_aes_256_sha[Thu Nov 17 15:05:11.004180 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: null_sha_256[Thu Nov 17 15:05:11.004191 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: aes_128_sha_256[Thu Nov 17 15:05:11.004285 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: aes_256_sha_256[Thu Nov 17 15:05:11.004352 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: camelia_128_sha[Thu Nov 17 15:05:11.004437 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: rsa_des_56_sha[Thu Nov 17 15:05:11.004509 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: rsa_rc4_56_sha[Thu Nov 17 15:05:11.004606 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: camelia_256_sha[Thu Nov 17 15:05:11.004668 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: rsa_aes_128_gcm_sha_256[Thu Nov 17 15:05:11.004724 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: rsa_aes_256_gcm_sha_384[Thu Nov 17 15:05:11.004806 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: fips_3des_sha[Thu Nov 17 15:05:11.004881 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: fips_des_sha[Thu Nov 17 15:05:11.004956 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: dhe_rsa_3des_sha[Thu Nov 17 15:05:11.005027 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: dhe_rsa_aes_128_sha[Thu Nov 17 15:05:11.005106 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: dhe_rsa_aes_256_sha[Thu Nov 17 15:05:11.005173 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: dhe_rsa_camellia_128_sha[Thu Nov 17 15:05:11.005238 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: dhe_rsa_camellia_256_sha[Thu Nov 17 15:05:11.005309 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: dhe_rsa_aes_128_sha256[Thu Nov 17 15:05:11.005380 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: dhe_rsa_aes_256_sha256[Thu Nov 17 15:05:11.005452 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: dhe_rsa_aes_128_gcm_sha_256[Thu Nov 17 15:05:11.005524 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: dhe_rsa_aes_256_gcm_sha_384[Thu Nov 17 15:05:11.005596 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_ecdsa_null_sha[Thu Nov 17 15:05:11.005655 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_ecdsa_rc4_128_sha[Thu Nov 17 15:05:11.005698 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_ecdsa_3des_sha[Thu Nov 17 15:05:11.005814 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_ecdsa_aes_128_sha[Thu Nov 17 15:05:11.005859 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_ecdsa_aes_256_sha[Thu Nov 17 15:05:11.005904 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdhe_ecdsa_null_sha[Thu Nov 17 15:05:11.005948 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdhe_ecdsa_rc4_128_sha[Thu Nov 17 15:05:11.005993 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdhe_ecdsa_3des_sha[Thu Nov 17 15:05:11.006037 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: ecdhe_ecdsa_aes_128_sha[Thu Nov 17 15:05:11.006081 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: ecdhe_ecdsa_aes_256_sha[Thu Nov 17 15:05:11.006124 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_rsa_null_sha[Thu Nov 17 15:05:11.006181 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_rsa_128_sha[Thu Nov 17 15:05:11.006223 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_rsa_3des_sha[Thu Nov 17 15:05:11.006261 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_rsa_aes_128_sha[Thu Nov 17 15:05:11.006304 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_rsa_aes_256_sha[Thu Nov 17 15:05:11.006348 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdhe_rsa_null[Thu Nov 17 15:05:11.006391 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdhe_rsa_rc4_128_sha[Thu Nov 17 15:05:11.006428 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdhe_rsa_3des_sha[Thu Nov 17 15:05:11.006466 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_sha[Thu Nov 17 15:05:11.006503 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_256_sha[Thu Nov 17 15:05:11.006541 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_anon_null_sha[Thu Nov 17 15:05:11.006580 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_anon_rc4_128sha[Thu Nov 17 15:05:11.006622 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_anon_3des_sha[Thu Nov 17 15:05:11.006649 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_anon_aes_128_sha[Thu Nov 17 15:05:11.006682 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdh_anon_aes_256_sha[Thu Nov 17 15:05:11.006725 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdhe_ecdsa_aes_128_sha_256[Thu Nov 17 15:05:11.006730 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdhe_rsa_aes_128_sha_256[Thu Nov 17 15:05:11.006734 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: ecdhe_ecdsa_aes_128_gcm_sha_256[Thu Nov 17 15:05:11.006737 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdhe_ecdsa_aes_256_sha_384[Thu Nov 17 15:05:11.006740 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Disable cipher: ecdhe_rsa_aes_256_sha_384[Thu Nov 17 15:05:11.006743 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: ecdhe_ecdsa_aes_256_gcm_sha_384[Thu Nov 17 15:05:11.006746 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_256_gcm_sha_384[Thu Nov 17 15:05:11.006749 2016] [:debug] [pid 10660] nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256[Thu Nov 17 15:05:11.006759 2016] [:info] [pid 10660] Using nickname Server-Cert.[Thu Nov 17 15:05:11.006771 2016] [:error] [pid 10660] Certificate not found: 'Server-Cert'[root at mlv-ipa01 ~]# tail -f /var/log/messagesNov 17 15:05:04 mlv-ipa01 systemd[1]: Starting Identity, Policy, Audit...Nov 17 15:05:07 mlv-ipa01 ipactl: Existing service file detected!Nov 17 15:05:07 mlv-ipa01 ipactl: Assuming stale, cleaning and proceedingNov 17 15:05:07 mlv-ipa01 systemd[1]: Starting 389 Directory Server IPA-MYDOMAIN-COM....Nov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.799208210 +0100] SSL alert: Sending pin request to SVRCore. You may need to run systemd-tty-ask-password-agent to provide the password.Nov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.803853873 +0100] SSL alert: Security Initialization: Enabling default cipher set.Nov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.805145890 +0100] SSL alert: Configured NSS CiphersNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.806316182 +0100] SSL alert: #011TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.807723387 +0100] SSL alert: #011TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.808923825 +0100] SSL alert: #011TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.810155882 +0100] SSL alert: #011TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.811325853 +0100] SSL alert: #011TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.812784224 +0100] SSL alert: #011TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.813976726 +0100] SSL alert: #011TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.815120447 +0100] SSL alert: #011TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.816327755 +0100] SSL alert: #011TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.817977411 +0100] SSL alert: #011TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.819254448 +0100] SSL alert: #011TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.820464679 +0100] SSL alert: #011TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.821632382 +0100] SSL alert: #011TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.822786869 +0100] SSL alert: #011TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.823971028 +0100] SSL alert: #011TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.825053303 +0100] SSL alert: #011TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.826194181 +0100] SSL alert: #011TLS_RSA_WITH_AES_256_GCM_SHA384: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.827825315 +0100] SSL alert: #011TLS_RSA_WITH_AES_256_CBC_SHA: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.829462992 +0100] SSL alert: #011TLS_RSA_WITH_AES_256_CBC_SHA256: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.830793383 +0100] SSL alert: #011TLS_RSA_WITH_AES_128_GCM_SHA256: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.832242224 +0100] SSL alert: #011TLS_RSA_WITH_AES_128_CBC_SHA: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.833873583 +0100] SSL alert: #011TLS_RSA_WITH_AES_128_CBC_SHA256: enabledNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.885093482 +0100] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2Nov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.886826410 +0100] 389-Directory/1.3.5.10 B2016.309.1527 starting upNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.924968051 +0100] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5MatchNov 17 15:05:07 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:07.960936427 +0100] WARNING: changelog: entry cache size 2097152 B is less than db size 15654912 B; We recommend to increase the entry cache size nsslapd-cachememsize.Nov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.051517901 +0100] schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup!Nov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.088107275 +0100] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.089975405 +0100] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.091605059 +0100] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.093396173 +0100] NSACLPlugin - The ACL target ou=sudoers,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.095072910 +0100] NSACLPlugin - The ACL target cn=users,cn=compat,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.097647403 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.099159503 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.100703471 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.102286938 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.103852482 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.105586463 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.107026360 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.108476210 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.110187640 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.111655019 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.113841889 +0100] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.133500119 +0100] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.135098802 +0100] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=mydomain,dc=com does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.363531779 +0100] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not existNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.373037600 +0100] Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipa,dc=mydomain,dc=com--no CoS Templates found, which should be added before the CoS Definition.Nov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.412160395 +0100] set_krb5_creds - Could not get initial credentials for principal [ldap/mlv-ipa01.ipa.mydomain.com at IPA.MYDOMAIN.COM ] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm)Nov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.417620890 +0100] schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds!Nov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.430081973 +0100] slapd started. Listening on All Interfaces port 389 for LDAP requestsNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.431273848 +0100] Listening on All Interfaces port 636 for LDAPS requestsNov 17 15:05:08 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:08.432861124 +0100] Listening on /var/run/slapd-IPA-MYDOMAIN-COM.socket for LDAPI requestsNov 17 15:05:08 mlv-ipa01 systemd[1]: Started 389 Directory Server IPA-MYDOMAIN-COM..Nov 17 15:05:09 mlv-ipa01 systemd[1]: Starting Kerberos 5 KDC...Nov 17 15:05:09 mlv-ipa01 systemd[1]: Started Kerberos 5 KDC.Nov 17 15:05:09 mlv-ipa01 systemd[1]: Starting Kerberos 5 Password-changing and Administration...Nov 17 15:05:09 mlv-ipa01 systemd[1]: Started Kerberos 5 Password-changing and Administration.Nov 17 15:05:09 mlv-ipa01 systemd[1]: Starting Generate rndc key for BIND (DNS)...Nov 17 15:05:09 mlv-ipa01 systemd[1]: Started Generate rndc key for BIND (DNS).Nov 17 15:05:09 mlv-ipa01 systemd[1]: Starting Berkeley Internet Name Domain (DNS) with native PKCS#11...Nov 17 15:05:09 mlv-ipa01 bash: zone localhost.localdomain/IN: loaded serial 0Nov 17 15:05:09 mlv-ipa01 bash: zone localhost/IN: loaded serial 0Nov 17 15:05:09 mlv-ipa01 bash: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0Nov 17 15:05:09 mlv-ipa01 bash: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0Nov 17 15:05:09 mlv-ipa01 bash: zone 0.in-addr.arpa/IN: loaded serial 0Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: starting BIND 9.9.4-RedHat-9.9.4-38.el7_3 -u namedNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--with-geoip' '--enable-ipv6' '--enable-filter-aaaa' '--enable-rrl' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--enable-exportlib' '--with-export-libdir=/usr/lib64' '--with-export-includedir=/usr/include' '--includedir=/usr/include/bind9' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE'Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: ----------------------------------------------------Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: BIND 9 is maintained by Internet Systems Consortium,Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: Inc. (ISC), a non-profit 501(c)(3) public-benefitNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: corporation. Support and training for BIND 9 areNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: available at https://www.isc.org/support Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: ----------------------------------------------------Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: adjusted limit on open files from 4096 to 1048576Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: found 8 CPUs, using 8 worker threadsNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: using 8 UDP listeners per interfaceNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: using up to 4096 socketsNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: loading configuration from '/etc/named.conf'Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: reading built-in trusted keys from file '/etc/named.iscdlv.key'Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: initializing GeoIP Country (IPv4) (type 1) DBNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GEO-106FREE 20160607 Build 1 Copyright (c) 2016 MaxMindNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: initializing GeoIP Country (IPv6) (type 12) DBNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GEO-106FREE 20160607 Build 1 CopyNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP City (IPv4) (type 2) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP City (IPv4) (type 6) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP City (IPv6) (type 30) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP City (IPv6) (type 31) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP Region (type 3) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP Region (type 7) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP ISP (type 4) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP Org (type 5) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP AS (type 9) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP Domain (type 11) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: GeoIP NetSpeed (type 10) DB not availableNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: using default UDP/IPv4 port range: [1024, 65535]Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: using default UDP/IPv6 port range: [1024, 65535]Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: listening on IPv6 interfaces, port 53Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: listening on IPv4 interface lo, 127.0.0.1#53Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: listening on IPv4 interface eth0, 192.168.0.65#53Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: generating session key for dynamic DNSNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: sizing zone task pool based on 6 zonesNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: set up managed keys zone for view _default, file '/var/named/dynamic/managed-keys.bind'Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: bind-dyndb-ldap version 10.0 compiled at 16:25:21 Nov 4 2016, compiler 4.8.5 20150623 (Red Hat 4.8.5-11)Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: option 'serial_autoincrement' is not supported, ignoringNov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: automatic empty zone: 10.IN-ADDR.ARPA...Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: command channel listening on 127.0.0.1#953Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: command channel listening on ::1#953Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: managed-keys-zone: loaded serial 10165Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: ignoring inherited 'forward first;' for zone '.' - did you want 'forward only;' to override automatic empty zone '10.IN-ADDR.ARPA'?...Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: zone ipa.mydomain.com/IN : loaded serial 1479391509Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: zone ipa.mydomain.com/IN : sending notifies (serial 1479391509)Nov 17 15:05:09 mlv-ipa01 named-pkcs11[10634]: 1 master zones from LDAP instance 'ipa' loaded (1 zones defined, 0 inactive, 0 failed to load)Nov 17 15:05:10 mlv-ipa01 ipa-httpd-kdcproxy: ipa : INFO KDC proxy enabledNov 17 15:05:11 mlv-ipa01 systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURENov 17 15:05:11 mlv-ipa01 kill: kill: cannot find process ""Nov 17 15:05:11 mlv-ipa01 systemd[1]: httpd.service: control process exited, code=exited status=1Nov 17 15:05:11 mlv-ipa01 systemd[1]: Failed to start The Apache HTTP Server.Nov 17 15:05:11 mlv-ipa01 systemd[1]: Unit httpd.service entered failed state.Nov 17 15:05:11 mlv-ipa01 systemd[1]: httpd.service failed.Nov 17 15:05:11 mlv-ipa01 systemctl[10657]: Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.Nov 17 15:05:11 mlv-ipa01 ipactl: Failed to start httpd ServiceNov 17 15:05:11 mlv-ipa01 ipactl: Shutting downNov 17 15:05:11 mlv-ipa01 systemd[1]: Stopping Kerberos 5 KDC...Nov 17 15:05:11 mlv-ipa01 systemd[1]: Stopped Kerberos 5 KDC.Nov 17 15:05:11 mlv-ipa01 systemd[1]: Stopping Kerberos 5 Password-changing and Administration...Nov 17 15:05:11 mlv-ipa01 systemd[1]: kadmin.service: main process exited, code=exited, status=2/INVALIDARGUMENTNov 17 15:05:11 mlv-ipa01 systemd[1]: Stopped Kerberos 5 Password-changing and Administration.Nov 17 15:05:11 mlv-ipa01 systemd[1]: Unit kadmin.service entered failed state.Nov 17 15:05:11 mlv-ipa01 systemd[1]: kadmin.service failed.Nov 17 15:05:11 mlv-ipa01 systemd[1]: Stopping Berkeley Internet Name Domain (DNS) with native PKCS#11...Nov 17 15:05:11 mlv-ipa01 named-pkcs11[10634]: received control channel command 'stop'Nov 17 15:05:11 mlv-ipa01 named-pkcs11[10634]: shutting down: flushing changesNov 17 15:05:11 mlv-ipa01 named-pkcs11[10634]: stopping command channel on 127.0.0.1#953Nov 17 15:05:11 mlv-ipa01 named-pkcs11[10634]: stopping command channel on ::1#953Nov 17 15:05:11 mlv-ipa01 named-pkcs11[10634]: zone ipa.mydomain.com/IN : shutting downNov 17 15:05:11 mlv-ipa01 named-pkcs11[10634]: no longer listening on ::#53Nov 17 15:05:11 mlv-ipa01 named-pkcs11[10634]: no longer listening on 127.0.0.1#53Nov 17 15:05:11 mlv-ipa01 named-pkcs11[10634]: no longer listening on 192.168.0.65#53Nov 17 15:05:11 mlv-ipa01 named-pkcs11[10634]: exitingNov 17 15:05:11 mlv-ipa01 systemd[1]: Stopped Berkeley Internet Name Domain (DNS) with native PKCS#11.Nov 17 15:05:11 mlv-ipa01 systemd[1]: Stopping IPA memcached daemon, increases IPA server performance...Nov 17 15:05:11 mlv-ipa01 systemd[1]: Stopped IPA memcached daemon, increases IPA server performance.Nov 17 15:05:11 mlv-ipa01 systemctl[10685]: Warning: httpd.service changed on disk. Run 'systemctl daemon-reload' to reload units.Nov 17 15:05:11 mlv-ipa01 systemd[1]: Stopping 389 Directory Server IPA-MYDOMAIN-COM....Nov 17 15:05:11 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:11.357603144 +0100] slapd shutting down - signaling operation threads - op stack size 1 max work q size 1 max work q stack size 1Nov 17 15:05:11 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:11.359785218 +0100] slapd shutting down - waiting for 25 threads to terminateNov 17 15:05:11 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:11.361826680 +0100] slapd shutting down - closing down internal subsystems and pluginsNov 17 15:05:13 mlv-ipa01 ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available (default cache: /tmp/krb5cc_996))Nov 17 15:05:13 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:13.811837199 +0100] Waiting for 4 database threads to stopNov 17 15:05:14 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:14.000534924 +0100] All database threads now stoppedNov 17 15:05:14 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:14.015405431 +0100] slapd shutting down - freed 1 work q stack objects - freed 1 op stack objectsNov 17 15:05:14 mlv-ipa01 ns-slapd: [17/Nov/2016:15:05:14.437288197 +0100] slapd stopped.Nov 17 15:05:14 mlv-ipa01 systemd[1]: Stopped 389 Directory Server IPA-MYDOMAIN-COM..Nov 17 15:05:14 mlv-ipa01 ipactl: Hint: You can use --ignore-service-failure option for forced start in case that a non-critical service failedNov 17 15:05:14 mlv-ipa01 ipactl: Aborting ipactlNov 17 15:05:14 mlv-ipa01 ipactl: Starting Directory ServiceNov 17 15:05:14 mlv-ipa01 ipactl: Starting krb5kdc ServiceNov 17 15:05:14 mlv-ipa01 ipactl: Starting kadmin ServiceNov 17 15:05:14 mlv-ipa01 ipactl: Starting named ServiceNov 17 15:05:14 mlv-ipa01 ipactl: Starting ipa_memcached ServiceNov 17 15:05:14 mlv-ipa01 ipactl: Starting httpd ServiceNov 17 15:05:14 mlv-ipa01 systemd[1]: ipa.service: main process exited, code=exited, status=1/FAILURENov 17 15:05:14 mlv-ipa01 systemd[1]: Failed to start Identity, Policy, Audit.Nov 17 15:05:14 mlv-ipa01 systemd[1]: Unit ipa.service entered failed state.Nov 17 15:05:14 mlv-ipa01 systemd[1]: ipa.service failed*. Do you think there is a kerberos problem? Please let me know, thanks. Bye, Morgan 2016-11-17 14:39 GMT+01:00 Florence Blanc-Renaud : > On 11/17/2016 12:09 PM, Morgan Marodin wrote: > >> Hello. >> >> This morning I've tried to upgrade my IPA server, but the upgrade >> failed, and now the service doesn't start! :( >> >> If I try lo launch the upgrade manually this is the output: >> /[root at mlv-ipa01 download]# 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 >> [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 >> 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: >> CalledProcessError: Command '/bin/systemctl start httpd.service' >> returned non-zero exit status 1 >> The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for >> more information/ >> >> These are error logs of Apache: >> /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] [pid 5664] AH01232: >> suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664] >> NSSSessionCacheTimeout is deprecated. Ignoring. >> [Thu Nov 17 11:48:45.830910 2016] [:error] [pid 5664] Certificate not >> found: 'Server-Cert'/ >> >> The problem seems to be the /Server-Cert /that could not be found. >> But if I try to execute the certutil command manually I can see it:/ >> [root at mlv-ipa01 log]# certutil -L -d /etc/httpd/alias/ >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> Signing-Cert u,u,u >> ipaCert u,u,u >> Server-Cert Pu,u,u >> IPA.MYDOMAIN.COM IPA >> CA CT,C,C/ >> >> Could you help me? >> What could I try to do to restart my service? >> >> Hi, > > I would first make sure that httpd is using /etc/httpd/alias as NSS DB > (check the directive NSSCertificateDatabase in /etc/httpd/conf.d/nss.conf). > Then it may be a file permission issue: the NSS DB should belong to > root:apache (the relevant files are cert8.db, key3.db and secmod.db). > You should also find a pwdfile.txt in the same directory, containing the > NSS DB password. Check that the password is valid using > certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt > (if the command succeeds then the password in pwdfile is OK). > > You can also enable mod-nss debug in /etc/httpd/conf/nss.conf by setting > "LogLevel debug", and check the output in /var/log/httpd/error_log. > > HTH, > Flo. > >> Thanks, Morgan >> >> >> > -- > 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 jbaird at follett.com Thu Nov 17 14:51:54 2016 From: jbaird at follett.com (Baird, Josh) Date: Thu, 17 Nov 2016 14:51:54 +0000 Subject: [Freeipa-users] IPA 4.4 replica installation failing Message-ID: Hi all, In my IPA 4.4 lab (RHEL 7.3), I'm trying to install/configure a new replica, and I seem to be hitting something similar to #5412 [1]. The 'ipa-replica-install' is getting stuck on: [4/26]: creating installation admin user Dirsrv error logs on the new replica: [17/Nov/2016:08:45:09.342813042 -0600] NSMMReplicationPlugin - agmt="cn=caToimqa-d1-dc01.qa-unix.domain.com" (imqa-d1-dc01:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. Dirsrv access logs on existing master: [17/Nov/2016:08:39:59.244698389 -0600] conn=121 op=83 RESULT err=0 tag=101 nentries=0 etime=0 [17/Nov/2016:08:40:00.248620354 -0600] conn=121 op=84 SRCH base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL [17/Nov/2016:08:40:00.248917257 -0600] conn=121 op=84 RESULT err=0 tag=101 nentries=0 etime=0 [17/Nov/2016:08:40:01.253067200 -0600] conn=121 op=85 SRCH base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL [17/Nov/2016:08:40:01.253481728 -0600] conn=121 op=85 RESULT err=0 tag=101 nentries=0 etime=0 [17/Nov/2016:08:40:02.257477560 -0600] conn=121 op=86 SRCH base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL [17/Nov/2016:08:40:02.257813691 -0600] conn=121 op=86 RESULT err=0 tag=101 nentries=0 etime=0 [17/Nov/2016:08:40:03.261805482 -0600] conn=121 op=88 SRCH base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL [17/Nov/2016:08:40:03.262310788 -0600] conn=121 op=88 RESULT err=0 tag=101 nentries=0 etime=0 Dirsrv logs on the existing master: [17/Nov/2016:08:40:20.644554573 -0600] NSMMReplicationPlugin - conn=120 op=13 replica="o=ipaca": Unable to acquire replica: error: permission denied [17/Nov/2016:08:41:57.858672215 -0600] NSMMReplicationPlugin - conn=123 op=5 replica="o=ipaca": Unable to acquire replica: error: permission denied [17/Nov/2016:08:45:09.334188374 -0600] NSMMReplicationPlugin - conn=130 op=5 replica="o=ipaca": Unable to acquire replica: error: permission denied Has anyone else experienced this issue? Thanks, Josh [1] https://fedorahosted.org/freeipa/ticket/5412 From rcritten at redhat.com Thu Nov 17 14:59:43 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Nov 2016 09:59:43 -0500 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: References: <20161116092207.sgfqdomuhhs62v4x@hendrix> <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> <20161116213755.b72r3uyybhtsy2sj@hendrix> Message-ID: <582DC5DF.3080008@redhat.com> Sean Hogan wrote: > Hi Jakub, > > I ended up re-enrolling the box and it is behaving as expected except I > am not getting a host cert. Robert indicated auto host cert no longer > avail with rhel 7 but using the --request -cert option on enroll to get > a host cert if I wanted one. I did so and get this in the install log > > > *2016-11-16T22:00:53Z DEBUG Starting external process* > *2016-11-16T22:00:53Z DEBUG args='/bin/systemctl' 'is-active' > 'certmonger.service'* > *2016-11-16T22:00:53Z DEBUG Process finished, return code=0* > *2016-11-16T22:00:53Z DEBUG stdout=active* > > *2016-11-16T22:00:53Z DEBUG stderr=* > *2016-11-16T22:00:53Z ERROR certmonger request for host certificate failed* Did you cut off the reason reported for the request failing? > Maybe this is an issue with RHEL 7(4.x) client hitting a RHEL 6 (3.x) > IPA server? You could look in the server logs for details. > As for crypto on RHEL 6 IPA I have (if this is what you looking for). > However this is modified version as it took me a while to get this list > to pass tenable scans by modding the dse files. > [root at ipa1 ~]# nmap --script ssl-enum-ciphers -p 636 `hostname` These are the TLS settings for LDAP, not the Kerberos encryption types supported. You instead want to run: $ ldapsearch -x -D 'cn=directory manager' -W -s base -b cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com krbSupportedEncSaltTypes rob From rcritten at redhat.com Thu Nov 17 15:11:01 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Nov 2016 10:11:01 -0500 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> Message-ID: <582DC885.6090205@redhat.com> Morgan Marodin wrote: > Hi Florence. > > Thanks for your support. > > Yes, httpd is using /etc/httpd/alias as NSS DB. And seems that all > permissions and certificates are good: > /[root at mlv-ipa01 ~]# ls -l /etc/httpd/alias/ > total 184 > -r--r--r-- 1 root root 1345 Sep 7 2015 cacert.asc > -rw-rw---- 1 root apache 65536 Nov 17 11:06 cert8.db > -rw-r-----. 1 root apache 65536 Sep 4 2015 cert8.db.orig > -rw-------. 1 root root 4833 Sep 4 2015 install.log > -rw-rw---- 1 root apache 16384 Nov 17 11:06 key3.db > -rw-r-----. 1 root apache 16384 Sep 4 2015 key3.db.orig > lrwxrwxrwx 1 root root 24 Nov 17 10:24 libnssckbi.so -> > /usr/lib64/libnssckbi.so > -rw-rw---- 1 root apache 20 Sep 7 2015 pwdfile.txt > -rw-rw---- 1 root apache 16384 Sep 7 2015 secmod.db > -rw-r-----. 1 root apache 16384 Sep 4 2015 secmod.db.orig/ Eventually you'll want to remove group write on the *.db files. > And password validations seems ok, too: > /[root at mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f > /etc/httpd/alias/pwdfile.txt good > Enabling mod-nss debug I can see these logs: > /[root at mlv-ipa01 ~]# tail -f /var/log/httpd/error_log > [Thu Nov 17 15:05:10.807603 2016] [suexec:notice] [pid 10660] AH01232: > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Thu Nov 17 15:05:10.807958 2016] [:warn] [pid 10660] > NSSSessionCacheTimeout is deprecated. Ignoring. > [Thu Nov 17 15:05:10.807991 2016] [:debug] [pid 10660] > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > -> Server-Cert > [Thu Nov 17 15:05:11.002664 2016] [:info] [pid 10660] Configuring server > for SSL protocol > [Thu Nov 17 15:05:11.002817 2016] [:debug] [pid 10660] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Thu Nov 17 15:05:11.002838 2016] [:debug] [pid 10660] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Thu Nov 17 15:05:11.002847 2016] [:debug] [pid 10660] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Thu Nov 17 15:05:11.002856 2016] [:debug] [pid 10660] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Thu Nov 17 15:05:11.002876 2016] [:debug] [pid 10660] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Thu Nov 17 15:05:11.003099 2016] [:debug] [pid 10660] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Thu Nov 17 15:05:11.003198 2016] [:debug] [pid 10660] > nss_engine_init.c(916): Enabling DHE key exchange > [Thu Nov 17 15:05:11.003313 2016] [:debug] [pid 10660] > nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Thu Nov 17 15:05:11.003469 2016] [:debug] [pid 10660] > [Thu Nov 17 15:05:11.006759 2016] [:info] [pid 10660] Using nickname > Server-Cert. [snip] > [Thu Nov 17 15:05:11.006771 2016] [:error] [pid 10660] Certificate not > found: 'Server-Cert' Can you shows what this returns: # grep NSSNickname /etc/httpd/conf.d/nss.conf > Do you think there is a kerberos problem? It definitely is not. You can bring the system up in a minimal way by manually starting the dirsrv at EXAMPLE.COM service and then krb5kdc. This will at least let your users authenticate. The management framework (GUI) runs through Apache so that will be down until we can get Apache started again. rob > > Please let me know, thanks. > Bye, Morgan > > 2016-11-17 14:39 GMT+01:00 Florence Blanc-Renaud >: > > On 11/17/2016 12:09 PM, Morgan Marodin wrote: > > Hello. > > This morning I've tried to upgrade my IPA server, but the upgrade > failed, and now the service doesn't start! :( > > If I try lo launch the upgrade manually this is the output: > /[root at mlv-ipa01 download]# 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 > [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 > 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: > CalledProcessError: Command '/bin/systemctl start httpd.service' > returned non-zero exit status 1 > The ipa-server-upgrade command failed. See > /var/log/ipaupgrade.log for > more information/ > > These are error logs of Apache: > /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] [pid 5664] > AH01232: > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664] > NSSSessionCacheTimeout is deprecated. Ignoring. > [Thu Nov 17 11:48:45.830910 2016] [:error] [pid 5664] > Certificate not > found: 'Server-Cert'/ > > The problem seems to be the /Server-Cert /that could not be found. > But if I try to execute the certutil command manually I can see it:/ > [root at mlv-ipa01 log]# certutil -L -d /etc/httpd/alias/ > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > Signing-Cert u,u,u > ipaCert u,u,u > Server-Cert Pu,u,u > IPA.MYDOMAIN.COM > IPA > CA CT,C,C/ > > Could you help me? > What could I try to do to restart my service? > > Hi, > > I would first make sure that httpd is using /etc/httpd/alias as NSS > DB (check the directive NSSCertificateDatabase in > /etc/httpd/conf.d/nss.conf). > Then it may be a file permission issue: the NSS DB should belong to > root:apache (the relevant files are cert8.db, key3.db and secmod.db). > You should also find a pwdfile.txt in the same directory, containing > the NSS DB password. Check that the password is valid using > certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt > (if the command succeeds then the password in pwdfile is OK). > > You can also enable mod-nss debug in /etc/httpd/conf/nss.conf by > setting "LogLevel debug", and check the output in > /var/log/httpd/error_log. > > HTH, > Flo. > > Thanks, Morgan > > > > -- > 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 Thu Nov 17 15:14:26 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Nov 2016 10:14:26 -0500 Subject: [Freeipa-users] Disabling Anonymous Binds (LDAP) In-Reply-To: <079a9de5-050f-01f2-2638-b1a7fd39dcc0@pobox.com> References: <8F863F5E-1F26-49F5-AA81-FD12FCEFF395@high5games.com> <079a9de5-050f-01f2-2638-b1a7fd39dcc0@pobox.com> Message-ID: <582DC952.4090109@redhat.com> Brian Candler wrote: > On 16/11/2016 16:46, Dan.Finkelstein at high5games.com wrote: >> I've seen some discussion in the (distant) past about disabling >> anonymous binds to the LDAP component of IPA, and I'm wondering if >> there's a preferred method to do it. Further, are there any known >> problems with disabling anonymous binds when using FreeIPA? The only >> modern documentation I can find is here: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html, >> and I'm curious if FreeIPA has a different way. > > FWIW, I see the same here. Installed ipa-server under CentOS 7 (which > gave me freeipa 4.2.0), and found anonymous binds allowed: tested by > "ldapsearch -x ..." > > I was able to disable anonymous bind (and also disable unencrypted > queries) by changing the cn=config entry: > > |dn: cn=config| > |changetype: modify| > |replace: nsslapd-allow-anonymous-access| > |nsslapd-allow-anonymous-access: rootdse| > |-| > |replace: nsslapd-minssf| > |nsslapd-minssf: 56| > > I don't think this replicated from master to slave though, and I ended > up doing it on slaves as well. > > If there is an "official" way to disable anon bind on FreeIPA 4.x, I > would like to know it. Modifying nsslapd-allow-anonymous-access is the official way. Attributes in cn=config are not replicated. rob From morgan at marodin.it Thu Nov 17 15:51:32 2016 From: morgan at marodin.it (Morgan Marodin) Date: Thu, 17 Nov 2016 16:51:32 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: <582DC885.6090205@redhat.com> References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> Message-ID: Hi Rob. I've just tried to remove the group write to the *.db files, but it's not the problem. *[root at mlv-ipa01 ~]# grep NSSNickname /etc/httpd/conf.d/nss.confNSSNickname Server-Cert* I've tried to run manually *dirsrv.target* and *krb5kdc.service*, and it works, services went up. The same for *ntpd*, *named-pkcs11.service*, *smb.service*, *winbind.service*, *kadmin.service*, *memcached.service* and *pki-tomcatd.target*. But if I try to start *httpd.service*: *[root at mlv-ipa01 ~]# tail -f /var/log/messagesNov 17 16:46:06 mlv-ipa01 systemd[1]: Starting The Apache HTTP Server...Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: ipa : INFO KDC proxy enabledNov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURENov 17 16:46:07 mlv-ipa01 kill: kill: cannot find process ""Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: control process exited, code=exited status=1Nov 17 16:46:07 mlv-ipa01 systemd[1]: Failed to start The Apache HTTP Server.Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit httpd.service entered failed state.Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service failed.* Any other ideas? Please let me know, thanks. Morgan 2016-11-17 16:11 GMT+01:00 Rob Crittenden : > Morgan Marodin wrote: > > Hi Florence. > > > > Thanks for your support. > > > > Yes, httpd is using /etc/httpd/alias as NSS DB. And seems that all > > permissions and certificates are good: > > /[root at mlv-ipa01 ~]# ls -l /etc/httpd/alias/ > > total 184 > > -r--r--r-- 1 root root 1345 Sep 7 2015 cacert.asc > > -rw-rw---- 1 root apache 65536 Nov 17 11:06 cert8.db > > -rw-r-----. 1 root apache 65536 Sep 4 2015 cert8.db.orig > > -rw-------. 1 root root 4833 Sep 4 2015 install.log > > -rw-rw---- 1 root apache 16384 Nov 17 11:06 key3.db > > -rw-r-----. 1 root apache 16384 Sep 4 2015 key3.db.orig > > lrwxrwxrwx 1 root root 24 Nov 17 10:24 libnssckbi.so -> > > /usr/lib64/libnssckbi.so > > -rw-rw---- 1 root apache 20 Sep 7 2015 pwdfile.txt > > -rw-rw---- 1 root apache 16384 Sep 7 2015 secmod.db > > -rw-r-----. 1 root apache 16384 Sep 4 2015 secmod.db.orig/ > > Eventually you'll want to remove group write on the *.db files. > > > And password validations seems ok, too: > > /[root at mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f > > /etc/httpd/alias/pwdfile.txt > good > > > Enabling mod-nss debug I can see these logs: > > /[root at mlv-ipa01 ~]# tail -f /var/log/httpd/error_log > > [Thu Nov 17 15:05:10.807603 2016] [suexec:notice] [pid 10660] AH01232: > > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > > [Thu Nov 17 15:05:10.807958 2016] [:warn] [pid 10660] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Thu Nov 17 15:05:10.807991 2016] [:debug] [pid 10660] > > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > -> Server-Cert > > [Thu Nov 17 15:05:11.002664 2016] [:info] [pid 10660] Configuring server > > for SSL protocol > > [Thu Nov 17 15:05:11.002817 2016] [:debug] [pid 10660] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Thu Nov 17 15:05:11.002838 2016] [:debug] [pid 10660] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Thu Nov 17 15:05:11.002847 2016] [:debug] [pid 10660] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Thu Nov 17 15:05:11.002856 2016] [:debug] [pid 10660] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Thu Nov 17 15:05:11.002876 2016] [:debug] [pid 10660] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Thu Nov 17 15:05:11.003099 2016] [:debug] [pid 10660] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Thu Nov 17 15:05:11.003198 2016] [:debug] [pid 10660] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Thu Nov 17 15:05:11.003313 2016] [:debug] [pid 10660] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Thu Nov 17 15:05:11.003469 2016] [:debug] [pid 10660] > > [Thu Nov 17 15:05:11.006759 2016] [:info] [pid 10660] Using nickname > > Server-Cert. > [snip] > > [Thu Nov 17 15:05:11.006771 2016] [:error] [pid 10660] Certificate not > > found: 'Server-Cert' > > Can you shows what this returns: > > # grep NSSNickname /etc/httpd/conf.d/nss.conf > > > Do you think there is a kerberos problem? > > It definitely is not. > > You can bring the system up in a minimal way by manually starting the > dirsrv at EXAMPLE.COM service and then krb5kdc. This will at least let your > users authenticate. The management framework (GUI) runs through Apache > so that will be down until we can get Apache started again. > > rob > > > > > Please let me know, thanks. > > Bye, Morgan > > > > 2016-11-17 14:39 GMT+01:00 Florence Blanc-Renaud > >: > > > > On 11/17/2016 12:09 PM, Morgan Marodin wrote: > > > > Hello. > > > > This morning I've tried to upgrade my IPA server, but the upgrade > > failed, and now the service doesn't start! :( > > > > If I try lo launch the upgrade manually this is the output: > > /[root at mlv-ipa01 download]# 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 > > [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 > > 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: > > CalledProcessError: Command '/bin/systemctl start httpd.service' > > returned non-zero exit status 1 > > The ipa-server-upgrade command failed. See > > /var/log/ipaupgrade.log for > > more information/ > > > > These are error logs of Apache: > > /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] [pid 5664] > > AH01232: > > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > > [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Thu Nov 17 11:48:45.830910 2016] [:error] [pid 5664] > > Certificate not > > found: 'Server-Cert'/ > > > > The problem seems to be the /Server-Cert /that could not be > found. > > But if I try to execute the certutil command manually I can see > it:/ > > [root at mlv-ipa01 log]# certutil -L -d /etc/httpd/alias/ > > Certificate Nickname > Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > Signing-Cert > u,u,u > > ipaCert > u,u,u > > Server-Cert > Pu,u,u > > IPA.MYDOMAIN.COM > > IPA > > CA CT,C,C/ > > > > Could you help me? > > What could I try to do to restart my service? > > > > Hi, > > > > I would first make sure that httpd is using /etc/httpd/alias as NSS > > DB (check the directive NSSCertificateDatabase in > > /etc/httpd/conf.d/nss.conf). > > Then it may be a file permission issue: the NSS DB should belong to > > root:apache (the relevant files are cert8.db, key3.db and secmod.db). > > You should also find a pwdfile.txt in the same directory, containing > > the NSS DB password. Check that the password is valid using > > certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt > > (if the command succeeds then the password in pwdfile is OK). > > > > You can also enable mod-nss debug in /etc/httpd/conf/nss.conf by > > setting "LogLevel debug", and check the output in > > /var/log/httpd/error_log. > > > > HTH, > > Flo. > > > > Thanks, Morgan > > > > > > > > -- > > 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 schogan at us.ibm.com Thu Nov 17 16:04:50 2016 From: schogan at us.ibm.com (Sean Hogan) Date: Thu, 17 Nov 2016 09:04:50 -0700 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: <582DC5DF.3080008@redhat.com> References: <20161116092207.sgfqdomuhhs62v4x@hendrix> <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> <20161116213755.b72r3uyybhtsy2sj@hendrix> <582DC5DF.3080008@redhat.com> Message-ID: Hi Robert, No I did not cut it off ....there was no reason listed.. that was the last line about the issue. I did find this to be my issue however https://bugzilla.redhat.com/show_bug.cgi?id=1262718 ... having our sat guys see if they can pull the new selinux policy packages as I do not see them avail right now for my boxes. [root at server2 log]# ausearch -m avc -m user_avc -m selinux_err -i -ts recent ---- type=USER_AVC msg=audit(11/17/2016 10:35:04.074:2502) : pid=1 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='avc: received setenforce notice (enforcing=0) exe=/usr/lib/systemd/systemd sauid=root hostname=? addr=? terminal=?' ---- type=PATH msg=audit(11/17/2016 10:37:21.803:2543) : item=0 name=/etc/ipa/nssdb inode=16807676 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=NORMAL type=SYSCALL msg=audit(11/17/2016 10:37:21.803:2543) : arch=x86_64 syscall=access success=yes exit=0 a0=0x7fbc870da950 a1=W_OK|R_OK a2=0x4000 a3=0xfffffffffffff8e8 items=1 ppid=1 pid=2875 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=certmonger exe=/usr/sbin/certmonger subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(11/17/2016 10:37:21.803:2543) : avc: denied { write } for pid=2875 comm=certmonger name=nssdb dev="dm-0" ino=16807676 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir ---- type=PATH msg=audit(11/17/2016 10:37:21.866:2544) : item=0 name=/etc/ipa/nssdb/cert8.db inode=16807680 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:etc_t:s0 objtype=NORMAL type=SYSCALL msg=audit(11/17/2016 10:37:21.866:2544) : arch=x86_64 syscall=open success=yes exit=11 a0=0x7fbc8712a080 a1=O_RDWR a2=0x180 a3=0x0 items=1 ppid=2875 pid=2918 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=certmonger exe=/usr/sbin/certmonger subj=system_u:system_r:certmonger_t:s0 key=(null) type=AVC msg=audit(11/17/2016 10:37:21.866:2544) : avc: denied { write } for pid=2918 comm=certmonger name=cert8.db dev="dm-0" ino=16807680 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file [root at server2 log]# rpm -qf /etc/ipa/nssdb ipa-python-4.1.0-18.el7_1.4.x86_64 Encryption types.. thanks for the command.. good to know but hate seeing the arcfour and des options as I know DISA will not like that. [root at ipa1 ~]# ldapsearch -x -D 'cn=directory manager' -W -s base -b cn=IPA.LOCAL,cn=kerberos,dc=ipa,dc=local krbSupportedEncSaltTypes Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: krbSupportedEncSaltTypes # # IPA.LOCAL, kerberos, ipa.local dn: cn=IPA.LOCAL,cn=kerberos,dc=ipa,dc=local krbSupportedEncSaltTypes: aes256-cts:normal krbSupportedEncSaltTypes: aes256-cts:special krbSupportedEncSaltTypes: aes128-cts:normal krbSupportedEncSaltTypes: aes128-cts:special krbSupportedEncSaltTypes: des3-hmac-sha1:normal krbSupportedEncSaltTypes: des3-hmac-sha1:special krbSupportedEncSaltTypes: arcfour-hmac:normal krbSupportedEncSaltTypes: arcfour-hmac:special # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Sean Hogan From: Rob Crittenden To: Sean Hogan/Durham/IBM at IBMUS, Jakub Hrozek Cc: freeipa-users at redhat.com, Martin Babinsky Date: 11/17/2016 07:59 AM Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server Sean Hogan wrote: > Hi Jakub, > > I ended up re-enrolling the box and it is behaving as expected except I > am not getting a host cert. Robert indicated auto host cert no longer > avail with rhel 7 but using the --request -cert option on enroll to get > a host cert if I wanted one. I did so and get this in the install log > > > *2016-11-16T22:00:53Z DEBUG Starting external process* > *2016-11-16T22:00:53Z DEBUG args='/bin/systemctl' 'is-active' > 'certmonger.service'* > *2016-11-16T22:00:53Z DEBUG Process finished, return code=0* > *2016-11-16T22:00:53Z DEBUG stdout=active* > > *2016-11-16T22:00:53Z DEBUG stderr=* > *2016-11-16T22:00:53Z ERROR certmonger request for host certificate failed* Did you cut off the reason reported for the request failing? > Maybe this is an issue with RHEL 7(4.x) client hitting a RHEL 6 (3.x) > IPA server? You could look in the server logs for details. > As for crypto on RHEL 6 IPA I have (if this is what you looking for). > However this is modified version as it took me a while to get this list > to pass tenable scans by modding the dse files. > [root at ipa1 ~]# nmap --script ssl-enum-ciphers -p 636 `hostname` These are the TLS settings for LDAP, not the Kerberos encryption types supported. You instead want to run: $ ldapsearch -x -D 'cn=directory manager' -W -s base -b cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com krbSupportedEncSaltTypes rob -------------- 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: From rcritten at redhat.com Thu Nov 17 16:07:31 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Nov 2016 11:07:31 -0500 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> Message-ID: <582DD5C3.1070809@redhat.com> Morgan Marodin wrote: > Hi Rob. > > I've just tried to remove the group write to the *.db files, but it's > not the problem. I didn't expect it to be but you don't want Apache having write access to your certs and keys. > /[root at mlv-ipa01 ~]# grep NSSNickname /etc/httpd/conf.d/nss.conf > NSSNickname Server-Cert/ Ok. > > I've tried to run manually /dirsrv.target/ and /krb5kdc.service/, and it > works, services went up. > The same for /ntpd/, /named-pkcs11.service/, /smb.service/, > /winbind.service/, /kadmin.service/, /memcached.service/ and > /pki-tomcatd.target/. Good, so you can limp along for a while then. > Any other ideas? So you upgraded. What did you actually upgrade? Only the IPA packages or a lot more? What version is running now, and what version of mod_nss? $ rpm -q mod_nss Let's see if the NSS tools can find the cert: # certutil -V -u V -d /etc/httpd/alias -n Server-Cert Should come back with: certutil: certificate is valid rob From flo at redhat.com Thu Nov 17 16:09:42 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 17 Nov 2016 17:09:42 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> Message-ID: On 11/17/2016 04:51 PM, Morgan Marodin wrote: > Hi Rob. > > I've just tried to remove the group write to the *.db files, but it's > not the problem. > /[root at mlv-ipa01 ~]# grep NSSNickname /etc/httpd/conf.d/nss.conf > NSSNickname Server-Cert/ > > I've tried to run manually /dirsrv.target/ and /krb5kdc.service/, and it > works, services went up. > The same for /ntpd/, /named-pkcs11.service/, /smb.service/, > /winbind.service/, /kadmin.service/, /memcached.service/ and > /pki-tomcatd.target/. > > But if I try to start /httpd.service/: > /[root at mlv-ipa01 ~]# tail -f /var/log/messages > Nov 17 16:46:06 mlv-ipa01 systemd[1]: Starting The Apache HTTP Server... > Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: ipa : INFO KDC > proxy enabled > Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: main process > exited, code=exited, status=1/FAILURE > Nov 17 16:46:07 mlv-ipa01 kill: kill: cannot find process "" > Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: control process > exited, code=exited status=1 > Nov 17 16:46:07 mlv-ipa01 systemd[1]: Failed to start The Apache HTTP > Server. > Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit httpd.service entered failed > state. > Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service failed./ > > Any other ideas? Hi, - Does the NSS Db contain the private key for Server-Cert? If yes, the command $ certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt should display a line like this one: < 0> rsa 01a6cbd773f3d785ffa44233148dcb8ade266ea5 NSS Certificate DB:Server-Cert - Is your system running with SElinux enforcing? If yes, you can check if there were SElinux permission denials using $ ausearch -m avc --start recent - If the certificate was expired, I believe you would see a different message, but it doesn't hurt to check its validity $ certutil -L -d /etc/httpd/alias/ -n Server-Cert | egrep "Not Before|Not After" Flo. > > Please let me know, thanks. > Morgan > > 2016-11-17 16:11 GMT+01:00 Rob Crittenden >: > > Morgan Marodin wrote: > > Hi Florence. > > > > Thanks for your support. > > > > Yes, httpd is using /etc/httpd/alias as NSS DB. And seems that all > > permissions and certificates are good: > > /[root at mlv-ipa01 ~]# ls -l /etc/httpd/alias/ > > total 184 > > -r--r--r-- 1 root root 1345 Sep 7 2015 cacert.asc > > -rw-rw---- 1 root apache 65536 Nov 17 11:06 cert8.db > > -rw-r-----. 1 root apache 65536 Sep 4 2015 cert8.db.orig > > -rw-------. 1 root root 4833 Sep 4 2015 install.log > > -rw-rw---- 1 root apache 16384 Nov 17 11:06 key3.db > > -rw-r-----. 1 root apache 16384 Sep 4 2015 key3.db.orig > > lrwxrwxrwx 1 root root 24 Nov 17 10:24 libnssckbi.so -> > > /usr/lib64/libnssckbi.so > > -rw-rw---- 1 root apache 20 Sep 7 2015 pwdfile.txt > > -rw-rw---- 1 root apache 16384 Sep 7 2015 secmod.db > > -rw-r-----. 1 root apache 16384 Sep 4 2015 secmod.db.orig/ > > Eventually you'll want to remove group write on the *.db files. > > > And password validations seems ok, too: > > /[root at mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f > > /etc/httpd/alias/pwdfile.txt > good > > > Enabling mod-nss debug I can see these logs: > > /[root at mlv-ipa01 ~]# tail -f /var/log/httpd/error_log > > [Thu Nov 17 15:05:10.807603 2016] [suexec:notice] [pid 10660] AH01232: > > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > > [Thu Nov 17 15:05:10.807958 2016] [:warn] [pid 10660] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Thu Nov 17 15:05:10.807991 2016] [:debug] [pid 10660] > > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > > -> Server-Cert > > [Thu Nov 17 15:05:11.002664 2016] [:info] [pid 10660] Configuring server > > for SSL protocol > > [Thu Nov 17 15:05:11.002817 2016] [:debug] [pid 10660] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Thu Nov 17 15:05:11.002838 2016] [:debug] [pid 10660] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Thu Nov 17 15:05:11.002847 2016] [:debug] [pid 10660] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Thu Nov 17 15:05:11.002856 2016] [:debug] [pid 10660] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Thu Nov 17 15:05:11.002876 2016] [:debug] [pid 10660] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Thu Nov 17 15:05:11.003099 2016] [:debug] [pid 10660] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Thu Nov 17 15:05:11.003198 2016] [:debug] [pid 10660] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Thu Nov 17 15:05:11.003313 2016] [:debug] [pid 10660] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Thu Nov 17 15:05:11.003469 2016] [:debug] [pid 10660] > > [Thu Nov 17 15:05:11.006759 2016] [:info] [pid 10660] Using nickname > > Server-Cert. > [snip] > > [Thu Nov 17 15:05:11.006771 2016] [:error] [pid 10660] Certificate not > > found: 'Server-Cert' > > Can you shows what this returns: > > # grep NSSNickname /etc/httpd/conf.d/nss.conf > > > Do you think there is a kerberos problem? > > It definitely is not. > > You can bring the system up in a minimal way by manually starting the > dirsrv at EXAMPLE.COM service and then > krb5kdc. This will at least let your > users authenticate. The management framework (GUI) runs through Apache > so that will be down until we can get Apache started again. > > rob > > > > > Please let me know, thanks. > > Bye, Morgan > > > > 2016-11-17 14:39 GMT+01:00 Florence Blanc-Renaud > > >>: > > > > On 11/17/2016 12:09 PM, Morgan Marodin wrote: > > > > Hello. > > > > This morning I've tried to upgrade my IPA server, but the > upgrade > > failed, and now the service doesn't start! :( > > > > If I try lo launch the upgrade manually this is the output: > > /[root at mlv-ipa01 download]# 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 > > [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 > > 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: > > CalledProcessError: Command '/bin/systemctl start > httpd.service' > > returned non-zero exit status 1 > > The ipa-server-upgrade command failed. See > > /var/log/ipaupgrade.log for > > more information/ > > > > These are error logs of Apache: > > /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] [pid 5664] > > AH01232: > > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > > [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Thu Nov 17 11:48:45.830910 2016] [:error] [pid 5664] > > Certificate not > > found: 'Server-Cert'/ > > > > The problem seems to be the /Server-Cert /that could not > be found. > > But if I try to execute the certutil command manually I > can see it:/ > > [root at mlv-ipa01 log]# certutil -L -d /etc/httpd/alias/ > > Certificate Nickname > Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > Signing-Cert > u,u,u > > ipaCert > u,u,u > > Server-Cert > Pu,u,u > > IPA.MYDOMAIN.COM > > > IPA > > CA CT,C,C/ > > > > Could you help me? > > What could I try to do to restart my service? > > > > Hi, > > > > I would first make sure that httpd is using /etc/httpd/alias > as NSS > > DB (check the directive NSSCertificateDatabase in > > /etc/httpd/conf.d/nss.conf). > > Then it may be a file permission issue: the NSS DB should > belong to > > root:apache (the relevant files are cert8.db, key3.db and > secmod.db). > > You should also find a pwdfile.txt in the same directory, > containing > > the NSS DB password. Check that the password is valid using > > certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt > > (if the command succeeds then the password in pwdfile is OK). > > > > You can also enable mod-nss debug in /etc/httpd/conf/nss.conf by > > setting "LogLevel debug", and check the output in > > /var/log/httpd/error_log. > > > > HTH, > > Flo. > > > > Thanks, Morgan > > > > > > > > -- > > 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 Thu Nov 17 16:13:57 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Nov 2016 11:13:57 -0500 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: References: <20161116092207.sgfqdomuhhs62v4x@hendrix> <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> <20161116213755.b72r3uyybhtsy2sj@hendrix> <582DC5DF.3080008@redhat.com> Message-ID: <582DD745.1090409@redhat.com> Sean Hogan wrote: > Hi Robert, > > No I did not cut it off ....there was no reason listed.. that was the > last line about the issue. > > I did find this to be my issue however > https://bugzilla.redhat.com/show_bug.cgi?id=1262718 ... having our sat > guys see if they can pull the new selinux policy packages as I do not > see them avail right now for my boxes. > > [root at server2 log]# ausearch -m avc -m user_avc -m selinux_err -i -ts recent > ---- > type=USER_AVC msg=audit(11/17/2016 10:35:04.074:2502) : pid=1 uid=root > auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='avc: received > setenforce notice (enforcing=0) exe=/usr/lib/systemd/systemd sauid=root > hostname=? addr=? terminal=?' > ---- > type=PATH msg=audit(11/17/2016 10:37:21.803:2543) : item=0 > name=/etc/ipa/nssdb inode=16807676 dev=fd:00 mode=dir,755 ouid=root > ogid=root rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=NORMAL > type=SYSCALL msg=audit(11/17/2016 10:37:21.803:2543) : arch=x86_64 > syscall=access success=yes exit=0 a0=0x7fbc870da950 a1=W_OK|R_OK > a2=0x4000 a3=0xfffffffffffff8e8 items=1 ppid=1 pid=2875 auid=unset > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > fsgid=root tty=(none) ses=unset comm=certmonger exe=/usr/sbin/certmonger > subj=system_u:system_r:certmonger_t:s0 key=(null) > type=AVC msg=audit(11/17/2016 10:37:21.803:2543) : avc: denied { write } > for pid=2875 comm=certmonger name=nssdb dev="dm-0" ino=16807676 > scontext=system_u:system_r:certmonger_t:s0 > tcontext=system_u:object_r:etc_t:s0 tclass=dir > ---- > type=PATH msg=audit(11/17/2016 10:37:21.866:2544) : item=0 > name=/etc/ipa/nssdb/cert8.db inode=16807680 dev=fd:00 mode=file,644 > ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:etc_t:s0 > objtype=NORMAL > type=SYSCALL msg=audit(11/17/2016 10:37:21.866:2544) : arch=x86_64 > syscall=open success=yes exit=11 a0=0x7fbc8712a080 a1=O_RDWR a2=0x180 > a3=0x0 items=1 ppid=2875 pid=2918 auid=unset uid=root gid=root euid=root > suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset > comm=certmonger exe=/usr/sbin/certmonger > subj=system_u:system_r:certmonger_t:s0 key=(null) > type=AVC msg=audit(11/17/2016 10:37:21.866:2544) : avc: denied { write } > for pid=2918 comm=certmonger name=cert8.db dev="dm-0" ino=16807680 > scontext=system_u:system_r:certmonger_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file Good catch, that seems like the issue. > [root at server2 log]# rpm -qf /etc/ipa/nssdb > ipa-python-4.1.0-18.el7_1.4.x86_64 IIRC it is just ghosted, all files should be owned by something. > Encryption types.. thanks for the command.. good to know but hate seeing > the arcfour and des options as I know DISA will not like that. No DES, Triple DES. You can always remove them if you want, just be aware of interoperability. rob > > [root at ipa1 ~]# ldapsearch -x -D 'cn=directory manager' -W -s base -b > cn=IPA.LOCAL,cn=kerberos,dc=ipa,dc=local krbSupportedEncSaltTypes > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope baseObject > # filter: (objectclass=*) > # requesting: krbSupportedEncSaltTypes > # > > # IPA.LOCAL, kerberos, ipa.local > dn: cn=IPA.LOCAL,cn=kerberos,dc=ipa,dc=local > krbSupportedEncSaltTypes: aes256-cts:normal > krbSupportedEncSaltTypes: aes256-cts:special > krbSupportedEncSaltTypes: aes128-cts:normal > krbSupportedEncSaltTypes: aes128-cts:special > krbSupportedEncSaltTypes: des3-hmac-sha1:normal > krbSupportedEncSaltTypes: des3-hmac-sha1:special > krbSupportedEncSaltTypes: arcfour-hmac:normal > krbSupportedEncSaltTypes: arcfour-hmac:special > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > > > Sean Hogan > > > > Inactive hide details for Rob Crittenden ---11/17/2016 07:59:55 > AM---Sean Hogan wrote: > Hi Jakub,Rob Crittenden ---11/17/2016 07:59:55 > AM---Sean Hogan wrote: > Hi Jakub, > > From: Rob Crittenden > To: Sean Hogan/Durham/IBM at IBMUS, Jakub Hrozek > Cc: freeipa-users at redhat.com, Martin Babinsky > Date: 11/17/2016 07:59 AM > Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server > > ------------------------------------------------------------------------ > > > > Sean Hogan wrote: >> Hi Jakub, >> >> I ended up re-enrolling the box and it is behaving as expected except I >> am not getting a host cert. Robert indicated auto host cert no longer >> avail with rhel 7 but using the --request -cert option on enroll to get >> a host cert if I wanted one. I did so and get this in the install log >> >> >> *2016-11-16T22:00:53Z DEBUG Starting external process* >> *2016-11-16T22:00:53Z DEBUG args='/bin/systemctl' 'is-active' >> 'certmonger.service'* >> *2016-11-16T22:00:53Z DEBUG Process finished, return code=0* >> *2016-11-16T22:00:53Z DEBUG stdout=active* >> >> *2016-11-16T22:00:53Z DEBUG stderr=* >> *2016-11-16T22:00:53Z ERROR certmonger request for host certificate > failed* > > Did you cut off the reason reported for the request failing? > >> Maybe this is an issue with RHEL 7(4.x) client hitting a RHEL 6 (3.x) >> IPA server? > > You could look in the server logs for details. > >> As for crypto on RHEL 6 IPA I have (if this is what you looking for). >> However this is modified version as it took me a while to get this list >> to pass tenable scans by modding the dse files. >> [root at ipa1 ~]# nmap --script ssl-enum-ciphers -p 636 `hostname` > > These are the TLS settings for LDAP, not the Kerberos encryption types > supported. You instead want to run: > > $ ldapsearch -x -D 'cn=directory manager' -W -s base -b > cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com krbSupportedEncSaltTypes > > rob > > > > From morgan at marodin.it Thu Nov 17 16:36:05 2016 From: morgan at marodin.it (Morgan Marodin) Date: Thu, 17 Nov 2016 17:36:05 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: <582DD5C3.1070809@redhat.com> References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> <582DD5C3.1070809@redhat.com> Message-ID: Hi. I've upgraded all packages of my distribution, not only ipa packages. There were a lot of packages. *[root at mlv-ipa01 ~]# rpm -q mod_nssmod_nss-1.0.14-7.el7.x86_64* All other checks seem ok: *[root at mlv-ipa01 ~]# certutil -V -u V -d /etc/httpd/alias -n Server-Certcertutil: certificate is valid[root at mlv-ipa01 ~]# getseboolgetsebool: SELinux is disabled[root at mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txtcertutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"< 0> rsa 736... NSS Certificate DB:Server-Cert< 1> rsa a4b... NSS Certificate DB:Signing-Cert< 2> rsa 0ff... NSS Certificate DB:ipaCert* *[root at mlv-ipa01 ~]# certutil -L -d /etc/httpd/alias/ -n Server-Cert | egrep "Not Before|Not After" Not Before: Mon Sep 07 10:15:34 2015 Not After : Thu Sep 07 10:15:34 2017* Could it be a good idea to export and re-import all certs from */etc/httpd/alias* folder? Thanks 2016-11-17 17:07 GMT+01:00 Rob Crittenden : > Morgan Marodin wrote: > > Hi Rob. > > > > I've just tried to remove the group write to the *.db files, but it's > > not the problem. > > I didn't expect it to be but you don't want Apache having write access > to your certs and keys. > > > /[root at mlv-ipa01 ~]# grep NSSNickname /etc/httpd/conf.d/nss.conf > > NSSNickname Server-Cert/ > > Ok. > > > > > I've tried to run manually /dirsrv.target/ and /krb5kdc.service/, and it > > works, services went up. > > The same for /ntpd/, /named-pkcs11.service/, /smb.service/, > > /winbind.service/, /kadmin.service/, /memcached.service/ and > > /pki-tomcatd.target/. > > Good, so you can limp along for a while then. > > > Any other ideas? > > So you upgraded. What did you actually upgrade? Only the IPA packages or > a lot more? > > What version is running now, and what version of mod_nss? > > $ rpm -q mod_nss > > Let's see if the NSS tools can find the cert: > > # certutil -V -u V -d /etc/httpd/alias -n Server-Cert > > Should come back with: certutil: certificate is valid > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morgan at marodin.it Thu Nov 17 17:18:14 2016 From: morgan at marodin.it (Morgan Marodin) Date: Thu, 17 Nov 2016 18:18:14 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> <582DD5C3.1070809@redhat.com> Message-ID: Hi. I've tried to delete and reimport only the *Server-Cert* certificate (I've a copy of the original folder). But it happened a strange behaviour: *# certutil -L -d /etc/httpd/alias -n Server-Cert -a > /tmp/Server-Cert.crt# certutil -D -d /etc/httpd/alias -n Server-Cert# certutil -L -d .Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPISigning-Cert u,u,uipaCert u,u,uIPA.PEDONGROUP.COM IPA CA CT,C,C# certutil -A -d /etc/httpd/alias -n Server-Cert -t u,u,u -a -i /tmp/Server-Cert.crtNotice: Trust flag u is set automatically if the private key is present.p11-kit: objects of this type cannot be created# certutil -L -d /etc/httpd/aliasCertificate Nickname Trust Attributes SSL,S/MIME,JAR/XPISigning-Cert u,u,uipaCert u,u,uIPA.PEDONGROUP.COM IPA CA CT,C,CServer-Cert Pu,u,u* What's the error message in bold? And why trust flags are set different from ones specified? Thanks, Morgan 2016-11-17 17:36 GMT+01:00 Morgan Marodin : > Hi. > > I've upgraded all packages of my distribution, not only ipa packages. > There were a lot of packages. > > *[root at mlv-ipa01 ~]# rpm -q mod_nssmod_nss-1.0.14-7.el7.x86_64* > > All other checks seem ok: > > > > > > > > > > > > *[root at mlv-ipa01 ~]# certutil -V -u V -d /etc/httpd/alias -n > Server-Certcertutil: certificate is valid[root at mlv-ipa01 ~]# > getseboolgetsebool: SELinux is disabled[root at mlv-ipa01 ~]# certutil -K -d > /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txtcertutil: Checking token > "NSS Certificate DB" in slot "NSS User Private Key and Certificate > Services"< 0> rsa 736... NSS Certificate DB:Server-Cert< 1> rsa > a4b... NSS Certificate DB:Signing-Cert< 2> rsa 0ff... NSS > Certificate DB:ipaCert* > > > *[root at mlv-ipa01 ~]# certutil -L -d /etc/httpd/alias/ -n Server-Cert | > egrep "Not Before|Not After" Not Before: Mon Sep 07 10:15:34 > 2015 Not After : Thu Sep 07 10:15:34 2017* > > Could it be a good idea to export and re-import all certs from > */etc/httpd/alias* folder? > > Thanks > > 2016-11-17 17:07 GMT+01:00 Rob Crittenden : > >> Morgan Marodin wrote: >> > Hi Rob. >> > >> > I've just tried to remove the group write to the *.db files, but it's >> > not the problem. >> >> I didn't expect it to be but you don't want Apache having write access >> to your certs and keys. >> >> > /[root at mlv-ipa01 ~]# grep NSSNickname /etc/httpd/conf.d/nss.conf >> > NSSNickname Server-Cert/ >> >> Ok. >> >> > >> > I've tried to run manually /dirsrv.target/ and /krb5kdc.service/, and it >> > works, services went up. >> > The same for /ntpd/, /named-pkcs11.service/, /smb.service/, >> > /winbind.service/, /kadmin.service/, /memcached.service/ and >> > /pki-tomcatd.target/. >> >> Good, so you can limp along for a while then. >> >> > Any other ideas? >> >> So you upgraded. What did you actually upgrade? Only the IPA packages or >> a lot more? >> >> What version is running now, and what version of mod_nss? >> >> $ rpm -q mod_nss >> >> Let's see if the NSS tools can find the cert: >> >> # certutil -V -u V -d /etc/httpd/alias -n Server-Cert >> >> Should come back with: certutil: certificate is valid >> >> rob >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schogan at us.ibm.com Thu Nov 17 20:19:44 2016 From: schogan at us.ibm.com (Sean Hogan) Date: Thu, 17 Nov 2016 13:19:44 -0700 Subject: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server In-Reply-To: <582DD745.1090409@redhat.com> References: <20161116092207.sgfqdomuhhs62v4x@hendrix> <14184e02-477b-8435-2c93-3594a4d14a89@redhat.com> <20161116213755.b72r3uyybhtsy2sj@hendrix> <582DC5DF.3080008@redhat.com> <582DD745.1090409@redhat.com> Message-ID: Hi Guys.. Sorry to bug ya again.. so looks like the selinux packages are not back ported to 7.1 as I only have selinux-policy-3.13.1-23.el7_1.21.noarch as an option Setting the contexts manually to /etc/ipa/nssdb Original [root at server2 ipa]# ls -dZ nssdb drwxr-xr-x. root root system_u:object_r:etc_t:s0 nssdb Set to [root at server2 ipa]# semanage fcontext -a -t cert_t "/etc/ipa/nssdb(/.*)?" [root at server2 ~]# restorecon -FvvR /etc/ipa/nssdb/ Check for change [root at server2 ~]# ls -dZ /etc/ipa/nssdb drwxr-xr-x. root root system_u:object_r:cert_t:s0 /etc/ipa/nssdb I did this.. re-enrolled the box again but still no host cert showing in IPA however I do get a result now from getcert list as seen below. The install log still shows certmonger failed .. 2016-11-17T20:05:05Z ERROR certmonger request for host certificate failed. getcert list Number of certificates and requests being tracked: 1. Request ID '20161117153721': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/ipa/nssdb',nickname='Local IPA host',token='NSS Certificate DB',pinfile='/etc/ipa/nssdb/pwdfile.txt' certificate: type=NSSDB,location='/etc/ipa/nssdb',nickname='Local IPA host' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes Not seeing anymore selinux issues either [root at server2 sudofix]# ausearch -m avc -m user_avc -m selinux_err -i -ts recent Sean Hogan Security Engineer Watson Security & Risk Assurance Watson Cloud Technology and Support email: schogan at us.ibm.com | Tel 919 486 1397 From: Rob Crittenden To: Sean Hogan/Durham/IBM at IBMUS Cc: freeipa-users at redhat.com, Jakub Hrozek , Martin Babinsky Date: 11/17/2016 09:14 AM Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server Sean Hogan wrote: > Hi Robert, > > No I did not cut it off ....there was no reason listed.. that was the > last line about the issue. > > I did find this to be my issue however > https://bugzilla.redhat.com/show_bug.cgi?id=1262718 ... having our sat > guys see if they can pull the new selinux policy packages as I do not > see them avail right now for my boxes. > > [root at server2 log]# ausearch -m avc -m user_avc -m selinux_err -i -ts recent > ---- > type=USER_AVC msg=audit(11/17/2016 10:35:04.074:2502) : pid=1 uid=root > auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='avc: received > setenforce notice (enforcing=0) exe=/usr/lib/systemd/systemd sauid=root > hostname=? addr=? terminal=?' > ---- > type=PATH msg=audit(11/17/2016 10:37:21.803:2543) : item=0 > name=/etc/ipa/nssdb inode=16807676 dev=fd:00 mode=dir,755 ouid=root > ogid=root rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=NORMAL > type=SYSCALL msg=audit(11/17/2016 10:37:21.803:2543) : arch=x86_64 > syscall=access success=yes exit=0 a0=0x7fbc870da950 a1=W_OK|R_OK > a2=0x4000 a3=0xfffffffffffff8e8 items=1 ppid=1 pid=2875 auid=unset > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > fsgid=root tty=(none) ses=unset comm=certmonger exe=/usr/sbin/certmonger > subj=system_u:system_r:certmonger_t:s0 key=(null) > type=AVC msg=audit(11/17/2016 10:37:21.803:2543) : avc: denied { write } > for pid=2875 comm=certmonger name=nssdb dev="dm-0" ino=16807676 > scontext=system_u:system_r:certmonger_t:s0 > tcontext=system_u:object_r:etc_t:s0 tclass=dir > ---- > type=PATH msg=audit(11/17/2016 10:37:21.866:2544) : item=0 > name=/etc/ipa/nssdb/cert8.db inode=16807680 dev=fd:00 mode=file,644 > ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:etc_t:s0 > objtype=NORMAL > type=SYSCALL msg=audit(11/17/2016 10:37:21.866:2544) : arch=x86_64 > syscall=open success=yes exit=11 a0=0x7fbc8712a080 a1=O_RDWR a2=0x180 > a3=0x0 items=1 ppid=2875 pid=2918 auid=unset uid=root gid=root euid=root > suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset > comm=certmonger exe=/usr/sbin/certmonger > subj=system_u:system_r:certmonger_t:s0 key=(null) > type=AVC msg=audit(11/17/2016 10:37:21.866:2544) : avc: denied { write } > for pid=2918 comm=certmonger name=cert8.db dev="dm-0" ino=16807680 > scontext=system_u:system_r:certmonger_t:s0 > tcontext=unconfined_u:object_r:etc_t:s0 tclass=file Good catch, that seems like the issue. > [root at server2 log]# rpm -qf /etc/ipa/nssdb > ipa-python-4.1.0-18.el7_1.4.x86_64 IIRC it is just ghosted, all files should be owned by something. > Encryption types.. thanks for the command.. good to know but hate seeing > the arcfour and des options as I know DISA will not like that. No DES, Triple DES. You can always remove them if you want, just be aware of interoperability. rob > > [root at ipa1 ~]# ldapsearch -x -D 'cn=directory manager' -W -s base -b > cn=IPA.LOCAL,cn=kerberos,dc=ipa,dc=local krbSupportedEncSaltTypes > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope baseObject > # filter: (objectclass=*) > # requesting: krbSupportedEncSaltTypes > # > > # IPA.LOCAL, kerberos, ipa.local > dn: cn=IPA.LOCAL,cn=kerberos,dc=ipa,dc=local > krbSupportedEncSaltTypes: aes256-cts:normal > krbSupportedEncSaltTypes: aes256-cts:special > krbSupportedEncSaltTypes: aes128-cts:normal > krbSupportedEncSaltTypes: aes128-cts:special > krbSupportedEncSaltTypes: des3-hmac-sha1:normal > krbSupportedEncSaltTypes: des3-hmac-sha1:special > krbSupportedEncSaltTypes: arcfour-hmac:normal > krbSupportedEncSaltTypes: arcfour-hmac:special > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > > > Sean Hogan > > > > Inactive hide details for Rob Crittenden ---11/17/2016 07:59:55 > AM---Sean Hogan wrote: > Hi Jakub,Rob Crittenden ---11/17/2016 07:59:55 > AM---Sean Hogan wrote: > Hi Jakub, > > From: Rob Crittenden > To: Sean Hogan/Durham/IBM at IBMUS, Jakub Hrozek > Cc: freeipa-users at redhat.com, Martin Babinsky > Date: 11/17/2016 07:59 AM > Subject: Re: [Freeipa-users] Rhel 7 client enroll to Rhel 6 IPA server > > ------------------------------------------------------------------------ > > > > Sean Hogan wrote: >> Hi Jakub, >> >> I ended up re-enrolling the box and it is behaving as expected except I >> am not getting a host cert. Robert indicated auto host cert no longer >> avail with rhel 7 but using the --request -cert option on enroll to get >> a host cert if I wanted one. I did so and get this in the install log >> >> >> *2016-11-16T22:00:53Z DEBUG Starting external process* >> *2016-11-16T22:00:53Z DEBUG args='/bin/systemctl' 'is-active' >> 'certmonger.service'* >> *2016-11-16T22:00:53Z DEBUG Process finished, return code=0* >> *2016-11-16T22:00:53Z DEBUG stdout=active* >> >> *2016-11-16T22:00:53Z DEBUG stderr=* >> *2016-11-16T22:00:53Z ERROR certmonger request for host certificate > failed* > > Did you cut off the reason reported for the request failing? > >> Maybe this is an issue with RHEL 7(4.x) client hitting a RHEL 6 (3.x) >> IPA server? > > You could look in the server logs for details. > >> As for crypto on RHEL 6 IPA I have (if this is what you looking for). >> However this is modified version as it took me a while to get this list >> to pass tenable scans by modding the dse files. >> [root at ipa1 ~]# nmap --script ssl-enum-ciphers -p 636 `hostname` > > These are the TLS settings for LDAP, not the Kerberos encryption types > supported. You instead want to run: > > $ ldapsearch -x -D 'cn=directory manager' -W -s base -b > cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com krbSupportedEncSaltTypes > > rob > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 09331459.jpg Type: image/jpeg Size: 27085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 09393284.gif Type: image/gif Size: 1650 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From william.muriithi at gmail.com Thu Nov 17 20:53:09 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 17 Nov 2016 15:53:09 -0500 Subject: [Freeipa-users] Would fixing hosts file break kerberos Message-ID: Afternoon. I just noticed that I used inappropriate way of setting up my hosts files and I am planning to make a fix. I am however worried this may break Kerberos. Should this change be of concern and have anyone made the changes before? My current /etc/hosts are as follows: 192.168.20.2 ipa ipa.example.com I am planning to change them so that the above line looks like this: 192.168.20.2 ipa.example.com ipa Regards, William From rharwood at redhat.com Thu Nov 17 21:10:00 2016 From: rharwood at redhat.com (Robbie Harwood) Date: Thu, 17 Nov 2016 16:10:00 -0500 Subject: [Freeipa-users] Would fixing hosts file break kerberos In-Reply-To: References: Message-ID: William Muriithi writes: > I just noticed that I used inappropriate way of setting up my hosts > files and I am planning to make a fix. I am however worried this may > break Kerberos. Should this change be of concern and have anyone made > the changes before? It will depend on what you named the host in the KDC and what your DNS/canonicalization options are. Any breakage will not be permanant; try it, see if it works, and if not, revert it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Nov 18 08:16:41 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 18 Nov 2016 09:16:41 +0100 Subject: [Freeipa-users] IPA 4.4 replica installation failing In-Reply-To: References: Message-ID: <49417871-e251-9be8-9a4e-68ef65a7b034@redhat.com> On 11/17/2016 03:51 PM, Baird, Josh wrote: > Hi all, > > In my IPA 4.4 lab (RHEL 7.3), I'm trying to install/configure a new replica, and I seem to be hitting something similar to #5412 [1]. > > The 'ipa-replica-install' is getting stuck on: > > [4/26]: creating installation admin user > > Dirsrv error logs on the new replica: > > [17/Nov/2016:08:45:09.342813042 -0600] NSMMReplicationPlugin - agmt="cn=caToimqa-d1-dc01.qa-unix.domain.com" (imqa-d1-dc01:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. > > Dirsrv access logs on existing master: > > [17/Nov/2016:08:39:59.244698389 -0600] conn=121 op=83 RESULT err=0 tag=101 nentries=0 etime=0 > [17/Nov/2016:08:40:00.248620354 -0600] conn=121 op=84 SRCH base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL > [17/Nov/2016:08:40:00.248917257 -0600] conn=121 op=84 RESULT err=0 tag=101 nentries=0 etime=0 > [17/Nov/2016:08:40:01.253067200 -0600] conn=121 op=85 SRCH base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL > [17/Nov/2016:08:40:01.253481728 -0600] conn=121 op=85 RESULT err=0 tag=101 nentries=0 etime=0 > [17/Nov/2016:08:40:02.257477560 -0600] conn=121 op=86 SRCH base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL > [17/Nov/2016:08:40:02.257813691 -0600] conn=121 op=86 RESULT err=0 tag=101 nentries=0 etime=0 > [17/Nov/2016:08:40:03.261805482 -0600] conn=121 op=88 SRCH base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL > [17/Nov/2016:08:40:03.262310788 -0600] conn=121 op=88 RESULT err=0 tag=101 nentries=0 etime=0 > > Dirsrv logs on the existing master: > > [17/Nov/2016:08:40:20.644554573 -0600] NSMMReplicationPlugin - conn=120 op=13 replica="o=ipaca": Unable to acquire replica: error: permission denied > [17/Nov/2016:08:41:57.858672215 -0600] NSMMReplicationPlugin - conn=123 op=5 replica="o=ipaca": Unable to acquire replica: error: permission denied > [17/Nov/2016:08:45:09.334188374 -0600] NSMMReplicationPlugin - conn=130 op=5 replica="o=ipaca": Unable to acquire replica: error: permission denied > > Has anyone else experienced this issue? > > Thanks, > > Josh > > [1] https://fedorahosted.org/freeipa/ticket/5412 > > Hi Josh, in the original ticket the issue was occuring when creating CA replica against 7.2 master upgraded to 7.3 with domain level raised to 1. Do you have the same scenario? Also, during the stuck installation can you check for the presence of replica's LDAP principal in 'nsds5replicabinddn' attribute on master's 'cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config' entry? I would also check for the reverse, i.e. if the master's LDAP principal is in the 'nsds5replicabinddn' attribute on replica's 'cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config' entry. -- Martin^3 Babinsky From morgan at marodin.it Fri Nov 18 09:04:54 2016 From: morgan at marodin.it (Morgan Marodin) Date: Fri, 18 Nov 2016 10:04:54 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> Message-ID: Hi Florence. I've tried to configure the wrong certificate in nss.conf (*ipaCert*), and with this Apache started. So I think the problem is in the *Server-Cert* stored in */etc/httpd/alias*, even if all manul checks are ok. These are logs with the wrong certificate test: *# tail -f /var/log/httpd/error_log* *[Fri Nov 18 09:34:32.583700 2016] [suexec:notice] [pid 7709] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)[Fri Nov 18 09:34:32.584142 2016] [:warn] [pid 7709] NSSSessionCacheTimeout is deprecated. Ignoring.[Fri Nov 18 09:34:32.584178 2016] [:debug] [pid 7709] nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com -> ipaCert[Fri Nov 18 09:34:32.844487 2016] [:info] [pid 7709] Configuring server for SSL protocol[Fri Nov 18 09:34:32.844635 2016] [:debug] [pid 7709] nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0[Fri Nov 18 09:34:32.844657 2016] [:debug] [pid 7709] nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1[Fri Nov 18 09:34:32.844668 2016] [:debug] [pid 7709] nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2[Fri Nov 18 09:34:32.844677 2016] [:debug] [pid 7709] nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum)[Fri Nov 18 09:34:32.844684 2016] [:debug] [pid 7709] nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum)[Fri Nov 18 09:34:32.844738 2016] [:debug] [pid 7709] nss_engine_init.c(906): Disabling TLS Session Tickets[Fri Nov 18 09:34:32.844746 2016] [:debug] [pid 7709] nss_engine_init.c(916): Enabling DHE key exchange[Fri Nov 18 09:34:32.844760 2016] [:debug] [pid 7709] nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL ciphers [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha][Fri Nov 18 09:34:32.844825 2016] [:debug] [pid 7709] nss_engine_init.c(1140): Disable cipher: rsa_null_md5...[Fri Nov 18 09:34:32.845105 2016] [:debug] [pid 7709] nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256[Fri Nov 18 09:34:32.845110 2016] [:info] [pid 7709] Using nickname ipaCert.[Fri Nov 18 09:34:32.847451 2016] [:error] [pid 7709] Misconfiguration of certificate's CN and virtual name. The certificate CN has IPA RA. We expected mlv-ipa01.ipa.mydomain.com as virtual name.[Fri Nov 18 09:34:33.028056 2016] [auth_digest:notice] [pid 7709] AH01757: generating secret for digest authentication ...[Fri Nov 18 09:34:33.030039 2016] [lbmethod_heartbeat:notice] [pid 7709] AH02282: No slotmem from mod_heartmonitor[Fri Nov 18 09:34:33.030122 2016] [:warn] [pid 7709] NSSSessionCacheTimeout is deprecated. Ignoring.[Fri Nov 18 09:34:33.030176 2016] [:debug] [pid 7709] nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com -> ipaCert[Fri Nov 18 09:34:33.051481 2016] [mpm_prefork:notice] [pid 7709] AH00163: Apache/2.4.6 () mod_auth_gssapi/1.4.0 mod_auth_kerb/5.4 mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations[Fri Nov 18 09:34:33.051551 2016] [core:notice] [pid 7709] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'[Fri Nov 18 09:34:33.096050 2016] [proxy:debug] [pid 7717] proxy_util.c(1838): AH00924: worker ajp://localhost shared already initialized[Fri Nov 18 09:34:33.096163 2016] [proxy:debug] [pid 7717] proxy_util.c(1880): AH00926: worker ajp://localhost local already initialized...[Fri Nov 18 09:34:33.105626 2016] [proxy:debug] [pid 7719] proxy_util.c(1838): AH00924: worker unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ shared already initialized[Fri Nov 18 09:34:33.105632 2016] [proxy:debug] [pid 7719] proxy_util.c(1880): AH00926: worker unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ local already initialized[Fri Nov 18 09:34:33.342762 2016] [:info] [pid 7717] Configuring server for SSL protocol[Fri Nov 18 09:34:33.342867 2016] [:debug] [pid 7717] nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0[Fri Nov 18 09:34:33.342880 2016] [:debug] [pid 7717] nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1[Fri Nov 18 09:34:33.342885 2016] [:debug] [pid 7717] nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2[Fri Nov 18 09:34:33.342890 2016] [:debug] [pid 7717] nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum)[Fri Nov 18 09:34:33.342894 2016] [:debug] [pid 7717] nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum)[Fri Nov 18 09:34:33.342900 2016] [:debug] [pid 7717] nss_engine_init.c(906): Disabling TLS Session Tickets[Fri Nov 18 09:34:33.342904 2016] [:debug] [pid 7717] nss_engine_init.c(916): Enabling DHE key exchange[Fri Nov 18 09:34:33.342917 2016] [:debug] [pid 7717] nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL ciphers [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha][Fri Nov 18 09:34:33.342970 2016] [:debug] [pid 7717] nss_engine_init.c(1140): Disable cipher: rsa_null_md5...[Fri Nov 18 09:34:33.343233 2016] [:debug] [pid 7717] nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256[Fri Nov 18 09:34:33.343237 2016] [:info] [pid 7717] Using nickname ipaCert.[Fri Nov 18 09:34:33.344533 2016] [:error] [pid 7717] Misconfiguration of certificate's CN and virtual name. The certificate CN has IPA RA. We expected mlv-ipa01.ipa.mydomain.com as virtual name.[Fri Nov 18 09:34:33.364061 2016] [:info] [pid 7718] Configuring server for SSL protocol[Fri Nov 18 09:34:33.364156 2016] [:debug] [pid 7718] nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0[Fri Nov 18 09:34:33.364167 2016] [:debug] [pid 7718] nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1[Fri Nov 18 09:34:33.364172 2016] [:debug] [pid 7718] nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2[Fri Nov 18 09:34:33.364176 2016] [:debug] [pid 7718] nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum)[Fri Nov 18 09:34:33.364180 2016] [:debug] [pid 7718] nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum)[Fri Nov 18 09:34:33.364187 2016] [:debug] [pid 7718] nss_engine_init.c(906): Disabling TLS Session Tickets[Fri Nov 18 09:34:33.364191 2016] [:debug] [pid 7718] nss_engine_init.c(916): Enabling DHE key exchange[Fri Nov 18 09:34:33.364202 2016] [:debug] [pid 7718] nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL ciphers [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha][Fri Nov 18 09:34:33.364240 2016] [:debug] [pid 7718] nss_engine_init.c(1140): Disable cipher: rsa_null_md5...[Fri Nov 18 09:34:33.364611 2016] [:debug] [pid 7718] nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256[Fri Nov 18 09:34:33.364625 2016] [:info] [pid 7718] Using nickname ipaCert.[Fri Nov 18 09:34:33.365549 2016] [:error] [pid 7718] Misconfiguration of certificate's CN and virtual name. The certificate CN has IPA RA. We expected mlv-ipa01.ipa.mydomain.com as virtual name.[Fri Nov 18 09:34:33.369972 2016] [:info] [pid 7720] Configuring server for SSL protocol[Fri Nov 18 09:34:33.370200 2016] [:debug] [pid 7720] nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0[Fri Nov 18 09:34:33.370224 2016] [:debug] [pid 7720] nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1[Fri Nov 18 09:34:33.370239 2016] [:debug] [pid 7720] nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2[Fri Nov 18 09:34:33.370255 2016] [:debug] [pid 7720] nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum)[Fri Nov 18 09:34:33.370269 2016] [:debug] [pid 7720] nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum)[Fri Nov 18 09:34:33.370286 2016] [:debug] [pid 7720] nss_engine_init.c(906): Disabling TLS Session Tickets[Fri Nov 18 09:34:33.370301 2016] [:debug] [pid 7720] nss_engine_init.c(916): Enabling DHE key exchange[Fri Nov 18 09:34:33.370322 2016] [:debug] [pid 7720] nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL ciphers [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha][Fri Nov 18 09:34:33.370383 2016] [:debug] [pid 7720] nss_engine_init.c(1140): Disable cipher: rsa_null_md5...[Fri Nov 18 09:34:33.371418 2016] [:debug] [pid 7720] nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256[Fri Nov 18 09:34:33.371437 2016] [:info] [pid 7720] Using nickname ipaCert.[Fri Nov 18 09:34:33.371486 2016] [:info] [pid 7716] Configuring server for SSL protocol[Fri Nov 18 09:34:33.372383 2016] [:debug] [pid 7716] nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0[Fri Nov 18 09:34:33.372439 2016] [:debug] [pid 7716] nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1[Fri Nov 18 09:34:33.372459 2016] [:debug] [pid 7716] nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2[Fri Nov 18 09:34:33.372484 2016] [:debug] [pid 7716] nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum)[Fri Nov 18 09:34:33.372513 2016] [:debug] [pid 7716] nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum)[Fri Nov 18 09:34:33.372534 2016] [:debug] [pid 7716] nss_engine_init.c(906): Disabling TLS Session Tickets[Fri Nov 18 09:34:33.372553 2016] [:debug] [pid 7716] nss_engine_init.c(916): Enabling DHE key exchange[Fri Nov 18 09:34:33.372580 2016] [:debug] [pid 7716] nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL ciphers [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha][Fri Nov 18 09:34:33.372627 2016] [:debug] [pid 7716] nss_engine_init.c(1140): Disable cipher: rsa_null_md5...[Fri Nov 18 09:34:33.373712 2016] [:debug] [pid 7716] nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256[Fri Nov 18 09:34:33.373734 2016] [:info] [pid 7716] Using nickname ipaCert.[Fri Nov 18 09:34:33.374652 2016] [:error] [pid 7716] Misconfiguration of certificate's CN and virtual name. The certificate CN has IPA RA. We expected mlv-ipa01.ipa.mydomain.com as virtual name.[Fri Nov 18 09:34:33.372295 2016] [:error] [pid 7720] Misconfiguration of certificate's CN and virtual name. The certificate CN has IPA RA. We expected mlv-ipa01.ipa.mydomain.com as virtual name.[Fri Nov 18 09:34:33.412689 2016] [:info] [pid 7719] Configuring server for SSL protocol[Fri Nov 18 09:34:33.412791 2016] [:debug] [pid 7719] nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0[Fri Nov 18 09:34:33.412803 2016] [:debug] [pid 7719] nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1[Fri Nov 18 09:34:33.412807 2016] [:debug] [pid 7719] nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2[Fri Nov 18 09:34:33.412812 2016] [:debug] [pid 7719] nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum)[Fri Nov 18 09:34:33.412817 2016] [:debug] [pid 7719] nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum)[Fri Nov 18 09:34:33.412824 2016] [:debug] [pid 7719] nss_engine_init.c(906): Disabling TLS Session Tickets[Fri Nov 18 09:34:33.412828 2016] [:debug] [pid 7719] nss_engine_init.c(916): Enabling DHE key exchange[Fri Nov 18 09:34:33.412840 2016] [:debug] [pid 7719] nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL ciphers [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha][Fri Nov 18 09:34:33.412891 2016] [:debug] [pid 7719] nss_engine_init.c(1140): Disable cipher: rsa_null_md5...[Fri Nov 18 09:34:33.413159 2016] [:debug] [pid 7719] nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256[Fri Nov 18 09:34:33.413164 2016] [:info] [pid 7719] Using nickname ipaCert.[Fri Nov 18 09:34:33.414462 2016] [:error] [pid 7719] Misconfiguration of certificate's CN and virtual name. The certificate CN has IPA RA. We expected mlv-ipa01.ipa.mydomain.com as virtual name.[Fri Nov 18 09:34:35.558286 2016] [:error] [pid 7715] ipa: WARNING: session memcached servers not running[Fri Nov 18 09:34:35.559653 2016] [:error] [pid 7714] ipa: WARNING: session memcached servers not running[Fri Nov 18 09:34:37.511457 2016] [:error] [pid 7714] ipa: INFO: *** PROCESS START ***[Fri Nov 18 09:34:37.517899 2016] [:error] [pid 7715] ipa: INFO: *** PROCESS START ***[Fri Nov 18 09:34:51.498536 2016] [:info] [pid 7717] Connection to child 1 established (server mlv-ipa01.ipa.mydomain.com , client 192.168.0.239)[Fri Nov 18 09:34:51.510292 2016] [:info] [pid 7717] SSL input filter read failed.[Fri Nov 18 09:34:51.510311 2016] [:error] [pid 7717] SSL Library Error: -12285 Unable to find the certificate or key necessary for authentication[Fri Nov 18 09:34:51.510356 2016] [:info] [pid 7717] Connection to child 1 closed (server mlv-ipa01.ipa.mydomain.com:443 , client 192.168.0.239)[Fri Nov 18 09:35:18.790760 2016] [mpm_prefork:notice] [pid 7709] AH00170: caught SIGWINCH, shutting down gracefully* Is possible to delete *Server-Cert* from */etc/httpd/alias* and reimport it from the original certificates of *mlv-ipa01.ipa.mydomain.com *? Where are stored the original certificates? Please let me know, thanks. Bye, Morgan 2016-11-17 17:09 GMT+01:00 Florence Blanc-Renaud : > On 11/17/2016 04:51 PM, Morgan Marodin wrote: > >> Hi Rob. >> >> I've just tried to remove the group write to the *.db files, but it's >> not the problem. >> /[root at mlv-ipa01 ~]# grep NSSNickname /etc/httpd/conf.d/nss.conf >> NSSNickname Server-Cert/ >> >> I've tried to run manually /dirsrv.target/ and /krb5kdc.service/, and it >> works, services went up. >> The same for /ntpd/, /named-pkcs11.service/, /smb.service/, >> /winbind.service/, /kadmin.service/, /memcached.service/ and >> /pki-tomcatd.target/. >> >> But if I try to start /httpd.service/: >> /[root at mlv-ipa01 ~]# tail -f /var/log/messages >> Nov 17 16:46:06 mlv-ipa01 systemd[1]: Starting The Apache HTTP Server... >> Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: ipa : INFO KDC >> proxy enabled >> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: main process >> exited, code=exited, status=1/FAILURE >> Nov 17 16:46:07 mlv-ipa01 kill: kill: cannot find process "" >> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: control process >> exited, code=exited status=1 >> Nov 17 16:46:07 mlv-ipa01 systemd[1]: Failed to start The Apache HTTP >> Server. >> Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit httpd.service entered failed >> state. >> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service failed./ >> >> Any other ideas? >> > Hi, > > - Does the NSS Db contain the private key for Server-Cert? If yes, the > command > $ certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt > should display a line like this one: > < 0> rsa 01a6cbd773f3d785ffa44233148dcb8ade266ea5 NSS Certificate > DB:Server-Cert > > - Is your system running with SElinux enforcing? If yes, you can check if > there were SElinux permission denials using > $ ausearch -m avc --start recent > > - If the certificate was expired, I believe you would see a different > message, but it doesn't hurt to check its validity > $ certutil -L -d /etc/httpd/alias/ -n Server-Cert | egrep "Not Before|Not > After" > > > Flo. > >> >> Please let me know, thanks. >> Morgan >> >> 2016-11-17 16:11 GMT+01:00 Rob Crittenden > >: >> >> >> Morgan Marodin wrote: >> > Hi Florence. >> > >> > Thanks for your support. >> > >> > Yes, httpd is using /etc/httpd/alias as NSS DB. And seems that all >> > permissions and certificates are good: >> > /[root at mlv-ipa01 ~]# ls -l /etc/httpd/alias/ >> > total 184 >> > -r--r--r-- 1 root root 1345 Sep 7 2015 cacert.asc >> > -rw-rw---- 1 root apache 65536 Nov 17 11:06 cert8.db >> > -rw-r-----. 1 root apache 65536 Sep 4 2015 cert8.db.orig >> > -rw-------. 1 root root 4833 Sep 4 2015 install.log >> > -rw-rw---- 1 root apache 16384 Nov 17 11:06 key3.db >> > -rw-r-----. 1 root apache 16384 Sep 4 2015 key3.db.orig >> > lrwxrwxrwx 1 root root 24 Nov 17 10:24 libnssckbi.so -> >> > /usr/lib64/libnssckbi.so >> > -rw-rw---- 1 root apache 20 Sep 7 2015 pwdfile.txt >> > -rw-rw---- 1 root apache 16384 Sep 7 2015 secmod.db >> > -rw-r-----. 1 root apache 16384 Sep 4 2015 secmod.db.orig/ >> >> Eventually you'll want to remove group write on the *.db files. >> >> > And password validations seems ok, too: >> > /[root at mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f >> > /etc/httpd/alias/pwdfile.txt >> good >> >> > Enabling mod-nss debug I can see these logs: >> > /[root at mlv-ipa01 ~]# tail -f /var/log/httpd/error_log >> > [Thu Nov 17 15:05:10.807603 2016] [suexec:notice] [pid 10660] >> AH01232: >> > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> > [Thu Nov 17 15:05:10.807958 2016] [:warn] [pid 10660] >> > NSSSessionCacheTimeout is deprecated. Ignoring. >> > [Thu Nov 17 15:05:10.807991 2016] [:debug] [pid 10660] >> > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com < >> http://mlv-ipa01.ipa.mydomain.com> >> > > >> > -> Server-Cert >> > [Thu Nov 17 15:05:11.002664 2016] [:info] [pid 10660] Configuring >> server >> > for SSL protocol >> > [Thu Nov 17 15:05:11.002817 2016] [:debug] [pid 10660] >> > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >> > [Thu Nov 17 15:05:11.002838 2016] [:debug] [pid 10660] >> > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >> > [Thu Nov 17 15:05:11.002847 2016] [:debug] [pid 10660] >> > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >> > [Thu Nov 17 15:05:11.002856 2016] [:debug] [pid 10660] >> > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >> > [Thu Nov 17 15:05:11.002876 2016] [:debug] [pid 10660] >> > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >> > [Thu Nov 17 15:05:11.003099 2016] [:debug] [pid 10660] >> > nss_engine_init.c(906): Disabling TLS Session Tickets >> > [Thu Nov 17 15:05:11.003198 2016] [:debug] [pid 10660] >> > nss_engine_init.c(916): Enabling DHE key exchange >> > [Thu Nov 17 15:05:11.003313 2016] [:debug] [pid 10660] >> > nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >> > ciphers >> > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_ >> sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_ >> sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_ >> sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+ >> rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >> > [Thu Nov 17 15:05:11.003469 2016] [:debug] [pid 10660] >> > [Thu Nov 17 15:05:11.006759 2016] [:info] [pid 10660] Using nickname >> > Server-Cert. >> [snip] >> > [Thu Nov 17 15:05:11.006771 2016] [:error] [pid 10660] Certificate >> not >> > found: 'Server-Cert' >> >> Can you shows what this returns: >> >> # grep NSSNickname /etc/httpd/conf.d/nss.conf >> >> > Do you think there is a kerberos problem? >> >> It definitely is not. >> >> You can bring the system up in a minimal way by manually starting the >> dirsrv at EXAMPLE.COM service and then >> krb5kdc. This will at least let your >> users authenticate. The management framework (GUI) runs through Apache >> so that will be down until we can get Apache started again. >> >> rob >> >> > >> > Please let me know, thanks. >> > Bye, Morgan >> > >> > 2016-11-17 14:39 GMT+01:00 Florence Blanc-Renaud > >> > >>: >> >> > >> > On 11/17/2016 12:09 PM, Morgan Marodin wrote: >> > >> > Hello. >> > >> > This morning I've tried to upgrade my IPA server, but the >> upgrade >> > failed, and now the service doesn't start! :( >> > >> > If I try lo launch the upgrade manually this is the output: >> > /[root at mlv-ipa01 download]# 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 >> > [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 >> > 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: >> > CalledProcessError: Command '/bin/systemctl start >> httpd.service' >> > returned non-zero exit status 1 >> > The ipa-server-upgrade command failed. See >> > /var/log/ipaupgrade.log for >> > more information/ >> > >> > These are error logs of Apache: >> > /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] [pid >> 5664] >> > AH01232: >> > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> > [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664] >> > NSSSessionCacheTimeout is deprecated. Ignoring. >> > [Thu Nov 17 11:48:45.830910 2016] [:error] [pid 5664] >> > Certificate not >> > found: 'Server-Cert'/ >> > >> > The problem seems to be the /Server-Cert /that could not >> be found. >> > But if I try to execute the certutil command manually I >> can see it:/ >> > [root at mlv-ipa01 log]# certutil -L -d /etc/httpd/alias/ >> > Certificate Nickname >> Trust >> > Attributes >> > >> > SSL,S/MIME,JAR/XPI >> > Signing-Cert >> u,u,u >> > ipaCert >> u,u,u >> > Server-Cert >> Pu,u,u >> > IPA.MYDOMAIN.COM >> >> > IPA >> > CA CT,C,C/ >> > >> > Could you help me? >> > What could I try to do to restart my service? >> > >> > Hi, >> > >> > I would first make sure that httpd is using /etc/httpd/alias >> as NSS >> > DB (check the directive NSSCertificateDatabase in >> > /etc/httpd/conf.d/nss.conf). >> > Then it may be a file permission issue: the NSS DB should >> belong to >> > root:apache (the relevant files are cert8.db, key3.db and >> secmod.db). >> > You should also find a pwdfile.txt in the same directory, >> containing >> > the NSS DB password. Check that the password is valid using >> > certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt >> > (if the command succeeds then the password in pwdfile is OK). >> > >> > You can also enable mod-nss debug in /etc/httpd/conf/nss.conf by >> > setting "LogLevel debug", and check the output in >> > /var/log/httpd/error_log. >> > >> > HTH, >> > Flo. >> > >> > Thanks, Morgan >> > >> > >> > >> > -- >> > 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 flo at redhat.com Fri Nov 18 09:39:53 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Fri, 18 Nov 2016 10:39:53 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> Message-ID: <994f1c25-5c63-b0f0-1da4-6b4788331daf@redhat.com> On 11/18/2016 10:04 AM, Morgan Marodin wrote: > Hi Florence. > > I've tried to configure the wrong certificate in nss.conf (/ipaCert/), > and with this Apache started. > So I think the problem is in the /Server-Cert/ stored in > //etc/httpd/alias/, even if all manul checks are ok. > > These are logs with the wrong certificate test: > /# tail -f /var/log/httpd/error_log/ > /[Fri Nov 18 09:34:32.583700 2016] [suexec:notice] [pid 7709] AH01232: > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Fri Nov 18 09:34:32.584142 2016] [:warn] [pid 7709] > NSSSessionCacheTimeout is deprecated. Ignoring. > [Fri Nov 18 09:34:32.584178 2016] [:debug] [pid 7709] > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > -> ipaCert > [Fri Nov 18 09:34:32.844487 2016] [:info] [pid 7709] Configuring server > for SSL protocol > [Fri Nov 18 09:34:32.844635 2016] [:debug] [pid 7709] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:32.844657 2016] [:debug] [pid 7709] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:32.844668 2016] [:debug] [pid 7709] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:32.844677 2016] [:debug] [pid 7709] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:32.844684 2016] [:debug] [pid 7709] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:32.844738 2016] [:debug] [pid 7709] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:32.844746 2016] [:debug] [pid 7709] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:32.844760 2016] [:debug] [pid 7709] > nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:32.844825 2016] [:debug] [pid 7709] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:32.845105 2016] [:debug] [pid 7709] > nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:32.845110 2016] [:info] [pid 7709] Using nickname ipaCert. > [Fri Nov 18 09:34:32.847451 2016] [:error] [pid 7709] Misconfiguration > of certificate's CN and virtual name. The certificate CN has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > as virtual name. > [Fri Nov 18 09:34:33.028056 2016] [auth_digest:notice] [pid 7709] > AH01757: generating secret for digest authentication ... > [Fri Nov 18 09:34:33.030039 2016] [lbmethod_heartbeat:notice] [pid 7709] > AH02282: No slotmem from mod_heartmonitor > [Fri Nov 18 09:34:33.030122 2016] [:warn] [pid 7709] > NSSSessionCacheTimeout is deprecated. Ignoring. > [Fri Nov 18 09:34:33.030176 2016] [:debug] [pid 7709] > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > -> ipaCert > [Fri Nov 18 09:34:33.051481 2016] [mpm_prefork:notice] [pid 7709] > AH00163: Apache/2.4.6 () mod_auth_gssapi/1.4.0 mod_auth_kerb/5.4 > mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured > -- resuming normal operations > [Fri Nov 18 09:34:33.051551 2016] [core:notice] [pid 7709] AH00094: > Command line: '/usr/sbin/httpd -D FOREGROUND' > [Fri Nov 18 09:34:33.096050 2016] [proxy:debug] [pid 7717] > proxy_util.c(1838): AH00924: worker ajp://localhost shared already > initialized > [Fri Nov 18 09:34:33.096163 2016] [proxy:debug] [pid 7717] > proxy_util.c(1880): AH00926: worker ajp://localhost local already > initialized > ... > [Fri Nov 18 09:34:33.105626 2016] [proxy:debug] [pid 7719] > proxy_util.c(1838): AH00924: worker > unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ shared already > initialized > [Fri Nov 18 09:34:33.105632 2016] [proxy:debug] [pid 7719] > proxy_util.c(1880): AH00926: worker > unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ local already > initialized > [Fri Nov 18 09:34:33.342762 2016] [:info] [pid 7717] Configuring server > for SSL protocol > [Fri Nov 18 09:34:33.342867 2016] [:debug] [pid 7717] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:33.342880 2016] [:debug] [pid 7717] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:33.342885 2016] [:debug] [pid 7717] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:33.342890 2016] [:debug] [pid 7717] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:33.342894 2016] [:debug] [pid 7717] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:33.342900 2016] [:debug] [pid 7717] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:33.342904 2016] [:debug] [pid 7717] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:33.342917 2016] [:debug] [pid 7717] > nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:33.342970 2016] [:debug] [pid 7717] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:33.343233 2016] [:debug] [pid 7717] > nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:33.343237 2016] [:info] [pid 7717] Using nickname ipaCert. > [Fri Nov 18 09:34:33.344533 2016] [:error] [pid 7717] Misconfiguration > of certificate's CN and virtual name. The certificate CN has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > as virtual name. > [Fri Nov 18 09:34:33.364061 2016] [:info] [pid 7718] Configuring server > for SSL protocol > [Fri Nov 18 09:34:33.364156 2016] [:debug] [pid 7718] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:33.364167 2016] [:debug] [pid 7718] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:33.364172 2016] [:debug] [pid 7718] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:33.364176 2016] [:debug] [pid 7718] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:33.364180 2016] [:debug] [pid 7718] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:33.364187 2016] [:debug] [pid 7718] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:33.364191 2016] [:debug] [pid 7718] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:33.364202 2016] [:debug] [pid 7718] > nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:33.364240 2016] [:debug] [pid 7718] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:33.364611 2016] [:debug] [pid 7718] > nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:33.364625 2016] [:info] [pid 7718] Using nickname ipaCert. > [Fri Nov 18 09:34:33.365549 2016] [:error] [pid 7718] Misconfiguration > of certificate's CN and virtual name. The certificate CN has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > as virtual name. > [Fri Nov 18 09:34:33.369972 2016] [:info] [pid 7720] Configuring server > for SSL protocol > [Fri Nov 18 09:34:33.370200 2016] [:debug] [pid 7720] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:33.370224 2016] [:debug] [pid 7720] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:33.370239 2016] [:debug] [pid 7720] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:33.370255 2016] [:debug] [pid 7720] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:33.370269 2016] [:debug] [pid 7720] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:33.370286 2016] [:debug] [pid 7720] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:33.370301 2016] [:debug] [pid 7720] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:33.370322 2016] [:debug] [pid 7720] > nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:33.370383 2016] [:debug] [pid 7720] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:33.371418 2016] [:debug] [pid 7720] > nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:33.371437 2016] [:info] [pid 7720] Using nickname ipaCert. > [Fri Nov 18 09:34:33.371486 2016] [:info] [pid 7716] Configuring server > for SSL protocol > [Fri Nov 18 09:34:33.372383 2016] [:debug] [pid 7716] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:33.372439 2016] [:debug] [pid 7716] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:33.372459 2016] [:debug] [pid 7716] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:33.372484 2016] [:debug] [pid 7716] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:33.372513 2016] [:debug] [pid 7716] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:33.372534 2016] [:debug] [pid 7716] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:33.372553 2016] [:debug] [pid 7716] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:33.372580 2016] [:debug] [pid 7716] > nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:33.372627 2016] [:debug] [pid 7716] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:33.373712 2016] [:debug] [pid 7716] > nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:33.373734 2016] [:info] [pid 7716] Using nickname ipaCert. > [Fri Nov 18 09:34:33.374652 2016] [:error] [pid 7716] Misconfiguration > of certificate's CN and virtual name. The certificate CN has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > as virtual name. > [Fri Nov 18 09:34:33.372295 2016] [:error] [pid 7720] Misconfiguration > of certificate's CN and virtual name. The certificate CN has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > as virtual name. > [Fri Nov 18 09:34:33.412689 2016] [:info] [pid 7719] Configuring server > for SSL protocol > [Fri Nov 18 09:34:33.412791 2016] [:debug] [pid 7719] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:33.412803 2016] [:debug] [pid 7719] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:33.412807 2016] [:debug] [pid 7719] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:33.412812 2016] [:debug] [pid 7719] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:33.412817 2016] [:debug] [pid 7719] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:33.412824 2016] [:debug] [pid 7719] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:33.412828 2016] [:debug] [pid 7719] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:33.412840 2016] [:debug] [pid 7719] > nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:33.412891 2016] [:debug] [pid 7719] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:33.413159 2016] [:debug] [pid 7719] > nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:33.413164 2016] [:info] [pid 7719] Using nickname ipaCert. > [Fri Nov 18 09:34:33.414462 2016] [:error] [pid 7719] Misconfiguration > of certificate's CN and virtual name. The certificate CN has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > as virtual name. > [Fri Nov 18 09:34:35.558286 2016] [:error] [pid 7715] ipa: WARNING: > session memcached servers not running > [Fri Nov 18 09:34:35.559653 2016] [:error] [pid 7714] ipa: WARNING: > session memcached servers not running > [Fri Nov 18 09:34:37.511457 2016] [:error] [pid 7714] ipa: INFO: *** > PROCESS START *** > [Fri Nov 18 09:34:37.517899 2016] [:error] [pid 7715] ipa: INFO: *** > PROCESS START *** > [Fri Nov 18 09:34:51.498536 2016] [:info] [pid 7717] Connection to child > 1 established (server mlv-ipa01.ipa.mydomain.com > , client 192.168.0.239) > [Fri Nov 18 09:34:51.510292 2016] [:info] [pid 7717] SSL input filter > read failed. > [Fri Nov 18 09:34:51.510311 2016] [:error] [pid 7717] SSL Library Error: > -12285 Unable to find the certificate or key necessary for authentication > [Fri Nov 18 09:34:51.510356 2016] [:info] [pid 7717] Connection to child > 1 closed (server mlv-ipa01.ipa.mydomain.com:443 > , client 192.168.0.239) > [Fri Nov 18 09:35:18.790760 2016] [mpm_prefork:notice] [pid 7709] > AH00170: caught SIGWINCH, shutting down gracefully/ > > Is possible to delete /Server-Cert/ from //etc/httpd/alias/ and reimport > it from the original certificates of /mlv-ipa01.ipa.mydomain.com > /? > Where are stored the original certificates? > Hi Morgan, with ldapsearch you should be able to find the certificate: ldapsearch -h ipaserver.ipadomain -p 389 -D "cn=directory manager" -w password -LLL -b krbprincipalname=HTTP/ipaserver.ipadomain at IPADOMAIN,cn=services,cn=accounts,dc=IPADOMAIN The cert will be stored in the field "usercertificate". HTH, Flo. > Please let me know, thanks. > Bye, Morgan > > 2016-11-17 17:09 GMT+01:00 Florence Blanc-Renaud >: > > On 11/17/2016 04:51 PM, Morgan Marodin wrote: > > Hi Rob. > > I've just tried to remove the group write to the *.db files, but > it's > not the problem. > /[root at mlv-ipa01 ~]# grep NSSNickname /etc/httpd/conf.d/nss.conf > NSSNickname Server-Cert/ > > I've tried to run manually /dirsrv.target/ and > /krb5kdc.service/, and it > works, services went up. > The same for /ntpd/, /named-pkcs11.service/, /smb.service/, > /winbind.service/, /kadmin.service/, /memcached.service/ and > /pki-tomcatd.target/. > > But if I try to start /httpd.service/: > /[root at mlv-ipa01 ~]# tail -f /var/log/messages > Nov 17 16:46:06 mlv-ipa01 systemd[1]: Starting The Apache HTTP > Server... > Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: ipa : > INFO KDC > proxy enabled > Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: main process > exited, code=exited, status=1/FAILURE > Nov 17 16:46:07 mlv-ipa01 kill: kill: cannot find process "" > Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: control process > exited, code=exited status=1 > Nov 17 16:46:07 mlv-ipa01 systemd[1]: Failed to start The Apache > HTTP > Server. > Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit httpd.service entered > failed > state. > Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service failed./ > > Any other ideas? > > Hi, > > - Does the NSS Db contain the private key for Server-Cert? If yes, > the command > $ certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt > should display a line like this one: > < 0> rsa 01a6cbd773f3d785ffa44233148dcb8ade266ea5 NSS > Certificate DB:Server-Cert > > - Is your system running with SElinux enforcing? If yes, you can > check if there were SElinux permission denials using > $ ausearch -m avc --start recent > > - If the certificate was expired, I believe you would see a > different message, but it doesn't hurt to check its validity > $ certutil -L -d /etc/httpd/alias/ -n Server-Cert | egrep "Not > Before|Not After" > > > Flo. > > > Please let me know, thanks. > Morgan > > 2016-11-17 16:11 GMT+01:00 Rob Crittenden > >>: > > > Morgan Marodin wrote: > > Hi Florence. > > > > Thanks for your support. > > > > Yes, httpd is using /etc/httpd/alias as NSS DB. And seems > that all > > permissions and certificates are good: > > /[root at mlv-ipa01 ~]# ls -l /etc/httpd/alias/ > > total 184 > > -r--r--r-- 1 root root 1345 Sep 7 2015 cacert.asc > > -rw-rw---- 1 root apache 65536 Nov 17 11:06 cert8.db > > -rw-r-----. 1 root apache 65536 Sep 4 2015 cert8.db.orig > > -rw-------. 1 root root 4833 Sep 4 2015 install.log > > -rw-rw---- 1 root apache 16384 Nov 17 11:06 key3.db > > -rw-r-----. 1 root apache 16384 Sep 4 2015 key3.db.orig > > lrwxrwxrwx 1 root root 24 Nov 17 10:24 libnssckbi.so -> > > /usr/lib64/libnssckbi.so > > -rw-rw---- 1 root apache 20 Sep 7 2015 pwdfile.txt > > -rw-rw---- 1 root apache 16384 Sep 7 2015 secmod.db > > -rw-r-----. 1 root apache 16384 Sep 4 2015 secmod.db.orig/ > > Eventually you'll want to remove group write on the *.db files. > > > And password validations seems ok, too: > > /[root at mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f > > /etc/httpd/alias/pwdfile.txt > good > > > Enabling mod-nss debug I can see these logs: > > /[root at mlv-ipa01 ~]# tail -f /var/log/httpd/error_log > > [Thu Nov 17 15:05:10.807603 2016] [suexec:notice] [pid > 10660] AH01232: > > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > > [Thu Nov 17 15:05:10.807958 2016] [:warn] [pid 10660] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Thu Nov 17 15:05:10.807991 2016] [:debug] [pid 10660] > > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > > > > > > >> -> Server-Cert > > [Thu Nov 17 15:05:11.002664 2016] [:info] [pid 10660] > Configuring server > > for SSL protocol > > [Thu Nov 17 15:05:11.002817 2016] [:debug] [pid 10660] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Thu Nov 17 15:05:11.002838 2016] [:debug] [pid 10660] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Thu Nov 17 15:05:11.002847 2016] [:debug] [pid 10660] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Thu Nov 17 15:05:11.002856 2016] [:debug] [pid 10660] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Thu Nov 17 15:05:11.002876 2016] [:debug] [pid 10660] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Thu Nov 17 15:05:11.003099 2016] [:debug] [pid 10660] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Thu Nov 17 15:05:11.003198 2016] [:debug] [pid 10660] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Thu Nov 17 15:05:11.003313 2016] [:debug] [pid 10660] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > permitted SSL > > ciphers > > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Thu Nov 17 15:05:11.003469 2016] [:debug] [pid 10660] > > [Thu Nov 17 15:05:11.006759 2016] [:info] [pid 10660] > Using nickname > > Server-Cert. > [snip] > > [Thu Nov 17 15:05:11.006771 2016] [:error] [pid 10660] > Certificate not > > found: 'Server-Cert' > > Can you shows what this returns: > > # grep NSSNickname /etc/httpd/conf.d/nss.conf > > > Do you think there is a kerberos problem? > > It definitely is not. > > You can bring the system up in a minimal way by manually > starting the > dirsrv at EXAMPLE.COM > > service > and then > krb5kdc. This will at least let your > users authenticate. The management framework (GUI) runs > through Apache > so that will be down until we can get Apache started again. > > rob > > > > > Please let me know, thanks. > > Bye, Morgan > > > > 2016-11-17 14:39 GMT+01:00 Florence Blanc-Renaud > > > > > >>>: > > > > > On 11/17/2016 12:09 PM, Morgan Marodin wrote: > > > > Hello. > > > > This morning I've tried to upgrade my IPA server, > but the > upgrade > > failed, and now the service doesn't start! :( > > > > If I try lo launch the upgrade manually this is > the output: > > /[root at mlv-ipa01 download]# 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 > > [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 > > 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: > > CalledProcessError: Command '/bin/systemctl start > httpd.service' > > returned non-zero exit status 1 > > The ipa-server-upgrade command failed. See > > /var/log/ipaupgrade.log for > > more information/ > > > > These are error logs of Apache: > > /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] > [pid 5664] > > AH01232: > > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > > [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Thu Nov 17 11:48:45.830910 2016] [:error] [pid 5664] > > Certificate not > > found: 'Server-Cert'/ > > > > The problem seems to be the /Server-Cert /that > could not > be found. > > But if I try to execute the certutil command > manually I > can see it:/ > > [root at mlv-ipa01 log]# certutil -L -d /etc/httpd/alias/ > > Certificate Nickname > Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > Signing-Cert > u,u,u > > ipaCert > u,u,u > > Server-Cert > Pu,u,u > > IPA.MYDOMAIN.COM > > > > IPA > > CA CT,C,C/ > > > > Could you help me? > > What could I try to do to restart my service? > > > > Hi, > > > > I would first make sure that httpd is using > /etc/httpd/alias > as NSS > > DB (check the directive NSSCertificateDatabase in > > /etc/httpd/conf.d/nss.conf). > > Then it may be a file permission issue: the NSS DB should > belong to > > root:apache (the relevant files are cert8.db, key3.db and > secmod.db). > > You should also find a pwdfile.txt in the same directory, > containing > > the NSS DB password. Check that the password is valid > using > > certutil -K -d /etc/httpd/alias/ -f > /etc/httpd/alias/pwdfile.txt > > (if the command succeeds then the password in pwdfile > is OK). > > > > You can also enable mod-nss debug in > /etc/httpd/conf/nss.conf by > > setting "LogLevel debug", and check the output in > > /var/log/httpd/error_log. > > > > HTH, > > Flo. > > > > Thanks, Morgan > > > > > > > > -- > > 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 tbordaz at redhat.com Fri Nov 18 10:08:23 2016 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 18 Nov 2016 11:08:23 +0100 Subject: [Freeipa-users] IPA 4.4 replica installation failing In-Reply-To: <49417871-e251-9be8-9a4e-68ef65a7b034@redhat.com> References: <49417871-e251-9be8-9a4e-68ef65a7b034@redhat.com> Message-ID: <582ED317.90705@redhat.com> On 11/18/2016 09:16 AM, Martin Babinsky wrote: > On 11/17/2016 03:51 PM, Baird, Josh wrote: >> Hi all, >> >> In my IPA 4.4 lab (RHEL 7.3), I'm trying to install/configure a new >> replica, and I seem to be hitting something similar to #5412 [1]. >> >> The 'ipa-replica-install' is getting stuck on: >> >> [4/26]: creating installation admin user >> >> Dirsrv error logs on the new replica: >> >> [17/Nov/2016:08:45:09.342813042 -0600] NSMMReplicationPlugin - >> agmt="cn=caToimqa-d1-dc01.qa-unix.domain.com" (imqa-d1-dc01:389): >> Unable to acquire replica: permission denied. The bind dn "" does not >> have permission to supply replication updates to the replica. Will >> retry later. >> >> Dirsrv access logs on existing master: >> >> [17/Nov/2016:08:39:59.244698389 -0600] conn=121 op=83 RESULT err=0 >> tag=101 nentries=0 etime=0 >> [17/Nov/2016:08:40:00.248620354 -0600] conn=121 op=84 SRCH >> base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" >> scope=0 filter="(objectClass=*)" attrs=ALL >> [17/Nov/2016:08:40:00.248917257 -0600] conn=121 op=84 RESULT err=0 >> tag=101 nentries=0 etime=0 >> [17/Nov/2016:08:40:01.253067200 -0600] conn=121 op=85 SRCH >> base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" >> scope=0 filter="(objectClass=*)" attrs=ALL >> [17/Nov/2016:08:40:01.253481728 -0600] conn=121 op=85 RESULT err=0 >> tag=101 nentries=0 etime=0 >> [17/Nov/2016:08:40:02.257477560 -0600] conn=121 op=86 SRCH >> base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" >> scope=0 filter="(objectClass=*)" attrs=ALL >> [17/Nov/2016:08:40:02.257813691 -0600] conn=121 op=86 RESULT err=0 >> tag=101 nentries=0 etime=0 >> [17/Nov/2016:08:40:03.261805482 -0600] conn=121 op=88 SRCH >> base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" >> scope=0 filter="(objectClass=*)" attrs=ALL >> [17/Nov/2016:08:40:03.262310788 -0600] conn=121 op=88 RESULT err=0 >> tag=101 nentries=0 etime=0 >> >> Dirsrv logs on the existing master: >> >> [17/Nov/2016:08:40:20.644554573 -0600] NSMMReplicationPlugin - >> conn=120 op=13 replica="o=ipaca": Unable to acquire replica: error: >> permission denied >> [17/Nov/2016:08:41:57.858672215 -0600] NSMMReplicationPlugin - >> conn=123 op=5 replica="o=ipaca": Unable to acquire replica: error: >> permission denied >> [17/Nov/2016:08:45:09.334188374 -0600] NSMMReplicationPlugin - >> conn=130 op=5 replica="o=ipaca": Unable to acquire replica: error: >> permission denied >> >> Has anyone else experienced this issue? >> >> Thanks, >> >> Josh >> >> [1] https://fedorahosted.org/freeipa/ticket/5412 >> >> > Hi Josh, > > in the original ticket the issue was occuring when creating CA replica > against 7.2 master upgraded to 7.3 with domain level raised to 1. Do > you have the same scenario? > > Also, during the stuck installation can you check for the presence of > replica's LDAP principal in 'nsds5replicabinddn' attribute on master's > 'cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config' entry? > > I would also check for the reverse, i.e. if the master's LDAP > principal is in the 'nsds5replicabinddn' attribute on replica's > 'cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config' entry. > Hi Josh, Both direction Replica Agreements should use GSSAPI authentication with accounts in 'cn=replication managers,cn=sysaccounts,cn=etc,' Would you check the members (on master and replica) of this entry and see if it contains the expected principals ? regards thierry From rajat.linux at gmail.com Fri Nov 18 11:09:41 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Fri, 18 Nov 2016 12:09:41 +0100 Subject: [Freeipa-users] Freeipa-users Digest, Vol 100, Issue 48 In-Reply-To: References: Message-ID: Hi, I removed the pam_winbind module. User are able to login now. But some time they are not. Below are logs when user are not able to login. Also SSH login is very slow for AD user. I am using sssd 1.4 ============================= rpm -qa | grep sssd sssd-krb5-common-1.14.0-43.el7.x86_64 python-sssdconfig-1.14.0-43.el7.noarch sssd-ldap-1.14.0-43.el7.x86_64 sssd-client-1.14.0-43.el7.x86_64 sssd-ipa-1.14.0-43.el7.x86_64 sssd-proxy-1.14.0-43.el7.x86_64 sssd-common-1.14.0-43.el7.x86_64 sssd-ad-1.14.0-43.el7.x86_64 sssd-1.14.0-43.el7.x86_64 sssd-krb5-1.14.0-43.el7.x86_64 sssd-common-pac-1.14.0-43.el7.x86_64 =========================== ===================================== My sssd.conf on ipa clinet cat /etc/sssd/sssd.conf [domain/ipa.preprod.local] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.ipadomain.local id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ilt-gif-ipa02.ipa.ipadomain.local chpass_provider = ipa ipa_server = _srv_, ilt-gif-ipa01.ipa.ipadomain.local ldap_tls_cacert = /etc/ipa/ca.crt debug_level = 10 krb5_use_enterprise_principal = True [sssd] default_domain_suffix = corp.addomain.com services = nss, sudo, pam, ssh domains = ipa.ipadomain.local debug_level = 10 [nss] override_homedir = /home/%u debug_level = 10 [pam] debug_level = 10 [sudo] [autofs] [ssh] debug_level = 10 [pac] [ifp] ============================================== /var/log/sssd/krb5_child.log (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [main] (0x0400): krb5_child started. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [unpack_buffer] (0x1000): total buffer size: [63] (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [unpack_buffer] (0x0100): cmd [249] uid [1007629326] gid [1007629326] validate [true] enterprise principal [false] offline [true] UPN [Subaranchan.T at MYDOMAON.COM] (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [become_user] (0x0200): Trying to become user [1007629326][1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [main] (0x2000): Running as [1007629326][1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [become_user] (0x0200): Trying to become user [1007629326][1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [become_user] (0x0200): Already user [1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [k5c_setup] (0x2000): Running as [1007629326][1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [main] (0x0400): Will perform pre-auth (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MYDOMAON.COM] (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [sss_child_krb5_trace_cb] (0x4000): [16083] 1479465985.794345: Getting initial credentials for Subaranchan.T at MYDOMAON.COM (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [sss_child_krb5_trace_cb] (0x4000): [16083] 1479465985.796449: Sending request (176 bytes) to MYDOMAON.COM (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [sss_child_krb5_trace_cb] (0x4000): [16083] 1479465985.797433: Retrying AS request with master KDC (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [sss_child_krb5_trace_cb] (0x4000): [16083] 1479465985.797466: Getting initial credentials for Subaranchan.T at MYDOMAON.COM (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [sss_child_krb5_trace_cb] (0x4000): [16083] 1479465985.797508: Sending request (176 bytes) to MYDOMAON.COM (master) (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328230} during pre-auth. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [k5c_send_data] (0x0200): Received error code 0 (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [pack_response_packet] (0x2000): response packet size: [4] (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [k5c_send_data] (0x4000): Response sent. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16083]]]] [main] (0x0400): krb5_child completed successfully (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [main] (0x0400): krb5_child started. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [unpack_buffer] (0x1000): total buffer size: [168] (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [unpack_buffer] (0x0100): cmd [241] uid [1007629326] gid [1007629326] validate [true] enterprise principal [false] offline [true] UPN [Subaranchan.T at MYDOMAON.COM] (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1007629326] old_ccname: [KEYRING:persistent:1007629326] keytab: [/etc/krb5.keytab] (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [switch_creds] (0x0200): Switch user to [1007629326][1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1007629326] and is active and TGT is valid. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [become_user] (0x0200): Trying to become user [1007629326][1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [main] (0x2000): Running as [1007629326][1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [become_user] (0x0200): Trying to become user [1007629326][1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [become_user] (0x0200): Already user [1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [k5c_setup] (0x2000): Running as [1007629326][1007629326]. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [main] (0x0400): Will perform offline auth (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [k5c_send_data] (0x0200): Received error code 0 (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [pack_response_packet] (0x2000): response packet size: [53] (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [k5c_send_data] (0x4000): Response sent. (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [main] (0x0400): krb5_child completed successfully (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [main] (0x0400): krb5_child started. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [unpack_buffer] (0x1000): total buffer size: [63] (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [unpack_buffer] (0x0100): cmd [249] uid [1007629326] gid [1007629326] validate [true] enterprise principal [false] offline [true] UPN [Subaranchan.T at MYDOMAON.COM] (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [become_user] (0x0200): Trying to become user [1007629326][1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [main] (0x2000): Running as [1007629326][1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [become_user] (0x0200): Trying to become user [1007629326][1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [become_user] (0x0200): Already user [1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [k5c_setup] (0x2000): Running as [1007629326][1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [main] (0x0400): Will perform pre-auth (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [MYDOMAON.COM] (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [sss_child_krb5_trace_cb] (0x4000): [16085] 1479465990.426010: Getting initial credentials for Subaranchan.T at MYDOMAON.COM (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [sss_child_krb5_trace_cb] (0x4000): [16085] 1479465990.428093: Sending request (176 bytes) to MYDOMAON.COM (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [sss_child_krb5_trace_cb] (0x4000): [16085] 1479465990.429220: Retrying AS request with master KDC (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [sss_child_krb5_trace_cb] (0x4000): [16085] 1479465990.429257: Getting initial credentials for Subaranchan.T at MYDOMAON.COM (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [sss_child_krb5_trace_cb] (0x4000): [16085] 1479465990.429319: Sending request (176 bytes) to MYDOMAON.COM (master) (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328230} during pre-auth. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [k5c_send_data] (0x0200): Received error code 0 (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [pack_response_packet] (0x2000): response packet size: [4] (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [k5c_send_data] (0x4000): Response sent. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16085]]]] [main] (0x0400): krb5_child completed successfully (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [main] (0x0400): krb5_child started. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [unpack_buffer] (0x1000): total buffer size: [168] (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [unpack_buffer] (0x0100): cmd [241] uid [1007629326] gid [1007629326] validate [true] enterprise principal [false] offline [true] UPN [Subaranchan.T at MYDOMAON.COM] (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1007629326] old_ccname: [KEYRING:persistent:1007629326] keytab: [/etc/krb5.keytab] (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [switch_creds] (0x0200): Switch user to [1007629326][1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1007629326] and is active and TGT is valid. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [become_user] (0x0200): Trying to become user [1007629326][1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [main] (0x2000): Running as [1007629326][1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [become_user] (0x0200): Trying to become user [1007629326][1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [become_user] (0x0200): Already user [1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [k5c_setup] (0x2000): Running as [1007629326][1007629326]. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [main] (0x0400): Will perform offline auth (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [k5c_send_data] (0x0200): Received error code 0 (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [pack_response_packet] (0x2000): response packet size: [53] (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [k5c_send_data] (0x4000): Response sent. (Fri Nov 18 11:46:30 2016) [[sssd[krb5_child[16086]]]] [main] (0x0400): krb5_child completed successfully /var/log/secure Nov 18 11:46:30 ilt-gif-ipa02 sshd[16060]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=st1985 Nov 18 11:46:30 ilt-gif-ipa02 sshd[16060]: pam_sss(sshd:auth): received for user st1985: 6 (Permission denied) Nov 18 11:46:30 ilt-gif-ipa02 sshd[16060]: Failed password for et33015 from x.x.x.x port 58568 ssh2 On Wed, Nov 16, 2016 at 2:31 PM, rajat gupta wrote: > Thanks, It is working for few user but not for every one. I have cleared > the sssd cache as well. > ===================== > /var/log/secure > > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=146.213.0.134 > user=kb1980 > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): received for > user kb1980: 6 (Permission denied) > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): getting > password (0x00000010) > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): > pam_get_item returned a password > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): internal > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'kb1980') > Nov 16 14:06:39 ipa-clinet1 sshd[6852]: Failed password for kb1980 from > 146.213.0.134 port 51114 ssh2 > Nov 16 14:06:48 ipa-clinet1 sshd[6852]: Connection closed by 146.213.0.134 > [preauth] > Nov 16 14:07:07 ipa-clinet1 sshd[3677]: pam_unix(sshd:session): session > closed for user kb1980 > > ======================== > krb5_child.log > > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [unpack_buffer] > (0x1000): total buffer size: [54] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [unpack_buffer] > (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [become_user] > (0x0200): Already user [1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_setup] > (0x2000): Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): > Will perform pre-auth > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN COM] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.872554: Getting > initial credentials for karan.b at MYDOMAIN COM > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.874607: Sending > request (167 bytes) to MYDOMAIN COM > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898179: Retrying AS > request with master KDC > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898221: Getting > initial credentials for karan.b at MYDOMAIN COM > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [sss_child_krb5_trace_cb] (0x4000): [6879] 1479301593.898291: Sending > request (167 bytes) to MYDOMAIN COM (master) > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [get_and_save_tgt] > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > pre-auth. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007628631] old_ccname: > [KEYRING:persistent:1007628631] keytab: [/etc/krb5.keytab] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [switch_creds] > (0x0200): Switch user to [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1007628631] > and is not active and TGT is valid. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [become_user] > (0x0200): Already user [1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_setup] > (0x2000): Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): > Will perform offline auth > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [create_empty_ccache] (0x1000): Existing ccache still valid, reusing > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] > [pack_response_packet] (0x2000): response packet size: [53] > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [unpack_buffer] > (0x1000): total buffer size: [54] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [unpack_buffer] > (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [become_user] > (0x0200): Already user [1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_setup] > (0x2000): Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): > Will perform pre-auth > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [MYDOMAIN COM] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.494908: Getting > initial credentials for karan.b at MYDOMAIN COM > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.496903: Sending > request (167 bytes) to MYDOMAIN COM > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.497962: Retrying AS > request with master KDC > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.497985: Getting > initial credentials for karan.b at MYDOMAIN COM > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [sss_child_krb5_trace_cb] (0x4000): [6881] 1479301599.498026: Sending > request (167 bytes) to MYDOMAIN COM (master) > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [get_and_save_tgt] > (0x0400): krb5_get_init_creds_password returned [-1765328230} during > pre-auth. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] > [pack_response_packet] (0x2000): response packet size: [4] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881]]]] [main] (0x0400): > krb5_child completed successfully > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): > krb5_child started. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > (0x1000): total buffer size: [159] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true] > enterprise principal [false] offline [true] UPN [karan.b at MYDOMAIN COM] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1007628631] old_ccname: > [KEYRING:persistent:1007628631] keytab: [/etc/krb5.keytab] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [switch_creds] > (0x0200): Switch user to [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1007628631] > and is not active and TGT is valid. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x2000): > Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] > (0x0200): Trying to become user [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [become_user] > (0x0200): Already user [1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_setup] > (0x2000): Running as [1007628631][1007628631]. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): > Will perform offline auth > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [create_empty_ccache] (0x1000): Existing ccache still valid, reusing > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] > [pack_response_packet] (0x2000): response packet size: [53] > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [k5c_send_data] > (0x4000): Response sent. > (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882]]]] [main] (0x0400): > krb5_child completed successfully > > On Wed, Nov 16, 2016 at 1:02 PM, wrote: > >> Send Freeipa-users mailing list submissions to >> freeipa-users at redhat.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.redhat.com/mailman/listinfo/freeipa-users >> or, via email, send a message with subject or body 'help' to >> freeipa-users-request at redhat.com >> >> You can reach the person managing the list at >> freeipa-users-owner at redhat.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Freeipa-users digest..." >> >> >> Today's Topics: >> >> 1. Client x.x.xx - RFC 1918 response from Internet in >> /var/log/messages (Bjarne Blichfeldt) >> 2. Re: pam_winbind(sshd:auth): pam_get_item returned a password >> (Sumit Bose) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 16 Nov 2016 11:56:05 +0000 >> From: Bjarne Blichfeldt >> To: "freeipa-users at redhat.com" >> Subject: [Freeipa-users] Client x.x.xx - RFC 1918 response from >> Internet in /var/log/messages >> Message-ID: >> <89213DDB84447F44A8E8950A5C2185E0482EB1EE at SJN01013.jnmain00. >> corp.jndata.net> >> >> Content-Type: text/plain; charset="us-ascii" >> >> Just updated a couple of free-ipa servers to: >> ipa-server-dns-4.4.0-12.el7.noarch >> redhat-release-server-7.3-7.el7.x86_64 >> >> Before the update, I resolved the issue with RFC messages by: >> /etc/named.conf: >> options { >> disable-empty-zone "10.in-addr.arpa."; >> : >> >> Now after the update the RFS messages has returned. I read in the >> changelog for 4.4 that this issue was resolved. >> What did I miss? >> >> >> >> >> >> >> Venlig hilsen >> >> >> Bjarne Blichfeldt >> >> >> Infrastructure Services >> >> >> >> Direkte +4563636119 >> >> >> Mobile +4521593270 >> >> >> BJB at jndata.dk >> >> [cid:image005.png at 01D24008.CA6EF0F0] >> >> JN Data A/S >> >> * >> >> Havsteensvej 4 >> >> * >> >> 4000 Roskilde >> >> >> Telefon 63 63 63 63/ Fax 63 63 63 64 >> >> >> www.jndata.dk >> >> >> [cid:image006.png at 01D24008.CA6EF0F0] >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: > 20161116/46aeee39/attachment.html> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image005.png >> Type: image/png >> Size: 410 bytes >> Desc: image005.png >> URL: > 20161116/46aeee39/attachment.png> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image006.png >> Type: image/png >> Size: 5487 bytes >> Desc: image006.png >> URL: > 20161116/46aeee39/attachment-0001.png> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 16 Nov 2016 13:01:59 +0100 >> From: Sumit Bose >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item >> returned a password >> Message-ID: >> <20161116120159.GL28171 at p.Speedport_W_724V_Typ_A_05011603_00_009> >> Content-Type: text/plain; charset=us-ascii >> >> On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote: >> > I am using FreeIPA version 4.4.0 Active Directory trust setup. And on >> > Active Directory side I am using UPN suffix. >> > Following are my domain setup. >> > >> > AD DOMANIN :- corp.addomain.com >> > UPN suffix :- username at mydomain.com >> > IPA DOMAIN :- ipa.ipadomain.local >> > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local >> >> When you call 'ipa trust-find' on the IPA server do you see the >> mydomain.com UPN suffix listed, like e.g.: >> >> # ipa trust-find >> --------------- >> 1 trust matched >> --------------- >> Realm-Name: ad.devel >> Domain NetBIOS name: AD >> Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199 >> Trust type: Active Directory domain >> UPN suffixes: alt.alt, alt.upn.suffix >> >> SSSD 1.14 and above on the IPA client should enable enterprise principal >> support automatically if UPN suffixes are found on the server but >> according to >> >> (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] >> enterprise principal [false] offline [false] UPN [ >> Rajat.Gupta at MYDOMAIN.COM] >> >> it is not. If the UPN suffixes are not know on the server, calling 'ipa >> trust-fetch-domains' might help to get them. If there are still no UPN >> suffixes >> available on the server you can switch on enterprise principal on the >> client >> manually by adding 'krb5_use_enterprise_principal = True' in the >> [domain/...] >> section of sssd.conf. You have to set it manually as well if you are using >> older versions of SSSD. >> >> HTH >> >> bye, >> Sumit >> >> > >> > >> > I am able to login with AD user on IPA server. But on IPA clinet i am >> not >> > able to login i am getting the login message "Access denied". I have >> > enabled the debug_level on sssd.conf on ipa clinet. >> > >> > below are some logs.. >> > ================ >> > /var/log/secure >> > >> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): >> authentication >> > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989 >> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received for >> > user e600336: 6 (Permission denied) >> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting >> > password (0x00000010) >> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): >> > pam_get_item returned a password >> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): internal >> > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989') >> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 from >> > x.x.x.x. port 48842 ssh2 >> > ================ >> > >> > ================ >> > krb5_child.log >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [k5c_send_data] >> > (0x4000): Response sent. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836]]]] [main] (0x0400): >> > krb5_child completed successfully >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): >> > krb5_child started. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] >> > (0x1000): total buffer size: [159] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] >> > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] >> > enterprise principal [false] offline [false] UPN [ >> Rajat.Gupta at MYDOMAIN.COM] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [unpack_buffer] >> > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: >> > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] >> > (0x0200): Switch user to [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [switch_creds] >> > (0x0200): Switch user to [0][0]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [k5c_check_old_ccache] (0x4000): Ccache_file is >> > [KEYRING:persistent:1007656917] and is not active and TGT is valid. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [k5c_precreate_ccache] (0x4000): Recreating ccache >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup_fast] >> > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to >> > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [find_principal_in_keytab] (0x4000): Trying to find principal >> > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [match_principal] >> > (0x1000): Principal matched to the sample >> > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> [check_fast_ccache] >> > (0x0200): FAST TGT is still valid. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [become_user] >> > (0x0200): Trying to become user [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x2000): >> > Running as [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_setup] >> (0x2000): >> > Running as [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [set_lifetime_options] (0x0100): Cannot read >> [SSSD_KRB5_RENEWABLE_LIFETIME] >> > from environment. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from >> > environment. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to >> [true] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): >> Will >> > perform online auth >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [tgt_req_child] >> > (0x1000): Attempting to get a TGT >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] >> > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.416687: Getting >> > initial credentials for Rajat.Gupta at MYDOMAIN.COM >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418641: FAST armor >> > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418698: Retrieving >> > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> >> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM >> > \@MYDOMAIN.COM at X-CACHECONF: from >> > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: >> > -1765328243/Matching credential not found >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.418756: Sending >> > request (164 bytes) to MYDOMAIN.COM >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419718: Retrying >> AS >> > request with master KDC >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419752: Getting >> > initial credentials for Rajat.Gupta at MYDOMAIN.COM >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419778: FAST armor >> > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419821: Retrieving >> > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> >> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM >> > \@MYDOMAIN.COM at X-CACHECONF: from >> > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: >> > -1765328243/Matching credential not found >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4837] 1479283764.419859: Sending >> > request (164 bytes) to MYDOMAIN.COM (master) >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [get_and_save_tgt] >> > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [map_krb5_error] >> > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] >> > (0x0200): Received error code 1432158228 >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] >> > [pack_response_packet] (0x2000): response packet size: [4] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [k5c_send_data] >> > (0x4000): Response sent. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837]]]] [main] (0x0400): >> > krb5_child completed successfully >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): >> > krb5_child started. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] >> > (0x1000): total buffer size: [159] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] >> > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] >> > enterprise principal [false] offline [false] UPN [ >> Rajat.Gupta at MYDOMAIN.COM] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [unpack_buffer] >> > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: >> > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] >> > (0x0200): Switch user to [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [switch_creds] >> > (0x0200): Switch user to [0][0]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [k5c_check_old_ccache] (0x4000): Ccache_file is >> > [KEYRING:persistent:1007656917] and is not active and TGT is valid. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [k5c_precreate_ccache] (0x4000): Recreating ccache >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup_fast] >> > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to >> > [host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [find_principal_in_keytab] (0x4000): Trying to find principal >> > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL in keytab. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [match_principal] >> > (0x1000): Principal matched to the sample >> > (host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL). >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> [check_fast_ccache] >> > (0x0200): FAST TGT is still valid. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [become_user] >> > (0x0200): Trying to become user [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x2000): >> > Running as [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_setup] >> (0x2000): >> > Running as [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [set_lifetime_options] (0x0100): Cannot read >> [SSSD_KRB5_RENEWABLE_LIFETIME] >> > from environment. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from >> > environment. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to >> [true] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): >> Will >> > perform online auth >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [tgt_req_child] >> > (0x1000): Attempting to get a TGT >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] >> > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.426870: Getting >> > initial credentials for Rajat.Gupta at MYDOMAIN.COM >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428706: FAST armor >> > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428762: Retrieving >> > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> >> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM >> > \@MYDOMAIN.COM at X-CACHECONF: from >> > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: >> > -1765328243/Matching credential not found >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.428825: Sending >> > request (164 bytes) to MYDOMAIN.COM >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429706: Retrying >> AS >> > request with master KDC >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429740: Getting >> > initial credentials for Rajat.Gupta at MYDOMAIN.COM >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429767: FAST armor >> > ccache: MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429812: Retrieving >> > host/ipa-clinet1.ipa.ipadomain.local at IPA.IPADOMAIN.LOCAL -> >> > krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM >> > \@MYDOMAIN.COM at X-CACHECONF: from >> > MEMORY:/var/lib/sss/db/fast_ccache_IPA.IPADOMAIN.LOCAL with result: >> > -1765328243/Matching credential not found >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4838] 1479283764.429854: Sending >> > request (164 bytes) to MYDOMAIN.COM (master) >> > >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [get_and_save_tgt] >> > (0x0020): 1296: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [map_krb5_error] >> > (0x0020): 1365: [-1765328230][Cannot find KDC for realm "MYDOMAIN.COM"] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] >> > (0x0200): Received error code 1432158228 >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] >> > [pack_response_packet] (0x2000): response packet size: [4] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [k5c_send_data] >> > (0x4000): Response sent. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4838]]]] [main] (0x0400): >> > krb5_child completed successfully >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): >> > krb5_child started. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] >> > (0x1000): total buffer size: [159] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] >> > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] >> > enterprise principal [false] offline [true] UPN [ >> Rajat.Gupta at MYDOMAIN.COM] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [unpack_buffer] >> > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: >> > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] >> > (0x0200): Switch user to [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] >> > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [switch_creds] >> > (0x0200): Switch user to [0][0]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] >> > [k5c_check_old_ccache] (0x4000): Ccache_file is >> > [KEYRING:persistent:1007656917] and is not active and TGT is valid. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] >> > (0x0200): Trying to become user [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x2000): >> > Running as [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] >> > (0x0200): Trying to become user [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [become_user] >> > (0x0200): Already user [1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_setup] >> (0x2000): >> > Running as [1007656917][1007656917]. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] >> > [set_lifetime_options] (0x0100): Cannot read >> [SSSD_KRB5_RENEWABLE_LIFETIME] >> > from environment. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] >> > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from >> > environment. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): >> Will >> > perform offline auth >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] >> [create_empty_ccache] >> > (0x1000): Existing ccache still valid, reusing >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] >> > (0x0200): Received error code 0 >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] >> > [pack_response_packet] (0x2000): response packet size: [53] >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [k5c_send_data] >> > (0x4000): Response sent. >> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4839]]]] [main] (0x0400): >> > krb5_child completed successfully >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): >> > krb5_child started. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] >> > (0x1000): total buffer size: [52] >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [unpack_buffer] >> > (0x0100): cmd [249] uid [1007656917] gid [1007656917] validate [true] >> > enterprise principal [false] offline [true] UPN [ >> Rajat.Gupta at MYDOMAIN.COM] >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] >> > (0x0200): Trying to become user [1007656917][1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x2000): >> > Running as [1007656917][1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] >> > (0x0200): Trying to become user [1007656917][1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [become_user] >> > (0x0200): Already user [1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_setup] >> (0x2000): >> > Running as [1007656917][1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] >> > [set_lifetime_options] (0x0100): Cannot read >> [SSSD_KRB5_RENEWABLE_LIFETIME] >> > from environment. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] >> > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from >> > environment. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): >> Will >> > perform pre-auth >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [tgt_req_child] >> > (0x1000): Attempting to get a TGT >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] >> > (0x0400): Attempting kinit for realm [MYDOMAIN.COM] >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.766694: Getting >> > initial credentials for Rajat.Gupta at MYDOMAIN.COM >> > >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.769074: Sending >> > request (164 bytes) to MYDOMAIN.COM >> > >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770020: Retrying >> AS >> > request with master KDC >> > >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770051: Getting >> > initial credentials for Rajat.Gupta at MYDOMAIN.COM >> > >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] >> > [sss_child_krb5_trace_cb] (0x4000): [4840] 1479283767.770091: Sending >> > request (164 bytes) to MYDOMAIN.COM (master) >> > >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [get_and_save_tgt] >> > (0x0400): krb5_get_init_creds_password returned [-1765328230} during >> > pre-auth. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] >> > (0x0200): Received error code 0 >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] >> > [pack_response_packet] (0x2000): response packet size: [4] >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [k5c_send_data] >> > (0x4000): Response sent. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4840]]]] [main] (0x0400): >> > krb5_child completed successfully >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): >> > krb5_child started. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] >> > (0x1000): total buffer size: [160] >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] >> > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] >> > enterprise principal [false] offline [true] UPN [ >> Rajat.Gupta at MYDOMAIN.COM] >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [unpack_buffer] >> > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname: >> > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab] >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] >> > (0x0200): Switch user to [1007656917][1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] >> > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [switch_creds] >> > (0x0200): Switch user to [0][0]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] >> > [k5c_check_old_ccache] (0x4000): Ccache_file is >> > [KEYRING:persistent:1007656917] and is not active and TGT is valid. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] >> > (0x0200): Trying to become user [1007656917][1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x2000): >> > Running as [1007656917][1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] >> > (0x0200): Trying to become user [1007656917][1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [become_user] >> > (0x0200): Already user [1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_setup] >> (0x2000): >> > Running as [1007656917][1007656917]. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] >> > [set_lifetime_options] (0x0100): Cannot read >> [SSSD_KRB5_RENEWABLE_LIFETIME] >> > from environment. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] >> > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from >> > environment. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): >> Will >> > perform offline auth >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] >> [create_empty_ccache] >> > (0x1000): Existing ccache still valid, reusing >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] >> > (0x0200): Received error code 0 >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] >> > [pack_response_packet] (0x2000): response packet size: [53] >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [k5c_send_data] >> > (0x4000): Response sent. >> > (Wed Nov 16 09:09:27 2016) [[sssd[krb5_child[4841]]]] [main] (0x0400): >> > krb5_child completed successfully >> > >> > ======================= >> > Can you please help me to fix this, >> >> > -- >> > Manage your subscription for the Freeipa-users mailing list: >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > Go to http://freeipa.org for more info on the project >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> End of Freeipa-users Digest, Vol 100, Issue 48 >> ********************************************** >> > > > > -- > > *Rajat Gupta * > -- *Rajat Gupta * -------------- next part -------------- An HTML attachment was scrubbed... URL: From morgan at marodin.it Fri Nov 18 11:11:24 2016 From: morgan at marodin.it (Morgan Marodin) Date: Fri, 18 Nov 2016 12:11:24 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: <994f1c25-5c63-b0f0-1da4-6b4788331daf@redhat.com> References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> <994f1c25-5c63-b0f0-1da4-6b4788331daf@redhat.com> Message-ID: I've tried to add it to a new test folder, with a new certificate nickname, and then to replace it to *nss.conf*. But the problem persists: *# certutil -V -u V -d /etc/httpd/test -n ipa01certcertutil: certificate is valid* *# tail -f /var/log/httpd/error_log* *[Fri Nov 18 12:09:39.513833 2016] [suexec:notice] [pid 11552] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)[Fri Nov 18 12:09:39.514266 2016] [:warn] [pid 11552] NSSSessionCacheTimeout is deprecated. Ignoring.[Fri Nov 18 12:09:39.514299 2016] [:debug] [pid 11552] nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com -> ipa01cert[Fri Nov 18 12:09:39.824880 2016] [:error] [pid 11552] The server key database has not been initialized.[Fri Nov 18 12:09:39.832443 2016] [:info] [pid 11552] Configuring server for SSL protocol...[Fri Nov 18 12:09:39.832676 2016] [:info] [pid 11552] Using nickname ipa01cert.[Fri Nov 18 12:09:39.832678 2016] [:error] [pid 11552] Certificate not found: 'ipa01cert'* I've found this guide: *Combine the server cert and key into a single file# cp localhost.crt > Server-Cert.txt# cat localhost.key >> Server-Cert.txtConvert the server cert into a p12 file# openssl pkcs12 -export -in Server-Cert.txt -out Server-Cert.p12 -name "Server-Cert"Now Import the Public and Private keys into the database at the same time.#pk12util -i /tmp/cert-files/Server-Cert.p12 -d /etc/httpd/alias -n Server-Cert* Where is stored the key certificate file? Thanks, Morgan 2016-11-18 10:39 GMT+01:00 Florence Blanc-Renaud : > On 11/18/2016 10:04 AM, Morgan Marodin wrote: > >> Hi Florence. >> >> I've tried to configure the wrong certificate in nss.conf (/ipaCert/), >> and with this Apache started. >> So I think the problem is in the /Server-Cert/ stored in >> //etc/httpd/alias/, even if all manul checks are ok. >> >> These are logs with the wrong certificate test: >> /# tail -f /var/log/httpd/error_log/ >> /[Fri Nov 18 09:34:32.583700 2016] [suexec:notice] [pid 7709] AH01232: >> suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> [Fri Nov 18 09:34:32.584142 2016] [:warn] [pid 7709] >> NSSSessionCacheTimeout is deprecated. Ignoring. >> [Fri Nov 18 09:34:32.584178 2016] [:debug] [pid 7709] >> nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com >> -> ipaCert >> >> [Fri Nov 18 09:34:32.844487 2016] [:info] [pid 7709] Configuring server >> for SSL protocol >> [Fri Nov 18 09:34:32.844635 2016] [:debug] [pid 7709] >> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >> [Fri Nov 18 09:34:32.844657 2016] [:debug] [pid 7709] >> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >> [Fri Nov 18 09:34:32.844668 2016] [:debug] [pid 7709] >> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >> [Fri Nov 18 09:34:32.844677 2016] [:debug] [pid 7709] >> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >> [Fri Nov 18 09:34:32.844684 2016] [:debug] [pid 7709] >> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >> [Fri Nov 18 09:34:32.844738 2016] [:debug] [pid 7709] >> nss_engine_init.c(906): Disabling TLS Session Tickets >> [Fri Nov 18 09:34:32.844746 2016] [:debug] [pid 7709] >> nss_engine_init.c(916): Enabling DHE key exchange >> [Fri Nov 18 09:34:32.844760 2016] [:debug] [pid 7709] >> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >> ciphers >> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_ >> sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_ >> sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_ >> sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+ >> rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >> [Fri Nov 18 09:34:32.844825 2016] [:debug] [pid 7709] >> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >> ... >> [Fri Nov 18 09:34:32.845105 2016] [:debug] [pid 7709] >> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >> [Fri Nov 18 09:34:32.845110 2016] [:info] [pid 7709] Using nickname >> ipaCert. >> [Fri Nov 18 09:34:32.847451 2016] [:error] [pid 7709] Misconfiguration >> of certificate's CN and virtual name. The certificate CN has IPA RA. We >> expected mlv-ipa01.ipa.mydomain.com >> as virtual name. >> [Fri Nov 18 09:34:33.028056 2016] [auth_digest:notice] [pid 7709] >> AH01757: generating secret for digest authentication ... >> [Fri Nov 18 09:34:33.030039 2016] [lbmethod_heartbeat:notice] [pid 7709] >> AH02282: No slotmem from mod_heartmonitor >> [Fri Nov 18 09:34:33.030122 2016] [:warn] [pid 7709] >> NSSSessionCacheTimeout is deprecated. Ignoring. >> [Fri Nov 18 09:34:33.030176 2016] [:debug] [pid 7709] >> nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com >> -> ipaCert >> >> [Fri Nov 18 09:34:33.051481 2016] [mpm_prefork:notice] [pid 7709] >> AH00163: Apache/2.4.6 () mod_auth_gssapi/1.4.0 mod_auth_kerb/5.4 >> mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured >> -- resuming normal operations >> [Fri Nov 18 09:34:33.051551 2016] [core:notice] [pid 7709] AH00094: >> Command line: '/usr/sbin/httpd -D FOREGROUND' >> [Fri Nov 18 09:34:33.096050 2016] [proxy:debug] [pid 7717] >> proxy_util.c(1838): AH00924: worker ajp://localhost shared already >> initialized >> [Fri Nov 18 09:34:33.096163 2016] [proxy:debug] [pid 7717] >> proxy_util.c(1880): AH00926: worker ajp://localhost local already >> initialized >> ... >> [Fri Nov 18 09:34:33.105626 2016] [proxy:debug] [pid 7719] >> proxy_util.c(1838): AH00924: worker >> unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ shared already >> initialized >> [Fri Nov 18 09:34:33.105632 2016] [proxy:debug] [pid 7719] >> proxy_util.c(1880): AH00926: worker >> unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ local already >> initialized >> [Fri Nov 18 09:34:33.342762 2016] [:info] [pid 7717] Configuring server >> for SSL protocol >> [Fri Nov 18 09:34:33.342867 2016] [:debug] [pid 7717] >> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >> [Fri Nov 18 09:34:33.342880 2016] [:debug] [pid 7717] >> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >> [Fri Nov 18 09:34:33.342885 2016] [:debug] [pid 7717] >> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >> [Fri Nov 18 09:34:33.342890 2016] [:debug] [pid 7717] >> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >> [Fri Nov 18 09:34:33.342894 2016] [:debug] [pid 7717] >> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >> [Fri Nov 18 09:34:33.342900 2016] [:debug] [pid 7717] >> nss_engine_init.c(906): Disabling TLS Session Tickets >> [Fri Nov 18 09:34:33.342904 2016] [:debug] [pid 7717] >> nss_engine_init.c(916): Enabling DHE key exchange >> [Fri Nov 18 09:34:33.342917 2016] [:debug] [pid 7717] >> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >> ciphers >> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_ >> sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_ >> sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_ >> sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+ >> rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >> [Fri Nov 18 09:34:33.342970 2016] [:debug] [pid 7717] >> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >> ... >> [Fri Nov 18 09:34:33.343233 2016] [:debug] [pid 7717] >> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >> [Fri Nov 18 09:34:33.343237 2016] [:info] [pid 7717] Using nickname >> ipaCert. >> [Fri Nov 18 09:34:33.344533 2016] [:error] [pid 7717] Misconfiguration >> of certificate's CN and virtual name. The certificate CN has IPA RA. We >> expected mlv-ipa01.ipa.mydomain.com >> >> as virtual name. >> [Fri Nov 18 09:34:33.364061 2016] [:info] [pid 7718] Configuring server >> for SSL protocol >> [Fri Nov 18 09:34:33.364156 2016] [:debug] [pid 7718] >> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >> [Fri Nov 18 09:34:33.364167 2016] [:debug] [pid 7718] >> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >> [Fri Nov 18 09:34:33.364172 2016] [:debug] [pid 7718] >> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >> [Fri Nov 18 09:34:33.364176 2016] [:debug] [pid 7718] >> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >> [Fri Nov 18 09:34:33.364180 2016] [:debug] [pid 7718] >> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >> [Fri Nov 18 09:34:33.364187 2016] [:debug] [pid 7718] >> nss_engine_init.c(906): Disabling TLS Session Tickets >> [Fri Nov 18 09:34:33.364191 2016] [:debug] [pid 7718] >> nss_engine_init.c(916): Enabling DHE key exchange >> [Fri Nov 18 09:34:33.364202 2016] [:debug] [pid 7718] >> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >> ciphers >> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_ >> sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_ >> sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_ >> sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+ >> rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >> [Fri Nov 18 09:34:33.364240 2016] [:debug] [pid 7718] >> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >> ... >> [Fri Nov 18 09:34:33.364611 2016] [:debug] [pid 7718] >> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >> [Fri Nov 18 09:34:33.364625 2016] [:info] [pid 7718] Using nickname >> ipaCert. >> [Fri Nov 18 09:34:33.365549 2016] [:error] [pid 7718] Misconfiguration >> of certificate's CN and virtual name. The certificate CN has IPA RA. We >> expected mlv-ipa01.ipa.mydomain.com >> >> as virtual name. >> [Fri Nov 18 09:34:33.369972 2016] [:info] [pid 7720] Configuring server >> for SSL protocol >> [Fri Nov 18 09:34:33.370200 2016] [:debug] [pid 7720] >> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >> [Fri Nov 18 09:34:33.370224 2016] [:debug] [pid 7720] >> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >> [Fri Nov 18 09:34:33.370239 2016] [:debug] [pid 7720] >> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >> [Fri Nov 18 09:34:33.370255 2016] [:debug] [pid 7720] >> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >> [Fri Nov 18 09:34:33.370269 2016] [:debug] [pid 7720] >> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >> [Fri Nov 18 09:34:33.370286 2016] [:debug] [pid 7720] >> nss_engine_init.c(906): Disabling TLS Session Tickets >> [Fri Nov 18 09:34:33.370301 2016] [:debug] [pid 7720] >> nss_engine_init.c(916): Enabling DHE key exchange >> [Fri Nov 18 09:34:33.370322 2016] [:debug] [pid 7720] >> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >> ciphers >> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_ >> sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_ >> sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_ >> sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+ >> rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >> [Fri Nov 18 09:34:33.370383 2016] [:debug] [pid 7720] >> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >> ... >> [Fri Nov 18 09:34:33.371418 2016] [:debug] [pid 7720] >> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >> [Fri Nov 18 09:34:33.371437 2016] [:info] [pid 7720] Using nickname >> ipaCert. >> [Fri Nov 18 09:34:33.371486 2016] [:info] [pid 7716] Configuring server >> for SSL protocol >> [Fri Nov 18 09:34:33.372383 2016] [:debug] [pid 7716] >> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >> [Fri Nov 18 09:34:33.372439 2016] [:debug] [pid 7716] >> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >> [Fri Nov 18 09:34:33.372459 2016] [:debug] [pid 7716] >> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >> [Fri Nov 18 09:34:33.372484 2016] [:debug] [pid 7716] >> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >> [Fri Nov 18 09:34:33.372513 2016] [:debug] [pid 7716] >> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >> [Fri Nov 18 09:34:33.372534 2016] [:debug] [pid 7716] >> nss_engine_init.c(906): Disabling TLS Session Tickets >> [Fri Nov 18 09:34:33.372553 2016] [:debug] [pid 7716] >> nss_engine_init.c(916): Enabling DHE key exchange >> [Fri Nov 18 09:34:33.372580 2016] [:debug] [pid 7716] >> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >> ciphers >> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_ >> sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_ >> sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_ >> sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+ >> rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >> [Fri Nov 18 09:34:33.372627 2016] [:debug] [pid 7716] >> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >> ... >> [Fri Nov 18 09:34:33.373712 2016] [:debug] [pid 7716] >> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >> [Fri Nov 18 09:34:33.373734 2016] [:info] [pid 7716] Using nickname >> ipaCert. >> [Fri Nov 18 09:34:33.374652 2016] [:error] [pid 7716] Misconfiguration >> of certificate's CN and virtual name. The certificate CN has IPA RA. We >> expected mlv-ipa01.ipa.mydomain.com >> as virtual name. >> [Fri Nov 18 09:34:33.372295 2016] [:error] [pid 7720] Misconfiguration >> of certificate's CN and virtual name. The certificate CN has IPA RA. We >> expected mlv-ipa01.ipa.mydomain.com >> >> as virtual name. >> [Fri Nov 18 09:34:33.412689 2016] [:info] [pid 7719] Configuring server >> for SSL protocol >> [Fri Nov 18 09:34:33.412791 2016] [:debug] [pid 7719] >> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >> [Fri Nov 18 09:34:33.412803 2016] [:debug] [pid 7719] >> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >> [Fri Nov 18 09:34:33.412807 2016] [:debug] [pid 7719] >> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >> [Fri Nov 18 09:34:33.412812 2016] [:debug] [pid 7719] >> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >> [Fri Nov 18 09:34:33.412817 2016] [:debug] [pid 7719] >> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >> [Fri Nov 18 09:34:33.412824 2016] [:debug] [pid 7719] >> nss_engine_init.c(906): Disabling TLS Session Tickets >> [Fri Nov 18 09:34:33.412828 2016] [:debug] [pid 7719] >> nss_engine_init.c(916): Enabling DHE key exchange >> [Fri Nov 18 09:34:33.412840 2016] [:debug] [pid 7719] >> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >> ciphers >> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_ >> sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_ >> sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_ >> sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+ >> rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >> [Fri Nov 18 09:34:33.412891 2016] [:debug] [pid 7719] >> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >> ... >> [Fri Nov 18 09:34:33.413159 2016] [:debug] [pid 7719] >> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >> [Fri Nov 18 09:34:33.413164 2016] [:info] [pid 7719] Using nickname >> ipaCert. >> [Fri Nov 18 09:34:33.414462 2016] [:error] [pid 7719] Misconfiguration >> of certificate's CN and virtual name. The certificate CN has IPA RA. We >> expected mlv-ipa01.ipa.mydomain.com >> as virtual name. >> [Fri Nov 18 09:34:35.558286 2016] [:error] [pid 7715] ipa: WARNING: >> session memcached servers not running >> [Fri Nov 18 09:34:35.559653 2016] [:error] [pid 7714] ipa: WARNING: >> session memcached servers not running >> [Fri Nov 18 09:34:37.511457 2016] [:error] [pid 7714] ipa: INFO: *** >> PROCESS START *** >> [Fri Nov 18 09:34:37.517899 2016] [:error] [pid 7715] ipa: INFO: *** >> PROCESS START *** >> [Fri Nov 18 09:34:51.498536 2016] [:info] [pid 7717] Connection to child >> 1 established (server mlv-ipa01.ipa.mydomain.com >> , client 192.168.0.239) >> [Fri Nov 18 09:34:51.510292 2016] [:info] [pid 7717] SSL input filter >> read failed. >> [Fri Nov 18 09:34:51.510311 2016] [:error] [pid 7717] SSL Library Error: >> -12285 Unable to find the certificate or key necessary for authentication >> [Fri Nov 18 09:34:51.510356 2016] [:info] [pid 7717] Connection to child >> 1 closed (server mlv-ipa01.ipa.mydomain.com:443 >> , client 192.168.0.239) >> [Fri Nov 18 09:35:18.790760 2016] [mpm_prefork:notice] [pid 7709] >> AH00170: caught SIGWINCH, shutting down gracefully/ >> >> Is possible to delete /Server-Cert/ from //etc/httpd/alias/ and reimport >> it from the original certificates of /mlv-ipa01.ipa.mydomain.com >> /? >> Where are stored the original certificates? >> >> Hi Morgan, > > with ldapsearch you should be able to find the certificate: > ldapsearch -h ipaserver.ipadomain -p 389 -D "cn=directory manager" -w > password -LLL -b krbprincipalname=HTTP/ipaserver.ipadomain at IPADOMAIN,cn= > services,cn=accounts,dc=IPADOMAIN > > The cert will be stored in the field "usercertificate". > > HTH, > Flo. > > Please let me know, thanks. >> Bye, Morgan >> >> 2016-11-17 17:09 GMT+01:00 Florence Blanc-Renaud > >: >> >> >> On 11/17/2016 04:51 PM, Morgan Marodin wrote: >> >> Hi Rob. >> >> I've just tried to remove the group write to the *.db files, but >> it's >> not the problem. >> /[root at mlv-ipa01 ~]# grep NSSNickname /etc/httpd/conf.d/nss.conf >> NSSNickname Server-Cert/ >> >> I've tried to run manually /dirsrv.target/ and >> /krb5kdc.service/, and it >> works, services went up. >> The same for /ntpd/, /named-pkcs11.service/, /smb.service/, >> /winbind.service/, /kadmin.service/, /memcached.service/ and >> /pki-tomcatd.target/. >> >> But if I try to start /httpd.service/: >> /[root at mlv-ipa01 ~]# tail -f /var/log/messages >> Nov 17 16:46:06 mlv-ipa01 systemd[1]: Starting The Apache HTTP >> Server... >> Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: ipa : >> INFO KDC >> proxy enabled >> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: main process >> exited, code=exited, status=1/FAILURE >> Nov 17 16:46:07 mlv-ipa01 kill: kill: cannot find process "" >> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: control >> process >> exited, code=exited status=1 >> Nov 17 16:46:07 mlv-ipa01 systemd[1]: Failed to start The Apache >> HTTP >> Server. >> Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit httpd.service entered >> failed >> state. >> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service failed./ >> >> Any other ideas? >> >> Hi, >> >> - Does the NSS Db contain the private key for Server-Cert? If yes, >> the command >> $ certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt >> should display a line like this one: >> < 0> rsa 01a6cbd773f3d785ffa44233148dcb8ade266ea5 NSS >> Certificate DB:Server-Cert >> >> - Is your system running with SElinux enforcing? If yes, you can >> check if there were SElinux permission denials using >> $ ausearch -m avc --start recent >> >> - If the certificate was expired, I believe you would see a >> different message, but it doesn't hurt to check its validity >> $ certutil -L -d /etc/httpd/alias/ -n Server-Cert | egrep "Not >> Before|Not After" >> >> >> Flo. >> >> >> Please let me know, thanks. >> Morgan >> >> 2016-11-17 16:11 GMT+01:00 Rob Crittenden > >> >>: >> >> >> >> Morgan Marodin wrote: >> > Hi Florence. >> > >> > Thanks for your support. >> > >> > Yes, httpd is using /etc/httpd/alias as NSS DB. And seems >> that all >> > permissions and certificates are good: >> > /[root at mlv-ipa01 ~]# ls -l /etc/httpd/alias/ >> > total 184 >> > -r--r--r-- 1 root root 1345 Sep 7 2015 cacert.asc >> > -rw-rw---- 1 root apache 65536 Nov 17 11:06 cert8.db >> > -rw-r-----. 1 root apache 65536 Sep 4 2015 cert8.db.orig >> > -rw-------. 1 root root 4833 Sep 4 2015 install.log >> > -rw-rw---- 1 root apache 16384 Nov 17 11:06 key3.db >> > -rw-r-----. 1 root apache 16384 Sep 4 2015 key3.db.orig >> > lrwxrwxrwx 1 root root 24 Nov 17 10:24 libnssckbi.so >> -> >> > /usr/lib64/libnssckbi.so >> > -rw-rw---- 1 root apache 20 Sep 7 2015 pwdfile.txt >> > -rw-rw---- 1 root apache 16384 Sep 7 2015 secmod.db >> > -rw-r-----. 1 root apache 16384 Sep 4 2015 secmod.db.orig/ >> >> Eventually you'll want to remove group write on the *.db >> files. >> >> > And password validations seems ok, too: >> > /[root at mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f >> > /etc/httpd/alias/pwdfile.txt >> good >> >> > Enabling mod-nss debug I can see these logs: >> > /[root at mlv-ipa01 ~]# tail -f /var/log/httpd/error_log >> > [Thu Nov 17 15:05:10.807603 2016] [suexec:notice] [pid >> 10660] AH01232: >> > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> > [Thu Nov 17 15:05:10.807958 2016] [:warn] [pid 10660] >> > NSSSessionCacheTimeout is deprecated. Ignoring. >> > [Thu Nov 17 15:05:10.807991 2016] [:debug] [pid 10660] >> > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com >> >> > > >> > > >> >> > >> -> Server-Cert >> > [Thu Nov 17 15:05:11.002664 2016] [:info] [pid 10660] >> Configuring server >> > for SSL protocol >> > [Thu Nov 17 15:05:11.002817 2016] [:debug] [pid 10660] >> > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >> > [Thu Nov 17 15:05:11.002838 2016] [:debug] [pid 10660] >> > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >> > [Thu Nov 17 15:05:11.002847 2016] [:debug] [pid 10660] >> > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >> > [Thu Nov 17 15:05:11.002856 2016] [:debug] [pid 10660] >> > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >> > [Thu Nov 17 15:05:11.002876 2016] [:debug] [pid 10660] >> > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >> > [Thu Nov 17 15:05:11.003099 2016] [:debug] [pid 10660] >> > nss_engine_init.c(906): Disabling TLS Session Tickets >> > [Thu Nov 17 15:05:11.003198 2016] [:debug] [pid 10660] >> > nss_engine_init.c(916): Enabling DHE key exchange >> > [Thu Nov 17 15:05:11.003313 2016] [:debug] [pid 10660] >> > nss_engine_init.c(1077): NSSCipherSuite: Configuring >> permitted SSL >> > ciphers >> > >> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_ >> sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_ >> sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_ >> sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+ >> rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >> > [Thu Nov 17 15:05:11.003469 2016] [:debug] [pid 10660] >> > [Thu Nov 17 15:05:11.006759 2016] [:info] [pid 10660] >> Using nickname >> > Server-Cert. >> [snip] >> > [Thu Nov 17 15:05:11.006771 2016] [:error] [pid 10660] >> Certificate not >> > found: 'Server-Cert' >> >> Can you shows what this returns: >> >> # grep NSSNickname /etc/httpd/conf.d/nss.conf >> >> > Do you think there is a kerberos problem? >> >> It definitely is not. >> >> You can bring the system up in a minimal way by manually >> starting the >> dirsrv at EXAMPLE.COM >> > service >> >> and then >> krb5kdc. This will at least let your >> users authenticate. The management framework (GUI) runs >> through Apache >> so that will be down until we can get Apache started again. >> >> rob >> >> > >> > Please let me know, thanks. >> > Bye, Morgan >> > >> > 2016-11-17 14:39 GMT+01:00 Florence Blanc-Renaud >> > > >> > >> >>>: >> >> > >> > On 11/17/2016 12:09 PM, Morgan Marodin wrote: >> > >> > Hello. >> > >> > This morning I've tried to upgrade my IPA server, >> but the >> upgrade >> > failed, and now the service doesn't start! :( >> > >> > If I try lo launch the upgrade manually this is >> the output: >> > /[root at mlv-ipa01 download]# 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 >> > [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 >> > 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: >> > CalledProcessError: Command '/bin/systemctl start >> httpd.service' >> > returned non-zero exit status 1 >> > The ipa-server-upgrade command failed. See >> > /var/log/ipaupgrade.log for >> > more information/ >> > >> > These are error logs of Apache: >> > /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] >> [pid 5664] >> > AH01232: >> > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> > [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid 5664] >> > NSSSessionCacheTimeout is deprecated. Ignoring. >> > [Thu Nov 17 11:48:45.830910 2016] [:error] [pid >> 5664] >> > Certificate not >> > found: 'Server-Cert'/ >> > >> > The problem seems to be the /Server-Cert /that >> could not >> be found. >> > But if I try to execute the certutil command >> manually I >> can see it:/ >> > [root at mlv-ipa01 log]# certutil -L -d >> /etc/httpd/alias/ >> > Certificate Nickname >> Trust >> > Attributes >> > >> > SSL,S/MIME,JAR/XPI >> > Signing-Cert >> u,u,u >> > ipaCert >> u,u,u >> > Server-Cert >> Pu,u,u >> > IPA.MYDOMAIN.COM >> >> >> > IPA >> > CA CT,C,C/ >> > >> > Could you help me? >> > What could I try to do to restart my service? >> > >> > Hi, >> > >> > I would first make sure that httpd is using >> /etc/httpd/alias >> as NSS >> > DB (check the directive NSSCertificateDatabase in >> > /etc/httpd/conf.d/nss.conf). >> > Then it may be a file permission issue: the NSS DB >> should >> belong to >> > root:apache (the relevant files are cert8.db, key3.db >> and >> secmod.db). >> > You should also find a pwdfile.txt in the same >> directory, >> containing >> > the NSS DB password. Check that the password is valid >> using >> > certutil -K -d /etc/httpd/alias/ -f >> /etc/httpd/alias/pwdfile.txt >> > (if the command succeeds then the password in pwdfile >> is OK). >> > >> > You can also enable mod-nss debug in >> /etc/httpd/conf/nss.conf by >> > setting "LogLevel debug", and check the output in >> > /var/log/httpd/error_log. >> > >> > HTH, >> > Flo. >> > >> > Thanks, Morgan >> > >> > >> > >> > -- >> > 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 sbose at redhat.com Fri Nov 18 13:02:15 2016 From: sbose at redhat.com (Sumit Bose) Date: Fri, 18 Nov 2016 14:02:15 +0100 Subject: [Freeipa-users] Freeipa-users Digest, Vol 100, Issue 48 In-Reply-To: References: Message-ID: <20161118130215.GX28171@p.Speedport_W_724V_Typ_A_05011603_00_009> On Fri, Nov 18, 2016 at 12:09:41PM +0100, rajat gupta wrote: > Hi, > > > I removed the pam_winbind module. User are able to login now. But some time > they are not. Below are logs when user are not able to login. Also SSH see comment at the end of the email. > login is very slow for AD user. I am using sssd 1.4 Please note that SSSD does more than a simple kinit, it will validate the returned TGT of the user by requesting a service ticket for a service form the local keytab. This requires for AD users at least one round trip to an AD DC and another one to the IPA server. If the AD user is coming from a member domain in the AD forest and not from the forest root there are even more round trips. > ============================= > rpm -qa | grep sssd > sssd-krb5-common-1.14.0-43.el7.x86_64 > python-sssdconfig-1.14.0-43.el7.noarch > sssd-ldap-1.14.0-43.el7.x86_64 > sssd-client-1.14.0-43.el7.x86_64 > sssd-ipa-1.14.0-43.el7.x86_64 > sssd-proxy-1.14.0-43.el7.x86_64 > sssd-common-1.14.0-43.el7.x86_64 > sssd-ad-1.14.0-43.el7.x86_64 > sssd-1.14.0-43.el7.x86_64 > sssd-krb5-1.14.0-43.el7.x86_64 > sssd-common-pac-1.14.0-43.el7.x86_64 > =========================== > > ===================================== > My sssd.conf on ipa clinet > > cat /etc/sssd/sssd.conf > [domain/ipa.preprod.local] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = ipa.ipadomain.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = ilt-gif-ipa02.ipa.ipadomain.local > chpass_provider = ipa > ipa_server = _srv_, ilt-gif-ipa01.ipa.ipadomain.local > ldap_tls_cacert = /etc/ipa/ca.crt > debug_level = 10 > krb5_use_enterprise_principal = True > > > > [sssd] > default_domain_suffix = corp.addomain.com > services = nss, sudo, pam, ssh > > domains = ipa.ipadomain.local > debug_level = 10 > > [nss] > override_homedir = /home/%u > debug_level = 10 > > > > [pam] > debug_level = 10 > > > [sudo] > > [autofs] > > [ssh] > debug_level = 10 > > > [pac] > > [ifp] > ============================================== > > > ... > (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [main] (0x0400): > krb5_child started. > (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [unpack_buffer] > (0x1000): total buffer size: [168] > (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1007629326] gid [1007629326] validate [true] > enterprise principal [false] offline [true] UPN [Subaranchan.T at MYDOMAON.COM] SSSD is in offline mode again, if the user never successfully login in with a password authentication will fail. You should check the SSSD domain log to figure out why SSSD switches into offline mode. HTH bye, Sumit From deepak.dimri2016 at gmail.com Fri Nov 18 13:45:47 2016 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Fri, 18 Nov 2016 19:15:47 +0530 Subject: [Freeipa-users] Getting "Your session has expired. Please re-login." when trying to access IPA Replica Message-ID: Hello All, I have IPA Master deployed in AWS US West region and replica in US East region. The replication installation went successfully however when i am trying to access the replication web UI (after making proxypass changes etc..) i am getting Error. I have ProxyPassReverseCookieDomain set correctly but still i get the error. Master & Replica are time synchronized. Can come please help me with this? I have tried it in all kinds of browser but no luck. i have followed this document in setting up the reverse proxy https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name. Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbaird at follett.com Fri Nov 18 14:21:25 2016 From: jbaird at follett.com (Baird, Josh) Date: Fri, 18 Nov 2016 14:21:25 +0000 Subject: [Freeipa-users] IPA 4.4 replica installation failing In-Reply-To: <49417871-e251-9be8-9a4e-68ef65a7b034@redhat.com> References: <49417871-e251-9be8-9a4e-68ef65a7b034@redhat.com> Message-ID: Martin, Yes, this is the exact scenario. My lab started with a RHEL 7.2 master/replica with 'domain level' set to 0. I raised the 'domain level' to 1, and now I'm trying to introduce a new replica into the environment. I will check on 'nsds5replicabinddn' and report back. Thanks, Josh -----Original Message----- From: Martin Babinsky [mailto:mbabinsk at redhat.com] Sent: Friday, November 18, 2016 3:17 AM To: Baird, Josh ; 'freeipa-users at redhat.com' Subject: Re: [Freeipa-users] IPA 4.4 replica installation failing On 11/17/2016 03:51 PM, Baird, Josh wrote: > Hi all, > > In my IPA 4.4 lab (RHEL 7.3), I'm trying to install/configure a new replica, and I seem to be hitting something similar to #5412 [1]. > > The 'ipa-replica-install' is getting stuck on: > > [4/26]: creating installation admin user > > Dirsrv error logs on the new replica: > > [17/Nov/2016:08:45:09.342813042 -0600] NSMMReplicationPlugin - agmt="cn=caToimqa-d1-dc01.qa-unix.domain.com" (imqa-d1-dc01:389): Unable to acquire replica: permission denied. The bind dn "" does not have permission to supply replication updates to the replica. Will retry later. > > Dirsrv access logs on existing master: > > [17/Nov/2016:08:39:59.244698389 -0600] conn=121 op=83 RESULT err=0 > tag=101 nentries=0 etime=0 > [17/Nov/2016:08:40:00.248620354 -0600] conn=121 op=84 SRCH > base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" > scope=0 filter="(objectClass=*)" attrs=ALL > [17/Nov/2016:08:40:00.248917257 -0600] conn=121 op=84 RESULT err=0 > tag=101 nentries=0 etime=0 > [17/Nov/2016:08:40:01.253067200 -0600] conn=121 op=85 SRCH > base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" > scope=0 filter="(objectClass=*)" attrs=ALL > [17/Nov/2016:08:40:01.253481728 -0600] conn=121 op=85 RESULT err=0 > tag=101 nentries=0 etime=0 > [17/Nov/2016:08:40:02.257477560 -0600] conn=121 op=86 SRCH > base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" > scope=0 filter="(objectClass=*)" attrs=ALL > [17/Nov/2016:08:40:02.257813691 -0600] conn=121 op=86 RESULT err=0 > tag=101 nentries=0 etime=0 > [17/Nov/2016:08:40:03.261805482 -0600] conn=121 op=88 SRCH > base="uid=admin-imqa-d2-dc01.qa-unix.follett.com,ou=people,o=ipaca" > scope=0 filter="(objectClass=*)" attrs=ALL > [17/Nov/2016:08:40:03.262310788 -0600] conn=121 op=88 RESULT err=0 > tag=101 nentries=0 etime=0 > > Dirsrv logs on the existing master: > > [17/Nov/2016:08:40:20.644554573 -0600] NSMMReplicationPlugin - > conn=120 op=13 replica="o=ipaca": Unable to acquire replica: error: > permission denied > [17/Nov/2016:08:41:57.858672215 -0600] NSMMReplicationPlugin - > conn=123 op=5 replica="o=ipaca": Unable to acquire replica: error: > permission denied > [17/Nov/2016:08:45:09.334188374 -0600] NSMMReplicationPlugin - > conn=130 op=5 replica="o=ipaca": Unable to acquire replica: error: > permission denied > > Has anyone else experienced this issue? > > Thanks, > > Josh > > [1] https://fedorahosted.org/freeipa/ticket/5412 > > Hi Josh, in the original ticket the issue was occuring when creating CA replica against 7.2 master upgraded to 7.3 with domain level raised to 1. Do you have the same scenario? Also, during the stuck installation can you check for the presence of replica's LDAP principal in 'nsds5replicabinddn' attribute on master's 'cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config' entry? I would also check for the reverse, i.e. if the master's LDAP principal is in the 'nsds5replicabinddn' attribute on replica's 'cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config' entry. -- Martin^3 Babinsky From morgan at marodin.it Fri Nov 18 14:21:43 2016 From: morgan at marodin.it (Morgan Marodin) Date: Fri, 18 Nov 2016 15:21:43 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> <994f1c25-5c63-b0f0-1da4-6b4788331daf@redhat.com> Message-ID: A little good news. Downgrading the *mod_nss* RPM package, and restoring the original */etc/httpd/alias* folder, *ipa-server-upgrade* procedure has finished well: *# ipa-server-upgradeUpgrading IPA: [1/10]: stopping directory server [2/10]: saving configuration [3/10]: disabling listeners [4/10]: enabling DS global lock [5/10]: starting directory server [6/10]: updating schema [7/10]: upgrading server [8/10]: stopping directory server [9/10]: restoring configuration [10/10]: starting directory serverDone.Update completeUpgrading IPA servicesUpgrading the configuration of the IPA services[Verifying that root certificate is published][Migrate CRL publish directory]CRL tree already moved[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]Global forward policy in named.conf will be changed to "only" to avoid conflicts with automatic empty zones[Adding server_id to named.conf]Changes to named.conf have been made, restart namedCustodia service is being configuredConfiguring ipa-custodia [1/5]: Generating ipa-custodia config file [2/5]: Making sure custodia container exists [3/5]: Generating ipa-custodia keys [4/5]: starting ipa-custodia [5/5]: configuring ipa-custodia to start on bootDone configuring ipa-custodia.[Upgrading CA schema]CA schema update complete[Verifying that CA audit signing cert has 2 year validity][Update certmonger certificate renewal configuration to version 5]Configuring certmonger to stop tracking system certificates for CACertmonger certificate renewal configuration updated 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]pki-tomcat configuration changed, restart pki-tomcat[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 principalRetrieving keytabCreating Custodia keysConfiguring key retrieverThe IPA services were upgradedThe ipa-server-upgrade command was successful* And Apache has started, BUT there is a problem with the web certificate: *# tail -f /var/log/httpd/error_log[Fri Nov 18 15:14:43.002268 2016] [:info] [pid 18673] Connection to child 2 established (server mlv-ipa01.ipa.mydomain.com:443 , client 192.168.0.252)[Fri Nov 18 15:14:43.207349 2016] [:info] [pid 18673] SSL input filter read failed.[Fri Nov 18 15:14:43.207389 2016] [:error] [pid 18673] SSL Library Error: -12285 Unable to find the certificate or key necessary for authentication[Fri Nov 18 15:14:43.207460 2016] [:info] [pid 18673] Connection to child 2 closed (server mlv-ipa01.ipa.mydomain.com:443 , client 192.168.0.252)* How do you suggest to go on with my issue? Thanks, Morgan 2016-11-18 12:11 GMT+01:00 Morgan Marodin : > I've tried to add it to a new test folder, with a new certificate > nickname, and then to replace it to *nss.conf*. > > But the problem persists: > > *# certutil -V -u V -d /etc/httpd/test -n ipa01certcertutil: certificate > is valid* > > > *# tail -f /var/log/httpd/error_log* > > > > > > > > *[Fri Nov 18 12:09:39.513833 2016] [suexec:notice] [pid 11552] AH01232: > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)[Fri Nov 18 > 12:09:39.514266 2016] [:warn] [pid 11552] NSSSessionCacheTimeout is > deprecated. Ignoring.[Fri Nov 18 12:09:39.514299 2016] [:debug] [pid 11552] > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > -> ipa01cert[Fri Nov 18 12:09:39.824880 > 2016] [:error] [pid 11552] The server key database has not been > initialized.[Fri Nov 18 12:09:39.832443 2016] [:info] [pid 11552] > Configuring server for SSL protocol...[Fri Nov 18 12:09:39.832676 2016] > [:info] [pid 11552] Using nickname ipa01cert.[Fri Nov 18 12:09:39.832678 > 2016] [:error] [pid 11552] Certificate not found: 'ipa01cert'* > > I've found this guide: > > > > > > > *Combine the server cert and key into a single file# cp localhost.crt > > Server-Cert.txt# cat localhost.key >> Server-Cert.txtConvert the server > cert into a p12 file# openssl pkcs12 -export -in Server-Cert.txt -out > Server-Cert.p12 -name "Server-Cert"Now Import the Public and Private keys > into the database at the same time.#pk12util -i > /tmp/cert-files/Server-Cert.p12 -d /etc/httpd/alias -n Server-Cert* > > Where is stored the key certificate file? > > Thanks, Morgan > > > 2016-11-18 10:39 GMT+01:00 Florence Blanc-Renaud : > >> On 11/18/2016 10:04 AM, Morgan Marodin wrote: >> >>> Hi Florence. >>> >>> I've tried to configure the wrong certificate in nss.conf (/ipaCert/), >>> and with this Apache started. >>> So I think the problem is in the /Server-Cert/ stored in >>> //etc/httpd/alias/, even if all manul checks are ok. >>> >>> These are logs with the wrong certificate test: >>> /# tail -f /var/log/httpd/error_log/ >>> /[Fri Nov 18 09:34:32.583700 2016] [suexec:notice] [pid 7709] AH01232: >>> suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >>> [Fri Nov 18 09:34:32.584142 2016] [:warn] [pid 7709] >>> NSSSessionCacheTimeout is deprecated. Ignoring. >>> [Fri Nov 18 09:34:32.584178 2016] [:debug] [pid 7709] >>> nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com >>> -> ipaCert >>> >>> [Fri Nov 18 09:34:32.844487 2016] [:info] [pid 7709] Configuring server >>> for SSL protocol >>> [Fri Nov 18 09:34:32.844635 2016] [:debug] [pid 7709] >>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>> [Fri Nov 18 09:34:32.844657 2016] [:debug] [pid 7709] >>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>> [Fri Nov 18 09:34:32.844668 2016] [:debug] [pid 7709] >>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>> [Fri Nov 18 09:34:32.844677 2016] [:debug] [pid 7709] >>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>> [Fri Nov 18 09:34:32.844684 2016] [:debug] [pid 7709] >>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>> [Fri Nov 18 09:34:32.844738 2016] [:debug] [pid 7709] >>> nss_engine_init.c(906): Disabling TLS Session Tickets >>> [Fri Nov 18 09:34:32.844746 2016] [:debug] [pid 7709] >>> nss_engine_init.c(916): Enabling DHE key exchange >>> [Fri Nov 18 09:34:32.844760 2016] [:debug] [pid 7709] >>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>> ciphers >>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_ >>> 256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384, >>> +ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_ >>> 128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>> [Fri Nov 18 09:34:32.844825 2016] [:debug] [pid 7709] >>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>> ... >>> [Fri Nov 18 09:34:32.845105 2016] [:debug] [pid 7709] >>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>> [Fri Nov 18 09:34:32.845110 2016] [:info] [pid 7709] Using nickname >>> ipaCert. >>> [Fri Nov 18 09:34:32.847451 2016] [:error] [pid 7709] Misconfiguration >>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>> expected mlv-ipa01.ipa.mydomain.com >>> as virtual name. >>> [Fri Nov 18 09:34:33.028056 2016] [auth_digest:notice] [pid 7709] >>> AH01757: generating secret for digest authentication ... >>> [Fri Nov 18 09:34:33.030039 2016] [lbmethod_heartbeat:notice] [pid 7709] >>> AH02282: No slotmem from mod_heartmonitor >>> [Fri Nov 18 09:34:33.030122 2016] [:warn] [pid 7709] >>> NSSSessionCacheTimeout is deprecated. Ignoring. >>> [Fri Nov 18 09:34:33.030176 2016] [:debug] [pid 7709] >>> nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com >>> -> ipaCert >>> >>> [Fri Nov 18 09:34:33.051481 2016] [mpm_prefork:notice] [pid 7709] >>> AH00163: Apache/2.4.6 () mod_auth_gssapi/1.4.0 mod_auth_kerb/5.4 >>> mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured >>> -- resuming normal operations >>> [Fri Nov 18 09:34:33.051551 2016] [core:notice] [pid 7709] AH00094: >>> Command line: '/usr/sbin/httpd -D FOREGROUND' >>> [Fri Nov 18 09:34:33.096050 2016] [proxy:debug] [pid 7717] >>> proxy_util.c(1838): AH00924: worker ajp://localhost shared already >>> initialized >>> [Fri Nov 18 09:34:33.096163 2016] [proxy:debug] [pid 7717] >>> proxy_util.c(1880): AH00926: worker ajp://localhost local already >>> initialized >>> ... >>> [Fri Nov 18 09:34:33.105626 2016] [proxy:debug] [pid 7719] >>> proxy_util.c(1838): AH00924: worker >>> unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ shared already >>> initialized >>> [Fri Nov 18 09:34:33.105632 2016] [proxy:debug] [pid 7719] >>> proxy_util.c(1880): AH00926: worker >>> unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ local already >>> initialized >>> [Fri Nov 18 09:34:33.342762 2016] [:info] [pid 7717] Configuring server >>> for SSL protocol >>> [Fri Nov 18 09:34:33.342867 2016] [:debug] [pid 7717] >>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>> [Fri Nov 18 09:34:33.342880 2016] [:debug] [pid 7717] >>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>> [Fri Nov 18 09:34:33.342885 2016] [:debug] [pid 7717] >>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>> [Fri Nov 18 09:34:33.342890 2016] [:debug] [pid 7717] >>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>> [Fri Nov 18 09:34:33.342894 2016] [:debug] [pid 7717] >>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>> [Fri Nov 18 09:34:33.342900 2016] [:debug] [pid 7717] >>> nss_engine_init.c(906): Disabling TLS Session Tickets >>> [Fri Nov 18 09:34:33.342904 2016] [:debug] [pid 7717] >>> nss_engine_init.c(916): Enabling DHE key exchange >>> [Fri Nov 18 09:34:33.342917 2016] [:debug] [pid 7717] >>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>> ciphers >>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_ >>> 256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384, >>> +ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_ >>> 128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>> [Fri Nov 18 09:34:33.342970 2016] [:debug] [pid 7717] >>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>> ... >>> [Fri Nov 18 09:34:33.343233 2016] [:debug] [pid 7717] >>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>> [Fri Nov 18 09:34:33.343237 2016] [:info] [pid 7717] Using nickname >>> ipaCert. >>> [Fri Nov 18 09:34:33.344533 2016] [:error] [pid 7717] Misconfiguration >>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>> expected mlv-ipa01.ipa.mydomain.com >>> >>> as virtual name. >>> [Fri Nov 18 09:34:33.364061 2016] [:info] [pid 7718] Configuring server >>> for SSL protocol >>> [Fri Nov 18 09:34:33.364156 2016] [:debug] [pid 7718] >>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>> [Fri Nov 18 09:34:33.364167 2016] [:debug] [pid 7718] >>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>> [Fri Nov 18 09:34:33.364172 2016] [:debug] [pid 7718] >>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>> [Fri Nov 18 09:34:33.364176 2016] [:debug] [pid 7718] >>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>> [Fri Nov 18 09:34:33.364180 2016] [:debug] [pid 7718] >>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>> [Fri Nov 18 09:34:33.364187 2016] [:debug] [pid 7718] >>> nss_engine_init.c(906): Disabling TLS Session Tickets >>> [Fri Nov 18 09:34:33.364191 2016] [:debug] [pid 7718] >>> nss_engine_init.c(916): Enabling DHE key exchange >>> [Fri Nov 18 09:34:33.364202 2016] [:debug] [pid 7718] >>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>> ciphers >>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_ >>> 256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384, >>> +ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_ >>> 128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>> [Fri Nov 18 09:34:33.364240 2016] [:debug] [pid 7718] >>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>> ... >>> [Fri Nov 18 09:34:33.364611 2016] [:debug] [pid 7718] >>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>> [Fri Nov 18 09:34:33.364625 2016] [:info] [pid 7718] Using nickname >>> ipaCert. >>> [Fri Nov 18 09:34:33.365549 2016] [:error] [pid 7718] Misconfiguration >>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>> expected mlv-ipa01.ipa.mydomain.com >>> >>> as virtual name. >>> [Fri Nov 18 09:34:33.369972 2016] [:info] [pid 7720] Configuring server >>> for SSL protocol >>> [Fri Nov 18 09:34:33.370200 2016] [:debug] [pid 7720] >>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>> [Fri Nov 18 09:34:33.370224 2016] [:debug] [pid 7720] >>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>> [Fri Nov 18 09:34:33.370239 2016] [:debug] [pid 7720] >>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>> [Fri Nov 18 09:34:33.370255 2016] [:debug] [pid 7720] >>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>> [Fri Nov 18 09:34:33.370269 2016] [:debug] [pid 7720] >>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>> [Fri Nov 18 09:34:33.370286 2016] [:debug] [pid 7720] >>> nss_engine_init.c(906): Disabling TLS Session Tickets >>> [Fri Nov 18 09:34:33.370301 2016] [:debug] [pid 7720] >>> nss_engine_init.c(916): Enabling DHE key exchange >>> [Fri Nov 18 09:34:33.370322 2016] [:debug] [pid 7720] >>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>> ciphers >>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_ >>> 256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384, >>> +ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_ >>> 128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>> [Fri Nov 18 09:34:33.370383 2016] [:debug] [pid 7720] >>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>> ... >>> [Fri Nov 18 09:34:33.371418 2016] [:debug] [pid 7720] >>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>> [Fri Nov 18 09:34:33.371437 2016] [:info] [pid 7720] Using nickname >>> ipaCert. >>> [Fri Nov 18 09:34:33.371486 2016] [:info] [pid 7716] Configuring server >>> for SSL protocol >>> [Fri Nov 18 09:34:33.372383 2016] [:debug] [pid 7716] >>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>> [Fri Nov 18 09:34:33.372439 2016] [:debug] [pid 7716] >>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>> [Fri Nov 18 09:34:33.372459 2016] [:debug] [pid 7716] >>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>> [Fri Nov 18 09:34:33.372484 2016] [:debug] [pid 7716] >>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>> [Fri Nov 18 09:34:33.372513 2016] [:debug] [pid 7716] >>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>> [Fri Nov 18 09:34:33.372534 2016] [:debug] [pid 7716] >>> nss_engine_init.c(906): Disabling TLS Session Tickets >>> [Fri Nov 18 09:34:33.372553 2016] [:debug] [pid 7716] >>> nss_engine_init.c(916): Enabling DHE key exchange >>> [Fri Nov 18 09:34:33.372580 2016] [:debug] [pid 7716] >>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>> ciphers >>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_ >>> 256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384, >>> +ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_ >>> 128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>> [Fri Nov 18 09:34:33.372627 2016] [:debug] [pid 7716] >>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>> ... >>> [Fri Nov 18 09:34:33.373712 2016] [:debug] [pid 7716] >>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>> [Fri Nov 18 09:34:33.373734 2016] [:info] [pid 7716] Using nickname >>> ipaCert. >>> [Fri Nov 18 09:34:33.374652 2016] [:error] [pid 7716] Misconfiguration >>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>> expected mlv-ipa01.ipa.mydomain.com >>> as virtual name. >>> [Fri Nov 18 09:34:33.372295 2016] [:error] [pid 7720] Misconfiguration >>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>> expected mlv-ipa01.ipa.mydomain.com >>> >>> as virtual name. >>> [Fri Nov 18 09:34:33.412689 2016] [:info] [pid 7719] Configuring server >>> for SSL protocol >>> [Fri Nov 18 09:34:33.412791 2016] [:debug] [pid 7719] >>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>> [Fri Nov 18 09:34:33.412803 2016] [:debug] [pid 7719] >>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>> [Fri Nov 18 09:34:33.412807 2016] [:debug] [pid 7719] >>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>> [Fri Nov 18 09:34:33.412812 2016] [:debug] [pid 7719] >>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>> [Fri Nov 18 09:34:33.412817 2016] [:debug] [pid 7719] >>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>> [Fri Nov 18 09:34:33.412824 2016] [:debug] [pid 7719] >>> nss_engine_init.c(906): Disabling TLS Session Tickets >>> [Fri Nov 18 09:34:33.412828 2016] [:debug] [pid 7719] >>> nss_engine_init.c(916): Enabling DHE key exchange >>> [Fri Nov 18 09:34:33.412840 2016] [:debug] [pid 7719] >>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>> ciphers >>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_ >>> 256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384, >>> +ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_ >>> 128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>> [Fri Nov 18 09:34:33.412891 2016] [:debug] [pid 7719] >>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>> ... >>> [Fri Nov 18 09:34:33.413159 2016] [:debug] [pid 7719] >>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>> [Fri Nov 18 09:34:33.413164 2016] [:info] [pid 7719] Using nickname >>> ipaCert. >>> [Fri Nov 18 09:34:33.414462 2016] [:error] [pid 7719] Misconfiguration >>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>> expected mlv-ipa01.ipa.mydomain.com >>> as virtual name. >>> [Fri Nov 18 09:34:35.558286 2016] [:error] [pid 7715] ipa: WARNING: >>> session memcached servers not running >>> [Fri Nov 18 09:34:35.559653 2016] [:error] [pid 7714] ipa: WARNING: >>> session memcached servers not running >>> [Fri Nov 18 09:34:37.511457 2016] [:error] [pid 7714] ipa: INFO: *** >>> PROCESS START *** >>> [Fri Nov 18 09:34:37.517899 2016] [:error] [pid 7715] ipa: INFO: *** >>> PROCESS START *** >>> [Fri Nov 18 09:34:51.498536 2016] [:info] [pid 7717] Connection to child >>> 1 established (server mlv-ipa01.ipa.mydomain.com >>> , client 192.168.0.239) >>> [Fri Nov 18 09:34:51.510292 2016] [:info] [pid 7717] SSL input filter >>> read failed. >>> [Fri Nov 18 09:34:51.510311 2016] [:error] [pid 7717] SSL Library Error: >>> -12285 Unable to find the certificate or key necessary for authentication >>> [Fri Nov 18 09:34:51.510356 2016] [:info] [pid 7717] Connection to child >>> 1 closed (server mlv-ipa01.ipa.mydomain.com:443 >>> , client 192.168.0.239) >>> [Fri Nov 18 09:35:18.790760 2016] [mpm_prefork:notice] [pid 7709] >>> AH00170: caught SIGWINCH, shutting down gracefully/ >>> >>> Is possible to delete /Server-Cert/ from //etc/httpd/alias/ and reimport >>> it from the original certificates of /mlv-ipa01.ipa.mydomain.com >>> /? >>> Where are stored the original certificates? >>> >>> Hi Morgan, >> >> with ldapsearch you should be able to find the certificate: >> ldapsearch -h ipaserver.ipadomain -p 389 -D "cn=directory manager" -w >> password -LLL -b krbprincipalname=HTTP/ipaserver.ipadomain at IPADOMAIN >> ,cn=services,cn=accounts,dc=IPADOMAIN >> >> The cert will be stored in the field "usercertificate". >> >> HTH, >> Flo. >> >> Please let me know, thanks. >>> Bye, Morgan >>> >>> 2016-11-17 17:09 GMT+01:00 Florence Blanc-Renaud >> >: >>> >>> >>> On 11/17/2016 04:51 PM, Morgan Marodin wrote: >>> >>> Hi Rob. >>> >>> I've just tried to remove the group write to the *.db files, but >>> it's >>> not the problem. >>> /[root at mlv-ipa01 ~]# grep NSSNickname /etc/httpd/conf.d/nss.conf >>> NSSNickname Server-Cert/ >>> >>> I've tried to run manually /dirsrv.target/ and >>> /krb5kdc.service/, and it >>> works, services went up. >>> The same for /ntpd/, /named-pkcs11.service/, /smb.service/, >>> /winbind.service/, /kadmin.service/, /memcached.service/ and >>> /pki-tomcatd.target/. >>> >>> But if I try to start /httpd.service/: >>> /[root at mlv-ipa01 ~]# tail -f /var/log/messages >>> Nov 17 16:46:06 mlv-ipa01 systemd[1]: Starting The Apache HTTP >>> Server... >>> Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: ipa : >>> INFO KDC >>> proxy enabled >>> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: main process >>> exited, code=exited, status=1/FAILURE >>> Nov 17 16:46:07 mlv-ipa01 kill: kill: cannot find process "" >>> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: control >>> process >>> exited, code=exited status=1 >>> Nov 17 16:46:07 mlv-ipa01 systemd[1]: Failed to start The Apache >>> HTTP >>> Server. >>> Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit httpd.service entered >>> failed >>> state. >>> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service failed./ >>> >>> Any other ideas? >>> >>> Hi, >>> >>> - Does the NSS Db contain the private key for Server-Cert? If yes, >>> the command >>> $ certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt >>> should display a line like this one: >>> < 0> rsa 01a6cbd773f3d785ffa44233148dcb8ade266ea5 NSS >>> Certificate DB:Server-Cert >>> >>> - Is your system running with SElinux enforcing? If yes, you can >>> check if there were SElinux permission denials using >>> $ ausearch -m avc --start recent >>> >>> - If the certificate was expired, I believe you would see a >>> different message, but it doesn't hurt to check its validity >>> $ certutil -L -d /etc/httpd/alias/ -n Server-Cert | egrep "Not >>> Before|Not After" >>> >>> >>> Flo. >>> >>> >>> Please let me know, thanks. >>> Morgan >>> >>> 2016-11-17 16:11 GMT+01:00 Rob Crittenden >> >>> >>: >>> >>> >>> >>> Morgan Marodin wrote: >>> > Hi Florence. >>> > >>> > Thanks for your support. >>> > >>> > Yes, httpd is using /etc/httpd/alias as NSS DB. And seems >>> that all >>> > permissions and certificates are good: >>> > /[root at mlv-ipa01 ~]# ls -l /etc/httpd/alias/ >>> > total 184 >>> > -r--r--r-- 1 root root 1345 Sep 7 2015 cacert.asc >>> > -rw-rw---- 1 root apache 65536 Nov 17 11:06 cert8.db >>> > -rw-r-----. 1 root apache 65536 Sep 4 2015 cert8.db.orig >>> > -rw-------. 1 root root 4833 Sep 4 2015 install.log >>> > -rw-rw---- 1 root apache 16384 Nov 17 11:06 key3.db >>> > -rw-r-----. 1 root apache 16384 Sep 4 2015 key3.db.orig >>> > lrwxrwxrwx 1 root root 24 Nov 17 10:24 libnssckbi.so >>> -> >>> > /usr/lib64/libnssckbi.so >>> > -rw-rw---- 1 root apache 20 Sep 7 2015 pwdfile.txt >>> > -rw-rw---- 1 root apache 16384 Sep 7 2015 secmod.db >>> > -rw-r-----. 1 root apache 16384 Sep 4 2015 >>> secmod.db.orig/ >>> >>> Eventually you'll want to remove group write on the *.db >>> files. >>> >>> > And password validations seems ok, too: >>> > /[root at mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f >>> > /etc/httpd/alias/pwdfile.txt >>> good >>> >>> > Enabling mod-nss debug I can see these logs: >>> > /[root at mlv-ipa01 ~]# tail -f /var/log/httpd/error_log >>> > [Thu Nov 17 15:05:10.807603 2016] [suexec:notice] [pid >>> 10660] AH01232: >>> > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >>> > [Thu Nov 17 15:05:10.807958 2016] [:warn] [pid 10660] >>> > NSSSessionCacheTimeout is deprecated. Ignoring. >>> > [Thu Nov 17 15:05:10.807991 2016] [:debug] [pid 10660] >>> > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com >>> >>> >> > >>> > >> >>> >>> >> >> -> Server-Cert >>> > [Thu Nov 17 15:05:11.002664 2016] [:info] [pid 10660] >>> Configuring server >>> > for SSL protocol >>> > [Thu Nov 17 15:05:11.002817 2016] [:debug] [pid 10660] >>> > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>> > [Thu Nov 17 15:05:11.002838 2016] [:debug] [pid 10660] >>> > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>> > [Thu Nov 17 15:05:11.002847 2016] [:debug] [pid 10660] >>> > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>> > [Thu Nov 17 15:05:11.002856 2016] [:debug] [pid 10660] >>> > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>> > [Thu Nov 17 15:05:11.002876 2016] [:debug] [pid 10660] >>> > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>> > [Thu Nov 17 15:05:11.003099 2016] [:debug] [pid 10660] >>> > nss_engine_init.c(906): Disabling TLS Session Tickets >>> > [Thu Nov 17 15:05:11.003198 2016] [:debug] [pid 10660] >>> > nss_engine_init.c(916): Enabling DHE key exchange >>> > [Thu Nov 17 15:05:11.003313 2016] [:debug] [pid 10660] >>> > nss_engine_init.c(1077): NSSCipherSuite: Configuring >>> permitted SSL >>> > ciphers >>> > >>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_ >>> 256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384, >>> +ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_ >>> 128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>> > [Thu Nov 17 15:05:11.003469 2016] [:debug] [pid 10660] >>> > [Thu Nov 17 15:05:11.006759 2016] [:info] [pid 10660] >>> Using nickname >>> > Server-Cert. >>> [snip] >>> > [Thu Nov 17 15:05:11.006771 2016] [:error] [pid 10660] >>> Certificate not >>> > found: 'Server-Cert' >>> >>> Can you shows what this returns: >>> >>> # grep NSSNickname /etc/httpd/conf.d/nss.conf >>> >>> > Do you think there is a kerberos problem? >>> >>> It definitely is not. >>> >>> You can bring the system up in a minimal way by manually >>> starting the >>> dirsrv at EXAMPLE.COM >>> > service >>> >>> and then >>> krb5kdc. This will at least let your >>> users authenticate. The management framework (GUI) runs >>> through Apache >>> so that will be down until we can get Apache started again. >>> >>> rob >>> >>> > >>> > Please let me know, thanks. >>> > Bye, Morgan >>> > >>> > 2016-11-17 14:39 GMT+01:00 Florence Blanc-Renaud >>> >> > >>> > >>> >>>: >>> >>> > >>> > On 11/17/2016 12:09 PM, Morgan Marodin wrote: >>> > >>> > Hello. >>> > >>> > This morning I've tried to upgrade my IPA server, >>> but the >>> upgrade >>> > failed, and now the service doesn't start! :( >>> > >>> > If I try lo launch the upgrade manually this is >>> the output: >>> > /[root at mlv-ipa01 download]# 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 >>> > [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 >>> > 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: >>> > CalledProcessError: Command '/bin/systemctl start >>> httpd.service' >>> > returned non-zero exit status 1 >>> > The ipa-server-upgrade command failed. See >>> > /var/log/ipaupgrade.log for >>> > more information/ >>> > >>> > These are error logs of Apache: >>> > /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] >>> [pid 5664] >>> > AH01232: >>> > suEXEC mechanism enabled (wrapper: >>> /usr/sbin/suexec) >>> > [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid >>> 5664] >>> > NSSSessionCacheTimeout is deprecated. Ignoring. >>> > [Thu Nov 17 11:48:45.830910 2016] [:error] [pid >>> 5664] >>> > Certificate not >>> > found: 'Server-Cert'/ >>> > >>> > The problem seems to be the /Server-Cert /that >>> could not >>> be found. >>> > But if I try to execute the certutil command >>> manually I >>> can see it:/ >>> > [root at mlv-ipa01 log]# certutil -L -d >>> /etc/httpd/alias/ >>> > Certificate Nickname >>> Trust >>> > Attributes >>> > >>> > SSL,S/MIME,JAR/XPI >>> > Signing-Cert >>> u,u,u >>> > ipaCert >>> u,u,u >>> > Server-Cert >>> Pu,u,u >>> > IPA.MYDOMAIN.COM >>> >>> >>> > IPA >>> > CA CT,C,C/ >>> > >>> > Could you help me? >>> > What could I try to do to restart my service? >>> > >>> > Hi, >>> > >>> > I would first make sure that httpd is using >>> /etc/httpd/alias >>> as NSS >>> > DB (check the directive NSSCertificateDatabase in >>> > /etc/httpd/conf.d/nss.conf). >>> > Then it may be a file permission issue: the NSS DB >>> should >>> belong to >>> > root:apache (the relevant files are cert8.db, key3.db >>> and >>> secmod.db). >>> > You should also find a pwdfile.txt in the same >>> directory, >>> containing >>> > the NSS DB password. Check that the password is valid >>> using >>> > certutil -K -d /etc/httpd/alias/ -f >>> /etc/httpd/alias/pwdfile.txt >>> > (if the command succeeds then the password in pwdfile >>> is OK). >>> > >>> > You can also enable mod-nss debug in >>> /etc/httpd/conf/nss.conf by >>> > setting "LogLevel debug", and check the output in >>> > /var/log/httpd/error_log. >>> > >>> > HTH, >>> > Flo. >>> > >>> > Thanks, Morgan >>> > >>> > >>> > >>> > -- >>> > 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 morgan at marodin.it Fri Nov 18 14:30:27 2016 From: morgan at marodin.it (Morgan Marodin) Date: Fri, 18 Nov 2016 15:30:27 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> <994f1c25-5c63-b0f0-1da4-6b4788331daf@redhat.com> Message-ID: It works! Thanks for your support. Anyway, I will try to update againt mod_nss package! :D Bye! 2016-11-18 15:21 GMT+01:00 Morgan Marodin : > A little good news. > > Downgrading the *mod_nss* RPM package, and restoring the original > */etc/httpd/alias* folder, *ipa-server-upgrade* procedure has finished > well: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *# ipa-server-upgradeUpgrading IPA: [1/10]: stopping directory server > [2/10]: saving configuration [3/10]: disabling listeners [4/10]: enabling > DS global lock [5/10]: starting directory server [6/10]: updating schema > [7/10]: upgrading server [8/10]: stopping directory server [9/10]: > restoring configuration [10/10]: starting directory serverDone.Update > completeUpgrading IPA servicesUpgrading the configuration of the IPA > services[Verifying that root certificate is published][Migrate CRL publish > directory]CRL tree already moved[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]Global forward > policy in named.conf will be changed to "only" to avoid conflicts with > automatic empty zones[Adding server_id to named.conf]Changes to named.conf > have been made, restart namedCustodia service is being > configuredConfiguring ipa-custodia [1/5]: Generating ipa-custodia config > file [2/5]: Making sure custodia container exists [3/5]: Generating > ipa-custodia keys [4/5]: starting ipa-custodia [5/5]: configuring > ipa-custodia to start on bootDone configuring ipa-custodia.[Upgrading CA > schema]CA schema update complete[Verifying that CA audit signing cert has 2 > year validity][Update certmonger certificate renewal configuration to > version 5]Configuring certmonger to stop tracking system certificates for > CACertmonger certificate renewal configuration updated 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]pki-tomcat configuration > changed, restart pki-tomcat[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 principalRetrieving > keytabCreating Custodia keysConfiguring key retrieverThe IPA services were > upgradedThe ipa-server-upgrade command was successful* > > And Apache has started, BUT there is a problem with the web certificate: > > > > > *# tail -f /var/log/httpd/error_log[Fri Nov 18 15:14:43.002268 2016] > [:info] [pid 18673] Connection to child 2 established (server > mlv-ipa01.ipa.mydomain.com:443 , > client 192.168.0.252)[Fri Nov 18 15:14:43.207349 2016] [:info] [pid 18673] > SSL input filter read failed.[Fri Nov 18 15:14:43.207389 2016] [:error] > [pid 18673] SSL Library Error: -12285 Unable to find the certificate or key > necessary for authentication[Fri Nov 18 15:14:43.207460 2016] [:info] [pid > 18673] Connection to child 2 closed (server mlv-ipa01.ipa.mydomain.com:443 > , client 192.168.0.252)* > > How do you suggest to go on with my issue? > > Thanks, Morgan > > 2016-11-18 12:11 GMT+01:00 Morgan Marodin : > >> I've tried to add it to a new test folder, with a new certificate >> nickname, and then to replace it to *nss.conf*. >> >> But the problem persists: >> >> *# certutil -V -u V -d /etc/httpd/test -n ipa01certcertutil: certificate >> is valid* >> >> >> *# tail -f /var/log/httpd/error_log* >> >> >> >> >> >> >> >> *[Fri Nov 18 12:09:39.513833 2016] [suexec:notice] [pid 11552] AH01232: >> suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)[Fri Nov 18 >> 12:09:39.514266 2016] [:warn] [pid 11552] NSSSessionCacheTimeout is >> deprecated. Ignoring.[Fri Nov 18 12:09:39.514299 2016] [:debug] [pid 11552] >> nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com >> -> ipa01cert[Fri Nov 18 12:09:39.824880 >> 2016] [:error] [pid 11552] The server key database has not been >> initialized.[Fri Nov 18 12:09:39.832443 2016] [:info] [pid 11552] >> Configuring server for SSL protocol...[Fri Nov 18 12:09:39.832676 2016] >> [:info] [pid 11552] Using nickname ipa01cert.[Fri Nov 18 12:09:39.832678 >> 2016] [:error] [pid 11552] Certificate not found: 'ipa01cert'* >> >> I've found this guide: >> >> >> >> >> >> >> *Combine the server cert and key into a single file# cp localhost.crt > >> Server-Cert.txt# cat localhost.key >> Server-Cert.txtConvert the server >> cert into a p12 file# openssl pkcs12 -export -in Server-Cert.txt -out >> Server-Cert.p12 -name "Server-Cert"Now Import the Public and Private keys >> into the database at the same time.#pk12util -i >> /tmp/cert-files/Server-Cert.p12 -d /etc/httpd/alias -n Server-Cert* >> >> Where is stored the key certificate file? >> >> Thanks, Morgan >> >> >> 2016-11-18 10:39 GMT+01:00 Florence Blanc-Renaud : >> >>> On 11/18/2016 10:04 AM, Morgan Marodin wrote: >>> >>>> Hi Florence. >>>> >>>> I've tried to configure the wrong certificate in nss.conf (/ipaCert/), >>>> and with this Apache started. >>>> So I think the problem is in the /Server-Cert/ stored in >>>> //etc/httpd/alias/, even if all manul checks are ok. >>>> >>>> These are logs with the wrong certificate test: >>>> /# tail -f /var/log/httpd/error_log/ >>>> /[Fri Nov 18 09:34:32.583700 2016] [suexec:notice] [pid 7709] AH01232: >>>> suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >>>> [Fri Nov 18 09:34:32.584142 2016] [:warn] [pid 7709] >>>> NSSSessionCacheTimeout is deprecated. Ignoring. >>>> [Fri Nov 18 09:34:32.584178 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com >>>> -> ipaCert >>>> >>>> [Fri Nov 18 09:34:32.844487 2016] [:info] [pid 7709] Configuring server >>>> for SSL protocol >>>> [Fri Nov 18 09:34:32.844635 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>>> [Fri Nov 18 09:34:32.844657 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>>> [Fri Nov 18 09:34:32.844668 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>>> [Fri Nov 18 09:34:32.844677 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>>> [Fri Nov 18 09:34:32.844684 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>>> [Fri Nov 18 09:34:32.844738 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(906): Disabling TLS Session Tickets >>>> [Fri Nov 18 09:34:32.844746 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(916): Enabling DHE key exchange >>>> [Fri Nov 18 09:34:32.844760 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>>> ciphers >>>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_25 >>>> 6,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ >>>> ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_ >>>> sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>>> [Fri Nov 18 09:34:32.844825 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>>> ... >>>> [Fri Nov 18 09:34:32.845105 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>>> [Fri Nov 18 09:34:32.845110 2016] [:info] [pid 7709] Using nickname >>>> ipaCert. >>>> [Fri Nov 18 09:34:32.847451 2016] [:error] [pid 7709] Misconfiguration >>>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>>> expected mlv-ipa01.ipa.mydomain.com >>>> as virtual name. >>>> [Fri Nov 18 09:34:33.028056 2016] [auth_digest:notice] [pid 7709] >>>> AH01757: generating secret for digest authentication ... >>>> [Fri Nov 18 09:34:33.030039 2016] [lbmethod_heartbeat:notice] [pid >>>> 7709] >>>> AH02282: No slotmem from mod_heartmonitor >>>> [Fri Nov 18 09:34:33.030122 2016] [:warn] [pid 7709] >>>> NSSSessionCacheTimeout is deprecated. Ignoring. >>>> [Fri Nov 18 09:34:33.030176 2016] [:debug] [pid 7709] >>>> nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com >>>> -> ipaCert >>>> >>>> [Fri Nov 18 09:34:33.051481 2016] [mpm_prefork:notice] [pid 7709] >>>> AH00163: Apache/2.4.6 () mod_auth_gssapi/1.4.0 mod_auth_kerb/5.4 >>>> mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured >>>> -- resuming normal operations >>>> [Fri Nov 18 09:34:33.051551 2016] [core:notice] [pid 7709] AH00094: >>>> Command line: '/usr/sbin/httpd -D FOREGROUND' >>>> [Fri Nov 18 09:34:33.096050 2016] [proxy:debug] [pid 7717] >>>> proxy_util.c(1838): AH00924: worker ajp://localhost shared already >>>> initialized >>>> [Fri Nov 18 09:34:33.096163 2016] [proxy:debug] [pid 7717] >>>> proxy_util.c(1880): AH00926: worker ajp://localhost local already >>>> initialized >>>> ... >>>> [Fri Nov 18 09:34:33.105626 2016] [proxy:debug] [pid 7719] >>>> proxy_util.c(1838): AH00924: worker >>>> unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ shared already >>>> initialized >>>> [Fri Nov 18 09:34:33.105632 2016] [proxy:debug] [pid 7719] >>>> proxy_util.c(1880): AH00926: worker >>>> unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ local already >>>> initialized >>>> [Fri Nov 18 09:34:33.342762 2016] [:info] [pid 7717] Configuring server >>>> for SSL protocol >>>> [Fri Nov 18 09:34:33.342867 2016] [:debug] [pid 7717] >>>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>>> [Fri Nov 18 09:34:33.342880 2016] [:debug] [pid 7717] >>>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>>> [Fri Nov 18 09:34:33.342885 2016] [:debug] [pid 7717] >>>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>>> [Fri Nov 18 09:34:33.342890 2016] [:debug] [pid 7717] >>>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>>> [Fri Nov 18 09:34:33.342894 2016] [:debug] [pid 7717] >>>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>>> [Fri Nov 18 09:34:33.342900 2016] [:debug] [pid 7717] >>>> nss_engine_init.c(906): Disabling TLS Session Tickets >>>> [Fri Nov 18 09:34:33.342904 2016] [:debug] [pid 7717] >>>> nss_engine_init.c(916): Enabling DHE key exchange >>>> [Fri Nov 18 09:34:33.342917 2016] [:debug] [pid 7717] >>>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>>> ciphers >>>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_25 >>>> 6,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ >>>> ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_ >>>> sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>>> [Fri Nov 18 09:34:33.342970 2016] [:debug] [pid 7717] >>>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>>> ... >>>> [Fri Nov 18 09:34:33.343233 2016] [:debug] [pid 7717] >>>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>>> [Fri Nov 18 09:34:33.343237 2016] [:info] [pid 7717] Using nickname >>>> ipaCert. >>>> [Fri Nov 18 09:34:33.344533 2016] [:error] [pid 7717] Misconfiguration >>>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>>> expected mlv-ipa01.ipa.mydomain.com >>>> >>>> as virtual name. >>>> [Fri Nov 18 09:34:33.364061 2016] [:info] [pid 7718] Configuring server >>>> for SSL protocol >>>> [Fri Nov 18 09:34:33.364156 2016] [:debug] [pid 7718] >>>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>>> [Fri Nov 18 09:34:33.364167 2016] [:debug] [pid 7718] >>>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>>> [Fri Nov 18 09:34:33.364172 2016] [:debug] [pid 7718] >>>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>>> [Fri Nov 18 09:34:33.364176 2016] [:debug] [pid 7718] >>>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>>> [Fri Nov 18 09:34:33.364180 2016] [:debug] [pid 7718] >>>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>>> [Fri Nov 18 09:34:33.364187 2016] [:debug] [pid 7718] >>>> nss_engine_init.c(906): Disabling TLS Session Tickets >>>> [Fri Nov 18 09:34:33.364191 2016] [:debug] [pid 7718] >>>> nss_engine_init.c(916): Enabling DHE key exchange >>>> [Fri Nov 18 09:34:33.364202 2016] [:debug] [pid 7718] >>>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>>> ciphers >>>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_25 >>>> 6,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ >>>> ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_ >>>> sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>>> [Fri Nov 18 09:34:33.364240 2016] [:debug] [pid 7718] >>>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>>> ... >>>> [Fri Nov 18 09:34:33.364611 2016] [:debug] [pid 7718] >>>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>>> [Fri Nov 18 09:34:33.364625 2016] [:info] [pid 7718] Using nickname >>>> ipaCert. >>>> [Fri Nov 18 09:34:33.365549 2016] [:error] [pid 7718] Misconfiguration >>>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>>> expected mlv-ipa01.ipa.mydomain.com >>>> >>>> as virtual name. >>>> [Fri Nov 18 09:34:33.369972 2016] [:info] [pid 7720] Configuring server >>>> for SSL protocol >>>> [Fri Nov 18 09:34:33.370200 2016] [:debug] [pid 7720] >>>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>>> [Fri Nov 18 09:34:33.370224 2016] [:debug] [pid 7720] >>>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>>> [Fri Nov 18 09:34:33.370239 2016] [:debug] [pid 7720] >>>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>>> [Fri Nov 18 09:34:33.370255 2016] [:debug] [pid 7720] >>>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>>> [Fri Nov 18 09:34:33.370269 2016] [:debug] [pid 7720] >>>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>>> [Fri Nov 18 09:34:33.370286 2016] [:debug] [pid 7720] >>>> nss_engine_init.c(906): Disabling TLS Session Tickets >>>> [Fri Nov 18 09:34:33.370301 2016] [:debug] [pid 7720] >>>> nss_engine_init.c(916): Enabling DHE key exchange >>>> [Fri Nov 18 09:34:33.370322 2016] [:debug] [pid 7720] >>>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>>> ciphers >>>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_25 >>>> 6,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ >>>> ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_ >>>> sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>>> [Fri Nov 18 09:34:33.370383 2016] [:debug] [pid 7720] >>>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>>> ... >>>> [Fri Nov 18 09:34:33.371418 2016] [:debug] [pid 7720] >>>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>>> [Fri Nov 18 09:34:33.371437 2016] [:info] [pid 7720] Using nickname >>>> ipaCert. >>>> [Fri Nov 18 09:34:33.371486 2016] [:info] [pid 7716] Configuring server >>>> for SSL protocol >>>> [Fri Nov 18 09:34:33.372383 2016] [:debug] [pid 7716] >>>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>>> [Fri Nov 18 09:34:33.372439 2016] [:debug] [pid 7716] >>>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>>> [Fri Nov 18 09:34:33.372459 2016] [:debug] [pid 7716] >>>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>>> [Fri Nov 18 09:34:33.372484 2016] [:debug] [pid 7716] >>>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>>> [Fri Nov 18 09:34:33.372513 2016] [:debug] [pid 7716] >>>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>>> [Fri Nov 18 09:34:33.372534 2016] [:debug] [pid 7716] >>>> nss_engine_init.c(906): Disabling TLS Session Tickets >>>> [Fri Nov 18 09:34:33.372553 2016] [:debug] [pid 7716] >>>> nss_engine_init.c(916): Enabling DHE key exchange >>>> [Fri Nov 18 09:34:33.372580 2016] [:debug] [pid 7716] >>>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>>> ciphers >>>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_25 >>>> 6,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ >>>> ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_ >>>> sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>>> [Fri Nov 18 09:34:33.372627 2016] [:debug] [pid 7716] >>>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>>> ... >>>> [Fri Nov 18 09:34:33.373712 2016] [:debug] [pid 7716] >>>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>>> [Fri Nov 18 09:34:33.373734 2016] [:info] [pid 7716] Using nickname >>>> ipaCert. >>>> [Fri Nov 18 09:34:33.374652 2016] [:error] [pid 7716] Misconfiguration >>>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>>> expected mlv-ipa01.ipa.mydomain.com >>>> as virtual name. >>>> [Fri Nov 18 09:34:33.372295 2016] [:error] [pid 7720] Misconfiguration >>>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>>> expected mlv-ipa01.ipa.mydomain.com >>>> >>>> as virtual name. >>>> [Fri Nov 18 09:34:33.412689 2016] [:info] [pid 7719] Configuring server >>>> for SSL protocol >>>> [Fri Nov 18 09:34:33.412791 2016] [:debug] [pid 7719] >>>> nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>>> [Fri Nov 18 09:34:33.412803 2016] [:debug] [pid 7719] >>>> nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>>> [Fri Nov 18 09:34:33.412807 2016] [:debug] [pid 7719] >>>> nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>>> [Fri Nov 18 09:34:33.412812 2016] [:debug] [pid 7719] >>>> nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>>> [Fri Nov 18 09:34:33.412817 2016] [:debug] [pid 7719] >>>> nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>>> [Fri Nov 18 09:34:33.412824 2016] [:debug] [pid 7719] >>>> nss_engine_init.c(906): Disabling TLS Session Tickets >>>> [Fri Nov 18 09:34:33.412828 2016] [:debug] [pid 7719] >>>> nss_engine_init.c(916): Enabling DHE key exchange >>>> [Fri Nov 18 09:34:33.412840 2016] [:debug] [pid 7719] >>>> nss_engine_init.c(1077): NSSCipherSuite: Configuring permitted SSL >>>> ciphers >>>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_25 >>>> 6,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ >>>> ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_ >>>> sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>>> [Fri Nov 18 09:34:33.412891 2016] [:debug] [pid 7719] >>>> nss_engine_init.c(1140): Disable cipher: rsa_null_md5 >>>> ... >>>> [Fri Nov 18 09:34:33.413159 2016] [:debug] [pid 7719] >>>> nss_engine_init.c(1140): Enable cipher: ecdhe_rsa_aes_128_gcm_sha_256 >>>> [Fri Nov 18 09:34:33.413164 2016] [:info] [pid 7719] Using nickname >>>> ipaCert. >>>> [Fri Nov 18 09:34:33.414462 2016] [:error] [pid 7719] Misconfiguration >>>> of certificate's CN and virtual name. The certificate CN has IPA RA. We >>>> expected mlv-ipa01.ipa.mydomain.com >>>> as virtual name. >>>> [Fri Nov 18 09:34:35.558286 2016] [:error] [pid 7715] ipa: WARNING: >>>> session memcached servers not running >>>> [Fri Nov 18 09:34:35.559653 2016] [:error] [pid 7714] ipa: WARNING: >>>> session memcached servers not running >>>> [Fri Nov 18 09:34:37.511457 2016] [:error] [pid 7714] ipa: INFO: *** >>>> PROCESS START *** >>>> [Fri Nov 18 09:34:37.517899 2016] [:error] [pid 7715] ipa: INFO: *** >>>> PROCESS START *** >>>> [Fri Nov 18 09:34:51.498536 2016] [:info] [pid 7717] Connection to child >>>> 1 established (server mlv-ipa01.ipa.mydomain.com >>>> , client 192.168.0.239) >>>> [Fri Nov 18 09:34:51.510292 2016] [:info] [pid 7717] SSL input filter >>>> read failed. >>>> [Fri Nov 18 09:34:51.510311 2016] [:error] [pid 7717] SSL Library Error: >>>> -12285 Unable to find the certificate or key necessary for >>>> authentication >>>> [Fri Nov 18 09:34:51.510356 2016] [:info] [pid 7717] Connection to child >>>> 1 closed (server mlv-ipa01.ipa.mydomain.com:443 >>>> , client 192.168.0.239) >>>> [Fri Nov 18 09:35:18.790760 2016] [mpm_prefork:notice] [pid 7709] >>>> AH00170: caught SIGWINCH, shutting down gracefully/ >>>> >>>> Is possible to delete /Server-Cert/ from //etc/httpd/alias/ and reimport >>>> it from the original certificates of /mlv-ipa01.ipa.mydomain.com >>>> /? >>>> Where are stored the original certificates? >>>> >>>> Hi Morgan, >>> >>> with ldapsearch you should be able to find the certificate: >>> ldapsearch -h ipaserver.ipadomain -p 389 -D "cn=directory manager" -w >>> password -LLL -b krbprincipalname=HTTP/ipaserver.ipadomain at IPADOMAIN >>> ,cn=services,cn=accounts,dc=IPADOMAIN >>> >>> The cert will be stored in the field "usercertificate". >>> >>> HTH, >>> Flo. >>> >>> Please let me know, thanks. >>>> Bye, Morgan >>>> >>>> 2016-11-17 17:09 GMT+01:00 Florence Blanc-Renaud >>> >: >>>> >>>> >>>> On 11/17/2016 04:51 PM, Morgan Marodin wrote: >>>> >>>> Hi Rob. >>>> >>>> I've just tried to remove the group write to the *.db files, but >>>> it's >>>> not the problem. >>>> /[root at mlv-ipa01 ~]# grep NSSNickname >>>> /etc/httpd/conf.d/nss.conf >>>> NSSNickname Server-Cert/ >>>> >>>> I've tried to run manually /dirsrv.target/ and >>>> /krb5kdc.service/, and it >>>> works, services went up. >>>> The same for /ntpd/, /named-pkcs11.service/, /smb.service/, >>>> /winbind.service/, /kadmin.service/, /memcached.service/ and >>>> /pki-tomcatd.target/. >>>> >>>> But if I try to start /httpd.service/: >>>> /[root at mlv-ipa01 ~]# tail -f /var/log/messages >>>> Nov 17 16:46:06 mlv-ipa01 systemd[1]: Starting The Apache HTTP >>>> Server... >>>> Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: ipa : >>>> INFO KDC >>>> proxy enabled >>>> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: main >>>> process >>>> exited, code=exited, status=1/FAILURE >>>> Nov 17 16:46:07 mlv-ipa01 kill: kill: cannot find process "" >>>> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service: control >>>> process >>>> exited, code=exited status=1 >>>> Nov 17 16:46:07 mlv-ipa01 systemd[1]: Failed to start The Apache >>>> HTTP >>>> Server. >>>> Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit httpd.service entered >>>> failed >>>> state. >>>> Nov 17 16:46:07 mlv-ipa01 systemd[1]: httpd.service failed./ >>>> >>>> Any other ideas? >>>> >>>> Hi, >>>> >>>> - Does the NSS Db contain the private key for Server-Cert? If yes, >>>> the command >>>> $ certutil -K -d /etc/httpd/alias/ -f /etc/httpd/alias/pwdfile.txt >>>> should display a line like this one: >>>> < 0> rsa 01a6cbd773f3d785ffa44233148dcb8ade266ea5 NSS >>>> Certificate DB:Server-Cert >>>> >>>> - Is your system running with SElinux enforcing? If yes, you can >>>> check if there were SElinux permission denials using >>>> $ ausearch -m avc --start recent >>>> >>>> - If the certificate was expired, I believe you would see a >>>> different message, but it doesn't hurt to check its validity >>>> $ certutil -L -d /etc/httpd/alias/ -n Server-Cert | egrep "Not >>>> Before|Not After" >>>> >>>> >>>> Flo. >>>> >>>> >>>> Please let me know, thanks. >>>> Morgan >>>> >>>> 2016-11-17 16:11 GMT+01:00 Rob Crittenden >>> >>>> >>: >>>> >>>> >>>> >>>> Morgan Marodin wrote: >>>> > Hi Florence. >>>> > >>>> > Thanks for your support. >>>> > >>>> > Yes, httpd is using /etc/httpd/alias as NSS DB. And seems >>>> that all >>>> > permissions and certificates are good: >>>> > /[root at mlv-ipa01 ~]# ls -l /etc/httpd/alias/ >>>> > total 184 >>>> > -r--r--r-- 1 root root 1345 Sep 7 2015 cacert.asc >>>> > -rw-rw---- 1 root apache 65536 Nov 17 11:06 cert8.db >>>> > -rw-r-----. 1 root apache 65536 Sep 4 2015 cert8.db.orig >>>> > -rw-------. 1 root root 4833 Sep 4 2015 install.log >>>> > -rw-rw---- 1 root apache 16384 Nov 17 11:06 key3.db >>>> > -rw-r-----. 1 root apache 16384 Sep 4 2015 key3.db.orig >>>> > lrwxrwxrwx 1 root root 24 Nov 17 10:24 >>>> libnssckbi.so -> >>>> > /usr/lib64/libnssckbi.so >>>> > -rw-rw---- 1 root apache 20 Sep 7 2015 pwdfile.txt >>>> > -rw-rw---- 1 root apache 16384 Sep 7 2015 secmod.db >>>> > -rw-r-----. 1 root apache 16384 Sep 4 2015 >>>> secmod.db.orig/ >>>> >>>> Eventually you'll want to remove group write on the *.db >>>> files. >>>> >>>> > And password validations seems ok, too: >>>> > /[root at mlv-ipa01 ~]# certutil -K -d /etc/httpd/alias/ -f >>>> > /etc/httpd/alias/pwdfile.txt >>>> good >>>> >>>> > Enabling mod-nss debug I can see these logs: >>>> > /[root at mlv-ipa01 ~]# tail -f /var/log/httpd/error_log >>>> > [Thu Nov 17 15:05:10.807603 2016] [suexec:notice] [pid >>>> 10660] AH01232: >>>> > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >>>> > [Thu Nov 17 15:05:10.807958 2016] [:warn] [pid 10660] >>>> > NSSSessionCacheTimeout is deprecated. Ignoring. >>>> > [Thu Nov 17 15:05:10.807991 2016] [:debug] [pid 10660] >>>> > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com >>>> >>>> >>> > >>>> > >>> >>>> >>>> >>> >> -> Server-Cert >>>> > [Thu Nov 17 15:05:11.002664 2016] [:info] [pid 10660] >>>> Configuring server >>>> > for SSL protocol >>>> > [Thu Nov 17 15:05:11.002817 2016] [:debug] [pid 10660] >>>> > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 >>>> > [Thu Nov 17 15:05:11.002838 2016] [:debug] [pid 10660] >>>> > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 >>>> > [Thu Nov 17 15:05:11.002847 2016] [:debug] [pid 10660] >>>> > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 >>>> > [Thu Nov 17 15:05:11.002856 2016] [:debug] [pid 10660] >>>> > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) >>>> > [Thu Nov 17 15:05:11.002876 2016] [:debug] [pid 10660] >>>> > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) >>>> > [Thu Nov 17 15:05:11.003099 2016] [:debug] [pid 10660] >>>> > nss_engine_init.c(906): Disabling TLS Session Tickets >>>> > [Thu Nov 17 15:05:11.003198 2016] [:debug] [pid 10660] >>>> > nss_engine_init.c(916): Enabling DHE key exchange >>>> > [Thu Nov 17 15:05:11.003313 2016] [:debug] [pid 10660] >>>> > nss_engine_init.c(1077): NSSCipherSuite: Configuring >>>> permitted SSL >>>> > ciphers >>>> > >>>> [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_ >>>> sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sh >>>> a_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_25 >>>> 6,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ >>>> ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_ >>>> sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] >>>> > [Thu Nov 17 15:05:11.003469 2016] [:debug] [pid 10660] >>>> > [Thu Nov 17 15:05:11.006759 2016] [:info] [pid 10660] >>>> Using nickname >>>> > Server-Cert. >>>> [snip] >>>> > [Thu Nov 17 15:05:11.006771 2016] [:error] [pid 10660] >>>> Certificate not >>>> > found: 'Server-Cert' >>>> >>>> Can you shows what this returns: >>>> >>>> # grep NSSNickname /etc/httpd/conf.d/nss.conf >>>> >>>> > Do you think there is a kerberos problem? >>>> >>>> It definitely is not. >>>> >>>> You can bring the system up in a minimal way by manually >>>> starting the >>>> dirsrv at EXAMPLE.COM >>>> > service >>>> >>>> and then >>>> krb5kdc. This will at least let your >>>> users authenticate. The management framework (GUI) runs >>>> through Apache >>>> so that will be down until we can get Apache started again. >>>> >>>> rob >>>> >>>> > >>>> > Please let me know, thanks. >>>> > Bye, Morgan >>>> > >>>> > 2016-11-17 14:39 GMT+01:00 Florence Blanc-Renaud >>>> >>> > >>>> > >>>> >>>: >>>> >>>> > >>>> > On 11/17/2016 12:09 PM, Morgan Marodin wrote: >>>> > >>>> > Hello. >>>> > >>>> > This morning I've tried to upgrade my IPA server, >>>> but the >>>> upgrade >>>> > failed, and now the service doesn't start! :( >>>> > >>>> > If I try lo launch the upgrade manually this is >>>> the output: >>>> > /[root at mlv-ipa01 download]# 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 >>>> > [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 >>>> > 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: >>>> > CalledProcessError: Command '/bin/systemctl start >>>> httpd.service' >>>> > returned non-zero exit status 1 >>>> > The ipa-server-upgrade command failed. See >>>> > /var/log/ipaupgrade.log for >>>> > more information/ >>>> > >>>> > These are error logs of Apache: >>>> > /[Thu Nov 17 11:48:45.498510 2016] [suexec:notice] >>>> [pid 5664] >>>> > AH01232: >>>> > suEXEC mechanism enabled (wrapper: >>>> /usr/sbin/suexec) >>>> > [Thu Nov 17 11:48:45.499220 2016] [:warn] [pid >>>> 5664] >>>> > NSSSessionCacheTimeout is deprecated. Ignoring. >>>> > [Thu Nov 17 11:48:45.830910 2016] [:error] [pid >>>> 5664] >>>> > Certificate not >>>> > found: 'Server-Cert'/ >>>> > >>>> > The problem seems to be the /Server-Cert /that >>>> could not >>>> be found. >>>> > But if I try to execute the certutil command >>>> manually I >>>> can see it:/ >>>> > [root at mlv-ipa01 log]# certutil -L -d >>>> /etc/httpd/alias/ >>>> > Certificate Nickname >>>> Trust >>>> > Attributes >>>> > >>>> > SSL,S/MIME,JAR/XPI >>>> > Signing-Cert >>>> u,u,u >>>> > ipaCert >>>> u,u,u >>>> > Server-Cert >>>> Pu,u,u >>>> > IPA.MYDOMAIN.COM >>>> >>>> >>>> > IPA >>>> > CA CT,C,C/ >>>> > >>>> > Could you help me? >>>> > What could I try to do to restart my service? >>>> > >>>> > Hi, >>>> > >>>> > I would first make sure that httpd is using >>>> /etc/httpd/alias >>>> as NSS >>>> > DB (check the directive NSSCertificateDatabase in >>>> > /etc/httpd/conf.d/nss.conf). >>>> > Then it may be a file permission issue: the NSS DB >>>> should >>>> belong to >>>> > root:apache (the relevant files are cert8.db, key3.db >>>> and >>>> secmod.db). >>>> > You should also find a pwdfile.txt in the same >>>> directory, >>>> containing >>>> > the NSS DB password. Check that the password is valid >>>> using >>>> > certutil -K -d /etc/httpd/alias/ -f >>>> /etc/httpd/alias/pwdfile.txt >>>> > (if the command succeeds then the password in pwdfile >>>> is OK). >>>> > >>>> > You can also enable mod-nss debug in >>>> /etc/httpd/conf/nss.conf by >>>> > setting "LogLevel debug", and check the output in >>>> > /var/log/httpd/error_log. >>>> > >>>> > HTH, >>>> > Flo. >>>> > >>>> > Thanks, Morgan >>>> > >>>> > >>>> > >>>> > -- >>>> > Manage your subscription for the Freeipa-users mailing >>>> list: >>>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>> > >>>> > >>> an/listinfo/freeipa-users >>>> >>>> >>> >> >>>> > Go to http://freeipa.org for more info on the project >>>> > >>>> > >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Nov 18 14:43:29 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 18 Nov 2016 09:43:29 -0500 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> <994f1c25-5c63-b0f0-1da4-6b4788331daf@redhat.com> Message-ID: <582F1391.3020109@redhat.com> Morgan Marodin wrote: > It works! > Thanks for your support. > > Anyway, I will try to update againt mod_nss package! :D Glad it's working for you. I'm curious what the backup database was for. Did you create that? rob > Bye! > > > 2016-11-18 15:21 GMT+01:00 Morgan Marodin >: > > A little good news. > > Downgrading the /mod_nss/ RPM package, and restoring the original > //etc/httpd/alias/ folder, /ipa-server-upgrade/ procedure has > finished well: > /# ipa-server-upgrade > Upgrading IPA: > [1/10]: stopping directory server > [2/10]: saving configuration > [3/10]: disabling listeners > [4/10]: enabling DS global lock > [5/10]: starting directory server > [6/10]: updating schema > [7/10]: upgrading server > [8/10]: stopping directory server > [9/10]: restoring configuration > [10/10]: starting directory server > 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 > [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] > Global forward policy in named.conf will be changed to "only" to > avoid conflicts with automatic empty zones > [Adding server_id to named.conf] > Changes to named.conf have been made, restart named > Custodia service is being configured > Configuring ipa-custodia > [1/5]: Generating ipa-custodia config file > [2/5]: Making sure custodia container exists > [3/5]: Generating ipa-custodia keys > [4/5]: starting ipa-custodia > [5/5]: configuring ipa-custodia to start on boot > Done configuring ipa-custodia. > [Upgrading CA schema] > CA schema update complete > [Verifying that CA audit signing cert has 2 year validity] > [Update certmonger certificate renewal configuration to version 5] > Configuring certmonger to stop tracking system certificates for CA > Certmonger certificate renewal configuration updated 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] > pki-tomcat configuration changed, restart pki-tomcat > [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 > Creating Custodia keys > Configuring key retriever > The IPA services were upgraded > The ipa-server-upgrade command was successful/ > > And Apache has started, BUT there is a problem with the web certificate: > /# tail -f /var/log/httpd/error_log > [Fri Nov 18 15:14:43.002268 2016] [:info] [pid 18673] Connection to > child 2 established (server mlv-ipa01.ipa.mydomain.com:443 > , client 192.168.0.252) > [Fri Nov 18 15:14:43.207349 2016] [:info] [pid 18673] SSL input > filter read failed. > [Fri Nov 18 15:14:43.207389 2016] [:error] [pid 18673] SSL Library > Error: -12285 Unable to find the certificate or key necessary for > authentication > [Fri Nov 18 15:14:43.207460 2016] [:info] [pid 18673] Connection to > child 2 closed (server mlv-ipa01.ipa.mydomain.com:443 > , client 192.168.0.252)/ > > How do you suggest to go on with my issue? > > Thanks, Morgan > > 2016-11-18 12:11 GMT+01:00 Morgan Marodin >: > > I've tried to add it to a new test folder, with a new > certificate nickname, and then to replace it to /nss.conf/. > > But the problem persists: > /# certutil -V -u V -d /etc/httpd/test -n ipa01cert > certutil: certificate is valid/ > > /# tail -f /var/log/httpd/error_log > / > /[Fri Nov 18 12:09:39.513833 2016] [suexec:notice] [pid 11552] > AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Fri Nov 18 12:09:39.514266 2016] [:warn] [pid 11552] > NSSSessionCacheTimeout is deprecated. Ignoring. > [Fri Nov 18 12:09:39.514299 2016] [:debug] [pid 11552] > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > -> ipa01cert > [Fri Nov 18 12:09:39.824880 2016] [:error] [pid 11552] The > server key database has not been initialized. > [Fri Nov 18 12:09:39.832443 2016] [:info] [pid 11552] > Configuring server for SSL protocol > ... > [Fri Nov 18 12:09:39.832676 2016] [:info] [pid 11552] Using > nickname ipa01cert. > [Fri Nov 18 12:09:39.832678 2016] [:error] [pid 11552] > Certificate not found: 'ipa01cert'/ > > I've found this guide:/ > Combine the server cert and key into a single file > # cp localhost.crt > Server-Cert.txt > # cat localhost.key >> Server-Cert.txt > Convert the server cert into a p12 file > # openssl pkcs12 -export -in Server-Cert.txt -out > Server-Cert.p12 -name "Server-Cert" > Now Import the Public and Private keys into the database at the > same time. > #pk12util -i /tmp/cert-files/Server-Cert.p12 -d /etc/httpd/alias > -n Server-Cert/ > > Where is stored the key certificate file? > > Thanks, Morgan > > > 2016-11-18 10:39 GMT+01:00 Florence Blanc-Renaud >: > > On 11/18/2016 10:04 AM, Morgan Marodin wrote: > > Hi Florence. > > I've tried to configure the wrong certificate in > nss.conf (/ipaCert/), > and with this Apache started. > So I think the problem is in the /Server-Cert/ stored in > //etc/httpd/alias/, even if all manul checks are ok. > > These are logs with the wrong certificate test: > /# tail -f /var/log/httpd/error_log/ > /[Fri Nov 18 09:34:32.583700 2016] [suexec:notice] [pid > 7709] AH01232: > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Fri Nov 18 09:34:32.584142 2016] [:warn] [pid 7709] > NSSSessionCacheTimeout is deprecated. Ignoring. > [Fri Nov 18 09:34:32.584178 2016] [:debug] [pid 7709] > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > > -> ipaCert > > [Fri Nov 18 09:34:32.844487 2016] [:info] [pid 7709] > Configuring server > for SSL protocol > [Fri Nov 18 09:34:32.844635 2016] [:debug] [pid 7709] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:32.844657 2016] [:debug] [pid 7709] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:32.844668 2016] [:debug] [pid 7709] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:32.844677 2016] [:debug] [pid 7709] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:32.844684 2016] [:debug] [pid 7709] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:32.844738 2016] [:debug] [pid 7709] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:32.844746 2016] [:debug] [pid 7709] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:32.844760 2016] [:debug] [pid 7709] > nss_engine_init.c(1077): NSSCipherSuite: Configuring > permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:32.844825 2016] [:debug] [pid 7709] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:32.845105 2016] [:debug] [pid 7709] > nss_engine_init.c(1140): Enable cipher: > ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:32.845110 2016] [:info] [pid 7709] > Using nickname ipaCert. > [Fri Nov 18 09:34:32.847451 2016] [:error] [pid 7709] > Misconfiguration > of certificate's CN and virtual name. The certificate CN > has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > > > > as virtual name. > [Fri Nov 18 09:34:33.028056 2016 ] > [auth_digest:notice] [pid 7709] > AH01757: generating secret for digest authentication ... > [Fri Nov 18 09:34:33.030039 2016 ] > [lbmethod_heartbeat:notice] [pid 7709] > AH02282: No slotmem from mod_heartmonitor > [Fri Nov 18 09:34:33.030122 2016 ] > [:warn] [pid 7709] > NSSSessionCacheTimeout is deprecated. Ignoring. > [Fri Nov 18 09:34:33.030176 2016 ] > [:debug] [pid 7709] > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > > -> ipaCert > > [Fri Nov 18 09:34:33.051481 2016 ] > [mpm_prefork:notice] [pid 7709] > AH00163: Apache/2.4.6 () mod_auth_gssapi/1.4.0 > mod_auth_kerb/5.4 > mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 > Python/2.7.5 configured > -- resuming normal operations > [Fri Nov 18 09:34:33.051551 2016 ] > [core:notice] [pid 7709] AH00094: > Command line: '/usr/sbin/httpd -D FOREGROUND' > [Fri Nov 18 09:34:33.096050 2016] [proxy:debug] [pid 7717] > proxy_util.c(1838): AH00924: worker ajp://localhost > shared already > initialized > [Fri Nov 18 09:34:33.096163 2016 ] > [proxy:debug] [pid 7717] > proxy_util.c(1880): AH00926: worker ajp://localhost > local already > initialized > ... > [Fri Nov 18 09:34:33.105626 2016] [proxy:debug] [pid 7719] > proxy_util.c(1838): AH00924: worker > unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ > shared already > initialized > [Fri Nov 18 09:34:33.105632 2016] [proxy:debug] [pid 7719] > proxy_util.c(1880): AH00926: worker > unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ > local already > initialized > [Fri Nov 18 09:34:33.342762 2016 ] > [:info] [pid 7717] Configuring server > for SSL protocol > [Fri Nov 18 09:34:33.342867 2016 ] > [:debug] [pid 7717] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:33.342880 2016 ] > [:debug] [pid 7717] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:33.342885 2016 ] > [:debug] [pid 7717] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:33.342890 2016 ] > [:debug] [pid 7717] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:33.342894 2016 ] > [:debug] [pid 7717] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:33.342900 2016 ] > [:debug] [pid 7717] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:33.342904 2016 ] > [:debug] [pid 7717] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:33.342917 2016 ] > [:debug] [pid 7717] > nss_engine_init.c(1077): NSSCipherSuite: Configuring > permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:33.342970 2016 ] > [:debug] [pid 7717] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:33.343233 2016 ] > [:debug] [pid 7717] > nss_engine_init.c(1140): Enable cipher: > ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:33.343237 2016 ] > [:info] [pid 7717] Using nickname ipaCert. > [Fri Nov 18 09:34:33.344533 2016 ] > [:error] [pid 7717] Misconfiguration > of certificate's CN and virtual name. The certificate CN > has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > > > > > as virtual name. > [Fri Nov 18 09:34:33.364061 2016 ] > [:info] [pid 7718] Configuring server > for SSL protocol > [Fri Nov 18 09:34:33.364156 2016 ] > [:debug] [pid 7718] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:33.364167 2016 ] > [:debug] [pid 7718] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:33.364172 2016 ] > [:debug] [pid 7718] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:33.364176 2016 ] > [:debug] [pid 7718] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:33.364180 2016 ] > [:debug] [pid 7718] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:33.364187 2016 ] > [:debug] [pid 7718] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:33.364191 2016 ] > [:debug] [pid 7718] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:33.364202 2016 ] > [:debug] [pid 7718] > nss_engine_init.c(1077): NSSCipherSuite: Configuring > permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:33.364240 2016 ] > [:debug] [pid 7718] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:33.364611 2016 ] > [:debug] [pid 7718] > nss_engine_init.c(1140): Enable cipher: > ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:33.364625 2016 ] > [:info] [pid 7718] Using nickname ipaCert. > [Fri Nov 18 09:34:33.365549 2016 ] > [:error] [pid 7718] Misconfiguration > of certificate's CN and virtual name. The certificate CN > has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > > > > > as virtual name. > [Fri Nov 18 09:34:33.369972 2016 ] > [:info] [pid 7720] Configuring server > for SSL protocol > [Fri Nov 18 09:34:33.370200 2016 ] > [:debug] [pid 7720] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:33.370224 2016 ] > [:debug] [pid 7720] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:33.370239 2016 ] > [:debug] [pid 7720] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:33.370255 2016 ] > [:debug] [pid 7720] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:33.370269 2016 ] > [:debug] [pid 7720] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:33.370286 2016 ] > [:debug] [pid 7720] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:33.370301 2016 ] > [:debug] [pid 7720] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:33.370322 2016 ] > [:debug] [pid 7720] > nss_engine_init.c(1077): NSSCipherSuite: Configuring > permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:33.370383 2016 ] > [:debug] [pid 7720] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:33.371418 2016 ] > [:debug] [pid 7720] > nss_engine_init.c(1140): Enable cipher: > ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:33.371437 2016 ] > [:info] [pid 7720] Using nickname ipaCert. > [Fri Nov 18 09:34:33.371486 2016 ] > [:info] [pid 7716] Configuring server > for SSL protocol > [Fri Nov 18 09:34:33.372383 2016 ] > [:debug] [pid 7716] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:33.372439 2016 ] > [:debug] [pid 7716] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:33.372459 2016 ] > [:debug] [pid 7716] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:33.372484 2016 ] > [:debug] [pid 7716] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:33.372513 2016 ] > [:debug] [pid 7716] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:33.372534 2016 ] > [:debug] [pid 7716] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:33.372553 2016 ] > [:debug] [pid 7716] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:33.372580 2016 ] > [:debug] [pid 7716] > nss_engine_init.c(1077): NSSCipherSuite: Configuring > permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:33.372627 2016 ] > [:debug] [pid 7716] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:33.373712 2016 ] > [:debug] [pid 7716] > nss_engine_init.c(1140): Enable cipher: > ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:33.373734 2016 ] > [:info] [pid 7716] Using nickname ipaCert. > [Fri Nov 18 09:34:33.374652 2016 ] > [:error] [pid 7716] Misconfiguration > of certificate's CN and virtual name. The certificate CN > has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > > > > as virtual name. > [Fri Nov 18 09:34:33.372295 2016 ] > [:error] [pid 7720] Misconfiguration > of certificate's CN and virtual name. The certificate CN > has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > > > > > as virtual name. > [Fri Nov 18 09:34:33.412689 2016] [:info] [pid 7719] > Configuring server > for SSL protocol > [Fri Nov 18 09:34:33.412791 2016] [:debug] [pid 7719] > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > [Fri Nov 18 09:34:33.412803 2016] [:debug] [pid 7719] > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > [Fri Nov 18 09:34:33.412807 2016] [:debug] [pid 7719] > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > [Fri Nov 18 09:34:33.412812 2016] [:debug] [pid 7719] > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > [Fri Nov 18 09:34:33.412817 2016] [:debug] [pid 7719] > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > [Fri Nov 18 09:34:33.412824 2016] [:debug] [pid 7719] > nss_engine_init.c(906): Disabling TLS Session Tickets > [Fri Nov 18 09:34:33.412828 2016] [:debug] [pid 7719] > nss_engine_init.c(916): Enabling DHE key exchange > [Fri Nov 18 09:34:33.412840 2016] [:debug] [pid 7719] > nss_engine_init.c(1077): NSSCipherSuite: Configuring > permitted SSL > ciphers > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > [Fri Nov 18 09:34:33.412891 2016] [:debug] [pid 7719] > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > ... > [Fri Nov 18 09:34:33.413159 2016] [:debug] [pid 7719] > nss_engine_init.c(1140): Enable cipher: > ecdhe_rsa_aes_128_gcm_sha_256 > [Fri Nov 18 09:34:33.413164 2016] [:info] [pid 7719] > Using nickname ipaCert. > [Fri Nov 18 09:34:33.414462 2016] [:error] [pid 7719] > Misconfiguration > of certificate's CN and virtual name. The certificate CN > has IPA RA. We > expected mlv-ipa01.ipa.mydomain.com > > > > as virtual name. > [Fri Nov 18 09:34:35.558286 2016 ] > [:error] [pid 7715] ipa: WARNING: > session memcached servers not running > [Fri Nov 18 09:34:35.559653 2016 ] > [:error] [pid 7714] ipa: WARNING: > session memcached servers not running > [Fri Nov 18 09:34:37.511457 2016] [:error] [pid 7714] > ipa: INFO: *** > PROCESS START *** > [Fri Nov 18 09:34:37.517899 2016] [:error] [pid 7715] > ipa: INFO: *** > PROCESS START *** > [Fri Nov 18 09:34:51.498536 2016] [:info] [pid 7717] > Connection to child > 1 established (server mlv-ipa01.ipa.mydomain.com > > >, client 192.168.0.239) > [Fri Nov 18 09:34:51.510292 2016] [:info] [pid 7717] SSL > input filter > read failed. > [Fri Nov 18 09:34:51.510311 2016] [:error] [pid 7717] > SSL Library Error: > -12285 Unable to find the certificate or key necessary > for authentication > [Fri Nov 18 09:34:51.510356 2016] [:info] [pid 7717] > Connection to child > 1 closed (server mlv-ipa01.ipa.mydomain.com:443 > > >, client > 192.168.0.239) > [Fri Nov 18 09:35:18.790760 2016] [mpm_prefork:notice] > [pid 7709] > AH00170: caught SIGWINCH, shutting down gracefully/ > > Is possible to delete /Server-Cert/ from > //etc/httpd/alias/ and reimport > it from the original certificates of > /mlv-ipa01.ipa.mydomain.com > > >/? > Where are stored the original certificates? > > Hi Morgan, > > with ldapsearch you should be able to find the certificate: > ldapsearch -h ipaserver.ipadomain -p 389 -D "cn=directory > manager" -w password -LLL -b > krbprincipalname=HTTP/ipaserver.ipadomain at IPADOMAIN,cn=services,cn=accounts,dc=IPADOMAIN > > The cert will be stored in the field "usercertificate". > > HTH, > Flo. > > Please let me know, thanks. > Bye, Morgan > > 2016-11-17 17:09 GMT+01:00 Florence Blanc-Renaud > > >>: > > > On 11/17/2016 04:51 PM, Morgan Marodin wrote: > > Hi Rob. > > I've just tried to remove the group write to the > *.db files, but > it's > not the problem. > /[root at mlv-ipa01 ~]# grep NSSNickname > /etc/httpd/conf.d/nss.conf > NSSNickname Server-Cert/ > > I've tried to run manually /dirsrv.target/ and > /krb5kdc.service/, and it > works, services went up. > The same for /ntpd/, /named-pkcs11.service/, > /smb.service/, > /winbind.service/, /kadmin.service/, > /memcached.service/ and > /pki-tomcatd.target/. > > But if I try to start /httpd.service/: > /[root at mlv-ipa01 ~]# tail -f /var/log/messages > Nov 17 16:46:06 mlv-ipa01 systemd[1]: Starting > The Apache HTTP > Server... > Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: > ipa : > INFO KDC > proxy enabled > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > httpd.service: main process > exited, code=exited, status=1/FAILURE > Nov 17 16:46:07 mlv-ipa01 kill: kill: cannot > find process "" > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > httpd.service: control process > exited, code=exited status=1 > Nov 17 16:46:07 mlv-ipa01 systemd[1]: Failed to > start The Apache > HTTP > Server. > Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit > httpd.service entered > failed > state. > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > httpd.service failed./ > > Any other ideas? > > Hi, > > - Does the NSS Db contain the private key for > Server-Cert? If yes, > the command > $ certutil -K -d /etc/httpd/alias/ -f > /etc/httpd/alias/pwdfile.txt > should display a line like this one: > < 0> rsa > 01a6cbd773f3d785ffa44233148dcb8ade266ea5 NSS > Certificate DB:Server-Cert > > - Is your system running with SElinux enforcing? If > yes, you can > check if there were SElinux permission denials using > $ ausearch -m avc --start recent > > - If the certificate was expired, I believe you > would see a > different message, but it doesn't hurt to check its > validity > $ certutil -L -d /etc/httpd/alias/ -n Server-Cert | > egrep "Not > Before|Not After" > > > Flo. > > > Please let me know, thanks. > Morgan > > 2016-11-17 16:11 GMT+01:00 Rob Crittenden > > > > >>>: > > > > Morgan Marodin wrote: > > Hi Florence. > > > > Thanks for your support. > > > > Yes, httpd is using /etc/httpd/alias as > NSS DB. And seems > that all > > permissions and certificates are good: > > /[root at mlv-ipa01 ~]# ls -l /etc/httpd/alias/ > > total 184 > > -r--r--r-- 1 root root 1345 Sep 7 > 2015 cacert.asc > > -rw-rw---- 1 root apache 65536 Nov 17 > 11:06 cert8.db > > -rw-r-----. 1 root apache 65536 Sep 4 > 2015 cert8.db.orig > > -rw-------. 1 root root 4833 Sep 4 > 2015 install.log > > -rw-rw---- 1 root apache 16384 Nov 17 > 11:06 key3.db > > -rw-r-----. 1 root apache 16384 Sep 4 > 2015 key3.db.orig > > lrwxrwxrwx 1 root root 24 Nov 17 > 10:24 libnssckbi.so -> > > /usr/lib64/libnssckbi.so > > -rw-rw---- 1 root apache 20 Sep 7 > 2015 pwdfile.txt > > -rw-rw---- 1 root apache 16384 Sep 7 > 2015 secmod.db > > -rw-r-----. 1 root apache 16384 Sep 4 > 2015 secmod.db.orig/ > > Eventually you'll want to remove group write > on the *.db files. > > > And password validations seems ok, too: > > /[root at mlv-ipa01 ~]# certutil -K -d > /etc/httpd/alias/ -f > > /etc/httpd/alias/pwdfile.txt > good > > > Enabling mod-nss debug I can see these logs: > > /[root at mlv-ipa01 ~]# tail -f > /var/log/httpd/error_log > > [Thu Nov 17 15:05:10.807603 2016] > [suexec:notice] [pid > 10660] AH01232: > > suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > > [Thu Nov 17 15:05:10.807958 2016] [:warn] > [pid 10660] > > NSSSessionCacheTimeout is deprecated. > Ignoring. > > [Thu Nov 17 15:05:10.807991 2016] [:debug] > [pid 10660] > > nss_engine_init.c(454): SNI: > mlv-ipa01.ipa.mydomain.com > > > > > >> > > > > > > > >>> -> Server-Cert > > [Thu Nov 17 15:05:11.002664 2016] [:info] > [pid 10660] > Configuring server > > for SSL protocol > > [Thu Nov 17 15:05:11.002817 2016] [:debug] > [pid 10660] > > nss_engine_init.c(770): NSSProtocol: > Enabling TLSv1.0 > > [Thu Nov 17 15:05:11.002838 2016] [:debug] > [pid 10660] > > nss_engine_init.c(775): NSSProtocol: > Enabling TLSv1.1 > > [Thu Nov 17 15:05:11.002847 2016] [:debug] > [pid 10660] > > nss_engine_init.c(780): NSSProtocol: > Enabling TLSv1.2 > > [Thu Nov 17 15:05:11.002856 2016] [:debug] > [pid 10660] > > nss_engine_init.c(839): NSSProtocol: [TLS > 1.0] (minimum) > > [Thu Nov 17 15:05:11.002876 2016] [:debug] > [pid 10660] > > nss_engine_init.c(866): NSSProtocol: [TLS > 1.2] (maximum) > > [Thu Nov 17 15:05:11.003099 2016] [:debug] > [pid 10660] > > nss_engine_init.c(906): Disabling TLS > Session Tickets > > [Thu Nov 17 15:05:11.003198 2016] [:debug] > [pid 10660] > > nss_engine_init.c(916): Enabling DHE key > exchange > > [Thu Nov 17 15:05:11.003313 2016] [:debug] > [pid 10660] > > nss_engine_init.c(1077): NSSCipherSuite: > Configuring > permitted SSL > > ciphers > > > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Thu Nov 17 15:05:11.003469 2016] [:debug] > [pid 10660] > > [Thu Nov 17 15:05:11.006759 2016] [:info] > [pid 10660] > Using nickname > > Server-Cert. > [snip] > > [Thu Nov 17 15:05:11.006771 2016] [:error] > [pid 10660] > Certificate not > > found: 'Server-Cert' > > Can you shows what this returns: > > # grep NSSNickname /etc/httpd/conf.d/nss.conf > > > Do you think there is a kerberos problem? > > It definitely is not. > > You can bring the system up in a minimal way > by manually > starting the > dirsrv at EXAMPLE.COM > > > >> service > > and then > krb5kdc. This will at least let your > users authenticate. The management framework > (GUI) runs > through Apache > so that will be down until we can get Apache > started again. > > rob > > > > > Please let me know, thanks. > > Bye, Morgan > > > > 2016-11-17 14:39 GMT+01:00 Florence > Blanc-Renaud > > > > > >> > > > > > >>>>: > > > > > On 11/17/2016 12:09 PM, Morgan Marodin > wrote: > > > > Hello. > > > > This morning I've tried to upgrade > my IPA server, > but the > upgrade > > failed, and now the service > doesn't start! :( > > > > If I try lo launch the upgrade > manually this is > the output: > > /[root at mlv-ipa01 download]# > 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 > > [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 > > 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: > > CalledProcessError: Command > '/bin/systemctl start > httpd.service' > > returned non-zero exit status 1 > > The ipa-server-upgrade command > failed. See > > /var/log/ipaupgrade.log for > > more information/ > > > > These are error logs of Apache: > > /[Thu Nov 17 11:48:45.498510 2016] > [suexec:notice] > [pid 5664] > > AH01232: > > suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > > [Thu Nov 17 11:48:45.499220 2016] > [:warn] [pid 5664] > > NSSSessionCacheTimeout is > deprecated. Ignoring. > > [Thu Nov 17 11:48:45.830910 2016] > [:error] [pid 5664] > > Certificate not > > found: 'Server-Cert'/ > > > > The problem seems to be the > /Server-Cert /that > could not > be found. > > But if I try to execute the > certutil command > manually I > can see it:/ > > [root at mlv-ipa01 log]# certutil -L > -d /etc/httpd/alias/ > > Certificate Nickname > Trust > > Attributes > > > > SSL,S/MIME,JAR/XPI > > Signing-Cert > u,u,u > > ipaCert > u,u,u > > Server-Cert > Pu,u,u > > IPA.MYDOMAIN.COM > > > > > IPA > > CA > CT,C,C/ > > > > Could you help me? > > What could I try to do to restart > my service? > > > > Hi, > > > > I would first make sure that httpd is > using > /etc/httpd/alias > as NSS > > DB (check the directive > NSSCertificateDatabase in > > /etc/httpd/conf.d/nss.conf). > > Then it may be a file permission > issue: the NSS DB should > belong to > > root:apache (the relevant files are > cert8.db, key3.db and > secmod.db). > > You should also find a pwdfile.txt in > the same directory, > containing > > the NSS DB password. Check that the > password is valid > using > > certutil -K -d /etc/httpd/alias/ -f > /etc/httpd/alias/pwdfile.txt > > (if the command succeeds then the > password in pwdfile > is OK). > > > > You can also enable mod-nss debug in > /etc/httpd/conf/nss.conf by > > setting "LogLevel debug", and check > the output in > > /var/log/httpd/error_log. > > > > HTH, > > Flo. > > > > Thanks, Morgan > > > > > > > > -- > > 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 deepak.dimri2016 at gmail.com Fri Nov 18 14:49:08 2016 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Fri, 18 Nov 2016 20:19:08 +0530 Subject: [Freeipa-users] Getting "Your session has expired. Please re-login." when trying to access IPA Replica In-Reply-To: References: Message-ID: Got it working, after uninstalling and reinstalling the replica. Not sure why it did not work at the first place... On Fri, Nov 18, 2016 at 7:15 PM, deepak dimri wrote: > Hello All, > > I have IPA Master deployed in AWS US West region and replica in US East > region. The replication installation went successfully however when i am > trying to access the replication web UI (after making proxypass changes > etc..) i am getting Error. I have ProxyPassReverseCookieDomain set > correctly but still i get the error. Master & Replica are time > synchronized. Can come please help me with this? I have tried it in all > kinds of browser but no luck. > > i have followed this document in setting up the reverse proxy > https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name. > > Thanks, > Deepak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morgan at marodin.it Fri Nov 18 15:03:56 2016 From: morgan at marodin.it (Morgan Marodin) Date: Fri, 18 Nov 2016 16:03:56 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: <582F1391.3020109@redhat.com> References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> <994f1c25-5c63-b0f0-1da4-6b4788331daf@redhat.com> <582F1391.3020109@redhat.com> Message-ID: What do you mean with backup database? Updating again the mod_nss RPM, Apache doesn't start ... so, this is the problem. 2016-11-18 15:43 GMT+01:00 Rob Crittenden : > Morgan Marodin wrote: > > It works! > > Thanks for your support. > > > > Anyway, I will try to update againt mod_nss package! :D > > Glad it's working for you. I'm curious what the backup database was for. > Did you create that? > > rob > > > Bye! > > > > > > 2016-11-18 15:21 GMT+01:00 Morgan Marodin > >: > > > > A little good news. > > > > Downgrading the /mod_nss/ RPM package, and restoring the original > > //etc/httpd/alias/ folder, /ipa-server-upgrade/ procedure has > > finished well: > > /# ipa-server-upgrade > > Upgrading IPA: > > [1/10]: stopping directory server > > [2/10]: saving configuration > > [3/10]: disabling listeners > > [4/10]: enabling DS global lock > > [5/10]: starting directory server > > [6/10]: updating schema > > [7/10]: upgrading server > > [8/10]: stopping directory server > > [9/10]: restoring configuration > > [10/10]: starting directory server > > 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 > > [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] > > Global forward policy in named.conf will be changed to "only" to > > avoid conflicts with automatic empty zones > > [Adding server_id to named.conf] > > Changes to named.conf have been made, restart named > > Custodia service is being configured > > Configuring ipa-custodia > > [1/5]: Generating ipa-custodia config file > > [2/5]: Making sure custodia container exists > > [3/5]: Generating ipa-custodia keys > > [4/5]: starting ipa-custodia > > [5/5]: configuring ipa-custodia to start on boot > > Done configuring ipa-custodia. > > [Upgrading CA schema] > > CA schema update complete > > [Verifying that CA audit signing cert has 2 year validity] > > [Update certmonger certificate renewal configuration to version 5] > > Configuring certmonger to stop tracking system certificates for CA > > Certmonger certificate renewal configuration updated 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] > > pki-tomcat configuration changed, restart pki-tomcat > > [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 > > Creating Custodia keys > > Configuring key retriever > > The IPA services were upgraded > > The ipa-server-upgrade command was successful/ > > > > And Apache has started, BUT there is a problem with the web > certificate: > > /# tail -f /var/log/httpd/error_log > > [Fri Nov 18 15:14:43.002268 2016] [:info] [pid 18673] Connection to > > child 2 established (server mlv-ipa01.ipa.mydomain.com:443 > > , client 192.168.0.252) > > [Fri Nov 18 15:14:43.207349 2016] [:info] [pid 18673] SSL input > > filter read failed. > > [Fri Nov 18 15:14:43.207389 2016] [:error] [pid 18673] SSL Library > > Error: -12285 Unable to find the certificate or key necessary for > > authentication > > [Fri Nov 18 15:14:43.207460 2016] [:info] [pid 18673] Connection to > > child 2 closed (server mlv-ipa01.ipa.mydomain.com:443 > > , client 192.168.0.252)/ > > > > How do you suggest to go on with my issue? > > > > Thanks, Morgan > > > > 2016-11-18 12:11 GMT+01:00 Morgan Marodin > >: > > > > I've tried to add it to a new test folder, with a new > > certificate nickname, and then to replace it to /nss.conf/. > > > > But the problem persists: > > /# certutil -V -u V -d /etc/httpd/test -n ipa01cert > > certutil: certificate is valid/ > > > > /# tail -f /var/log/httpd/error_log > > / > > /[Fri Nov 18 12:09:39.513833 2016] [suexec:notice] [pid 11552] > > AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > > [Fri Nov 18 12:09:39.514266 2016] [:warn] [pid 11552] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Fri Nov 18 12:09:39.514299 2016] [:debug] [pid 11552] > > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > -> ipa01cert > > [Fri Nov 18 12:09:39.824880 2016] [:error] [pid 11552] The > > server key database has not been initialized. > > [Fri Nov 18 12:09:39.832443 2016] [:info] [pid 11552] > > Configuring server for SSL protocol > > ... > > [Fri Nov 18 12:09:39.832676 2016] [:info] [pid 11552] Using > > nickname ipa01cert. > > [Fri Nov 18 12:09:39.832678 2016] [:error] [pid 11552] > > Certificate not found: 'ipa01cert'/ > > > > I've found this guide:/ > > Combine the server cert and key into a single file > > # cp localhost.crt > Server-Cert.txt > > # cat localhost.key >> Server-Cert.txt > > Convert the server cert into a p12 file > > # openssl pkcs12 -export -in Server-Cert.txt -out > > Server-Cert.p12 -name "Server-Cert" > > Now Import the Public and Private keys into the database at the > > same time. > > #pk12util -i /tmp/cert-files/Server-Cert.p12 -d /etc/httpd/alias > > -n Server-Cert/ > > > > Where is stored the key certificate file? > > > > Thanks, Morgan > > > > > > 2016-11-18 10:39 GMT+01:00 Florence Blanc-Renaud > >: > > > > On 11/18/2016 10:04 AM, Morgan Marodin wrote: > > > > Hi Florence. > > > > I've tried to configure the wrong certificate in > > nss.conf (/ipaCert/), > > and with this Apache started. > > So I think the problem is in the /Server-Cert/ stored in > > //etc/httpd/alias/, even if all manul checks are ok. > > > > These are logs with the wrong certificate test: > > /# tail -f /var/log/httpd/error_log/ > > /[Fri Nov 18 09:34:32.583700 2016] [suexec:notice] [pid > > 7709] AH01232: > > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > > [Fri Nov 18 09:34:32.584142 2016] [:warn] [pid 7709] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Fri Nov 18 09:34:32.584178 2016] [:debug] [pid 7709] > > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > > > > > -> ipaCert > > > > [Fri Nov 18 09:34:32.844487 2016] [:info] [pid 7709] > > Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:32.844635 2016] [:debug] [pid 7709] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:32.844657 2016] [:debug] [pid 7709] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:32.844668 2016] [:debug] [pid 7709] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:32.844677 2016] [:debug] [pid 7709] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Fri Nov 18 09:34:32.844684 2016] [:debug] [pid 7709] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Fri Nov 18 09:34:32.844738 2016] [:debug] [pid 7709] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:32.844746 2016] [:debug] [pid 7709] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:32.844760 2016] [:debug] [pid 7709] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:32.844825 2016] [:debug] [pid 7709] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:32.845105 2016] [:debug] [pid 7709] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:32.845110 2016] [:info] [pid 7709] > > Using nickname ipaCert. > > [Fri Nov 18 09:34:32.847451 2016] [:error] [pid 7709] > > Misconfiguration > > of certificate's CN and virtual name. The certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > > as virtual name. > > [Fri Nov 18 09:34:33.028056 2016 ] > > [auth_digest:notice] [pid 7709] > > AH01757: generating secret for digest authentication ... > > [Fri Nov 18 09:34:33.030039 2016 ] > > [lbmethod_heartbeat:notice] [pid 7709] > > AH02282: No slotmem from mod_heartmonitor > > [Fri Nov 18 09:34:33.030122 2016 ] > > [:warn] [pid 7709] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Fri Nov 18 09:34:33.030176 2016 ] > > [:debug] [pid 7709] > > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > > > > > -> ipaCert > > > > [Fri Nov 18 09:34:33.051481 2016 ] > > [mpm_prefork:notice] [pid 7709] > > AH00163: Apache/2.4.6 () mod_auth_gssapi/1.4.0 > > mod_auth_kerb/5.4 > > mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 > > Python/2.7.5 configured > > -- resuming normal operations > > [Fri Nov 18 09:34:33.051551 2016 ] > > [core:notice] [pid 7709] AH00094: > > Command line: '/usr/sbin/httpd -D FOREGROUND' > > [Fri Nov 18 09:34:33.096050 2016] [proxy:debug] [pid > 7717] > > proxy_util.c(1838): AH00924: worker ajp://localhost > > shared already > > initialized > > [Fri Nov 18 09:34:33.096163 2016 ] > > [proxy:debug] [pid 7717] > > proxy_util.c(1880): AH00926: worker ajp://localhost > > local already > > initialized > > ... > > [Fri Nov 18 09:34:33.105626 2016] [proxy:debug] [pid > 7719] > > proxy_util.c(1838): AH00924: worker > > unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ > > shared already > > initialized > > [Fri Nov 18 09:34:33.105632 2016] [proxy:debug] [pid > 7719] > > proxy_util.c(1880): AH00926: worker > > unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ > > local already > > initialized > > [Fri Nov 18 09:34:33.342762 2016 ] > > [:info] [pid 7717] Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:33.342867 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:33.342880 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:33.342885 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:33.342890 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Fri Nov 18 09:34:33.342894 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Fri Nov 18 09:34:33.342900 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:33.342904 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:33.342917 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:33.342970 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:33.343233 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:33.343237 2016 ] > > [:info] [pid 7717] Using nickname ipaCert. > > [Fri Nov 18 09:34:33.344533 2016 ] > > [:error] [pid 7717] Misconfiguration > > of certificate's CN and virtual name. The certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > > > > as virtual name. > > [Fri Nov 18 09:34:33.364061 2016 ] > > [:info] [pid 7718] Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:33.364156 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:33.364167 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:33.364172 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:33.364176 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Fri Nov 18 09:34:33.364180 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Fri Nov 18 09:34:33.364187 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:33.364191 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:33.364202 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:33.364240 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:33.364611 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:33.364625 2016 ] > > [:info] [pid 7718] Using nickname ipaCert. > > [Fri Nov 18 09:34:33.365549 2016 ] > > [:error] [pid 7718] Misconfiguration > > of certificate's CN and virtual name. The certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > > > > as virtual name. > > [Fri Nov 18 09:34:33.369972 2016 ] > > [:info] [pid 7720] Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:33.370200 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:33.370224 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:33.370239 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:33.370255 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Fri Nov 18 09:34:33.370269 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Fri Nov 18 09:34:33.370286 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:33.370301 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:33.370322 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:33.370383 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:33.371418 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:33.371437 2016 ] > > [:info] [pid 7720] Using nickname ipaCert. > > [Fri Nov 18 09:34:33.371486 2016 ] > > [:info] [pid 7716] Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:33.372383 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:33.372439 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:33.372459 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:33.372484 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Fri Nov 18 09:34:33.372513 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Fri Nov 18 09:34:33.372534 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:33.372553 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:33.372580 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:33.372627 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:33.373712 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:33.373734 2016 ] > > [:info] [pid 7716] Using nickname ipaCert. > > [Fri Nov 18 09:34:33.374652 2016 ] > > [:error] [pid 7716] Misconfiguration > > of certificate's CN and virtual name. The certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > > as virtual name. > > [Fri Nov 18 09:34:33.372295 2016 ] > > [:error] [pid 7720] Misconfiguration > > of certificate's CN and virtual name. The certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > > > > as virtual name. > > [Fri Nov 18 09:34:33.412689 2016] [:info] [pid 7719] > > Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:33.412791 2016] [:debug] [pid 7719] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:33.412803 2016] [:debug] [pid 7719] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:33.412807 2016] [:debug] [pid 7719] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:33.412812 2016] [:debug] [pid 7719] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Fri Nov 18 09:34:33.412817 2016] [:debug] [pid 7719] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Fri Nov 18 09:34:33.412824 2016] [:debug] [pid 7719] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:33.412828 2016] [:debug] [pid 7719] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:33.412840 2016] [:debug] [pid 7719] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:33.412891 2016] [:debug] [pid 7719] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:33.413159 2016] [:debug] [pid 7719] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:33.413164 2016] [:info] [pid 7719] > > Using nickname ipaCert. > > [Fri Nov 18 09:34:33.414462 2016] [:error] [pid 7719] > > Misconfiguration > > of certificate's CN and virtual name. The certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > > as virtual name. > > [Fri Nov 18 09:34:35.558286 2016 ] > > [:error] [pid 7715] ipa: WARNING: > > session memcached servers not running > > [Fri Nov 18 09:34:35.559653 2016 ] > > [:error] [pid 7714] ipa: WARNING: > > session memcached servers not running > > [Fri Nov 18 09:34:37.511457 2016] [:error] [pid 7714] > > ipa: INFO: *** > > PROCESS START *** > > [Fri Nov 18 09:34:37.517899 2016] [:error] [pid 7715] > > ipa: INFO: *** > > PROCESS START *** > > [Fri Nov 18 09:34:51.498536 2016] [:info] [pid 7717] > > Connection to child > > 1 established (server mlv-ipa01.ipa.mydomain.com > > > > > >, client > 192.168.0.239) > > [Fri Nov 18 09:34:51.510292 2016] [:info] [pid 7717] SSL > > input filter > > read failed. > > [Fri Nov 18 09:34:51.510311 2016] [:error] [pid 7717] > > SSL Library Error: > > -12285 Unable to find the certificate or key necessary > > for authentication > > [Fri Nov 18 09:34:51.510356 2016] [:info] [pid 7717] > > Connection to child > > 1 closed (server mlv-ipa01.ipa.mydomain.com:443 > > > > > >, client > > 192.168.0.239) > > [Fri Nov 18 09:35:18.790760 2016] [mpm_prefork:notice] > > [pid 7709] > > AH00170: caught SIGWINCH, shutting down gracefully/ > > > > Is possible to delete /Server-Cert/ from > > //etc/httpd/alias/ and reimport > > it from the original certificates of > > /mlv-ipa01.ipa.mydomain.com > > > > > >/? > > Where are stored the original certificates? > > > > Hi Morgan, > > > > with ldapsearch you should be able to find the certificate: > > ldapsearch -h ipaserver.ipadomain -p 389 -D "cn=directory > > manager" -w password -LLL -b > > krbprincipalname=HTTP/ipaserver.ipadomain at IPADOMAIN, > cn=services,cn=accounts,dc=IPADOMAIN > > > > The cert will be stored in the field "usercertificate". > > > > HTH, > > Flo. > > > > Please let me know, thanks. > > Bye, Morgan > > > > 2016-11-17 17:09 GMT+01:00 Florence Blanc-Renaud > > > > >>: > > > > > > On 11/17/2016 04:51 PM, Morgan Marodin wrote: > > > > Hi Rob. > > > > I've just tried to remove the group write to the > > *.db files, but > > it's > > not the problem. > > /[root at mlv-ipa01 ~]# grep NSSNickname > > /etc/httpd/conf.d/nss.conf > > NSSNickname Server-Cert/ > > > > I've tried to run manually /dirsrv.target/ and > > /krb5kdc.service/, and it > > works, services went up. > > The same for /ntpd/, /named-pkcs11.service/, > > /smb.service/, > > /winbind.service/, /kadmin.service/, > > /memcached.service/ and > > /pki-tomcatd.target/. > > > > But if I try to start /httpd.service/: > > /[root at mlv-ipa01 ~]# tail -f /var/log/messages > > Nov 17 16:46:06 mlv-ipa01 systemd[1]: Starting > > The Apache HTTP > > Server... > > Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: > > ipa : > > INFO KDC > > proxy enabled > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > > httpd.service: main process > > exited, code=exited, status=1/FAILURE > > Nov 17 16:46:07 mlv-ipa01 kill: kill: cannot > > find process "" > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > > httpd.service: control process > > exited, code=exited status=1 > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: Failed to > > start The Apache > > HTTP > > Server. > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit > > httpd.service entered > > failed > > state. > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > > httpd.service failed./ > > > > Any other ideas? > > > > Hi, > > > > - Does the NSS Db contain the private key for > > Server-Cert? If yes, > > the command > > $ certutil -K -d /etc/httpd/alias/ -f > > /etc/httpd/alias/pwdfile.txt > > should display a line like this one: > > < 0> rsa > > 01a6cbd773f3d785ffa44233148dcb8ade266ea5 NSS > > Certificate DB:Server-Cert > > > > - Is your system running with SElinux enforcing? If > > yes, you can > > check if there were SElinux permission denials using > > $ ausearch -m avc --start recent > > > > - If the certificate was expired, I believe you > > would see a > > different message, but it doesn't hurt to check its > > validity > > $ certutil -L -d /etc/httpd/alias/ -n Server-Cert | > > egrep "Not > > Before|Not After" > > > > > > Flo. > > > > > > Please let me know, thanks. > > Morgan > > > > 2016-11-17 16:11 GMT+01:00 Rob Crittenden > > > > > > > > > > >>>: > > > > > > > > Morgan Marodin wrote: > > > Hi Florence. > > > > > > Thanks for your support. > > > > > > Yes, httpd is using /etc/httpd/alias as > > NSS DB. And seems > > that all > > > permissions and certificates are good: > > > /[root at mlv-ipa01 ~]# ls -l > /etc/httpd/alias/ > > > total 184 > > > -r--r--r-- 1 root root 1345 Sep 7 > > 2015 cacert.asc > > > -rw-rw---- 1 root apache 65536 Nov 17 > > 11:06 cert8.db > > > -rw-r-----. 1 root apache 65536 Sep 4 > > 2015 cert8.db.orig > > > -rw-------. 1 root root 4833 Sep 4 > > 2015 install.log > > > -rw-rw---- 1 root apache 16384 Nov 17 > > 11:06 key3.db > > > -rw-r-----. 1 root apache 16384 Sep 4 > > 2015 key3.db.orig > > > lrwxrwxrwx 1 root root 24 Nov 17 > > 10:24 libnssckbi.so -> > > > /usr/lib64/libnssckbi.so > > > -rw-rw---- 1 root apache 20 Sep 7 > > 2015 pwdfile.txt > > > -rw-rw---- 1 root apache 16384 Sep 7 > > 2015 secmod.db > > > -rw-r-----. 1 root apache 16384 Sep 4 > > 2015 secmod.db.orig/ > > > > Eventually you'll want to remove group write > > on the *.db files. > > > > > And password validations seems ok, too: > > > /[root at mlv-ipa01 ~]# certutil -K -d > > /etc/httpd/alias/ -f > > > /etc/httpd/alias/pwdfile.txt > > good > > > > > Enabling mod-nss debug I can see these > logs: > > > /[root at mlv-ipa01 ~]# tail -f > > /var/log/httpd/error_log > > > [Thu Nov 17 15:05:10.807603 2016] > > [suexec:notice] [pid > > 10660] AH01232: > > > suEXEC mechanism enabled (wrapper: > > /usr/sbin/suexec) > > > [Thu Nov 17 15:05:10.807958 2016] [:warn] > > [pid 10660] > > > NSSSessionCacheTimeout is deprecated. > > Ignoring. > > > [Thu Nov 17 15:05:10.807991 2016] [:debug] > > [pid 10660] > > > nss_engine_init.c(454): SNI: > > mlv-ipa01.ipa.mydomain.com > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >>> -> Server-Cert > > > [Thu Nov 17 15:05:11.002664 2016] [:info] > > [pid 10660] > > Configuring server > > > for SSL protocol > > > [Thu Nov 17 15:05:11.002817 2016] [:debug] > > [pid 10660] > > > nss_engine_init.c(770): NSSProtocol: > > Enabling TLSv1.0 > > > [Thu Nov 17 15:05:11.002838 2016] [:debug] > > [pid 10660] > > > nss_engine_init.c(775): NSSProtocol: > > Enabling TLSv1.1 > > > [Thu Nov 17 15:05:11.002847 2016] [:debug] > > [pid 10660] > > > nss_engine_init.c(780): NSSProtocol: > > Enabling TLSv1.2 > > > [Thu Nov 17 15:05:11.002856 2016] [:debug] > > [pid 10660] > > > nss_engine_init.c(839): NSSProtocol: [TLS > > 1.0] (minimum) > > > [Thu Nov 17 15:05:11.002876 2016] [:debug] > > [pid 10660] > > > nss_engine_init.c(866): NSSProtocol: [TLS > > 1.2] (maximum) > > > [Thu Nov 17 15:05:11.003099 2016] [:debug] > > [pid 10660] > > > nss_engine_init.c(906): Disabling TLS > > Session Tickets > > > [Thu Nov 17 15:05:11.003198 2016] [:debug] > > [pid 10660] > > > nss_engine_init.c(916): Enabling DHE key > > exchange > > > [Thu Nov 17 15:05:11.003313 2016] [:debug] > > [pid 10660] > > > nss_engine_init.c(1077): NSSCipherSuite: > > Configuring > > permitted SSL > > > ciphers > > > > > > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > > [Thu Nov 17 15:05:11.003469 2016] [:debug] > > [pid 10660] > > > [Thu Nov 17 15:05:11.006759 2016] [:info] > > [pid 10660] > > Using nickname > > > Server-Cert. > > [snip] > > > [Thu Nov 17 15:05:11.006771 2016] [:error] > > [pid 10660] > > Certificate not > > > found: 'Server-Cert' > > > > Can you shows what this returns: > > > > # grep NSSNickname /etc/httpd/conf.d/nss.conf > > > > > Do you think there is a kerberos problem? > > > > It definitely is not. > > > > You can bring the system up in a minimal way > > by manually > > starting the > > dirsrv at EXAMPLE.COM > > > > > > > > >> service > > > > and then > > krb5kdc. This will at least let your > > users authenticate. The management framework > > (GUI) runs > > through Apache > > so that will be down until we can get Apache > > started again. > > > > rob > > > > > > > > Please let me know, thanks. > > > Bye, Morgan > > > > > > 2016-11-17 14:39 GMT+01:00 Florence > > Blanc-Renaud > > > > > > > > > >> > > > > > > > > > > >>>>: > > > > > > > > On 11/17/2016 12:09 PM, Morgan Marodin > > wrote: > > > > > > Hello. > > > > > > This morning I've tried to upgrade > > my IPA server, > > but the > > upgrade > > > failed, and now the service > > doesn't start! :( > > > > > > If I try lo launch the upgrade > > manually this is > > the output: > > > /[root at mlv-ipa01 download]# > > 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 > > > [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 > > > 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: > > > CalledProcessError: Command > > '/bin/systemctl start > > httpd.service' > > > returned non-zero exit status 1 > > > The ipa-server-upgrade command > > failed. See > > > /var/log/ipaupgrade.log for > > > more information/ > > > > > > These are error logs of Apache: > > > /[Thu Nov 17 11:48:45.498510 2016] > > [suexec:notice] > > [pid 5664] > > > AH01232: > > > suEXEC mechanism enabled (wrapper: > > /usr/sbin/suexec) > > > [Thu Nov 17 11:48:45.499220 2016] > > [:warn] [pid 5664] > > > NSSSessionCacheTimeout is > > deprecated. Ignoring. > > > [Thu Nov 17 11:48:45.830910 2016] > > [:error] [pid 5664] > > > Certificate not > > > found: 'Server-Cert'/ > > > > > > The problem seems to be the > > /Server-Cert /that > > could not > > be found. > > > But if I try to execute the > > certutil command > > manually I > > can see it:/ > > > [root at mlv-ipa01 log]# certutil -L > > -d /etc/httpd/alias/ > > > Certificate Nickname > > Trust > > > Attributes > > > > > > SSL,S/MIME,JAR/XPI > > > Signing-Cert > > u,u,u > > > ipaCert > > u,u,u > > > Server-Cert > > Pu,u,u > > > IPA.MYDOMAIN.COM > > > > > > > > > IPA > > > CA > > CT,C,C/ > > > > > > Could you help me? > > > What could I try to do to restart > > my service? > > > > > > Hi, > > > > > > I would first make sure that httpd is > > using > > /etc/httpd/alias > > as NSS > > > DB (check the directive > > NSSCertificateDatabase in > > > /etc/httpd/conf.d/nss.conf). > > > Then it may be a file permission > > issue: the NSS DB should > > belong to > > > root:apache (the relevant files are > > cert8.db, key3.db and > > secmod.db). > > > You should also find a pwdfile.txt in > > the same directory, > > containing > > > the NSS DB password. Check that the > > password is valid > > using > > > certutil -K -d /etc/httpd/alias/ -f > > /etc/httpd/alias/pwdfile.txt > > > (if the command succeeds then the > > password in pwdfile > > is OK). > > > > > > You can also enable mod-nss debug in > > /etc/httpd/conf/nss.conf by > > > setting "LogLevel debug", and check > > the output in > > > /var/log/httpd/error_log. > > > > > > HTH, > > > Flo. > > > > > > Thanks, Morgan > > > > > > > > > > > > -- > > > 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 rcritten at redhat.com Fri Nov 18 15:51:00 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 18 Nov 2016 10:51:00 -0500 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> <994f1c25-5c63-b0f0-1da4-6b4788331daf@redhat.com> <582F1391.3020109@redhat.com> Message-ID: <582F2364.3040707@redhat.com> Morgan Marodin wrote: > What do you mean with backup database? > > Updating again the mod_nss RPM, Apache doesn't start ... so, this is the > problem. You said "and restoring the original /etc/httpd/alias/ folder". Original from what, where did that come from? So merely updating mod_nss breaks things? Strange. What is the working version? rpm -q mod_nss rob > > 2016-11-18 15:43 GMT+01:00 Rob Crittenden >: > > Morgan Marodin wrote: > > It works! > > Thanks for your support. > > > > Anyway, I will try to update againt mod_nss package! :D > > Glad it's working for you. I'm curious what the backup database was for. > Did you create that? > > rob > > > Bye! > > > > > > 2016-11-18 15:21 GMT+01:00 Morgan Marodin > > >>: > > > > A little good news. > > > > Downgrading the /mod_nss/ RPM package, and restoring the original > > //etc/httpd/alias/ folder, /ipa-server-upgrade/ procedure has > > finished well: > > /# ipa-server-upgrade > > Upgrading IPA: > > [1/10]: stopping directory server > > [2/10]: saving configuration > > [3/10]: disabling listeners > > [4/10]: enabling DS global lock > > [5/10]: starting directory server > > [6/10]: updating schema > > [7/10]: upgrading server > > [8/10]: stopping directory server > > [9/10]: restoring configuration > > [10/10]: starting directory server > > 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 > > [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] > > Global forward policy in named.conf will be changed to "only" to > > avoid conflicts with automatic empty zones > > [Adding server_id to named.conf] > > Changes to named.conf have been made, restart named > > Custodia service is being configured > > Configuring ipa-custodia > > [1/5]: Generating ipa-custodia config file > > [2/5]: Making sure custodia container exists > > [3/5]: Generating ipa-custodia keys > > [4/5]: starting ipa-custodia > > [5/5]: configuring ipa-custodia to start on boot > > Done configuring ipa-custodia. > > [Upgrading CA schema] > > CA schema update complete > > [Verifying that CA audit signing cert has 2 year validity] > > [Update certmonger certificate renewal configuration to version 5] > > Configuring certmonger to stop tracking system certificates for CA > > Certmonger certificate renewal configuration updated 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] > > pki-tomcat configuration changed, restart pki-tomcat > > [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 > > Creating Custodia keys > > Configuring key retriever > > The IPA services were upgraded > > The ipa-server-upgrade command was successful/ > > > > And Apache has started, BUT there is a problem with the web certificate: > > /# tail -f /var/log/httpd/error_log > > [Fri Nov 18 15:14:43.002268 2016] [:info] [pid 18673] Connection to > > child 2 established (server mlv-ipa01.ipa.mydomain.com:443 > > > >, client 192.168.0.252) > > [Fri Nov 18 15:14:43.207349 2016] [:info] [pid 18673] SSL input > > filter read failed. > > [Fri Nov 18 15:14:43.207389 2016] [:error] [pid 18673] SSL Library > > Error: -12285 Unable to find the certificate or key necessary for > > authentication > > [Fri Nov 18 15:14:43.207460 2016] [:info] [pid 18673] Connection to > > child 2 closed (server mlv-ipa01.ipa.mydomain.com:443 > > > >, client 192.168.0.252)/ > > > > How do you suggest to go on with my issue? > > > > Thanks, Morgan > > > > 2016-11-18 12:11 GMT+01:00 Morgan Marodin > > >>: > > > > I've tried to add it to a new test folder, with a new > > certificate nickname, and then to replace it to /nss.conf/. > > > > But the problem persists: > > /# certutil -V -u V -d /etc/httpd/test -n ipa01cert > > certutil: certificate is valid/ > > > > /# tail -f /var/log/httpd/error_log > > / > > /[Fri Nov 18 12:09:39.513833 2016] [suexec:notice] [pid 11552] > > AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > > [Fri Nov 18 12:09:39.514266 2016] [:warn] [pid 11552] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Fri Nov 18 12:09:39.514299 2016] [:debug] [pid 11552] > > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > > -> ipa01cert > > [Fri Nov 18 12:09:39.824880 2016] [:error] [pid 11552] The > > server key database has not been initialized. > > [Fri Nov 18 12:09:39.832443 2016] [:info] [pid 11552] > > Configuring server for SSL protocol > > ... > > [Fri Nov 18 12:09:39.832676 2016] [:info] [pid 11552] Using > > nickname ipa01cert. > > [Fri Nov 18 12:09:39.832678 2016] [:error] [pid 11552] > > Certificate not found: 'ipa01cert'/ > > > > I've found this guide:/ > > Combine the server cert and key into a single file > > # cp localhost.crt > Server-Cert.txt > > # cat localhost.key >> Server-Cert.txt > > Convert the server cert into a p12 file > > # openssl pkcs12 -export -in Server-Cert.txt -out > > Server-Cert.p12 -name "Server-Cert" > > Now Import the Public and Private keys into the database at the > > same time. > > #pk12util -i /tmp/cert-files/Server-Cert.p12 -d /etc/httpd/alias > > -n Server-Cert/ > > > > Where is stored the key certificate file? > > > > Thanks, Morgan > > > > > > 2016-11-18 10:39 GMT+01:00 Florence Blanc-Renaud > > >>: > > > > On 11/18/2016 10:04 AM, Morgan Marodin wrote: > > > > Hi Florence. > > > > I've tried to configure the wrong certificate in > > nss.conf (/ipaCert/), > > and with this Apache started. > > So I think the problem is in the /Server-Cert/ stored in > > //etc/httpd/alias/, even if all manul checks are ok. > > > > These are logs with the wrong certificate test: > > /# tail -f /var/log/httpd/error_log/ > > /[Fri Nov 18 09:34:32.583700 2016] [suexec:notice] [pid > > 7709] AH01232: > > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > > [Fri Nov 18 09:34:32.584142 2016] [:warn] [pid 7709] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Fri Nov 18 09:34:32.584178 2016] [:debug] [pid 7709] > > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > > > > > > >> -> ipaCert > > > > [Fri Nov 18 09:34:32.844487 2016] [:info] [pid 7709] > > Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:32.844635 2016] [:debug] [pid 7709] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:32.844657 2016] [:debug] [pid 7709] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:32.844668 2016] [:debug] [pid 7709] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:32.844677 2016] [:debug] [pid 7709] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] > (minimum) > > [Fri Nov 18 09:34:32.844684 2016] [:debug] [pid 7709] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] > (maximum) > > [Fri Nov 18 09:34:32.844738 2016] [:debug] [pid 7709] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:32.844746 2016] [:debug] [pid 7709] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:32.844760 2016] [:debug] [pid 7709] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:32.844825 2016] [:debug] [pid 7709] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:32.845105 2016] [:debug] [pid 7709] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:32.845110 2016] [:info] [pid 7709] > > Using nickname ipaCert. > > [Fri Nov 18 09:34:32.847451 2016] [:error] [pid 7709] > > Misconfiguration > > of certificate's CN and virtual name. The > certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > > >> > > as virtual name. > > [Fri Nov 18 09:34:33.028056 2016 > ] > > [auth_digest:notice] [pid 7709] > > AH01757: generating secret for digest authentication ... > > [Fri Nov 18 09:34:33.030039 2016 > ] > > [lbmethod_heartbeat:notice] [pid 7709] > > AH02282: No slotmem from mod_heartmonitor > > [Fri Nov 18 09:34:33.030122 2016 > ] > > [:warn] [pid 7709] > > NSSSessionCacheTimeout is deprecated. Ignoring. > > [Fri Nov 18 09:34:33.030176 2016 > ] > > [:debug] [pid 7709] > > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com > > > > > > > >> -> ipaCert > > > > [Fri Nov 18 09:34:33.051481 2016 > ] > > [mpm_prefork:notice] [pid 7709] > > AH00163: Apache/2.4.6 () mod_auth_gssapi/1.4.0 > > mod_auth_kerb/5.4 > > mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 > > Python/2.7.5 configured > > -- resuming normal operations > > [Fri Nov 18 09:34:33.051551 2016 > ] > > [core:notice] [pid 7709] AH00094: > > Command line: '/usr/sbin/httpd -D FOREGROUND' > > [Fri Nov 18 09:34:33.096050 2016] [proxy:debug] [pid 7717] > > proxy_util.c(1838): AH00924: worker ajp://localhost > > shared already > > initialized > > [Fri Nov 18 09:34:33.096163 2016 > ] > > [proxy:debug] [pid 7717] > > proxy_util.c(1880): AH00926: worker ajp://localhost > > local already > > initialized > > ... > > [Fri Nov 18 09:34:33.105626 2016] [proxy:debug] [pid 7719] > > proxy_util.c(1838): AH00924: worker > > unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ > > shared already > > initialized > > [Fri Nov 18 09:34:33.105632 2016] [proxy:debug] [pid 7719] > > proxy_util.c(1880): AH00926: worker > > unix:/run/httpd/ipa-custodia.sock|http://localhost/keys/ > > local already > > initialized > > [Fri Nov 18 09:34:33.342762 2016 > ] > > [:info] [pid 7717] Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:33.342867 2016 > ] > > [:debug] [pid 7717] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:33.342880 2016 > ] > > [:debug] [pid 7717] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:33.342885 2016 > ] > > [:debug] [pid 7717] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:33.342890 2016 > ] > > [:debug] [pid 7717] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Fri Nov 18 09:34:33.342894 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Fri Nov 18 09:34:33.342900 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:33.342904 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:33.342917 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:33.342970 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:33.343233 2016 ] > > [:debug] [pid 7717] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:33.343237 2016 ] > > [:info] [pid 7717] Using nickname ipaCert. > > [Fri Nov 18 09:34:33.344533 2016 ] > > [:error] [pid 7717] Misconfiguration > > of certificate's CN and virtual name. The certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > >> > > > > as virtual name. > > [Fri Nov 18 09:34:33.364061 2016 ] > > [:info] [pid 7718] Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:33.364156 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:33.364167 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:33.364172 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:33.364176 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Fri Nov 18 09:34:33.364180 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Fri Nov 18 09:34:33.364187 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:33.364191 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:33.364202 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:33.364240 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:33.364611 2016 ] > > [:debug] [pid 7718] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:33.364625 2016 ] > > [:info] [pid 7718] Using nickname ipaCert. > > [Fri Nov 18 09:34:33.365549 2016 ] > > [:error] [pid 7718] Misconfiguration > > of certificate's CN and virtual name. The certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > >> > > > > as virtual name. > > [Fri Nov 18 09:34:33.369972 2016 ] > > [:info] [pid 7720] Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:33.370200 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:33.370224 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:33.370239 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:33.370255 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Fri Nov 18 09:34:33.370269 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Fri Nov 18 09:34:33.370286 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:33.370301 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:33.370322 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:33.370383 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:33.371418 2016 ] > > [:debug] [pid 7720] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:33.371437 2016 ] > > [:info] [pid 7720] Using nickname ipaCert. > > [Fri Nov 18 09:34:33.371486 2016 ] > > [:info] [pid 7716] Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:33.372383 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:33.372439 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:33.372459 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:33.372484 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] (minimum) > > [Fri Nov 18 09:34:33.372513 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] (maximum) > > [Fri Nov 18 09:34:33.372534 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:33.372553 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:33.372580 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:33.372627 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:33.373712 2016 ] > > [:debug] [pid 7716] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:33.373734 2016 ] > > [:info] [pid 7716] Using nickname ipaCert. > > [Fri Nov 18 09:34:33.374652 2016 ] > > [:error] [pid 7716] Misconfiguration > > of certificate's CN and virtual name. The certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > >> > > as virtual name. > > [Fri Nov 18 09:34:33.372295 2016 ] > > [:error] [pid 7720] Misconfiguration > > of certificate's CN and virtual name. The certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > >> > > > > as virtual name. > > [Fri Nov 18 09:34:33.412689 2016] [:info] [pid 7719] > > Configuring server > > for SSL protocol > > [Fri Nov 18 09:34:33.412791 2016] [:debug] [pid 7719] > > nss_engine_init.c(770): NSSProtocol: Enabling TLSv1.0 > > [Fri Nov 18 09:34:33.412803 2016] [:debug] [pid 7719] > > nss_engine_init.c(775): NSSProtocol: Enabling TLSv1.1 > > [Fri Nov 18 09:34:33.412807 2016] [:debug] [pid 7719] > > nss_engine_init.c(780): NSSProtocol: Enabling TLSv1.2 > > [Fri Nov 18 09:34:33.412812 2016] [:debug] [pid 7719] > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] > (minimum) > > [Fri Nov 18 09:34:33.412817 2016] [:debug] [pid 7719] > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] > (maximum) > > [Fri Nov 18 09:34:33.412824 2016] [:debug] [pid 7719] > > nss_engine_init.c(906): Disabling TLS Session Tickets > > [Fri Nov 18 09:34:33.412828 2016] [:debug] [pid 7719] > > nss_engine_init.c(916): Enabling DHE key exchange > > [Fri Nov 18 09:34:33.412840 2016] [:debug] [pid 7719] > > nss_engine_init.c(1077): NSSCipherSuite: Configuring > > permitted SSL > > ciphers > > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > [Fri Nov 18 09:34:33.412891 2016] [:debug] [pid 7719] > > nss_engine_init.c(1140): Disable cipher: rsa_null_md5 > > ... > > [Fri Nov 18 09:34:33.413159 2016] [:debug] [pid 7719] > > nss_engine_init.c(1140): Enable cipher: > > ecdhe_rsa_aes_128_gcm_sha_256 > > [Fri Nov 18 09:34:33.413164 2016] [:info] [pid 7719] > > Using nickname ipaCert. > > [Fri Nov 18 09:34:33.414462 2016] [:error] [pid 7719] > > Misconfiguration > > of certificate's CN and virtual name. The > certificate CN > > has IPA RA. We > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > > >> > > as virtual name. > > [Fri Nov 18 09:34:35.558286 2016 ] > > [:error] [pid 7715] ipa: WARNING: > > session memcached servers not running > > [Fri Nov 18 09:34:35.559653 2016 ] > > [:error] [pid 7714] ipa: WARNING: > > session memcached servers not running > > [Fri Nov 18 09:34:37.511457 2016] [:error] [pid 7714] > > ipa: INFO: *** > > PROCESS START *** > > [Fri Nov 18 09:34:37.517899 2016] [:error] [pid 7715] > > ipa: INFO: *** > > PROCESS START *** > > [Fri Nov 18 09:34:51.498536 2016] [:info] [pid 7717] > > Connection to child > > 1 established (server mlv-ipa01.ipa.mydomain.com > > > > > > > >>, client 192.168.0.239) > > [Fri Nov 18 09:34:51.510292 2016] [:info] [pid 7717] SSL > > input filter > > read failed. > > [Fri Nov 18 09:34:51.510311 2016] [:error] [pid 7717] > > SSL Library Error: > > -12285 Unable to find the certificate or key necessary > > for authentication > > [Fri Nov 18 09:34:51.510356 2016] [:info] [pid 7717] > > Connection to child > > 1 closed (server mlv-ipa01.ipa.mydomain.com:443 > > > > > > > >>, client > > 192.168.0.239) > > [Fri Nov 18 09:35:18.790760 2016] [mpm_prefork:notice] > > [pid 7709] > > AH00170: caught SIGWINCH, shutting down gracefully/ > > > > Is possible to delete /Server-Cert/ from > > //etc/httpd/alias/ and reimport > > it from the original certificates of > > /mlv-ipa01.ipa.mydomain.com > > > > > > > >>/? > > Where are stored the original certificates? > > > > Hi Morgan, > > > > with ldapsearch you should be able to find the certificate: > > ldapsearch -h ipaserver.ipadomain -p 389 -D "cn=directory > > manager" -w password -LLL -b > > krbprincipalname=HTTP/ipaserver.ipadomain at IPADOMAIN,cn=services,cn=accounts,dc=IPADOMAIN > > > > The cert will be stored in the field "usercertificate". > > > > HTH, > > Flo. > > > > Please let me know, thanks. > > Bye, Morgan > > > > 2016-11-17 17:09 GMT+01:00 Florence Blanc-Renaud > > > > > > >>>: > > > > > > On 11/17/2016 04:51 PM, Morgan Marodin wrote: > > > > Hi Rob. > > > > I've just tried to remove the group write > to the > > *.db files, but > > it's > > not the problem. > > /[root at mlv-ipa01 ~]# grep NSSNickname > > /etc/httpd/conf.d/nss.conf > > NSSNickname Server-Cert/ > > > > I've tried to run manually /dirsrv.target/ and > > /krb5kdc.service/, and it > > works, services went up. > > The same for /ntpd/, /named-pkcs11.service/, > > /smb.service/, > > /winbind.service/, /kadmin.service/, > > /memcached.service/ and > > /pki-tomcatd.target/. > > > > But if I try to start /httpd.service/: > > /[root at mlv-ipa01 ~]# tail -f /var/log/messages > > Nov 17 16:46:06 mlv-ipa01 systemd[1]: Starting > > The Apache HTTP > > Server... > > Nov 17 16:46:06 mlv-ipa01 ipa-httpd-kdcproxy: > > ipa : > > INFO KDC > > proxy enabled > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > > httpd.service: main process > > exited, code=exited, status=1/FAILURE > > Nov 17 16:46:07 mlv-ipa01 kill: kill: cannot > > find process "" > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > > httpd.service: control process > > exited, code=exited status=1 > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > Failed to > > start The Apache > > HTTP > > Server. > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit > > httpd.service entered > > failed > > state. > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > > httpd.service failed./ > > > > Any other ideas? > > > > Hi, > > > > - Does the NSS Db contain the private key for > > Server-Cert? If yes, > > the command > > $ certutil -K -d /etc/httpd/alias/ -f > > /etc/httpd/alias/pwdfile.txt > > should display a line like this one: > > < 0> rsa > > 01a6cbd773f3d785ffa44233148dcb8ade266ea5 NSS > > Certificate DB:Server-Cert > > > > - Is your system running with SElinux > enforcing? If > > yes, you can > > check if there were SElinux permission denials > using > > $ ausearch -m avc --start recent > > > > - If the certificate was expired, I believe you > > would see a > > different message, but it doesn't hurt to > check its > > validity > > $ certutil -L -d /etc/httpd/alias/ -n > Server-Cert | > > egrep "Not > > Before|Not After" > > > > > > Flo. > > > > > > Please let me know, thanks. > > Morgan > > > > 2016-11-17 16:11 GMT+01:00 Rob Crittenden > > > > > > > > >> > > > > > > > >>>>: > > > > > > > > Morgan Marodin wrote: > > > Hi Florence. > > > > > > Thanks for your support. > > > > > > Yes, httpd is using /etc/httpd/alias as > > NSS DB. And seems > > that all > > > permissions and certificates are good: > > > /[root at mlv-ipa01 ~]# ls -l > /etc/httpd/alias/ > > > total 184 > > > -r--r--r-- 1 root root 1345 Sep 7 > > 2015 cacert.asc > > > -rw-rw---- 1 root apache 65536 Nov 17 > > 11:06 cert8.db > > > -rw-r-----. 1 root apache 65536 Sep 4 > > 2015 cert8.db.orig > > > -rw-------. 1 root root 4833 Sep 4 > > 2015 install.log > > > -rw-rw---- 1 root apache 16384 Nov 17 > > 11:06 key3.db > > > -rw-r-----. 1 root apache 16384 Sep 4 > > 2015 key3.db.orig > > > lrwxrwxrwx 1 root root 24 Nov 17 > > 10:24 libnssckbi.so -> > > > /usr/lib64/libnssckbi.so > > > -rw-rw---- 1 root apache 20 Sep 7 > > 2015 pwdfile.txt > > > -rw-rw---- 1 root apache 16384 Sep 7 > > 2015 secmod.db > > > -rw-r-----. 1 root apache 16384 Sep 4 > > 2015 secmod.db.orig/ > > > > Eventually you'll want to remove group > write > > on the *.db files. > > > > > And password validations seems ok, too: > > > /[root at mlv-ipa01 ~]# certutil -K -d > > /etc/httpd/alias/ -f > > > /etc/httpd/alias/pwdfile.txt > > good > > > > > Enabling mod-nss debug I can see > these logs: > > > /[root at mlv-ipa01 ~]# tail -f > > /var/log/httpd/error_log > > > [Thu Nov 17 15:05:10.807603 2016] > > [suexec:notice] [pid > > 10660] AH01232: > > > suEXEC mechanism enabled (wrapper: > > /usr/sbin/suexec) > > > [Thu Nov 17 15:05:10.807958 2016] > [:warn] > > [pid 10660] > > > NSSSessionCacheTimeout is deprecated. > > Ignoring. > > > [Thu Nov 17 15:05:10.807991 2016] > [:debug] > > [pid 10660] > > > nss_engine_init.c(454): SNI: > > mlv-ipa01.ipa.mydomain.com > > > > > > > > >> > > > > > > > > > >>> > > > > > > > > > > >> > > > > > > > > > > > >>>> -> Server-Cert > > > [Thu Nov 17 15:05:11.002664 2016] > [:info] > > [pid 10660] > > Configuring server > > > for SSL protocol > > > [Thu Nov 17 15:05:11.002817 2016] > [:debug] > > [pid 10660] > > > nss_engine_init.c(770): NSSProtocol: > > Enabling TLSv1.0 > > > [Thu Nov 17 15:05:11.002838 2016] > [:debug] > > [pid 10660] > > > nss_engine_init.c(775): NSSProtocol: > > Enabling TLSv1.1 > > > [Thu Nov 17 15:05:11.002847 2016] > [:debug] > > [pid 10660] > > > nss_engine_init.c(780): NSSProtocol: > > Enabling TLSv1.2 > > > [Thu Nov 17 15:05:11.002856 2016] > [:debug] > > [pid 10660] > > > nss_engine_init.c(839): > NSSProtocol: [TLS > > 1.0] (minimum) > > > [Thu Nov 17 15:05:11.002876 2016] > [:debug] > > [pid 10660] > > > nss_engine_init.c(866): > NSSProtocol: [TLS > > 1.2] (maximum) > > > [Thu Nov 17 15:05:11.003099 2016] > [:debug] > > [pid 10660] > > > nss_engine_init.c(906): Disabling TLS > > Session Tickets > > > [Thu Nov 17 15:05:11.003198 2016] > [:debug] > > [pid 10660] > > > nss_engine_init.c(916): Enabling DHE key > > exchange > > > [Thu Nov 17 15:05:11.003313 2016] > [:debug] > > [pid 10660] > > > nss_engine_init.c(1077): NSSCipherSuite: > > Configuring > > permitted SSL > > > ciphers > > > > > > > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > > [Thu Nov 17 15:05:11.003469 2016] > [:debug] > > [pid 10660] > > > [Thu Nov 17 15:05:11.006759 2016] > [:info] > > [pid 10660] > > Using nickname > > > Server-Cert. > > [snip] > > > [Thu Nov 17 15:05:11.006771 2016] > [:error] > > [pid 10660] > > Certificate not > > > found: 'Server-Cert' > > > > Can you shows what this returns: > > > > # grep NSSNickname > /etc/httpd/conf.d/nss.conf > > > > > Do you think there is a kerberos > problem? > > > > It definitely is not. > > > > You can bring the system up in a > minimal way > > by manually > > starting the > > dirsrv at EXAMPLE.COM > > > > > > >> > > > > > > > >>> service > > > > and then > > krb5kdc. This will at least let your > > users authenticate. The management > framework > > (GUI) runs > > through Apache > > so that will be down until we can get > Apache > > started again. > > > > rob > > > > > > > > Please let me know, thanks. > > > Bye, Morgan > > > > > > 2016-11-17 14:39 GMT+01:00 Florence > > Blanc-Renaud > > > > > > > >> > > > > > > >>> > > > > > > > > > >> > > > > > > >>>>>: > > > > > > > > On 11/17/2016 12:09 PM, Morgan > Marodin > > wrote: > > > > > > Hello. > > > > > > This morning I've tried to > upgrade > > my IPA server, > > but the > > upgrade > > > failed, and now the service > > doesn't start! :( > > > > > > If I try lo launch the upgrade > > manually this is > > the output: > > > /[root at mlv-ipa01 download]# > > 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 > > > [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 > > > 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: > > > CalledProcessError: Command > > '/bin/systemctl start > > httpd.service' > > > returned non-zero exit status 1 > > > The ipa-server-upgrade command > > failed. See > > > /var/log/ipaupgrade.log for > > > more information/ > > > > > > These are error logs of Apache: > > > /[Thu Nov 17 11:48:45.498510 > 2016] > > [suexec:notice] > > [pid 5664] > > > AH01232: > > > suEXEC mechanism enabled > (wrapper: > > /usr/sbin/suexec) > > > [Thu Nov 17 11:48:45.499220 > 2016] > > [:warn] [pid 5664] > > > NSSSessionCacheTimeout is > > deprecated. Ignoring. > > > [Thu Nov 17 11:48:45.830910 > 2016] > > [:error] [pid 5664] > > > Certificate not > > > found: 'Server-Cert'/ > > > > > > The problem seems to be the > > /Server-Cert /that > > could not > > be found. > > > But if I try to execute the > > certutil command > > manually I > > can see it:/ > > > [root at mlv-ipa01 log]# > certutil -L > > -d /etc/httpd/alias/ > > > Certificate Nickname > > Trust > > > Attributes > > > > > > SSL,S/MIME,JAR/XPI > > > Signing-Cert > > u,u,u > > > ipaCert > > u,u,u > > > Server-Cert > > Pu,u,u > > > IPA.MYDOMAIN.COM > > > > > > > > > > IPA > > > CA > > CT,C,C/ > > > > > > Could you help me? > > > What could I try to do to > restart > > my service? > > > > > > Hi, > > > > > > I would first make sure that > httpd is > > using > > /etc/httpd/alias > > as NSS > > > DB (check the directive > > NSSCertificateDatabase in > > > /etc/httpd/conf.d/nss.conf). > > > Then it may be a file permission > > issue: the NSS DB should > > belong to > > > root:apache (the relevant files are > > cert8.db, key3.db and > > secmod.db). > > > You should also find a > pwdfile.txt in > > the same directory, > > containing > > > the NSS DB password. Check that the > > password is valid > > using > > > certutil -K -d /etc/httpd/alias/ -f > > /etc/httpd/alias/pwdfile.txt > > > (if the command succeeds then the > > password in pwdfile > > is OK). > > > > > > You can also enable mod-nss debug in > > /etc/httpd/conf/nss.conf by > > > setting "LogLevel debug", and check > > the output in > > > /var/log/httpd/error_log. > > > > > > HTH, > > > Flo. > > > > > > Thanks, Morgan > > > > > > > > > > > > -- > > > 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 b.candler at pobox.com Fri Nov 18 15:57:42 2016 From: b.candler at pobox.com (Brian Candler) Date: Fri, 18 Nov 2016 15:57:42 +0000 Subject: [Freeipa-users] LDAP bind permitted for expired passwords Message-ID: <0eedce02-c3c4-938d-505d-6d7e645f1f38@pobox.com> Looking at FreeIPA 4.2 under CentOS 7: I find that LDAP simple binds succeed even for DNs whose krbPasswordExpiration time has passed. Is this fixed, or is it possible to change this? The reason I ask is because some applications use LDAP bind as a password validation oracle: for example, if you configure a Sophos UTM to use LDAP, it works this way. I realise that an LDAP bind doesn't give a way to prompt the user to change their password. However, a failure could be used to force the user to go to the web UI to reset it (and you could always notify people by E-mail if their password is about to expire) Thanks, Brian. From morgan at marodin.it Fri Nov 18 16:44:46 2016 From: morgan at marodin.it (Morgan Marodin) Date: Fri, 18 Nov 2016 17:44:46 +0100 Subject: [Freeipa-users] My IPA installation doesn't work after upgrade In-Reply-To: <582F2364.3040707@redhat.com> References: <77f4cd3a-d41e-2b32-57d2-a232e2811e60@redhat.com> <582DC885.6090205@redhat.com> <994f1c25-5c63-b0f0-1da4-6b4788331daf@redhat.com> <582F1391.3020109@redhat.com> <582F2364.3040707@redhat.com> Message-ID: Ok, I did a manual copy of the folder yesterday, bedore testing with the *certutil* binary. The working *mod_nss* RPM is 1.0.11-6.el7.x86_64 version. The bad one is 1.0.14-7.el7 version. Bye 2016-11-18 16:51 GMT+01:00 Rob Crittenden : > Morgan Marodin wrote: > > What do you mean with backup database? > > > > Updating again the mod_nss RPM, Apache doesn't start ... so, this is the > > problem. > > You said "and restoring the original /etc/httpd/alias/ folder". Original > from what, where did that come from? > > So merely updating mod_nss breaks things? Strange. What is the working > version? rpm -q mod_nss > > rob > > > > > 2016-11-18 15:43 GMT+01:00 Rob Crittenden > >: > > > > Morgan Marodin wrote: > > > It works! > > > Thanks for your support. > > > > > > Anyway, I will try to update againt mod_nss package! :D > > > > Glad it's working for you. I'm curious what the backup database was > for. > > Did you create that? > > > > rob > > > > > Bye! > > > > > > > > > 2016-11-18 15:21 GMT+01:00 Morgan Marodin > > > >>: > > > > > > A little good news. > > > > > > Downgrading the /mod_nss/ RPM package, and restoring the > original > > > //etc/httpd/alias/ folder, /ipa-server-upgrade/ procedure has > > > finished well: > > > /# ipa-server-upgrade > > > Upgrading IPA: > > > [1/10]: stopping directory server > > > [2/10]: saving configuration > > > [3/10]: disabling listeners > > > [4/10]: enabling DS global lock > > > [5/10]: starting directory server > > > [6/10]: updating schema > > > [7/10]: upgrading server > > > [8/10]: stopping directory server > > > [9/10]: restoring configuration > > > [10/10]: starting directory server > > > 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 > > > [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] > > > Global forward policy in named.conf will be changed to "only" > to > > > avoid conflicts with automatic empty zones > > > [Adding server_id to named.conf] > > > Changes to named.conf have been made, restart named > > > Custodia service is being configured > > > Configuring ipa-custodia > > > [1/5]: Generating ipa-custodia config file > > > [2/5]: Making sure custodia container exists > > > [3/5]: Generating ipa-custodia keys > > > [4/5]: starting ipa-custodia > > > [5/5]: configuring ipa-custodia to start on boot > > > Done configuring ipa-custodia. > > > [Upgrading CA schema] > > > CA schema update complete > > > [Verifying that CA audit signing cert has 2 year validity] > > > [Update certmonger certificate renewal configuration to > version 5] > > > Configuring certmonger to stop tracking system certificates > for CA > > > Certmonger certificate renewal configuration updated 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] > > > pki-tomcat configuration changed, restart pki-tomcat > > > [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 > > > Creating Custodia keys > > > Configuring key retriever > > > The IPA services were upgraded > > > The ipa-server-upgrade command was successful/ > > > > > > And Apache has started, BUT there is a problem with the web > certificate: > > > /# tail -f /var/log/httpd/error_log > > > [Fri Nov 18 15:14:43.002268 2016] [:info] [pid 18673] > Connection to > > > child 2 established (server mlv-ipa01.ipa.mydomain.com:443 > > > > > > >, client 192.168.0.252) > > > [Fri Nov 18 15:14:43.207349 2016] [:info] [pid 18673] SSL input > > > filter read failed. > > > [Fri Nov 18 15:14:43.207389 2016] [:error] [pid 18673] SSL > Library > > > Error: -12285 Unable to find the certificate or key necessary > for > > > authentication > > > [Fri Nov 18 15:14:43.207460 2016] [:info] [pid 18673] > Connection to > > > child 2 closed (server mlv-ipa01.ipa.mydomain.com:443 > > > > > > >, client 192.168.0.252)/ > > > > > > How do you suggest to go on with my issue? > > > > > > Thanks, Morgan > > > > > > 2016-11-18 12:11 GMT+01:00 Morgan Marodin > > > >>: > > > > > > I've tried to add it to a new test folder, with a new > > > certificate nickname, and then to replace it to /nss.conf/. > > > > > > But the problem persists: > > > /# certutil -V -u V -d /etc/httpd/test -n ipa01cert > > > certutil: certificate is valid/ > > > > > > /# tail -f /var/log/httpd/error_log > > > / > > > /[Fri Nov 18 12:09:39.513833 2016] [suexec:notice] [pid > 11552] > > > AH01232: suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > > > [Fri Nov 18 12:09:39.514266 2016] [:warn] [pid 11552] > > > NSSSessionCacheTimeout is deprecated. Ignoring. > > > [Fri Nov 18 12:09:39.514299 2016] [:debug] [pid 11552] > > > nss_engine_init.c(454): SNI: mlv-ipa01.ipa.mydomain.com < > http://mlv-ipa01.ipa.mydomain.com> > > > > > -> ipa01cert > > > [Fri Nov 18 12:09:39.824880 2016] [:error] [pid 11552] The > > > server key database has not been initialized. > > > [Fri Nov 18 12:09:39.832443 2016] [:info] [pid 11552] > > > Configuring server for SSL protocol > > > ... > > > [Fri Nov 18 12:09:39.832676 2016] [:info] [pid 11552] Using > > > nickname ipa01cert. > > > [Fri Nov 18 12:09:39.832678 2016] [:error] [pid 11552] > > > Certificate not found: 'ipa01cert'/ > > > > > > I've found this guide:/ > > > Combine the server cert and key into a single file > > > # cp localhost.crt > Server-Cert.txt > > > # cat localhost.key >> Server-Cert.txt > > > Convert the server cert into a p12 file > > > # openssl pkcs12 -export -in Server-Cert.txt -out > > > Server-Cert.p12 -name "Server-Cert" > > > Now Import the Public and Private keys into the database > at the > > > same time. > > > #pk12util -i /tmp/cert-files/Server-Cert.p12 -d > /etc/httpd/alias > > > -n Server-Cert/ > > > > > > Where is stored the key certificate file? > > > > > > Thanks, Morgan > > > > > > > > > 2016-11-18 10:39 GMT+01:00 Florence Blanc-Renaud < > flo at redhat.com > > > >>: > > > > > > On 11/18/2016 10:04 AM, Morgan Marodin wrote: > > > > > > Hi Florence. > > > > > > I've tried to configure the wrong certificate in > > > nss.conf (/ipaCert/), > > > and with this Apache started. > > > So I think the problem is in the /Server-Cert/ > stored in > > > //etc/httpd/alias/, even if all manul checks are > ok. > > > > > > These are logs with the wrong certificate test: > > > /# tail -f /var/log/httpd/error_log/ > > > /[Fri Nov 18 09:34:32.583700 2016] [suexec:notice] > [pid > > > 7709] AH01232: > > > suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > > > [Fri Nov 18 09:34:32.584142 2016] [:warn] [pid > 7709] > > > NSSSessionCacheTimeout is deprecated. Ignoring. > > > [Fri Nov 18 09:34:32.584178 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(454): SNI: > mlv-ipa01.ipa.mydomain.com > > > http://mlv-ipa01.ipa.mydomain.com>> > > > > > > > > >> -> ipaCert > > > > > > [Fri Nov 18 09:34:32.844487 2016] [:info] [pid > 7709] > > > Configuring server > > > for SSL protocol > > > [Fri Nov 18 09:34:32.844635 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(770): NSSProtocol: Enabling > TLSv1.0 > > > [Fri Nov 18 09:34:32.844657 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(775): NSSProtocol: Enabling > TLSv1.1 > > > [Fri Nov 18 09:34:32.844668 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(780): NSSProtocol: Enabling > TLSv1.2 > > > [Fri Nov 18 09:34:32.844677 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] > > (minimum) > > > [Fri Nov 18 09:34:32.844684 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] > > (maximum) > > > [Fri Nov 18 09:34:32.844738 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(906): Disabling TLS Session > Tickets > > > [Fri Nov 18 09:34:32.844746 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(916): Enabling DHE key exchange > > > [Fri Nov 18 09:34:32.844760 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(1077): NSSCipherSuite: > Configuring > > > permitted SSL > > > ciphers > > > > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > > [Fri Nov 18 09:34:32.844825 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(1140): Disable cipher: > rsa_null_md5 > > > ... > > > [Fri Nov 18 09:34:32.845105 2016] [:debug] [pid > 7709] > > > nss_engine_init.c(1140): Enable cipher: > > > ecdhe_rsa_aes_128_gcm_sha_256 > > > [Fri Nov 18 09:34:32.845110 2016] [:info] [pid > 7709] > > > Using nickname ipaCert. > > > [Fri Nov 18 09:34:32.847451 2016] [:error] [pid > 7709] > > > Misconfiguration > > > of certificate's CN and virtual name. The > > certificate CN > > > has IPA RA. We > > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > > > > > > > > http://mlv-ipa01.ipa.mydomain.com>>> > > > as virtual name. > > > [Fri Nov 18 09:34:33.028056 2016 > > ] > > > [auth_digest:notice] [pid 7709] > > > AH01757: generating secret for digest > authentication ... > > > [Fri Nov 18 09:34:33.030039 2016 > > ] > > > [lbmethod_heartbeat:notice] [pid 7709] > > > AH02282: No slotmem from mod_heartmonitor > > > [Fri Nov 18 09:34:33.030122 2016 > > ] > > > [:warn] [pid 7709] > > > NSSSessionCacheTimeout is deprecated. Ignoring. > > > [Fri Nov 18 09:34:33.030176 2016 > > ] > > > [:debug] [pid 7709] > > > nss_engine_init.c(454): SNI: > mlv-ipa01.ipa.mydomain.com > > > http://mlv-ipa01.ipa.mydomain.com>> > > > > > > > > >> -> ipaCert > > > > > > [Fri Nov 18 09:34:33.051481 2016 > > ] > > > [mpm_prefork:notice] [pid 7709] > > > AH00163: Apache/2.4.6 () mod_auth_gssapi/1.4.0 > > > mod_auth_kerb/5.4 > > > mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 > > > Python/2.7.5 configured > > > -- resuming normal operations > > > [Fri Nov 18 09:34:33.051551 2016 > > ] > > > [core:notice] [pid 7709] AH00094: > > > Command line: '/usr/sbin/httpd -D FOREGROUND' > > > [Fri Nov 18 09:34:33.096050 2016] [proxy:debug] > [pid 7717] > > > proxy_util.c(1838): AH00924: worker ajp://localhost > > > shared already > > > initialized > > > [Fri Nov 18 09:34:33.096163 2016 > > ] > > > [proxy:debug] [pid 7717] > > > proxy_util.c(1880): AH00926: worker ajp://localhost > > > local already > > > initialized > > > ... > > > [Fri Nov 18 09:34:33.105626 2016] [proxy:debug] > [pid 7719] > > > proxy_util.c(1838): AH00924: worker > > > unix:/run/httpd/ipa-custodia.sock| > http://localhost/keys/ > > > shared already > > > initialized > > > [Fri Nov 18 09:34:33.105632 2016] [proxy:debug] > [pid 7719] > > > proxy_util.c(1880): AH00926: worker > > > unix:/run/httpd/ipa-custodia.sock| > http://localhost/keys/ > > > local already > > > initialized > > > [Fri Nov 18 09:34:33.342762 2016 > > ] > > > [:info] [pid 7717] Configuring server > > > for SSL protocol > > > [Fri Nov 18 09:34:33.342867 2016 > > ] > > > [:debug] [pid 7717] > > > nss_engine_init.c(770): NSSProtocol: Enabling > TLSv1.0 > > > [Fri Nov 18 09:34:33.342880 2016 > > ] > > > [:debug] [pid 7717] > > > nss_engine_init.c(775): NSSProtocol: Enabling > TLSv1.1 > > > [Fri Nov 18 09:34:33.342885 2016 > > ] > > > [:debug] [pid 7717] > > > nss_engine_init.c(780): NSSProtocol: Enabling > TLSv1.2 > > > [Fri Nov 18 09:34:33.342890 2016 > > ] > > > [:debug] [pid 7717] > > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] > (minimum) > > > [Fri Nov 18 09:34:33.342894 2016 > ] > > > [:debug] [pid 7717] > > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] > (maximum) > > > [Fri Nov 18 09:34:33.342900 2016 > ] > > > [:debug] [pid 7717] > > > nss_engine_init.c(906): Disabling TLS Session > Tickets > > > [Fri Nov 18 09:34:33.342904 2016 > ] > > > [:debug] [pid 7717] > > > nss_engine_init.c(916): Enabling DHE key exchange > > > [Fri Nov 18 09:34:33.342917 2016 > ] > > > [:debug] [pid 7717] > > > nss_engine_init.c(1077): NSSCipherSuite: > Configuring > > > permitted SSL > > > ciphers > > > [+aes_128_sha_256,+aes_256_ > sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_ > 128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_ > 256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_ > 128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_ > 256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_ > 256_gcm_sha_384,+rsa_aes_256_sha] > > > [Fri Nov 18 09:34:33.342970 2016 > ] > > > [:debug] [pid 7717] > > > nss_engine_init.c(1140): Disable cipher: > rsa_null_md5 > > > ... > > > [Fri Nov 18 09:34:33.343233 2016 > ] > > > [:debug] [pid 7717] > > > nss_engine_init.c(1140): Enable cipher: > > > ecdhe_rsa_aes_128_gcm_sha_256 > > > [Fri Nov 18 09:34:33.343237 2016 > ] > > > [:info] [pid 7717] Using nickname ipaCert. > > > [Fri Nov 18 09:34:33.344533 2016 > ] > > > [:error] [pid 7717] Misconfiguration > > > of certificate's CN and virtual name. The > certificate CN > > > has IPA RA. We > > > expected mlv-ipa01.ipa.mydomain.com < > http://mlv-ipa01.ipa.mydomain.com> > > > http://mlv-ipa01.ipa.mydomain.com>> > > > > > > > http://mlv-ipa01.ipa.mydomain.com>>> > > > > > > as virtual name. > > > [Fri Nov 18 09:34:33.364061 2016 > ] > > > [:info] [pid 7718] Configuring server > > > for SSL protocol > > > [Fri Nov 18 09:34:33.364156 2016 > ] > > > [:debug] [pid 7718] > > > nss_engine_init.c(770): NSSProtocol: Enabling > TLSv1.0 > > > [Fri Nov 18 09:34:33.364167 2016 > ] > > > [:debug] [pid 7718] > > > nss_engine_init.c(775): NSSProtocol: Enabling > TLSv1.1 > > > [Fri Nov 18 09:34:33.364172 2016 > ] > > > [:debug] [pid 7718] > > > nss_engine_init.c(780): NSSProtocol: Enabling > TLSv1.2 > > > [Fri Nov 18 09:34:33.364176 2016 > ] > > > [:debug] [pid 7718] > > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] > (minimum) > > > [Fri Nov 18 09:34:33.364180 2016 > ] > > > [:debug] [pid 7718] > > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] > (maximum) > > > [Fri Nov 18 09:34:33.364187 2016 > ] > > > [:debug] [pid 7718] > > > nss_engine_init.c(906): Disabling TLS Session > Tickets > > > [Fri Nov 18 09:34:33.364191 2016 > ] > > > [:debug] [pid 7718] > > > nss_engine_init.c(916): Enabling DHE key exchange > > > [Fri Nov 18 09:34:33.364202 2016 > ] > > > [:debug] [pid 7718] > > > nss_engine_init.c(1077): NSSCipherSuite: > Configuring > > > permitted SSL > > > ciphers > > > [+aes_128_sha_256,+aes_256_ > sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_ > 128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_ > 256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_ > 128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_ > 256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_ > 256_gcm_sha_384,+rsa_aes_256_sha] > > > [Fri Nov 18 09:34:33.364240 2016 > ] > > > [:debug] [pid 7718] > > > nss_engine_init.c(1140): Disable cipher: > rsa_null_md5 > > > ... > > > [Fri Nov 18 09:34:33.364611 2016 > ] > > > [:debug] [pid 7718] > > > nss_engine_init.c(1140): Enable cipher: > > > ecdhe_rsa_aes_128_gcm_sha_256 > > > [Fri Nov 18 09:34:33.364625 2016 > ] > > > [:info] [pid 7718] Using nickname ipaCert. > > > [Fri Nov 18 09:34:33.365549 2016 > ] > > > [:error] [pid 7718] Misconfiguration > > > of certificate's CN and virtual name. The > certificate CN > > > has IPA RA. We > > > expected mlv-ipa01.ipa.mydomain.com < > http://mlv-ipa01.ipa.mydomain.com> > > > http://mlv-ipa01.ipa.mydomain.com>> > > > > > > > http://mlv-ipa01.ipa.mydomain.com>>> > > > > > > as virtual name. > > > [Fri Nov 18 09:34:33.369972 2016 > ] > > > [:info] [pid 7720] Configuring server > > > for SSL protocol > > > [Fri Nov 18 09:34:33.370200 2016 > ] > > > [:debug] [pid 7720] > > > nss_engine_init.c(770): NSSProtocol: Enabling > TLSv1.0 > > > [Fri Nov 18 09:34:33.370224 2016 > ] > > > [:debug] [pid 7720] > > > nss_engine_init.c(775): NSSProtocol: Enabling > TLSv1.1 > > > [Fri Nov 18 09:34:33.370239 2016 > ] > > > [:debug] [pid 7720] > > > nss_engine_init.c(780): NSSProtocol: Enabling > TLSv1.2 > > > [Fri Nov 18 09:34:33.370255 2016 > ] > > > [:debug] [pid 7720] > > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] > (minimum) > > > [Fri Nov 18 09:34:33.370269 2016 > ] > > > [:debug] [pid 7720] > > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] > (maximum) > > > [Fri Nov 18 09:34:33.370286 2016 > ] > > > [:debug] [pid 7720] > > > nss_engine_init.c(906): Disabling TLS Session > Tickets > > > [Fri Nov 18 09:34:33.370301 2016 > ] > > > [:debug] [pid 7720] > > > nss_engine_init.c(916): Enabling DHE key exchange > > > [Fri Nov 18 09:34:33.370322 2016 > ] > > > [:debug] [pid 7720] > > > nss_engine_init.c(1077): NSSCipherSuite: > Configuring > > > permitted SSL > > > ciphers > > > [+aes_128_sha_256,+aes_256_ > sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_ > 128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_ > 256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_ > 128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_ > 256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_ > 256_gcm_sha_384,+rsa_aes_256_sha] > > > [Fri Nov 18 09:34:33.370383 2016 > ] > > > [:debug] [pid 7720] > > > nss_engine_init.c(1140): Disable cipher: > rsa_null_md5 > > > ... > > > [Fri Nov 18 09:34:33.371418 2016 > ] > > > [:debug] [pid 7720] > > > nss_engine_init.c(1140): Enable cipher: > > > ecdhe_rsa_aes_128_gcm_sha_256 > > > [Fri Nov 18 09:34:33.371437 2016 > ] > > > [:info] [pid 7720] Using nickname ipaCert. > > > [Fri Nov 18 09:34:33.371486 2016 > ] > > > [:info] [pid 7716] Configuring server > > > for SSL protocol > > > [Fri Nov 18 09:34:33.372383 2016 > ] > > > [:debug] [pid 7716] > > > nss_engine_init.c(770): NSSProtocol: Enabling > TLSv1.0 > > > [Fri Nov 18 09:34:33.372439 2016 > ] > > > [:debug] [pid 7716] > > > nss_engine_init.c(775): NSSProtocol: Enabling > TLSv1.1 > > > [Fri Nov 18 09:34:33.372459 2016 > ] > > > [:debug] [pid 7716] > > > nss_engine_init.c(780): NSSProtocol: Enabling > TLSv1.2 > > > [Fri Nov 18 09:34:33.372484 2016 > ] > > > [:debug] [pid 7716] > > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] > (minimum) > > > [Fri Nov 18 09:34:33.372513 2016 > ] > > > [:debug] [pid 7716] > > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] > (maximum) > > > [Fri Nov 18 09:34:33.372534 2016 > ] > > > [:debug] [pid 7716] > > > nss_engine_init.c(906): Disabling TLS Session > Tickets > > > [Fri Nov 18 09:34:33.372553 2016 > ] > > > [:debug] [pid 7716] > > > nss_engine_init.c(916): Enabling DHE key exchange > > > [Fri Nov 18 09:34:33.372580 2016 > ] > > > [:debug] [pid 7716] > > > nss_engine_init.c(1077): NSSCipherSuite: > Configuring > > > permitted SSL > > > ciphers > > > [+aes_128_sha_256,+aes_256_ > sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_ > 128_sha,+ecdhe_ecdsa_aes_256_gcm_sha_384,+ecdhe_ecdsa_aes_ > 256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_ > 128_sha,+ecdhe_rsa_aes_256_gcm_sha_384,+ecdhe_rsa_aes_ > 256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_ > 256_gcm_sha_384,+rsa_aes_256_sha] > > > [Fri Nov 18 09:34:33.372627 2016 > ] > > > [:debug] [pid 7716] > > > nss_engine_init.c(1140): Disable cipher: > rsa_null_md5 > > > ... > > > [Fri Nov 18 09:34:33.373712 2016 > ] > > > [:debug] [pid 7716] > > > nss_engine_init.c(1140): Enable cipher: > > > ecdhe_rsa_aes_128_gcm_sha_256 > > > [Fri Nov 18 09:34:33.373734 2016 > ] > > > [:info] [pid 7716] Using nickname ipaCert. > > > [Fri Nov 18 09:34:33.374652 2016 > ] > > > [:error] [pid 7716] Misconfiguration > > > of certificate's CN and virtual name. The > certificate CN > > > has IPA RA. We > > > expected mlv-ipa01.ipa.mydomain.com < > http://mlv-ipa01.ipa.mydomain.com> > > > http://mlv-ipa01.ipa.mydomain.com>> > > > > > > > http://mlv-ipa01.ipa.mydomain.com>>> > > > as virtual name. > > > [Fri Nov 18 09:34:33.372295 2016 > ] > > > [:error] [pid 7720] Misconfiguration > > > of certificate's CN and virtual name. The > certificate CN > > > has IPA RA. We > > > expected mlv-ipa01.ipa.mydomain.com < > http://mlv-ipa01.ipa.mydomain.com> > > > http://mlv-ipa01.ipa.mydomain.com>> > > > > > > > > >> > > > > > > as virtual name. > > > [Fri Nov 18 09:34:33.412689 2016] [:info] [pid > 7719] > > > Configuring server > > > for SSL protocol > > > [Fri Nov 18 09:34:33.412791 2016] [:debug] [pid > 7719] > > > nss_engine_init.c(770): NSSProtocol: Enabling > TLSv1.0 > > > [Fri Nov 18 09:34:33.412803 2016] [:debug] [pid > 7719] > > > nss_engine_init.c(775): NSSProtocol: Enabling > TLSv1.1 > > > [Fri Nov 18 09:34:33.412807 2016] [:debug] [pid > 7719] > > > nss_engine_init.c(780): NSSProtocol: Enabling > TLSv1.2 > > > [Fri Nov 18 09:34:33.412812 2016] [:debug] [pid > 7719] > > > nss_engine_init.c(839): NSSProtocol: [TLS 1.0] > > (minimum) > > > [Fri Nov 18 09:34:33.412817 2016] [:debug] [pid > 7719] > > > nss_engine_init.c(866): NSSProtocol: [TLS 1.2] > > (maximum) > > > [Fri Nov 18 09:34:33.412824 2016] [:debug] [pid > 7719] > > > nss_engine_init.c(906): Disabling TLS Session > Tickets > > > [Fri Nov 18 09:34:33.412828 2016] [:debug] [pid > 7719] > > > nss_engine_init.c(916): Enabling DHE key exchange > > > [Fri Nov 18 09:34:33.412840 2016] [:debug] [pid > 7719] > > > nss_engine_init.c(1077): NSSCipherSuite: > Configuring > > > permitted SSL > > > ciphers > > > > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > > [Fri Nov 18 09:34:33.412891 2016] [:debug] [pid > 7719] > > > nss_engine_init.c(1140): Disable cipher: > rsa_null_md5 > > > ... > > > [Fri Nov 18 09:34:33.413159 2016] [:debug] [pid > 7719] > > > nss_engine_init.c(1140): Enable cipher: > > > ecdhe_rsa_aes_128_gcm_sha_256 > > > [Fri Nov 18 09:34:33.413164 2016] [:info] [pid > 7719] > > > Using nickname ipaCert. > > > [Fri Nov 18 09:34:33.414462 2016] [:error] [pid > 7719] > > > Misconfiguration > > > of certificate's CN and virtual name. The > > certificate CN > > > has IPA RA. We > > > expected mlv-ipa01.ipa.mydomain.com > > > > > > > > > > > > > > http://mlv-ipa01.ipa.mydomain.com>>> > > > as virtual name. > > > [Fri Nov 18 09:34:35.558286 2016 > ] > > > [:error] [pid 7715] ipa: WARNING: > > > session memcached servers not running > > > [Fri Nov 18 09:34:35.559653 2016 > ] > > > [:error] [pid 7714] ipa: WARNING: > > > session memcached servers not running > > > [Fri Nov 18 09:34:37.511457 2016] [:error] [pid > 7714] > > > ipa: INFO: *** > > > PROCESS START *** > > > [Fri Nov 18 09:34:37.517899 2016] [:error] [pid > 7715] > > > ipa: INFO: *** > > > PROCESS START *** > > > [Fri Nov 18 09:34:51.498536 2016] [:info] [pid > 7717] > > > Connection to child > > > 1 established (server mlv-ipa01.ipa.mydomain.com < > http://mlv-ipa01.ipa.mydomain.com> > > > http://mlv-ipa01.ipa.mydomain.com>> > > > > > > > > >>, client 192.168.0.239) > > > [Fri Nov 18 09:34:51.510292 2016] [:info] [pid > 7717] SSL > > > input filter > > > read failed. > > > [Fri Nov 18 09:34:51.510311 2016] [:error] [pid > 7717] > > > SSL Library Error: > > > -12285 Unable to find the certificate or key > necessary > > > for authentication > > > [Fri Nov 18 09:34:51.510356 2016] [:info] [pid > 7717] > > > Connection to child > > > 1 closed (server mlv-ipa01.ipa.mydomain.com:443 < > http://mlv-ipa01.ipa.mydomain.com:443> > > > > > > > > > > > > > >>, client > > > 192.168.0.239) > > > [Fri Nov 18 09:35:18.790760 2016] > [mpm_prefork:notice] > > > [pid 7709] > > > AH00170: caught SIGWINCH, shutting down gracefully/ > > > > > > Is possible to delete /Server-Cert/ from > > > //etc/httpd/alias/ and reimport > > > it from the original certificates of > > > /mlv-ipa01.ipa.mydomain.com mydomain.com> > > > http://mlv-ipa01.ipa.mydomain.com>> > > > > > > > > >>/? > > > Where are stored the original certificates? > > > > > > Hi Morgan, > > > > > > with ldapsearch you should be able to find the > certificate: > > > ldapsearch -h ipaserver.ipadomain -p 389 -D > "cn=directory > > > manager" -w password -LLL -b > > > krbprincipalname=HTTP/ipaserver.ipadomain at IPADOMAIN, > cn=services,cn=accounts,dc=IPADOMAIN > > > > > > The cert will be stored in the field "usercertificate". > > > > > > HTH, > > > Flo. > > > > > > Please let me know, thanks. > > > Bye, Morgan > > > > > > 2016-11-17 17:09 GMT+01:00 Florence Blanc-Renaud > > > flo at redhat.com > > > > > > > > >>>: > > > > > > > > > On 11/17/2016 04:51 PM, Morgan Marodin wrote: > > > > > > Hi Rob. > > > > > > I've just tried to remove the group write > > to the > > > *.db files, but > > > it's > > > not the problem. > > > /[root at mlv-ipa01 ~]# grep NSSNickname > > > /etc/httpd/conf.d/nss.conf > > > NSSNickname Server-Cert/ > > > > > > I've tried to run manually /dirsrv.target/ > and > > > /krb5kdc.service/, and it > > > works, services went up. > > > The same for /ntpd/, > /named-pkcs11.service/, > > > /smb.service/, > > > /winbind.service/, /kadmin.service/, > > > /memcached.service/ and > > > /pki-tomcatd.target/. > > > > > > But if I try to start /httpd.service/: > > > /[root at mlv-ipa01 ~]# tail -f > /var/log/messages > > > Nov 17 16:46:06 mlv-ipa01 systemd[1]: > Starting > > > The Apache HTTP > > > Server... > > > Nov 17 16:46:06 mlv-ipa01 > ipa-httpd-kdcproxy: > > > ipa : > > > INFO KDC > > > proxy enabled > > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > > > httpd.service: main process > > > exited, code=exited, status=1/FAILURE > > > Nov 17 16:46:07 mlv-ipa01 kill: kill: > cannot > > > find process "" > > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > > > httpd.service: control process > > > exited, code=exited status=1 > > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > > Failed to > > > start The Apache > > > HTTP > > > Server. > > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: Unit > > > httpd.service entered > > > failed > > > state. > > > Nov 17 16:46:07 mlv-ipa01 systemd[1]: > > > httpd.service failed./ > > > > > > Any other ideas? > > > > > > Hi, > > > > > > - Does the NSS Db contain the private key for > > > Server-Cert? If yes, > > > the command > > > $ certutil -K -d /etc/httpd/alias/ -f > > > /etc/httpd/alias/pwdfile.txt > > > should display a line like this one: > > > < 0> rsa > > > 01a6cbd773f3d785ffa44233148dcb8ade266ea5 NSS > > > Certificate DB:Server-Cert > > > > > > - Is your system running with SElinux > > enforcing? If > > > yes, you can > > > check if there were SElinux permission denials > > using > > > $ ausearch -m avc --start recent > > > > > > - If the certificate was expired, I believe you > > > would see a > > > different message, but it doesn't hurt to > > check its > > > validity > > > $ certutil -L -d /etc/httpd/alias/ -n > > Server-Cert | > > > egrep "Not > > > Before|Not After" > > > > > > > > > Flo. > > > > > > > > > Please let me know, thanks. > > > Morgan > > > > > > 2016-11-17 16:11 GMT+01:00 Rob Crittenden > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > >>>>: > > > > > > > > > > > > Morgan Marodin wrote: > > > > Hi Florence. > > > > > > > > Thanks for your support. > > > > > > > > Yes, httpd is using /etc/httpd/alias > as > > > NSS DB. And seems > > > that all > > > > permissions and certificates are > good: > > > > /[root at mlv-ipa01 ~]# ls -l > > /etc/httpd/alias/ > > > > total 184 > > > > -r--r--r-- 1 root root 1345 Sep > 7 > > > 2015 cacert.asc > > > > -rw-rw---- 1 root apache 65536 Nov > 17 > > > 11:06 cert8.db > > > > -rw-r-----. 1 root apache 65536 Sep > 4 > > > 2015 cert8.db.orig > > > > -rw-------. 1 root root 4833 Sep > 4 > > > 2015 install.log > > > > -rw-rw---- 1 root apache 16384 Nov > 17 > > > 11:06 key3.db > > > > -rw-r-----. 1 root apache 16384 Sep > 4 > > > 2015 key3.db.orig > > > > lrwxrwxrwx 1 root root 24 Nov > 17 > > > 10:24 libnssckbi.so -> > > > > /usr/lib64/libnssckbi.so > > > > -rw-rw---- 1 root apache 20 Sep > 7 > > > 2015 pwdfile.txt > > > > -rw-rw---- 1 root apache 16384 Sep > 7 > > > 2015 secmod.db > > > > -rw-r-----. 1 root apache 16384 Sep > 4 > > > 2015 secmod.db.orig/ > > > > > > Eventually you'll want to remove group > > write > > > on the *.db files. > > > > > > > And password validations seems ok, > too: > > > > /[root at mlv-ipa01 ~]# certutil -K -d > > > /etc/httpd/alias/ -f > > > > /etc/httpd/alias/pwdfile.txt > > > good > > > > > > > Enabling mod-nss debug I can see > > these logs: > > > > /[root at mlv-ipa01 ~]# tail -f > > > /var/log/httpd/error_log > > > > [Thu Nov 17 15:05:10.807603 2016] > > > [suexec:notice] [pid > > > 10660] AH01232: > > > > suEXEC mechanism enabled (wrapper: > > > /usr/sbin/suexec) > > > > [Thu Nov 17 15:05:10.807958 2016] > > [:warn] > > > [pid 10660] > > > > NSSSessionCacheTimeout is deprecated. > > > Ignoring. > > > > [Thu Nov 17 15:05:10.807991 2016] > > [:debug] > > > [pid 10660] > > > > nss_engine_init.c(454): SNI: > > > mlv-ipa01.ipa.mydomain.com > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > >>>> -> Server-Cert > > > > [Thu Nov 17 15:05:11.002664 2016] > > [:info] > > > [pid 10660] > > > Configuring server > > > > for SSL protocol > > > > [Thu Nov 17 15:05:11.002817 2016] > > [:debug] > > > [pid 10660] > > > > nss_engine_init.c(770): NSSProtocol: > > > Enabling TLSv1.0 > > > > [Thu Nov 17 15:05:11.002838 2016] > > [:debug] > > > [pid 10660] > > > > nss_engine_init.c(775): NSSProtocol: > > > Enabling TLSv1.1 > > > > [Thu Nov 17 15:05:11.002847 2016] > > [:debug] > > > [pid 10660] > > > > nss_engine_init.c(780): NSSProtocol: > > > Enabling TLSv1.2 > > > > [Thu Nov 17 15:05:11.002856 2016] > > [:debug] > > > [pid 10660] > > > > nss_engine_init.c(839): > > NSSProtocol: [TLS > > > 1.0] (minimum) > > > > [Thu Nov 17 15:05:11.002876 2016] > > [:debug] > > > [pid 10660] > > > > nss_engine_init.c(866): > > NSSProtocol: [TLS > > > 1.2] (maximum) > > > > [Thu Nov 17 15:05:11.003099 2016] > > [:debug] > > > [pid 10660] > > > > nss_engine_init.c(906): Disabling TLS > > > Session Tickets > > > > [Thu Nov 17 15:05:11.003198 2016] > > [:debug] > > > [pid 10660] > > > > nss_engine_init.c(916): Enabling DHE > key > > > exchange > > > > [Thu Nov 17 15:05:11.003313 2016] > > [:debug] > > > [pid 10660] > > > > nss_engine_init.c(1077): > NSSCipherSuite: > > > Configuring > > > permitted SSL > > > > ciphers > > > > > > > > > > > > [+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_ > gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_ > gcm_sha_384,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_ > gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_ > gcm_sha_384,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_ > 256,+rsa_aes_128_sha,+rsa_aes_256_gcm_sha_384,+rsa_aes_256_sha] > > > > [Thu Nov 17 15:05:11.003469 2016] > > [:debug] > > > [pid 10660] > > > > [Thu Nov 17 15:05:11.006759 2016] > > [:info] > > > [pid 10660] > > > Using nickname > > > > Server-Cert. > > > [snip] > > > > [Thu Nov 17 15:05:11.006771 2016] > > [:error] > > > [pid 10660] > > > Certificate not > > > > found: 'Server-Cert' > > > > > > Can you shows what this returns: > > > > > > # grep NSSNickname > > /etc/httpd/conf.d/nss.conf > > > > > > > Do you think there is a kerberos > > problem? > > > > > > It definitely is not. > > > > > > You can bring the system up in a > > minimal way > > > by manually > > > starting the > > > dirsrv at EXAMPLE.COM > > > > > > > > > > > > >> > > > > > > > > > > > > > > >>> service > > > > > > and then > > > krb5kdc. This will at least let your > > > users authenticate. The management > > framework > > > (GUI) runs > > > through Apache > > > so that will be down until we can get > > Apache > > > started again. > > > > > > rob > > > > > > > > > > > Please let me know, thanks. > > > > Bye, Morgan > > > > > > > > 2016-11-17 14:39 GMT+01:00 Florence > > > Blanc-Renaud > > > > > > > > > > > >> > > > > > > > > > > > >>> > > > > > > > > > > > > > > >> > > > > flo at redhat.com>> > > > > > >>>>>: > > > > > > > > > > > On 11/17/2016 12:09 PM, Morgan > > Marodin > > > wrote: > > > > > > > > Hello. > > > > > > > > This morning I've tried to > > upgrade > > > my IPA server, > > > but the > > > upgrade > > > > failed, and now the service > > > doesn't start! :( > > > > > > > > If I try lo launch the > upgrade > > > manually this is > > > the output: > > > > /[root at mlv-ipa01 download]# > > > 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 > > > > [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 > > > > 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: > > > > CalledProcessError: Command > > > '/bin/systemctl start > > > httpd.service' > > > > returned non-zero exit > status 1 > > > > The ipa-server-upgrade > command > > > failed. See > > > > /var/log/ipaupgrade.log for > > > > more information/ > > > > > > > > These are error logs of > Apache: > > > > /[Thu Nov 17 11:48:45.498510 > > 2016] > > > [suexec:notice] > > > [pid 5664] > > > > AH01232: > > > > suEXEC mechanism enabled > > (wrapper: > > > /usr/sbin/suexec) > > > > [Thu Nov 17 11:48:45.499220 > > 2016] > > > [:warn] [pid 5664] > > > > NSSSessionCacheTimeout is > > > deprecated. Ignoring. > > > > [Thu Nov 17 11:48:45.830910 > > 2016] > > > [:error] [pid 5664] > > > > Certificate not > > > > found: 'Server-Cert'/ > > > > > > > > The problem seems to be the > > > /Server-Cert /that > > > could not > > > be found. > > > > But if I try to execute the > > > certutil command > > > manually I > > > can see it:/ > > > > [root at mlv-ipa01 log]# > > certutil -L > > > -d /etc/httpd/alias/ > > > > Certificate Nickname > > > Trust > > > > Attributes > > > > > > > > SSL,S/MIME,JAR/XPI > > > > Signing-Cert > > > u,u,u > > > > ipaCert > > > u,u,u > > > > Server-Cert > > > Pu,u,u > > > > IPA.MYDOMAIN.COM > > > > > > > > > > > > > > > > > IPA > > > > CA > > > CT,C,C/ > > > > > > > > Could you help me? > > > > What could I try to do to > > restart > > > my service? > > > > > > > > Hi, > > > > > > > > I would first make sure that > > httpd is > > > using > > > /etc/httpd/alias > > > as NSS > > > > DB (check the directive > > > NSSCertificateDatabase in > > > > /etc/httpd/conf.d/nss.conf). > > > > Then it may be a file permission > > > issue: the NSS DB should > > > belong to > > > > root:apache (the relevant files > are > > > cert8.db, key3.db and > > > secmod.db). > > > > You should also find a > > pwdfile.txt in > > > the same directory, > > > containing > > > > the NSS DB password. Check that > the > > > password is valid > > > using > > > > certutil -K -d /etc/httpd/alias/ > -f > > > /etc/httpd/alias/pwdfile.txt > > > > (if the command succeeds then the > > > password in pwdfile > > > is OK). > > > > > > > > You can also enable mod-nss > debug in > > > /etc/httpd/conf/nss.conf by > > > > setting "LogLevel debug", and > check > > > the output in > > > > /var/log/httpd/error_log. > > > > > > > > HTH, > > > > Flo. > > > > > > > > Thanks, Morgan > > > > > > > > > > > > > > > > -- > > > > 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 rkleinberg at keywcorp.com Fri Nov 18 18:12:32 2016 From: rkleinberg at keywcorp.com (Robert Kleinberg) Date: Fri, 18 Nov 2016 18:12:32 +0000 Subject: [Freeipa-users] Is there an simple way to add in sudo time window options in FreeIPA? Message-ID: <94AE223E3874284B9502002D06BEE51936C280A4@IHQ-ExchMS01.resources.keywcorp.com> Would like to establish valid sudo usage windows with sudonotbefore and sudonotafter options. However, I did not see an easy way to set this up other than via an sudo options text entry line. Is there another menu-driven way that shows a schedule of allowed times? Bob Kleinberg Lead System Engineer KEYW Corporation|www.keywcorp.com 7740 Milestone Parkway, Suite 400 | Hanover, MD 21076 443-737-9703 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4270 bytes Desc: not available URL: From michael.plemmons at crosschx.com Fri Nov 18 19:00:32 2016 From: michael.plemmons at crosschx.com (Michael Plemmons) Date: Fri, 18 Nov 2016 14:00:32 -0500 Subject: [Freeipa-users] FreeIPA 3 to FreeIPA 4 migration and Kerberos realm is a forwarded zone Message-ID: Hello, My existing FreeIPA 3.0 (CentOS 6) setup is as follows: Kerberos Realm: test.com I have several DNS zones test.com dev.test.com stage.test.com qa.test.com prod.test.com mgmt.test.com ipa01.mgmt.test.com - FreeIPA 3.0 Master ipa02.mgmt.test.com - FreeIPA 3.0 Replica The FreeIPA servers actually reside in mgmt.test.com. test.com in FreeIPA 3 has forwarding DNS servers configured. We are going to move to FreeIPA 4.2 (CentOS 7) and here is the path I have tested that appears to work. I followed this guide. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html 1 Create an IPA 4 server (ipa03.mgmt.test.com) that is a replica of the IPA 3 master server (ipa01.mgmt.test.com) 2 Remove replica agreement for ipa02.mgmt.test.com on IPA 3 master ( ipa01.mgmt.test.com) 3 Shutdown ipa02.mgmt.test.com to prep for an IPA 4 server to take its place 4 Build a new server and install IPA 4 server that will become a new ipa02.mgmt.test.com 5 Make ipa02.mgmt.test.com a replica of ipa03.mgmt.test.com 6 Make ipa02.mgmt.test.com the master CRL server instead of ipa01.mgmt.test.com 7 Shutdown ipa01.mgmt.test.com to prep for an IPA 4 server to take its place 8 Build a new server and install IPA 4 server that will become a new ipa01.mgmt.test.com 9 Make ipa01.mgmt.test.com a replica of ipa02.mgmt.test.com The reason for removing old servers to take the place of new servers is so that I can reuse the IP addresses and do not need to change DNS entries on any client The problem occurs when I realize that the test.com zone needs to be a forwarded zone in IPA 4 but in IPA 3 is it a normal DNS zone and I need to have test.com be a forwarded zone. In IPA 3 there is no entry for ipa-ca.test.com but I do see it in IPA 4. In my testing I have removed the test.com zone and made it a forwarding zone but that removes the entry for ipa-ca.test.com as well as all the test.com kerberos entries. What I do not know is what did I break when I removed test.com since it is the Kerberos realm. It appears that replication between the servers still works and I was able to add a IPA 4 client server without issue. We plan on using certs generated from IPA 4 for OpenVPN but I do not have enough information to know if the removal of the test.com zone will break that certificate validation and revocation since the ipa-ca.test.com DNS entry no longer exists. I believe where I went wrong was that I should have setup mgmt.test.com as the Kerberos realm rather than test.com and I would not have the questions I do now. Thank you for your help. *Mike Plemmons | Senior DevOps Engineer* 614-741-5475 mike.plemmons at crosschx.com www.crosschx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Nov 18 20:29:39 2016 From: simo at redhat.com (Simo Sorce) Date: Fri, 18 Nov 2016 15:29:39 -0500 Subject: [Freeipa-users] Would fixing hosts file break kerberos In-Reply-To: References: Message-ID: <1479500979.15289.12.camel@redhat.com> On Thu, 2016-11-17 at 15:53 -0500, William Muriithi wrote: > Afternoon. > > I just noticed that I used inappropriate way of setting up my hosts > files and I am planning to make a fix. I am however worried this may > break Kerberos. Should this change be of concern and have anyone made > the changes before? > > My current /etc/hosts are as follows: > 192.168.20.2 ipa ipa.example.com > > I am planning to change them so that the above line looks like this: > 192.168.20.2 ipa.example.com ipa The former may actually break things, the second should "fix" them ... unless you depended on the incorrect configuration in some way ... -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Sun Nov 20 11:00:30 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 20 Nov 2016 12:00:30 +0100 Subject: [Freeipa-users] Is there an simple way to add in sudo time window options in FreeIPA? In-Reply-To: <94AE223E3874284B9502002D06BEE51936C280A4@IHQ-ExchMS01.resources.keywcorp.com> References: <94AE223E3874284B9502002D06BEE51936C280A4@IHQ-ExchMS01.resources.keywcorp.com> Message-ID: <5304A836-2487-4D9F-B16F-A09B607958DA@redhat.com> > On 18 Nov 2016, at 19:12, Robert Kleinberg wrote: > > Would like to establish valid sudo usage windows with sudonotbefore and sudonotafter options. However, I did not see an easy way to set this up other than via an sudo options text entry line. Is there another menu-driven way that shows a schedule of allowed times? > I think at the moment you need to ?setattr or ?addattr the sudo attributes, I don?t think the sudo IPA UI allows settings these ?natively?. > Bob Kleinberg > Lead System Engineer > > KEYW Corporation|www.keywcorp.com > 7740 Milestone Parkway, Suite 400 | Hanover, MD 21076 > 443-737-9703 > > -- > 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 datakid at gmail.com Sun Nov 20 22:48:16 2016 From: datakid at gmail.com (Lachlan Musicman) Date: Mon, 21 Nov 2016 09:48:16 +1100 Subject: [Freeipa-users] packet_write_wait: Connection to x.x.x.x port 22: Broken pipe Message-ID: Hola, I'm getting the above error when trying to login - inconsistently and after the password request. Using debian's openssh 7.3p1-3 going into Centos 7.2, FreeIPA 4.2 and sssd 1.14.2 (from copr). When I google, none of the results seem applicable, but I'm not 100% sure, and testing seems difficult. On the test client, I've set pam_id_timeout and kr5b_auth_timeout to 30 because we found that helped with the transfer of data between the FreeIPA server and the enrolled host, and I thought that might be causing the error. Having added both ServerAliveInterval 60 and ClientAliveInterval 60 just to humour myself (and the google results) but am still getting this result. This is a solution I'd rather not implement anyway, but I thought I'd check. Has anyone seen this before? 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 jamesaharrisonuk at yahoo.co.uk Mon Nov 21 09:14:48 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Mon, 21 Nov 2016 09:14:48 +0000 (UTC) Subject: [Freeipa-users] Something I dont get with FriiIPA and AD Trusts and Users and Greoups References: <1773115772.1645697.1479719688245.ref@mail.yahoo.com> Message-ID: <1773115772.1645697.1479719688245@mail.yahoo.com> Hi all,I have established an AD trust Between Free IPA and our Windows network and its working. No problems there. I have created the IDM Groups for active directory as proposed in section 5.5 of the Windows_Integration_Guide. Now what? The group in Free IPA I've created (from section 5.5) allows me to do what? Am I supposed to get a synchronised list of Domain Admin users in Free IPA? I can log in to a Linux client using AD credentials, regardless of the AD users external map (The user I'm logging is with is a member of the AD Domain Admins group). Many thanks,James Harrison -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Nov 21 09:43:28 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 21 Nov 2016 11:43:28 +0200 Subject: [Freeipa-users] State of External Users feature In-Reply-To: References: Message-ID: <20161121094328.mx73iunc7ogt6zoq@redhat.com> On ti, 15 marras 2016, Christoph H?sler wrote: >The documentation about "External Users in FreeIPA" ( >http://www.freeipa.org/page/External_Users_in_IPA) has not been updated for >quite some time. What is the current state of this feature? Is it still on >the roadmap? It is not currently considered for implementation. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Nov 21 09:45:48 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 21 Nov 2016 11:45:48 +0200 Subject: [Freeipa-users] krb5 and nfsv4 not working right In-Reply-To: <89213DDB84447F44A8E8950A5C2185E0482EB005@SJN01013.jnmain00.corp.jndata.net> References: <15fad8b4-38da-948d-5af6-813e2b926f09@statsbiblioteket.dk> <89213DDB84447F44A8E8950A5C2185E0482EB005@SJN01013.jnmain00.corp.jndata.net> Message-ID: <20161121094548.azvtdjcffyim7apw@redhat.com> On ke, 16 marras 2016, Bjarne Blichfeldt wrote: >Try inserting this in /etc/gssproxy/gssproxy.conf: >cred_store = ccache:FILE:/tmp/krb5cc_%U > > >/etc/gssproxy/gssproxy.conf: >[service/nfs-client] > mechs = krb5 > cred_store = keytab:/etc/krb5.keytab > cred_store = ccache:FILE:/tmp/krb5cc_%U > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U > cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab > cred_usage = initiate > allow_any_uid = yes > trusted = yes > euid = 0 Correct. There is an issue in NFS client utilities called by the kernel to handle credentials via upcall interface that they cannot yet handle kernel keyring-based ccaches. > > >Regards, >Bjarne Blichfeldt > > >-----Original Message----- >From: Tony Brian Albers [mailto:tba at statsbiblioteket.dk] >Sent: 15. november 2016 13:18 >To: freeipa-users at redhat.com >Subject: [Freeipa-users] krb5 and nfsv4 not working right > >Hi guys, > >I've followed every guide I can find on this subject. What I'm trying to is to get our home directories which are shared via NFS from the FreeIPA server mounted via autofs on the clients. > >The client is kact-man-001 and the FreeIPA server is kact-adm-001 > >/etc/exports: > > >I've done the ipa-client-install and the ipa-client-automount > >However, when I log in, my homedir is mounted as expected but what I get in the messages log is: > >Nov 15 12:52:25 kact-man-001 gssproxy: gssproxy[770]: (OID: { 1 2 840 >113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found > >A lot! > >/etc/krb5.conf is default from the FreeIPA installation: > > default_ccache_name = KEYRING:persistent:%{uid} > > >The autofs setup looks like this: > >--------------------------------------------------------- > >[root at kact-adm-001 log]# ipa automountmap-find >Location: default >------------------------ >3 automount maps matched >------------------------ > Map: auto.direct > > Map: auto.home > > Map: auto.master >---------------------------- >Number of entries returned 3 >---------------------------- >[root at kact-adm-001 log]# > > > >[root at kact-adm-001 log]# ipa automountkey-find >Location: default >Map: auto.home >----------------------- >1 automount key matched >----------------------- > Key: * > Mount information: -fstype=nfs4,rw,sec=krb5,rsize=8192,wsize=8192 >kact-adm-001.kact.sblokalnet:/data/home/& >---------------------------- >Number of entries returned 1 >---------------------------- >[root at kact-adm-001 log]# > >--------------------------------------------------------- > >Now, the BAD thing is, trying to copy a large file to the automounted dir on the client just hangs: > >[tba at pc588 images]$ scp NAS4Free-x64-LiveUSB-10.3.0.3.2987.img.gz >tba-sb at kact-man-001.kact.sblokalnet:. >tba-sb at kact-man-001.kact.sblokalnet's password: >NAS4Free-x64-LiveUSB-10.3.0.3.2987.img.gz > 100% 281MB 93.6MB/s >00:03 >[hangs] > >And my logged in session on the client hangs if I try to do ls in my >homedir: >[tba at pc588 ~]$ ssh tba-sb at kact-man-001.kact.sblokalnet >tba-sb at kact-man-001.kact.sblokalnet's password: >Last login: Tue Nov 15 13:07:12 2016 from pc588.sb.statsbiblioteket.dk -sh-4.2$ -sh-4.2$ -sh-4.2$ pwd /home/tba-sb -sh-4.2$ hostname >kact-man-001 >-sh-4.2$ >-sh-4.2$ ls >[hangs] > > >And I see a huge amount of the GSS failures in the messages file on the >client. > > >Any suggestions? > >TIA > > > > >-- >Best regards, > >Tony Albers >Systems administrator, IT-development >State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. >Tel: +45 2566 2383 / +45 8946 2316 > > > >-- >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 abokovoy at redhat.com Mon Nov 21 09:54:18 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 21 Nov 2016 11:54:18 +0200 Subject: [Freeipa-users] LDAP bind permitted for expired passwords In-Reply-To: <0eedce02-c3c4-938d-505d-6d7e645f1f38@pobox.com> References: <0eedce02-c3c4-938d-505d-6d7e645f1f38@pobox.com> Message-ID: <20161121095418.jwsy2klq47zj3cno@redhat.com> On pe, 18 marras 2016, Brian Candler wrote: >Looking at FreeIPA 4.2 under CentOS 7: I find that LDAP simple binds >succeed even for DNs whose krbPasswordExpiration time has passed. Is >this fixed, or is it possible to change this? Not yet. We have a ticket you can look at and read the history of discussion there. >The reason I ask is because some applications use LDAP bind as a >password validation oracle: for example, if you configure a Sophos UTM >to use LDAP, it works this way. > >I realise that an LDAP bind doesn't give a way to prompt the user to >change their password. However, a failure could be used to force the >user to go to the web UI to reset it (and you could always notify >people by E-mail if their password is about to expire) The problem is in changing expired passwords -- if disable ability to do LDAP bind for expired passwords, you will not be able to change passwords as you'll not be able to bind to do the change. These are two different LDAP operations but they are combined. In past we also lacked support from 389-ds to allow us to handle expired password changes without disabling the bind process. See https://fedorahosted.org/freeipa/ticket/1539 for more details. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Nov 21 09:57:11 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 21 Nov 2016 11:57:11 +0200 Subject: [Freeipa-users] Something I dont get with FriiIPA and AD Trusts and Users and Greoups In-Reply-To: <1773115772.1645697.1479719688245@mail.yahoo.com> References: <1773115772.1645697.1479719688245.ref@mail.yahoo.com> <1773115772.1645697.1479719688245@mail.yahoo.com> Message-ID: <20161121095711.troaieky2abauknx@redhat.com> On ma, 21 marras 2016, James Harrison wrote: >Hi all,I have established an AD trust Between Free IPA and our Windows network and its working. No problems there. >I have created the IDM Groups for active directory as proposed in section 5.5 of the Windows_Integration_Guide. >Now what? The group in Free IPA I've created (from section 5.5) allows >me to do what? Am I supposed to get a synchronised list of Domain Admin >users in Free IPA? Please read archives of this list. This was discussed multiple times. See, for example, this thread: https://www.redhat.com/archives/freeipa-users/2016-October/msg00083.html -- / Alexander Bokovoy From BJB at jndata.dk Mon Nov 21 12:29:32 2016 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Mon, 21 Nov 2016 12:29:32 +0000 Subject: [Freeipa-users] keytab kvno differs between ipa servers Message-ID: <89213DDB84447F44A8E8950A5C2185E0482F1EFE@SJN01013.jnmain00.corp.jndata.net> IPA: VERSION: 4.4.0, API_VERSION: 2.213 This may be for lack of understanding the process, but.. When I retrieve a keytab for a principal using ipa-getkeytab, the kvno is increased on the idm. In our test environment we have two ipa servers running and the kvno is only increased on one of them. After several retrivals, one principals kvno is now on 5 on ipa1 and 18 on ipa2. That means the resulting keytab is only usable on one ipa server and results in a "password expired" message from the other ipa server. How do I synchronize the two Kerberos servers and how do I avoid this? Regards Bjarne Blichfeldt -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Nov 21 12:42:45 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 21 Nov 2016 13:42:45 +0100 Subject: [Freeipa-users] keytab kvno differs between ipa servers In-Reply-To: <89213DDB84447F44A8E8950A5C2185E0482F1EFE@SJN01013.jnmain00.corp.jndata.net> References: <89213DDB84447F44A8E8950A5C2185E0482F1EFE@SJN01013.jnmain00.corp.jndata.net> Message-ID: <8bcbf1ec-78aa-a331-aad6-6d7caf0d4f7a@redhat.com> On 21.11.2016 13:29, Bjarne Blichfeldt wrote: > IPA: VERSION: 4.4.0, API_VERSION: 2.213 > > This may be for lack of understanding the process, but.. > > When I retrieve a keytab for a principal using ipa-getkeytab, the kvno is increased on the idm. > In our test environment we have two ipa servers running and the kvno is only increased on one of them. After several retrivals, one principals kvno is now on 5 on ipa1 and 18 on ipa2. > > That means the resulting keytab is only usable on one ipa server and results in a "password expired" message from the other ipa server. > > How do I synchronize the two Kerberos servers and how do I avoid this? This might be caused by broken replication between your IPA servers: http://www.freeipa.org/page/Troubleshooting#Replication_issues -- Petr^2 Spacek From BJB at jndata.dk Mon Nov 21 13:54:18 2016 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Mon, 21 Nov 2016 13:54:18 +0000 Subject: [Freeipa-users] keytab kvno differs between ipa servers In-Reply-To: <8bcbf1ec-78aa-a331-aad6-6d7caf0d4f7a@redhat.com> References: <89213DDB84447F44A8E8950A5C2185E0482F1EFE@SJN01013.jnmain00.corp.jndata.net> <8bcbf1ec-78aa-a331-aad6-6d7caf0d4f7a@redhat.com> Message-ID: <89213DDB84447F44A8E8950A5C2185E0482F20CB@SJN01013.jnmain00.corp.jndata.net> ok Thanks I will try to debug that. No errors in the logs, the ldapsearch from your link works fine.. ok work ahead... Regards Bjarne Blichfeldt -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: 21. november 2016 13:43 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] keytab kvno differs between ipa servers On 21.11.2016 13:29, Bjarne Blichfeldt wrote: > IPA: VERSION: 4.4.0, API_VERSION: 2.213 > > This may be for lack of understanding the process, but.. > > When I retrieve a keytab for a principal using ipa-getkeytab, the kvno is increased on the idm. > In our test environment we have two ipa servers running and the kvno is only increased on one of them. After several retrivals, one principals kvno is now on 5 on ipa1 and 18 on ipa2. > > That means the resulting keytab is only usable on one ipa server and results in a "password expired" message from the other ipa server. > > How do I synchronize the two Kerberos servers and how do I avoid this? This might be caused by broken replication between your IPA servers: http://www.freeipa.org/page/Troubleshooting#Replication_issues -- Petr^2 Spacek -- 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 datakid at gmail.com Mon Nov 21 23:16:29 2016 From: datakid at gmail.com (Lachlan Musicman) Date: Tue, 22 Nov 2016 10:16:29 +1100 Subject: [Freeipa-users] Shadow Utils appears in sssd.conf In-Reply-To: <20161116083905.GA16665@10.4.128.1> References: <20161116083905.GA16665@10.4.128.1> Message-ID: Great - thank you. That worked. Unfortunately SELinux creates too much overhead on a subset of our servers, so we have it disabled. cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 16 November 2016 at 19:39, Lukas Slebodnik wrote: > On (16/11/16 11:46), Lachlan Musicman wrote: > >I don't know what I've done wrong, but when I use ipa-client-install on a > >new host to add to my one way trust domain, I now have a > >[domain/shadowutils] stanza. > > > >This first happened a couple of weeks ago, I saw this bug and thought "it > >will be solved soon". > > > >https://bugzilla.redhat.com/show_bug.cgi?id=1369118 > > > >The report says it's been resolved in a recent advisory but I'm still > >seeing the error. > > > It was fixed by reverting upstream commit which > introduced such seature. > https://git.fedorahosted.org/cgit/sssd.git/commit/?id= > 59744cff6edb106ae799b2321cb8731edadf409a > > >Is it because I'm using sssd 1.14.2-1 from COPR instead of the centrally > >supplied sssd? > > > Yes, theis feature is still available in upstream/fedora. > > A) "domain/shadowutils" should not cause any problems. > If yes then it should be also reproducible on fedora > please filae a bug. > > B) It does not happen with SELinux in enforcing mode. > Another reason for "setenforce 1" :-) > > LS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tk at mdevsys.com Tue Nov 22 05:33:02 2016 From: tk at mdevsys.com (TomK) Date: Tue, 22 Nov 2016 00:33:02 -0500 Subject: [Freeipa-users] Ping forwarded domain name. Message-ID: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> Hey Guy's, I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 over to my dual Free IPA server. The Free IPA servers are authoritative for this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz and forwards dom.abc.xyz. I cannot ping dom.abc.xyz. Everything else, including client registrations, work fine. If Free IPA is authoritative on dom.abc.xyz, should it not create DNS entries so the sub domain can be pinged as well? /etc/resolv.conf also get's regenerated on reboot on the IPA Servers and wanted to ask if you can point me to some materials online to determine where can I permanently adjust the search to add dom.abc.xyz to the already present abc.xyz . I wasn't able to locate what I needed in my searches. I'm using the latest v4. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From mbasti at redhat.com Tue Nov 22 07:59:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 22 Nov 2016 08:59:44 +0100 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> Message-ID: Hey, On 22.11.2016 06:33, TomK wrote: > Hey Guy's, > > I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 over to > my dual Free IPA server. The Free IPA servers are authoritative for > this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz > and forwards dom.abc.xyz. Do you have configured proper zone delegation for subdomain dom.abc.xyz? Proper NS and glue records http://www.zytrax.com/books/dns/ch9/delegate.html > > I cannot ping dom.abc.xyz. Everything else, including client > registrations, work fine. If Free IPA is authoritative on > dom.abc.xyz, should it not create DNS entries so the sub domain can be > pinged as well? What do you mean by "ping"? > > /etc/resolv.conf also get's regenerated on reboot on the IPA Servers > and wanted to ask if you can point me to some materials online to > determine where can I permanently adjust the search to add dom.abc.xyz > to the already present abc.xyz . I wasn't able to locate what I > needed in my searches. > > I'm using the latest v4. It depends on what are you using, probably you have NetworkManager there that is editing /etc/resolv.conf https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ Martin From bretif at phosphore.eu Tue Nov 22 09:07:12 2016 From: bretif at phosphore.eu (Bertrand =?utf-8?Q?R=C3=A9tif?=) Date: Tue, 22 Nov 2016 10:07:12 +0100 (CET) Subject: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue In-Reply-To: <835252359.90240.1477410669922.JavaMail.zimbra@phosphore.eu> References: <1383346498.1295916.1476825748599.JavaMail.zimbra@phosphore.eu> <1101487784.1356614.1476878994121.JavaMail.zimbra@phosphore.eu> <58077566.8010401@redhat.com> <719022987.1370764.1476884527122.JavaMail.zimbra@phosphore.eu> <1467699597.1398215.1476901090793.JavaMail.zimbra@phosphore.eu> <835252359.90240.1477410669922.JavaMail.zimbra@phosphore.eu> Message-ID: <1898060535.461337.1479805632262.JavaMail.zimbra@phosphore.eu> ----- Mail original ----- > De: "Bertrand R?tif" > ?: freeipa-users at redhat.com > Envoy?: Mardi 25 Octobre 2016 17:51:09 > Objet: Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue > ----- Mail original ----- > > De: "Florence Blanc-Renaud" > > > ?: "Bertrand R?tif" , freeipa-users at redhat.com > > > Envoy?: Jeudi 20 Octobre 2016 18:45:21 > > > Objet: Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat > > issue > > > On 10/19/2016 08:18 PM, Bertrand R?tif wrote: > > > > *De: *"Bertrand R?tif" > > > > > > > > *?: *freeipa-users at redhat.com > > > > *Envoy?: *Mercredi 19 Octobre 2016 15:42:07 > > > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > > > pki-tomcat issue > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > *De: *"Rob Crittenden" > > > > *?: *"Bertrand R?tif" , > > > > freeipa-users at redhat.com > > > > *Envoy?: *Mercredi 19 Octobre 2016 15:30:14 > > > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > > > pki-tomcat issue > > > > > > > > Bertrand R?tif wrote: > > > > >> De: "Martin Babinsky" > > > > >> ?: freeipa-users at redhat.com > > > > >> Envoy?: Mercredi 19 Octobre 2016 08:45:49 > > > > >> Objet: Re: [Freeipa-users] Impossible to renew certificate. > > > > pki-tomcat issue > > > > > > > > > >> On 10/18/2016 11:22 PM, Bertrand R?tif wrote: > > > > >>> Hello, > > > > >>> > > > > >>> I had an issue with pki-tomcat. > > > > >>> I had serveral certificate that was expired and pki-tomcat > > > > did not start > > > > >>> anymore. > > > > >>> > > > > >>> I set the dateon the server before certificate expiration > > > > and then > > > > >>> pki-tomcat starts properly. > > > > >>> Then I try to resubmit the certificate, but I get below error: > > > > >>> "Profile caServerCert Not Found" > > > > >>> > > > > >>> Do you have any idea how I could fix this issue. > > > > >>> > > > > >>> Please find below output of commands: > > > > >>> > > > > >>> > > > > >>> # getcert resubmit -i 20160108170324 > > > > >>> > > > > >>> # getcert list -i 20160108170324 > > > > >>> Number of certificates and requests being tracked: 7. > > > > >>> Request ID '20160108170324': > > > > >>> status: MONITORING > > > > >>> ca-error: Server at > > > > >>> "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit" > > > > replied: > > > > >>> Profile caServerCert Not Found > > > > >>> stuck: no > > > > >>> key pair storage: > > > > >>> > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > >>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > >>> certificate: > > > > >>> > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > >>> Certificate DB' > > > > >>> CA: dogtag-ipa-ca-renew-agent > > > > >>> issuer: CN=Certificate Authority,O=A.SKINFRA.EU > > > > >>> subject: CN=IPA RA,O=A.SKINFRA.EU > > > > >>> expires: 2016-06-28 15:25:11 UTC > > > > >>> key usage: > > > > >>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > >>> eku: id-kp-serverAuth,id-kp-clientAuth > > > > >>> pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > > >>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > > > > >>> track: yes > > > > >>> auto-renew: yes > > > > >>> > > > > >>> > > > > >>> Thanksby advance for your help. > > > > >>> Bertrand > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > > > > > > >> Hi Betrand, > > > > > > > > > >> what version of FreeIPA and Dogtag are you running? > > > > > > > > > >> Also perform the following search on the IPA master and post > > > > the result: > > > > > > > > > >> """ > > > > >> ldapsearch -D "cn=Directory Manager" -W -b > > > > >> 'ou=certificateProfiles,ou=ca,o=ipaca' > > > > '(objectClass=certProfile)' > > > > >> """ > > > > > > > > > > Hi Martin, > > > > > > > > > > Thanks for your reply. > > > > > > > > > > Here is version: > > > > > - FreeIPA 4.2.0 > > > > > - Centos 7.2 > > > > > > > > > > I have been able to fix the issue with "Profile caServerCert > > > > Not Found" by editing /var/lib/pki/pki-tomcat/ca/conf/CS.cfg > > > > > I replace below entry > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem" > > > > > by > > > > > "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem" > > > > > > > > > > and then launch "ipa-server-upgrade" command > > > > > I found this solution in this post: > > > > http://osdir.com/ml/freeipa-users/2016-03/msg00280.html > > > > > > > > > > Then I was able to renew my certificate. > > > > > > > > > > However I reboot my server to and pki-tomcat do not start and > > > > provide with a new erreor in /var/log/pki/pki-tomcat/ca/debug > > > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: CertUtils: > > > > verifySystemCertByNickname() passed: auditSigningCert cert-pki-ca > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > SignedAuditEventFactory: create() > > > > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$ > > > > > System$][Outcome=Success][CertNickName=auditSigningCert > > > > cert-pki-ca] CIMC certificate verification > > > > > > > > > > java.lang.Exception: SystemCertsVerification: system certs > > > > verification failure > > > > > at > > > > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) > > > > > at > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) > > > > > at > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) > > > > > at > > > > com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701) > > > > > at > > > > com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148) > > > > > at com.netscape.certsrv.apps.CMS.startup(CMS.java:200) > > > > > at com.netscape.certsrv.apps.CMS.start(CMS.java:1602) > > > > > at > > > > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) > > > > > at javax.servlet.GenericServlet.init(GenericServlet.java:158) > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > > at > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > > at > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > > at java.lang.reflect.Method.invoke(Method.java:606) > > > > > at > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) > > > > > at > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) > > > > > at java.security.AccessController.doPrivileged(Native Method) > > > > > at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) > > > > > at > > > > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) > > > > > at > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) > > > > > at > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) > > > > > at > > > > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) > > > > > at > > > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) > > > > > at > > > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) > > > > > at > > > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) > > > > > at > > > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) > > > > > at > > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > > > > > at > > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > > > > at > > > > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > > > > > at > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > > > > > at > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > > > > > at java.security.AccessController.doPrivileged(Native Method) > > > > > at > > > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > > > > > at > > > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > > > > > at > > > > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > > > > > at > > > > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > > > > > at > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > > > > > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > > > > > at > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > > > at > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > SignedAuditEventFactory: create() > > > > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] > > > > self tests execution (see selftests.log for details) > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > CMSEngine.shutdown() > > > > > > > > > > > > > > > I am currently stuck here. > > > > > Thanks a lot for your help. > > > > > > > > I'm guessing at least one of the CA subsystem certificates are > > > > still > > > > expired. Look at the "getcert list" output to see if there are any > > > > expired certificates. > > > > > > > > rob > > > > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > > > > > Hello Rob, > > > > > > > > I check on my 2 servers and no certificate is expired > > > > > > > > [root at sdkipa03 ~]# getcert list |grep expire > > > > expires: 2018-06-22 22:02:26 UTC > > > > expires: 2018-06-22 22:02:47 UTC > > > > expires: 2034-07-09 15:24:34 UTC > > > > expires: 2016-10-30 13:35:29 UTC > > > > > > > > [root at sdkipa01 conf]# getcert list |grep expire > > > > expires: 2018-06-12 23:38:01 UTC > > > > expires: 2018-06-12 23:37:41 UTC > > > > expires: 2018-06-11 22:53:57 UTC > > > > expires: 2018-06-11 22:55:50 UTC > > > > expires: 2018-06-11 22:57:47 UTC > > > > expires: 2034-07-09 15:24:34 UTC > > > > expires: 2018-06-11 22:59:55 UTC > > > > > > > > I see that one certificate is in status: CA_UNREACHABLE, maybe I > > > > reboot to soon my server... > > > > > > > > I continue to investigate > > > > > > > > Thanks for your help. > > > > Bertrand > > > > > > > > I fix my previous issue. > > > > Now I have an issue with a server. > > > > This server can not start pki-tomcatd, I get this error in debug file: > > > > "Error netscape.ldap.LDAPExceptio n: IO Error creating JSS SSL Socket > > > (-1)" > > > > > > > > After investigation i see that I do not have "ipaCert" certificat in > > > > "/etc/httpd/alias" > > > > cf below command: > > > > > > > > [root at sdkipa03 ~]# getcert list -d /etc/httpd/alias > > > > Number of certificates and requests being tracked: 4. > > > > Request ID '20141110133632': > > > > status: MONITORING > > > > stuck: no > > > > 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=A.SKINFRA.EU > > > > subject: CN=sdkipa03.skinfra.eu,O=A.SKINFRA.EU > > > > expires: 2018-06-22 22:02:47 UTC > > > > principal name: HTTP/sdkipa03.skinfra.eu at A.SKINFRA.EU > > > > key usage: > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > > pre-save command: > > > > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > > > > track: yes > > > > auto-renew: yes > > > > > > > > > > > > How can I add the certificate to /etc/httpd/alias? > > > > > > > Hi, > > > for the record, the command getcert list that you supplied shows the > > > certificates in /etc/httpd/alias that are tracked by certmonger. If you > > > want to display all the certificates contained in /etc/httpd/alias > > > (whether tracked or not), then you may want to use certutil -L -d > > > /etc/httpd/alias instead. > > > If ipaCert is missing, you can export ipaCert certificate from another > > > master, then import it to your server. > > > On a master containing the cert: > > > # certutil -d /etc/httpd/alias -L -n 'ipaCert' -a > /tmp/newRAcert.crt > > > Then copy the file /tmp/newRAcert.crt to your server and import the cert: > > > # certutil -d /etc/httpd/alias -A -n 'ipaCert' -a -i /tmp/newRAcert.crt > > > -t u,u,u > > > And finally you need to tell certmonger to monitor the cert using > > > getcert start-tracking. > > > Hope this helps, > > > Flo. > > > > Thanks fo ryour support. > > > > Regards > > > > Bertrand > > > > > > > > > > > > > > Hi, > Florence, thanks for your help. > I was able to import correctly ipaCert with your commands. > Now it seems that I also have an issue on one server with "subsystemCert > cert-pki-ca" in /etc/pki/pki-tomcat/alias as I get below error when > pki-tomcat try to start > LdapJssSSLSocket set client auth cert nickname subsystemCert cert-pki-ca > Could not connect to LDAP server host sdkipa03.XX.YY port 636 Error > netscape.ldap.LDAPException: IO Error creating JSS SSL Socket ( > -1) > Is there a way to restore a correct "subsystemCert cert-pki-ca"? > Regards > Bertrand Hello, I am still stuck with my IPA server. I have issues on both servers. On server1, below certificate is not renewed properly certutil -L -d /etc/httpd/alias/ -n "ipaCert" and on server 2 this is this certificate: certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "Server-Cert cert-pki-ca" Could you provide me with the correct syntax with start-tracking command. I tried to laucnh this command but my certificat remains in "NEWLY_ADDED_NEED_KEYINFO_READ_PIN" state. Here is the comnd I use: getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d /var/lib/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -B /usr/lib64/ipa/certmonger/stop_pkicad -C '/usr/lib64/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"' -T "Server-Cert cert-pki-ca" -P '20160614000000' Thanks by advance for your help. Regards Bertrand -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Tue Nov 22 09:24:34 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 22 Nov 2016 10:24:34 +0100 Subject: [Freeipa-users] keytab kvno differs between ipa servers In-Reply-To: <89213DDB84447F44A8E8950A5C2185E0482F20CB@SJN01013.jnmain00.corp.jndata.net> References: <89213DDB84447F44A8E8950A5C2185E0482F1EFE@SJN01013.jnmain00.corp.jndata.net> <8bcbf1ec-78aa-a331-aad6-6d7caf0d4f7a@redhat.com> <89213DDB84447F44A8E8950A5C2185E0482F20CB@SJN01013.jnmain00.corp.jndata.net> Message-ID: <20161122092434.GC2754@10.4.128.1> On (21/11/16 13:54), Bjarne Blichfeldt wrote: >ok Thanks > >I will try to debug that. No errors in the logs, the ldapsearch from your link works fine.. >ok work ahead... > >Regards > >Bjarne Blichfeldt > man 1 ipa-getkeytab says: WARNING: retrieving the keytab resets the secret for the Kerberos prin? cipal. This renders all other keytabs for that principal invalid. and also there is an option: -r Retrieve mode. Retrieve an existing key from the server instead of generating a new one. This is incompatibile with the --pass? word option, and will work only against a FreeIPA server more recent than version 3.3. The user requesting the keytab must have access to the keys for this operation to succeed. HTH LS From BJB at jndata.dk Tue Nov 22 10:15:37 2016 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Tue, 22 Nov 2016 10:15:37 +0000 Subject: [Freeipa-users] keytab kvno differs between ipa servers In-Reply-To: <20161122092434.GC2754@10.4.128.1> References: <89213DDB84447F44A8E8950A5C2185E0482F1EFE@SJN01013.jnmain00.corp.jndata.net> <8bcbf1ec-78aa-a331-aad6-6d7caf0d4f7a@redhat.com> <89213DDB84447F44A8E8950A5C2185E0482F20CB@SJN01013.jnmain00.corp.jndata.net> <20161122092434.GC2754@10.4.128.1> Message-ID: <89213DDB84447F44A8E8950A5C2185E0482FE4FE@SJN01013.jnmain00.corp.jndata.net> Thanks for the suggestion. yes I tried the -r option but could not get it to work. Permission denied even as admin. In the design paper it looks like this is not yet implemented for user principals. I ended up retrieving the required keytab entry and put it in a configuration channel in satellite. That makes it easy to distribute. I haven?t located he replication problem yet, but did a "ipa-replica-manage re-initialize". That got the kvno to same level. Havent had the courage to retrieve the keytab to test the replication yet. Will do that in a different environment shortly. Regards Bjarne Blichfeldt. -----Original Message----- From: Lukas Slebodnik [mailto:lslebodn at redhat.com] Sent: 22. november 2016 10:25 To: Bjarne Blichfeldt Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] keytab kvno differs between ipa servers On (21/11/16 13:54), Bjarne Blichfeldt wrote: >ok Thanks > >I will try to debug that. No errors in the logs, the ldapsearch from your link works fine.. >ok work ahead... > >Regards > >Bjarne Blichfeldt > man 1 ipa-getkeytab says: WARNING: retrieving the keytab resets the secret for the Kerberos prin? cipal. This renders all other keytabs for that principal invalid. and also there is an option: -r Retrieve mode. Retrieve an existing key from the server instead of generating a new one. This is incompatibile with the --pass? word option, and will work only against a FreeIPA server more recent than version 3.3. The user requesting the keytab must have access to the keys for this operation to succeed. HTH LS From stijn.deweirdt at ugent.be Tue Nov 22 10:25:38 2016 From: stijn.deweirdt at ugent.be (Stijn De Weirdt) Date: Tue, 22 Nov 2016 11:25:38 +0100 Subject: [Freeipa-users] minimise impact compromised host In-Reply-To: References: <520773e2-752d-8f4b-b770-3e079f2a7045@redhat.com> <5a26a1d4-e702-f428-22f2-b742d661bcc3@redhat.com> Message-ID: <6c8a7cea-bd52-8b39-2c2e-b34fbd5d5dd6@ugent.be> hi petr, i reread the links and some other info. it should indeed not be possible to abuse those. i thought i was once able to abuse these, but i've tried to reproduce what i did and failed (probably some ssh forwarding was mixed at that time). stijn On 11/16/2016 06:58 PM, Petr Spacek wrote: > On 16.11.2016 18:26, Stijn De Weirdt wrote: >> hi petr, >> >>>>>> this is a different question: what can we do such that compromised host >>>>>> can do a little as possible if the admin doesn't (yet) know the host is >>>>>> compromised. >>>>>> >>>>>> the default policy allows way too much. >>>>> >>>>> For any useful advice we need more details. >>>>> >>>>> What are the operations you want to disable? >>>> at the very least, "kvno userlogin" should fail (i.e. access to a host >>>> keytab shouldn't permit retrieval of arbitrary user token). >>> >>> I think that this is misunderstanding. >> i'll spend some more time rereading and getting a better understanding >> (again ;) >> >>> >>> "kvno userlogin" does not allow the attacker to do anything. The result of >>> kvno command is a service ticket for particular principal (user, host). >>> >>> The attacker can use this service ticket *for authentication to the particular >>> principal* (user, host). >>> >>> So the only thing the attacker can do is to prove its identity to given (user, >>> host). This exactly matches capabilities the attacker already has - the full >>> control over the host. >> hhmm, ok. is there a way to let e.g. klist show this? it now says >> 'userlogin at REALM' in the 'Service principal' column. for the (user,host) >> combo i expected to see a userlogin/fqdn at REALM, like other service tokens. >> >> anyway, clearly i'm missing something here. > > The important field is 'Default principal:' which is above the list of > tickets. It contains name of the principal "who you are". > > Rest of the list shows just service tickets which are used to authenticate you > to the services listed in the list. It just means that you tried to contact > them some time ago (or called kvno explicitly). > > Please go and read some articles about Kerberos protocol, e.g. the Wikipedia > article I linked below. It will explain a lot of things. > > Petr^2 Spacek > >> >> >> stijn >> >>> >>> Please see >>> https://en.wikipedia.org/wiki/Kerberos_(protocol)#Client_Service_Request >>> for further details on this. >>> >>> Does it explain the situation? >>> >>> Petr^2 Spacek >>> >>>> >>>> i'm assuming that retrieval of service tokens for another host is >>>> already not possible? (ie if you have keyatb of fqdn1, you shouldn't be >>>> able to retrieve a token for SERVICE/fqdn2 at REALM). >>>> >>>> stijn >>>> >>>>> >>>>> Petr^2 Spacek >>>>> >>>>> >>>>>> >>>>>> how to clean it up once you know the host is compromised is the subject >>>>>> of the other thread. >>>>>> >>>>>> stijn >>>>>> >>>>>>> >>>>>>> In the case that the host is compromised/stolen/hijacked, you can >>>>>>> host-disable it to invalidate the keytab stored there but this does not >>>>>>> prevent anyone logged on that host to bruteforce/DOS user accounts by >>>>>>> trying to guess their Kerberos keys by repeated kinit. >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> > > From flo at redhat.com Tue Nov 22 10:33:45 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 22 Nov 2016 11:33:45 +0100 Subject: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue In-Reply-To: <1898060535.461337.1479805632262.JavaMail.zimbra@phosphore.eu> References: <1383346498.1295916.1476825748599.JavaMail.zimbra@phosphore.eu> <1101487784.1356614.1476878994121.JavaMail.zimbra@phosphore.eu> <58077566.8010401@redhat.com> <719022987.1370764.1476884527122.JavaMail.zimbra@phosphore.eu> <1467699597.1398215.1476901090793.JavaMail.zimbra@phosphore.eu> <835252359.90240.1477410669922.JavaMail.zimbra@phosphore.eu> <1898060535.461337.1479805632262.JavaMail.zimbra@phosphore.eu> Message-ID: On 11/22/2016 10:07 AM, Bertrand R?tif wrote: > ------------------------------------------------------------------------ > > *De: *"Bertrand R?tif" > *?: *freeipa-users at redhat.com > *Envoy?: *Mardi 25 Octobre 2016 17:51:09 > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > pki-tomcat issue > > > ------------------------------------------------------------------------ > > *De: *"Florence Blanc-Renaud" > *?: *"Bertrand R?tif" , > freeipa-users at redhat.com > *Envoy?: *Jeudi 20 Octobre 2016 18:45:21 > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > pki-tomcat issue > > On 10/19/2016 08:18 PM, Bertrand R?tif wrote: > > *De: *"Bertrand R?tif" > > > > *?: *freeipa-users at redhat.com > > *Envoy?: *Mercredi 19 Octobre 2016 15:42:07 > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > pki-tomcat issue > > > > > > > ------------------------------------------------------------------------ > > > > *De: *"Rob Crittenden" > > *?: *"Bertrand R?tif" , > > freeipa-users at redhat.com > > *Envoy?: *Mercredi 19 Octobre 2016 15:30:14 > > *Objet: *Re: [Freeipa-users] Impossible to renew > certificate. > > pki-tomcat issue > > > > Bertrand R?tif wrote: > > >> De: "Martin Babinsky" > > >> ?: freeipa-users at redhat.com > > >> Envoy?: Mercredi 19 Octobre 2016 08:45:49 > > >> Objet: Re: [Freeipa-users] Impossible to renew > certificate. > > pki-tomcat issue > > > > > >> On 10/18/2016 11:22 PM, Bertrand R?tif wrote: > > >>> Hello, > > >>> > > >>> I had an issue with pki-tomcat. > > >>> I had serveral certificate that was expired and > pki-tomcat > > did not start > > >>> anymore. > > >>> > > >>> I set the dateon the server before certificate > expiration > > and then > > >>> pki-tomcat starts properly. > > >>> Then I try to resubmit the certificate, but I get > below error: > > >>> "Profile caServerCert Not Found" > > >>> > > >>> Do you have any idea how I could fix this issue. > > >>> > > >>> Please find below output of commands: > > >>> > > >>> > > >>> # getcert resubmit -i 20160108170324 > > >>> > > >>> # getcert list -i 20160108170324 > > >>> Number of certificates and requests being tracked: 7. > > >>> Request ID '20160108170324': > > >>> status: MONITORING > > >>> ca-error: Server at > > >>> > "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit" > > replied: > > >>> Profile caServerCert Not Found > > >>> stuck: no > > >>> key pair storage: > > >>> > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > >>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > >>> certificate: > > >>> > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > >>> Certificate DB' > > >>> CA: dogtag-ipa-ca-renew-agent > > >>> issuer: CN=Certificate Authority,O=A.SKINFRA.EU > > >>> subject: CN=IPA RA,O=A.SKINFRA.EU > > >>> expires: 2016-06-28 15:25:11 UTC > > >>> key usage: > > >>> > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > >>> eku: id-kp-serverAuth,id-kp-clientAuth > > >>> pre-save command: > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > >>> post-save command: > /usr/lib64/ipa/certmonger/renew_ra_cert > > >>> track: yes > > >>> auto-renew: yes > > >>> > > >>> > > >>> Thanksby advance for your help. > > >>> Bertrand > > >>> > > >>> > > >>> > > >>> > > > > > >> Hi Betrand, > > > > > >> what version of FreeIPA and Dogtag are you running? > > > > > >> Also perform the following search on the IPA master > and post > > the result: > > > > > >> """ > > >> ldapsearch -D "cn=Directory Manager" -W -b > > >> 'ou=certificateProfiles,ou=ca,o=ipaca' > > '(objectClass=certProfile)' > > >> """ > > > > > > Hi Martin, > > > > > > Thanks for your reply. > > > > > > Here is version: > > > - FreeIPA 4.2.0 > > > - Centos 7.2 > > > > > > I have been able to fix the issue with "Profile > caServerCert > > Not Found" by editing > /var/lib/pki/pki-tomcat/ca/conf/CS.cfg > > > I replace below entry > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem" > > > by > > > > "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem" > > > > > > and then launch "ipa-server-upgrade" command > > > I found this solution in this post: > > http://osdir.com/ml/freeipa-users/2016-03/msg00280.html > > > > > > Then I was able to renew my certificate. > > > > > > However I reboot my server to and pki-tomcat do not > start and > > provide with a new erreor in > /var/log/pki/pki-tomcat/ca/debug > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > CertUtils: > > verifySystemCertByNickname() passed: auditSigningCert > cert-pki-ca > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > SignedAuditEventFactory: create() > > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$ > > > System$][Outcome=Success][CertNickName=auditSigningCert > > cert-pki-ca] CIMC certificate verification > > > > > > java.lang.Exception: SystemCertsVerification: system > certs > > verification failure > > > at > > > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) > > > at > > > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) > > > at > > > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) > > > at > > > com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701) > > > at > > > com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148) > > > at com.netscape.certsrv.apps.CMS.startup(CMS.java:200) > > > at com.netscape.certsrv.apps.CMS.start(CMS.java:1602) > > > at > > > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) > > > at > javax.servlet.GenericServlet.init(GenericServlet.java:158) > > > at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > at java.lang.reflect.Method.invoke(Method.java:606) > > > at > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) > > > at > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) > > > at > java.security.AccessController.doPrivileged(Native Method) > > > at > javax.security.auth.Subject.doAsPrivileged(Subject.java:536) > > > at > > > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) > > > at > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) > > > at > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) > > > at > > > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) > > > at > > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) > > > at > > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) > > > at > > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) > > > at > > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) > > > at > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > > > at > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > > at > > > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > > > at > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > > > at > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > > > at > java.security.AccessController.doPrivileged(Native Method) > > > at > > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > > > at > > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > > > at > > > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > > > at > > > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > > > at > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > > > at > java.util.concurrent.FutureTask.run(FutureTask.java:262) > > > at > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > at > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > at java.lang.Thread.run(Thread.java:745) > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > SignedAuditEventFactory: create() > > > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] > > self tests execution (see selftests.log for details) > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > CMSEngine.shutdown() > > > > > > > > > I am currently stuck here. > > > Thanks a lot for your help. > > > > I'm guessing at least one of the CA subsystem > certificates are > > still > > expired. Look at the "getcert list" output to see if > there are any > > expired certificates. > > > > rob > > > > > > > > Bertrand > > > > > > > > > > Hello Rob, > > > > I check on my 2 servers and no certificate is expired > > > > [root at sdkipa03 ~]# getcert list |grep expire > > expires: 2018-06-22 22:02:26 UTC > > expires: 2018-06-22 22:02:47 UTC > > expires: 2034-07-09 15:24:34 UTC > > expires: 2016-10-30 13:35:29 UTC > > > > [root at sdkipa01 conf]# getcert list |grep expire > > expires: 2018-06-12 23:38:01 UTC > > expires: 2018-06-12 23:37:41 UTC > > expires: 2018-06-11 22:53:57 UTC > > expires: 2018-06-11 22:55:50 UTC > > expires: 2018-06-11 22:57:47 UTC > > expires: 2034-07-09 15:24:34 UTC > > expires: 2018-06-11 22:59:55 UTC > > > > I see that one certificate is in status: CA_UNREACHABLE, > maybe I > > reboot to soon my server... > > > > I continue to investigate > > > > Thanks for your help. > > Bertrand > > > > I fix my previous issue. > > Now I have an issue with a server. > > This server can not start pki-tomcatd, I get this error in > debug file: > > "Error netscape.ldap.LDAPExceptio n: IO Error creating JSS SSL > Socket (-1)" > > > > After investigation i see that I do not have "ipaCert" > certificat in > > "/etc/httpd/alias" > > cf below command: > > > > [root at sdkipa03 ~]# getcert list -d /etc/httpd/alias > > Number of certificates and requests being tracked: 4. > > Request ID '20141110133632': > > status: MONITORING > > stuck: no > > 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=A.SKINFRA.EU > > subject: CN=sdkipa03.skinfra.eu,O=A.SKINFRA.EU > > expires: 2018-06-22 22:02:47 UTC > > principal name: HTTP/sdkipa03.skinfra.eu at A.SKINFRA.EU > > key usage: > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > > track: yes > > auto-renew: yes > > > > > > How can I add the certificate to /etc/httpd/alias? > > > Hi, > > for the record, the command getcert list that you supplied shows > the > certificates in /etc/httpd/alias that are tracked by certmonger. > If you > want to display all the certificates contained in /etc/httpd/alias > (whether tracked or not), then you may want to use certutil -L -d > /etc/httpd/alias instead. > > If ipaCert is missing, you can export ipaCert certificate from > another > master, then import it to your server. > > On a master containing the cert: > # certutil -d /etc/httpd/alias -L -n 'ipaCert' -a > > /tmp/newRAcert.crt > > Then copy the file /tmp/newRAcert.crt to your server and import > the cert: > # certutil -d /etc/httpd/alias -A -n 'ipaCert' -a -i > /tmp/newRAcert.crt > -t u,u,u > > And finally you need to tell certmonger to monitor the cert using > getcert start-tracking. > > Hope this helps, > Flo. > > > Thanks fo ryour support. > > Regards > > Bertrand > > > > > > > > Hi, > > Florence, thanks for your help. > I was able to import correctly ipaCert with your commands. > Now it seems that I also have an issue on one server with > "subsystemCert cert-pki-ca" in /etc/pki/pki-tomcat/alias as I get > below error when pki-tomcat try to start > > > LdapJssSSLSocket set client auth cert nickname subsystemCert cert-pki-ca > Could not connect to LDAP server host sdkipa03.XX.YY port 636 Error > netscape.ldap.LDAPException: IO Error creating JSS SSL Socket ( > -1) > > > Is there a way to restore a correct "subsystemCert cert-pki-ca"? > > Regards > Bertrand > > Hello, > > I am still stuck with my IPA server. > I have issues on both servers. > On server1, below certificate is not renewed properly > certutil -L -d /etc/httpd/alias/ -n "ipaCert" > > and on server 2 this is this certificate: > certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "Server-Cert cert-pki-ca" > > Could you provide me with the correct syntax with start-tracking command. > I tried to laucnh this command but my certificat remains in > "NEWLY_ADDED_NEED_KEYINFO_READ_PIN" state. > Here is the comnd I use: > getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d > /var/lib/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -B > /usr/lib64/ipa/certmonger/stop_pkicad -C > '/usr/lib64/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"' -T > "Server-Cert cert-pki-ca" -P '20160614000000' > Hi Bertrand, to get the right command, you can check on a system where the certificate is properly monitored, this will show you the right parameters: $ sudo getcert list -n ipaCert Number of certificates and requests being tracked: 8. Request ID '20161122095344': [..] key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' [...] CA: dogtag-ipa-ca-renew-agent [...] pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert [...] The relevant fields are NSSDB location, pinfile, nickname, CA, pre and post-save commands. So in order to monitor ipaCert, you will need to use $ sudo getcert start-tracking -d /etc/httpd/alias -n ipaCert \ -p /etc/httpd/alias/pwdfile.txt \ -c dogtag-ipa-ca-renew-agent \ -B /usr/lib64/ipa/certmonger/renew_ra_cert_pre \ -C /usr/lib64/ipa/certmonger/renew_ra_cert HTH, Flo. > Thanks by advance for your help. > > Regards > Bertrand > > > > From stijn.deweirdt at ugent.be Tue Nov 22 10:37:03 2016 From: stijn.deweirdt at ugent.be (Stijn De Weirdt) Date: Tue, 22 Nov 2016 11:37:03 +0100 Subject: [Freeipa-users] group-add-member external "trusted domain object not found" Message-ID: hi all, i'm trying to setup a one-sided trust with an AD, following https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-groups.html the trust is setup and seems to work (i get IPA service token using kvno and an AD kerberos credential), "ipa trustdomain-find domain.name" reports that the domain is enabled (but for some reason dumps this info twice). however, when trying to add the "Domain Users", i get a 'trusted domain object not found' > # ipa group-add-member extgroup --external="NETBIOSNAME\Domain Users" --users=a_valid_ad_user > Group name: extgroup > Description: some desc > Member of groups: intgroup > Failed members: > member user: a_valid_ad_user: no such entry > member group: NETBIOSNAME\Domain Users: trusted domain object not found > ------------------------- > Number of members added 0 > ------------------------- i also tried with "Domain Users at domain.name" any clues how to debug what is going wrong? many thanks, stijn From bretif at phosphore.eu Tue Nov 22 10:50:04 2016 From: bretif at phosphore.eu (Bertrand =?utf-8?Q?R=C3=A9tif?=) Date: Tue, 22 Nov 2016 11:50:04 +0100 (CET) Subject: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue In-Reply-To: References: <1383346498.1295916.1476825748599.JavaMail.zimbra@phosphore.eu> <58077566.8010401@redhat.com> <719022987.1370764.1476884527122.JavaMail.zimbra@phosphore.eu> <1467699597.1398215.1476901090793.JavaMail.zimbra@phosphore.eu> <835252359.90240.1477410669922.JavaMail.zimbra@phosphore.eu> <1898060535.461337.1479805632262.JavaMail.zimbra@phosphore.eu> Message-ID: <1349958374.477173.1479811804586.JavaMail.zimbra@phosphore.eu> > De: "Florence Blanc-Renaud" > ?: "Bertrand R?tif" , freeipa-users at redhat.com > Envoy?: Mardi 22 Novembre 2016 11:33:45 > Objet: Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue > On 11/22/2016 10:07 AM, Bertrand R?tif wrote: > > ------------------------------------------------------------------------ > > > > *De: *"Bertrand R?tif" > > *?: *freeipa-users at redhat.com > > *Envoy?: *Mardi 25 Octobre 2016 17:51:09 > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > pki-tomcat issue > > > > > > ------------------------------------------------------------------------ > > > > *De: *"Florence Blanc-Renaud" > > *?: *"Bertrand R?tif" , > > freeipa-users at redhat.com > > *Envoy?: *Jeudi 20 Octobre 2016 18:45:21 > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > pki-tomcat issue > > > > On 10/19/2016 08:18 PM, Bertrand R?tif wrote: > > > *De: *"Bertrand R?tif" > > > > > > *?: *freeipa-users at redhat.com > > > *Envoy?: *Mercredi 19 Octobre 2016 15:42:07 > > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > > pki-tomcat issue > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > *De: *"Rob Crittenden" > > > *?: *"Bertrand R?tif" , > > > freeipa-users at redhat.com > > > *Envoy?: *Mercredi 19 Octobre 2016 15:30:14 > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > certificate. > > > pki-tomcat issue > > > > > > Bertrand R?tif wrote: > > > >> De: "Martin Babinsky" > > > >> ?: freeipa-users at redhat.com > > > >> Envoy?: Mercredi 19 Octobre 2016 08:45:49 > > > >> Objet: Re: [Freeipa-users] Impossible to renew > > certificate. > > > pki-tomcat issue > > > > > > > >> On 10/18/2016 11:22 PM, Bertrand R?tif wrote: > > > >>> Hello, > > > >>> > > > >>> I had an issue with pki-tomcat. > > > >>> I had serveral certificate that was expired and > > pki-tomcat > > > did not start > > > >>> anymore. > > > >>> > > > >>> I set the dateon the server before certificate > > expiration > > > and then > > > >>> pki-tomcat starts properly. > > > >>> Then I try to resubmit the certificate, but I get > > below error: > > > >>> "Profile caServerCert Not Found" > > > >>> > > > >>> Do you have any idea how I could fix this issue. > > > >>> > > > >>> Please find below output of commands: > > > >>> > > > >>> > > > >>> # getcert resubmit -i 20160108170324 > > > >>> > > > >>> # getcert list -i 20160108170324 > > > >>> Number of certificates and requests being tracked: 7. > > > >>> Request ID '20160108170324': > > > >>> status: MONITORING > > > >>> ca-error: Server at > > > >>> > > "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit" > > > replied: > > > >>> Profile caServerCert Not Found > > > >>> stuck: no > > > >>> key pair storage: > > > >>> > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > >>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > >>> certificate: > > > >>> > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > >>> Certificate DB' > > > >>> CA: dogtag-ipa-ca-renew-agent > > > >>> issuer: CN=Certificate Authority,O=A.SKINFRA.EU > > > >>> subject: CN=IPA RA,O=A.SKINFRA.EU > > > >>> expires: 2016-06-28 15:25:11 UTC > > > >>> key usage: > > > >>> > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > >>> eku: id-kp-serverAuth,id-kp-clientAuth > > > >>> pre-save command: > > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > >>> post-save command: > > /usr/lib64/ipa/certmonger/renew_ra_cert > > > >>> track: yes > > > >>> auto-renew: yes > > > >>> > > > >>> > > > >>> Thanksby advance for your help. > > > >>> Bertrand > > > >>> > > > >>> > > > >>> > > > >>> > > > > > > > >> Hi Betrand, > > > > > > > >> what version of FreeIPA and Dogtag are you running? > > > > > > > >> Also perform the following search on the IPA master > > and post > > > the result: > > > > > > > >> """ > > > >> ldapsearch -D "cn=Directory Manager" -W -b > > > >> 'ou=certificateProfiles,ou=ca,o=ipaca' > > > '(objectClass=certProfile)' > > > >> """ > > > > > > > > Hi Martin, > > > > > > > > Thanks for your reply. > > > > > > > > Here is version: > > > > - FreeIPA 4.2.0 > > > > - Centos 7.2 > > > > > > > > I have been able to fix the issue with "Profile > > caServerCert > > > Not Found" by editing > > /var/lib/pki/pki-tomcat/ca/conf/CS.cfg > > > > I replace below entry > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem" > > > > by > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem" > > > > > > > > and then launch "ipa-server-upgrade" command > > > > I found this solution in this post: > > > http://osdir.com/ml/freeipa-users/2016-03/msg00280.html > > > > > > > > Then I was able to renew my certificate. > > > > > > > > However I reboot my server to and pki-tomcat do not > > start and > > > provide with a new erreor in > > /var/log/pki/pki-tomcat/ca/debug > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > CertUtils: > > > verifySystemCertByNickname() passed: auditSigningCert > > cert-pki-ca > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > SignedAuditEventFactory: create() > > > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$ > > > > System$][Outcome=Success][CertNickName=auditSigningCert > > > cert-pki-ca] CIMC certificate verification > > > > > > > > java.lang.Exception: SystemCertsVerification: system > > certs > > > verification failure > > > > at > > > > > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) > > > > at > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) > > > > at > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) > > > > at > > > > > com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701) > > > > at > > > > > com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148) > > > > at com.netscape.certsrv.apps.CMS.startup(CMS.java:200) > > > > at com.netscape.certsrv.apps.CMS.start(CMS.java:1602) > > > > at > > > > > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) > > > > at > > javax.servlet.GenericServlet.init(GenericServlet.java:158) > > > > at > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > at > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > at > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(Method.java:606) > > > > at > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) > > > > at > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) > > > > at > > java.security.AccessController.doPrivileged(Native Method) > > > > at > > javax.security.auth.Subject.doAsPrivileged(Subject.java:536) > > > > at > > > > > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) > > > > at > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) > > > > at > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) > > > > at > > > > > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) > > > > at > > > > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) > > > > at > > > > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) > > > > at > > > > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) > > > > at > > > > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) > > > > at > > > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > > > > at > > > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > > > at > > > > > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > > > > at > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > > > > at > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > > > > at > > java.security.AccessController.doPrivileged(Native Method) > > > > at > > > > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > > > > at > > > > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > > > > at > > > > > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > > > > at > > > > > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > > > > at > > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > > > > at > > java.util.concurrent.FutureTask.run(FutureTask.java:262) > > > > at > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > > at > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > > at java.lang.Thread.run(Thread.java:745) > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > SignedAuditEventFactory: create() > > > > > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] > > > self tests execution (see selftests.log for details) > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > CMSEngine.shutdown() > > > > > > > > > > > > I am currently stuck here. > > > > Thanks a lot for your help. > > > > > > I'm guessing at least one of the CA subsystem > > certificates are > > > still > > > expired. Look at the "getcert list" output to see if > > there are any > > > expired certificates. > > > > > > rob > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > Hello Rob, > > > > > > I check on my 2 servers and no certificate is expired > > > > > > [root at sdkipa03 ~]# getcert list |grep expire > > > expires: 2018-06-22 22:02:26 UTC > > > expires: 2018-06-22 22:02:47 UTC > > > expires: 2034-07-09 15:24:34 UTC > > > expires: 2016-10-30 13:35:29 UTC > > > > > > [root at sdkipa01 conf]# getcert list |grep expire > > > expires: 2018-06-12 23:38:01 UTC > > > expires: 2018-06-12 23:37:41 UTC > > > expires: 2018-06-11 22:53:57 UTC > > > expires: 2018-06-11 22:55:50 UTC > > > expires: 2018-06-11 22:57:47 UTC > > > expires: 2034-07-09 15:24:34 UTC > > > expires: 2018-06-11 22:59:55 UTC > > > > > > I see that one certificate is in status: CA_UNREACHABLE, > > maybe I > > > reboot to soon my server... > > > > > > I continue to investigate > > > > > > Thanks for your help. > > > Bertrand > > > > > > I fix my previous issue. > > > Now I have an issue with a server. > > > This server can not start pki-tomcatd, I get this error in > > debug file: > > > "Error netscape.ldap.LDAPExceptio n: IO Error creating JSS SSL > > Socket (-1)" > > > > > > After investigation i see that I do not have "ipaCert" > > certificat in > > > "/etc/httpd/alias" > > > cf below command: > > > > > > [root at sdkipa03 ~]# getcert list -d /etc/httpd/alias > > > Number of certificates and requests being tracked: 4. > > > Request ID '20141110133632': > > > status: MONITORING > > > stuck: no > > > 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=A.SKINFRA.EU > > > subject: CN=sdkipa03.skinfra.eu,O=A.SKINFRA.EU > > > expires: 2018-06-22 22:02:47 UTC > > > principal name: HTTP/sdkipa03.skinfra.eu at A.SKINFRA.EU > > > key usage: > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > pre-save command: > > > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > > > track: yes > > > auto-renew: yes > > > > > > > > > How can I add the certificate to /etc/httpd/alias? > > > > > Hi, > > > > for the record, the command getcert list that you supplied shows > > the > > certificates in /etc/httpd/alias that are tracked by certmonger. > > If you > > want to display all the certificates contained in /etc/httpd/alias > > (whether tracked or not), then you may want to use certutil -L -d > > /etc/httpd/alias instead. > > > > If ipaCert is missing, you can export ipaCert certificate from > > another > > master, then import it to your server. > > > > On a master containing the cert: > > # certutil -d /etc/httpd/alias -L -n 'ipaCert' -a > > > /tmp/newRAcert.crt > > > > Then copy the file /tmp/newRAcert.crt to your server and import > > the cert: > > # certutil -d /etc/httpd/alias -A -n 'ipaCert' -a -i > > /tmp/newRAcert.crt > > -t u,u,u > > > > And finally you need to tell certmonger to monitor the cert using > > getcert start-tracking. > > > > Hope this helps, > > Flo. > > > > > Thanks fo ryour support. > > > Regards > > > Bertrand > > > > > > > > > > > > > Hi, > > > > Florence, thanks for your help. > > I was able to import correctly ipaCert with your commands. > > Now it seems that I also have an issue on one server with > > "subsystemCert cert-pki-ca" in /etc/pki/pki-tomcat/alias as I get > > below error when pki-tomcat try to start > > > > > > LdapJssSSLSocket set client auth cert nickname subsystemCert cert-pki-ca > > Could not connect to LDAP server host sdkipa03.XX.YY port 636 Error > > netscape.ldap.LDAPException: IO Error creating JSS SSL Socket ( > > -1) > > > > > > Is there a way to restore a correct "subsystemCert cert-pki-ca"? > > > > Regards > > Bertrand > > > > Hello, > > > > I am still stuck with my IPA server. > > I have issues on both servers. > > On server1, below certificate is not renewed properly > > certutil -L -d /etc/httpd/alias/ -n "ipaCert" > > > > and on server 2 this is this certificate: > > certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "Server-Cert cert-pki-ca" > > > > Could you provide me with the correct syntax with start-tracking command. > > I tried to laucnh this command but my certificat remains in > > "NEWLY_ADDED_NEED_KEYINFO_READ_PIN" state. > > Here is the comnd I use: > > getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d > > /var/lib/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -B > > /usr/lib64/ipa/certmonger/stop_pkicad -C > > '/usr/lib64/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"' -T > > "Server-Cert cert-pki-ca" -P '20160614000000' > > > Hi Bertrand, > to get the right command, you can check on a system where the > certificate is properly monitored, this will show you the right parameters: > $ sudo getcert list -n ipaCert > Number of certificates and requests being tracked: 8. > Request ID '20161122095344': > [..] key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > [...] > CA: dogtag-ipa-ca-renew-agent > [...] > pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > [...] > The relevant fields are NSSDB location, pinfile, nickname, CA, pre and > post-save commands. So in order to monitor ipaCert, you will need to use > $ sudo getcert start-tracking -d /etc/httpd/alias -n ipaCert \ > -p /etc/httpd/alias/pwdfile.txt \ > -c dogtag-ipa-ca-renew-agent \ > -B /usr/lib64/ipa/certmonger/renew_ra_cert_pre \ > -C /usr/lib64/ipa/certmonger/renew_ra_cert > HTH, > Flo. > > Thanks by advance for your help. > > > > Regards > > Bertrand Hello Florence, Thanks for your reply. Before doing any mistakes, I just need some explanations as I think I do not well understand how it should work. Do all the certificate need to be track by certmonger on all servers or they should only be tracked on one server and FreeIPA will update them on other servers? In my case I have below certicates outdated and not track on "server 1": - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "auditSigningCert cert-pki-ca" - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "ocspSigningCert cert-pki-ca" - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "subsystemCert cert-pki-ca" They are tracked by certmonger and have been correctly renewed on "server 2" Do I need to add them tracked by certmonger on "server 1"? If not, it means FreeIPA failed to update them? Should I delete and import them manually on server 2? If you need more details, do not hesitate to ask. Regards Bertrand -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Tue Nov 22 12:17:34 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 22 Nov 2016 13:17:34 +0100 Subject: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue In-Reply-To: <1349958374.477173.1479811804586.JavaMail.zimbra@phosphore.eu> References: <1383346498.1295916.1476825748599.JavaMail.zimbra@phosphore.eu> <58077566.8010401@redhat.com> <719022987.1370764.1476884527122.JavaMail.zimbra@phosphore.eu> <1467699597.1398215.1476901090793.JavaMail.zimbra@phosphore.eu> <835252359.90240.1477410669922.JavaMail.zimbra@phosphore.eu> <1898060535.461337.1479805632262.JavaMail.zimbra@phosphore.eu> <1349958374.477173.1479811804586.JavaMail.zimbra@phosphore.eu> Message-ID: On 11/22/2016 11:50 AM, Bertrand R?tif wrote: > > > *De: *"Florence Blanc-Renaud" > *?: *"Bertrand R?tif" , freeipa-users at redhat.com > *Envoy?: *Mardi 22 Novembre 2016 11:33:45 > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > pki-tomcat issue > > On 11/22/2016 10:07 AM, Bertrand R?tif wrote: > > > ------------------------------------------------------------------------ > > > > *De: *"Bertrand R?tif" > > *?: *freeipa-users at redhat.com > > *Envoy?: *Mardi 25 Octobre 2016 17:51:09 > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > pki-tomcat issue > > > > > > > ------------------------------------------------------------------------ > > > > *De: *"Florence Blanc-Renaud" > > *?: *"Bertrand R?tif" , > > freeipa-users at redhat.com > > *Envoy?: *Jeudi 20 Octobre 2016 18:45:21 > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > pki-tomcat issue > > > > On 10/19/2016 08:18 PM, Bertrand R?tif wrote: > > > *De: *"Bertrand R?tif" > > > > > > *?: *freeipa-users at redhat.com > > > *Envoy?: *Mercredi 19 Octobre 2016 15:42:07 > > > *Objet: *Re: [Freeipa-users] Impossible to renew > certificate. > > > pki-tomcat issue > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > *De: *"Rob Crittenden" > > > *?: *"Bertrand R?tif" , > > > freeipa-users at redhat.com > > > *Envoy?: *Mercredi 19 Octobre 2016 15:30:14 > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > certificate. > > > pki-tomcat issue > > > > > > Bertrand R?tif wrote: > > > >> De: "Martin Babinsky" > > > >> ?: freeipa-users at redhat.com > > > >> Envoy?: Mercredi 19 Octobre 2016 08:45:49 > > > >> Objet: Re: [Freeipa-users] Impossible to renew > > certificate. > > > pki-tomcat issue > > > > > > > >> On 10/18/2016 11:22 PM, Bertrand R?tif wrote: > > > >>> Hello, > > > >>> > > > >>> I had an issue with pki-tomcat. > > > >>> I had serveral certificate that was expired and > > pki-tomcat > > > did not start > > > >>> anymore. > > > >>> > > > >>> I set the dateon the server before certificate > > expiration > > > and then > > > >>> pki-tomcat starts properly. > > > >>> Then I try to resubmit the certificate, but > I get > > below error: > > > >>> "Profile caServerCert Not Found" > > > >>> > > > >>> Do you have any idea how I could fix this issue. > > > >>> > > > >>> Please find below output of commands: > > > >>> > > > >>> > > > >>> # getcert resubmit -i 20160108170324 > > > >>> > > > >>> # getcert list -i 20160108170324 > > > >>> Number of certificates and requests being > tracked: 7. > > > >>> Request ID '20160108170324': > > > >>> status: MONITORING > > > >>> ca-error: Server at > > > >>> > > "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit" > > > replied: > > > >>> Profile caServerCert Not Found > > > >>> stuck: no > > > >>> key pair storage: > > > >>> > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > >>> Certificate > DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > >>> certificate: > > > >>> > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > >>> Certificate DB' > > > >>> CA: dogtag-ipa-ca-renew-agent > > > >>> issuer: CN=Certificate Authority,O=A.SKINFRA.EU > > > >>> subject: CN=IPA RA,O=A.SKINFRA.EU > > > >>> expires: 2016-06-28 15:25:11 UTC > > > >>> key usage: > > > >>> > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > >>> eku: id-kp-serverAuth,id-kp-clientAuth > > > >>> pre-save command: > > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > >>> post-save command: > > /usr/lib64/ipa/certmonger/renew_ra_cert > > > >>> track: yes > > > >>> auto-renew: yes > > > >>> > > > >>> > > > >>> Thanksby advance for your help. > > > >>> Bertrand > > > >>> > > > >>> > > > >>> > > > >>> > > > > > > > >> Hi Betrand, > > > > > > > >> what version of FreeIPA and Dogtag are you > running? > > > > > > > >> Also perform the following search on the IPA > master > > and post > > > the result: > > > > > > > >> """ > > > >> ldapsearch -D "cn=Directory Manager" -W -b > > > >> 'ou=certificateProfiles,ou=ca,o=ipaca' > > > '(objectClass=certProfile)' > > > >> """ > > > > > > > > Hi Martin, > > > > > > > > Thanks for your reply. > > > > > > > > Here is version: > > > > - FreeIPA 4.2.0 > > > > - Centos 7.2 > > > > > > > > I have been able to fix the issue with "Profile > > caServerCert > > > Not Found" by editing > > /var/lib/pki/pki-tomcat/ca/conf/CS.cfg > > > > I replace below entry > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem" > > > > by > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem" > > > > > > > > and then launch "ipa-server-upgrade" command > > > > I found this solution in this post: > > > > http://osdir.com/ml/freeipa-users/2016-03/msg00280.html > > > > > > > > Then I was able to renew my certificate. > > > > > > > > However I reboot my server to and pki-tomcat > do not > > start and > > > provide with a new erreor in > > /var/log/pki/pki-tomcat/ca/debug > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > CertUtils: > > > verifySystemCertByNickname() passed: > auditSigningCert > > cert-pki-ca > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > SignedAuditEventFactory: create() > > > > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$ > > > > > System$][Outcome=Success][CertNickName=auditSigningCert > > > cert-pki-ca] CIMC certificate verification > > > > > > > > java.lang.Exception: SystemCertsVerification: > system > > certs > > > verification failure > > > > at > > > > > > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) > > > > at > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) > > > > at > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) > > > > at > > > > > > com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701) > > > > at > > > > > > com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148) > > > > at > com.netscape.certsrv.apps.CMS.startup(CMS.java:200) > > > > at > com.netscape.certsrv.apps.CMS.start(CMS.java:1602) > > > > at > > > > > > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) > > > > at > > javax.servlet.GenericServlet.init(GenericServlet.java:158) > > > > at > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > at > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > at > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > at > java.lang.reflect.Method.invoke(Method.java:606) > > > > at > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) > > > > at > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) > > > > at > > java.security.AccessController.doPrivileged(Native Method) > > > > at > > javax.security.auth.Subject.doAsPrivileged(Subject.java:536) > > > > at > > > > > > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) > > > > at > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) > > > > at > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) > > > > at > > > > > > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) > > > > at > > > > > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) > > > > at > > > > > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) > > > > at > > > > > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) > > > > at > > > > > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) > > > > at > > > > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > > > > at > > > > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > > > at > > > > > > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > > > > at > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > > > > at > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > > > > at > > java.security.AccessController.doPrivileged(Native Method) > > > > at > > > > > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > > > > at > > > > > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > > > > at > > > > > > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > > > > at > > > > > > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > > > > at > > > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > > > > at > > java.util.concurrent.FutureTask.run(FutureTask.java:262) > > > > at > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > > at > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > > at java.lang.Thread.run(Thread.java:745) > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > SignedAuditEventFactory: create() > > > > > > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] > > > self tests execution (see selftests.log for details) > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > CMSEngine.shutdown() > > > > > > > > > > > > I am currently stuck here. > > > > Thanks a lot for your help. > > > > > > I'm guessing at least one of the CA subsystem > > certificates are > > > still > > > expired. Look at the "getcert list" output to see if > > there are any > > > expired certificates. > > > > > > rob > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > Hello Rob, > > > > > > I check on my 2 servers and no certificate is expired > > > > > > [root at sdkipa03 ~]# getcert list |grep expire > > > expires: 2018-06-22 22:02:26 UTC > > > expires: 2018-06-22 22:02:47 UTC > > > expires: 2034-07-09 15:24:34 UTC > > > expires: 2016-10-30 13:35:29 UTC > > > > > > [root at sdkipa01 conf]# getcert list |grep expire > > > expires: 2018-06-12 23:38:01 UTC > > > expires: 2018-06-12 23:37:41 UTC > > > expires: 2018-06-11 22:53:57 UTC > > > expires: 2018-06-11 22:55:50 UTC > > > expires: 2018-06-11 22:57:47 UTC > > > expires: 2034-07-09 15:24:34 UTC > > > expires: 2018-06-11 22:59:55 UTC > > > > > > I see that one certificate is in status: CA_UNREACHABLE, > > maybe I > > > reboot to soon my server... > > > > > > I continue to investigate > > > > > > Thanks for your help. > > > Bertrand > > > > > > I fix my previous issue. > > > Now I have an issue with a server. > > > This server can not start pki-tomcatd, I get this error in > > debug file: > > > "Error netscape.ldap.LDAPExceptio n: IO Error creating > JSS SSL > > Socket (-1)" > > > > > > After investigation i see that I do not have "ipaCert" > > certificat in > > > "/etc/httpd/alias" > > > cf below command: > > > > > > [root at sdkipa03 ~]# getcert list -d /etc/httpd/alias > > > Number of certificates and requests being tracked: 4. > > > Request ID '20141110133632': > > > status: MONITORING > > > stuck: no > > > 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=A.SKINFRA.EU > > > subject: CN=sdkipa03.skinfra.eu,O=A.SKINFRA.EU > > > expires: 2018-06-22 22:02:47 UTC > > > principal name: HTTP/sdkipa03.skinfra.eu at A.SKINFRA.EU > > > key usage: > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > pre-save command: > > > post-save command: > /usr/lib64/ipa/certmonger/restart_httpd > > > track: yes > > > auto-renew: yes > > > > > > > > > How can I add the certificate to /etc/httpd/alias? > > > > > Hi, > > > > for the record, the command getcert list that you supplied > shows > > the > > certificates in /etc/httpd/alias that are tracked by > certmonger. > > If you > > want to display all the certificates contained in > /etc/httpd/alias > > (whether tracked or not), then you may want to use > certutil -L -d > > /etc/httpd/alias instead. > > > > If ipaCert is missing, you can export ipaCert certificate from > > another > > master, then import it to your server. > > > > On a master containing the cert: > > # certutil -d /etc/httpd/alias -L -n 'ipaCert' -a > > > /tmp/newRAcert.crt > > > > Then copy the file /tmp/newRAcert.crt to your server and > import > > the cert: > > # certutil -d /etc/httpd/alias -A -n 'ipaCert' -a -i > > /tmp/newRAcert.crt > > -t u,u,u > > > > And finally you need to tell certmonger to monitor the > cert using > > getcert start-tracking. > > > > Hope this helps, > > Flo. > > > > > Thanks fo ryour support. > > > Regards > > > Bertrand > > > > > > > > > > > > > Hi, > > > > Florence, thanks for your help. > > I was able to import correctly ipaCert with your commands. > > Now it seems that I also have an issue on one server with > > "subsystemCert cert-pki-ca" in /etc/pki/pki-tomcat/alias as I get > > below error when pki-tomcat try to start > > > > > > LdapJssSSLSocket set client auth cert nickname subsystemCert > cert-pki-ca > > Could not connect to LDAP server host sdkipa03.XX.YY port 636 > Error > > netscape.ldap.LDAPException: IO Error creating JSS SSL Socket ( > > -1) > > > > > > Is there a way to restore a correct "subsystemCert cert-pki-ca"? > > > > Regards > > Bertrand > > > > Hello, > > > > I am still stuck with my IPA server. > > I have issues on both servers. > > On server1, below certificate is not renewed properly > > certutil -L -d /etc/httpd/alias/ -n "ipaCert" > > > > and on server 2 this is this certificate: > > certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "Server-Cert > cert-pki-ca" > > > > Could you provide me with the correct syntax with start-tracking > command. > > I tried to laucnh this command but my certificat remains in > > "NEWLY_ADDED_NEED_KEYINFO_READ_PIN" state. > > Here is the comnd I use: > > getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d > > /var/lib/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -B > > /usr/lib64/ipa/certmonger/stop_pkicad -C > > '/usr/lib64/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"' -T > > "Server-Cert cert-pki-ca" -P '20160614000000' > > > Hi Bertrand, > > to get the right command, you can check on a system where the > certificate is properly monitored, this will show you the right > parameters: > $ sudo getcert list -n ipaCert > Number of certificates and requests being tracked: 8. > Request ID '20161122095344': > [..] key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > [...] > CA: dogtag-ipa-ca-renew-agent > [...] > pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > [...] > > The relevant fields are NSSDB location, pinfile, nickname, CA, pre and > post-save commands. So in order to monitor ipaCert, you will need to use > $ sudo getcert start-tracking -d /etc/httpd/alias -n ipaCert \ > -p /etc/httpd/alias/pwdfile.txt \ > -c dogtag-ipa-ca-renew-agent \ > -B /usr/lib64/ipa/certmonger/renew_ra_cert_pre \ > -C /usr/lib64/ipa/certmonger/renew_ra_cert > > HTH, > Flo. > > > Thanks by advance for your help. > > > > Regards > > Bertrand > > Hello Florence, > > Thanks for your reply. > Before doing any mistakes, I just need some explanations as I think I do > not well understand how it should work. > > Do all the certificate need to be track by certmonger on all servers or > they should only be tracked on one server and FreeIPA will update them > on other servers? > > In my case I have below certicates outdated and not track on "server 1": > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "auditSigningCert > cert-pki-ca" > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "ocspSigningCert > cert-pki-ca" > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "subsystemCert > cert-pki-ca" > > They are tracked by certmonger and have been correctly renewed on "server 2" > Do I need to add them tracked by certmonger on "server 1"? > If not, it means FreeIPA failed to update them? Should I delete and > import them manually on server 2? > > If you need more details, do not hesitate to ask. > Hi Bertrand, The certificate tracking depends on the type of certificate and on the server you're considering. For instance, if IPA includes a Certificate Authority, then ipaCert will be present on all the IPA servers (master/replicas) and tracked on all of them. The same ipaCert certificate is used on all the replicas. On the renewal master, the renewal operation actually renews the certificate and uploads the cert on LDAP, but on the other replicas the operation consists in downloading the new certificate from LDAP. The HTTP and LDAP server certificates are present and tracked on all the IPA servers, but they are different on each server (you can see that the Subject of the certificate contains the hostname). They can be renewed independently on each IPA server. The certificates used by Dogtag (the component providing the Certificate System) are present and tracked only on the IPA servers where the CA was setup (for instance if you installed a replica with --setup-ca or if you ran ipa-ca-install later on). The same certificates are used on all replicas containing a CA instance. They are: 'ocspSigningCert cert-pki-ca', 'subsystemCert cert-pki-ca', 'caSigningCert cert-pki-ca' and 'Server-Cert cert-pki-ca'. The renewal operation renews them on the renewal master and uploads them in LDAP, but just downloads them from LDAP on the other servers. In your example, if server1 also contains a CA instance then it should also track the above certs. You can find the renewal master with the following ldapsearch command: $ ldapsearch -h localhost -p 389 -D 'cn=Directory Manager' -w password -b "cn=masters,cn=ipa,cn=etc,$BASEDN" -LLL '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn dn: cn=CA,cn=ipaserver.fqdn,cn=masters,cn=ipa,cn=etc,$BASEDN In this case the renewal master is ipaserver.fqdn Hope this clarifies, Flo. > Regards > Bertrand > > From tk at mdevsys.com Tue Nov 22 12:57:07 2016 From: tk at mdevsys.com (TomK) Date: Tue, 22 Nov 2016 07:57:07 -0500 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> Message-ID: <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> On 11/22/2016 2:59 AM, Martin Basti wrote: > Hey, > > > On 22.11.2016 06:33, TomK wrote: >> Hey Guy's, >> >> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 over to >> my dual Free IPA server. The Free IPA servers are authoritative for >> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >> and forwards dom.abc.xyz. > Do you have configured proper zone delegation for subdomain dom.abc.xyz? > Proper NS and glue records > http://www.zytrax.com/books/dns/ch9/delegate.html > >> >> I cannot ping dom.abc.xyz. Everything else, including client >> registrations, work fine. If Free IPA is authoritative on >> dom.abc.xyz, should it not create DNS entries so the sub domain can be >> pinged as well? > > What do you mean by "ping"? > >> >> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >> and wanted to ask if you can point me to some materials online to >> determine where can I permanently adjust the search to add dom.abc.xyz >> to the already present abc.xyz . I wasn't able to locate what I >> needed in my searches. >> >> I'm using the latest v4. > > It depends on what are you using, probably you have NetworkManager there > that is editing /etc/resolv.conf > > https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ > > > Martin I Uninstalled NetworkManager. Still changes. ping dom.abc.com results in "ping: unknown host" I'll have a look at the first link, ty. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From pspacek at redhat.com Tue Nov 22 14:45:08 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 22 Nov 2016 15:45:08 +0100 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> Message-ID: <5b73319f-1e00-4369-d912-9c580e734959@redhat.com> On 22.11.2016 13:57, TomK wrote: > On 11/22/2016 2:59 AM, Martin Basti wrote: >> Hey, >> >> >> On 22.11.2016 06:33, TomK wrote: >>> Hey Guy's, >>> >>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 over to >>> my dual Free IPA server. The Free IPA servers are authoritative for >>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>> and forwards dom.abc.xyz. >> Do you have configured proper zone delegation for subdomain dom.abc.xyz? >> Proper NS and glue records >> http://www.zytrax.com/books/dns/ch9/delegate.html >> >>> >>> I cannot ping dom.abc.xyz. Everything else, including client >>> registrations, work fine. If Free IPA is authoritative on >>> dom.abc.xyz, should it not create DNS entries so the sub domain can be >>> pinged as well? >> >> What do you mean by "ping"? >> >>> >>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>> and wanted to ask if you can point me to some materials online to >>> determine where can I permanently adjust the search to add dom.abc.xyz >>> to the already present abc.xyz . I wasn't able to locate what I >>> needed in my searches. >>> >>> I'm using the latest v4. >> >> It depends on what are you using, probably you have NetworkManager there >> that is editing /etc/resolv.conf >> >> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >> >> >> >> Martin > > > I Uninstalled NetworkManager. Still changes. > ping dom.abc.com results in "ping: unknown host" FreeIPA does not put any IP address (A/AAAA) record onto its domain name by default. (The philosophical question would be - what IP address should go there?) If you want to ping something, ping one of your FreeIPA servers. If want to test DNS, use a DNS tool like dig or so to test if names from that domain can be resolved. Petr^2 Spacek > I'll have a look at the first link, ty. From mbasti at redhat.com Tue Nov 22 15:22:59 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 22 Nov 2016 16:22:59 +0100 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> Message-ID: <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> On 22.11.2016 13:57, TomK wrote: > On 11/22/2016 2:59 AM, Martin Basti wrote: >> Hey, >> >> >> On 22.11.2016 06:33, TomK wrote: >>> Hey Guy's, >>> >>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 over to >>> my dual Free IPA server. The Free IPA servers are authoritative for >>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>> and forwards dom.abc.xyz. >> Do you have configured proper zone delegation for subdomain dom.abc.xyz? >> Proper NS and glue records >> http://www.zytrax.com/books/dns/ch9/delegate.html >> >>> >>> I cannot ping dom.abc.xyz. Everything else, including client >>> registrations, work fine. If Free IPA is authoritative on >>> dom.abc.xyz, should it not create DNS entries so the sub domain can be >>> pinged as well? >> >> What do you mean by "ping"? >> >>> >>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>> and wanted to ask if you can point me to some materials online to >>> determine where can I permanently adjust the search to add dom.abc.xyz >>> to the already present abc.xyz . I wasn't able to locate what I >>> needed in my searches. >>> >>> I'm using the latest v4. >> >> It depends on what are you using, probably you have NetworkManager there >> that is editing /etc/resolv.conf >> >> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >> >> >> >> Martin > > > I Uninstalled NetworkManager. Still changes. > ping dom.abc.com results in "ping: unknown host" > > I'll have a look at the first link, ty. > ping (ICMP protocol) and DNS system are different things, do you have hostname dom.abc.com with A record or it is a zone? with ping command hostname "dom.abc.com" is resolved to IP address first, do you have A record set for dom.abc.com in zone apex or what are you trying to achieve with ping command? for testing DNS try to use commands: dig, host, nslookup Martin From dag at sonsorol.org Tue Nov 22 15:37:06 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Tue, 22 Nov 2016 10:37:06 -0500 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? Message-ID: <58346622.1080504@sonsorol.org> Upfront - I know this question is fairly common and I do read the list and archives, honest! - I'm following the SSSD troubleshooting wiki and running with debug settings for PAM and SSH - Still not quite sure where my config problem lies - I see "Server not found in kerberos database" in /var/log/messages so I think I have a simple /etc/krb5.conf error; possibly a very simple root cause like my client can't use DNS to autodiscover a KDC. Not 100% sure how to confirm that Setup: - We run an IPA server at COMPANY-IDM.ORG with the goal of using it as "glue" for multiple Active Directory relationships - Successful trusts made with a number of test AD forest and domains, including SSH logins all working fine - Got the Trust set up to the real COMPANY.ORG forest last night - Trust to COMPANY.ORG went in just fine - We can fetch trusted domains through COMPANY.ORG and see all the children we expect to see (excellent!) Situation: - I can resolve username at NAFTA.COMPANY.ORG on IPA server and bound client - I can "kinit username at NAFTA.COMPANY.ORG" on the IPA server and ipa managed client - From root I can "sudo username at nafta.company.org" on IPA and client server and end up as proper user in proper homedir - I can login via SSH to IPA server and client machines as user at TESTDOMAIN.ORG - ping COMPANY.ORG and NAFTA.COMPANY.ORG resolves to the remote AD servers so I think DNS forwarding is OK BUT -- any sort of "ssh username at nafta.company.org" fails, client sees variations of "permission denied"; nothing super useful so far in security, ssh or sssd logs So basically password checking is broken for the actual COMPANY.ORG trust we set up last night. When I had this issue with our test AD domains I think the answer was that "client could not discover which KDC to contact for password checking" so our response was to customize the krb5.conf file to explicitly enable DNS lookups.. This feels to me like either I've messed up sssd.conf or perhaps more likely I'm missing a config setting in krb5.conf that is specific to password checking for COMPANY.ORG and NAFTA.COMPANY.org We are running in AWS with VPC Flow Logs enabled and there are no obvious REJECT logs showing blockage of traffic to KDC or Domain Controllers Seeking tips and any guidance people can provide! Without burying people in log and config data, here is what I think the relevant info on our side is: /etc/krb5.conf (IPA client) --------------------------------- [libdefaults] default_realm = COMPANY-IDM.ORG dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] COMPANY-IDM.ORG = { kdc = usaeilidmp001.company-idm.org:88 master_kdc = usaeilidmp001.company-idm.org:88 admin_server = usaeilidmp001.company-idm.org:749 default_domain = company-idm.org pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] ipa-client.company-aws.org = COMPANY-IDM.ORG [capaths] COMPANY-AWS.ORG = { COMPANY-IDM.ORG = COMPANY-AWS.ORG } COMPANY-IDM.ORG = { COMPANY-AWS.ORG = COMPANY-AWS.ORG } Here is /etc/sssd/sssd.conf from an IPA client: --------------------------------------------------------- [domain/company-idm.org] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = company-idm.org id_provider = ipa auth_provider = ipa access_provider = ipa ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = client.company-aws.org chpass_provider = ipa ipa_server = _srv_, usaeilidmp001.company-idm.org dns_discovery_domain = company-idm.org [sssd] debug_level = 6 services = nss, sudo, pam, ssh config_file_version = 2 domains = company-idm.org [nss] homedir_substring = /home [pam] debug_level = 10 [sudo] [autofs] [ssh] debug_level = 6 [pac] [ifp] And finally after turning on debug here is some output from sssd_pam.log with debug mode set: ----------- (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [username at NAFTA.COMPANY.ORG] (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is username at NAFTA.COMPANY.ORG (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_initgr_cache_set] (0x2000): [username at nafta.COMPANY.ORG] added to PAM initgroup cache (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: NAFTA.COMPANY.ORG (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): user: username at NAFTA.COMPANY.ORG (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): service: su-l (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: pts/0 (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: root (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 3939 (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: username at nafta.COMPANY.ORG (Tue Nov 22 14:55:07 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f98ae9cd8d0 (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Tue Nov 22 14:55:07 2016) [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f98ac9eb090:3:username at NAFTA.COMPANY.ORG] (Tue Nov 22 14:55:07 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f98ae9cd8d0 (Tue Nov 22 14:55:07 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f98ae9c6ce0 (Tue Nov 22 14:55:07 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][NAFTA.COMPANY.ORG] (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 35 (Tue Nov 22 14:55:07 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f98ae9ccf20][19] (Tue Nov 22 14:55:12 2016) [sssd[pam]] [pam_initgr_cache_remove] (0x2000): [username at nafta.COMPANY.ORG] removed from PAM initgroup cache pam_sshd has this to say: Nov 22 15:01:25 usaeilvdip001 sshd[4041]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=usaeilvdip001.syngentaaws.org user=username at nafta.company.org Nov 22 15:01:25 usaeilvdip001 sshd[4041]: pam_sss(sshd:auth): received for user username at nafta.company.org : 4 (System error) Nov 22 15:01:25 usaeilvdip001 sshd[4041]: Failed password for username at nafta.company.org from 10.127.64.12 port 33812 ssh2 Nov 22 15:01:29 usaeilvdip001 sshd[4041]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=usaeilvdip001.syngentaaws.org user=username at nafta.company.org Nov 22 15:01:29 usaeilvdip001 sshd[4041]: pam_sss(sshd:auth): received for user username at nafta.company.org : 4 (System error) Nov 22 15:01:29 usaeilvdip001 sshd[4041]: Failed password for username at nafta.company.org from 10.127.64.12 port 33812 ssh2 Nov 22 15:01:31 usaeilvdip001 sshd[4041]: Connection closed by 10.127.64.12 [preauth] And this seems pretty clear from /var/log/messages right after I fail with SSH as a NAFTA.COMPANY.ORG user: Nov 22 15:29:43 usaeilvdip001 [sssd[krb5_child[4099]]]: Server not found in Kerberos database Nov 22 15:29:43 usaeilvdip001 [sssd[krb5_child[4099]]]: Server not found in Kerberos database Nov 22 15:29:54 usaeilvdip001 [sssd[krb5_child[4102]]]: Server not found in Kerberos database Nov 22 15:29:54 usaeilvdip001 [sssd[krb5_child[4102]]]: Server not found in Kerberos database I've played with simple edits to /etc/krb5.conf to explicitly set a realm for COMPANY.ORG so I could list kdc entries but it is either not working or I've got a syntax misunderstanding. For instance I've tried to add this to krb5.conf on the client underneath the IPA REALM entry: COMPANY.ORG = { kdc = company.org:88 master_kdc = company.org:88 admin_server = company.org } Any tips / help greatly appreciated Regards, Chris From sbose at redhat.com Tue Nov 22 15:49:30 2016 From: sbose at redhat.com (Sumit Bose) Date: Tue, 22 Nov 2016 16:49:30 +0100 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <58346622.1080504@sonsorol.org> References: <58346622.1080504@sonsorol.org> Message-ID: <20161122154930.GA18779@p.Speedport_W_724V_Typ_A_05011603_00_009> On Tue, Nov 22, 2016 at 10:37:06AM -0500, Chris Dagdigian wrote: > Upfront > - I know this question is fairly common and I do read the list and > archives, honest! > - I'm following the SSSD troubleshooting wiki and running with debug > settings for PAM and SSH > - Still not quite sure where my config problem lies > > - I see "Server not found in kerberos database" in /var/log/messages so I > think I have a simple /etc/krb5.conf error; possibly a very simple root > cause like my client can't use DNS to autodiscover a KDC. Not 100% sure how > to confirm that Please send the full krb5_child.log with debug_level=10 in the [domain/...] section of sssd.conf. My current guess is the ticket validation fails. Which version of SSSD are you using? bye, Sumit > > > Setup: > > - We run an IPA server at COMPANY-IDM.ORG with the goal of using it as > "glue" for multiple Active Directory relationships > - Successful trusts made with a number of test AD forest and domains, > including SSH logins all working fine > - Got the Trust set up to the real COMPANY.ORG forest last night > - Trust to COMPANY.ORG went in just fine > - We can fetch trusted domains through COMPANY.ORG and see all the children > we expect to see (excellent!) > > Situation: > > - I can resolve username at NAFTA.COMPANY.ORG on IPA server and bound client > - I can "kinit username at NAFTA.COMPANY.ORG" on the IPA server and ipa > managed client > - From root I can "sudo username at nafta.company.org" on IPA and client > server and end up as proper user in proper homedir > - I can login via SSH to IPA server and client machines as > user at TESTDOMAIN.ORG > - ping COMPANY.ORG and NAFTA.COMPANY.ORG resolves to the remote AD servers > so I think DNS forwarding is OK > > BUT -- any sort of "ssh username at nafta.company.org" fails, client sees > variations of "permission denied"; nothing super useful so far in security, > ssh or sssd logs > > So basically password checking is broken for the actual COMPANY.ORG trust we > set up last night. > > When I had this issue with our test AD domains I think the answer was that > "client could not discover which KDC to contact for password checking" so > our response was to customize the krb5.conf file to explicitly enable DNS > lookups.. > > This feels to me like either I've messed up sssd.conf or perhaps more likely > I'm missing a config setting in krb5.conf that is specific to password > checking for COMPANY.ORG and NAFTA.COMPANY.org > > > We are running in AWS with VPC Flow Logs enabled and there are no obvious > REJECT logs showing blockage of traffic to KDC or Domain Controllers > > > Seeking tips and any guidance people can provide! > > Without burying people in log and config data, here is what I think the > relevant info on our side is: > > /etc/krb5.conf (IPA client) > --------------------------------- > > [libdefaults] > > default_realm = COMPANY-IDM.ORG > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > udp_preference_limit = 0 > default_ccache_name = KEYRING:persistent:%{uid} > > [realms] > > COMPANY-IDM.ORG = { > kdc = usaeilidmp001.company-idm.org:88 > master_kdc = usaeilidmp001.company-idm.org:88 > admin_server = usaeilidmp001.company-idm.org:749 > default_domain = company-idm.org > pkinit_anchors = FILE:/etc/ipa/ca.crt > > } > > [domain_realm] > > ipa-client.company-aws.org = COMPANY-IDM.ORG > > [capaths] > > COMPANY-AWS.ORG = { > > COMPANY-IDM.ORG = COMPANY-AWS.ORG > > } > > COMPANY-IDM.ORG = { > > COMPANY-AWS.ORG = COMPANY-AWS.ORG > > } > > > > Here is /etc/sssd/sssd.conf from an IPA client: > --------------------------------------------------------- > > [domain/company-idm.org] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = company-idm.org > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ldap_tls_cacert = /etc/ipa/ca.crt > ipa_hostname = client.company-aws.org > chpass_provider = ipa > ipa_server = _srv_, usaeilidmp001.company-idm.org > dns_discovery_domain = company-idm.org > > [sssd] > > debug_level = 6 > services = nss, sudo, pam, ssh > config_file_version = 2 > > domains = company-idm.org > > [nss] > > homedir_substring = /home > > [pam] > > debug_level = 10 > > [sudo] > > [autofs] > > [ssh] > > debug_level = 6 > > [pac] > > [ifp] > > > > And finally after turning on debug here is some output from sssd_pam.log > with debug mode set: > ----------- > > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_check_user_search] (0x0400): > Returning info for user [username at NAFTA.COMPANY.ORG] > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pd_set_primary_name] (0x0400): > User's primary name is username at NAFTA.COMPANY.ORG (Tue Nov 22 14:55:07 2016) > [sssd[pam]] [pam_initgr_cache_set] (0x2000): [username at nafta.COMPANY.ORG] > added to PAM initgroup cache > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): command: > PAM_OPEN_SESSION > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: > NAFTA.COMPANY.ORG (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] > (0x0100): user: username at NAFTA.COMPANY.ORG (Tue Nov 22 14:55:07 2016) > [sssd[pam]] [pam_print_data] (0x0100): service: su-l > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: pts/0 > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: > root > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: not > set > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok > type: 0 > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 3939 > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): logon > name: username at nafta.COMPANY.ORG > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): > 0x7f98ae9cd8d0 > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [sss_dp_req_destructor] (0x0400): > Deleting request: [0x7f98ac9eb090:3:username at NAFTA.COMPANY.ORG] > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): > 0x7f98ae9cd8d0 > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: > 0x7f98ae9c6ce0 > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [sbus_dispatch] (0x4000): > Dispatching. > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): > received: [0 (Success)][NAFTA.COMPANY.ORG] > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply > called with result [0]: Success. > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 35 > (Tue Nov 22 14:55:07 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x7f98ae9ccf20][19] > (Tue Nov 22 14:55:12 2016) [sssd[pam]] [pam_initgr_cache_remove] (0x2000): > [username at nafta.COMPANY.ORG] removed from PAM initgroup cache > > > pam_sshd has this to say: > > Nov 22 15:01:25 usaeilvdip001 sshd[4041]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=usaeilvdip001.syngentaaws.org user=username at nafta.company.org > > Nov 22 15:01:25 usaeilvdip001 sshd[4041]: pam_sss(sshd:auth): received for > user username at nafta.company.org : 4 > (System error) > Nov 22 15:01:25 usaeilvdip001 sshd[4041]: Failed password for > username at nafta.company.org from > 10.127.64.12 port 33812 ssh2 > Nov 22 15:01:29 usaeilvdip001 sshd[4041]: pam_sss(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=usaeilvdip001.syngentaaws.org user=username at nafta.company.org > > Nov 22 15:01:29 usaeilvdip001 sshd[4041]: pam_sss(sshd:auth): received for > user username at nafta.company.org : 4 > (System error) > Nov 22 15:01:29 usaeilvdip001 sshd[4041]: Failed password for > username at nafta.company.org from > 10.127.64.12 port 33812 ssh2 > Nov 22 15:01:31 usaeilvdip001 sshd[4041]: Connection closed by 10.127.64.12 > [preauth] > > > > And this seems pretty clear from /var/log/messages right after I fail with > SSH as a NAFTA.COMPANY.ORG user: > > Nov 22 15:29:43 usaeilvdip001 [sssd[krb5_child[4099]]]: Server not found in > Kerberos database > Nov 22 15:29:43 usaeilvdip001 [sssd[krb5_child[4099]]]: Server not found in > Kerberos database > Nov 22 15:29:54 usaeilvdip001 [sssd[krb5_child[4102]]]: Server not found in > Kerberos database > Nov 22 15:29:54 usaeilvdip001 [sssd[krb5_child[4102]]]: Server not found in > Kerberos database > > > I've played with simple edits to /etc/krb5.conf to explicitly set a realm > for COMPANY.ORG so I could list kdc entries but it is either not working or > I've got a syntax misunderstanding. > > For instance I've tried to add this to krb5.conf on the client underneath > the IPA REALM entry: > > COMPANY.ORG = { > > kdc = company.org:88 > > master_kdc = company.org:88 > > admin_server = company.org > > } > > > Any tips / help greatly appreciated > > > Regards, > Chris > > > > > > > > -- > 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 dag at sonsorol.org Tue Nov 22 15:50:44 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Tue, 22 Nov 2016 10:50:44 -0500 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <58346622.1080504@sonsorol.org> References: <58346622.1080504@sonsorol.org> Message-ID: <58346954.7070608@sonsorol.org> Following up my own email after realizing my sssd debug info was better when I ran it via "# sssd -i -d 5" ... Here are the relevant entries from sssd during a failed login attempt via SSH using AD credentials from username at nafta.company.com -Chris (Tue Nov 22 15:43:27 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received client version [0]. (Tue Nov 22 15:43:27 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered version [0]. (Tue Nov 22 15:43:27 2016) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 't859531 at NAFTA.COMPANY.ORG ' matched expression for domain 'NAFTA.COMPANY.ORG', user is t859531 (Tue Nov 22 15:43:27 2016) [sssd[be[company-idm.org]]] [be_get_account_info] (0x0200): Got request for [0x1][1][name=t859531] (Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] (Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] [sysdb_update_members_ex] (0x0020): Could not add member [t859531 at NAFTA.COMPANY.ORG ] to group [name=t859531 at NAFTA.COMPANY.ORG ,cn=groups,cn=NAFTA.COMPANY.ORG,cn=sysdb]. Skipping. (Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] (Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] [sysdb_update_members_ex] (0x0020): Could not add member [t859531 at NAFTA.COMPANY.ORG ] to group [name=t859531 at NAFTA.COMPANY.ORG ,cn=groups,cn=NAFTA.COMPANY.ORG,cn=sysdb]. Skipping. (Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) (Tue Nov 22 15:43:28 2016) [sssd[ssh]] [client_recv] (0x0200): Client disconnected! (Tue Nov 22 15:43:28 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Received client version [0]. (Tue Nov 22 15:43:28 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered version [0]. (Tue Nov 22 15:43:28 2016) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200): name 't859531 at NAFTA.COMPANY.ORG ' matched expression for domain 'NAFTA.COMPANY.ORG', user is t859531 (Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] [be_get_account_info] (0x0200): Got request for [0x1][1][name=t859531] (Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] (Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] [sysdb_update_members_ex] (0x0020): Could not add member [t859531 at NAFTA.COMPANY.ORG ] to group [name=t859531 at NAFTA.COMPANY.ORG ,cn=groups,cn=NAFTA.COMPANY.ORG,cn=sysdb]. Skipping. (Tue Nov 22 15:43:29 2016) [sssd[be[company-idm.org]]] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] (Tue Nov 22 15:43:29 2016) [sssd[be[company-idm.org]]] [sysdb_update_members_ex] (0x0020): Could not add member [t859531 at NAFTA.COMPANY.ORG ] to group [name=t859531 at NAFTA.COMPANY.ORG ,cn=groups,cn=NAFTA.COMPANY.ORG,cn=sysdb]. Skipping. (Tue Nov 22 15:43:29 2016) [sssd[be[company-idm.org]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) (Tue Nov 22 15:43:29 2016) [sssd[ssh]] [client_recv] (0x0200): Client disconnected! (Tue Nov 22 15:43:32 2016) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3]. (Tue Nov 22 15:43:32 2016) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3]. (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_cmd_preauth] (0x0100): entering pam_cmd_preauth (Tue Nov 22 15:43:32 2016) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 't859531 at NAFTA.COMPANY.ORG ' matched expression for domain 'NAFTA.COMPANY.ORG', user is t859531 (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_PREAUTH (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: NAFTA.COMPANY.ORG (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): user: t859531 (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: usrelnu4239n3y2.NAFTA.COMPANY.ORG (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 4180 (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: t859531 at NAFTA.COMPANY.ORG (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [be_get_account_info] (0x0200): Got request for [0x3][1][name=t859531] (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [sysdb_update_members_ex] (0x0020): Could not add member [t859531 at NAFTA.COMPANY.ORG ] to group [name=t859531 at NAFTA.COMPANY.ORG ,cn=groups,cn=NAFTA.COMPANY.ORG,cn=sysdb]. Skipping. (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such object](32)[ldb_wait: No such object (32)] (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [sysdb_update_members_ex] (0x0020): Could not add member [t859531 at NAFTA.COMPANY.ORG ] to group [name=t859531 at NAFTA.COMPANY.ORG ,cn=groups,cn=NAFTA.COMPANY.ORG,cn=sysdb]. Skipping. (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [t859531 at NAFTA.COMPANY.ORG ] (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_PREAUTH (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: NAFTA.COMPANY.ORG (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): user: t859531 at NAFTA.COMPANY.ORG (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: usrelnu4239n3y2.NAFTA.COMPANY.ORG (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 4180 (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: t859531 at NAFTA.COMPANY.ORG (Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [be_pam_handler] (0x0100): Got request with the following data (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): command: SSS_PAM_PREAUTH (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): domain: NAFTA.COMPANY.ORG (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): user: t859531 at NAFTA.COMPANY.ORG (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): service: sshd (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): tty: ssh (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): ruser: (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): rhost: usrelnu4239n3y2.NAFTA.COMPANY.ORG (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): authtok type: 0 (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): priv: 1 (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): cli_pid: 4180 (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [pam_print_data] (0x0100): logon name: not set (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Tue Nov 22 15:43:32 2016) [sssd[be[company-idm.org]]] [be_resolve_server_process] (0x0200): Found address for server usaeilidmp001.company-idm.org: [10.127.64.11] TTL 1162 (Tue Nov 22 15:43:32 2016) [[sssd[krb5_child[4184]]]] [unpack_buffer] (0x0100): cmd [249] uid [1843770609] gid [1843770609] validate [true] enterprise principal [false] offline [false] UPN [t859531 at SYNGENTA.ORG ] (Tue Nov 22 15:43:32 2016) [[sssd[krb5_child[4184]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/usaeilvdip001.syngentaaws.org at company-idm.org ] (Tue Nov 22 15:43:32 2016) [[sssd[krb5_child[4184]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Nov 22 15:43:32 2016) [sssd[pac]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Tue Nov 22 15:43:32 2016) [sssd[pac]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Tue Nov 22 15:43:32 2016) [[sssd[krb5_child[4184]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Nov 22 15:43:32 2016) [[sssd[krb5_child[4184]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Nov 22 15:43:32 2016) [[sssd[krb5_child[4184]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Nov 22 15:43:32 2016) [[sssd[krb5_child[4184]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Nov 22 15:43:33 2016) [[sssd[krb5_child[4184]]]] [sss_krb5_prompter] (0x0020): Cannot handle password prompts. (Tue Nov 22 15:43:33 2016) [[sssd[krb5_child[4184]]]] [k5c_send_data] (0x0200): Received error code 0 (Tue Nov 22 15:43:33 2016) [sssd[pac]] [client_recv] (0x0200): Client disconnected! (Tue Nov 22 15:43:33 2016) [sssd[be[company-idm.org]]] [child_sig_handler] (0x0100): child [4184] finished successfully. (Tue Nov 22 15:43:33 2016) [sssd[be[company-idm.org]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'usaeilidmp001.company-idm.org' as 'working' (Tue Nov 22 15:43:33 2016) [sssd[be[company-idm.org]]] [set_server_common_status] (0x0100): Marking server 'usaeilidmp001.company-idm.org' as 'working' (Tue Nov 22 15:43:33 2016) [sssd[be[company-idm.org]]] [krb5_auth_store_creds] (0x0010): unsupported PAM command [249]. (Tue Nov 22 15:43:33 2016) [sssd[be[company-idm.org]]] [krb5_auth_store_creds] (0x0010): password not available, offline auth may not work. (Tue Nov 22 15:43:33 2016) [sssd[be[company-idm.org]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success (Success)] (Tue Nov 22 15:43:33 2016) [sssd[be[company-idm.org]]] [be_pam_handler_callback] (0x0100): Sending result [0][NAFTA.COMPANY.ORG] (Tue Nov 22 15:43:33 2016) [sssd[be[company-idm.org]]] [be_pam_handler_callback] (0x0100): Sent result [0][NAFTA.COMPANY.ORG] (Tue Nov 22 15:43:33 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [0 (Success)][NAFTA.COMPANY.ORG] (Tue Nov 22 15:43:33 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]: Success. (Tue Nov 22 15:43:33 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 35 From dag at sonsorol.org Tue Nov 22 16:17:37 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Tue, 22 Nov 2016 11:17:37 -0500 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <20161122154930.GA18779@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <58346622.1080504@sonsorol.org> <20161122154930.GA18779@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <58346FA1.3050409@sonsorol.org> Sumit Bose wrote: > Please send the full krb5_child.log with debug_level=10 in the > [domain/...] section of sssd.conf. My current guess is the ticket > validation fails. Which version of SSSD are you using? > > bye, > Sumit This is a CentOS 7 client running SSSD-1.13 Thank you. Lots of interesting info in this log. I've sanitized hostnames, username and IP but that was it: ### log data below #### (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [main] (0x0400): krb5_child started. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [unpack_buffer] (0x1000): total buffer size: [52] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [unpack_buffer] (0x0100): cmd [249] uid [1843770609] gid [1843770609] validate [true] enterprise principal [false] offline [false] UPN [username at COMPANY.ORG] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/usaeilvdip001.company-aws.org at company-idm.org] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/usaeilvdip001.company-aws.org at company-idm.org in keytab. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [match_principal] (0x1000): Principal matched to the sample (host/usaeilvdip001.company-aws.org at company-idm.org). (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [main] (0x2000): Running as [1843770609][1843770609]. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [k5c_setup] (0x2000): Running as [1843770609][1843770609]. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [main] (0x0400): Will perform pre-auth (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [COMPANY.ORG] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.455849: Getting initial credentials for username at COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.455913: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.455943: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/COMPANY.ORG\@COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.455988: Sending request (169 bytes) to COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.456104: Resolving hostname COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.457461: Initiating TCP connection to stream 192.141.1.62:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.544892: Sending TCP request to stream 192.141.1.62:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.632904: Received answer (118 bytes) from stream 192.141.1.62:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.632941: Terminating TCP connection to stream 192.141.1.62:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.633006: Response was from master KDC (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.633037: Received error from KDC: -1765328316/Realm not local to KDC (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.633070: Following referral to realm NAFTA.COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.633087: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.633137: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/NAFTA.COMPANY.ORG\@NAFTA.COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.633176: Sending request (181 bytes) to NAFTA.COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.638652: Resolving hostname usetwadsfsmo04.nafta.COMPANY.ORG. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.639637: Sending initial UDP request to dgram 192.189.131.31:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.657192: Received answer (205 bytes) from dgram 192.189.131.31:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.657943: Response was not from master KDC (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.657987: Received error from KDC: -1765328359/Additional pre-authentication required (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.658021: Processing preauth types: 16, 15, 19, 2 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.658041: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGusername", params "" (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_krb5_prompter] (0x0020): Cannot handle password prompts. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.658071: Preauth module encrypted_timestamp (2) (real) returned: -1765328254/Cannot read password (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.658090: Retrying AS request with master KDC (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.658098: Getting initial credentials for username at COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.658117: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.658141: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/COMPANY.ORG\@COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.658164: Sending request (169 bytes) to COMPANY.ORG (master) (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.658181: Resolving hostname COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.659023: Initiating TCP connection to stream 192.189.131.10:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.675608: Sending TCP request to stream 192.189.131.10:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.692668: Received answer (118 bytes) from stream 192.189.131.10:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.692717: Terminating TCP connection to stream 192.189.131.10:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.692773: Received error from KDC: -1765328316/Realm not local to KDC (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.692789: Following referral to realm NAFTA.COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.692806: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.692842: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/NAFTA.COMPANY.ORG\@NAFTA.COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.692878: Sending request (181 bytes) to NAFTA.COMPANY.ORG (master) (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328254} during pre-auth. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [k5c_send_data] (0x0200): Received error code 0 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [pack_response_packet] (0x2000): response packet size: [4] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [k5c_send_data] (0x4000): Response sent. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366]]]] [main] (0x0400): krb5_child completed successfully (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [main] (0x0400): krb5_child started. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [unpack_buffer] (0x1000): total buffer size: [158] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [unpack_buffer] (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [true] enterprise principal [false] offline [false] UPN [username at COMPANY.ORG] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1843770609] old_ccname: [KEYRING:persistent:1843770609] keytab: [/etc/krb5.keytab] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [switch_creds] (0x0200): Switch user to [1843770609][1843770609]. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1843770609] and is not active and TGT is valid. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/usaeilvdip001.company-aws.org at company-idm.org] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/usaeilvdip001.company-aws.org at company-idm.org in keytab. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [match_principal] (0x1000): Principal matched to the sample (host/usaeilvdip001.company-aws.org at company-idm.org). (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [main] (0x2000): Running as [1843770609][1843770609]. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [k5c_setup] (0x2000): Running as [1843770609][1843770609]. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [main] (0x0400): Will perform online auth (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [COMPANY.ORG] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.708701: Getting initial credentials for username at COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.708766: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.708797: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/COMPANY.ORG\@COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.708845: Sending request (169 bytes) to COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.708968: Resolving hostname COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.710135: Initiating TCP connection to stream 192.141.1.63:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.796151: Sending TCP request to stream 192.141.1.63:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.882766: Received answer (118 bytes) from stream 192.141.1.63:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.882802: Terminating TCP connection to stream 192.141.1.63:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.882886: Response was from master KDC (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.882924: Received error from KDC: -1765328316/Realm not local to KDC (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.882941: Following referral to realm NAFTA.COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.882956: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.882984: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/NAFTA.COMPANY.ORG\@NAFTA.COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.883019: Sending request (181 bytes) to NAFTA.COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.888739: Resolving hostname usetwadsgc06.nafta.COMPANY.ORG. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.889684: Sending initial UDP request to dgram 192.189.132.21:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.911271: Received answer (205 bytes) from dgram 192.189.132.21:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.912054: Response was not from master KDC (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.912092: Received error from KDC: -1765328359/Additional pre-authentication required (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.912126: Processing preauth types: 16, 15, 19, 2 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.912145: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGusername", params "" (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.920736: AS key obtained for encrypted timestamp: aes256-cts/3D3B (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.920813: Encrypted timestamp (for 1479830563.304057): plain 301AA011180F32303136313132323136303234335AA105020304A3B9, encrypted D2B644646EA65470D011BB1C63145BAB3DB096C644CC47DD7D23A2C4E51C4F42357493825530FFF5E852DEE96D794CD33492279CB85A8E8D (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.920835: Preauth module encrypted_timestamp (2) (real) returned: 0/Success (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.920843: Produced preauth for next request: 2 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.920879: Sending request (260 bytes) to NAFTA.COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.926274: Resolving hostname usetwadsgc06.nafta.COMPANY.ORG. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.927107: Sending initial UDP request to dgram 192.189.132.21:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.946258: Received answer (108 bytes) from dgram 192.189.132.21:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.947022: Response was not from master KDC (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.947057: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.947068: Request or response is too big for UDP; retrying with TCP (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.947078: Sending request (260 bytes) to NAFTA.COMPANY.ORG (tcp only) (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.949638: Resolving hostname usetwadsfsmo03.nafta.COMPANY.ORG. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.950847: Initiating TCP connection to stream 192.189.131.30:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.967068: Sending TCP request to stream 192.189.131.30:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.985509: Received answer (2127 bytes) from stream 192.189.131.30:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.985549: Terminating TCP connection to stream 192.189.131.30:88 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986327: Response was not from master KDC (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986373: Processing preauth types: 19 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986395: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGusername", params "" (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986405: Produced preauth for next request: (empty) (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986416: AS key determined by preauth: aes256-cts/3D3B (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986487: Decrypted AS reply; session key is: aes256-cts/6F15 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986501: FAST negotiation: unavailable (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_krb5_expire_callback_func] (0x2000): exp_time: [3966065] (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [validate_tgt] (0x2000): Keytab entry with the realm of the credential not found in keytab. Using the last entry. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986574: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org from MEMORY:/etc/krb5.keytab (vno 0, enctype 0) with result: 0/Success (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986582: Resolving unique ccache of type MEMORY (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986596: Initializing MEMORY:yWXP1Fr with default princ username at NAFTA.COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986605: Storing username at NAFTA.COMPANY.ORG -> krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG in MEMORY:yWXP1Fr (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986624: Getting credentials username at NAFTA.COMPANY.ORG -> host/usaeilvdip001.company-aws.org at company-idm.org using ccache MEMORY:yWXP1Fr (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986650: Retrieving username at NAFTA.COMPANY.ORG -> host/usaeilvdip001.company-aws.org at company-idm.org from MEMORY:yWXP1Fr with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986665: Retrieving username at NAFTA.COMPANY.ORG -> krbtgt/company-idm.org at company-idm.org from MEMORY:yWXP1Fr with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986679: Retrieving username at NAFTA.COMPANY.ORG -> krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG from MEMORY:yWXP1Fr with result: 0/Success (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986687: Starting with TGT for client realm: username at NAFTA.COMPANY.ORG -> krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986702: Retrieving username at NAFTA.COMPANY.ORG -> krbtgt/company-idm.org at company-idm.org from MEMORY:yWXP1Fr with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986711: Requesting TGT krbtgt/company-idm.org at NAFTA.COMPANY.ORG using TGT krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986728: Generated subkey for TGS request: aes256-cts/52B3 (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986768: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986829: Encoding request body and padata into FAST request (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.986884: Sending request (2297 bytes) to NAFTA.COMPANY.ORG (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.992252: Resolving hostname usetwadsfsmo04.nafta.COMPANY.ORG. (Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830563.993077: Sending initial UDP request to dgram 192.189.131.31:88 (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830564.10283: Received answer (105 bytes) from dgram 192.189.131.31:88 (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830564.11260: Response was not from master KDC (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830564.11300: TGS request result: -1765328377/Server not found in Kerberos database (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [sss_child_krb5_trace_cb] (0x4000): [4367] 1479830564.11322: Destroying ccache MEMORY:yWXP1Fr (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [validate_tgt] (0x0020): TGT failed verification using key for [host/usaeilvdip001.company-aws.org at company-idm.org]. (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [get_and_save_tgt] (0x0020): 1242: [-1765328377][Server not found in Kerberos database] (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [map_krb5_error] (0x0020): 1303: [-1765328377][Server not found in Kerberos database] (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [pack_response_packet] (0x2000): response packet size: [20] (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [k5c_send_data] (0x4000): Response sent. (Tue Nov 22 16:02:44 2016) [[sssd[krb5_child[4367]]]] [main] (0x0400): krb5_child completed successfully (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [main] (0x0400): krb5_child started. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [unpack_buffer] (0x1000): total buffer size: [52] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [unpack_buffer] (0x0100): cmd [249] uid [1843770609] gid [1843770609] validate [true] enterprise principal [false] offline [false] UPN [username at COMPANY.ORG] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/usaeilvdip001.company-aws.org at company-idm.org] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/usaeilvdip001.company-aws.org at company-idm.org in keytab. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [match_principal] (0x1000): Principal matched to the sample (host/usaeilvdip001.company-aws.org at company-idm.org). (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [main] (0x2000): Running as [1843770609][1843770609]. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [k5c_setup] (0x2000): Running as [1843770609][1843770609]. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [main] (0x0400): Will perform pre-auth (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [COMPANY.ORG] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.646744: Getting initial credentials for username at COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.646810: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.646840: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/COMPANY.ORG\@COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.646884: Sending request (169 bytes) to COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.647003: Resolving hostname COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.648291: Initiating TCP connection to stream 192.141.1.10:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.734271: Sending TCP request to stream 192.141.1.10:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.820703: Received answer (118 bytes) from stream 192.141.1.10:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.820748: Terminating TCP connection to stream 192.141.1.10:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.820812: Response was from master KDC (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.820843: Received error from KDC: -1765328316/Realm not local to KDC (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.820866: Following referral to realm NAFTA.COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.820888: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.820931: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/NAFTA.COMPANY.ORG\@NAFTA.COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.820969: Sending request (181 bytes) to NAFTA.COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.827033: Resolving hostname usetwadsgc06.nafta.COMPANY.ORG. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.827943: Sending initial UDP request to dgram 192.189.132.21:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.847365: Received answer (205 bytes) from dgram 192.189.132.21:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848133: Response was not from master KDC (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848172: Received error from KDC: -1765328359/Additional pre-authentication required (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848215: Processing preauth types: 16, 15, 19, 2 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848235: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGusername", params "" (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_krb5_prompter] (0x0020): Cannot handle password prompts. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848264: Preauth module encrypted_timestamp (2) (real) returned: -1765328254/Cannot read password (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848283: Retrying AS request with master KDC (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848291: Getting initial credentials for username at COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848309: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848331: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/COMPANY.ORG\@COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848355: Sending request (169 bytes) to COMPANY.ORG (master) (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.848371: Resolving hostname COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.849169: Initiating TCP connection to stream 192.189.131.28:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.866111: Sending TCP request to stream 192.189.131.28:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.883592: Received answer (118 bytes) from stream 192.189.131.28:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.883625: Terminating TCP connection to stream 192.189.131.28:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.883676: Received error from KDC: -1765328316/Realm not local to KDC (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.883692: Following referral to realm NAFTA.COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.883709: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.883744: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/NAFTA.COMPANY.ORG\@NAFTA.COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [sss_child_krb5_trace_cb] (0x4000): [4368] 1479830567.883778: Sending request (181 bytes) to NAFTA.COMPANY.ORG (master) (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328254} during pre-auth. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [k5c_send_data] (0x0200): Received error code 0 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [pack_response_packet] (0x2000): response packet size: [4] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [k5c_send_data] (0x4000): Response sent. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4368]]]] [main] (0x0400): krb5_child completed successfully (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [main] (0x0400): krb5_child started. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [unpack_buffer] (0x1000): total buffer size: [158] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [unpack_buffer] (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [true] enterprise principal [false] offline [false] UPN [username at COMPANY.ORG] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1843770609] old_ccname: [KEYRING:persistent:1843770609] keytab: [/etc/krb5.keytab] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [switch_creds] (0x0200): Switch user to [1843770609][1843770609]. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1843770609] and is not active and TGT is valid. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/usaeilvdip001.company-aws.org at company-idm.org] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/usaeilvdip001.company-aws.org at company-idm.org in keytab. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [match_principal] (0x1000): Principal matched to the sample (host/usaeilvdip001.company-aws.org at company-idm.org). (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [main] (0x2000): Running as [1843770609][1843770609]. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [k5c_setup] (0x2000): Running as [1843770609][1843770609]. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [main] (0x0400): Will perform online auth (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [COMPANY.ORG] (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899271: Getting initial credentials for username at COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899337: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899368: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/COMPANY.ORG\@COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899415: Sending request (169 bytes) to COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899575: Resolving hostname COMPANY.ORG (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.900935: Initiating TCP connection to stream 192.141.1.15:88 (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.987925: Sending TCP request to stream 192.141.1.15:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75357: Received answer (118 bytes) from stream 192.141.1.15:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75404: Terminating TCP connection to stream 192.141.1.15:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75502: Response was from master KDC (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75529: Received error from KDC: -1765328316/Realm not local to KDC (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75544: Following referral to realm NAFTA.COMPANY.ORG (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75559: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75586: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/NAFTA.COMPANY.ORG\@NAFTA.COMPANY.ORG at X-CACHECONF: from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75621: Sending request (181 bytes) to NAFTA.COMPANY.ORG (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.81119: Resolving hostname usetwadsfsmo03.nafta.COMPANY.ORG. (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.81947: Sending initial UDP request to dgram 192.189.131.30:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.99200: Received answer (205 bytes) from dgram 192.189.131.30:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.100064: Response was not from master KDC (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.100103: Received error from KDC: -1765328359/Additional pre-authentication required (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.100136: Processing preauth types: 16, 15, 19, 2 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.100155: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGusername", params "" (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.108691: AS key obtained for encrypted timestamp: aes256-cts/3D3B (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.108766: Encrypted timestamp (for 1479830568.478875): plain 301AA011180F32303136313132323136303234385AA1050203074E9B, encrypted 133359586FCB362BF70E6CC90D509C68D6B19903CE0113AD37826E22256090F77B2B7F0BE410C1D7E72F890C437A77FE4BE1DA21848F6209 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.108787: Preauth module encrypted_timestamp (2) (real) returned: 0/Success (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.108794: Produced preauth for next request: 2 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.108829: Sending request (260 bytes) to NAFTA.COMPANY.ORG (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.114751: Resolving hostname usetwadsfsmo03.nafta.COMPANY.ORG. (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.115601: Sending initial UDP request to dgram 192.189.131.30:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.133353: Received answer (108 bytes) from dgram 192.189.131.30:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.134326: Response was not from master KDC (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.134360: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.134370: Request or response is too big for UDP; retrying with TCP (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.134379: Sending request (260 bytes) to NAFTA.COMPANY.ORG (tcp only) (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.137246: Resolving hostname friawadsgc12.nafta.COMPANY.ORG. (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.138084: Initiating TCP connection to stream 192.141.1.52:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.224054: Sending TCP request to stream 192.141.1.52:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.311440: Received answer (2178 bytes) from stream 192.141.1.52:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.311483: Terminating TCP connection to stream 192.141.1.52:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312325: Response was not from master KDC (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312369: Processing preauth types: 19 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312381: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGusername", params "" (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312390: Produced preauth for next request: (empty) (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312401: AS key determined by preauth: aes256-cts/3D3B (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312459: Decrypted AS reply; session key is: aes256-cts/43A1 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312498: FAST negotiation: unavailable (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_krb5_expire_callback_func] (0x2000): exp_time: [3966060] (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [validate_tgt] (0x2000): Keytab entry with the realm of the credential not found in keytab. Using the last entry. (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312579: Retrieving host/usaeilvdip001.company-aws.org at company-idm.org from MEMORY:/etc/krb5.keytab (vno 0, enctype 0) with result: 0/Success (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312588: Resolving unique ccache of type MEMORY (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312602: Initializing MEMORY:Fnv4hCg with default princ username at NAFTA.COMPANY.ORG (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312621: Storing username at NAFTA.COMPANY.ORG -> krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG in MEMORY:Fnv4hCg (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312642: Getting credentials username at NAFTA.COMPANY.ORG -> host/usaeilvdip001.company-aws.org at company-idm.org using ccache MEMORY:Fnv4hCg (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312668: Retrieving username at NAFTA.COMPANY.ORG -> host/usaeilvdip001.company-aws.org at company-idm.org from MEMORY:Fnv4hCg with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312683: Retrieving username at NAFTA.COMPANY.ORG -> krbtgt/company-idm.org at company-idm.org from MEMORY:Fnv4hCg with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312698: Retrieving username at NAFTA.COMPANY.ORG -> krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG from MEMORY:Fnv4hCg with result: 0/Success (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312706: Starting with TGT for client realm: username at NAFTA.COMPANY.ORG -> krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312721: Retrieving username at NAFTA.COMPANY.ORG -> krbtgt/company-idm.org at company-idm.org from MEMORY:Fnv4hCg with result: -1765328243/Matching credential not found (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312729: Requesting TGT krbtgt/company-idm.org at NAFTA.COMPANY.ORG using TGT krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312747: Generated subkey for TGS request: aes256-cts/57A1 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312787: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312840: Encoding request body and padata into FAST request (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312894: Sending request (2313 bytes) to NAFTA.COMPANY.ORG (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.318783: Resolving hostname friawadsgc02.nafta.COMPANY.ORG. (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.319777: Sending initial UDP request to dgram 192.141.1.11:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.406882: Received answer (105 bytes) from dgram 192.141.1.11:88 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.407810: Response was not from master KDC (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.407847: TGS request result: -1765328377/Server not found in Kerberos database (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.407869: Destroying ccache MEMORY:Fnv4hCg (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [validate_tgt] (0x0020): TGT failed verification using key for [host/usaeilvdip001.company-aws.org at company-idm.org]. (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [get_and_save_tgt] (0x0020): 1242: [-1765328377][Server not found in Kerberos database] (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [map_krb5_error] (0x0020): 1303: [-1765328377][Server not found in Kerberos database] (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [k5c_send_data] (0x0200): Received error code 1432158209 (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [pack_response_packet] (0x2000): response packet size: [20] (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [k5c_send_data] (0x4000): Response sent. (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [main] (0x0400): krb5_child completed successfully [root at usaeilvdip001 sssd]# From bretif at phosphore.eu Tue Nov 22 17:06:18 2016 From: bretif at phosphore.eu (Bertrand =?utf-8?Q?R=C3=A9tif?=) Date: Tue, 22 Nov 2016 18:06:18 +0100 (CET) Subject: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue In-Reply-To: References: <1383346498.1295916.1476825748599.JavaMail.zimbra@phosphore.eu> <1467699597.1398215.1476901090793.JavaMail.zimbra@phosphore.eu> <835252359.90240.1477410669922.JavaMail.zimbra@phosphore.eu> <1898060535.461337.1479805632262.JavaMail.zimbra@phosphore.eu> <1349958374.477173.1479811804586.JavaMail.zimbra@phosphore.eu> Message-ID: <1673063951.535652.1479834378886.JavaMail.zimbra@phosphore.eu> Hi Florence, Thanks for clarification. Your explanation was very clear and I better understand Now my issue is that I need to start tracking "auditSigningCert cert-pki-ca", "ocspSigningCert cert-pki-ca" and "subsystemCert cert-pki-ca" on a server. I take a look on another server where they are properly tracked. However getcert list return me "pin set" and not a "pinfile" as described in your mail. In "/etc/pki/pki-tomcat/alias" I do not see any pwdfile.txt file, so my question is where do I get the PIN? Once again, thanks for your support, I tried to fix this issue for days! Regards Bertrand -- Bertrand R?tif Phosphore Services Informatiques - http://www.phosphore.eu Tel: 04 66 51 87 73 / Mob: 06 61 87 03 30 / Fax: 09 72 12 61 44 ----- Mail original ----- > De: "Florence Blanc-Renaud" > ?: "Bertrand R?tif" , freeipa-users at redhat.com > Envoy?: Mardi 22 Novembre 2016 13:17:34 > Objet: Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue > On 11/22/2016 11:50 AM, Bertrand R?tif wrote: > > > > > > *De: *"Florence Blanc-Renaud" > > *?: *"Bertrand R?tif" , freeipa-users at redhat.com > > *Envoy?: *Mardi 22 Novembre 2016 11:33:45 > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > pki-tomcat issue > > > > On 11/22/2016 10:07 AM, Bertrand R?tif wrote: > > > > > ------------------------------------------------------------------------ > > > > > > *De: *"Bertrand R?tif" > > > *?: *freeipa-users at redhat.com > > > *Envoy?: *Mardi 25 Octobre 2016 17:51:09 > > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > > pki-tomcat issue > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > *De: *"Florence Blanc-Renaud" > > > *?: *"Bertrand R?tif" , > > > freeipa-users at redhat.com > > > *Envoy?: *Jeudi 20 Octobre 2016 18:45:21 > > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > > pki-tomcat issue > > > > > > On 10/19/2016 08:18 PM, Bertrand R?tif wrote: > > > > *De: *"Bertrand R?tif" > > > > > > > > *?: *freeipa-users at redhat.com > > > > *Envoy?: *Mercredi 19 Octobre 2016 15:42:07 > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > certificate. > > > > pki-tomcat issue > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > *De: *"Rob Crittenden" > > > > *?: *"Bertrand R?tif" , > > > > freeipa-users at redhat.com > > > > *Envoy?: *Mercredi 19 Octobre 2016 15:30:14 > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > > certificate. > > > > pki-tomcat issue > > > > > > > > Bertrand R?tif wrote: > > > > >> De: "Martin Babinsky" > > > > >> ?: freeipa-users at redhat.com > > > > >> Envoy?: Mercredi 19 Octobre 2016 08:45:49 > > > > >> Objet: Re: [Freeipa-users] Impossible to renew > > > certificate. > > > > pki-tomcat issue > > > > > > > > > >> On 10/18/2016 11:22 PM, Bertrand R?tif wrote: > > > > >>> Hello, > > > > >>> > > > > >>> I had an issue with pki-tomcat. > > > > >>> I had serveral certificate that was expired and > > > pki-tomcat > > > > did not start > > > > >>> anymore. > > > > >>> > > > > >>> I set the dateon the server before certificate > > > expiration > > > > and then > > > > >>> pki-tomcat starts properly. > > > > >>> Then I try to resubmit the certificate, but > > I get > > > below error: > > > > >>> "Profile caServerCert Not Found" > > > > >>> > > > > >>> Do you have any idea how I could fix this issue. > > > > >>> > > > > >>> Please find below output of commands: > > > > >>> > > > > >>> > > > > >>> # getcert resubmit -i 20160108170324 > > > > >>> > > > > >>> # getcert list -i 20160108170324 > > > > >>> Number of certificates and requests being > > tracked: 7. > > > > >>> Request ID '20160108170324': > > > > >>> status: MONITORING > > > > >>> ca-error: Server at > > > > >>> > > > "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit" > > > > replied: > > > > >>> Profile caServerCert Not Found > > > > >>> stuck: no > > > > >>> key pair storage: > > > > >>> > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > >>> Certificate > > DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > >>> certificate: > > > > >>> > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > >>> Certificate DB' > > > > >>> CA: dogtag-ipa-ca-renew-agent > > > > >>> issuer: CN=Certificate Authority,O=A.SKINFRA.EU > > > > >>> subject: CN=IPA RA,O=A.SKINFRA.EU > > > > >>> expires: 2016-06-28 15:25:11 UTC > > > > >>> key usage: > > > > >>> > > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > >>> eku: id-kp-serverAuth,id-kp-clientAuth > > > > >>> pre-save command: > > > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > > >>> post-save command: > > > /usr/lib64/ipa/certmonger/renew_ra_cert > > > > >>> track: yes > > > > >>> auto-renew: yes > > > > >>> > > > > >>> > > > > >>> Thanksby advance for your help. > > > > >>> Bertrand > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > > > > > > >> Hi Betrand, > > > > > > > > > >> what version of FreeIPA and Dogtag are you > > running? > > > > > > > > > >> Also perform the following search on the IPA > > master > > > and post > > > > the result: > > > > > > > > > >> """ > > > > >> ldapsearch -D "cn=Directory Manager" -W -b > > > > >> 'ou=certificateProfiles,ou=ca,o=ipaca' > > > > '(objectClass=certProfile)' > > > > >> """ > > > > > > > > > > Hi Martin, > > > > > > > > > > Thanks for your reply. > > > > > > > > > > Here is version: > > > > > - FreeIPA 4.2.0 > > > > > - Centos 7.2 > > > > > > > > > > I have been able to fix the issue with "Profile > > > caServerCert > > > > Not Found" by editing > > > /var/lib/pki/pki-tomcat/ca/conf/CS.cfg > > > > > I replace below entry > > > > > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem" > > > > > by > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem" > > > > > > > > > > and then launch "ipa-server-upgrade" command > > > > > I found this solution in this post: > > > > > > http://osdir.com/ml/freeipa-users/2016-03/msg00280.html > > > > > > > > > > Then I was able to renew my certificate. > > > > > > > > > > However I reboot my server to and pki-tomcat > > do not > > > start and > > > > provide with a new erreor in > > > /var/log/pki/pki-tomcat/ca/debug > > > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > CertUtils: > > > > verifySystemCertByNickname() passed: > > auditSigningCert > > > cert-pki-ca > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > SignedAuditEventFactory: create() > > > > > > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$ > > > > > > > System$][Outcome=Success][CertNickName=auditSigningCert > > > > cert-pki-ca] CIMC certificate verification > > > > > > > > > > java.lang.Exception: SystemCertsVerification: > > system > > > certs > > > > verification failure > > > > > at > > > > > > > > > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) > > > > > at > > > > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) > > > > > at > > > > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) > > > > > at > > > > > > > > > com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701) > > > > > at > > > > > > > > > com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148) > > > > > at > > com.netscape.certsrv.apps.CMS.startup(CMS.java:200) > > > > > at > > com.netscape.certsrv.apps.CMS.start(CMS.java:1602) > > > > > at > > > > > > > > > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) > > > > > at > > > javax.servlet.GenericServlet.init(GenericServlet.java:158) > > > > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > > at > > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > > at > > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > > at > > java.lang.reflect.Method.invoke(Method.java:606) > > > > > at > > > > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) > > > > > at > > > > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) > > > > > at > > > java.security.AccessController.doPrivileged(Native Method) > > > > > at > > > javax.security.auth.Subject.doAsPrivileged(Subject.java:536) > > > > > at > > > > > > > > > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) > > > > > at > > > > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) > > > > > at > > > > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) > > > > > at > > > > > > > > > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) > > > > > at > > > > > > > > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) > > > > > at > > > > > > > > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) > > > > > at > > > > > > > > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) > > > > > at > > > > > > > > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) > > > > > at > > > > > > > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > > > > > at > > > > > > > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > > > > at > > > > > > > > > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > > > > > at > > > > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > > > > > at > > > > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > > > > > at > > > java.security.AccessController.doPrivileged(Native Method) > > > > > at > > > > > > > > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > > > > > at > > > > > > > > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > > > > > at > > > > > > > > > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > > > > > at > > > > > > > > > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > > > > > at > > > > > > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > > > > > at > > > java.util.concurrent.FutureTask.run(FutureTask.java:262) > > > > > at > > > > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > > > at > > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > SignedAuditEventFactory: create() > > > > > > > > > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] > > > > self tests execution (see selftests.log for details) > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > CMSEngine.shutdown() > > > > > > > > > > > > > > > I am currently stuck here. > > > > > Thanks a lot for your help. > > > > > > > > I'm guessing at least one of the CA subsystem > > > certificates are > > > > still > > > > expired. Look at the "getcert list" output to see if > > > there are any > > > > expired certificates. > > > > > > > > rob > > > > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > > > > > Hello Rob, > > > > > > > > I check on my 2 servers and no certificate is expired > > > > > > > > [root at sdkipa03 ~]# getcert list |grep expire > > > > expires: 2018-06-22 22:02:26 UTC > > > > expires: 2018-06-22 22:02:47 UTC > > > > expires: 2034-07-09 15:24:34 UTC > > > > expires: 2016-10-30 13:35:29 UTC > > > > > > > > [root at sdkipa01 conf]# getcert list |grep expire > > > > expires: 2018-06-12 23:38:01 UTC > > > > expires: 2018-06-12 23:37:41 UTC > > > > expires: 2018-06-11 22:53:57 UTC > > > > expires: 2018-06-11 22:55:50 UTC > > > > expires: 2018-06-11 22:57:47 UTC > > > > expires: 2034-07-09 15:24:34 UTC > > > > expires: 2018-06-11 22:59:55 UTC > > > > > > > > I see that one certificate is in status: CA_UNREACHABLE, > > > maybe I > > > > reboot to soon my server... > > > > > > > > I continue to investigate > > > > > > > > Thanks for your help. > > > > Bertrand > > > > > > > > I fix my previous issue. > > > > Now I have an issue with a server. > > > > This server can not start pki-tomcatd, I get this error in > > > debug file: > > > > "Error netscape.ldap.LDAPExceptio n: IO Error creating > > JSS SSL > > > Socket (-1)" > > > > > > > > After investigation i see that I do not have "ipaCert" > > > certificat in > > > > "/etc/httpd/alias" > > > > cf below command: > > > > > > > > [root at sdkipa03 ~]# getcert list -d /etc/httpd/alias > > > > Number of certificates and requests being tracked: 4. > > > > Request ID '20141110133632': > > > > status: MONITORING > > > > stuck: no > > > > 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=A.SKINFRA.EU > > > > subject: CN=sdkipa03.skinfra.eu,O=A.SKINFRA.EU > > > > expires: 2018-06-22 22:02:47 UTC > > > > principal name: HTTP/sdkipa03.skinfra.eu at A.SKINFRA.EU > > > > key usage: > > > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > > pre-save command: > > > > post-save command: > > /usr/lib64/ipa/certmonger/restart_httpd > > > > track: yes > > > > auto-renew: yes > > > > > > > > > > > > How can I add the certificate to /etc/httpd/alias? > > > > > > > Hi, > > > > > > for the record, the command getcert list that you supplied > > shows > > > the > > > certificates in /etc/httpd/alias that are tracked by > > certmonger. > > > If you > > > want to display all the certificates contained in > > /etc/httpd/alias > > > (whether tracked or not), then you may want to use > > certutil -L -d > > > /etc/httpd/alias instead. > > > > > > If ipaCert is missing, you can export ipaCert certificate from > > > another > > > master, then import it to your server. > > > > > > On a master containing the cert: > > > # certutil -d /etc/httpd/alias -L -n 'ipaCert' -a > > > > /tmp/newRAcert.crt > > > > > > Then copy the file /tmp/newRAcert.crt to your server and > > import > > > the cert: > > > # certutil -d /etc/httpd/alias -A -n 'ipaCert' -a -i > > > /tmp/newRAcert.crt > > > -t u,u,u > > > > > > And finally you need to tell certmonger to monitor the > > cert using > > > getcert start-tracking. > > > > > > Hope this helps, > > > Flo. > > > > > > > Thanks fo ryour support. > > > > Regards > > > > Bertrand > > > > > > > > > > > > > > > > > > Hi, > > > > > > Florence, thanks for your help. > > > I was able to import correctly ipaCert with your commands. > > > Now it seems that I also have an issue on one server with > > > "subsystemCert cert-pki-ca" in /etc/pki/pki-tomcat/alias as I get > > > below error when pki-tomcat try to start > > > > > > > > > LdapJssSSLSocket set client auth cert nickname subsystemCert > > cert-pki-ca > > > Could not connect to LDAP server host sdkipa03.XX.YY port 636 > > Error > > > netscape.ldap.LDAPException: IO Error creating JSS SSL Socket ( > > > -1) > > > > > > > > > Is there a way to restore a correct "subsystemCert cert-pki-ca"? > > > > > > Regards > > > Bertrand > > > > > > Hello, > > > > > > I am still stuck with my IPA server. > > > I have issues on both servers. > > > On server1, below certificate is not renewed properly > > > certutil -L -d /etc/httpd/alias/ -n "ipaCert" > > > > > > and on server 2 this is this certificate: > > > certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "Server-Cert > > cert-pki-ca" > > > > > > Could you provide me with the correct syntax with start-tracking > > command. > > > I tried to laucnh this command but my certificat remains in > > > "NEWLY_ADDED_NEED_KEYINFO_READ_PIN" state. > > > Here is the comnd I use: > > > getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d > > > /var/lib/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -B > > > /usr/lib64/ipa/certmonger/stop_pkicad -C > > > '/usr/lib64/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"' -T > > > "Server-Cert cert-pki-ca" -P '20160614000000' > > > > > Hi Bertrand, > > > > to get the right command, you can check on a system where the > > certificate is properly monitored, this will show you the right > > parameters: > > $ sudo getcert list -n ipaCert > > Number of certificates and requests being tracked: 8. > > Request ID '20161122095344': > > [..] key pair storage: > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > [...] > > CA: dogtag-ipa-ca-renew-agent > > [...] > > pre-save command: /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > > [...] > > > > The relevant fields are NSSDB location, pinfile, nickname, CA, pre and > > post-save commands. So in order to monitor ipaCert, you will need to use > > $ sudo getcert start-tracking -d /etc/httpd/alias -n ipaCert \ > > -p /etc/httpd/alias/pwdfile.txt \ > > -c dogtag-ipa-ca-renew-agent \ > > -B /usr/lib64/ipa/certmonger/renew_ra_cert_pre \ > > -C /usr/lib64/ipa/certmonger/renew_ra_cert > > > > HTH, > > Flo. > > > > > Thanks by advance for your help. > > > > > > Regards > > > Bertrand > > > > Hello Florence, > > > > Thanks for your reply. > > Before doing any mistakes, I just need some explanations as I think I do > > not well understand how it should work. > > > > Do all the certificate need to be track by certmonger on all servers or > > they should only be tracked on one server and FreeIPA will update them > > on other servers? > > > > In my case I have below certicates outdated and not track on "server 1": > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "auditSigningCert > > cert-pki-ca" > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "ocspSigningCert > > cert-pki-ca" > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "subsystemCert > > cert-pki-ca" > > > > They are tracked by certmonger and have been correctly renewed on "server > > 2" > > Do I need to add them tracked by certmonger on "server 1"? > > If not, it means FreeIPA failed to update them? Should I delete and > > import them manually on server 2? > > > > If you need more details, do not hesitate to ask. > > > Hi Bertrand, > The certificate tracking depends on the type of certificate and on the > server you're considering. For instance, if IPA includes a Certificate > Authority, then ipaCert will be present on all the IPA servers > (master/replicas) and tracked on all of them. The same ipaCert > certificate is used on all the replicas. On the renewal master, the > renewal operation actually renews the certificate and uploads the cert > on LDAP, but on the other replicas the operation consists in downloading > the new certificate from LDAP. > The HTTP and LDAP server certificates are present and tracked on all the > IPA servers, but they are different on each server (you can see that the > Subject of the certificate contains the hostname). They can be renewed > independently on each IPA server. > The certificates used by Dogtag (the component providing the Certificate > System) are present and tracked only on the IPA servers where the CA was > setup (for instance if you installed a replica with --setup-ca or if you > ran ipa-ca-install later on). The same certificates are used on all > replicas containing a CA instance. > They are: 'ocspSigningCert cert-pki-ca', 'subsystemCert cert-pki-ca', > 'caSigningCert cert-pki-ca' and 'Server-Cert cert-pki-ca'. > The renewal operation renews them on the renewal master and uploads them > in LDAP, but just downloads them from LDAP on the other servers. > In your example, if server1 also contains a CA instance then it should > also track the above certs. > You can find the renewal master with the following ldapsearch command: > $ ldapsearch -h localhost -p 389 -D 'cn=Directory Manager' -w password > -b "cn=masters,cn=ipa,cn=etc,$BASEDN" -LLL > '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn > dn: cn=CA,cn=ipaserver.fqdn,cn=masters,cn=ipa,cn=etc,$BASEDN > In this case the renewal master is ipaserver.fqdn > Hope this clarifies, > Flo. > > Regards > > Bertrand > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lachlan.Simpson at petermac.org Tue Nov 22 21:30:08 2016 From: Lachlan.Simpson at petermac.org (Simpson Lachlan) Date: Tue, 22 Nov 2016 21:30:08 +0000 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <58346622.1080504@sonsorol.org> References: <58346622.1080504@sonsorol.org> Message-ID: <0137003026EBE54FBEC540C5600C03C43C4E8A@PAPR-EXMBX1.petermac.org.au> > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Chris Dagdigian > Sent: Wednesday, 23 November 2016 2:37 AM > To: freeipa-users at redhat.com > Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD > forest - where am I going wrong? > > > /etc/krb5.conf (IPA client) > --------------------------------- > > [libdefaults] > > default_realm = COMPANY-IDM.ORG > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > udp_preference_limit = 0 > default_ccache_name = KEYRING:persistent:%{uid} > > [realms] > > COMPANY-IDM.ORG = { > kdc = usaeilidmp001.company-idm.org:88 > master_kdc = usaeilidmp001.company-idm.org:88 > admin_server = usaeilidmp001.company-idm.org:749 > default_domain = company-idm.org > pkinit_anchors = FILE:/etc/ipa/ca.crt > > } > > [domain_realm] > > ipa-client.company-aws.org = COMPANY-IDM.ORG > > [capaths] > > COMPANY-AWS.ORG = { > > COMPANY-IDM.ORG = COMPANY-AWS.ORG > > } > > COMPANY-IDM.ORG = { > > COMPANY-AWS.ORG = COMPANY-AWS.ORG > > } By no means am I an expert, but isn't there meant to be a stanza in [realm] that looks like this? auth_to_local = RULE:[1:$1@$0](^.*@DOMAIN.COM$)s/@DOMAIN.COM/@domain.com/ auth_to_local = DEFAULT Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. From dag at sonsorol.org Tue Nov 22 22:28:11 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Tue, 22 Nov 2016 17:28:11 -0500 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <0137003026EBE54FBEC540C5600C03C43C4E8A@PAPR-EXMBX1.petermac.org.au> References: <58346622.1080504@sonsorol.org> <0137003026EBE54FBEC540C5600C03C43C4E8A@PAPR-EXMBX1.petermac.org.au> Message-ID: <5834C67B.90606@sonsorol.org> Simpson Lachlan wrote: > By no means am I an expert, but isn't there meant to be a stanza in [realm] that looks like this? > > auth_to_local = RULE:[1:$1@$0](^.*@DOMAIN.COM$)s/@DOMAIN.COM/@domain.com/ > auth_to_local = DEFAULT > Appreciate the reply! From what I can tell that stanza is not needed when there is a localauth provider for IPA (RHEL-7/Centos-7 basically) - I think the docs I read mentioned that the actions in the stanza are automatic or implicit when localauth plugin is present. Both my IPA box and test client are CentOS-7 at the moment so I did not do the extra auth_to_local rule Regards, Chris From Lachlan.Simpson at petermac.org Tue Nov 22 22:45:21 2016 From: Lachlan.Simpson at petermac.org (Simpson Lachlan) Date: Tue, 22 Nov 2016 22:45:21 +0000 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <5834C67B.90606@sonsorol.org> References: <58346622.1080504@sonsorol.org> <0137003026EBE54FBEC540C5600C03C43C4E8A@PAPR-EXMBX1.petermac.org.au> <5834C67B.90606@sonsorol.org> Message-ID: <0137003026EBE54FBEC540C5600C03C43C4F29@PAPR-EXMBX1.petermac.org.au> > -----Original Message----- > From: Chris Dagdigian [mailto:dag at sonsorol.org] > Sent: Wednesday, 23 November 2016 9:28 AM > To: Simpson Lachlan > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] This again :) - ssh authentication for users in complex > AD forest - where am I going wrong? > > Simpson Lachlan wrote: > > By no means am I an expert, but isn't there meant to be a stanza in [realm] that > looks like this? > > > > auth_to_local = > > RULE:[1:$1@$0](^.*@DOMAIN.COM$)s/@DOMAIN.COM/@domain.com/ > > auth_to_local = DEFAULT > > > > Appreciate the reply! > > From what I can tell that stanza is not needed when there is a localauth provider for > IPA (RHEL-7/Centos-7 basically) - I think the docs I read mentioned that the actions > in the stanza are automatic or implicit when localauth plugin is present. > > Both my IPA box and test client are CentOS-7 at the moment so I did not do the > extra auth_to_local rule Oh! So do I. I don't need it either? Damn. Thanks for the tip. Cheers L. This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. From tk at mdevsys.com Wed Nov 23 02:48:25 2016 From: tk at mdevsys.com (TomK) Date: Tue, 22 Nov 2016 21:48:25 -0500 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> Message-ID: <97e67d02-a736-239e-0d65-5ce551454a1f@mdevsys.com> On 11/22/2016 10:22 AM, Martin Basti wrote: > > > On 22.11.2016 13:57, TomK wrote: >> On 11/22/2016 2:59 AM, Martin Basti wrote: >>> Hey, >>> >>> >>> On 22.11.2016 06:33, TomK wrote: >>>> Hey Guy's, >>>> >>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 over to >>>> my dual Free IPA server. The Free IPA servers are authoritative for >>>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>>> and forwards dom.abc.xyz. >>> Do you have configured proper zone delegation for subdomain dom.abc.xyz? >>> Proper NS and glue records >>> http://www.zytrax.com/books/dns/ch9/delegate.html >>> >>>> >>>> I cannot ping dom.abc.xyz. Everything else, including client >>>> registrations, work fine. If Free IPA is authoritative on >>>> dom.abc.xyz, should it not create DNS entries so the sub domain can be >>>> pinged as well? >>> >>> What do you mean by "ping"? >>> >>>> >>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>>> and wanted to ask if you can point me to some materials online to >>>> determine where can I permanently adjust the search to add dom.abc.xyz >>>> to the already present abc.xyz . I wasn't able to locate what I >>>> needed in my searches. >>>> >>>> I'm using the latest v4. >>> >>> It depends on what are you using, probably you have NetworkManager there >>> that is editing /etc/resolv.conf >>> >>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >>> >>> >>> >>> Martin >> >> >> I Uninstalled NetworkManager. Still changes. >> ping dom.abc.com results in "ping: unknown host" >> >> I'll have a look at the first link, ty. >> > > ping (ICMP protocol) and DNS system are different things, do you have > hostname dom.abc.com with A record or it is a zone? > > with ping command hostname "dom.abc.com" is resolved to IP address > first, do you have A record set for dom.abc.com in zone apex or what are > you trying to achieve with ping command? > > for testing DNS try to use commands: dig, host, nslookup > > Martin > Apologize for the long reply but it should give some background on what it is that I'm doing. 1) dom.abc.com is a zone. There is no A record for dom.abc.com in FreeIPA (Confirmed by Petr). I get the point Petr Spacek pointed out in his comment as well. What should it really point too? ( I kind of answer this question below so please read on. ) Where I'm getting this from is that in Windows Server 2012 abc.com returns the IP of any of the participating AD / DNS servers within the cluster (The two Windows Server 2012 are a combined clustered AD + DNS servers.). Being able to resolve abc.xyz is handy. During a lookup, I can get a list of all the IP's associated with that domain which would indicate all the DNS + AD servers online under that domain or serving that domain: # nslookup abc.xyz Server: 192.168.0.3 Address: 192.168.0.3#53 Name: abc.xyz Address: 192.168.0.3 Name: abc.xyz Address: 192.168.0.1 Name: abc.xyz Address: 192.168.0.2 # Again, where this is handy is when configuring sssd.conf for example or other apps for that matter. I can just point the app to authenticate against the domain and I have my redundancy solved. Windows Server 2012 does it, but FreeIPA didn't, so I threw the question out there. Delegation from this Windows DNS works as expected. Any lookup from dom.abc.xyz is forwarded too and handled by FreeIPA servers. Tested this out. No issue with this. I did see earlier that there is no A record for dom.abc.xyz in FreeIPA. My reasons for asking if there was an IP on the subdomain in FreeIPA were above but the missing IP on the subdomain isn't a major issue for me. Things are working without dom.abc.xyz resolving to an IP. What I was hoping for is to have a VIP for the IPA servers and one for the Windows Server 2012 DNS Cluster in /etc/resolv.conf. (I have the VIP for the windows server). One forwarding to the other for a given domain. This is all for testing a) redundancy, b) forwarding, a) authentication . IE: # cat /etc/resolv.conf search nix.mds.xyz mds.xyz nameserver 192.168.0.3 <------------ Win Cluster DNS VIP nameserver 192.168.0.4 <------------ IPA Cluster DNS VIP * Just what I want to achieve above. VIP 192.168.0.4 doesn't exist on my cluster yet. I'm looking to integrate ucarp with the above IPA servers. 2) More to the topic of my second question however, is that /etc/resolv.conf, on the IPA servers themselves, get's rewritten on restart. Would like to know by what if I already uninstalled NetworkManager? When I configured the FreeIPA server, I used: ipa-server-install --setup-dns --forwarder=192.168.0.3 -p "Hush!" -a "Hush!" -r DOM.ABC.XYZ -n dom.abc.xyz --hostname ipa01.dom.abc.xyz Notice I used the VIP of the Windows Server 2012 Cluster when installing FreeIPA. This is nice for redundancy. So the resolv.conf ends up being: # cat /etc/resolv.conf # Generated by NetworkManager search abc.xyz nameserver 192.168.0.3 nameserver 123.123.123.1 nameserver 123.123.123.2 Then I add: search dom.abc.xyz abc.xyz but it changes back to search abc.xyz (the Windows Server 2012 DNS). This all works, except for the above minor items, and I can resolve anything over this network. ( Thinking this is fine because the forward is on the subdomain. I haven't had issues with forwarding through this setup. ) # cat /etc/resolv.conf # Generated by NetworkManager search abc.xyz nameserver 192.168.0.3 nameserver 123.123.123.1 nameserver 123.123.123.2 But NetworkManager is not installed on these IPA servers. I've removed it earlier: # rpm -aq|grep -i NetworkManager # Is FreeIPA replacing /etc/resolv.conf with a copy it keeps elsewhere? 3) After running: ipa-client-install --mkhomedir --enable-dns-updates on a new host, the hostname of the new host doesn't resolve for a few minutes. How do I make this instantaneous? (Other then that, autodiscovery of the IPA servers is excellent!). Before installing the IPA Client, the new hosts /etc/resolv.conf file looks like this: # cat /etc/resolv.conf search abc.xyz nameserver 192.168.0.3 nameserver 123.123.123.1 nameserver 123.123.123.2 I did dig, host, nslookup earlier. Verified all except for the items I'm inquiring about. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From rns at unimelb.edu.au Wed Nov 23 06:58:58 2016 From: rns at unimelb.edu.au (Robert Sturrock) Date: Wed, 23 Nov 2016 17:58:58 +1100 Subject: [Freeipa-users] AD Trust users not resolving on clients: ipa_get_*_acct request failed Message-ID: <4285203D-558D-4926-BE25-993C460601A3@unimelb.edu.au> Hi All. I?m having a problem getting trust users to resolve on *any* IPA client (this _was_ working well and I?m not sure what?s changed that may have caused it to start failing - although we have recently updated to IPA 4.4, plus IPA DNS enabled with delegation of ipa.example.com). Whenever I try to lookup a trust user on a client (Ubuntu 16.04 with sssd-1.13.4-1ubuntu1.1) I see: # id username at example.com id: ?username at example.com': no such user The error message block in the sssd/domain log is: > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_group_dn_list] (0x0040): find_domain_by_object_name failed. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): get_group_dn_list failed. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [12]: Cannot allocate memory. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,12,Out of memory A more complete log is below. The domain users resolve fine on each of the three IPA servers (all RHEL7 with ipa-server-4.4.0-12.el7.x86_64). IPA domain is ipa.example.com. AD domain is example.com. I have looked at https://fedorahosted.org/sssd/wiki/Troubleshooting, but no particular ideas are coming from that, so I guess I?m after some hints about what to check or any further tests to try. Regards, Robert. (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_dispatch] (0x4000): dbus conn: 0xfd8480 (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_dispatch] (0x4000): Dispatching. (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for [0x1001][FAST BE_REQ_USER][1][name=mib] (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [be_req_set_domain] (0x0400): Changing request domain from [ipa.example.com] to [example.com] (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaUserOverride)(uid=mib))]. (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_print_server] (0x2000): Searching 172.25.180.53 (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaUserOverride)(uid=mib))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=example,dc=com]. (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 21 (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_op_add] (0x2000): New operation 21 timeout 6 (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfd76d0], connected[1], ops[0xff6420], ldap[0xfded70] (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_op_destructor] (0x2000): Operation 21 finished (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaUserOverride)(uid=mib))]. (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 22 (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_op_add] (0x2000): New operation 22 timeout 6 (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfd76d0], connected[1], ops[0xff9310], ldap[0xfded70] (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfd76d0], connected[1], ops[0xff9310], ldap[0xfded70] (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null). (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_op_destructor] (0x2000): Operation 22 finished (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [add_v1_user_data] (0x4000): BER tag is [48] (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Found new sequence. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [objectSIDString]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [userPrincipalName]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [adAccountExpires]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [adUserAccountControl]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [mail]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalDN]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff88e0 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff89a0 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff88e0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff89a0 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff88e0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff7530 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff75f0 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff7530 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff75f0 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff7530 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff72a0 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff7360 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff72a0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff7360 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff72a0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff72a0 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff7360 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff72a0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff7360 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff72a0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff7460 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff7520 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff7460 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff7520 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff7460 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff7460 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff7520 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff7460 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff7520 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff7460 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff75d0 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016050 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff75d0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016050 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff75d0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff72a0 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff7360 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff72a0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff7360 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff72a0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1016050 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016110 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x1016050 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016110 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x1016050 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1016050 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016110 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x1016050 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016110 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x1016050 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1016150 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016210 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x1016150 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016210 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x1016150 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1016210 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10162d0 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x1016210 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x10162d0 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x1016210 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1016150 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016210 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x1016150 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016210 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x1016150 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x10162b0 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016370 (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x10162b0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016370 "ltdb_timeout" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x10162b0 "ltdb_callback" (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_group_dn_list] (0x0040): find_domain_by_object_name failed. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): get_group_dn_list failed. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_done] (0x4000): releasing operation connection (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [12]: Cannot allocate memory. (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,12,Out of memory (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfd76d0], connected[1], ops[(nil)], ldap[0xfded70] (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! From th at casalogic.dk Wed Nov 23 07:24:48 2016 From: th at casalogic.dk (Troels Hansen) Date: Wed, 23 Nov 2016 08:24:48 +0100 (CET) Subject: [Freeipa-users] Samba in IPA / AD trust, best practise Message-ID: <1109983165.948187.1479885888068.JavaMail.zimbra@casalogic.dk> Hi there I'm having a bit of a dilemma. I'm going to set up a Samba in a IPA 4.4 / AD trust, and was wondering what the official or best practise method of joining the Samba server is: I see two methods: - The one from http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA using wbclient. - A second one where I use ipasam I was wondering which is actually the officially best practise as it seems documentation states wbclient, but samba configured on IPA server uses ipasam? -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Wed Nov 23 07:49:28 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 23 Nov 2016 08:49:28 +0100 Subject: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue In-Reply-To: <1673063951.535652.1479834378886.JavaMail.zimbra@phosphore.eu> References: <1383346498.1295916.1476825748599.JavaMail.zimbra@phosphore.eu> <1467699597.1398215.1476901090793.JavaMail.zimbra@phosphore.eu> <835252359.90240.1477410669922.JavaMail.zimbra@phosphore.eu> <1898060535.461337.1479805632262.JavaMail.zimbra@phosphore.eu> <1349958374.477173.1479811804586.JavaMail.zimbra@phosphore.eu> <1673063951.535652.1479834378886.JavaMail.zimbra@phosphore.eu> Message-ID: <3b56f25b-7645-b861-e2b6-f0a02a26e32c@redhat.com> On 11/22/2016 06:06 PM, Bertrand R?tif wrote: > Hi Florence, > > Thanks for clarification. > Your explanation was very clear and I better understand > > Now my issue is that I need to start tracking "auditSigningCert > cert-pki-ca", "ocspSigningCert cert-pki-ca" and "subsystemCert > cert-pki-ca" on a server. > > I take a look on another server where they are properly tracked. However > getcert list return me "pin set" and not a "pinfile" as described in > your mail. > In "/etc/pki/pki-tomcat/alias" I do not see any pwdfile.txt file, so my > question is where do I get the PIN? > Hi Bertrand, With IPA 4.2.0 I believe that the pin is stored in /var/lib/pki/pki-tomcat/conf/password.conf, in the 'internal' field: $ grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf internal=0123456789101 HTH, Flo > Once again, thanks for your support, I tried to fix this issue for days! > > Regards > Bertrand > > > -- > Bertrand R?tif > Phosphore Services Informatiques - http://www.phosphore.eu > Tel: 04 66 51 87 73 / Mob: 06 61 87 03 30 / Fax: 09 72 12 61 44 > > ------------------------------------------------------------------------ > > *De: *"Florence Blanc-Renaud" > *?: *"Bertrand R?tif" , freeipa-users at redhat.com > *Envoy?: *Mardi 22 Novembre 2016 13:17:34 > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > pki-tomcat issue > > On 11/22/2016 11:50 AM, Bertrand R?tif wrote: > > > > > > *De: *"Florence Blanc-Renaud" > > *?: *"Bertrand R?tif" , > freeipa-users at redhat.com > > *Envoy?: *Mardi 22 Novembre 2016 11:33:45 > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > pki-tomcat issue > > > > On 11/22/2016 10:07 AM, Bertrand R?tif wrote: > > > > > > ------------------------------------------------------------------------ > > > > > > *De: *"Bertrand R?tif" > > > *?: *freeipa-users at redhat.com > > > *Envoy?: *Mardi 25 Octobre 2016 17:51:09 > > > *Objet: *Re: [Freeipa-users] Impossible to renew > certificate. > > > pki-tomcat issue > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > *De: *"Florence Blanc-Renaud" > > > *?: *"Bertrand R?tif" , > > > freeipa-users at redhat.com > > > *Envoy?: *Jeudi 20 Octobre 2016 18:45:21 > > > *Objet: *Re: [Freeipa-users] Impossible to renew > certificate. > > > pki-tomcat issue > > > > > > On 10/19/2016 08:18 PM, Bertrand R?tif wrote: > > > > *De: *"Bertrand R?tif" > > > > > > > > *?: *freeipa-users at redhat.com > > > > *Envoy?: *Mercredi 19 Octobre 2016 15:42:07 > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > certificate. > > > > pki-tomcat issue > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > *De: *"Rob Crittenden" > > > > *?: *"Bertrand R?tif" , > > > > freeipa-users at redhat.com > > > > *Envoy?: *Mercredi 19 Octobre 2016 15:30:14 > > > > *Objet: *Re: [Freeipa-users] Impossible to > renew > > > certificate. > > > > pki-tomcat issue > > > > > > > > Bertrand R?tif wrote: > > > > >> De: "Martin Babinsky" > > > > >> ?: freeipa-users at redhat.com > > > > >> Envoy?: Mercredi 19 Octobre 2016 08:45:49 > > > > >> Objet: Re: [Freeipa-users] Impossible > to renew > > > certificate. > > > > pki-tomcat issue > > > > > > > > > >> On 10/18/2016 11:22 PM, Bertrand R?tif > wrote: > > > > >>> Hello, > > > > >>> > > > > >>> I had an issue with pki-tomcat. > > > > >>> I had serveral certificate that was > expired and > > > pki-tomcat > > > > did not start > > > > >>> anymore. > > > > >>> > > > > >>> I set the dateon the server before > certificate > > > expiration > > > > and then > > > > >>> pki-tomcat starts properly. > > > > >>> Then I try to resubmit the > certificate, but > > I get > > > below error: > > > > >>> "Profile caServerCert Not Found" > > > > >>> > > > > >>> Do you have any idea how I could fix > this issue. > > > > >>> > > > > >>> Please find below output of commands: > > > > >>> > > > > >>> > > > > >>> # getcert resubmit -i 20160108170324 > > > > >>> > > > > >>> # getcert list -i 20160108170324 > > > > >>> Number of certificates and requests being > > tracked: 7. > > > > >>> Request ID '20160108170324': > > > > >>> status: MONITORING > > > > >>> ca-error: Server at > > > > >>> > > > > "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit" > > > > replied: > > > > >>> Profile caServerCert Not Found > > > > >>> stuck: no > > > > >>> key pair storage: > > > > >>> > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > >>> Certificate > > DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > >>> certificate: > > > > >>> > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > >>> Certificate DB' > > > > >>> CA: dogtag-ipa-ca-renew-agent > > > > >>> issuer: CN=Certificate > Authority,O=A.SKINFRA.EU > > > > >>> subject: CN=IPA RA,O=A.SKINFRA.EU > > > > >>> expires: 2016-06-28 15:25:11 UTC > > > > >>> key usage: > > > > >>> > > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > >>> eku: id-kp-serverAuth,id-kp-clientAuth > > > > >>> pre-save command: > > > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > > >>> post-save command: > > > /usr/lib64/ipa/certmonger/renew_ra_cert > > > > >>> track: yes > > > > >>> auto-renew: yes > > > > >>> > > > > >>> > > > > >>> Thanksby advance for your help. > > > > >>> Bertrand > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > > > > > > >> Hi Betrand, > > > > > > > > > >> what version of FreeIPA and Dogtag are you > > running? > > > > > > > > > >> Also perform the following search on > the IPA > > master > > > and post > > > > the result: > > > > > > > > > >> """ > > > > >> ldapsearch -D "cn=Directory Manager" -W -b > > > > >> 'ou=certificateProfiles,ou=ca,o=ipaca' > > > > '(objectClass=certProfile)' > > > > >> """ > > > > > > > > > > Hi Martin, > > > > > > > > > > Thanks for your reply. > > > > > > > > > > Here is version: > > > > > - FreeIPA 4.2.0 > > > > > - Centos 7.2 > > > > > > > > > > I have been able to fix the issue with > "Profile > > > caServerCert > > > > Not Found" by editing > > > /var/lib/pki/pki-tomcat/ca/conf/CS.cfg > > > > > I replace below entry > > > > > > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem" > > > > > by > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem" > > > > > > > > > > and then launch "ipa-server-upgrade" command > > > > > I found this solution in this post: > > > > > > http://osdir.com/ml/freeipa-users/2016-03/msg00280.html > > > > > > > > > > Then I was able to renew my certificate. > > > > > > > > > > However I reboot my server to and pki-tomcat > > do not > > > start and > > > > provide with a new erreor in > > > /var/log/pki/pki-tomcat/ca/debug > > > > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > CertUtils: > > > > verifySystemCertByNickname() passed: > > auditSigningCert > > > cert-pki-ca > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > SignedAuditEventFactory: create() > > > > > > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$ > > > > > > > System$][Outcome=Success][CertNickName=auditSigningCert > > > > cert-pki-ca] CIMC certificate verification > > > > > > > > > > java.lang.Exception: > SystemCertsVerification: > > system > > > certs > > > > verification failure > > > > > at > > > > > > > > > > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) > > > > > at > > > > > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) > > > > > at > > > > > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) > > > > > at > > > > > > > > > > com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701) > > > > > at > > > > > > > > > com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148) > > > > > at > > com.netscape.certsrv.apps.CMS.startup(CMS.java:200) > > > > > at > > com.netscape.certsrv.apps.CMS.start(CMS.java:1602) > > > > > at > > > > > > > > > > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) > > > > > at > > > > javax.servlet.GenericServlet.init(GenericServlet.java:158) > > > > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > > > > at > > > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > > at > > > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > > at > > java.lang.reflect.Method.invoke(Method.java:606) > > > > > at > > > > > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) > > > > > at > > > > > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) > > > > > at > > > java.security.AccessController.doPrivileged(Native > Method) > > > > > at > > > > javax.security.auth.Subject.doAsPrivileged(Subject.java:536) > > > > > at > > > > > > > > > > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) > > > > > at > > > > > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) > > > > > at > > > > > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) > > > > > at > > > > > > > > > > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) > > > > > at > > > > > > > > > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) > > > > > at > > > > > > > > > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) > > > > > at > > > > > > > > > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) > > > > > at > > > > > > > > > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) > > > > > at > > > > > > > > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > > > > > at > > > > > > > > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > > > > at > > > > > > > > > > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > > > > > at > > > > > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > > > > > at > > > > > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > > > > > at > > > java.security.AccessController.doPrivileged(Native > Method) > > > > > at > > > > > > > > > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > > > > > at > > > > > > > > > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > > > > > at > > > > > > > > > > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > > > > > at > > > > > > > > > > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > > > > > at > > > > > > > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > > > > > at > > > java.util.concurrent.FutureTask.run(FutureTask.java:262) > > > > > at > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > > > at > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > SignedAuditEventFactory: create() > > > > > > > > > > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] > > > > self tests execution (see selftests.log > for details) > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > CMSEngine.shutdown() > > > > > > > > > > > > > > > I am currently stuck here. > > > > > Thanks a lot for your help. > > > > > > > > I'm guessing at least one of the CA subsystem > > > certificates are > > > > still > > > > expired. Look at the "getcert list" output > to see if > > > there are any > > > > expired certificates. > > > > > > > > rob > > > > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > > > > > Hello Rob, > > > > > > > > I check on my 2 servers and no certificate is > expired > > > > > > > > [root at sdkipa03 ~]# getcert list |grep expire > > > > expires: 2018-06-22 22:02:26 UTC > > > > expires: 2018-06-22 22:02:47 UTC > > > > expires: 2034-07-09 15:24:34 UTC > > > > expires: 2016-10-30 13:35:29 UTC > > > > > > > > [root at sdkipa01 conf]# getcert list |grep expire > > > > expires: 2018-06-12 23:38:01 UTC > > > > expires: 2018-06-12 23:37:41 UTC > > > > expires: 2018-06-11 22:53:57 UTC > > > > expires: 2018-06-11 22:55:50 UTC > > > > expires: 2018-06-11 22:57:47 UTC > > > > expires: 2034-07-09 15:24:34 UTC > > > > expires: 2018-06-11 22:59:55 UTC > > > > > > > > I see that one certificate is in status: > CA_UNREACHABLE, > > > maybe I > > > > reboot to soon my server... > > > > > > > > I continue to investigate > > > > > > > > Thanks for your help. > > > > Bertrand > > > > > > > > I fix my previous issue. > > > > Now I have an issue with a server. > > > > This server can not start pki-tomcatd, I get this > error in > > > debug file: > > > > "Error netscape.ldap.LDAPExceptio n: IO Error creating > > JSS SSL > > > Socket (-1)" > > > > > > > > After investigation i see that I do not have "ipaCert" > > > certificat in > > > > "/etc/httpd/alias" > > > > cf below command: > > > > > > > > [root at sdkipa03 ~]# getcert list -d /etc/httpd/alias > > > > Number of certificates and requests being tracked: 4. > > > > Request ID '20141110133632': > > > > status: MONITORING > > > > stuck: no > > > > 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=A.SKINFRA.EU > > > > subject: CN=sdkipa03.skinfra.eu,O=A.SKINFRA.EU > > > > expires: 2018-06-22 22:02:47 UTC > > > > principal name: > HTTP/sdkipa03.skinfra.eu at A.SKINFRA.EU > > > > key usage: > > > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > > pre-save command: > > > > post-save command: > > /usr/lib64/ipa/certmonger/restart_httpd > > > > track: yes > > > > auto-renew: yes > > > > > > > > > > > > How can I add the certificate to /etc/httpd/alias? > > > > > > > Hi, > > > > > > for the record, the command getcert list that you > supplied > > shows > > > the > > > certificates in /etc/httpd/alias that are tracked by > > certmonger. > > > If you > > > want to display all the certificates contained in > > /etc/httpd/alias > > > (whether tracked or not), then you may want to use > > certutil -L -d > > > /etc/httpd/alias instead. > > > > > > If ipaCert is missing, you can export ipaCert > certificate from > > > another > > > master, then import it to your server. > > > > > > On a master containing the cert: > > > # certutil -d /etc/httpd/alias -L -n 'ipaCert' -a > > > > /tmp/newRAcert.crt > > > > > > Then copy the file /tmp/newRAcert.crt to your server and > > import > > > the cert: > > > # certutil -d /etc/httpd/alias -A -n 'ipaCert' -a -i > > > /tmp/newRAcert.crt > > > -t u,u,u > > > > > > And finally you need to tell certmonger to monitor the > > cert using > > > getcert start-tracking. > > > > > > Hope this helps, > > > Flo. > > > > > > > Thanks fo ryour support. > > > > Regards > > > > Bertrand > > > > > > > > > > > > > > > > > > Hi, > > > > > > Florence, thanks for your help. > > > I was able to import correctly ipaCert with your commands. > > > Now it seems that I also have an issue on one server with > > > "subsystemCert cert-pki-ca" in /etc/pki/pki-tomcat/alias > as I get > > > below error when pki-tomcat try to start > > > > > > > > > LdapJssSSLSocket set client auth cert nickname subsystemCert > > cert-pki-ca > > > Could not connect to LDAP server host sdkipa03.XX.YY > port 636 > > Error > > > netscape.ldap.LDAPException: IO Error creating JSS SSL > Socket ( > > > -1) > > > > > > > > > Is there a way to restore a correct "subsystemCert > cert-pki-ca"? > > > > > > Regards > > > Bertrand > > > > > > Hello, > > > > > > I am still stuck with my IPA server. > > > I have issues on both servers. > > > On server1, below certificate is not renewed properly > > > certutil -L -d /etc/httpd/alias/ -n "ipaCert" > > > > > > and on server 2 this is this certificate: > > > certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "Server-Cert > > cert-pki-ca" > > > > > > Could you provide me with the correct syntax with start-tracking > > command. > > > I tried to laucnh this command but my certificat remains in > > > "NEWLY_ADDED_NEED_KEYINFO_READ_PIN" state. > > > Here is the comnd I use: > > > getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d > > > /var/lib/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -B > > > /usr/lib64/ipa/certmonger/stop_pkicad -C > > > '/usr/lib64/ipa/certmonger/renew_ca_cert "Server-Cert > cert-pki-ca"' -T > > > "Server-Cert cert-pki-ca" -P '20160614000000' > > > > > Hi Bertrand, > > > > to get the right command, you can check on a system where the > > certificate is properly monitored, this will show you the right > > parameters: > > $ sudo getcert list -n ipaCert > > Number of certificates and requests being tracked: 8. > > Request ID '20161122095344': > > [..] key pair storage: > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > [...] > > CA: dogtag-ipa-ca-renew-agent > > [...] > > pre-save command: > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > > [...] > > > > The relevant fields are NSSDB location, pinfile, nickname, CA, > pre and > > post-save commands. So in order to monitor ipaCert, you will > need to use > > $ sudo getcert start-tracking -d /etc/httpd/alias -n ipaCert \ > > -p /etc/httpd/alias/pwdfile.txt \ > > -c dogtag-ipa-ca-renew-agent \ > > -B /usr/lib64/ipa/certmonger/renew_ra_cert_pre \ > > -C /usr/lib64/ipa/certmonger/renew_ra_cert > > > > HTH, > > Flo. > > > > > Thanks by advance for your help. > > > > > > Regards > > > Bertrand > > > > Hello Florence, > > > > Thanks for your reply. > > Before doing any mistakes, I just need some explanations as I > think I do > > not well understand how it should work. > > > > Do all the certificate need to be track by certmonger on all > servers or > > they should only be tracked on one server and FreeIPA will update them > > on other servers? > > > > In my case I have below certicates outdated and not track on > "server 1": > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n > "auditSigningCert > > cert-pki-ca" > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "ocspSigningCert > > cert-pki-ca" > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "subsystemCert > > cert-pki-ca" > > > > They are tracked by certmonger and have been correctly renewed on > "server 2" > > Do I need to add them tracked by certmonger on "server 1"? > > If not, it means FreeIPA failed to update them? Should I delete and > > import them manually on server 2? > > > > If you need more details, do not hesitate to ask. > > > Hi Bertrand, > > The certificate tracking depends on the type of certificate and on the > server you're considering. For instance, if IPA includes a Certificate > Authority, then ipaCert will be present on all the IPA servers > (master/replicas) and tracked on all of them. The same ipaCert > certificate is used on all the replicas. On the renewal master, the > renewal operation actually renews the certificate and uploads the cert > on LDAP, but on the other replicas the operation consists in > downloading > the new certificate from LDAP. > > The HTTP and LDAP server certificates are present and tracked on all > the > IPA servers, but they are different on each server (you can see that > the > Subject of the certificate contains the hostname). They can be renewed > independently on each IPA server. > > The certificates used by Dogtag (the component providing the > Certificate > System) are present and tracked only on the IPA servers where the CA > was > setup (for instance if you installed a replica with --setup-ca or if > you > ran ipa-ca-install later on). The same certificates are used on all > replicas containing a CA instance. > They are: 'ocspSigningCert cert-pki-ca', 'subsystemCert cert-pki-ca', > 'caSigningCert cert-pki-ca' and 'Server-Cert cert-pki-ca'. > The renewal operation renews them on the renewal master and uploads > them > in LDAP, but just downloads them from LDAP on the other servers. > > In your example, if server1 also contains a CA instance then it should > also track the above certs. > > You can find the renewal master with the following ldapsearch command: > $ ldapsearch -h localhost -p 389 -D 'cn=Directory Manager' -w password > -b "cn=masters,cn=ipa,cn=etc,$BASEDN" -LLL > '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn > dn: cn=CA,cn=ipaserver.fqdn,cn=masters,cn=ipa,cn=etc,$BASEDN > > In this case the renewal master is ipaserver.fqdn > > Hope this clarifies, > Flo. > > > Regards > > Bertrand > > > > > > > > From abokovoy at redhat.com Wed Nov 23 07:52:38 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 23 Nov 2016 09:52:38 +0200 Subject: [Freeipa-users] Samba in IPA / AD trust, best practise In-Reply-To: <1109983165.948187.1479885888068.JavaMail.zimbra@casalogic.dk> References: <1109983165.948187.1479885888068.JavaMail.zimbra@casalogic.dk> Message-ID: <20161123075238.6s2piebesavb3lug@redhat.com> On ke, 23 marras 2016, Troels Hansen wrote: >Hi there > >I'm having a bit of a dilemma. I'm going to set up a Samba in a IPA 4.4 / AD trust, and was wondering what the official or best practise method of joining the Samba server is: > >I see two methods: >- The one from http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA using wbclient. >- A second one where I use ipasam > >I was wondering which is actually the officially best practise as it >seems documentation states wbclient, but samba configured on IPA server >uses ipasam? You are trying to conflate two different configurations into a single one, this is not going to work, no wonder. IPA master uses ipasam. Along other features, ipasam stores information about trusted domains (ldapsam doesn't do that). IPA client running Samba server currently can only be configured with the way described in the wiki, with SSSD-provided libwbclient replacement. It has own limitations, namely lack of NTLMSSP (password-based) support. If you need to have Samba file server setup for the trust case, you either give up password-based access completely and go with the wiki-described way where only Kerberos-based access would work, or you'd dedicate one IPA master to be a file server, run ipa-adtrust-install on it and get a machine with ipasam configuration that will be able to check passwords with NTLMSSP. The downside is that it is a fully-blown IPA master, running 389-ds and MIT Kerberos on it. -- / Alexander Bokovoy From th at casalogic.dk Wed Nov 23 08:02:58 2016 From: th at casalogic.dk (Troels Hansen) Date: Wed, 23 Nov 2016 09:02:58 +0100 (CET) Subject: [Freeipa-users] Samba in IPA / AD trust, best practise In-Reply-To: <20161123075238.6s2piebesavb3lug@redhat.com> References: <1109983165.948187.1479885888068.JavaMail.zimbra@casalogic.dk> <20161123075238.6s2piebesavb3lug@redhat.com> Message-ID: <271115186.949092.1479888178111.JavaMail.zimbra@casalogic.dk> ----- On Nov 23, 2016, at 8:52 AM, Alexander Bokovoy abokovoy at redhat.com wrote: > IPA client running Samba server currently can only be configured with > the way described in the wiki, with SSSD-provided libwbclient > replacement. It has own limitations, namely lack of NTLMSSP > (password-based) support. Hmm, I have set up a "normal" IPA client, running Samba, using ipasam on multiple occations, so I know for sure that it works, althoug I haven't tested it in a AD trust environment. From abokovoy at redhat.com Wed Nov 23 08:17:51 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 23 Nov 2016 10:17:51 +0200 Subject: [Freeipa-users] Samba in IPA / AD trust, best practise In-Reply-To: <271115186.949092.1479888178111.JavaMail.zimbra@casalogic.dk> References: <1109983165.948187.1479885888068.JavaMail.zimbra@casalogic.dk> <20161123075238.6s2piebesavb3lug@redhat.com> <271115186.949092.1479888178111.JavaMail.zimbra@casalogic.dk> Message-ID: <20161123081751.3s5np47ntu75262k@redhat.com> On ke, 23 marras 2016, Troels Hansen wrote: > > >----- On Nov 23, 2016, at 8:52 AM, Alexander Bokovoy abokovoy at redhat.com wrote: > >> IPA client running Samba server currently can only be configured with >> the way described in the wiki, with SSSD-provided libwbclient >> replacement. It has own limitations, namely lack of NTLMSSP >> (password-based) support. > >Hmm, I have set up a "normal" IPA client, running Samba, using ipasam >on multiple occations, so I know for sure that it works, althoug I >haven't tested it in a AD trust environment. Then you know how to set it up. It is not something we support out of the box. -- / Alexander Bokovoy From mbasti at redhat.com Wed Nov 23 08:28:33 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Nov 2016 09:28:33 +0100 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: <97e67d02-a736-239e-0d65-5ce551454a1f@mdevsys.com> References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> <97e67d02-a736-239e-0d65-5ce551454a1f@mdevsys.com> Message-ID: <2837abb4-3605-1946-e752-a09b289439c5@redhat.com> On 23.11.2016 03:48, TomK wrote: > On 11/22/2016 10:22 AM, Martin Basti wrote: >> >> >> On 22.11.2016 13:57, TomK wrote: >>> On 11/22/2016 2:59 AM, Martin Basti wrote: >>>> Hey, >>>> >>>> >>>> On 22.11.2016 06:33, TomK wrote: >>>>> Hey Guy's, >>>>> >>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 >>>>> over to >>>>> my dual Free IPA server. The Free IPA servers are authoritative for >>>>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>>>> and forwards dom.abc.xyz. >>>> Do you have configured proper zone delegation for subdomain >>>> dom.abc.xyz? >>>> Proper NS and glue records >>>> http://www.zytrax.com/books/dns/ch9/delegate.html >>>> >>>>> >>>>> I cannot ping dom.abc.xyz. Everything else, including client >>>>> registrations, work fine. If Free IPA is authoritative on >>>>> dom.abc.xyz, should it not create DNS entries so the sub domain >>>>> can be >>>>> pinged as well? >>>> >>>> What do you mean by "ping"? >>>> >>>>> >>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>>>> and wanted to ask if you can point me to some materials online to >>>>> determine where can I permanently adjust the search to add >>>>> dom.abc.xyz >>>>> to the already present abc.xyz . I wasn't able to locate what I >>>>> needed in my searches. >>>>> >>>>> I'm using the latest v4. >>>> >>>> It depends on what are you using, probably you have NetworkManager >>>> there >>>> that is editing /etc/resolv.conf >>>> >>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >>>> >>>> >>>> >>>> >>>> Martin >>> >>> >>> I Uninstalled NetworkManager. Still changes. >>> ping dom.abc.com results in "ping: unknown host" >>> >>> I'll have a look at the first link, ty. >>> >> >> ping (ICMP protocol) and DNS system are different things, do you have >> hostname dom.abc.com with A record or it is a zone? >> >> with ping command hostname "dom.abc.com" is resolved to IP address >> first, do you have A record set for dom.abc.com in zone apex or what are >> you trying to achieve with ping command? >> >> for testing DNS try to use commands: dig, host, nslookup >> >> Martin >> > > Apologize for the long reply but it should give some background on > what it is that I'm doing. > > 1) dom.abc.com is a zone. There is no A record for dom.abc.com in > FreeIPA (Confirmed by Petr). I get the point Petr Spacek pointed out > in his comment as well. What should it really point too? ( I kind of > answer this question below so please read on. ) Where I'm getting > this from is that in Windows Server 2012 abc.com returns the IP of any > of the participating AD / DNS servers within the cluster (The two > Windows Server 2012 are a combined clustered AD + DNS servers.). > Being able to resolve abc.xyz is handy. During a lookup, I can get a > list of all the IP's associated with that domain which would indicate > all the DNS + AD servers online under that domain or serving that domain: > > > # nslookup abc.xyz > Server: 192.168.0.3 > Address: 192.168.0.3#53 > > Name: abc.xyz > Address: 192.168.0.3 > Name: abc.xyz > Address: 192.168.0.1 > Name: abc.xyz > Address: 192.168.0.2 > # > > Again, where this is handy is when configuring sssd.conf for example > or other apps for that matter. I can just point the app to > authenticate against the domain and I have my redundancy solved. > Windows Server 2012 does it, but FreeIPA didn't, so I threw the > question out there. IPA uses SRV records heavily, all IPA related services have SRV records, SSSD uses SRV records of IPA, client should use SRV record to connect to the right service (or URI record - will be in next IPA). SRV records work for IPA locations mechanism, we cannot achieve this with pure A records. > > Delegation from this Windows DNS works as expected. Any lookup from > dom.abc.xyz is forwarded too and handled by FreeIPA servers. Tested > this out. No issue with this. > > I did see earlier that there is no A record for dom.abc.xyz in > FreeIPA. My reasons for asking if there was an IP on the subdomain in > FreeIPA were above but the missing IP on the subdomain isn't a major > issue for me. Things are working without dom.abc.xyz resolving to an > IP. What I was hoping for is to have a VIP for the IPA servers and > one for the Windows Server 2012 DNS Cluster in /etc/resolv.conf. (I > have the VIP for the windows server). One forwarding to the other for > a given domain. This is all for testing a) redundancy, b) forwarding, > a) authentication . > > IE: > > # cat /etc/resolv.conf > search nix.mds.xyz mds.xyz > nameserver 192.168.0.3 <------------ Win Cluster DNS VIP > nameserver 192.168.0.4 <------------ IPA Cluster DNS VIP > > * Just what I want to achieve above. VIP 192.168.0.4 doesn't exist on > my cluster yet. I'm looking to integrate ucarp with the above IPA > servers. > > > 2) More to the topic of my second question however, is that > /etc/resolv.conf, on the IPA servers themselves, get's rewritten on > restart. Would like to know by what if I already uninstalled > NetworkManager? When I configured the FreeIPA server, I used: > > ipa-server-install --setup-dns --forwarder=192.168.0.3 -p "Hush!" -a > "Hush!" -r DOM.ABC.XYZ -n dom.abc.xyz --hostname ipa01.dom.abc.xyz > > Notice I used the VIP of the Windows Server 2012 Cluster when > installing FreeIPA. This is nice for redundancy. So the resolv.conf > ends up being: > > # cat /etc/resolv.conf > # Generated by NetworkManager > search abc.xyz > nameserver 192.168.0.3 > nameserver 123.123.123.1 > nameserver 123.123.123.2 > > Then I add: > > search dom.abc.xyz abc.xyz > > but it changes back to search abc.xyz (the Windows Server 2012 DNS). > This all works, except for the above minor items, and I can resolve > anything over this network. ( Thinking this is fine because the > forward is on the subdomain. I haven't had issues with forwarding > through this setup. ) > > # cat /etc/resolv.conf > # Generated by NetworkManager > search abc.xyz > nameserver 192.168.0.3 > nameserver 123.123.123.1 > nameserver 123.123.123.2 > > But NetworkManager is not installed on these IPA servers. I've > removed it earlier: > > # rpm -aq|grep -i NetworkManager > # > > Is FreeIPA replacing /etc/resolv.conf with a copy it keeps elsewhere? On servers with DNS /etc/resolv.conf should point to 127.0.0.1 and ::1, and global or per server dns forwarders should be configured instead Have you properly stopped NetworkManager using systemctl stop and systemctl disable ? In case you just removed rpm files service can still work. I recommend to update network manager config, not to remove it :) As last resort way, you can set immutable bit to resolv.conf if something is still changing your resolv.conf file > > 3) After running: > > ipa-client-install --mkhomedir --enable-dns-updates > > on a new host, the hostname of the new host doesn't resolve for a few > minutes. How do I make this instantaneous? (Other then that, > autodiscovery of the IPA servers is excellent!). Before installing > the IPA Client, the new hosts /etc/resolv.conf file looks like this: > > # cat /etc/resolv.conf > search abc.xyz > nameserver 192.168.0.3 > nameserver 123.123.123.1 > nameserver 123.123.123.2 > > I did dig, host, nslookup earlier. Verified all except for the items > I'm inquiring about. > That weird, because ipa-client-install creates A records directly to DNS server using nsupdate, so it should be accessible instantly. Do you have any caching DNS servers? Martin From jhrozek at redhat.com Wed Nov 23 08:58:51 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 23 Nov 2016 09:58:51 +0100 Subject: [Freeipa-users] AD Trust users not resolving on clients: ipa_get_*_acct request failed In-Reply-To: <4285203D-558D-4926-BE25-993C460601A3@unimelb.edu.au> References: <4285203D-558D-4926-BE25-993C460601A3@unimelb.edu.au> Message-ID: <20161123085851.a6gwjg7iyzsx2lqj@hendrix> On Wed, Nov 23, 2016 at 05:58:58PM +1100, Robert Sturrock wrote: > Hi All. > > I?m having a problem getting trust users to resolve on *any* IPA client (this _was_ working well and I?m not sure what?s changed that may have caused it to start failing - although we have recently updated to IPA 4.4, plus IPA DNS enabled with delegation of ipa.example.com). > > Whenever I try to lookup a trust user on a client (Ubuntu 16.04 with sssd-1.13.4-1ubuntu1.1) I see: > > # id username at example.com > id: ?username at example.com': no such user > > The error message block in the sssd/domain log is: > > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_group_dn_list] (0x0040): find_domain_by_object_name failed. The error happens here. Too bad we don't print the names of the group that failed the find_domain_by_object_name() but I would guess a supplemetary name is qualified with a domain that the client doesn't know for some reason. The only suggestion I have is to run "id" for this user on the server and check the domains of the supplementary groups that are returned. Then check if the domains are expected. You can also run ldbsearch on the client cache with objectclass=subdomain to check which trusted domains the client knows about and whether they match the domains of the supplementary groups on the server. (This wouldn't fix the issue of course, but maybe help us understand better where the error really is..) Do you maybe use some non-default configuration on the server that strips the domain names from the qualified name? > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): get_group_dn_list failed. > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_done] (0x4000): releasing operation connection > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [12]: Cannot allocate memory. > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,12,Out of memory > > > A more complete log is below. > > The domain users resolve fine on each of the three IPA servers (all RHEL7 with ipa-server-4.4.0-12.el7.x86_64). > > IPA domain is ipa.example.com. AD domain is example.com. > > I have looked at https://fedorahosted.org/sssd/wiki/Troubleshooting, but no particular ideas are coming from that, so I guess I?m after some hints about what to check or any further tests to try. > > Regards, > > Robert. > > > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_dispatch] (0x4000): dbus conn: 0xfd8480 > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_dispatch] (0x4000): Dispatching. > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.dataprovider.getAccountInfo on path /org/freedesktop/sssd/dataprovider > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for [0x1001][FAST BE_REQ_USER][1][name=mib] > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [be_req_set_domain] (0x0400): Changing request domain from [ipa.example.com] to [example.com] > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaUserOverride)(uid=mib))]. > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_print_server] (0x2000): Searching 172.25.180.53 > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaUserOverride)(uid=mib))][cn=Default Trust View,cn=views,cn=accounts,dc=ipa,dc=example,dc=com]. > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 21 > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_op_add] (0x2000): New operation 21 timeout 6 > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfd76d0], connected[1], ops[0xff6420], ldap[0xfded70] > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_op_destructor] (0x2000): Operation 21 finished > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaUserOverride)(uid=mib))]. > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 22 > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_op_add] (0x2000): New operation 22 timeout 6 > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfd76d0], connected[1], ops[0xff9310], ldap[0xfded70] > (Wed Nov 23 17:24:03 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfd76d0], connected[1], ops[0xff9310], ldap[0xfded70] > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Success(0), (null). > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_op_destructor] (0x2000): Operation 22 finished > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [add_v1_user_data] (0x4000): BER tag is [48] > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Found new sequence. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [objectSIDString]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [userPrincipalName]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [adAccountExpires]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [adUserAccountControl]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [mail]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalDN]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_extra_attrs] (0x4000): Extra attribute [originalMemberOf]. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff88e0 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff89a0 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff88e0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff89a0 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff88e0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff7530 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff75f0 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff7530 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff75f0 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff7530 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff72a0 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff7360 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff72a0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff7360 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff72a0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff72a0 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff7360 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff72a0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff7360 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff72a0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff7460 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff7520 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff7460 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff7520 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff7460 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff7460 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff7520 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff7460 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff7520 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff7460 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff75d0 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016050 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff75d0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016050 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff75d0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0xff72a0 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0xff7360 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0xff72a0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0xff7360 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0xff72a0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1016050 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016110 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x1016050 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016110 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x1016050 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1016050 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016110 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x1016050 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016110 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x1016050 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1016150 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016210 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x1016150 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016210 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x1016150 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1016210 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10162d0 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x1016210 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x10162d0 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x1016210 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1016150 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016210 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x1016150 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016210 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x1016150 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x10162b0 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1016370 > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Running timer event 0x10162b0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Destroying timer event 0x1016370 "ltdb_timeout" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ldb] (0x4000): Ending timer event 0x10162b0 "ltdb_callback" > > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sysdb_search_by_name] (0x0400): No such entry > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [get_group_dn_list] (0x0040): find_domain_by_object_name failed. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): get_group_dn_list failed. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [12]: Cannot allocate memory. > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_id_op_destroy] (0x4000): releasing operation connection > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,12,Out of memory > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: sh[0xfd76d0], connected[1], ops[(nil)], ldap[0xfded70] > (Wed Nov 23 17:24:04 2016) [sssd[be[ipa.example.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > > > -- > 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 sbose at redhat.com Wed Nov 23 11:07:12 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 23 Nov 2016 12:07:12 +0100 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <58346FA1.3050409@sonsorol.org> References: <58346622.1080504@sonsorol.org> <20161122154930.GA18779@p.Speedport_W_724V_Typ_A_05011603_00_009> <58346FA1.3050409@sonsorol.org> Message-ID: <20161123110712.GB18369@p.Speedport_W_724V_Typ_A_05011603_00_009> On Tue, Nov 22, 2016 at 11:17:37AM -0500, Chris Dagdigian wrote: > > > Sumit Bose wrote: > > Please send the full krb5_child.log with debug_level=10 in the > > [domain/...] section of sssd.conf. My current guess is the ticket > > validation fails. Which version of SSSD are you using? > > > > bye, > > Sumit > > > This is a CentOS 7 client running SSSD-1.13 > > Thank you. Lots of interesting info in this log. I've sanitized hostnames, > username and IP but that was it: > > ### log data below #### > > > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [main] (0x0400): > krb5_child started. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [unpack_buffer] > (0x1000): total buffer size: [158] > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [true] > enterprise principal [false] offline [false] UPN [username at COMPANY.ORG] > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [unpack_buffer] > (0x0100): ccname: [KEYRING:persistent:1843770609] old_ccname: > [KEYRING:persistent:1843770609] keytab: [/etc/krb5.keytab] > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [switch_creds] > (0x0200): Switch user to [1843770609][1843770609]. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [switch_creds] > (0x0200): Switch user to [0][0]. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [k5c_check_old_ccache] > (0x4000): Ccache_file is [KEYRING:persistent:1843770609] and is not active > and TGT is valid. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [k5c_precreate_ccache] > (0x4000): Recreating ccache > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [k5c_setup_fast] > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to > [host/usaeilvdip001.company-aws.org at company-idm.org] > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] > [find_principal_in_keytab] (0x4000): Trying to find principal > host/usaeilvdip001.company-aws.org at company-idm.org in keytab. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [match_principal] > (0x1000): Principal matched to the sample > (host/usaeilvdip001.company-aws.org at company-idm.org). > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [check_fast_ccache] > (0x0200): FAST TGT is still valid. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [become_user] > (0x0200): Trying to become user [1843770609][1843770609]. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [main] (0x2000): > Running as [1843770609][1843770609]. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [k5c_setup] (0x2000): > Running as [1843770609][1843770609]. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [set_lifetime_options] > (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [set_lifetime_options] > (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [main] (0x0400): Will > perform online auth > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [tgt_req_child] > (0x1000): Attempting to get a TGT > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] [get_and_save_tgt] > (0x0400): Attempting kinit for realm [COMPANY.ORG] > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899271: Getting > initial credentials for username at COMPANY.ORG > > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899337: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org > > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899368: Retrieving > host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/COMPANY.ORG\@COMPANY.ORG at X-CACHECONF: > from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: > -1765328243/Matching credential not found > > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899415: Sending > request (169 bytes) to COMPANY.ORG > > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899575: Resolving > hostname COMPANY.ORG > > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.900935: Initiating TCP > connection to stream 192.141.1.15:88 > > (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.987925: Sending TCP > request to stream 192.141.1.15:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75357: Received answer > (118 bytes) from stream 192.141.1.15:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75404: Terminating TCP > connection to stream 192.141.1.15:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75502: Response was > from master KDC > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75529: Received error > from KDC: -1765328316/Realm not local to KDC > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75544: Following > referral to realm NAFTA.COMPANY.ORG > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75559: FAST armor > ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75586: Retrieving > host/usaeilvdip001.company-aws.org at company-idm.org -> krb5_ccache_conf_data/fast_avail/krbtgt\/NAFTA.COMPANY.ORG\@NAFTA.COMPANY.ORG at X-CACHECONF: > from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: > -1765328243/Matching credential not found > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.75621: Sending request > (181 bytes) to NAFTA.COMPANY.ORG > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.81119: Resolving > hostname usetwadsfsmo03.nafta.COMPANY.ORG. > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.81947: Sending initial > UDP request to dgram 192.189.131.30:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.99200: Received answer > (205 bytes) from dgram 192.189.131.30:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.100064: Response was > not from master KDC > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.100103: Received error > from KDC: -1765328359/Additional pre-authentication required > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.100136: Processing > preauth types: 16, 15, 19, 2 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.100155: Selected etype > info: etype aes256-cts, salt "NAFTA.COMPANY.ORGusername", params "" > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.108691: AS key > obtained for encrypted timestamp: aes256-cts/3D3B > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.108766: Encrypted > timestamp (for 1479830568.478875): plain > 301AA011180F32303136313132323136303234385AA1050203074E9B, encrypted 133359586FCB362BF70E6CC90D509C68D6B19903CE0113AD37826E22256090F77B2B7F0BE410C1D7E72F890C437A77FE4BE1DA21848F6209 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.108787: Preauth module > encrypted_timestamp (2) (real) returned: 0/Success > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.108794: Produced > preauth for next request: 2 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.108829: Sending > request (260 bytes) to NAFTA.COMPANY.ORG > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.114751: Resolving > hostname usetwadsfsmo03.nafta.COMPANY.ORG. > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.115601: Sending > initial UDP request to dgram 192.189.131.30:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.133353: Received > answer (108 bytes) from dgram 192.189.131.30:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.134326: Response was > not from master KDC > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.134360: Received error > from KDC: -1765328332/Response too big for UDP, retry with TCP > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.134370: Request or > response is too big for UDP; retrying with TCP > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.134379: Sending > request (260 bytes) to NAFTA.COMPANY.ORG (tcp only) > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.137246: Resolving > hostname friawadsgc12.nafta.COMPANY.ORG. > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.138084: Initiating TCP > connection to stream 192.141.1.52:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.224054: Sending TCP > request to stream 192.141.1.52:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.311440: Received > answer (2178 bytes) from stream 192.141.1.52:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.311483: Terminating > TCP connection to stream 192.141.1.52:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312325: Response was > not from master KDC > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312369: Processing > preauth types: 19 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312381: Selected etype > info: etype aes256-cts, salt "NAFTA.COMPANY.ORGusername", params "" > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312390: Produced > preauth for next request: (empty) > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312401: AS key > determined by preauth: aes256-cts/3D3B > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312459: Decrypted AS > reply; session key is: aes256-cts/43A1 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312498: FAST > negotiation: unavailable > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_krb5_expire_callback_func] (0x2000): exp_time: [3966060] > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [validate_tgt] > (0x2000): Keytab entry with the realm of the credential not found in keytab. > Using the last entry. > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312579: Retrieving > host/usaeilvdip001.company-aws.org at company-idm.org from > MEMORY:/etc/krb5.keytab (vno 0, enctype 0) with result: 0/Success > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312588: Resolving > unique ccache of type MEMORY > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312602: Initializing > MEMORY:Fnv4hCg with default princ username at NAFTA.COMPANY.ORG > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312621: Storing > username at NAFTA.COMPANY.ORG -> krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG in > MEMORY:Fnv4hCg > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312642: Getting > credentials username at NAFTA.COMPANY.ORG -> > host/usaeilvdip001.company-aws.org at company-idm.org using ccache > MEMORY:Fnv4hCg > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312668: Retrieving > username at NAFTA.COMPANY.ORG -> > host/usaeilvdip001.company-aws.org at company-idm.org from MEMORY:Fnv4hCg with > result: -1765328243/Matching credential not found > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312683: Retrieving > username at NAFTA.COMPANY.ORG -> krbtgt/company-idm.org at company-idm.org from > MEMORY:Fnv4hCg with result: -1765328243/Matching credential not found > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312698: Retrieving > username at NAFTA.COMPANY.ORG -> krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG > from MEMORY:Fnv4hCg with result: 0/Success > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312706: Starting with > TGT for client realm: username at NAFTA.COMPANY.ORG -> > krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312721: Retrieving > username at NAFTA.COMPANY.ORG -> krbtgt/company-idm.org at company-idm.org from > MEMORY:Fnv4hCg with result: -1765328243/Matching credential not found > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312729: Requesting TGT > krbtgt/company-idm.org at NAFTA.COMPANY.ORG using TGT > krbtgt/NAFTA.COMPANY.ORG at NAFTA.COMPANY.ORG > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312747: Generated > subkey for TGS request: aes256-cts/57A1 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312787: etypes > requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, > camellia128-cts, camellia256-cts > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312840: Encoding > request body and padata into FAST request > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.312894: Sending > request (2313 bytes) to NAFTA.COMPANY.ORG > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.318783: Resolving > hostname friawadsgc02.nafta.COMPANY.ORG. > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.319777: Sending > initial UDP request to dgram 192.141.1.11:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.406882: Received > answer (105 bytes) from dgram 192.141.1.11:88 > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.407810: Response was > not from master KDC > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.407847: TGS request > result: -1765328377/Server not found in Kerberos database > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] > [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830568.407869: Destroying > ccache MEMORY:Fnv4hCg > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [validate_tgt] > (0x0020): TGT failed verification using key for > [host/usaeilvdip001.company-aws.org at company-idm.org]. ok, it is the ticket validation which fails. You can get around this for testing by setting 'krb5_validate = false' in the [domain/...] section of sssd.conf. But please use this only for testing because this error indicates that there are issues in your setup/configuration. But your host principal host/usaeilvdip001.company-aws.org at company-idm.org looks odd as well. Why is the host in the AD DNS domain, this calls for trouble. Additionally I wonder why the realm part '@company-idm.org' was created in lower-case while joining the IPA this should be created upper-case. Or is this all due to sanitation? > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [get_and_save_tgt] > (0x0020): 1242: [-1765328377][Server not found in Kerberos database] > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [map_krb5_error] > (0x0020): 1303: [-1765328377][Server not found in Kerberos database] > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [k5c_send_data] > (0x0200): Received error code 1432158209 > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [pack_response_packet] > (0x2000): response packet size: [20] > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [k5c_send_data] > (0x4000): Response sent. > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [main] (0x0400): > krb5_child completed successfully > [root at usaeilvdip001 sssd]# > > The logs indicate that the user actually come from the member domain in the forest: username at NAFTA.COMPANY.ORG. But the [capath] section you added to krb5.conf only contains the forest root. > COMPANY-AWS.ORG = { > > COMPANY-IDM.ORG = COMPANY-AWS.ORG > > } > > COMPANY-IDM.ORG = { > > COMPANY-AWS.ORG = COMPANY-AWS.ORG > > } > Please try to add the member domain as well. The result might look like this: (assuming COMPANY-AWS is the forest root, NAFTA is the member domain and COMPANY-IDM is the IPA domain) COMPANY-AWS.ORG = { COMPANY-IDM.ORG = COMPANY-AWS.ORG } COMPANY-IDM.ORG = { COMPANY-AWS.ORG = COMPANY-AWS.ORG NAFTA.COMPANY.ORG = COMPANY-AWS.ORG } NAFTA.COMPANY.ORG = { COMPANY-IDM.ORG = COMPANY-AWS.ORG } You can test the configuration independent of SSSD by calling kdestroy -A kinit username at NAFTA.COMPANY.ORG kvno host/usaeilvdip001.company-aws.org at COMPANY-IDM.ORG If kvno returns an error please rerun as KRB5_TRACE=/dev/stdout kvno host/usaeilvdip001.company-aws.org at COMPANY-IDM.ORG and send the output. HTH bye, Sumit From dag at sonsorol.org Wed Nov 23 12:38:49 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 23 Nov 2016 07:38:49 -0500 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <20161123110712.GB18369@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <58346622.1080504@sonsorol.org> <20161122154930.GA18779@p.Speedport_W_724V_Typ_A_05011603_00_009> <58346FA1.3050409@sonsorol.org> <20161123110712.GB18369@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <58358DD9.7000906@sonsorol.org> < huge log sample deleted > Sumit Bose wrote: > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [validate_tgt] > (0x0020): TGT failed verification using key for > [host/usaeilvdip001.company-aws.org at company-idm.org]. > > ok, it is the ticket validation which fails. You can get around this for > testing by setting 'krb5_validate = false' in the [domain/...] section > of sssd.conf. But please use this only for testing because this error > indicates that there are issues in your setup/configuration. Much appreciated. Will test today. > But your host principal > host/usaeilvdip001.company-aws.org at company-idm.org looks odd as well. > Why is the host in the AD DNS domain, this calls for trouble. > Additionally I wonder why the realm part '@company-idm.org' was created > in lower-case while joining the IPA this should be created upper-case. > Or is this all due to sanitation? { Capitalization problem was a sanitation error } At the time we set up the IPA environment the only AD domain we had administrative control over was already in use and could not easily be reconfigured to meet the best practices for having an IPA server sit in the same domain name and realm After reading the documentation and a lot of posts on redhat.com we decided that the IPA server would have to be in a completely new autonomous domain name, DNS zone and Kerberos realm. The IPA instructions (and ipa-client-install options) all seem to indicate that although not a best practice it is something that was supported although there is a loss of functionality to be expected. So we run servers as FQDN members of company-aws.org but they are IPA clients of company-ipa.org My understanding is that if we: 1. Bind a Linux IPA client to company-ipa.com 2. But configure the Linux client to have a hostname of client.company-aws.com .. then what we primarily lose is kerberos related service functionality for logged-in users Since our core need was for AD password authentication and RBAC control over Linux hosts we decided to move forward with this odd config. Would be greatly interested if I'm way off base on use of totally autonomous IPA realms and domain names. >> (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [get_and_save_tgt] >> (0x0020): 1242: [-1765328377][Server not found in Kerberos database] >> (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [map_krb5_error] >> (0x0020): 1303: [-1765328377][Server not found in Kerberos database] >> (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [k5c_send_data] >> (0x0200): Received error code 1432158209 >> (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [pack_response_packet] >> (0x2000): response packet size: [20] >> (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [k5c_send_data] >> (0x4000): Response sent. >> (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [main] (0x0400): >> krb5_child completed successfully >> [root at usaeilvdip001 sssd]# >> >> > > The logs indicate that the user actually come from the member domain in > the forest: username at NAFTA.COMPANY.ORG. But the [capath] section you > added to krb5.conf only contains the forest root. > >> COMPANY-AWS.ORG = { >> >> COMPANY-IDM.ORG = COMPANY-AWS.ORG >> >> } >> >> COMPANY-IDM.ORG = { >> >> COMPANY-AWS.ORG = COMPANY-AWS.ORG >> >> } >> > > Please try to add the member domain as well. The result might look like > this: (assuming COMPANY-AWS is the forest root, NAFTA is the member > domain and COMPANY-IDM is the IPA domain) > > COMPANY-AWS.ORG = { > > COMPANY-IDM.ORG = COMPANY-AWS.ORG > > } > > COMPANY-IDM.ORG = { > > COMPANY-AWS.ORG = COMPANY-AWS.ORG > NAFTA.COMPANY.ORG = COMPANY-AWS.ORG > } > > NAFTA.COMPANY.ORG = { > COMPANY-IDM.ORG = COMPANY-AWS.ORG > } Thank you. I don't think our Linux client picked up the CAPATH changes needed but I think the IPA server did the proper thing deep down in that include directory that is referenced at the top of sssd.com. Will check and verify. > You can test the configuration independent of SSSD by calling > > kdestroy -A > kinit username at NAFTA.COMPANY.ORG > kvno host/usaeilvdip001.company-aws.org at COMPANY-IDM.ORG > > If kvno returns an error please rerun as > > KRB5_TRACE=/dev/stdout kvno host/usaeilvdip001.company-aws.org at COMPANY-IDM.ORG > > and send the output. Again, thanks for the time, attention and helpful replies. > > HTH > > bye, > Sumit From sbose at redhat.com Wed Nov 23 13:18:08 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 23 Nov 2016 14:18:08 +0100 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <58358DD9.7000906@sonsorol.org> References: <58346622.1080504@sonsorol.org> <20161122154930.GA18779@p.Speedport_W_724V_Typ_A_05011603_00_009> <58346FA1.3050409@sonsorol.org> <20161123110712.GB18369@p.Speedport_W_724V_Typ_A_05011603_00_009> <58358DD9.7000906@sonsorol.org> Message-ID: <20161123131808.GF18369@p.Speedport_W_724V_Typ_A_05011603_00_009> On Wed, Nov 23, 2016 at 07:38:49AM -0500, Chris Dagdigian wrote: > > < huge log sample deleted > > > Sumit Bose wrote: > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [validate_tgt] > > (0x0020): TGT failed verification using key for > > [host/usaeilvdip001.company-aws.org at company-idm.org]. > > > > ok, it is the ticket validation which fails. You can get around this for > > testing by setting 'krb5_validate = false' in the [domain/...] section > > of sssd.conf. But please use this only for testing because this error > > indicates that there are issues in your setup/configuration. > > Much appreciated. Will test today. > > But your host principal > > host/usaeilvdip001.company-aws.org at company-idm.org looks odd as well. > > Why is the host in the AD DNS domain, this calls for trouble. > > Additionally I wonder why the realm part '@company-idm.org' was created > > in lower-case while joining the IPA this should be created upper-case. > > Or is this all due to sanitation? > > { Capitalization problem was a sanitation error } > > At the time we set up the IPA environment the only AD domain we had > administrative control over > was already in use and could not easily be reconfigured to meet the best > practices for having an > IPA server sit in the same domain name and realm > > After reading the documentation and a lot of posts on redhat.com we decided > that the IPA server > would have to be in a completely new autonomous domain name, DNS zone and > Kerberos realm. The > IPA instructions (and ipa-client-install options) all seem to indicate that > although not a best practice it > is something that was supported although there is a loss of functionality to > be expected. NO. It is the other way round. It is _not_ recommended and will not even work properly to use the same DNS domain for IPA and AD. Even worse with using the same realm for both, this cannot work at all. It is required to have a different realm name for the IPA domain and it is important to use a different DNS domain as well (a bit is possible with hosts in the same DNS domain but you loose functionality here). Where did you find the recommendation to user the same DNS domain and realm? bye, Sumit > > So we run servers as FQDN members of company-aws.org but they are IPA > clients of company-ipa.org > > My understanding is that if we: > > 1. Bind a Linux IPA client to company-ipa.com > 2. But configure the Linux client to have a hostname of > client.company-aws.com > > .. then what we primarily lose is kerberos related service functionality for > logged-in users > > Since our core need was for AD password authentication and RBAC control over > Linux hosts we > decided to move forward with this odd config. > > Would be greatly interested if I'm way off base on use of totally autonomous > IPA realms and domain names. > > > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [get_and_save_tgt] > > > (0x0020): 1242: [-1765328377][Server not found in Kerberos database] > > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [map_krb5_error] > > > (0x0020): 1303: [-1765328377][Server not found in Kerberos database] > > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [k5c_send_data] > > > (0x0200): Received error code 1432158209 > > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [pack_response_packet] > > > (0x2000): response packet size: [20] > > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [k5c_send_data] > > > (0x4000): Response sent. > > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369]]]] [main] (0x0400): > > > krb5_child completed successfully > > > [root at usaeilvdip001 sssd]# > > > > > > > > > > The logs indicate that the user actually come from the member domain in > > the forest: username at NAFTA.COMPANY.ORG. But the [capath] section you > > added to krb5.conf only contains the forest root. > > > > > COMPANY-AWS.ORG = { > > > > > > COMPANY-IDM.ORG = COMPANY-AWS.ORG > > > > > > } > > > > > > COMPANY-IDM.ORG = { > > > > > > COMPANY-AWS.ORG = COMPANY-AWS.ORG > > > > > > } > > > > > > > Please try to add the member domain as well. The result might look like > > this: (assuming COMPANY-AWS is the forest root, NAFTA is the member > > domain and COMPANY-IDM is the IPA domain) > > > > COMPANY-AWS.ORG = { > > > > COMPANY-IDM.ORG = COMPANY-AWS.ORG > > > > } > > > > COMPANY-IDM.ORG = { > > > > COMPANY-AWS.ORG = COMPANY-AWS.ORG > > NAFTA.COMPANY.ORG = COMPANY-AWS.ORG > > } > > > > NAFTA.COMPANY.ORG = { > > COMPANY-IDM.ORG = COMPANY-AWS.ORG > > } > > Thank you. I don't think our Linux client picked up the CAPATH changes > needed > but I think the IPA server did the proper thing deep down in that include > directory that > is referenced at the top of sssd.com. > > Will check and verify. > > > > You can test the configuration independent of SSSD by calling > > > > kdestroy -A > > kinit username at NAFTA.COMPANY.ORG > > kvno host/usaeilvdip001.company-aws.org at COMPANY-IDM.ORG > > > > If kvno returns an error please rerun as > > > > KRB5_TRACE=/dev/stdout kvno host/usaeilvdip001.company-aws.org at COMPANY-IDM.ORG > > > > and send the output. > > Again, thanks for the time, attention and helpful replies. > > > > > HTH > > > > bye, > > Sumit > From dag at sonsorol.org Wed Nov 23 13:25:52 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 23 Nov 2016 08:25:52 -0500 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <20161123131808.GF18369@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <58346622.1080504@sonsorol.org> <20161122154930.GA18779@p.Speedport_W_724V_Typ_A_05011603_00_009> <58346FA1.3050409@sonsorol.org> <20161123110712.GB18369@p.Speedport_W_724V_Typ_A_05011603_00_009> <58358DD9.7000906@sonsorol.org> <20161123131808.GF18369@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <583598E0.8090604@sonsorol.org> Sumit Bose wrote: > NO. It is the other way round. > > It is_not_ recommended and will not even work properly to use the same > DNS domain for IPA and AD. Even worse with using the same realm for > both, this cannot work at all. > > It is required to have a different realm name for the IPA domain and it > is important to use a different DNS domain as well (a bit is possible > with hosts in the same DNS domain but you loose functionality here). > > Where did you find the recommendation to user the same DNS domain and > realm? > Apologies I must have been unclear. What I was trying to say is that we are going for the "hosts in the different DNS domain" deployment scenario ... - We have unique domain name and realm for IPA: company-ipa.org - We use company-aws.org in AWS and have our own Active Directory servers for: company-aws.org - We want to use ipa-client to bind our servers to company-ipa.org but use DNS names from company-aws.org for operation Our end goal: - We have many external AD forests we are linking to company-ipa.org one at a time - End goal: operate hosts with DNS name "company-aws.org" as IPA clients of "company-ipa.org" using AD logins coming from the external trusts -Chris From bretif at phosphore.eu Wed Nov 23 13:25:53 2016 From: bretif at phosphore.eu (Bertrand =?utf-8?Q?R=C3=A9tif?=) Date: Wed, 23 Nov 2016 14:25:53 +0100 (CET) Subject: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue In-Reply-To: <3b56f25b-7645-b861-e2b6-f0a02a26e32c@redhat.com> References: <1383346498.1295916.1476825748599.JavaMail.zimbra@phosphore.eu> <835252359.90240.1477410669922.JavaMail.zimbra@phosphore.eu> <1898060535.461337.1479805632262.JavaMail.zimbra@phosphore.eu> <1349958374.477173.1479811804586.JavaMail.zimbra@phosphore.eu> <1673063951.535652.1479834378886.JavaMail.zimbra@phosphore.eu> <3b56f25b-7645-b861-e2b6-f0a02a26e32c@redhat.com> Message-ID: <307643568.635481.1479907553069.JavaMail.zimbra@phosphore.eu> ----- Mail original ----- > De: "Florence Blanc-Renaud" > ?: "Bertrand R?tif" , freeipa-users at redhat.com > Envoy?: Mercredi 23 Novembre 2016 08:49:28 > Objet: Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue > On 11/22/2016 06:06 PM, Bertrand R?tif wrote: > > Hi Florence, > > > > Thanks for clarification. > > Your explanation was very clear and I better understand > > > > Now my issue is that I need to start tracking "auditSigningCert > > cert-pki-ca", "ocspSigningCert cert-pki-ca" and "subsystemCert > > cert-pki-ca" on a server. > > > > I take a look on another server where they are properly tracked. However > > getcert list return me "pin set" and not a "pinfile" as described in > > your mail. > > In "/etc/pki/pki-tomcat/alias" I do not see any pwdfile.txt file, so my > > question is where do I get the PIN? > > > Hi Bertrand, > With IPA 4.2.0 I believe that the pin is stored in > /var/lib/pki/pki-tomcat/conf/password.conf, in the 'internal' field: > $ grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf > internal=0123456789101 > HTH, > Flo > > Once again, thanks for your support, I tried to fix this issue for days! > > > > Regards > > Bertrand > > > > > > -- > > Bertrand R?tif > > Phosphore Services Informatiques - http://www.phosphore.eu > > Tel: 04 66 51 87 73 / Mob: 06 61 87 03 30 / Fax: 09 72 12 61 44 > > > > ------------------------------------------------------------------------ > > > > *De: *"Florence Blanc-Renaud" > > *?: *"Bertrand R?tif" , freeipa-users at redhat.com > > *Envoy?: *Mardi 22 Novembre 2016 13:17:34 > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > pki-tomcat issue > > > > On 11/22/2016 11:50 AM, Bertrand R?tif wrote: > > > > > > > > > *De: *"Florence Blanc-Renaud" > > > *?: *"Bertrand R?tif" , > > freeipa-users at redhat.com > > > *Envoy?: *Mardi 22 Novembre 2016 11:33:45 > > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > > pki-tomcat issue > > > > > > On 11/22/2016 10:07 AM, Bertrand R?tif wrote: > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > *De: *"Bertrand R?tif" > > > > *?: *freeipa-users at redhat.com > > > > *Envoy?: *Mardi 25 Octobre 2016 17:51:09 > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > certificate. > > > > pki-tomcat issue > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > *De: *"Florence Blanc-Renaud" > > > > *?: *"Bertrand R?tif" , > > > > freeipa-users at redhat.com > > > > *Envoy?: *Jeudi 20 Octobre 2016 18:45:21 > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > certificate. > > > > pki-tomcat issue > > > > > > > > On 10/19/2016 08:18 PM, Bertrand R?tif wrote: > > > > > *De: *"Bertrand R?tif" > > > > > > > > > > *?: *freeipa-users at redhat.com > > > > > *Envoy?: *Mercredi 19 Octobre 2016 15:42:07 > > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > > certificate. > > > > > pki-tomcat issue > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > *De: *"Rob Crittenden" > > > > > *?: *"Bertrand R?tif" , > > > > > freeipa-users at redhat.com > > > > > *Envoy?: *Mercredi 19 Octobre 2016 15:30:14 > > > > > *Objet: *Re: [Freeipa-users] Impossible to > > renew > > > > certificate. > > > > > pki-tomcat issue > > > > > > > > > > Bertrand R?tif wrote: > > > > > >> De: "Martin Babinsky" > > > > > >> ?: freeipa-users at redhat.com > > > > > >> Envoy?: Mercredi 19 Octobre 2016 08:45:49 > > > > > >> Objet: Re: [Freeipa-users] Impossible > > to renew > > > > certificate. > > > > > pki-tomcat issue > > > > > > > > > > > >> On 10/18/2016 11:22 PM, Bertrand R?tif > > wrote: > > > > > >>> Hello, > > > > > >>> > > > > > >>> I had an issue with pki-tomcat. > > > > > >>> I had serveral certificate that was > > expired and > > > > pki-tomcat > > > > > did not start > > > > > >>> anymore. > > > > > >>> > > > > > >>> I set the dateon the server before > > certificate > > > > expiration > > > > > and then > > > > > >>> pki-tomcat starts properly. > > > > > >>> Then I try to resubmit the > > certificate, but > > > I get > > > > below error: > > > > > >>> "Profile caServerCert Not Found" > > > > > >>> > > > > > >>> Do you have any idea how I could fix > > this issue. > > > > > >>> > > > > > >>> Please find below output of commands: > > > > > >>> > > > > > >>> > > > > > >>> # getcert resubmit -i 20160108170324 > > > > > >>> > > > > > >>> # getcert list -i 20160108170324 > > > > > >>> Number of certificates and requests being > > > tracked: 7. > > > > > >>> Request ID '20160108170324': > > > > > >>> status: MONITORING > > > > > >>> ca-error: Server at > > > > > >>> > > > > > > "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit" > > > > > replied: > > > > > >>> Profile caServerCert Not Found > > > > > >>> stuck: no > > > > > >>> key pair storage: > > > > > >>> > > > > > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > > >>> Certificate > > > DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > > >>> certificate: > > > > > >>> > > > > > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > > >>> Certificate DB' > > > > > >>> CA: dogtag-ipa-ca-renew-agent > > > > > >>> issuer: CN=Certificate > > Authority,O=A.SKINFRA.EU > > > > > >>> subject: CN=IPA RA,O=A.SKINFRA.EU > > > > > >>> expires: 2016-06-28 15:25:11 UTC > > > > > >>> key usage: > > > > > >>> > > > > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > > >>> eku: id-kp-serverAuth,id-kp-clientAuth > > > > > >>> pre-save command: > > > > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > > > >>> post-save command: > > > > /usr/lib64/ipa/certmonger/renew_ra_cert > > > > > >>> track: yes > > > > > >>> auto-renew: yes > > > > > >>> > > > > > >>> > > > > > >>> Thanksby advance for your help. > > > > > >>> Bertrand > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > > > > > > > >> Hi Betrand, > > > > > > > > > > > >> what version of FreeIPA and Dogtag are you > > > running? > > > > > > > > > > > >> Also perform the following search on > > the IPA > > > master > > > > and post > > > > > the result: > > > > > > > > > > > >> """ > > > > > >> ldapsearch -D "cn=Directory Manager" -W -b > > > > > >> 'ou=certificateProfiles,ou=ca,o=ipaca' > > > > > '(objectClass=certProfile)' > > > > > >> """ > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > Thanks for your reply. > > > > > > > > > > > > Here is version: > > > > > > - FreeIPA 4.2.0 > > > > > > - Centos 7.2 > > > > > > > > > > > > I have been able to fix the issue with > > "Profile > > > > caServerCert > > > > > Not Found" by editing > > > > /var/lib/pki/pki-tomcat/ca/conf/CS.cfg > > > > > > I replace below entry > > > > > > > > > > > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem" > > > > > > by > > > > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem" > > > > > > > > > > > > and then launch "ipa-server-upgrade" command > > > > > > I found this solution in this post: > > > > > > > > http://osdir.com/ml/freeipa-users/2016-03/msg00280.html > > > > > > > > > > > > Then I was able to renew my certificate. > > > > > > > > > > > > However I reboot my server to and pki-tomcat > > > do not > > > > start and > > > > > provide with a new erreor in > > > > /var/log/pki/pki-tomcat/ca/debug > > > > > > > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > CertUtils: > > > > > verifySystemCertByNickname() passed: > > > auditSigningCert > > > > cert-pki-ca > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > > SignedAuditEventFactory: create() > > > > > > > > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$ > > > > > > > > > System$][Outcome=Success][CertNickName=auditSigningCert > > > > > cert-pki-ca] CIMC certificate verification > > > > > > > > > > > > java.lang.Exception: > > SystemCertsVerification: > > > system > > > > certs > > > > > verification failure > > > > > > at > > > > > > > > > > > > > > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) > > > > > > at > > > > > > > > > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) > > > > > > at > > > > > > > > > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) > > > > > > at > > > > > > > > > > > > > > com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701) > > > > > > at > > > > > > > > > > > > com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148) > > > > > > at > > > com.netscape.certsrv.apps.CMS.startup(CMS.java:200) > > > > > > at > > > com.netscape.certsrv.apps.CMS.start(CMS.java:1602) > > > > > > at > > > > > > > > > > > > > > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) > > > > > > at > > > > > > javax.servlet.GenericServlet.init(GenericServlet.java:158) > > > > > > at > > > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > > > > > at > > > > > > > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > > > at > > > > > > > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > > > at > > > java.lang.reflect.Method.invoke(Method.java:606) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) > > > > > > at > > > > java.security.AccessController.doPrivileged(Native > > Method) > > > > > > at > > > > > > javax.security.auth.Subject.doAsPrivileged(Subject.java:536) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > > > > > > at > > > > java.security.AccessController.doPrivileged(Native > > Method) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > > > > > > at > > > > > > > > > > > > > > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > > > > > > at > > > > > > > > > > > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > > > > > > at > > > > java.util.concurrent.FutureTask.run(FutureTask.java:262) > > > > > > at > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > > > > at > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > > SignedAuditEventFactory: create() > > > > > > > > > > > > > > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] > > > > > self tests execution (see selftests.log > > for details) > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > > CMSEngine.shutdown() > > > > > > > > > > > > > > > > > > I am currently stuck here. > > > > > > Thanks a lot for your help. > > > > > > > > > > I'm guessing at least one of the CA subsystem > > > > certificates are > > > > > still > > > > > expired. Look at the "getcert list" output > > to see if > > > > there are any > > > > > expired certificates. > > > > > > > > > > rob > > > > > > > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > > > > > > > > > Hello Rob, > > > > > > > > > > I check on my 2 servers and no certificate is > > expired > > > > > > > > > > [root at sdkipa03 ~]# getcert list |grep expire > > > > > expires: 2018-06-22 22:02:26 UTC > > > > > expires: 2018-06-22 22:02:47 UTC > > > > > expires: 2034-07-09 15:24:34 UTC > > > > > expires: 2016-10-30 13:35:29 UTC > > > > > > > > > > [root at sdkipa01 conf]# getcert list |grep expire > > > > > expires: 2018-06-12 23:38:01 UTC > > > > > expires: 2018-06-12 23:37:41 UTC > > > > > expires: 2018-06-11 22:53:57 UTC > > > > > expires: 2018-06-11 22:55:50 UTC > > > > > expires: 2018-06-11 22:57:47 UTC > > > > > expires: 2034-07-09 15:24:34 UTC > > > > > expires: 2018-06-11 22:59:55 UTC > > > > > > > > > > I see that one certificate is in status: > > CA_UNREACHABLE, > > > > maybe I > > > > > reboot to soon my server... > > > > > > > > > > I continue to investigate > > > > > > > > > > Thanks for your help. > > > > > Bertrand > > > > > > > > > > I fix my previous issue. > > > > > Now I have an issue with a server. > > > > > This server can not start pki-tomcatd, I get this > > error in > > > > debug file: > > > > > "Error netscape.ldap.LDAPExceptio n: IO Error creating > > > JSS SSL > > > > Socket (-1)" > > > > > > > > > > After investigation i see that I do not have "ipaCert" > > > > certificat in > > > > > "/etc/httpd/alias" > > > > > cf below command: > > > > > > > > > > [root at sdkipa03 ~]# getcert list -d /etc/httpd/alias > > > > > Number of certificates and requests being tracked: 4. > > > > > Request ID '20141110133632': > > > > > status: MONITORING > > > > > stuck: no > > > > > 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=A.SKINFRA.EU > > > > > subject: CN=sdkipa03.skinfra.eu,O=A.SKINFRA.EU > > > > > expires: 2018-06-22 22:02:47 UTC > > > > > principal name: > > HTTP/sdkipa03.skinfra.eu at A.SKINFRA.EU > > > > > key usage: > > > > > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > > > pre-save command: > > > > > post-save command: > > > /usr/lib64/ipa/certmonger/restart_httpd > > > > > track: yes > > > > > auto-renew: yes > > > > > > > > > > > > > > > How can I add the certificate to /etc/httpd/alias? > > > > > > > > > Hi, > > > > > > > > for the record, the command getcert list that you > > supplied > > > shows > > > > the > > > > certificates in /etc/httpd/alias that are tracked by > > > certmonger. > > > > If you > > > > want to display all the certificates contained in > > > /etc/httpd/alias > > > > (whether tracked or not), then you may want to use > > > certutil -L -d > > > > /etc/httpd/alias instead. > > > > > > > > If ipaCert is missing, you can export ipaCert > > certificate from > > > > another > > > > master, then import it to your server. > > > > > > > > On a master containing the cert: > > > > # certutil -d /etc/httpd/alias -L -n 'ipaCert' -a > > > > > /tmp/newRAcert.crt > > > > > > > > Then copy the file /tmp/newRAcert.crt to your server and > > > import > > > > the cert: > > > > # certutil -d /etc/httpd/alias -A -n 'ipaCert' -a -i > > > > /tmp/newRAcert.crt > > > > -t u,u,u > > > > > > > > And finally you need to tell certmonger to monitor the > > > cert using > > > > getcert start-tracking. > > > > > > > > Hope this helps, > > > > Flo. > > > > > > > > > Thanks fo ryour support. > > > > > Regards > > > > > Bertrand > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > Florence, thanks for your help. > > > > I was able to import correctly ipaCert with your commands. > > > > Now it seems that I also have an issue on one server with > > > > "subsystemCert cert-pki-ca" in /etc/pki/pki-tomcat/alias > > as I get > > > > below error when pki-tomcat try to start > > > > > > > > > > > > LdapJssSSLSocket set client auth cert nickname subsystemCert > > > cert-pki-ca > > > > Could not connect to LDAP server host sdkipa03.XX.YY > > port 636 > > > Error > > > > netscape.ldap.LDAPException: IO Error creating JSS SSL > > Socket ( > > > > -1) > > > > > > > > > > > > Is there a way to restore a correct "subsystemCert > > cert-pki-ca"? > > > > > > > > Regards > > > > Bertrand > > > > > > > > Hello, > > > > > > > > I am still stuck with my IPA server. > > > > I have issues on both servers. > > > > On server1, below certificate is not renewed properly > > > > certutil -L -d /etc/httpd/alias/ -n "ipaCert" > > > > > > > > and on server 2 this is this certificate: > > > > certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "Server-Cert > > > cert-pki-ca" > > > > > > > > Could you provide me with the correct syntax with start-tracking > > > command. > > > > I tried to laucnh this command but my certificat remains in > > > > "NEWLY_ADDED_NEED_KEYINFO_READ_PIN" state. > > > > Here is the comnd I use: > > > > getcert start-tracking -c dogtag-ipa-retrieve-agent-submit -d > > > > /var/lib/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -B > > > > /usr/lib64/ipa/certmonger/stop_pkicad -C > > > > '/usr/lib64/ipa/certmonger/renew_ca_cert "Server-Cert > > cert-pki-ca"' -T > > > > "Server-Cert cert-pki-ca" -P '20160614000000' > > > > > > > Hi Bertrand, > > > > > > to get the right command, you can check on a system where the > > > certificate is properly monitored, this will show you the right > > > parameters: > > > $ sudo getcert list -n ipaCert > > > Number of certificates and requests being tracked: 8. > > > Request ID '20161122095344': > > > [..] key pair storage: > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > [...] > > > CA: dogtag-ipa-ca-renew-agent > > > [...] > > > pre-save command: > > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > > > [...] > > > > > > The relevant fields are NSSDB location, pinfile, nickname, CA, > > pre and > > > post-save commands. So in order to monitor ipaCert, you will > > need to use > > > $ sudo getcert start-tracking -d /etc/httpd/alias -n ipaCert \ > > > -p /etc/httpd/alias/pwdfile.txt \ > > > -c dogtag-ipa-ca-renew-agent \ > > > -B /usr/lib64/ipa/certmonger/renew_ra_cert_pre \ > > > -C /usr/lib64/ipa/certmonger/renew_ra_cert > > > > > > HTH, > > > Flo. > > > > > > > Thanks by advance for your help. > > > > > > > > Regards > > > > Bertrand > > > > > > Hello Florence, > > > > > > Thanks for your reply. > > > Before doing any mistakes, I just need some explanations as I > > think I do > > > not well understand how it should work. > > > > > > Do all the certificate need to be track by certmonger on all > > servers or > > > they should only be tracked on one server and FreeIPA will update them > > > on other servers? > > > > > > In my case I have below certicates outdated and not track on > > "server 1": > > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n > > "auditSigningCert > > > cert-pki-ca" > > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "ocspSigningCert > > > cert-pki-ca" > > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n "subsystemCert > > > cert-pki-ca" > > > > > > They are tracked by certmonger and have been correctly renewed on > > "server 2" > > > Do I need to add them tracked by certmonger on "server 1"? > > > If not, it means FreeIPA failed to update them? Should I delete and > > > import them manually on server 2? > > > > > > If you need more details, do not hesitate to ask. > > > > > Hi Bertrand, > > > > The certificate tracking depends on the type of certificate and on the > > server you're considering. For instance, if IPA includes a Certificate > > Authority, then ipaCert will be present on all the IPA servers > > (master/replicas) and tracked on all of them. The same ipaCert > > certificate is used on all the replicas. On the renewal master, the > > renewal operation actually renews the certificate and uploads the cert > > on LDAP, but on the other replicas the operation consists in > > downloading > > the new certificate from LDAP. > > > > The HTTP and LDAP server certificates are present and tracked on all > > the > > IPA servers, but they are different on each server (you can see that > > the > > Subject of the certificate contains the hostname). They can be renewed > > independently on each IPA server. > > > > The certificates used by Dogtag (the component providing the > > Certificate > > System) are present and tracked only on the IPA servers where the CA > > was > > setup (for instance if you installed a replica with --setup-ca or if > > you > > ran ipa-ca-install later on). The same certificates are used on all > > replicas containing a CA instance. > > They are: 'ocspSigningCert cert-pki-ca', 'subsystemCert cert-pki-ca', > > 'caSigningCert cert-pki-ca' and 'Server-Cert cert-pki-ca'. > > The renewal operation renews them on the renewal master and uploads > > them > > in LDAP, but just downloads them from LDAP on the other servers. > > > > In your example, if server1 also contains a CA instance then it should > > also track the above certs. > > > > You can find the renewal master with the following ldapsearch command: > > $ ldapsearch -h localhost -p 389 -D 'cn=Directory Manager' -w password > > -b "cn=masters,cn=ipa,cn=etc,$BASEDN" -LLL > > '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn > > dn: cn=CA,cn=ipaserver.fqdn,cn=masters,cn=ipa,cn=etc,$BASEDN > > > > In this case the renewal master is ipaserver.fqdn > > > > Hope this clarifies, > > Flo. > > > > > Regards > > > Bertrand > > > > > > Hi Florence, Thanks. All my certificate are now renewed and tracked. I set back current time on my servers and everything is now running properly. However now I get an issue with ldap replication. Here are details of my 3 servers S1, S2 S3 All below commands are launched on S1 servers # ipa-replica-manage list S1: master S2: master S3: master # ipa-replica-manage -v list S1 S2: replica last init status: 0 Total update succeeded last init ended: 2016-11-23 12:56:27+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2016-11-23 13:12:00+00:00 S3: replica last init status: 0 Total update succeeded last init ended: 2016-11-23 12:54:51+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2016-11-23 13:12:00+00:00 # ipa-replica-manage -v S2 S1: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: -1 Incremental update has failed and requires administrator actionLDAP error: Can't contact LDAP server last update ended: 1970-01-01 00:00:00+00:00 # ipa-replica-manage -v S3 S3: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: -1 Incremental update has failed and requires administrator actionLDAP error: Can't contact LDAP server last update ended: 1970-01-01 00:00:00+00:00 I tried to reinitialize S2 server, however I still get the issue: Command below is run on S2: S2# ipa-replica-manage re-initialize --from S1 ipa: INFO: Setting agreement cn=meToS2.skinfra.eu,cn=replica,cn=dc\=a\,dc\=skinfra\,dc\=eu,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn=meToS2,cn=replica,cn=dc\=a\,dc\=skinfra\,dc\=eu,cn=mapping tree,cn=config Update in progress, 2 seconds elapsed Update succeeded On S2 server in /var/log/dirsrv/slapd-REALM/errors log I get [23/Nov/2016:13:54:51 +0100] agmt="cn=meToS1" (S1:389) - Can't locate CSN 583669ee000a000f0000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [23/Nov/2016:13:54:51 +0100] NSMMReplicationPlugin - changelog program - agmt="cn=meToS1" (S1:389): CSN 583669ee000a000f0000 not found, we aren't as up to date, or we purged [23/Nov/2016:13:54:51 +0100] NSMMReplicationPlugin - agmt="cn=meToS1" (S1:389): Data required to update replica has been purged. The replica must be reinitialized. [23/Nov/2016:13:54:51 +0100] NSMMReplicationPlugin - agmt="cn=meToS1" (S1:389): Incremental update failed and requires administrator action .............. [23/Nov/2016:14:18:10 +0100] slapi_ldap_bind - Error: could not bind id [cn=Replication Manager cloneAgreement1-S2,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 (Success) I search on google but I did not find any solution to fix issue and I do not want to break everything Regards Bertrand -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Nov 23 13:34:46 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 23 Nov 2016 15:34:46 +0200 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <583598E0.8090604@sonsorol.org> References: <58346622.1080504@sonsorol.org> <20161122154930.GA18779@p.Speedport_W_724V_Typ_A_05011603_00_009> <58346FA1.3050409@sonsorol.org> <20161123110712.GB18369@p.Speedport_W_724V_Typ_A_05011603_00_009> <58358DD9.7000906@sonsorol.org> <20161123131808.GF18369@p.Speedport_W_724V_Typ_A_05011603_00_009> <583598E0.8090604@sonsorol.org> Message-ID: <20161123133446.mgwdczck6evcsep3@redhat.com> On ke, 23 marras 2016, Chris Dagdigian wrote: > > >Sumit Bose wrote: >>NO. It is the other way round. >> >>It is_not_ recommended and will not even work properly to use the same >>DNS domain for IPA and AD. Even worse with using the same realm for >>both, this cannot work at all. >> >>It is required to have a different realm name for the IPA domain and it >>is important to use a different DNS domain as well (a bit is possible >>with hosts in the same DNS domain but you loose functionality here). >> >>Where did you find the recommendation to user the same DNS domain and >>realm? >> > >Apologies I must have been unclear. What I was trying to say is that >we are going for the "hosts in the different DNS domain" deployment >scenario ... > >- We have unique domain name and realm for IPA: company-ipa.org >- We use company-aws.org in AWS and have our own Active Directory >servers for: company-aws.org >- We want to use ipa-client to bind our servers to company-ipa.org but >use DNS names from company-aws.org for operation > >Our end goal: >- We have many external AD forests we are linking to company-ipa.org >one at a time >- End goal: operate hosts with DNS name "company-aws.org" as IPA >clients of "company-ipa.org" using AD logins coming from the external >trusts This setup should work with password-based authentication. It will not work with GSSAPI (Kerberos) authentication. I think this is what you are aware of and accepted as the limitation. For the benefit of others, here is the list of articles and documentation of the topic of mixed DNS domains/hostnames with Active Directory: - High-level description: http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/ - Documentation chapter: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#ipa-in-ad-dns - Technical details: http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain There is nothing we can do with the Active Directory limitations beyond these documents. -- / Alexander Bokovoy From dag at sonsorol.org Wed Nov 23 13:54:25 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 23 Nov 2016 08:54:25 -0500 Subject: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong? In-Reply-To: <20161123133446.mgwdczck6evcsep3@redhat.com> References: <58346622.1080504@sonsorol.org> <20161122154930.GA18779@p.Speedport_W_724V_Typ_A_05011603_00_009> <58346FA1.3050409@sonsorol.org> <20161123110712.GB18369@p.Speedport_W_724V_Typ_A_05011603_00_009> <58358DD9.7000906@sonsorol.org> <20161123131808.GF18369@p.Speedport_W_724V_Typ_A_05011603_00_009> <583598E0.8090604@sonsorol.org> <20161123133446.mgwdczck6evcsep3@redhat.com> Message-ID: <58359F91.6040703@sonsorol.org> 100% correct. We are OK with losing GSSAPI authentication if we can operate in a different DNS domain than the IPA server that "glues" together all of our various Active Directory trusts. We want password authentication from Active Directory as our main concern with role-based access control coming in as a strong second desire. The Redhat/IPA documentation and links that Alexander posted below on this are quite good and the issues on our end have generally come from following more generic deployment instructions that don't cover the different-DNS-domain situation. The quality of technical insight on this list has been fantastic. If our "different DNS" setup is of interest to others I'd be happy to write up our architecture and configurations in more detail once this project settles down. At the very least I should be able to prepare a concise "lessons learned" summary that details the configuration settings that deviate from the norms advised in the more general-purpose instructions. Regards, Chris Alexander Bokovoy wrote: >> Apologies I must have been unclear. What I was trying to say is that >> we are going for the "hosts in the different DNS domain" deployment >> scenario ... >> >> - We have unique domain name and realm for IPA: company-ipa.org >> - We use company-aws.org in AWS and have our own Active Directory >> servers for: company-aws.org >> - We want to use ipa-client to bind our servers to company-ipa.org >> but use DNS names from company-aws.org for operation >> >> Our end goal: >> - We have many external AD forests we are linking to company-ipa.org >> one at a time >> - End goal: operate hosts with DNS name "company-aws.org" as IPA >> clients of "company-ipa.org" using AD logins coming from the external >> trusts > This setup should work with password-based authentication. It will not > work with GSSAPI (Kerberos) authentication. I think this is what you are > aware of and accepted as the limitation. > > For the benefit of others, here is the list of articles and > documentation of the topic of mixed DNS domains/hostnames with Active > Directory: > > - High-level description: > http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/ > > - Documentation chapter: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#ipa-in-ad-dns > > > - Technical details: > http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain > > There is nothing we can do with the Active Directory limitations beyond > these documents. > From tk at mdevsys.com Thu Nov 24 05:08:04 2016 From: tk at mdevsys.com (TomK) Date: Thu, 24 Nov 2016 00:08:04 -0500 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: <2837abb4-3605-1946-e752-a09b289439c5@redhat.com> References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> <97e67d02-a736-239e-0d65-5ce551454a1f@mdevsys.com> <2837abb4-3605-1946-e752-a09b289439c5@redhat.com> Message-ID: <731bb495-e534-8581-9da4-ae57f9f6b466@mdevsys.com> On 11/23/2016 3:28 AM, Martin Basti wrote: > > > On 23.11.2016 03:48, TomK wrote: >> On 11/22/2016 10:22 AM, Martin Basti wrote: >>> >>> >>> On 22.11.2016 13:57, TomK wrote: >>>> On 11/22/2016 2:59 AM, Martin Basti wrote: >>>>> Hey, >>>>> >>>>> >>>>> On 22.11.2016 06:33, TomK wrote: >>>>>> Hey Guy's, >>>>>> >>>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 >>>>>> over to >>>>>> my dual Free IPA server. The Free IPA servers are authoritative for >>>>>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>>>>> and forwards dom.abc.xyz. >>>>> Do you have configured proper zone delegation for subdomain >>>>> dom.abc.xyz? >>>>> Proper NS and glue records >>>>> http://www.zytrax.com/books/dns/ch9/delegate.html >>>>> >>>>>> >>>>>> I cannot ping dom.abc.xyz. Everything else, including client >>>>>> registrations, work fine. If Free IPA is authoritative on >>>>>> dom.abc.xyz, should it not create DNS entries so the sub domain >>>>>> can be >>>>>> pinged as well? >>>>> >>>>> What do you mean by "ping"? >>>>> >>>>>> >>>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>>>>> and wanted to ask if you can point me to some materials online to >>>>>> determine where can I permanently adjust the search to add >>>>>> dom.abc.xyz >>>>>> to the already present abc.xyz . I wasn't able to locate what I >>>>>> needed in my searches. >>>>>> >>>>>> I'm using the latest v4. >>>>> >>>>> It depends on what are you using, probably you have NetworkManager >>>>> there >>>>> that is editing /etc/resolv.conf >>>>> >>>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >>>>> >>>>> >>>>> >>>>> >>>>> Martin >>>> >>>> >>>> I Uninstalled NetworkManager. Still changes. >>>> ping dom.abc.com results in "ping: unknown host" >>>> >>>> I'll have a look at the first link, ty. >>>> >>> >>> ping (ICMP protocol) and DNS system are different things, do you have >>> hostname dom.abc.com with A record or it is a zone? >>> >>> with ping command hostname "dom.abc.com" is resolved to IP address >>> first, do you have A record set for dom.abc.com in zone apex or what are >>> you trying to achieve with ping command? >>> >>> for testing DNS try to use commands: dig, host, nslookup >>> >>> Martin >>> >> >> Apologize for the long reply but it should give some background on >> what it is that I'm doing. >> >> 1) dom.abc.com is a zone. There is no A record for dom.abc.com in >> FreeIPA (Confirmed by Petr). I get the point Petr Spacek pointed out >> in his comment as well. What should it really point too? ( I kind of >> answer this question below so please read on. ) Where I'm getting >> this from is that in Windows Server 2012 abc.com returns the IP of any >> of the participating AD / DNS servers within the cluster (The two >> Windows Server 2012 are a combined clustered AD + DNS servers.). >> Being able to resolve abc.xyz is handy. During a lookup, I can get a >> list of all the IP's associated with that domain which would indicate >> all the DNS + AD servers online under that domain or serving that domain: >> >> >> # nslookup abc.xyz >> Server: 192.168.0.3 >> Address: 192.168.0.3#53 >> >> Name: abc.xyz >> Address: 192.168.0.3 >> Name: abc.xyz >> Address: 192.168.0.1 >> Name: abc.xyz >> Address: 192.168.0.2 >> # >> >> Again, where this is handy is when configuring sssd.conf for example >> or other apps for that matter. I can just point the app to >> authenticate against the domain and I have my redundancy solved. >> Windows Server 2012 does it, but FreeIPA didn't, so I threw the >> question out there. > > IPA uses SRV records heavily, all IPA related services have SRV records, > SSSD uses SRV records of IPA, client should use SRV record to connect to > the right service (or URI record - will be in next IPA). SRV records > work for IPA locations mechanism, we cannot achieve this with pure A > records. > >> >> Delegation from this Windows DNS works as expected. Any lookup from >> dom.abc.xyz is forwarded too and handled by FreeIPA servers. Tested >> this out. No issue with this. >> >> I did see earlier that there is no A record for dom.abc.xyz in >> FreeIPA. My reasons for asking if there was an IP on the subdomain in >> FreeIPA were above but the missing IP on the subdomain isn't a major >> issue for me. Things are working without dom.abc.xyz resolving to an >> IP. What I was hoping for is to have a VIP for the IPA servers and >> one for the Windows Server 2012 DNS Cluster in /etc/resolv.conf. (I >> have the VIP for the windows server). One forwarding to the other for >> a given domain. This is all for testing a) redundancy, b) forwarding, >> a) authentication . >> >> IE: >> >> # cat /etc/resolv.conf >> search dom.abc.xyz abc.xyz >> nameserver 192.168.0.3 <------------ Win Cluster DNS VIP >> nameserver 192.168.0.4 <------------ IPA Cluster DNS VIP >> >> * Just what I want to achieve above. VIP 192.168.0.4 doesn't exist on >> my cluster yet. I'm looking to integrate ucarp with the above IPA >> servers. >> >> >> 2) More to the topic of my second question however, is that >> /etc/resolv.conf, on the IPA servers themselves, get's rewritten on >> restart. Would like to know by what if I already uninstalled >> NetworkManager? When I configured the FreeIPA server, I used: >> >> ipa-server-install --setup-dns --forwarder=192.168.0.3 -p "Hush!" -a >> "Hush!" -r DOM.ABC.XYZ -n dom.abc.xyz --hostname ipa01.dom.abc.xyz >> >> Notice I used the VIP of the Windows Server 2012 Cluster when >> installing FreeIPA. This is nice for redundancy. So the resolv.conf >> ends up being: >> >> # cat /etc/resolv.conf >> # Generated by NetworkManager >> search abc.xyz >> nameserver 192.168.0.3 >> nameserver 123.123.123.1 >> nameserver 123.123.123.2 >> >> Then I add: >> >> search dom.abc.xyz abc.xyz >> >> but it changes back to search abc.xyz (the Windows Server 2012 DNS). >> This all works, except for the above minor items, and I can resolve >> anything over this network. ( Thinking this is fine because the >> forward is on the subdomain. I haven't had issues with forwarding >> through this setup. ) >> >> # cat /etc/resolv.conf >> # Generated by NetworkManager >> search abc.xyz >> nameserver 192.168.0.3 >> nameserver 123.123.123.1 >> nameserver 123.123.123.2 >> >> But NetworkManager is not installed on these IPA servers. I've >> removed it earlier: >> >> # rpm -aq|grep -i NetworkManager >> # >> >> Is FreeIPA replacing /etc/resolv.conf with a copy it keeps elsewhere? > > On servers with DNS /etc/resolv.conf should point to 127.0.0.1 and ::1, > and global or per server dns forwarders should be configured instead > > Have you properly stopped NetworkManager using systemctl stop and > systemctl disable ? In case you just removed rpm files service can still > work. > I recommend to update network manager config, not to remove it :) > > As last resort way, you can set immutable bit to resolv.conf if > something is still changing your resolv.conf file > >> >> 3) After running: >> >> ipa-client-install --mkhomedir --enable-dns-updates >> >> on a new host, the hostname of the new host doesn't resolve for a few >> minutes. How do I make this instantaneous? (Other then that, >> autodiscovery of the IPA servers is excellent!). Before installing >> the IPA Client, the new hosts /etc/resolv.conf file looks like this: >> >> # cat /etc/resolv.conf >> search abc.xyz >> nameserver 192.168.0.3 >> nameserver 123.123.123.1 >> nameserver 123.123.123.2 >> >> I did dig, host, nslookup earlier. Verified all except for the items >> I'm inquiring about. >> > > That weird, because ipa-client-install creates A records directly to DNS > server using nsupdate, so it should be accessible instantly. Do you have > any caching DNS servers? > > Martin > No caching DNS servers. On the topic of NetworkManager. It's completely gone yet still the /etc/resolv.conf file is being replaced with the text # Generated by NetworkManager. # systemctl show NetworkManager.service --property=Id,Names,Description Id=NetworkManager.service Names=NetworkManager.service Description=NetworkManager.service # # systemctl list-units --type service --all|grep -i network network.service loaded active exited LSB: Bring up/down networking ? NetworkManager-wait-online.service not-found inactive dead NetworkManager-wait-online.service ? NetworkManager.service not-found inactive dead NetworkManager.service ntpd.service loaded active running Network Time Service rhel-domainname.service loaded active exited Read and set NIS domainname from /etc/sysconfig/network rhel-import-state.service loaded active exited Import network configuration from initramfs # The only thing that is left of the NetworkManager service is the above. Nothing I type from systemd removed it completely. So I've reverted to the last resort: # lsattr /etc/resolv.conf ----i----------- /etc/resolv.conf # With the above, I'm trying to see what's writing to the file by using this auditctl and found that postfix seems to be doing this: ---- time->Wed Nov 23 23:14:47 2016 type=PATH msg=audit(1479960887.978:293): item=0 name="/etc/resolv.conf" inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(1479960887.978:293): cwd="/" type=SYSCALL msg=audit(1479960887.978:293): arch=c000003e syscall=2 success=yes exit=4 a0=7ffb36b6f43a a1=80000 a2=1b6 a3=24 items=1 ppid=1 pid=5527 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="postfix" exe="/usr/sbin/postfix" subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" ---- time->Wed Nov 23 23:14:48 2016 type=PATH msg=audit(1479960888.013:301): item=0 name="/etc/resolv.conf" inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(1479960888.013:301): cwd="/var/spool/postfix" type=SYSCALL msg=audit(1479960888.013:301): arch=c000003e syscall=2 success=yes exit=3 a0=7f32c163043a a1=80000 a2=1b6 a3=24 items=1 ppid=5545 pid=5546 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="postconf" exe="/usr/sbin/postconf" subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" This in turn appears to be called by started by: # grep postfix access|tail -n 1 [23/Nov/2016:23:42:04 -0500] conn=34 op=5 SRCH base="cn=accounts,dc=dom,dc=abc,dc=xyz" scope=2 filter="(&(uid=postfix)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))" attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf ipaUniqueID ipaNTSecurityIdentifier modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdattribute authorizedService accountexpires useraccountcontrol nsAccountLock host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey ipaUserAuthType usercertificate;binary" # pwd /var/log/dirsrv/slapd-DOM-ABC-XYZ # -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From jrichard at placeiq.com Thu Nov 24 06:15:05 2016 From: jrichard at placeiq.com (Jim Richard) Date: Thu, 24 Nov 2016 01:15:05 -0500 Subject: [Freeipa-users] ACIerrors is httpd log Message-ID: <4B8D5975-7858-4CC2-99AF-FC1E4D6EEB93@placeiq.com> Honestly I?m not even sure if something is not working correctly :) All I know is that my httpd, access and krb5 logs are filling up all my disk space extremely quickly and I have no idea why. Centos 6.8 + IPA 3.0 One master and one replica. Are these things related? How do I fix, where do I even start? Thanks ! On the replica the httpd log is constantly getting spammed with: [Thu Nov 24 05:55:18 2016] [error] ipa: INFO: host/phoenix-153.nym1.placeiq.net at PLACEIQ.NET: cert_request(u?actual cert removed?.. , add=True): ACIError and on the master the access log is filling up quickly with: 10.1.41.110 - - [24/Nov/2016:06:09:54 +0000] "POST /ca/agent/ca/displayBySerial HTTP/1.1" 200 10106 and finally also on the master?s krb5 log is filling up with: Nov 24 06:11:45 sso-109.nym1.placeiq.net krb5kdc[19333](info): AS_REQ (4 etypes {18 17 16 23}) 10.1.60.130: ISSUE: authtime 1479967905, etypes {rep=18 tkt=18 ses=18}, host/phoenix-130.nym1.placeiq.net at PLACEIQ.NET for krbtgt/PLACEIQ.NET at PLACEIQ.NET Nov 24 06:11:45 sso-109.nym1.placeiq.net krb5kdc[19332](info): TGS_REQ (4 etypes {18 17 16 23}) 10.1.60.87: ISSUE: authtime 1479967905, etypes {rep=18 tkt=18 ses=18}, host/phoenix-087.nym1.placeiq.net at PLACEIQ.NET for ldap/sso-109.nym1.placeiq.net at PLACEIQ.NET Nov 24 06:11:45 sso-109.nym1.placeiq.net krb5kdc[19332](info): TGS_REQ (4 etypes {18 17 16 23}) 10.1.60.130: ISSUE: authtime 1479967905, etypes {rep=18 tkt=18 ses=18}, host/phoenix-130.nym1.placeiq.net at PLACEIQ.NET for HTTP/sso-110.nym1.placeiq.net at PLACEIQ.NET Nov 24 06:11:45 sso-109.nym1.placeiq.net krb5kdc[19333](info): TGS_REQ (1 etypes {18}) 10.1.60.130: ISSUE: authtime 1479967905, etypes {rep=18 tkt=18 ses=18}, host/phoenix-130.nym1.placeiq.net at PLACEIQ.NET for krbtgt/PLACEIQ.NET at PLACEIQ.NET Nov 24 06:11:45 sso-109.nym1.placeiq.net krb5kdc[19333](info): AS_REQ (4 etypes {18 17 16 23}) 10.1.60.160: NEEDED_PREAUTH: host/phoenix-160.nym1.placeiq.net at PLACEIQ.NET for krbtgt/PLACEIQ.NET at PLACEIQ.NET, Additional pre-authentication required Nov 24 06:11:45 sso-109.nym1.placeiq.net krb5kdc[19332](info): AS_REQ (4 etypes {18 17 16 23}) 10.1.60.160: ISSUE: authtime 1479967905, etypes {rep=18 tkt=18 ses=18}, host/phoenix-160.nym1.placeiq.net at PLACEIQ.NET for krbtgt/PLACEIQ.NET at PLACEIQ.NET Nov 24 06:11:45 sso-109.nym1.placeiq.net krb5kdc[19333](info): TGS_REQ (4 etypes {18 17 16 23}) 10.1.60.160: ISSUE: authtime 1479967905, etypes {rep=18 tkt=18 ses=18}, host/phoenix-160.nym1.placeiq.net at PLACEIQ.NET for HTTP/sso-110.nym1.placeiq.net at PLACEIQ.NET Nov 24 06:11:45 sso-109.nym1.placeiq.net krb5kdc[19333](info): TGS_REQ (1 etypes {18}) 10.1.60.160: ISSUE: authtime 1479967905, etypes {rep=18 tkt=18 ses=18}, host/phoenix-160.nym1.placeiq.net at PLACEIQ.NET for krbtgt/PLACEIQ.NET at PLACEIQ.NET Nov 24 06:11:45 sso-109.nym1.placeiq.net krb5kdc[19333](info): AS_REQ (4 etypes {18 17 16 23}) 10.1.60.175: NEEDED_PREAUTH: host/phoenix-175.nym1.placeiq.net at PLACEIQ.NET for krbtgt/PLACEIQ.NET at PLACEIQ.NET, Additional pre-authentication required Nov 24 06:11:45 sso-109.nym1.placeiq.net krb5kdc[19332](info): AS_REQ (4 etypes {18 17 16 23}) 10.1.60.175: ISSUE: authtime 1479967905, etypes {rep=18 tkt=18 ses=18}, host/phoenix-175.nym1.placeiq.net at PLACEIQ.NET for krbtgt/PLACEIQ.NET at PLACEIQ.NET Jim Richard SYSTEM ADMINISTRATOR III (646) 338-8905 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Nov 24 09:49:54 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 24 Nov 2016 10:49:54 +0100 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: <731bb495-e534-8581-9da4-ae57f9f6b466@mdevsys.com> References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> <97e67d02-a736-239e-0d65-5ce551454a1f@mdevsys.com> <2837abb4-3605-1946-e752-a09b289439c5@redhat.com> <731bb495-e534-8581-9da4-ae57f9f6b466@mdevsys.com> Message-ID: On 24.11.2016 06:08, TomK wrote: > On 11/23/2016 3:28 AM, Martin Basti wrote: >> >> >> On 23.11.2016 03:48, TomK wrote: >>> On 11/22/2016 10:22 AM, Martin Basti wrote: >>>> >>>> >>>> On 22.11.2016 13:57, TomK wrote: >>>>> On 11/22/2016 2:59 AM, Martin Basti wrote: >>>>>> Hey, >>>>>> >>>>>> >>>>>> On 22.11.2016 06:33, TomK wrote: >>>>>>> Hey Guy's, >>>>>>> >>>>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 >>>>>>> over to >>>>>>> my dual Free IPA server. The Free IPA servers are authoritative for >>>>>>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>>>>>> and forwards dom.abc.xyz. >>>>>> Do you have configured proper zone delegation for subdomain >>>>>> dom.abc.xyz? >>>>>> Proper NS and glue records >>>>>> http://www.zytrax.com/books/dns/ch9/delegate.html >>>>>> >>>>>>> >>>>>>> I cannot ping dom.abc.xyz. Everything else, including client >>>>>>> registrations, work fine. If Free IPA is authoritative on >>>>>>> dom.abc.xyz, should it not create DNS entries so the sub domain >>>>>>> can be >>>>>>> pinged as well? >>>>>> >>>>>> What do you mean by "ping"? >>>>>> >>>>>>> >>>>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>>>>>> and wanted to ask if you can point me to some materials online to >>>>>>> determine where can I permanently adjust the search to add >>>>>>> dom.abc.xyz >>>>>>> to the already present abc.xyz . I wasn't able to locate what I >>>>>>> needed in my searches. >>>>>>> >>>>>>> I'm using the latest v4. >>>>>> >>>>>> It depends on what are you using, probably you have NetworkManager >>>>>> there >>>>>> that is editing /etc/resolv.conf >>>>>> >>>>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Martin >>>>> >>>>> >>>>> I Uninstalled NetworkManager. Still changes. >>>>> ping dom.abc.com results in "ping: unknown host" >>>>> >>>>> I'll have a look at the first link, ty. >>>>> >>>> >>>> ping (ICMP protocol) and DNS system are different things, do you have >>>> hostname dom.abc.com with A record or it is a zone? >>>> >>>> with ping command hostname "dom.abc.com" is resolved to IP address >>>> first, do you have A record set for dom.abc.com in zone apex or what are >>>> you trying to achieve with ping command? >>>> >>>> for testing DNS try to use commands: dig, host, nslookup >>>> >>>> Martin >>>> >>> >>> Apologize for the long reply but it should give some background on >>> what it is that I'm doing. >>> >>> 1) dom.abc.com is a zone. There is no A record for dom.abc.com in >>> FreeIPA (Confirmed by Petr). I get the point Petr Spacek pointed out >>> in his comment as well. What should it really point too? ( I kind of >>> answer this question below so please read on. ) Where I'm getting >>> this from is that in Windows Server 2012 abc.com returns the IP of any >>> of the participating AD / DNS servers within the cluster (The two >>> Windows Server 2012 are a combined clustered AD + DNS servers.). >>> Being able to resolve abc.xyz is handy. During a lookup, I can get a >>> list of all the IP's associated with that domain which would indicate >>> all the DNS + AD servers online under that domain or serving that domain: >>> >>> >>> # nslookup abc.xyz >>> Server: 192.168.0.3 >>> Address: 192.168.0.3#53 >>> >>> Name: abc.xyz >>> Address: 192.168.0.3 >>> Name: abc.xyz >>> Address: 192.168.0.1 >>> Name: abc.xyz >>> Address: 192.168.0.2 >>> # >>> >>> Again, where this is handy is when configuring sssd.conf for example >>> or other apps for that matter. I can just point the app to >>> authenticate against the domain and I have my redundancy solved. >>> Windows Server 2012 does it, but FreeIPA didn't, so I threw the >>> question out there. >> >> IPA uses SRV records heavily, all IPA related services have SRV records, >> SSSD uses SRV records of IPA, client should use SRV record to connect to >> the right service (or URI record - will be in next IPA). SRV records >> work for IPA locations mechanism, we cannot achieve this with pure A >> records. >> >>> >>> Delegation from this Windows DNS works as expected. Any lookup from >>> dom.abc.xyz is forwarded too and handled by FreeIPA servers. Tested >>> this out. No issue with this. >>> >>> I did see earlier that there is no A record for dom.abc.xyz in >>> FreeIPA. My reasons for asking if there was an IP on the subdomain in >>> FreeIPA were above but the missing IP on the subdomain isn't a major >>> issue for me. Things are working without dom.abc.xyz resolving to an >>> IP. What I was hoping for is to have a VIP for the IPA servers and >>> one for the Windows Server 2012 DNS Cluster in /etc/resolv.conf. (I >>> have the VIP for the windows server). One forwarding to the other for >>> a given domain. This is all for testing a) redundancy, b) forwarding, >>> a) authentication . >>> >>> IE: >>> >>> # cat /etc/resolv.conf >>> search dom.abc.xyz abc.xyz >>> nameserver 192.168.0.3 <------------ Win Cluster DNS VIP >>> nameserver 192.168.0.4 <------------ IPA Cluster DNS VIP >>> >>> * Just what I want to achieve above. VIP 192.168.0.4 doesn't exist on >>> my cluster yet. I'm looking to integrate ucarp with the above IPA >>> servers. >>> >>> >>> 2) More to the topic of my second question however, is that >>> /etc/resolv.conf, on the IPA servers themselves, get's rewritten on >>> restart. Would like to know by what if I already uninstalled >>> NetworkManager? When I configured the FreeIPA server, I used: >>> >>> ipa-server-install --setup-dns --forwarder=192.168.0.3 -p "Hush!" -a >>> "Hush!" -r DOM.ABC.XYZ -n dom.abc.xyz --hostname ipa01.dom.abc.xyz >>> >>> Notice I used the VIP of the Windows Server 2012 Cluster when >>> installing FreeIPA. This is nice for redundancy. So the resolv.conf >>> ends up being: >>> >>> # cat /etc/resolv.conf >>> # Generated by NetworkManager >>> search abc.xyz >>> nameserver 192.168.0.3 >>> nameserver 123.123.123.1 >>> nameserver 123.123.123.2 >>> >>> Then I add: >>> >>> search dom.abc.xyz abc.xyz >>> >>> but it changes back to search abc.xyz (the Windows Server 2012 DNS). >>> This all works, except for the above minor items, and I can resolve >>> anything over this network. ( Thinking this is fine because the >>> forward is on the subdomain. I haven't had issues with forwarding >>> through this setup. ) >>> >>> # cat /etc/resolv.conf >>> # Generated by NetworkManager >>> search abc.xyz >>> nameserver 192.168.0.3 >>> nameserver 123.123.123.1 >>> nameserver 123.123.123.2 >>> >>> But NetworkManager is not installed on these IPA servers. I've >>> removed it earlier: >>> >>> # rpm -aq|grep -i NetworkManager >>> # >>> >>> Is FreeIPA replacing /etc/resolv.conf with a copy it keeps elsewhere? >> >> On servers with DNS /etc/resolv.conf should point to 127.0.0.1 and ::1, >> and global or per server dns forwarders should be configured instead >> >> Have you properly stopped NetworkManager using systemctl stop and >> systemctl disable ? In case you just removed rpm files service can still >> work. >> I recommend to update network manager config, not to remove it :) >> >> As last resort way, you can set immutable bit to resolv.conf if >> something is still changing your resolv.conf file >> >>> >>> 3) After running: >>> >>> ipa-client-install --mkhomedir --enable-dns-updates >>> >>> on a new host, the hostname of the new host doesn't resolve for a few >>> minutes. How do I make this instantaneous? (Other then that, >>> autodiscovery of the IPA servers is excellent!). Before installing >>> the IPA Client, the new hosts /etc/resolv.conf file looks like this: >>> >>> # cat /etc/resolv.conf >>> search abc.xyz >>> nameserver 192.168.0.3 >>> nameserver 123.123.123.1 >>> nameserver 123.123.123.2 >>> >>> I did dig, host, nslookup earlier. Verified all except for the items >>> I'm inquiring about. >>> >> >> That weird, because ipa-client-install creates A records directly to DNS >> server using nsupdate, so it should be accessible instantly. Do you have >> any caching DNS servers? >> >> Martin >> > > No caching DNS servers. > > On the topic of NetworkManager. It's completely gone yet still the > /etc/resolv.conf file is being replaced with the text # Generated by > NetworkManager. > > # systemctl show NetworkManager.service --property=Id,Names,Description > Id=NetworkManager.service > Names=NetworkManager.service > Description=NetworkManager.service > # > > # systemctl list-units --type service --all|grep -i network > network.service loaded active exited LSB: Bring > up/down networking > ? NetworkManager-wait-online.service not-found inactive dead > NetworkManager-wait-online.service > ? NetworkManager.service not-found inactive dead > NetworkManager.service > ntpd.service loaded active running Network > Time Service > rhel-domainname.service loaded active exited Read and > set NIS domainname from /etc/sysconfig/network > rhel-import-state.service loaded active exited Import > network configuration from initramfs > # > > > The only thing that is left of the NetworkManager service is the above. > Nothing I type from systemd removed it completely. So I've reverted to the > last resort: > > # lsattr /etc/resolv.conf > ----i----------- /etc/resolv.conf > # > > With the above, I'm trying to see what's writing to the file by using this > auditctl and found that postfix seems to be doing this: > > ---- > time->Wed Nov 23 23:14:47 2016 > type=PATH msg=audit(1479960887.978:293): item=0 name="/etc/resolv.conf" > inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL > type=CWD msg=audit(1479960887.978:293): cwd="/" > type=SYSCALL msg=audit(1479960887.978:293): arch=c000003e syscall=2 > success=yes exit=4 a0=7ffb36b6f43a a1=80000 a2=1b6 a3=24 items=1 ppid=1 > pid=5527 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) ses=4294967295 comm="postfix" exe="/usr/sbin/postfix" > subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" > ---- > time->Wed Nov 23 23:14:48 2016 > type=PATH msg=audit(1479960888.013:301): item=0 name="/etc/resolv.conf" > inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL > type=CWD msg=audit(1479960888.013:301): cwd="/var/spool/postfix" > type=SYSCALL msg=audit(1479960888.013:301): arch=c000003e syscall=2 > success=yes exit=3 a0=7f32c163043a a1=80000 a2=1b6 a3=24 items=1 ppid=5545 > pid=5546 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) ses=4294967295 comm="postconf" exe="/usr/sbin/postconf" > subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" It usually helps to run ausearch -i, it translates numberic codes to names. Assuming you are running Linux on x86_64, it would be interpreted like this: ---- type=SYSCALL msg=audit(24.11.2016 05:14:47.978:293) : arch=x86_64 syscall=open success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 key=/root/resolv.conf-file type=CWD msg=audit(24.11.2016 05:14:47.978:293) : cwd=/ type=PATH msg=audit(24.11.2016 05:14:47.978:293) : item=0 name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL ---- type=SYSCALL msg=audit(24.11.2016 05:14:48.013:301) : arch=x86_64 syscall=open success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 key=/root/resolv.conf-file type=CWD msg=audit(24.11.2016 05:14:48.013:301) : cwd=/var/spool/postfix type=PATH msg=audit(24.11.2016 05:14:48.013:301) : item=0 name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL In other words, /root/resolv.conf-file is open for reading. It is interesting ... What does the file contain? Petr^2 Spacek > > This in turn appears to be called by started by: > > # grep postfix access|tail -n 1 > [23/Nov/2016:23:42:04 -0500] conn=34 op=5 SRCH > base="cn=accounts,dc=dom,dc=abc,dc=xyz" scope=2 > filter="(&(uid=postfix)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))" > attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory > loginShell krbPrincipalName cn memberOf ipaUniqueID ipaNTSecurityIdentifier > modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning > shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration > pwdattribute authorizedService accountexpires useraccountcontrol nsAccountLock > host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey > ipaUserAuthType usercertificate;binary" > # pwd > /var/log/dirsrv/slapd-DOM-ABC-XYZ From d.mueller2 at rto.de Thu Nov 24 12:48:50 2016 From: d.mueller2 at rto.de (=?utf-8?B?RGVuaXMgTcO8bGxlcg==?=) Date: Thu, 24 Nov 2016 12:48:50 +0000 Subject: [Freeipa-users] Can't establish a trust to AD Message-ID: <1479991730.5392.61.camel@rto.de> Hello Guys, we need help to establish a trust from freeipa to ad. Ad users should be able to access to linux environment, but linux users not to ad environment. our setup: AD Domain: domain.com, there we have two AD-Controllers installed wird Windows Server 2008. All users are managed here. IPA Domain: wop.domain.com. We would like to sync users from ad to a specific group to provide user-management in linux environments. In this subdomain we have 2 ipa-servers: ipa01.wop.domain.com and ipa02.domain.com Ipa version on both servers is: VERSION: 4.2.0, API_VERSION: 2.156 Both serves have "ipa-server-trust-ad" installed. [root at ipa01 ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful kinit admin works as expected ! DNS konfiguration: IPA-Side: [root at ipa01 ~]# dig +short -t SRV _kerberos._udp.wop.domain.com 0 100 88 ipa02.wop.domain.com. 0 100 88 ipa01.wop.domain.com. root at ipa01 ~]# dig +short -t TXT _kerberos.wop.domain.com "WOP.DOMAIN.COM" [root at ipa01 ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.wop.domain.com. 0 100 88 ipa02.wop.domain.com. 0 100 88 ipa01.wop.domain.com. [root at ipa01 ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.wop.domain.com. 0 100 88 ipa01.wop.domain.com. 0 100 88 ipa02.wop.domain.com. AD-Side: C:\Users\demueller>nslookup Standardserver: dc2.domain.com Address: 192.168.3.9 > set type=SRV > _kerberos._udp.wop.domain.com. Server: dc2.domain.com Address: 192.168.3.9 Nicht autorisierende Antwort: _kerberos._udp.wop.domain.com SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipa01.wop.domainc.om _kerberos._udp.wop.rto.de SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipa02.wop.domain.com ipa01.wop.domain.com internet address = 192.168.11.75 ipa02.wop.domainc.om internet address = 192.168.11.106 DNS looks fine, firewall too. Providing trust:ipa trust-add --type=ad rto.de --trust-secret --server=dc2.domain.com As a Result: [root at ipa01 ~]# ipa trustdomain-find domain.com Domain name: domain.com Domain NetBIOS name: DOMAIN (It should be DC2, right?) Domain Security Identifier: S-1-5-21-746137067-2052111302-1801674531 Domain enabled: True ------------------------------------- ipa trust-fetch-domain domain.com Logging: [Thu Nov 24 13:43:44.167918 2016] [:error] [pid 9123] ipa: INFO: [jsonserver_session] admin at WOP.DOMAIN.COM: ping(): SUCCESS [Thu Nov 24 13:43:44.306718 2016] [:error] [pid 9124] ipa: INFO: [jsonserver_session] admin at WOP.DOMAIN.COM: trustdomain_find(u'domain.com', None, all=False, raw=False, version=u'2.156', pkey_only=False): SUCCESS [Thu Nov 24 13:45:16.662862 2016] [:error] [pid 9123] ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm 'WOP.DOMAIN.COM) I can't understand the problem. On AD side we create a trust certifiacte as explained hear: http://www.freeipa.org/page/Active_Directory_trust_setup ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peljasz at yahoo.co.uk Thu Nov 24 12:59:15 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 24 Nov 2016 12:59:15 +0000 Subject: [Freeipa-users] where to put computer accounts... ? Message-ID: <28cb6f36-cb96-85b1-1962-096e561c1b09@yahoo.co.uk> .. in order to satisfy classic Samba (which still uses openldap for user db backend but needs computer unix account) which complains: Failed to find a Unix account for yourcomp$ ? many thanks, L. From simo at redhat.com Thu Nov 24 15:10:50 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 24 Nov 2016 10:10:50 -0500 Subject: [Freeipa-users] where to put computer accounts... ? In-Reply-To: <28cb6f36-cb96-85b1-1962-096e561c1b09@yahoo.co.uk> References: <28cb6f36-cb96-85b1-1962-096e561c1b09@yahoo.co.uk> Message-ID: <1480000250.3917.83.camel@redhat.com> On Thu, 2016-11-24 at 12:59 +0000, lejeczek wrote: > .. in order to satisfy classic Samba (which still uses > openldap for user db backend but needs computer unix > account) which complains: > Failed to find a Unix account for yourcomp$ > > ? If this is on a client machine for its own computer account I would think of adding it to the local user database, if you have to distribute it via LDAP you'll have to create actual user accounts ion the directory I guess. Simo. -- Simo Sorce * Red Hat, Inc * New York From Adam.Bishop at jisc.ac.uk Thu Nov 24 15:27:05 2016 From: Adam.Bishop at jisc.ac.uk (Adam Bishop) Date: Thu, 24 Nov 2016 15:27:05 +0000 Subject: [Freeipa-users] ipalib authentication Message-ID: <81A0EC2E-7489-49C6-8480-768DA022321E@jisc.ac.uk> I'm writing a bit of code using ipalib directly, I'm a little stuck on authentication though. It works fine if grab a Kerberos ticket with kinit then run the code interactively, but I'd like to run this as a daemon which makes maintaining a ticket tricky. What other options are there for authenticating to the API, avoiding calling external tools like curl or kinit? Regards, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc?s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. From peljasz at yahoo.co.uk Thu Nov 24 15:27:45 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 24 Nov 2016 15:27:45 +0000 Subject: [Freeipa-users] where to put computer accounts... ? In-Reply-To: <1480000250.3917.83.camel@redhat.com> References: <28cb6f36-cb96-85b1-1962-096e561c1b09@yahoo.co.uk> <1480000250.3917.83.camel@redhat.com> Message-ID: <0afb1aab-880d-d9e5-7d06-e1ebfc2b53d5@yahoo.co.uk> On 24/11/16 15:10, Simo Sorce wrote: > On Thu, 2016-11-24 at 12:59 +0000, lejeczek wrote: >> .. in order to satisfy classic Samba (which still uses >> openldap for user db backend but needs computer unix >> account) which complains: >> Failed to find a Unix account for yourcomp$ >> >> ? > If this is on a client machine for its own computer account I would > think of adding it to the local user database, if you have to distribute > it via LDAP you'll have to create actual user accounts ion the directory > I guess. > > Simo. yes distributed, yes but where, just where all users go: cn=users,cn=accounts or some other container perhaps? I don't suppose ipa host* tool would be the means to put these computers where "regular" hosts go? mthx. L From slaznick at redhat.com Thu Nov 24 15:54:55 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Thu, 24 Nov 2016 16:54:55 +0100 Subject: [Freeipa-users] ipalib authentication In-Reply-To: <81A0EC2E-7489-49C6-8480-768DA022321E@jisc.ac.uk> References: <81A0EC2E-7489-49C6-8480-768DA022321E@jisc.ac.uk> Message-ID: <393ca78c-d4d2-2932-3bb1-d39a85498cb3@redhat.com> On 11/24/2016 04:27 PM, Adam Bishop wrote: > I'm writing a bit of code using ipalib directly, I'm a little stuck on authentication though. > > It works fine if grab a Kerberos ticket with kinit then run the code interactively, but I'd like to run this as a daemon which makes maintaining a ticket tricky. > > What other options are there for authenticating to the API, avoiding calling external tools like curl or kinit? > > Regards, > > Adam Bishop > > gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 > > jisc.ac.uk > > Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc?s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. > > Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. > > Hello Adam, Nice to see someone interested in FreeIPA development. For questions about developing FreeIPA, feel free to contact other developers at freeipa-devel at redhat.com (in CC). You can also create a pull request on GitHub (https://github.com/freeipa/freeipa) if you'd like to share your code with the community. As for your question, would it be feasible to use keytabs? Sure, you still have to perform kinit but there's no user action required (except for maintaining the keytab, of course). Standa From abokovoy at redhat.com Thu Nov 24 15:57:08 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 24 Nov 2016 17:57:08 +0200 Subject: [Freeipa-users] ipalib authentication In-Reply-To: <81A0EC2E-7489-49C6-8480-768DA022321E@jisc.ac.uk> References: <81A0EC2E-7489-49C6-8480-768DA022321E@jisc.ac.uk> Message-ID: <20161124155708.n7ro2bkuwvr4wkiz@redhat.com> On to, 24 marras 2016, Adam Bishop wrote: >I'm writing a bit of code using ipalib directly, I'm a little stuck on >authentication though. > >It works fine if grab a Kerberos ticket with kinit then run the code >interactively, but I'd like to run this as a daemon which makes >maintaining a ticket tricky. > >What other options are there for authenticating to the API, avoiding >calling external tools like curl or kinit? Python API right now only accepts Kerberos ticket. I think we have a ticket to improve on this but right now your options are limited. -- / Alexander Bokovoy From mbasti at redhat.com Thu Nov 24 16:17:28 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 24 Nov 2016 17:17:28 +0100 Subject: [Freeipa-users] ipalib authentication In-Reply-To: <20161124155708.n7ro2bkuwvr4wkiz@redhat.com> References: <81A0EC2E-7489-49C6-8480-768DA022321E@jisc.ac.uk> <20161124155708.n7ro2bkuwvr4wkiz@redhat.com> Message-ID: <51a680ff-2545-df47-2adf-5f0497dcec20@redhat.com> On 24.11.2016 16:57, Alexander Bokovoy wrote: > On to, 24 marras 2016, Adam Bishop wrote: >> I'm writing a bit of code using ipalib directly, I'm a little stuck on >> authentication though. >> >> It works fine if grab a Kerberos ticket with kinit then run the code >> interactively, but I'd like to run this as a daemon which makes >> maintaining a ticket tricky. >> >> What other options are there for authenticating to the API, avoiding >> calling external tools like curl or kinit? > Python API right now only accepts Kerberos ticket. > > I think we have a ticket to improve on this but right now your options > are limited. Might be possible to use python-gssapi and kinit_keytab function instead of kinit command? Martin^2 From cheimes at redhat.com Thu Nov 24 16:18:41 2016 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 24 Nov 2016 17:18:41 +0100 Subject: [Freeipa-users] ipalib authentication In-Reply-To: <81A0EC2E-7489-49C6-8480-768DA022321E@jisc.ac.uk> References: <81A0EC2E-7489-49C6-8480-768DA022321E@jisc.ac.uk> Message-ID: On 2016-11-24 16:27, Adam Bishop wrote: > I'm writing a bit of code using ipalib directly, I'm a little stuck on authentication though. > > It works fine if grab a Kerberos ticket with kinit then run the code interactively, but I'd like to run this as a daemon which makes maintaining a ticket tricky. > > What other options are there for authenticating to the API, avoiding calling external tools like curl or kinit? Hi Adam, for a service you can use a Kerberos keytab to authenticate. A keytab can be requested with ipa-getkeytab. The command will replace the password of the service with a random one. In order to use the keytab file from ipalib, simple set the env var KRB5_CLIENT_KTNAME [1] to the absolute filename of the keytab file. You can set it any time before you initialize FreeIPA's API. GSSAPI will automatically pick up the keytab and use the first principal to authenticate. Christian https://web.mit.edu/kerberos/krb5-1.14/doc/admin/env_variables.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From peljasz at yahoo.co.uk Thu Nov 24 16:19:03 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 24 Nov 2016 16:19:03 +0000 Subject: [Freeipa-users] can(should) IPA issue/manage certificates... Message-ID: <2b8a2abe-5668-56c8-9d4e-0749ca279181@yahoo.co.uk> .. for entities outside of it's own domain? Would you use IPA this way? I'm thinking - it would be nice that have one central point(console) and manage all my "virtual" domains certification, but, I'm not an expert on the subject. And if yes then what would be the steps? mthx, L. From Adam.Bishop at jisc.ac.uk Thu Nov 24 16:41:26 2016 From: Adam.Bishop at jisc.ac.uk (Adam Bishop) Date: Thu, 24 Nov 2016 16:41:26 +0000 Subject: [Freeipa-users] ipalib authentication In-Reply-To: References: <81A0EC2E-7489-49C6-8480-768DA022321E@jisc.ac.uk> Message-ID: <1BBA2A2A-A628-42CC-87CA-4EBB6CA7A7A4@jisc.ac.uk> On 24 Nov 2016, at 16:18, Christian Heimes wrote: > for a service you can use a Kerberos keytab to authenticate. A keytab > can be requested with ipa-getkeytab. The command will replace the > password of the service with a random one. Thanks everyone, I think using a key tab will be fine; having a manual step for initial configuration is not a huge burden. I'll take a look at python-gssapi too. Thanks again, Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc?s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800. From freeipa at jacobdevans.com Thu Nov 24 16:56:36 2016 From: freeipa at jacobdevans.com (Jake) Date: Thu, 24 Nov 2016 11:56:36 -0500 (EST) Subject: [Freeipa-users] Can't establish a trust to AD In-Reply-To: <1479991730.5392.61.camel@rto.de> References: <1479991730.5392.61.camel@rto.de> Message-ID: <4945192.1516.1480006596124@lux.jacobdevans.com> 4.2 is a one-way trust, by design. http://www.freeipa.org/page/V4/One-way_trust -Jake From: "Denis M?ller" To: "freeipa-users" Sent: Thursday, November 24, 2016 7:48:50 AM Subject: [Freeipa-users] Can't establish a trust to AD Hello Guys, we need help to establish a trust from freeipa to ad. Ad users should be able to access to linux environment, but linux users not to ad environment. our setup: AD Domain: domain.com, there we have two AD-Controllers installed wird Windows Server 2008. All users are managed here. IPA Domain: wop.domain.com. We would like to sync users from ad to a specific group to provide user-management in linux environments. In this subdomain we have 2 ipa-servers: ipa01.wop.domain.com and ipa02.domain.com Ipa version on both servers is: VERSION: 4.2.0, API_VERSION: 2.156 Both serves have "ipa-server-trust-ad" installed. [ [ mailto:root at ipa01 | root at ipa01 ] ~]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful kinit admin works as expected ! DNS konfiguration: IPA-Side: [ [ mailto:root at ipa01 | root at ipa01 ] ~]# dig +short -t SRV _kerberos._udp.wop.domain.com 0 100 88 ipa02.wop.domain.com. 0 100 88 ipa01.wop.domain.com. [ mailto:root at ipa01 | root at ipa01 ] ~]# dig +short -t TXT _kerberos.wop.domain.com "WOP.DOMAIN.COM" [ [ mailto:root at ipa01 | root at ipa01 ] ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.wop.domain.com. 0 100 88 ipa02.wop.domain.com. 0 100 88 ipa01.wop.domain.com. [ [ mailto:root at ipa01 | root at ipa01 ] ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.wop.domain.com. 0 100 88 ipa01.wop.domain.com. 0 100 88 ipa02.wop.domain.com. AD-Side: C:\Users\demueller>nslookup Standardserver: dc2.domain.com Address: 192.168.3.9 > set type=SRV > _kerberos._udp.wop.domain.com. Server: dc2.domain.com Address: 192.168.3.9 Nicht autorisierende Antwort: _kerberos._udp.wop.domain.com SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipa01.wop.domainc.om _kerberos._udp.wop.rto.de SRV service location: priority = 0 weight = 100 port = 88 svr hostname = ipa02.wop.domain.com ipa01.wop.domain.com internet address = 192.168.11.75 ipa02.wop.domainc.om internet address = 192.168.11.106 DNS looks fine, firewall too. Providing trust:ipa trust-add --type=ad rto.de --trust-secret --server=dc2.domain.com As a Result: [ [ mailto:root at ipa01 | root at ipa01 ] ~]# ipa trustdomain-find domain.com Domain name: domain.com Domain NetBIOS name: DOMAIN (It should be DC2, right?) Domain Security Identifier: S-1-5-21-746137067-2052111302-1801674531 Domain enabled: True ------------------------------------- ipa trust-fetch-domain domain.com Logging: [Thu Nov 24 13:43:44.167918 2016] [:error] [pid 9123] ipa: INFO: [jsonserver_session] [ file://admin%40wop.domain/ | admin at WOP.DOMAIN ] .COM: ping(): SUCCESS [Thu Nov 24 13:43:44.306718 2016] [:error] [pid 9124] ipa: INFO: [jsonserver_session] [ file://admin%40wop.domain/ | admin at WOP.DOMAIN ] .COM: trustdomain_find(u'domain.com', None, all=False, raw=False, version=u'2.156', pkey_only=False): SUCCESS [Thu Nov 24 13:45:16.662862 2016] [:error] [pid 9123] ipa: INFO: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm 'WOP.DOMAIN.COM) I can't understand the problem. On AD side we create a trust certifiacte as explained hear: [ http://www.freeipa.org/page/Active_Directory_trust_setup | http://www.freeipa.org/page/Active_Directory_trust_setup ] -- 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 peljasz at yahoo.co.uk Thu Nov 24 17:14:06 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 24 Nov 2016 17:14:06 +0000 Subject: [Freeipa-users] error; Allocation of a new value Message-ID: <9da362de-b66f-c7a4-1c7d-2016ee46f013@yahoo.co.uk> hi I see this: 2 ranges matched ---------------- Range name: xx.id_range First Posix ID of the range: 1952400000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-1144915091-2252175215-702530032 Range type: Active Directory domain range Range name: xx.xx.xx.xx.x_id_range First Posix ID of the range: 1875000000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range ---------------------------- Number of entries returned 2 some time ago when I first set up IPA I migrated users from samba3's ldap backend. Since then until today there was no new users I needed to add but now I do. First on the list range I think it is a remnant of AD trust which does not exists any more (should it be removed?). I'm not sure how to read those ranges info, one thing I notice is that UIDs from migration are probably between 500 & 2000 and now if I supply uid manually to user-add and gid (which is old Samba's domain users group) then creation of new user succeeds. Is this normal, expected? mthx, L From abokovoy at redhat.com Thu Nov 24 17:30:06 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 24 Nov 2016 19:30:06 +0200 Subject: [Freeipa-users] Can't establish a trust to AD In-Reply-To: <1479991730.5392.61.camel@rto.de> References: <1479991730.5392.61.camel@rto.de> Message-ID: <20161124173006.se7y3ysdapcv6gso@redhat.com> On to, 24 marras 2016, Denis M?ller wrote: >Hello Guys, we need help to establish a trust from freeipa to ad. Ad >users should be able to access to linux environment, but linux users >not to ad environment. > >our setup: > >AD Domain: >domain.com, there we have two AD-Controllers installed wird Windows >Server 2008. All users are managed here. > >IPA Domain: >wop.domain.com. We would like to sync users from ad to a specific group >to provide user-management in linux environments. In this subdomain we >have 2 ipa-servers: ipa01.wop.domain.com and ipa02.domain.com > >Ipa version on both servers is: VERSION: 4.2.0, API_VERSION: 2.156 > >Both serves have "ipa-server-trust-ad" installed. > >[root at ipa01 ~]# ipactl status >Directory Service: RUNNING >krb5kdc Service: RUNNING >kadmin Service: RUNNING >named Service: RUNNING >ipa_memcached Service: RUNNING >httpd Service: RUNNING >pki-tomcatd Service: RUNNING >smb Service: RUNNING >winbind Service: RUNNING >ipa-otpd Service: RUNNING >ipa-dnskeysyncd Service: RUNNING >ipa: INFO: The ipactl command was successful > >kinit admin works as expected ! > > > >DNS konfiguration: >IPA-Side: > >[root at ipa01 ~]# dig +short -t SRV _kerberos._udp.wop.domain.com >0 100 88 ipa02.wop.domain.com. >0 100 88 ipa01.wop.domain.com. > >root at ipa01 ~]# dig +short -t TXT _kerberos.wop.domain.com >"WOP.DOMAIN.COM" > >[root at ipa01 ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.wop.domain.com. >0 100 88 ipa02.wop.domain.com. >0 100 88 ipa01.wop.domain.com. > >[root at ipa01 ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.wop.domain.com. >0 100 88 ipa01.wop.domain.com. >0 100 88 ipa02.wop.domain.com. > >AD-Side: > >C:\Users\demueller>nslookup >Standardserver: dc2.domain.com >Address: 192.168.3.9 > >> set type=SRV >> _kerberos._udp.wop.domain.com. >Server: dc2.domain.com >Address: 192.168.3.9 > >Nicht autorisierende Antwort: >_kerberos._udp.wop.domain.com SRV service location: > priority = 0 > weight = 100 > port = 88 > svr hostname = ipa01.wop.domainc.om >_kerberos._udp.wop.rto.de SRV service location: > priority = 0 > weight = 100 > port = 88 > svr hostname = ipa02.wop.domain.com > >ipa01.wop.domain.com internet address = 192.168.11.75 >ipa02.wop.domainc.om internet address = 192.168.11.106 > >DNS looks fine, firewall too. > >Providing trust:ipa trust-add --type=ad rto.de --trust-secret --server=dc2.domain.com > >As a Result: > >[root at ipa01 ~]# ipa trustdomain-find domain.com > Domain name: domain.com > Domain NetBIOS name: DOMAIN (It should be DC2, right?) > Domain Security Identifier: S-1-5-21-746137067-2052111302-1801674531 > Domain enabled: True >------------------------------------- > > >ipa trust-fetch-domain domain.com > >Logging: > >[Thu Nov 24 13:43:44.167918 2016] [:error] [pid 9123] ipa: INFO: [jsonserver_session] admin at WOP.DOMAIN.COM: ping(): SUCCESS >[Thu Nov 24 13:43:44.306718 2016] [:error] [pid 9124] ipa: INFO: [jsonserver_session] admin at WOP.DOMAIN.COM: trustdomain_find(u'domain.com', None, all=False, raw=False, version=u'2.156', pkey_only=False): SUCCESS >[Thu Nov 24 13:45:16.662862 2016] [:error] [pid 9123] ipa: INFO: 401 >Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI >Error: Unspecified GSS failure. Minor code may provide more >information (Cannot contact any KDC for realm 'WOP.DOMAIN.COM) > >I can't understand the problem. It looks like IPA master's Kerberos configuration does not allow to resolve KDCs of unknown realms via DNS. What do you have in /etc/krb5.conf in the [libdefaults] section: dns_lookup_realm = false dns_lookup_kdc = false or dns_lookup_realm = true dns_lookup_kdc = true ? See manual page for krb5.conf for details on these options. >On AD side we create a trust certifiacte as explained hear: >http://www.freeipa.org/page/Active_Directory_trust_setup I'm not sure what do you mean by 'trust certificate', there is no such thing and no such requirement. -- / Alexander Bokovoy From peljasz at yahoo.co.uk Thu Nov 24 18:30:39 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 24 Nov 2016 18:30:39 +0000 Subject: [Freeipa-users] error; Allocation of a new value In-Reply-To: <9da362de-b66f-c7a4-1c7d-2016ee46f013@yahoo.co.uk> References: <9da362de-b66f-c7a4-1c7d-2016ee46f013@yahoo.co.uk> Message-ID: On 24/11/16 17:14, lejeczek wrote: > hi > > I see this: > > 2 ranges matched > ---------------- > Range name: xx.id_range > First Posix ID of the range: 1952400000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 0 > Domain SID of the trusted domain: > S-1-5-21-1144915091-2252175215-702530032 > Range type: Active Directory domain range > > Range name: xx.xx.xx.xx.x_id_range > First Posix ID of the range: 1875000000 > Number of IDs in the range: 200000 > First RID of the corresponding RID range: 1000 > First RID of the secondary RID range: 100000000 > Range type: local domain range > ---------------------------- > Number of entries returned 2 > > some time ago when I first set up IPA I migrated users > from samba3's ldap backend. Since then until today there > was no new users I needed to add but now I do. > First on the list range I think it is a remnant of AD > trust which does not exists any more (should it be removed?). > I'm not sure how to read those ranges info, one thing I > notice is that UIDs from migration are probably between > 500 & 2000 and now if I supply uid manually to user-add > and gid (which is old Samba's domain users group) then > creation of new user succeeds. > Is this normal, expected? > > mthx, > L > ok, solution(ldapmodify) to the problem: https://www.redhat.com/archives/freeipa-users/2014-February/msg00246.html but could some experts shed more light on it - I see that some time ago(after migration/import) I actually created manually a user: $ id netdevadmin uid=1875000006(netdevadmin) gid=1875000006(netdevadmin) groups=1875000006(netdevadmin) today, after ldapmodify I create a new user but uids seem to come from (what?) a different range?? $ id appmgr uid=3501(appmgr) gid=3501(appmgr) groups=3501(appmgr) what's is happening? regards L From ftweedal at redhat.com Fri Nov 25 03:18:40 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 25 Nov 2016 13:18:40 +1000 Subject: [Freeipa-users] can(should) IPA issue/manage certificates... In-Reply-To: <2b8a2abe-5668-56c8-9d4e-0749ca279181@yahoo.co.uk> References: <2b8a2abe-5668-56c8-9d4e-0749ca279181@yahoo.co.uk> Message-ID: <20161125031840.GM8861@dhcp-40-8.bne.redhat.com> On Thu, Nov 24, 2016 at 04:19:03PM +0000, lejeczek wrote: > .. for entities outside of it's own domain? > Would you use IPA this way? > > I'm thinking - it would be nice that have one central point(console) and > manage all my "virtual" domains certification, but, I'm not an expert on the > subject. > And if yes then what would be the steps? > Can IPA manage certs for "external" entities? No. Should it be able to? Maybe. There have been some preliminary discussions about use cases and how it could be implemented. Do you want to elaborate on your use case? (Bear in mind that, unless your IPA CA is chained to a publicly trusted CA, certs issued by it will not be publicly trusted.) Cheers, Fraser > mthx, > 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 From tk at mdevsys.com Fri Nov 25 04:57:16 2016 From: tk at mdevsys.com (TomK) Date: Thu, 24 Nov 2016 23:57:16 -0500 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> <97e67d02-a736-239e-0d65-5ce551454a1f@mdevsys.com> <2837abb4-3605-1946-e752-a09b289439c5@redhat.com> <731bb495-e534-8581-9da4-ae57f9f6b466@mdevsys.com> Message-ID: <0c386e0e-dce9-d1b1-960c-d91690fbbc9f@mdevsys.com> On 11/24/2016 4:49 AM, Petr Spacek wrote: > On 24.11.2016 06:08, TomK wrote: >> On 11/23/2016 3:28 AM, Martin Basti wrote: >>> >>> >>> On 23.11.2016 03:48, TomK wrote: >>>> On 11/22/2016 10:22 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 22.11.2016 13:57, TomK wrote: >>>>>> On 11/22/2016 2:59 AM, Martin Basti wrote: >>>>>>> Hey, >>>>>>> >>>>>>> >>>>>>> On 22.11.2016 06:33, TomK wrote: >>>>>>>> Hey Guy's, >>>>>>>> >>>>>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 >>>>>>>> over to >>>>>>>> my dual Free IPA server. The Free IPA servers are authoritative for >>>>>>>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>>>>>>> and forwards dom.abc.xyz. >>>>>>> Do you have configured proper zone delegation for subdomain >>>>>>> dom.abc.xyz? >>>>>>> Proper NS and glue records >>>>>>> http://www.zytrax.com/books/dns/ch9/delegate.html >>>>>>> >>>>>>>> >>>>>>>> I cannot ping dom.abc.xyz. Everything else, including client >>>>>>>> registrations, work fine. If Free IPA is authoritative on >>>>>>>> dom.abc.xyz, should it not create DNS entries so the sub domain >>>>>>>> can be >>>>>>>> pinged as well? >>>>>>> >>>>>>> What do you mean by "ping"? >>>>>>> >>>>>>>> >>>>>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>>>>>>> and wanted to ask if you can point me to some materials online to >>>>>>>> determine where can I permanently adjust the search to add >>>>>>>> dom.abc.xyz >>>>>>>> to the already present abc.xyz . I wasn't able to locate what I >>>>>>>> needed in my searches. >>>>>>>> >>>>>>>> I'm using the latest v4. >>>>>>> >>>>>>> It depends on what are you using, probably you have NetworkManager >>>>>>> there >>>>>>> that is editing /etc/resolv.conf >>>>>>> >>>>>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Martin >>>>>> >>>>>> >>>>>> I Uninstalled NetworkManager. Still changes. >>>>>> ping dom.abc.com results in "ping: unknown host" >>>>>> >>>>>> I'll have a look at the first link, ty. >>>>>> >>>>> >>>>> ping (ICMP protocol) and DNS system are different things, do you have >>>>> hostname dom.abc.com with A record or it is a zone? >>>>> >>>>> with ping command hostname "dom.abc.com" is resolved to IP address >>>>> first, do you have A record set for dom.abc.com in zone apex or what are >>>>> you trying to achieve with ping command? >>>>> >>>>> for testing DNS try to use commands: dig, host, nslookup >>>>> >>>>> Martin >>>>> >>>> >>>> Apologize for the long reply but it should give some background on >>>> what it is that I'm doing. >>>> >>>> 1) dom.abc.com is a zone. There is no A record for dom.abc.com in >>>> FreeIPA (Confirmed by Petr). I get the point Petr Spacek pointed out >>>> in his comment as well. What should it really point too? ( I kind of >>>> answer this question below so please read on. ) Where I'm getting >>>> this from is that in Windows Server 2012 abc.com returns the IP of any >>>> of the participating AD / DNS servers within the cluster (The two >>>> Windows Server 2012 are a combined clustered AD + DNS servers.). >>>> Being able to resolve abc.xyz is handy. During a lookup, I can get a >>>> list of all the IP's associated with that domain which would indicate >>>> all the DNS + AD servers online under that domain or serving that domain: >>>> >>>> >>>> # nslookup abc.xyz >>>> Server: 192.168.0.3 >>>> Address: 192.168.0.3#53 >>>> >>>> Name: abc.xyz >>>> Address: 192.168.0.3 >>>> Name: abc.xyz >>>> Address: 192.168.0.1 >>>> Name: abc.xyz >>>> Address: 192.168.0.2 >>>> # >>>> >>>> Again, where this is handy is when configuring sssd.conf for example >>>> or other apps for that matter. I can just point the app to >>>> authenticate against the domain and I have my redundancy solved. >>>> Windows Server 2012 does it, but FreeIPA didn't, so I threw the >>>> question out there. >>> >>> IPA uses SRV records heavily, all IPA related services have SRV records, >>> SSSD uses SRV records of IPA, client should use SRV record to connect to >>> the right service (or URI record - will be in next IPA). SRV records >>> work for IPA locations mechanism, we cannot achieve this with pure A >>> records. >>> >>>> >>>> Delegation from this Windows DNS works as expected. Any lookup from >>>> dom.abc.xyz is forwarded too and handled by FreeIPA servers. Tested >>>> this out. No issue with this. >>>> >>>> I did see earlier that there is no A record for dom.abc.xyz in >>>> FreeIPA. My reasons for asking if there was an IP on the subdomain in >>>> FreeIPA were above but the missing IP on the subdomain isn't a major >>>> issue for me. Things are working without dom.abc.xyz resolving to an >>>> IP. What I was hoping for is to have a VIP for the IPA servers and >>>> one for the Windows Server 2012 DNS Cluster in /etc/resolv.conf. (I >>>> have the VIP for the windows server). One forwarding to the other for >>>> a given domain. This is all for testing a) redundancy, b) forwarding, >>>> a) authentication . >>>> >>>> IE: >>>> >>>> # cat /etc/resolv.conf >>>> search dom.abc.xyz abc.xyz >>>> nameserver 192.168.0.3 <------------ Win Cluster DNS VIP >>>> nameserver 192.168.0.4 <------------ IPA Cluster DNS VIP >>>> >>>> * Just what I want to achieve above. VIP 192.168.0.4 doesn't exist on >>>> my cluster yet. I'm looking to integrate ucarp with the above IPA >>>> servers. >>>> >>>> >>>> 2) More to the topic of my second question however, is that >>>> /etc/resolv.conf, on the IPA servers themselves, get's rewritten on >>>> restart. Would like to know by what if I already uninstalled >>>> NetworkManager? When I configured the FreeIPA server, I used: >>>> >>>> ipa-server-install --setup-dns --forwarder=192.168.0.3 -p "Hush!" -a >>>> "Hush!" -r DOM.ABC.XYZ -n dom.abc.xyz --hostname ipa01.dom.abc.xyz >>>> >>>> Notice I used the VIP of the Windows Server 2012 Cluster when >>>> installing FreeIPA. This is nice for redundancy. So the resolv.conf >>>> ends up being: >>>> >>>> # cat /etc/resolv.conf >>>> # Generated by NetworkManager >>>> search abc.xyz >>>> nameserver 192.168.0.3 >>>> nameserver 123.123.123.1 >>>> nameserver 123.123.123.2 >>>> >>>> Then I add: >>>> >>>> search dom.abc.xyz abc.xyz >>>> >>>> but it changes back to search abc.xyz (the Windows Server 2012 DNS). >>>> This all works, except for the above minor items, and I can resolve >>>> anything over this network. ( Thinking this is fine because the >>>> forward is on the subdomain. I haven't had issues with forwarding >>>> through this setup. ) >>>> >>>> # cat /etc/resolv.conf >>>> # Generated by NetworkManager >>>> search abc.xyz >>>> nameserver 192.168.0.3 >>>> nameserver 123.123.123.1 >>>> nameserver 123.123.123.2 >>>> >>>> But NetworkManager is not installed on these IPA servers. I've >>>> removed it earlier: >>>> >>>> # rpm -aq|grep -i NetworkManager >>>> # >>>> >>>> Is FreeIPA replacing /etc/resolv.conf with a copy it keeps elsewhere? >>> >>> On servers with DNS /etc/resolv.conf should point to 127.0.0.1 and ::1, >>> and global or per server dns forwarders should be configured instead >>> >>> Have you properly stopped NetworkManager using systemctl stop and >>> systemctl disable ? In case you just removed rpm files service can still >>> work. >>> I recommend to update network manager config, not to remove it :) >>> >>> As last resort way, you can set immutable bit to resolv.conf if >>> something is still changing your resolv.conf file >>> >>>> >>>> 3) After running: >>>> >>>> ipa-client-install --mkhomedir --enable-dns-updates >>>> >>>> on a new host, the hostname of the new host doesn't resolve for a few >>>> minutes. How do I make this instantaneous? (Other then that, >>>> autodiscovery of the IPA servers is excellent!). Before installing >>>> the IPA Client, the new hosts /etc/resolv.conf file looks like this: >>>> >>>> # cat /etc/resolv.conf >>>> search abc.xyz >>>> nameserver 192.168.0.3 >>>> nameserver 123.123.123.1 >>>> nameserver 123.123.123.2 >>>> >>>> I did dig, host, nslookup earlier. Verified all except for the items >>>> I'm inquiring about. >>>> >>> >>> That weird, because ipa-client-install creates A records directly to DNS >>> server using nsupdate, so it should be accessible instantly. Do you have >>> any caching DNS servers? >>> >>> Martin >>> >> >> No caching DNS servers. >> >> On the topic of NetworkManager. It's completely gone yet still the >> /etc/resolv.conf file is being replaced with the text # Generated by >> NetworkManager. >> >> # systemctl show NetworkManager.service --property=Id,Names,Description >> Id=NetworkManager.service >> Names=NetworkManager.service >> Description=NetworkManager.service >> # >> >> # systemctl list-units --type service --all|grep -i network >> network.service loaded active exited LSB: Bring >> up/down networking >> ? NetworkManager-wait-online.service not-found inactive dead >> NetworkManager-wait-online.service >> ? NetworkManager.service not-found inactive dead >> NetworkManager.service >> ntpd.service loaded active running Network >> Time Service >> rhel-domainname.service loaded active exited Read and >> set NIS domainname from /etc/sysconfig/network >> rhel-import-state.service loaded active exited Import >> network configuration from initramfs >> # >> >> >> The only thing that is left of the NetworkManager service is the above. >> Nothing I type from systemd removed it completely. So I've reverted to the >> last resort: >> >> # lsattr /etc/resolv.conf >> ----i----------- /etc/resolv.conf >> # >> >> With the above, I'm trying to see what's writing to the file by using this >> auditctl and found that postfix seems to be doing this: >> >> ---- >> time->Wed Nov 23 23:14:47 2016 >> type=PATH msg=audit(1479960887.978:293): item=0 name="/etc/resolv.conf" >> inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 >> obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >> type=CWD msg=audit(1479960887.978:293): cwd="/" >> type=SYSCALL msg=audit(1479960887.978:293): arch=c000003e syscall=2 >> success=yes exit=4 a0=7ffb36b6f43a a1=80000 a2=1b6 a3=24 items=1 ppid=1 >> pid=5527 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >> fsgid=0 tty=(none) ses=4294967295 comm="postfix" exe="/usr/sbin/postfix" >> subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" >> ---- >> time->Wed Nov 23 23:14:48 2016 >> type=PATH msg=audit(1479960888.013:301): item=0 name="/etc/resolv.conf" >> inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 >> obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >> type=CWD msg=audit(1479960888.013:301): cwd="/var/spool/postfix" >> type=SYSCALL msg=audit(1479960888.013:301): arch=c000003e syscall=2 >> success=yes exit=3 a0=7f32c163043a a1=80000 a2=1b6 a3=24 items=1 ppid=5545 >> pid=5546 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >> fsgid=0 tty=(none) ses=4294967295 comm="postconf" exe="/usr/sbin/postconf" >> subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" > > It usually helps to run ausearch -i, it translates numberic codes to names. > > Assuming you are running Linux on x86_64, it would be interpreted like this: > > ---- > type=SYSCALL msg=audit(24.11.2016 05:14:47.978:293) : arch=x86_64 syscall=open > success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 > items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root > fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix > exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 > key=/root/resolv.conf-file > type=CWD msg=audit(24.11.2016 05:14:47.978:293) : cwd=/ > type=PATH msg=audit(24.11.2016 05:14:47.978:293) : item=0 > name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL > ---- > type=SYSCALL msg=audit(24.11.2016 05:14:48.013:301) : arch=x86_64 syscall=open > success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 > items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root > fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf > exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 > key=/root/resolv.conf-file > type=CWD msg=audit(24.11.2016 05:14:48.013:301) : cwd=/var/spool/postfix > type=PATH msg=audit(24.11.2016 05:14:48.013:301) : item=0 > name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL > > > In other words, /root/resolv.conf-file is open for reading. > > It is interesting ... What does the file contain? > > Petr^2 Spacek > > >> >> This in turn appears to be called by started by: >> >> # grep postfix access|tail -n 1 >> [23/Nov/2016:23:42:04 -0500] conn=34 op=5 SRCH >> base="cn=accounts,dc=dom,dc=abc,dc=xyz" scope=2 >> filter="(&(uid=postfix)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))" >> attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory >> loginShell krbPrincipalName cn memberOf ipaUniqueID ipaNTSecurityIdentifier >> modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning >> shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration >> pwdattribute authorizedService accountexpires useraccountcontrol nsAccountLock >> host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey >> ipaUserAuthType usercertificate;binary" >> # pwd >> /var/log/dirsrv/slapd-DOM-ABC-XYZ root/resolv.conf-file is only a identifier (key) by which auditctl marked events that occurred on /etc/resolv.conf. In other words, it was just a custom assigned identifier I used that read / write requests got tagged with. I really should have called it 'resolv-conf-identifier' or similar to avoid confusion. It's not a file. The commands I used to watch the file are: /sbin/ausearch -f /etc/resolv.conf -key=/root/resolv.conf-file Then to get events: /sbin/ausearch -f /etc/resolv.conf --key "/root/resolv.conf-file" Adding the -i as per your note, I get this: [root at idmipa01 ~]# /sbin/ausearch -f /etc/resolv.conf --key "/root/resolv.conf-file" -i ---- type=PATH msg=audit(11/23/2016 23:14:04.708:287) : item=0 name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(11/23/2016 23:14:04.708:287) : cwd=/var/log/dirsrv/slapd-NIX-MDS-XYZ type=SYSCALL msg=audit(11/23/2016 23:14:04.708:287) : arch=x86_64 syscall=open success=yes exit=53 a0=0x7f66d82c243a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 items=1 ppid=1 pid=5080 auid=unset uid=dirsrv gid=dirsrv euid=dirsrv suid=dirsrv fsuid=dirsrv egid=dirsrv sgid=dirsrv fsgid=dirsrv tty=(none) ses=unset comm=ns-slapd exe=/usr/sbin/ns-slapd subj=system_u:system_r:dirsrv_t:s0 key=/root/resolv.conf-file ---- type=PATH msg=audit(11/23/2016 23:14:32.182:288) : item=0 name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(11/23/2016 23:14:32.182:288) : cwd=/var/log/audit type=SYSCALL msg=audit(11/23/2016 23:14:32.182:288) : arch=x86_64 syscall=open success=yes exit=3 a0=0x7fffd2fa47ff a1=O_RDONLY|O_NONBLOCK a2=0x7fffd2fa2f00 a3=0x7fffd2fa2c70 items=1 ppid=2389 pid=5511 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=chattr exe=/usr/bin/chattr subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=/root/resolv.conf-file ---- type=PATH msg=audit(11/23/2016 23:14:32.182:289) : item=0 name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(11/23/2016 23:14:32.182:289) : cwd=/var/log/audit type=SYSCALL msg=audit(11/23/2016 23:14:32.182:289) : arch=x86_64 syscall=open success=yes exit=3 a0=0x7fffd2fa47ff a1=O_RDONLY|O_NONBLOCK a2=0x7fffd2fa2f00 a3=0x7fffd2fa2d50 items=1 ppid=2389 pid=5511 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=chattr exe=/usr/bin/chattr subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=/root/resolv.conf-file ---- type=PATH msg=audit(11/23/2016 23:14:36.847:290) : item=0 name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(11/23/2016 23:14:36.847:290) : cwd=/var/log/audit type=SYSCALL msg=audit(11/23/2016 23:14:36.847:290) : arch=x86_64 syscall=open success=yes exit=3 a0=0x7fff791a17ff a1=O_RDONLY|O_NONBLOCK a2=0x7fff791a0180 a3=0x7fff7919fef0 items=1 ppid=2389 pid=5512 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 comm=lsattr exe=/usr/bin/lsattr subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=/root/resolv.conf-file ---- type=PATH msg=audit(11/23/2016 23:14:47.978:293) : item=0 name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(11/23/2016 23:14:47.978:293) : cwd=/ type=SYSCALL msg=audit(11/23/2016 23:14:47.978:293) : arch=x86_64 syscall=open success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 key=/root/resolv.conf-file ---- type=PATH msg=audit(11/23/2016 23:14:48.013:301) : item=0 name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=CWD msg=audit(11/23/2016 23:14:48.013:301) : cwd=/var/spool/postfix type=SYSCALL msg=audit(11/23/2016 23:14:48.013:301) : arch=x86_64 syscall=open success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 key=/root/resolv.conf-file [root at idmipa01 ~]# -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From tk at mdevsys.com Fri Nov 25 05:15:00 2016 From: tk at mdevsys.com (TomK) Date: Fri, 25 Nov 2016 00:15:00 -0500 Subject: [Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads? In-Reply-To: References: <582B38AF.6010407@sonsorol.org> <9518896f-2be2-85a8-17e7-16ca5851e613@redhat.com> Message-ID: <6694be29-dcce-1562-eec7-130ee3059d7f@mdevsys.com> On 11/16/2016 11:23 AM, Sean Hogan wrote: > Yes... just got 2 of them from same address.. kimi rachel > > > > > > Sean Hogan > > > > > > > > Inactive hide details for Tony Brian Albers ---11/15/2016 11:54:35 > PM---Hehe, just you wait Lachlan ;) /tonyTony Brian Albers ---11/15/2016 > 11:54:35 PM---Hehe, just you wait Lachlan ;) /tony > > From: Tony Brian Albers > To: "freeipa-users at redhat.com" > Date: 11/15/2016 11:54 PM > Subject: Re: [Freeipa-users] anyone else getting porn spam pretending to > be replies to freeipa-users threads? > Sent by: freeipa-users-bounces at redhat.com > > ------------------------------------------------------------------------ > > > > Hehe, just you wait Lachlan ;) > > /tony > > On 11/16/2016 01:56 AM, Lachlan Musicman wrote: >> Gah, just happened to me. Wasn't porn, but was someone called Kimi and >> the only content was "Heeey Lachlan, how's it going?" >> >> L. >> >> ------ >> The most dangerous phrase in the language is, "We've always done it this >> way." >> >> - Grace Hopper >> >> On 16 November 2016 at 04:02, Martin Basti > > wrote: >> >> >> >> On 15.11.2016 17:32, Chris Dagdigian wrote: >> >> >> >> Got a porn spam today that had a subject header of: >> >> Re: [Freeipa-users] URL is changing on the browser >> >> >> Have to admit that got through my spam filter and got me to open >> the email. >> >> It's clear that it was not a list message; looks like something >> may be mining the public list archives to pull email addresses >> and plausible sounding subject lines. >> >> Mildly interested if anyone else got an email like this? >> >> -Chris >> >> >> We are receiving those emails as well (different subjects, domains, >> but the same content) >> >> >> -- >> 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, > > Tony Albers > Systems administrator, IT-development > State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. > Tel: +45 2566 2383 / +45 8946 2316 > > -- > 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 > > > > > > Getting the same. The header is as follows. I've blocked the two for now, to see how effective this would be but previous IP changed again. Mellowhost NET-148-163-124-128-25 (NET-148-163-124-128-1) 148.163.124.128 - 148.163.124.255 Input Output Flood LLC IOFLOOD (NET-148-163-0-0-1) 148.163.0.0 - 148.163.127.255 Return-Path: Received: from m40.bytekeys.com ([148.163.124.181]) by mx.perfora.net (mxeueus003 [74.208.5.3]) with ESMTP (Nemesis) id 0MhTU4-1cMSKS0KOo-00McNU for ; Thu, 24 Nov 2016 11:36:22 +0100 Received: from localhost (unknown [107.178.101.40]) by m40.bytekeys.com (Postfix) with ESMTPSA id BBE4D22E71 for ; Thu, 24 Nov 2016 10:35:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.1 m40.bytekeys.com BBE4D22E71 Date: Thu, 24 Nov 2016 16:35:18 +0600 To: tk at mdevsys.com From: Kimi Rachel Reply-To: Kimi Rachel Subject: Re: Re: [Freeipa-users] Ping forwarded domain name. Message-ID: <62e8e8f685dbfb70eec33b944d962877 at localhost> In-Reply-To: <731bb495-e534-8581-9da4-ae57f9f6b466 at mdevsys.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_62e8e8f685dbfb70eec33b944d962877" Content-Transfer-Encoding: 7bit Envelope-To: -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From d.mueller2 at rto.de Fri Nov 25 07:24:11 2016 From: d.mueller2 at rto.de (=?utf-8?B?RGVuaXMgTcO8bGxlcg==?=) Date: Fri, 25 Nov 2016 07:24:11 +0000 Subject: [Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads? In-Reply-To: <6694be29-dcce-1562-eec7-130ee3059d7f@mdevsys.com> References: <582B38AF.6010407@sonsorol.org> <9518896f-2be2-85a8-17e7-16ca5851e613@redhat.com> <6694be29-dcce-1562-eec7-130ee3059d7f@mdevsys.com> Message-ID: <1480058651.1223.0.camel@rto.de> Yeah, im getting spam too! Denis Am Freitag, den 25.11.2016, 00:15 -0500 schrieb TomK: On 11/16/2016 11:23 AM, Sean Hogan wrote: Yes... just got 2 of them from same address.. kimi rachel Sean Hogan Inactive hide details for Tony Brian Albers ---11/15/2016 11:54:35 PM---Hehe, just you wait Lachlan ;) /tonyTony Brian Albers ---11/15/2016 11:54:35 PM---Hehe, just you wait Lachlan ;) /tony From: Tony Brian Albers > To: "freeipa-users at redhat.com" > Date: 11/15/2016 11:54 PM Subject: Re: [Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads? Sent by: freeipa-users-bounces at redhat.com ------------------------------------------------------------------------ Hehe, just you wait Lachlan ;) /tony On 11/16/2016 01:56 AM, Lachlan Musicman wrote: Gah, just happened to me. Wasn't porn, but was someone called Kimi and the only content was "Heeey Lachlan, how's it going?" L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 16 November 2016 at 04:02, Martin Basti > wrote: On 15.11.2016 17:32, Chris Dagdigian wrote: Got a porn spam today that had a subject header of: Re: [Freeipa-users] URL is changing on the browser Have to admit that got through my spam filter and got me to open the email. It's clear that it was not a list message; looks like something may be mining the public list archives to pull email addresses and plausible sounding subject lines. Mildly interested if anyone else got an email like this? -Chris We are receiving those emails as well (different subjects, domains, but the same content) -- 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, Tony Albers Systems administrator, IT-development State and University Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark. Tel: +45 2566 2383 / +45 8946 2316 -- 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 Getting the same. The header is as follows. I've blocked the two for now, to see how effective this would be but previous IP changed again. Mellowhost NET-148-163-124-128-25 (NET-148-163-124-128-1) 148.163.124.128 - 148.163.124.255 Input Output Flood LLC IOFLOOD (NET-148-163-0-0-1) 148.163.0.0 - 148.163.127.255 Return-Path: > Received: from m40.bytekeys.com ([148.163.124.181]) by mx.perfora.net (mxeueus003 [74.208.5.3]) with ESMTP (Nemesis) id 0MhTU4-1cMSKS0KOo-00McNU for >; Thu, 24 Nov 2016 11:36:22 +0100 Received: from localhost (unknown [107.178.101.40]) by m40.bytekeys.com (Postfix) with ESMTPSA id BBE4D22E71 for >; Thu, 24 Nov 2016 10:35:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.1 m40.bytekeys.com BBE4D22E71 Date: Thu, 24 Nov 2016 16:35:18 +0600 To: tk at mdevsys.com From: Kimi Rachel > Reply-To: Kimi Rachel > Subject: Re: Re: [Freeipa-users] Ping forwarded domain name. Message-ID: <62e8e8f685dbfb70eec33b944d962877 at localhost> In-Reply-To: <731bb495-e534-8581-9da4-ae57f9f6b466 at mdevsys.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_62e8e8f685dbfb70eec33b944d962877" Content-Transfer-Encoding: 7bit Envelope-To: > -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Fri Nov 25 07:52:19 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 25 Nov 2016 08:52:19 +0100 Subject: [Freeipa-users] error; Allocation of a new value In-Reply-To: References: <9da362de-b66f-c7a4-1c7d-2016ee46f013@yahoo.co.uk> Message-ID: <5d001eab-4ff0-90e8-2270-d1eb1262f869@redhat.com> On 11/24/2016 07:30 PM, lejeczek wrote: > > > On 24/11/16 17:14, lejeczek wrote: >> hi >> >> I see this: >> >> 2 ranges matched >> ---------------- >> Range name: xx.id_range >> First Posix ID of the range: 1952400000 >> Number of IDs in the range: 200000 >> First RID of the corresponding RID range: 0 >> Domain SID of the trusted domain: >> S-1-5-21-1144915091-2252175215-702530032 >> Range type: Active Directory domain range >> >> Range name: xx.xx.xx.xx.x_id_range >> First Posix ID of the range: 1875000000 >> Number of IDs in the range: 200000 >> First RID of the corresponding RID range: 1000 >> First RID of the secondary RID range: 100000000 >> Range type: local domain range >> ---------------------------- >> Number of entries returned 2 >> >> some time ago when I first set up IPA I migrated users from samba3's >> ldap backend. Since then until today there was no new users I needed >> to add but now I do. >> First on the list range I think it is a remnant of AD trust which does >> not exists any more (should it be removed?). >> I'm not sure how to read those ranges info, one thing I notice is that >> UIDs from migration are probably between 500 & 2000 and now if I >> supply uid manually to user-add and gid (which is old Samba's domain >> users group) then creation of new user succeeds. >> Is this normal, expected? >> >> mthx, >> L >> > ok, solution(ldapmodify) to the problem: > https://www.redhat.com/archives/freeipa-users/2014-February/msg00246.html > but could some experts shed more light on it - I see that some time > ago(after migration/import) I actually created manually a user: > $ id netdevadmin > uid=1875000006(netdevadmin) gid=1875000006(netdevadmin) > groups=1875000006(netdevadmin) > > today, after ldapmodify I create a new user but uids seem to come from > (what?) a different range?? > $ id appmgr > uid=3501(appmgr) gid=3501(appmgr) groups=3501(appmgr) > > what's is happening? > regards > L > You are seeing this because you probably set dnaMaxValue too low (5000 or so) and, as tha name of the attribute implies, it sets the maximum UID/GID for the range assigned by the plugin. By default, the local IPA ID ranges are set to huge numbers (on my test VMs I have dnaMaxValue 241799999) to aviod collisions with UIDs/GIDs of local users which are typically in the range of thousands/tens of thousands). However, the changes done directly in the DNA plugin configuration are not reflected in ID range objects, that's why you may observe the disparity between ID range characteristics and actual UIDs/GIDs provisioned. -- Martin^3 Babinsky From pspacek at redhat.com Fri Nov 25 09:00:32 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 25 Nov 2016 10:00:32 +0100 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: <0c386e0e-dce9-d1b1-960c-d91690fbbc9f@mdevsys.com> References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> <97e67d02-a736-239e-0d65-5ce551454a1f@mdevsys.com> <2837abb4-3605-1946-e752-a09b289439c5@redhat.com> <731bb495-e534-8581-9da4-ae57f9f6b466@mdevsys.com> <0c386e0e-dce9-d1b1-960c-d91690fbbc9f@mdevsys.com> Message-ID: <16d0ec1a-f4ed-4759-3f51-d000a0515097@redhat.com> On 25.11.2016 05:57, TomK wrote: > On 11/24/2016 4:49 AM, Petr Spacek wrote: >> On 24.11.2016 06:08, TomK wrote: >>> On 11/23/2016 3:28 AM, Martin Basti wrote: >>>> >>>> >>>> On 23.11.2016 03:48, TomK wrote: >>>>> On 11/22/2016 10:22 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 22.11.2016 13:57, TomK wrote: >>>>>>> On 11/22/2016 2:59 AM, Martin Basti wrote: >>>>>>>> Hey, >>>>>>>> >>>>>>>> >>>>>>>> On 22.11.2016 06:33, TomK wrote: >>>>>>>>> Hey Guy's, >>>>>>>>> >>>>>>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 >>>>>>>>> over to >>>>>>>>> my dual Free IPA server. The Free IPA servers are authoritative for >>>>>>>>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>>>>>>>> and forwards dom.abc.xyz. >>>>>>>> Do you have configured proper zone delegation for subdomain >>>>>>>> dom.abc.xyz? >>>>>>>> Proper NS and glue records >>>>>>>> http://www.zytrax.com/books/dns/ch9/delegate.html >>>>>>>> >>>>>>>>> >>>>>>>>> I cannot ping dom.abc.xyz. Everything else, including client >>>>>>>>> registrations, work fine. If Free IPA is authoritative on >>>>>>>>> dom.abc.xyz, should it not create DNS entries so the sub domain >>>>>>>>> can be >>>>>>>>> pinged as well? >>>>>>>> >>>>>>>> What do you mean by "ping"? >>>>>>>> >>>>>>>>> >>>>>>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>>>>>>>> and wanted to ask if you can point me to some materials online to >>>>>>>>> determine where can I permanently adjust the search to add >>>>>>>>> dom.abc.xyz >>>>>>>>> to the already present abc.xyz . I wasn't able to locate what I >>>>>>>>> needed in my searches. >>>>>>>>> >>>>>>>>> I'm using the latest v4. >>>>>>>> >>>>>>>> It depends on what are you using, probably you have NetworkManager >>>>>>>> there >>>>>>>> that is editing /etc/resolv.conf >>>>>>>> >>>>>>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Martin >>>>>>> >>>>>>> >>>>>>> I Uninstalled NetworkManager. Still changes. >>>>>>> ping dom.abc.com results in "ping: unknown host" >>>>>>> >>>>>>> I'll have a look at the first link, ty. >>>>>>> >>>>>> >>>>>> ping (ICMP protocol) and DNS system are different things, do you have >>>>>> hostname dom.abc.com with A record or it is a zone? >>>>>> >>>>>> with ping command hostname "dom.abc.com" is resolved to IP address >>>>>> first, do you have A record set for dom.abc.com in zone apex or what are >>>>>> you trying to achieve with ping command? >>>>>> >>>>>> for testing DNS try to use commands: dig, host, nslookup >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> Apologize for the long reply but it should give some background on >>>>> what it is that I'm doing. >>>>> >>>>> 1) dom.abc.com is a zone. There is no A record for dom.abc.com in >>>>> FreeIPA (Confirmed by Petr). I get the point Petr Spacek pointed out >>>>> in his comment as well. What should it really point too? ( I kind of >>>>> answer this question below so please read on. ) Where I'm getting >>>>> this from is that in Windows Server 2012 abc.com returns the IP of any >>>>> of the participating AD / DNS servers within the cluster (The two >>>>> Windows Server 2012 are a combined clustered AD + DNS servers.). >>>>> Being able to resolve abc.xyz is handy. During a lookup, I can get a >>>>> list of all the IP's associated with that domain which would indicate >>>>> all the DNS + AD servers online under that domain or serving that domain: >>>>> >>>>> >>>>> # nslookup abc.xyz >>>>> Server: 192.168.0.3 >>>>> Address: 192.168.0.3#53 >>>>> >>>>> Name: abc.xyz >>>>> Address: 192.168.0.3 >>>>> Name: abc.xyz >>>>> Address: 192.168.0.1 >>>>> Name: abc.xyz >>>>> Address: 192.168.0.2 >>>>> # >>>>> >>>>> Again, where this is handy is when configuring sssd.conf for example >>>>> or other apps for that matter. I can just point the app to >>>>> authenticate against the domain and I have my redundancy solved. >>>>> Windows Server 2012 does it, but FreeIPA didn't, so I threw the >>>>> question out there. >>>> >>>> IPA uses SRV records heavily, all IPA related services have SRV records, >>>> SSSD uses SRV records of IPA, client should use SRV record to connect to >>>> the right service (or URI record - will be in next IPA). SRV records >>>> work for IPA locations mechanism, we cannot achieve this with pure A >>>> records. >>>> >>>>> >>>>> Delegation from this Windows DNS works as expected. Any lookup from >>>>> dom.abc.xyz is forwarded too and handled by FreeIPA servers. Tested >>>>> this out. No issue with this. >>>>> >>>>> I did see earlier that there is no A record for dom.abc.xyz in >>>>> FreeIPA. My reasons for asking if there was an IP on the subdomain in >>>>> FreeIPA were above but the missing IP on the subdomain isn't a major >>>>> issue for me. Things are working without dom.abc.xyz resolving to an >>>>> IP. What I was hoping for is to have a VIP for the IPA servers and >>>>> one for the Windows Server 2012 DNS Cluster in /etc/resolv.conf. (I >>>>> have the VIP for the windows server). One forwarding to the other for >>>>> a given domain. This is all for testing a) redundancy, b) forwarding, >>>>> a) authentication . >>>>> >>>>> IE: >>>>> >>>>> # cat /etc/resolv.conf >>>>> search dom.abc.xyz abc.xyz >>>>> nameserver 192.168.0.3 <------------ Win Cluster DNS VIP >>>>> nameserver 192.168.0.4 <------------ IPA Cluster DNS VIP >>>>> >>>>> * Just what I want to achieve above. VIP 192.168.0.4 doesn't exist on >>>>> my cluster yet. I'm looking to integrate ucarp with the above IPA >>>>> servers. >>>>> >>>>> >>>>> 2) More to the topic of my second question however, is that >>>>> /etc/resolv.conf, on the IPA servers themselves, get's rewritten on >>>>> restart. Would like to know by what if I already uninstalled >>>>> NetworkManager? When I configured the FreeIPA server, I used: >>>>> >>>>> ipa-server-install --setup-dns --forwarder=192.168.0.3 -p "Hush!" -a >>>>> "Hush!" -r DOM.ABC.XYZ -n dom.abc.xyz --hostname ipa01.dom.abc.xyz >>>>> >>>>> Notice I used the VIP of the Windows Server 2012 Cluster when >>>>> installing FreeIPA. This is nice for redundancy. So the resolv.conf >>>>> ends up being: >>>>> >>>>> # cat /etc/resolv.conf >>>>> # Generated by NetworkManager >>>>> search abc.xyz >>>>> nameserver 192.168.0.3 >>>>> nameserver 123.123.123.1 >>>>> nameserver 123.123.123.2 >>>>> >>>>> Then I add: >>>>> >>>>> search dom.abc.xyz abc.xyz >>>>> >>>>> but it changes back to search abc.xyz (the Windows Server 2012 DNS). >>>>> This all works, except for the above minor items, and I can resolve >>>>> anything over this network. ( Thinking this is fine because the >>>>> forward is on the subdomain. I haven't had issues with forwarding >>>>> through this setup. ) >>>>> >>>>> # cat /etc/resolv.conf >>>>> # Generated by NetworkManager >>>>> search abc.xyz >>>>> nameserver 192.168.0.3 >>>>> nameserver 123.123.123.1 >>>>> nameserver 123.123.123.2 >>>>> >>>>> But NetworkManager is not installed on these IPA servers. I've >>>>> removed it earlier: >>>>> >>>>> # rpm -aq|grep -i NetworkManager >>>>> # >>>>> >>>>> Is FreeIPA replacing /etc/resolv.conf with a copy it keeps elsewhere? >>>> >>>> On servers with DNS /etc/resolv.conf should point to 127.0.0.1 and ::1, >>>> and global or per server dns forwarders should be configured instead >>>> >>>> Have you properly stopped NetworkManager using systemctl stop and >>>> systemctl disable ? In case you just removed rpm files service can still >>>> work. >>>> I recommend to update network manager config, not to remove it :) >>>> >>>> As last resort way, you can set immutable bit to resolv.conf if >>>> something is still changing your resolv.conf file >>>> >>>>> >>>>> 3) After running: >>>>> >>>>> ipa-client-install --mkhomedir --enable-dns-updates >>>>> >>>>> on a new host, the hostname of the new host doesn't resolve for a few >>>>> minutes. How do I make this instantaneous? (Other then that, >>>>> autodiscovery of the IPA servers is excellent!). Before installing >>>>> the IPA Client, the new hosts /etc/resolv.conf file looks like this: >>>>> >>>>> # cat /etc/resolv.conf >>>>> search abc.xyz >>>>> nameserver 192.168.0.3 >>>>> nameserver 123.123.123.1 >>>>> nameserver 123.123.123.2 >>>>> >>>>> I did dig, host, nslookup earlier. Verified all except for the items >>>>> I'm inquiring about. >>>>> >>>> >>>> That weird, because ipa-client-install creates A records directly to DNS >>>> server using nsupdate, so it should be accessible instantly. Do you have >>>> any caching DNS servers? >>>> >>>> Martin >>>> >>> >>> No caching DNS servers. >>> >>> On the topic of NetworkManager. It's completely gone yet still the >>> /etc/resolv.conf file is being replaced with the text # Generated by >>> NetworkManager. >>> >>> # systemctl show NetworkManager.service --property=Id,Names,Description >>> Id=NetworkManager.service >>> Names=NetworkManager.service >>> Description=NetworkManager.service >>> # >>> >>> # systemctl list-units --type service --all|grep -i network >>> network.service loaded active exited LSB: Bring >>> up/down networking >>> ? NetworkManager-wait-online.service not-found inactive dead >>> NetworkManager-wait-online.service >>> ? NetworkManager.service not-found inactive dead >>> NetworkManager.service >>> ntpd.service loaded active running Network >>> Time Service >>> rhel-domainname.service loaded active exited Read and >>> set NIS domainname from /etc/sysconfig/network >>> rhel-import-state.service loaded active exited Import >>> network configuration from initramfs >>> # >>> >>> >>> The only thing that is left of the NetworkManager service is the above. >>> Nothing I type from systemd removed it completely. So I've reverted to the >>> last resort: >>> >>> # lsattr /etc/resolv.conf >>> ----i----------- /etc/resolv.conf >>> # >>> >>> With the above, I'm trying to see what's writing to the file by using this >>> auditctl and found that postfix seems to be doing this: >>> >>> ---- >>> time->Wed Nov 23 23:14:47 2016 >>> type=PATH msg=audit(1479960887.978:293): item=0 name="/etc/resolv.conf" >>> inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 >>> obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>> type=CWD msg=audit(1479960887.978:293): cwd="/" >>> type=SYSCALL msg=audit(1479960887.978:293): arch=c000003e syscall=2 >>> success=yes exit=4 a0=7ffb36b6f43a a1=80000 a2=1b6 a3=24 items=1 ppid=1 >>> pid=5527 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >>> fsgid=0 tty=(none) ses=4294967295 comm="postfix" exe="/usr/sbin/postfix" >>> subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" >>> ---- >>> time->Wed Nov 23 23:14:48 2016 >>> type=PATH msg=audit(1479960888.013:301): item=0 name="/etc/resolv.conf" >>> inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 >>> obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>> type=CWD msg=audit(1479960888.013:301): cwd="/var/spool/postfix" >>> type=SYSCALL msg=audit(1479960888.013:301): arch=c000003e syscall=2 >>> success=yes exit=3 a0=7f32c163043a a1=80000 a2=1b6 a3=24 items=1 ppid=5545 >>> pid=5546 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >>> fsgid=0 tty=(none) ses=4294967295 comm="postconf" exe="/usr/sbin/postconf" >>> subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" >> >> It usually helps to run ausearch -i, it translates numberic codes to names. >> >> Assuming you are running Linux on x86_64, it would be interpreted like this: >> >> ---- >> type=SYSCALL msg=audit(24.11.2016 05:14:47.978:293) : arch=x86_64 syscall=open >> success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >> items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root >> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix >> exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 >> key=/root/resolv.conf-file >> type=CWD msg=audit(24.11.2016 05:14:47.978:293) : cwd=/ >> type=PATH msg=audit(24.11.2016 05:14:47.978:293) : item=0 >> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >> ---- >> type=SYSCALL msg=audit(24.11.2016 05:14:48.013:301) : arch=x86_64 syscall=open >> success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >> items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root >> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf >> exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 >> key=/root/resolv.conf-file >> type=CWD msg=audit(24.11.2016 05:14:48.013:301) : cwd=/var/spool/postfix >> type=PATH msg=audit(24.11.2016 05:14:48.013:301) : item=0 >> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >> >> >> In other words, /root/resolv.conf-file is open for reading. >> >> It is interesting ... What does the file contain? >> >> Petr^2 Spacek >> >> >>> >>> This in turn appears to be called by started by: >>> >>> # grep postfix access|tail -n 1 >>> [23/Nov/2016:23:42:04 -0500] conn=34 op=5 SRCH >>> base="cn=accounts,dc=dom,dc=abc,dc=xyz" scope=2 >>> filter="(&(uid=postfix)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))" >>> >>> attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory >>> loginShell krbPrincipalName cn memberOf ipaUniqueID ipaNTSecurityIdentifier >>> modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning >>> shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration >>> pwdattribute authorizedService accountexpires useraccountcontrol nsAccountLock >>> host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey >>> ipaUserAuthType usercertificate;binary" >>> # pwd >>> /var/log/dirsrv/slapd-DOM-ABC-XYZ > > root/resolv.conf-file is only a identifier (key) by which auditctl marked > events that occurred on /etc/resolv.conf. In other words, it was just a > custom assigned identifier I used that read / write requests got tagged with. > I really should have called it 'resolv-conf-identifier' or similar to avoid > confusion. It's not a file. > > The commands I used to watch the file are: > > /sbin/ausearch -f /etc/resolv.conf -key=/root/resolv.conf-file > > Then to get events: > > /sbin/ausearch -f /etc/resolv.conf --key "/root/resolv.conf-file" > > Adding the -i as per your note, I get this: > > > [root at idmipa01 ~]# /sbin/ausearch -f /etc/resolv.conf --key > "/root/resolv.conf-file" -i > ---- > type=PATH msg=audit(11/23/2016 23:14:04.708:287) : item=0 > name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL > type=CWD msg=audit(11/23/2016 23:14:04.708:287) : > cwd=/var/log/dirsrv/slapd-NIX-MDS-XYZ > type=SYSCALL msg=audit(11/23/2016 23:14:04.708:287) : arch=x86_64 syscall=open > success=yes exit=53 a0=0x7f66d82c243a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 > items=1 ppid=1 pid=5080 auid=unset uid=dirsrv gid=dirsrv euid=dirsrv > suid=dirsrv fsuid=dirsrv egid=dirsrv sgid=dirsrv fsgid=dirsrv tty=(none) > ses=unset comm=ns-slapd exe=/usr/sbin/ns-slapd > subj=system_u:system_r:dirsrv_t:s0 key=/root/resolv.conf-file > ---- > type=PATH msg=audit(11/23/2016 23:14:32.182:288) : item=0 > name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL > type=CWD msg=audit(11/23/2016 23:14:32.182:288) : cwd=/var/log/audit > type=SYSCALL msg=audit(11/23/2016 23:14:32.182:288) : arch=x86_64 syscall=open > success=yes exit=3 a0=0x7fffd2fa47ff a1=O_RDONLY|O_NONBLOCK a2=0x7fffd2fa2f00 > a3=0x7fffd2fa2c70 items=1 ppid=2389 pid=5511 auid=root uid=root gid=root > euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 > comm=chattr exe=/usr/bin/chattr > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key=/root/resolv.conf-file > ---- > type=PATH msg=audit(11/23/2016 23:14:32.182:289) : item=0 > name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL > type=CWD msg=audit(11/23/2016 23:14:32.182:289) : cwd=/var/log/audit > type=SYSCALL msg=audit(11/23/2016 23:14:32.182:289) : arch=x86_64 syscall=open > success=yes exit=3 a0=0x7fffd2fa47ff a1=O_RDONLY|O_NONBLOCK a2=0x7fffd2fa2f00 > a3=0x7fffd2fa2d50 items=1 ppid=2389 pid=5511 auid=root uid=root gid=root > euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 > comm=chattr exe=/usr/bin/chattr > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key=/root/resolv.conf-file > ---- > type=PATH msg=audit(11/23/2016 23:14:36.847:290) : item=0 > name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL > type=CWD msg=audit(11/23/2016 23:14:36.847:290) : cwd=/var/log/audit > type=SYSCALL msg=audit(11/23/2016 23:14:36.847:290) : arch=x86_64 syscall=open > success=yes exit=3 a0=0x7fff791a17ff a1=O_RDONLY|O_NONBLOCK a2=0x7fff791a0180 > a3=0x7fff7919fef0 items=1 ppid=2389 pid=5512 auid=root uid=root gid=root > euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 > comm=lsattr exe=/usr/bin/lsattr > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key=/root/resolv.conf-file > ---- > type=PATH msg=audit(11/23/2016 23:14:47.978:293) : item=0 > name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL > type=CWD msg=audit(11/23/2016 23:14:47.978:293) : cwd=/ > type=SYSCALL msg=audit(11/23/2016 23:14:47.978:293) : arch=x86_64 syscall=open > success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 > items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root > fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix > exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 > key=/root/resolv.conf-file > ---- > type=PATH msg=audit(11/23/2016 23:14:48.013:301) : item=0 > name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL > type=CWD msg=audit(11/23/2016 23:14:48.013:301) : cwd=/var/spool/postfix > type=SYSCALL msg=audit(11/23/2016 23:14:48.013:301) : arch=x86_64 syscall=open > success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 > items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root > fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf > exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 > key=/root/resolv.conf-file > [root at idmipa01 ~]# Okay, the important part is that all open() syscalls have parameter O_RDONLY so there is nothing writing to the file. The wrong value must have get into resolv.conf by some other means. -- Petr^2 Spacek From torajveersingh at gmail.com Fri Nov 25 09:59:43 2016 From: torajveersingh at gmail.com (Rajveer Singh) Date: Fri, 25 Nov 2016 15:29:43 +0530 Subject: [Freeipa-users] Configure HPUX 11i V3 as IPA Client Message-ID: Hi All, I am referring http://www.freeipa.org/page/ConfiguringUnixClients#Configuring_Client_Authentication_3 to configure HP UX 11i V3 as IPA client but it has no reference for 11iV3 but only 11i V0, 1 & 2. Though I tried to follow the steps mentioned in 11iv0, but they are not getting good understanding. Do we have any such document/procedure? Any URL will be highly appreciated. Thanks, Raj -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Fri Nov 25 10:03:53 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Fri, 25 Nov 2016 11:03:53 +0100 Subject: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue In-Reply-To: <307643568.635481.1479907553069.JavaMail.zimbra@phosphore.eu> References: <1383346498.1295916.1476825748599.JavaMail.zimbra@phosphore.eu> <835252359.90240.1477410669922.JavaMail.zimbra@phosphore.eu> <1898060535.461337.1479805632262.JavaMail.zimbra@phosphore.eu> <1349958374.477173.1479811804586.JavaMail.zimbra@phosphore.eu> <1673063951.535652.1479834378886.JavaMail.zimbra@phosphore.eu> <3b56f25b-7645-b861-e2b6-f0a02a26e32c@redhat.com> <307643568.635481.1479907553069.JavaMail.zimbra@phosphore.eu> Message-ID: On 11/23/2016 02:25 PM, Bertrand R?tif wrote: > > ------------------------------------------------------------------------ > > *De: *"Florence Blanc-Renaud" > *?: *"Bertrand R?tif" , freeipa-users at redhat.com > *Envoy?: *Mercredi 23 Novembre 2016 08:49:28 > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > pki-tomcat issue > > On 11/22/2016 06:06 PM, Bertrand R?tif wrote: > > Hi Florence, > > > > Thanks for clarification. > > Your explanation was very clear and I better understand > > > > Now my issue is that I need to start tracking "auditSigningCert > > cert-pki-ca", "ocspSigningCert cert-pki-ca" and "subsystemCert > > cert-pki-ca" on a server. > > > > I take a look on another server where they are properly tracked. > However > > getcert list return me "pin set" and not a "pinfile" as described in > > your mail. > > In "/etc/pki/pki-tomcat/alias" I do not see any pwdfile.txt file, > so my > > question is where do I get the PIN? > > > Hi Bertrand, > > With IPA 4.2.0 I believe that the pin is stored in > /var/lib/pki/pki-tomcat/conf/password.conf, in the 'internal' field: > $ grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf > internal=0123456789101 > > HTH, > Flo > > > Once again, thanks for your support, I tried to fix this issue for > days! > > > > Regards > > Bertrand > > > > > > -- > > Bertrand R?tif > > Phosphore Services Informatiques - http://www.phosphore.eu > > Tel: 04 66 51 87 73 / Mob: 06 61 87 03 30 / Fax: 09 72 12 61 44 > > > > > ------------------------------------------------------------------------ > > > > *De: *"Florence Blanc-Renaud" > > *?: *"Bertrand R?tif" , > freeipa-users at redhat.com > > *Envoy?: *Mardi 22 Novembre 2016 13:17:34 > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > pki-tomcat issue > > > > On 11/22/2016 11:50 AM, Bertrand R?tif wrote: > > > > > > > > > *De: *"Florence Blanc-Renaud" > > > *?: *"Bertrand R?tif" , > > freeipa-users at redhat.com > > > *Envoy?: *Mardi 22 Novembre 2016 11:33:45 > > > *Objet: *Re: [Freeipa-users] Impossible to renew > certificate. > > > pki-tomcat issue > > > > > > On 11/22/2016 10:07 AM, Bertrand R?tif wrote: > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > *De: *"Bertrand R?tif" > > > > *?: *freeipa-users at redhat.com > > > > *Envoy?: *Mardi 25 Octobre 2016 17:51:09 > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > certificate. > > > > pki-tomcat issue > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > *De: *"Florence Blanc-Renaud" > > > > *?: *"Bertrand R?tif" , > > > > freeipa-users at redhat.com > > > > *Envoy?: *Jeudi 20 Octobre 2016 18:45:21 > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > certificate. > > > > pki-tomcat issue > > > > > > > > On 10/19/2016 08:18 PM, Bertrand R?tif wrote: > > > > > *De: *"Bertrand R?tif" > > > > > > > > > > *?: *freeipa-users at redhat.com > > > > > *Envoy?: *Mercredi 19 Octobre 2016 15:42:07 > > > > > *Objet: *Re: [Freeipa-users] Impossible > to renew > > > certificate. > > > > > pki-tomcat issue > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > *De: *"Rob Crittenden" > > > > > > *?: *"Bertrand R?tif" > , > > > > > freeipa-users at redhat.com > > > > > *Envoy?: *Mercredi 19 Octobre 2016 > 15:30:14 > > > > > *Objet: *Re: [Freeipa-users] > Impossible to > > renew > > > > certificate. > > > > > pki-tomcat issue > > > > > > > > > > Bertrand R?tif wrote: > > > > > >> De: "Martin Babinsky" > > > > > > >> ?: freeipa-users at redhat.com > > > > > >> Envoy?: Mercredi 19 Octobre 2016 > 08:45:49 > > > > > >> Objet: Re: [Freeipa-users] Impossible > > to renew > > > > certificate. > > > > > pki-tomcat issue > > > > > > > > > > > >> On 10/18/2016 11:22 PM, Bertrand > R?tif > > wrote: > > > > > >>> Hello, > > > > > >>> > > > > > >>> I had an issue with pki-tomcat. > > > > > >>> I had serveral certificate that was > > expired and > > > > pki-tomcat > > > > > did not start > > > > > >>> anymore. > > > > > >>> > > > > > >>> I set the dateon the server before > > certificate > > > > expiration > > > > > and then > > > > > >>> pki-tomcat starts properly. > > > > > >>> Then I try to resubmit the > > certificate, but > > > I get > > > > below error: > > > > > >>> "Profile caServerCert Not Found" > > > > > >>> > > > > > >>> Do you have any idea how I could fix > > this issue. > > > > > >>> > > > > > >>> Please find below output of > commands: > > > > > >>> > > > > > >>> > > > > > >>> # getcert resubmit -i 20160108170324 > > > > > >>> > > > > > >>> # getcert list -i 20160108170324 > > > > > >>> Number of certificates and > requests being > > > tracked: 7. > > > > > >>> Request ID '20160108170324': > > > > > >>> status: MONITORING > > > > > >>> ca-error: Server at > > > > > >>> > > > > > > "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit" > > > > > replied: > > > > > >>> Profile caServerCert Not Found > > > > > >>> stuck: no > > > > > >>> key pair storage: > > > > > >>> > > > > > > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > > >>> Certificate > > > DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > > >>> certificate: > > > > > >>> > > > > > > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > > >>> Certificate DB' > > > > > >>> CA: dogtag-ipa-ca-renew-agent > > > > > >>> issuer: CN=Certificate > > Authority,O=A.SKINFRA.EU > > > > > >>> subject: CN=IPA RA,O=A.SKINFRA.EU > > > > > >>> expires: 2016-06-28 15:25:11 UTC > > > > > >>> key usage: > > > > > >>> > > > > > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > > >>> eku: > id-kp-serverAuth,id-kp-clientAuth > > > > > >>> pre-save command: > > > > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > > > >>> post-save command: > > > > /usr/lib64/ipa/certmonger/renew_ra_cert > > > > > >>> track: yes > > > > > >>> auto-renew: yes > > > > > >>> > > > > > >>> > > > > > >>> Thanksby advance for your help. > > > > > >>> Bertrand > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > > > > > > > >> Hi Betrand, > > > > > > > > > > > >> what version of FreeIPA and > Dogtag are you > > > running? > > > > > > > > > > > >> Also perform the following search on > > the IPA > > > master > > > > and post > > > > > the result: > > > > > > > > > > > >> """ > > > > > >> ldapsearch -D "cn=Directory > Manager" -W -b > > > > > >> > 'ou=certificateProfiles,ou=ca,o=ipaca' > > > > > '(objectClass=certProfile)' > > > > > >> """ > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > Thanks for your reply. > > > > > > > > > > > > Here is version: > > > > > > - FreeIPA 4.2.0 > > > > > > - Centos 7.2 > > > > > > > > > > > > I have been able to fix the issue with > > "Profile > > > > caServerCert > > > > > Not Found" by editing > > > > /var/lib/pki/pki-tomcat/ca/conf/CS.cfg > > > > > > I replace below entry > > > > > > > > > > > > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem" > > > > > > by > > > > > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem" > > > > > > > > > > > > and then launch > "ipa-server-upgrade" command > > > > > > I found this solution in this post: > > > > > > > > http://osdir.com/ml/freeipa-users/2016-03/msg00280.html > > > > > > > > > > > > Then I was able to renew my > certificate. > > > > > > > > > > > > However I reboot my server to and > pki-tomcat > > > do not > > > > start and > > > > > provide with a new erreor in > > > > /var/log/pki/pki-tomcat/ca/debug > > > > > > > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > CertUtils: > > > > > verifySystemCertByNickname() passed: > > > auditSigningCert > > > > cert-pki-ca > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > > SignedAuditEventFactory: create() > > > > > > > > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$ > > > > > > > > > System$][Outcome=Success][CertNickName=auditSigningCert > > > > > cert-pki-ca] CIMC certificate > verification > > > > > > > > > > > > java.lang.Exception: > > SystemCertsVerification: > > > system > > > > certs > > > > > verification failure > > > > > > at > > > > > > > > > > > > > > > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) > > > > > > at > > > > > > > > > > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) > > > > > > at > > > > > > > > > > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) > > > > > > at > > > > > > > > > > > > > > > com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701) > > > > > > at > > > > > > > > > > > > > com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148) > > > > > > at > > > com.netscape.certsrv.apps.CMS.startup(CMS.java:200) > > > > > > at > > > com.netscape.certsrv.apps.CMS.start(CMS.java:1602) > > > > > > at > > > > > > > > > > > > > > > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) > > > > > > at > > > > > > javax.servlet.GenericServlet.init(GenericServlet.java:158) > > > > > > at > > > > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > > > > > at > > > > > > > > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > > > at > > > > > > > > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > > > at > > > java.lang.reflect.Method.invoke(Method.java:606) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) > > > > > > at > > > > java.security.AccessController.doPrivileged(Native > > Method) > > > > > > at > > > > > > javax.security.auth.Subject.doAsPrivileged(Subject.java:536) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > > > > > > at > > > > java.security.AccessController.doPrivileged(Native > > Method) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > > > > > > at > > > > > > > > > > > > > > > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > > > > > > at > > > > > > > > > > > > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > > > > > > at > > > > > java.util.concurrent.FutureTask.run(FutureTask.java:262) > > > > > > at > > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > > > > at > > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > > > > at > java.lang.Thread.run(Thread.java:745) > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > > SignedAuditEventFactory: create() > > > > > > > > > > > > > > > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] > > > > > self tests execution (see selftests.log > > for details) > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > > CMSEngine.shutdown() > > > > > > > > > > > > > > > > > > I am currently stuck here. > > > > > > Thanks a lot for your help. > > > > > > > > > > I'm guessing at least one of the CA > subsystem > > > > certificates are > > > > > still > > > > > expired. Look at the "getcert list" > output > > to see if > > > > there are any > > > > > expired certificates. > > > > > > > > > > rob > > > > > > > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > > > > > > > > > Hello Rob, > > > > > > > > > > I check on my 2 servers and no > certificate is > > expired > > > > > > > > > > [root at sdkipa03 ~]# getcert list |grep expire > > > > > expires: 2018-06-22 22:02:26 UTC > > > > > expires: 2018-06-22 22:02:47 UTC > > > > > expires: 2034-07-09 15:24:34 UTC > > > > > expires: 2016-10-30 13:35:29 UTC > > > > > > > > > > [root at sdkipa01 conf]# getcert list |grep > expire > > > > > expires: 2018-06-12 23:38:01 UTC > > > > > expires: 2018-06-12 23:37:41 UTC > > > > > expires: 2018-06-11 22:53:57 UTC > > > > > expires: 2018-06-11 22:55:50 UTC > > > > > expires: 2018-06-11 22:57:47 UTC > > > > > expires: 2034-07-09 15:24:34 UTC > > > > > expires: 2018-06-11 22:59:55 UTC > > > > > > > > > > I see that one certificate is in status: > > CA_UNREACHABLE, > > > > maybe I > > > > > reboot to soon my server... > > > > > > > > > > I continue to investigate > > > > > > > > > > Thanks for your help. > > > > > Bertrand > > > > > > > > > > I fix my previous issue. > > > > > Now I have an issue with a server. > > > > > This server can not start pki-tomcatd, I get > this > > error in > > > > debug file: > > > > > "Error netscape.ldap.LDAPExceptio n: IO > Error creating > > > JSS SSL > > > > Socket (-1)" > > > > > > > > > > After investigation i see that I do not have > "ipaCert" > > > > certificat in > > > > > "/etc/httpd/alias" > > > > > cf below command: > > > > > > > > > > [root at sdkipa03 ~]# getcert list -d > /etc/httpd/alias > > > > > Number of certificates and requests being > tracked: 4. > > > > > Request ID '20141110133632': > > > > > status: MONITORING > > > > > stuck: no > > > > > 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=A.SKINFRA.EU > > > > > subject: > CN=sdkipa03.skinfra.eu,O=A.SKINFRA.EU > > > > > expires: 2018-06-22 22:02:47 UTC > > > > > principal name: > > HTTP/sdkipa03.skinfra.eu at A.SKINFRA.EU > > > > > key usage: > > > > > > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > > > pre-save command: > > > > > post-save command: > > > /usr/lib64/ipa/certmonger/restart_httpd > > > > > track: yes > > > > > auto-renew: yes > > > > > > > > > > > > > > > How can I add the certificate to > /etc/httpd/alias? > > > > > > > > > Hi, > > > > > > > > for the record, the command getcert list that you > > supplied > > > shows > > > > the > > > > certificates in /etc/httpd/alias that are > tracked by > > > certmonger. > > > > If you > > > > want to display all the certificates contained in > > > /etc/httpd/alias > > > > (whether tracked or not), then you may want to use > > > certutil -L -d > > > > /etc/httpd/alias instead. > > > > > > > > If ipaCert is missing, you can export ipaCert > > certificate from > > > > another > > > > master, then import it to your server. > > > > > > > > On a master containing the cert: > > > > # certutil -d /etc/httpd/alias -L -n 'ipaCert' > -a > > > > > /tmp/newRAcert.crt > > > > > > > > Then copy the file /tmp/newRAcert.crt to your > server and > > > import > > > > the cert: > > > > # certutil -d /etc/httpd/alias -A -n 'ipaCert' > -a -i > > > > /tmp/newRAcert.crt > > > > -t u,u,u > > > > > > > > And finally you need to tell certmonger to > monitor the > > > cert using > > > > getcert start-tracking. > > > > > > > > Hope this helps, > > > > Flo. > > > > > > > > > Thanks fo ryour support. > > > > > Regards > > > > > Bertrand > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > Florence, thanks for your help. > > > > I was able to import correctly ipaCert with your > commands. > > > > Now it seems that I also have an issue on one > server with > > > > "subsystemCert cert-pki-ca" in > /etc/pki/pki-tomcat/alias > > as I get > > > > below error when pki-tomcat try to start > > > > > > > > > > > > LdapJssSSLSocket set client auth cert nickname > subsystemCert > > > cert-pki-ca > > > > Could not connect to LDAP server host sdkipa03.XX.YY > > port 636 > > > Error > > > > netscape.ldap.LDAPException: IO Error creating JSS SSL > > Socket ( > > > > -1) > > > > > > > > > > > > Is there a way to restore a correct "subsystemCert > > cert-pki-ca"? > > > > > > > > Regards > > > > Bertrand > > > > > > > > Hello, > > > > > > > > I am still stuck with my IPA server. > > > > I have issues on both servers. > > > > On server1, below certificate is not renewed properly > > > > certutil -L -d /etc/httpd/alias/ -n "ipaCert" > > > > > > > > and on server 2 this is this certificate: > > > > certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n > "Server-Cert > > > cert-pki-ca" > > > > > > > > Could you provide me with the correct syntax with > start-tracking > > > command. > > > > I tried to laucnh this command but my certificat > remains in > > > > "NEWLY_ADDED_NEED_KEYINFO_READ_PIN" state. > > > > Here is the comnd I use: > > > > getcert start-tracking -c > dogtag-ipa-retrieve-agent-submit -d > > > > /var/lib/pki/pki-tomcat/alias -n 'Server-Cert > cert-pki-ca' -B > > > > /usr/lib64/ipa/certmonger/stop_pkicad -C > > > > '/usr/lib64/ipa/certmonger/renew_ca_cert "Server-Cert > > cert-pki-ca"' -T > > > > "Server-Cert cert-pki-ca" -P '20160614000000' > > > > > > > Hi Bertrand, > > > > > > to get the right command, you can check on a system > where the > > > certificate is properly monitored, this will show you > the right > > > parameters: > > > $ sudo getcert list -n ipaCert > > > Number of certificates and requests being tracked: 8. > > > Request ID '20161122095344': > > > [..] key pair storage: > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > [...] > > > CA: dogtag-ipa-ca-renew-agent > > > [...] > > > pre-save command: > > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > post-save command: > /usr/lib64/ipa/certmonger/renew_ra_cert > > > [...] > > > > > > The relevant fields are NSSDB location, pinfile, > nickname, CA, > > pre and > > > post-save commands. So in order to monitor ipaCert, you will > > need to use > > > $ sudo getcert start-tracking -d /etc/httpd/alias -n > ipaCert \ > > > -p /etc/httpd/alias/pwdfile.txt \ > > > -c dogtag-ipa-ca-renew-agent \ > > > -B /usr/lib64/ipa/certmonger/renew_ra_cert_pre \ > > > -C /usr/lib64/ipa/certmonger/renew_ra_cert > > > > > > HTH, > > > Flo. > > > > > > > Thanks by advance for your help. > > > > > > > > Regards > > > > Bertrand > > > > > > Hello Florence, > > > > > > Thanks for your reply. > > > Before doing any mistakes, I just need some explanations as I > > think I do > > > not well understand how it should work. > > > > > > Do all the certificate need to be track by certmonger on all > > servers or > > > they should only be tracked on one server and FreeIPA will > update them > > > on other servers? > > > > > > In my case I have below certicates outdated and not track on > > "server 1": > > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n > > "auditSigningCert > > > cert-pki-ca" > > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n > "ocspSigningCert > > > cert-pki-ca" > > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n > "subsystemCert > > > cert-pki-ca" > > > > > > They are tracked by certmonger and have been correctly > renewed on > > "server 2" > > > Do I need to add them tracked by certmonger on "server 1"? > > > If not, it means FreeIPA failed to update them? Should I > delete and > > > import them manually on server 2? > > > > > > If you need more details, do not hesitate to ask. > > > > > Hi Bertrand, > > > > The certificate tracking depends on the type of certificate > and on the > > server you're considering. For instance, if IPA includes a > Certificate > > Authority, then ipaCert will be present on all the IPA servers > > (master/replicas) and tracked on all of them. The same ipaCert > > certificate is used on all the replicas. On the renewal > master, the > > renewal operation actually renews the certificate and uploads > the cert > > on LDAP, but on the other replicas the operation consists in > > downloading > > the new certificate from LDAP. > > > > The HTTP and LDAP server certificates are present and tracked > on all > > the > > IPA servers, but they are different on each server (you can > see that > > the > > Subject of the certificate contains the hostname). They can be > renewed > > independently on each IPA server. > > > > The certificates used by Dogtag (the component providing the > > Certificate > > System) are present and tracked only on the IPA servers where > the CA > > was > > setup (for instance if you installed a replica with --setup-ca > or if > > you > > ran ipa-ca-install later on). The same certificates are used > on all > > replicas containing a CA instance. > > They are: 'ocspSigningCert cert-pki-ca', 'subsystemCert > cert-pki-ca', > > 'caSigningCert cert-pki-ca' and 'Server-Cert cert-pki-ca'. > > The renewal operation renews them on the renewal master and > uploads > > them > > in LDAP, but just downloads them from LDAP on the other servers. > > > > In your example, if server1 also contains a CA instance then > it should > > also track the above certs. > > > > You can find the renewal master with the following ldapsearch > command: > > $ ldapsearch -h localhost -p 389 -D 'cn=Directory Manager' -w > password > > -b "cn=masters,cn=ipa,cn=etc,$BASEDN" -LLL > > '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn > > dn: cn=CA,cn=ipaserver.fqdn,cn=masters,cn=ipa,cn=etc,$BASEDN > > > > In this case the renewal master is ipaserver.fqdn > > > > Hope this clarifies, > > Flo. > > > > > Regards > > > Bertrand > > > > > > > > Hi Florence, > > Thanks. > All my certificate are now renewed and tracked. I set back current time > on my servers and everything is now running properly. > > However now I get an issue with ldap replication. > Here are details of my 3 servers S1, S2 S3 > > All below commands are launched on S1 servers > > # ipa-replica-manage list > S1: master > S2: master > S3: master > > # ipa-replica-manage -v list S1 > S2: replica > last init status: 0 Total update succeeded > last init ended: 2016-11-23 12:56:27+00:00 > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2016-11-23 13:12:00+00:00 > S3: replica > last init status: 0 Total update succeeded > last init ended: 2016-11-23 12:54:51+00:00 > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2016-11-23 13:12:00+00:00 > > # ipa-replica-manage -v S2 > S1: replica > last init status: None > last init ended: 1970-01-01 00:00:00+00:00 > last update status: -1 Incremental update has failed and requires > administrator actionLDAP error: Can't contact LDAP server > last update ended: 1970-01-01 00:00:00+00:00 > > > # ipa-replica-manage -v S3 > S3: replica > last init status: None > last init ended: 1970-01-01 00:00:00+00:00 > last update status: -1 Incremental update has failed and requires > administrator actionLDAP error: Can't contact LDAP server > last update ended: 1970-01-01 00:00:00+00:00 > > > I tried to reinitialize S2 server, however I still get the issue: > Command below is run on S2: > > S2# ipa-replica-manage re-initialize --from S1 > ipa: INFO: Setting agreement > cn=meToS2.skinfra.eu,cn=replica,cn=dc\=a\,dc\=skinfra\,dc\=eu,cn=mapping > tree,cn=config schedule to 2358-2359 0 to force synch > ipa: INFO: Deleting schedule 2358-2359 0 from agreement > cn=meToS2,cn=replica,cn=dc\=a\,dc\=skinfra\,dc\=eu,cn=mapping tree,cn=config > Update in progress, 2 seconds elapsed > Update succeeded > > On S2 server in /var/log/dirsrv/slapd-REALM/errors log I get > > [23/Nov/2016:13:54:51 +0100] agmt="cn=meToS1" (S1:389) - Can't locate > CSN 583669ee000a000f0000 in the changelog (DB rc=-30988). If replication > stops, the consumer may need to be reinitialized. > [23/Nov/2016:13:54:51 +0100] NSMMReplicationPlugin - changelog program - > agmt="cn=meToS1" (S1:389): CSN 583669ee000a000f0000 not found, we aren't > as up to date, or we purged > [23/Nov/2016:13:54:51 +0100] NSMMReplicationPlugin - agmt="cn=meToS1" > (S1:389): Data required to update replica has been purged. The replica > must be reinitialized. > [23/Nov/2016:13:54:51 +0100] NSMMReplicationPlugin - agmt="cn=meToS1" > (S1:389): Incremental update failed and requires administrator action > .............. > [23/Nov/2016:14:18:10 +0100] slapi_ldap_bind - Error: could not bind id > [cn=Replication Manager cloneAgreement1-S2,ou=csusers,cn=config] > authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 > (Success) > > > I search on google but I did not find any solution to fix issue and I do > not want to break everything > Hi Bertrand, Replication applies to 2 different suffixes: the domain suffix (that contains users and groups) and o=ipaca that contains the data for the Certificate System (see "Explaining Replication Agreements" [1]). The entry that is missing (cn=Replication Manager cloneAgreement1-S2,ou=csusers,cn=config) corresponds to the replication manager entry used for authenticating the replication of the CS component (for more information you can read "Replication Identity" [2] in Red Hat Directory Server Administration Guide). I don't know how the entry disappeared, but I would try the following to re-create it: - remove the CA replication agreement on S2 to S1 using ipa-csreplica-manage disconnect - re-create the CA replication agreement on S2 to S1 using ipa-csreplica-manage connect You need to be sure that S1 is the most up-to-date source of data though. Flo. [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-topology-old.html#replication-agreements [2] https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication.html#Replication_Overview-Replication_Identity > Regards > Bertrand > > From bretif at phosphore.eu Fri Nov 25 10:16:04 2016 From: bretif at phosphore.eu (Bertrand =?utf-8?Q?R=C3=A9tif?=) Date: Fri, 25 Nov 2016 11:16:04 +0100 (CET) Subject: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue In-Reply-To: References: <1383346498.1295916.1476825748599.JavaMail.zimbra@phosphore.eu> <1349958374.477173.1479811804586.JavaMail.zimbra@phosphore.eu> <1673063951.535652.1479834378886.JavaMail.zimbra@phosphore.eu> <3b56f25b-7645-b861-e2b6-f0a02a26e32c@redhat.com> <307643568.635481.1479907553069.JavaMail.zimbra@phosphore.eu> Message-ID: <386664157.835328.1480068964154.JavaMail.zimbra@phosphore.eu> -- Bertrand R?tif Phosphore Services Informatiques - http://www.phosphore.eu Tel: 04 66 51 87 73 / Mob: 06 61 87 03 30 / Fax: 09 72 12 61 44 ----- Mail original ----- > De: "Florence Blanc-Renaud" > ?: "Bertrand R?tif" , freeipa-users at redhat.com > Envoy?: Vendredi 25 Novembre 2016 11:03:53 > Objet: Re: [Freeipa-users] Impossible to renew certificate. pki-tomcat issue > On 11/23/2016 02:25 PM, Bertrand R?tif wrote: > > > > ------------------------------------------------------------------------ > > > > *De: *"Florence Blanc-Renaud" > > *?: *"Bertrand R?tif" , freeipa-users at redhat.com > > *Envoy?: *Mercredi 23 Novembre 2016 08:49:28 > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > pki-tomcat issue > > > > On 11/22/2016 06:06 PM, Bertrand R?tif wrote: > > > Hi Florence, > > > > > > Thanks for clarification. > > > Your explanation was very clear and I better understand > > > > > > Now my issue is that I need to start tracking "auditSigningCert > > > cert-pki-ca", "ocspSigningCert cert-pki-ca" and "subsystemCert > > > cert-pki-ca" on a server. > > > > > > I take a look on another server where they are properly tracked. > > However > > > getcert list return me "pin set" and not a "pinfile" as described in > > > your mail. > > > In "/etc/pki/pki-tomcat/alias" I do not see any pwdfile.txt file, > > so my > > > question is where do I get the PIN? > > > > > Hi Bertrand, > > > > With IPA 4.2.0 I believe that the pin is stored in > > /var/lib/pki/pki-tomcat/conf/password.conf, in the 'internal' field: > > $ grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf > > internal=0123456789101 > > > > HTH, > > Flo > > > > > Once again, thanks for your support, I tried to fix this issue for > > days! > > > > > > Regards > > > Bertrand > > > > > > > > > -- > > > Bertrand R?tif > > > Phosphore Services Informatiques - http://www.phosphore.eu > > > Tel: 04 66 51 87 73 / Mob: 06 61 87 03 30 / Fax: 09 72 12 61 44 > > > > > > > > ------------------------------------------------------------------------ > > > > > > *De: *"Florence Blanc-Renaud" > > > *?: *"Bertrand R?tif" , > > freeipa-users at redhat.com > > > *Envoy?: *Mardi 22 Novembre 2016 13:17:34 > > > *Objet: *Re: [Freeipa-users] Impossible to renew certificate. > > > pki-tomcat issue > > > > > > On 11/22/2016 11:50 AM, Bertrand R?tif wrote: > > > > > > > > > > > > *De: *"Florence Blanc-Renaud" > > > > *?: *"Bertrand R?tif" , > > > freeipa-users at redhat.com > > > > *Envoy?: *Mardi 22 Novembre 2016 11:33:45 > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > certificate. > > > > pki-tomcat issue > > > > > > > > On 11/22/2016 10:07 AM, Bertrand R?tif wrote: > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > *De: *"Bertrand R?tif" > > > > > *?: *freeipa-users at redhat.com > > > > > *Envoy?: *Mardi 25 Octobre 2016 17:51:09 > > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > > certificate. > > > > > pki-tomcat issue > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > *De: *"Florence Blanc-Renaud" > > > > > *?: *"Bertrand R?tif" , > > > > > freeipa-users at redhat.com > > > > > *Envoy?: *Jeudi 20 Octobre 2016 18:45:21 > > > > > *Objet: *Re: [Freeipa-users] Impossible to renew > > > certificate. > > > > > pki-tomcat issue > > > > > > > > > > On 10/19/2016 08:18 PM, Bertrand R?tif wrote: > > > > > > *De: *"Bertrand R?tif" > > > > > > > > > > > > *?: *freeipa-users at redhat.com > > > > > > *Envoy?: *Mercredi 19 Octobre 2016 15:42:07 > > > > > > *Objet: *Re: [Freeipa-users] Impossible > > to renew > > > > certificate. > > > > > > pki-tomcat issue > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > *De: *"Rob Crittenden" > > > > > > > > *?: *"Bertrand R?tif" > > , > > > > > > freeipa-users at redhat.com > > > > > > *Envoy?: *Mercredi 19 Octobre 2016 > > 15:30:14 > > > > > > *Objet: *Re: [Freeipa-users] > > Impossible to > > > renew > > > > > certificate. > > > > > > pki-tomcat issue > > > > > > > > > > > > Bertrand R?tif wrote: > > > > > > >> De: "Martin Babinsky" > > > > > > > > >> ?: freeipa-users at redhat.com > > > > > > >> Envoy?: Mercredi 19 Octobre 2016 > > 08:45:49 > > > > > > >> Objet: Re: [Freeipa-users] Impossible > > > to renew > > > > > certificate. > > > > > > pki-tomcat issue > > > > > > > > > > > > > >> On 10/18/2016 11:22 PM, Bertrand > > R?tif > > > wrote: > > > > > > >>> Hello, > > > > > > >>> > > > > > > >>> I had an issue with pki-tomcat. > > > > > > >>> I had serveral certificate that was > > > expired and > > > > > pki-tomcat > > > > > > did not start > > > > > > >>> anymore. > > > > > > >>> > > > > > > >>> I set the dateon the server before > > > certificate > > > > > expiration > > > > > > and then > > > > > > >>> pki-tomcat starts properly. > > > > > > >>> Then I try to resubmit the > > > certificate, but > > > > I get > > > > > below error: > > > > > > >>> "Profile caServerCert Not Found" > > > > > > >>> > > > > > > >>> Do you have any idea how I could fix > > > this issue. > > > > > > >>> > > > > > > >>> Please find below output of > > commands: > > > > > > >>> > > > > > > >>> > > > > > > >>> # getcert resubmit -i 20160108170324 > > > > > > >>> > > > > > > >>> # getcert list -i 20160108170324 > > > > > > >>> Number of certificates and > > requests being > > > > tracked: 7. > > > > > > >>> Request ID '20160108170324': > > > > > > >>> status: MONITORING > > > > > > >>> ca-error: Server at > > > > > > >>> > > > > > > > > "http://sdkipa01.a.skinfra.eu:8080/ca/ee/ca/profileSubmit" > > > > > > replied: > > > > > > >>> Profile caServerCert Not Found > > > > > > >>> stuck: no > > > > > > >>> key pair storage: > > > > > > >>> > > > > > > > > > > > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > > > >>> Certificate > > > > DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > > > >>> certificate: > > > > > > >>> > > > > > > > > > > > > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > > > >>> Certificate DB' > > > > > > >>> CA: dogtag-ipa-ca-renew-agent > > > > > > >>> issuer: CN=Certificate > > > Authority,O=A.SKINFRA.EU > > > > > > >>> subject: CN=IPA RA,O=A.SKINFRA.EU > > > > > > >>> expires: 2016-06-28 15:25:11 UTC > > > > > > >>> key usage: > > > > > > >>> > > > > > > > > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > > > >>> eku: > > id-kp-serverAuth,id-kp-clientAuth > > > > > > >>> pre-save command: > > > > > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > > > > >>> post-save command: > > > > > /usr/lib64/ipa/certmonger/renew_ra_cert > > > > > > >>> track: yes > > > > > > >>> auto-renew: yes > > > > > > >>> > > > > > > >>> > > > > > > >>> Thanksby advance for your help. > > > > > > >>> Bertrand > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > > > > > > > > >> Hi Betrand, > > > > > > > > > > > > > >> what version of FreeIPA and > > Dogtag are you > > > > running? > > > > > > > > > > > > > >> Also perform the following search on > > > the IPA > > > > master > > > > > and post > > > > > > the result: > > > > > > > > > > > > > >> """ > > > > > > >> ldapsearch -D "cn=Directory > > Manager" -W -b > > > > > > >> > > 'ou=certificateProfiles,ou=ca,o=ipaca' > > > > > > '(objectClass=certProfile)' > > > > > > >> """ > > > > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > Thanks for your reply. > > > > > > > > > > > > > > Here is version: > > > > > > > - FreeIPA 4.2.0 > > > > > > > - Centos 7.2 > > > > > > > > > > > > > > I have been able to fix the issue with > > > "Profile > > > > > caServerCert > > > > > > Not Found" by editing > > > > > /var/lib/pki/pki-tomcat/ca/conf/CS.cfg > > > > > > > I replace below entry > > > > > > > > > > > > > > > > > > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.LDAPProfileSubsystem" > > > > > > > by > > > > > > > > > > > > > > > > > > "subsystem.1.class=com.netscape.cmscore.profile.ProfileSubsystem" > > > > > > > > > > > > > > and then launch > > "ipa-server-upgrade" command > > > > > > > I found this solution in this post: > > > > > > > > > > http://osdir.com/ml/freeipa-users/2016-03/msg00280.html > > > > > > > > > > > > > > Then I was able to renew my > > certificate. > > > > > > > > > > > > > > However I reboot my server to and > > pki-tomcat > > > > do not > > > > > start and > > > > > > provide with a new erreor in > > > > > /var/log/pki/pki-tomcat/ca/debug > > > > > > > > > > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > > CertUtils: > > > > > > verifySystemCertByNickname() passed: > > > > auditSigningCert > > > > > cert-pki-ca > > > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > > > SignedAuditEventFactory: create() > > > > > > > > > > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$ > > > > > > > > > > > System$][Outcome=Success][CertNickName=auditSigningCert > > > > > > cert-pki-ca] CIMC certificate > > verification > > > > > > > > > > > > > > java.lang.Exception: > > > SystemCertsVerification: > > > > system > > > > > certs > > > > > > verification failure > > > > > > > at > > > > > > > > > > > > > > > > > > > > com.netscape.cms.selftests.common.SystemCertsVerification.runSelfTest(SystemCertsVerification.java:198) > > > > > > > at > > > > > > > > > > > > > > > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.runSelfTestsAtStartup(SelfTestSubsystem.java:861) > > > > > > > at > > > > > > > > > > > > > > > > > > > > com.netscape.cmscore.selftests.SelfTestSubsystem.startup(SelfTestSubsystem.java:1797) > > > > > > > at > > > > > > > > > > > > > > > > > > > > com.netscape.cmscore.apps.CMSEngine.startupSubsystems(CMSEngine.java:1701) > > > > > > > at > > > > > > > > > > > > > > > > > com.netscape.cmscore.apps.CMSEngine.startup(CMSEngine.java:1148) > > > > > > > at > > > > com.netscape.certsrv.apps.CMS.startup(CMS.java:200) > > > > > > > at > > > > com.netscape.certsrv.apps.CMS.start(CMS.java:1602) > > > > > > > at > > > > > > > > > > > > > > > > > > > > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) > > > > > > > at > > > > > > > > javax.servlet.GenericServlet.init(GenericServlet.java:158) > > > > > > > at > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > > Method) > > > > > > > at > > > > > > > > > > > > > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > > > > at > > > > > > > > > > > > > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > > > > at > > > > java.lang.reflect.Method.invoke(Method.java:606) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) > > > > > > > at > > > > > java.security.AccessController.doPrivileged(Native > > > Method) > > > > > > > at > > > > > > > > javax.security.auth.Subject.doAsPrivileged(Subject.java:536) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) > > > > > > > at > > > > > java.security.AccessController.doPrivileged(Native > > > Method) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) > > > > > > > at > > > > > > > > > > > > > > > > > > > > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) > > > > > > > at > > > > > > > > > > > > > > > > > > > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > > > > > > > at > > > > > > > java.util.concurrent.FutureTask.run(FutureTask.java:262) > > > > > > > at > > > > > > > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > > > > > at > > > > > > > > > > > > > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > > > > > at > > java.lang.Thread.run(Thread.java:745) > > > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > > > SignedAuditEventFactory: create() > > > > > > > > > > > > > > > > > > > > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failure] > > > > > > self tests execution (see selftests.log > > > for details) > > > > > > > > > > [19/Oct/2016:11:11:52][localhost-startStop-1]: > > > > > > CMSEngine.shutdown() > > > > > > > > > > > > > > > > > > > > > I am currently stuck here. > > > > > > > Thanks a lot for your help. > > > > > > > > > > > > I'm guessing at least one of the CA > > subsystem > > > > > certificates are > > > > > > still > > > > > > expired. Look at the "getcert list" > > output > > > to see if > > > > > there are any > > > > > > expired certificates. > > > > > > > > > > > > rob > > > > > > > > > > > > > > > > > > > > Bertrand > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Rob, > > > > > > > > > > > > I check on my 2 servers and no > > certificate is > > > expired > > > > > > > > > > > > [root at sdkipa03 ~]# getcert list |grep expire > > > > > > expires: 2018-06-22 22:02:26 UTC > > > > > > expires: 2018-06-22 22:02:47 UTC > > > > > > expires: 2034-07-09 15:24:34 UTC > > > > > > expires: 2016-10-30 13:35:29 UTC > > > > > > > > > > > > [root at sdkipa01 conf]# getcert list |grep > > expire > > > > > > expires: 2018-06-12 23:38:01 UTC > > > > > > expires: 2018-06-12 23:37:41 UTC > > > > > > expires: 2018-06-11 22:53:57 UTC > > > > > > expires: 2018-06-11 22:55:50 UTC > > > > > > expires: 2018-06-11 22:57:47 UTC > > > > > > expires: 2034-07-09 15:24:34 UTC > > > > > > expires: 2018-06-11 22:59:55 UTC > > > > > > > > > > > > I see that one certificate is in status: > > > CA_UNREACHABLE, > > > > > maybe I > > > > > > reboot to soon my server... > > > > > > > > > > > > I continue to investigate > > > > > > > > > > > > Thanks for your help. > > > > > > Bertrand > > > > > > > > > > > > I fix my previous issue. > > > > > > Now I have an issue with a server. > > > > > > This server can not start pki-tomcatd, I get > > this > > > error in > > > > > debug file: > > > > > > "Error netscape.ldap.LDAPExceptio n: IO > > Error creating > > > > JSS SSL > > > > > Socket (-1)" > > > > > > > > > > > > After investigation i see that I do not have > > "ipaCert" > > > > > certificat in > > > > > > "/etc/httpd/alias" > > > > > > cf below command: > > > > > > > > > > > > [root at sdkipa03 ~]# getcert list -d > > /etc/httpd/alias > > > > > > Number of certificates and requests being > > tracked: 4. > > > > > > Request ID '20141110133632': > > > > > > status: MONITORING > > > > > > stuck: no > > > > > > 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=A.SKINFRA.EU > > > > > > subject: > > CN=sdkipa03.skinfra.eu,O=A.SKINFRA.EU > > > > > > expires: 2018-06-22 22:02:47 UTC > > > > > > principal name: > > > HTTP/sdkipa03.skinfra.eu at A.SKINFRA.EU > > > > > > key usage: > > > > > > > > > > > > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > > > > > > eku: id-kp-serverAuth,id-kp-clientAuth > > > > > > pre-save command: > > > > > > post-save command: > > > > /usr/lib64/ipa/certmonger/restart_httpd > > > > > > track: yes > > > > > > auto-renew: yes > > > > > > > > > > > > > > > > > > How can I add the certificate to > > /etc/httpd/alias? > > > > > > > > > > > Hi, > > > > > > > > > > for the record, the command getcert list that you > > > supplied > > > > shows > > > > > the > > > > > certificates in /etc/httpd/alias that are > > tracked by > > > > certmonger. > > > > > If you > > > > > want to display all the certificates contained in > > > > /etc/httpd/alias > > > > > (whether tracked or not), then you may want to use > > > > certutil -L -d > > > > > /etc/httpd/alias instead. > > > > > > > > > > If ipaCert is missing, you can export ipaCert > > > certificate from > > > > > another > > > > > master, then import it to your server. > > > > > > > > > > On a master containing the cert: > > > > > # certutil -d /etc/httpd/alias -L -n 'ipaCert' > > -a > > > > > > /tmp/newRAcert.crt > > > > > > > > > > Then copy the file /tmp/newRAcert.crt to your > > server and > > > > import > > > > > the cert: > > > > > # certutil -d /etc/httpd/alias -A -n 'ipaCert' > > -a -i > > > > > /tmp/newRAcert.crt > > > > > -t u,u,u > > > > > > > > > > And finally you need to tell certmonger to > > monitor the > > > > cert using > > > > > getcert start-tracking. > > > > > > > > > > Hope this helps, > > > > > Flo. > > > > > > > > > > > Thanks fo ryour support. > > > > > > Regards > > > > > > Bertrand > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Florence, thanks for your help. > > > > > I was able to import correctly ipaCert with your > > commands. > > > > > Now it seems that I also have an issue on one > > server with > > > > > "subsystemCert cert-pki-ca" in > > /etc/pki/pki-tomcat/alias > > > as I get > > > > > below error when pki-tomcat try to start > > > > > > > > > > > > > > > LdapJssSSLSocket set client auth cert nickname > > subsystemCert > > > > cert-pki-ca > > > > > Could not connect to LDAP server host sdkipa03.XX.YY > > > port 636 > > > > Error > > > > > netscape.ldap.LDAPException: IO Error creating JSS SSL > > > Socket ( > > > > > -1) > > > > > > > > > > > > > > > Is there a way to restore a correct "subsystemCert > > > cert-pki-ca"? > > > > > > > > > > Regards > > > > > Bertrand > > > > > > > > > > Hello, > > > > > > > > > > I am still stuck with my IPA server. > > > > > I have issues on both servers. > > > > > On server1, below certificate is not renewed properly > > > > > certutil -L -d /etc/httpd/alias/ -n "ipaCert" > > > > > > > > > > and on server 2 this is this certificate: > > > > > certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n > > "Server-Cert > > > > cert-pki-ca" > > > > > > > > > > Could you provide me with the correct syntax with > > start-tracking > > > > command. > > > > > I tried to laucnh this command but my certificat > > remains in > > > > > "NEWLY_ADDED_NEED_KEYINFO_READ_PIN" state. > > > > > Here is the comnd I use: > > > > > getcert start-tracking -c > > dogtag-ipa-retrieve-agent-submit -d > > > > > /var/lib/pki/pki-tomcat/alias -n 'Server-Cert > > cert-pki-ca' -B > > > > > /usr/lib64/ipa/certmonger/stop_pkicad -C > > > > > '/usr/lib64/ipa/certmonger/renew_ca_cert "Server-Cert > > > cert-pki-ca"' -T > > > > > "Server-Cert cert-pki-ca" -P '20160614000000' > > > > > > > > > Hi Bertrand, > > > > > > > > to get the right command, you can check on a system > > where the > > > > certificate is properly monitored, this will show you > > the right > > > > parameters: > > > > $ sudo getcert list -n ipaCert > > > > Number of certificates and requests being tracked: 8. > > > > Request ID '20161122095344': > > > > [..] key pair storage: > > > > > > > > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > > > [...] > > > > CA: dogtag-ipa-ca-renew-agent > > > > [...] > > > > pre-save command: > > > /usr/lib64/ipa/certmonger/renew_ra_cert_pre > > > > post-save command: > > /usr/lib64/ipa/certmonger/renew_ra_cert > > > > [...] > > > > > > > > The relevant fields are NSSDB location, pinfile, > > nickname, CA, > > > pre and > > > > post-save commands. So in order to monitor ipaCert, you will > > > need to use > > > > $ sudo getcert start-tracking -d /etc/httpd/alias -n > > ipaCert \ > > > > -p /etc/httpd/alias/pwdfile.txt \ > > > > -c dogtag-ipa-ca-renew-agent \ > > > > -B /usr/lib64/ipa/certmonger/renew_ra_cert_pre \ > > > > -C /usr/lib64/ipa/certmonger/renew_ra_cert > > > > > > > > HTH, > > > > Flo. > > > > > > > > > Thanks by advance for your help. > > > > > > > > > > Regards > > > > > Bertrand > > > > > > > > Hello Florence, > > > > > > > > Thanks for your reply. > > > > Before doing any mistakes, I just need some explanations as I > > > think I do > > > > not well understand how it should work. > > > > > > > > Do all the certificate need to be track by certmonger on all > > > servers or > > > > they should only be tracked on one server and FreeIPA will > > update them > > > > on other servers? > > > > > > > > In my case I have below certicates outdated and not track on > > > "server 1": > > > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n > > > "auditSigningCert > > > > cert-pki-ca" > > > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n > > "ocspSigningCert > > > > cert-pki-ca" > > > > - certutil -L -d /var/lib/pki/pki-tomcat/alias/ -n > > "subsystemCert > > > > cert-pki-ca" > > > > > > > > They are tracked by certmonger and have been correctly > > renewed on > > > "server 2" > > > > Do I need to add them tracked by certmonger on "server 1"? > > > > If not, it means FreeIPA failed to update them? Should I > > delete and > > > > import them manually on server 2? > > > > > > > > If you need more details, do not hesitate to ask. > > > > > > > Hi Bertrand, > > > > > > The certificate tracking depends on the type of certificate > > and on the > > > server you're considering. For instance, if IPA includes a > > Certificate > > > Authority, then ipaCert will be present on all the IPA servers > > > (master/replicas) and tracked on all of them. The same ipaCert > > > certificate is used on all the replicas. On the renewal > > master, the > > > renewal operation actually renews the certificate and uploads > > the cert > > > on LDAP, but on the other replicas the operation consists in > > > downloading > > > the new certificate from LDAP. > > > > > > The HTTP and LDAP server certificates are present and tracked > > on all > > > the > > > IPA servers, but they are different on each server (you can > > see that > > > the > > > Subject of the certificate contains the hostname). They can be > > renewed > > > independently on each IPA server. > > > > > > The certificates used by Dogtag (the component providing the > > > Certificate > > > System) are present and tracked only on the IPA servers where > > the CA > > > was > > > setup (for instance if you installed a replica with --setup-ca > > or if > > > you > > > ran ipa-ca-install later on). The same certificates are used > > on all > > > replicas containing a CA instance. > > > They are: 'ocspSigningCert cert-pki-ca', 'subsystemCert > > cert-pki-ca', > > > 'caSigningCert cert-pki-ca' and 'Server-Cert cert-pki-ca'. > > > The renewal operation renews them on the renewal master and > > uploads > > > them > > > in LDAP, but just downloads them from LDAP on the other servers. > > > > > > In your example, if server1 also contains a CA instance then > > it should > > > also track the above certs. > > > > > > You can find the renewal master with the following ldapsearch > > command: > > > $ ldapsearch -h localhost -p 389 -D 'cn=Directory Manager' -w > > password > > > -b "cn=masters,cn=ipa,cn=etc,$BASEDN" -LLL > > > '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn > > > dn: cn=CA,cn=ipaserver.fqdn,cn=masters,cn=ipa,cn=etc,$BASEDN > > > > > > In this case the renewal master is ipaserver.fqdn > > > > > > Hope this clarifies, > > > Flo. > > > > > > > Regards > > > > Bertrand > > > > > > > > > > > > Hi Florence, > > > > Thanks. > > All my certificate are now renewed and tracked. I set back current time > > on my servers and everything is now running properly. > > > > However now I get an issue with ldap replication. > > Here are details of my 3 servers S1, S2 S3 > > > > All below commands are launched on S1 servers > > > > # ipa-replica-manage list > > S1: master > > S2: master > > S3: master > > > > # ipa-replica-manage -v list S1 > > S2: replica > > last init status: 0 Total update succeeded > > last init ended: 2016-11-23 12:56:27+00:00 > > last update status: 0 Replica acquired successfully: Incremental > > update succeeded > > last update ended: 2016-11-23 13:12:00+00:00 > > S3: replica > > last init status: 0 Total update succeeded > > last init ended: 2016-11-23 12:54:51+00:00 > > last update status: 0 Replica acquired successfully: Incremental > > update succeeded > > last update ended: 2016-11-23 13:12:00+00:00 > > > > # ipa-replica-manage -v S2 > > S1: replica > > last init status: None > > last init ended: 1970-01-01 00:00:00+00:00 > > last update status: -1 Incremental update has failed and requires > > administrator actionLDAP error: Can't contact LDAP server > > last update ended: 1970-01-01 00:00:00+00:00 > > > > > > # ipa-replica-manage -v S3 > > S3: replica > > last init status: None > > last init ended: 1970-01-01 00:00:00+00:00 > > last update status: -1 Incremental update has failed and requires > > administrator actionLDAP error: Can't contact LDAP server > > last update ended: 1970-01-01 00:00:00+00:00 > > > > > > I tried to reinitialize S2 server, however I still get the issue: > > Command below is run on S2: > > > > S2# ipa-replica-manage re-initialize --from S1 > > ipa: INFO: Setting agreement > > cn=meToS2.skinfra.eu,cn=replica,cn=dc\=a\,dc\=skinfra\,dc\=eu,cn=mapping > > tree,cn=config schedule to 2358-2359 0 to force synch > > ipa: INFO: Deleting schedule 2358-2359 0 from agreement > > cn=meToS2,cn=replica,cn=dc\=a\,dc\=skinfra\,dc\=eu,cn=mapping > > tree,cn=config > > Update in progress, 2 seconds elapsed > > Update succeeded > > > > On S2 server in /var/log/dirsrv/slapd-REALM/errors log I get > > > > [23/Nov/2016:13:54:51 +0100] agmt="cn=meToS1" (S1:389) - Can't locate > > CSN 583669ee000a000f0000 in the changelog (DB rc=-30988). If replication > > stops, the consumer may need to be reinitialized. > > [23/Nov/2016:13:54:51 +0100] NSMMReplicationPlugin - changelog program - > > agmt="cn=meToS1" (S1:389): CSN 583669ee000a000f0000 not found, we aren't > > as up to date, or we purged > > [23/Nov/2016:13:54:51 +0100] NSMMReplicationPlugin - agmt="cn=meToS1" > > (S1:389): Data required to update replica has been purged. The replica > > must be reinitialized. > > [23/Nov/2016:13:54:51 +0100] NSMMReplicationPlugin - agmt="cn=meToS1" > > (S1:389): Incremental update failed and requires administrator action > > .............. > > [23/Nov/2016:14:18:10 +0100] slapi_ldap_bind - Error: could not bind id > > [cn=Replication Manager cloneAgreement1-S2,ou=csusers,cn=config] > > authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 > > (Success) > > > > > > I search on google but I did not find any solution to fix issue and I do > > not want to break everything > > > Hi Bertrand, > Replication applies to 2 different suffixes: the domain suffix (that > contains users and groups) and o=ipaca that contains the data for the > Certificate System (see "Explaining Replication Agreements" [1]). > The entry that is missing (cn=Replication Manager > cloneAgreement1-S2,ou=csusers,cn=config) corresponds to the replication > manager entry used for authenticating the replication of the CS > component (for more information you can read "Replication Identity" [2] > in Red Hat Directory Server Administration Guide). > I don't know how the entry disappeared, but I would try the following to > re-create it: > - remove the CA replication agreement on S2 to S1 using > ipa-csreplica-manage disconnect > - re-create the CA replication agreement on S2 to S1 using > ipa-csreplica-manage connect > You need to be sure that S1 is the most up-to-date source of data though. > Flo. > [1] > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-topology-old.html#replication-agreements > [2] > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication.html#Replication_Overview-Replication_Identity > > Regards > > Bertrand > > > > Florence, I manage to have replication working between my 3 servers. You right I had issue with that entry missing. And I did what you say in your post. After I also had issues with ruv entries that I had to delete. This post https://www.redhat.com/archives/freeipa-users/2016-January/msg00257.html helped to fix all my replication issues. Now everything seems to be working fine for 24hours! My FreeIPA infra was really in a terrible shape and without your help I would certainly not to be able to fix all issues by myself. So once again thanks a lot. Hope this thread will help other people. Brgds Bertrand -------------- next part -------------- An HTML attachment was scrubbed... URL: From peljasz at yahoo.co.uk Fri Nov 25 11:48:33 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Fri, 25 Nov 2016 11:48:33 +0000 Subject: [Freeipa-users] error; Allocation of a new value In-Reply-To: <5d001eab-4ff0-90e8-2270-d1eb1262f869@redhat.com> References: <9da362de-b66f-c7a4-1c7d-2016ee46f013@yahoo.co.uk> <5d001eab-4ff0-90e8-2270-d1eb1262f869@redhat.com> Message-ID: On 25/11/16 07:52, Martin Babinsky wrote: > On 11/24/2016 07:30 PM, lejeczek wrote: >> >> >> On 24/11/16 17:14, lejeczek wrote: >>> hi >>> >>> I see this: >>> >>> 2 ranges matched >>> ---------------- >>> Range name: xx.id_range >>> First Posix ID of the range: 1952400000 >>> Number of IDs in the range: 200000 >>> First RID of the corresponding RID range: 0 >>> Domain SID of the trusted domain: >>> S-1-5-21-1144915091-2252175215-702530032 >>> Range type: Active Directory domain range >>> >>> Range name: xx.xx.xx.xx.x_id_range >>> First Posix ID of the range: 1875000000 >>> Number of IDs in the range: 200000 >>> First RID of the corresponding RID range: 1000 >>> First RID of the secondary RID range: 100000000 >>> Range type: local domain range >>> ---------------------------- >>> Number of entries returned 2 >>> >>> some time ago when I first set up IPA I migrated users >>> from samba3's >>> ldap backend. Since then until today there was no new >>> users I needed >>> to add but now I do. >>> First on the list range I think it is a remnant of AD >>> trust which does >>> not exists any more (should it be removed?). >>> I'm not sure how to read those ranges info, one thing I >>> notice is that >>> UIDs from migration are probably between 500 & 2000 and >>> now if I >>> supply uid manually to user-add and gid (which is old >>> Samba's domain >>> users group) then creation of new user succeeds. >>> Is this normal, expected? >>> >>> mthx, >>> L >>> >> ok, solution(ldapmodify) to the problem: >> https://www.redhat.com/archives/freeipa-users/2014-February/msg00246.html >> >> but could some experts shed more light on it - I see that >> some time >> ago(after migration/import) I actually created manually a >> user: >> $ id netdevadmin >> uid=1875000006(netdevadmin) gid=1875000006(netdevadmin) >> groups=1875000006(netdevadmin) >> >> today, after ldapmodify I create a new user but uids seem >> to come from >> (what?) a different range?? >> $ id appmgr >> uid=3501(appmgr) gid=3501(appmgr) groups=3501(appmgr) >> >> what's is happening? >> regards >> L >> > > You are seeing this because you probably set s too low > (5000 or so) and, as tha name of the attribute implies, it > sets the maximum UID/GID for the range assigned by the > plugin. > > By default, the local IPA ID ranges are set to huge > numbers (on my test VMs I have dnaMaxValue 241799999) to > aviod collisions with UIDs/GIDs of local users which are > typically in the range of thousands/tens of thousands). > > However, the changes done directly in the DNA plugin > configuration are not reflected in ID range objects, > that's why you may observe the disparity between ID range > characteristics and actual UIDs/GIDs provisioned. > can you guess what changed those dnaMaxValue after initial setup/installation (soon after I created 1875000006(netdevadmin), UID was assigned by IPA)? It certainly was not me. Should I worry about these disparities? Should I be setting dnaMaxValue(and any relavent) to correspond to idrange(s)? Lastly, I see my IPA has two ranges, one is from AD trust which has been removed, is it ok to leave/keep that range? mthx, L. From mbabinsk at redhat.com Fri Nov 25 12:02:25 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 25 Nov 2016 13:02:25 +0100 Subject: [Freeipa-users] error; Allocation of a new value In-Reply-To: References: <9da362de-b66f-c7a4-1c7d-2016ee46f013@yahoo.co.uk> <5d001eab-4ff0-90e8-2270-d1eb1262f869@redhat.com> Message-ID: <2555f01f-7403-ffd9-2194-25cec24fa566@redhat.com> On 11/25/2016 12:48 PM, lejeczek wrote: > > > On 25/11/16 07:52, Martin Babinsky wrote: >> On 11/24/2016 07:30 PM, lejeczek wrote: >>> >>> >>> On 24/11/16 17:14, lejeczek wrote: >>>> hi >>>> >>>> I see this: >>>> >>>> 2 ranges matched >>>> ---------------- >>>> Range name: xx.id_range >>>> First Posix ID of the range: 1952400000 >>>> Number of IDs in the range: 200000 >>>> First RID of the corresponding RID range: 0 >>>> Domain SID of the trusted domain: >>>> S-1-5-21-1144915091-2252175215-702530032 >>>> Range type: Active Directory domain range >>>> >>>> Range name: xx.xx.xx.xx.x_id_range >>>> First Posix ID of the range: 1875000000 >>>> Number of IDs in the range: 200000 >>>> First RID of the corresponding RID range: 1000 >>>> First RID of the secondary RID range: 100000000 >>>> Range type: local domain range >>>> ---------------------------- >>>> Number of entries returned 2 >>>> >>>> some time ago when I first set up IPA I migrated users from samba3's >>>> ldap backend. Since then until today there was no new users I needed >>>> to add but now I do. >>>> First on the list range I think it is a remnant of AD trust which does >>>> not exists any more (should it be removed?). >>>> I'm not sure how to read those ranges info, one thing I notice is that >>>> UIDs from migration are probably between 500 & 2000 and now if I >>>> supply uid manually to user-add and gid (which is old Samba's domain >>>> users group) then creation of new user succeeds. >>>> Is this normal, expected? >>>> >>>> mthx, >>>> L >>>> >>> ok, solution(ldapmodify) to the problem: >>> https://www.redhat.com/archives/freeipa-users/2014-February/msg00246.html >>> >>> but could some experts shed more light on it - I see that some time >>> ago(after migration/import) I actually created manually a user: >>> $ id netdevadmin >>> uid=1875000006(netdevadmin) gid=1875000006(netdevadmin) >>> groups=1875000006(netdevadmin) >>> >>> today, after ldapmodify I create a new user but uids seem to come from >>> (what?) a different range?? >>> $ id appmgr >>> uid=3501(appmgr) gid=3501(appmgr) groups=3501(appmgr) >>> >>> what's is happening? >>> regards >>> L >>> >> >> You are seeing this because you probably set s too low (5000 or so) >> and, as tha name of the attribute implies, it sets the maximum UID/GID >> for the range assigned by the plugin. >> >> By default, the local IPA ID ranges are set to huge numbers (on my >> test VMs I have dnaMaxValue 241799999) to aviod collisions with >> UIDs/GIDs of local users which are typically in the range of >> thousands/tens of thousands). >> >> However, the changes done directly in the DNA plugin configuration are >> not reflected in ID range objects, that's why you may observe the >> disparity between ID range characteristics and actual UIDs/GIDs >> provisioned. >> > can you guess what changed those dnaMaxValue after initial > setup/installation (soon after I created 1875000006(netdevadmin), UID > was assigned by IPA)? It certainly was not me. Well, you wrote: > ok, solution(ldapmodify) to the problem: > https://www.redhat.com/archives/freeipa-users/2014-February/msg00246.html so I guess you indeed changed the value by running ldapmodify? > Should I worry about these disparities? Should I be setting > dnaMaxValue(and any relavent) to correspond to idrange(s)? I general, I would not meddle with DNA plugin settings unless something is seriously wrong (like a replica that did not receive any DNA range block before the master was decomissioned, se [1]), and even then I would be extra careful to set the DNA plugin ranges to correspond to the actual IPA ID ranges to avoid any UID/GID collisions (which can get nasty very quickly). > Lastly, I see my IPA has two ranges, one is from AD trust which has been > removed, is it ok to leave/keep that range? > The leftover range from AD does no harm, you can safely remove it just to avoid confusion. > mthx, > L. > > [1] http://www.freeipa.org/page/V3/Recover_DNA_Ranges -- Martin^3 Babinsky From peljasz at yahoo.co.uk Fri Nov 25 12:18:10 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Fri, 25 Nov 2016 12:18:10 +0000 Subject: [Freeipa-users] error; Allocation of a new value In-Reply-To: <2555f01f-7403-ffd9-2194-25cec24fa566@redhat.com> References: <9da362de-b66f-c7a4-1c7d-2016ee46f013@yahoo.co.uk> <5d001eab-4ff0-90e8-2270-d1eb1262f869@redhat.com> <2555f01f-7403-ffd9-2194-25cec24fa566@redhat.com> Message-ID: On 25/11/16 12:02, Martin Babinsky wrote: > On 11/25/2016 12:48 PM, lejeczek wrote: >> >> >> On 25/11/16 07:52, Martin Babinsky wrote: >>> On 11/24/2016 07:30 PM, lejeczek wrote: >>>> >>>> >>>> On 24/11/16 17:14, lejeczek wrote: >>>>> hi >>>>> >>>>> I see this: >>>>> >>>>> 2 ranges matched >>>>> ---------------- >>>>> Range name: xx.id_range >>>>> First Posix ID of the range: 1952400000 >>>>> Number of IDs in the range: 200000 >>>>> First RID of the corresponding RID range: 0 >>>>> Domain SID of the trusted domain: >>>>> S-1-5-21-1144915091-2252175215-702530032 >>>>> Range type: Active Directory domain range >>>>> >>>>> Range name: xx.xx.xx.xx.x_id_range >>>>> First Posix ID of the range: 1875000000 >>>>> Number of IDs in the range: 200000 >>>>> First RID of the corresponding RID range: 1000 >>>>> First RID of the secondary RID range: 100000000 >>>>> Range type: local domain range >>>>> ---------------------------- >>>>> Number of entries returned 2 >>>>> >>>>> some time ago when I first set up IPA I migrated users >>>>> from samba3's >>>>> ldap backend. Since then until today there was no new >>>>> users I needed >>>>> to add but now I do. >>>>> First on the list range I think it is a remnant of AD >>>>> trust which does >>>>> not exists any more (should it be removed?). >>>>> I'm not sure how to read those ranges info, one thing >>>>> I notice is that >>>>> UIDs from migration are probably between 500 & 2000 >>>>> and now if I >>>>> supply uid manually to user-add and gid (which is old >>>>> Samba's domain >>>>> users group) then creation of new user succeeds. >>>>> Is this normal, expected? >>>>> >>>>> mthx, >>>>> L >>>>> >>>> ok, solution(ldapmodify) to the problem: >>>> https://www.redhat.com/archives/freeipa-users/2014-February/msg00246.html >>>> >>>> >>>> but could some experts shed more light on it - I see >>>> that some time >>>> ago(after migration/import) I actually created manually >>>> a user: >>>> $ id netdevadmin >>>> uid=1875000006(netdevadmin) gid=1875000006(netdevadmin) >>>> groups=1875000006(netdevadmin) >>>> >>>> today, after ldapmodify I create a new user but uids >>>> seem to come from >>>> (what?) a different range?? >>>> $ id appmgr >>>> uid=3501(appmgr) gid=3501(appmgr) groups=3501(appmgr) >>>> >>>> what's is happening? >>>> regards >>>> L >>>> >>> >>> You are seeing this because you probably set s too low >>> (5000 or so) >>> and, as tha name of the attribute implies, it sets the >>> maximum UID/GID >>> for the range assigned by the plugin. >>> >>> By default, the local IPA ID ranges are set to huge >>> numbers (on my >>> test VMs I have dnaMaxValue 241799999) to aviod >>> collisions with >>> UIDs/GIDs of local users which are typically in the >>> range of >>> thousands/tens of thousands). >>> >>> However, the changes done directly in the DNA plugin >>> configuration are >>> not reflected in ID range objects, that's why you may >>> observe the >>> disparity between ID range characteristics and actual >>> UIDs/GIDs >>> provisioned. >>> >> can you guess what changed those dnaMaxValue after initial >> setup/installation (soon after I created >> 1875000006(netdevadmin), UID >> was assigned by IPA)? It certainly was not me. > Well, you wrote: > > > ok, solution(ldapmodify) to the problem: > > > https://www.redhat.com/archives/freeipa-users/2014-February/msg00246.html > > so I guess you indeed changed the value by running > ldapmodify? well, I did but only now, hoping to fix: ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. and before I did, those values were: # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config cn: Posix IDs dnaMaxValue: 1100 dnaNextValue: 1101 dnaThreshold: 500 dnaType: uidNumber dnaType: gidNumber objectClass: top objectClass: extensibleObject >> Should I worry about these disparities? Should I be setting >> dnaMaxValue(and any relavent) to correspond to idrange(s)? > I general, I would not meddle with DNA plugin settings > unless something is seriously wrong (like a replica that > did not receive any DNA range block before the master was > decomissioned, se [1]), and even then I would be extra > careful to set the DNA plugin ranges to correspond to the > actual IPA ID ranges to avoid any UID/GID collisions > (which can get nasty very quickly). > so, would you say what should be the value of dnaMaxValue in case of that rage my IPA shows? >> Lastly, I see my IPA has two ranges, one is from AD trust >> which has been >> removed, is it ok to leave/keep that range? >> > > The leftover range from AD does no harm, you can safely > remove it just to avoid confusion. >> mthx, >> L. >> >> > > > [1] http://www.freeipa.org/page/V3/Recover_DNA_Ranges From tk at mdevsys.com Fri Nov 25 13:48:45 2016 From: tk at mdevsys.com (TomK) Date: Fri, 25 Nov 2016 08:48:45 -0500 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: <16d0ec1a-f4ed-4759-3f51-d000a0515097@redhat.com> References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> <97e67d02-a736-239e-0d65-5ce551454a1f@mdevsys.com> <2837abb4-3605-1946-e752-a09b289439c5@redhat.com> <731bb495-e534-8581-9da4-ae57f9f6b466@mdevsys.com> <0c386e0e-dce9-d1b1-960c-d91690fbbc9f@mdevsys.com> <16d0ec1a-f4ed-4759-3f51-d000a0515097@redhat.com> Message-ID: <0ddffb55-7b97-9a59-d67d-314671cc966e@mdevsys.com> On 11/25/2016 4:00 AM, Petr Spacek wrote: > On 25.11.2016 05:57, TomK wrote: >> On 11/24/2016 4:49 AM, Petr Spacek wrote: >>> On 24.11.2016 06:08, TomK wrote: >>>> On 11/23/2016 3:28 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 23.11.2016 03:48, TomK wrote: >>>>>> On 11/22/2016 10:22 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 22.11.2016 13:57, TomK wrote: >>>>>>>> On 11/22/2016 2:59 AM, Martin Basti wrote: >>>>>>>>> Hey, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 22.11.2016 06:33, TomK wrote: >>>>>>>>>> Hey Guy's, >>>>>>>>>> >>>>>>>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 >>>>>>>>>> over to >>>>>>>>>> my dual Free IPA server. The Free IPA servers are authoritative for >>>>>>>>>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>>>>>>>>> and forwards dom.abc.xyz. >>>>>>>>> Do you have configured proper zone delegation for subdomain >>>>>>>>> dom.abc.xyz? >>>>>>>>> Proper NS and glue records >>>>>>>>> http://www.zytrax.com/books/dns/ch9/delegate.html >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I cannot ping dom.abc.xyz. Everything else, including client >>>>>>>>>> registrations, work fine. If Free IPA is authoritative on >>>>>>>>>> dom.abc.xyz, should it not create DNS entries so the sub domain >>>>>>>>>> can be >>>>>>>>>> pinged as well? >>>>>>>>> >>>>>>>>> What do you mean by "ping"? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>>>>>>>>> and wanted to ask if you can point me to some materials online to >>>>>>>>>> determine where can I permanently adjust the search to add >>>>>>>>>> dom.abc.xyz >>>>>>>>>> to the already present abc.xyz . I wasn't able to locate what I >>>>>>>>>> needed in my searches. >>>>>>>>>> >>>>>>>>>> I'm using the latest v4. >>>>>>>>> >>>>>>>>> It depends on what are you using, probably you have NetworkManager >>>>>>>>> there >>>>>>>>> that is editing /etc/resolv.conf >>>>>>>>> >>>>>>>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Martin >>>>>>>> >>>>>>>> >>>>>>>> I Uninstalled NetworkManager. Still changes. >>>>>>>> ping dom.abc.com results in "ping: unknown host" >>>>>>>> >>>>>>>> I'll have a look at the first link, ty. >>>>>>>> >>>>>>> >>>>>>> ping (ICMP protocol) and DNS system are different things, do you have >>>>>>> hostname dom.abc.com with A record or it is a zone? >>>>>>> >>>>>>> with ping command hostname "dom.abc.com" is resolved to IP address >>>>>>> first, do you have A record set for dom.abc.com in zone apex or what are >>>>>>> you trying to achieve with ping command? >>>>>>> >>>>>>> for testing DNS try to use commands: dig, host, nslookup >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> Apologize for the long reply but it should give some background on >>>>>> what it is that I'm doing. >>>>>> >>>>>> 1) dom.abc.com is a zone. There is no A record for dom.abc.com in >>>>>> FreeIPA (Confirmed by Petr). I get the point Petr Spacek pointed out >>>>>> in his comment as well. What should it really point too? ( I kind of >>>>>> answer this question below so please read on. ) Where I'm getting >>>>>> this from is that in Windows Server 2012 abc.com returns the IP of any >>>>>> of the participating AD / DNS servers within the cluster (The two >>>>>> Windows Server 2012 are a combined clustered AD + DNS servers.). >>>>>> Being able to resolve abc.xyz is handy. During a lookup, I can get a >>>>>> list of all the IP's associated with that domain which would indicate >>>>>> all the DNS + AD servers online under that domain or serving that domain: >>>>>> >>>>>> >>>>>> # nslookup abc.xyz >>>>>> Server: 192.168.0.3 >>>>>> Address: 192.168.0.3#53 >>>>>> >>>>>> Name: abc.xyz >>>>>> Address: 192.168.0.3 >>>>>> Name: abc.xyz >>>>>> Address: 192.168.0.1 >>>>>> Name: abc.xyz >>>>>> Address: 192.168.0.2 >>>>>> # >>>>>> >>>>>> Again, where this is handy is when configuring sssd.conf for example >>>>>> or other apps for that matter. I can just point the app to >>>>>> authenticate against the domain and I have my redundancy solved. >>>>>> Windows Server 2012 does it, but FreeIPA didn't, so I threw the >>>>>> question out there. >>>>> >>>>> IPA uses SRV records heavily, all IPA related services have SRV records, >>>>> SSSD uses SRV records of IPA, client should use SRV record to connect to >>>>> the right service (or URI record - will be in next IPA). SRV records >>>>> work for IPA locations mechanism, we cannot achieve this with pure A >>>>> records. >>>>> >>>>>> >>>>>> Delegation from this Windows DNS works as expected. Any lookup from >>>>>> dom.abc.xyz is forwarded too and handled by FreeIPA servers. Tested >>>>>> this out. No issue with this. >>>>>> >>>>>> I did see earlier that there is no A record for dom.abc.xyz in >>>>>> FreeIPA. My reasons for asking if there was an IP on the subdomain in >>>>>> FreeIPA were above but the missing IP on the subdomain isn't a major >>>>>> issue for me. Things are working without dom.abc.xyz resolving to an >>>>>> IP. What I was hoping for is to have a VIP for the IPA servers and >>>>>> one for the Windows Server 2012 DNS Cluster in /etc/resolv.conf. (I >>>>>> have the VIP for the windows server). One forwarding to the other for >>>>>> a given domain. This is all for testing a) redundancy, b) forwarding, >>>>>> a) authentication . >>>>>> >>>>>> IE: >>>>>> >>>>>> # cat /etc/resolv.conf >>>>>> search dom.abc.xyz abc.xyz >>>>>> nameserver 192.168.0.3 <------------ Win Cluster DNS VIP >>>>>> nameserver 192.168.0.4 <------------ IPA Cluster DNS VIP >>>>>> >>>>>> * Just what I want to achieve above. VIP 192.168.0.4 doesn't exist on >>>>>> my cluster yet. I'm looking to integrate ucarp with the above IPA >>>>>> servers. >>>>>> >>>>>> >>>>>> 2) More to the topic of my second question however, is that >>>>>> /etc/resolv.conf, on the IPA servers themselves, get's rewritten on >>>>>> restart. Would like to know by what if I already uninstalled >>>>>> NetworkManager? When I configured the FreeIPA server, I used: >>>>>> >>>>>> ipa-server-install --setup-dns --forwarder=192.168.0.3 -p "Hush!" -a >>>>>> "Hush!" -r DOM.ABC.XYZ -n dom.abc.xyz --hostname ipa01.dom.abc.xyz >>>>>> >>>>>> Notice I used the VIP of the Windows Server 2012 Cluster when >>>>>> installing FreeIPA. This is nice for redundancy. So the resolv.conf >>>>>> ends up being: >>>>>> >>>>>> # cat /etc/resolv.conf >>>>>> # Generated by NetworkManager >>>>>> search abc.xyz >>>>>> nameserver 192.168.0.3 >>>>>> nameserver 123.123.123.1 >>>>>> nameserver 123.123.123.2 >>>>>> >>>>>> Then I add: >>>>>> >>>>>> search dom.abc.xyz abc.xyz >>>>>> >>>>>> but it changes back to search abc.xyz (the Windows Server 2012 DNS). >>>>>> This all works, except for the above minor items, and I can resolve >>>>>> anything over this network. ( Thinking this is fine because the >>>>>> forward is on the subdomain. I haven't had issues with forwarding >>>>>> through this setup. ) >>>>>> >>>>>> # cat /etc/resolv.conf >>>>>> # Generated by NetworkManager >>>>>> search abc.xyz >>>>>> nameserver 192.168.0.3 >>>>>> nameserver 123.123.123.1 >>>>>> nameserver 123.123.123.2 >>>>>> >>>>>> But NetworkManager is not installed on these IPA servers. I've >>>>>> removed it earlier: >>>>>> >>>>>> # rpm -aq|grep -i NetworkManager >>>>>> # >>>>>> >>>>>> Is FreeIPA replacing /etc/resolv.conf with a copy it keeps elsewhere? >>>>> >>>>> On servers with DNS /etc/resolv.conf should point to 127.0.0.1 and ::1, >>>>> and global or per server dns forwarders should be configured instead >>>>> >>>>> Have you properly stopped NetworkManager using systemctl stop and >>>>> systemctl disable ? In case you just removed rpm files service can still >>>>> work. >>>>> I recommend to update network manager config, not to remove it :) >>>>> >>>>> As last resort way, you can set immutable bit to resolv.conf if >>>>> something is still changing your resolv.conf file >>>>> >>>>>> >>>>>> 3) After running: >>>>>> >>>>>> ipa-client-install --mkhomedir --enable-dns-updates >>>>>> >>>>>> on a new host, the hostname of the new host doesn't resolve for a few >>>>>> minutes. How do I make this instantaneous? (Other then that, >>>>>> autodiscovery of the IPA servers is excellent!). Before installing >>>>>> the IPA Client, the new hosts /etc/resolv.conf file looks like this: >>>>>> >>>>>> # cat /etc/resolv.conf >>>>>> search abc.xyz >>>>>> nameserver 192.168.0.3 >>>>>> nameserver 123.123.123.1 >>>>>> nameserver 123.123.123.2 >>>>>> >>>>>> I did dig, host, nslookup earlier. Verified all except for the items >>>>>> I'm inquiring about. >>>>>> >>>>> >>>>> That weird, because ipa-client-install creates A records directly to DNS >>>>> server using nsupdate, so it should be accessible instantly. Do you have >>>>> any caching DNS servers? >>>>> >>>>> Martin >>>>> >>>> >>>> No caching DNS servers. >>>> >>>> On the topic of NetworkManager. It's completely gone yet still the >>>> /etc/resolv.conf file is being replaced with the text # Generated by >>>> NetworkManager. >>>> >>>> # systemctl show NetworkManager.service --property=Id,Names,Description >>>> Id=NetworkManager.service >>>> Names=NetworkManager.service >>>> Description=NetworkManager.service >>>> # >>>> >>>> # systemctl list-units --type service --all|grep -i network >>>> network.service loaded active exited LSB: Bring >>>> up/down networking >>>> ? NetworkManager-wait-online.service not-found inactive dead >>>> NetworkManager-wait-online.service >>>> ? NetworkManager.service not-found inactive dead >>>> NetworkManager.service >>>> ntpd.service loaded active running Network >>>> Time Service >>>> rhel-domainname.service loaded active exited Read and >>>> set NIS domainname from /etc/sysconfig/network >>>> rhel-import-state.service loaded active exited Import >>>> network configuration from initramfs >>>> # >>>> >>>> >>>> The only thing that is left of the NetworkManager service is the above. >>>> Nothing I type from systemd removed it completely. So I've reverted to the >>>> last resort: >>>> >>>> # lsattr /etc/resolv.conf >>>> ----i----------- /etc/resolv.conf >>>> # >>>> >>>> With the above, I'm trying to see what's writing to the file by using this >>>> auditctl and found that postfix seems to be doing this: >>>> >>>> ---- >>>> time->Wed Nov 23 23:14:47 2016 >>>> type=PATH msg=audit(1479960887.978:293): item=0 name="/etc/resolv.conf" >>>> inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 >>>> obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>> type=CWD msg=audit(1479960887.978:293): cwd="/" >>>> type=SYSCALL msg=audit(1479960887.978:293): arch=c000003e syscall=2 >>>> success=yes exit=4 a0=7ffb36b6f43a a1=80000 a2=1b6 a3=24 items=1 ppid=1 >>>> pid=5527 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >>>> fsgid=0 tty=(none) ses=4294967295 comm="postfix" exe="/usr/sbin/postfix" >>>> subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" >>>> ---- >>>> time->Wed Nov 23 23:14:48 2016 >>>> type=PATH msg=audit(1479960888.013:301): item=0 name="/etc/resolv.conf" >>>> inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 >>>> obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>> type=CWD msg=audit(1479960888.013:301): cwd="/var/spool/postfix" >>>> type=SYSCALL msg=audit(1479960888.013:301): arch=c000003e syscall=2 >>>> success=yes exit=3 a0=7f32c163043a a1=80000 a2=1b6 a3=24 items=1 ppid=5545 >>>> pid=5546 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >>>> fsgid=0 tty=(none) ses=4294967295 comm="postconf" exe="/usr/sbin/postconf" >>>> subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" >>> >>> It usually helps to run ausearch -i, it translates numberic codes to names. >>> >>> Assuming you are running Linux on x86_64, it would be interpreted like this: >>> >>> ---- >>> type=SYSCALL msg=audit(24.11.2016 05:14:47.978:293) : arch=x86_64 syscall=open >>> success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>> items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root >>> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix >>> exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 >>> key=/root/resolv.conf-file >>> type=CWD msg=audit(24.11.2016 05:14:47.978:293) : cwd=/ >>> type=PATH msg=audit(24.11.2016 05:14:47.978:293) : item=0 >>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>> ---- >>> type=SYSCALL msg=audit(24.11.2016 05:14:48.013:301) : arch=x86_64 syscall=open >>> success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>> items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root >>> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf >>> exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 >>> key=/root/resolv.conf-file >>> type=CWD msg=audit(24.11.2016 05:14:48.013:301) : cwd=/var/spool/postfix >>> type=PATH msg=audit(24.11.2016 05:14:48.013:301) : item=0 >>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>> >>> >>> In other words, /root/resolv.conf-file is open for reading. >>> >>> It is interesting ... What does the file contain? >>> >>> Petr^2 Spacek >>> >>> >>>> >>>> This in turn appears to be called by started by: >>>> >>>> # grep postfix access|tail -n 1 >>>> [23/Nov/2016:23:42:04 -0500] conn=34 op=5 SRCH >>>> base="cn=accounts,dc=dom,dc=abc,dc=xyz" scope=2 >>>> filter="(&(uid=postfix)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))" >>>> >>>> attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory >>>> loginShell krbPrincipalName cn memberOf ipaUniqueID ipaNTSecurityIdentifier >>>> modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning >>>> shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration >>>> pwdattribute authorizedService accountexpires useraccountcontrol nsAccountLock >>>> host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey >>>> ipaUserAuthType usercertificate;binary" >>>> # pwd >>>> /var/log/dirsrv/slapd-DOM-ABC-XYZ >> >> root/resolv.conf-file is only a identifier (key) by which auditctl marked >> events that occurred on /etc/resolv.conf. In other words, it was just a >> custom assigned identifier I used that read / write requests got tagged with. >> I really should have called it 'resolv-conf-identifier' or similar to avoid >> confusion. It's not a file. >> >> The commands I used to watch the file are: >> >> /sbin/ausearch -f /etc/resolv.conf -key=/root/resolv.conf-file >> >> Then to get events: >> >> /sbin/ausearch -f /etc/resolv.conf --key "/root/resolv.conf-file" >> >> Adding the -i as per your note, I get this: >> >> >> [root at idmipa01 ~]# /sbin/ausearch -f /etc/resolv.conf --key >> "/root/resolv.conf-file" -i >> ---- >> type=PATH msg=audit(11/23/2016 23:14:04.708:287) : item=0 >> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >> type=CWD msg=audit(11/23/2016 23:14:04.708:287) : >> cwd=/var/log/dirsrv/slapd-NIX-MDS-XYZ >> type=SYSCALL msg=audit(11/23/2016 23:14:04.708:287) : arch=x86_64 syscall=open >> success=yes exit=53 a0=0x7f66d82c243a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >> items=1 ppid=1 pid=5080 auid=unset uid=dirsrv gid=dirsrv euid=dirsrv >> suid=dirsrv fsuid=dirsrv egid=dirsrv sgid=dirsrv fsgid=dirsrv tty=(none) >> ses=unset comm=ns-slapd exe=/usr/sbin/ns-slapd >> subj=system_u:system_r:dirsrv_t:s0 key=/root/resolv.conf-file >> ---- >> type=PATH msg=audit(11/23/2016 23:14:32.182:288) : item=0 >> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >> type=CWD msg=audit(11/23/2016 23:14:32.182:288) : cwd=/var/log/audit >> type=SYSCALL msg=audit(11/23/2016 23:14:32.182:288) : arch=x86_64 syscall=open >> success=yes exit=3 a0=0x7fffd2fa47ff a1=O_RDONLY|O_NONBLOCK a2=0x7fffd2fa2f00 >> a3=0x7fffd2fa2c70 items=1 ppid=2389 pid=5511 auid=root uid=root gid=root >> euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 >> comm=chattr exe=/usr/bin/chattr >> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >> key=/root/resolv.conf-file >> ---- >> type=PATH msg=audit(11/23/2016 23:14:32.182:289) : item=0 >> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >> type=CWD msg=audit(11/23/2016 23:14:32.182:289) : cwd=/var/log/audit >> type=SYSCALL msg=audit(11/23/2016 23:14:32.182:289) : arch=x86_64 syscall=open >> success=yes exit=3 a0=0x7fffd2fa47ff a1=O_RDONLY|O_NONBLOCK a2=0x7fffd2fa2f00 >> a3=0x7fffd2fa2d50 items=1 ppid=2389 pid=5511 auid=root uid=root gid=root >> euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 >> comm=chattr exe=/usr/bin/chattr >> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >> key=/root/resolv.conf-file >> ---- >> type=PATH msg=audit(11/23/2016 23:14:36.847:290) : item=0 >> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >> type=CWD msg=audit(11/23/2016 23:14:36.847:290) : cwd=/var/log/audit >> type=SYSCALL msg=audit(11/23/2016 23:14:36.847:290) : arch=x86_64 syscall=open >> success=yes exit=3 a0=0x7fff791a17ff a1=O_RDONLY|O_NONBLOCK a2=0x7fff791a0180 >> a3=0x7fff7919fef0 items=1 ppid=2389 pid=5512 auid=root uid=root gid=root >> euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 >> comm=lsattr exe=/usr/bin/lsattr >> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >> key=/root/resolv.conf-file >> ---- >> type=PATH msg=audit(11/23/2016 23:14:47.978:293) : item=0 >> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >> type=CWD msg=audit(11/23/2016 23:14:47.978:293) : cwd=/ >> type=SYSCALL msg=audit(11/23/2016 23:14:47.978:293) : arch=x86_64 syscall=open >> success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >> items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root >> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix >> exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 >> key=/root/resolv.conf-file >> ---- >> type=PATH msg=audit(11/23/2016 23:14:48.013:301) : item=0 >> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >> type=CWD msg=audit(11/23/2016 23:14:48.013:301) : cwd=/var/spool/postfix >> type=SYSCALL msg=audit(11/23/2016 23:14:48.013:301) : arch=x86_64 syscall=open >> success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >> items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root >> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf >> exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 >> key=/root/resolv.conf-file >> [root at idmipa01 ~]# > > Okay, the important part is that all open() syscalls have parameter O_RDONLY > so there is nothing writing to the file. > > The wrong value must have get into resolv.conf by some other means. > So the only way for me to find out what's modifying that file is to step through the boot process since auditctl might not be loading yet or simply has to be loaded manually each time to capture anything of value. The command I ran is: /sbin/auditctl -w /etc/resolv.conf -p war -k /root/resolv.conf-file Can't find a convenient way to capture this at boot. I know /etc/resolv.conf changes through run level changes. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From pspacek at redhat.com Fri Nov 25 14:09:52 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 25 Nov 2016 15:09:52 +0100 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: <0ddffb55-7b97-9a59-d67d-314671cc966e@mdevsys.com> References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> <97e67d02-a736-239e-0d65-5ce551454a1f@mdevsys.com> <2837abb4-3605-1946-e752-a09b289439c5@redhat.com> <731bb495-e534-8581-9da4-ae57f9f6b466@mdevsys.com> <0c386e0e-dce9-d1b1-960c-d91690fbbc9f@mdevsys.com> <16d0ec1a-f4ed-4759-3f51-d000a0515097@redhat.com> <0ddffb55-7b97-9a59-d67d-314671cc966e@mdevsys.com> Message-ID: On 25.11.2016 14:48, TomK wrote: > On 11/25/2016 4:00 AM, Petr Spacek wrote: >> On 25.11.2016 05:57, TomK wrote: >>> On 11/24/2016 4:49 AM, Petr Spacek wrote: >>>> On 24.11.2016 06:08, TomK wrote: >>>>> On 11/23/2016 3:28 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 23.11.2016 03:48, TomK wrote: >>>>>>> On 11/22/2016 10:22 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 22.11.2016 13:57, TomK wrote: >>>>>>>>> On 11/22/2016 2:59 AM, Martin Basti wrote: >>>>>>>>>> Hey, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 22.11.2016 06:33, TomK wrote: >>>>>>>>>>> Hey Guy's, >>>>>>>>>>> >>>>>>>>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 >>>>>>>>>>> over to >>>>>>>>>>> my dual Free IPA server. The Free IPA servers are authoritative for >>>>>>>>>>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>>>>>>>>>> and forwards dom.abc.xyz. >>>>>>>>>> Do you have configured proper zone delegation for subdomain >>>>>>>>>> dom.abc.xyz? >>>>>>>>>> Proper NS and glue records >>>>>>>>>> http://www.zytrax.com/books/dns/ch9/delegate.html >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I cannot ping dom.abc.xyz. Everything else, including client >>>>>>>>>>> registrations, work fine. If Free IPA is authoritative on >>>>>>>>>>> dom.abc.xyz, should it not create DNS entries so the sub domain >>>>>>>>>>> can be >>>>>>>>>>> pinged as well? >>>>>>>>>> >>>>>>>>>> What do you mean by "ping"? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>>>>>>>>>> and wanted to ask if you can point me to some materials online to >>>>>>>>>>> determine where can I permanently adjust the search to add >>>>>>>>>>> dom.abc.xyz >>>>>>>>>>> to the already present abc.xyz . I wasn't able to locate what I >>>>>>>>>>> needed in my searches. >>>>>>>>>>> >>>>>>>>>>> I'm using the latest v4. >>>>>>>>>> >>>>>>>>>> It depends on what are you using, probably you have NetworkManager >>>>>>>>>> there >>>>>>>>>> that is editing /etc/resolv.conf >>>>>>>>>> >>>>>>>>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>> >>>>>>>>> >>>>>>>>> I Uninstalled NetworkManager. Still changes. >>>>>>>>> ping dom.abc.com results in "ping: unknown host" >>>>>>>>> >>>>>>>>> I'll have a look at the first link, ty. >>>>>>>>> >>>>>>>> >>>>>>>> ping (ICMP protocol) and DNS system are different things, do you have >>>>>>>> hostname dom.abc.com with A record or it is a zone? >>>>>>>> >>>>>>>> with ping command hostname "dom.abc.com" is resolved to IP address >>>>>>>> first, do you have A record set for dom.abc.com in zone apex or what are >>>>>>>> you trying to achieve with ping command? >>>>>>>> >>>>>>>> for testing DNS try to use commands: dig, host, nslookup >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> Apologize for the long reply but it should give some background on >>>>>>> what it is that I'm doing. >>>>>>> >>>>>>> 1) dom.abc.com is a zone. There is no A record for dom.abc.com in >>>>>>> FreeIPA (Confirmed by Petr). I get the point Petr Spacek pointed out >>>>>>> in his comment as well. What should it really point too? ( I kind of >>>>>>> answer this question below so please read on. ) Where I'm getting >>>>>>> this from is that in Windows Server 2012 abc.com returns the IP of any >>>>>>> of the participating AD / DNS servers within the cluster (The two >>>>>>> Windows Server 2012 are a combined clustered AD + DNS servers.). >>>>>>> Being able to resolve abc.xyz is handy. During a lookup, I can get a >>>>>>> list of all the IP's associated with that domain which would indicate >>>>>>> all the DNS + AD servers online under that domain or serving that domain: >>>>>>> >>>>>>> >>>>>>> # nslookup abc.xyz >>>>>>> Server: 192.168.0.3 >>>>>>> Address: 192.168.0.3#53 >>>>>>> >>>>>>> Name: abc.xyz >>>>>>> Address: 192.168.0.3 >>>>>>> Name: abc.xyz >>>>>>> Address: 192.168.0.1 >>>>>>> Name: abc.xyz >>>>>>> Address: 192.168.0.2 >>>>>>> # >>>>>>> >>>>>>> Again, where this is handy is when configuring sssd.conf for example >>>>>>> or other apps for that matter. I can just point the app to >>>>>>> authenticate against the domain and I have my redundancy solved. >>>>>>> Windows Server 2012 does it, but FreeIPA didn't, so I threw the >>>>>>> question out there. >>>>>> >>>>>> IPA uses SRV records heavily, all IPA related services have SRV records, >>>>>> SSSD uses SRV records of IPA, client should use SRV record to connect to >>>>>> the right service (or URI record - will be in next IPA). SRV records >>>>>> work for IPA locations mechanism, we cannot achieve this with pure A >>>>>> records. >>>>>> >>>>>>> >>>>>>> Delegation from this Windows DNS works as expected. Any lookup from >>>>>>> dom.abc.xyz is forwarded too and handled by FreeIPA servers. Tested >>>>>>> this out. No issue with this. >>>>>>> >>>>>>> I did see earlier that there is no A record for dom.abc.xyz in >>>>>>> FreeIPA. My reasons for asking if there was an IP on the subdomain in >>>>>>> FreeIPA were above but the missing IP on the subdomain isn't a major >>>>>>> issue for me. Things are working without dom.abc.xyz resolving to an >>>>>>> IP. What I was hoping for is to have a VIP for the IPA servers and >>>>>>> one for the Windows Server 2012 DNS Cluster in /etc/resolv.conf. (I >>>>>>> have the VIP for the windows server). One forwarding to the other for >>>>>>> a given domain. This is all for testing a) redundancy, b) forwarding, >>>>>>> a) authentication . >>>>>>> >>>>>>> IE: >>>>>>> >>>>>>> # cat /etc/resolv.conf >>>>>>> search dom.abc.xyz abc.xyz >>>>>>> nameserver 192.168.0.3 <------------ Win Cluster DNS VIP >>>>>>> nameserver 192.168.0.4 <------------ IPA Cluster DNS VIP >>>>>>> >>>>>>> * Just what I want to achieve above. VIP 192.168.0.4 doesn't exist on >>>>>>> my cluster yet. I'm looking to integrate ucarp with the above IPA >>>>>>> servers. >>>>>>> >>>>>>> >>>>>>> 2) More to the topic of my second question however, is that >>>>>>> /etc/resolv.conf, on the IPA servers themselves, get's rewritten on >>>>>>> restart. Would like to know by what if I already uninstalled >>>>>>> NetworkManager? When I configured the FreeIPA server, I used: >>>>>>> >>>>>>> ipa-server-install --setup-dns --forwarder=192.168.0.3 -p "Hush!" -a >>>>>>> "Hush!" -r DOM.ABC.XYZ -n dom.abc.xyz --hostname ipa01.dom.abc.xyz >>>>>>> >>>>>>> Notice I used the VIP of the Windows Server 2012 Cluster when >>>>>>> installing FreeIPA. This is nice for redundancy. So the resolv.conf >>>>>>> ends up being: >>>>>>> >>>>>>> # cat /etc/resolv.conf >>>>>>> # Generated by NetworkManager >>>>>>> search abc.xyz >>>>>>> nameserver 192.168.0.3 >>>>>>> nameserver 123.123.123.1 >>>>>>> nameserver 123.123.123.2 >>>>>>> >>>>>>> Then I add: >>>>>>> >>>>>>> search dom.abc.xyz abc.xyz >>>>>>> >>>>>>> but it changes back to search abc.xyz (the Windows Server 2012 DNS). >>>>>>> This all works, except for the above minor items, and I can resolve >>>>>>> anything over this network. ( Thinking this is fine because the >>>>>>> forward is on the subdomain. I haven't had issues with forwarding >>>>>>> through this setup. ) >>>>>>> >>>>>>> # cat /etc/resolv.conf >>>>>>> # Generated by NetworkManager >>>>>>> search abc.xyz >>>>>>> nameserver 192.168.0.3 >>>>>>> nameserver 123.123.123.1 >>>>>>> nameserver 123.123.123.2 >>>>>>> >>>>>>> But NetworkManager is not installed on these IPA servers. I've >>>>>>> removed it earlier: >>>>>>> >>>>>>> # rpm -aq|grep -i NetworkManager >>>>>>> # >>>>>>> >>>>>>> Is FreeIPA replacing /etc/resolv.conf with a copy it keeps elsewhere? >>>>>> >>>>>> On servers with DNS /etc/resolv.conf should point to 127.0.0.1 and ::1, >>>>>> and global or per server dns forwarders should be configured instead >>>>>> >>>>>> Have you properly stopped NetworkManager using systemctl stop and >>>>>> systemctl disable ? In case you just removed rpm files service can still >>>>>> work. >>>>>> I recommend to update network manager config, not to remove it :) >>>>>> >>>>>> As last resort way, you can set immutable bit to resolv.conf if >>>>>> something is still changing your resolv.conf file >>>>>> >>>>>>> >>>>>>> 3) After running: >>>>>>> >>>>>>> ipa-client-install --mkhomedir --enable-dns-updates >>>>>>> >>>>>>> on a new host, the hostname of the new host doesn't resolve for a few >>>>>>> minutes. How do I make this instantaneous? (Other then that, >>>>>>> autodiscovery of the IPA servers is excellent!). Before installing >>>>>>> the IPA Client, the new hosts /etc/resolv.conf file looks like this: >>>>>>> >>>>>>> # cat /etc/resolv.conf >>>>>>> search abc.xyz >>>>>>> nameserver 192.168.0.3 >>>>>>> nameserver 123.123.123.1 >>>>>>> nameserver 123.123.123.2 >>>>>>> >>>>>>> I did dig, host, nslookup earlier. Verified all except for the items >>>>>>> I'm inquiring about. >>>>>>> >>>>>> >>>>>> That weird, because ipa-client-install creates A records directly to DNS >>>>>> server using nsupdate, so it should be accessible instantly. Do you have >>>>>> any caching DNS servers? >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> No caching DNS servers. >>>>> >>>>> On the topic of NetworkManager. It's completely gone yet still the >>>>> /etc/resolv.conf file is being replaced with the text # Generated by >>>>> NetworkManager. >>>>> >>>>> # systemctl show NetworkManager.service --property=Id,Names,Description >>>>> Id=NetworkManager.service >>>>> Names=NetworkManager.service >>>>> Description=NetworkManager.service >>>>> # >>>>> >>>>> # systemctl list-units --type service --all|grep -i network >>>>> network.service loaded active exited LSB: >>>>> Bring >>>>> up/down networking >>>>> ? NetworkManager-wait-online.service not-found inactive dead >>>>> NetworkManager-wait-online.service >>>>> ? NetworkManager.service not-found inactive dead >>>>> NetworkManager.service >>>>> ntpd.service loaded active running Network >>>>> Time Service >>>>> rhel-domainname.service loaded active exited Read and >>>>> set NIS domainname from /etc/sysconfig/network >>>>> rhel-import-state.service loaded active exited Import >>>>> network configuration from initramfs >>>>> # >>>>> >>>>> >>>>> The only thing that is left of the NetworkManager service is the above. >>>>> Nothing I type from systemd removed it completely. So I've reverted to the >>>>> last resort: >>>>> >>>>> # lsattr /etc/resolv.conf >>>>> ----i----------- /etc/resolv.conf >>>>> # >>>>> >>>>> With the above, I'm trying to see what's writing to the file by using this >>>>> auditctl and found that postfix seems to be doing this: >>>>> >>>>> ---- >>>>> time->Wed Nov 23 23:14:47 2016 >>>>> type=PATH msg=audit(1479960887.978:293): item=0 name="/etc/resolv.conf" >>>>> inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 >>>>> obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>>> type=CWD msg=audit(1479960887.978:293): cwd="/" >>>>> type=SYSCALL msg=audit(1479960887.978:293): arch=c000003e syscall=2 >>>>> success=yes exit=4 a0=7ffb36b6f43a a1=80000 a2=1b6 a3=24 items=1 ppid=1 >>>>> pid=5527 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >>>>> fsgid=0 tty=(none) ses=4294967295 comm="postfix" exe="/usr/sbin/postfix" >>>>> subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" >>>>> ---- >>>>> time->Wed Nov 23 23:14:48 2016 >>>>> type=PATH msg=audit(1479960888.013:301): item=0 name="/etc/resolv.conf" >>>>> inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 >>>>> obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>>> type=CWD msg=audit(1479960888.013:301): cwd="/var/spool/postfix" >>>>> type=SYSCALL msg=audit(1479960888.013:301): arch=c000003e syscall=2 >>>>> success=yes exit=3 a0=7f32c163043a a1=80000 a2=1b6 a3=24 items=1 ppid=5545 >>>>> pid=5546 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >>>>> fsgid=0 tty=(none) ses=4294967295 comm="postconf" exe="/usr/sbin/postconf" >>>>> subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" >>>> >>>> It usually helps to run ausearch -i, it translates numberic codes to names. >>>> >>>> Assuming you are running Linux on x86_64, it would be interpreted like this: >>>> >>>> ---- >>>> type=SYSCALL msg=audit(24.11.2016 05:14:47.978:293) : arch=x86_64 >>>> syscall=open >>>> success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>>> items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root >>>> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix >>>> exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 >>>> key=/root/resolv.conf-file >>>> type=CWD msg=audit(24.11.2016 05:14:47.978:293) : cwd=/ >>>> type=PATH msg=audit(24.11.2016 05:14:47.978:293) : item=0 >>>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>> ---- >>>> type=SYSCALL msg=audit(24.11.2016 05:14:48.013:301) : arch=x86_64 >>>> syscall=open >>>> success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>>> items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root >>>> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf >>>> exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 >>>> key=/root/resolv.conf-file >>>> type=CWD msg=audit(24.11.2016 05:14:48.013:301) : cwd=/var/spool/postfix >>>> type=PATH msg=audit(24.11.2016 05:14:48.013:301) : item=0 >>>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>> >>>> >>>> In other words, /root/resolv.conf-file is open for reading. >>>> >>>> It is interesting ... What does the file contain? >>>> >>>> Petr^2 Spacek >>>> >>>> >>>>> >>>>> This in turn appears to be called by started by: >>>>> >>>>> # grep postfix access|tail -n 1 >>>>> [23/Nov/2016:23:42:04 -0500] conn=34 op=5 SRCH >>>>> base="cn=accounts,dc=dom,dc=abc,dc=xyz" scope=2 >>>>> filter="(&(uid=postfix)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))" >>>>> >>>>> >>>>> attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory >>>>> loginShell krbPrincipalName cn memberOf ipaUniqueID ipaNTSecurityIdentifier >>>>> modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning >>>>> shadowInactive shadowExpire shadowFlag krbLastPwdChange >>>>> krbPasswordExpiration >>>>> pwdattribute authorizedService accountexpires useraccountcontrol >>>>> nsAccountLock >>>>> host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey >>>>> ipaUserAuthType usercertificate;binary" >>>>> # pwd >>>>> /var/log/dirsrv/slapd-DOM-ABC-XYZ >>> >>> root/resolv.conf-file is only a identifier (key) by which auditctl marked >>> events that occurred on /etc/resolv.conf. In other words, it was just a >>> custom assigned identifier I used that read / write requests got tagged with. >>> I really should have called it 'resolv-conf-identifier' or similar to avoid >>> confusion. It's not a file. >>> >>> The commands I used to watch the file are: >>> >>> /sbin/ausearch -f /etc/resolv.conf -key=/root/resolv.conf-file >>> >>> Then to get events: >>> >>> /sbin/ausearch -f /etc/resolv.conf --key "/root/resolv.conf-file" >>> >>> Adding the -i as per your note, I get this: >>> >>> >>> [root at idmipa01 ~]# /sbin/ausearch -f /etc/resolv.conf --key >>> "/root/resolv.conf-file" -i >>> ---- >>> type=PATH msg=audit(11/23/2016 23:14:04.708:287) : item=0 >>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>> type=CWD msg=audit(11/23/2016 23:14:04.708:287) : >>> cwd=/var/log/dirsrv/slapd-NIX-MDS-XYZ >>> type=SYSCALL msg=audit(11/23/2016 23:14:04.708:287) : arch=x86_64 syscall=open >>> success=yes exit=53 a0=0x7f66d82c243a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>> items=1 ppid=1 pid=5080 auid=unset uid=dirsrv gid=dirsrv euid=dirsrv >>> suid=dirsrv fsuid=dirsrv egid=dirsrv sgid=dirsrv fsgid=dirsrv tty=(none) >>> ses=unset comm=ns-slapd exe=/usr/sbin/ns-slapd >>> subj=system_u:system_r:dirsrv_t:s0 key=/root/resolv.conf-file >>> ---- >>> type=PATH msg=audit(11/23/2016 23:14:32.182:288) : item=0 >>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>> type=CWD msg=audit(11/23/2016 23:14:32.182:288) : cwd=/var/log/audit >>> type=SYSCALL msg=audit(11/23/2016 23:14:32.182:288) : arch=x86_64 syscall=open >>> success=yes exit=3 a0=0x7fffd2fa47ff a1=O_RDONLY|O_NONBLOCK a2=0x7fffd2fa2f00 >>> a3=0x7fffd2fa2c70 items=1 ppid=2389 pid=5511 auid=root uid=root gid=root >>> euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 >>> comm=chattr exe=/usr/bin/chattr >>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >>> key=/root/resolv.conf-file >>> ---- >>> type=PATH msg=audit(11/23/2016 23:14:32.182:289) : item=0 >>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>> type=CWD msg=audit(11/23/2016 23:14:32.182:289) : cwd=/var/log/audit >>> type=SYSCALL msg=audit(11/23/2016 23:14:32.182:289) : arch=x86_64 syscall=open >>> success=yes exit=3 a0=0x7fffd2fa47ff a1=O_RDONLY|O_NONBLOCK a2=0x7fffd2fa2f00 >>> a3=0x7fffd2fa2d50 items=1 ppid=2389 pid=5511 auid=root uid=root gid=root >>> euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 >>> comm=chattr exe=/usr/bin/chattr >>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >>> key=/root/resolv.conf-file >>> ---- >>> type=PATH msg=audit(11/23/2016 23:14:36.847:290) : item=0 >>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>> type=CWD msg=audit(11/23/2016 23:14:36.847:290) : cwd=/var/log/audit >>> type=SYSCALL msg=audit(11/23/2016 23:14:36.847:290) : arch=x86_64 syscall=open >>> success=yes exit=3 a0=0x7fff791a17ff a1=O_RDONLY|O_NONBLOCK a2=0x7fff791a0180 >>> a3=0x7fff7919fef0 items=1 ppid=2389 pid=5512 auid=root uid=root gid=root >>> euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 >>> comm=lsattr exe=/usr/bin/lsattr >>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >>> key=/root/resolv.conf-file >>> ---- >>> type=PATH msg=audit(11/23/2016 23:14:47.978:293) : item=0 >>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>> type=CWD msg=audit(11/23/2016 23:14:47.978:293) : cwd=/ >>> type=SYSCALL msg=audit(11/23/2016 23:14:47.978:293) : arch=x86_64 syscall=open >>> success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>> items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root >>> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix >>> exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 >>> key=/root/resolv.conf-file >>> ---- >>> type=PATH msg=audit(11/23/2016 23:14:48.013:301) : item=0 >>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>> type=CWD msg=audit(11/23/2016 23:14:48.013:301) : cwd=/var/spool/postfix >>> type=SYSCALL msg=audit(11/23/2016 23:14:48.013:301) : arch=x86_64 syscall=open >>> success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>> items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root >>> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf >>> exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 >>> key=/root/resolv.conf-file >>> [root at idmipa01 ~]# >> >> Okay, the important part is that all open() syscalls have parameter O_RDONLY >> so there is nothing writing to the file. >> >> The wrong value must have get into resolv.conf by some other means. >> > > So the only way for me to find out what's modifying that file is to step > through the boot process since auditctl might not be loading yet or simply has > to be loaded manually each time to capture anything of value. > > The command I ran is: > > /sbin/auditctl -w /etc/resolv.conf -p war -k /root/resolv.conf-file > > Can't find a convenient way to capture this at boot. I know /etc/resolv.conf > changes through run level changes. Maybe this is a stupid question, but ... did you try to put the rules into /etc/audit/rules.d/audit.rules ? -- Petr^2 Spacek From tk at mdevsys.com Sat Nov 26 00:46:21 2016 From: tk at mdevsys.com (TomK) Date: Fri, 25 Nov 2016 19:46:21 -0500 Subject: [Freeipa-users] Ping forwarded domain name. In-Reply-To: References: <5eb274d5-8293-2865-80df-fc97b7dbc34d@mdevsys.com> <5dd10afd-5423-540a-9e1c-8d48dd9efcff@mdevsys.com> <5be09ff6-cd6d-f4a4-429b-20c0419b03ec@redhat.com> <97e67d02-a736-239e-0d65-5ce551454a1f@mdevsys.com> <2837abb4-3605-1946-e752-a09b289439c5@redhat.com> <731bb495-e534-8581-9da4-ae57f9f6b466@mdevsys.com> <0c386e0e-dce9-d1b1-960c-d91690fbbc9f@mdevsys.com> <16d0ec1a-f4ed-4759-3f51-d000a0515097@redhat.com> <0ddffb55-7b97-9a59-d67d-314671cc966e@mdevsys.com> Message-ID: <19a23ef0-85fd-d344-b79f-c8097f746fce@mdevsys.com> On 11/25/2016 9:09 AM, Petr Spacek wrote: > On 25.11.2016 14:48, TomK wrote: >> On 11/25/2016 4:00 AM, Petr Spacek wrote: >>> On 25.11.2016 05:57, TomK wrote: >>>> On 11/24/2016 4:49 AM, Petr Spacek wrote: >>>>> On 24.11.2016 06:08, TomK wrote: >>>>>> On 11/23/2016 3:28 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 23.11.2016 03:48, TomK wrote: >>>>>>>> On 11/22/2016 10:22 AM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 22.11.2016 13:57, TomK wrote: >>>>>>>>>> On 11/22/2016 2:59 AM, Martin Basti wrote: >>>>>>>>>>> Hey, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 22.11.2016 06:33, TomK wrote: >>>>>>>>>>>> Hey Guy's, >>>>>>>>>>>> >>>>>>>>>>>> I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 >>>>>>>>>>>> over to >>>>>>>>>>>> my dual Free IPA server. The Free IPA servers are authoritative for >>>>>>>>>>>> this subdomain. The Windows Server 2012 DNS is resolves on abc.xyz >>>>>>>>>>>> and forwards dom.abc.xyz. >>>>>>>>>>> Do you have configured proper zone delegation for subdomain >>>>>>>>>>> dom.abc.xyz? >>>>>>>>>>> Proper NS and glue records >>>>>>>>>>> http://www.zytrax.com/books/dns/ch9/delegate.html >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I cannot ping dom.abc.xyz. Everything else, including client >>>>>>>>>>>> registrations, work fine. If Free IPA is authoritative on >>>>>>>>>>>> dom.abc.xyz, should it not create DNS entries so the sub domain >>>>>>>>>>>> can be >>>>>>>>>>>> pinged as well? >>>>>>>>>>> >>>>>>>>>>> What do you mean by "ping"? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /etc/resolv.conf also get's regenerated on reboot on the IPA Servers >>>>>>>>>>>> and wanted to ask if you can point me to some materials online to >>>>>>>>>>>> determine where can I permanently adjust the search to add >>>>>>>>>>>> dom.abc.xyz >>>>>>>>>>>> to the already present abc.xyz . I wasn't able to locate what I >>>>>>>>>>>> needed in my searches. >>>>>>>>>>>> >>>>>>>>>>>> I'm using the latest v4. >>>>>>>>>>> >>>>>>>>>>> It depends on what are you using, probably you have NetworkManager >>>>>>>>>>> there >>>>>>>>>>> that is editing /etc/resolv.conf >>>>>>>>>>> >>>>>>>>>>> https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I Uninstalled NetworkManager. Still changes. >>>>>>>>>> ping dom.abc.com results in "ping: unknown host" >>>>>>>>>> >>>>>>>>>> I'll have a look at the first link, ty. >>>>>>>>>> >>>>>>>>> >>>>>>>>> ping (ICMP protocol) and DNS system are different things, do you have >>>>>>>>> hostname dom.abc.com with A record or it is a zone? >>>>>>>>> >>>>>>>>> with ping command hostname "dom.abc.com" is resolved to IP address >>>>>>>>> first, do you have A record set for dom.abc.com in zone apex or what are >>>>>>>>> you trying to achieve with ping command? >>>>>>>>> >>>>>>>>> for testing DNS try to use commands: dig, host, nslookup >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>> >>>>>>>> Apologize for the long reply but it should give some background on >>>>>>>> what it is that I'm doing. >>>>>>>> >>>>>>>> 1) dom.abc.com is a zone. There is no A record for dom.abc.com in >>>>>>>> FreeIPA (Confirmed by Petr). I get the point Petr Spacek pointed out >>>>>>>> in his comment as well. What should it really point too? ( I kind of >>>>>>>> answer this question below so please read on. ) Where I'm getting >>>>>>>> this from is that in Windows Server 2012 abc.com returns the IP of any >>>>>>>> of the participating AD / DNS servers within the cluster (The two >>>>>>>> Windows Server 2012 are a combined clustered AD + DNS servers.). >>>>>>>> Being able to resolve abc.xyz is handy. During a lookup, I can get a >>>>>>>> list of all the IP's associated with that domain which would indicate >>>>>>>> all the DNS + AD servers online under that domain or serving that domain: >>>>>>>> >>>>>>>> >>>>>>>> # nslookup abc.xyz >>>>>>>> Server: 192.168.0.3 >>>>>>>> Address: 192.168.0.3#53 >>>>>>>> >>>>>>>> Name: abc.xyz >>>>>>>> Address: 192.168.0.3 >>>>>>>> Name: abc.xyz >>>>>>>> Address: 192.168.0.1 >>>>>>>> Name: abc.xyz >>>>>>>> Address: 192.168.0.2 >>>>>>>> # >>>>>>>> >>>>>>>> Again, where this is handy is when configuring sssd.conf for example >>>>>>>> or other apps for that matter. I can just point the app to >>>>>>>> authenticate against the domain and I have my redundancy solved. >>>>>>>> Windows Server 2012 does it, but FreeIPA didn't, so I threw the >>>>>>>> question out there. >>>>>>> >>>>>>> IPA uses SRV records heavily, all IPA related services have SRV records, >>>>>>> SSSD uses SRV records of IPA, client should use SRV record to connect to >>>>>>> the right service (or URI record - will be in next IPA). SRV records >>>>>>> work for IPA locations mechanism, we cannot achieve this with pure A >>>>>>> records. >>>>>>> >>>>>>>> >>>>>>>> Delegation from this Windows DNS works as expected. Any lookup from >>>>>>>> dom.abc.xyz is forwarded too and handled by FreeIPA servers. Tested >>>>>>>> this out. No issue with this. >>>>>>>> >>>>>>>> I did see earlier that there is no A record for dom.abc.xyz in >>>>>>>> FreeIPA. My reasons for asking if there was an IP on the subdomain in >>>>>>>> FreeIPA were above but the missing IP on the subdomain isn't a major >>>>>>>> issue for me. Things are working without dom.abc.xyz resolving to an >>>>>>>> IP. What I was hoping for is to have a VIP for the IPA servers and >>>>>>>> one for the Windows Server 2012 DNS Cluster in /etc/resolv.conf. (I >>>>>>>> have the VIP for the windows server). One forwarding to the other for >>>>>>>> a given domain. This is all for testing a) redundancy, b) forwarding, >>>>>>>> a) authentication . >>>>>>>> >>>>>>>> IE: >>>>>>>> >>>>>>>> # cat /etc/resolv.conf >>>>>>>> search dom.abc.xyz abc.xyz >>>>>>>> nameserver 192.168.0.3 <------------ Win Cluster DNS VIP >>>>>>>> nameserver 192.168.0.4 <------------ IPA Cluster DNS VIP >>>>>>>> >>>>>>>> * Just what I want to achieve above. VIP 192.168.0.4 doesn't exist on >>>>>>>> my cluster yet. I'm looking to integrate ucarp with the above IPA >>>>>>>> servers. >>>>>>>> >>>>>>>> >>>>>>>> 2) More to the topic of my second question however, is that >>>>>>>> /etc/resolv.conf, on the IPA servers themselves, get's rewritten on >>>>>>>> restart. Would like to know by what if I already uninstalled >>>>>>>> NetworkManager? When I configured the FreeIPA server, I used: >>>>>>>> >>>>>>>> ipa-server-install --setup-dns --forwarder=192.168.0.3 -p "Hush!" -a >>>>>>>> "Hush!" -r DOM.ABC.XYZ -n dom.abc.xyz --hostname ipa01.dom.abc.xyz >>>>>>>> >>>>>>>> Notice I used the VIP of the Windows Server 2012 Cluster when >>>>>>>> installing FreeIPA. This is nice for redundancy. So the resolv.conf >>>>>>>> ends up being: >>>>>>>> >>>>>>>> # cat /etc/resolv.conf >>>>>>>> # Generated by NetworkManager >>>>>>>> search abc.xyz >>>>>>>> nameserver 192.168.0.3 >>>>>>>> nameserver 123.123.123.1 >>>>>>>> nameserver 123.123.123.2 >>>>>>>> >>>>>>>> Then I add: >>>>>>>> >>>>>>>> search dom.abc.xyz abc.xyz >>>>>>>> >>>>>>>> but it changes back to search abc.xyz (the Windows Server 2012 DNS). >>>>>>>> This all works, except for the above minor items, and I can resolve >>>>>>>> anything over this network. ( Thinking this is fine because the >>>>>>>> forward is on the subdomain. I haven't had issues with forwarding >>>>>>>> through this setup. ) >>>>>>>> >>>>>>>> # cat /etc/resolv.conf >>>>>>>> # Generated by NetworkManager >>>>>>>> search abc.xyz >>>>>>>> nameserver 192.168.0.3 >>>>>>>> nameserver 123.123.123.1 >>>>>>>> nameserver 123.123.123.2 >>>>>>>> >>>>>>>> But NetworkManager is not installed on these IPA servers. I've >>>>>>>> removed it earlier: >>>>>>>> >>>>>>>> # rpm -aq|grep -i NetworkManager >>>>>>>> # >>>>>>>> >>>>>>>> Is FreeIPA replacing /etc/resolv.conf with a copy it keeps elsewhere? >>>>>>> >>>>>>> On servers with DNS /etc/resolv.conf should point to 127.0.0.1 and ::1, >>>>>>> and global or per server dns forwarders should be configured instead >>>>>>> >>>>>>> Have you properly stopped NetworkManager using systemctl stop and >>>>>>> systemctl disable ? In case you just removed rpm files service can still >>>>>>> work. >>>>>>> I recommend to update network manager config, not to remove it :) >>>>>>> >>>>>>> As last resort way, you can set immutable bit to resolv.conf if >>>>>>> something is still changing your resolv.conf file >>>>>>> >>>>>>>> >>>>>>>> 3) After running: >>>>>>>> >>>>>>>> ipa-client-install --mkhomedir --enable-dns-updates >>>>>>>> >>>>>>>> on a new host, the hostname of the new host doesn't resolve for a few >>>>>>>> minutes. How do I make this instantaneous? (Other then that, >>>>>>>> autodiscovery of the IPA servers is excellent!). Before installing >>>>>>>> the IPA Client, the new hosts /etc/resolv.conf file looks like this: >>>>>>>> >>>>>>>> # cat /etc/resolv.conf >>>>>>>> search abc.xyz >>>>>>>> nameserver 192.168.0.3 >>>>>>>> nameserver 123.123.123.1 >>>>>>>> nameserver 123.123.123.2 >>>>>>>> >>>>>>>> I did dig, host, nslookup earlier. Verified all except for the items >>>>>>>> I'm inquiring about. >>>>>>>> >>>>>>> >>>>>>> That weird, because ipa-client-install creates A records directly to DNS >>>>>>> server using nsupdate, so it should be accessible instantly. Do you have >>>>>>> any caching DNS servers? >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> No caching DNS servers. >>>>>> >>>>>> On the topic of NetworkManager. It's completely gone yet still the >>>>>> /etc/resolv.conf file is being replaced with the text # Generated by >>>>>> NetworkManager. >>>>>> >>>>>> # systemctl show NetworkManager.service --property=Id,Names,Description >>>>>> Id=NetworkManager.service >>>>>> Names=NetworkManager.service >>>>>> Description=NetworkManager.service >>>>>> # >>>>>> >>>>>> # systemctl list-units --type service --all|grep -i network >>>>>> network.service loaded active exited LSB: >>>>>> Bring >>>>>> up/down networking >>>>>> ? NetworkManager-wait-online.service not-found inactive dead >>>>>> NetworkManager-wait-online.service >>>>>> ? NetworkManager.service not-found inactive dead >>>>>> NetworkManager.service >>>>>> ntpd.service loaded active running Network >>>>>> Time Service >>>>>> rhel-domainname.service loaded active exited Read and >>>>>> set NIS domainname from /etc/sysconfig/network >>>>>> rhel-import-state.service loaded active exited Import >>>>>> network configuration from initramfs >>>>>> # >>>>>> >>>>>> >>>>>> The only thing that is left of the NetworkManager service is the above. >>>>>> Nothing I type from systemd removed it completely. So I've reverted to the >>>>>> last resort: >>>>>> >>>>>> # lsattr /etc/resolv.conf >>>>>> ----i----------- /etc/resolv.conf >>>>>> # >>>>>> >>>>>> With the above, I'm trying to see what's writing to the file by using this >>>>>> auditctl and found that postfix seems to be doing this: >>>>>> >>>>>> ---- >>>>>> time->Wed Nov 23 23:14:47 2016 >>>>>> type=PATH msg=audit(1479960887.978:293): item=0 name="/etc/resolv.conf" >>>>>> inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 >>>>>> obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>>>> type=CWD msg=audit(1479960887.978:293): cwd="/" >>>>>> type=SYSCALL msg=audit(1479960887.978:293): arch=c000003e syscall=2 >>>>>> success=yes exit=4 a0=7ffb36b6f43a a1=80000 a2=1b6 a3=24 items=1 ppid=1 >>>>>> pid=5527 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >>>>>> fsgid=0 tty=(none) ses=4294967295 comm="postfix" exe="/usr/sbin/postfix" >>>>>> subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" >>>>>> ---- >>>>>> time->Wed Nov 23 23:14:48 2016 >>>>>> type=PATH msg=audit(1479960888.013:301): item=0 name="/etc/resolv.conf" >>>>>> inode=135699633 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 >>>>>> obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>>>> type=CWD msg=audit(1479960888.013:301): cwd="/var/spool/postfix" >>>>>> type=SYSCALL msg=audit(1479960888.013:301): arch=c000003e syscall=2 >>>>>> success=yes exit=3 a0=7f32c163043a a1=80000 a2=1b6 a3=24 items=1 ppid=5545 >>>>>> pid=5546 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 >>>>>> fsgid=0 tty=(none) ses=4294967295 comm="postconf" exe="/usr/sbin/postconf" >>>>>> subj=system_u:system_r:postfix_master_t:s0 key="/root/resolv.conf-file" >>>>> >>>>> It usually helps to run ausearch -i, it translates numberic codes to names. >>>>> >>>>> Assuming you are running Linux on x86_64, it would be interpreted like this: >>>>> >>>>> ---- >>>>> type=SYSCALL msg=audit(24.11.2016 05:14:47.978:293) : arch=x86_64 >>>>> syscall=open >>>>> success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>>>> items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root >>>>> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix >>>>> exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 >>>>> key=/root/resolv.conf-file >>>>> type=CWD msg=audit(24.11.2016 05:14:47.978:293) : cwd=/ >>>>> type=PATH msg=audit(24.11.2016 05:14:47.978:293) : item=0 >>>>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>>>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>>> ---- >>>>> type=SYSCALL msg=audit(24.11.2016 05:14:48.013:301) : arch=x86_64 >>>>> syscall=open >>>>> success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>>>> items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root >>>>> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf >>>>> exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 >>>>> key=/root/resolv.conf-file >>>>> type=CWD msg=audit(24.11.2016 05:14:48.013:301) : cwd=/var/spool/postfix >>>>> type=PATH msg=audit(24.11.2016 05:14:48.013:301) : item=0 >>>>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>>>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>>> >>>>> >>>>> In other words, /root/resolv.conf-file is open for reading. >>>>> >>>>> It is interesting ... What does the file contain? >>>>> >>>>> Petr^2 Spacek >>>>> >>>>> >>>>>> >>>>>> This in turn appears to be called by started by: >>>>>> >>>>>> # grep postfix access|tail -n 1 >>>>>> [23/Nov/2016:23:42:04 -0500] conn=34 op=5 SRCH >>>>>> base="cn=accounts,dc=dom,dc=abc,dc=xyz" scope=2 >>>>>> filter="(&(uid=postfix)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))" >>>>>> >>>>>> >>>>>> attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory >>>>>> loginShell krbPrincipalName cn memberOf ipaUniqueID ipaNTSecurityIdentifier >>>>>> modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning >>>>>> shadowInactive shadowExpire shadowFlag krbLastPwdChange >>>>>> krbPasswordExpiration >>>>>> pwdattribute authorizedService accountexpires useraccountcontrol >>>>>> nsAccountLock >>>>>> host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey >>>>>> ipaUserAuthType usercertificate;binary" >>>>>> # pwd >>>>>> /var/log/dirsrv/slapd-DOM-ABC-XYZ >>>> >>>> root/resolv.conf-file is only a identifier (key) by which auditctl marked >>>> events that occurred on /etc/resolv.conf. In other words, it was just a >>>> custom assigned identifier I used that read / write requests got tagged with. >>>> I really should have called it 'resolv-conf-identifier' or similar to avoid >>>> confusion. It's not a file. >>>> >>>> The commands I used to watch the file are: >>>> >>>> /sbin/ausearch -f /etc/resolv.conf -key=/root/resolv.conf-file >>>> >>>> Then to get events: >>>> >>>> /sbin/ausearch -f /etc/resolv.conf --key "/root/resolv.conf-file" >>>> >>>> Adding the -i as per your note, I get this: >>>> >>>> >>>> [root at idmipa01 ~]# /sbin/ausearch -f /etc/resolv.conf --key >>>> "/root/resolv.conf-file" -i >>>> ---- >>>> type=PATH msg=audit(11/23/2016 23:14:04.708:287) : item=0 >>>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>> type=CWD msg=audit(11/23/2016 23:14:04.708:287) : >>>> cwd=/var/log/dirsrv/slapd-NIX-MDS-XYZ >>>> type=SYSCALL msg=audit(11/23/2016 23:14:04.708:287) : arch=x86_64 syscall=open >>>> success=yes exit=53 a0=0x7f66d82c243a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>>> items=1 ppid=1 pid=5080 auid=unset uid=dirsrv gid=dirsrv euid=dirsrv >>>> suid=dirsrv fsuid=dirsrv egid=dirsrv sgid=dirsrv fsgid=dirsrv tty=(none) >>>> ses=unset comm=ns-slapd exe=/usr/sbin/ns-slapd >>>> subj=system_u:system_r:dirsrv_t:s0 key=/root/resolv.conf-file >>>> ---- >>>> type=PATH msg=audit(11/23/2016 23:14:32.182:288) : item=0 >>>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>> type=CWD msg=audit(11/23/2016 23:14:32.182:288) : cwd=/var/log/audit >>>> type=SYSCALL msg=audit(11/23/2016 23:14:32.182:288) : arch=x86_64 syscall=open >>>> success=yes exit=3 a0=0x7fffd2fa47ff a1=O_RDONLY|O_NONBLOCK a2=0x7fffd2fa2f00 >>>> a3=0x7fffd2fa2c70 items=1 ppid=2389 pid=5511 auid=root uid=root gid=root >>>> euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 >>>> comm=chattr exe=/usr/bin/chattr >>>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >>>> key=/root/resolv.conf-file >>>> ---- >>>> type=PATH msg=audit(11/23/2016 23:14:32.182:289) : item=0 >>>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>> type=CWD msg=audit(11/23/2016 23:14:32.182:289) : cwd=/var/log/audit >>>> type=SYSCALL msg=audit(11/23/2016 23:14:32.182:289) : arch=x86_64 syscall=open >>>> success=yes exit=3 a0=0x7fffd2fa47ff a1=O_RDONLY|O_NONBLOCK a2=0x7fffd2fa2f00 >>>> a3=0x7fffd2fa2d50 items=1 ppid=2389 pid=5511 auid=root uid=root gid=root >>>> euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 >>>> comm=chattr exe=/usr/bin/chattr >>>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >>>> key=/root/resolv.conf-file >>>> ---- >>>> type=PATH msg=audit(11/23/2016 23:14:36.847:290) : item=0 >>>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>> type=CWD msg=audit(11/23/2016 23:14:36.847:290) : cwd=/var/log/audit >>>> type=SYSCALL msg=audit(11/23/2016 23:14:36.847:290) : arch=x86_64 syscall=open >>>> success=yes exit=3 a0=0x7fff791a17ff a1=O_RDONLY|O_NONBLOCK a2=0x7fff791a0180 >>>> a3=0x7fff7919fef0 items=1 ppid=2389 pid=5512 auid=root uid=root gid=root >>>> euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=1 >>>> comm=lsattr exe=/usr/bin/lsattr >>>> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 >>>> key=/root/resolv.conf-file >>>> ---- >>>> type=PATH msg=audit(11/23/2016 23:14:47.978:293) : item=0 >>>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>> type=CWD msg=audit(11/23/2016 23:14:47.978:293) : cwd=/ >>>> type=SYSCALL msg=audit(11/23/2016 23:14:47.978:293) : arch=x86_64 syscall=open >>>> success=yes exit=4 a0=0x7ffb36b6f43a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>>> items=1 ppid=1 pid=5527 auid=unset uid=root gid=root euid=root suid=root >>>> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postfix >>>> exe=/usr/sbin/postfix subj=system_u:system_r:postfix_master_t:s0 >>>> key=/root/resolv.conf-file >>>> ---- >>>> type=PATH msg=audit(11/23/2016 23:14:48.013:301) : item=0 >>>> name=/etc/resolv.conf inode=135699633 dev=fd:00 mode=file,644 ouid=root >>>> ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL >>>> type=CWD msg=audit(11/23/2016 23:14:48.013:301) : cwd=/var/spool/postfix >>>> type=SYSCALL msg=audit(11/23/2016 23:14:48.013:301) : arch=x86_64 syscall=open >>>> success=yes exit=3 a0=0x7f32c163043a a1=O_RDONLY|O_CLOEXEC a2=0x1b6 a3=0x24 >>>> items=1 ppid=5545 pid=5546 auid=unset uid=root gid=root euid=root suid=root >>>> fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=postconf >>>> exe=/usr/sbin/postconf subj=system_u:system_r:postfix_master_t:s0 >>>> key=/root/resolv.conf-file >>>> [root at idmipa01 ~]# >>> >>> Okay, the important part is that all open() syscalls have parameter O_RDONLY >>> so there is nothing writing to the file. >>> >>> The wrong value must have get into resolv.conf by some other means. >>> >> >> So the only way for me to find out what's modifying that file is to step >> through the boot process since auditctl might not be loading yet or simply has >> to be loaded manually each time to capture anything of value. >> >> The command I ran is: >> >> /sbin/auditctl -w /etc/resolv.conf -p war -k /root/resolv.conf-file >> >> Can't find a convenient way to capture this at boot. I know /etc/resolv.conf >> changes through run level changes. > > Maybe this is a stupid question, but ... did you try to put the rules into > /etc/audit/rules.d/audit.rules ? > Yep I did: # cat /etc/audit/audit.rules ## This file is automatically generated from /etc/audit/rules.d -D -b 320 -w /etc/resolv.conf -p wxr -k etc-resolv-conf-key and could check now. Indeed it was the network scripts. /etc/sysconfig/network-scripts/ifup-post type=PATH msg=audit(11/25/2016 18:53:09.762:37) : item=1 name=/etc/resolv.conf inode=135699635 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:net_conf_t:s0 objtype=NORMAL type=PATH msg=audit(11/25/2016 18:53:09.762:37) : item=0 name=/etc/ inode=134299841 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=PARENT type=CWD msg=audit(11/25/2016 18:53:09.762:37) : cwd=/etc/sysconfig/network-scripts type=SYSCALL msg=audit(11/25/2016 18:53:09.762:37) : arch=x86_64 syscall=open success=yes exit=3 a0=0x208c990 a1=O_WRONLY|O_CREAT|O_TRUNC a2=0666 a3=0xfffffff0 items=2 ppid=770 pid=854 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=ifup-post exe=/usr/bin/bash subj=system_u:system_r:initrc_t:s0 key=etc-resolv-conf-key So I've changed to the following: # grep DNS ifcfg-eth0 PEERDNS=yes DNS1=192.168.0.3 # vi ifcfg-eth0 # grep DNS ifcfg-eth0 PEERDNS=yes DNS1=127.0.0.1 # After I made the change to ifcfg-eth0 above and restarted the network, all good and it set the entry from 192.168.0.3 to 127.0.0.1: # cat /etc/resolv.conf search com.abc.xyz abc.xyz nameserver 127.0.0.1 # Quite a few of those scripts change the /etc/resolv.conf: # grep -i resolv * ifdown-post:if [ "$PEERDNS" != "no" -o -n "$RESOLV_MODS" -a "$RESOLV_MODS" != "no" ]; then ifdown-post: if [ -f /etc/resolv.conf.save ]; then ifdown-post: change_resolv_conf /etc/resolv.conf.save ifdown-post: rm -f /etc/resolv.conf.save ifup-post:if [ "$PEERDNS" != "no" ] ||[ -n "$RESOLV_MODS" -a "$RESOLV_MODS" != "no" ]; then ifup-post: if [ -n "$DNS1" ] && ! grep -q "^nameserver $DNS1" /etc/resolv.conf && ifup-post: (cat /etc/resolv.conf ; echo EOF ; echo EOF) | while read answer ; do ifup-post: # backup resolv.conf ifup-post: cp -af /etc/resolv.conf /etc/resolv.conf.save ifup-post: change_resolv_conf $tr ifup-ppp: cp -f /etc/resolv.conf /etc/resolv.conf.save network-functions: if ! grep search /etc/resolv.conf >/dev/null 2>&1; then network-functions: cat /etc/resolv.conf > $rsctmp network-functions: change_resolv_conf $rsctmp network-functions:# Invoke this when /etc/resolv.conf has changed: network-functions:change_resolv_conf () network-functions: s=$(/bin/grep '^[\ \ ]*option' /etc/resolv.conf 2>/dev/null); network-functions: (echo "$s" > /etc/resolv.conf;) >/dev/null 2>&1; network-functions: [ -x /sbin/restorecon ] && /sbin/restorecon /etc/resolv.conf >/dev/null 2>&1 # reset the correct context network-functions: /usr/bin/logger -p local7.notice -t "NET" -i "$0 : updated /etc/resolv.conf"; network-functions-ipv6:## Resolve need of explicit next hop for an interface -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From lslebodn at redhat.com Sat Nov 26 12:47:25 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 26 Nov 2016 13:47:25 +0100 Subject: [Freeipa-users] Shadow Utils appears in sssd.conf In-Reply-To: References: <20161116083905.GA16665@10.4.128.1> Message-ID: <20161126124724.GA17852@10.4.128.1> On (22/11/16 10:16), Lachlan Musicman wrote: >Great - thank you. That worked. > I am not sure what is working now. Did the domain "domain/shadowutils" cause any problems to you? LS From deepak.dimri2016 at gmail.com Sat Nov 26 17:48:59 2016 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Sat, 26 Nov 2016 23:18:59 +0530 Subject: [Freeipa-users] FreeIPA behind Apache Reverse Proxy and Load Balancer Message-ID: Hi All, I want to configure Apache reverse proxy to load balance/failover between two IPA servers. I have referred *https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name * to configure reverse proxy and it all works fine with one IPA server but i want to load balance across two IPA Servers using Proxy Balancer module. What should be the configuration for RequestHeader edit Referer with Proxy balancer? In another thread* https://www.mail-archive.com/freeipa-users at redhat.com/msg24644.html *Peter has mentioned cookie rewriting or 2 VHs and i will try VH option. But it will really help and will save my time if some one can share full working configuration. I tried below configuration but its failing at RequestHeader edit Referer. # IPA Server 1 BalancerMember https://ipa1.int.com/ # IPA Server 2 BalancerMember https://ipa2.int.com/ SSLEngine On SSLProxyEngine On LogLevel debug SSLCertificateFile /etc/apache2/ssl/apache.crt SSLCertificateKeyFile /etc/apache2/ssl/apache.key ProxyRequests off ProxyPass / balancer://ipacluster/ ProxyPassReverse / balancer://ipacluster/ ProxyPassReverseCookieDomain ipa1.int.com ipa.ext.com RequestHeader edit Referer ^https://ipa\.ext\.com/ https://ipa1.int.com/ ProxyPassReverseCookieDomain ipa2.int.com ipa.ext.com RequestHeader edit Referer ^https://ipa\.ext\.com/ https://ipa2.int.com/ Many Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.dimri2016 at gmail.com Sun Nov 27 07:36:36 2016 From: deepak.dimri2016 at gmail.com (deepak dimri) Date: Sun, 27 Nov 2016 13:06:36 +0530 Subject: [Freeipa-users] IPA rewrite conf Message-ID: Hi All, I am posting my issue here with an hope that i get a response. I have WS ELB configured to connect to FreeIPA servers on Ubuntu. My FreeIPA servers are in private subnets. I am able to access my test index.html page deployed on the FreeIPA server by hitting https:///index.html. However when i try IPA UI https:///ipa/ui then i am getting redirected to my internal IPA address which then resulting to "site cannot be reached" error. I am wondering if i have an option of tweaking my /usr/share/ipa/ipa-rewrite.conf file so that i can access IPA UI using external ELB URL? Would appreciate if some one can give some pointers Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak_dimri at hotmail.com Sun Nov 27 09:03:22 2016 From: deepak_dimri at hotmail.com (Deepak Dimri) Date: Sun, 27 Nov 2016 09:03:22 +0000 Subject: [Freeipa-users] IPA rewrite conf with AWS ELB Message-ID: Hi All, I am posting my issue here with an hope that i get a response. I have AWS ELB configured to connect to FreeIPA servers on Ubuntu. My FreeIPA servers are in private subnets. I am able to access my test index.html page deployed on the FreeIPA server by hitting https:///index.html. However when i try IPA UI https:///ipa/ui then i am getting redirected to my internal IPA address which then resulting to "site cannot be reached" error. I am wondering if i have an option of tweaking my /etc/httpd/conf.d/ipa-rewrite.conf file so that i can access IPA UI using external ELB URL? I see ipa-rewrite.conf is hardcoded with my internal IPA server URLs. Would appreciate if some one can give some pointers Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Sun Nov 27 17:31:39 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Sun, 27 Nov 2016 12:31:39 -0500 Subject: [Freeipa-users] mount lookup failure getautomntent_r Message-ID: Hello, I have noticed an error that pop up as the final line after running this command " automount -m". I suspect its related to selinux, but haven't seen how to fix it from the google search this morning. I have autofs maps on IPA and using SSSD to read the maps. Mount point: /- source(s): lookup_read_map: lookup(sss): getautomntent_r: No such file or directory failed to read map Have anyone found a way to clean up that error? Regards, William From jhrozek at redhat.com Sun Nov 27 20:43:03 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 27 Nov 2016 21:43:03 +0100 Subject: [Freeipa-users] mount lookup failure getautomntent_r In-Reply-To: References: Message-ID: <1D831CA6-807C-4C40-A1F0-9470B17E003E@redhat.com> > On 27 Nov 2016, at 18:31, William Muriithi wrote: > > Hello, > > I have noticed an error that pop up as the final line after running > this command " > automount -m". I suspect its related to selinux, but haven't seen how > to fix it from the google search this morning. > > I have autofs maps on IPA and using SSSD to read the maps. > > > Mount point: /- > > > source(s): > > lookup_read_map: lookup(sss): getautomntent_r: No such file or directory > > failed to read map > > Have anyone found a way to clean up that error? > No idea without more context, sorry. Does auto mounter actually work for you or are some maps missing? The message can really be harmless, because the client (=automounter) iterates over the maps returned by the server (=sssd in this context) until the server returns ENOENT. I agree though the message is confusing and we?ll be (most probably) looking at some autofs enhancements in the next sssd version.. > 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 From jochen at jochen.org Sun Nov 27 21:45:35 2016 From: jochen at jochen.org (Jochen Hein) Date: Sun, 27 Nov 2016 22:45:35 +0100 Subject: [Freeipa-users] Add 4.4 replica to 4.3 server fails Message-ID: <83h96s4mww.fsf@echidna.jochen.org> I'm running a single IPA master 4.3 on an up-to-date Fedora 24. That server has been updated from earlier Fedoras and runs DNS and CA. I've updated domainlevel to 1 manually. Installed packages in IPA master: [root at freeipa ~]# rpm -qa | grep freeipa freeipa-admintools-4.3.2-2.fc24.noarch freeipa-server-common-4.3.2-2.fc24.noarch freeipa-server-4.3.2-2.fc24.x86_64 freeipa-client-common-4.3.2-2.fc24.noarch freeipa-server-trust-ad-4.3.2-2.fc24.x86_64 freeipa-client-4.3.2-2.fc24.x86_64 freeipa-common-4.3.2-2.fc24.noarch freeipa-python-compat-4.3.2-2.fc24.noarch Now I'd like to switch to a CentOS install, so I installed CentOS 7.2 on a new VM and updated to the CR repo, so I'll get IPA 4.4. Installed packages in new VM: [root at freeipa1 ~]# rpm -qa | grep ipa python2-ipaserver-4.4.0-12.el7.centos.noarch python2-ipalib-4.4.0-12.el7.centos.noarch ipa-server-4.4.0-12.el7.centos.x86_64 python-iniparse-0.4-9.el7.noarch ipa-server-dns-4.4.0-12.el7.centos.noarch ipa-client-common-4.4.0-12.el7.centos.noarch libipa_hbac-1.14.0-43.el7.x86_64 ipa-common-4.4.0-12.el7.centos.noarch ipa-admintools-4.4.0-12.el7.centos.noarch sssd-ipa-1.14.0-43.el7.x86_64 ipa-client-4.4.0-12.el7.centos.x86_64 ipa-python-compat-4.4.0-12.el7.centos.noarch python-libipa_hbac-1.14.0-43.el7.x86_64 python2-ipaclient-4.4.0-12.el7.centos.noarch python-ipaddress-1.0.16-2.el7.noarch ipa-server-common-4.4.0-12.el7.centos.noarch When installing a replica with "ipa-replica-install --setup-ca" I get: [root at freeipa1 ~]# ipa-replica-install --setup-ca Run connection check to master Connection check OK 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/44]: creating directory server user [2/44]: creating directory server instance [3/44]: updating configuration in dse.ldif [4/44]: restarting directory server [5/44]: adding default schema [6/44]: enabling memberof plugin [7/44]: enabling winsync plugin [8/44]: configuring replication version plugin [9/44]: enabling IPA enrollment plugin [10/44]: enabling ldapi [11/44]: configuring uniqueness plugin [12/44]: configuring uuid plugin [13/44]: configuring modrdn plugin [14/44]: configuring DNS plugin [15/44]: enabling entryUSN plugin [16/44]: configuring lockout plugin [17/44]: configuring topology plugin [18/44]: creating indices [19/44]: enabling referential integrity plugin [20/44]: configuring certmap.conf [21/44]: configure autobind for root [22/44]: configure new location for managed entries [23/44]: configure dirsrv ccache [24/44]: enabling SASL mapping fallback [25/44]: restarting directory server [26/44]: creating DS keytab [27/44]: retrieving DS Certificate [28/44]: restarting directory server [29/44]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 8 seconds elapsed Update succeeded [30/44]: adding sasl mappings to the directory [31/44]: updating schema [32/44]: setting Auto Member configuration [33/44]: enabling S4U2Proxy delegation [34/44]: importing CA certificates from LDAP [35/44]: initializing group membership [36/44]: adding master entry [37/44]: initializing domain level [38/44]: configuring Posix uid/gid generation [39/44]: adding replication acis [40/44]: enabling compatibility plugin [41/44]: activating sidgen plugin [42/44]: activating extdom plugin [43/44]: tuning directory server [44/44]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring ipa-custodia [1/5]: Generating ipa-custodia config file [2/5]: Generating ipa-custodia keys [3/5]: Importing RA Key /usr/lib/python2.7/site-packages/urllib3/connection.py:251: SecurityWarning: Certificate has no `subjectAltName`, falling back to check for a `commonName` for now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SecurityWarning [error] HTTPError: 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Multibackend cannot be initialized with no backends. If you are seeing this error when trying to use default_backend() please try uninstalling and reinstalling cryptography.',)]"] Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Multibackend cannot be initialized with no backends. If you are seeing this error when trying to use default_backend() please try uninstalling and reinstalling cryptography.',)]"] ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information In ipareplica-install.log we have: [...] 2016-11-27T21:07:25Z DEBUG Configuring ipa-custodia 2016-11-27T21:07:25Z DEBUG [1/5]: Generating ipa-custodia config file 2016-11-27T21:07:25Z DEBUG duration: 0 seconds 2016-11-27T21:07:25Z DEBUG [2/5]: Generating ipa-custodia keys 2016-11-27T21:07:26Z DEBUG duration: 1 seconds 2016-11-27T21:07:26Z DEBUG [3/5]: Importing RA Key 2016-11-27T21:07:26Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 448, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 438, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line 112, in __import_ra_key cli.fetch_key('ra/ipaCert') File "/usr/lib/python2.7/site-packages/ipapython/secrets/client.py", line 98, in fetch_key r.raise_for_status() File "/usr/lib/python2.7/site-packages/requests/models.py", line 834, in raise_for_status raise HTTPError(http_error_msg, response=self) HTTPError: 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Multibackend cannot be initialized with no backends. If you are seeing this error when trying to use default_backend() please try uninstalling and reinstalling cryptography.',)]"] 2016-11-27T21:07:26Z DEBUG [error] HTTPError: 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Multibackend cannot be initialized with no backends. If you are seeing this error when trying to use default_backend() please try uninstalling and reinstalling cryptography.',)]"] 2016-11-27T21:07:26Z 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 310, in run self.execute() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 332, in execute for nothing in self._executor(): 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 586, in _configure next(executor) 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 1714, in main promote(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 1470, in promote custodia.create_replica(config.master_host_name) File "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line 95, in create_replica realm=self.realm) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 580, in create_instance self.start_creation("Configuring %s" % self.service_name) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 448, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 438, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/custodiainstance.py", line 112, in __import_ra_key cli.fetch_key('ra/ipaCert') File "/usr/lib/python2.7/site-packages/ipapython/secrets/client.py", line 98, in fetch_key r.raise_for_status() File "/usr/lib/python2.7/site-packages/requests/models.py", line 834, in raise_for_status raise HTTPError(http_error_msg, response=self) 2016-11-27T21:07:26Z DEBUG The ipa-replica-install command failed, exception: HTTPError: 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Multibackend cannot be initialized with no backends. If you are seeing this error when trying to use default_backend() please try uninstalling and reinstalling cryptography.',)]"] 2016-11-27T21:07:26Z ERROR 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Multibackend cannot be initialized with no backends. If you are seeing this error when trying to use default_backend() please try uninstalling and reinstalling cryptography.',)]"] 2016-11-27T21:07:26Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information Any idea what's wrong? Jochen -- The only problem with troubleshooting is that the trouble shoots back. From william.muriithi at gmail.com Sun Nov 27 22:34:20 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Sun, 27 Nov 2016 17:34:20 -0500 Subject: [Freeipa-users] mount lookup failure getautomntent_r In-Reply-To: <1D831CA6-807C-4C40-A1F0-9470B17E003E@redhat.com> References: <1D831CA6-807C-4C40-A1F0-9470B17E003E@redhat.com> Message-ID: Jakub, Thanks for response On 27 November 2016 at 15:43, Jakub Hrozek wrote: > >> >> I have noticed an error that pop up as the final line after running >> lookup_read_map: lookup(sss): getautomntent_r: No such file or directory >> >> failed to read map >> >> Have anyone found a way to clean up that error? >> > > No idea without more context, sorry. Does auto mounter actually work for you or are some maps missing? > The mount work fine actually. I only noticed the error because I have a script that is consuming the standard output from "automount -m" command. I thought instead of filtering away the error, it would be more prudent to fix the root issue. > The message can really be harmless, because the client (=automounter) iterates over the maps returned by the server (=sssd in this context) until the server returns ENOENT. I agree though the message is confusing and we?ll be (most probably) looking at some autofs enhancements in the next sssd version.. > Now that I have shared some context, is there any way I can track down whats might be causing it? Or better, whats are some of the candidate mistakes that can trigger it. Regards, William From jochen at jochen.org Sun Nov 27 22:38:50 2016 From: jochen at jochen.org (Jochen Hein) Date: Sun, 27 Nov 2016 23:38:50 +0100 Subject: [Freeipa-users] Add 4.4 replica to 4.3 server fails In-Reply-To: <83h96s4mww.fsf@echidna.jochen.org> (Jochen Hein's message of "Sun, 27 Nov 2016 22:45:35 +0100") References: <83h96s4mww.fsf@echidna.jochen.org> Message-ID: <83d1hg4kg5.fsf@echidna.jochen.org> Jochen Hein writes: > 2016-11-27T21:07:26Z DEBUG The ipa-replica-install command failed, exception: HTTPError: 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Multibackend cannot be initialized with no backends. If you are seeing this error when trying to use default_backend() please try uninstalling and reinstalling cryptography.',)]"] > 2016-11-27T21:07:26Z ERROR 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Multibackend cannot be initialized with no backends. If you are seeing this error when trying to use default_backend() please try uninstalling and reinstalling cryptography.',)]"] > 2016-11-27T21:07:26Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information > > Any idea what's wrong? Around that time the pki on the old master has this: 0.Thread-17 - [27/Nov/2016:22:06:47 MEZ] [8] [3] Publishing: Could not publish certificate serial number 0x1a. Error Failed to publish using rule: No rules enabled Debug has: [27/Nov/2016:22:06:47][Thread-17]: RunListeners:: Queue: 1 noSingleRequest [27/Nov/2016:22:06:47][Thread-17]: getRequest mRequests=1 mSearchForRequests=false [27/Nov/2016:22:06:47][Thread-17]: getRequest getting request: 29 [27/Nov/2016:22:06:47][Thread-17]: In LdapBoundConnFactory::getConn() [27/Nov/2016:22:06:47][Thread-17]: masterConn is connected: true [27/Nov/2016:22:06:47][Thread-17]: getConn: conn is connected true [27/Nov/2016:22:06:47][Thread-17]: getConn: mNumConns now 4 [27/Nov/2016:22:06:47][Thread-17]: returnConn: mNumConns now 5 [27/Nov/2016:22:06:47][Thread-17]: getRequest request 29 found [27/Nov/2016:22:06:47][Thread-17]: getRequest mRequests=0 mSearchForRequests=false done [27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = com.netscape.cms.listeners.CertificateIssuedListener [27/Nov/2016:22:06:47][Thread-17]: CertificateIssuedListener: accept 29 [27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = com.netscape.ca.CRLIssuingPoint$RevocationRequestListener [27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = com.netscape.cmscore.ldap.LdapRequestListener [27/Nov/2016:22:06:47][Thread-17]: LdapRequestListener handling publishing for enrollment request id 29 [27/Nov/2016:22:06:47][Thread-17]: Checking publishing for request 29 [27/Nov/2016:22:06:47][Thread-17]: In PublisherProcessor::publishCert [27/Nov/2016:22:06:47][Thread-17]: Publishing: can't find publishing rule,exiting routine. [27/Nov/2016:22:06:47][Thread-17]: PublishProcessor::publishCert : Failed to publish using rule: No rules enabled [27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = com.netscape.cms.listeners.CertificateRevokedListener [27/Nov/2016:22:06:47][Thread-17]: RunListeners: mRequest = 29 [27/Nov/2016:22:06:47][Thread-17]: updatePublishingStatus mSavePublishingCounter: 3 mSavePublishingStatus: 200 [27/Nov/2016:22:06:47][Thread-17]: RunListeners: noQueue SingleRequest [27/Nov/2016:22:06:47][Thread-17]: RequestRepository: setPublishingStatus mBaseDN: ou=ca,ou=requests,o=ipaca status: -1 [27/Nov/2016:22:06:47][Thread-17]: In LdapBoundConnFactory::getConn() [27/Nov/2016:22:06:47][Thread-17]: masterConn is connected: true [27/Nov/2016:22:06:47][Thread-17]: getConn: conn is connected true [27/Nov/2016:22:06:47][Thread-17]: getConn: mNumConns now 4 [27/Nov/2016:22:06:47][Thread-17]: returnConn: mNumConns now 5 [27/Nov/2016:22:06:47][Thread-17]: Number of publishing threads: 0 Maybe something in dogtag is missing? Jochen -- The only problem with troubleshooting is that the trouble shoots back. From deepak_dimri at hotmail.com Mon Nov 28 01:15:17 2016 From: deepak_dimri at hotmail.com (Deepak Dimri) Date: Mon, 28 Nov 2016 01:15:17 +0000 Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: References: , <20161114122601.GJ560@redhat.com> , <582A0A74.2030706@sonsorol.org>, , Message-ID: Adding Jan into the email thread. Hopefully Jan can help too Best Regards, Deepak ________________________________ From: Deepak Dimri Sent: Sunday, November 27, 2016 8:08 PM To: Chris Dagdigian Subject: Re: [Freeipa-users] URL is changing on the browser Hello Chris, Were you able to get around AWS ELB integration with IPA Server? I am stuck with this - when i hit my ELB URL i am getting redirected to internal FQDN of the IP server ( hosted on private subnet). I tried tweaking ipa-rewrite.conf but in vain. As an alternate i have installed Apache reverse proxy on the public subnet and then proxying the requests to IPA. But then it does not work if i add one more IPA server for load balancing/failover - i think its failing at "RequestHeader edit Referer" directive work. Just thought of checking with you if found any solution to this issue Many Thanks for your time, Deepak ________________________________ > On 15-Nov-2016, at 00:33, Chris Dagdigian wrote: > > > I'm still interested in this topic as our IPA servers are on private AWS subnets and it would be really nice to have an internal AWS ALB or ELB be the user-facing interface so we can route traffic between IPA systems and only "advertise" a single hostname for access. Plus it would be great to put the load balancer name into the various sssd.conf and krb5.conf client files since our internal DNS-based service discovery has some brittleness that is outside my control to fix. > > I played with this for a short time and hit the "IPA redirects to it's internal FQDN" problem as well. Now that this appears to be a somewhat simple tweak to the httpd.conf type files I may start playing around with putting private IPA systems behind a private AWS load balancer > > Chris > > > > Deepak Dimri wrote: >> we discussed the options internally and finally decided to host ipa within the private subnets - our security team wast too comfortable to expose ipa servers on to the public network. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.mueller2 at rto.de Mon Nov 28 07:10:38 2016 From: d.mueller2 at rto.de (=?utf-8?B?RGVuaXMgTcO8bGxlcg==?=) Date: Mon, 28 Nov 2016 07:10:38 +0000 Subject: [Freeipa-users] SPAM, please ban this user In-Reply-To: References: , <20161114122601.GJ560@redhat.com> , <582A0A74.2030706@sonsorol.org> , , Message-ID: <1480317038.2892.1.camel@rto.de> kimirachel1031 at tmtis.com spamming all the time. Please help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Nov 28 07:57:28 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 28 Nov 2016 08:57:28 +0100 Subject: [Freeipa-users] mount lookup failure getautomntent_r In-Reply-To: References: <1D831CA6-807C-4C40-A1F0-9470B17E003E@redhat.com> Message-ID: <20161128075728.yiipx5h3tdcpnquw@hendrix> On Sun, Nov 27, 2016 at 05:34:20PM -0500, William Muriithi wrote: > Jakub, > > Thanks for response > On 27 November 2016 at 15:43, Jakub Hrozek wrote: > > > >> > >> I have noticed an error that pop up as the final line after running > > >> lookup_read_map: lookup(sss): getautomntent_r: No such file or directory > >> > >> failed to read map > >> > >> Have anyone found a way to clean up that error? > >> > > > > No idea without more context, sorry. Does auto mounter actually work for you or are some maps missing? > > > The mount work fine actually. I only noticed the error because I have > a script that is consuming the standard output from "automount -m" > command. I thought instead of filtering away the error, it would be > more prudent to fix the root issue. Yes.. > > > The message can really be harmless, because the client (=automounter) iterates over the maps returned by the server (=sssd in this context) until the server returns ENOENT. I agree though the message is confusing and we?ll be (most probably) looking at some autofs enhancements in the next sssd version.. > > > Now that I have shared some context, is there any way I can track down > whats might be causing it? Or better, whats are some of the candidate > mistakes that can trigger it. As long as all the maps are returned, though, this is really only a confusing error message. I think the code that causes it is in SSSD's automounter client code, around line 172 with the current master: 172 if (len == 0) { 173 /* There are no more records. */ 174 *_key = NULL; 175 *_value = NULL; 176 ret = ENOENT; 177 goto done; 178 } what you see in the output is just strerror(ENOENT).. From jpazdziora at redhat.com Mon Nov 28 07:59:15 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 28 Nov 2016 08:59:15 +0100 Subject: [Freeipa-users] URL is changing on the browser In-Reply-To: References: <20161114122601.GJ560@redhat.com> <582A0A74.2030706@sonsorol.org> Message-ID: <20161128075915.GA7355@redhat.com> On Mon, Nov 28, 2016 at 01:15:17AM +0000, Deepak Dimri wrote: > Adding Jan into the email thread. Hopefully Jan can help too I'm sorry but there seem to be different people chiming into this thread with their use-cases and we really need to be talking ont setup at a time. What is the setup that you have, what is the configuration, what is the expected behaviour, and what is the behaviour that you see? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From jpazdziora at redhat.com Mon Nov 28 08:04:04 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 28 Nov 2016 09:04:04 +0100 Subject: [Freeipa-users] IPA rewrite conf In-Reply-To: References: Message-ID: <20161128080404.GT29414@redhat.com> On Sun, Nov 27, 2016 at 01:06:36PM +0530, deepak dimri wrote: > Hi All, > > I am posting my issue here with an hope that i get a response. > > I have WS ELB configured to connect to FreeIPA servers on Ubuntu. My > FreeIPA servers are in private subnets. I am able to access my test > index.html page deployed on the FreeIPA server by hitting https:// url>/index.html. However when i try IPA UI https:///ipa/ui then i > am getting redirected to my internal IPA address which then resulting to > "site cannot be reached" error. I am wondering if i have an option of > tweaking my /usr/share/ipa/ipa-rewrite.conf file so that i can access IPA > UI using external ELB URL? > > Would appreciate if some one can give some pointers I don't know what WS ELB is but maybe https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name can get you started? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From mbasti at redhat.com Mon Nov 28 08:04:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 28 Nov 2016 09:04:03 +0100 Subject: [Freeipa-users] SPAM, please ban this user In-Reply-To: <1480317038.2892.1.camel@rto.de> References: <20161114122601.GJ560@redhat.com> <582A0A74.2030706@sonsorol.org> <1480317038.2892.1.camel@rto.de> Message-ID: On 28.11.2016 08:10, Denis M?ller wrote: > kimirachel1031 at tmtis.com > > spamming all the time. > Please help. > > It is not registered user, it is spambot that is mining public archives, it is not sent from RH servers, we can't help here, sorry. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Mon Nov 28 08:07:45 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Mon, 28 Nov 2016 09:07:45 +0100 Subject: [Freeipa-users] Add 4.4 replica to 4.3 server fails In-Reply-To: <83d1hg4kg5.fsf@echidna.jochen.org> References: <83h96s4mww.fsf@echidna.jochen.org> <83d1hg4kg5.fsf@echidna.jochen.org> Message-ID: <490106a0-a804-0563-8c99-1bd963c80098@redhat.com> On 11/27/2016 11:38 PM, Jochen Hein wrote: > Jochen Hein writes: > >> 2016-11-27T21:07:26Z DEBUG The ipa-replica-install command failed, exception: HTTPError: 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Multibackend cannot be initialized with no backends. If you are seeing this error when trying to use default_backend() please try uninstalling and reinstalling cryptography.',)]"] >> 2016-11-27T21:07:26Z ERROR 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Multibackend cannot be initialized with no backends. If you are seeing this error when trying to use default_backend() please try uninstalling and reinstalling cryptography.',)]"] >> 2016-11-27T21:07:26Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information >> >> Any idea what's wrong? > > Around that time the pki on the old master has this: > > 0.Thread-17 - [27/Nov/2016:22:06:47 MEZ] [8] [3] Publishing: Could not > publish certificate serial number 0x1a. Error Failed to publish using > rule: No rules enabled > > Debug has: > [27/Nov/2016:22:06:47][Thread-17]: RunListeners:: Queue: 1 noSingleRequest > [27/Nov/2016:22:06:47][Thread-17]: getRequest mRequests=1 mSearchForRequests=false > [27/Nov/2016:22:06:47][Thread-17]: getRequest getting request: 29 > [27/Nov/2016:22:06:47][Thread-17]: In LdapBoundConnFactory::getConn() > [27/Nov/2016:22:06:47][Thread-17]: masterConn is connected: true > [27/Nov/2016:22:06:47][Thread-17]: getConn: conn is connected true > [27/Nov/2016:22:06:47][Thread-17]: getConn: mNumConns now 4 > [27/Nov/2016:22:06:47][Thread-17]: returnConn: mNumConns now 5 > [27/Nov/2016:22:06:47][Thread-17]: getRequest request 29 found > [27/Nov/2016:22:06:47][Thread-17]: getRequest mRequests=0 mSearchForRequests=false done > [27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = com.netscape.cms.listeners.CertificateIssuedListener > [27/Nov/2016:22:06:47][Thread-17]: CertificateIssuedListener: accept 29 > [27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = com.netscape.ca.CRLIssuingPoint$RevocationRequestListener > [27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = com.netscape.cmscore.ldap.LdapRequestListener > [27/Nov/2016:22:06:47][Thread-17]: LdapRequestListener handling publishing for enrollment request id 29 > [27/Nov/2016:22:06:47][Thread-17]: Checking publishing for request 29 > [27/Nov/2016:22:06:47][Thread-17]: In PublisherProcessor::publishCert > [27/Nov/2016:22:06:47][Thread-17]: Publishing: can't find publishing rule,exiting routine. > [27/Nov/2016:22:06:47][Thread-17]: PublishProcessor::publishCert : Failed to publish using rule: No rules enabled > [27/Nov/2016:22:06:47][Thread-17]: RunListeners: IRequestListener = com.netscape.cms.listeners.CertificateRevokedListener > [27/Nov/2016:22:06:47][Thread-17]: RunListeners: mRequest = 29 > [27/Nov/2016:22:06:47][Thread-17]: updatePublishingStatus mSavePublishingCounter: 3 mSavePublishingStatus: 200 > [27/Nov/2016:22:06:47][Thread-17]: RunListeners: noQueue SingleRequest > [27/Nov/2016:22:06:47][Thread-17]: RequestRepository: setPublishingStatus mBaseDN: ou=ca,ou=requests,o=ipaca status: -1 > [27/Nov/2016:22:06:47][Thread-17]: In LdapBoundConnFactory::getConn() > [27/Nov/2016:22:06:47][Thread-17]: masterConn is connected: true > [27/Nov/2016:22:06:47][Thread-17]: getConn: conn is connected true > [27/Nov/2016:22:06:47][Thread-17]: getConn: mNumConns now 4 > [27/Nov/2016:22:06:47][Thread-17]: returnConn: mNumConns now 5 > [27/Nov/2016:22:06:47][Thread-17]: Number of publishing threads: 0 > > Maybe something in dogtag is missing? > > Jochen > Hi Jochen, can you please check the version of python-cryptography on master and replica? I remember there used to be problem with pre-0.9 versions breaking Custodia. -- Martin^3 Babinsky From deepak_dimri at hotmail.com Mon Nov 28 11:25:30 2016 From: deepak_dimri at hotmail.com (Deepak Dimri) Date: Mon, 28 Nov 2016 11:25:30 +0000 Subject: [Freeipa-users] IPA rewrite conf In-Reply-To: <20161128080404.GT29414@redhat.com> References: , <20161128080404.GT29414@redhat.com> Message-ID: Hi Jan, Thanks for your reply. Sorry for the typo its AWS ELB. I have seen the link you shared below. My issue is that i want my IPA servers in Failover/Load Balancing mode and when i add another IPA server using Proxy balancer i believe ProxyPassReverseCookieDomain and RequestHeader edit Referer directives does not work for me. Basically I am trying to make the balancer to work with below configuration but its failing at the ProxyPassReverseCookieDomain and RequestHeader edit Referer directives level: # IPA Server 1 BalancerMember https://ipa1.int.example.com/ # IPA Server 2 BalancerMember https://ipa2.int.example.com/ SSLProxyEngine on ProxyPass / balancer://ipacluster/ ProxyPassReverse / balancer://ipacluster/ ProxyPassReverseCookieDomain ipa1.int.example.com webipa.example.com RequestHeader edit Referer ^https://webipa\.example\.com/ https://ipa1.int.example.com/ ProxyPassReverseCookieDomain ipa2.int.example.com webipa.example.com RequestHeader edit Referer ^https://webipa\.example\.com/ https://ipa2.int.example.com/ I am not sure how ProxyPassReverseCookieDomain and RequestHeader edit Referer can be configured in this scenario along with Proxy balancer? Regards, Deepak ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Jan Pazdziora Sent: Monday, November 28, 2016 3:04 AM To: deepak dimri Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA rewrite conf On Sun, Nov 27, 2016 at 01:06:36PM +0530, deepak dimri wrote: > Hi All, > > I am posting my issue here with an hope that i get a response. > > I have WS ELB configured to connect to FreeIPA servers on Ubuntu. My > FreeIPA servers are in private subnets. I am able to access my test > index.html page deployed on the FreeIPA server by hitting https:// url>/index.html. However when i try IPA UI https:///ipa/ui then i > am getting redirected to my internal IPA address which then resulting to > "site cannot be reached" error. I am wondering if i have an option of > tweaking my /usr/share/ipa/ipa-rewrite.conf file so that i can access IPA > UI using external ELB URL? > > Would appreciate if some one can give some pointers I don't know what WS ELB is but maybe https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name can get you started? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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 giulio at di.unimi.it Mon Nov 28 11:39:15 2016 From: giulio at di.unimi.it (Giulio Casella) Date: Mon, 28 Nov 2016 12:39:15 +0100 Subject: [Freeipa-users] ns-slapd segfault Message-ID: Hello, I have a setup with two ipa server in replica, based on CentOS 7. On one server (since a couple of days) ipa cannot start, the failing service is dirsrv@.service. In journal I have: ns-slapd[4617]: segfault at 7fb53b1ce515 ip 00007fb50126e1a6sp 00007ffc0b80d6c8 error 4 in libc-2.17.so[7fb501124000+1b7000] (just after a lot of SSL alerts complaining about some enabled cypher suite, but I cannot say if this could be related). I'm using ipa 4.2.0, and 389-ds-base 1.3.4. Servers are identical in hardware (they're virtual machines) and software (installed and updated at the same time). Second server works like a charme. Any hint? -- Giulio Casella giulio at di.unimi.it System and network manager Computer Science Dept. - University of Milano From BJB at jndata.dk Mon Nov 28 11:46:58 2016 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Mon, 28 Nov 2016 11:46:58 +0000 Subject: [Freeipa-users] directory server does not start after a system reboot Message-ID: <89213DDB84447F44A8E8950A5C2185E048317311@SJN01013.jnmain00.corp.jndata.net> VERSION: 4.4.0, API_VERSION: 2.213 For some reason, I can't get an otherwise well running directory server to start after a system reboot. As far as I know, nothing was changed recently on the server. using ipactl start -d reveals nothing: ipa: DEBUG: File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 752, in run_script return_value = main_function() File "/sbin/ipactl", line 578, in main ipa_restart(options) File "/sbin/ipactl", line 384, in ipa_restart raise IpactlError("Failed to start Directory Service: " + str(e)) ipa: DEBUG: The ipactl command failed, exception: IpactlError: Failed to start Directory Service: Command '/bin/systemctl start dirsrv at REALM.service' returned non-zero exit status 1 Failed to start Directory Service: Command '/bin/systemctl start dirsrv at REALM.service' returned non-zero exit status 1 the errorlog ends with: Nov 28 12:37:39 IDMSERVER ns-slapd[3278]: [28/Nov/2016:12:37:39.209235581 +0100] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: PR_DeleteSemaphore: /var/lib/dirsrv/slapd-REALM/cldb/bc2d6e92-886011e5-9529edd4-d9f0aefc.sema; NSPR error - -5943 The access log is not touched. Is there a debug flag somewhere I can add to get further info? Venlig hilsen Bjarne Blichfeldt Infrastructure Services Direkte +4563636119 Mobile +4521593270 BJB at jndata.dk [cid:image002.png at 01D24975.811CB830] JN Data A/S * Havsteensvej 4 * 4000 Roskilde Telefon 63 63 63 63/ Fax 63 63 63 64 www.jndata.dk [cid:image004.png at 01D24975.811CB830] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 410 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 5487 bytes Desc: image004.png URL: From william.muriithi at gmail.com Mon Nov 28 12:03:09 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Mon, 28 Nov 2016 07:03:09 -0500 Subject: [Freeipa-users] mailing list SPAM Message-ID: Hello, This is just a FYI. Whenever I post an email here, I get lot of emails from this address - kimirachel4991 at cczaa.com. Think there is someone in the list who is harvesting email addresses. That wouldn't be too bad because if he try to send a fresh mail, the spam system at google would filter it out, but since he is leveraging the mailing list and a current thread, it just pass through. Regards, William From simo at redhat.com Mon Nov 28 12:03:13 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 28 Nov 2016 07:03:13 -0500 Subject: [Freeipa-users] FreeIPA behind Apache Reverse Proxy and Load Balancer In-Reply-To: References: Message-ID: <1480334593.4311.10.camel@redhat.com> On Sat, 2016-11-26 at 23:18 +0530, deepak dimri wrote: > Hi All, > > I want to configure Apache reverse proxy to load balance/failover between > two IPA servers. I have referred > *https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name > * to > configure reverse proxy and it all works fine with one IPA server but i > want to load balance across two IPA Servers using Proxy Balancer module. > What should be the configuration for RequestHeader edit Referer with Proxy > balancer? In another thread* > https://www.mail-archive.com/freeipa-users at redhat.com/msg24644.html > *Peter > has mentioned cookie rewriting or 2 VHs and i will try VH option. But it > will really help and will save my time if some one can share full working > configuration. I tried below configuration but its failing at RequestHeader > edit Referer. > > > > # IPA Server 1 > BalancerMember https://ipa1.int.com/ > # IPA Server 2 > BalancerMember https://ipa2.int.com/ > > SSLEngine On > SSLProxyEngine On > LogLevel debug > SSLCertificateFile /etc/apache2/ssl/apache.crt > SSLCertificateKeyFile /etc/apache2/ssl/apache.key > ProxyRequests off > ProxyPass / balancer://ipacluster/ > ProxyPassReverse / balancer://ipacluster/ > ProxyPassReverseCookieDomain ipa1.int.com ipa.ext.com > RequestHeader edit Referer ^https://ipa\.ext\.com/ > https://ipa1.int.com/ > ProxyPassReverseCookieDomain ipa2.int.com ipa.ext.com > RequestHeader edit Referer ^https://ipa\.ext\.com/ > https://ipa2.int.com/ > > Changing the referer is not sufficient, if you use a different name then kerberos authentication will fail. You'd have to create a new key for the new name and distribute it to both server's http keytab so they can decrypt incoming requests. However your load balancer then also needs to stick with one server for all requests coming from the same client, because we use session cookies to maintain authentication and we do not share them between servers. Simo. -- Simo Sorce * Red Hat, Inc * New York From callum.guy at x-on.co.uk Mon Nov 28 12:03:53 2016 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 28 Nov 2016 12:03:53 +0000 Subject: [Freeipa-users] OTP Algorithm Message-ID: Hi All, I wanted to ask a quick question - perhaps a more experienced user will be able to help or point me to the correct documentation. Basically we have implemented password+OTP type authentication which works great. When adding a OTP code using the admin login you can choose an algorithm. For us the generated codes only work properly if the weakest sha1 algorithm is chosen/ To be clear the code generation works fine but the codes are not valid when logging in. Is there a related setting we must change? Thanks, Callum -- *0333 332 0000 | www.x-on.co.uk | ** * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From th at casalogic.dk Mon Nov 28 12:37:56 2016 From: th at casalogic.dk (Troels Hansen) Date: Mon, 28 Nov 2016 13:37:56 +0100 (CET) Subject: [Freeipa-users] SSH using putty to IPA client In-Reply-To: <20160928094802.GB24352@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <1098516169.379802.1474874746409.JavaMail.zimbra@casalogic.dk> <20160926113018.GU6019@p.Speedport_W_724V_Typ_A_05011603_00_009> <820303837.407114.1475047177588.JavaMail.zimbra@casalogic.dk> <20160928080620.GY6019@p.Speedport_W_724V_Typ_A_05011603_00_009> <585899542.408376.1475051623551.JavaMail.zimbra@casalogic.dk> <20160928084331.GA24101@p.Speedport_W_724V_Typ_A_05011603_00_009> <734257841.409436.1475055056872.JavaMail.zimbra@casalogic.dk> <20160928094802.GB24352@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <683238656.1013875.1480336676294.JavaMail.zimbra@casalogic.dk> Hi all Just wanted to follow up on my recent findings in regards to IPA - AD trust and kerberos delegations, sa we gave up on this, and just lived with it not working. In the end we ended up discovering that for kerberos trust delegation to work ldap/udp ingoing HAVE to be open on the IPA server! ----- On Sep 28, 2016, at 11:48 AM, Sumit Bose sbose at redhat.com wrote: > On Wed, Sep 28, 2016 at 11:30:56AM +0200, Troels Hansen wrote: >> >> > Yes, this makes sense as well. If you are not in the forest root you >> > first need a cross-realm TGT for your domain and the forest root. Then >> > you need a cross-realm TGT for the forest root and the IPA domain. >> > >> > As a next step you should see a request to the IPA KDC to get the actual >> > service ticket for the host in the IPA domain. >> >> Yes, this is the traffic that's never seen in the capture. >> It seems Windows(Putty) never asks for at host ticket for the IPA host. I >> receive the krbtgt for the IPA domain, but never sees any traffic from the >> Windows client to IPA, and thus, never receives the host ticket on the Windows >> client. > > Please check the other traffic on the client after receiving the > cross-realm ticket for the IPA domain. Since the client get the name to > the IPA realm from the AD DC in the last response I would expect that it > will try some DNS SRV lookups to find a KDC in the IPA realm. > > HTH > > bye, > Sumit > >> >> I'm not at all sure how Kerberos works in Putty, but it seems it uses its own >> Kerberos libraryes and that these fail. >> >> I Linux not joined to IPA, just installed with kerberos and use dns config in >> krb5.conf can kinit in the NET domain, and ssh to IPA using kerberos just fine, > > so it seems the problem just relates to putty. -- Med venlig hilsen Troels Hansen Systemkonsulent Casalogic A/S T (+45) 70 20 10 63 M (+45) 22 43 71 57 Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. From jpazdziora at redhat.com Mon Nov 28 13:09:16 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 28 Nov 2016 14:09:16 +0100 Subject: [Freeipa-users] IPA rewrite conf In-Reply-To: References: <20161128080404.GT29414@redhat.com> Message-ID: <20161128130916.GV29414@redhat.com> On Mon, Nov 28, 2016 at 11:25:30AM +0000, Deepak Dimri wrote: > Hi Jan, Thanks for your reply. Sorry for the typo its AWS ELB. > > > I have seen the link you shared below. My issue is that i want my IPA servers in Failover/Load Balancing mode and when i add another IPA server using Proxy balancer i believe ProxyPassReverseCookieDomain and RequestHeader edit Referer directives does not work for me. Basically I am trying to make the balancer to work with below configuration but its failing at the ProxyPassReverseCookieDomain and RequestHeader edit Referer directives level: > What error do you get when it fails? > > > # IPA Server 1 > BalancerMember https://ipa1.int.example.com/ > # IPA Server 2 > BalancerMember https://ipa2.int.example.com/ > > SSLProxyEngine on > ProxyPass / balancer://ipacluster/ > ProxyPassReverse / balancer://ipacluster/ > ProxyPassReverseCookieDomain ipa1.int.example.com webipa.example.com > RequestHeader edit Referer ^https://webipa\.example\.com/ https://ipa1.int.example.com/ > ProxyPassReverseCookieDomain ipa2.int.example.com webipa.example.com > RequestHeader edit Referer ^https://webipa\.example\.com/ https://ipa2.int.example.com/ > > > I am not sure how ProxyPassReverseCookieDomain and RequestHeader edit Referer can be configured in this scenario along with Proxy balancer? I don't see why ProxyPassReverseCookieDomain should fail. With RequestHeader, I suspect only one change will be done because after the first change, the value of the Referer header already contains name of one of the replicas. Could you try modifying the Referer with the RequestHeader directly on the IPA server, instead of on the balancer machine? On the IPA server, you already know what name you want to set it to. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Mon Nov 28 13:15:49 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 28 Nov 2016 15:15:49 +0200 Subject: [Freeipa-users] SSH using putty to IPA client In-Reply-To: <683238656.1013875.1480336676294.JavaMail.zimbra@casalogic.dk> References: <1098516169.379802.1474874746409.JavaMail.zimbra@casalogic.dk> <20160926113018.GU6019@p.Speedport_W_724V_Typ_A_05011603_00_009> <820303837.407114.1475047177588.JavaMail.zimbra@casalogic.dk> <20160928080620.GY6019@p.Speedport_W_724V_Typ_A_05011603_00_009> <585899542.408376.1475051623551.JavaMail.zimbra@casalogic.dk> <20160928084331.GA24101@p.Speedport_W_724V_Typ_A_05011603_00_009> <734257841.409436.1475055056872.JavaMail.zimbra@casalogic.dk> <20160928094802.GB24352@p.Speedport_W_724V_Typ_A_05011603_00_009> <683238656.1013875.1480336676294.JavaMail.zimbra@casalogic.dk> Message-ID: <20161128131549.qiwcmnlcaqjajc45@redhat.com> On ma, 28 marras 2016, Troels Hansen wrote: >Hi all > >Just wanted to follow up on my recent findings in regards to IPA - AD >trust and kerberos delegations, sa we gave up on this, and just lived >with it not working. > >In the end we ended up discovering that for kerberos trust delegation >to work ldap/udp ingoing HAVE to be open on the IPA server! Correct, this is so-called CLDAP protocol (connectionless LDAP, 389/UDP), which is a key in DC resolution for AD domains. This requirement is documented in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-req-ports > > > >----- On Sep 28, 2016, at 11:48 AM, Sumit Bose sbose at redhat.com wrote: > >> On Wed, Sep 28, 2016 at 11:30:56AM +0200, Troels Hansen wrote: >>> >>> > Yes, this makes sense as well. If you are not in the forest root you >>> > first need a cross-realm TGT for your domain and the forest root. Then >>> > you need a cross-realm TGT for the forest root and the IPA domain. >>> > >>> > As a next step you should see a request to the IPA KDC to get the actual >>> > service ticket for the host in the IPA domain. >>> >>> Yes, this is the traffic that's never seen in the capture. >>> It seems Windows(Putty) never asks for at host ticket for the IPA host. I >>> receive the krbtgt for the IPA domain, but never sees any traffic from the >>> Windows client to IPA, and thus, never receives the host ticket on the Windows >>> client. >> >> Please check the other traffic on the client after receiving the >> cross-realm ticket for the IPA domain. Since the client get the name to >> the IPA realm from the AD DC in the last response I would expect that it >> will try some DNS SRV lookups to find a KDC in the IPA realm. >> >> HTH >> >> bye, >> Sumit >> >>> >>> I'm not at all sure how Kerberos works in Putty, but it seems it uses its own >>> Kerberos libraryes and that these fail. >>> >>> I Linux not joined to IPA, just installed with kerberos and use dns config in >>> krb5.conf can kinit in the NET domain, and ssh to IPA using kerberos just fine, >> > so it seems the problem just relates to putty. > >-- >Med venlig hilsen > >Troels Hansen > >Systemkonsulent > >Casalogic A/S > > >T (+45) 70 20 10 63 > >M (+45) 22 43 71 57 > >Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og meget mere. > >-- >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 lslebodn at redhat.com Mon Nov 28 14:25:47 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 28 Nov 2016 15:25:47 +0100 Subject: [Freeipa-users] ns-slapd segfault In-Reply-To: References: Message-ID: <20161128142547.GB30923@10.4.128.1> On (28/11/16 12:39), Giulio Casella wrote: >Hello, > >I have a setup with two ipa server in replica, based on CentOS 7. >On one server (since a couple of days) ipa cannot start, the failing service >is dirsrv@.service. >In journal I have: > >ns-slapd[4617]: segfault at 7fb53b1ce515 ip 00007fb50126e1a6sp >00007ffc0b80d6c8 error 4 in libc-2.17.so[7fb501124000+1b7000] > >(just after a lot of SSL alerts complaining about some enabled cypher suite, >but I cannot say if this could be related). > >I'm using ipa 4.2.0, and 389-ds-base 1.3.4. > It would be good to know the exact version. rpm -q 389-ds-base Please provide backtrace or coredump; other developers will know wheter it's know bug or a new bug. http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-crashes LS From deepak_dimri at hotmail.com Mon Nov 28 15:09:51 2016 From: deepak_dimri at hotmail.com (Deepak Dimri) Date: Mon, 28 Nov 2016 15:09:51 +0000 Subject: [Freeipa-users] IPA rewrite conf In-Reply-To: <20161128130916.GV29414@redhat.com> References: <20161128080404.GT29414@redhat.com> , <20161128130916.GV29414@redhat.com> Message-ID: Hi Jan, sorry to ask but where exactly i can modify the referer with RequestHeader on IPA Server? Many Thanks, Deepak ________________________________ From: Jan Pazdziora Sent: Monday, November 28, 2016 8:09 AM To: Deepak Dimri Cc: deepak dimri; freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA rewrite conf On Mon, Nov 28, 2016 at 11:25:30AM +0000, Deepak Dimri wrote: > Hi Jan, Thanks for your reply. Sorry for the typo its AWS ELB. > > > I have seen the link you shared below. My issue is that i want my IPA servers in Failover/Load Balancing mode and when i add another IPA server using Proxy balancer i believe ProxyPassReverseCookieDomain and RequestHeader edit Referer directives does not work for me. Basically I am trying to make the balancer to work with below configuration but its failing at the ProxyPassReverseCookieDomain and RequestHeader edit Referer directives level: > What error do you get when it fails? > > > # IPA Server 1 > BalancerMember https://ipa1.int.example.com/ > # IPA Server 2 > BalancerMember https://ipa2.int.example.com/ > > SSLProxyEngine on > ProxyPass / balancer://ipacluster/ > ProxyPassReverse / balancer://ipacluster/ > ProxyPassReverseCookieDomain ipa1.int.example.com webipa.example.com > RequestHeader edit Referer ^https://webipa\.example\.com/ https://ipa1.int.example.com/ > ProxyPassReverseCookieDomain ipa2.int.example.com webipa.example.com > RequestHeader edit Referer ^https://webipa\.example\.com/ https://ipa2.int.example.com/ > > > I am not sure how ProxyPassReverseCookieDomain and RequestHeader edit Referer can be configured in this scenario along with Proxy balancer? I don't see why ProxyPassReverseCookieDomain should fail. With RequestHeader, I suspect only one change will be done because after the first change, the value of the Referer header already contains name of one of the replicas. Could you try modifying the Referer with the RequestHeader directly on the IPA server, instead of on the balancer machine? On the IPA server, you already know what name you want to set it to. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From giulio at di.unimi.it Mon Nov 28 15:22:50 2016 From: giulio at di.unimi.it (Giulio Casella) Date: Mon, 28 Nov 2016 16:22:50 +0100 Subject: [Freeipa-users] ns-slapd segfault In-Reply-To: <20161128142547.GB30923@10.4.128.1> References: <20161128142547.GB30923@10.4.128.1> Message-ID: Il 28/11/2016 15:25, Lukas Slebodnik ha scritto: > On (28/11/16 12:39), Giulio Casella wrote: >> Hello, >> >> I have a setup with two ipa server in replica, based on CentOS 7. >> On one server (since a couple of days) ipa cannot start, the failing service >> is dirsrv@.service. >> In journal I have: >> >> ns-slapd[4617]: segfault at 7fb53b1ce515 ip 00007fb50126e1a6sp >> 00007ffc0b80d6c8 error 4 in libc-2.17.so[7fb501124000+1b7000] >> >> (just after a lot of SSL alerts complaining about some enabled cypher suite, >> but I cannot say if this could be related). >> >> I'm using ipa 4.2.0, and 389-ds-base 1.3.4. >> > It would be good to know the exact version. > rpm -q 389-ds-base Installed version is: 389-ds-base-1.3.4.0-33.el7_2.x86_64 > > Please provide backtrace or coredump; other developers will know > wheter it's know bug or a new bug. Ok, you can find attached full stacktrace. Thanks in advance, gc -------------- next part -------------- GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /usr/sbin/ns-slapd...Reading symbols from /usr/lib/debug/usr/sbin/ns-slapd.debug...done. done. [New LWP 4378] [New LWP 4379] [New LWP 4380] [New LWP 4381] [New LWP 4382] [New LWP 4383] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-MYDOMAIN-LOCAL -i /var/ru'. Program terminated with signal 11, Segmentation fault. #0 __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1515 1515 movdqu 0x10(%rsi), %xmm1 Thread 6 (Thread 0x7f023ffff700 (LWP 4383)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007f02565021f0 in PR_WaitCondVar (cvar=cvar at entry=0x7f025a3a2660, timeout=4294967295) at ../../../nspr/pr/src/pthreads/ptsynch.c:396 rv = thred = 0x7f0259e7a8a0 #2 0x00007f0258348198 in slapi_wait_condvar (cvar=0x7f025a3a2660, timeout=timeout at entry=0x0) at ldap/servers/slapd/slapi2nspr.c:150 prit = #3 0x00007f024e6d662e in cos_cache_wait_on_change (arg=) at ldap/servers/plugins/cos/cos_cache.c:407 No locals. #4 0x00007f025650796b in _pt_root (arg=0x7f0259e7a8a0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7f0259e7a8a0 detached = 1 id = 139647640401664 tid = 4383 #5 0x00007f0255ea8dc5 in start_thread (arg=0x7f023ffff700) at pthread_create.c:308 __res = pd = 0x7f023ffff700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139647640401664, 6391692756101938369, 0, 139647640402368, 139647640401664, 1, -6433491789647921983, -6433548853668037439}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #6 0x00007f0255bd5ced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 5 (Thread 0x7f0244eca700 (LWP 4382)): #0 0x00007f0255bcd413 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007f02583590e9 in DS_Sleep (ticks=) at ldap/servers/slapd/util.c:1035 mSecs = tm = {tv_sec = 0, tv_usec = 893342} #2 0x00007f024b9f6784 in perfctrs_wait (milliseconds=milliseconds at entry=1000, priv=, db_env=) at ldap/servers/slapd/back-ldbm/perfctrs.c:100 interval = #3 0x00007f024b99e707 in perf_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:3966 priv = 0x7f0259cd0a60 li = #4 0x00007f025650796b in _pt_root (arg=0x7f0259e7f770) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7f0259e7f770 detached = 1 id = 139647723022080 tid = 4382 #5 0x00007f0255ea8dc5 in start_thread (arg=0x7f0244eca700) at pthread_create.c:308 __res = pd = 0x7f0244eca700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139647723022080, 6391692756101938369, 0, 139647723022784, 139647723022080, 1, -6433581822362993471, -6433548853668037439}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #6 0x00007f0255bd5ced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 4 (Thread 0x7f02456cb700 (LWP 4381)): #0 0x00007f0255bcd413 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007f02583590e9 in DS_Sleep (ticks=ticks at entry=250) at ldap/servers/slapd/util.c:1035 mSecs = tm = {tv_sec = 0, tv_usec = 165349} #2 0x00007f024b9a3b7f in trickle_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:4892 interval = 250 rval = priv = 0x7f0259cd0a60 li = debug_checkpointing = 0 #3 0x00007f025650796b in _pt_root (arg=0x7f0259f31730) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7f0259f31730 detached = 1 id = 139647731414784 tid = 4381 #4 0x00007f0255ea8dc5 in start_thread (arg=0x7f02456cb700) at pthread_create.c:308 __res = pd = 0x7f02456cb700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139647731414784, 6391692756101938369, 0, 139647731415488, 139647731414784, 1, -6433585121434747711, -6433548853668037439}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #5 0x00007f0255bd5ced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 3 (Thread 0x7f0245ecc700 (LWP 4380)): #0 0x00007f0255bcd413 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007f02583590e9 in DS_Sleep (ticks=ticks at entry=250) at ldap/servers/slapd/util.c:1035 mSecs = tm = {tv_sec = 0, tv_usec = 209345} #2 0x00007f024b9a7a26 in checkpoint_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:4675 time_of_last_checkpoint_completion = 1480346209 interval = rval = priv = li = debug_checkpointing = 0 checkpoint_interval = home_dir = list = 0x0 listp = penv = 0x7f0259e74820 time_of_last_comapctdb_completion = 1480346209 compactdb_interval = 2592000 txn = {back_txn_txn = 0x0} #3 0x00007f025650796b in _pt_root (arg=0x7f0259d3b4a0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7f0259d3b4a0 detached = 1 id = 139647739807488 tid = 4380 #4 0x00007f0255ea8dc5 in start_thread (arg=0x7f0245ecc700) at pthread_create.c:308 __res = pd = 0x7f0245ecc700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139647739807488, 6391692756101938369, 0, 139647739808192, 139647739807488, 1, -6433584022459990847, -6433548853668037439}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #5 0x00007f0255bd5ced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 2 (Thread 0x7f02466cd700 (LWP 4379)): #0 0x00007f0255bcd413 in select () at ../sysdeps/unix/syscall-template.S:81 No locals. #1 0x00007f02583590e9 in DS_Sleep (ticks=ticks at entry=100) at ldap/servers/slapd/util.c:1035 mSecs = tm = {tv_sec = 0, tv_usec = 59358} #2 0x00007f024b9a3907 in deadlock_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:4466 rval = priv = 0x7f0259cd0a60 li = interval = #3 0x00007f025650796b in _pt_root (arg=0x7f0259e840d0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 rv = thred = 0x7f0259e840d0 detached = 1 id = 139647748200192 tid = 4379 #4 0x00007f0255ea8dc5 in start_thread (arg=0x7f02466cd700) at pthread_create.c:308 __res = pd = 0x7f02466cd700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139647748200192, 6391692756101938369, 0, 139647748200896, 139647748200192, 1, -6433578521143755583, -6433548853668037439}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #5 0x00007f0255bd5ced in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals. Thread 1 (Thread 0x7f02587bc840 (LWP 4378)): #0 __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1515 No locals. #1 0x00007f024b6f7e50 in memcpy (__len=, __src=, __dest=) at /usr/include/bits/string3.h:51 No locals. #2 _cl5ReadBerval (bv=bv at entry=0x7ffc382a3020, buff=buff at entry=0x7ffc382a3008) at ldap/servers/plugins/replication/cl5_api.c:2764 length = net_length = #3 0x00007f024b6f8d35 in _cl5ReadMod (buff=, smod=0x7ffc382a3050) at ldap/servers/plugins/replication/cl5_api.c:2654 i = 0 val_count = 20264761 type = 0x0 bv = {bv_len = 895759414, bv_val = 0x7f01f8f20010 "2000000040000"} pos = 0x7f025a317c4f "2000000040000" op = decbv = 0x0 bv_to_use = rc = #4 _cl5ReadMods (mods=mods at entry=0x7ffc382a3330, buff=buff at entry=0x7ffc382a3150) at ldap/servers/plugins/replication/cl5_api.c:2607 pos = i = 3 mod_count = 4 smods = {mods = 0x7f025a311d40, num_elements = 5, num_mods = 3, iterator = 0, free_mods = 1} smod = {mod = 0x7f025a339360, num_elements = 20264762, num_values = 0, iterator = 0, free_mod = 1} #5 0x00007f024b6faba5 in cl5DBData2Entry (data=, len=, entry=entry at entry=0x7ffc382a3290) at ldap/servers/plugins/replication/cl5_api.c:2342 rc = version = pos = 0x7f025a317bbf "" strCSN = 0x0 op = 0x7ffc382a3300 add_mods = 0x7f025a368e90 rawDN = 0x7f025a30f960 "fqdn=client-065-13.mydomain.local,cn=computers,cn=accounts,dc=mydomain,dc=local" s = "\260\215\066Z\002\177\000\000\300\061*8\374\177\000\000\300\061*", #6 0x00007f024b6fb5d6 in _cl5GetNextEntry (entry=entry at entry=0x7ffc382a3290, iterator=0x7f025a368e90) at ldap/servers/plugins/replication/cl5_api.c:5291 rc = 0 it = 0x7f025a368e90 key = {data = 0x0, size = 21, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 16} data = {data = 0x7f025a317b10, size = 348, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 16} #7 0x00007f024b6fbb34 in _cl5ConstructRUV (purge=1, obj=0x7f025a368db0, replGen=0x7ffc382a3290 "") at ldap/servers/plugins/replication/cl5_api.c:4306 iterator = 0x7f025a368e90 file = 0x7f025a368db0 rid = rc = entry = {op = 0x7ffc382a3300, time = 1469437006} op = {operation_type = 8, target_address = {udn = 0x0, uniqueid = 0x7f025a339c70 "92b59414-0bad11e6-815587a5-97ea67cc", sdn = 0x7f025a317030}, csn = 0x7f025a33b310, request_controls = 0x0, p = {p_add = {target_entry = 0x0, parentuniqueid = 0x0}, p_bind = {bind_method = 0, bind_creds = 0x0, bind_saslmechanism = 0x0, bind_ret_saslcreds = 0x0}, p_compare = {compare_ava = {ava_type = 0x0, ava_value = {bv_len = 0, bv_val = 0x0}, ava_private = 0x0}}, p_modify = {modify_mods = 0x0}, p_modrdn = {modrdn_newrdn = 0x0, modrdn_deloldrdn = 0, modrdn_newsuperior_address = {udn = 0x0, uniqueid = 0x0, sdn = 0x0}, modrdn_mods = 0x0}, p_search = {search_scope = 0, search_deref = 0, search_sizelimit = 0, search_timelimit = 0, search_filter = 0x0, search_strfilter = 0x0, search_attrs = 0x0, search_attrsonly = 0, search_is_and = 0, search_gerattrs = 0x0}, p_abandon = {abandon_targetmsgid = 0}, p_extended = {exop_oid = 0x0, exop_value = 0x0}}} #8 _cl5ReadRUV (replGen=replGen at entry=0x7f025a369b40 "568f7999000000040000", obj=obj at entry=0x7f025a31cc20, purge=purge at entry=1) at ldap/servers/plugins/replication/cl5_api.c:4153 rc = csnStr = "000000de", '0' key = {data = 0x7ffc382a3370, size = 21, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 0} data = {data = 0x0, size = 0, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 16} vals = 0x0 file = pos = agmt_name = 0x7f024b75c4d3 "" #9 0x00007f024b6fbf99 in _cl5DBOpenFileByReplicaName (replName=replName at entry=0x7f025a33c0f0 "9a90fe85-b5e511e5-bde187f9-d6459a2a", replGen=0x7f025a369b40 "568f7999000000040000", obj=obj at entry=0x0, checkDups=checkDups at entry=0) at ldap/servers/plugins/replication/cl5_api.c:6041 rc = tmpObj = 0x7f025a31cc20 file = 0x7f025a368db0 file_name = 0x7f025a36d5b0 "" #10 0x00007f024b6fcf65 in _cl5DBOpenFile (obj=0x0, checkDups=0, replica=0x7f025a31def0) at ldap/servers/plugins/replication/cl5_api.c:5988 rc = replName = 0x7f025a33c0f0 "9a90fe85-b5e511e5-bde187f9-d6459a2a" replGen = 0x7f025a369b40 "568f7999000000040000" r = 0x7f025a3a2890 #11 _cl5DBOpen () at ldap/servers/plugins/replication/cl5_api.c:2068 dir = 0x7f025a31d970 entry = 0x7f025a31d970 rc = replica = 0x7f025a31def0 count = 1 #12 0x00007f024b6fd3f6 in _cl5Open (dir=dir at entry=0x7f025a39a5a0 "/var/lib/dirsrv/slapd-MYDOMAIN-LOCAL/cldb", config=config at entry=0x7ffc382a4668, openMode=openMode at entry=CL5_OPEN_NORMAL) at ldap/servers/plugins/replication/cl5_api.c:1911 rc = #13 0x00007f024b6fd600 in cl5Open (dir=0x7f025a39a5a0 "/var/lib/dirsrv/slapd-MYDOMAIN-LOCAL/cldb", config=config at entry=0x7ffc382a4668) at ldap/servers/plugins/replication/cl5_api.c:484 rc = #14 0x00007f024b7041f6 in changelog5_init () at ldap/servers/plugins/replication/cl5_init.c:51 rc = 0 config = {dir = 0x7f025a39a5a0 "/var/lib/dirsrv/slapd-MYDOMAIN-LOCAL/cldb", maxAge = 0x7f025a369950 "-1", maxEntries = 0, dbconfig = {pageSize = 0, fileMode = 0, maxConcurrentWrites = 2, encryptionAlgorithm = 0x0, symmetricKey = 0x0}, symmetricKey = 0x0, compactInterval = 2592000, trimInterval = 300} #15 0x00007f024b71a0dc in multimaster_start (pb=0x7f0259e9a5b8) at ldap/servers/plugins/replication/repl5_init.c:761 rc = pb = 0x7f0259e9a5b8 rc = #16 0x00007f02583258b7 in plugin_call_func (list=0x7f0259ce3f40, operation=operation at entry=212, pb=0x7f0259e9a5b8, call_one=call_one at entry=1) at ldap/servers/slapd/plugin.c:1920 n = func = 0x7f024b719f90 rc = return_value = 0 count = 0 #17 0x00007f0258325fe8 in plugin_call_one (pb=, operation=212, list=) at ldap/servers/slapd/plugin.c:1870 No locals. #18 plugin_dependency_startall (argc=argc at entry=7, argv=argv at entry=0x7ffc382a5418, errmsg=, operation=212) at ldap/servers/slapd/plugin.c:1679 enabled = satisfied = 1 break_out = 0 ret = 0 pb = {pb_backend = 0x0, pb_conn = 0x0, pb_op = 0x0, pb_plugin = 0x0, pb_opreturn = 0, pb_object = 0x0, pb_destroy_fn = 0x0, pb_requestor_isroot = 0, pb_config_fname = 0x0, pb_config_lineno = 0, pb_config_argc = 0, pb_config_argv = 0x0, plugin_tracking = 0, pb_target_entry = 0x0, pb_existing_dn_entry = 0x0, pb_existing_uniqueid_entry = 0x0, pb_parent_entry = 0x0, pb_newparent_entry = 0x0, pb_pre_op_entry = 0x0, pb_post_op_entry = 0x0, pb_seq_type = 0, pb_seq_attrname = 0x0, pb_seq_val = 0x0, pb_dbverify_dbdir = 0x0, pb_ldif_file = 0x0, pb_removedupvals = 0, pb_db2index_attrs = 0x0, pb_ldif2db_noattrindexes = 0, pb_ldif_printkey = 0, pb_instance_name = 0x0, pb_task = 0x0, pb_task_flags = 0, pb_mr_filter_match_fn = 0x0, pb_mr_filter_index_fn = 0x0, pb_mr_filter_reset_fn = 0x0, pb_mr_index_fn = 0x0, pb_mr_oid = 0x0, pb_mr_type = 0x0, pb_mr_value = 0x0, pb_mr_values = 0x0, pb_mr_keys = 0x0, pb_mr_filter_reusable = 0, pb_mr_query_operator = 0, pb_mr_usage = 0, pb_pwd_storage_scheme_user_passwd = 0x0, pb_pwd_storage_scheme_db_passwd = 0x0, pb_managedsait = 0, pb_internal_op_result = 0, pb_plugin_internal_search_op_entries = 0x0, pb_plugin_internal_search_op_referrals = 0x0, pb_plugin_identity = 0x0, pb_plugin_config_area = 0x0, pb_parent_txn = 0x0, pb_txn = 0x0, pb_txn_ruv_mods_fn = 0x0, pb_dbsize = 0, pb_ldif_files = 0x0, pb_ldif_include = 0x0, pb_ldif_exclude = 0x0, pb_ldif_dump_replica = 0, pb_ldif_dump_uniqueid = 0, pb_ldif_generate_uniqueid = 0, pb_ldif_namespaceid = 0x0, pb_ldif_encrypt = 0, pb_operation_notes = 0, pb_slapd_argc = 7, pb_slapd_argv = 0x7ffc382a5418, pb_slapd_configdir = 0x0, pb_ctrls_arg = 0x0, pb_dse_dont_add_write = 0, pb_dse_add_merge = 0, pb_dse_dont_check_dups = 0, pb_dse_is_primary_file = 0, pb_schema_flags = 0, pb_result_code = 0, pb_result_text = 0x0, pb_result_matched = 0x0, pb_nentries = 0, urls = 0x0, pb_import_entry = 0x0, pb_import_state = 0, pb_destroy_content = 0, pb_dse_reapply_mods = 0, pb_urp_naming_collision_dn = 0x0, pb_urp_tombstone_uniqueid = 0x0, pb_server_running = 0, pb_backend_count = 0, pb_pwpolicy_ctrl = 0, pb_vattr_context = 0x0, pb_substrlens = 0x0, pb_plugin_enabled = 0, pb_search_ctrls = 0x0, pb_mr_index_sv_fn = 0x0, pb_syntax_filter_normalized = 0, pb_syntax_filter_data = 0x0, pb_paged_results_index = 0, pwdpolicy = 0x0, op_stack_elem = 0x0, pb_aci_target_check = 0} total_plugins = config = 0x7f0259e8b140 plugin_head = 0x7f0259e83a50 plugin_index = 79 plugin_entry = i = the_plugin_type = index = value = 0x0 plugins_started = 1 num_plg_started = 92 plugin = ep = shutdown_index = 15 #19 0x00007f02583263f1 in plugin_startall (argc=argc at entry=7, argv=argv at entry=0x7ffc382a5418, start_backends=start_backends at entry=1, start_global=start_global at entry=1) at ldap/servers/slapd/plugin.c:1832 No locals. #20 0x00007f02587efbc2 in main (argc=7, argv=0x7ffc382a5418) at ldap/servers/slapd/main.c:1054 rc = 0 sdn = 0x0 return_value = 0 slapdFrontendConfig = ports_info = {n_port = 389, s_port = 636, n_listenaddr = 0x7f0259c5c370, s_listenaddr = 0x7f0259c5c200, n_socket = 0x7f0259c5c250, i_listenaddr = 0x7f0259c5c2f0, i_port = 1, i_socket = 0x7f0259c5b340, s_socket = 0x7f0259c5c1e0} m = From esdras.laroque at gmail.com Mon Nov 28 16:10:53 2016 From: esdras.laroque at gmail.com (Esdras La-Roque) Date: Mon, 28 Nov 2016 13:10:53 -0300 Subject: [Freeipa-users] Clonning VM Message-ID: Hi Guys, What's the safe method to clone an virtual machine that is in IPA ? I tried do this already, but I had many troubles related with IPA to fix. -- *Esdras La-Roque* Analista e Desenvolvedor de Sistemas Mestrando em Ci?ncia da Computa??o LPI-1 | Linux Professional Institute - N?vel 1 MCITP | Microsoft Virtualization Administrator NCLA | Novell Certified Linux Administrator DCTS | Data Center Technical Specialist -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkudyba at fordham.edu Mon Nov 28 16:38:07 2016 From: rkudyba at fordham.edu (Robert Kudyba) Date: Mon, 28 Nov 2016 11:38:07 -0500 Subject: [Freeipa-users] new install on Fedora 24 kinit: Generic preauthentication failure while getting initial credentials Message-ID: <60257124-FA5E-4972-889E-0441005D111A@fordham.edu> There seems to be a problem either with Kerberos and/or using a self signed certificate vs. Let?s Encrypt. I tried to run the set up script from https://github.com/freeipa/freeipa-letsencrypt and below are some errors and logs. Within the /etc/httpd/conf.d/ipa.conf file I commented out these directives as I had some Apache redirects that were breaking: #WSGIDaemonProcess ipa processes=2 threads=1 maximum-requests=500 \ display-name=%{GROUP} socket-timeout=2147483647 #WSGIImportScript /usr/share/ipa/wsgi.py process-group=ipa application-group=ipa #WSGIScriptAlias /ipa /usr/share/ipa/wsgi.py #WSGIScriptReloading Off ./setup-le.sh Last metadata expiration check: 0:24:16 ago on Mon Nov 28 10:40:45 2016. Package certbot-0.9.3-1.fc25.noarch is already installed, skipping. Dependencies resolved. Nothing to do. Complete! Installing CA certificate, please wait Not a valid CA certificate: (SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user. (visit http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) The ipa-cacert-manage command failed. ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING ipa_memcached Service: RUNNING ipa-custodia Service: RUNNING ntpd Service: RUNNING pki-tomcatd Service: RUNNING ipa-otpd Service: RUNNING ipa: INFO: The ipactl command was successful kinit admin kinit: Generic preauthentication failure while getting initial credentials journalctl -u named-pkcs11 -- No entries ? journalctl -u named -- No entries ? file /var/named/data/named.run /var/named/data/named.run: cannot open `/var/named/data/named.run' (No such file or directory) ldapsearch -Y GSSAPI '(&(ipaConfigString=enabledService)(ipaConfigString=dnssecKeyMaster))' SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available (default cache: KEYRING:persistent:0)) ipa help krbtpolicy ipa: ERROR: did not receive Kerberos credentials In /var/log/krb5kdc.log: Nov 28 05:19:49 krb5kdc[19575](info): closing down fd 11 Nov 28 11:04:40 krb5kdc[19575](info): AS_REQ (6 etypes {18 17 16 23 25 26}) ip: NEEDED_PREAUTH: admin at for krbtgt/ourdomain@ ourdomain, Additional pre-authentication required Nov 28 11:04:40 krb5kdc[19575](info): closing down fd 11 Nov 28 11:15:35 krb5kdc[19573](info): AS_REQ (6 etypes {18 17 16 23 25 26}) ip: NEEDED_PREAUTH: admin at for krbtgt/ourdomain@ ourdomain, Additional pre-authentication required Nov 28 11:15:35 krb5kdc[19573](info): closing down fd 11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen at jochen.org Mon Nov 28 16:41:12 2016 From: jochen at jochen.org (Jochen Hein) Date: Mon, 28 Nov 2016 17:41:12 +0100 Subject: [Freeipa-users] Valid Sender ? - Re: Add 4.4 replica to 4.3 server fails In-Reply-To: <490106a0-a804-0563-8c99-1bd963c80098@redhat.com> (Martin Babinsky's message of "Mon, 28 Nov 2016 09:07:45 +0100") References: <83h96s4mww.fsf@echidna.jochen.org> <83d1hg4kg5.fsf@echidna.jochen.org> <490106a0-a804-0563-8c99-1bd963c80098@redhat.com> Message-ID: <838ts34kwn.fsf@echidna.jochen.org> Martin Babinsky writes: >>> 2016-11-27T21:07:26Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information >>> >>> Any idea what's wrong? > can you please check the version of python-cryptography on master and > replica? I remember there used to be problem with pre-0.9 versions > breaking Custodia. Both are newer. Master: [root at freeipa ca]# rpm -qa | grep python.*cryptogra python2-cryptography-1.5.3-3.fc24.x86_64 Replica: [root at freeipa1 pki]# rpm -qa | grep python.*cryptogra python2-cryptography-1.3.1-3.el7.x86_64 I've found https://github.com/latchset/jwcrypto/issues/47, https://github.com/pyinstaller/pyinstaller/issues/2013, and https://github.com/pyca/cryptography/issues/2907. But nothing that stands out for me. I'll wait for GA of CentOS 7.3 and will try again later, and also browse reports I may find. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From lslebodn at redhat.com Mon Nov 28 17:52:12 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 28 Nov 2016 18:52:12 +0100 Subject: [Freeipa-users] Clonning VM In-Reply-To: References: Message-ID: <20161128175212.GA1896@10.4.128.1> On (28/11/16 13:10), Esdras La-Roque wrote: >Hi Guys, > >What's the safe method to clone an virtual machine that is in IPA ? > >I tried do this already, but I had many troubles related with IPA to fix. > Why do you need to create clone? IMHO, It's much simpler to create replica of IPA (including CA replica). LS From mikej at flowjo.com Mon Nov 28 18:02:50 2016 From: mikej at flowjo.com (Mike Jacobacci) Date: Mon, 28 Nov 2016 10:02:50 -0800 Subject: [Freeipa-users] Host with Multiple hostnames Message-ID: Hello, I am sorry for the simple question, but I am using FreeIPA as our DNS server and I am trying to figure out how to map a second hostname to a host... I am unsure how the best way to go do it. I am just trying to give a server a user friendly name for access and I don't want to change the system hostname. I thought I could just add a CNAME entry for the host record, but it fails with the following error: invalid 'cnamerecord': CNAME record is not allowed to coexist with any other record (RFC 1034, section 3.6.2) Is there an easy way I can do this? Cheers, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From esdras.laroque at gmail.com Mon Nov 28 18:09:16 2016 From: esdras.laroque at gmail.com (Esdras La-Roque) Date: Mon, 28 Nov 2016 15:09:16 -0300 Subject: [Freeipa-users] Clonning VM In-Reply-To: <20161128175212.GA1896@10.4.128.1> References: <20161128175212.GA1896@10.4.128.1> Message-ID: I don't need clone of IPA Server.. I need for an client. 2016-11-28 14:52 GMT-03:00 Lukas Slebodnik : > On (28/11/16 13:10), Esdras La-Roque wrote: > >Hi Guys, > > > >What's the safe method to clone an virtual machine that is in IPA ? > > > >I tried do this already, but I had many troubles related with IPA to fix. > > > Why do you need to create clone? > IMHO, It's much simpler to create replica of IPA (including CA replica). > > LS > -- *Esdras La-Roque* Analista e Desenvolvedor de Sistemas Mestrando em Ci?ncia da Computa??o LPI-1 | Linux Professional Institute - N?vel 1 MCITP | Microsoft Virtualization Administrator NCLA | Novell Certified Linux Administrator DCTS | Data Center Technical Specialist -------------- next part -------------- An HTML attachment was scrubbed... URL: From mareynol at redhat.com Mon Nov 28 18:22:08 2016 From: mareynol at redhat.com (Mark Reynolds) Date: Mon, 28 Nov 2016 13:22:08 -0500 Subject: [Freeipa-users] ns-slapd segfault In-Reply-To: References: <20161128142547.GB30923@10.4.128.1> Message-ID: <8a02a86c-8e62-2d81-3905-14bfdebcfe52@redhat.com> On 11/28/2016 10:22 AM, Giulio Casella wrote: > Il 28/11/2016 15:25, Lukas Slebodnik ha scritto: >> On (28/11/16 12:39), Giulio Casella wrote: >>> Hello, >>> >>> I have a setup with two ipa server in replica, based on CentOS 7. >>> On one server (since a couple of days) ipa cannot start, the failing >>> service >>> is dirsrv@.service. >>> In journal I have: >>> >>> ns-slapd[4617]: segfault at 7fb53b1ce515 ip 00007fb50126e1a6sp >>> 00007ffc0b80d6c8 error 4 in libc-2.17.so[7fb501124000+1b7000] >>> >>> (just after a lot of SSL alerts complaining about some enabled >>> cypher suite, >>> but I cannot say if this could be related). >>> >>> I'm using ipa 4.2.0, and 389-ds-base 1.3.4. >>> >> It would be good to know the exact version. >> rpm -q 389-ds-base > > Installed version is: > > 389-ds-base-1.3.4.0-33.el7_2.x86_64 > >> >> Please provide backtrace or coredump; other developers will know >> wheter it's know bug or a new bug. > > Ok, you can find attached full stacktrace. It's crashing trying to read updates from the replication changelog. Are you using attribute encryption? Any chance you have a way to reproduce this? Since this is happening on only one server then I think recreating the replication changelog will "fix" the issue. Just re-initializing that replica should do it. Does this server start - so it can be reinited? If not, you need to manually remove the changelog and start the directory server, and reinit it. Or perform a manual ldif initialization. (I can help with either one if needed) Regards, Mark > > Thanks in advance, > gc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrichard at placeiq.com Mon Nov 28 19:28:09 2016 From: jrichard at placeiq.com (Jim Richard) Date: Mon, 28 Nov 2016 14:28:09 -0500 Subject: [Freeipa-users] httpd error logs Message-ID: I?ve got one master and one replica, IPA version is 3.0/CentOS 6.8. About 1000 hosts. Problem is, my httpd error logs are filling on super fast. I have no idea what these errors mean. Can someone point me in the right direction please. Thanks ! On the master: [28/Nov/2016:19:21:27 +0000] "POST /ca/agent/ca/displayBySerial HTTP/1.1" 200 10108 On the replica: (no CA): [Mon Nov 28 19:22:39 2016] [error] ipa: INFO: host/phoenix-226.nym1.placeiq.net at PLACEIQ.NET: cert_request(u??.removed?.PLACEIQ.NET', add=True): ACIError Jim Richard SYSTEM ADMINISTRATOR III (646) 338-8905 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Nov 28 19:36:06 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Nov 2016 14:36:06 -0500 Subject: [Freeipa-users] Clonning VM In-Reply-To: References: <20161128175212.GA1896@10.4.128.1> Message-ID: <583C8726.5020601@redhat.com> Esdras La-Roque wrote: > I don't need clone of IPA Server.. I need for an client. It won't work for either client or server. IPA provides an identity to a machine based on it's hostname. If you clone a machine and give it a new hostname then things won't line up and simply won't work. rob > > 2016-11-28 14:52 GMT-03:00 Lukas Slebodnik >: > > On (28/11/16 13:10), Esdras La-Roque wrote: > >Hi Guys, > > > >What's the safe method to clone an virtual machine that is in IPA ? > > > >I tried do this already, but I had many troubles related with IPA to fix. > > > Why do you need to create clone? > IMHO, It's much simpler to create replica of IPA (including CA replica). > > LS > > > > > -- > *Esdras La-Roque* > Analista e Desenvolvedor de Sistemas > Mestrando em Ci?ncia da Computa??o > > LPI-1 | Linux Professional Institute - N?vel 1 > MCITP | Microsoft Virtualization Administrator > NCLA | Novell Certified Linux Administrator > DCTS | Data Center Technical Specialist > > From rcritten at redhat.com Mon Nov 28 19:39:50 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Nov 2016 14:39:50 -0500 Subject: [Freeipa-users] ACIerrors is httpd log In-Reply-To: <4B8D5975-7858-4CC2-99AF-FC1E4D6EEB93@placeiq.com> References: <4B8D5975-7858-4CC2-99AF-FC1E4D6EEB93@placeiq.com> Message-ID: <583C8806.1030809@redhat.com> Jim Richard wrote: > Honestly I?m not even sure if something is not working correctly :) > > All I know is that my httpd, access and krb5 logs are filling up all my > disk space extremely quickly and I have no idea why. > > Centos 6.8 + IPA 3.0 > > One master and one replica. > > Are these things related? > > How do I fix, where do I even start? > > Thanks ! > > On the replica the httpd log is constantly getting spammed with: > > [Thu Nov 24 05:55:18 2016] [error] ipa: INFO: > host/phoenix-153.nym1.placeiq.net at PLACEIQ.NET: > cert_request(u?actual cert removed .. , add=True): ACIError > > and on the master the access log is filling up quickly with: > > 10.1.41.110 - - [24/Nov/2016:06:09:54 +0000] "POST > /ca/agent/ca/displayBySerial HTTP/1.1" 200 10106 Looks like certmonger trying to renew the per-client SSL certificate. You can confirm by pulling out the CSR and poking at it with openssl req. On the client you can try running: ipa-getcert list This may show more details on why the request was rejected. rob From rcritten at redhat.com Mon Nov 28 19:41:26 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Nov 2016 14:41:26 -0500 Subject: [Freeipa-users] Configure HPUX 11i V3 as IPA Client In-Reply-To: References: Message-ID: <583C8866.5040302@redhat.com> Rajveer Singh wrote: > Hi All, > > I am referring > http://www.freeipa.org/page/ConfiguringUnixClients#Configuring_Client_Authentication_3 > to configure HP UX 11i V3 as IPA client but it has no reference for > 11iV3 but only 11i V0, 1 & 2. > > Though I tried to follow the steps mentioned in 11iv0, but they are not > getting good understanding. > > Do we have any such document/procedure? Any URL will be highly appreciated. Not that I know of. If you provide the errors you are seeing, or describe what isn't working, someone might be able to help You might try contacting HP directly for assistance. rob From rkudyba at fordham.edu Mon Nov 28 20:34:54 2016 From: rkudyba at fordham.edu (Robert Kudyba) Date: Mon, 28 Nov 2016 15:34:54 -0500 Subject: [Freeipa-users] Fedora 25 install error PR_ADDRESS_NOT_SUPPORTED_ERROR Network address type not supported Message-ID: <31CE8274-3A18-4B57-B98B-FC327F9987BE@fordham.edu> This is a new installation attempt. Apache was running but I commented out #IncludeOptional conf.d/*.conf in the httpd.conf file. We also have DNS running outside this server. Any reasons for this? Known work around? This is what the end of the install script shows: trying https://ourdomain/ipa/json Forwarding 'schema' to json server 'https://ourdomain/ipa/json' Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 3138, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 3119, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 2828, 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 426, in _fetch schema = client.forward(u'schema', **kwargs)['result'] File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1000, in forward raise NetworkError(uri=server, error=str(e)) ipalib.errors.NetworkError: cannot connect to 'https://ourdomain/ipa/json': Could not connect to ourdomain using any address: (PR_ADDRESS_NOT_SUPPORTED_ERROR) Network address type not supported. ipa.ipapython.install.cli.install_tool(Server): ERROR Configuration of client side components failed! ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Nov 28 20:43:44 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Nov 2016 15:43:44 -0500 Subject: [Freeipa-users] Fedora 25 install error PR_ADDRESS_NOT_SUPPORTED_ERROR Network address type not supported In-Reply-To: <31CE8274-3A18-4B57-B98B-FC327F9987BE@fordham.edu> References: <31CE8274-3A18-4B57-B98B-FC327F9987BE@fordham.edu> Message-ID: <583C9700.4040201@redhat.com> Robert Kudyba wrote: > This is a new installation attempt. Apache was running but I commented > out #IncludeOptional conf.d/*.conf in the httpd.conf file. We also have > DNS running outside this server. Any reasons for this? Known work > around? This is what the end of the install script shows: You disabled the IPA web framework by commenting out the includes. rob > > trying https://ourdomain/ipa/json > Forwarding 'schema' to json server 'https://ourdomain/ipa/json' > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 3138, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 3119, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 2828, 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 426, in _fetch > schema = client.forward(u'schema', **kwargs)['result'] > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1000, in > forward > raise NetworkError(uri=server, error=str(e)) > ipalib.errors.NetworkError: cannot connect to > 'https://ourdomain/ipa/json': Could not connect to ourdomain using any > address: (PR_ADDRESS_NOT_SUPPORTED_ERROR) Network address type not > supported. > ipa.ipapython.install.cli.install_tool(Server): ERROR Configuration > of client side components failed! > ipa.ipapython.install.cli.install_tool(Server): ERROR The > ipa-server-install command failed. > > From rkudyba at fordham.edu Mon Nov 28 20:50:28 2016 From: rkudyba at fordham.edu (Robert Kudyba) Date: Mon, 28 Nov 2016 15:50:28 -0500 Subject: [Freeipa-users] Fedora 25 install error PR_ADDRESS_NOT_SUPPORTED_ERROR Network address type not supported In-Reply-To: <583C9700.4040201@redhat.com> References: <31CE8274-3A18-4B57-B98B-FC327F9987BE@fordham.edu> <583C9700.4040201@redhat.com> Message-ID: OK that?s because I got this error: Apache is already configured with a listener on port 443: *:443 ourdomain (/etc/httpd/conf.d/ssl.conf:56) What?s the best practice here? Comment out line 56? > On Nov 28, 2016, at 3:43 PM, Rob Crittenden wrote: > > Robert Kudyba wrote: >> This is a new installation attempt. Apache was running but I commented >> out #IncludeOptional conf.d/*.conf in the httpd.conf file. We also have >> DNS running outside this server. Any reasons for this? Known work >> around? This is what the end of the install script shows: > > You disabled the IPA web framework by commenting out the includes. > > rob > >> >> trying https://urldefense.proofpoint.com/v2/url?u=https-3A__ourdomain_ipa_json&d=DgICAw&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=JYfpTfJLQ2tucNaB1dYOh7KiTqCXl2oUTVcz8N5M9QI&s=oirPn2kEpdqJ2f4kKjWNdTFZpUZ79rd2e1BDI5BvK8g&e= >> Forwarding 'schema' to json server 'https://urldefense.proofpoint.com/v2/url?u=https-3A__ourdomain_ipa_json&d=DgICAw&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=JYfpTfJLQ2tucNaB1dYOh7KiTqCXl2oUTVcz8N5M9QI&s=oirPn2kEpdqJ2f4kKjWNdTFZpUZ79rd2e1BDI5BvK8g&e= ' >> Traceback (most recent call last): >> File "/usr/sbin/ipa-client-install", line 3138, in >> sys.exit(main()) >> File "/usr/sbin/ipa-client-install", line 3119, in main >> rval = install(options, env, fstore, statestore) >> File "/usr/sbin/ipa-client-install", line 2828, 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 426, in _fetch >> schema = client.forward(u'schema', **kwargs)['result'] >> File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1000, in >> forward >> raise NetworkError(uri=server, error=str(e)) >> ipalib.errors.NetworkError: cannot connect to >> 'https://urldefense.proofpoint.com/v2/url?u=https-3A__ourdomain_ipa_json-27-3A&d=DgICAw&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=JYfpTfJLQ2tucNaB1dYOh7KiTqCXl2oUTVcz8N5M9QI&s=9Yr-BQxeooBAJqbH13XubUi-EjMipmNnHgO6zFhYBiU&e= Could not connect to ourdomain using any >> address: (PR_ADDRESS_NOT_SUPPORTED_ERROR) Network address type not >> supported. >> ipa.ipapython.install.cli.install_tool(Server): ERROR Configuration >> of client side components failed! >> ipa.ipapython.install.cli.install_tool(Server): ERROR The >> ipa-server-install command failed. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Nov 28 21:17:20 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 28 Nov 2016 16:17:20 -0500 Subject: [Freeipa-users] Clonning VM In-Reply-To: References: Message-ID: <1480367840.4311.22.camel@redhat.com> On Mon, 2016-11-28 at 13:10 -0300, Esdras La-Roque wrote: > Hi Guys, > > What's the safe method to clone an virtual machine that is in IPA ? > > I tried do this already, but I had many troubles related with IPA to fix. Unjoin the client before you clone (ipa-client-install --uninstall) and then re-join after. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Nov 28 21:32:21 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Nov 2016 16:32:21 -0500 Subject: [Freeipa-users] Fedora 25 install error PR_ADDRESS_NOT_SUPPORTED_ERROR Network address type not supported In-Reply-To: References: <31CE8274-3A18-4B57-B98B-FC327F9987BE@fordham.edu> <583C9700.4040201@redhat.com> Message-ID: <583CA265.7030001@redhat.com> Robert Kudyba wrote: > OK that?s because I got this error: > > > Apache is already configured with a listener on port 443: > *:443 ourdomain (/etc/httpd/conf.d/ssl.conf:56) > > > What?s the best practice here? Comment out line 56? Only one SSL provider can own a given port. mod_nss and mod_ssl can co-exist ok but one may own port 443. Your best bet is to remove the mod_ssl package. rob > >> On Nov 28, 2016, at 3:43 PM, Rob Crittenden > > wrote: >> >> Robert Kudyba wrote: >>> This is a new installation attempt. Apache was running but I commented >>> out #IncludeOptional conf.d/*.conf in the httpd.conf file. We also have >>> DNS running outside this server. Any reasons for this? Known work >>> around? This is what the end of the install script shows: >> >> You disabled the IPA web framework by commenting out the includes. >> >> rob >> >>> >>> trying >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__ourdomain_ipa_json&d=DgICAw&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=JYfpTfJLQ2tucNaB1dYOh7KiTqCXl2oUTVcz8N5M9QI&s=oirPn2kEpdqJ2f4kKjWNdTFZpUZ79rd2e1BDI5BvK8g&e= >>> >>> Forwarding 'schema' to json server >>> 'https://urldefense.proofpoint.com/v2/url?u=https-3A__ourdomain_ipa_json&d=DgICAw&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=JYfpTfJLQ2tucNaB1dYOh7KiTqCXl2oUTVcz8N5M9QI&s=oirPn2kEpdqJ2f4kKjWNdTFZpUZ79rd2e1BDI5BvK8g&e= >>> ' >>> Traceback (most recent call last): >>> File "/usr/sbin/ipa-client-install", line 3138, in >>> sys.exit(main()) >>> File "/usr/sbin/ipa-client-install", line 3119, in main >>> rval = install(options, env, fstore, statestore) >>> File "/usr/sbin/ipa-client-install", line 2828, 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 426, in _fetch >>> schema = client.forward(u'schema', **kwargs)['result'] >>> File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 1000, in >>> forward >>> raise NetworkError(uri=server, error=str(e)) >>> ipalib.errors.NetworkError: cannot connect to >>> 'https://urldefense.proofpoint.com/v2/url?u=https-3A__ourdomain_ipa_json-27-3A&d=DgICAw&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=JYfpTfJLQ2tucNaB1dYOh7KiTqCXl2oUTVcz8N5M9QI&s=9Yr-BQxeooBAJqbH13XubUi-EjMipmNnHgO6zFhYBiU&e= >>> Could not connect to ourdomain using any >>> address: (PR_ADDRESS_NOT_SUPPORTED_ERROR) Network address type not >>> supported. >>> ipa.ipapython.install.cli.install_tool(Server): ERROR Configuration >>> of client side components failed! >>> ipa.ipapython.install.cli.install_tool(Server): ERROR The >>> ipa-server-install command failed. >>> >>> >> > From esdras.laroque at gmail.com Mon Nov 28 21:49:51 2016 From: esdras.laroque at gmail.com (Esdras La-Roque) Date: Mon, 28 Nov 2016 18:49:51 -0300 Subject: [Freeipa-users] Clonning VM In-Reply-To: <1480367840.4311.22.camel@redhat.com> References: <1480367840.4311.22.camel@redhat.com> Message-ID: This will be help me. Thanks Simo. 2016-11-28 18:17 GMT-03:00 Simo Sorce : > On Mon, 2016-11-28 at 13:10 -0300, Esdras La-Roque wrote: > > Hi Guys, > > > > What's the safe method to clone an virtual machine that is in IPA ? > > > > I tried do this already, but I had many troubles related with IPA to fix. > > Unjoin the client before you clone (ipa-client-install --uninstall) and > then re-join after. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- *Esdras La-Roque* Analista e Desenvolvedor de Sistemas Mestrando em Ci?ncia da Computa??o LPI-1 | Linux Professional Institute - N?vel 1 MCITP | Microsoft Virtualization Administrator NCLA | Novell Certified Linux Administrator DCTS | Data Center Technical Specialist -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.plemmons at crosschx.com Mon Nov 28 22:18:52 2016 From: michael.plemmons at crosschx.com (Michael Plemmons) Date: Mon, 28 Nov 2016 17:18:52 -0500 Subject: [Freeipa-users] Host with Multiple hostnames In-Reply-To: References: Message-ID: The error is telling you that a DNS entry already exists for the hostname you want the CNAME. A DNS record can only have one record type. Meaning is you have 1.2.3.4 points to test.example.com you cannot have test.example.com also be a CNAME for foo.example.com. *Mike Plemmons | Senior DevOps Engineer* 614-741-5475 mike.plemmons at crosschx.com www.crosschx.com On Mon, Nov 28, 2016 at 1:02 PM, Mike Jacobacci wrote: > Hello, > > I am sorry for the simple question, but I am using FreeIPA as our DNS > server and I am trying to figure out how to map a second hostname to a > host... I am unsure how the best way to go do it. I am just trying to > give a server a user friendly name for access and I don't want to change > the system hostname. > > I thought I could just add a CNAME entry for the host record, but it fails > with the following error: > > invalid 'cnamerecord': CNAME record is not allowed to coexist with any > other record (RFC 1034, section 3.6.2) > > Is there an easy way I can do this? > > Cheers, > Mike > > > > -- > 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 mike.driscoll at oracle.com Mon Nov 28 22:44:10 2016 From: mike.driscoll at oracle.com (Mike Driscoll) Date: Mon, 28 Nov 2016 14:44:10 -0800 Subject: [Freeipa-users] DNS search timeouts and incomplete results Message-ID: <65B5DD10-9792-44C7-BD17-E3A45BDDE2FD@oracle.com> I'm running: # rpm -qa | grep ipa-server ipa-server-4.4.0-12.0.1.el7.x86_64 ipa-server-dns-4.4.0-12.0.1.el7.noarch ipa-server-common-4.4.0-12.0.1.el7.noarch Searching DNS for all hostnames containing "qa" times out in the GUI. Setting aside the option to change server defaults, this cli command isn't giving me the content I need: # ipa dnsrecord-find mydomain.com --sizelimit=10000 --timelimit=20 | grep qa ipa: WARNING: Search result has been truncated: Configured size limit exceeded It seems like the sizelimit parameter greater than two thousand is being ignored: # ipa dnsrecord-find mydomain.com --sizelimit=1900 --timelimit=20 ... ------------------------------- Number of entries returned 1900 ------------------------------- # ipa dnsrecord-find mydomain.com --sizelimit=2100 --timelimit=20 ... ------------------------------- Number of entries returned 2000 ------------------------------- Any suggestions? Mike From splash at gmail.com Mon Nov 28 23:11:34 2016 From: splash at gmail.com (Diogenes S. Jesus) Date: Tue, 29 Nov 2016 00:11:34 +0100 Subject: [Freeipa-users] How to enable anonymous pkinit on FreeIPA 4.3.1 on Ubuntu ? Message-ID: I've got one freeipa instance for testing purposes and I'm trying to enable anonymous pkinit support on it[1], as Simon mentioned being possible :) [2] For debug purposes, I have done: /etc/kdc.conf --------------- [kdcdefaults] kdc_ports = 88 kdc_tcp_ports = 88 restrict_anonymous_to_tgt = true [realms] REALM.EU = { master_key_type = aes256-cts max_life = 7d max_renewable_life = 14d acl_file = /etc/krb5kdc/kadm5.acl dict_file = /usr/share/dict/words default_principal_flags = +preauth admin_keytab = /etc/krb5kdc/kadm5.keytab pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem pkinit_eku_checking = none } The user krb5.conf file: [realms] REALM.EU = { master_kdc = kdc.realm.eu admin_server = kdc.realm.eu pkinit_anchors = /usr/local/share/ca-certificates/root-ca.crt } Openssl is able to verify the certificate: root at ipa01:~# openssl verify -verbose -CAfile /usr/local/share/ca-certificates/root-ca.crt /var/lib/krb5kdc/kdc.pem /var/lib/krb5kdc/kdc.pem: OK The KDC certificate was created based on MIT Kerberos guidelines[3] The anonymous user (created manually first with "-rankey"), resulting in the following user-side messages: root at ubuntu:~# KRB5_TRACE=/dev/stdout kinit -n [11573] 1480374327.337803: Getting initial credentials for WELLKNOWN/ANONYMOUS at REALM.EU [11573] 1480374327.340203: Sending request (178 bytes) to REALM.EU [11573] 1480374327.443449: Retrying AS request with master KDC [11573] 1480374327.443939: Getting initial credentials for WELLKNOWN/ANONYMOUS at REALM.EU [11573] 1480374327.444784: Sending request (178 bytes) to REALM.EU (master) [11573] 1480374327.445357: Resolving hostname kdc.bdc1.hu.sec.in.realm.eu [11573] 1480374327.471043: Sending initial UDP request to dgram 10.235.2.25:88 [11573] 1480374328.472199: Resolving hostname kdc.bdc1.hu.sec.in.realm.eu [11573] 1480374328.498175: Sending initial UDP request to dgram 10.235.2.25:750 [11573] 1480374329.500579: Initiating TCP connection to stream 10.235.2.25:88 [11573] 1480374329.527259: Sending TCP request to stream 10.235.2.25:88 [11573] 1480374329.557528: Received answer (459 bytes) from stream 10.235.2.25:88 [11573] 1480374329.558323: Received error from KDC: -1765328359/Additional pre-authentication required [11573] 1480374329.558767: Processing preauth types: 16, 15, 14, 136, 19, 147, 2, 133 [11573] 1480374329.558976: Selected etype info: etype aes256-cts, salt "REALM.EUWELLKNOWNANONYMOUS", params "" [11573] 1480374329.559480: Received cookie: MIT [11573] 1480374329.559532: Preauth module pkinit (147) (info) returned: 0/Success [11573] 1480374329.559627: PKINIT client has no configured identity; giving up [11573] 1480374329.559651: Preauth module pkinit (16) (real) returned: 22/Invalid argument [11573] 1480374329.559669: PKINIT client has no configured identity; giving up [11573] 1480374329.559680: Preauth module pkinit (14) (real) returned: 22/Invalid argument [11573] 1480374329.559696: PKINIT client has no configured identity; giving up [11573] 1480374329.559707: Preauth module pkinit (14) (real) returned: 22/Invalid argument Password for WELLKNOWN/ANONYMOUS at REALM.EU: Then removed the anonymous user keys: root at ipa01:~# kadmin.local -x ipa-setup-override-restrictions -q 'purgekeys -all WELLKNOWN/ANONYMOUS' On the client side: root at ubuntu:~# KRB5_TRACE=/dev/stdout kinit -n [10593] 1480350802.381306: Getting initial credentials for WELLKNOWN/ANONYMOUS at REALM.EU [10593] 1480350802.384075: Sending request (178 bytes) to REALM.EU [10593] 1480350802.433623: Retrying AS request with master KDC [10593] 1480350802.434688: Getting initial credentials for WELLKNOWN/ANONYMOUS at REALM.EU [10593] 1480350802.435476: Sending request (178 bytes) to REALM.EU (master) [10593] 1480350802.436191: Resolving hostname kdc.domain.eu [10593] 1480350802.462072: Sending initial UDP request to dgram 10.235.2.25:88 [10593] 1480350803.465087: Resolving hostname kdc.domain.eu [10593] 1480350803.489656: Sending initial UDP request to dgram 10.235.2.25:750 [10593] 1480350804.491058: Initiating TCP connection to stream 10.235.2.25:88 [10593] 1480350804.515736: Sending TCP request to stream 10.235.2.25:88 [10593] 1480350804.547579: Received answer (269 bytes) from stream 10.235.2.25:88 [10593] 1480350804.547663: Received error from KDC: -1765328359/Additional pre-authentication required [10593] 1480350804.547708: Processing preauth types: 16, 15, 14, 136, 147, 133 [10593] 1480350804.547713: Received cookie: MIT [10593] 1480350804.547744: Preauth module pkinit (147) (info) returned: 0/Success [10593] 1480350804.547758: PKINIT client has no configured identity; giving up [10593] 1480350804.547765: Preauth module pkinit (16) (real) returned: 22/Invalid argument [10593] 1480350804.547776: PKINIT client has no configured identity; giving up [10593] 1480350804.547782: Preauth module pkinit (14) (real) returned: 22/Invalid argument [10593] 1480350804.547793: PKINIT client has no configured identity; giving up [10593] 1480350804.547798: Preauth module pkinit (14) (real) returned: 22/Invalid argument kinit: Invalid argument while getting initial credentials root at ubuntu:~# I've also done: root at ipa01:~# kadmin.local -x ipa-setup-override-restrictions -q 'modprinc -requires_preauth WELLKNOWN/ANONYMOUS' , but the user-side messages are the same. I've checked the KDC fqdn matches the CN in kdc.pem. I've tried creating the anonymous user without a key (-nokey) but FreeIPA clearly has issues with that: kadmin.local: add_principal +requires_preauth -nokey WELLKNOWN/ANONYMOUS WARNING: no policy specified for WELLKNOWN/ANONYMOUS at PAN-NET.EU; defaulting to no policy add_principal: Server error while creating "WELLKNOWN/ANONYMOUS at PAN-NET.EU". kadmin.local: I've also tried all the above when the user's krb5.conf "realm" section was set with the following options pkinit_eku_checking = kpServerAuth pkinit_kdc_hostname = kdc.realm.eu , but that didn't help either. Any thoughts would be appreciated. Thanks in advance [1] https://fedorahosted.org/freeipa/ticket/5678 [2] https://github.com/freeipa/freeipa/pull/62#issuecomment-261950279 [3] https://web.mit.edu/kerberos/krb5-1.13/doc/admin/pkinit.html -- -------- Diogenes S. de Jesus From tkrizek at redhat.com Tue Nov 29 08:15:59 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Tue, 29 Nov 2016 09:15:59 +0100 Subject: [Freeipa-users] DNS search timeouts and incomplete results In-Reply-To: <65B5DD10-9792-44C7-BD17-E3A45BDDE2FD@oracle.com> References: <65B5DD10-9792-44C7-BD17-E3A45BDDE2FD@oracle.com> Message-ID: <16a478e8-fe1c-c183-bf91-f895fdcbd79d@redhat.com> On 11/28/2016 11:44 PM, Mike Driscoll wrote: > I'm running: > # rpm -qa | grep ipa-server > ipa-server-4.4.0-12.0.1.el7.x86_64 > ipa-server-dns-4.4.0-12.0.1.el7.noarch > ipa-server-common-4.4.0-12.0.1.el7.noarch > > Searching DNS for all hostnames containing "qa" times out in the GUI. Setting aside the option to change server defaults, this cli command isn't giving me the content I need: > > # ipa dnsrecord-find mydomain.com --sizelimit=10000 --timelimit=20 | grep qa > ipa: WARNING: Search result has been truncated: Configured size limit exceeded > > It seems like the sizelimit parameter greater than two thousand is being ignored: > > # ipa dnsrecord-find mydomain.com --sizelimit=1900 --timelimit=20 > ... > ------------------------------- > Number of entries returned 1900 > ------------------------------- > > # ipa dnsrecord-find mydomain.com --sizelimit=2100 --timelimit=20 > ... > ------------------------------- > Number of entries returned 2000 > ------------------------------- > > Any suggestions? > > Mike > Hi, you seem to be hitting the size limit on LDAP side. To verify, check ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep nsslapd-sizelimit If you really need to increase this size limit, you will have to modify the nsslapd-sizelimit in cn=config. -- Tomas Krizek From mukarram.syed at 8x8.com Tue Nov 29 07:31:22 2016 From: mukarram.syed at 8x8.com (Mukarram Syed) Date: Mon, 28 Nov 2016 23:31:22 -0800 Subject: [Freeipa-users] Request to help adding FreeIPA group to VMware VCenter6.0 Message-ID: Hi, In VCenter 6.0 Web Appliance, I would like to add the Admin group of users in FreeIPA. I looked through many articles on the internet and found recommended solutions, but none seem to work for me. Basically, I have group of "admins" in FreeIPA. In VCenter I Name: *IPA* Base DN for users: *cn=users,cn=accounts,dc=dev,dc=local* Domain Name: *dev.local* Base DN for groups: *cn=admins*,*cn=groups,cn=accounts,dc=dev,dc=local* Primary Server URL: *ldap://freeipa1.dev.local* Username: *uid=admin,cn=users,cn=accounts,dc=dev,dc=local* In doing this, I get all the users. But I want only the users in the group "admins", which I am not able to accomplish. On Base DN for groups i tried using *(|memberOf=* *cn=admins,cn=groups,cn=accounts,dc=dev,dc=local)* But Vcenter does not seem to accept "memberOf" in the Base DN for groups. I have successfully used "memberOf" in other LDAP environments. Any help/suggestions are appreciated. Thanks # mukarram -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.blenkins at 8x8.com Tue Nov 29 09:44:53 2016 From: jim.blenkins at 8x8.com (Jim Blenkins) Date: Tue, 29 Nov 2016 09:44:53 +0000 Subject: [Freeipa-users] Request to help adding FreeIPA group to VMware VCenter6.0 In-Reply-To: References: Message-ID: Muk Look at how we have done we basically used a system account sudo and gave rhis user a password this means all freeipa users can login but cant see anything until individual privileges are assigned inside vmware Jim On 29 Nov 2016 9:40 a.m., "Mukarram Syed" wrote: > Hi, > > In VCenter 6.0 Web Appliance, I would like to add the Admin group of > users in FreeIPA. > I looked through many articles on the internet and found recommended > solutions, but none seem to work for me. > Basically, I have group of "admins" in FreeIPA. > In VCenter I > > Name: *IPA* > > Base DN for users: *cn=users,cn=accounts,dc=dev,dc=local* > > Domain Name: *dev.local* > > Base DN for groups: *cn=admins*,*cn=groups,cn=accounts,dc=dev,dc=local* > > Primary Server URL: *ldap://freeipa1.dev.local* > > Username: *uid=admin,cn=users,cn=accounts,dc=dev,dc=local* > In doing this, I get all the users. But I want only the users in the > group "admins", which I am not able to accomplish. > > On Base DN for groups i tried using *(|memberOf=* > *cn=admins,cn=groups,cn=accounts,dc=dev,dc=local)* > But Vcenter does not seem to accept "memberOf" in the Base DN for groups. > I have successfully used "memberOf" in other LDAP environments. > > Any help/suggestions are appreciated. > > Thanks > > # mukarram > > -- > 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 tkrizek at redhat.com Tue Nov 29 09:50:10 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Tue, 29 Nov 2016 10:50:10 +0100 Subject: [Freeipa-users] new install on Fedora 24 kinit: Generic preauthentication failure while getting initial credentials In-Reply-To: <60257124-FA5E-4972-889E-0441005D111A@fordham.edu> References: <60257124-FA5E-4972-889E-0441005D111A@fordham.edu> Message-ID: On 11/28/2016 05:38 PM, Robert Kudyba wrote: > There seems to be a problem either with Kerberos and/or using a self > signed certificate vs. Let?s Encrypt. I tried to run the set up script > from https://github.com/freeipa/freeipa-letsencrypt and below are some > errors and logs. > > Within the /etc/httpd/conf.d/ipa.conffile I commented out > these directives as I had some Apache redirects that were breaking: > > #WSGIDaemonProcess ipa processes=2 threads=1 maximum-requests=500 \ > display-name=%{GROUP} socket-timeout=2147483647 > #WSGIImportScript /usr/share/ipa/wsgi.py process-group=ipa > application-group=ipa > #WSGIScriptAlias /ipa /usr/share/ipa/wsgi.py > #WSGIScriptReloading Off > > ./setup-le.sh > Last metadata expiration check: 0:24:16 ago on Mon Nov 28 10:40:45 2016. > Package certbot-0.9.3-1.fc25.noarch is already installed, skipping. > Dependencies resolved. > Nothing to do. > Complete! > Installing CA certificate, please wait > Not a valid CA certificate: (SEC_ERROR_UNTRUSTED_ISSUER) Peer's > certificate issuer has been marked as not trusted by the user. (visit > http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) > The ipa-cacert-manage command failed. > > ipactl status > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > ipa_memcached Service: RUNNING > ipa-custodia Service: RUNNING > ntpd Service: RUNNING > pki-tomcatd Service: RUNNING > ipa-otpd Service: RUNNING > ipa: INFO: The ipactl command was successful > > kinit admin > kinit: Generic preauthentication failure while getting initial credentials > > journalctl -u named-pkcs11 > -- No entries ? > > journalctl -u named > -- No entries ? > > file /var/named/data/named.run > /var/named/data/named.run: cannot open `/var/named/data/named.run' (No > such file or directory) > > ldapsearch -Y GSSAPI > '(&(ipaConfigString=enabledService)(ipaConfigString=dnssecKeyMaster))' > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (No Kerberos > credentials available (default cache: KEYRING:persistent:0)) > > ipa help krbtpolicy > ipa: ERROR: did not receive Kerberos credentials > > In /var/log/krb5kdc.log: > > Nov 28 05:19:49 krb5kdc[19575](info): closing down fd 11 > Nov 28 11:04:40 krb5kdc[19575](info): AS_REQ (6 etypes {18 17 16 23 25 > 26}) ip: NEEDED_PREAUTH: admin at for krbtgt/ourdomain@ ourdomain, > Additional pre-authentication required > Nov 28 11:04:40 krb5kdc[19575](info): closing down fd 11 > Nov 28 11:15:35 krb5kdc[19573](info): AS_REQ (6 etypes {18 17 16 23 25 > 26}) ip: NEEDED_PREAUTH: admin at for krbtgt/ourdomain@ ourdomain, > Additional pre-authentication required > Nov 28 11:15:35 krb5kdc[19573](info): closing down fd 11 > > > Hi, you're hitting an issue with Let's Encrypt setup. https://github.com/freeipa/freeipa-letsencrypt/issues/1 unfortunately, I'm not aware of any workaround or solution as of now. -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Nov 29 10:04:47 2016 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Nov 2016 05:04:47 -0500 Subject: [Freeipa-users] How to enable anonymous pkinit on FreeIPA 4.3.1 on Ubuntu ? In-Reply-To: References: Message-ID: <1480413887.4311.32.camel@redhat.com> On Tue, 2016-11-29 at 00:11 +0100, Diogenes S. Jesus wrote: > I've got one freeipa instance for testing purposes and I'm trying to > enable anonymous pkinit support on it[1], as Simon mentioned being > possible :) [2] > > For debug purposes, I have done: > > /etc/kdc.conf > --------------- > [kdcdefaults] > kdc_ports = 88 > kdc_tcp_ports = 88 > restrict_anonymous_to_tgt = true > > [realms] > REALM.EU = { > master_key_type = aes256-cts > max_life = 7d > max_renewable_life = 14d > acl_file = /etc/krb5kdc/kadm5.acl > dict_file = /usr/share/dict/words > default_principal_flags = +preauth > admin_keytab = /etc/krb5kdc/kadm5.keytab > pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem > pkinit_eku_checking = none > } > > The user krb5.conf file: > [realms] > REALM.EU = { > master_kdc = kdc.realm.eu > admin_server = kdc.realm.eu > pkinit_anchors = /usr/local/share/ca-certificates/root-ca.crt > } > > > Openssl is able to verify the certificate: > root at ipa01:~# openssl verify -verbose -CAfile > /usr/local/share/ca-certificates/root-ca.crt /var/lib/krb5kdc/kdc.pem > /var/lib/krb5kdc/kdc.pem: OK > > The KDC certificate was created based on MIT Kerberos guidelines[3] > > The anonymous user (created manually first with "-rankey"), resulting > in the following user-side messages: > root at ubuntu:~# KRB5_TRACE=/dev/stdout kinit -n > [11573] 1480374327.337803: Getting initial credentials for > WELLKNOWN/ANONYMOUS at REALM.EU > [11573] 1480374327.340203: Sending request (178 bytes) to REALM.EU > [11573] 1480374327.443449: Retrying AS request with master KDC > [11573] 1480374327.443939: Getting initial credentials for > WELLKNOWN/ANONYMOUS at REALM.EU > [11573] 1480374327.444784: Sending request (178 bytes) to REALM.EU (master) > [11573] 1480374327.445357: Resolving hostname kdc.bdc1.hu.sec.in.realm.eu > [11573] 1480374327.471043: Sending initial UDP request to dgram 10.235.2.25:88 > [11573] 1480374328.472199: Resolving hostname kdc.bdc1.hu.sec.in.realm.eu > [11573] 1480374328.498175: Sending initial UDP request to dgram 10.235.2.25:750 > [11573] 1480374329.500579: Initiating TCP connection to stream 10.235.2.25:88 > [11573] 1480374329.527259: Sending TCP request to stream 10.235.2.25:88 > [11573] 1480374329.557528: Received answer (459 bytes) from stream > 10.235.2.25:88 > [11573] 1480374329.558323: Received error from KDC: > -1765328359/Additional pre-authentication required > [11573] 1480374329.558767: Processing preauth types: 16, 15, 14, 136, > 19, 147, 2, 133 > [11573] 1480374329.558976: Selected etype info: etype aes256-cts, salt > "REALM.EUWELLKNOWNANONYMOUS", params "" > [11573] 1480374329.559480: Received cookie: MIT > [11573] 1480374329.559532: Preauth module pkinit (147) (info) > returned: 0/Success > [11573] 1480374329.559627: PKINIT client has no configured identity; giving up > [11573] 1480374329.559651: Preauth module pkinit (16) (real) returned: > 22/Invalid argument > [11573] 1480374329.559669: PKINIT client has no configured identity; giving up > [11573] 1480374329.559680: Preauth module pkinit (14) (real) returned: > 22/Invalid argument > [11573] 1480374329.559696: PKINIT client has no configured identity; giving up > [11573] 1480374329.559707: Preauth module pkinit (14) (real) returned: > 22/Invalid argument > Password for WELLKNOWN/ANONYMOUS at REALM.EU: > > > Then removed the anonymous user keys: > root at ipa01:~# kadmin.local -x ipa-setup-override-restrictions -q > 'purgekeys -all WELLKNOWN/ANONYMOUS' This is not necessary and won't make any difference. > On the client side: > > root at ubuntu:~# KRB5_TRACE=/dev/stdout kinit -n > [10593] 1480350802.381306: Getting initial credentials for > WELLKNOWN/ANONYMOUS at REALM.EU > [10593] 1480350802.384075: Sending request (178 bytes) to REALM.EU > [10593] 1480350802.433623: Retrying AS request with master KDC > [10593] 1480350802.434688: Getting initial credentials for > WELLKNOWN/ANONYMOUS at REALM.EU > [10593] 1480350802.435476: Sending request (178 bytes) to REALM.EU (master) > [10593] 1480350802.436191: Resolving hostname kdc.domain.eu > [10593] 1480350802.462072: Sending initial UDP request to dgram 10.235.2.25:88 > [10593] 1480350803.465087: Resolving hostname kdc.domain.eu > [10593] 1480350803.489656: Sending initial UDP request to dgram 10.235.2.25:750 > [10593] 1480350804.491058: Initiating TCP connection to stream 10.235.2.25:88 > [10593] 1480350804.515736: Sending TCP request to stream 10.235.2.25:88 > [10593] 1480350804.547579: Received answer (269 bytes) from stream > 10.235.2.25:88 > [10593] 1480350804.547663: Received error from KDC: > -1765328359/Additional pre-authentication required > [10593] 1480350804.547708: Processing preauth types: 16, 15, 14, 136, 147, 133 > [10593] 1480350804.547713: Received cookie: MIT > [10593] 1480350804.547744: Preauth module pkinit (147) (info) > returned: 0/Success This means the client correctly selects Pkinit authentication. > [10593] 1480350804.547758: PKINIT client has no configured identity; giving up However this says the client has some issues getting a ticket for the anonymous principal as it is looking for some local cert to use. Can you please provide the matching KDC logs you find in /var/log/kerberos/krb5kdc.log ? > [10593] 1480350804.547765: Preauth module pkinit (16) (real) returned: > 22/Invalid argument > [10593] 1480350804.547776: PKINIT client has no configured identity; giving up > [10593] 1480350804.547782: Preauth module pkinit (14) (real) returned: > 22/Invalid argument > [10593] 1480350804.547793: PKINIT client has no configured identity; giving up > [10593] 1480350804.547798: Preauth module pkinit (14) (real) returned: > 22/Invalid argument > kinit: Invalid argument while getting initial credentials > root at ubuntu:~# > > I've also done: > > root at ipa01:~# kadmin.local -x ipa-setup-override-restrictions -q > 'modprinc -requires_preauth WELLKNOWN/ANONYMOUS' This is incorrect, pkinit is a pre-authentication mechanism. > , but the user-side messages are the same. > > > I've checked the KDC fqdn matches the CN in kdc.pem. > > I've tried creating the anonymous user without a key (-nokey) but > FreeIPA clearly has issues with that: > > kadmin.local: add_principal +requires_preauth -nokey WELLKNOWN/ANONYMOUS > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at PAN-NET.EU; > defaulting to no policy > add_principal: Server error while creating "WELLKNOWN/ANONYMOUS at PAN-NET.EU". > kadmin.local: Whether the principal has keys or not doesn't matter, pkinit pre-authentication ignores the keys anyway. > I've also tried all the above when the user's krb5.conf "realm" > section was set with the following options > pkinit_eku_checking = kpServerAuth > pkinit_kdc_hostname = kdc.realm.eu > > , but that didn't help either. > > Any thoughts would be appreciated. KDC logs may shed some light. > Thanks in advance > > [1] https://fedorahosted.org/freeipa/ticket/5678 > [2] https://github.com/freeipa/freeipa/pull/62#issuecomment-261950279 > [3] https://web.mit.edu/kerberos/krb5-1.13/doc/admin/pkinit.html > -- > > -------- > > Diogenes S. de Jesus > -- Simo Sorce * Red Hat, Inc * New York From david.dejaeghere at gmail.com Tue Nov 29 10:51:49 2016 From: david.dejaeghere at gmail.com (David Dejaeghere) Date: Tue, 29 Nov 2016 11:51:49 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process Message-ID: Hi, I have a setup where i want to add a replica. The first master setup has an externally signed cert for dirsrv and httpd. The replica is prepapred succesfully with ipa-client-install but the replica install then keeps failing. It seems that during install dirserv is not configured correctly with a valid server certificate. Output from the dirsrv error added to this email as well. [root at ns02 ~]# ipa-replica-install --setup-ca WARNING: conflicting time&date synchronization service 'chronyd' will be disabled in favor of ntpd Run connection check to master Connection check OK 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/43]: creating directory server user [2/43]: creating directory server instance [3/43]: restarting directory server [4/43]: adding default schema [5/43]: enabling memberof plugin [6/43]: enabling winsync plugin [7/43]: configuring replication version plugin [8/43]: enabling IPA enrollment plugin [9/43]: enabling ldapi [10/43]: configuring uniqueness plugin [11/43]: configuring uuid plugin [12/43]: configuring modrdn plugin [13/43]: configuring DNS plugin [14/43]: enabling entryUSN plugin [15/43]: configuring lockout plugin [16/43]: configuring topology plugin [17/43]: creating indices [18/43]: enabling referential integrity plugin [19/43]: configuring certmap.conf [20/43]: configure autobind for root [21/43]: configure new location for managed entries [22/43]: configure dirsrv ccache [23/43]: enabling SASL mapping fallback [24/43]: restarting directory server [25/43]: creating DS keytab [26/43]: retrieving DS Certificate [27/43]: restarting directory server ipa : CRITICAL Failed to restart the directory server (Command '/bin/systemctl restart dirsrv at SOMETHING-BE.service' returned non-zero exit status 1). See the installation log for details. [28/43]: setting up initial replication [error] error: [Errno 111] Connection refused Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security Initialization: Can't find certificate (Server-Cert) for family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - security library: bad database.) [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security Initialization: Unable to retrieve private key for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - security library: bad database.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Tue Nov 29 11:09:20 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 29 Nov 2016 12:09:20 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process In-Reply-To: References: Message-ID: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> On 29/11/16 11:51, David Dejaeghere wrote: > Hi, > > I have a setup where i want to add a replica. The first master setup has > an externally signed cert for dirsrv and httpd. The replica is prepapred > succesfully with ipa-client-install but the replica install then keeps > failing. It seems that during install dirserv is not configured correctly > with a valid server certificate. Output from the dirsrv error added to this > email as well. > > [root at ns02 ~]# ipa-replica-install --setup-ca > WARNING: conflicting time&date synchronization service 'chronyd' will > be disabled in favor of ntpd > > Run connection check to master > Connection check OK > 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/43]: creating directory server user > [2/43]: creating directory server instance > [3/43]: restarting directory server > [4/43]: adding default schema > [5/43]: enabling memberof plugin > [6/43]: enabling winsync plugin > [7/43]: configuring replication version plugin > [8/43]: enabling IPA enrollment plugin > [9/43]: enabling ldapi > [10/43]: configuring uniqueness plugin > [11/43]: configuring uuid plugin > [12/43]: configuring modrdn plugin > [13/43]: configuring DNS plugin > [14/43]: enabling entryUSN plugin > [15/43]: configuring lockout plugin > [16/43]: configuring topology plugin > [17/43]: creating indices > [18/43]: enabling referential integrity plugin > [19/43]: configuring certmap.conf > [20/43]: configure autobind for root > [21/43]: configure new location for managed entries > [22/43]: configure dirsrv ccache > [23/43]: enabling SASL mapping fallback > [24/43]: restarting directory server > [25/43]: creating DS keytab > [26/43]: retrieving DS Certificate > [27/43]: restarting directory server > ipa : CRITICAL Failed to restart the directory server (Command > '/bin/systemctl restart dirsrv at SOMETHING-BE.service' returned non-zero exit > status 1). See the installation log for details. > [28/43]: setting up initial replication > [error] error: [Errno 111] Connection refused > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > > [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security Initialization: > Can't find certificate (Server-Cert) for family > cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - > security library: bad database.) > [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security Initialization: > Unable to retrieve private key for cert Server-Cert of family > cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - > security library: bad database.) > > > Hello David, The error from the log indicates that either the NSSDB for dirsrv is not initialized or not accessible. Could you please send output of the following commands? # ls -lZ /etc/dirsrv/slapd-$REALM/ # certutil -d /etc/dirsrv/slapd-$REALM/ -L # ausearch -m avc -i -- David Kupka From pvoborni at redhat.com Tue Nov 29 11:10:18 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 29 Nov 2016 12:10:18 +0100 Subject: [Freeipa-users] OTP Algorithm In-Reply-To: References: Message-ID: <79cd7b7f-3fc7-84f9-4762-75cd386a0cac@redhat.com> On 11/28/2016 01:03 PM, Callum Guy wrote: > Hi All, > > I wanted to ask a quick question - perhaps a more experienced user will be able > to help or point me to the correct documentation. > > Basically we have implemented password+OTP type authentication which works great. > > When adding a OTP code using the admin login you can choose an algorithm. For us > the generated codes only work properly if the weakest sha1 algorithm is chosen/ > To be clear the code generation works fine but the codes are not valid when > logging in. Is there a related setting we must change? > > Thanks, > > Callum > What type of otp token do you use? Does it work with some different? E.g. FreeOTP vs Google Authenticator ... -- Petr Vobornik From david.dejaeghere at gmail.com Tue Nov 29 11:15:20 2016 From: david.dejaeghere at gmail.com (David Dejaeghere) Date: Tue, 29 Nov 2016 12:15:20 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process In-Reply-To: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> References: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> Message-ID: Seems like it is but it does not show a server cert for dirsrv [root at ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ total 468 -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 65536 Nov 29 11:29 cert8.db -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 65536 Nov 29 11:29 cert8.db.orig -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 1623 Nov 29 11:29 certmap.conf -rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 Nov 29 11:29 dse.ldif -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 Nov 29 11:29 dse.ldif.bak -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 Nov 29 11:29 dse.ldif.startOK -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 36228 Nov 29 11:28 dse_original.ldif -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 key3.db -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 key3.db.orig -r--------. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 66 Nov 29 11:29 pin.txt -rw-------. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 40 Nov 29 11:29 pwdfile.txt drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 4096 Nov 29 11:29 schema -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 secmod.db -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 secmod.db.orig -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 15142 Nov 29 11:28 slapd-collations.conf [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CN=something-PAPRIKA-CA,DC=something,DC=local CT,C,C SOMETHING.BE IPA CA CT,C,C [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CN=something-PAPRIKA-CA,DC=something,DC=local CT,C,C SOMETHING.BE IPA CA CT,C,C [root at ns02 ~]# ausearch -m avc -i 2016-11-29 12:09 GMT+01:00 David Kupka : > On 29/11/16 11:51, David Dejaeghere wrote: > >> Hi, >> >> I have a setup where i want to add a replica. The first master setup has >> an externally signed cert for dirsrv and httpd. The replica is prepapred >> succesfully with ipa-client-install but the replica install then keeps >> failing. It seems that during install dirserv is not configured correctly >> with a valid server certificate. Output from the dirsrv error added to >> this >> email as well. >> >> [root at ns02 ~]# ipa-replica-install --setup-ca >> WARNING: conflicting time&date synchronization service 'chronyd' will >> be disabled in favor of ntpd >> >> Run connection check to master >> Connection check OK >> 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/43]: creating directory server user >> [2/43]: creating directory server instance >> [3/43]: restarting directory server >> [4/43]: adding default schema >> [5/43]: enabling memberof plugin >> [6/43]: enabling winsync plugin >> [7/43]: configuring replication version plugin >> [8/43]: enabling IPA enrollment plugin >> [9/43]: enabling ldapi >> [10/43]: configuring uniqueness plugin >> [11/43]: configuring uuid plugin >> [12/43]: configuring modrdn plugin >> [13/43]: configuring DNS plugin >> [14/43]: enabling entryUSN plugin >> [15/43]: configuring lockout plugin >> [16/43]: configuring topology plugin >> [17/43]: creating indices >> [18/43]: enabling referential integrity plugin >> [19/43]: configuring certmap.conf >> [20/43]: configure autobind for root >> [21/43]: configure new location for managed entries >> [22/43]: configure dirsrv ccache >> [23/43]: enabling SASL mapping fallback >> [24/43]: restarting directory server >> [25/43]: creating DS keytab >> [26/43]: retrieving DS Certificate >> [27/43]: restarting directory server >> ipa : CRITICAL Failed to restart the directory server (Command >> '/bin/systemctl restart dirsrv at SOMETHING-BE.service' returned non-zero >> exit >> status 1). See the installation log for details. >> [28/43]: setting up initial replication >> [error] error: [Errno 111] Connection refused >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> >> [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security >> Initialization: >> Can't find certificate (Server-Cert) for family >> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - >> security library: bad database.) >> [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security >> Initialization: >> Unable to retrieve private key for cert Server-Cert of family >> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - >> security library: bad database.) >> >> >> >> > Hello David, > > The error from the log indicates that either the NSSDB for dirsrv is not > initialized or not accessible. > > Could you please send output of the following commands? > > # ls -lZ /etc/dirsrv/slapd-$REALM/ > # certutil -d /etc/dirsrv/slapd-$REALM/ -L > # ausearch -m avc -i > > > -- > David Kupka > -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Tue Nov 29 11:17:14 2016 From: callum.guy at x-on.co.uk (Callum Guy) Date: Tue, 29 Nov 2016 11:17:14 +0000 Subject: [Freeipa-users] OTP Algorithm In-Reply-To: <79cd7b7f-3fc7-84f9-4762-75cd386a0cac@redhat.com> References: <79cd7b7f-3fc7-84f9-4762-75cd386a0cac@redhat.com> Message-ID: Hi Petr, Thanks for coming back to me on this. I have only tried using Google Authenticator. The generated QR code successfully scans and codes are then generated on the GA device as normal. The problem is that the codes simply do not work. My current thinking is that the service which interprets the codes server-side is not configured to use the same algorithm meaning that it is trying to validate sha256/sha512 (both tested and not functional for me) etc codes against codes perhaps generated with sha1 (the only algorithm that appears to work). I apologise in advance for my naive interpretation of the situation, this really isn't an area where i have experience. I'd love to understand whats going on however I can't find what i need in the OTP documentation. Best Regards, Callum On Tue, Nov 29, 2016 at 11:10 AM Petr Vobornik wrote: > On 11/28/2016 01:03 PM, Callum Guy wrote: > > Hi All, > > > > I wanted to ask a quick question - perhaps a more experienced user will > be able > > to help or point me to the correct documentation. > > > > Basically we have implemented password+OTP type authentication which > works great. > > > > When adding a OTP code using the admin login you can choose an > algorithm. For us > > the generated codes only work properly if the weakest sha1 algorithm is > chosen/ > > To be clear the code generation works fine but the codes are not valid > when > > logging in. Is there a related setting we must change? > > > > Thanks, > > > > Callum > > > > What type of otp token do you use? Does it work with some different? > E.g. FreeOTP vs Google Authenticator ... > > > -- > Petr Vobornik > -- *0333 332 0000 | www.x-on.co.uk | ** * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Tue Nov 29 11:43:26 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 29 Nov 2016 12:43:26 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process In-Reply-To: References: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> Message-ID: <17ed1617-b686-368a-b6af-55cb39c720a0@redhat.com> On 29/11/16 12:15, David Dejaeghere wrote: > Seems like it is but it does not show a server cert for dirsrv > > [root at ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ > total 468 > -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 65536 > Nov 29 11:29 cert8.db > -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 65536 > Nov 29 11:29 cert8.db.orig > -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 1623 > Nov 29 11:29 certmap.conf > -rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 > Nov 29 11:29 dse.ldif > -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 > Nov 29 11:29 dse.ldif.bak > -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 > Nov 29 11:29 dse.ldif.startOK > -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 36228 > Nov 29 11:28 dse_original.ldif > -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 16384 > Nov 29 11:29 key3.db > -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 16384 > Nov 29 11:29 key3.db.orig > -r--------. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 66 > Nov 29 11:29 pin.txt > -rw-------. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 40 > Nov 29 11:29 pwdfile.txt > drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 4096 > Nov 29 11:29 schema > -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 16384 > Nov 29 11:29 secmod.db > -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 16384 > Nov 29 11:29 secmod.db.orig > -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 15142 > Nov 29 11:28 slapd-collations.conf > > [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > CN=something-PAPRIKA-CA,DC=something,DC=local CT,C,C > SOMETHING.BE IPA CA CT,C,C > [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > CN=something-PAPRIKA-CA,DC=something,DC=local CT,C,C > SOMETHING.BE IPA CA CT,C,C > > [root at ns02 ~]# ausearch -m avc -i > > > Exactly, the NSSDB should be accessible to dirsrv and is missing the Server-Cert but I don't understand why there's "bad database" error in the errors log. I'll try to reproduce it. What version of FreeIPA are you using? On what system? > > 2016-11-29 12:09 GMT+01:00 David Kupka : > >> On 29/11/16 11:51, David Dejaeghere wrote: >> >>> Hi, >>> >>> I have a setup where i want to add a replica. The first master setup has >>> an externally signed cert for dirsrv and httpd. The replica is prepapred >>> succesfully with ipa-client-install but the replica install then keeps >>> failing. It seems that during install dirserv is not configured correctly >>> with a valid server certificate. Output from the dirsrv error added to >>> this >>> email as well. >>> >>> [root at ns02 ~]# ipa-replica-install --setup-ca >>> WARNING: conflicting time&date synchronization service 'chronyd' will >>> be disabled in favor of ntpd >>> >>> Run connection check to master >>> Connection check OK >>> 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/43]: creating directory server user >>> [2/43]: creating directory server instance >>> [3/43]: restarting directory server >>> [4/43]: adding default schema >>> [5/43]: enabling memberof plugin >>> [6/43]: enabling winsync plugin >>> [7/43]: configuring replication version plugin >>> [8/43]: enabling IPA enrollment plugin >>> [9/43]: enabling ldapi >>> [10/43]: configuring uniqueness plugin >>> [11/43]: configuring uuid plugin >>> [12/43]: configuring modrdn plugin >>> [13/43]: configuring DNS plugin >>> [14/43]: enabling entryUSN plugin >>> [15/43]: configuring lockout plugin >>> [16/43]: configuring topology plugin >>> [17/43]: creating indices >>> [18/43]: enabling referential integrity plugin >>> [19/43]: configuring certmap.conf >>> [20/43]: configure autobind for root >>> [21/43]: configure new location for managed entries >>> [22/43]: configure dirsrv ccache >>> [23/43]: enabling SASL mapping fallback >>> [24/43]: restarting directory server >>> [25/43]: creating DS keytab >>> [26/43]: retrieving DS Certificate >>> [27/43]: restarting directory server >>> ipa : CRITICAL Failed to restart the directory server (Command >>> '/bin/systemctl restart dirsrv at SOMETHING-BE.service' returned non-zero >>> exit >>> status 1). See the installation log for details. >>> [28/43]: setting up initial replication >>> [error] error: [Errno 111] Connection refused >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> >>> [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security >>> Initialization: >>> Can't find certificate (Server-Cert) for family >>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - >>> security library: bad database.) >>> [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security >>> Initialization: >>> Unable to retrieve private key for cert Server-Cert of family >>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - >>> security library: bad database.) >>> >>> >>> >>> >> Hello David, >> >> The error from the log indicates that either the NSSDB for dirsrv is not >> initialized or not accessible. >> >> Could you please send output of the following commands? >> >> # ls -lZ /etc/dirsrv/slapd-$REALM/ >> # certutil -d /etc/dirsrv/slapd-$REALM/ -L >> # ausearch -m avc -i >> >> >> -- >> David Kupka >> > -- David Kupka From abokovoy at redhat.com Tue Nov 29 11:51:26 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 29 Nov 2016 13:51:26 +0200 Subject: [Freeipa-users] OTP Algorithm In-Reply-To: References: <79cd7b7f-3fc7-84f9-4762-75cd386a0cac@redhat.com> Message-ID: <20161129115126.lboewmlkco2ufa4s@redhat.com> On ti, 29 marras 2016, Callum Guy wrote: >Hi Petr, > >Thanks for coming back to me on this. > >I have only tried using Google Authenticator. The generated QR code >successfully scans and codes are then generated on the GA device as normal. >The problem is that the codes simply do not work. > >My current thinking is that the service which interprets the codes >server-side is not configured to use the same algorithm meaning that it is >trying to validate sha256/sha512 (both tested and not functional for me) >etc codes against codes perhaps generated with sha1 (the only algorithm >that appears to work). > >I apologise in advance for my naive interpretation of the situation, this >really isn't an area where i have experience. I'd love to understand whats >going on however I can't find what i need in the OTP documentation. Which IPA version we are talking about? There was a case when the URI generated by 'ipa otptoken-add' was using a wrong case in the algorithm value and this was breaking Google Authenticator. https://fedorahosted.org/freeipa/ticket/5047 This bug was fixed since 4.1.5 release. > >Best Regards, > >Callum > > >On Tue, Nov 29, 2016 at 11:10 AM Petr Vobornik wrote: > >> On 11/28/2016 01:03 PM, Callum Guy wrote: >> > Hi All, >> > >> > I wanted to ask a quick question - perhaps a more experienced user will >> be able >> > to help or point me to the correct documentation. >> > >> > Basically we have implemented password+OTP type authentication which >> works great. >> > >> > When adding a OTP code using the admin login you can choose an >> algorithm. For us >> > the generated codes only work properly if the weakest sha1 algorithm is >> chosen/ >> > To be clear the code generation works fine but the codes are not valid >> when >> > logging in. Is there a related setting we must change? >> > >> > Thanks, >> > >> > Callum >> > >> >> What type of otp token do you use? Does it work with some different? >> E.g. FreeOTP vs Google Authenticator ... >> >> >> -- >> Petr Vobornik >> > >-- > > > >*0333 332 0000 | www.x-on.co.uk | ** > > > * >X-on is a trading name of Storacall Technology Ltd a limited company >registered in England and Wales. >Registered Office : Avaland House, 110 London Road, Apsley, Hemel >Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >The information in this e-mail is confidential and for use by the >addressee(s) only. If you are not the intended recipient, please notify >X-on immediately on +44(0)333 332 0000 and delete the >message from your computer. If you are not a named addressee you must not >use, disclose, disseminate, distribute, copy, print or reply to this email. Views >or opinions expressed by an individual >within this email may not necessarily reflect the views of X-on or its >associated companies. Although X-on routinely screens for viruses, >addressees should scan this email and any attachments >for viruses. X-on makes no representation or warranty as to the absence of >viruses in this email or any attachments. > >-- >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 callum.guy at x-on.co.uk Tue Nov 29 11:57:03 2016 From: callum.guy at x-on.co.uk (Callum Guy) Date: Tue, 29 Nov 2016 11:57:03 +0000 Subject: [Freeipa-users] OTP Algorithm In-Reply-To: <20161129115126.lboewmlkco2ufa4s@redhat.com> References: <79cd7b7f-3fc7-84f9-4762-75cd386a0cac@redhat.com> <20161129115126.lboewmlkco2ufa4s@redhat.com> Message-ID: Hi Alexander, I can confirm that I am using version 4.2.0. The bug link provided mentions that it caused GA to fail to scan the codes. In my situation it is FreeIPA (or related service) which appears to fail to validate codes generated, meaning that only OTP codes generated using sha1 are validated and accepted. Just for clarity I can confirm that I have only tested OTP codes generated and configured via the FreeIPA web interface. I will check the command line generation and let you know if this makes a difference. Best Regards, Callum On Tue, Nov 29, 2016 at 11:51 AM Alexander Bokovoy wrote: > On ti, 29 marras 2016, Callum Guy wrote: > >Hi Petr, > > > >Thanks for coming back to me on this. > > > >I have only tried using Google Authenticator. The generated QR code > >successfully scans and codes are then generated on the GA device as > normal. > >The problem is that the codes simply do not work. > > > >My current thinking is that the service which interprets the codes > >server-side is not configured to use the same algorithm meaning that it is > >trying to validate sha256/sha512 (both tested and not functional for me) > >etc codes against codes perhaps generated with sha1 (the only algorithm > >that appears to work). > > > >I apologise in advance for my naive interpretation of the situation, this > >really isn't an area where i have experience. I'd love to understand whats > >going on however I can't find what i need in the OTP documentation. > Which IPA version we are talking about? There was a case when the URI > generated by 'ipa otptoken-add' was using a wrong case in the algorithm > value and this was breaking Google Authenticator. > > https://fedorahosted.org/freeipa/ticket/5047 > > This bug was fixed since 4.1.5 release. > > > > >Best Regards, > > > >Callum > > > > > >On Tue, Nov 29, 2016 at 11:10 AM Petr Vobornik > wrote: > > > >> On 11/28/2016 01:03 PM, Callum Guy wrote: > >> > Hi All, > >> > > >> > I wanted to ask a quick question - perhaps a more experienced user > will > >> be able > >> > to help or point me to the correct documentation. > >> > > >> > Basically we have implemented password+OTP type authentication which > >> works great. > >> > > >> > When adding a OTP code using the admin login you can choose an > >> algorithm. For us > >> > the generated codes only work properly if the weakest sha1 algorithm > is > >> chosen/ > >> > To be clear the code generation works fine but the codes are not valid > >> when > >> > logging in. Is there a related setting we must change? > >> > > >> > Thanks, > >> > > >> > Callum > >> > > >> > >> What type of otp token do you use? Does it work with some different? > >> E.g. FreeOTP vs Google Authenticator ... > >> > >> > >> -- > >> Petr Vobornik > >> > > > >-- > > > > > > > >*0333 332 0000 | www.x-on.co.uk | ** > > > > > > * > >X-on is a trading name of Storacall Technology Ltd a limited company > >registered in England and Wales. > >Registered Office : Avaland House, 110 London Road, Apsley, Hemel > >Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > >The information in this e-mail is confidential and for use by the > >addressee(s) only. If you are not the intended recipient, please notify > >X-on immediately on +44(0)333 332 0000 <+44%20333%20332%200000> and > delete the > >message from your computer. If you are not a named addressee you must not > >use, disclose, disseminate, distribute, copy, print or reply to this > email. Views > >or opinions expressed by an individual > >within this email may not necessarily reflect the views of X-on or its > >associated companies. Although X-on routinely screens for viruses, > >addressees should scan this email and any attachments > >for viruses. X-on makes no representation or warranty as to the absence of > >viruses in this email or any attachments. > > > > >-- > >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 > -- *0333 332 0000 | www.x-on.co.uk | ** * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From giulio at di.unimi.it Tue Nov 29 12:20:19 2016 From: giulio at di.unimi.it (Giulio Casella) Date: Tue, 29 Nov 2016 13:20:19 +0100 Subject: [Freeipa-users] ns-slapd segfault In-Reply-To: <8a02a86c-8e62-2d81-3905-14bfdebcfe52@redhat.com> References: <20161128142547.GB30923@10.4.128.1> <8a02a86c-8e62-2d81-3905-14bfdebcfe52@redhat.com> Message-ID: <34437c0e-7100-bc8b-9b81-31172fc00098@di.unimi.it> Il 28/11/2016 19:22, Mark Reynolds ha scritto: > > > On 11/28/2016 10:22 AM, Giulio Casella wrote: >> Il 28/11/2016 15:25, Lukas Slebodnik ha scritto: >>> On (28/11/16 12:39), Giulio Casella wrote: >>>> Hello, >>>> >>>> I have a setup with two ipa server in replica, based on CentOS 7. >>>> On one server (since a couple of days) ipa cannot start, the failing >>>> service >>>> is dirsrv@.service. >>>> In journal I have: >>>> >>>> ns-slapd[4617]: segfault at 7fb53b1ce515 ip 00007fb50126e1a6sp >>>> 00007ffc0b80d6c8 error 4 in libc-2.17.so[7fb501124000+1b7000] >>>> >>>> (just after a lot of SSL alerts complaining about some enabled >>>> cypher suite, >>>> but I cannot say if this could be related). >>>> >>>> I'm using ipa 4.2.0, and 389-ds-base 1.3.4. >>>> >>> It would be good to know the exact version. >>> rpm -q 389-ds-base >> >> Installed version is: >> >> 389-ds-base-1.3.4.0-33.el7_2.x86_64 >> >>> >>> Please provide backtrace or coredump; other developers will know >>> wheter it's know bug or a new bug. >> >> Ok, you can find attached full stacktrace. > It's crashing trying to read updates from the replication changelog. > > Are you using attribute encryption? > Any chance you have a way to reproduce this? > > Since this is happening on only one server then I think recreating the > replication changelog will "fix" the issue. Just re-initializing that > replica should do it. Does this server start - so it can be reinited? > If not, you need to manually remove the changelog and start the > directory server, and reinit it. Or perform a manual ldif > initialization. (I can help with either one if needed) > No, directory server can't start, so I think I have to manually remove the changelog. Any help is obviously welcome. BTW: Do you confirm I won't lose data on second (working) server doing removal of changelog? Thanks in advance, gc From pvoborni at redhat.com Tue Nov 29 12:41:14 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 29 Nov 2016 13:41:14 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process In-Reply-To: <17ed1617-b686-368a-b6af-55cb39c720a0@redhat.com> References: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> <17ed1617-b686-368a-b6af-55cb39c720a0@redhat.com> Message-ID: On 11/29/2016 12:43 PM, David Kupka wrote: > On 29/11/16 12:15, David Dejaeghere wrote: >> Seems like it is but it does not show a server cert for dirsrv >> >> [root at ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ >> total 468 >> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >> 65536 >> Nov 29 11:29 cert8.db >> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >> 65536 >> Nov 29 11:29 cert8.db.orig >> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >> 1623 >> Nov 29 11:29 certmap.conf >> -rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >> 89977 >> Nov 29 11:29 dse.ldif >> -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >> 89977 >> Nov 29 11:29 dse.ldif.bak >> -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >> 89977 >> Nov 29 11:29 dse.ldif.startOK >> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >> 36228 >> Nov 29 11:28 dse_original.ldif >> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >> 16384 >> Nov 29 11:29 key3.db >> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >> 16384 >> Nov 29 11:29 key3.db.orig >> -r--------. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 66 >> Nov 29 11:29 pin.txt >> -rw-------. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 40 >> Nov 29 11:29 pwdfile.txt >> drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >> 4096 >> Nov 29 11:29 schema >> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >> 16384 >> Nov 29 11:29 secmod.db >> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >> 16384 >> Nov 29 11:29 secmod.db.orig >> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >> 15142 >> Nov 29 11:28 slapd-collations.conf >> >> [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> CN=something-PAPRIKA-CA,DC=something,DC=local >> CT,C,C >> SOMETHING.BE IPA CA CT,C,C >> [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> CN=something-PAPRIKA-CA,DC=something,DC=local >> CT,C,C >> SOMETHING.BE IPA CA CT,C,C >> >> [root at ns02 ~]# ausearch -m avc -i >> >> >> > > Exactly, the NSSDB should be accessible to dirsrv and is missing the > Server-Cert but I don't understand why there's "bad database" error in > the errors log. I'll try to reproduce it. What version of FreeIPA are > you using? On what system? Right. Seems bit similar to https://fedorahosted.org/freeipa/ticket/6514 would be good to check if it has the same symptoms, mainly certmonger request is in state dbus.String(u'CA_UNREACHABLE', variant_level=1) in replica install log. > >> >> 2016-11-29 12:09 GMT+01:00 David Kupka : >> >>> On 29/11/16 11:51, David Dejaeghere wrote: >>> >>>> Hi, >>>> >>>> I have a setup where i want to add a replica. The first master >>>> setup has >>>> an externally signed cert for dirsrv and httpd. The replica is >>>> prepapred >>>> succesfully with ipa-client-install but the replica install then keeps >>>> failing. It seems that during install dirserv is not configured >>>> correctly >>>> with a valid server certificate. Output from the dirsrv error added to >>>> this >>>> email as well. >>>> >>>> [root at ns02 ~]# ipa-replica-install --setup-ca >>>> WARNING: conflicting time&date synchronization service 'chronyd' will >>>> be disabled in favor of ntpd >>>> >>>> Run connection check to master >>>> Connection check OK >>>> 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/43]: creating directory server user >>>> [2/43]: creating directory server instance >>>> [3/43]: restarting directory server >>>> [4/43]: adding default schema >>>> [5/43]: enabling memberof plugin >>>> [6/43]: enabling winsync plugin >>>> [7/43]: configuring replication version plugin >>>> [8/43]: enabling IPA enrollment plugin >>>> [9/43]: enabling ldapi >>>> [10/43]: configuring uniqueness plugin >>>> [11/43]: configuring uuid plugin >>>> [12/43]: configuring modrdn plugin >>>> [13/43]: configuring DNS plugin >>>> [14/43]: enabling entryUSN plugin >>>> [15/43]: configuring lockout plugin >>>> [16/43]: configuring topology plugin >>>> [17/43]: creating indices >>>> [18/43]: enabling referential integrity plugin >>>> [19/43]: configuring certmap.conf >>>> [20/43]: configure autobind for root >>>> [21/43]: configure new location for managed entries >>>> [22/43]: configure dirsrv ccache >>>> [23/43]: enabling SASL mapping fallback >>>> [24/43]: restarting directory server >>>> [25/43]: creating DS keytab >>>> [26/43]: retrieving DS Certificate >>>> [27/43]: restarting directory server >>>> ipa : CRITICAL Failed to restart the directory server (Command >>>> '/bin/systemctl restart dirsrv at SOMETHING-BE.service' returned non-zero >>>> exit >>>> status 1). See the installation log for details. >>>> [28/43]: setting up initial replication >>>> [error] error: [Errno 111] Connection refused >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> >>>> >>>> [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security >>>> Initialization: >>>> Can't find certificate (Server-Cert) for family >>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - >>>> security library: bad database.) >>>> [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security >>>> Initialization: >>>> Unable to retrieve private key for cert Server-Cert of family >>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - >>>> security library: bad database.) >>>> >>>> >>>> >>>> >>> Hello David, >>> >>> The error from the log indicates that either the NSSDB for dirsrv is not >>> initialized or not accessible. >>> >>> Could you please send output of the following commands? >>> >>> # ls -lZ /etc/dirsrv/slapd-$REALM/ >>> # certutil -d /etc/dirsrv/slapd-$REALM/ -L >>> # ausearch -m avc -i >>> >>> >>> -- >>> David Kupka >>> -- Petr Vobornik From tkrizek at redhat.com Tue Nov 29 12:41:33 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Tue, 29 Nov 2016 13:41:33 +0100 Subject: [Freeipa-users] new install on Fedora 24 kinit: Generic preauthentication failure while getting initial credentials In-Reply-To: References: <60257124-FA5E-4972-889E-0441005D111A@fordham.edu> Message-ID: <62e567aa-19a3-3ba5-122a-c319b7cacadd@redhat.com> On 11/29/2016 10:50 AM, Tomas Krizek wrote: > On 11/28/2016 05:38 PM, Robert Kudyba wrote: >> There seems to be a problem either with Kerberos and/or using a self >> signed certificate vs. Let?s Encrypt. I tried to run the set up >> script from https://github.com/freeipa/freeipa-letsencrypt and below >> are some errors and logs. >> >> Within the /etc/httpd/conf.d/ipa.conffile I commented out >> these directives as I had some Apache redirects that were breaking: >> >> #WSGIDaemonProcess ipa processes=2 threads=1 maximum-requests=500 \ >> display-name=%{GROUP} socket-timeout=2147483647 >> #WSGIImportScript /usr/share/ipa/wsgi.py process-group=ipa >> application-group=ipa >> #WSGIScriptAlias /ipa /usr/share/ipa/wsgi.py >> #WSGIScriptReloading Off >> >> ./setup-le.sh >> Last metadata expiration check: 0:24:16 ago on Mon Nov 28 10:40:45 2016. >> Package certbot-0.9.3-1.fc25.noarch is already installed, skipping. >> Dependencies resolved. >> Nothing to do. >> Complete! >> Installing CA certificate, please wait >> Not a valid CA certificate: (SEC_ERROR_UNTRUSTED_ISSUER) Peer's >> certificate issuer has been marked as not trusted by the user. (visit >> http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) >> The ipa-cacert-manage command failed. >> >> ipactl status >> Directory Service: RUNNING >> krb5kdc Service: RUNNING >> kadmin Service: RUNNING >> ipa_memcached Service: RUNNING >> ipa-custodia Service: RUNNING >> ntpd Service: RUNNING >> pki-tomcatd Service: RUNNING >> ipa-otpd Service: RUNNING >> ipa: INFO: The ipactl command was successful >> >> kinit admin >> kinit: Generic preauthentication failure while getting initial >> credentials >> >> journalctl -u named-pkcs11 >> -- No entries ? >> >> journalctl -u named >> -- No entries ? >> >> file /var/named/data/named.run >> /var/named/data/named.run: cannot open `/var/named/data/named.run' >> (No such file or directory) >> >> ldapsearch -Y GSSAPI >> '(&(ipaConfigString=enabledService)(ipaConfigString=dnssecKeyMaster))' >> SASL/GSSAPI authentication started >> ldap_sasl_interactive_bind_s: Local error (-2) >> additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified >> GSS failure. Minor code may provide more information (No Kerberos >> credentials available (default cache: KEYRING:persistent:0)) >> >> ipa help krbtpolicy >> ipa: ERROR: did not receive Kerberos credentials >> >> In /var/log/krb5kdc.log: >> >> Nov 28 05:19:49 krb5kdc[19575](info): closing down fd 11 >> Nov 28 11:04:40 krb5kdc[19575](info): AS_REQ (6 etypes {18 17 16 23 >> 25 26}) ip: NEEDED_PREAUTH: admin at for krbtgt/ourdomain@ ourdomain, >> Additional pre-authentication required >> Nov 28 11:04:40 krb5kdc[19575](info): closing down fd 11 >> Nov 28 11:15:35 krb5kdc[19573](info): AS_REQ (6 etypes {18 17 16 23 >> 25 26}) ip: NEEDED_PREAUTH: admin at for krbtgt/ourdomain@ ourdomain, >> Additional pre-authentication required >> Nov 28 11:15:35 krb5kdc[19573](info): closing down fd 11 >> >> >> > Hi, > > you're hitting an issue with Let's Encrypt setup. > > https://github.com/freeipa/freeipa-letsencrypt/issues/1 > > unfortunately, I'm not aware of any workaround or solution as of now. > -- > Tomas Krizek > > The issue should be fixed now. Please try to setup Let's Encrypt again. In case it does not work, you might need to reinstall IPA before setting up Let's Encrypt. -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.dejaeghere at gmail.com Tue Nov 29 12:55:40 2016 From: david.dejaeghere at gmail.com (David Dejaeghere) Date: Tue, 29 Nov 2016 13:55:40 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process In-Reply-To: References: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> <17ed1617-b686-368a-b6af-55cb39c720a0@redhat.com> Message-ID: Correct. Same symptoms. 2016-11-29T10:29:42Z DEBUG certmonger request is in state dbus.String(u'CA_UNREACHABLE', variant_level=1) Fedora 24 Server [root at ns02 ~]# dnf history userinstalled Packages installed by user freeipa-client-4.3.2-2.fc24.x86_64 freeipa-server-4.3.2-2.fc24.x86_64 grub2-1:2.02-0.34.fc24.x86_64 kernel-4.5.5-300.fc24.x86_64 kernel-4.8.8-200.fc24.x86_64 lvm2-2.02.150-2.fc24.x86_64 xfsprogs-4.5.0-2.fc24.x86_64 2016-11-29 13:41 GMT+01:00 Petr Vobornik : > On 11/29/2016 12:43 PM, David Kupka wrote: > > On 29/11/16 12:15, David Dejaeghere wrote: > >> Seems like it is but it does not show a server cert for dirsrv > >> > >> [root at ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ > >> total 468 > >> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 > >> 65536 > >> Nov 29 11:29 cert8.db > >> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 65536 > >> Nov 29 11:29 cert8.db.orig > >> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 1623 > >> Nov 29 11:29 certmap.conf > >> -rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 > >> 89977 > >> Nov 29 11:29 dse.ldif > >> -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 > >> 89977 > >> Nov 29 11:29 dse.ldif.bak > >> -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 > >> 89977 > >> Nov 29 11:29 dse.ldif.startOK > >> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 36228 > >> Nov 29 11:28 dse_original.ldif > >> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 > >> 16384 > >> Nov 29 11:29 key3.db > >> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 16384 > >> Nov 29 11:29 key3.db.orig > >> -r--------. 1 dirsrv dirsrv > >> unconfined_u:object_r:dirsrv_config_t:s0 66 > >> Nov 29 11:29 pin.txt > >> -rw-------. 1 dirsrv dirsrv > >> unconfined_u:object_r:dirsrv_config_t:s0 40 > >> Nov 29 11:29 pwdfile.txt > >> drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 4096 > >> Nov 29 11:29 schema > >> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 > >> 16384 > >> Nov 29 11:29 secmod.db > >> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 16384 > >> Nov 29 11:29 secmod.db.orig > >> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > >> 15142 > >> Nov 29 11:28 slapd-collations.conf > >> > >> [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L > >> > >> Certificate Nickname Trust > >> Attributes > >> > >> SSL,S/MIME,JAR/XPI > >> > >> CN=something-PAPRIKA-CA,DC=something,DC=local > >> CT,C,C > >> SOMETHING.BE IPA CA CT,C,C > >> [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L > >> > >> Certificate Nickname Trust > >> Attributes > >> > >> SSL,S/MIME,JAR/XPI > >> > >> CN=something-PAPRIKA-CA,DC=something,DC=local > >> CT,C,C > >> SOMETHING.BE IPA CA CT,C,C > >> > >> [root at ns02 ~]# ausearch -m avc -i > >> > >> > >> > > > > Exactly, the NSSDB should be accessible to dirsrv and is missing the > > Server-Cert but I don't understand why there's "bad database" error in > > the errors log. I'll try to reproduce it. What version of FreeIPA are > > you using? On what system? > > Right. > > Seems bit similar to https://fedorahosted.org/freeipa/ticket/6514 would > be good to check if it has the same symptoms, mainly > certmonger request is in state dbus.String(u'CA_UNREACHABLE', > variant_level=1) > > in replica install log. > > > > > >> > >> 2016-11-29 12:09 GMT+01:00 David Kupka : > >> > >>> On 29/11/16 11:51, David Dejaeghere wrote: > >>> > >>>> Hi, > >>>> > >>>> I have a setup where i want to add a replica. The first master > >>>> setup has > >>>> an externally signed cert for dirsrv and httpd. The replica is > >>>> prepapred > >>>> succesfully with ipa-client-install but the replica install then keeps > >>>> failing. It seems that during install dirserv is not configured > >>>> correctly > >>>> with a valid server certificate. Output from the dirsrv error added to > >>>> this > >>>> email as well. > >>>> > >>>> [root at ns02 ~]# ipa-replica-install --setup-ca > >>>> WARNING: conflicting time&date synchronization service 'chronyd' will > >>>> be disabled in favor of ntpd > >>>> > >>>> Run connection check to master > >>>> Connection check OK > >>>> 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/43]: creating directory server user > >>>> [2/43]: creating directory server instance > >>>> [3/43]: restarting directory server > >>>> [4/43]: adding default schema > >>>> [5/43]: enabling memberof plugin > >>>> [6/43]: enabling winsync plugin > >>>> [7/43]: configuring replication version plugin > >>>> [8/43]: enabling IPA enrollment plugin > >>>> [9/43]: enabling ldapi > >>>> [10/43]: configuring uniqueness plugin > >>>> [11/43]: configuring uuid plugin > >>>> [12/43]: configuring modrdn plugin > >>>> [13/43]: configuring DNS plugin > >>>> [14/43]: enabling entryUSN plugin > >>>> [15/43]: configuring lockout plugin > >>>> [16/43]: configuring topology plugin > >>>> [17/43]: creating indices > >>>> [18/43]: enabling referential integrity plugin > >>>> [19/43]: configuring certmap.conf > >>>> [20/43]: configure autobind for root > >>>> [21/43]: configure new location for managed entries > >>>> [22/43]: configure dirsrv ccache > >>>> [23/43]: enabling SASL mapping fallback > >>>> [24/43]: restarting directory server > >>>> [25/43]: creating DS keytab > >>>> [26/43]: retrieving DS Certificate > >>>> [27/43]: restarting directory server > >>>> ipa : CRITICAL Failed to restart the directory server (Command > >>>> '/bin/systemctl restart dirsrv at SOMETHING-BE.service' returned > non-zero > >>>> exit > >>>> status 1). See the installation log for details. > >>>> [28/43]: setting up initial replication > >>>> [error] error: [Errno 111] Connection refused > >>>> Your system may be partly configured. > >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. > >>>> > >>>> > >>>> [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security > >>>> Initialization: > >>>> Can't find certificate (Server-Cert) for family > >>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 > - > >>>> security library: bad database.) > >>>> [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security > >>>> Initialization: > >>>> Unable to retrieve private key for cert Server-Cert of family > >>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 > - > >>>> security library: bad database.) > >>>> > >>>> > >>>> > >>>> > >>> Hello David, > >>> > >>> The error from the log indicates that either the NSSDB for dirsrv is > not > >>> initialized or not accessible. > >>> > >>> Could you please send output of the following commands? > >>> > >>> # ls -lZ /etc/dirsrv/slapd-$REALM/ > >>> # certutil -d /etc/dirsrv/slapd-$REALM/ -L > >>> # ausearch -m avc -i > >>> > >>> > >>> -- > >>> David Kupka > >>> > > > -- > Petr Vobornik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giulio at di.unimi.it Tue Nov 29 13:46:21 2016 From: giulio at di.unimi.it (Giulio Casella) Date: Tue, 29 Nov 2016 14:46:21 +0100 Subject: [Freeipa-users] ns-slapd segfault In-Reply-To: <27d5e3ca-8dc9-5dcd-1d5d-dba916182cd3@redhat.com> References: <20161128142547.GB30923@10.4.128.1> <8a02a86c-8e62-2d81-3905-14bfdebcfe52@redhat.com> <98c92d9e-fad8-64db-3fba-1c08839af369@di.unimi.it> <27d5e3ca-8dc9-5dcd-1d5d-dba916182cd3@redhat.com> Message-ID: <646848ae-e354-07e3-1e9c-f83effbdd261@di.unimi.it> Il 29/11/2016 14:19, Mark Reynolds ha scritto: > > > On 11/29/2016 03:14 AM, Giulio Casella wrote: >> Il 28/11/2016 19:22, Mark Reynolds ha scritto: >>> >>> >>> On 11/28/2016 10:22 AM, Giulio Casella wrote: >>>> Il 28/11/2016 15:25, Lukas Slebodnik ha scritto: >>>>> On (28/11/16 12:39), Giulio Casella wrote: >>>>>> Hello, >>>>>> >>>>>> I have a setup with two ipa server in replica, based on CentOS 7. >>>>>> On one server (since a couple of days) ipa cannot start, the failing >>>>>> service >>>>>> is dirsrv@.service. >>>>>> In journal I have: >>>>>> >>>>>> ns-slapd[4617]: segfault at 7fb53b1ce515 ip 00007fb50126e1a6sp >>>>>> 00007ffc0b80d6c8 error 4 in libc-2.17.so[7fb501124000+1b7000] >>>>>> >>>>>> (just after a lot of SSL alerts complaining about some enabled >>>>>> cypher suite, >>>>>> but I cannot say if this could be related). >>>>>> >>>>>> I'm using ipa 4.2.0, and 389-ds-base 1.3.4. >>>>>> >>>>> It would be good to know the exact version. >>>>> rpm -q 389-ds-base >>>> >>>> Installed version is: >>>> >>>> 389-ds-base-1.3.4.0-33.el7_2.x86_64 >>>> >>>>> >>>>> Please provide backtrace or coredump; other developers will know >>>>> wheter it's know bug or a new bug. >>>> >>>> Ok, you can find attached full stacktrace. >>> It's crashing trying to read updates from the replication changelog. >>> >>> Are you using attribute encryption? >>> Any chance you have a way to reproduce this? >>> >>> Since this is happening on only one server then I think recreating the >>> replication changelog will "fix" the issue. Just re-initializing that >>> replica should do it. Does this server start - so it can be reinited? >>> If not, you need to manually remove the changelog and start the >>> directory server, and reinit it. Or perform a manual ldif >>> initialization. (I can help with either one if needed) >>> >> >> No, directory server can't start, so I think I have to manually remove >> the changelog. > Probably best: > > Its under /var/lib/dirsrv/slapd-INSTANCE/db/changelog (something like that) > >> Any help is obviously welcome. >> BTW: Do you confirm I won't lose data on second (working) server doing >> removal of changelog? > Well the changelog appears to be hosed. So if something is lost, its > already lost and is not recoverable. As long as you have another master > you are okay, and IPA only creates masters so you should be good. > Thank you Mark, I moved away and recreated entire /var/lib/dirsrv/slapd-INSTANCE/db/changelog directory, rebooted server and now it's up and running! Thank you again. Bye, gc From dkupka at redhat.com Tue Nov 29 13:57:58 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 29 Nov 2016 14:57:58 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process In-Reply-To: References: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> <17ed1617-b686-368a-b6af-55cb39c720a0@redhat.com> Message-ID: <11a369fa-dceb-3337-053b-4c2e3e46b3bf@redhat.com> On 29/11/16 13:55, David Dejaeghere wrote: > Correct. Same symptoms. > > 2016-11-29T10:29:42Z DEBUG certmonger request is in state > dbus.String(u'CA_UNREACHABLE', variant_level=1) > > Fedora 24 Server > > [root at ns02 ~]# dnf history userinstalled > Packages installed by user > freeipa-client-4.3.2-2.fc24.x86_64 > freeipa-server-4.3.2-2.fc24.x86_64 > grub2-1:2.02-0.34.fc24.x86_64 > kernel-4.5.5-300.fc24.x86_64 > kernel-4.8.8-200.fc24.x86_64 > lvm2-2.02.150-2.fc24.x86_64 > xfsprogs-4.5.0-2.fc24.x86_64 Ok. I've reproduced it by simply stopping dogtag on FreeIPA server while installing the replica. I see the exactly same errors as you've reported and are described in the ticket, now. Is dogtag running on your master? Is in responding (e.g. issuing certificates for users)? Is it accessible from the replica? > > 2016-11-29 13:41 GMT+01:00 Petr Vobornik : > >> On 11/29/2016 12:43 PM, David Kupka wrote: >>> On 29/11/16 12:15, David Dejaeghere wrote: >>>> Seems like it is but it does not show a server cert for dirsrv >>>> >>>> [root at ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ >>>> total 468 >>>> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >>>> 65536 >>>> Nov 29 11:29 cert8.db >>>> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>> 65536 >>>> Nov 29 11:29 cert8.db.orig >>>> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>> 1623 >>>> Nov 29 11:29 certmap.conf >>>> -rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >>>> 89977 >>>> Nov 29 11:29 dse.ldif >>>> -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >>>> 89977 >>>> Nov 29 11:29 dse.ldif.bak >>>> -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >>>> 89977 >>>> Nov 29 11:29 dse.ldif.startOK >>>> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>> 36228 >>>> Nov 29 11:28 dse_original.ldif >>>> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >>>> 16384 >>>> Nov 29 11:29 key3.db >>>> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>> 16384 >>>> Nov 29 11:29 key3.db.orig >>>> -r--------. 1 dirsrv dirsrv >>>> unconfined_u:object_r:dirsrv_config_t:s0 66 >>>> Nov 29 11:29 pin.txt >>>> -rw-------. 1 dirsrv dirsrv >>>> unconfined_u:object_r:dirsrv_config_t:s0 40 >>>> Nov 29 11:29 pwdfile.txt >>>> drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>> 4096 >>>> Nov 29 11:29 schema >>>> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >>>> 16384 >>>> Nov 29 11:29 secmod.db >>>> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>> 16384 >>>> Nov 29 11:29 secmod.db.orig >>>> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>> 15142 >>>> Nov 29 11:28 slapd-collations.conf >>>> >>>> [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L >>>> >>>> Certificate Nickname Trust >>>> Attributes >>>> >>>> SSL,S/MIME,JAR/XPI >>>> >>>> CN=something-PAPRIKA-CA,DC=something,DC=local >>>> CT,C,C >>>> SOMETHING.BE IPA CA CT,C,C >>>> [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L >>>> >>>> Certificate Nickname Trust >>>> Attributes >>>> >>>> SSL,S/MIME,JAR/XPI >>>> >>>> CN=something-PAPRIKA-CA,DC=something,DC=local >>>> CT,C,C >>>> SOMETHING.BE IPA CA CT,C,C >>>> >>>> [root at ns02 ~]# ausearch -m avc -i >>>> >>>> >>>> >>> >>> Exactly, the NSSDB should be accessible to dirsrv and is missing the >>> Server-Cert but I don't understand why there's "bad database" error in >>> the errors log. I'll try to reproduce it. What version of FreeIPA are >>> you using? On what system? >> >> Right. >> >> Seems bit similar to https://fedorahosted.org/freeipa/ticket/6514 would >> be good to check if it has the same symptoms, mainly >> certmonger request is in state dbus.String(u'CA_UNREACHABLE', >> variant_level=1) >> >> in replica install log. >> >> >>> >>>> >>>> 2016-11-29 12:09 GMT+01:00 David Kupka : >>>> >>>>> On 29/11/16 11:51, David Dejaeghere wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have a setup where i want to add a replica. The first master >>>>>> setup has >>>>>> an externally signed cert for dirsrv and httpd. The replica is >>>>>> prepapred >>>>>> succesfully with ipa-client-install but the replica install then keeps >>>>>> failing. It seems that during install dirserv is not configured >>>>>> correctly >>>>>> with a valid server certificate. Output from the dirsrv error added to >>>>>> this >>>>>> email as well. >>>>>> >>>>>> [root at ns02 ~]# ipa-replica-install --setup-ca >>>>>> WARNING: conflicting time&date synchronization service 'chronyd' will >>>>>> be disabled in favor of ntpd >>>>>> >>>>>> Run connection check to master >>>>>> Connection check OK >>>>>> 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/43]: creating directory server user >>>>>> [2/43]: creating directory server instance >>>>>> [3/43]: restarting directory server >>>>>> [4/43]: adding default schema >>>>>> [5/43]: enabling memberof plugin >>>>>> [6/43]: enabling winsync plugin >>>>>> [7/43]: configuring replication version plugin >>>>>> [8/43]: enabling IPA enrollment plugin >>>>>> [9/43]: enabling ldapi >>>>>> [10/43]: configuring uniqueness plugin >>>>>> [11/43]: configuring uuid plugin >>>>>> [12/43]: configuring modrdn plugin >>>>>> [13/43]: configuring DNS plugin >>>>>> [14/43]: enabling entryUSN plugin >>>>>> [15/43]: configuring lockout plugin >>>>>> [16/43]: configuring topology plugin >>>>>> [17/43]: creating indices >>>>>> [18/43]: enabling referential integrity plugin >>>>>> [19/43]: configuring certmap.conf >>>>>> [20/43]: configure autobind for root >>>>>> [21/43]: configure new location for managed entries >>>>>> [22/43]: configure dirsrv ccache >>>>>> [23/43]: enabling SASL mapping fallback >>>>>> [24/43]: restarting directory server >>>>>> [25/43]: creating DS keytab >>>>>> [26/43]: retrieving DS Certificate >>>>>> [27/43]: restarting directory server >>>>>> ipa : CRITICAL Failed to restart the directory server (Command >>>>>> '/bin/systemctl restart dirsrv at SOMETHING-BE.service' returned >> non-zero >>>>>> exit >>>>>> status 1). See the installation log for details. >>>>>> [28/43]: setting up initial replication >>>>>> [error] error: [Errno 111] Connection refused >>>>>> Your system may be partly configured. >>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>>>> >>>>>> >>>>>> [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security >>>>>> Initialization: >>>>>> Can't find certificate (Server-Cert) for family >>>>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 >> - >>>>>> security library: bad database.) >>>>>> [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security >>>>>> Initialization: >>>>>> Unable to retrieve private key for cert Server-Cert of family >>>>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 >> - >>>>>> security library: bad database.) >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hello David, >>>>> >>>>> The error from the log indicates that either the NSSDB for dirsrv is >> not >>>>> initialized or not accessible. >>>>> >>>>> Could you please send output of the following commands? >>>>> >>>>> # ls -lZ /etc/dirsrv/slapd-$REALM/ >>>>> # certutil -d /etc/dirsrv/slapd-$REALM/ -L >>>>> # ausearch -m avc -i >>>>> >>>>> >>>>> -- >>>>> David Kupka >>>>> >> >> >> -- >> Petr Vobornik >> > -- David Kupka From david.dejaeghere at gmail.com Tue Nov 29 14:19:04 2016 From: david.dejaeghere at gmail.com (David Dejaeghere) Date: Tue, 29 Nov 2016 15:19:04 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process In-Reply-To: <11a369fa-dceb-3337-053b-4c2e3e46b3bf@redhat.com> References: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> <17ed1617-b686-368a-b6af-55cb39c720a0@redhat.com> <11a369fa-dceb-3337-053b-4c2e3e46b3bf@redhat.com> Message-ID: Can you give me a couple of test commands? I am not familiar with Dogtag. Groeten, David 2016-11-29 14:57 GMT+01:00 David Kupka : > On 29/11/16 13:55, David Dejaeghere wrote: > >> Correct. Same symptoms. >> >> 2016-11-29T10:29:42Z DEBUG certmonger request is in state >> dbus.String(u'CA_UNREACHABLE', variant_level=1) >> >> Fedora 24 Server >> >> [root at ns02 ~]# dnf history userinstalled >> Packages installed by user >> freeipa-client-4.3.2-2.fc24.x86_64 >> freeipa-server-4.3.2-2.fc24.x86_64 >> grub2-1:2.02-0.34.fc24.x86_64 >> kernel-4.5.5-300.fc24.x86_64 >> kernel-4.8.8-200.fc24.x86_64 >> lvm2-2.02.150-2.fc24.x86_64 >> xfsprogs-4.5.0-2.fc24.x86_64 >> > > Ok. I've reproduced it by simply stopping dogtag on FreeIPA server while > installing the replica. I see the exactly same errors as you've reported > and are described in the ticket, now. > > Is dogtag running on your master? Is in responding (e.g. issuing > certificates for users)? Is it accessible from the replica? > > > >> 2016-11-29 13:41 GMT+01:00 Petr Vobornik : >> >> On 11/29/2016 12:43 PM, David Kupka wrote: >>> >>>> On 29/11/16 12:15, David Dejaeghere wrote: >>>> >>>>> Seems like it is but it does not show a server cert for dirsrv >>>>> >>>>> [root at ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ >>>>> total 468 >>>>> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 65536 >>>>> Nov 29 11:29 cert8.db >>>>> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 65536 >>>>> Nov 29 11:29 cert8.db.orig >>>>> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 1623 >>>>> Nov 29 11:29 certmap.conf >>>>> -rw-------. 1 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >>>>> 89977 >>>>> Nov 29 11:29 dse.ldif >>>>> -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >>>>> 89977 >>>>> Nov 29 11:29 dse.ldif.bak >>>>> -rw-------. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 >>>>> 89977 >>>>> Nov 29 11:29 dse.ldif.startOK >>>>> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 36228 >>>>> Nov 29 11:28 dse_original.ldif >>>>> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 16384 >>>>> Nov 29 11:29 key3.db >>>>> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 16384 >>>>> Nov 29 11:29 key3.db.orig >>>>> -r--------. 1 dirsrv dirsrv >>>>> unconfined_u:object_r:dirsrv_config_t:s0 66 >>>>> Nov 29 11:29 pin.txt >>>>> -rw-------. 1 dirsrv dirsrv >>>>> unconfined_u:object_r:dirsrv_config_t:s0 40 >>>>> Nov 29 11:29 pwdfile.txt >>>>> drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 4096 >>>>> Nov 29 11:29 schema >>>>> -rw-------. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 16384 >>>>> Nov 29 11:29 secmod.db >>>>> -rw-rw----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 16384 >>>>> Nov 29 11:29 secmod.db.orig >>>>> -r--r-----. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 >>>>> 15142 >>>>> Nov 29 11:28 slapd-collations.conf >>>>> >>>>> [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L >>>>> >>>>> Certificate Nickname Trust >>>>> Attributes >>>>> >>>>> SSL,S/MIME,JAR/XPI >>>>> >>>>> CN=something-PAPRIKA-CA,DC=something,DC=local >>>>> CT,C,C >>>>> SOMETHING.BE IPA CA CT,C,C >>>>> [root at ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L >>>>> >>>>> Certificate Nickname Trust >>>>> Attributes >>>>> >>>>> SSL,S/MIME,JAR/XPI >>>>> >>>>> CN=something-PAPRIKA-CA,DC=something,DC=local >>>>> CT,C,C >>>>> SOMETHING.BE IPA CA CT,C,C >>>>> >>>>> [root at ns02 ~]# ausearch -m avc -i >>>>> >>>>> >>>>> >>>>> >>>> Exactly, the NSSDB should be accessible to dirsrv and is missing the >>>> Server-Cert but I don't understand why there's "bad database" error in >>>> the errors log. I'll try to reproduce it. What version of FreeIPA are >>>> you using? On what system? >>>> >>> >>> Right. >>> >>> Seems bit similar to https://fedorahosted.org/freeipa/ticket/6514 would >>> be good to check if it has the same symptoms, mainly >>> certmonger request is in state dbus.String(u'CA_UNREACHABLE', >>> variant_level=1) >>> >>> in replica install log. >>> >>> >>> >>>> >>>>> 2016-11-29 12:09 GMT+01:00 David Kupka : >>>>> >>>>> On 29/11/16 11:51, David Dejaeghere wrote: >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> I have a setup where i want to add a replica. The first master >>>>>>> setup has >>>>>>> an externally signed cert for dirsrv and httpd. The replica is >>>>>>> prepapred >>>>>>> succesfully with ipa-client-install but the replica install then >>>>>>> keeps >>>>>>> failing. It seems that during install dirserv is not configured >>>>>>> correctly >>>>>>> with a valid server certificate. Output from the dirsrv error added >>>>>>> to >>>>>>> this >>>>>>> email as well. >>>>>>> >>>>>>> [root at ns02 ~]# ipa-replica-install --setup-ca >>>>>>> WARNING: conflicting time&date synchronization service 'chronyd' will >>>>>>> be disabled in favor of ntpd >>>>>>> >>>>>>> Run connection check to master >>>>>>> Connection check OK >>>>>>> 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/43]: creating directory server user >>>>>>> [2/43]: creating directory server instance >>>>>>> [3/43]: restarting directory server >>>>>>> [4/43]: adding default schema >>>>>>> [5/43]: enabling memberof plugin >>>>>>> [6/43]: enabling winsync plugin >>>>>>> [7/43]: configuring replication version plugin >>>>>>> [8/43]: enabling IPA enrollment plugin >>>>>>> [9/43]: enabling ldapi >>>>>>> [10/43]: configuring uniqueness plugin >>>>>>> [11/43]: configuring uuid plugin >>>>>>> [12/43]: configuring modrdn plugin >>>>>>> [13/43]: configuring DNS plugin >>>>>>> [14/43]: enabling entryUSN plugin >>>>>>> [15/43]: configuring lockout plugin >>>>>>> [16/43]: configuring topology plugin >>>>>>> [17/43]: creating indices >>>>>>> [18/43]: enabling referential integrity plugin >>>>>>> [19/43]: configuring certmap.conf >>>>>>> [20/43]: configure autobind for root >>>>>>> [21/43]: configure new location for managed entries >>>>>>> [22/43]: configure dirsrv ccache >>>>>>> [23/43]: enabling SASL mapping fallback >>>>>>> [24/43]: restarting directory server >>>>>>> [25/43]: creating DS keytab >>>>>>> [26/43]: retrieving DS Certificate >>>>>>> [27/43]: restarting directory server >>>>>>> ipa : CRITICAL Failed to restart the directory server >>>>>>> (Command >>>>>>> '/bin/systemctl restart dirsrv at SOMETHING-BE.service' returned >>>>>>> >>>>>> non-zero >>> >>>> exit >>>>>>> status 1). See the installation log for details. >>>>>>> [28/43]: setting up initial replication >>>>>>> [error] error: [Errno 111] Connection refused >>>>>>> Your system may be partly configured. >>>>>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>>>>> >>>>>>> >>>>>>> [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security >>>>>>> Initialization: >>>>>>> Can't find certificate (Server-Cert) for family >>>>>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 >>>>>>> >>>>>> - >>> >>>> security library: bad database.) >>>>>>> [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security >>>>>>> Initialization: >>>>>>> Unable to retrieve private key for cert Server-Cert of family >>>>>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 >>>>>>> >>>>>> - >>> >>>> security library: bad database.) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hello David, >>>>>> >>>>>> The error from the log indicates that either the NSSDB for dirsrv is >>>>>> >>>>> not >>> >>>> initialized or not accessible. >>>>>> >>>>>> Could you please send output of the following commands? >>>>>> >>>>>> # ls -lZ /etc/dirsrv/slapd-$REALM/ >>>>>> # certutil -d /etc/dirsrv/slapd-$REALM/ -L >>>>>> # ausearch -m avc -i >>>>>> >>>>>> >>>>>> -- >>>>>> David Kupka >>>>>> >>>>>> >>> >>> -- >>> Petr Vobornik >>> >>> >> > > -- > David Kupka > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giulio at di.unimi.it Tue Nov 29 14:27:04 2016 From: giulio at di.unimi.it (Giulio Casella) Date: Tue, 29 Nov 2016 15:27:04 +0100 Subject: [Freeipa-users] ns-slapd segfault In-Reply-To: <646848ae-e354-07e3-1e9c-f83effbdd261@di.unimi.it> References: <20161128142547.GB30923@10.4.128.1> <8a02a86c-8e62-2d81-3905-14bfdebcfe52@redhat.com> <98c92d9e-fad8-64db-3fba-1c08839af369@di.unimi.it> <27d5e3ca-8dc9-5dcd-1d5d-dba916182cd3@redhat.com> <646848ae-e354-07e3-1e9c-f83effbdd261@di.unimi.it> Message-ID: <631f5dda-c9d0-4f9b-5c84-5941135b9b22@di.unimi.it> Il 29/11/2016 14:46, Giulio Casella ha scritto: > Il 29/11/2016 14:19, Mark Reynolds ha scritto: >> >> >> On 11/29/2016 03:14 AM, Giulio Casella wrote: >>> Il 28/11/2016 19:22, Mark Reynolds ha scritto: >>>> >>>> >>>> On 11/28/2016 10:22 AM, Giulio Casella wrote: >>>>> Il 28/11/2016 15:25, Lukas Slebodnik ha scritto: >>>>>> On (28/11/16 12:39), Giulio Casella wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I have a setup with two ipa server in replica, based on CentOS 7. >>>>>>> On one server (since a couple of days) ipa cannot start, the failing >>>>>>> service >>>>>>> is dirsrv@.service. >>>>>>> In journal I have: >>>>>>> >>>>>>> ns-slapd[4617]: segfault at 7fb53b1ce515 ip 00007fb50126e1a6sp >>>>>>> 00007ffc0b80d6c8 error 4 in libc-2.17.so[7fb501124000+1b7000] >>>>>>> >>>>>>> (just after a lot of SSL alerts complaining about some enabled >>>>>>> cypher suite, >>>>>>> but I cannot say if this could be related). >>>>>>> >>>>>>> I'm using ipa 4.2.0, and 389-ds-base 1.3.4. >>>>>>> >>>>>> It would be good to know the exact version. >>>>>> rpm -q 389-ds-base >>>>> >>>>> Installed version is: >>>>> >>>>> 389-ds-base-1.3.4.0-33.el7_2.x86_64 >>>>> >>>>>> >>>>>> Please provide backtrace or coredump; other developers will know >>>>>> wheter it's know bug or a new bug. >>>>> >>>>> Ok, you can find attached full stacktrace. >>>> It's crashing trying to read updates from the replication changelog. >>>> >>>> Are you using attribute encryption? >>>> Any chance you have a way to reproduce this? >>>> >>>> Since this is happening on only one server then I think recreating the >>>> replication changelog will "fix" the issue. Just re-initializing that >>>> replica should do it. Does this server start - so it can be reinited? >>>> If not, you need to manually remove the changelog and start the >>>> directory server, and reinit it. Or perform a manual ldif >>>> initialization. (I can help with either one if needed) >>>> >>> >>> No, directory server can't start, so I think I have to manually remove >>> the changelog. >> Probably best: >> >> Its under /var/lib/dirsrv/slapd-INSTANCE/db/changelog (something like >> that) >> >>> Any help is obviously welcome. >>> BTW: Do you confirm I won't lose data on second (working) server doing >>> removal of changelog? >> Well the changelog appears to be hosed. So if something is lost, its >> already lost and is not recoverable. As long as you have another master >> you are okay, and IPA only creates masters so you should be good. >> > > Thank you Mark, > I moved away and recreated entire > /var/lib/dirsrv/slapd-INSTANCE/db/changelog directory, rebooted server > and now it's up and running! > For completeness: I've removed also the content of /var/lib/dirsrv/slapd-INSTANCE/cldb (I think cldb stands for changelog database) to make it work. From rkudyba at fordham.edu Tue Nov 29 16:11:56 2016 From: rkudyba at fordham.edu (Robert Kudyba) Date: Tue, 29 Nov 2016 11:11:56 -0500 Subject: [Freeipa-users] attempting to Import Local Accounts into FreeIPA Server on Fedora 25: ipa: ERROR: Could not get User login interactively Message-ID: <626B4808-F136-4C36-B887-9EA500C4024F@fordham.edu> I?m trying to use the script posted on https://shellonearth.net/import-local-accounts-in-freeipa-rhelcentos/. I?m getting the below error. Have the options for ipa user-add changed recently? Here?s what the error looks like in context from the CLI: Password for admin at ourdomain: User login: ipa: ERROR: Could not get User login interactively Here is what?s in the script: ipa user-add $USER --first=$FIRST --last=$LAST --cn="$FULL" --displayname="$FULL" --uid=$UUID --gidnumber=$GID --setattr userpassword='{crypt}$CRYPT' -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Nov 29 16:37:19 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Nov 2016 11:37:19 -0500 Subject: [Freeipa-users] attempting to Import Local Accounts into FreeIPA Server on Fedora 25: ipa: ERROR: Could not get User login interactively In-Reply-To: <626B4808-F136-4C36-B887-9EA500C4024F@fordham.edu> References: <626B4808-F136-4C36-B887-9EA500C4024F@fordham.edu> Message-ID: <583DAEBF.7060203@redhat.com> Robert Kudyba wrote: > I?m trying to use the script posted on > https://shellonearth.net/import-local-accounts-in-freeipa-rhelcentos/. > I?m getting the below error. Have the options for ipa user-add changed > recently? Here?s what the error looks like in context from the CLI: > > Password for admin at ourdomain: > User login: > ipa: ERROR: Could not get User login interactively > > Here is what?s in the script: > > ipa user-add $USER --first=$FIRST --last=$LAST --cn="$FULL" > --displayname="$FULL" --uid=$UUID --gidnumber=$GID --setattr > userpassword='{crypt}$CRYPT' > > Are you sure $USER has a value? It looks like it is falling back on interactive prompting for required fields. rob From john.l.daly at navy.mil Tue Nov 29 18:21:11 2016 From: john.l.daly at navy.mil (Daly, John L CIV NAVAIR, 4G0000D) Date: Tue, 29 Nov 2016 18:21:11 +0000 Subject: [Freeipa-users] Mac OS X 10.12 Smart card authentication to FreeIPA server. Message-ID: <64E450F484A55148AE81AFCE975F216850F3534F@NAWECHLKXM02V.nadsuswe.nads.navy.mil> Greetings, I thumbed through the archive, but didn't find an answer. If I missed it, perhaps someone will be kind enough to point me in the right direction. I'm testing replacing our OpenDirectory server with a FreeIPA server for authenticating our Mac systems. So far, I have the server and client running in a virtual machine (FreeIPA running on CentOS 7, Mac is MacOS 10.12.1), and, following a number of instructions found on the web, they are talking to each other and I can log in from the Mac client to the FreeIPA server with a user account on the FreeIPA server. The final step in this is that I need to use smart card authentication instead of username/password. I have managed to get the smart card's certificate added to the user account on the FreeIPA server, but that's as far as I've managed. In MacOS 10.7-10.11, the method of getting smart card authorization to work is to get the hash of the certificate on the smart card and then add that to AuthenticationAuthority in Directory Utility as ;pubkeyhash; In 10.12, it will actually ask you if you want to pair the smart card with the account, and if so, in the background it adds the hash as ;tokenIdentity; to AuthenticationAuthority (but it only does that to local accounts. to do it in Open Directory, you have to add it manually still) In my ignorance, I'm guessing that I just somehow need to map the certificate that's been added to the user account in FreeIPA to AuthenticationAuthority in DirectoryUtility. Right now the only thing mapped in the bind for AuthenticationAuthority is uid. Could someone tell me what map I would need to make when setting up the bind to make this work? Or if I'm totally heading in the wrong direction, could someone send me in the right direction? Nathan Kinder's blog was very helpful, but he mentions telling how to actually set up login on the next installment, and that was over a year ago and there's no next installment. Most of what I've been able to find covers how to use sssd to get a linux machine to authenticate with the smartcard to FreeIPA, but I haven't been able to translate that to getting the Mac to authenticate. Thank you, John From rkudyba at fordham.edu Tue Nov 29 20:35:14 2016 From: rkudyba at fordham.edu (Robert Kudyba) Date: Tue, 29 Nov 2016 15:35:14 -0500 Subject: [Freeipa-users] attempting to Import Local Accounts into FreeIPA Server on Fedora 25: ipa: ERROR: Could not get User login interactively In-Reply-To: <583DAEBF.7060203@redhat.com> References: <626B4808-F136-4C36-B887-9EA500C4024F@fordham.edu> <583DAEBF.7060203@redhat.com> Message-ID: <33829EC8-8C28-4395-9568-78F83303AED6@fordham.edu> > On Nov 29, 2016, at 11:37 AM, Rob Crittenden wrote: > > Robert Kudyba wrote: >> I? trying to use the script posted on >> https://urldefense.proofpoint.com/v2/url?u=https-3A__shellonearth.net_import-2Dlocal-2Daccounts-2Din-2Dfreeipa-2Drhelcentos_&d=DgIDAw&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=qUO21wyGfiMBRaZk6rjEMSMEMYZB0QpBVyQTCq3U6lw&s=9CmZV-vE0Nle4yup0VrHuHVnMuPNCBaOcJQkR4GzebM&e= . >> I? getting the below error. Have the options for ipa user-add changed >> recently? Here? what the error looks like in context from the CLI: >> >> Password for admin at ourdomain: >> User login: >> ipa: ERROR: Could not get User login interactively >> >> Here is what? in the script: >> >> ipa user-add $USER --first=$FIRST --last=$LAST --cn="$FULL" >> --displayname="$FULL" --uid=$UUID --gidnumber=$GID --setattr >> userpassword='{crypt}$CRYPT' >> >> > > Are you sure $USER has a value? > > It looks like it is falling back on interactive prompting for required > fields. Thanks that gave me a clue. The script was looking for a group ID of 8 characters long I changed it to 4: for line in "$(echo $p | grep "x:[0-9][0-9][0-9][0-9]*:")" # Only grep user accounts with IDs of 4 digits or more But now the script just ?hangs? and no response. I confirmed permissions of the shadow and passwd files and just using 20 login names from each file. Nothing shows up in the user search of the FreeIPA GUI. -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Tue Nov 29 21:16:00 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 29 Nov 2016 22:16:00 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process In-Reply-To: References: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> <17ed1617-b686-368a-b6af-55cb39c720a0@redhat.com> <11a369fa-dceb-3337-053b-4c2e3e46b3bf@redhat.com> Message-ID: <9bc54a14-dd27-fef8-bbaf-be4b918fb7de@redhat.com> On 11/29/2016 03:19 PM, David Dejaeghere wrote: > Can you give me a couple of test commands? > I am not familiar with Dogtag. > Hi, To reproduce the issue: 1. install IPA server 2. On the replica, run ipa-client-install 3. On the server, stop dogtag with $ systemctl stop pki-tomcatd at pki-tomcat.service 4. On the replica, run ipa-replica-install When you want to restart dogtag, you can run $ systemctl start pki-tomcatd at pki-tomcat.service If you want to check if dogtag is running: $ systemctl status pki-tomcatd at pki-tomcat.service You may find more information on Dogtag here: http://pki.fedoraproject.org/wiki/PKI_Main_Page http://pki.fedoraproject.org/wiki/IPA http://pki.fedoraproject.org/wiki/Debugging_the_state_of_dogtag_in_an_ipa_install Flo > Groeten, > > David > > 2016-11-29 14:57 GMT+01:00 David Kupka >: > > On 29/11/16 13:55, David Dejaeghere wrote: > > Correct. Same symptoms. > > 2016-11-29T10:29:42Z DEBUG certmonger request is in state > dbus.String(u'CA_UNREACHABLE', variant_level=1) > > Fedora 24 Server > > [root at ns02 ~]# dnf history userinstalled > Packages installed by user > freeipa-client-4.3.2-2.fc24.x86_64 > freeipa-server-4.3.2-2.fc24.x86_64 > grub2-1:2.02-0.34.fc24.x86_64 > kernel-4.5.5-300.fc24.x86_64 > kernel-4.8.8-200.fc24.x86_64 > lvm2-2.02.150-2.fc24.x86_64 > xfsprogs-4.5.0-2.fc24.x86_64 > > > Ok. I've reproduced it by simply stopping dogtag on FreeIPA server > while installing the replica. I see the exactly same errors as > you've reported and are described in the ticket, now. > > Is dogtag running on your master? Is in responding (e.g. issuing > certificates for users)? Is it accessible from the replica? > > > > 2016-11-29 13:41 GMT+01:00 Petr Vobornik >: > > On 11/29/2016 12:43 PM, David Kupka wrote: > > On 29/11/16 12:15, David Dejaeghere wrote: > > Seems like it is but it does not show a server cert > for dirsrv > > [root at ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ > total 468 > -rw-------. 1 dirsrv root > unconfined_u:object_r:dirsrv_config_t:s0 > 65536 > Nov 29 11:29 cert8.db > -rw-rw----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 65536 > Nov 29 11:29 cert8.db.orig > -r--r-----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 1623 > Nov 29 11:29 certmap.conf > -rw-------. 1 dirsrv dirsrv > system_u:object_r:dirsrv_config_t:s0 > 89977 > Nov 29 11:29 dse.ldif > -rw-------. 2 dirsrv dirsrv > system_u:object_r:dirsrv_config_t:s0 > 89977 > Nov 29 11:29 dse.ldif.bak > -rw-------. 2 dirsrv dirsrv > system_u:object_r:dirsrv_config_t:s0 > 89977 > Nov 29 11:29 dse.ldif.startOK > -r--r-----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 36228 > Nov 29 11:28 dse_original.ldif > -rw-------. 1 dirsrv root > unconfined_u:object_r:dirsrv_config_t:s0 > 16384 > Nov 29 11:29 key3.db > -rw-rw----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 16384 > Nov 29 11:29 key3.db.orig > -r--------. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 66 > Nov 29 11:29 pin.txt > -rw-------. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 40 > Nov 29 11:29 pwdfile.txt > drwxrwx---. 2 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 4096 > Nov 29 11:29 schema > -rw-------. 1 dirsrv root > unconfined_u:object_r:dirsrv_config_t:s0 > 16384 > Nov 29 11:29 secmod.db > -rw-rw----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 16384 > Nov 29 11:29 secmod.db.orig > -r--r-----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 15142 > Nov 29 11:28 slapd-collations.conf > > [root at ns02 ~]# certutil -d > /etc/dirsrv/slapd-SOMETHING-BE -L > > Certificate Nickname > Trust > Attributes > > SSL,S/MIME,JAR/XPI > > CN=something-PAPRIKA-CA,DC=something,DC=local > CT,C,C > SOMETHING.BE IPA CA > CT,C,C > [root at ns02 ~]# certutil -d > /etc/dirsrv/slapd-SOMETHING-BE -L > > Certificate Nickname > Trust > Attributes > > SSL,S/MIME,JAR/XPI > > CN=something-PAPRIKA-CA,DC=something,DC=local > CT,C,C > SOMETHING.BE IPA CA > CT,C,C > > [root at ns02 ~]# ausearch -m avc -i > > > > > Exactly, the NSSDB should be accessible to dirsrv and is > missing the > Server-Cert but I don't understand why there's "bad > database" error in > the errors log. I'll try to reproduce it. What version > of FreeIPA are > you using? On what system? > > > Right. > > Seems bit similar to > https://fedorahosted.org/freeipa/ticket/6514 > would > be good to check if it has the same symptoms, mainly > certmonger request is in state dbus.String(u'CA_UNREACHABLE', > variant_level=1) > > in replica install log. > > > > > 2016-11-29 12:09 GMT+01:00 David Kupka > >: > > On 29/11/16 11:51, David Dejaeghere wrote: > > Hi, > > I have a setup where i want to add a > replica. The first master > setup has > an externally signed cert for dirsrv and > httpd. The replica is > prepapred > succesfully with ipa-client-install but the > replica install then keeps > failing. It seems that during install > dirserv is not configured > correctly > with a valid server certificate. Output from > the dirsrv error added to > this > email as well. > > [root at ns02 ~]# ipa-replica-install --setup-ca > WARNING: conflicting time&date > synchronization service 'chronyd' will > be disabled in favor of ntpd > > Run connection check to master > Connection check OK > 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/43]: creating directory server user > [2/43]: creating directory server instance > [3/43]: restarting directory server > [4/43]: adding default schema > [5/43]: enabling memberof plugin > [6/43]: enabling winsync plugin > [7/43]: configuring replication version plugin > [8/43]: enabling IPA enrollment plugin > [9/43]: enabling ldapi > [10/43]: configuring uniqueness plugin > [11/43]: configuring uuid plugin > [12/43]: configuring modrdn plugin > [13/43]: configuring DNS plugin > [14/43]: enabling entryUSN plugin > [15/43]: configuring lockout plugin > [16/43]: configuring topology plugin > [17/43]: creating indices > [18/43]: enabling referential integrity plugin > [19/43]: configuring certmap.conf > [20/43]: configure autobind for root > [21/43]: configure new location for > managed entries > [22/43]: configure dirsrv ccache > [23/43]: enabling SASL mapping fallback > [24/43]: restarting directory server > [25/43]: creating DS keytab > [26/43]: retrieving DS Certificate > [27/43]: restarting directory server > ipa : CRITICAL Failed to restart the > directory server (Command > '/bin/systemctl restart > dirsrv at SOMETHING-BE.service' returned > > non-zero > > exit > status 1). See the installation log for details. > [28/43]: setting up initial replication > [error] error: [Errno 111] Connection refused > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall > to clean up. > > > [29/Nov/2016:11:29:44.034285579 +0100] SSL > alert: Security > Initialization: > Can't find certificate (Server-Cert) for family > cn=RSA,cn=encryption,cn=config (Netscape > Portable Runtime error -8174 > > - > > security library: bad database.) > [29/Nov/2016:11:29:44.045039728 +0100] SSL > alert: Security > Initialization: > Unable to retrieve private key for cert > Server-Cert of family > cn=RSA,cn=encryption,cn=config (Netscape > Portable Runtime error -8174 > > - > > security library: bad database.) > > > > > Hello David, > > The error from the log indicates that either the > NSSDB for dirsrv is > > not > > initialized or not accessible. > > Could you please send output of the following > commands? > > # ls -lZ /etc/dirsrv/slapd-$REALM/ > # certutil -d /etc/dirsrv/slapd-$REALM/ -L > # ausearch -m avc -i > > > -- > David Kupka > > > > -- > Petr Vobornik > > > > > -- > David Kupka > > > > From slaznick at redhat.com Wed Nov 30 07:49:46 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Wed, 30 Nov 2016 08:49:46 +0100 Subject: [Freeipa-users] attempting to Import Local Accounts into FreeIPA Server on Fedora 25: ipa: ERROR: Could not get User login interactively In-Reply-To: <33829EC8-8C28-4395-9568-78F83303AED6@fordham.edu> References: <626B4808-F136-4C36-B887-9EA500C4024F@fordham.edu> <583DAEBF.7060203@redhat.com> <33829EC8-8C28-4395-9568-78F83303AED6@fordham.edu> Message-ID: <26c4dbfa-fca7-0ece-eb1e-79f7ab300a3e@redhat.com> On 11/29/2016 09:35 PM, Robert Kudyba wrote: > >> On Nov 29, 2016, at 11:37 AM, Rob Crittenden > > wrote: >> >> Robert Kudyba wrote: >>> I? trying to use the script posted on >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__shellonearth.net_import-2Dlocal-2Daccounts-2Din-2Dfreeipa-2Drhelcentos_&d=DgIDAw&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=qUO21wyGfiMBRaZk6rjEMSMEMYZB0QpBVyQTCq3U6lw&s=9CmZV-vE0Nle4yup0VrHuHVnMuPNCBaOcJQkR4GzebM&e= >>> . >>> I? getting the below error. Have the options for ipa user-add changed >>> recently? Here? what the error looks like in context from the CLI: >>> >>> Password for admin at ourdomain: >>> User login: >>> ipa: ERROR: Could not get User login interactively >>> >>> Here is what? in the script: >>> >>> ipa user-add $USER --first=$FIRST --last=$LAST --cn="$FULL" >>> --displayname="$FULL" --uid=$UUID --gidnumber=$GID --setattr >>> userpassword='{crypt}$CRYPT' >>> >>> >> >> Are you sure $USER has a value? >> >> It looks like it is falling back on interactive prompting for required >> fields. > > Thanks that gave me a clue. The script was looking for a group ID of 8 > characters long I changed it to 4: > forline in"$(echo $p | grep "x:[0-9][0-9][0-9][0-9]*:")"# Only grep > user accounts with IDs of 4 digits or more > > But now the script just ?hangs? and no response. I confirmed > permissions of the shadow and passwd files and just using 20 login > names from each file. Nothing shows up in the user search of the > FreeIPA GUI. > > > Well, I may not be that fluent in bash as I used to be, but from what I see here, it's quite obvious. Line 39 - you have a `while read p` part there that waits for input from stdin. That's where you hang. How you managed to get to `ipa user-add` line before I am not really certain. Did you perhaps mean to read from /tmp/passwd or /tmp/shadow on L39? :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Nov 30 08:46:42 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 30 Nov 2016 09:46:42 +0100 Subject: [Freeipa-users] Mac OS X 10.12 Smart card authentication to FreeIPA server. In-Reply-To: <64E450F484A55148AE81AFCE975F216850F3534F@NAWECHLKXM02V.nadsuswe.nads.navy.mil> References: <64E450F484A55148AE81AFCE975F216850F3534F@NAWECHLKXM02V.nadsuswe.nads.navy.mil> Message-ID: <20161130084642.GD21759@p.Speedport_W_724V_Typ_A_05011603_00_009> On Tue, Nov 29, 2016 at 06:21:11PM +0000, Daly, John L CIV NAVAIR, 4G0000D wrote: > Greetings, > I thumbed through the archive, but didn't find an answer. If I missed it, perhaps someone will be kind enough to point me in the right direction. > > I'm testing replacing our OpenDirectory server with a FreeIPA server for authenticating our Mac systems. So far, I have the server and client running in a virtual machine (FreeIPA running on CentOS 7, Mac is MacOS 10.12.1), and, following a number of instructions found on the web, they are talking to each other and I can log in from the Mac client to the FreeIPA server with a user account on the FreeIPA server. > > The final step in this is that I need to use smart card authentication instead of username/password. I have managed to get the smart card's certificate added to the user account on the FreeIPA server, but that's as far as I've managed. > > In MacOS 10.7-10.11, the method of getting smart card authorization to work is to get the hash of the certificate on the smart card and then add that to AuthenticationAuthority in Directory Utility as ;pubkeyhash; > In 10.12, it will actually ask you if you want to pair the smart card with the account, and if so, in the background it adds the hash as ;tokenIdentity; to AuthenticationAuthority (but it only does that to local accounts. to do it in Open Directory, you have to add it manually still) > > In my ignorance, I'm guessing that I just somehow need to map the certificate that's been added to the user account in FreeIPA to AuthenticationAuthority in DirectoryUtility. Right now the only thing mapped in the bind for AuthenticationAuthority is uid. Can you send me an example of an user object from OpenDirectory which has all the needed attributes to make Smartcard authentication work? bye, Sumit > > Could someone tell me what map I would need to make when setting up the bind to make this work? Or if I'm totally heading in the wrong direction, could someone send me in the right direction? > > Nathan Kinder's blog was very helpful, but he mentions telling how to actually set up login on the next installment, and that was over a year ago and there's no next installment. Most of what I've been able to find covers how to use sssd to get a linux machine to authenticate with the smartcard to FreeIPA, but I haven't been able to translate that to getting the Mac to authenticate. > > Thank you, > John > > -- > 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 dkupka at redhat.com Wed Nov 30 09:13:16 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 30 Nov 2016 10:13:16 +0100 Subject: [Freeipa-users] OTP Algorithm In-Reply-To: References: <79cd7b7f-3fc7-84f9-4762-75cd386a0cac@redhat.com> <20161129115126.lboewmlkco2ufa4s@redhat.com> Message-ID: <7ec15f84-a3ee-5a14-2653-f320a49702b2@redhat.com> On 29/11/16 12:57, Callum Guy wrote: > Hi Alexander, > > I can confirm that I am using version 4.2.0. > > The bug link provided mentions that it caused GA to fail to scan the codes. > In my situation it is FreeIPA (or related service) which appears to fail to > validate codes generated, meaning that only OTP codes generated using sha1 > are validated and accepted. > > Just for clarity I can confirm that I have only tested OTP codes generated > and configured via the FreeIPA web interface. I will check the command line > generation and let you know if this makes a difference. > > Best Regards, > > Callum Hello Callum, I've tried it with FreeIPA 4.3.2 (stock Fedora 24) and FreeOTP. I've generated 3 OTPs (with sha256, sha384 and sha512) for tuser in the WebUI and was then able to login into WebUI without problems. $ ipa otptoken-find --owner tuser --all -------------------- 3 OTP tokens matched -------------------- dn: ipatokenuniqueid=3c899764-7abf-459d-bf2b-7ba4af978a8b,cn=otp,dc=dom-058-216,dc=example,dc=com Unique ID: 3c899764-7abf-459d-bf2b-7ba4af978a8b Type: TOTP Owner: tuser Key: U5XDN0BYc9KbvG1iYuVPuVHB448= Algorithm: sha256 Digits: 6 Clock offset: 0 Clock interval: 30 ipatokentotpwatermark: 49349880 objectclass: top, ipatokentotp, ipatoken dn: ipatokenuniqueid=40ad189b-7b7c-44b9-8450-b3eb78057ef6,cn=otp,dc=dom-058-216,dc=example,dc=com Unique ID: 40ad189b-7b7c-44b9-8450-b3eb78057ef6 Type: TOTP Owner: tuser Key: C79y2W+I0z429eRzsRP7qdpROaI= Algorithm: sha512 Digits: 6 Clock offset: 0 Clock interval: 30 ipatokentotpwatermark: 49349882 objectclass: top, ipatokentotp, ipatoken dn: ipatokenuniqueid=baf6d329-61ad-46f1-beca-6ddb55ba9bb4,cn=otp,dc=dom-058-216,dc=example,dc=com Unique ID: baf6d329-61ad-46f1-beca-6ddb55ba9bb4 Type: TOTP Owner: tuser Key: 2hxrsJjQ6e+3qzVPZremtsB/NCg= Algorithm: sha384 Digits: 6 Clock offset: 0 Clock interval: 30 ipatokentotpwatermark: 49349881 objectclass: top, ipatokentotp, ipatoken > > > On Tue, Nov 29, 2016 at 11:51 AM Alexander Bokovoy > wrote: > >> On ti, 29 marras 2016, Callum Guy wrote: >>> Hi Petr, >>> >>> Thanks for coming back to me on this. >>> >>> I have only tried using Google Authenticator. The generated QR code >>> successfully scans and codes are then generated on the GA device as >> normal. >>> The problem is that the codes simply do not work. >>> >>> My current thinking is that the service which interprets the codes >>> server-side is not configured to use the same algorithm meaning that it is >>> trying to validate sha256/sha512 (both tested and not functional for me) >>> etc codes against codes perhaps generated with sha1 (the only algorithm >>> that appears to work). >>> >>> I apologise in advance for my naive interpretation of the situation, this >>> really isn't an area where i have experience. I'd love to understand whats >>> going on however I can't find what i need in the OTP documentation. >> Which IPA version we are talking about? There was a case when the URI >> generated by 'ipa otptoken-add' was using a wrong case in the algorithm >> value and this was breaking Google Authenticator. >> >> https://fedorahosted.org/freeipa/ticket/5047 >> >> This bug was fixed since 4.1.5 release. >> >>> >>> Best Regards, >>> >>> Callum >>> >>> >>> On Tue, Nov 29, 2016 at 11:10 AM Petr Vobornik >> wrote: >>> >>>> On 11/28/2016 01:03 PM, Callum Guy wrote: >>>>> Hi All, >>>>> >>>>> I wanted to ask a quick question - perhaps a more experienced user >> will >>>> be able >>>>> to help or point me to the correct documentation. >>>>> >>>>> Basically we have implemented password+OTP type authentication which >>>> works great. >>>>> >>>>> When adding a OTP code using the admin login you can choose an >>>> algorithm. For us >>>>> the generated codes only work properly if the weakest sha1 algorithm >> is >>>> chosen/ >>>>> To be clear the code generation works fine but the codes are not valid >>>> when >>>>> logging in. Is there a related setting we must change? >>>>> >>>>> Thanks, >>>>> >>>>> Callum >>>>> >>>> >>>> What type of otp token do you use? Does it work with some different? >>>> E.g. FreeOTP vs Google Authenticator ... >>>> >>>> >>>> -- >>>> Petr Vobornik >>>> >>> >>> -- >>> >>> >>> >>> *0333 332 0000 | www.x-on.co.uk | ** >>> >>> >>> * >>> X-on is a trading name of Storacall Technology Ltd a limited company >>> registered in England and Wales. >>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >>> The information in this e-mail is confidential and for use by the >>> addressee(s) only. If you are not the intended recipient, please notify >>> X-on immediately on +44(0)333 332 0000 <+44%20333%20332%200000> and >> delete the >>> message from your computer. If you are not a named addressee you must not >>> use, disclose, disseminate, distribute, copy, print or reply to this >> email. Views >>> or opinions expressed by an individual >>> within this email may not necessarily reflect the views of X-on or its >>> associated companies. Although X-on routinely screens for viruses, >>> addressees should scan this email and any attachments >>> for viruses. X-on makes no representation or warranty as to the absence of >>> viruses in this email or any attachments. >>> >> >>> -- >>> 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 >> > > > -- David Kupka From dkupka at redhat.com Wed Nov 30 13:11:42 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 30 Nov 2016 14:11:42 +0100 Subject: [Freeipa-users] OTP Algorithm In-Reply-To: <7ec15f84-a3ee-5a14-2653-f320a49702b2@redhat.com> References: <79cd7b7f-3fc7-84f9-4762-75cd386a0cac@redhat.com> <20161129115126.lboewmlkco2ufa4s@redhat.com> <7ec15f84-a3ee-5a14-2653-f320a49702b2@redhat.com> Message-ID: <587018a7-ad4e-370c-ba9b-6465900cc644@redhat.com> On 30/11/16 10:13, David Kupka wrote: > On 29/11/16 12:57, Callum Guy wrote: >> Hi Alexander, >> >> I can confirm that I am using version 4.2.0. >> >> The bug link provided mentions that it caused GA to fail to scan the >> codes. >> In my situation it is FreeIPA (or related service) which appears to >> fail to >> validate codes generated, meaning that only OTP codes generated using >> sha1 >> are validated and accepted. >> >> Just for clarity I can confirm that I have only tested OTP codes >> generated >> and configured via the FreeIPA web interface. I will check the command >> line >> generation and let you know if this makes a difference. >> >> Best Regards, >> >> Callum > > Hello Callum, > I've tried it with FreeIPA 4.3.2 (stock Fedora 24) and FreeOTP. I've > generated 3 OTPs (with sha256, sha384 and sha512) for tuser in the WebUI > and was then able to login into WebUI without problems. > > > $ ipa otptoken-find --owner tuser --all > -------------------- > 3 OTP tokens matched > -------------------- > dn: > ipatokenuniqueid=3c899764-7abf-459d-bf2b-7ba4af978a8b,cn=otp,dc=dom-058-216,dc=example,dc=com > > Unique ID: 3c899764-7abf-459d-bf2b-7ba4af978a8b > Type: TOTP > Owner: tuser > Key: U5XDN0BYc9KbvG1iYuVPuVHB448= > Algorithm: sha256 > Digits: 6 > Clock offset: 0 > Clock interval: 30 > ipatokentotpwatermark: 49349880 > objectclass: top, ipatokentotp, ipatoken > > dn: > ipatokenuniqueid=40ad189b-7b7c-44b9-8450-b3eb78057ef6,cn=otp,dc=dom-058-216,dc=example,dc=com > > Unique ID: 40ad189b-7b7c-44b9-8450-b3eb78057ef6 > Type: TOTP > Owner: tuser > Key: C79y2W+I0z429eRzsRP7qdpROaI= > Algorithm: sha512 > Digits: 6 > Clock offset: 0 > Clock interval: 30 > ipatokentotpwatermark: 49349882 > objectclass: top, ipatokentotp, ipatoken > > dn: > ipatokenuniqueid=baf6d329-61ad-46f1-beca-6ddb55ba9bb4,cn=otp,dc=dom-058-216,dc=example,dc=com > > Unique ID: baf6d329-61ad-46f1-beca-6ddb55ba9bb4 > Type: TOTP > Owner: tuser > Key: 2hxrsJjQ6e+3qzVPZremtsB/NCg= > Algorithm: sha384 > Digits: 6 > Clock offset: 0 > Clock interval: 30 > ipatokentotpwatermark: 49349881 > objectclass: top, ipatokentotp, ipatoken I've tried with Google Authenicator too and was unable to login. Alexander found issue [1] asking for SHA256 support. From comment on the issue it appear that SHA1 is the only supported hash. I compared codes generated by oathtool [2] and find out that Google Authenticator just ignores the information about used hash function and uses SHA1 without any error or warning. So I can only recommend switching to FreeOTP or returning to SHA-1 hash function. [1] https://github.com/google/google-authenticator-libpam/issues/11 [2] http://www.nongnu.org/oath-toolkit/oathtool.1.html > > >> >> >> On Tue, Nov 29, 2016 at 11:51 AM Alexander Bokovoy >> wrote: >> >>> On ti, 29 marras 2016, Callum Guy wrote: >>>> Hi Petr, >>>> >>>> Thanks for coming back to me on this. >>>> >>>> I have only tried using Google Authenticator. The generated QR code >>>> successfully scans and codes are then generated on the GA device as >>> normal. >>>> The problem is that the codes simply do not work. >>>> >>>> My current thinking is that the service which interprets the codes >>>> server-side is not configured to use the same algorithm meaning that >>>> it is >>>> trying to validate sha256/sha512 (both tested and not functional for >>>> me) >>>> etc codes against codes perhaps generated with sha1 (the only algorithm >>>> that appears to work). >>>> >>>> I apologise in advance for my naive interpretation of the situation, >>>> this >>>> really isn't an area where i have experience. I'd love to understand >>>> whats >>>> going on however I can't find what i need in the OTP documentation. >>> Which IPA version we are talking about? There was a case when the URI >>> generated by 'ipa otptoken-add' was using a wrong case in the algorithm >>> value and this was breaking Google Authenticator. >>> >>> https://fedorahosted.org/freeipa/ticket/5047 >>> >>> This bug was fixed since 4.1.5 release. >>> >>>> >>>> Best Regards, >>>> >>>> Callum >>>> >>>> >>>> On Tue, Nov 29, 2016 at 11:10 AM Petr Vobornik >>> wrote: >>>> >>>>> On 11/28/2016 01:03 PM, Callum Guy wrote: >>>>>> Hi All, >>>>>> >>>>>> I wanted to ask a quick question - perhaps a more experienced user >>> will >>>>> be able >>>>>> to help or point me to the correct documentation. >>>>>> >>>>>> Basically we have implemented password+OTP type authentication which >>>>> works great. >>>>>> >>>>>> When adding a OTP code using the admin login you can choose an >>>>> algorithm. For us >>>>>> the generated codes only work properly if the weakest sha1 algorithm >>> is >>>>> chosen/ >>>>>> To be clear the code generation works fine but the codes are not >>>>>> valid >>>>> when >>>>>> logging in. Is there a related setting we must change? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Callum >>>>>> >>>>> >>>>> What type of otp token do you use? Does it work with some different? >>>>> E.g. FreeOTP vs Google Authenticator ... >>>>> >>>>> >>>>> -- >>>>> Petr Vobornik >>>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *0333 332 0000 | www.x-on.co.uk | ** >>>> >>>> >>>> * >>>> X-on is a trading name of Storacall Technology Ltd a limited company >>>> registered in England and Wales. >>>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>>> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >>>> The information in this e-mail is confidential and for use by the >>>> addressee(s) only. If you are not the intended recipient, please notify >>>> X-on immediately on +44(0)333 332 0000 <+44%20333%20332%200000> and >>> delete the >>>> message from your computer. If you are not a named addressee you >>>> must not >>>> use, disclose, disseminate, distribute, copy, print or reply to this >>> email. Views >>>> or opinions expressed by an individual >>>> within this email may not necessarily reflect the views of X-on or its >>>> associated companies. Although X-on routinely screens for viruses, >>>> addressees should scan this email and any attachments >>>> for viruses. X-on makes no representation or warranty as to the >>>> absence of >>>> viruses in this email or any attachments. >>>> >>> >>>> -- >>>> 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 >>> >> >> >> > > -- David Kupka From rcritten at redhat.com Wed Nov 30 13:34:01 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Nov 2016 08:34:01 -0500 Subject: [Freeipa-users] attempting to Import Local Accounts into FreeIPA Server on Fedora 25: ipa: ERROR: Could not get User login interactively In-Reply-To: <26c4dbfa-fca7-0ece-eb1e-79f7ab300a3e@redhat.com> References: <626B4808-F136-4C36-B887-9EA500C4024F@fordham.edu> <583DAEBF.7060203@redhat.com> <33829EC8-8C28-4395-9568-78F83303AED6@fordham.edu> <26c4dbfa-fca7-0ece-eb1e-79f7ab300a3e@redhat.com> Message-ID: <583ED549.7020603@redhat.com> Standa Laznicka wrote: > On 11/29/2016 09:35 PM, Robert Kudyba wrote: >> >>> On Nov 29, 2016, at 11:37 AM, Rob Crittenden >> > wrote: >>> >>> Robert Kudyba wrote: >>>> I? trying to use the script posted on >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__shellonearth.net_import-2Dlocal-2Daccounts-2Din-2Dfreeipa-2Drhelcentos_&d=DgIDAw&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=qUO21wyGfiMBRaZk6rjEMSMEMYZB0QpBVyQTCq3U6lw&s=9CmZV-vE0Nle4yup0VrHuHVnMuPNCBaOcJQkR4GzebM&e= >>>> . >>>> I? getting the below error. Have the options for ipa user-add changed >>>> recently? Here? what the error looks like in context from the CLI: >>>> >>>> Password for admin at ourdomain: >>>> User login: >>>> ipa: ERROR: Could not get User login interactively >>>> >>>> Here is what? in the script: >>>> >>>> ipa user-add $USER --first=$FIRST --last=$LAST --cn="$FULL" >>>> --displayname="$FULL" --uid=$UUID --gidnumber=$GID --setattr >>>> userpassword='{crypt}$CRYPT' >>>> >>>> >>> >>> Are you sure $USER has a value? >>> >>> It looks like it is falling back on interactive prompting for required >>> fields. >> >> Thanks that gave me a clue. The script was looking for a group ID of 8 >> characters long I changed it to 4: >> forline in"$(echo $p | grep "x:[0-9][0-9][0-9][0-9]*:")"# Only grep >> user accounts with IDs of 4 digits or more >> >> But now the script just ?hangs? and no response. I confirmed >> permissions of the shadow and passwd files and just using 20 login >> names from each file. Nothing shows up in the user search of the >> FreeIPA GUI. >> >> >> > Well, I may not be that fluent in bash as I used to be, but from what I > see here, it's quite obvious. Line 39 - you have a `while read p` part > there that waits for input from stdin. That's where you hang. How you > managed to get to `ipa user-add` line before I am not really certain. > > Did you perhaps mean to read from /tmp/passwd or /tmp/shadow on L39? :) > Check out his blog, he has an updated script. He was missing a < before $PASSWORD at the end. It still seems really fragile to me. I've attached a python script I wrote ages ago to do a similar import. You'd need to add your regex but this worked last I tried and is more performant when importing a lot of users because it does them in batches. rob -------------- next part -------------- #!/usr/bin/python # import re import sys import tempfile from ipalib.dn import DN from ipalib import api, errors bulksize = 50 name_pattern = re.compile('(\w+) \w (\w+)') if len(sys.argv) != 2: sys.exit("Usage: %s " % sys.argv[0]) filename=sys.argv[1] api.bootstrap(context='cli') api.finalize() api.Backend.xmlclient.connect() def process_batch(batch): try: results = api.Command['batch'](batch)['results'] for result in results: if result['error'] and 'already exists' not in result['error']: print result['error'] elif 'completed' in results: if result['completed'] > 0: print "New members added to group %s" % result['result']['cn'] elif 'failed' in result and len(result['failed']['member']['user']) > 0 and 'not allowed' in result['failed']['member']['user'][0][1]: print "Cannot add members to a user-private group: %s" % result['result']['cn'] except errors.NetworkError, e: print "FAIL: connection error trying to run batch: %s" % e except errors.LimitsExceeded: # This was probably thrown in the post_callback, it isn't critical print 'Limits error' except KeyboardInterrupt: sys.exit("quitting") batch = [] count = 0 fd = open(filename, 'r') while True: line = fd.readline() if not line: break line = unicode(line.strip()) (uid, line) = line.split(' ', 1) try: (login, passwd, uid, gid, gecos, dir, shell) = line.split(':') except ValueError, e: print "mal-formed passwd entry: %s (%s)" % (e, line) continue m = name_pattern.match(gecos) if m: first = m.group(1) last = m.group(2) else: first = u'NIS' last = u'USER' batch.append(dict(method='user_add', params=([login], dict(gidnumber=int(gid), uidnumber=int(uid), gecos=gecos.strip(), homedir=dir, shell=shell, givenname=first, sn=last, noprivate=u'true', addattr='userPassword={crypt}%s' % passwd)))) count += 1 if count % bulksize == 0: process_batch(batch) batch = [] print "%d users" % count if batch: process_batch(batch) fd.close() From david.dejaeghere at gmail.com Wed Nov 30 14:27:16 2016 From: david.dejaeghere at gmail.com (David Dejaeghere) Date: Wed, 30 Nov 2016 15:27:16 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process In-Reply-To: <9bc54a14-dd27-fef8-bbaf-be4b918fb7de@redhat.com> References: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> <17ed1617-b686-368a-b6af-55cb39c720a0@redhat.com> <11a369fa-dceb-3337-053b-4c2e3e46b3bf@redhat.com> <9bc54a14-dd27-fef8-bbaf-be4b918fb7de@redhat.com> Message-ID: Hi, The Pki service is running and I cannot find any issues with it. I can run a curl request to the master hostname on port 8443 and communication works fine. Any other idea why this replica install code would fail and log CA_UNREACHABLE? Regards, David 2016-11-29 22:16 GMT+01:00 Florence Blanc-Renaud : > On 11/29/2016 03:19 PM, David Dejaeghere wrote: > >> Can you give me a couple of test commands? >> I am not familiar with Dogtag. >> >> Hi, > > To reproduce the issue: > 1. install IPA server > 2. On the replica, run ipa-client-install > 3. On the server, stop dogtag with > $ systemctl stop pki-tomcatd at pki-tomcat.service > 4. On the replica, run ipa-replica-install > > When you want to restart dogtag, you can run > $ systemctl start pki-tomcatd at pki-tomcat.service > > If you want to check if dogtag is running: > $ systemctl status pki-tomcatd at pki-tomcat.service > > You may find more information on Dogtag here: > http://pki.fedoraproject.org/wiki/PKI_Main_Page > http://pki.fedoraproject.org/wiki/IPA > http://pki.fedoraproject.org/wiki/Debugging_the_state_of_dog > tag_in_an_ipa_install > > Flo > > Groeten, >> >> David >> >> 2016-11-29 14:57 GMT+01:00 David Kupka > >: >> >> On 29/11/16 13:55, David Dejaeghere wrote: >> >> Correct. Same symptoms. >> >> 2016-11-29T10:29:42Z DEBUG certmonger request is in state >> dbus.String(u'CA_UNREACHABLE', variant_level=1) >> >> Fedora 24 Server >> >> [root at ns02 ~]# dnf history userinstalled >> Packages installed by user >> freeipa-client-4.3.2-2.fc24.x86_64 >> freeipa-server-4.3.2-2.fc24.x86_64 >> grub2-1:2.02-0.34.fc24.x86_64 >> kernel-4.5.5-300.fc24.x86_64 >> kernel-4.8.8-200.fc24.x86_64 >> lvm2-2.02.150-2.fc24.x86_64 >> xfsprogs-4.5.0-2.fc24.x86_64 >> >> >> Ok. I've reproduced it by simply stopping dogtag on FreeIPA server >> while installing the replica. I see the exactly same errors as >> you've reported and are described in the ticket, now. >> >> Is dogtag running on your master? Is in responding (e.g. issuing >> certificates for users)? Is it accessible from the replica? >> >> >> >> 2016-11-29 13:41 GMT+01:00 Petr Vobornik > >: >> >> >> On 11/29/2016 12:43 PM, David Kupka wrote: >> >> On 29/11/16 12:15, David Dejaeghere wrote: >> >> Seems like it is but it does not show a server cert >> for dirsrv >> >> [root at ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ >> total 468 >> -rw-------. 1 dirsrv root >> unconfined_u:object_r:dirsrv_config_t:s0 >> 65536 >> Nov 29 11:29 cert8.db >> -rw-rw----. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >> 65536 >> Nov 29 11:29 cert8.db.orig >> -r--r-----. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >> 1623 >> Nov 29 11:29 certmap.conf >> -rw-------. 1 dirsrv dirsrv >> system_u:object_r:dirsrv_config_t:s0 >> 89977 >> Nov 29 11:29 dse.ldif >> -rw-------. 2 dirsrv dirsrv >> system_u:object_r:dirsrv_config_t:s0 >> 89977 >> Nov 29 11:29 dse.ldif.bak >> -rw-------. 2 dirsrv dirsrv >> system_u:object_r:dirsrv_config_t:s0 >> 89977 >> Nov 29 11:29 dse.ldif.startOK >> -r--r-----. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >> 36228 >> Nov 29 11:28 dse_original.ldif >> -rw-------. 1 dirsrv root >> unconfined_u:object_r:dirsrv_config_t:s0 >> 16384 >> Nov 29 11:29 key3.db >> -rw-rw----. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >> 16384 >> Nov 29 11:29 key3.db.orig >> -r--------. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 66 >> Nov 29 11:29 pin.txt >> -rw-------. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 40 >> Nov 29 11:29 pwdfile.txt >> drwxrwx---. 2 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >> 4096 >> Nov 29 11:29 schema >> -rw-------. 1 dirsrv root >> unconfined_u:object_r:dirsrv_config_t:s0 >> 16384 >> Nov 29 11:29 secmod.db >> -rw-rw----. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >> 16384 >> Nov 29 11:29 secmod.db.orig >> -r--r-----. 1 dirsrv dirsrv >> unconfined_u:object_r:dirsrv_config_t:s0 >> 15142 >> Nov 29 11:28 slapd-collations.conf >> >> [root at ns02 ~]# certutil -d >> /etc/dirsrv/slapd-SOMETHING-BE -L >> >> Certificate Nickname >> Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> CN=something-PAPRIKA-CA,DC=something,DC=local >> CT,C,C >> SOMETHING.BE IPA CA >> CT,C,C >> [root at ns02 ~]# certutil -d >> /etc/dirsrv/slapd-SOMETHING-BE -L >> >> Certificate Nickname >> Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> CN=something-PAPRIKA-CA,DC=something,DC=local >> CT,C,C >> SOMETHING.BE IPA CA >> CT,C,C >> >> [root at ns02 ~]# ausearch -m avc -i >> >> >> >> >> Exactly, the NSSDB should be accessible to dirsrv and is >> missing the >> Server-Cert but I don't understand why there's "bad >> database" error in >> the errors log. I'll try to reproduce it. What version >> of FreeIPA are >> you using? On what system? >> >> >> Right. >> >> Seems bit similar to >> https://fedorahosted.org/freeipa/ticket/6514 >> would >> be good to check if it has the same symptoms, mainly >> certmonger request is in state >> dbus.String(u'CA_UNREACHABLE', >> variant_level=1) >> >> in replica install log. >> >> >> >> >> 2016-11-29 12:09 GMT+01:00 David Kupka >> >: >> >> >> On 29/11/16 11:51, David Dejaeghere wrote: >> >> Hi, >> >> I have a setup where i want to add a >> replica. The first master >> setup has >> an externally signed cert for dirsrv and >> httpd. The replica is >> prepapred >> succesfully with ipa-client-install but the >> replica install then keeps >> failing. It seems that during install >> dirserv is not configured >> correctly >> with a valid server certificate. Output from >> the dirsrv error added to >> this >> email as well. >> >> [root at ns02 ~]# ipa-replica-install --setup-ca >> WARNING: conflicting time&date >> synchronization service 'chronyd' will >> be disabled in favor of ntpd >> >> Run connection check to master >> Connection check OK >> 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/43]: creating directory server user >> [2/43]: creating directory server instance >> [3/43]: restarting directory server >> [4/43]: adding default schema >> [5/43]: enabling memberof plugin >> [6/43]: enabling winsync plugin >> [7/43]: configuring replication version >> plugin >> [8/43]: enabling IPA enrollment plugin >> [9/43]: enabling ldapi >> [10/43]: configuring uniqueness plugin >> [11/43]: configuring uuid plugin >> [12/43]: configuring modrdn plugin >> [13/43]: configuring DNS plugin >> [14/43]: enabling entryUSN plugin >> [15/43]: configuring lockout plugin >> [16/43]: configuring topology plugin >> [17/43]: creating indices >> [18/43]: enabling referential integrity >> plugin >> [19/43]: configuring certmap.conf >> [20/43]: configure autobind for root >> [21/43]: configure new location for >> managed entries >> [22/43]: configure dirsrv ccache >> [23/43]: enabling SASL mapping fallback >> [24/43]: restarting directory server >> [25/43]: creating DS keytab >> [26/43]: retrieving DS Certificate >> [27/43]: restarting directory server >> ipa : CRITICAL Failed to restart the >> directory server (Command >> '/bin/systemctl restart >> dirsrv at SOMETHING-BE.service' returned >> >> non-zero >> >> exit >> status 1). See the installation log for >> details. >> [28/43]: setting up initial replication >> [error] error: [Errno 111] Connection >> refused >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall >> to clean up. >> >> >> [29/Nov/2016:11:29:44.034285579 +0100] SSL >> alert: Security >> Initialization: >> Can't find certificate (Server-Cert) for >> family >> cn=RSA,cn=encryption,cn=config (Netscape >> Portable Runtime error -8174 >> >> - >> >> security library: bad database.) >> [29/Nov/2016:11:29:44.045039728 +0100] SSL >> alert: Security >> Initialization: >> Unable to retrieve private key for cert >> Server-Cert of family >> cn=RSA,cn=encryption,cn=config (Netscape >> Portable Runtime error -8174 >> >> - >> >> security library: bad database.) >> >> >> >> >> Hello David, >> >> The error from the log indicates that either the >> NSSDB for dirsrv is >> >> not >> >> initialized or not accessible. >> >> Could you please send output of the following >> commands? >> >> # ls -lZ /etc/dirsrv/slapd-$REALM/ >> # certutil -d /etc/dirsrv/slapd-$REALM/ -L >> # ausearch -m avc -i >> >> >> -- >> David Kupka >> >> >> >> -- >> Petr Vobornik >> >> >> >> >> -- >> David Kupka >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Wed Nov 30 14:30:55 2016 From: callum.guy at x-on.co.uk (Callum Guy) Date: Wed, 30 Nov 2016 14:30:55 +0000 Subject: [Freeipa-users] OTP Algorithm In-Reply-To: <587018a7-ad4e-370c-ba9b-6465900cc644@redhat.com> References: <79cd7b7f-3fc7-84f9-4762-75cd386a0cac@redhat.com> <20161129115126.lboewmlkco2ufa4s@redhat.com> <7ec15f84-a3ee-5a14-2653-f320a49702b2@redhat.com> <587018a7-ad4e-370c-ba9b-6465900cc644@redhat.com> Message-ID: Hi David, I can confirm that using FreeOTP resolves the problem for me. What a frustration, I am surprised that Google wouldn't add support beyond SHA1 - perhaps a notice on the OTP documentation page would help others in this situation. Thank you so much for your assistance and links to explain the situation. I hope to pay back the favour in due course. Best Regards, Callum On Wed, Nov 30, 2016 at 1:11 PM David Kupka wrote: > On 30/11/16 10:13, David Kupka wrote: > > On 29/11/16 12:57, Callum Guy wrote: > >> Hi Alexander, > >> > >> I can confirm that I am using version 4.2.0. > >> > >> The bug link provided mentions that it caused GA to fail to scan the > >> codes. > >> In my situation it is FreeIPA (or related service) which appears to > >> fail to > >> validate codes generated, meaning that only OTP codes generated using > >> sha1 > >> are validated and accepted. > >> > >> Just for clarity I can confirm that I have only tested OTP codes > >> generated > >> and configured via the FreeIPA web interface. I will check the command > >> line > >> generation and let you know if this makes a difference. > >> > >> Best Regards, > >> > >> Callum > > > > Hello Callum, > > I've tried it with FreeIPA 4.3.2 (stock Fedora 24) and FreeOTP. I've > > generated 3 OTPs (with sha256, sha384 and sha512) for tuser in the WebUI > > and was then able to login into WebUI without problems. > > > > > > $ ipa otptoken-find --owner tuser --all > > -------------------- > > 3 OTP tokens matched > > -------------------- > > dn: > > > ipatokenuniqueid=3c899764-7abf-459d-bf2b-7ba4af978a8b,cn=otp,dc=dom-058-216,dc=example,dc=com > > > > Unique ID: 3c899764-7abf-459d-bf2b-7ba4af978a8b > > Type: TOTP > > Owner: tuser > > Key: U5XDN0BYc9KbvG1iYuVPuVHB448= > > Algorithm: sha256 > > Digits: 6 > > Clock offset: 0 > > Clock interval: 30 > > ipatokentotpwatermark: 49349880 > > objectclass: top, ipatokentotp, ipatoken > > > > dn: > > > ipatokenuniqueid=40ad189b-7b7c-44b9-8450-b3eb78057ef6,cn=otp,dc=dom-058-216,dc=example,dc=com > > > > Unique ID: 40ad189b-7b7c-44b9-8450-b3eb78057ef6 > > Type: TOTP > > Owner: tuser > > Key: C79y2W+I0z429eRzsRP7qdpROaI= > > Algorithm: sha512 > > Digits: 6 > > Clock offset: 0 > > Clock interval: 30 > > ipatokentotpwatermark: 49349882 > > objectclass: top, ipatokentotp, ipatoken > > > > dn: > > > ipatokenuniqueid=baf6d329-61ad-46f1-beca-6ddb55ba9bb4,cn=otp,dc=dom-058-216,dc=example,dc=com > > > > Unique ID: baf6d329-61ad-46f1-beca-6ddb55ba9bb4 > > Type: TOTP > > Owner: tuser > > Key: 2hxrsJjQ6e+3qzVPZremtsB/NCg= > > Algorithm: sha384 > > Digits: 6 > > Clock offset: 0 > > Clock interval: 30 > > ipatokentotpwatermark: 49349881 > > objectclass: top, ipatokentotp, ipatoken > > I've tried with Google Authenicator too and was unable to login. > > Alexander found issue [1] asking for SHA256 support. From comment on the > issue it appear that SHA1 is the only supported hash. > > I compared codes generated by oathtool [2] and find out that Google > Authenticator just ignores the information about used hash function and > uses SHA1 without any error or warning. > > So I can only recommend switching to FreeOTP or returning to SHA-1 hash > function. > > [1] https://github.com/google/google-authenticator-libpam/issues/11 > [2] http://www.nongnu.org/oath-toolkit/oathtool.1.html > > > > > > >> > >> > >> On Tue, Nov 29, 2016 at 11:51 AM Alexander Bokovoy > > >> wrote: > >> > >>> On ti, 29 marras 2016, Callum Guy wrote: > >>>> Hi Petr, > >>>> > >>>> Thanks for coming back to me on this. > >>>> > >>>> I have only tried using Google Authenticator. The generated QR code > >>>> successfully scans and codes are then generated on the GA device as > >>> normal. > >>>> The problem is that the codes simply do not work. > >>>> > >>>> My current thinking is that the service which interprets the codes > >>>> server-side is not configured to use the same algorithm meaning that > >>>> it is > >>>> trying to validate sha256/sha512 (both tested and not functional for > >>>> me) > >>>> etc codes against codes perhaps generated with sha1 (the only > algorithm > >>>> that appears to work). > >>>> > >>>> I apologise in advance for my naive interpretation of the situation, > >>>> this > >>>> really isn't an area where i have experience. I'd love to understand > >>>> whats > >>>> going on however I can't find what i need in the OTP documentation. > >>> Which IPA version we are talking about? There was a case when the URI > >>> generated by 'ipa otptoken-add' was using a wrong case in the algorithm > >>> value and this was breaking Google Authenticator. > >>> > >>> https://fedorahosted.org/freeipa/ticket/5047 > >>> > >>> This bug was fixed since 4.1.5 release. > >>> > >>>> > >>>> Best Regards, > >>>> > >>>> Callum > >>>> > >>>> > >>>> On Tue, Nov 29, 2016 at 11:10 AM Petr Vobornik > >>> wrote: > >>>> > >>>>> On 11/28/2016 01:03 PM, Callum Guy wrote: > >>>>>> Hi All, > >>>>>> > >>>>>> I wanted to ask a quick question - perhaps a more experienced user > >>> will > >>>>> be able > >>>>>> to help or point me to the correct documentation. > >>>>>> > >>>>>> Basically we have implemented password+OTP type authentication which > >>>>> works great. > >>>>>> > >>>>>> When adding a OTP code using the admin login you can choose an > >>>>> algorithm. For us > >>>>>> the generated codes only work properly if the weakest sha1 algorithm > >>> is > >>>>> chosen/ > >>>>>> To be clear the code generation works fine but the codes are not > >>>>>> valid > >>>>> when > >>>>>> logging in. Is there a related setting we must change? > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Callum > >>>>>> > >>>>> > >>>>> What type of otp token do you use? Does it work with some different? > >>>>> E.g. FreeOTP vs Google Authenticator ... > >>>>> > >>>>> > >>>>> -- > >>>>> Petr Vobornik > >>>>> > >>>> > >>>> -- > >>>> > >>>> > >>>> > >>>> *0333 332 0000 | www.x-on.co.uk | ** > >>>> > >>>> > >>>> * > >>>> X-on is a trading name of Storacall Technology Ltd a limited company > >>>> registered in England and Wales. > >>>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel > >>>> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. > >>>> The information in this e-mail is confidential and for use by the > >>>> addressee(s) only. If you are not the intended recipient, please > notify > >>>> X-on immediately on +44(0)333 332 0000 <+44%20333%20332%200000> > <+44%20333%20332%200000> and > >>> delete the > >>>> message from your computer. If you are not a named addressee you > >>>> must not > >>>> use, disclose, disseminate, distribute, copy, print or reply to this > >>> email. Views > >>>> or opinions expressed by an individual > >>>> within this email may not necessarily reflect the views of X-on or its > >>>> associated companies. Although X-on routinely screens for viruses, > >>>> addressees should scan this email and any attachments > >>>> for viruses. X-on makes no representation or warranty as to the > >>>> absence of > >>>> viruses in this email or any attachments. > >>>> > >>> > >>>> -- > >>>> 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 > >>> > >> > >> > >> > > > > > > > -- > David Kupka > -- *0333 332 0000 | www.x-on.co.uk | ** * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Wed Nov 30 15:05:00 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 30 Nov 2016 16:05:00 +0100 Subject: [Freeipa-users] OTP Algorithm In-Reply-To: References: <79cd7b7f-3fc7-84f9-4762-75cd386a0cac@redhat.com> <20161129115126.lboewmlkco2ufa4s@redhat.com> <7ec15f84-a3ee-5a14-2653-f320a49702b2@redhat.com> <587018a7-ad4e-370c-ba9b-6465900cc644@redhat.com> Message-ID: <5d5774d4-6079-435a-5fdc-d5485f4bc218@redhat.com> On 30/11/16 15:30, Callum Guy wrote: > Hi David, > > I can confirm that using FreeOTP resolves the problem for me. > > What a frustration, I am surprised that Google wouldn't add support beyond > SHA1 - perhaps a notice on the OTP documentation page would help others in > this situation. > > Thank you so much for your assistance and links to explain the situation. I > hope to pay back the favour in due course. > > Best Regards, > > Callum I'm glad I could help. I was very surprised that Google Authenticator is missing this and even worse don't error out about it. At first I was convinced that FreeOTP and FreeIPA has some shared bug and generates the codes in wrong way. I've added a paragraph to Troubleshooting page [1]. Could you please send me a link to the page where you were trying to find information at first? I would like to add a note and link there so other users with the same issue have it easier. [1] http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_user_with_OTP_with_Google_Authenticator > > > On Wed, Nov 30, 2016 at 1:11 PM David Kupka wrote: > >> On 30/11/16 10:13, David Kupka wrote: >>> On 29/11/16 12:57, Callum Guy wrote: >>>> Hi Alexander, >>>> >>>> I can confirm that I am using version 4.2.0. >>>> >>>> The bug link provided mentions that it caused GA to fail to scan the >>>> codes. >>>> In my situation it is FreeIPA (or related service) which appears to >>>> fail to >>>> validate codes generated, meaning that only OTP codes generated using >>>> sha1 >>>> are validated and accepted. >>>> >>>> Just for clarity I can confirm that I have only tested OTP codes >>>> generated >>>> and configured via the FreeIPA web interface. I will check the command >>>> line >>>> generation and let you know if this makes a difference. >>>> >>>> Best Regards, >>>> >>>> Callum >>> >>> Hello Callum, >>> I've tried it with FreeIPA 4.3.2 (stock Fedora 24) and FreeOTP. I've >>> generated 3 OTPs (with sha256, sha384 and sha512) for tuser in the WebUI >>> and was then able to login into WebUI without problems. >>> >>> >>> $ ipa otptoken-find --owner tuser --all >>> -------------------- >>> 3 OTP tokens matched >>> -------------------- >>> dn: >>> >> ipatokenuniqueid=3c899764-7abf-459d-bf2b-7ba4af978a8b,cn=otp,dc=dom-058-216,dc=example,dc=com >>> >>> Unique ID: 3c899764-7abf-459d-bf2b-7ba4af978a8b >>> Type: TOTP >>> Owner: tuser >>> Key: U5XDN0BYc9KbvG1iYuVPuVHB448= >>> Algorithm: sha256 >>> Digits: 6 >>> Clock offset: 0 >>> Clock interval: 30 >>> ipatokentotpwatermark: 49349880 >>> objectclass: top, ipatokentotp, ipatoken >>> >>> dn: >>> >> ipatokenuniqueid=40ad189b-7b7c-44b9-8450-b3eb78057ef6,cn=otp,dc=dom-058-216,dc=example,dc=com >>> >>> Unique ID: 40ad189b-7b7c-44b9-8450-b3eb78057ef6 >>> Type: TOTP >>> Owner: tuser >>> Key: C79y2W+I0z429eRzsRP7qdpROaI= >>> Algorithm: sha512 >>> Digits: 6 >>> Clock offset: 0 >>> Clock interval: 30 >>> ipatokentotpwatermark: 49349882 >>> objectclass: top, ipatokentotp, ipatoken >>> >>> dn: >>> >> ipatokenuniqueid=baf6d329-61ad-46f1-beca-6ddb55ba9bb4,cn=otp,dc=dom-058-216,dc=example,dc=com >>> >>> Unique ID: baf6d329-61ad-46f1-beca-6ddb55ba9bb4 >>> Type: TOTP >>> Owner: tuser >>> Key: 2hxrsJjQ6e+3qzVPZremtsB/NCg= >>> Algorithm: sha384 >>> Digits: 6 >>> Clock offset: 0 >>> Clock interval: 30 >>> ipatokentotpwatermark: 49349881 >>> objectclass: top, ipatokentotp, ipatoken >> >> I've tried with Google Authenicator too and was unable to login. >> >> Alexander found issue [1] asking for SHA256 support. From comment on the >> issue it appear that SHA1 is the only supported hash. >> >> I compared codes generated by oathtool [2] and find out that Google >> Authenticator just ignores the information about used hash function and >> uses SHA1 without any error or warning. >> >> So I can only recommend switching to FreeOTP or returning to SHA-1 hash >> function. >> >> [1] https://github.com/google/google-authenticator-libpam/issues/11 >> [2] http://www.nongnu.org/oath-toolkit/oathtool.1.html >> >>> >>> >>>> >>>> >>>> On Tue, Nov 29, 2016 at 11:51 AM Alexander Bokovoy >> >>>> wrote: >>>> >>>>> On ti, 29 marras 2016, Callum Guy wrote: >>>>>> Hi Petr, >>>>>> >>>>>> Thanks for coming back to me on this. >>>>>> >>>>>> I have only tried using Google Authenticator. The generated QR code >>>>>> successfully scans and codes are then generated on the GA device as >>>>> normal. >>>>>> The problem is that the codes simply do not work. >>>>>> >>>>>> My current thinking is that the service which interprets the codes >>>>>> server-side is not configured to use the same algorithm meaning that >>>>>> it is >>>>>> trying to validate sha256/sha512 (both tested and not functional for >>>>>> me) >>>>>> etc codes against codes perhaps generated with sha1 (the only >> algorithm >>>>>> that appears to work). >>>>>> >>>>>> I apologise in advance for my naive interpretation of the situation, >>>>>> this >>>>>> really isn't an area where i have experience. I'd love to understand >>>>>> whats >>>>>> going on however I can't find what i need in the OTP documentation. >>>>> Which IPA version we are talking about? There was a case when the URI >>>>> generated by 'ipa otptoken-add' was using a wrong case in the algorithm >>>>> value and this was breaking Google Authenticator. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/5047 >>>>> >>>>> This bug was fixed since 4.1.5 release. >>>>> >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Callum >>>>>> >>>>>> >>>>>> On Tue, Nov 29, 2016 at 11:10 AM Petr Vobornik >>>>> wrote: >>>>>> >>>>>>> On 11/28/2016 01:03 PM, Callum Guy wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I wanted to ask a quick question - perhaps a more experienced user >>>>> will >>>>>>> be able >>>>>>>> to help or point me to the correct documentation. >>>>>>>> >>>>>>>> Basically we have implemented password+OTP type authentication which >>>>>>> works great. >>>>>>>> >>>>>>>> When adding a OTP code using the admin login you can choose an >>>>>>> algorithm. For us >>>>>>>> the generated codes only work properly if the weakest sha1 algorithm >>>>> is >>>>>>> chosen/ >>>>>>>> To be clear the code generation works fine but the codes are not >>>>>>>> valid >>>>>>> when >>>>>>>> logging in. Is there a related setting we must change? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Callum >>>>>>>> >>>>>>> >>>>>>> What type of otp token do you use? Does it work with some different? >>>>>>> E.g. FreeOTP vs Google Authenticator ... >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Petr Vobornik >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> *0333 332 0000 | www.x-on.co.uk | ** >>>>>> >>>>>> >>>>>> * >>>>>> X-on is a trading name of Storacall Technology Ltd a limited company >>>>>> registered in England and Wales. >>>>>> Registered Office : Avaland House, 110 London Road, Apsley, Hemel >>>>>> Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. >>>>>> The information in this e-mail is confidential and for use by the >>>>>> addressee(s) only. If you are not the intended recipient, please >> notify >>>>>> X-on immediately on +44(0)333 332 0000 <+44%20333%20332%200000> >> <+44%20333%20332%200000> and >>>>> delete the >>>>>> message from your computer. If you are not a named addressee you >>>>>> must not >>>>>> use, disclose, disseminate, distribute, copy, print or reply to this >>>>> email. Views >>>>>> or opinions expressed by an individual >>>>>> within this email may not necessarily reflect the views of X-on or its >>>>>> associated companies. Although X-on routinely screens for viruses, >>>>>> addressees should scan this email and any attachments >>>>>> for viruses. X-on makes no representation or warranty as to the >>>>>> absence of >>>>>> viruses in this email or any attachments. >>>>>> >>>>> >>>>>> -- >>>>>> 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 >>>>> >>>> >>>> >>>> >>> >>> >> >> >> -- >> David Kupka >> > -- David Kupka From flo at redhat.com Wed Nov 30 16:26:18 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 30 Nov 2016 17:26:18 +0100 Subject: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process In-Reply-To: References: <1a904801-2687-12e4-1820-be3ca1e39371@redhat.com> <17ed1617-b686-368a-b6af-55cb39c720a0@redhat.com> <11a369fa-dceb-3337-053b-4c2e3e46b3bf@redhat.com> <9bc54a14-dd27-fef8-bbaf-be4b918fb7de@redhat.com> Message-ID: <86598c30-4aeb-9d68-c514-a13909ed27c6@redhat.com> On 11/30/2016 03:27 PM, David Dejaeghere wrote: > Hi, > > The Pki service is running and I cannot find any issues with it. I can > run a curl request to the master hostname on port 8443 and communication > works fine. > Any other idea why this replica install code would fail and log > CA_UNREACHABLE? > Hi, can you check the logs on the server around the time of the replica installation? - in /var/log/httpd/access_log you should find a line with "POST https://ipaserver.domain.com:443/ca/eeca/ca/profileSubmitSSLClient HTTP/1.1" 200 2216 This line shows that certmonger did send the certificate request to IPA master. - in /var/log/httpd/error_log, around the same time, you may find [proxy:error] [pid 20702] (111)Connection refused: AH00957: AJP: attempt to connect to 127.0.0.1:8009 (localhost) failed [proxy:error] [pid 20702] AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 60s [proxy_ajp:error] [pid 20702] [client ] AH00896: failed to make connection to backend: localhost [:error] [pid 20698] ipa: ERROR: ra.request_certificate(): Unable to communicate with CMS (503) [:error] [pid 20698] ipa: INFO: [xmlserver] host/ipasrerver.domain.com at DOMAIN.COM: cert_request(u'[...]', principal=u'ldap/ipaclient.domain.com at DOMAIN.COM', add=True, version=u'2.51'): CertificateOperationError If you find this type of error, the problem may come from the redirection httpd -> tomcat. Apache is configured to redirect the URL profileSubmitSSLClient to ajp://localhost:8009 (see in /etc/httpd/conf.d/ipa-pki-proxy.conf). You can check if Dogtag is listening on port 8009 (with netstat -tupnl | grep 8009, which should output the pid of Dogtag). If it is not the case, there is probably a configuration issue on Tomcat side. Flo. > Regards, > > David > > > 2016-11-29 22:16 GMT+01:00 Florence Blanc-Renaud >: > > On 11/29/2016 03:19 PM, David Dejaeghere wrote: > > Can you give me a couple of test commands? > I am not familiar with Dogtag. > > Hi, > > To reproduce the issue: > 1. install IPA server > 2. On the replica, run ipa-client-install > 3. On the server, stop dogtag with > $ systemctl stop pki-tomcatd at pki-tomcat.service > 4. On the replica, run ipa-replica-install > > When you want to restart dogtag, you can run > $ systemctl start pki-tomcatd at pki-tomcat.service > > If you want to check if dogtag is running: > $ systemctl status pki-tomcatd at pki-tomcat.service > > You may find more information on Dogtag here: > http://pki.fedoraproject.org/wiki/PKI_Main_Page > > http://pki.fedoraproject.org/wiki/IPA > > http://pki.fedoraproject.org/wiki/Debugging_the_state_of_dogtag_in_an_ipa_install > > > Flo > > Groeten, > > David > > 2016-11-29 14:57 GMT+01:00 David Kupka > >>: > > On 29/11/16 13:55, David Dejaeghere wrote: > > Correct. Same symptoms. > > 2016-11-29T10:29:42Z DEBUG certmonger request is in state > dbus.String(u'CA_UNREACHABLE', variant_level=1) > > Fedora 24 Server > > [root at ns02 ~]# dnf history userinstalled > Packages installed by user > freeipa-client-4.3.2-2.fc24.x86_64 > freeipa-server-4.3.2-2.fc24.x86_64 > grub2-1:2.02-0.34.fc24.x86_64 > kernel-4.5.5-300.fc24.x86_64 > kernel-4.8.8-200.fc24.x86_64 > lvm2-2.02.150-2.fc24.x86_64 > xfsprogs-4.5.0-2.fc24.x86_64 > > > Ok. I've reproduced it by simply stopping dogtag on FreeIPA > server > while installing the replica. I see the exactly same errors as > you've reported and are described in the ticket, now. > > Is dogtag running on your master? Is in responding (e.g. issuing > certificates for users)? Is it accessible from the replica? > > > > 2016-11-29 13:41 GMT+01:00 Petr Vobornik > > >>: > > > On 11/29/2016 12:43 PM, David Kupka wrote: > > On 29/11/16 12:15, David Dejaeghere wrote: > > Seems like it is but it does not show a > server cert > for dirsrv > > [root at ns02 ~]# ls -lZ > /etc/dirsrv/slapd-SOMETHING-BE/ > total 468 > -rw-------. 1 dirsrv root > unconfined_u:object_r:dirsrv_config_t:s0 > 65536 > Nov 29 11:29 cert8.db > -rw-rw----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 65536 > Nov 29 11:29 cert8.db.orig > -r--r-----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 1623 > Nov 29 11:29 certmap.conf > -rw-------. 1 dirsrv dirsrv > system_u:object_r:dirsrv_config_t:s0 > 89977 > Nov 29 11:29 dse.ldif > -rw-------. 2 dirsrv dirsrv > system_u:object_r:dirsrv_config_t:s0 > 89977 > Nov 29 11:29 dse.ldif.bak > -rw-------. 2 dirsrv dirsrv > system_u:object_r:dirsrv_config_t:s0 > 89977 > Nov 29 11:29 dse.ldif.startOK > -r--r-----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 36228 > Nov 29 11:28 dse_original.ldif > -rw-------. 1 dirsrv root > unconfined_u:object_r:dirsrv_config_t:s0 > 16384 > Nov 29 11:29 key3.db > -rw-rw----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 16384 > Nov 29 11:29 key3.db.orig > -r--------. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 66 > Nov 29 11:29 pin.txt > -rw-------. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 40 > Nov 29 11:29 pwdfile.txt > drwxrwx---. 2 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 4096 > Nov 29 11:29 schema > -rw-------. 1 dirsrv root > unconfined_u:object_r:dirsrv_config_t:s0 > 16384 > Nov 29 11:29 secmod.db > -rw-rw----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 16384 > Nov 29 11:29 secmod.db.orig > -r--r-----. 1 dirsrv dirsrv > unconfined_u:object_r:dirsrv_config_t:s0 > 15142 > Nov 29 11:28 slapd-collations.conf > > [root at ns02 ~]# certutil -d > /etc/dirsrv/slapd-SOMETHING-BE -L > > Certificate Nickname > Trust > Attributes > > SSL,S/MIME,JAR/XPI > > CN=something-PAPRIKA-CA,DC=something,DC=local > CT,C,C > SOMETHING.BE > IPA CA > CT,C,C > [root at ns02 ~]# certutil -d > /etc/dirsrv/slapd-SOMETHING-BE -L > > Certificate Nickname > Trust > Attributes > > SSL,S/MIME,JAR/XPI > > CN=something-PAPRIKA-CA,DC=something,DC=local > CT,C,C > SOMETHING.BE > IPA CA > CT,C,C > > [root at ns02 ~]# ausearch -m avc -i > > > > > Exactly, the NSSDB should be accessible to > dirsrv and is > missing the > Server-Cert but I don't understand why there's "bad > database" error in > the errors log. I'll try to reproduce it. What > version > of FreeIPA are > you using? On what system? > > > Right. > > Seems bit similar to > https://fedorahosted.org/freeipa/ticket/6514 > > > would > be good to check if it has the same symptoms, mainly > certmonger request is in state > dbus.String(u'CA_UNREACHABLE', > variant_level=1) > > in replica install log. > > > > > 2016-11-29 12:09 GMT+01:00 David Kupka > >>: > > > On 29/11/16 11:51, David Dejaeghere wrote: > > Hi, > > I have a setup where i want to add a > replica. The first master > setup has > an externally signed cert for dirsrv and > httpd. The replica is > prepapred > succesfully with ipa-client-install > but the > replica install then keeps > failing. It seems that during install > dirserv is not configured > correctly > with a valid server certificate. > Output from > the dirsrv error added to > this > email as well. > > [root at ns02 ~]# ipa-replica-install > --setup-ca > WARNING: conflicting time&date > synchronization service 'chronyd' will > be disabled in favor of ntpd > > Run connection check to master > Connection check OK > 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/43]: creating directory server user > [2/43]: creating directory server > instance > [3/43]: restarting directory server > [4/43]: adding default schema > [5/43]: enabling memberof plugin > [6/43]: enabling winsync plugin > [7/43]: configuring replication > version plugin > [8/43]: enabling IPA enrollment plugin > [9/43]: enabling ldapi > [10/43]: configuring uniqueness plugin > [11/43]: configuring uuid plugin > [12/43]: configuring modrdn plugin > [13/43]: configuring DNS plugin > [14/43]: enabling entryUSN plugin > [15/43]: configuring lockout plugin > [16/43]: configuring topology plugin > [17/43]: creating indices > [18/43]: enabling referential > integrity plugin > [19/43]: configuring certmap.conf > [20/43]: configure autobind for root > [21/43]: configure new location for > managed entries > [22/43]: configure dirsrv ccache > [23/43]: enabling SASL mapping > fallback > [24/43]: restarting directory server > [25/43]: creating DS keytab > [26/43]: retrieving DS Certificate > [27/43]: restarting directory server > ipa : CRITICAL Failed to > restart the > directory server (Command > '/bin/systemctl restart > dirsrv at SOMETHING-BE.service' returned > > non-zero > > exit > status 1). See the installation log > for details. > [28/43]: setting up initial > replication > [error] error: [Errno 111] > Connection refused > Your system may be partly configured. > Run /usr/sbin/ipa-server-install > --uninstall > to clean up. > > > [29/Nov/2016:11:29:44.034285579 > +0100] SSL > alert: Security > Initialization: > Can't find certificate (Server-Cert) > for family > cn=RSA,cn=encryption,cn=config (Netscape > Portable Runtime error -8174 > > - > > security library: bad database.) > [29/Nov/2016:11:29:44.045039728 > +0100] SSL > alert: Security > Initialization: > Unable to retrieve private key for cert > Server-Cert of family > cn=RSA,cn=encryption,cn=config (Netscape > Portable Runtime error -8174 > > - > > security library: bad database.) > > > > > Hello David, > > The error from the log indicates that > either the > NSSDB for dirsrv is > > not > > initialized or not accessible. > > Could you please send output of the > following > commands? > > # ls -lZ /etc/dirsrv/slapd-$REALM/ > # certutil -d /etc/dirsrv/slapd-$REALM/ -L > # ausearch -m avc -i > > > -- > David Kupka > > > > -- > Petr Vobornik > > > > > -- > David Kupka > > > > > > From john.l.daly at navy.mil Wed Nov 30 18:46:38 2016 From: john.l.daly at navy.mil (Daly, John L CIV NAVAIR, 4G0000D) Date: Wed, 30 Nov 2016 18:46:38 +0000 Subject: [Freeipa-users] Mac OS X 10.12 Smart card authentication to FreeIPA server. Message-ID: <64E450F484A55148AE81AFCE975F216851B91958@NAWECHLKXM02V.nadsuswe.nads.navy.mil> Hi Sumit. Here's an example of a user that works with smartcard authentication to an Open Directory server. the key is the ;pubkeyhash; in authentication authority. in 10.12 it's the ;tokenidenity; that does it. Thank you, John __________________________ dsAttrTypeNative:objectClass: inetOrgPerson posixAccount shadowAccount apple-user extensibleObject organizationalPerson top person AltSecurityIdentities: Kerberos:user at SERVER.DOMAIN.NAME AppleMetaNodeLocation: /LDAPv3/server.domain.name AppleMetaRecordName: uid=user,cn=users,dc=server,dc=domain,dc=name AuthenticationAuthority: ;ApplePasswordServer;0x5230e3e66bef0ef40000007f00000070,1024 35 137153981046475199943945843867332692680750197424744096859870797093676645749027380403427308966078902581285961066749586341210370640493694174807003238022253128816071402321107596780023824943279942604404381371976466757866276940266744128110435619726808591040123586775364081346530916319469827937868172697966549077993 root at server.domain.name:192.168.0.1 ;pubkeyhash;CFF322DE5D9F21E1FEF8957548EF94D846E6B43C ;pubkeyhash;A89153274F7EF7132FAAF4507078064AA522E78D ;tokenidentity;44AFDECA841C27354223BFVE1F3A91VEDC48C65A Comment: sysadmin extraordinaire.. sort of EMailAddress: user at server.domain GeneratedUID: FDCEB042-BD89-11D9-BFEE-0003939529C2 LastName: 99 MCXFlags: simultaneous_login_enabled NFSHomeDirectory: /Network/Servers/server.domain.name/Volumes/shares/netusers/user Password: ******** PrimaryGroupID: 80 RealName: User Name RecordName: user RecordType: dsRecTypeStandard:Users ServicesLocator: 793D4083-126E-44A7-A3FF-85251F39556D:E245FF24-D266-4F7E-BCF4-709611F539A6:calendar (null):(null):calendar UniqueID: 1025 UserShell: /bin/bash Message: 5 Date: Wed, 30 Nov 2016 09:46:42 +0100 From: Sumit Bose To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Mac OS X 10.12 Smart card authentication to FreeIPA server. Message-ID: <20161130084642.GD21759 at p.Speedport_W_724V_Typ_A_05011603_00_009> Content-Type: text/plain; charset=us-ascii ______________________________________ On Tue, Nov 29, 2016 at 06:21:11PM +0000, Daly, John L CIV NAVAIR, 4G0000D wrote: > Greetings, > I thumbed through the archive, but didn't find an answer. If I missed it, perhaps someone will be kind enough to point me in the right direction. > > I'm testing replacing our OpenDirectory server with a FreeIPA server for authenticating our Mac systems. So far, I have the server and client running in a virtual machine (FreeIPA running on CentOS 7, Mac is MacOS 10.12.1), and, following a number of instructions found on the web, they are talking to each other and I can log in from the Mac client to the FreeIPA server with a user account on the FreeIPA server. > > The final step in this is that I need to use smart card authentication instead of username/password. I have managed to get the smart card's certificate added to the user account on the FreeIPA server, but that's as far as I've managed. > > In MacOS 10.7-10.11, the method of getting smart card authorization to work is to get the hash of the certificate on the smart card and then add that to AuthenticationAuthority in Directory Utility as ;pubkeyhash; > In 10.12, it will actually ask you if you want to pair the smart card with the account, and if so, in the background it adds the hash as ;tokenIdentity; to AuthenticationAuthority (but it only does that to local accounts. to do it in Open Directory, you have to add it manually still) > > In my ignorance, I'm guessing that I just somehow need to map the certificate that's been added to the user account in FreeIPA to AuthenticationAuthority in DirectoryUtility. Right now the only thing mapped in the bind for AuthenticationAuthority is uid. Can you send me an example of an user object from OpenDirectory which has all the needed attributes to make Smartcard authentication work? bye, Sumit > > Could someone tell me what map I would need to make when setting up the bind to make this work? Or if I'm totally heading in the wrong direction, could someone send me in the right direction? > > Nathan Kinder's blog was very helpful, but he mentions telling how to actually set up login on the next installment, and that was over a year ago and there's no next installment. Most of what I've been able to find covers how to use sssd to get a linux machine to authenticate with the smartcard to FreeIPA, but I haven't been able to translate that to getting the Mac to authenticate. > > Thank you, > John > > -- > 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