From wdh at dds.nl Thu Dec 1 08:07:36 2016 From: wdh at dds.nl (Winfried de Heiden) Date: Thu, 1 Dec 2016 09:07:36 +0100 Subject: [Freeipa-users] Freeipa on ARM (raspberry pi) - OpenJDK vs. Oracle JDK Message-ID: <06aaa943-160f-fb13-d598-9d85c5fef2da@dds.nl> An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Dec 1 08:19:38 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 1 Dec 2016 09:19:38 +0100 Subject: [Freeipa-users] Freeipa on ARM (raspberry pi) - OpenJDK vs. Oracle JDK In-Reply-To: <06aaa943-160f-fb13-d598-9d85c5fef2da@dds.nl> References: <06aaa943-160f-fb13-d598-9d85c5fef2da@dds.nl> Message-ID: <62534711-6e74-b9e9-818e-5a10d01245bb@redhat.com> On 1.12.2016 09:07, Winfried de Heiden wrote: > Hi all, > > Started as "just because it's possible" running FreeIPA on a BananaPI or > Raspberry PI turned to out to be rather succesfull and for more than a year I > use FreeIPA at home. > > OK, running on small boards like Raspberry PI it never will be fast but it's > surely quick enough to run at small scale. However, starting FreeIPA became much > slower since Fedora 24 and even more on Fedora 25. > Since Oracle Java is also available for ARM and there's much written this is > much faster I took some time for an experiment. > > Starting FreeIPA using the default installation (running OpenJDK) starting > FreeIPA takes a painfull 15 minutes (afterward, it all just works fine): > > [root at rpi2 sysconfig]# time ipactl start > Starting Directory Service > Starting krb5kdc Service > Starting kadmin Service > Starting named Service > Starting ipa_memcached Service > Starting httpd Service > Starting ipa-custodia Service > Starting ntpd Service > Starting pki-tomcatd Service > Starting ipa-otpd Service > Starting ipa-dnskeysyncd Service > ipa: INFO: The ipactl command was successful > > real 15m40.638s > user 0m33.095s > sys 0m1.910s > > Now, after installing Oracle Java and changing JAVA_HOME in > /etc/sysconfig/pki-tomcat to: > > #JAVA_HOME="/usr/lib/jvm/jre-1.8.0-openjdk" > JAVA_HOME="/opt/jdk1.8.0_111/jre" > > [root at rpi2 sysconfig]# time ipactl start > Starting Directory Service > Starting krb5kdc Service > Starting kadmin Service > Starting named Service > Starting ipa_memcached Service > Starting httpd Service > Starting ipa-custodia Service > Starting ntpd Service > Starting pki-tomcatd Service > Starting ipa-otpd Service > Starting ipa-dnskeysyncd Service > ipa: INFO: The ipactl command was successful > > real 2m14.823s > user 0m33.400s > sys 0m1.730s > > Wow, I expected some improvement, but this far better than expected! This leaves > a question: what is happening here!!?? Huh? That is really huge difference. Please open a bug against OpenJDK: https://bugzilla.redhat.com/enter_bug.cgi That way it will reach OpenJDK developers. They will have better idea than FreeIPA developers, I guess. Please report the bug number to this forum so we can track it as well. Thank you very much! Petr^2 Spacek > > I prefer to use OpenJDK, it 's Open Source and because it's availabe from the > Fedora ARM repositories it is also much more easy to update. But for now, Oracle > is much faster and OpenJDK from this point of view is a very poor alternative. > Why is OpenJDK so much slower? Is improvement possible? For now (some > "tweaking") of in a future release? > > For the record, I tested these Java versions: > > [root at rpi2 sysconfig]# > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.arm/jre/bin/java -version > openjdk version "1.8.0_111" > OpenJDK Runtime Environment (build 1.8.0_111-b16) > OpenJDK Zero VM (build 25.111-b16, interpreted mode) > > [root at rpi2 sysconfig]# /opt/jdk1.8.0_111/jre/bin/java -version > java version "1.8.0_111" > Java(TM) SE Runtime Environment (build 1.8.0_111-b14) > Java HotSpot(TM) Client VM (build 25.111-b14, mixed mode) > > > Kind regards, > > Winfried > > > -- Petr^2 Spacek From wdh at dds.nl Thu Dec 1 10:01:13 2016 From: wdh at dds.nl (Winfried de Heiden) Date: Thu, 1 Dec 2016 11:01:13 +0100 Subject: [Freeipa-users] Freeipa on ARM (raspberry pi) - OpenJDK vs. Oracle JDK In-Reply-To: <62534711-6e74-b9e9-818e-5a10d01245bb@redhat.com> References: <06aaa943-160f-fb13-d598-9d85c5fef2da@dds.nl> <62534711-6e74-b9e9-818e-5a10d01245bb@redhat.com> Message-ID: <0fb9e08c-46fd-573c-51e2-664e92cf0063@dds.nl> An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Thu Dec 1 10:09:34 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Thu, 1 Dec 2016 11:09:34 +0100 Subject: [Freeipa-users] ipa fails to start hangs on pki-tomcatd Message-ID: Hello, For some reason my ipa server no longer boots. It keeps trying to start pki-tomcat service. Does anybody know where I should start looking to get this fixed ? Rob Verduijn ipactl -d start gives this output: ipa: DEBUG: The CA status is: check interrupted due to error: Command ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' ' https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus'' returned non-zero exit status 8 ipa: DEBUG: Waiting for CA to start... ipa: DEBUG: Starting external process ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' ' https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus' ipa: DEBUG: Process finished, return code=8 ipa: DEBUG: stdout= ipa: DEBUG: stderr=--2016-12-01 11:06:12-- https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus Resolving freeipa02.tjako.thuis (freeipa02.tjako.thuis)... 172.16.1.13 Connecting to freeipa02.tjako.thuis (freeipa02.tjako.thuis)|172.16.1.13|:8443... connected. HTTP request sent, awaiting response... HTTP/1.1 500 Internal Server Error Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 2134 Date: Thu, 01 Dec 2016 10:06:13 GMT Connection: close 2016-12-01 11:06:13 ERROR 500: Internal Server Error. There are also some java warnings in the logs, but its java and I can never tell if its a serious error when java gives a warning. Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM org.apache.catalina.startup.SetAllPropertiesRule begin Dec 1 09:53:59 freeipa02 server: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'serverCertNickFile' to '/var/lib/pki/pki-tomcat/conf/serverCertNick.conf' did not find a matching property. Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM org.apache.catalina.startup.SetAllPropertiesRule begin Dec 1 09:53:59 freeipa02 server: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'passwordFile' to '/var/lib/pki/pki-tomcat/conf/password.conf' did not find a matching property. Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM org.apache.catalina.startup.SetAllPropertiesRule begin Dec 1 09:53:59 freeipa02 server: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'passwordClass' to 'org.apache.tomcat.util.net.jss.PlainPasswordFile' did not find a matching property. Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM org.apache.catalina.startup.SetAllPropertiesRule begin Dec 1 09:53:59 freeipa02 server: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'certdbDir' to '/var/lib/pki/pki-tomcat/alias' did not find a matching property. Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM org.apache.tomcat.util.digester.SetPropertiesRule begin Dec 1 09:53:59 freeipa02 server: WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 'xmlValidation' to 'false' did not find a matching property. Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM org.apache.tomcat.util.digester.SetPropertiesRule begin Dec 1 09:53:59 freeipa02 server: WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting property 'xmlNamespaceAware' to 'false' did not find a matching property. I'm running centos7.2 x86_64 with the latest patches applied. some package versions below rpm -qa|egrep "ipa|tomcat"|sort ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64 ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64 ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64 ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64 libipa_hbac-1.13.0-40.el7_2.12.x86_64 python-iniparse-0.4-9.el7.noarch python-libipa_hbac-1.13.0-40.el7_2.12.x86_64 sssd-ipa-1.13.0-40.el7_2.12.x86_64 tomcat-7.0.54-8.el7_2.noarch tomcat-el-2.2-api-7.0.54-8.el7_2.noarch tomcat-jsp-2.2-api-7.0.54-8.el7_2.noarch tomcatjss-7.1.2-1.el7.noarch tomcat-lib-7.0.54-8.el7_2.noarch tomcat-servlet-3.0-api-7.0.54-8.el7_2.noarch -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Dec 1 10:35:28 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 1 Dec 2016 11:35:28 +0100 Subject: [Freeipa-users] Mac OS X 10.12 Smart card authentication to FreeIPA server. In-Reply-To: <64E450F484A55148AE81AFCE975F216851B91958@NAWECHLKXM02V.nadsuswe.nads.navy.mil> References: <64E450F484A55148AE81AFCE975F216851B91958@NAWECHLKXM02V.nadsuswe.nads.navy.mil> Message-ID: <20161201103528.GE8701@p.Speedport_W_724V_Typ_A_05011603_00_009> On Wed, Nov 30, 2016 at 06:46:38PM +0000, Daly, John L CIV NAVAIR, 4G0000D wrote: > 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 for the details but I think I was looking in to wrong direction. You want to allow clients to authenticate with a certificate against the FreeIPA LDAP server. There was a thread "user certificate ldap EXTERNAL authentication" on this list ealier this year https://www.redhat.com/archives/freeipa-users/2016-March/msg00024.html which resulted in a howto page http://www.freeipa.org/page/Howto/Client_Certificate_Authentication_with_LDAP. The page also contains links to the official 389ds/Directory Server documentation which should explain even more details. I hope this will help you to get started with MacOS clients and Smartcard authentication against FreeIPA. bye, Sumit > > 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 > > -- > Manage your subscription for 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 nharrington at i-neda.com Thu Dec 1 12:28:36 2016 From: nharrington at i-neda.com (Neal Harrington | i-Neda Ltd) Date: Thu, 1 Dec 2016 12:28:36 +0000 Subject: [Freeipa-users] Loss of initial master in multi master setup Message-ID: Hi IPA Gurus, I had a 3 site multi master IPA replication setup (1 office and 2 datacentres) with 2 IPA servers at each site. Each server was replicating successfully to 3 other servers (the other local site server and one server at each of the two remote sites). Everything is running on the default packages from CentOS 7.2 and each server is a full replica (ipa-replica-install /var/lib/ipa/replica-info-id-myserver.fqdn.com.gpg --setup-ca --setup-dns --mkhomedir --forwarder 8.8.8.8) Everything was ticking over nicely until we had notice that the office site was moving on short notice. I successfully created IPA servers at the new site, setup replication again between the new office and the two datacentres that were to remain online, tested and everything worked as expected - unfortunately in the rush I did not have time to properly retire the IPA servers in the old office. The problem this has caused is that I only ever created users in one of the IPA servers in the original office - so only those servers have a DNA range and I am now unable to create new users on the active servers. The original office servers are still in the IPA replication and powered on but offline so potential split brain? I now have two things I would like to know before proceeding: * Is the best fix here to force remove the original IPA servers and manually add a new dna range significantly different from the original to avoid overlaps? * Is there anything else I should check? I can't see any issues however did not notice the DNA range until I tried to create a user. Any pointers greatly appreciated. Thanks, Neal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbabinsk at redhat.com Thu Dec 1 13:03:26 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 1 Dec 2016 14:03:26 +0100 Subject: [Freeipa-users] Loss of initial master in multi master setup In-Reply-To: References: Message-ID: <96c3ee7b-d0e5-fe87-9585-e4a46ff0991b@redhat.com> On 12/01/2016 01:28 PM, Neal Harrington | i-Neda Ltd wrote: > Hi IPA Gurus, > > > I had a 3 site multi master IPA replication setup (1 office and 2 > datacentres) with 2 IPA servers at each site. Each server was > replicating successfully to 3 other servers (the other local site server > and one server at each of the two remote sites). Everything is running > on the default packages from CentOS 7.2 and each server is a full > replica (ipa-replica-install > /var/lib/ipa/replica-info-id-myserver.fqdn.com.gpg --setup-ca > --setup-dns --mkhomedir --forwarder 8.8.8.8) > > > Everything was ticking over nicely until we had notice that the > office site was moving on short notice. > > > I successfully created IPA servers at the new site, setup replication > again between the new office and the two datacentres that were to remain > online, tested and everything worked as expected - unfortunately in the > rush I did not have time to properly retire the IPA servers in the old > office. > > > The problem this has caused is that I only ever created users in one of > the IPA servers in the original office - so only those servers have a > DNA range and I am now unable to create new users on the active servers. > The original office servers are still in the IPA replication and powered > on but offline so potential split brain? > > > I now have two things I would like to know before proceeding: > > * Is the best fix here to force remove the original IPA servers and > manually add a new dna range significantly different from the > original to avoid overlaps? > * Is there anything else I should check? I can't see any issues > however did not notice the DNA range until I tried to create a user. > > Any pointers greatly appreciated. > > > Thanks, > > Neal. > > > > > > Hi Neal, If you already disconnected/decomissioned the old masters then I thnk the best you can do is option a, i.e. re-set DNA ranges on replicas to new values while avioding overlap with old ranges. We have an upstream document[1] describing the procedure. Hope it helps. Also make sure that you migrated CA renewal and CRL master responsibilities to the new replicas, otherwise you may get problems with expiring certificates which are really hard to solve. See the following guide for details. [2] [1] http://www.freeipa.org/page/V3/Recover_DNA_Ranges [2] http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master -- Martin^3 Babinsky From d.mueller2 at rto.de Thu Dec 1 13:20:41 2016 From: d.mueller2 at rto.de (=?utf-8?B?RGVuaXMgTcO8bGxlcg==?=) Date: Thu, 1 Dec 2016 13:20:41 +0000 Subject: [Freeipa-users] No ad users in web gui In-Reply-To: <64E450F484A55148AE81AFCE975F216851B91958@NAWECHLKXM02V.nadsuswe.nads.navy.mil> References: <64E450F484A55148AE81AFCE975F216851B91958@NAWECHLKXM02V.nadsuswe.nads.navy.mil> Message-ID: <1480598441.10825.40.camel@rto.de> Hello Ipa-users, i established successful trust to an domain controller and able to get ssh working. AD users are able to log into ipa-domain via ssh. But fortunately i can't see those users in the web gui. What im i doing wrong? Greets, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Dec 1 13:26:58 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 1 Dec 2016 15:26:58 +0200 Subject: [Freeipa-users] No ad users in web gui In-Reply-To: <1480598441.10825.40.camel@rto.de> References: <64E450F484A55148AE81AFCE975F216851B91958@NAWECHLKXM02V.nadsuswe.nads.navy.mil> <1480598441.10825.40.camel@rto.de> Message-ID: <20161201132658.6kwpotjnsnmtlq75@redhat.com> On to, 01 joulu 2016, Denis M?ller wrote: >Hello Ipa-users, > >i established successful trust to an domain controller and able to get >ssh working. AD users are able to log into ipa-domain via ssh. But >fortunately i can't see those users in the web gui. What im i doing >wrong? The only thing you are doing wrong is not reading documentation carefully. You are not going to see AD users in IPA web UI because they are not managed there. Go to your AD DC and use Active Directory management tools to Manage AD users and groups. You can use FreeIPA web UI to manage ID overrides for these users and groups. You can use FreeIPA web UI to define mapping between AD users and groups and FreeIPA 'external' groups for the purpose of HBAC and SUDO rules. You cannot manage users/groups from AD, neither use them to manage FreeIPA right now. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Dec 1 13:54:11 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 1 Dec 2016 15:54:11 +0200 Subject: [Freeipa-users] No ad users in web gui In-Reply-To: <20161201132658.6kwpotjnsnmtlq75@redhat.com> References: <64E450F484A55148AE81AFCE975F216851B91958@NAWECHLKXM02V.nadsuswe.nads.navy.mil> <1480598441.10825.40.camel@rto.de> <20161201132658.6kwpotjnsnmtlq75@redhat.com> Message-ID: <20161201135411.ydxlqiveo6hf5hzw@redhat.com> On to, 01 joulu 2016, Alexander Bokovoy wrote: >On to, 01 joulu 2016, Denis M?ller wrote: >>Hello Ipa-users, >> >>i established successful trust to an domain controller and able to get >>ssh working. AD users are able to log into ipa-domain via ssh. But >>fortunately i can't see those users in the web gui. What im i doing >>wrong? >The only thing you are doing wrong is not reading documentation >carefully. You are not going to see AD users in IPA web UI because they >are not managed there. > >Go to your AD DC and use Active Directory management tools to Manage AD >users and groups. > >You can use FreeIPA web UI to manage ID overrides for these users and >groups. You can use FreeIPA web UI to define mapping between AD users >and groups and FreeIPA 'external' groups for the purpose of HBAC and >SUDO rules. > >You cannot manage users/groups from AD, neither use them to manage >FreeIPA right now. ... And I did not mean anything hostile by saying that. Sorry if it was felt so... -- / Alexander Bokovoy From fujisan43 at gmail.com Thu Dec 1 14:12:26 2016 From: fujisan43 at gmail.com (Fujisan) Date: Thu, 1 Dec 2016 15:12:26 +0100 Subject: [Freeipa-users] cannot access to freeipa client's linux share from windows Message-ID: Hello, I have upgraded a client and a freeipa server from Fedora 24 to 25 recently. And I *cannot* access linux shares located on the F25 freeipa client from a windows desktop. But I can access linux shares located on the F25 freeipa server from that windows desktop. And I can access linux shares located on the F24 freeipa client from that windows desktop. To be clear, I have: A/ 1 F25 freeipa server B/ 1 F25 freeipa client C/ 1 F24 freeipa client D/ 1 windows desktop I can access linux shares of A from D. I can access linux shares of C from D. I *cannot* access linux shares of B from D. I get these messages on B in /var/log/samba/log.10.0.21.247 : [2016/12/01 11:42:19.218759, 1] ../source3/librpc/crypto/gse_ krb5.c:534(fill_mem_keytab_from_dedicated_keytab) ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed (Key table name malformed) [2016/12/01 11:42:19.218800, 1] ../source3/librpc/crypto/gse_ krb5.c:627(gse_krb5_get_server_keytab) ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab - -1765328205 [2016/12/01 11:42:19.218823, 1] ../auth/gensec/gensec_start.c: 698(gensec_start_mech) Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR [2016/12/01 11:42:19.261611, 1] ../source3/librpc/crypto/gse_ krb5.c:534(fill_mem_keytab_from_dedicated_keytab) ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed (Key table name malformed) [2016/12/01 11:42:19.261638, 1] ../source3/librpc/crypto/gse_ krb5.c:627(gse_krb5_get_server_keytab) ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab - -1765328205 [2016/12/01 11:42:19.261653, 1] ../auth/gensec/gensec_start.c: 698(gensec_start_mech) Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR [2016/12/01 11:42:19.263330, 2] ../source3/auth/auth.c:315( auth_check_ntlm_password) check_ntlm_password: Authentication for user [smith] -> [smith] FAILED with error NT_STATUS_NO_SUCH_USER [2016/12/01 11:42:19.263380, 2] ../auth/gensec/spnego.c:720( gensec_spnego_server_negTokenTarg) SPNEGO login failed: NT_STATUS_NO_SUCH_USER [2016/12/01 11:42:19.270531, 1] ../source3/librpc/crypto/gse_ krb5.c:534(fill_mem_keytab_from_dedicated_keytab) ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed (Key table name malformed) [2016/12/01 11:42:19.270562, 1] ../source3/librpc/crypto/gse_ krb5.c:627(gse_krb5_get_server_keytab) ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab - -1765328205 [2016/12/01 11:42:19.270586, 1] ../auth/gensec/gensec_start.c: 698(gensec_start_mech) Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR [2016/12/01 11:42:19.313479, 1] ../source3/librpc/crypto/gse_ krb5.c:534(fill_mem_keytab_from_dedicated_keytab) ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed (Key table name malformed) [2016/12/01 11:42:19.313506, 1] ../source3/librpc/crypto/gse_ krb5.c:627(gse_krb5_get_server_keytab) ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab - -1765328205 [2016/12/01 11:42:19.313523, 1] ../auth/gensec/gensec_start.c: 698(gensec_start_mech) Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR [2016/12/01 11:42:19.315256, 2] ../source3/auth/auth.c:315( auth_check_ntlm_password) check_ntlm_password: Authentication for user [smith] -> [smith] FAILED with error NT_STATUS_NO_SUCH_USER [2016/12/01 11:42:19.315291, 2] ../auth/gensec/spnego.c:720( gensec_spnego_server_negTokenTarg) SPNEGO login failed: NT_STATUS_NO_SUCH_USER Also from the F25 server, I have the following when I run smbclient f25server # smbclient -k -L f25desktop.mydomain lp_load_ex: changing to config backend registry session setup failed: NT_STATUS_LOGON_FAILURE But if i run it with a F24 desktop, it works: f25server # smbclient -k -L f24desktop.mydomain lp_load_ex: changing to config backend registry Domain=[MYDOMAIN] OS=[Windows 6.1] Server=[Samba 4.4.7] Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba Server Version 4.4.7) data Disk /data on f24desktop data2 Disk /data2 on f24desktop data3 Disk /data3 on f24desktop backup Disk /backup on f24desktop [...] net conf list on the f25desktop gives: f25desktop # net conf list [global] workgroup = MYDOMAIN realm = MYDOMAIN netbios name = F25SERVER server string = Samba Server Version %v kerberos method = dedicated keytab dedicated keytab file = FILE:/etc/samba/samba.keytab log file = /var/log/samba/log.%m rpc_server:epmapper = external rpc_server:lsarpc = external rpc_server:lsass = external rpc_server:lsasd = external rpc_server:samr = external rpc_server:netlogon = external rpc_server:tcpip = yes rpc_daemon:epmd = fork rpc_daemon:lsasd = fork security = user map untrusted to domain = Yes smb ports = 139 445 log level = 2 [data] comment = /data on f25desktop path = /data create mask = 0644 read only = no [data2] comment = /data2 on f25desktop path = /data2 create mask = 0644 read only = no [data3] comment = /data3 on f25desktop path = /data3 create mask = 0644 read only = no [backup] comment = /backup on f25desktop path = /backup read only = no net conf list on the f25server gives: f25server # net conf list [global] workgroup = MYDOMAIN netbios name = F25SERVER realm = MYDOMAIN kerberos method = dedicated keytab dedicated keytab file = FILE:/etc/samba/samba.keytab create krb5 conf = no domain master = yes domain logons = yes max log size = 10000 log file = /var/log/samba/log.%m passdb backend = ipasam:ldapi://%2fvar%2frun%2fslapd-MYDOMAIN.socket disable spoolss = yes ldapsam:trusted = yes ldap ssl = off ldap suffix = dc=mydomain ldap user suffix = cn=users,cn=accounts ldap group suffix = cn=groups,cn=accounts ldap machine suffix = cn=computers,cn=accounts rpc_server:epmapper = external rpc_server:lsarpc = external rpc_server:lsass = external rpc_server:lsasd = external rpc_server:samr = external rpc_server:netlogon = external rpc_server:tcpip = yes rpc_daemon:epmd = fork rpc_daemon:lsasd = fork security = user enable core files = no log level = 2 [homes] comment = Home Directories read only = no browseable = yes create mask = 0664 directory mask = 0775 on the F25 server and desktop, i have the following packages installed: samba-4.5.1-1.fc25.x86_64 samba-client-4.5.1-1.fc25.x86_64 samba-client-libs-4.5.1-1.fc25.x86_64 samba-common-4.5.1-1.fc25.noarch samba-common-libs-4.5.1-1.fc25.x86_64 samba-common-tools-4.5.1-1.fc25.x86_64 samba-libs-4.5.1-1.fc25.x86_64 samba-python-4.5.1-1.fc25.x86_64 samba-test-4.5.1-1.fc25.x86_64 samba-test-libs-4.5.1-1.fc25.x86_64 samba-winbind-4.5.1-1.fc25.x86_64 samba-winbind-clients-4.5.1-1.fc25.x86_64 samba-winbind-krb5-locator-4.5.1-1.fc25.x86_64 samba-winbind-modules-4.5.1-1.fc25.x86_64 system-config-samba-1.2.100-5.fc24.noarch system-config-samba-docs-1.0.9-9.fc24.noarch Any idea what is wrong? Regards, Fuji -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Dec 1 14:12:54 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 1 Dec 2016 16:12:54 +0200 Subject: [Freeipa-users] No ad users in web gui In-Reply-To: <1480600301.10825.47.camel@rto.de> References: <64E450F484A55148AE81AFCE975F216851B91958@NAWECHLKXM02V.nadsuswe.nads.navy.mil> <1480598441.10825.40.camel@rto.de> <20161201132658.6kwpotjnsnmtlq75@redhat.com> <1480600301.10825.47.camel@rto.de> Message-ID: <20161201141254.zirlap7zpouiypnv@redhat.com> On to, 01 joulu 2016, Denis M?ller wrote: >Hello Alexander, > >thank you for reply. As i understand, working with ad users/groups works this way: > >ad_users => ad_users_external_group => ipa_users_group > >So i can manage ipa_users_group to provide Sudo Rules etc. > >But how can i provide rules to a single user? What would be the best way? The same way -- by specifying user as part of the external group. Check out this email, this topic is raised regularly: https://www.redhat.com/archives/freeipa-users/2016-October/msg00083.html -- / Alexander Bokovoy From rcritten at redhat.com Thu Dec 1 14:38:16 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 1 Dec 2016 09:38:16 -0500 Subject: [Freeipa-users] Loss of initial master in multi master setup In-Reply-To: <96c3ee7b-d0e5-fe87-9585-e4a46ff0991b@redhat.com> References: <96c3ee7b-d0e5-fe87-9585-e4a46ff0991b@redhat.com> Message-ID: <584035D8.7090601@redhat.com> Martin Babinsky wrote: > On 12/01/2016 01:28 PM, Neal Harrington | i-Neda Ltd wrote: >> Hi IPA Gurus, >> >> >> I had a 3 site multi master IPA replication setup (1 office and 2 >> datacentres) with 2 IPA servers at each site. Each server was >> replicating successfully to 3 other servers (the other local site server >> and one server at each of the two remote sites). Everything is running >> on the default packages from CentOS 7.2 and each server is a full >> replica (ipa-replica-install >> /var/lib/ipa/replica-info-id-myserver.fqdn.com.gpg --setup-ca >> --setup-dns --mkhomedir --forwarder 8.8.8.8) >> >> >> Everything was ticking over nicely until we had notice that the >> office site was moving on short notice. >> >> >> I successfully created IPA servers at the new site, setup replication >> again between the new office and the two datacentres that were to remain >> online, tested and everything worked as expected - unfortunately in the >> rush I did not have time to properly retire the IPA servers in the old >> office. >> >> >> The problem this has caused is that I only ever created users in one of >> the IPA servers in the original office - so only those servers have a >> DNA range and I am now unable to create new users on the active servers. >> The original office servers are still in the IPA replication and powered >> on but offline so potential split brain? >> >> >> I now have two things I would like to know before proceeding: >> >> * Is the best fix here to force remove the original IPA servers and >> manually add a new dna range significantly different from the >> original to avoid overlaps? >> * Is there anything else I should check? I can't see any issues >> however did not notice the DNA range until I tried to create a user. >> >> Any pointers greatly appreciated. >> >> >> Thanks, >> >> Neal. >> >> >> >> >> >> > > Hi Neal, > > If you already disconnected/decomissioned the old masters then I thnk > the best you can do is option a, i.e. re-set DNA ranges on replicas to > new values while avioding overlap with old ranges. > > We have an upstream document[1] describing the procedure. Hope it helps. > > Also make sure that you migrated CA renewal and CRL master > responsibilities to the new replicas, otherwise you may get problems > with expiring certificates which are really hard to solve. See the > following guide for details. [2] > > [1] http://www.freeipa.org/page/V3/Recover_DNA_Ranges > [2] http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master > You may want to look at this too, http://blog-rcritten.rhcloud.com/?p=50 rob From rcritten at redhat.com Thu Dec 1 14:41:44 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 1 Dec 2016 09:41:44 -0500 Subject: [Freeipa-users] ipa fails to start hangs on pki-tomcatd In-Reply-To: References: Message-ID: <584036A8.1030403@redhat.com> Rob Verduijn wrote: > Hello, > > For some reason my ipa server no longer boots. > It keeps trying to start pki-tomcat service. > > Does anybody know where I should start looking to get this fixed ? > > Rob Verduijn > > ipactl -d start gives this output: > ipa: DEBUG: The CA status is: check interrupted due to error: Command > ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus'' returned > non-zero exit status 8 > ipa: DEBUG: Waiting for CA to start... > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' > '--no-check-certificate' > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus' > ipa: DEBUG: Process finished, return code=8 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=--2016-12-01 11:06:12-- > https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus > Resolving freeipa02.tjako.thuis (freeipa02.tjako.thuis)... 172.16.1.13 > Connecting to freeipa02.tjako.thuis > (freeipa02.tjako.thuis)|172.16.1.13|:8443... connected. > HTTP request sent, awaiting response... > HTTP/1.1 500 Internal Server Error > Server: Apache-Coyote/1.1 > Content-Type: text/html;charset=utf-8 > Content-Language: en > Content-Length: 2134 > Date: Thu, 01 Dec 2016 10:06:13 GMT > Connection: close > 2016-12-01 11:06:13 ERROR 500: Internal Server Error. > > There are also some java warnings in the logs, but its java and I can > never tell if its a serious error when java gives a warning. > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > org.apache.catalina.startup.SetAllPropertiesRule begin > Dec 1 09:53:59 freeipa02 server: WARNING: > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'serverCertNickFile' to > '/var/lib/pki/pki-tomcat/conf/serverCertNick.conf' did not find a > matching property. > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > org.apache.catalina.startup.SetAllPropertiesRule begin > Dec 1 09:53:59 freeipa02 server: WARNING: > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'passwordFile' to '/var/lib/pki/pki-tomcat/conf/password.conf' did not > find a matching property. > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > org.apache.catalina.startup.SetAllPropertiesRule begin > Dec 1 09:53:59 freeipa02 server: WARNING: > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'passwordClass' to 'org.apache.tomcat.util.net.jss.PlainPasswordFile' > did not find a matching property. > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > org.apache.catalina.startup.SetAllPropertiesRule begin > Dec 1 09:53:59 freeipa02 server: WARNING: > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'certdbDir' to '/var/lib/pki/pki-tomcat/alias' did not find a matching > property. > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > org.apache.tomcat.util.digester.SetPropertiesRule begin > Dec 1 09:53:59 freeipa02 server: WARNING: > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property > 'xmlValidation' to 'false' did not find a matching property. > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > org.apache.tomcat.util.digester.SetPropertiesRule begin > Dec 1 09:53:59 freeipa02 server: WARNING: > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property > 'xmlNamespaceAware' to 'false' did not find a matching property. > > > I'm running centos7.2 x86_64 with the latest patches applied. > some package versions below > rpm -qa|egrep "ipa|tomcat"|sort > ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64 > ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64 > ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64 > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 > ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64 > libipa_hbac-1.13.0-40.el7_2.12.x86_64 > python-iniparse-0.4-9.el7.noarch > python-libipa_hbac-1.13.0-40.el7_2.12.x86_64 > sssd-ipa-1.13.0-40.el7_2.12.x86_64 > tomcat-7.0.54-8.el7_2.noarch > tomcat-el-2.2-api-7.0.54-8.el7_2.noarch > tomcat-jsp-2.2-api-7.0.54-8.el7_2.noarch > tomcatjss-7.1.2-1.el7.noarch > tomcat-lib-7.0.54-8.el7_2.noarch > tomcat-servlet-3.0-api-7.0.54-8.el7_2.noarch The debug log is quite verbose. I find it helpful to note where the previous log ended, starting and pulling the difference and going line by line. It sometimes fails in one place which cascades to others this generally makes it hard to grok. I'd also run `getcert list` and check to ensure that the CA subsystem certificates are still valid. rob From abokovoy at redhat.com Thu Dec 1 15:12:10 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 1 Dec 2016 17:12:10 +0200 Subject: [Freeipa-users] No ad users in web gui In-Reply-To: <1480603871.10825.52.camel@rto.de> References: <64E450F484A55148AE81AFCE975F216851B91958@NAWECHLKXM02V.nadsuswe.nads.navy.mil> <1480598441.10825.40.camel@rto.de> <20161201132658.6kwpotjnsnmtlq75@redhat.com> <1480600301.10825.47.camel@rto.de> <20161201141254.zirlap7zpouiypnv@redhat.com> <1480603871.10825.52.camel@rto.de> Message-ID: <20161201151210.imq5mexmknnnjcac@redhat.com> Please keep freeipa-users@ in CC: On to, 01 joulu 2016, Denis M?ller wrote: >Sorry, but i still do not understand how can i apply a single HAC-Rule >to a single user. Editing a HBAC-Rule, there is no option to select an >ad_user. As I said, there wouldn't any. The concept is that you need to have a real LDAP object to include into the HBAC or SUDO rule and that object must be a POSIX user or group. We cannot map AD user to POSIX user this way yet, only to POSIX groups, so in the HBAC rule you need to use POSIX group to add instead of AD user (or IPA user). > >[root at ipa01 ~]# ipa group-show ad_users_external > Gruppenname: ad_users_external > Beschreibung: AD users external map > Mitglied der Gruppen: ad_users > Indirect Member of HBAC rule: ssh_rule > External member: user1 at rto.de, user2 at rto.de > > > >[root at ipa01 ~]# ipa hbacrule-add-user >Regelname: ssh_rule >[Mitglied Benutzer]: user1 at rto.de >[Mitglied Gruppe]: ad_users_external > Regelname: ssh_rule > Aktiviert: TRUE > Benutzergruppen: ad_users, ad_users_external > Hosts: ipa-web.wop.bto.de > Dienste: sshd > Failed users/groups: > Mitglied Benutzer: user1 at rto.de: no such entry > Mitglied Gruppe: > > >Am Donnerstag, den 01.12.2016, 16:12 +0200 schrieb Alexander Bokovoy: > >On to, 01 joulu 2016, Denis M?ller wrote: > > >Hello Alexander, > >thank you for reply. As i understand, working with ad users/groups works this way: > >ad_users => ad_users_external_group => ipa_users_group > >So i can manage ipa_users_group to provide Sudo Rules etc. > >But how can i provide rules to a single user? What would be the best way? > > >The same way -- by specifying user as part of the external group. > >Check out this email, this topic is raised regularly: >https://www.redhat.com/archives/freeipa-users/2016-October/msg00083.html > > -- / Alexander Bokovoy From rob.verduijn at gmail.com Thu Dec 1 15:23:45 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Thu, 1 Dec 2016 16:23:45 +0100 Subject: [Freeipa-users] ipa fails to start hangs on pki-tomcatd In-Reply-To: <584036A8.1030403@redhat.com> References: <584036A8.1030403@redhat.com> Message-ID: 2016-12-01 15:41 GMT+01:00 Rob Crittenden : > Rob Verduijn wrote: > > Hello, > > > > For some reason my ipa server no longer boots. > > It keeps trying to start pki-tomcat service. > > > > Does anybody know where I should start looking to get this fixed ? > > > > Rob Verduijn > > > > ipactl -d start gives this output: > > ipa: DEBUG: The CA status is: check interrupted due to error: Command > > ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' > > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus'' returned > > non-zero exit status 8 > > ipa: DEBUG: Waiting for CA to start... > > ipa: DEBUG: Starting external process > > ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' > > '--no-check-certificate' > > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus' > > ipa: DEBUG: Process finished, return code=8 > > ipa: DEBUG: stdout= > > ipa: DEBUG: stderr=--2016-12-01 11:06:12-- > > https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus > > Resolving freeipa02.tjako.thuis (freeipa02.tjako.thuis)... 172.16.1.13 > > Connecting to freeipa02.tjako.thuis > > (freeipa02.tjako.thuis)|172.16.1.13|:8443... connected. > > HTTP request sent, awaiting response... > > HTTP/1.1 500 Internal Server Error > > Server: Apache-Coyote/1.1 > > Content-Type: text/html;charset=utf-8 > > Content-Language: en > > Content-Length: 2134 > > Date: Thu, 01 Dec 2016 10:06:13 GMT > > Connection: close > > 2016-12-01 11:06:13 ERROR 500: Internal Server Error. > > > > There are also some java warnings in the logs, but its java and I can > > never tell if its a serious error when java gives a warning. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.catalina.startup.SetAllPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > 'serverCertNickFile' to > > '/var/lib/pki/pki-tomcat/conf/serverCertNick.conf' did not find a > > matching property. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.catalina.startup.SetAllPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > 'passwordFile' to '/var/lib/pki/pki-tomcat/conf/password.conf' did not > > find a matching property. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.catalina.startup.SetAllPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > 'passwordClass' to 'org.apache.tomcat.util.net.jss.PlainPasswordFile' > > did not find a matching property. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.catalina.startup.SetAllPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > 'certdbDir' to '/var/lib/pki/pki-tomcat/alias' did not find a matching > > property. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.tomcat.util.digester.SetPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property > > 'xmlValidation' to 'false' did not find a matching property. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.tomcat.util.digester.SetPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property > > 'xmlNamespaceAware' to 'false' did not find a matching property. > > > > > > I'm running centos7.2 x86_64 with the latest patches applied. > > some package versions below > > rpm -qa|egrep "ipa|tomcat"|sort > > ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64 > > libipa_hbac-1.13.0-40.el7_2.12.x86_64 > > python-iniparse-0.4-9.el7.noarch > > python-libipa_hbac-1.13.0-40.el7_2.12.x86_64 > > sssd-ipa-1.13.0-40.el7_2.12.x86_64 > > tomcat-7.0.54-8.el7_2.noarch > > tomcat-el-2.2-api-7.0.54-8.el7_2.noarch > > tomcat-jsp-2.2-api-7.0.54-8.el7_2.noarch > > tomcatjss-7.1.2-1.el7.noarch > > tomcat-lib-7.0.54-8.el7_2.noarch > > tomcat-servlet-3.0-api-7.0.54-8.el7_2.noarch > > The debug log is quite verbose. I find it helpful to note where the > previous log ended, starting and pulling the difference and going line > by line. It sometimes fails in one place which cascades to others this > generally makes it hard to grok. > > I'd also run `getcert list` and check to ensure that the CA subsystem > certificates are still valid. > > rob > Hi, My certs where indeed expired. I did what was said in here http://www.freeipa.org/page/Howto/CA_Certificate_Renewal And now they are all valid again. However it is still stuck at the same spot. It keeps waiting for the ca to start and gets an internal error. In the pki-cataline logs this keeps repeating : Dec 01, 2016 4:22:44 PM org.apache.catalina.core.ContainerBase backgroundProcess WARNING: Exception processing realm com.netscape.cms.tomcat.ProxyRealm at 6934e456 background process java.lang.NullPointerException at com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:108) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1360) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519) at java.lang.Thread.run(Thread.java:745) I keep digging through the logs, but they are rather overwhelming. Have you got any pointers for me ? Rob Verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From nharrington at i-neda.com Thu Dec 1 15:53:06 2016 From: nharrington at i-neda.com (Neal Harrington | i-Neda Ltd) Date: Thu, 1 Dec 2016 15:53:06 +0000 Subject: [Freeipa-users] Loss of initial master in multi master setup In-Reply-To: <96c3ee7b-d0e5-fe87-9585-e4a46ff0991b@redhat.com> References: <96c3ee7b-d0e5-fe87-9585-e4a46ff0991b@redhat.com> Message-ID: > > Hi IPA Gurus, > > > > > > I had a 3 site multi master IPA replication setup (1 office and 2 > > datacentres) with 2 IPA servers at each site. Each server was > > replicating successfully to 3 other servers (the other local site > > server and one server at each of the two remote sites). Everything is > > running on the default packages from CentOS 7.2 and each server is a > > full replica (ipa-replica-install > > /var/lib/ipa/replica-info-id-myserver.fqdn.com.gpg --setup-ca > > --setup-dns --mkhomedir --forwarder 8.8.8.8) > > > > > > Everything was ticking over nicely until we had notice that the office > > site was moving on short notice. > > > > > > I successfully created IPA servers at the new site, setup replication > > again between the new office and the two datacentres that were to > > remain online, tested and everything worked as expected - > > unfortunately in the rush I did not have time to properly retire the > > IPA servers in the old office. > > > > > > The problem this has caused is that I only ever created users in one > > of the IPA servers in the original office - so only those servers have > > a DNA range and I am now unable to create new users on the active > servers. > > The original office servers are still in the IPA replication and > > powered on but offline so potential split brain? > > > > > > I now have two things I would like to know before proceeding: > > > > * Is the best fix here to force remove the original IPA servers and > > manually add a new dna range significantly different from the > > original to avoid overlaps? > > * Is there anything else I should check? I can't see any issues > > however did not notice the DNA range until I tried to create a user. > > > > Any pointers greatly appreciated. > > > > > > Thanks, > > > > Neal. > > Hi Neal, > > If you already disconnected/decomissioned the old masters then I thnk the > best you can do is option a, i.e. re-set DNA ranges on replicas to new values > while avioding overlap with old ranges. > > We have an upstream document[1] describing the procedure. Hope it helps. > > Also make sure that you migrated CA renewal and CRL master responsibilities > to the new replicas, otherwise you may get problems with expiring > certificates which are really hard to solve. See the following guide for details. > [2] > > [1] http://www.freeipa.org/page/V3/Recover_DNA_Ranges > [2] > http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_ > Master > > -- > Martin^3 Babinsky Hi Martin & Rob, Thank you very much for the pointers. I have added a new range to a IPA server I used the top half of the previous range, I only had 30 ish ID's used so far) # ipa-replica-manage dnarange-set office03.fqdn.com 310300000-310399999 and this has allowed me to add a user on that server. However when I try to add a user on a different server it still fails with "allocation of new value for range". I was expecting this to request a new range and halve the currently assigned range. Robs link included this command: # ldapsearch -x -D 'cn=Directory Manager' -W -b cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=int,dc=i-neda,dc=com ...Which seems to list all of the other servers, including office03.fqdn.com which it shows as having 99999 dnaRemainingValues (all the rest have 0) so the server that cannot add users can see office03 has 99999 unused. However of more immediate concern now I can create user accounts is the CA replication which I seem to have completely messed up. Most CA replication went back to the (now offline) office and even what I have does not seem to work as expected. Eg on Office03: # ldapsearch -H ldap://$HOSTNAME -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn search result search: 2 result: 32 No such object Following the instructions to set the master seems to work at first (no errors) but the ldap search for renewal master still returns "result: 32 No Such Object" # ipa-csreplica-manage set-renewal-master ipa: WARNING: session memcached servers not running Directory Manager password: office03.fqdn.com is now the renewal master re running the set-renwal-master command reports that this server is already the renewal master. I think I need to reinitialize the CA replication and connect everything up in a redundant loop as I have with the main replication - however the LDAP query not returning the replication master does not seem right. I have not added any IPA servers since these network changes happened a week ago, is it reasonably safe to assume no certificates will have been created so all servers are effectively in sync? Your help with this is greatly appreciated. On the plus side the systems we use this for are all dev, not live, so it is a good learning experience for me if nothing else! Best Regards, Neal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Dec 1 16:20:45 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 1 Dec 2016 11:20:45 -0500 Subject: [Freeipa-users] ipa fails to start hangs on pki-tomcatd In-Reply-To: References: <584036A8.1030403@redhat.com> Message-ID: <58404DDD.2020000@redhat.com> Rob Verduijn wrote: > > > 2016-12-01 15:41 GMT+01:00 Rob Crittenden >: > > Rob Verduijn wrote: > > Hello, > > > > For some reason my ipa server no longer boots. > > It keeps trying to start pki-tomcat service. > > > > Does anybody know where I should start looking to get this fixed ? > > > > Rob Verduijn > > > > ipactl -d start gives this output: > > ipa: DEBUG: The CA status is: check interrupted due to error: Command > > ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' > > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus > '' returned > > non-zero exit status 8 > > ipa: DEBUG: Waiting for CA to start... > > ipa: DEBUG: Starting external process > > ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' > > '--no-check-certificate' > > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus > ' > > ipa: DEBUG: Process finished, return code=8 > > ipa: DEBUG: stdout= > > ipa: DEBUG: stderr=--2016-12-01 11:06:12-- > > https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus > > > Resolving freeipa02.tjako.thuis (freeipa02.tjako.thuis)... 172.16.1.13 > > Connecting to freeipa02.tjako.thuis > > (freeipa02.tjako.thuis)|172.16.1.13|:8443... connected. > > HTTP request sent, awaiting response... > > HTTP/1.1 500 Internal Server Error > > Server: Apache-Coyote/1.1 > > Content-Type: text/html;charset=utf-8 > > Content-Language: en > > Content-Length: 2134 > > Date: Thu, 01 Dec 2016 10:06:13 GMT > > Connection: close > > 2016-12-01 11:06:13 ERROR 500: Internal Server Error. > > > > There are also some java warnings in the logs, but its java and I can > > never tell if its a serious error when java gives a warning. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.catalina.startup.SetAllPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > 'serverCertNickFile' to > > '/var/lib/pki/pki-tomcat/conf/serverCertNick.conf' did not find a > > matching property. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.catalina.startup.SetAllPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > 'passwordFile' to '/var/lib/pki/pki-tomcat/conf/password.conf' did not > > find a matching property. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.catalina.startup.SetAllPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > 'passwordClass' to 'org.apache.tomcat.util.net > .jss.PlainPasswordFile' > > did not find a matching property. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.catalina.startup.SetAllPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > 'certdbDir' to '/var/lib/pki/pki-tomcat/alias' did not find a matching > > property. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.tomcat.util.digester.SetPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property > > 'xmlValidation' to 'false' did not find a matching property. > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > org.apache.tomcat.util.digester.SetPropertiesRule begin > > Dec 1 09:53:59 freeipa02 server: WARNING: > > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property > > 'xmlNamespaceAware' to 'false' did not find a matching property. > > > > > > I'm running centos7.2 x86_64 with the latest patches applied. > > some package versions below > > rpm -qa|egrep "ipa|tomcat"|sort > > ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64 > > libipa_hbac-1.13.0-40.el7_2.12.x86_64 > > python-iniparse-0.4-9.el7.noarch > > python-libipa_hbac-1.13.0-40.el7_2.12.x86_64 > > sssd-ipa-1.13.0-40.el7_2.12.x86_64 > > tomcat-7.0.54-8.el7_2.noarch > > tomcat-el-2.2-api-7.0.54-8.el7_2.noarch > > tomcat-jsp-2.2-api-7.0.54-8.el7_2.noarch > > tomcatjss-7.1.2-1.el7.noarch > > tomcat-lib-7.0.54-8.el7_2.noarch > > tomcat-servlet-3.0-api-7.0.54-8.el7_2.noarch > > The debug log is quite verbose. I find it helpful to note where the > previous log ended, starting and pulling the difference and going line > by line. It sometimes fails in one place which cascades to others this > generally makes it hard to grok. > > I'd also run `getcert list` and check to ensure that the CA subsystem > certificates are still valid. > > rob > > > > Hi, > > My certs where indeed expired. > I did what was said in here > http://www.freeipa.org/page/Howto/CA_Certificate_Renewal > And now they are all valid again. > > However it is still stuck at the same spot. > It keeps waiting for the ca to start and gets an internal error. > > In the pki-cataline logs this keeps repeating : > Dec 01, 2016 4:22:44 PM org.apache.catalina.core.ContainerBase > backgroundProcess > WARNING: Exception processing realm > com.netscape.cms.tomcat.ProxyRealm at 6934e456 background process > java.lang.NullPointerException > at > com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:108) > at > org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1360) > at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530) > at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540) > at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540) > at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519) > at java.lang.Thread.run(Thread.java:745) > > I keep digging through the logs, but they are rather overwhelming. > > Have you got any pointers for me ? My only recommendation is to read top-down instead of bottom up as one would normally do. Look for the selftest and see if it was successful. If it wasn't then nothing will work. rob From outbackdingo at gmail.com Thu Dec 1 16:50:40 2016 From: outbackdingo at gmail.com (Outback Dingo) Date: Fri, 2 Dec 2016 00:50:40 +0800 Subject: [Freeipa-users] new IPA Servers Message-ID: trying to deploy new ipa servers so i can take down the old ones prior to a move however the install is failing with. zone optimcloud.com. already exists in DNS and is handled by server(s): ipa.optimcloud.com., ipa2.optimcloud.com. so how can i get around this... note the old servers are going away forever. but i need them alive until the new ones are ready From mbabinsk at redhat.com Thu Dec 1 16:55:21 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 1 Dec 2016 17:55:21 +0100 Subject: [Freeipa-users] new IPA Servers In-Reply-To: References: Message-ID: On 12/01/2016 05:50 PM, Outback Dingo wrote: > trying to deploy new ipa servers so i can take down the old ones prior > to a move however the install is failing with. > > zone optimcloud.com. already exists in DNS and is handled by > server(s): ipa.optimcloud.com., ipa2.optimcloud.com. > > > so how can i get around this... note the old servers are going away > forever. but i need them alive until the new ones are ready > The error message says that you are trying to install DNS server for a zone that is already managed by old masters. You should rather create replicas of the old servers, move CA renewal/CRL/DNSSec master from them to new replicas and then disconnect and decommission the old masters. -- Martin^3 Babinsky From bnordgren at fs.fed.us Thu Dec 1 17:47:58 2016 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Thu, 1 Dec 2016 17:47:58 +0000 Subject: [Freeipa-users] Freeipa on ARM (raspberry pi) - OpenJDK vs. Oracle JDK In-Reply-To: <06aaa943-160f-fb13-d598-9d85c5fef2da@dds.nl> References: <06aaa943-160f-fb13-d598-9d85c5fef2da@dds.nl> Message-ID: My guess aligns with this response: http://stackoverflow.com/questions/31153584/why-is-there-such-a-performance-difference-on-raspberry-pi-between-open-and-orac Bryce From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Winfried de Heiden Sent: Thursday, December 01, 2016 1:08 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] Freeipa on ARM (raspberry pi) - OpenJDK vs. Oracle JDK Hi all, Started as "just because it's possible" running FreeIPA on a BananaPI or Raspberry PI turned to out to be rather succesfull and for more than a year I use FreeIPA at home. OK, running on small boards like Raspberry PI it never will be fast but it's surely quick enough to run at small scale. However, starting FreeIPA became much slower since Fedora 24 and even more on Fedora 25. Since Oracle Java is also available for ARM and there's much written this is much faster I took some time for an experiment. Starting FreeIPA using the default installation (running OpenJDK) starting FreeIPA takes a painfull 15 minutes (afterward, it all just works fine): [root at rpi2 sysconfig]# time ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting ipa-custodia Service Starting ntpd Service Starting pki-tomcatd Service Starting ipa-otpd Service Starting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful real 15m40.638s user 0m33.095s sys 0m1.910s Now, after installing Oracle Java and changing JAVA_HOME in /etc/sysconfig/pki-tomcat to: #JAVA_HOME="/usr/lib/jvm/jre-1.8.0-openjdk" JAVA_HOME="/opt/jdk1.8.0_111/jre" [root at rpi2 sysconfig]# time ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting ipa-custodia Service Starting ntpd Service Starting pki-tomcatd Service Starting ipa-otpd Service Starting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful real 2m14.823s user 0m33.400s sys 0m1.730s Wow, I expected some improvement, but this far better than expected! This leaves a question: what is happening here!!?? I prefer to use OpenJDK, it 's Open Source and because it's availabe from the Fedora ARM repositories it is also much more easy to update. But for now, Oracle is much faster and OpenJDK from this point of view is a very poor alternative. Why is OpenJDK so much slower? Is improvement possible? For now (some "tweaking") of in a future release? For the record, I tested these Java versions: [root at rpi2 sysconfig]# /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-3.b16.fc25.arm/jre/bin/java -version openjdk version "1.8.0_111" OpenJDK Runtime Environment (build 1.8.0_111-b16) OpenJDK Zero VM (build 25.111-b16, interpreted mode) [root at rpi2 sysconfig]# /opt/jdk1.8.0_111/jre/bin/java -version java version "1.8.0_111" Java(TM) SE Runtime Environment (build 1.8.0_111-b14) Java HotSpot(TM) Client VM (build 25.111-b14, mixed mode) Kind regards, Winfried 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Thu Dec 1 18:44:24 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Thu, 1 Dec 2016 19:44:24 +0100 Subject: [Freeipa-users] ipa fails to start hangs on pki-tomcatd In-Reply-To: <58404DDD.2020000@redhat.com> References: <584036A8.1030403@redhat.com> <58404DDD.2020000@redhat.com> Message-ID: 2016-12-01 17:20 GMT+01:00 Rob Crittenden : > Rob Verduijn wrote: > > > > > > 2016-12-01 15:41 GMT+01:00 Rob Crittenden > >: > > > > Rob Verduijn wrote: > > > Hello, > > > > > > For some reason my ipa server no longer boots. > > > It keeps trying to start pki-tomcat service. > > > > > > Does anybody know where I should start looking to get this fixed ? > > > > > > Rob Verduijn > > > > > > ipactl -d start gives this output: > > > ipa: DEBUG: The CA status is: check interrupted due to error: > Command > > > ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' > '--no-check-certificate' > > > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus > > '' > returned > > > non-zero exit status 8 > > > ipa: DEBUG: Waiting for CA to start... > > > ipa: DEBUG: Starting external process > > > ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' > > > '--no-check-certificate' > > > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus > > ' > > > ipa: DEBUG: Process finished, return code=8 > > > ipa: DEBUG: stdout= > > > ipa: DEBUG: stderr=--2016-12-01 11:06:12-- > > > https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus > > > > > Resolving freeipa02.tjako.thuis (freeipa02.tjako.thuis)... > 172.16.1.13 > > > Connecting to freeipa02.tjako.thuis > > > (freeipa02.tjako.thuis)|172.16.1.13|:8443... connected. > > > HTTP request sent, awaiting response... > > > HTTP/1.1 500 Internal Server Error > > > Server: Apache-Coyote/1.1 > > > Content-Type: text/html;charset=utf-8 > > > Content-Language: en > > > Content-Length: 2134 > > > Date: Thu, 01 Dec 2016 10:06:13 GMT > > > Connection: close > > > 2016-12-01 11:06:13 ERROR 500: Internal Server Error. > > > > > > There are also some java warnings in the logs, but its java and I > can > > > never tell if its a serious error when java gives a warning. > > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > > org.apache.catalina.startup.SetAllPropertiesRule begin > > > Dec 1 09:53:59 freeipa02 server: WARNING: > > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > > 'serverCertNickFile' to > > > '/var/lib/pki/pki-tomcat/conf/serverCertNick.conf' did not find a > > > matching property. > > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > > org.apache.catalina.startup.SetAllPropertiesRule begin > > > Dec 1 09:53:59 freeipa02 server: WARNING: > > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > > 'passwordFile' to '/var/lib/pki/pki-tomcat/conf/password.conf' > did not > > > find a matching property. > > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > > org.apache.catalina.startup.SetAllPropertiesRule begin > > > Dec 1 09:53:59 freeipa02 server: WARNING: > > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > > 'passwordClass' to 'org.apache.tomcat.util.net > > .jss.PlainPasswordFile' > > > did not find a matching property. > > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > > org.apache.catalina.startup.SetAllPropertiesRule begin > > > Dec 1 09:53:59 freeipa02 server: WARNING: > > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property > > > 'certdbDir' to '/var/lib/pki/pki-tomcat/alias' did not find a > matching > > > property. > > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > > org.apache.tomcat.util.digester.SetPropertiesRule begin > > > Dec 1 09:53:59 freeipa02 server: WARNING: > > > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property > > > 'xmlValidation' to 'false' did not find a matching property. > > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM > > > org.apache.tomcat.util.digester.SetPropertiesRule begin > > > Dec 1 09:53:59 freeipa02 server: WARNING: > > > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property > > > 'xmlNamespaceAware' to 'false' did not find a matching property. > > > > > > > > > I'm running centos7.2 x86_64 with the latest patches applied. > > > some package versions below > > > rpm -qa|egrep "ipa|tomcat"|sort > > > ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64 > > > ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64 > > > ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64 > > > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 > > > ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64 > > > libipa_hbac-1.13.0-40.el7_2.12.x86_64 > > > python-iniparse-0.4-9.el7.noarch > > > python-libipa_hbac-1.13.0-40.el7_2.12.x86_64 > > > sssd-ipa-1.13.0-40.el7_2.12.x86_64 > > > tomcat-7.0.54-8.el7_2.noarch > > > tomcat-el-2.2-api-7.0.54-8.el7_2.noarch > > > tomcat-jsp-2.2-api-7.0.54-8.el7_2.noarch > > > tomcatjss-7.1.2-1.el7.noarch > > > tomcat-lib-7.0.54-8.el7_2.noarch > > > tomcat-servlet-3.0-api-7.0.54-8.el7_2.noarch > > > > The debug log is quite verbose. I find it helpful to note where the > > previous log ended, starting and pulling the difference and going > line > > by line. It sometimes fails in one place which cascades to others > this > > generally makes it hard to grok. > > > > I'd also run `getcert list` and check to ensure that the CA subsystem > > certificates are still valid. > > > > rob > > > > > > > > Hi, > > > > My certs where indeed expired. > > I did what was said in here > > http://www.freeipa.org/page/Howto/CA_Certificate_Renewal > > And now they are all valid again. > > > > However it is still stuck at the same spot. > > It keeps waiting for the ca to start and gets an internal error. > > > > In the pki-cataline logs this keeps repeating : > > Dec 01, 2016 4:22:44 PM org.apache.catalina.core.ContainerBase > > backgroundProcess > > WARNING: Exception processing realm > > com.netscape.cms.tomcat.ProxyRealm at 6934e456 background process > > java.lang.NullPointerException > > at > > com.netscape.cms.tomcat.ProxyRealm.backgroundProcess( > ProxyRealm.java:108) > > at > > org.apache.catalina.core.ContainerBase.backgroundProcess( > ContainerBase.java:1360) > > at > > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor. > processChildren(ContainerBase.java:1530) > > at > > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor. > processChildren(ContainerBase.java:1540) > > at > > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor. > processChildren(ContainerBase.java:1540) > > at > > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor. > run(ContainerBase.java:1519) > > at java.lang.Thread.run(Thread.java:745) > > > > I keep digging through the logs, but they are rather overwhelming. > > > > Have you got any pointers for me ? > > My only recommendation is to read top-down instead of bottom up as one > would normally do. Look for the selftest and see if it was successful. > If it wasn't then nothing will work. > > rob > in the pki-catalina log I find a lot of warnings are these real warnings or just noise from tomcat ? Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'enableOCSP' to 'false' did not find a matching property. Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderURL' to 'http://freeipa02.tjako.thuis:9080/ca/ocsp' did not find a matching property. Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a matching property. Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspCacheSize' to '1000' did not find a matching property. Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspMinCacheEntryDuration' to '60' did not find a matching property. Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspMaxCacheEntryDuration' to '120' did not find a matching property. Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspTimeout' to '10' did not find a matching property. Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'strictCiphers' to 'true' did not find a matching property. Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'sslOptions' to 'ssl2=false,ssl3=false,tls=true' did not find a matching property. Rob Verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikej at flowjo.com Thu Dec 1 19:37:31 2016 From: mikej at flowjo.com (Mike Jacobacci) Date: Thu, 1 Dec 2016 11:37:31 -0800 Subject: [Freeipa-users] FreeIPA, Ipsilon, Duo Security integration Message-ID: Hi, As of now, we have FreeIPA/FreeRadius with OTP and Ipsilon working perfectly. Now, I am looking at possibly integrating Duo security instead of FreeIPA's 2FA. I am concerned about how it will fit in with Ipsilon and FreeIPA... Has anyone else tried this before? If so, are there any pitfalls or problems you have encountered or any general advise? Cheers, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Dec 1 21:34:50 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Dec 2016 16:34:50 -0500 Subject: [Freeipa-users] FreeIPA, Ipsilon, Duo Security integration In-Reply-To: References: Message-ID: <1480628090.4311.103.camel@redhat.com> On Thu, 2016-12-01 at 11:37 -0800, Mike Jacobacci wrote: > Hi, > > As of now, we have FreeIPA/FreeRadius with OTP and Ipsilon working > perfectly. Now, I am looking at possibly integrating Duo security instead > of FreeIPA's 2FA. I am concerned about how it will fit in with Ipsilon and > FreeIPA... Has anyone else tried this before? If so, are there any > pitfalls or problems you have encountered or any general advise? I think there are issues with the workflow Duo requires and the latency (sending token via SMS and waiting for user to input). Simo. -- Simo Sorce * Red Hat, Inc * New York From jochen at jochen.org Thu Dec 1 22:32:06 2016 From: jochen at jochen.org (Jochen Hein) Date: Thu, 01 Dec 2016 23:32:06 +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: <834m2n46xl.fsf@echidna.jochen.org> Jochen Hein writes: > 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. > > 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. > When installing a replica with "ipa-replica-install --setup-ca" I get: ... > [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 CentOS 7.2/7.3 we have python-jwcrypto-0.2.1-1.el7, in Fedora 23 we have 0.3.2-1. https://github.com/latchset/jwcrypto/issues/47 talks about problems with FreeIPA and custodia, and that downgrading python-jwcrypto helped. Since I consider the way forward a better choice I upgraded python-jwcrypto on CentOS to 0.3.2, and now I have new replicas with FreeIPA 4.4 attached to my 4.3 master. Yeah! It might be a good idea to get the package in CentOS/RHEL upgraded... Jochen -- The only problem with troubleshooting is that the trouble shoots back. From jrichard at placeiq.com Fri Dec 2 01:32:50 2016 From: jrichard at placeiq.com (Jim Richard) Date: Thu, 1 Dec 2016 20:32:50 -0500 Subject: [Freeipa-users] ACIerrors is httpd log In-Reply-To: <583C8806.1030809@redhat.com> References: <4B8D5975-7858-4CC2-99AF-FC1E4D6EEB93@placeiq.com> <583C8806.1030809@redhat.com> Message-ID: I think I know what the issue is. I had 2 IPA servers, both with CA?s I dropped one and rebuilt without the CA but a bunch of clients are still pointing at this one server that now is without a CA. Will rebuild that one with a CA and almost sure that will fix. Jim Richard SYSTEM ADMINISTRATOR III (646) 338-8905 > On Nov 28, 2016, at 2:39 PM, Rob Crittenden wrote: > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Dec 2 03:56:57 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 1 Dec 2016 22:56:57 -0500 Subject: [Freeipa-users] ACIerrors is httpd log In-Reply-To: References: <4B8D5975-7858-4CC2-99AF-FC1E4D6EEB93@placeiq.com> <583C8806.1030809@redhat.com> Message-ID: <5840F109.1040507@redhat.com> Jim Richard wrote: > I think I know what the issue is. > > I had 2 IPA servers, both with CA?s > > I dropped one and rebuilt without the CA but a bunch of clients are > still pointing at this one server that now is without a CA. > > Will rebuild that one with a CA and almost sure that will fix. I'm rather skeptical of that. Not having a CA should not result in an ACI error. It should internally forward any cert requests to an IPA server that does have a CA and relay the result back to the requester. rob > > > Jim Richard > > > > SYSTEM ADMINISTRATOR III > /(646) 338-8905 / > > > PlaceIQ:Alibaba > > > > > >> On Nov 28, 2016, at 2:39 PM, Rob Crittenden > > wrote: >> >> 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 abokovoy at redhat.com Fri Dec 2 09:29:51 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Dec 2016 11:29:51 +0200 Subject: [Freeipa-users] cannot access to freeipa client's linux share from windows In-Reply-To: References: Message-ID: <20161202092951.uajc7sypj5q7t4cw@redhat.com> On to, 01 joulu 2016, Fujisan wrote: >Hello, > >I have upgraded a client and a freeipa server from Fedora 24 to 25 recently. >And I *cannot* access linux shares located on the F25 freeipa client from a >windows desktop. >But I can access linux shares located on the F25 freeipa server from that >windows desktop. >And I can access linux shares located on the F24 freeipa client from that >windows desktop. > >To be clear, I have: > A/ 1 F25 freeipa server > B/ 1 F25 freeipa client > C/ 1 F24 freeipa client > D/ 1 windows desktop > >I can access linux shares of A from D. >I can access linux shares of C from D. >I *cannot* access linux shares of B from D. > >I get these messages on B in /var/log/samba/log.10.0.21.247 : > >[2016/12/01 11:42:19.218759, 1] ../source3/librpc/crypto/gse_ >krb5.c:534(fill_mem_keytab_from_dedicated_keytab) > ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed (Key >table name malformed) >[2016/12/01 11:42:19.218800, 1] ../source3/librpc/crypto/gse_ >krb5.c:627(gse_krb5_get_server_keytab) > ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >- -1765328205 >[2016/12/01 11:42:19.218823, 1] ../auth/gensec/gensec_start.c: >698(gensec_start_mech) > Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >[2016/12/01 11:42:19.261611, 1] ../source3/librpc/crypto/gse_ >krb5.c:534(fill_mem_keytab_from_dedicated_keytab) > ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed (Key >table name malformed) >[2016/12/01 11:42:19.261638, 1] ../source3/librpc/crypto/gse_ >krb5.c:627(gse_krb5_get_server_keytab) > ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >- -1765328205 >[2016/12/01 11:42:19.261653, 1] ../auth/gensec/gensec_start.c: >698(gensec_start_mech) > Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >[2016/12/01 11:42:19.263330, 2] ../source3/auth/auth.c:315( >auth_check_ntlm_password) > check_ntlm_password: Authentication for user [smith] -> [smith] FAILED >with error NT_STATUS_NO_SUCH_USER >[2016/12/01 11:42:19.263380, 2] ../auth/gensec/spnego.c:720( >gensec_spnego_server_negTokenTarg) > SPNEGO login failed: NT_STATUS_NO_SUCH_USER >[2016/12/01 11:42:19.270531, 1] ../source3/librpc/crypto/gse_ >krb5.c:534(fill_mem_keytab_from_dedicated_keytab) > ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed (Key >table name malformed) >[2016/12/01 11:42:19.270562, 1] ../source3/librpc/crypto/gse_ >krb5.c:627(gse_krb5_get_server_keytab) > ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >- -1765328205 >[2016/12/01 11:42:19.270586, 1] ../auth/gensec/gensec_start.c: >698(gensec_start_mech) > Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >[2016/12/01 11:42:19.313479, 1] ../source3/librpc/crypto/gse_ >krb5.c:534(fill_mem_keytab_from_dedicated_keytab) > ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed (Key >table name malformed) >[2016/12/01 11:42:19.313506, 1] ../source3/librpc/crypto/gse_ >krb5.c:627(gse_krb5_get_server_keytab) > ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >- -1765328205 >[2016/12/01 11:42:19.313523, 1] ../auth/gensec/gensec_start.c: >698(gensec_start_mech) > Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >[2016/12/01 11:42:19.315256, 2] ../source3/auth/auth.c:315( >auth_check_ntlm_password) > check_ntlm_password: Authentication for user [smith] -> [smith] FAILED >with error NT_STATUS_NO_SUCH_USER >[2016/12/01 11:42:19.315291, 2] ../auth/gensec/spnego.c:720( >gensec_spnego_server_negTokenTarg) > SPNEGO login failed: NT_STATUS_NO_SUCH_USER > >Also from the F25 server, I have the following when I run smbclient > >f25server # smbclient -k -L f25desktop.mydomain >lp_load_ex: changing to config backend registry >session setup failed: NT_STATUS_LOGON_FAILURE > >But if i run it with a F24 desktop, it works: > >f25server # smbclient -k -L f24desktop.mydomain >lp_load_ex: changing to config backend registry >Domain=[MYDOMAIN] OS=[Windows 6.1] Server=[Samba 4.4.7] > > Sharename Type Comment > --------- ---- ------- > IPC$ IPC IPC Service (Samba Server Version 4.4.7) > data Disk /data on f24desktop > data2 Disk /data2 on f24desktop > data3 Disk /data3 on f24desktop > backup Disk /backup on f24desktop >[...] > > >net conf list on the f25desktop gives: > >f25desktop # net conf list >[global] > workgroup = MYDOMAIN > realm = MYDOMAIN > netbios name = F25SERVER > server string = Samba Server Version %v > kerberos method = dedicated keytab > dedicated keytab file = FILE:/etc/samba/samba.keytab There seem to be a change in Samba 4.5.0 which uses 'dedicated keytab file' value as it is when constructing a memory keytab. As result, libkrb5 is confused and does not know which keytab processing routine to use (MEMORY:FILE:/etc/samba/samba.keytab is invalid). You can replace the value by removing FILE: right now: net conf setparm global 'dedicated keytab file' /etc/samba/samba.keytab When no prefix is used, libkrb5 will default to FILE: itself. We are going to look at changing the Samba code to strip the prefix from the 'dedicated keytab file' when applying it to memory-based keytabs. -- / Alexander Bokovoy From fujisan43 at gmail.com Fri Dec 2 09:48:05 2016 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Dec 2016 10:48:05 +0100 Subject: [Freeipa-users] cannot access to freeipa client's linux share from windows In-Reply-To: <20161202092951.uajc7sypj5q7t4cw@redhat.com> References: <20161202092951.uajc7sypj5q7t4cw@redhat.com> Message-ID: Alexander, I have now in my conf on server A and client B dedicated keytab file = /etc/samba/samba.keytab instead of dedicated keytab file = FILE:/etc/samba/samba.keytab But unfortunately, it did not solve the problem. On Fri, Dec 2, 2016 at 10:29 AM, Alexander Bokovoy wrote: > On to, 01 joulu 2016, Fujisan wrote: > >> Hello, >> >> I have upgraded a client and a freeipa server from Fedora 24 to 25 >> recently. >> And I *cannot* access linux shares located on the F25 freeipa client from >> a >> windows desktop. >> But I can access linux shares located on the F25 freeipa server from that >> windows desktop. >> And I can access linux shares located on the F24 freeipa client from that >> windows desktop. >> >> To be clear, I have: >> A/ 1 F25 freeipa server >> B/ 1 F25 freeipa client >> C/ 1 F24 freeipa client >> D/ 1 windows desktop >> >> I can access linux shares of A from D. >> I can access linux shares of C from D. >> I *cannot* access linux shares of B from D. >> >> I get these messages on B in /var/log/samba/log.10.0.21.247 : >> >> [2016/12/01 11:42:19.218759, 1] ../source3/librpc/crypto/gse_ >> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >> (Key >> table name malformed) >> [2016/12/01 11:42:19.218800, 1] ../source3/librpc/crypto/gse_ >> krb5.c:627(gse_krb5_get_server_keytab) >> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >> - -1765328205 >> [2016/12/01 11:42:19.218823, 1] ../auth/gensec/gensec_start.c: >> 698(gensec_start_mech) >> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >> [2016/12/01 11:42:19.261611, 1] ../source3/librpc/crypto/gse_ >> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >> (Key >> table name malformed) >> [2016/12/01 11:42:19.261638, 1] ../source3/librpc/crypto/gse_ >> krb5.c:627(gse_krb5_get_server_keytab) >> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >> - -1765328205 >> [2016/12/01 11:42:19.261653, 1] ../auth/gensec/gensec_start.c: >> 698(gensec_start_mech) >> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >> [2016/12/01 11:42:19.263330, 2] ../source3/auth/auth.c:315( >> auth_check_ntlm_password) >> check_ntlm_password: Authentication for user [smith] -> [smith] FAILED >> with error NT_STATUS_NO_SUCH_USER >> [2016/12/01 11:42:19.263380, 2] ../auth/gensec/spnego.c:720( >> gensec_spnego_server_negTokenTarg) >> SPNEGO login failed: NT_STATUS_NO_SUCH_USER >> [2016/12/01 11:42:19.270531, 1] ../source3/librpc/crypto/gse_ >> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >> (Key >> table name malformed) >> [2016/12/01 11:42:19.270562, 1] ../source3/librpc/crypto/gse_ >> krb5.c:627(gse_krb5_get_server_keytab) >> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >> - -1765328205 >> [2016/12/01 11:42:19.270586, 1] ../auth/gensec/gensec_start.c: >> 698(gensec_start_mech) >> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >> [2016/12/01 11:42:19.313479, 1] ../source3/librpc/crypto/gse_ >> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >> (Key >> table name malformed) >> [2016/12/01 11:42:19.313506, 1] ../source3/librpc/crypto/gse_ >> krb5.c:627(gse_krb5_get_server_keytab) >> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >> - -1765328205 >> [2016/12/01 11:42:19.313523, 1] ../auth/gensec/gensec_start.c: >> 698(gensec_start_mech) >> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >> [2016/12/01 11:42:19.315256, 2] ../source3/auth/auth.c:315( >> auth_check_ntlm_password) >> check_ntlm_password: Authentication for user [smith] -> [smith] FAILED >> with error NT_STATUS_NO_SUCH_USER >> [2016/12/01 11:42:19.315291, 2] ../auth/gensec/spnego.c:720( >> gensec_spnego_server_negTokenTarg) >> SPNEGO login failed: NT_STATUS_NO_SUCH_USER >> >> Also from the F25 server, I have the following when I run smbclient >> >> f25server # smbclient -k -L f25desktop.mydomain >> lp_load_ex: changing to config backend registry >> session setup failed: NT_STATUS_LOGON_FAILURE >> >> But if i run it with a F24 desktop, it works: >> >> f25server # smbclient -k -L f24desktop.mydomain >> lp_load_ex: changing to config backend registry >> Domain=[MYDOMAIN] OS=[Windows 6.1] Server=[Samba 4.4.7] >> >> Sharename Type Comment >> --------- ---- ------- >> IPC$ IPC IPC Service (Samba Server Version 4.4.7) >> data Disk /data on f24desktop >> data2 Disk /data2 on f24desktop >> data3 Disk /data3 on f24desktop >> backup Disk /backup on f24desktop >> [...] >> >> >> net conf list on the f25desktop gives: >> >> f25desktop # net conf list >> [global] >> workgroup = MYDOMAIN >> realm = MYDOMAIN >> netbios name = F25SERVER >> server string = Samba Server Version %v >> kerberos method = dedicated keytab >> dedicated keytab file = FILE:/etc/samba/samba.keytab >> > There seem to be a change in Samba 4.5.0 which uses 'dedicated keytab > file' value as it is when constructing a memory keytab. As result, > libkrb5 is confused and does not know which keytab processing routine to > use (MEMORY:FILE:/etc/samba/samba.keytab is invalid). > > You can replace the value by removing FILE: right now: > > net conf setparm global 'dedicated keytab file' /etc/samba/samba.keytab > > When no prefix is used, libkrb5 will default to FILE: itself. > > We are going to look at changing the Samba code to strip the prefix from > the 'dedicated keytab file' when applying it to memory-based keytabs. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Dec 2 09:57:38 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Dec 2016 11:57:38 +0200 Subject: [Freeipa-users] cannot access to freeipa client's linux share from windows In-Reply-To: References: <20161202092951.uajc7sypj5q7t4cw@redhat.com> Message-ID: <20161202095738.cl53tifgir6edqk4@redhat.com> On pe, 02 joulu 2016, Fujisan wrote: >Alexander, > >I have now in my conf on server A and client B > >dedicated keytab file = /etc/samba/samba.keytab > >instead of > >dedicated keytab file = FILE:/etc/samba/samba.keytab > > >But unfortunately, it did not solve the problem. It did solve for me. The offending commit in Samba is c2f5c30b $ git tag --contains c2f5c30b|grep samba samba-4.5.0 samba-4.5.0rc1 samba-4.5.0rc2 samba-4.5.0rc3 samba-4.5.1 It has following code: +krb5_error_code smb_krb5_open_keytab(krb5_context context, + const char *keytab_name_req, + bool write_access, + krb5_keytab *keytab) +{ + if (keytab_name_req != NULL) { + if (keytab_name_req[0] != '/') { + return KRB5_KT_BADNAME; + } + } + + return smb_krb5_open_keytab_relative(context, + keytab_name_req, + write_access, + keytab); +} It is the check for keytab_name_req[0] not starting from '/' what causes the break. > > > >On Fri, Dec 2, 2016 at 10:29 AM, Alexander Bokovoy >wrote: > >> On to, 01 joulu 2016, Fujisan wrote: >> >>> Hello, >>> >>> I have upgraded a client and a freeipa server from Fedora 24 to 25 >>> recently. >>> And I *cannot* access linux shares located on the F25 freeipa client from >>> a >>> windows desktop. >>> But I can access linux shares located on the F25 freeipa server from that >>> windows desktop. >>> And I can access linux shares located on the F24 freeipa client from that >>> windows desktop. >>> >>> To be clear, I have: >>> A/ 1 F25 freeipa server >>> B/ 1 F25 freeipa client >>> C/ 1 F24 freeipa client >>> D/ 1 windows desktop >>> >>> I can access linux shares of A from D. >>> I can access linux shares of C from D. >>> I *cannot* access linux shares of B from D. >>> >>> I get these messages on B in /var/log/samba/log.10.0.21.247 : >>> >>> [2016/12/01 11:42:19.218759, 1] ../source3/librpc/crypto/gse_ >>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>> (Key >>> table name malformed) >>> [2016/12/01 11:42:19.218800, 1] ../source3/librpc/crypto/gse_ >>> krb5.c:627(gse_krb5_get_server_keytab) >>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >>> - -1765328205 >>> [2016/12/01 11:42:19.218823, 1] ../auth/gensec/gensec_start.c: >>> 698(gensec_start_mech) >>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>> [2016/12/01 11:42:19.261611, 1] ../source3/librpc/crypto/gse_ >>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>> (Key >>> table name malformed) >>> [2016/12/01 11:42:19.261638, 1] ../source3/librpc/crypto/gse_ >>> krb5.c:627(gse_krb5_get_server_keytab) >>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >>> - -1765328205 >>> [2016/12/01 11:42:19.261653, 1] ../auth/gensec/gensec_start.c: >>> 698(gensec_start_mech) >>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>> [2016/12/01 11:42:19.263330, 2] ../source3/auth/auth.c:315( >>> auth_check_ntlm_password) >>> check_ntlm_password: Authentication for user [smith] -> [smith] FAILED >>> with error NT_STATUS_NO_SUCH_USER >>> [2016/12/01 11:42:19.263380, 2] ../auth/gensec/spnego.c:720( >>> gensec_spnego_server_negTokenTarg) >>> SPNEGO login failed: NT_STATUS_NO_SUCH_USER >>> [2016/12/01 11:42:19.270531, 1] ../source3/librpc/crypto/gse_ >>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>> (Key >>> table name malformed) >>> [2016/12/01 11:42:19.270562, 1] ../source3/librpc/crypto/gse_ >>> krb5.c:627(gse_krb5_get_server_keytab) >>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >>> - -1765328205 >>> [2016/12/01 11:42:19.270586, 1] ../auth/gensec/gensec_start.c: >>> 698(gensec_start_mech) >>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>> [2016/12/01 11:42:19.313479, 1] ../source3/librpc/crypto/gse_ >>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>> (Key >>> table name malformed) >>> [2016/12/01 11:42:19.313506, 1] ../source3/librpc/crypto/gse_ >>> krb5.c:627(gse_krb5_get_server_keytab) >>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem keytab >>> - -1765328205 >>> [2016/12/01 11:42:19.313523, 1] ../auth/gensec/gensec_start.c: >>> 698(gensec_start_mech) >>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>> [2016/12/01 11:42:19.315256, 2] ../source3/auth/auth.c:315( >>> auth_check_ntlm_password) >>> check_ntlm_password: Authentication for user [smith] -> [smith] FAILED >>> with error NT_STATUS_NO_SUCH_USER >>> [2016/12/01 11:42:19.315291, 2] ../auth/gensec/spnego.c:720( >>> gensec_spnego_server_negTokenTarg) >>> SPNEGO login failed: NT_STATUS_NO_SUCH_USER >>> >>> Also from the F25 server, I have the following when I run smbclient >>> >>> f25server # smbclient -k -L f25desktop.mydomain >>> lp_load_ex: changing to config backend registry >>> session setup failed: NT_STATUS_LOGON_FAILURE >>> >>> But if i run it with a F24 desktop, it works: >>> >>> f25server # smbclient -k -L f24desktop.mydomain >>> lp_load_ex: changing to config backend registry >>> Domain=[MYDOMAIN] OS=[Windows 6.1] Server=[Samba 4.4.7] >>> >>> Sharename Type Comment >>> --------- ---- ------- >>> IPC$ IPC IPC Service (Samba Server Version 4.4.7) >>> data Disk /data on f24desktop >>> data2 Disk /data2 on f24desktop >>> data3 Disk /data3 on f24desktop >>> backup Disk /backup on f24desktop >>> [...] >>> >>> >>> net conf list on the f25desktop gives: >>> >>> f25desktop # net conf list >>> [global] >>> workgroup = MYDOMAIN >>> realm = MYDOMAIN >>> netbios name = F25SERVER >>> server string = Samba Server Version %v >>> kerberos method = dedicated keytab >>> dedicated keytab file = FILE:/etc/samba/samba.keytab >>> >> There seem to be a change in Samba 4.5.0 which uses 'dedicated keytab >> file' value as it is when constructing a memory keytab. As result, >> libkrb5 is confused and does not know which keytab processing routine to >> use (MEMORY:FILE:/etc/samba/samba.keytab is invalid). >> >> You can replace the value by removing FILE: right now: >> >> net conf setparm global 'dedicated keytab file' /etc/samba/samba.keytab >> >> When no prefix is used, libkrb5 will default to FILE: itself. >> >> We are going to look at changing the Samba code to strip the prefix from >> the 'dedicated keytab file' when applying it to memory-based keytabs. >> >> -- >> / Alexander Bokovoy >> -- / Alexander Bokovoy From fujisan43 at gmail.com Fri Dec 2 10:11:02 2016 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Dec 2016 11:11:02 +0100 Subject: [Freeipa-users] cannot access to freeipa client's linux share from windows In-Reply-To: <20161202095738.cl53tifgir6edqk4@redhat.com> References: <20161202092951.uajc7sypj5q7t4cw@redhat.com> <20161202095738.cl53tifgir6edqk4@redhat.com> Message-ID: I'm not sure my problem is linked to this 'dedicated keytab file' with FILE: before the path to keytab file. # smbclient -d3 -L \\10.0.21.200 -U smith lp_load_ex: refreshing parameters Initialising global parameters rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Processing section "[global]" lp_load_ex: changing to config backend registry Initialising global parameters rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) lp_load_ex: refreshing parameters Initialising global parameters rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) Processing section "[global]" added interface eno1 ip=10.0.21.18 bcast=10.0.21.31 netmask=255.255.255.240 Client started (version 4.5.1). Enter smith's password: Connecting to 10.0.21.200 at port 445 Doing spnego session setup (blob length=74) got OID=1.3.6.1.4.1.311.2.2.10 got principal=not_defined_in_RFC4178 at please_ignore GENSEC backend 'gssapi_spnego' registered GENSEC backend 'gssapi_krb5' registered GENSEC backend 'gssapi_krb5_sasl' registered GENSEC backend 'spnego' registered GENSEC backend 'schannel' registered GENSEC backend 'naclrpc_as_system' registered GENSEC backend 'sasl-EXTERNAL' registered GENSEC backend 'ntlmssp' registered GENSEC backend 'ntlmssp_resume_ccache' registered GENSEC backend 'http_basic' registered GENSEC backend 'http_ntlm' registered Got challenge flags: Got NTLMSSP neg_flags=0x628a8215 NTLMSSP: Set final flags: Got NTLMSSP neg_flags=0x62088215 NTLMSSP Sign/Seal - Initialising with flags: Got NTLMSSP neg_flags=0x62088215 SPNEGO login failed: Logon failure session setup failed: NT_STATUS_LOGON_FAILURE On Fri, Dec 2, 2016 at 10:57 AM, Alexander Bokovoy wrote: > On pe, 02 joulu 2016, Fujisan wrote: > >> Alexander, >> >> I have now in my conf on server A and client B >> >> dedicated keytab file = /etc/samba/samba.keytab >> >> instead of >> >> dedicated keytab file = FILE:/etc/samba/samba.keytab >> >> >> But unfortunately, it did not solve the problem. >> > It did solve for me. The offending commit in Samba is c2f5c30b > > $ git tag --contains c2f5c30b|grep samba > samba-4.5.0 > samba-4.5.0rc1 > samba-4.5.0rc2 > samba-4.5.0rc3 > samba-4.5.1 > > It has following code: > +krb5_error_code smb_krb5_open_keytab(krb5_context context, > + const char *keytab_name_req, > + bool write_access, > + krb5_keytab *keytab) > +{ > + if (keytab_name_req != NULL) { > + if (keytab_name_req[0] != '/') { > + return KRB5_KT_BADNAME; > + } > + } > + > + return smb_krb5_open_keytab_relative(context, > + keytab_name_req, > + write_access, > + keytab); > +} > > It is the check for keytab_name_req[0] not starting from '/' what causes > the break. > > > >> >> >> On Fri, Dec 2, 2016 at 10:29 AM, Alexander Bokovoy >> wrote: >> >> On to, 01 joulu 2016, Fujisan wrote: >>> >>> Hello, >>>> >>>> I have upgraded a client and a freeipa server from Fedora 24 to 25 >>>> recently. >>>> And I *cannot* access linux shares located on the F25 freeipa client >>>> from >>>> a >>>> windows desktop. >>>> But I can access linux shares located on the F25 freeipa server from >>>> that >>>> windows desktop. >>>> And I can access linux shares located on the F24 freeipa client from >>>> that >>>> windows desktop. >>>> >>>> To be clear, I have: >>>> A/ 1 F25 freeipa server >>>> B/ 1 F25 freeipa client >>>> C/ 1 F24 freeipa client >>>> D/ 1 windows desktop >>>> >>>> I can access linux shares of A from D. >>>> I can access linux shares of C from D. >>>> I *cannot* access linux shares of B from D. >>>> >>>> I get these messages on B in /var/log/samba/log.10.0.21.247 : >>>> >>>> [2016/12/01 11:42:19.218759, 1] ../source3/librpc/crypto/gse_ >>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>> (Key >>>> table name malformed) >>>> [2016/12/01 11:42:19.218800, 1] ../source3/librpc/crypto/gse_ >>>> krb5.c:627(gse_krb5_get_server_keytab) >>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>> keytab >>>> - -1765328205 >>>> [2016/12/01 11:42:19.218823, 1] ../auth/gensec/gensec_start.c: >>>> 698(gensec_start_mech) >>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>> [2016/12/01 11:42:19.261611, 1] ../source3/librpc/crypto/gse_ >>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>> (Key >>>> table name malformed) >>>> [2016/12/01 11:42:19.261638, 1] ../source3/librpc/crypto/gse_ >>>> krb5.c:627(gse_krb5_get_server_keytab) >>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>> keytab >>>> - -1765328205 >>>> [2016/12/01 11:42:19.261653, 1] ../auth/gensec/gensec_start.c: >>>> 698(gensec_start_mech) >>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>> [2016/12/01 11:42:19.263330, 2] ../source3/auth/auth.c:315( >>>> auth_check_ntlm_password) >>>> check_ntlm_password: Authentication for user [smith] -> [smith] FAILED >>>> with error NT_STATUS_NO_SUCH_USER >>>> [2016/12/01 11:42:19.263380, 2] ../auth/gensec/spnego.c:720( >>>> gensec_spnego_server_negTokenTarg) >>>> SPNEGO login failed: NT_STATUS_NO_SUCH_USER >>>> [2016/12/01 11:42:19.270531, 1] ../source3/librpc/crypto/gse_ >>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>> (Key >>>> table name malformed) >>>> [2016/12/01 11:42:19.270562, 1] ../source3/librpc/crypto/gse_ >>>> krb5.c:627(gse_krb5_get_server_keytab) >>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>> keytab >>>> - -1765328205 >>>> [2016/12/01 11:42:19.270586, 1] ../auth/gensec/gensec_start.c: >>>> 698(gensec_start_mech) >>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>> [2016/12/01 11:42:19.313479, 1] ../source3/librpc/crypto/gse_ >>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>> (Key >>>> table name malformed) >>>> [2016/12/01 11:42:19.313506, 1] ../source3/librpc/crypto/gse_ >>>> krb5.c:627(gse_krb5_get_server_keytab) >>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>> keytab >>>> - -1765328205 >>>> [2016/12/01 11:42:19.313523, 1] ../auth/gensec/gensec_start.c: >>>> 698(gensec_start_mech) >>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>> [2016/12/01 11:42:19.315256, 2] ../source3/auth/auth.c:315( >>>> auth_check_ntlm_password) >>>> check_ntlm_password: Authentication for user [smith] -> [smith] FAILED >>>> with error NT_STATUS_NO_SUCH_USER >>>> [2016/12/01 11:42:19.315291, 2] ../auth/gensec/spnego.c:720( >>>> gensec_spnego_server_negTokenTarg) >>>> SPNEGO login failed: NT_STATUS_NO_SUCH_USER >>>> >>>> Also from the F25 server, I have the following when I run smbclient >>>> >>>> f25server # smbclient -k -L f25desktop.mydomain >>>> lp_load_ex: changing to config backend registry >>>> session setup failed: NT_STATUS_LOGON_FAILURE >>>> >>>> But if i run it with a F24 desktop, it works: >>>> >>>> f25server # smbclient -k -L f24desktop.mydomain >>>> lp_load_ex: changing to config backend registry >>>> Domain=[MYDOMAIN] OS=[Windows 6.1] Server=[Samba 4.4.7] >>>> >>>> Sharename Type Comment >>>> --------- ---- ------- >>>> IPC$ IPC IPC Service (Samba Server Version 4.4.7) >>>> data Disk /data on f24desktop >>>> data2 Disk /data2 on f24desktop >>>> data3 Disk /data3 on f24desktop >>>> backup Disk /backup on f24desktop >>>> [...] >>>> >>>> >>>> net conf list on the f25desktop gives: >>>> >>>> f25desktop # net conf list >>>> [global] >>>> workgroup = MYDOMAIN >>>> realm = MYDOMAIN >>>> netbios name = F25SERVER >>>> server string = Samba Server Version %v >>>> kerberos method = dedicated keytab >>>> dedicated keytab file = FILE:/etc/samba/samba.keytab >>>> >>>> There seem to be a change in Samba 4.5.0 which uses 'dedicated keytab >>> file' value as it is when constructing a memory keytab. As result, >>> libkrb5 is confused and does not know which keytab processing routine to >>> use (MEMORY:FILE:/etc/samba/samba.keytab is invalid). >>> >>> You can replace the value by removing FILE: right now: >>> >>> net conf setparm global 'dedicated keytab file' /etc/samba/samba.keytab >>> >>> When no prefix is used, libkrb5 will default to FILE: itself. >>> >>> We are going to look at changing the Samba code to strip the prefix from >>> the 'dedicated keytab file' when applying it to memory-based keytabs. >>> >>> -- >>> / Alexander Bokovoy >>> >>> > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Dec 2 10:20:57 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Dec 2016 12:20:57 +0200 Subject: [Freeipa-users] cannot access to freeipa client's linux share from windows In-Reply-To: References: <20161202092951.uajc7sypj5q7t4cw@redhat.com> <20161202095738.cl53tifgir6edqk4@redhat.com> Message-ID: <20161202102057.fqfipr6rdzhkrjqc@redhat.com> On pe, 02 joulu 2016, Fujisan wrote: >I'm not sure my problem is linked to this 'dedicated keytab file' with >FILE: before the path to keytab file. Yes, it does. Your client log below reports that the server cannot communicate with you because _the_server_ is unable to read its keytab when initializing GENSEC backed gssapi_krb5 and thus client switches to SPNEGO which also fails as the server cannot work without proper keytab using kerberos and password-based auth is not possible. > ># smbclient -d3 -L \\10.0.21.200 -U smith >lp_load_ex: refreshing parameters >Initialising global parameters >rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) >Processing section "[global]" >lp_load_ex: changing to config backend registry >Initialising global parameters >rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) >lp_load_ex: refreshing parameters >Initialising global parameters >rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) >Processing section "[global]" >added interface eno1 ip=10.0.21.18 bcast=10.0.21.31 netmask=255.255.255.240 >Client started (version 4.5.1). >Enter smith's password: >Connecting to 10.0.21.200 at port 445 >Doing spnego session setup (blob length=74) >got OID=1.3.6.1.4.1.311.2.2.10 >got principal=not_defined_in_RFC4178 at please_ignore >GENSEC backend 'gssapi_spnego' registered >GENSEC backend 'gssapi_krb5' registered >GENSEC backend 'gssapi_krb5_sasl' registered >GENSEC backend 'spnego' registered >GENSEC backend 'schannel' registered >GENSEC backend 'naclrpc_as_system' registered >GENSEC backend 'sasl-EXTERNAL' registered >GENSEC backend 'ntlmssp' registered >GENSEC backend 'ntlmssp_resume_ccache' registered >GENSEC backend 'http_basic' registered >GENSEC backend 'http_ntlm' registered >Got challenge flags: >Got NTLMSSP neg_flags=0x628a8215 >NTLMSSP: Set final flags: >Got NTLMSSP neg_flags=0x62088215 >NTLMSSP Sign/Seal - Initialising with flags: >Got NTLMSSP neg_flags=0x62088215 >SPNEGO login failed: Logon failure >session setup failed: NT_STATUS_LOGON_FAILURE > >On Fri, Dec 2, 2016 at 10:57 AM, Alexander Bokovoy >wrote: > >> On pe, 02 joulu 2016, Fujisan wrote: >> >>> Alexander, >>> >>> I have now in my conf on server A and client B >>> >>> dedicated keytab file = /etc/samba/samba.keytab >>> >>> instead of >>> >>> dedicated keytab file = FILE:/etc/samba/samba.keytab >>> >>> >>> But unfortunately, it did not solve the problem. >>> >> It did solve for me. The offending commit in Samba is c2f5c30b >> >> $ git tag --contains c2f5c30b|grep samba >> samba-4.5.0 >> samba-4.5.0rc1 >> samba-4.5.0rc2 >> samba-4.5.0rc3 >> samba-4.5.1 >> >> It has following code: >> +krb5_error_code smb_krb5_open_keytab(krb5_context context, >> + const char *keytab_name_req, >> + bool write_access, >> + krb5_keytab *keytab) >> +{ >> + if (keytab_name_req != NULL) { >> + if (keytab_name_req[0] != '/') { >> + return KRB5_KT_BADNAME; >> + } >> + } >> + >> + return smb_krb5_open_keytab_relative(context, >> + keytab_name_req, >> + write_access, >> + keytab); >> +} >> >> It is the check for keytab_name_req[0] not starting from '/' what causes >> the break. >> >> >> >>> >>> >>> On Fri, Dec 2, 2016 at 10:29 AM, Alexander Bokovoy >>> wrote: >>> >>> On to, 01 joulu 2016, Fujisan wrote: >>>> >>>> Hello, >>>>> >>>>> I have upgraded a client and a freeipa server from Fedora 24 to 25 >>>>> recently. >>>>> And I *cannot* access linux shares located on the F25 freeipa client >>>>> from >>>>> a >>>>> windows desktop. >>>>> But I can access linux shares located on the F25 freeipa server from >>>>> that >>>>> windows desktop. >>>>> And I can access linux shares located on the F24 freeipa client from >>>>> that >>>>> windows desktop. >>>>> >>>>> To be clear, I have: >>>>> A/ 1 F25 freeipa server >>>>> B/ 1 F25 freeipa client >>>>> C/ 1 F24 freeipa client >>>>> D/ 1 windows desktop >>>>> >>>>> I can access linux shares of A from D. >>>>> I can access linux shares of C from D. >>>>> I *cannot* access linux shares of B from D. >>>>> >>>>> I get these messages on B in /var/log/samba/log.10.0.21.247 : >>>>> >>>>> [2016/12/01 11:42:19.218759, 1] ../source3/librpc/crypto/gse_ >>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>>> (Key >>>>> table name malformed) >>>>> [2016/12/01 11:42:19.218800, 1] ../source3/librpc/crypto/gse_ >>>>> krb5.c:627(gse_krb5_get_server_keytab) >>>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>>> keytab >>>>> - -1765328205 >>>>> [2016/12/01 11:42:19.218823, 1] ../auth/gensec/gensec_start.c: >>>>> 698(gensec_start_mech) >>>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>>> [2016/12/01 11:42:19.261611, 1] ../source3/librpc/crypto/gse_ >>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>>> (Key >>>>> table name malformed) >>>>> [2016/12/01 11:42:19.261638, 1] ../source3/librpc/crypto/gse_ >>>>> krb5.c:627(gse_krb5_get_server_keytab) >>>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>>> keytab >>>>> - -1765328205 >>>>> [2016/12/01 11:42:19.261653, 1] ../auth/gensec/gensec_start.c: >>>>> 698(gensec_start_mech) >>>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>>> [2016/12/01 11:42:19.263330, 2] ../source3/auth/auth.c:315( >>>>> auth_check_ntlm_password) >>>>> check_ntlm_password: Authentication for user [smith] -> [smith] FAILED >>>>> with error NT_STATUS_NO_SUCH_USER >>>>> [2016/12/01 11:42:19.263380, 2] ../auth/gensec/spnego.c:720( >>>>> gensec_spnego_server_negTokenTarg) >>>>> SPNEGO login failed: NT_STATUS_NO_SUCH_USER >>>>> [2016/12/01 11:42:19.270531, 1] ../source3/librpc/crypto/gse_ >>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>>> (Key >>>>> table name malformed) >>>>> [2016/12/01 11:42:19.270562, 1] ../source3/librpc/crypto/gse_ >>>>> krb5.c:627(gse_krb5_get_server_keytab) >>>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>>> keytab >>>>> - -1765328205 >>>>> [2016/12/01 11:42:19.270586, 1] ../auth/gensec/gensec_start.c: >>>>> 698(gensec_start_mech) >>>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>>> [2016/12/01 11:42:19.313479, 1] ../source3/librpc/crypto/gse_ >>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>>> (Key >>>>> table name malformed) >>>>> [2016/12/01 11:42:19.313506, 1] ../source3/librpc/crypto/gse_ >>>>> krb5.c:627(gse_krb5_get_server_keytab) >>>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>>> keytab >>>>> - -1765328205 >>>>> [2016/12/01 11:42:19.313523, 1] ../auth/gensec/gensec_start.c: >>>>> 698(gensec_start_mech) >>>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>>> [2016/12/01 11:42:19.315256, 2] ../source3/auth/auth.c:315( >>>>> auth_check_ntlm_password) >>>>> check_ntlm_password: Authentication for user [smith] -> [smith] FAILED >>>>> with error NT_STATUS_NO_SUCH_USER >>>>> [2016/12/01 11:42:19.315291, 2] ../auth/gensec/spnego.c:720( >>>>> gensec_spnego_server_negTokenTarg) >>>>> SPNEGO login failed: NT_STATUS_NO_SUCH_USER >>>>> >>>>> Also from the F25 server, I have the following when I run smbclient >>>>> >>>>> f25server # smbclient -k -L f25desktop.mydomain >>>>> lp_load_ex: changing to config backend registry >>>>> session setup failed: NT_STATUS_LOGON_FAILURE >>>>> >>>>> But if i run it with a F24 desktop, it works: >>>>> >>>>> f25server # smbclient -k -L f24desktop.mydomain >>>>> lp_load_ex: changing to config backend registry >>>>> Domain=[MYDOMAIN] OS=[Windows 6.1] Server=[Samba 4.4.7] >>>>> >>>>> Sharename Type Comment >>>>> --------- ---- ------- >>>>> IPC$ IPC IPC Service (Samba Server Version 4.4.7) >>>>> data Disk /data on f24desktop >>>>> data2 Disk /data2 on f24desktop >>>>> data3 Disk /data3 on f24desktop >>>>> backup Disk /backup on f24desktop >>>>> [...] >>>>> >>>>> >>>>> net conf list on the f25desktop gives: >>>>> >>>>> f25desktop # net conf list >>>>> [global] >>>>> workgroup = MYDOMAIN >>>>> realm = MYDOMAIN >>>>> netbios name = F25SERVER >>>>> server string = Samba Server Version %v >>>>> kerberos method = dedicated keytab >>>>> dedicated keytab file = FILE:/etc/samba/samba.keytab >>>>> >>>>> There seem to be a change in Samba 4.5.0 which uses 'dedicated keytab >>>> file' value as it is when constructing a memory keytab. As result, >>>> libkrb5 is confused and does not know which keytab processing routine to >>>> use (MEMORY:FILE:/etc/samba/samba.keytab is invalid). >>>> >>>> You can replace the value by removing FILE: right now: >>>> >>>> net conf setparm global 'dedicated keytab file' /etc/samba/samba.keytab >>>> >>>> When no prefix is used, libkrb5 will default to FILE: itself. >>>> >>>> We are going to look at changing the Samba code to strip the prefix from >>>> the 'dedicated keytab file' when applying it to memory-based keytabs. >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >> -- >> / Alexander Bokovoy >> -- / Alexander Bokovoy From fujisan43 at gmail.com Fri Dec 2 10:28:49 2016 From: fujisan43 at gmail.com (Fujisan) Date: Fri, 2 Dec 2016 11:28:49 +0100 Subject: [Freeipa-users] cannot access to freeipa client's linux share from windows In-Reply-To: <20161202102057.fqfipr6rdzhkrjqc@redhat.com> References: <20161202092951.uajc7sypj5q7t4cw@redhat.com> <20161202095738.cl53tifgir6edqk4@redhat.com> <20161202102057.fqfipr6rdzhkrjqc@redhat.com> Message-ID: Ok so why is it still not working? Any suggestion? On Fri, Dec 2, 2016 at 11:20 AM, Alexander Bokovoy wrote: > On pe, 02 joulu 2016, Fujisan wrote: > >> I'm not sure my problem is linked to this 'dedicated keytab file' with >> FILE: before the path to keytab file. >> > Yes, it does. Your client log below reports that the server cannot > communicate with you because _the_server_ is unable to read its keytab > when initializing GENSEC backed gssapi_krb5 and thus client switches to > SPNEGO which also fails as the server cannot work without proper keytab > using kerberos and password-based auth is not possible. > > > >> # smbclient -d3 -L \\10.0.21.200 -U smith >> lp_load_ex: refreshing parameters >> Initialising global parameters >> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) >> Processing section "[global]" >> lp_load_ex: changing to config backend registry >> Initialising global parameters >> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) >> lp_load_ex: refreshing parameters >> Initialising global parameters >> rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) >> Processing section "[global]" >> added interface eno1 ip=10.0.21.18 bcast=10.0.21.31 >> netmask=255.255.255.240 >> Client started (version 4.5.1). >> Enter smith's password: >> Connecting to 10.0.21.200 at port 445 >> Doing spnego session setup (blob length=74) >> got OID=1.3.6.1.4.1.311.2.2.10 >> got principal=not_defined_in_RFC4178 at please_ignore >> GENSEC backend 'gssapi_spnego' registered >> GENSEC backend 'gssapi_krb5' registered >> GENSEC backend 'gssapi_krb5_sasl' registered >> GENSEC backend 'spnego' registered >> GENSEC backend 'schannel' registered >> GENSEC backend 'naclrpc_as_system' registered >> GENSEC backend 'sasl-EXTERNAL' registered >> GENSEC backend 'ntlmssp' registered >> GENSEC backend 'ntlmssp_resume_ccache' registered >> GENSEC backend 'http_basic' registered >> GENSEC backend 'http_ntlm' registered >> Got challenge flags: >> Got NTLMSSP neg_flags=0x628a8215 >> NTLMSSP: Set final flags: >> Got NTLMSSP neg_flags=0x62088215 >> NTLMSSP Sign/Seal - Initialising with flags: >> Got NTLMSSP neg_flags=0x62088215 >> SPNEGO login failed: Logon failure >> session setup failed: NT_STATUS_LOGON_FAILURE >> >> On Fri, Dec 2, 2016 at 10:57 AM, Alexander Bokovoy >> wrote: >> >> On pe, 02 joulu 2016, Fujisan wrote: >>> >>> Alexander, >>>> >>>> I have now in my conf on server A and client B >>>> >>>> dedicated keytab file = /etc/samba/samba.keytab >>>> >>>> instead of >>>> >>>> dedicated keytab file = FILE:/etc/samba/samba.keytab >>>> >>>> >>>> But unfortunately, it did not solve the problem. >>>> >>>> It did solve for me. The offending commit in Samba is c2f5c30b >>> >>> $ git tag --contains c2f5c30b|grep samba >>> samba-4.5.0 >>> samba-4.5.0rc1 >>> samba-4.5.0rc2 >>> samba-4.5.0rc3 >>> samba-4.5.1 >>> >>> It has following code: >>> +krb5_error_code smb_krb5_open_keytab(krb5_context context, >>> + const char *keytab_name_req, >>> + bool write_access, >>> + krb5_keytab *keytab) >>> +{ >>> + if (keytab_name_req != NULL) { >>> + if (keytab_name_req[0] != '/') { >>> + return KRB5_KT_BADNAME; >>> + } >>> + } >>> + >>> + return smb_krb5_open_keytab_relative(context, >>> + keytab_name_req, >>> + write_access, >>> + keytab); >>> +} >>> >>> It is the check for keytab_name_req[0] not starting from '/' what causes >>> the break. >>> >>> >>> >>> >>>> >>>> On Fri, Dec 2, 2016 at 10:29 AM, Alexander Bokovoy >>> > >>>> wrote: >>>> >>>> On to, 01 joulu 2016, Fujisan wrote: >>>> >>>>> >>>>> Hello, >>>>> >>>>>> >>>>>> I have upgraded a client and a freeipa server from Fedora 24 to 25 >>>>>> recently. >>>>>> And I *cannot* access linux shares located on the F25 freeipa client >>>>>> from >>>>>> a >>>>>> windows desktop. >>>>>> But I can access linux shares located on the F25 freeipa server from >>>>>> that >>>>>> windows desktop. >>>>>> And I can access linux shares located on the F24 freeipa client from >>>>>> that >>>>>> windows desktop. >>>>>> >>>>>> To be clear, I have: >>>>>> A/ 1 F25 freeipa server >>>>>> B/ 1 F25 freeipa client >>>>>> C/ 1 F24 freeipa client >>>>>> D/ 1 windows desktop >>>>>> >>>>>> I can access linux shares of A from D. >>>>>> I can access linux shares of C from D. >>>>>> I *cannot* access linux shares of B from D. >>>>>> >>>>>> I get these messages on B in /var/log/samba/log.10.0.21.247 : >>>>>> >>>>>> [2016/12/01 11:42:19.218759, 1] ../source3/librpc/crypto/gse_ >>>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>>>> (Key >>>>>> table name malformed) >>>>>> [2016/12/01 11:42:19.218800, 1] ../source3/librpc/crypto/gse_ >>>>>> krb5.c:627(gse_krb5_get_server_keytab) >>>>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>>>> keytab >>>>>> - -1765328205 >>>>>> [2016/12/01 11:42:19.218823, 1] ../auth/gensec/gensec_start.c: >>>>>> 698(gensec_start_mech) >>>>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>>>> [2016/12/01 11:42:19.261611, 1] ../source3/librpc/crypto/gse_ >>>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>>>> (Key >>>>>> table name malformed) >>>>>> [2016/12/01 11:42:19.261638, 1] ../source3/librpc/crypto/gse_ >>>>>> krb5.c:627(gse_krb5_get_server_keytab) >>>>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>>>> keytab >>>>>> - -1765328205 >>>>>> [2016/12/01 11:42:19.261653, 1] ../auth/gensec/gensec_start.c: >>>>>> 698(gensec_start_mech) >>>>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>>>> [2016/12/01 11:42:19.263330, 2] ../source3/auth/auth.c:315( >>>>>> auth_check_ntlm_password) >>>>>> check_ntlm_password: Authentication for user [smith] -> [smith] >>>>>> FAILED >>>>>> with error NT_STATUS_NO_SUCH_USER >>>>>> [2016/12/01 11:42:19.263380, 2] ../auth/gensec/spnego.c:720( >>>>>> gensec_spnego_server_negTokenTarg) >>>>>> SPNEGO login failed: NT_STATUS_NO_SUCH_USER >>>>>> [2016/12/01 11:42:19.270531, 1] ../source3/librpc/crypto/gse_ >>>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>>>> (Key >>>>>> table name malformed) >>>>>> [2016/12/01 11:42:19.270562, 1] ../source3/librpc/crypto/gse_ >>>>>> krb5.c:627(gse_krb5_get_server_keytab) >>>>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>>>> keytab >>>>>> - -1765328205 >>>>>> [2016/12/01 11:42:19.270586, 1] ../auth/gensec/gensec_start.c: >>>>>> 698(gensec_start_mech) >>>>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>>>> [2016/12/01 11:42:19.313479, 1] ../source3/librpc/crypto/gse_ >>>>>> krb5.c:534(fill_mem_keytab_from_dedicated_keytab) >>>>>> ../source3/librpc/crypto/gse_krb5.c:534: smb_krb5_open_keytab failed >>>>>> (Key >>>>>> table name malformed) >>>>>> [2016/12/01 11:42:19.313506, 1] ../source3/librpc/crypto/gse_ >>>>>> krb5.c:627(gse_krb5_get_server_keytab) >>>>>> ../source3/librpc/crypto/gse_krb5.c:627: Error! Unable to set mem >>>>>> keytab >>>>>> - -1765328205 >>>>>> [2016/12/01 11:42:19.313523, 1] ../auth/gensec/gensec_start.c: >>>>>> 698(gensec_start_mech) >>>>>> Failed to start GENSEC server mech gse_krb5: NT_STATUS_INTERNAL_ERROR >>>>>> [2016/12/01 11:42:19.315256, 2] ../source3/auth/auth.c:315( >>>>>> auth_check_ntlm_password) >>>>>> check_ntlm_password: Authentication for user [smith] -> [smith] >>>>>> FAILED >>>>>> with error NT_STATUS_NO_SUCH_USER >>>>>> [2016/12/01 11:42:19.315291, 2] ../auth/gensec/spnego.c:720( >>>>>> gensec_spnego_server_negTokenTarg) >>>>>> SPNEGO login failed: NT_STATUS_NO_SUCH_USER >>>>>> >>>>>> Also from the F25 server, I have the following when I run smbclient >>>>>> >>>>>> f25server # smbclient -k -L f25desktop.mydomain >>>>>> lp_load_ex: changing to config backend registry >>>>>> session setup failed: NT_STATUS_LOGON_FAILURE >>>>>> >>>>>> But if i run it with a F24 desktop, it works: >>>>>> >>>>>> f25server # smbclient -k -L f24desktop.mydomain >>>>>> lp_load_ex: changing to config backend registry >>>>>> Domain=[MYDOMAIN] OS=[Windows 6.1] Server=[Samba 4.4.7] >>>>>> >>>>>> Sharename Type Comment >>>>>> --------- ---- ------- >>>>>> IPC$ IPC IPC Service (Samba Server Version 4.4.7) >>>>>> data Disk /data on f24desktop >>>>>> data2 Disk /data2 on f24desktop >>>>>> data3 Disk /data3 on f24desktop >>>>>> backup Disk /backup on f24desktop >>>>>> [...] >>>>>> >>>>>> >>>>>> net conf list on the f25desktop gives: >>>>>> >>>>>> f25desktop # net conf list >>>>>> [global] >>>>>> workgroup = MYDOMAIN >>>>>> realm = MYDOMAIN >>>>>> netbios name = F25SERVER >>>>>> server string = Samba Server Version %v >>>>>> kerberos method = dedicated keytab >>>>>> dedicated keytab file = FILE:/etc/samba/samba.keytab >>>>>> >>>>>> There seem to be a change in Samba 4.5.0 which uses 'dedicated keytab >>>>>> >>>>> file' value as it is when constructing a memory keytab. As result, >>>>> libkrb5 is confused and does not know which keytab processing routine >>>>> to >>>>> use (MEMORY:FILE:/etc/samba/samba.keytab is invalid). >>>>> >>>>> You can replace the value by removing FILE: right now: >>>>> >>>>> net conf setparm global 'dedicated keytab file' /etc/samba/samba.keytab >>>>> >>>>> When no prefix is used, libkrb5 will default to FILE: itself. >>>>> >>>>> We are going to look at changing the Samba code to strip the prefix >>>>> from >>>>> the 'dedicated keytab file' when applying it to memory-based keytabs. >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>>> >>>>> >>>>> -- >>> / Alexander Bokovoy >>> >>> > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tk at mdevsys.com Fri Dec 2 13:30:28 2016 From: tk at mdevsys.com (TomK) Date: Fri, 2 Dec 2016 08:30:28 -0500 Subject: [Freeipa-users] Mapping users from AD to IPA KDC Message-ID: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> Hey All, I've successfully mapped the nixadmins to the external group nixadmins_external. However no users in that group make it over to Free IPA that I can see. ipa group-add-member nixadmins_external --external "nixadmins" Windows AD users, 3 of them, are in the windows AD group nixadmins. However I can't port them over. These accounts have UNIX attributes assigned to them. Question that I have and can't find, should I be seeing these users in the mapped groups above? ( ie within the GUI should I see any users listed from AD DC in nixadmins or nixadmins_external? ) If there is an issue and I'm just not picking it out from the debug logs, what to look for? Is there anything more I need to do on the Windows side that I haven't found on the existing pages? # ipa group-add-member nixadmins_external --external "nixadmins" [member user]: [member group]: Group name: nixadmins_external Description: NIX Admins External map External member: S-1-5-21-3418825849-1633701630-2291579631-1006 Member groups: nixadmins Member of groups: nixadmins Indirect Member groups: nixadmins_external ------------------------- Number of members added 1 ------------------------- # # ipa trustdomain-find abc.xyz Domain name: abc.xyz Domain NetBIOS name: ABC Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517 Domain enabled: True ---------------------------- Number of entries returned 1 ---------------------------- # [realms] DOM.ABC.XYZ = { . . . auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/ auth_to_local = DEFAULT } # ipa trust-fetch-domains abc.xyz ---------------------------------------------------------------------------------------- List of trust domains successfully refreshed. Use trustdomain-find command to list them. ---------------------------------------------------------------------------------------- ---------------------------- Number of entries returned 0 ---------------------------- [root at idmipa01 sssd]# ipa trustdomain-find abc.xyz Domain name: abc.xyz Domain NetBIOS name: ABC Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517 Domain enabled: True ---------------------------- Number of entries returned 1 ---------------------------- # ipa trust-fetch-domains abc.xyz ---------------------------------------------------------------------------------------- List of trust domains successfully refreshed. Use trustdomain-find command to list them. ---------------------------------------------------------------------------------------- ---------------------------- Number of entries returned 0 ---------------------------- # The following command successfully returns all AD objects under the Users cn. # ldapsearch -x -h 192.168.0.3 -D "tom at abc.xyz" -W -b "cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From rob.verduijn at gmail.com Fri Dec 2 13:42:43 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Fri, 2 Dec 2016 14:42:43 +0100 Subject: [Freeipa-users] ipa fails to start hangs on pki-tomcatd In-Reply-To: References: <584036A8.1030403@redhat.com> <58404DDD.2020000@redhat.com> Message-ID: 2016-12-01 19:44 GMT+01:00 Rob Verduijn : > > > 2016-12-01 17:20 GMT+01:00 Rob Crittenden : > >> Rob Verduijn wrote: >> > >> > >> > 2016-12-01 15:41 GMT+01:00 Rob Crittenden > > >: >> > >> > Rob Verduijn wrote: >> > > Hello, >> > > >> > > For some reason my ipa server no longer boots. >> > > It keeps trying to start pki-tomcat service. >> > > >> > > Does anybody know where I should start looking to get this fixed ? >> > > >> > > Rob Verduijn >> > > >> > > ipactl -d start gives this output: >> > > ipa: DEBUG: The CA status is: check interrupted due to error: >> Command >> > > ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' >> '--no-check-certificate' >> > > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus >> > '' >> returned >> > > non-zero exit status 8 >> > > ipa: DEBUG: Waiting for CA to start... >> > > ipa: DEBUG: Starting external process >> > > ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' >> > > '--no-check-certificate' >> > > 'https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus >> > ' >> > > ipa: DEBUG: Process finished, return code=8 >> > > ipa: DEBUG: stdout= >> > > ipa: DEBUG: stderr=--2016-12-01 11:06:12-- >> > > https://freeipa02.tjako.thuis:8443/ca/admin/ca/getStatus >> > >> > > Resolving freeipa02.tjako.thuis (freeipa02.tjako.thuis)... >> 172.16.1.13 >> > > Connecting to freeipa02.tjako.thuis >> > > (freeipa02.tjako.thuis)|172.16.1.13|:8443... connected. >> > > HTTP request sent, awaiting response... >> > > HTTP/1.1 500 Internal Server Error >> > > Server: Apache-Coyote/1.1 >> > > Content-Type: text/html;charset=utf-8 >> > > Content-Language: en >> > > Content-Length: 2134 >> > > Date: Thu, 01 Dec 2016 10:06:13 GMT >> > > Connection: close >> > > 2016-12-01 11:06:13 ERROR 500: Internal Server Error. >> > > >> > > There are also some java warnings in the logs, but its java and I >> can >> > > never tell if its a serious error when java gives a warning. >> > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM >> > > org.apache.catalina.startup.SetAllPropertiesRule begin >> > > Dec 1 09:53:59 freeipa02 server: WARNING: >> > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> > > 'serverCertNickFile' to >> > > '/var/lib/pki/pki-tomcat/conf/serverCertNick.conf' did not find a >> > > matching property. >> > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM >> > > org.apache.catalina.startup.SetAllPropertiesRule begin >> > > Dec 1 09:53:59 freeipa02 server: WARNING: >> > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> > > 'passwordFile' to '/var/lib/pki/pki-tomcat/conf/password.conf' >> did not >> > > find a matching property. >> > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM >> > > org.apache.catalina.startup.SetAllPropertiesRule begin >> > > Dec 1 09:53:59 freeipa02 server: WARNING: >> > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> > > 'passwordClass' to 'org.apache.tomcat.util.net >> > .jss.PlainPasswordFile' >> > > did not find a matching property. >> > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM >> > > org.apache.catalina.startup.SetAllPropertiesRule begin >> > > Dec 1 09:53:59 freeipa02 server: WARNING: >> > > [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> > > 'certdbDir' to '/var/lib/pki/pki-tomcat/alias' did not find a >> matching >> > > property. >> > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM >> > > org.apache.tomcat.util.digester.SetPropertiesRule begin >> > > Dec 1 09:53:59 freeipa02 server: WARNING: >> > > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property >> > > 'xmlValidation' to 'false' did not find a matching property. >> > > Dec 1 09:53:59 freeipa02 server: Dec 01, 2016 9:53:59 AM >> > > org.apache.tomcat.util.digester.SetPropertiesRule begin >> > > Dec 1 09:53:59 freeipa02 server: WARNING: >> > > [SetPropertiesRule]{Server/Service/Engine/Host} Setting property >> > > 'xmlNamespaceAware' to 'false' did not find a matching property. >> > > >> > > >> > > I'm running centos7.2 x86_64 with the latest patches applied. >> > > some package versions below >> > > rpm -qa|egrep "ipa|tomcat"|sort >> > > ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64 >> > > ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64 >> > > ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64 >> > > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 >> > > ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64 >> > > libipa_hbac-1.13.0-40.el7_2.12.x86_64 >> > > python-iniparse-0.4-9.el7.noarch >> > > python-libipa_hbac-1.13.0-40.el7_2.12.x86_64 >> > > sssd-ipa-1.13.0-40.el7_2.12.x86_64 >> > > tomcat-7.0.54-8.el7_2.noarch >> > > tomcat-el-2.2-api-7.0.54-8.el7_2.noarch >> > > tomcat-jsp-2.2-api-7.0.54-8.el7_2.noarch >> > > tomcatjss-7.1.2-1.el7.noarch >> > > tomcat-lib-7.0.54-8.el7_2.noarch >> > > tomcat-servlet-3.0-api-7.0.54-8.el7_2.noarch >> > >> > The debug log is quite verbose. I find it helpful to note where the >> > previous log ended, starting and pulling the difference and going >> line >> > by line. It sometimes fails in one place which cascades to others >> this >> > generally makes it hard to grok. >> > >> > I'd also run `getcert list` and check to ensure that the CA >> subsystem >> > certificates are still valid. >> > >> > rob >> > >> > >> > >> > Hi, >> > >> > My certs where indeed expired. >> > I did what was said in here >> > http://www.freeipa.org/page/Howto/CA_Certificate_Renewal >> > And now they are all valid again. >> > >> > However it is still stuck at the same spot. >> > It keeps waiting for the ca to start and gets an internal error. >> > >> > In the pki-cataline logs this keeps repeating : >> > Dec 01, 2016 4:22:44 PM org.apache.catalina.core.ContainerBase >> > backgroundProcess >> > WARNING: Exception processing realm >> > com.netscape.cms.tomcat.ProxyRealm at 6934e456 background process >> > java.lang.NullPointerException >> > at >> > com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRe >> alm.java:108) >> > at >> > org.apache.catalina.core.ContainerBase.backgroundProcess(Con >> tainerBase.java:1360) >> > at >> > org.apache.catalina.core.ContainerBase$ContainerBackgroundPr >> ocessor.processChildren(ContainerBase.java:1530) >> > at >> > org.apache.catalina.core.ContainerBase$ContainerBackgroundPr >> ocessor.processChildren(ContainerBase.java:1540) >> > at >> > org.apache.catalina.core.ContainerBase$ContainerBackgroundPr >> ocessor.processChildren(ContainerBase.java:1540) >> > at >> > org.apache.catalina.core.ContainerBase$ContainerBackgroundPr >> ocessor.run(ContainerBase.java:1519) >> > at java.lang.Thread.run(Thread.java:745) >> > >> > I keep digging through the logs, but they are rather overwhelming. >> > >> > Have you got any pointers for me ? >> >> My only recommendation is to read top-down instead of bottom up as one >> would normally do. Look for the selftest and see if it was successful. >> If it wasn't then nothing will work. >> >> rob >> > > > > in the pki-catalina log I find a lot of warnings are these real warnings > or just noise from tomcat ? > Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule > begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'enableOCSP' to 'false' did not find a matching property. > Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule > begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'ocspResponderURL' to 'http://freeipa02.tjako.thuis:9080/ca/ocsp' > did not find a matching property. > Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule > begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did > not find a matching property. > Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule > begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'ocspCacheSize' to '1000' did not find a matching property. > Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule > begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'ocspMinCacheEntryDuration' to '60' did not find a matching > property. > Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule > begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'ocspMaxCacheEntryDuration' to '120' did not find a matching > property. > Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule > begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'ocspTimeout' to '10' did not find a matching property. > Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule > begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'strictCiphers' to 'true' did not find a matching property. > Dec 01, 2016 6:18:40 PM org.apache.catalina.startup.SetAllPropertiesRule > begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting > property 'sslOptions' to 'ssl2=false,ssl3=false,tls=true' did not find a > matching property. > > Rob Verduijn > > -- > Manage your subscription for 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 again, After some serious digging, I found something in the catalina log which happens at the same time in the slapd errors log ==> /var/log/pki/pki-tomcat/catalina.2016-11-23.log <== INFO: Deploying configuration descriptor /etc/pki/pki-tomcat/Catalina/localhost/ca.xml ==> /var/log/dirsrv/slapd-TJAKO-THUIS/errors <== [23/Nov/2016:14:38:19 +0100] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [23/Nov/2016:14:38:19 +0100] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [23/Nov/2016:14:38:19 +0100] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) Those are the first errors after which many follow. Manual binding to the ldap works ofcourse. What could be causing this ? Rob verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Dec 2 13:43:04 2016 From: sbose at redhat.com (Sumit Bose) Date: Fri, 2 Dec 2016 14:43:04 +0100 Subject: [Freeipa-users] Mapping users from AD to IPA KDC In-Reply-To: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> References: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> Message-ID: <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> On Fri, Dec 02, 2016 at 08:30:28AM -0500, TomK wrote: > Hey All, > > I've successfully mapped the nixadmins to the external group > nixadmins_external. However no users in that group make it over to Free IPA > that I can see. > > ipa group-add-member nixadmins_external --external "nixadmins" > > Windows AD users, 3 of them, are in the windows AD group nixadmins. However > I can't port them over. > > These accounts have UNIX attributes assigned to them. > > Question that I have and can't find, should I be seeing these users in the > mapped groups above? ( ie within the GUI should I see any users listed from > AD DC in nixadmins or nixadmins_external? ) no, the GUI won't show them. Calling 'id user_from_nixadmins at ad.domain' should show that nixadmins_external is a member of that group. With recent version of SSSD 'getent group nixadmins_external' should list the users from nixadmins as well, older versions might miss them. HTH bye, Sumit > > If there is an issue and I'm just not picking it out from the debug logs, > what to look for? Is there anything more I need to do on the Windows side > that I haven't found on the existing pages? > > > # ipa group-add-member nixadmins_external --external "nixadmins" > [member user]: > [member group]: > Group name: nixadmins_external > Description: NIX Admins External map > External member: S-1-5-21-3418825849-1633701630-2291579631-1006 > Member groups: nixadmins > Member of groups: nixadmins > Indirect Member groups: nixadmins_external > ------------------------- > Number of members added 1 > ------------------------- > # > > > # ipa trustdomain-find abc.xyz > Domain name: abc.xyz > Domain NetBIOS name: ABC > Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517 > Domain enabled: True > ---------------------------- > Number of entries returned 1 > ---------------------------- > # > > > [realms] > DOM.ABC.XYZ = { > . > . > . > auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/ > auth_to_local = DEFAULT > } > > > # ipa trust-fetch-domains abc.xyz > ---------------------------------------------------------------------------------------- > List of trust domains successfully refreshed. Use trustdomain-find command > to list them. > ---------------------------------------------------------------------------------------- > ---------------------------- > Number of entries returned 0 > ---------------------------- > [root at idmipa01 sssd]# ipa trustdomain-find abc.xyz > Domain name: abc.xyz > Domain NetBIOS name: ABC > Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517 > Domain enabled: True > ---------------------------- > Number of entries returned 1 > ---------------------------- > > > # ipa trust-fetch-domains abc.xyz > ---------------------------------------------------------------------------------------- > List of trust domains successfully refreshed. Use trustdomain-find command > to list them. > ---------------------------------------------------------------------------------------- > ---------------------------- > Number of entries returned 0 > ---------------------------- > # > > > The following command successfully returns all AD objects under the Users > cn. > > # ldapsearch -x -h 192.168.0.3 -D "tom at abc.xyz" -W -b > "cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn > > > -- > Cheers, > Tom K. > ------------------------------------------------------------------------------------- > > Living on earth is expensive, but it includes a free trip around the sun. > > -- > Manage your subscription for 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 jrichard at placeiq.com Fri Dec 2 15:46:44 2016 From: jrichard at placeiq.com (Jim Richard) Date: Fri, 2 Dec 2016 10:46:44 -0500 Subject: [Freeipa-users] ACIerrors is httpd log In-Reply-To: <5840F109.1040507@redhat.com> References: <4B8D5975-7858-4CC2-99AF-FC1E4D6EEB93@placeiq.com> <583C8806.1030809@redhat.com> <5840F109.1040507@redhat.com> Message-ID: <5BEF9BE5-D289-4616-BC11-A02CE4366877@placeiq.com> Hmm ya. So before I rebuilt anything I thought maybe it was my DNS records but it looks like that?s not it. More background, I used to have sso-109 and sso-110, both CA?s. I rebuilt sso-110 without CA. My DNS is external, BIND on another host. Using the following (at the end of the message) host/key issue as an example. On this host, in sssd.conf, ipa_server and krb5_server values are both _srv_ so that means they?ll discover from DNS right? But in my krb5.conf I have: [realms] PLACEIQ.NET = { kdc = sso-110.nym1.placeiq.net:88 master_kdc = sso-110.nym1.placeiq.net:88 admin_server = sso-110.nym1.placeiq.net:749 default_domain = placeiq.net pkinit_anchors = FILE:/etc/ipa/ca.crt } Is there any other IPA related config file that might reference a host name? I?ll include my DNS records at the end here, do they look correct for a two server setup, one with a CA (sso-109) and the other no CA (sso-110)? I never have been sure about the ?kerberos-master? entries, what makes an IPA host a ?kerberos master? and is this related to the CA in any way? ; ldap servers _ldap._tcp IN SRV 0 100 389 sso-109.nym1.placeiq.net. _ldap._tcp IN SRV 0 100 389 sso-110.nym1.placeiq.net. ;kerberos realm _kerberos IN TXT PLACEIQ.NET ; kerberos servers _kerberos._tcp IN SRV 0 100 88 sso-109.nym1.placeiq.net. _kerberos._tcp IN SRV 0 100 88 sso-110.nym1.placeiq.net. _kerberos._udp IN SRV 0 100 88 sso-109.nym1.placeiq.net. _kerberos._udp IN SRV 0 100 88 sso-110.nym1.placeiq.net. _kerberos-master._tcp IN SRV 0 100 88 sso-109.nym1.placeiq.net. _kerberos-master._udp IN SRV 0 100 88 sso-109.nym1.placeiq.net. _kerberos-adm._tcp IN SRV 0 100 749 sso-109.nym1.placeiq.net. _kerberos-adm._udp IN SRV 0 100 749 sso-109.nym1.placeiq.net. _kpasswd._tcp IN SRV 0 100 464 sso-109.nym1.placeiq.net. _kpasswd._tcp IN SRV 0 100 464 sso-110.nym1.placeiq.net. _kpasswd._udp IN SRV 0 100 464 sso-109.nym1.placeiq.net. _kpasswd._udp IN SRV 0 100 464 sso-110.nym1.placeiq.net. ; CNAME for IPA CA replicas (used for CRL, OCSP) ipa-ca IN A 10.1.41.109 Number of certificates and requests being tracked: 1. Request ID '20141110221330': status: MONITORING ca-error: Server at https://sso-110.nym1.placeiq.net/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: not allowed to perform this command). stuck: no key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - phoenix-142.nym1.placeiq.net',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - phoenix-142.nym1.placeiq.net',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=PLACEIQ.NET subject: CN=phoenix-142.nym1.placeiq.net,O=PLACEIQ.NET expires: 2016-11-10 22:13:31 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes We are moving to latest version on RHEL so we?ll have paid support but before than, gaining this understanding is massively valuable :) Jim Richard SYSTEM ADMINISTRATOR III (646) 338-8905 > On Dec 1, 2016, at 10:56 PM, Rob Crittenden wrote: > > Jim Richard wrote: >> I think I know what the issue is. >> >> I had 2 IPA servers, both with CA?s >> >> I dropped one and rebuilt without the CA but a bunch of clients are >> still pointing at this one server that now is without a CA. >> >> Will rebuild that one with a CA and almost sure that will fix. > > I'm rather skeptical of that. Not having a CA should not result in an > ACI error. It should internally forward any cert requests to an IPA > server that does have a CA and relay the result back to the requester. > > rob > >> >> >> Jim Richard >> >> >> >> SYSTEM ADMINISTRATOR III >> /(646) 338-8905 / >> >> >> PlaceIQ:Alibaba >> >> >> >> >> >>> On Nov 28, 2016, at 2:39 PM, Rob Crittenden >> > wrote: >>> >>> 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From outbackdingo at gmail.com Fri Dec 2 16:11:50 2016 From: outbackdingo at gmail.com (Outback Dingo) Date: Sat, 3 Dec 2016 00:11:50 +0800 Subject: [Freeipa-users] New IPA Servers Message-ID: Ok so trying to setup a replca to deploy 2 new freeipa servers on AWS... migrating from old servers going away, It was suggested to create a replica then promote it. this issue is.... the public ip for the new server is not the same as the servers IP on AWS... so which one do i use ??? From rcritten at redhat.com Fri Dec 2 22:29:13 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 2 Dec 2016 17:29:13 -0500 Subject: [Freeipa-users] ACIerrors is httpd log In-Reply-To: <5BEF9BE5-D289-4616-BC11-A02CE4366877@placeiq.com> References: <4B8D5975-7858-4CC2-99AF-FC1E4D6EEB93@placeiq.com> <583C8806.1030809@redhat.com> <5840F109.1040507@redhat.com> <5BEF9BE5-D289-4616-BC11-A02CE4366877@placeiq.com> Message-ID: <5841F5B9.1060405@redhat.com> Jim Richard wrote: > Hmm ya. So before I rebuilt anything I thought maybe it was my DNS > records but it looks like that?s not it. > > More background, I used to have sso-109 and sso-110, both CA?s. I > rebuilt sso-110 without CA. > > My DNS is external, BIND on another host. > > Using the following (at the end of the message) host/key issue as an > example. On this host, in sssd.conf, ipa_server and krb5_server values > are both _srv_ so that means they?ll discover from DNS right? > > But in my krb5.conf I have: > > [realms] > PLACEIQ.NET = { > kdc = sso-110.nym1.placeiq.net :88 > master_kdc = sso-110.nym1.placeiq.net > :88 > admin_server = sso-110.nym1.placeiq.net > :749 > default_domain = placeiq.net > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > > Is there any other IPA related config file that might reference a host name? > > I?ll include my DNS records at the end here, do they look correct for a > two server setup, one with a CA (sso-109) and the other no CA (sso-110)? > > I never have been sure about the ?kerberos-master? entries, what makes > an IPA host a ?kerberos master? and is this related to the CA in any way? > > ; ldap servers > _ldap._tcp IN SRV 0 100 389 sso-109.nym1.placeiq.net > . > _ldap._tcp IN SRV 0 100 389 sso-110.nym1.placeiq.net > . > > ;kerberos realm > _kerberos IN TXT PLACEIQ.NET > > ; kerberos servers > _kerberos._tcp IN SRV 0 100 88 sso-109.nym1.placeiq.net > . > _kerberos._tcp IN SRV 0 100 88 sso-110.nym1.placeiq.net > . > > _kerberos._udp IN SRV 0 100 88 sso-109.nym1.placeiq.net > . > _kerberos._udp IN SRV 0 100 88 sso-110.nym1.placeiq.net > . > > _kerberos-master._tcp IN SRV 0 100 88 sso-109.nym1.placeiq.net > . > _kerberos-master._udp IN SRV 0 100 88 sso-109.nym1.placeiq.net > . > _kerberos-adm._tcp IN SRV 0 100 749 sso-109.nym1.placeiq.net > . > _kerberos-adm._udp IN SRV 0 100 749 sso-109.nym1.placeiq.net > . > > _kpasswd._tcp IN SRV 0 100 464 sso-109.nym1.placeiq.net > . > _kpasswd._tcp IN SRV 0 100 464 sso-110.nym1.placeiq.net > . > > _kpasswd._udp IN SRV 0 100 464 sso-109.nym1.placeiq.net > . > _kpasswd._udp IN SRV 0 100 464 sso-110.nym1.placeiq.net > . > > ; CNAME for IPA CA replicas (used for CRL, OCSP) > ipa-ca IN A 10.1.41.109 > > > > Number of certificates and requests being tracked: 1. > Request ID '20141110221330': > status: MONITORING > ca-error: Server at https://sso-110.nym1.placeiq.net/ipa/xml > denied our request, giving up: 2100 (RPC failed at server. Insufficient > access: not allowed to perform this command). > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - > phoenix-142.nym1.placeiq.net > ',token='NSS Certificate DB' > certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA > Machine Certificate - phoenix-142.nym1.placeiq.net > ',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=PLACEIQ.NET > subject: CN=phoenix-142.nym1.placeiq.net > ,O=PLACEIQ.NET > expires: 2016-11-10 22:13:31 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > > We are moving to latest version on RHEL so we?ll have paid support but > before than, gaining this understanding is massively valuable :) I'm pretty certain this has nothing to do with servers being removed. IPA isn't saying it can't find something, it's saying you aren't allowed to do something. Why that is the case I don't know. A way to maybe find out would involve enabling debugging on the server. You can do this by creating /etc/ipa/server.conf with these contents: [global] debug=True Restart httpd and watch. I'd leave it on just long enough to see the problem, then turn it off again given you are already having disk space issues. There is no way to dynamically do this w/o restarting the service. rob From tk at mdevsys.com Sat Dec 3 05:33:43 2016 From: tk at mdevsys.com (TomK) Date: Sat, 3 Dec 2016 00:33:43 -0500 Subject: [Freeipa-users] Mapping users from AD to IPA KDC In-Reply-To: <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <2c4ff955-ab05-80ea-f4ae-da217d21b285@mdevsys.com> On 12/2/2016 8:43 AM, Sumit Bose wrote: > On Fri, Dec 02, 2016 at 08:30:28AM -0500, TomK wrote: >> Hey All, >> >> I've successfully mapped the nixadmins to the external group >> nixadmins_external. However no users in that group make it over to Free IPA >> that I can see. >> >> ipa group-add-member nixadmins_external --external "nixadmins" >> >> Windows AD users, 3 of them, are in the windows AD group nixadmins. However >> I can't port them over. >> >> These accounts have UNIX attributes assigned to them. >> >> Question that I have and can't find, should I be seeing these users in the >> mapped groups above? ( ie within the GUI should I see any users listed from >> AD DC in nixadmins or nixadmins_external? ) > > no, the GUI won't show them. Calling 'id user_from_nixadmins at ad.domain' > should show that nixadmins_external is a member of that group. With > recent version of SSSD 'getent group nixadmins_external' should list the > users from nixadmins as well, older versions might miss them. > > HTH > > bye, > Sumit > >> >> If there is an issue and I'm just not picking it out from the debug logs, >> what to look for? Is there anything more I need to do on the Windows side >> that I haven't found on the existing pages? >> >> >> # ipa group-add-member nixadmins_external --external "nixadmins" >> [member user]: >> [member group]: >> Group name: nixadmins_external >> Description: NIX Admins External map >> External member: S-1-5-21-3418825849-1633701630-2291579631-1006 >> Member groups: nixadmins >> Member of groups: nixadmins >> Indirect Member groups: nixadmins_external >> ------------------------- >> Number of members added 1 >> ------------------------- >> # >> >> >> # ipa trustdomain-find abc.xyz >> Domain name: abc.xyz >> Domain NetBIOS name: ABC >> Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517 >> Domain enabled: True >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> # >> >> >> [realms] >> DOM.ABC.XYZ = { >> . >> . >> . >> auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/ >> auth_to_local = DEFAULT >> } >> >> >> # ipa trust-fetch-domains abc.xyz >> ---------------------------------------------------------------------------------------- >> List of trust domains successfully refreshed. Use trustdomain-find command >> to list them. >> ---------------------------------------------------------------------------------------- >> ---------------------------- >> Number of entries returned 0 >> ---------------------------- >> [root at idmipa01 sssd]# ipa trustdomain-find abc.xyz >> Domain name: abc.xyz >> Domain NetBIOS name: ABC >> Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517 >> Domain enabled: True >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> >> # ipa trust-fetch-domains abc.xyz >> ---------------------------------------------------------------------------------------- >> List of trust domains successfully refreshed. Use trustdomain-find command >> to list them. >> ---------------------------------------------------------------------------------------- >> ---------------------------- >> Number of entries returned 0 >> ---------------------------- >> # >> >> >> The following command successfully returns all AD objects under the Users >> cn. >> >> # ldapsearch -x -h 192.168.0.3 -D "tom at abc.xyz" -W -b >> "cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn >> >> >> -- >> Cheers, >> Tom K. >> ------------------------------------------------------------------------------------- >> >> Living on earth is expensive, but it includes a free trip around the sun. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project > Nothing: # id tom at abc.xyz id: tom at abc.xyz: no such user # getent group nixadmins_external # getent group nixadmins nixadmins:*:1746600012: # I'll enable debug logging to determine further. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From tk at mdevsys.com Sat Dec 3 17:57:57 2016 From: tk at mdevsys.com (TomK) Date: Sat, 3 Dec 2016 12:57:57 -0500 Subject: [Freeipa-users] Mapping users from AD to IPA KDC In-Reply-To: <2c4ff955-ab05-80ea-f4ae-da217d21b285@mdevsys.com> References: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> <2c4ff955-ab05-80ea-f4ae-da217d21b285@mdevsys.com> Message-ID: On 12/3/2016 12:33 AM, TomK wrote: > On 12/2/2016 8:43 AM, Sumit Bose wrote: >> On Fri, Dec 02, 2016 at 08:30:28AM -0500, TomK wrote: >>> Hey All, >>> >>> I've successfully mapped the nixadmins to the external group >>> nixadmins_external. However no users in that group make it over to >>> Free IPA >>> that I can see. >>> >>> ipa group-add-member nixadmins_external --external "nixadmins" >>> >>> Windows AD users, 3 of them, are in the windows AD group nixadmins. >>> However >>> I can't port them over. >>> >>> These accounts have UNIX attributes assigned to them. >>> >>> Question that I have and can't find, should I be seeing these users >>> in the >>> mapped groups above? ( ie within the GUI should I see any users >>> listed from >>> AD DC in nixadmins or nixadmins_external? ) >> >> no, the GUI won't show them. Calling 'id user_from_nixadmins at ad.domain' >> should show that nixadmins_external is a member of that group. With >> recent version of SSSD 'getent group nixadmins_external' should list the >> users from nixadmins as well, older versions might miss them. >> >> HTH >> >> bye, >> Sumit >> >>> >>> If there is an issue and I'm just not picking it out from the debug >>> logs, >>> what to look for? Is there anything more I need to do on the Windows >>> side >>> that I haven't found on the existing pages? >>> >>> >>> # ipa group-add-member nixadmins_external --external "nixadmins" >>> [member user]: >>> [member group]: >>> Group name: nixadmins_external >>> Description: NIX Admins External map >>> External member: S-1-5-21-3418825849-1633701630-2291579631-1006 >>> Member groups: nixadmins >>> Member of groups: nixadmins >>> Indirect Member groups: nixadmins_external >>> ------------------------- >>> Number of members added 1 >>> ------------------------- >>> # >>> >>> >>> # ipa trustdomain-find abc.xyz >>> Domain name: abc.xyz >>> Domain NetBIOS name: ABC >>> Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517 >>> Domain enabled: True >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> # >>> >>> >>> [realms] >>> DOM.ABC.XYZ = { >>> . >>> . >>> . >>> auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/ >>> auth_to_local = DEFAULT >>> } >>> >>> >>> # ipa trust-fetch-domains abc.xyz >>> ---------------------------------------------------------------------------------------- >>> >>> List of trust domains successfully refreshed. Use trustdomain-find >>> command >>> to list them. >>> ---------------------------------------------------------------------------------------- >>> >>> ---------------------------- >>> Number of entries returned 0 >>> ---------------------------- >>> [root at idmipa01 sssd]# ipa trustdomain-find abc.xyz >>> Domain name: abc.xyz >>> Domain NetBIOS name: ABC >>> Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517 >>> Domain enabled: True >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> >>> >>> # ipa trust-fetch-domains abc.xyz >>> ---------------------------------------------------------------------------------------- >>> >>> List of trust domains successfully refreshed. Use trustdomain-find >>> command >>> to list them. >>> ---------------------------------------------------------------------------------------- >>> >>> ---------------------------- >>> Number of entries returned 0 >>> ---------------------------- >>> # >>> >>> >>> The following command successfully returns all AD objects under the >>> Users >>> cn. >>> >>> # ldapsearch -x -h 192.168.0.3 -D "tom at abc.xyz" -W -b >>> "cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn >>> >>> >>> -- >>> Cheers, >>> Tom K. >>> ------------------------------------------------------------------------------------- >>> >>> >>> Living on earth is expensive, but it includes a free trip around the >>> sun. >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go to http://freeipa.org for more info on the project >> > > Nothing: > > # id tom at abc.xyz > id: tom at abc.xyz: no such user > # getent group nixadmins_external > # getent group nixadmins > nixadmins:*:1746600012: > # > > I'll enable debug logging to determine further. > I'm getting the following in the logs. Not sure why it cannot assign a GID (possibly a range mismatch) but my dnaRemainingValues: 99498 and so is fine: [2016/12/03 10:45:44.232656, 3, pid=4792, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_allocate_gid.c:45(winbindd_allocate_gid_send) allocate_gid [2016/12/03 10:45:44.232689, 1, pid=4792, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:439(ndr_print_function_debug) wbint_AllocateGid: struct wbint_AllocateGid in: struct wbint_AllocateGid [2016/12/03 10:45:44.233134, 1, pid=4792, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:439(ndr_print_function_debug) wbint_AllocateGid: struct wbint_AllocateGid out: struct wbint_AllocateGid gid : * gid : 0x0000000000000000 (0) result : NT_STATUS_UNSUCCESSFUL [2016/12/03 10:45:44.233192, 5, pid=4792, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_allocate_gid.c:83(winbindd_allocate_gid_recv) Could not allocate gid: NT_STATUS_UNSUCCESSFUL [2016/12/03 10:45:44.233212, 10, pid=4792, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:787(wb_request_done) wb_request_done[5125:ALLOCATE_GID]: NT_STATUS_UNSUCCESSFUL Any hints would be appreciated while I look for a solution on this end. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From tk at mdevsys.com Mon Dec 5 03:23:25 2016 From: tk at mdevsys.com (TomK) Date: Sun, 4 Dec 2016 22:23:25 -0500 Subject: [Freeipa-users] Mapping users from AD to IPA KDC In-Reply-To: References: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> <2c4ff955-ab05-80ea-f4ae-da217d21b285@mdevsys.com> Message-ID: On 12/3/2016 12:57 PM, TomK wrote: > On 12/3/2016 12:33 AM, TomK wrote: >> On 12/2/2016 8:43 AM, Sumit Bose wrote: >>> On Fri, Dec 02, 2016 at 08:30:28AM -0500, TomK wrote: >>>> Hey All, >>>> >>>> I've successfully mapped the nixadmins to the external group >>>> nixadmins_external. However no users in that group make it over to >>>> Free IPA >>>> that I can see. >>>> >>>> ipa group-add-member nixadmins_external --external "nixadmins" >>>> >>>> Windows AD users, 3 of them, are in the windows AD group nixadmins. >>>> However >>>> I can't port them over. >>>> >>>> These accounts have UNIX attributes assigned to them. >>>> >>>> Question that I have and can't find, should I be seeing these users >>>> in the >>>> mapped groups above? ( ie within the GUI should I see any users >>>> listed from >>>> AD DC in nixadmins or nixadmins_external? ) >>> >>> no, the GUI won't show them. Calling 'id user_from_nixadmins at ad.domain' >>> should show that nixadmins_external is a member of that group. With >>> recent version of SSSD 'getent group nixadmins_external' should list the >>> users from nixadmins as well, older versions might miss them. >>> >>> HTH >>> >>> bye, >>> Sumit >>> >>>> >>>> If there is an issue and I'm just not picking it out from the debug >>>> logs, >>>> what to look for? Is there anything more I need to do on the Windows >>>> side >>>> that I haven't found on the existing pages? >>>> >>>> >>>> # ipa group-add-member nixadmins_external --external "nixadmins" >>>> [member user]: >>>> [member group]: >>>> Group name: nixadmins_external >>>> Description: NIX Admins External map >>>> External member: S-1-5-21-3418825849-1633701630-2291579631-1006 >>>> Member groups: nixadmins >>>> Member of groups: nixadmins >>>> Indirect Member groups: nixadmins_external >>>> ------------------------- >>>> Number of members added 1 >>>> ------------------------- >>>> # >>>> >>>> >>>> # ipa trustdomain-find abc.xyz >>>> Domain name: abc.xyz >>>> Domain NetBIOS name: ABC >>>> Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517 >>>> Domain enabled: True >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> # >>>> >>>> >>>> [realms] >>>> DOM.ABC.XYZ = { >>>> . >>>> . >>>> . >>>> auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/ >>>> auth_to_local = DEFAULT >>>> } >>>> >>>> >>>> # ipa trust-fetch-domains abc.xyz >>>> ---------------------------------------------------------------------------------------- >>>> >>>> >>>> List of trust domains successfully refreshed. Use trustdomain-find >>>> command >>>> to list them. >>>> ---------------------------------------------------------------------------------------- >>>> >>>> >>>> ---------------------------- >>>> Number of entries returned 0 >>>> ---------------------------- >>>> [root at idmipa01 sssd]# ipa trustdomain-find abc.xyz >>>> Domain name: abc.xyz >>>> Domain NetBIOS name: ABC >>>> Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517 >>>> Domain enabled: True >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> >>>> >>>> # ipa trust-fetch-domains abc.xyz >>>> ---------------------------------------------------------------------------------------- >>>> >>>> >>>> List of trust domains successfully refreshed. Use trustdomain-find >>>> command >>>> to list them. >>>> ---------------------------------------------------------------------------------------- >>>> >>>> >>>> ---------------------------- >>>> Number of entries returned 0 >>>> ---------------------------- >>>> # >>>> >>>> >>>> The following command successfully returns all AD objects under the >>>> Users >>>> cn. >>>> >>>> # ldapsearch -x -h 192.168.0.3 -D "tom at abc.xyz" -W -b >>>> "cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn >>>> >>>> >>>> -- >>>> Cheers, >>>> Tom K. >>>> ------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> Living on earth is expensive, but it includes a free trip around the >>>> sun. >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go to http://freeipa.org for more info on the project >>> >> >> Nothing: >> >> # id tom at abc.xyz >> id: tom at abc.xyz: no such user >> # getent group nixadmins_external >> # getent group nixadmins >> nixadmins:*:1746600012: >> # >> >> I'll enable debug logging to determine further. >> > > I'm getting the following in the logs. Not sure why it cannot assign a > GID (possibly a range mismatch) but my dnaRemainingValues: 99498 and so > is fine: > > [2016/12/03 10:45:44.232656, 3, pid=4792, effective(0, 0), real(0, 0), > class=winbind] > ../source3/winbindd/winbindd_allocate_gid.c:45(winbindd_allocate_gid_send) > allocate_gid > [2016/12/03 10:45:44.232689, 1, pid=4792, effective(0, 0), real(0, 0)] > ../librpc/ndr/ndr.c:439(ndr_print_function_debug) > wbint_AllocateGid: struct wbint_AllocateGid > in: struct wbint_AllocateGid > [2016/12/03 10:45:44.233134, 1, pid=4792, effective(0, 0), real(0, 0)] > ../librpc/ndr/ndr.c:439(ndr_print_function_debug) > wbint_AllocateGid: struct wbint_AllocateGid > out: struct wbint_AllocateGid > gid : * > gid : 0x0000000000000000 (0) > result : NT_STATUS_UNSUCCESSFUL > [2016/12/03 10:45:44.233192, 5, pid=4792, effective(0, 0), real(0, 0), > class=winbind] > ../source3/winbindd/winbindd_allocate_gid.c:83(winbindd_allocate_gid_recv) > Could not allocate gid: NT_STATUS_UNSUCCESSFUL > [2016/12/03 10:45:44.233212, 10, pid=4792, effective(0, 0), real(0, 0), > class=winbind] ../source3/winbindd/winbindd.c:787(wb_request_done) > wb_request_done[5125:ALLOCATE_GID]: NT_STATUS_UNSUCCESSFUL > > Any hints would be appreciated while I look for a solution on this end. > Could not get much from logs and decided to start fresh. When I run this: ipa trust-add --type=ad mds.xyz --admin Administrator --password Trust works fine and id tom at mds.xyz returns a valid result. However when I run the following on both masters on a fresh new setup: ipa-adtrust-install --netbios-name=NIX -a "" ipa trust-add --type=ad "mds.xyz" --trust-secret and created a trust object in AD DC with the name of NIX and a non-transitive trust, the above did NOT work. I didn't get anything by typing id tom at mds.xyz. (I do not get an option for a Forest Trust as the gif on this page suggests: https://www.freeipa.org/page/Active_Directory_trust_setup . Possibly it's Server 2012 hence the difference in what's presented to me but another reason is that the name I type for the trust can't resolve to an IP for now: nix.mds.xyz . So I use NIX to match the bios name used on the ipa-adtrust-install command above. ) I went back to the trust object in AD and set it to Transitive from Non-transitive. And all of a sudden I can resolve the AD ID's on the IP Servers and all is working fine. Great! I could not follow the section within the online document above for setting up forwarders. I had to delegate nix.mds.xyz from the two AD / DNS Clustered Windows Server 2012 servers to the two FreeIPA servers (idmipa01, idmipa02) . I found that the forwarding section doesn't quite jive well with delegation in Windows Server 2012. The remaining questions I need to ask is does the NetBIOS name used on the ipa-adtrust-install command above have to match the AD DC Trust object name? Any tie's between the naming of the two? ( Thinking no tie in but not 100% . Seems AD expects a domain that resolves to an IP ) Also, given this setup I have: 1) The two windows servers, winad01, winad02 are both DNS, AD servers and are clustered (NLB) 2) Have DNS delegation on nix.mds.xyz so FreeIPA servers will be authoritative for that subdomain. 3) AD Trust objects look for a resolvable domain (ie nix.mds.xyz) and current version of FreeIPA does not yet resolve nix.mds.xyz to any IP ( 4) IPA ipa-adtrust-install only accepts NetBIOS names. Is it at all possible to setup a non-transitive trust with all that? ( I might just not be seeing the forest through the trees :) - Pun Intended. ) Still new to quite a bit of this so thank you for your patience and feedback. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From abokovoy at redhat.com Mon Dec 5 07:02:32 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 Dec 2016 09:02:32 +0200 Subject: [Freeipa-users] Mapping users from AD to IPA KDC In-Reply-To: References: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> <2c4ff955-ab05-80ea-f4ae-da217d21b285@mdevsys.com> Message-ID: <20161205070232.gnntt334q5siv3va@redhat.com> On su, 04 joulu 2016, TomK wrote: >Could not get much from logs and decided to start fresh. When I run this: > >ipa trust-add --type=ad mds.xyz --admin Administrator --password > >Trust works fine and id tom at mds.xyz returns a valid result. > >However when I run the following on both masters on a fresh new setup: > >ipa-adtrust-install --netbios-name=NIX -a "" >ipa trust-add --type=ad "mds.xyz" --trust-secret > >and created a trust object in AD DC with the name of NIX and a >non-transitive trust, the above did NOT work. I didn't get anything >by typing id tom at mds.xyz. (I do not get an option for a Forest Trust >as the gif on this page suggests: >https://www.freeipa.org/page/Active_Directory_trust_setup . Possibly >it's Server 2012 hence the difference in what's presented to me but >another reason is that the name I type for the trust can't resolve to >an IP for now: nix.mds.xyz . So I use NIX to match the bios name used >on the ipa-adtrust-install command above. ) The shared secret case for one-way trust is known to be broken. When a shared half is created on AD side first, it is marked as not yet valid by Windows and currently we cannot perform validation of it from IPA side. Validating it from AD side is not possible as well as we don't provide all interfaces Windows would like to use. And the fact you cannot see 'Forest Trust' type of the trust says also that you have problems with reaching IPA masters from AD DC side for probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and UDP). >I went back to the trust object in AD and set it to Transitive from >Non-transitive. And all of a sudden I can resolve the AD ID's on the >IP Servers and all is working fine. Great! > >I could not follow the section within the online document above for >setting up forwarders. I had to delegate nix.mds.xyz from the two AD >/ DNS Clustered Windows Server 2012 servers to the two FreeIPA servers >(idmipa01, idmipa02) . I found that the forwarding section doesn't >quite jive well with delegation in Windows Server 2012. Whatever you do to forward DNS in a DNS-compliant way should be enough. The documentation typically tries to explain that there are multiple ways to achieve this, from hackish to standards-compliant. >The remaining questions I need to ask is does the NetBIOS name used on >the ipa-adtrust-install command above have to match the AD DC Trust >object name? Any tie's between the naming of the two? ( Thinking no >tie in but not 100% . Seems AD expects a domain that resolves to an IP >) 100% tied, this is AD requirement. Each domain has domain name in NetBIOS, domain name in DNS, and SID. The first two must be matching and on DNS level AD expects both to resolve properly. It is a legacy from NT times that _all_ trusted domain objects are named as NetBIOS$, as well as _all_ computer objects have the same style names COMPUTER$. This is enforced on multiple levels, from SMB to Kerberos. What 'resolve' means here is that DNS searches for different types of SRV records should succeed, and then CLDAP ping to the servers which are mentioned in the _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.$DOMAIN or _ldap._tcp.dc._msdcs.$DOMAIN should succeed too. >Also, given this setup I have: > >1) The two windows servers, winad01, winad02 are both DNS, AD servers >and are clustered (NLB) > >2) Have DNS delegation on nix.mds.xyz so FreeIPA servers will be >authoritative for that subdomain. > >3) AD Trust objects look for a resolvable domain (ie nix.mds.xyz) and >current version of FreeIPA does not yet resolve nix.mds.xyz to any IP No, this is not required. What required, is that trust object is correctly set, and it involves a lot more than what you are outlining. As you can see above, resolving nix.mds.xyz to IP is not required, but DNS SRV records like _ldap._tcp.dc._msdcs.nix.mds.xyz should be resolvable. >4) IPA ipa-adtrust-install only accepts NetBIOS names. ipa-adtrust-install configures what is missing from the base setup related to the trust to AD. NetBIOS name is missing, thus is added. > >Is it at all possible to setup a non-transitive trust with all that? >( I might just not be seeing the forest through the trees :) - Pun >Intended. ) Still new to quite a bit of this so thank you for your >patience and feedback. Non-transitive trust is called 'external trust' in AD jargon. It can be established to any domain in a forest. We support it from FreeIPA 4.4 with --external=true option to 'ipa trust-add'. With non-transitive trust only users from directly trusted domain can be seen and authenticated. -- / Alexander Bokovoy From jjflynn22 at gmail.com Sun Dec 4 23:25:13 2016 From: jjflynn22 at gmail.com (Joseph Flynn) Date: Sun, 4 Dec 2016 18:25:13 -0500 Subject: [Freeipa-users] Let's Encrypt along with FreeIPA Message-ID: Sorry if this is not the appropriate forum for discussing this topic. I have installed a FreeIPA system on CentOS 7 and am trying to get the Let's Encrypt scripts to work as defined in https://github.com/freeipa/freeipa-letsencrypt I hand to tinker with a combination of enabling/disabling EPEL and this new tool DNF that I am not too familiar with but eventually got the script to run. It is ending with the following error: ipa: INFO: Systemwide CA database updated. > ipa.ipaclient.ipa_certupdate.CertUpdate: INFO: The ipa-certupdate command > was successful > Directory Manager password: > > Installing CA certificate, please wait > Not a valid CA certificate: (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate > issuer is not recognized. (visit > http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) > > Does anyone recognize this situation? I have installed this on a VirtualBox client in Bridge Network mode. Prior to trying to use a real certificate, I could access the FreeIPA UI from Firefox on both the VM and other computers in the home. I've gotten a domain name and have that domain name pointed to my home router with a handful of ports (those listed at the end of the FreeIPA install) forwarded to my VM. For completeness, I have included the history below along with the full output including a couple of highlighted areas that could be errors. Thanks for any assistance from anyone who might notice an error in my ways. Joe History: 1 ifconfig -a 2 sudo yum -y update 3 cat /etc/hostname 4 sudo echo 192.168.1.201 ipa-1.kkgpitt.org ipa-1 >> /etc/hosts 5 sudo vi /etc/hosts 7 sudo reboot now 8 hostname 9 ifconfig -a 11 sudo visudo 12 sudo ls # just to set pw 13 sudo yum install epel-release -y 14 sudo yum install -y haveged 15 sudo systemctl start haveged.service 16 sudo ipa-server-install 17 kinit admin 18 firewall-cmd --permanent --add-service=ntp 19 firewall-cmd --permanent --add-service=http 20 firewall-cmd --permanent --add-service=https 21 firewall-cmd --permanent --add-service=ldap 22 firewall-cmd --permanent --add-service=ldaps 23 firewall-cmd --permanent --add-service=kerberos 24 firewall-cmd --permanent --add-service=kpasswd 26 sudo authconfig --enablemkhomedir --update 27 sudo chkconfig sssd on 28 git config --global user.name "Joe Flynn" 29 git config --global user.email "jjflynn22 at gmail.com" 30 mkdir ~/.ssh 31 cd ~/.ssh 32 vi id_rsa 33 vi id_rsa.pub 34 chmod 700 ~/.ssh 35 chmod 600 ~/.ssh/* 36 ssh-add ~/.ssh/id_rsa 37 sudo yum install -y letsencrypt 38 sudo cp -r /etc/httpd/alias /etc/httpd/alias_backup 39 cd ~ 40 git clone https://github.com/freeipa/freeipa-letsencrypt.git 41 sudo cp -r freeipa-letsencrypt /root/ipa-le 42 sudo vi /root/ipa-le/renew-le.sh 43 sudo yum install -y dnf 44 sudo yum remove -y epel-release 45 sudo dnf repolist 46 sudo /root/ipa-le/setup-le.sh 47 history > [jjflynn22 at ipa-1 ~]$ sudo visudo > [sudo] password for jjflynn22: > [jjflynn22 at ipa-1 ~]$ sudo yum install epel-release -y > Loaded plugins: fastestmirror, langpacks > base > | 3.6 kB 00:00:00 > extras > | 3.4 kB 00:00:00 > updates > | 3.4 kB 00:00:00 > Loading mirror speeds from cached hostfile > * base: repo1.ash.innoscale.net > * extras: mirrors.advancedhosters.com > * updates: mirror.cs.vt.edu > Resolving Dependencies > --> Running transaction check > ---> Package epel-release.noarch 0:7-6 will be installed > --> Finished Dependency Resolution > > Dependencies Resolved > > > ============================================================================================================================= > Package Arch > Version Repository Size > > ============================================================================================================================= > Installing: > epel-release noarch > 7-6 extras 14 k > > Transaction Summary > > ============================================================================================================================= > Install 1 Package > > Total download size: 14 k > Installed size: 24 k > Downloading packages: > epel-release-7-6.noarch.rpm > | 14 kB 00:00:00 > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Installing : > epel-release-7-6.noarch > 1/1 > Verifying : > epel-release-7-6.noarch > 1/1 > > Installed: > epel-release.noarch > 0:7-6 > > > Complete! > [jjflynn22 at ipa-1 ~]$ sudo yum install -y haveged > Loaded plugins: fastestmirror, langpacks > epel/x86_64/metalink > | 13 kB 00:00:00 > epel > | 4.3 kB 00:00:00 > (1/3): > epel/x86_64/updateinfo > | 676 kB 00:00:00 > (2/3): > epel/x86_64/group_gz > | 170 kB 00:00:00 > (3/3): > epel/x86_64/primary_db > | 4.4 MB 00:00:01 > Loading mirror speeds from cached hostfile > * base: repo1.ash.innoscale.net > * epel: ftp.osuosl.org > * extras: mirror.fusioncloud.co > * updates: ftp.osuosl.org > Resolving Dependencies > --> Running transaction check > ---> Package haveged.x86_64 0:1.9.1-1.el7 will be installed > --> Finished Dependency Resolution > > Dependencies Resolved > > > ============================================================================================================================= > Package Arch > Version Repository Size > > ============================================================================================================================= > Installing: > haveged x86_64 > 1.9.1-1.el7 epel 61 k > > Transaction Summary > > ============================================================================================================================= > Install 1 Package > > Total download size: 61 k > Installed size: 181 k > Downloading packages: > warning: > /var/cache/yum/x86_64/7/epel/packages/haveged-1.9.1-1.el7.x86_64.rpm: > Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY > Public key for haveged-1.9.1-1.el7.x86_64.rpm is not installed > haveged-1.9.1-1.el7.x86_64.rpm > | 61 kB 00:00:00 > Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 > Importing GPG key 0x352C64E5: > Userid : "Fedora EPEL (7) " > Fingerprint: 91e9 7d7c 4a5e 96f1 7f3e 888f 6a2f aea2 352c 64e5 > Package : epel-release-7-6.noarch (@extras) > From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Installing : > haveged-1.9.1-1.el7.x86_64 > 1/1 > Verifying : > haveged-1.9.1-1.el7.x86_64 > 1/1 > > Installed: > haveged.x86_64 > 0:1.9.1-1.el7 > > > Complete! > [jjflynn22 at ipa-1 ~]$ sudo systemctl start haveged.service > [jjflynn22 at ipa-1 ~]$ > [jjflynn22 at ipa-1 ~]$ > [jjflynn22 at ipa-1 ~]$ > [jjflynn22 at ipa-1 ~]$ > [jjflynn22 at ipa-1 ~]$ sudo ipa-server-install > > The log file for this installation can be found in > /var/log/ipaserver-install.log > > ============================================================================== > This program will set up the IPA Server. > > This includes: > * Configure a stand-alone CA (dogtag) for certificate management > * Configure the Network Time Daemon (ntpd) > * Create and configure an instance of Directory Server > * Create and configure a Kerberos Key Distribution Center (KDC) > * Configure Apache (httpd) > > To accept the default shown in brackets, press the Enter key. > > WARNING: conflicting time&date synchronization service 'chronyd' will be > disabled > in favor of ntpd > > Do you want to configure integrated DNS (BIND)? [no]: > > Enter the fully qualified domain name of the computer > on which you're setting up server software. Using the form > . > Example: master.example.com. > > > Server host name [ipa-1.kkgpitt.org]: > > The domain name has been determined based on the host name. > > Please confirm the domain name [kkgpitt.org]: > > The kerberos protocol requires a Realm name to be defined. > This is typically the domain name converted to uppercase. > > Please provide a realm name [KKGPITT.ORG]: > Certain directory server operations require an administrative user. > This user is referred to as the Directory Manager and has full access > to the Directory for system management tasks and will be added to the > instance of directory server created for IPA. > The password must be at least 8 characters long. > > Directory Manager password: > Password (confirm): > > The IPA server requires an administrative user, named 'admin'. > This user is a regular system account used for IPA server administration. > > IPA admin password: > Password (confirm): > > > The IPA Master Server will be configured with: > Hostname: ipa-1.kkgpitt.org > IP address(es): 192.168.1.201 > Domain name: kkgpitt.org > Realm name: KKGPITT.ORG > > Continue to configure the system with these values? [no]: yes > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv). Estimated time: 1 minute > [1/42]: creating directory server user > [2/42]: creating directory server instance > [3/42]: adding default schema > [4/42]: enabling memberof plugin > [5/42]: enabling winsync plugin > [6/42]: configuring replication version plugin > [7/42]: enabling IPA enrollment plugin > [8/42]: enabling ldapi > [9/42]: configuring uniqueness plugin > [10/42]: configuring uuid plugin > [11/42]: configuring modrdn plugin > [12/42]: configuring DNS plugin > [13/42]: enabling entryUSN plugin > [14/42]: configuring lockout plugin > [15/42]: creating indices > [16/42]: enabling referential integrity plugin > [17/42]: configuring certmap.conf > [18/42]: configure autobind for root > [19/42]: configure new location for managed entries > [20/42]: configure dirsrv ccache > [21/42]: enable SASL mapping fallback > [22/42]: restarting directory server > [23/42]: adding default layout > [24/42]: adding delegation layout > [25/42]: creating container for managed entries > [26/42]: configuring user private groups > [27/42]: configuring netgroups from hostgroups > [28/42]: creating default Sudo bind user > [29/42]: creating default Auto Member layout > [30/42]: adding range check plugin > [31/42]: creating default HBAC rule allow_all > [32/42]: adding entries for topology management > [33/42]: initializing group membership > [34/42]: adding master entry > [35/42]: initializing domain level > [36/42]: configuring Posix uid/gid generation > [37/42]: adding replication acis > [38/42]: enabling compatibility plugin > [39/42]: activating sidgen plugin > [40/42]: activating extdom plugin > [41/42]: tuning directory server > [42/42]: configuring directory to start on boot > Done configuring directory server (dirsrv). > Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 > seconds > [1/28]: creating certificate server user > [2/28]: configuring certificate server instance > [3/28]: stopping certificate server instance to update CS.cfg > [4/28]: backing up CS.cfg > [5/28]: disabling nonces > [6/28]: set up CRL publishing > [7/28]: enable PKIX certificate path discovery and validation > [8/28]: starting certificate server instance > [9/28]: creating RA agent certificate database > [10/28]: importing CA chain to RA certificate database > [11/28]: fixing RA database permissions > [12/28]: setting up signing cert profile > [13/28]: setting audit signing renewal to 2 years > [14/28]: restarting certificate server > [15/28]: requesting RA certificate from CA > [16/28]: issuing RA agent certificate > [17/28]: adding RA agent as a trusted user > [18/28]: authorizing RA to modify profiles > [19/28]: configure certmonger for renewals > [20/28]: configure certificate renewals > [21/28]: configure RA certificate renewal > [22/28]: configure Server-Cert certificate renewal > [23/28]: Configure HTTP to proxy connections > [24/28]: restarting certificate server > [25/28]: migrating certificate profiles to LDAP > [26/28]: importing IPA certificate profiles > [27/28]: adding default CA ACL > [28/28]: updating IPA configuration > Done configuring certificate server (pki-tomcatd). > Configuring directory server (dirsrv). Estimated time: 10 seconds > [1/3]: configuring ssl for ds instance > [2/3]: restarting directory server > [3/3]: adding CA certificate entry > Done configuring directory server (dirsrv). > Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds > [1/10]: adding sasl mappings to the directory > [2/10]: adding kerberos container to the directory > [3/10]: configuring KDC > [4/10]: initialize kerberos container > [5/10]: adding default ACIs > [6/10]: creating a keytab for the directory > [7/10]: creating a keytab for the machine > [8/10]: adding the password extension to the directory > [9/10]: starting the KDC > [10/10]: configuring KDC to start on boot > Done configuring Kerberos KDC (krb5kdc). > Configuring kadmin > [1/2]: starting kadmin > [2/2]: configuring kadmin to start on boot > Done configuring kadmin. > Configuring ipa_memcached > [1/2]: starting ipa_memcached > [2/2]: configuring ipa_memcached to start on boot > Done configuring ipa_memcached. > Configuring ipa-otpd > [1/2]: starting ipa-otpd > [2/2]: configuring ipa-otpd to start on boot > Done configuring ipa-otpd. > Configuring the web interface (httpd). Estimated time: 1 minute > [1/19]: setting mod_nss port to 443 > [2/19]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2 > [3/19]: setting mod_nss password file > [4/19]: enabling mod_nss renegotiate > [5/19]: adding URL rewriting rules > [6/19]: configuring httpd > [7/19]: configure certmonger for renewals > [8/19]: setting up ssl > [9/19]: importing CA certificates from LDAP > [10/19]: setting up browser autoconfig > [11/19]: publish CA cert > [12/19]: creating a keytab for httpd > [13/19]: clean up any existing httpd ccache > [14/19]: configuring SELinux for httpd > [15/19]: create KDC proxy user > [16/19]: create KDC proxy config > [17/19]: enable KDC proxy > [18/19]: restarting httpd > [19/19]: configuring httpd to start on boot > Done configuring the web interface (httpd). > Applying LDAP updates > Upgrading IPA: > [1/9]: stopping directory server > [2/9]: saving configuration > [3/9]: disabling listeners > [4/9]: enabling DS global lock > [5/9]: starting directory server > [6/9]: upgrading server > [7/9]: stopping directory server > [8/9]: restoring configuration > [9/9]: starting directory server > Done. > Restarting the directory server > Restarting the KDC > Sample zone file for bind has been created in /tmp/sample.zone.Yjwpca.db > Restarting the web server > > ============================================================================== > Setup complete > > Next steps: > 1. You must make sure these network ports are open: > TCP Ports: > * 80, 443: HTTP/HTTPS > * 389, 636: LDAP/LDAPS > * 88, 464: kerberos > UDP Ports: > * 88, 464: kerberos > * 123: ntp > > 2. You can now obtain a kerberos ticket using the command: 'kinit > admin' > This ticket will allow you to use the IPA tools (e.g., ipa user-add) > and the web user interface. > > Be sure to back up the CA certificates stored in /root/cacert.p12 > These files are required to create replicas. The password for these > files is the Directory Manager password > [jjflynn22 at ipa-1 ~]$ kinit admin > Password for admin at KKGPITT.ORG: > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=ntp > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=http > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=https > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=ldap > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=ldaps > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=kerberos > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=kpasswd > success > [jjflynn22 at ipa-1 ~]$ sudo authconfig --enablemkhomedir --update > [jjflynn22 at ipa-1 ~]$ sudo chkconfig sssd on > Note: Forwarding request to 'systemctl enable sssd.service'. > [jjflynn22 at ipa-1 ~]$ git config --global user.name "Joe Flynn" > [jjflynn22 at ipa-1 ~]$ git config --global user.email "jjflynn22 at gmail.com" > [jjflynn22 at ipa-1 ~]$ mkdir ~/.ssh > [jjflynn22 at ipa-1 ~]$ cd ~/.ssh > [jjflynn22 at ipa-1 .ssh]$ vi id_rsa > [jjflynn22 at ipa-1 .ssh]$ vi id_rsa.pub > [jjflynn22 at ipa-1 .ssh]$ chmod 700 ~/.ssh > [jjflynn22 at ipa-1 .ssh]$ chmod 600 ~/.ssh/* > [jjflynn22 at ipa-1 .ssh]$ ssh-add ~/.ssh/id_rsa > Identity added: /home/jjflynn22/.ssh/id_rsa (/home/jjflynn22/.ssh/id_rsa) > [jjflynn22 at ipa-1 .ssh]$ sudo yum install -y letsencrypt > Loaded plugins: fastestmirror, langpacks > Loading mirror speeds from cached hostfile > * base: repo1.ash.innoscale.net > * epel: mirror.cogentco.com > * extras: chicago.gaminghost.co > * updates: mirror.cs.vt.edu > Resolving Dependencies > --> Running transaction check > ---> Package certbot.noarch 0:0.9.3-1.el7 will be installed > --> Processing Dependency: python2-certbot = 0.9.3-1.el7 for package: > certbot-0.9.3-1.el7.noarch > --> Running transaction check > ---> Package python2-certbot.noarch 0:0.9.3-1.el7 will be installed > --> Processing Dependency: python2-acme = 0.9.3 for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python2-dialog >= 3.3.0 for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python2-configargparse >= 0.10.0 for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python-psutil >= 2.1.0 for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python-zope-interface for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python-zope-component for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python-parsedatetime for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python-mock for package: > python2-certbot-0.9.3-1.el7.noarch > --> Running transaction check > ---> Package python-parsedatetime.noarch 0:1.5-3.el7 will be installed > ---> Package python-psutil.x86_64 0:2.2.1-1.el7 will be installed > ---> Package python-zope-component.noarch 1:4.1.0-1.el7 will be installed > --> Processing Dependency: python-zope-event for package: > 1:python-zope-component-4.1.0-1.el7.noarch > ---> Package python-zope-interface.x86_64 0:4.0.5-4.el7 will be installed > ---> Package python2-acme.noarch 0:0.9.3-1.el7 will be installed > --> Processing Dependency: python-pyrfc3339 for package: > python2-acme-0.9.3-1.el7.noarch > --> Processing Dependency: python-ndg_httpsclient for package: > python2-acme-0.9.3-1.el7.noarch > ---> Package python2-configargparse.noarch 0:0.10.0-1.el7 will be installed > ---> Package python2-dialog.noarch 0:3.3.0-6.el7 will be installed > --> Processing Dependency: dialog for package: > python2-dialog-3.3.0-6.el7.noarch > ---> Package python2-mock.noarch 0:1.0.1-9.el7 will be installed > --> Running transaction check > ---> Package dialog.x86_64 0:1.2-4.20130523.el7 will be installed > ---> Package python-ndg_httpsclient.noarch 0:0.3.2-1.el7 will be installed > ---> Package python-zope-event.noarch 0:4.0.3-2.el7 will be installed > ---> Package python2-pyrfc3339.noarch 0:1.0-2.el7 will be installed > --> Finished Dependency Resolution > > Dependencies Resolved > > > ============================================================================================================================= > Package Arch > Version Repository Size > > ============================================================================================================================= > Installing: > certbot noarch > 0.9.3-1.el7 epel 16 k > Installing for dependencies: > dialog x86_64 > 1.2-4.20130523.el7 base 208 k > python-ndg_httpsclient noarch > 0.3.2-1.el7 epel 43 k > python-parsedatetime noarch > 1.5-3.el7 epel 61 k > python-psutil x86_64 > 2.2.1-1.el7 epel 114 k > python-zope-component noarch > 1:4.1.0-1.el7 epel 110 k > python-zope-event noarch > 4.0.3-2.el7 epel 79 k > python-zope-interface x86_64 > 4.0.5-4.el7 base 138 k > python2-acme noarch > 0.9.3-1.el7 epel 168 k > python2-certbot noarch > 0.9.3-1.el7 epel 361 k > python2-configargparse noarch > 0.10.0-1.el7 epel 28 k > python2-dialog noarch > 3.3.0-6.el7 epel 94 k > python2-mock noarch > 1.0.1-9.el7 epel 92 k > python2-pyrfc3339 noarch > 1.0-2.el7 epel 13 k > > Transaction Summary > > ============================================================================================================================= > Install 1 Package (+13 Dependent packages) > > Total download size: 1.5 M > Installed size: 6.3 M > Downloading packages: > (1/14): > python-ndg_httpsclient-0.3.2-1.el7.noarch.rpm > | 43 kB 00:00:00 > (2/14): > dialog-1.2-4.20130523.el7.x86_64.rpm > | 208 kB 00:00:00 > (3/14): > certbot-0.9.3-1.el7.noarch.rpm > | 16 kB 00:00:00 > (4/14): > python-parsedatetime-1.5-3.el7.noarch.rpm > | 61 kB 00:00:00 > (5/14): > python-psutil-2.2.1-1.el7.x86_64.rpm > | 114 kB 00:00:00 > (6/14): > python-zope-component-4.1.0-1.el7.noarch.rpm > | 110 kB 00:00:00 > (7/14): > python-zope-interface-4.0.5-4.el7.x86_64.rpm > | 138 kB 00:00:00 > (8/14): > python-zope-event-4.0.3-2.el7.noarch.rpm > | 79 kB 00:00:00 > (9/14): > python2-certbot-0.9.3-1.el7.noarch.rpm > | 361 kB 00:00:00 > (10/14): > python2-configargparse-0.10.0-1.el7.noarch.rpm > | 28 kB 00:00:00 > (11/14): > python2-acme-0.9.3-1.el7.noarch.rpm > | 168 kB 00:00:00 > (12/14): > python2-dialog-3.3.0-6.el7.noarch.rpm > | 94 kB 00:00:00 > (13/14): > python2-pyrfc3339-1.0-2.el7.noarch.rpm > | 13 kB 00:00:00 > (14/14): > python2-mock-1.0.1-9.el7.noarch.rpm > | 92 kB 00:00:00 > > ----------------------------------------------------------------------------------------------------------------------------- > Total > 1.3 MB/s | 1.5 MB 00:00:01 > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Installing : > python-zope-interface-4.0.5-4.el7.x86_64 > 1/14 > Installing : > python2-mock-1.0.1-9.el7.noarch > 2/14 > Installing : > python-parsedatetime-1.5-3.el7.noarch > 3/14 > Installing : > python-psutil-2.2.1-1.el7.x86_64 > 4/14 > Installing : > python-zope-event-4.0.3-2.el7.noarch > 5/14 > Installing : > 1:python-zope-component-4.1.0-1.el7.noarch > 6/14 > Installing : > python-ndg_httpsclient-0.3.2-1.el7.noarch > 7/14 > Installing : > python2-pyrfc3339-1.0-2.el7.noarch > 8/14 > Installing : > python2-acme-0.9.3-1.el7.noarch > 9/14 > Installing : > python2-configargparse-0.10.0-1.el7.noarch > 10/14 > Installing : > dialog-1.2-4.20130523.el7.x86_64 > 11/14 > Installing : > python2-dialog-3.3.0-6.el7.noarch > 12/14 > Installing : > python2-certbot-0.9.3-1.el7.noarch > 13/14 > Installing : > certbot-0.9.3-1.el7.noarch > 14/14 > Verifying : > dialog-1.2-4.20130523.el7.x86_64 > 1/14 > Verifying : > certbot-0.9.3-1.el7.noarch > 2/14 > Verifying : > python2-configargparse-0.10.0-1.el7.noarch > 3/14 > Verifying : > python2-pyrfc3339-1.0-2.el7.noarch > 4/14 > Verifying : > python-zope-interface-4.0.5-4.el7.x86_64 > 5/14 > Verifying : > python-ndg_httpsclient-0.3.2-1.el7.noarch > 6/14 > Verifying : > python-zope-event-4.0.3-2.el7.noarch > 7/14 > Verifying : > python-psutil-2.2.1-1.el7.x86_64 > 8/14 > Verifying : > python2-acme-0.9.3-1.el7.noarch > 9/14 > Verifying : > python2-dialog-3.3.0-6.el7.noarch > 10/14 > Verifying : > 1:python-zope-component-4.1.0-1.el7.noarch > 11/14 > Verifying : > python-parsedatetime-1.5-3.el7.noarch > 12/14 > Verifying : > python2-certbot-0.9.3-1.el7.noarch > 13/14 > Verifying : > python2-mock-1.0.1-9.el7.noarch > 14/14 > > Installed: > certbot.noarch > 0:0.9.3-1.el7 > > > Dependency Installed: > dialog.x86_64 0:1.2-4.20130523.el7 > python-ndg_httpsclient.noarch 0:0.3.2-1.el7 > python-parsedatetime.noarch 0:1.5-3.el7 > python-psutil.x86_64 0:2.2.1-1.el7 > python-zope-component.noarch 1:4.1.0-1.el7 > python-zope-event.noarch 0:4.0.3-2.el7 > python-zope-interface.x86_64 0:4.0.5-4.el7 > python2-acme.noarch 0:0.9.3-1.el7 > python2-certbot.noarch 0:0.9.3-1.el7 > python2-configargparse.noarch 0:0.10.0-1.el7 > python2-dialog.noarch 0:3.3.0-6.el7 > python2-mock.noarch 0:1.0.1-9.el7 > python2-pyrfc3339.noarch 0:1.0-2.el7 > > Complete! > [jjflynn22 at ipa-1 .ssh]$ > [jjflynn22 at ipa-1 .ssh]$ > [jjflynn22 at ipa-1 .ssh]$ sudo cp -r /etc/httpd/alias > /etc/httpd/alias_backup > [jjflynn22 at ipa-1 .ssh]$ cd ~ > [jjflynn22 at ipa-1 ~]$ git clone > https://github.com/freeipa/freeipa-letsencrypt.git > Cloning into 'freeipa-letsencrypt'... > remote: Counting objects: 45, done. > remote: Compressing objects: 100% (4/4), done. > remote: Total 45 (delta 0), reused 0 (delta 0), pack-reused 41 > Unpacking objects: 100% (45/45), done. > [jjflynn22 at ipa-1 ~]$ sudo cp -r freeipa-letsencrypt /root/ipa-le > [jjflynn22 at ipa-1 ~]$ sudo vi /root/ipa-le/renew-le.sh > [jjflynn22 at ipa-1 ~]$ sudo yum install -y dnf > Loaded plugins: fastestmirror, langpacks > Loading mirror speeds from cached hostfile > * base: repo1.ash.innoscale.net > * epel: mirror.cogentco.com > * extras: mirrors.advancedhosters.com > * updates: mirror.cs.vt.edu > Resolving Dependencies > --> Running transaction check > ---> Package dnf.noarch 0:0.6.4-2.el7 will be installed > --> Processing Dependency: python-dnf = 0.6.4-2.el7 for package: > dnf-0.6.4-2.el7.noarch > --> Running transaction check > ---> Package python-dnf.noarch 0:0.6.4-2.el7 will be installed > --> Processing Dependency: dnf-conf = 0.6.4-2.el7 for package: > python-dnf-0.6.4-2.el7.noarch > --> Processing Dependency: python-librepo >= 1.7.5 for package: > python-dnf-0.6.4-2.el7.noarch > --> Processing Dependency: python-libcomps >= 0.1.6 for package: > python-dnf-0.6.4-2.el7.noarch > --> Processing Dependency: python-hawkey >= 0.5.3 for package: > python-dnf-0.6.4-2.el7.noarch > --> Running transaction check > ---> Package dnf-conf.noarch 0:0.6.4-2.el7 will be installed > ---> Package python-hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 will be > installed > --> Processing Dependency: hawkey(x86-64) = 0.5.8-2.git.0.202b194.el7 for > package: python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > --> Processing Dependency: libsolv.so.0(SOLV_1.0)(64bit) for package: > python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > --> Processing Dependency: libsolv.so.0()(64bit) for package: > python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > --> Processing Dependency: libhawkey.so.2()(64bit) for package: > python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > ---> Package python-libcomps.x86_64 0:0.1.6-13.el7 will be installed > --> Processing Dependency: libcomps(x86-64) = 0.1.6-13.el7 for package: > python-libcomps-0.1.6-13.el7.x86_64 > --> Processing Dependency: libcomps.so.0.1.6()(64bit) for package: > python-libcomps-0.1.6-13.el7.x86_64 > ---> Package python-librepo.x86_64 0:1.7.16-1.el7 will be installed > --> Processing Dependency: librepo(x86-64) = 1.7.16-1.el7 for package: > python-librepo-1.7.16-1.el7.x86_64 > --> Processing Dependency: librepo.so.0()(64bit) for package: > python-librepo-1.7.16-1.el7.x86_64 > --> Running transaction check > ---> Package hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 will be installed > ---> Package libcomps.x86_64 0:0.1.6-13.el7 will be installed > ---> Package librepo.x86_64 0:1.7.16-1.el7 will be installed > ---> Package libsolv.x86_64 0:0.6.11-1.el7 will be installed > --> Finished Dependency Resolution > > Dependencies Resolved > > > ============================================================================================================================= > Package Arch > Version Repository Size > > ============================================================================================================================= > Installing: > dnf noarch > 0.6.4-2.el7 epel 209 k > Installing for dependencies: > dnf-conf noarch > 0.6.4-2.el7 epel 61 k > hawkey x86_64 > 0.5.8-2.git.0.202b194.el7 base 87 k > libcomps x86_64 > 0.1.6-13.el7 epel 72 k > librepo x86_64 > 1.7.16-1.el7 base 77 k > libsolv x86_64 > 0.6.11-1.el7 base 316 k > python-dnf noarch > 0.6.4-2.el7 epel 407 k > python-hawkey x86_64 > 0.5.8-2.git.0.202b194.el7 base 71 k > python-libcomps x86_64 > 0.1.6-13.el7 epel 44 k > python-librepo x86_64 > 1.7.16-1.el7 base 49 k > > Transaction Summary > > ============================================================================================================================= > Install 1 Package (+9 Dependent packages) > > Total download size: 1.4 M > Installed size: 4.1 M > Downloading packages: > (1/10): > hawkey-0.5.8-2.git.0.202b194.el7.x86_64.rpm > | 87 kB 00:00:00 > (2/10): > dnf-conf-0.6.4-2.el7.noarch.rpm > | 61 kB 00:00:00 > (3/10): > dnf-0.6.4-2.el7.noarch.rpm > | 209 kB 00:00:00 > (4/10): > librepo-1.7.16-1.el7.x86_64.rpm > | 77 kB 00:00:00 > (5/10): > libcomps-0.1.6-13.el7.x86_64.rpm > | 72 kB 00:00:00 > (6/10): > python-librepo-1.7.16-1.el7.x86_64.rpm > | 49 kB 00:00:00 > (7/10): > python-libcomps-0.1.6-13.el7.x86_64.rpm > | 44 kB 00:00:00 > (8/10): > python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64.rpm > | 71 kB 00:00:00 > (9/10): > python-dnf-0.6.4-2.el7.noarch.rpm > | 407 kB 00:00:00 > (10/10): > libsolv-0.6.11-1.el7.x86_64.rpm > | 316 kB 00:00:00 > > ----------------------------------------------------------------------------------------------------------------------------- > Total > 1.4 MB/s | 1.4 MB 00:00:01 > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Installing : > libsolv-0.6.11-1.el7.x86_64 > 1/10 > Installing : > hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > 2/10 > Installing : > python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > 3/10 > Installing : > dnf-conf-0.6.4-2.el7.noarch > 4/10 > Installing : > libcomps-0.1.6-13.el7.x86_64 > 5/10 > Installing : > python-libcomps-0.1.6-13.el7.x86_64 > 6/10 > Installing : > librepo-1.7.16-1.el7.x86_64 > 7/10 > Installing : > python-librepo-1.7.16-1.el7.x86_64 > 8/10 > Installing : > python-dnf-0.6.4-2.el7.noarch > 9/10 > Installing : > dnf-0.6.4-2.el7.noarch > 10/10 > Verifying : > librepo-1.7.16-1.el7.x86_64 > 1/10 > Verifying : > python-libcomps-0.1.6-13.el7.x86_64 > 2/10 > Verifying : > python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > 3/10 > Verifying : > python-librepo-1.7.16-1.el7.x86_64 > 4/10 > Verifying : > python-dnf-0.6.4-2.el7.noarch > 5/10 > Verifying : > libcomps-0.1.6-13.el7.x86_64 > 6/10 > Verifying : > hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > 7/10 > Verifying : > dnf-conf-0.6.4-2.el7.noarch > 8/10 > Verifying : > dnf-0.6.4-2.el7.noarch > 9/10 > Verifying : > libsolv-0.6.11-1.el7.x86_64 > 10/10 > > Installed: > dnf.noarch > 0:0.6.4-2.el7 > > > Dependency Installed: > dnf-conf.noarch 0:0.6.4-2.el7 > hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 > libcomps.x86_64 0:0.1.6-13.el7 > librepo.x86_64 0:1.7.16-1.el7 > libsolv.x86_64 0:0.6.11-1.el7 > python-dnf.noarch 0:0.6.4-2.el7 > python-hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 > python-libcomps.x86_64 0:0.1.6-13.el7 > python-librepo.x86_64 0:1.7.16-1.el7 > > Complete! > [jjflynn22 at ipa-1 ~]$ sudo yum remove -y epel-release > Loaded plugins: fastestmirror, langpacks > Resolving Dependencies > --> Running transaction check > ---> Package epel-release.noarch 0:7-6 will be erased > --> Finished Dependency Resolution > > Dependencies Resolved > > > ============================================================================================================================= > Package Arch > Version Repository Size > > ============================================================================================================================= > Removing: > epel-release noarch > 7-6 @extras 24 k > > Transaction Summary > > ============================================================================================================================= > Remove 1 Package > > Installed size: 24 k > Downloading packages: > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Erasing : > epel-release-7-6.noarch > 1/1 > Verifying : > epel-release-7-6.noarch > 1/1 > > Removed: > epel-release.noarch > 0:7-6 > > > Complete! > [jjflynn22 at ipa-1 ~]$ sudo dnf repolist > CentOS-7 - > Base > 8.4 MB/s | 8.8 MB 00:01 > CentOS-7 - > Updates > 4.5 MB/s | 12 MB 00:02 > CentOS-7 - > Extras > 1.9 MB/s | 569 kB 00:00 > Using metadata from Sun Dec 4 18:06:04 2016 > repo id repo > name status > base CentOS-7 - > Base 9,007 > extras CentOS-7 - > Extras 393 > updates CentOS-7 - > Updates 2,560 > [jjflynn22 at ipa-1 ~]$ sudo /root/ipa-le/setup-le.sh > Using metadata from Sun Dec 4 18:06:04 2016 > Package certbot-0.9.3-1.el7.noarch is already installed, skipping. > Dependencies resolved. > Nothing to do. > Directory Manager password: > > Installing CA certificate, please wait > CA certificate successfully installed > The ipa-cacert-manage command was successful > ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: Not logging to a file > ipa: DEBUG: Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > ipa: DEBUG: importing all plugin modules in ipalib.plugins... > ipa: DEBUG: importing plugin module ipalib.plugins.aci > ipa: DEBUG: importing plugin module ipalib.plugins.automember > ipa: DEBUG: importing plugin module ipalib.plugins.automount > ipa: DEBUG: importing plugin module ipalib.plugins.baseldap > ipa: DEBUG: importing plugin module ipalib.plugins.baseuser > ipa: DEBUG: importing plugin module ipalib.plugins.batch > ipa: DEBUG: importing plugin module ipalib.plugins.caacl > ipa: DEBUG: importing plugin module ipalib.plugins.cert > ipa: DEBUG: importing plugin module ipalib.plugins.certprofile > ipa: DEBUG: importing plugin module ipalib.plugins.config > ipa: DEBUG: importing plugin module ipalib.plugins.delegation > ipa: DEBUG: importing plugin module ipalib.plugins.dns > ipa: DEBUG: importing plugin module ipalib.plugins.domainlevel > ipa: DEBUG: importing plugin module ipalib.plugins.group > ipa: DEBUG: importing plugin module ipalib.plugins.hbacrule > ipa: DEBUG: importing plugin module ipalib.plugins.hbacsvc > ipa: DEBUG: importing plugin module ipalib.plugins.hbacsvcgroup > ipa: DEBUG: importing plugin module ipalib.plugins.hbactest > ipa: DEBUG: importing plugin module ipalib.plugins.host > ipa: DEBUG: importing plugin module ipalib.plugins.hostgroup > ipa: DEBUG: importing plugin module ipalib.plugins.idrange > ipa: DEBUG: importing plugin module ipalib.plugins.idviews > ipa: DEBUG: importing plugin module ipalib.plugins.internal > ipa: DEBUG: importing plugin module ipalib.plugins.kerberos > ipa: DEBUG: importing plugin module ipalib.plugins.krbtpolicy > ipa: DEBUG: importing plugin module ipalib.plugins.migration > ipa: DEBUG: importing plugin module ipalib.plugins.misc > ipa: DEBUG: importing plugin module ipalib.plugins.netgroup > ipa: DEBUG: importing plugin module ipalib.plugins.otpconfig > ipa: DEBUG: importing plugin module ipalib.plugins.otptoken > ipa: DEBUG: importing plugin module ipalib.plugins.otptoken_yubikey > ipa: DEBUG: importing plugin module ipalib.plugins.passwd > ipa: DEBUG: importing plugin module ipalib.plugins.permission > ipa: DEBUG: importing plugin module ipalib.plugins.ping > ipa: DEBUG: importing plugin module ipalib.plugins.pkinit > ipa: DEBUG: importing plugin module ipalib.plugins.privilege > ipa: DEBUG: importing plugin module ipalib.plugins.pwpolicy > ipa: DEBUG: Starting external process > ipa: DEBUG: args='klist' '-V' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=Kerberos 5 version 1.13.2 > > ipa: DEBUG: stderr= > ipa: DEBUG: importing plugin module ipalib.plugins.radiusproxy > ipa: DEBUG: importing plugin module ipalib.plugins.realmdomains > ipa: DEBUG: importing plugin module ipalib.plugins.role > ipa: DEBUG: importing plugin module ipalib.plugins.rpcclient > ipa: DEBUG: importing plugin module ipalib.plugins.selfservice > ipa: DEBUG: importing plugin module ipalib.plugins.selinuxusermap > ipa: DEBUG: importing plugin module ipalib.plugins.server > ipa: DEBUG: importing plugin module ipalib.plugins.service > ipa: DEBUG: importing plugin module ipalib.plugins.servicedelegation > ipa: DEBUG: importing plugin module ipalib.plugins.session > ipa: DEBUG: importing plugin module ipalib.plugins.stageuser > ipa: DEBUG: importing plugin module ipalib.plugins.sudocmd > ipa: DEBUG: importing plugin module ipalib.plugins.sudocmdgroup > ipa: DEBUG: importing plugin module ipalib.plugins.sudorule > ipa: DEBUG: importing plugin module ipalib.plugins.topology > ipa: DEBUG: importing plugin module ipalib.plugins.trust > ipa: DEBUG: importing plugin module ipalib.plugins.user > ipa: DEBUG: importing plugin module ipalib.plugins.vault > ipa: DEBUG: importing plugin module ipalib.plugins.virtual > ipa: DEBUG: Initializing principal host/ipa-1.kkgpitt.org at KKGPITT.ORG > using keytab /etc/krb5.keytab > ipa: DEBUG: using ccache /tmp/tmp-zgrScg/ccache > ipa: DEBUG: Attempt 1/1: success > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:host/ > ipa-1.kkgpitt.org at KKGPITT.ORG' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=134111920 > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'pipe' '134111920' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=ipa_session=59c01d94b52f0586e30046bd36ef93a5; Domain= > ipa-1.kkgpitt.org; Path=/ipa; Expires=Sun, 04 Dec 2016 23:21:13 GMT; > Secure; HttpOnly > ipa: DEBUG: stderr= > ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: found session_cookie in > persistent storage for principal 'host/ipa-1.kkgpitt.org at KKGPITT.ORG', > cookie: 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; Domain= > ipa-1.kkgpitt.org; Path=/ipa; Expires=Sun, 04 Dec 2016 23:21:13 GMT; > Secure; HttpOnly' > ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: setting session_cookie into > context 'ipa_session=59c01d94b52f0586e30046bd36ef93a5;' > ipa.ipalib.plugins.rpcclient.rpcclient: INFO: trying > https://ipa-1.kkgpitt.org/ipa/session/json > ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: Created connection > context.rpcclient_71021840 > ipa.ipalib.plugins.rpcclient.rpcclient: INFO: Forwarding 'ca_is_enabled' > to json server 'https://ipa-1.kkgpitt.org/ipa/session/json' > ipa: DEBUG: NSSConnection init ipa-1.kkgpitt.org > ipa: DEBUG: Connecting: 192.168.1.201:0 > ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server > ipa: DEBUG: cert valid True for "CN=ipa-1.kkgpitt.org,O=KKGPITT.ORG" > ipa: DEBUG: handshake complete, peer = 192.168.1.201:443 > ipa: DEBUG: Protocol: TLS1.2 > ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_256_CBC_SHA > ipa: DEBUG: received Set-Cookie > 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; Domain=ipa-1.kkgpitt.org; > Path=/ipa; Expires=Sun, 04 Dec 2016 23:26:28 GMT; Secure; HttpOnly' > ipa: DEBUG: storing cookie 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; > Domain=ipa-1.kkgpitt.org; Path=/ipa; Expires=Sun, 04 Dec 2016 23:26:28 > GMT; Secure; HttpOnly' for principal host/ipa-1.kkgpitt.org at KKGPITT.ORG > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:host/ > ipa-1.kkgpitt.org at KKGPITT.ORG' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=134111920 > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:host/ > ipa-1.kkgpitt.org at KKGPITT.ORG' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=134111920 > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'pupdate' '134111920' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: Destroyed connection > context.rpcclient_71021840 > ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing ldap:// > ipa-1.kkgpitt.org:389 from SchemaCache > ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for > SchemaCache url=ldap://ipa-1.kkgpitt.org:389 > conn= > ipa: DEBUG: Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-KKGPITT-ORG' > '-A' '-n' 'KKGPITT.ORG IPA CA' '-t' 'CT,C,C' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-KKGPITT-ORG' > '-A' '-n' 'DSTRootCAX3' '-t' 'C,,' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'is-active' 'dirsrv at KKGPITT-ORG.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=active > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' '--system' 'daemon-reload' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'restart' 'dirsrv at KKGPITT-ORG.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'is-active' 'dirsrv at KKGPITT-ORG.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=active > > ipa: DEBUG: stderr= > ipa: DEBUG: wait_for_open_ports: localhost [389] timeout 300 > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/httpd/alias' '-A' '-n' ' > KKGPITT.ORG IPA CA' '-t' 'CT,C,C' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/httpd/alias' '-A' '-n' > 'DSTRootCAX3' '-t' 'C,,' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'is-active' 'httpd.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=active > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'restart' 'httpd.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'is-active' 'httpd.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=active > > ipa: DEBUG: stderr= > ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: resubmitting certmonger > request '20161204225818' > ipa: DEBUG: certmonger request is in state dbus.String(u'GENERATING_CSR', > variant_level=1) > ipa: DEBUG: certmonger request is in state dbus.String(u'PRE_SAVE_CERT', > variant_level=1) > ipa: DEBUG: certmonger request is in state dbus.String(u'POST_SAVED_CERT', > variant_level=1) > ipa: DEBUG: certmonger request is in state dbus.String(u'POST_SAVED_CERT', > variant_level=1) > ipa: DEBUG: certmonger request is in state dbus.String(u'POST_SAVED_CERT', > variant_level=1) > ipa: DEBUG: certmonger request is in state dbus.String(u'MONITORING', > variant_level=1) > ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: modifying certmonger > request '20161204225818' > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > KKGPITT.ORG IPA CA CT,C,C > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-L' '-n' ' > KKGPITT.ORG IPA CA' '-a' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=-----BEGIN CERTIFICATE----- > MIIDjTCCAnWgAwIBAgIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtLS0dQ > SVRULk9SRzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MTIw > NDIyNTczNFoXDTM2MTIwNDIyNTczNFowNjEUMBIGA1UECgwLS0tHUElUVC5PUkcx > HjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEB > . . > BYuURWnoNBd110T0HFOnMOmN5ycnsMvCwCdUFuFKCsjNjCm5/oUCsWSVlad2bzlj > 7gvnv3d6YmXwTzpOlOHpMu/S7y+JU5ErM9fp97R/vUvBz/7CM0MOKBgXMvfKTu6X > PTROdl8lKofxA6TMvM+du020+o79dami0hWV/3cRN386huTDcWVn9gbud6hxX8U5 > StsgHtJLlrm4tjLk8+S5VTDu9Y6EX7OsEX51RHwtrfNjEYdCa68AM2/slxdgf+5S > IQ== > -----END CERTIFICATE----- > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-D' '-n' ' > KKGPITT.ORG IPA CA' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-L' '-n' ' > KKGPITT.ORG IPA CA' '-a' > ipa: DEBUG: Process finished, return code=255 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=certutil: Could not find cert: KKGPITT.ORG IPA CA > : PR_FILE_NOT_FOUND_ERROR: File not found > > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L' '-n' 'IPA > CA' '-a' > ipa: DEBUG: Process finished, return code=255 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA > : PR_FILE_NOT_FOUND_ERROR: File not found > > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L' '-n' > 'External CA cert' '-a' > ipa: DEBUG: Process finished, return code=255 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert > : PR_FILE_NOT_FOUND_ERROR: File not found > > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-A' '-n' ' > KKGPITT.ORG IPA CA' '-t' 'CT,C,C' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-A' '-n' > 'DSTRootCAX3' '-t' 'C,,' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-A' '-n' ' > KKGPITT.ORG IPA CA' '-t' 'CT,C,C' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-A' '-n' > 'DSTRootCAX3' '-t' 'C,,' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/update-ca-trust' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: INFO: Systemwide CA database updated. > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/update-ca-trust' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: INFO: Systemwide CA database updated. > ipa.ipaclient.ipa_certupdate.CertUpdate: INFO: The ipa-certupdate command > was successful > Directory Manager password: > > Installing CA certificate, please wait > Not a valid CA certificate: (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate > issuer is not recognized. (visit > http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) > [jjflynn22 at ipa-1 ~]$ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Mon Dec 5 12:05:13 2016 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 05 Dec 2016 12:05:13 +0000 Subject: [Freeipa-users] Directory Manager Password Change Message-ID: Hi All, I have been testing FreeIPA and now plan to migrate to production use - thanks for creating such a great application! During the test phase we have been using simple passwords for the admin and directory manager users however we need these changed before moving into production. I believe we can change the admin password using the web interface however as I understand it amending the directory manager password is not so straightforward. I have found this link https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password however I am unsure if this is the correct procedure for our installation - certainly i am having no luck so far. We have the following setup: FreeIPA 4.2.0 - single master server (no replicas), multiple clients CentOS 7.2 I have tried the following steps in order: http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html followed by https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password After completing that I am no longer able to authenticate user logins. The below covers my current situation: This works: ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" "objectclass=*" This does not work: ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" "objectclass=*" This works: ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" -W -b "" -s base OLDPASSWORD This does not work: ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" -W -b "" -s base NEWPASSWORD So i'm i a mixed up state! Is anyone able to offer advise on resolving this issue? Thank you, 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 flo at redhat.com Mon Dec 5 13:08:52 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Mon, 5 Dec 2016 14:08:52 +0100 Subject: [Freeipa-users] Directory Manager Password Change In-Reply-To: References: Message-ID: <7783a1de-0924-250c-c057-7601f8724af6@redhat.com> On 12/05/2016 01:05 PM, Callum Guy wrote: > Hi All, > > I have been testing FreeIPA and now plan to migrate to production use - > thanks for creating such a great application! > > During the test phase we have been using simple passwords for the admin > and directory manager users however we need these changed before moving > into production. I believe we can change the admin password using the > web interface however as I understand it amending the directory manager > password is not so straightforward. > > I have found this > link https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password however > I am unsure if this is the correct procedure for our installation - > certainly i am having no luck so far. > > We have the following setup: > > FreeIPA 4.2.0 - single master server (no replicas), multiple clients > CentOS 7.2 > > I have tried the following steps in order: > > http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html > followed by > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > After completing that I am no longer able to authenticate user logins. > The below covers my current situation: > > This works: > ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" > "objectclass=*" > > This does not work: > ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" > "objectclass=*" > > This works: > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > -W -b "" -s base > OLDPASSWORD > > This does not work: > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > -W -b "" -s base > NEWPASSWORD > Hi, your commands show that the Directory Manager password was properly modified, but not admin's password. Did you run the step 3 Updating PKI admin password of the procedure [1]? ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W -T /root/dm_password "uid=admin,ou=people,o=ipaca" Flo. [1] https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password > So i'm i a mixed up state! Is anyone able to offer advise on resolving > this issue? > > Thank you, > > 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. > > > From callum.guy at x-on.co.uk Mon Dec 5 13:37:48 2016 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 05 Dec 2016 13:37:48 +0000 Subject: [Freeipa-users] Directory Manager Password Change In-Reply-To: <7783a1de-0924-250c-c057-7601f8724af6@redhat.com> References: <7783a1de-0924-250c-c057-7601f8724af6@redhat.com> Message-ID: Hi Flo, I have indeed executed every step in order, including the one you have indicated. The password I has used included a dollar sign and this meant that echo -n $DM_PASSWORD > /root/dm_password didn't work as I had expected meaning everything after the dollar was interpreted as a variable and was missing in the file. I have corrected this and performed the full process again, starting with the 389 reset however it is still not working correctly. I remain in the same state as before where the admin password has not been changed - this confuses me as my understanding is that admin only exists as the FreeIPA web admin user whose password I can change separately. Am i misunderstanding, is there another admin user within FreeIPA which is directly linked to the directory manager? Having run out of ideas I have just executed ipa-server-upgrade however this hasn't helped. My situation remains as follows: *Works:* ldapsearch -x -D "cn=directory manager" -w *NEW_DM_PW *-s base -b "" "objectclass=*" *Fails: *ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" -w *NEW_DM_PW *-b "" -s base Are you able to offer any other ideas? Other information: I can confirm that cacert.p12 has been updated by the actions performed. File /etc/pki/pki-tomcat/password.conf now contains a new line internaldb= *NEW_DM_PW *(as per instruction 1 on FreeIPA link) Best Regards, Callum On Mon, Dec 5, 2016 at 1:08 PM Florence Blanc-Renaud wrote: > On 12/05/2016 01:05 PM, Callum Guy wrote: > > Hi All, > > > > I have been testing FreeIPA and now plan to migrate to production use - > > thanks for creating such a great application! > > > > During the test phase we have been using simple passwords for the admin > > and directory manager users however we need these changed before moving > > into production. I believe we can change the admin password using the > > web interface however as I understand it amending the directory manager > > password is not so straightforward. > > > > I have found this > > link > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > however > > I am unsure if this is the correct procedure for our installation - > > certainly i am having no luck so far. > > > > We have the following setup: > > > > FreeIPA 4.2.0 - single master server (no replicas), multiple clients > > CentOS 7.2 > > > > I have tried the following steps in order: > > > > > http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html > > followed by > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > > > After completing that I am no longer able to authenticate user logins. > > The below covers my current situation: > > > > This works: > > ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" > > "objectclass=*" > > > > This does not work: > > ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" > > "objectclass=*" > > > > This works: > > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > > -W -b "" -s base > > OLDPASSWORD > > > > This does not work: > > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > > -W -b "" -s base > > NEWPASSWORD > > > Hi, > > your commands show that the Directory Manager password was properly > modified, but not admin's password. Did you run the step 3 Updating PKI > admin password of the procedure [1]? > ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W > -T /root/dm_password "uid=admin,ou=people,o=ipaca" > > Flo. > > [1] > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password > > > So i'm i a mixed up state! Is anyone able to offer advise on resolving > > this issue? > > > > Thank you, > > > > 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 <+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. > > > > > > > > -- *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 suygur at firstderivatives.com Mon Dec 5 14:48:24 2016 From: suygur at firstderivatives.com (Stefan Uygur) Date: Mon, 5 Dec 2016 14:48:24 +0000 Subject: [Freeipa-users] Directory Manager Password Change In-Reply-To: References: <7783a1de-0924-250c-c057-7601f8724af6@redhat.com> Message-ID: <38C784D32FB4354DAED01CCB1BB5053517561A22@mail01.firstderivatives.com> Hi, I think you are copying and pasting the exact same commands from the article, which is of course a wrong approach. Never copy/paste from web to execute on your server. That $ signs indicates you can give any name you?d like. Follow this article here: https://access.redhat.com/solutions/308623 Stefan From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Callum Guy Sent: 05 December 2016 13:38 To: Florence Blanc-Renaud; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Directory Manager Password Change Hi Flo, I have indeed executed every step in order, including the one you have indicated. The password I has used included a dollar sign and this meant that echo -n $DM_PASSWORD > /root/dm_password didn't work as I had expected meaning everything after the dollar was interpreted as a variable and was missing in the file. I have corrected this and performed the full process again, starting with the 389 reset however it is still not working correctly. I remain in the same state as before where the admin password has not been changed - this confuses me as my understanding is that admin only exists as the FreeIPA web admin user whose password I can change separately. Am i misunderstanding, is there another admin user within FreeIPA which is directly linked to the directory manager? Having run out of ideas I have just executed ipa-server-upgrade however this hasn't helped. My situation remains as follows: Works: ldapsearch -x -D "cn=directory manager" -w NEW_DM_PW -s base -b "" "objectclass=*" Fails: ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" -w NEW_DM_PW -b "" -s base Are you able to offer any other ideas? Other information: I can confirm that cacert.p12 has been updated by the actions performed. File /etc/pki/pki-tomcat/password.conf now contains a new line internaldb=NEW_DM_PW (as per instruction 1 on FreeIPA link) Best Regards, Callum On Mon, Dec 5, 2016 at 1:08 PM Florence Blanc-Renaud > wrote: On 12/05/2016 01:05 PM, Callum Guy wrote: > Hi All, > > I have been testing FreeIPA and now plan to migrate to production use - > thanks for creating such a great application! > > During the test phase we have been using simple passwords for the admin > and directory manager users however we need these changed before moving > into production. I believe we can change the admin password using the > web interface however as I understand it amending the directory manager > password is not so straightforward. > > I have found this > link https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password however > I am unsure if this is the correct procedure for our installation - > certainly i am having no luck so far. > > We have the following setup: > > FreeIPA 4.2.0 - single master server (no replicas), multiple clients > CentOS 7.2 > > I have tried the following steps in order: > > http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html > followed by > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > After completing that I am no longer able to authenticate user logins. > The below covers my current situation: > > This works: > ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" > "objectclass=*" > > This does not work: > ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" > "objectclass=*" > > This works: > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > -W -b "" -s base > OLDPASSWORD > > This does not work: > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > -W -b "" -s base > NEWPASSWORD > Hi, your commands show that the Directory Manager password was properly modified, but not admin's password. Did you run the step 3 Updating PKI admin password of the procedure [1]? ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W -T /root/dm_password "uid=admin,ou=people,o=ipaca" Flo. [1] https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password > So i'm i a mixed up state! Is anyone able to offer advise on resolving > this issue? > > Thank you, > > 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. > > > [http://www.x-on.co.uk/email/footer/banner-x-on.jpg] 0333 332 0000 | www.x-on.co.uk | [http://www.x-on.co.uk/images/icon/linkedin.png] [http://www.x-on.co.uk/images/icon/facebook.png] [http://www.x-on.co.uk/images/icon/twitter.png] 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 tkrizek at redhat.com Mon Dec 5 15:35:07 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Mon, 5 Dec 2016 16:35:07 +0100 Subject: [Freeipa-users] Let's Encrypt along with FreeIPA In-Reply-To: References: Message-ID: <608a680e-0761-1984-733a-f6a6cbd2600a@redhat.com> On 12/05/2016 12:25 AM, Joseph Flynn wrote: > Sorry if this is not the appropriate forum for discussing this topic. > > I have installed a FreeIPA system on CentOS 7 and am trying to get the > Let's Encrypt scripts to work as defined in > https://github.com/freeipa/freeipa-letsencrypt > > I hand to tinker with a combination of enabling/disabling EPEL and > this new tool DNF that I am not too familiar with but eventually got > the script to run. > > It is ending with the following error: > > ipa: INFO: Systemwide CA database updated. > ipa.ipaclient.ipa_certupdate.CertUpdate: INFO: The ipa-certupdate > command was successful > Directory Manager password: > > Installing CA certificate, please wait > Not a valid CA certificate: (SEC_ERROR_UNKNOWN_ISSUER) Peer's > Certificate issuer is not recognized. (visit > http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) > > > Does anyone recognize this situation? > > I have installed this on a VirtualBox client in Bridge Network mode. > Prior to trying to use a real certificate, I could access the FreeIPA > UI from Firefox on both the VM and other computers in the home. I've > gotten a domain name and have that domain name pointed to my home > router with a handful of ports (those listed at the end of the FreeIPA > install) forwarded to my VM. > > For completeness, I have included the history below along with the > full output including a couple of highlighted areas that could be errors. > > Thanks for any assistance from anyone who might notice an error in my > ways. > Joe > > > History: > 1 ifconfig -a > 2 sudo yum -y update > 3 cat /etc/hostname > 4 sudo echo 192.168.1.201 ipa-1.kkgpitt.org > ipa-1 >> /etc/hosts > 5 sudo vi /etc/hosts > 7 sudo reboot now > 8 hostname > 9 ifconfig -a > 11 sudo visudo > 12 sudo ls # just to set pw > 13 sudo yum install epel-release -y > 14 sudo yum install -y haveged > 15 sudo systemctl start haveged.service > 16 sudo ipa-server-install > 17 kinit admin > 18 firewall-cmd --permanent --add-service=ntp > 19 firewall-cmd --permanent --add-service=http > 20 firewall-cmd --permanent --add-service=https > 21 firewall-cmd --permanent --add-service=ldap > 22 firewall-cmd --permanent --add-service=ldaps > 23 firewall-cmd --permanent --add-service=kerberos > 24 firewall-cmd --permanent --add-service=kpasswd > 26 sudo authconfig --enablemkhomedir --update > 27 sudo chkconfig sssd on > 28 git config --global user.name "Joe Flynn" > 29 git config --global user.email "jjflynn22 at gmail.com > " > 30 mkdir ~/.ssh > 31 cd ~/.ssh > 32 vi id_rsa > 33 vi id_rsa.pub > 34 chmod 700 ~/.ssh > 35 chmod 600 ~/.ssh/* > 36 ssh-add ~/.ssh/id_rsa > 37 sudo yum install -y letsencrypt > 38 sudo cp -r /etc/httpd/alias /etc/httpd/alias_backup > 39 cd ~ > 40 git clone https://github.com/freeipa/freeipa-letsencrypt.git > 41 sudo cp -r freeipa-letsencrypt /root/ipa-le > 42 sudo vi /root/ipa-le/renew-le.sh > 43 sudo yum install -y dnf > 44 sudo yum remove -y epel-release > 45 sudo dnf repolist > 46 sudo /root/ipa-le/setup-le.sh > 47 history > > > > [jjflynn22 at ipa-1 ~]$ sudo visudo > [sudo] password for jjflynn22: > [jjflynn22 at ipa-1 ~]$ sudo yum install epel-release -y > Loaded plugins: fastestmirror, langpacks > base | 3.6 kB 00:00:00 > extras | 3.4 kB 00:00:00 > updates | 3.4 kB 00:00:00 > Loading mirror speeds from cached hostfile > * base: repo1.ash.innoscale.net > * extras: mirrors.advancedhosters.com > > * updates: mirror.cs.vt.edu > Resolving Dependencies > --> Running transaction check > ---> Package epel-release.noarch 0:7-6 will be installed > --> Finished Dependency Resolution > > Dependencies Resolved > > ============================================================================================================================= > Package Arch Version > Repository Size > ============================================================================================================================= > Installing: > epel-release noarch 7-6 > extras 14 k > > Transaction Summary > ============================================================================================================================= > Install 1 Package > > Total download size: 14 k > Installed size: 24 k > Downloading packages: > epel-release-7-6.noarch.rpm | 14 kB 00:00:00 > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Installing : epel-release-7-6.noarch 1/1 > Verifying : epel-release-7-6.noarch 1/1 > > Installed: > epel-release.noarch 0:7-6 > > Complete! > [jjflynn22 at ipa-1 ~]$ sudo yum install -y haveged > Loaded plugins: fastestmirror, langpacks > epel/x86_64/metalink | 13 kB 00:00:00 > epel | 4.3 kB 00:00:00 > (1/3): epel/x86_64/updateinfo | 676 kB 00:00:00 > (2/3): epel/x86_64/group_gz | 170 kB 00:00:00 > (3/3): epel/x86_64/primary_db | 4.4 MB 00:00:01 > Loading mirror speeds from cached hostfile > * base: repo1.ash.innoscale.net > * epel: ftp.osuosl.org > * extras: mirror.fusioncloud.co > * updates: ftp.osuosl.org > Resolving Dependencies > --> Running transaction check > ---> Package haveged.x86_64 0:1.9.1-1.el7 will be installed > --> Finished Dependency Resolution > > Dependencies Resolved > > ============================================================================================================================= > Package Arch Version Repository Size > ============================================================================================================================= > Installing: > haveged x86_64 1.9.1-1.el7 epel 61 k > > Transaction Summary > ============================================================================================================================= > Install 1 Package > > Total download size: 61 k > Installed size: 181 k > Downloading packages: > warning: > /var/cache/yum/x86_64/7/epel/packages/haveged-1.9.1-1.el7.x86_64.rpm: > Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY > Public key for haveged-1.9.1-1.el7.x86_64.rpm is not installed > haveged-1.9.1-1.el7.x86_64.rpm | 61 kB 00:00:00 > Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 > Importing GPG key 0x352C64E5: > Userid : "Fedora EPEL (7) >" > Fingerprint: 91e9 7d7c 4a5e 96f1 7f3e 888f 6a2f aea2 352c 64e5 > Package : epel-release-7-6.noarch (@extras) > From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Installing : haveged-1.9.1-1.el7.x86_64 1/1 > Verifying : haveged-1.9.1-1.el7.x86_64 1/1 > > Installed: > haveged.x86_64 0:1.9.1-1.el7 > > Complete! > [jjflynn22 at ipa-1 ~]$ sudo systemctl start haveged.service > [jjflynn22 at ipa-1 ~]$ > [jjflynn22 at ipa-1 ~]$ > [jjflynn22 at ipa-1 ~]$ > [jjflynn22 at ipa-1 ~]$ > [jjflynn22 at ipa-1 ~]$ sudo ipa-server-install > > The log file for this installation can be found in > /var/log/ipaserver-install.log > ============================================================================== > This program will set up the IPA Server. > > This includes: > * Configure a stand-alone CA (dogtag) for certificate management > * Configure the Network Time Daemon (ntpd) > * Create and configure an instance of Directory Server > * Create and configure a Kerberos Key Distribution Center (KDC) > * Configure Apache (httpd) > > To accept the default shown in brackets, press the Enter key. > > WARNING: conflicting time&date synchronization service 'chronyd' > will be disabled > in favor of ntpd > > Do you want to configure integrated DNS (BIND)? [no]: > > Enter the fully qualified domain name of the computer > on which you're setting up server software. Using the form > . > Example: master.example.com . > > > Server host name [ipa-1.kkgpitt.org ]: > > The domain name has been determined based on the host name. > > Please confirm the domain name [kkgpitt.org ]: > > The kerberos protocol requires a Realm name to be defined. > This is typically the domain name converted to uppercase. > > Please provide a realm name [KKGPITT.ORG ]: > Certain directory server operations require an administrative user. > This user is referred to as the Directory Manager and has full access > to the Directory for system management tasks and will be added to the > instance of directory server created for IPA. > The password must be at least 8 characters long. > > Directory Manager password: > Password (confirm): > > The IPA server requires an administrative user, named 'admin'. > This user is a regular system account used for IPA server > administration. > > IPA admin password: > Password (confirm): > > > The IPA Master Server will be configured with: > Hostname: ipa-1.kkgpitt.org > IP address(es): 192.168.1.201 > Domain name: kkgpitt.org > Realm name: KKGPITT.ORG > > Continue to configure the system with these values? [no]: yes > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv). Estimated time: 1 minute > [1/42]: creating directory server user > [2/42]: creating directory server instance > [3/42]: adding default schema > [4/42]: enabling memberof plugin > [5/42]: enabling winsync plugin > [6/42]: configuring replication version plugin > [7/42]: enabling IPA enrollment plugin > [8/42]: enabling ldapi > [9/42]: configuring uniqueness plugin > [10/42]: configuring uuid plugin > [11/42]: configuring modrdn plugin > [12/42]: configuring DNS plugin > [13/42]: enabling entryUSN plugin > [14/42]: configuring lockout plugin > [15/42]: creating indices > [16/42]: enabling referential integrity plugin > [17/42]: configuring certmap.conf > [18/42]: configure autobind for root > [19/42]: configure new location for managed entries > [20/42]: configure dirsrv ccache > [21/42]: enable SASL mapping fallback > [22/42]: restarting directory server > [23/42]: adding default layout > [24/42]: adding delegation layout > [25/42]: creating container for managed entries > [26/42]: configuring user private groups > [27/42]: configuring netgroups from hostgroups > [28/42]: creating default Sudo bind user > [29/42]: creating default Auto Member layout > [30/42]: adding range check plugin > [31/42]: creating default HBAC rule allow_all > [32/42]: adding entries for topology management > [33/42]: initializing group membership > [34/42]: adding master entry > [35/42]: initializing domain level > [36/42]: configuring Posix uid/gid generation > [37/42]: adding replication acis > [38/42]: enabling compatibility plugin > [39/42]: activating sidgen plugin > [40/42]: activating extdom plugin > [41/42]: tuning directory server > [42/42]: configuring directory to start on boot > Done configuring directory server (dirsrv). > Configuring certificate server (pki-tomcatd). Estimated time: 3 > minutes 30 seconds > [1/28]: creating certificate server user > [2/28]: configuring certificate server instance > [3/28]: stopping certificate server instance to update CS.cfg > [4/28]: backing up CS.cfg > [5/28]: disabling nonces > [6/28]: set up CRL publishing > [7/28]: enable PKIX certificate path discovery and validation > [8/28]: starting certificate server instance > [9/28]: creating RA agent certificate database > [10/28]: importing CA chain to RA certificate database > [11/28]: fixing RA database permissions > [12/28]: setting up signing cert profile > [13/28]: setting audit signing renewal to 2 years > [14/28]: restarting certificate server > [15/28]: requesting RA certificate from CA > [16/28]: issuing RA agent certificate > [17/28]: adding RA agent as a trusted user > [18/28]: authorizing RA to modify profiles > [19/28]: configure certmonger for renewals > [20/28]: configure certificate renewals > [21/28]: configure RA certificate renewal > [22/28]: configure Server-Cert certificate renewal > [23/28]: Configure HTTP to proxy connections > [24/28]: restarting certificate server > [25/28]: migrating certificate profiles to LDAP > [26/28]: importing IPA certificate profiles > [27/28]: adding default CA ACL > [28/28]: updating IPA configuration > Done configuring certificate server (pki-tomcatd). > Configuring directory server (dirsrv). Estimated time: 10 seconds > [1/3]: configuring ssl for ds instance > [2/3]: restarting directory server > [3/3]: adding CA certificate entry > Done configuring directory server (dirsrv). > Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds > [1/10]: adding sasl mappings to the directory > [2/10]: adding kerberos container to the directory > [3/10]: configuring KDC > [4/10]: initialize kerberos container > [5/10]: adding default ACIs > [6/10]: creating a keytab for the directory > [7/10]: creating a keytab for the machine > [8/10]: adding the password extension to the directory > [9/10]: starting the KDC > [10/10]: configuring KDC to start on boot > Done configuring Kerberos KDC (krb5kdc). > Configuring kadmin > [1/2]: starting kadmin > [2/2]: configuring kadmin to start on boot > Done configuring kadmin. > Configuring ipa_memcached > [1/2]: starting ipa_memcached > [2/2]: configuring ipa_memcached to start on boot > Done configuring ipa_memcached. > Configuring ipa-otpd > [1/2]: starting ipa-otpd > [2/2]: configuring ipa-otpd to start on boot > Done configuring ipa-otpd. > Configuring the web interface (httpd). Estimated time: 1 minute > [1/19]: setting mod_nss port to 443 > [2/19]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2 > [3/19]: setting mod_nss password file > [4/19]: enabling mod_nss renegotiate > [5/19]: adding URL rewriting rules > [6/19]: configuring httpd > [7/19]: configure certmonger for renewals > [8/19]: setting up ssl > [9/19]: importing CA certificates from LDAP > [10/19]: setting up browser autoconfig > [11/19]: publish CA cert > [12/19]: creating a keytab for httpd > [13/19]: clean up any existing httpd ccache > [14/19]: configuring SELinux for httpd > [15/19]: create KDC proxy user > [16/19]: create KDC proxy config > [17/19]: enable KDC proxy > [18/19]: restarting httpd > [19/19]: configuring httpd to start on boot > Done configuring the web interface (httpd). > Applying LDAP updates > Upgrading IPA: > [1/9]: stopping directory server > [2/9]: saving configuration > [3/9]: disabling listeners > [4/9]: enabling DS global lock > [5/9]: starting directory server > [6/9]: upgrading server > [7/9]: stopping directory server > [8/9]: restoring configuration > [9/9]: starting directory server > Done. > Restarting the directory server > Restarting the KDC > Sample zone file for bind has been created in > /tmp/sample.zone.Yjwpca.db > Restarting the web server > ============================================================================== > Setup complete > > Next steps: > 1. You must make sure these network ports are open: > TCP Ports: > * 80, 443: HTTP/HTTPS > * 389, 636: LDAP/LDAPS > * 88, 464: kerberos > UDP Ports: > * 88, 464: kerberos > * 123: ntp > > 2. You can now obtain a kerberos ticket using the command: > 'kinit admin' > This ticket will allow you to use the IPA tools (e.g., ipa > user-add) > and the web user interface. > > Be sure to back up the CA certificates stored in /root/cacert.p12 > These files are required to create replicas. The password for these > files is the Directory Manager password > [jjflynn22 at ipa-1 ~]$ kinit admin > Password for admin at KKGPITT.ORG : > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=ntp > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=http > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=https > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=ldap > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=ldaps > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=kerberos > success > [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=kpasswd > success > [jjflynn22 at ipa-1 ~]$ sudo authconfig --enablemkhomedir --update > [jjflynn22 at ipa-1 ~]$ sudo chkconfig sssd on > Note: Forwarding request to 'systemctl enable sssd.service'. > [jjflynn22 at ipa-1 ~]$ git config --global user.name > "Joe Flynn" > [jjflynn22 at ipa-1 ~]$ git config --global user.email > "jjflynn22 at gmail.com " > [jjflynn22 at ipa-1 ~]$ mkdir ~/.ssh > [jjflynn22 at ipa-1 ~]$ cd ~/.ssh > [jjflynn22 at ipa-1 .ssh]$ vi id_rsa > [jjflynn22 at ipa-1 .ssh]$ vi id_rsa.pub > [jjflynn22 at ipa-1 .ssh]$ chmod 700 ~/.ssh > [jjflynn22 at ipa-1 .ssh]$ chmod 600 ~/.ssh/* > [jjflynn22 at ipa-1 .ssh]$ ssh-add ~/.ssh/id_rsa > Identity added: /home/jjflynn22/.ssh/id_rsa > (/home/jjflynn22/.ssh/id_rsa) > [jjflynn22 at ipa-1 .ssh]$ sudo yum install -y letsencrypt > Loaded plugins: fastestmirror, langpacks > Loading mirror speeds from cached hostfile > * base: repo1.ash.innoscale.net > * epel: mirror.cogentco.com > * extras: chicago.gaminghost.co > * updates: mirror.cs.vt.edu > Resolving Dependencies > --> Running transaction check > ---> Package certbot.noarch 0:0.9.3-1.el7 will be installed > --> Processing Dependency: python2-certbot = 0.9.3-1.el7 for > package: certbot-0.9.3-1.el7.noarch > --> Running transaction check > ---> Package python2-certbot.noarch 0:0.9.3-1.el7 will be installed > --> Processing Dependency: python2-acme = 0.9.3 for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python2-dialog >= 3.3.0 for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python2-configargparse >= 0.10.0 for > package: python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python-psutil >= 2.1.0 for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python-zope-interface for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python-zope-component for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python-parsedatetime for package: > python2-certbot-0.9.3-1.el7.noarch > --> Processing Dependency: python-mock for package: > python2-certbot-0.9.3-1.el7.noarch > --> Running transaction check > ---> Package python-parsedatetime.noarch 0:1.5-3.el7 will be installed > ---> Package python-psutil.x86_64 0:2.2.1-1.el7 will be installed > ---> Package python-zope-component.noarch 1:4.1.0-1.el7 will be > installed > --> Processing Dependency: python-zope-event for package: > 1:python-zope-component-4.1.0-1.el7.noarch > ---> Package python-zope-interface.x86_64 0:4.0.5-4.el7 will be > installed > ---> Package python2-acme.noarch 0:0.9.3-1.el7 will be installed > --> Processing Dependency: python-pyrfc3339 for package: > python2-acme-0.9.3-1.el7.noarch > --> Processing Dependency: python-ndg_httpsclient for package: > python2-acme-0.9.3-1.el7.noarch > ---> Package python2-configargparse.noarch 0:0.10.0-1.el7 will be > installed > ---> Package python2-dialog.noarch 0:3.3.0-6.el7 will be installed > --> Processing Dependency: dialog for package: > python2-dialog-3.3.0-6.el7.noarch > ---> Package python2-mock.noarch 0:1.0.1-9.el7 will be installed > --> Running transaction check > ---> Package dialog.x86_64 0:1.2-4.20130523.el7 will be installed > ---> Package python-ndg_httpsclient.noarch 0:0.3.2-1.el7 will be > installed > ---> Package python-zope-event.noarch 0:4.0.3-2.el7 will be installed > ---> Package python2-pyrfc3339.noarch 0:1.0-2.el7 will be installed > --> Finished Dependency Resolution > > Dependencies Resolved > > ============================================================================================================================= > Package Arch Version Repository Size > ============================================================================================================================= > Installing: > certbot noarch 0.9.3-1.el7 epel 16 k > Installing for dependencies: > dialog x86_64 1.2-4.20130523.el7 base 208 k > python-ndg_httpsclient noarch 0.3.2-1.el7 > epel 43 k > python-parsedatetime noarch 1.5-3.el7 > epel 61 k > python-psutil x86_64 2.2.1-1.el7 epel 114 k > python-zope-component noarch 1:4.1.0-1.el7 > epel 110 k > python-zope-event noarch 4.0.3-2.el7 epel 79 k > python-zope-interface x86_64 4.0.5-4.el7 > base 138 k > python2-acme noarch 0.9.3-1.el7 epel 168 k > python2-certbot noarch 0.9.3-1.el7 epel 361 k > python2-configargparse noarch 0.10.0-1.el7 > epel 28 k > python2-dialog noarch 3.3.0-6.el7 epel 94 k > python2-mock noarch 1.0.1-9.el7 epel 92 k > python2-pyrfc3339 noarch 1.0-2.el7 epel 13 k > > Transaction Summary > ============================================================================================================================= > Install 1 Package (+13 Dependent packages) > > Total download size: 1.5 M > Installed size: 6.3 M > Downloading packages: > (1/14): python-ndg_httpsclient-0.3.2-1.el7.noarch.rpm | 43 kB > 00:00:00 > (2/14): dialog-1.2-4.20130523.el7.x86_64.rpm | 208 kB 00:00:00 > (3/14): certbot-0.9.3-1.el7.noarch.rpm | 16 kB 00:00:00 > (4/14): python-parsedatetime-1.5-3.el7.noarch.rpm | 61 kB 00:00:00 > (5/14): python-psutil-2.2.1-1.el7.x86_64.rpm | 114 kB 00:00:00 > (6/14): python-zope-component-4.1.0-1.el7.noarch.rpm | 110 kB > 00:00:00 > (7/14): python-zope-interface-4.0.5-4.el7.x86_64.rpm | 138 kB > 00:00:00 > (8/14): python-zope-event-4.0.3-2.el7.noarch.rpm | 79 kB 00:00:00 > (9/14): python2-certbot-0.9.3-1.el7.noarch.rpm | 361 kB 00:00:00 > (10/14): python2-configargparse-0.10.0-1.el7.noarch.rpm | 28 kB > 00:00:00 > (11/14): python2-acme-0.9.3-1.el7.noarch.rpm | 168 kB 00:00:00 > (12/14): python2-dialog-3.3.0-6.el7.noarch.rpm | 94 kB 00:00:00 > (13/14): python2-pyrfc3339-1.0-2.el7.noarch.rpm | 13 kB 00:00:00 > (14/14): python2-mock-1.0.1-9.el7.noarch.rpm | 92 kB 00:00:00 > ----------------------------------------------------------------------------------------------------------------------------- > Total 1.3 MB/s | 1.5 MB 00:00:01 > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Installing : python-zope-interface-4.0.5-4.el7.x86_64 1/14 > Installing : python2-mock-1.0.1-9.el7.noarch 2/14 > Installing : python-parsedatetime-1.5-3.el7.noarch 3/14 > Installing : python-psutil-2.2.1-1.el7.x86_64 4/14 > Installing : python-zope-event-4.0.3-2.el7.noarch 5/14 > Installing : 1:python-zope-component-4.1.0-1.el7.noarch 6/14 > Installing : python-ndg_httpsclient-0.3.2-1.el7.noarch 7/14 > Installing : python2-pyrfc3339-1.0-2.el7.noarch 8/14 > Installing : python2-acme-0.9.3-1.el7.noarch 9/14 > Installing : python2-configargparse-0.10.0-1.el7.noarch 10/14 > Installing : dialog-1.2-4.20130523.el7.x86_64 11/14 > Installing : python2-dialog-3.3.0-6.el7.noarch 12/14 > Installing : python2-certbot-0.9.3-1.el7.noarch 13/14 > Installing : certbot-0.9.3-1.el7.noarch 14/14 > Verifying : dialog-1.2-4.20130523.el7.x86_64 1/14 > Verifying : certbot-0.9.3-1.el7.noarch 2/14 > Verifying : python2-configargparse-0.10.0-1.el7.noarch 3/14 > Verifying : python2-pyrfc3339-1.0-2.el7.noarch 4/14 > Verifying : python-zope-interface-4.0.5-4.el7.x86_64 5/14 > Verifying : python-ndg_httpsclient-0.3.2-1.el7.noarch 6/14 > Verifying : python-zope-event-4.0.3-2.el7.noarch 7/14 > Verifying : python-psutil-2.2.1-1.el7.x86_64 8/14 > Verifying : python2-acme-0.9.3-1.el7.noarch 9/14 > Verifying : python2-dialog-3.3.0-6.el7.noarch 10/14 > Verifying : 1:python-zope-component-4.1.0-1.el7.noarch 11/14 > Verifying : python-parsedatetime-1.5-3.el7.noarch 12/14 > Verifying : python2-certbot-0.9.3-1.el7.noarch 13/14 > Verifying : python2-mock-1.0.1-9.el7.noarch 14/14 > > Installed: > certbot.noarch 0:0.9.3-1.el7 > > Dependency Installed: > dialog.x86_64 0:1.2-4.20130523.el7 python-ndg_httpsclient.noarch > 0:0.3.2-1.el7 > python-parsedatetime.noarch 0:1.5-3.el7 > python-psutil.x86_64 0:2.2.1-1.el7 > python-zope-component.noarch 1:4.1.0-1.el7 > python-zope-event.noarch 0:4.0.3-2.el7 > python-zope-interface.x86_64 0:4.0.5-4.el7 > python2-acme.noarch 0:0.9.3-1.el7 > python2-certbot.noarch 0:0.9.3-1.el7 > python2-configargparse.noarch 0:0.10.0-1.el7 > python2-dialog.noarch 0:3.3.0-6.el7 python2-mock.noarch > 0:1.0.1-9.el7 > python2-pyrfc3339.noarch 0:1.0-2.el7 > > Complete! > [jjflynn22 at ipa-1 .ssh]$ > [jjflynn22 at ipa-1 .ssh]$ > [jjflynn22 at ipa-1 .ssh]$ sudo cp -r /etc/httpd/alias > /etc/httpd/alias_backup > [jjflynn22 at ipa-1 .ssh]$ cd ~ > [jjflynn22 at ipa-1 ~]$ git clone > https://github.com/freeipa/freeipa-letsencrypt.git > Cloning into 'freeipa-letsencrypt'... > remote: Counting objects: 45, done. > remote: Compressing objects: 100% (4/4), done. > remote: Total 45 (delta 0), reused 0 (delta 0), pack-reused 41 > Unpacking objects: 100% (45/45), done. > [jjflynn22 at ipa-1 ~]$ sudo cp -r freeipa-letsencrypt /root/ipa-le > [jjflynn22 at ipa-1 ~]$ sudo vi /root/ipa-le/renew-le.sh > [jjflynn22 at ipa-1 ~]$ sudo yum install -y dnf > Loaded plugins: fastestmirror, langpacks > Loading mirror speeds from cached hostfile > * base: repo1.ash.innoscale.net > * epel: mirror.cogentco.com > * extras: mirrors.advancedhosters.com > > * updates: mirror.cs.vt.edu > Resolving Dependencies > --> Running transaction check > ---> Package dnf.noarch 0:0.6.4-2.el7 will be installed > --> Processing Dependency: python-dnf = 0.6.4-2.el7 for package: > dnf-0.6.4-2.el7.noarch > --> Running transaction check > ---> Package python-dnf.noarch 0:0.6.4-2.el7 will be installed > --> Processing Dependency: dnf-conf = 0.6.4-2.el7 for package: > python-dnf-0.6.4-2.el7.noarch > --> Processing Dependency: python-librepo >= 1.7.5 for package: > python-dnf-0.6.4-2.el7.noarch > --> Processing Dependency: python-libcomps >= 0.1.6 for package: > python-dnf-0.6.4-2.el7.noarch > --> Processing Dependency: python-hawkey >= 0.5.3 for package: > python-dnf-0.6.4-2.el7.noarch > --> Running transaction check > ---> Package dnf-conf.noarch 0:0.6.4-2.el7 will be installed > ---> Package python-hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 will > be installed > --> Processing Dependency: hawkey(x86-64) = > 0.5.8-2.git.0.202b194.el7 for package: > python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > --> Processing Dependency: libsolv.so.0(SOLV_1.0)(64bit) for > package: python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > --> Processing Dependency: libsolv.so.0()(64bit) for package: > python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > --> Processing Dependency: libhawkey.so.2()(64bit) for package: > python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 > ---> Package python-libcomps.x86_64 0:0.1.6-13.el7 will be installed > --> Processing Dependency: libcomps(x86-64) = 0.1.6-13.el7 for > package: python-libcomps-0.1.6-13.el7.x86_64 > --> Processing Dependency: libcomps.so.0.1.6()(64bit) for package: > python-libcomps-0.1.6-13.el7.x86_64 > ---> Package python-librepo.x86_64 0:1.7.16-1.el7 will be installed > --> Processing Dependency: librepo(x86-64) = 1.7.16-1.el7 for > package: python-librepo-1.7.16-1.el7.x86_64 > --> Processing Dependency: librepo.so.0()(64bit) for package: > python-librepo-1.7.16-1.el7.x86_64 > --> Running transaction check > ---> Package hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 will be > installed > ---> Package libcomps.x86_64 0:0.1.6-13.el7 will be installed > ---> Package librepo.x86_64 0:1.7.16-1.el7 will be installed > ---> Package libsolv.x86_64 0:0.6.11-1.el7 will be installed > --> Finished Dependency Resolution > > Dependencies Resolved > > ============================================================================================================================= > Package Arch Version > Repository Size > ============================================================================================================================= > Installing: > dnf noarch 0.6.4-2.el7 > epel 209 k > Installing for dependencies: > dnf-conf noarch 0.6.4-2.el7 > epel 61 k > hawkey x86_64 0.5.8-2.git.0.202b194.el7 > base 87 k > libcomps x86_64 0.1.6-13.el7 > epel 72 k > librepo x86_64 1.7.16-1.el7 > base 77 k > libsolv x86_64 0.6.11-1.el7 > base 316 k > python-dnf noarch 0.6.4-2.el7 > epel 407 k > python-hawkey x86_64 0.5.8-2.git.0.202b194.el7 > base 71 k > python-libcomps x86_64 0.1.6-13.el7 > epel 44 k > python-librepo x86_64 1.7.16-1.el7 > base 49 k > > Transaction Summary > ============================================================================================================================= > Install 1 Package (+9 Dependent packages) > > Total download size: 1.4 M > Installed size: 4.1 M > Downloading packages: > (1/10): hawkey-0.5.8-2.git.0.202b194.el7.x86_64.rpm | 87 kB > 00:00:00 > (2/10): dnf-conf-0.6.4-2.el7.noarch.rpm | 61 kB 00:00:00 > (3/10): dnf-0.6.4-2.el7.noarch.rpm | 209 kB 00:00:00 > (4/10): librepo-1.7.16-1.el7.x86_64.rpm | 77 kB 00:00:00 > (5/10): libcomps-0.1.6-13.el7.x86_64.rpm | 72 kB 00:00:00 > (6/10): python-librepo-1.7.16-1.el7.x86_64.rpm | 49 kB 00:00:00 > (7/10): python-libcomps-0.1.6-13.el7.x86_64.rpm | 44 kB 00:00:00 > (8/10): python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64.rpm | 71 > kB 00:00:00 > (9/10): python-dnf-0.6.4-2.el7.noarch.rpm | 407 kB 00:00:00 > (10/10): libsolv-0.6.11-1.el7.x86_64.rpm | 316 kB 00:00:00 > ----------------------------------------------------------------------------------------------------------------------------- > Total 1.4 MB/s | 1.4 MB 00:00:01 > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Installing : libsolv-0.6.11-1.el7.x86_64 1/10 > Installing : hawkey-0.5.8-2.git.0.202b194.el7.x86_64 2/10 > Installing : python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 3/10 > Installing : dnf-conf-0.6.4-2.el7.noarch 4/10 > Installing : libcomps-0.1.6-13.el7.x86_64 5/10 > Installing : python-libcomps-0.1.6-13.el7.x86_64 6/10 > Installing : librepo-1.7.16-1.el7.x86_64 7/10 > Installing : python-librepo-1.7.16-1.el7.x86_64 8/10 > Installing : python-dnf-0.6.4-2.el7.noarch 9/10 > Installing : dnf-0.6.4-2.el7.noarch 10/10 > Verifying : librepo-1.7.16-1.el7.x86_64 1/10 > Verifying : python-libcomps-0.1.6-13.el7.x86_64 2/10 > Verifying : python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 3/10 > Verifying : python-librepo-1.7.16-1.el7.x86_64 4/10 > Verifying : python-dnf-0.6.4-2.el7.noarch 5/10 > Verifying : libcomps-0.1.6-13.el7.x86_64 6/10 > Verifying : hawkey-0.5.8-2.git.0.202b194.el7.x86_64 7/10 > Verifying : dnf-conf-0.6.4-2.el7.noarch 8/10 > Verifying : dnf-0.6.4-2.el7.noarch 9/10 > Verifying : libsolv-0.6.11-1.el7.x86_64 10/10 > > Installed: > dnf.noarch 0:0.6.4-2.el7 > > Dependency Installed: > dnf-conf.noarch 0:0.6.4-2.el7 hawkey.x86_64 > 0:0.5.8-2.git.0.202b194.el7 > libcomps.x86_64 0:0.1.6-13.el7 librepo.x86_64 0:1.7.16-1.el7 > libsolv.x86_64 0:0.6.11-1.el7 python-dnf.noarch 0:0.6.4-2.el7 > python-hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 > python-libcomps.x86_64 0:0.1.6-13.el7 > python-librepo.x86_64 0:1.7.16-1.el7 > > Complete! > [jjflynn22 at ipa-1 ~]$ sudo yum remove -y epel-release > Loaded plugins: fastestmirror, langpacks > Resolving Dependencies > --> Running transaction check > ---> Package epel-release.noarch 0:7-6 will be erased > --> Finished Dependency Resolution > > Dependencies Resolved > > ============================================================================================================================= > Package Arch Version > Repository Size > ============================================================================================================================= > Removing: > epel-release noarch 7-6 > @extras 24 k > > Transaction Summary > ============================================================================================================================= > Remove 1 Package > > Installed size: 24 k > Downloading packages: > Running transaction check > Running transaction test > Transaction test succeeded > Running transaction > Erasing : epel-release-7-6.noarch 1/1 > Verifying : epel-release-7-6.noarch 1/1 > > Removed: > epel-release.noarch 0:7-6 > > Complete! > [jjflynn22 at ipa-1 ~]$ sudo dnf repolist > CentOS-7 - Base 8.4 MB/s | 8.8 MB 00:01 > CentOS-7 - Updates 4.5 MB/s | 12 MB 00:02 > CentOS-7 - Extras 1.9 MB/s | 569 kB 00:00 > Using metadata from Sun Dec 4 18:06:04 2016 > repo id repo name status > base CentOS-7 - Base 9,007 > extras CentOS-7 - Extras 393 > updates CentOS-7 - Updates 2,560 > [jjflynn22 at ipa-1 ~]$ sudo /root/ipa-le/setup-le.sh > Using metadata from Sun Dec 4 18:06:04 2016 > Package certbot-0.9.3-1.el7.noarch is already installed, skipping. > Dependencies resolved. > Nothing to do. > Directory Manager password: > > Installing CA certificate, please wait > CA certificate successfully installed > The ipa-cacert-manage command was successful > ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: Not logging to a file > ipa: DEBUG: Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > ipa: DEBUG: importing all plugin modules in ipalib.plugins... > ipa: DEBUG: importing plugin module ipalib.plugins.aci > ipa: DEBUG: importing plugin module ipalib.plugins.automember > ipa: DEBUG: importing plugin module ipalib.plugins.automount > ipa: DEBUG: importing plugin module ipalib.plugins.baseldap > ipa: DEBUG: importing plugin module ipalib.plugins.baseuser > ipa: DEBUG: importing plugin module ipalib.plugins.batch > ipa: DEBUG: importing plugin module ipalib.plugins.caacl > ipa: DEBUG: importing plugin module ipalib.plugins.cert > ipa: DEBUG: importing plugin module ipalib.plugins.certprofile > ipa: DEBUG: importing plugin module ipalib.plugins.config > ipa: DEBUG: importing plugin module ipalib.plugins.delegation > ipa: DEBUG: importing plugin module ipalib.plugins.dns > ipa: DEBUG: importing plugin module ipalib.plugins.domainlevel > ipa: DEBUG: importing plugin module ipalib.plugins.group > ipa: DEBUG: importing plugin module ipalib.plugins.hbacrule > ipa: DEBUG: importing plugin module ipalib.plugins.hbacsvc > ipa: DEBUG: importing plugin module ipalib.plugins.hbacsvcgroup > ipa: DEBUG: importing plugin module ipalib.plugins.hbactest > ipa: DEBUG: importing plugin module ipalib.plugins.host > ipa: DEBUG: importing plugin module ipalib.plugins.hostgroup > ipa: DEBUG: importing plugin module ipalib.plugins.idrange > ipa: DEBUG: importing plugin module ipalib.plugins.idviews > ipa: DEBUG: importing plugin module ipalib.plugins.internal > ipa: DEBUG: importing plugin module ipalib.plugins.kerberos > ipa: DEBUG: importing plugin module ipalib.plugins.krbtpolicy > ipa: DEBUG: importing plugin module ipalib.plugins.migration > ipa: DEBUG: importing plugin module ipalib.plugins.misc > ipa: DEBUG: importing plugin module ipalib.plugins.netgroup > ipa: DEBUG: importing plugin module ipalib.plugins.otpconfig > ipa: DEBUG: importing plugin module ipalib.plugins.otptoken > ipa: DEBUG: importing plugin module ipalib.plugins.otptoken_yubikey > ipa: DEBUG: importing plugin module ipalib.plugins.passwd > ipa: DEBUG: importing plugin module ipalib.plugins.permission > ipa: DEBUG: importing plugin module ipalib.plugins.ping > ipa: DEBUG: importing plugin module ipalib.plugins.pkinit > ipa: DEBUG: importing plugin module ipalib.plugins.privilege > ipa: DEBUG: importing plugin module ipalib.plugins.pwpolicy > ipa: DEBUG: Starting external process > ipa: DEBUG: args='klist' '-V' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=Kerberos 5 version 1.13.2 > > ipa: DEBUG: stderr= > ipa: DEBUG: importing plugin module ipalib.plugins.radiusproxy > ipa: DEBUG: importing plugin module ipalib.plugins.realmdomains > ipa: DEBUG: importing plugin module ipalib.plugins.role > ipa: DEBUG: importing plugin module ipalib.plugins.rpcclient > ipa: DEBUG: importing plugin module ipalib.plugins.selfservice > ipa: DEBUG: importing plugin module ipalib.plugins.selinuxusermap > ipa: DEBUG: importing plugin module ipalib.plugins.server > ipa: DEBUG: importing plugin module ipalib.plugins.service > ipa: DEBUG: importing plugin module ipalib.plugins.servicedelegation > ipa: DEBUG: importing plugin module ipalib.plugins.session > ipa: DEBUG: importing plugin module ipalib.plugins.stageuser > ipa: DEBUG: importing plugin module ipalib.plugins.sudocmd > ipa: DEBUG: importing plugin module ipalib.plugins.sudocmdgroup > ipa: DEBUG: importing plugin module ipalib.plugins.sudorule > ipa: DEBUG: importing plugin module ipalib.plugins.topology > ipa: DEBUG: importing plugin module ipalib.plugins.trust > ipa: DEBUG: importing plugin module ipalib.plugins.user > ipa: DEBUG: importing plugin module ipalib.plugins.vault > ipa: DEBUG: importing plugin module ipalib.plugins.virtual > ipa: DEBUG: Initializing principal > host/ipa-1.kkgpitt.org at KKGPITT.ORG > using keytab /etc/krb5.keytab > ipa: DEBUG: using ccache /tmp/tmp-zgrScg/ccache > ipa: DEBUG: Attempt 1/1: success > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'search' '@s' 'user' > 'ipa_session_cookie:host/ipa-1.kkgpitt.org at KKGPITT.ORG > ' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=134111920 > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'pipe' '134111920' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=ipa_session=59c01d94b52f0586e30046bd36ef93a5; > Domain=ipa-1.kkgpitt.org ; Path=/ipa; > Expires=Sun, 04 Dec 2016 23:21:13 GMT; Secure; HttpOnly > ipa: DEBUG: stderr= > ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: found > session_cookie in persistent storage for principal > 'host/ipa-1.kkgpitt.org at KKGPITT.ORG > ', cookie: > 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; > Domain=ipa-1.kkgpitt.org ; Path=/ipa; > Expires=Sun, 04 Dec 2016 23:21:13 GMT; Secure; HttpOnly' > ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: setting > session_cookie into context > 'ipa_session=59c01d94b52f0586e30046bd36ef93a5;' > ipa.ipalib.plugins.rpcclient.rpcclient: INFO: trying > https://ipa-1.kkgpitt.org/ipa/session/json > ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: Created connection > context.rpcclient_71021840 > ipa.ipalib.plugins.rpcclient.rpcclient: INFO: Forwarding > 'ca_is_enabled' to json server > 'https://ipa-1.kkgpitt.org/ipa/session/json' > ipa: DEBUG: NSSConnection init ipa-1.kkgpitt.org > > ipa: DEBUG: Connecting: 192.168.1.201:0 > ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server > ipa: DEBUG: cert valid True for "CN=ipa-1.kkgpitt.org > ,O=KKGPITT.ORG " > ipa: DEBUG: handshake complete, peer = 192.168.1.201:443 > > ipa: DEBUG: Protocol: TLS1.2 > ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_256_CBC_SHA > ipa: DEBUG: received Set-Cookie > 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; > Domain=ipa-1.kkgpitt.org ; Path=/ipa; > Expires=Sun, 04 Dec 2016 23:26:28 GMT; Secure; HttpOnly' > ipa: DEBUG: storing cookie > 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; > Domain=ipa-1.kkgpitt.org ; Path=/ipa; > Expires=Sun, 04 Dec 2016 23:26:28 GMT; Secure; HttpOnly' for > principal host/ipa-1.kkgpitt.org at KKGPITT.ORG > > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'search' '@s' 'user' > 'ipa_session_cookie:host/ipa-1.kkgpitt.org at KKGPITT.ORG > ' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=134111920 > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'search' '@s' 'user' > 'ipa_session_cookie:host/ipa-1.kkgpitt.org at KKGPITT.ORG > ' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=134111920 > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'pupdate' '134111920' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: Destroyed > connection context.rpcclient_71021840 > ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing > ldap://ipa-1.kkgpitt.org:389 from > SchemaCache > ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for > SchemaCache url=ldap://ipa-1.kkgpitt.org:389 > > conn= > ipa: DEBUG: Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-KKGPITT-ORG' '-A' '-n' 'KKGPITT.ORG > IPA CA' '-t' 'CT,C,C' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' > '/etc/dirsrv/slapd-KKGPITT-ORG' '-A' '-n' 'DSTRootCAX3' '-t' 'C,,' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'is-active' > 'dirsrv at KKGPITT-ORG.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=active > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' '--system' 'daemon-reload' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'restart' > 'dirsrv at KKGPITT-ORG.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'is-active' > 'dirsrv at KKGPITT-ORG.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=active > > ipa: DEBUG: stderr= > ipa: DEBUG: wait_for_open_ports: localhost [389] timeout 300 > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/httpd/alias' '-A' > '-n' 'KKGPITT.ORG IPA CA' '-t' 'CT,C,C' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/httpd/alias' '-A' > '-n' 'DSTRootCAX3' '-t' 'C,,' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'is-active' 'httpd.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=active > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'restart' 'httpd.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/bin/systemctl' 'is-active' 'httpd.service' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=active > > ipa: DEBUG: stderr= > ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: resubmitting > certmonger request '20161204225818' > ipa: DEBUG: certmonger request is in state > dbus.String(u'GENERATING_CSR', variant_level=1) > ipa: DEBUG: certmonger request is in state > dbus.String(u'PRE_SAVE_CERT', variant_level=1) > ipa: DEBUG: certmonger request is in state > dbus.String(u'POST_SAVED_CERT', variant_level=1) > ipa: DEBUG: certmonger request is in state > dbus.String(u'POST_SAVED_CERT', variant_level=1) > ipa: DEBUG: certmonger request is in state > dbus.String(u'POST_SAVED_CERT', variant_level=1) > ipa: DEBUG: certmonger request is in state > dbus.String(u'MONITORING', variant_level=1) > ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: modifying > certmonger request '20161204225818' > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > Certificate Nickname Trust > Attributes > SSL,S/MIME,JAR/XPI > > KKGPITT.ORG IPA > CA CT,C,C > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-L' > '-n' 'KKGPITT.ORG IPA CA' '-a' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=-----BEGIN CERTIFICATE----- > MIIDjTCCAnWgAwIBAgIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtLS0dQ > SVRULk9SRzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MTIw > NDIyNTczNFoXDTM2MTIwNDIyNTczNFowNjEUMBIGA1UECgwLS0tHUElUVC5PUkcx > HjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEB > . > > . > > BYuURWnoNBd110T0HFOnMOmN5ycnsMvCwCdUFuFKCsjNjCm5/oUCsWSVlad2bzlj > 7gvnv3d6YmXwTzpOlOHpMu/S7y+JU5ErM9fp97R/vUvBz/7CM0MOKBgXMvfKTu6X > PTROdl8lKofxA6TMvM+du020+o79dami0hWV/3cRN386huTDcWVn9gbud6hxX8U5 > StsgHtJLlrm4tjLk8+S5VTDu9Y6EX7OsEX51RHwtrfNjEYdCa68AM2/slxdgf+5S > IQ== > -----END CERTIFICATE----- > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-D' > '-n' 'KKGPITT.ORG IPA CA' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-L' > '-n' 'KKGPITT.ORG IPA CA' '-a' > ipa: DEBUG: Process finished, return code=255 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=certutil: Could not find cert: KKGPITT.ORG > IPA CA > : PR_FILE_NOT_FOUND_ERROR: File not found > > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L' > '-n' 'IPA CA' '-a' > ipa: DEBUG: Process finished, return code=255 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA > : PR_FILE_NOT_FOUND_ERROR: File not found > > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L' > '-n' 'External CA cert' '-a' > ipa: DEBUG: Process finished, return code=255 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert > : PR_FILE_NOT_FOUND_ERROR: File not found > > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-A' > '-n' 'KKGPITT.ORG IPA CA' '-t' 'CT,C,C' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-A' > '-n' 'DSTRootCAX3' '-t' 'C,,' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-A' > '-n' 'KKGPITT.ORG IPA CA' '-t' 'CT,C,C' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-A' > '-n' 'DSTRootCAX3' '-t' 'C,,' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/update-ca-trust' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: INFO: Systemwide CA database updated. > ipa: DEBUG: Starting external process > ipa: DEBUG: args='/usr/bin/update-ca-trust' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: INFO: Systemwide CA database updated. > ipa.ipaclient.ipa_certupdate.CertUpdate: INFO: The ipa-certupdate > command was successful > Directory Manager password: > > Installing CA certificate, please wait > Not a valid CA certificate: (SEC_ERROR_UNKNOWN_ISSUER) Peer's > Certificate issuer is not recognized. (visit > http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) > [jjflynn22 at ipa-1 ~]$ > > > > Hi, you seem to have an issue when the LetsEncryptAuthorityX3 is being installed. The certificate from the CA that issued this certificate (DSTRootCAX3) seems to be installed correctly. Could you verify that DSTRootCAX3 is marked as trusted CA by issuing: certutil -d /etc/httpd/alias/ -L The DSTRoootCAX3 should have C,, trust flags. There was an issue fixed last week that might caused this issue if you've ever tried to install letsencrypt on this particular VM before: https://github.com/freeipa/freeipa-letsencrypt/issues/1#issuecomment-263546822 If that's the case, you will need to re-install IPA before the letsencrypt solution will work. I was not able to reproduce your issue with a clean machine. -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkudyba at fordham.edu Mon Dec 5 16:05:38 2016 From: rkudyba at fordham.edu (Robert Kudyba) Date: Mon, 5 Dec 2016 11:05:38 -0500 Subject: [Freeipa-users] Importing Host Entries from /etc/hosts using sample nis-hosts.sh: Zone name error Message-ID: <5E209638-1EEE-465F-9815-8B670FB39F9F@fordham.edu> Using the sample script I?m trying to use hosts that are in various states meaning they could be powered off or disconnected, in our 2 campuses. We maintain a ?master? /etc/hosts file just to document how are static IP?s are assigned. When I try to use the script I get asked for the zone name for each host. We use the DNS of the university rather than running one on the FreeIPA Fedora 25 server. This is a new install so I can redo this as needed. Here?s what I get: ./nis-hosts.sh nisname subdomain.ourdomain.edu Zone name: ipa: ERROR: 'name' is required awk: cmd. line:1: {print $3 "." subdomain.ourdomain.edu "." nisname ".in-addr.arpa."} awk: cmd. line:1: ^ syntax error Zone name: subdomain ipa: ERROR: DNS is not configured Note I?m using our real domain and subdomain from above. The script is below. Can I hard code our domain and/or sub-domain some where in the script to get around the Zone name being prompted for each host? #!/bin/sh # 1 is the nis domain, 2 is the nis master server ypcat -d $1 -h $2 hosts | egrep -v "localhost|127.0.0.1" > /dev/shm/nis-map.hosts 2>&1 IFS=$'\n' for line in $(cat /dev/shm/nis-map.hosts); do IFS=' ' ipaddress=$(echo $line|awk '{print $1}') hostname=$(echo $line|awk '{print $2}') master=$(ipa env xmlrpc_uri |tr -d '[:space:]'|cut -f3 -d:|cut -f3 -d/) domain=$(ipa env domain|tr -d '[:space:]'|cut -f2 -d:) if [ $(echo $hostname|grep "\." |wc -l) -eq 0 ]; then hostname=$(echo $hostname.$domain) fi zone=$(echo $hostname|cut -f2- -d.) if [ $(ipa dnszone-show $zone 2>/dev/null | wc -l) -eq 0 ]; then ipa dnszone-add --name-server=$master --admin-email=root.$master fi ptrzone=$(echo $ipaddress|awk -F. '{print $3 "." $2 "." $1 ".in-addr.arpa."}') if [ $(ipa dnszone-show $ptrzone 2>/dev/null|wc -l) -eq 0 ]; then ipa dnszone-add $ptrzone --name-server=$master --admin-email=root.$master fi # Now create this entry ipa host-add $hostname --ip-address=$ipaddress ipa host-show $hostname done -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Mon Dec 5 16:37:02 2016 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 05 Dec 2016 16:37:02 +0000 Subject: [Freeipa-users] Directory Manager Password Change In-Reply-To: <38C784D32FB4354DAED01CCB1BB5053517561A22@mail01.firstderivatives.com> References: <7783a1de-0924-250c-c057-7601f8724af6@redhat.com> <38C784D32FB4354DAED01CCB1BB5053517561A22@mail01.firstderivatives.com> Message-ID: Hi Stefan, Thanks for your input, I am able to clarify that I wasn't simply copying and pasting in - the dollar sign was included in my password rather than the example. But yes, no denying that my command line skills are to blame. Further to this problem I am happy to report that the issue is now solved. My main issue was the dollar sign meaning that I had updated the DM password incorrectly for FreeIPA. Secondly I appear to have caused an issue with SSSD and it was a restart of this service which finally resolved the issue for me. I doubt there is much to be learnt from my issue - definitely user error. Thanks so much for your responses, very much appreciated. Apologies for taking up your time. Callum On Mon, Dec 5, 2016 at 2:48 PM Stefan Uygur wrote: > Hi, > > I think you are copying and pasting the exact same commands from the > article, which is of course a wrong approach. Never copy/paste from web to > execute on your server. That $ signs indicates you can give any name you?d > like. > > > > Follow this article here: > > https://access.redhat.com/solutions/308623 > > > > Stefan > > > > > > *From:* freeipa-users-bounces at redhat.com [mailto: > freeipa-users-bounces at redhat.com] *On Behalf Of *Callum Guy > *Sent:* 05 December 2016 13:38 > *To:* Florence Blanc-Renaud; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Directory Manager Password Change > > > > Hi Flo, > > > > I have indeed executed every step in order, including the one you have > indicated. > > > > The password I has used included a dollar sign and this meant that echo > -n $DM_PASSWORD > /root/dm_password didn't work as I had expected meaning > everything after the dollar was interpreted as a variable and was missing > in the file. I have corrected this and performed the full process again, > starting with the 389 reset however it is still not working correctly. > > > > I remain in the same state as before where the admin password has not been > changed - this confuses me as my understanding is that admin only exists as > the FreeIPA web admin user whose password I can change separately. Am i > misunderstanding, is there another admin user within FreeIPA which is > directly linked to the directory manager? > > > > Having run out of ideas I have just executed ipa-server-upgrade however > this hasn't helped. My situation remains as follows: > > > > *Works:* ldapsearch -x -D "cn=directory manager" -w *NEW_DM_PW *-s base > -b "" "objectclass=*" > > *Fails: *ldapsearch -h localhost -ZZ -p 389 -x -D > "uid=admin,ou=people,o=ipaca" -w *NEW_DM_PW *-b "" -s base > > > > Are you able to offer any other ideas? > > > > Other information: > > I can confirm that cacert.p12 has been updated by the actions performed. > > File /etc/pki/pki-tomcat/password.conf now contains a new line internaldb= > *NEW_DM_PW *(as per instruction 1 on FreeIPA link) > > > > Best Regards, > > > > Callum > > > > > > On Mon, Dec 5, 2016 at 1:08 PM Florence Blanc-Renaud > wrote: > > On 12/05/2016 01:05 PM, Callum Guy wrote: > > Hi All, > > > > I have been testing FreeIPA and now plan to migrate to production use - > > thanks for creating such a great application! > > > > During the test phase we have been using simple passwords for the admin > > and directory manager users however we need these changed before moving > > into production. I believe we can change the admin password using the > > web interface however as I understand it amending the directory manager > > password is not so straightforward. > > > > I have found this > > link > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > however > > I am unsure if this is the correct procedure for our installation - > > certainly i am having no luck so far. > > > > We have the following setup: > > > > FreeIPA 4.2.0 - single master server (no replicas), multiple clients > > CentOS 7.2 > > > > I have tried the following steps in order: > > > > > http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html > > followed by > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > > > After completing that I am no longer able to authenticate user logins. > > The below covers my current situation: > > > > This works: > > ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" > > "objectclass=*" > > > > This does not work: > > ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" > > "objectclass=*" > > > > This works: > > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > > -W -b "" -s base > > OLDPASSWORD > > > > This does not work: > > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > > -W -b "" -s base > > NEWPASSWORD > > > Hi, > > your commands show that the Directory Manager password was properly > modified, but not admin's password. Did you run the step 3 Updating PKI > admin password of the procedure [1]? > ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W > -T /root/dm_password "uid=admin,ou=people,o=ipaca" > > Flo. > > [1] > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password > > > So i'm i a mixed up state! Is anyone able to offer advise on resolving > > this issue? > > > > Thank you, > > > > 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 <+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. > > > > > > > > > > *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. > -- *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 rcritten at redhat.com Mon Dec 5 16:38:19 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 5 Dec 2016 11:38:19 -0500 Subject: [Freeipa-users] Importing Host Entries from /etc/hosts using sample nis-hosts.sh: Zone name error In-Reply-To: <5E209638-1EEE-465F-9815-8B670FB39F9F@fordham.edu> References: <5E209638-1EEE-465F-9815-8B670FB39F9F@fordham.edu> Message-ID: <584597FB.4090505@redhat.com> Robert Kudyba wrote: > Using the sample script > I?m > trying to use hosts that are in various states meaning they could be > powered off or disconnected, in our 2 campuses. We maintain a ?master? > /etc/hosts file just to document how are static IP?s are assigned. When > I try to use the script I get asked for the zone name for each host. We > use the DNS of the university rather than running one on the FreeIPA > Fedora 25 server. This is a new install so I can redo this as needed. > Here?s what I get: > > ./nis-hosts.sh nisname subdomain.ourdomain.edu > > Zone name: > ipa: ERROR: 'name' is required > awk: cmd. line:1: {print $3 "." subdomain.ourdomain.edu > "." nisname ".in-addr.arpa."} > awk: cmd. line:1: ^ syntax error > > Zone name: subdomain > ipa: ERROR: DNS is not configured Looks to me like the DNS component was not configured in IPA so all the dns-* commands will fail. > Note I?m using our real domain and subdomain from above. The script is > below. Can I hard code our domain and/or sub-domain some where in the > script to get around the Zone name being prompted for each host? > > #!/bin/sh > # 1 is the nis domain, 2 is the nis master server > ypcat -d $1-h $2hosts | egrep -v "localhost|127.0.0.1"> > /dev/shm/nis-map.hosts 2>&1 > > > > IFS=$'\n' > forline in$(cat /dev/shm/nis-map.hosts); do > IFS=' ' > ipaddress=$(echo $line|awk '{print $1}') > hostname=$(echo $line|awk '{print $2}') > master=$(ipa env xmlrpc_uri |tr -d '[:space:]'|cut -f3 -d:|cut > -f3 -d/) > domain=$(ipa env domain|tr -d '[:space:]'|cut -f2 -d:) I'd move these two ipa env commands out of the loop. These values won't change and will just work to slow down the import. rob > if[ $(echo $hostname|grep "\."|wc -l) -eq 0 ]; then > hostname=$(echo $hostname.$domain) > fi > zone=$(echo $hostname|cut -f2- -d.) > if[ $(ipa dnszone-show $zone2>/dev/null | wc -l) -eq 0 ]; then > ipa dnszone-add > --name-server=$master--admin-email=root.$master > fi > ptrzone=$(echo $ipaddress|awk -F. '{print $3 "." $2 "." $1 > ".in-addr.arpa."}') > if[ $(ipa dnszone-show $ptrzone2>/dev/null|wc -l) -eq 0 ]; then > ipa dnszone-add > $ptrzone--name-server=$master--admin-email=root.$master > fi > # Now create this entry > ipa host-add $hostname--ip-address=$ipaddress > ipa host-show $hostname > done > > > From suygur at firstderivatives.com Mon Dec 5 16:39:55 2016 From: suygur at firstderivatives.com (Stefan Uygur) Date: Mon, 5 Dec 2016 16:39:55 +0000 Subject: [Freeipa-users] Directory Manager Password Change In-Reply-To: References: <7783a1de-0924-250c-c057-7601f8724af6@redhat.com> <38C784D32FB4354DAED01CCB1BB5053517561A22@mail01.firstderivatives.com> Message-ID: <38C784D32FB4354DAED01CCB1BB5053517561AF1@mail01.firstderivatives.com> Glad you solved your issue. I?ve been there myself so don?t worry about it at all. From: Callum Guy [mailto:callum.guy at x-on.co.uk] Sent: 05 December 2016 16:37 To: Stefan Uygur; Florence Blanc-Renaud; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Directory Manager Password Change Hi Stefan, Thanks for your input, I am able to clarify that I wasn't simply copying and pasting in - the dollar sign was included in my password rather than the example. But yes, no denying that my command line skills are to blame. Further to this problem I am happy to report that the issue is now solved. My main issue was the dollar sign meaning that I had updated the DM password incorrectly for FreeIPA. Secondly I appear to have caused an issue with SSSD and it was a restart of this service which finally resolved the issue for me. I doubt there is much to be learnt from my issue - definitely user error. Thanks so much for your responses, very much appreciated. Apologies for taking up your time. Callum On Mon, Dec 5, 2016 at 2:48 PM Stefan Uygur > wrote: Hi, I think you are copying and pasting the exact same commands from the article, which is of course a wrong approach. Never copy/paste from web to execute on your server. That $ signs indicates you can give any name you?d like. Follow this article here: https://access.redhat.com/solutions/308623 Stefan From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Callum Guy Sent: 05 December 2016 13:38 To: Florence Blanc-Renaud; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Directory Manager Password Change Hi Flo, I have indeed executed every step in order, including the one you have indicated. The password I has used included a dollar sign and this meant that echo -n $DM_PASSWORD > /root/dm_password didn't work as I had expected meaning everything after the dollar was interpreted as a variable and was missing in the file. I have corrected this and performed the full process again, starting with the 389 reset however it is still not working correctly. I remain in the same state as before where the admin password has not been changed - this confuses me as my understanding is that admin only exists as the FreeIPA web admin user whose password I can change separately. Am i misunderstanding, is there another admin user within FreeIPA which is directly linked to the directory manager? Having run out of ideas I have just executed ipa-server-upgrade however this hasn't helped. My situation remains as follows: Works: ldapsearch -x -D "cn=directory manager" -w NEW_DM_PW -s base -b "" "objectclass=*" Fails: ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" -w NEW_DM_PW -b "" -s base Are you able to offer any other ideas? Other information: I can confirm that cacert.p12 has been updated by the actions performed. File /etc/pki/pki-tomcat/password.conf now contains a new line internaldb=NEW_DM_PW (as per instruction 1 on FreeIPA link) Best Regards, Callum On Mon, Dec 5, 2016 at 1:08 PM Florence Blanc-Renaud > wrote: On 12/05/2016 01:05 PM, Callum Guy wrote: > Hi All, > > I have been testing FreeIPA and now plan to migrate to production use - > thanks for creating such a great application! > > During the test phase we have been using simple passwords for the admin > and directory manager users however we need these changed before moving > into production. I believe we can change the admin password using the > web interface however as I understand it amending the directory manager > password is not so straightforward. > > I have found this > link https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password however > I am unsure if this is the correct procedure for our installation - > certainly i am having no luck so far. > > We have the following setup: > > FreeIPA 4.2.0 - single master server (no replicas), multiple clients > CentOS 7.2 > > I have tried the following steps in order: > > http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html > followed by > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > After completing that I am no longer able to authenticate user logins. > The below covers my current situation: > > This works: > ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" > "objectclass=*" > > This does not work: > ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" > "objectclass=*" > > This works: > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > -W -b "" -s base > OLDPASSWORD > > This does not work: > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > -W -b "" -s base > NEWPASSWORD > Hi, your commands show that the Directory Manager password was properly modified, but not admin's password. Did you run the step 3 Updating PKI admin password of the procedure [1]? ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W -T /root/dm_password "uid=admin,ou=people,o=ipaca" Flo. [1] https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password > So i'm i a mixed up state! Is anyone able to offer advise on resolving > this issue? > > Thank you, > > 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. > > > [http://www.x-on.co.uk/email/footer/banner-x-on.jpg] 0333 332 0000 | www.x-on.co.uk | [http://www.x-on.co.uk/images/icon/linkedin.png] [http://www.x-on.co.uk/images/icon/facebook.png] [http://www.x-on.co.uk/images/icon/twitter.png] 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. [http://www.x-on.co.uk/email/footer/banner-x-on.jpg] 0333 332 0000 | www.x-on.co.uk | [http://www.x-on.co.uk/images/icon/linkedin.png] [http://www.x-on.co.uk/images/icon/facebook.png] [http://www.x-on.co.uk/images/icon/twitter.png] 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 rkudyba at fordham.edu Mon Dec 5 16:42:50 2016 From: rkudyba at fordham.edu (Robert Kudyba) Date: Mon, 5 Dec 2016 11:42:50 -0500 Subject: [Freeipa-users] Importing Host Entries from /etc/hosts using sample nis-hosts.sh: Zone name error In-Reply-To: <584597FB.4090505@redhat.com> References: <5E209638-1EEE-465F-9815-8B670FB39F9F@fordham.edu> <584597FB.4090505@redhat.com> Message-ID: <82CE9E83-4883-409D-9CD7-6BACCD7CF692@fordham.edu> >> ./nis-hosts.sh nisname subdomain.ourdomain.edu >> > >> Zone name: >> ipa: ERROR: 'name' is required >> awk: cmd. line:1: {print $3 "." subdomain.ourdomain.edu >> > "." nisname ".in-addr.arpa."} >> awk: cmd. line:1: ^ syntax error >> >> Zone name: subdomain >> ipa: ERROR: DNS is not configured > > Looks to me like the DNS component was not configured in IPA so all the > dns-* commands will fail. Well I mentioned that we are using the university?s DNS rather than a dedicated DNS server on the FreeIPA Fedora server. Where do I configure that in the GUI? Since our department does not have authority over the ouruniversity.edu domain I figured it was best to use their?s red resolving DNS. -------------- next part -------------- An HTML attachment was scrubbed... URL: From suygur at firstderivatives.com Mon Dec 5 16:45:32 2016 From: suygur at firstderivatives.com (Stefan Uygur) Date: Mon, 5 Dec 2016 16:45:32 +0000 Subject: [Freeipa-users] Directory Manager Password Change | off topic Message-ID: <38C784D32FB4354DAED01CCB1BB5053517561B12@mail01.firstderivatives.com> Guys, Since I replied to the list I keep receiving spam emails, what is happening? From: Stefan Uygur Sent: 05 December 2016 16:40 To: 'Callum Guy'; Florence Blanc-Renaud; freeipa-users at redhat.com Subject: RE: [Freeipa-users] Directory Manager Password Change Glad you solved your issue. I?ve been there myself so don?t worry about it at all. From: Callum Guy [mailto:callum.guy at x-on.co.uk] Sent: 05 December 2016 16:37 To: Stefan Uygur; Florence Blanc-Renaud; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Directory Manager Password Change Hi Stefan, Thanks for your input, I am able to clarify that I wasn't simply copying and pasting in - the dollar sign was included in my password rather than the example. But yes, no denying that my command line skills are to blame. Further to this problem I am happy to report that the issue is now solved. My main issue was the dollar sign meaning that I had updated the DM password incorrectly for FreeIPA. Secondly I appear to have caused an issue with SSSD and it was a restart of this service which finally resolved the issue for me. I doubt there is much to be learnt from my issue - definitely user error. Thanks so much for your responses, very much appreciated. Apologies for taking up your time. Callum On Mon, Dec 5, 2016 at 2:48 PM Stefan Uygur > wrote: Hi, I think you are copying and pasting the exact same commands from the article, which is of course a wrong approach. Never copy/paste from web to execute on your server. That $ signs indicates you can give any name you?d like. Follow this article here: https://access.redhat.com/solutions/308623 Stefan From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Callum Guy Sent: 05 December 2016 13:38 To: Florence Blanc-Renaud; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Directory Manager Password Change Hi Flo, I have indeed executed every step in order, including the one you have indicated. The password I has used included a dollar sign and this meant that echo -n $DM_PASSWORD > /root/dm_password didn't work as I had expected meaning everything after the dollar was interpreted as a variable and was missing in the file. I have corrected this and performed the full process again, starting with the 389 reset however it is still not working correctly. I remain in the same state as before where the admin password has not been changed - this confuses me as my understanding is that admin only exists as the FreeIPA web admin user whose password I can change separately. Am i misunderstanding, is there another admin user within FreeIPA which is directly linked to the directory manager? Having run out of ideas I have just executed ipa-server-upgrade however this hasn't helped. My situation remains as follows: Works: ldapsearch -x -D "cn=directory manager" -w NEW_DM_PW -s base -b "" "objectclass=*" Fails: ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" -w NEW_DM_PW -b "" -s base Are you able to offer any other ideas? Other information: I can confirm that cacert.p12 has been updated by the actions performed. File /etc/pki/pki-tomcat/password.conf now contains a new line internaldb=NEW_DM_PW (as per instruction 1 on FreeIPA link) Best Regards, Callum On Mon, Dec 5, 2016 at 1:08 PM Florence Blanc-Renaud > wrote: On 12/05/2016 01:05 PM, Callum Guy wrote: > Hi All, > > I have been testing FreeIPA and now plan to migrate to production use - > thanks for creating such a great application! > > During the test phase we have been using simple passwords for the admin > and directory manager users however we need these changed before moving > into production. I believe we can change the admin password using the > web interface however as I understand it amending the directory manager > password is not so straightforward. > > I have found this > link https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password however > I am unsure if this is the correct procedure for our installation - > certainly i am having no luck so far. > > We have the following setup: > > FreeIPA 4.2.0 - single master server (no replicas), multiple clients > CentOS 7.2 > > I have tried the following steps in order: > > http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html > followed by > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > After completing that I am no longer able to authenticate user logins. > The below covers my current situation: > > This works: > ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" > "objectclass=*" > > This does not work: > ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" > "objectclass=*" > > This works: > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > -W -b "" -s base > OLDPASSWORD > > This does not work: > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > -W -b "" -s base > NEWPASSWORD > Hi, your commands show that the Directory Manager password was properly modified, but not admin's password. Did you run the step 3 Updating PKI admin password of the procedure [1]? ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W -T /root/dm_password "uid=admin,ou=people,o=ipaca" Flo. [1] https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password > So i'm i a mixed up state! Is anyone able to offer advise on resolving > this issue? > > Thank you, > > 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. > > > [http://www.x-on.co.uk/email/footer/banner-x-on.jpg] 0333 332 0000 | www.x-on.co.uk | [http://www.x-on.co.uk/images/icon/linkedin.png] [http://www.x-on.co.uk/images/icon/facebook.png] [http://www.x-on.co.uk/images/icon/twitter.png] 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. [http://www.x-on.co.uk/email/footer/banner-x-on.jpg] 0333 332 0000 | www.x-on.co.uk | [http://www.x-on.co.uk/images/icon/linkedin.png] [http://www.x-on.co.uk/images/icon/facebook.png] [http://www.x-on.co.uk/images/icon/twitter.png] 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 tkrizek at redhat.com Mon Dec 5 16:51:59 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Mon, 5 Dec 2016 17:51:59 +0100 Subject: [Freeipa-users] Let's Encrypt along with FreeIPA In-Reply-To: References: <608a680e-0761-1984-733a-f6a6cbd2600a@redhat.com> Message-ID: <0af9dbd3-e406-a615-f17d-9908a9d8b850@redhat.com> Please keep freeipa-users at redhat.com in CC. On 12/05/2016 05:23 PM, Joseph Flynn wrote: > By the way Tomas, can you recommend a good read to better understand > how all of these certs play together in an architecture like this? > I'm quite confident in Linux usage an admin but must admit this is not > quite clear to me. The chain of trust on the Let's Encrypt side is explained in https://letsencrypt.org/certificates/ On the FreeIPA side, there are some articles on our wiki page related to Public Key Infrastructure, for example http://www.freeipa.org/page/PKI > > On Mon, Dec 5, 2016 at 11:19 AM, Joseph Flynn >wrote: > > Thank you for responding Tom. > > I created the CentOS 7 VM earlier in the week and did its updates > and set the hostnames, etc and took a snapshot. I also tried on > Ubuntu first but that had too many install hiccups. > > From that snapshot I have tried several times with the same > results as recently as yesterday. > > Here is the output of your suggestion: > > [jjflynn22 at ipa-1 ~]$ sudo certutil -d /etc/httpd/alias/ -L > [sudo] password for jjflynn22: > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > Signing-Cert u,u,u > DSTRootCAX3 C,, > ipaCert u,u,u > Server-Cert u,u,u > KKGPITT.ORG IPA CA CT,C,C > This seems correct, however this information can be misleading if DSTRootCAX3 was installed in FreeIPA before. The last thing I can think of is to verify that the Subject Field of DTSRootCAX3 is in fact the same as the Issuer Field in the LetsEncryptAuthorityX3 certificate. I've checked the ones that are used in the git repo and they are correct, so I can't see how this could be the issue, but just to verify: openssl x509 -text -in /root/ipa-le/ca/DSTRootCAX3.pem | grep 'Subject:' openssl x509 -text -in /root/ipa-le/ca/LetsEncryptAuthorityX3.pem | grep 'Issuer:' If that doesn't reveal any difference, I'd suggest to attempt to reproduce the issue with a clean environment (new VM) and if you still encounter the same problem, please open an issue and provide as much information as possible, including software versions. https://github.com/freeipa/freeipa-letsencrypt/issues > > > > Joe > > > > On Mon, Dec 5, 2016 at 10:35 AM, Tomas Krizek >wrote: > > > > On 12/05/2016 12:25 AM, Joseph Flynn wrote: >> Sorry if this is not the appropriate forum for discussing >> this topic. >> >> I have installed a FreeIPA system on CentOS 7 and am trying >> to get the Let's Encrypt scripts to work as defined in >> https://github.com/freeipa/freeipa-letsencrypt >> >> >> I hand to tinker with a combination of enabling/disabling >> EPEL and this new tool DNF that I am not too familiar with >> but eventually got the script to run. >> >> It is ending with the following error: >> >> ipa: INFO: Systemwide CA database updated. >> ipa.ipaclient.ipa_certupdate.CertUpdate: INFO: The >> ipa-certupdate command was successful >> Directory Manager password: >> >> Installing CA certificate, please wait >> Not a valid CA certificate: (SEC_ERROR_UNKNOWN_ISSUER) >> Peer's Certificate issuer is not recognized. (visit >> http://www.freeipa.org/page/Troubleshooting >> for >> troubleshooting guide) >> >> >> Does anyone recognize this situation? >> >> I have installed this on a VirtualBox client in Bridge >> Network mode. Prior to trying to use a real certificate, I >> could access the FreeIPA UI from Firefox on both the VM and >> other computers in the home. I've gotten a domain name and >> have that domain name pointed to my home router with a >> handful of ports (those listed at the end of the FreeIPA >> install) forwarded to my VM. >> >> For completeness, I have included the history below along >> with the full output including a couple of highlighted areas >> that could be errors. >> >> Thanks for any assistance from anyone who might notice an >> error in my ways. >> Joe >> >> >> History: >> 1 ifconfig -a >> 2 sudo yum -y update >> 3 cat /etc/hostname >> 4 sudo echo 192.168.1.201 ipa-1.kkgpitt.org >> ipa-1 >> /etc/hosts >> 5 sudo vi /etc/hosts >> 7 sudo reboot now >> 8 hostname >> 9 ifconfig -a >> 11 sudo visudo >> 12 sudo ls # just to set pw >> 13 sudo yum install epel-release -y >> 14 sudo yum install -y haveged >> 15 sudo systemctl start haveged.service >> 16 sudo ipa-server-install >> 17 kinit admin >> 18 firewall-cmd --permanent --add-service=ntp >> 19 firewall-cmd --permanent --add-service=http >> 20 firewall-cmd --permanent --add-service=https >> 21 firewall-cmd --permanent --add-service=ldap >> 22 firewall-cmd --permanent --add-service=ldaps >> 23 firewall-cmd --permanent --add-service=kerberos >> 24 firewall-cmd --permanent --add-service=kpasswd >> 26 sudo authconfig --enablemkhomedir --update >> 27 sudo chkconfig sssd on >> 28 git config --global user.name "Joe >> Flynn" >> 29 git config --global user.email "jjflynn22 at gmail.com >> " >> 30 mkdir ~/.ssh >> 31 cd ~/.ssh >> 32 vi id_rsa >> 33 vi id_rsa.pub >> 34 chmod 700 ~/.ssh >> 35 chmod 600 ~/.ssh/* >> 36 ssh-add ~/.ssh/id_rsa >> 37 sudo yum install -y letsencrypt >> 38 sudo cp -r /etc/httpd/alias /etc/httpd/alias_backup >> 39 cd ~ >> 40 git clone >> https://github.com/freeipa/freeipa-letsencrypt.git >> >> 41 sudo cp -r freeipa-letsencrypt /root/ipa-le >> 42 sudo vi /root/ipa-le/renew-le.sh >> 43 sudo yum install -y dnf >> 44 sudo yum remove -y epel-release >> 45 sudo dnf repolist >> 46 sudo /root/ipa-le/setup-le.sh >> 47 history >> >> >> >> [jjflynn22 at ipa-1 ~]$ sudo visudo >> [sudo] password for jjflynn22: >> [jjflynn22 at ipa-1 ~]$ sudo yum install epel-release -y >> Loaded plugins: fastestmirror, langpacks >> base | 3.6 kB 00:00:00 >> extras | 3.4 kB 00:00:00 >> updates | 3.4 kB 00:00:00 >> Loading mirror speeds from cached hostfile >> * base: repo1.ash.innoscale.net >> >> * extras: mirrors.advancedhosters.com >> >> * updates: mirror.cs.vt.edu >> Resolving Dependencies >> --> Running transaction check >> ---> Package epel-release.noarch 0:7-6 will be installed >> --> Finished Dependency Resolution >> >> Dependencies Resolved >> >> ============================================================================================================================= >> Package Arch Version Repository Size >> ============================================================================================================================= >> Installing: >> epel-release noarch 7-6 extras 14 k >> >> Transaction Summary >> ============================================================================================================================= >> Install 1 Package >> >> Total download size: 14 k >> Installed size: 24 k >> Downloading packages: >> epel-release-7-6.noarch.rpm | 14 kB 00:00:00 >> Running transaction check >> Running transaction test >> Transaction test succeeded >> Running transaction >> Installing : epel-release-7-6.noarch 1/1 >> Verifying : epel-release-7-6.noarch 1/1 >> >> Installed: >> epel-release.noarch 0:7-6 >> >> Complete! >> [jjflynn22 at ipa-1 ~]$ sudo yum install -y haveged >> Loaded plugins: fastestmirror, langpacks >> epel/x86_64/metalink | 13 kB 00:00:00 >> epel | 4.3 kB 00:00:00 >> (1/3): epel/x86_64/updateinfo | 676 kB 00:00:00 >> (2/3): epel/x86_64/group_gz | 170 kB 00:00:00 >> (3/3): epel/x86_64/primary_db | 4.4 MB 00:00:01 >> Loading mirror speeds from cached hostfile >> * base: repo1.ash.innoscale.net >> >> * epel: ftp.osuosl.org >> * extras: mirror.fusioncloud.co >> >> * updates: ftp.osuosl.org >> Resolving Dependencies >> --> Running transaction check >> ---> Package haveged.x86_64 0:1.9.1-1.el7 will be installed >> --> Finished Dependency Resolution >> >> Dependencies Resolved >> >> ============================================================================================================================= >> Package Arch Version Repository Size >> ============================================================================================================================= >> Installing: >> haveged x86_64 1.9.1-1.el7 epel 61 k >> >> Transaction Summary >> ============================================================================================================================= >> Install 1 Package >> >> Total download size: 61 k >> Installed size: 181 k >> Downloading packages: >> warning: >> /var/cache/yum/x86_64/7/epel/packages/haveged-1.9.1-1.el7.x86_64.rpm: >> Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY >> Public key for haveged-1.9.1-1.el7.x86_64.rpm is not >> installed >> haveged-1.9.1-1.el7.x86_64.rpm | 61 kB 00:00:00 >> Retrieving key from >> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 >> Importing GPG key 0x352C64E5: >> Userid : "Fedora EPEL (7) > >" >> Fingerprint: 91e9 7d7c 4a5e 96f1 7f3e 888f 6a2f aea2 >> 352c 64e5 >> Package : epel-release-7-6.noarch (@extras) >> From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 >> Running transaction check >> Running transaction test >> Transaction test succeeded >> Running transaction >> Installing : haveged-1.9.1-1.el7.x86_64 1/1 >> Verifying : haveged-1.9.1-1.el7.x86_64 1/1 >> >> Installed: >> haveged.x86_64 0:1.9.1-1.el7 >> >> Complete! >> [jjflynn22 at ipa-1 ~]$ sudo systemctl start haveged.service >> [jjflynn22 at ipa-1 ~]$ >> [jjflynn22 at ipa-1 ~]$ >> [jjflynn22 at ipa-1 ~]$ >> [jjflynn22 at ipa-1 ~]$ >> [jjflynn22 at ipa-1 ~]$ sudo ipa-server-install >> >> The log file for this installation can be found in >> /var/log/ipaserver-install.log >> ============================================================================== >> This program will set up the IPA Server. >> >> This includes: >> * Configure a stand-alone CA (dogtag) for certificate >> management >> * Configure the Network Time Daemon (ntpd) >> * Create and configure an instance of Directory Server >> * Create and configure a Kerberos Key Distribution >> Center (KDC) >> * Configure Apache (httpd) >> >> To accept the default shown in brackets, press the Enter key. >> >> WARNING: conflicting time&date synchronization service >> 'chronyd' will be disabled >> in favor of ntpd >> >> Do you want to configure integrated DNS (BIND)? [no]: >> >> Enter the fully qualified domain name of the computer >> on which you're setting up server software. Using the form >> . >> Example: master.example.com . >> >> >> Server host name [ipa-1.kkgpitt.org >> ]: >> >> The domain name has been determined based on the host name. >> >> Please confirm the domain name [kkgpitt.org >> ]: >> >> The kerberos protocol requires a Realm name to be defined. >> This is typically the domain name converted to uppercase. >> >> Please provide a realm name [KKGPITT.ORG >> ]: >> Certain directory server operations require an >> administrative user. >> This user is referred to as the Directory Manager and has >> full access >> to the Directory for system management tasks and will be >> added to the >> instance of directory server created for IPA. >> The password must be at least 8 characters long. >> >> Directory Manager password: >> Password (confirm): >> >> The IPA server requires an administrative user, named >> 'admin'. >> This user is a regular system account used for IPA server >> administration. >> >> IPA admin password: >> Password (confirm): >> >> >> The IPA Master Server will be configured with: >> Hostname: ipa-1.kkgpitt.org >> IP address(es): 192.168.1.201 >> Domain name: kkgpitt.org >> Realm name: KKGPITT.ORG >> >> Continue to configure the system with these values? [no]: yes >> >> The following operations may take some minutes to complete. >> Please wait until the prompt is returned. >> >> Configuring NTP daemon (ntpd) >> [1/4]: stopping ntpd >> [2/4]: writing configuration >> [3/4]: configuring ntpd to start on boot >> [4/4]: starting ntpd >> Done configuring NTP daemon (ntpd). >> Configuring directory server (dirsrv). Estimated time: 1 >> minute >> [1/42]: creating directory server user >> [2/42]: creating directory server instance >> [3/42]: adding default schema >> [4/42]: enabling memberof plugin >> [5/42]: enabling winsync plugin >> [6/42]: configuring replication version plugin >> [7/42]: enabling IPA enrollment plugin >> [8/42]: enabling ldapi >> [9/42]: configuring uniqueness plugin >> [10/42]: configuring uuid plugin >> [11/42]: configuring modrdn plugin >> [12/42]: configuring DNS plugin >> [13/42]: enabling entryUSN plugin >> [14/42]: configuring lockout plugin >> [15/42]: creating indices >> [16/42]: enabling referential integrity plugin >> [17/42]: configuring certmap.conf >> [18/42]: configure autobind for root >> [19/42]: configure new location for managed entries >> [20/42]: configure dirsrv ccache >> [21/42]: enable SASL mapping fallback >> [22/42]: restarting directory server >> [23/42]: adding default layout >> [24/42]: adding delegation layout >> [25/42]: creating container for managed entries >> [26/42]: configuring user private groups >> [27/42]: configuring netgroups from hostgroups >> [28/42]: creating default Sudo bind user >> [29/42]: creating default Auto Member layout >> [30/42]: adding range check plugin >> [31/42]: creating default HBAC rule allow_all >> [32/42]: adding entries for topology management >> [33/42]: initializing group membership >> [34/42]: adding master entry >> [35/42]: initializing domain level >> [36/42]: configuring Posix uid/gid generation >> [37/42]: adding replication acis >> [38/42]: enabling compatibility plugin >> [39/42]: activating sidgen plugin >> [40/42]: activating extdom plugin >> [41/42]: tuning directory server >> [42/42]: configuring directory to start on boot >> Done configuring directory server (dirsrv). >> Configuring certificate server (pki-tomcatd). Estimated >> time: 3 minutes 30 seconds >> [1/28]: creating certificate server user >> [2/28]: configuring certificate server instance >> [3/28]: stopping certificate server instance to update >> CS.cfg >> [4/28]: backing up CS.cfg >> [5/28]: disabling nonces >> [6/28]: set up CRL publishing >> [7/28]: enable PKIX certificate path discovery and >> validation >> [8/28]: starting certificate server instance >> [9/28]: creating RA agent certificate database >> [10/28]: importing CA chain to RA certificate database >> [11/28]: fixing RA database permissions >> [12/28]: setting up signing cert profile >> [13/28]: setting audit signing renewal to 2 years >> [14/28]: restarting certificate server >> [15/28]: requesting RA certificate from CA >> [16/28]: issuing RA agent certificate >> [17/28]: adding RA agent as a trusted user >> [18/28]: authorizing RA to modify profiles >> [19/28]: configure certmonger for renewals >> [20/28]: configure certificate renewals >> [21/28]: configure RA certificate renewal >> [22/28]: configure Server-Cert certificate renewal >> [23/28]: Configure HTTP to proxy connections >> [24/28]: restarting certificate server >> [25/28]: migrating certificate profiles to LDAP >> [26/28]: importing IPA certificate profiles >> [27/28]: adding default CA ACL >> [28/28]: updating IPA configuration >> Done configuring certificate server (pki-tomcatd). >> Configuring directory server (dirsrv). Estimated time: 10 >> seconds >> [1/3]: configuring ssl for ds instance >> [2/3]: restarting directory server >> [3/3]: adding CA certificate entry >> Done configuring directory server (dirsrv). >> Configuring Kerberos KDC (krb5kdc). Estimated time: 30 >> seconds >> [1/10]: adding sasl mappings to the directory >> [2/10]: adding kerberos container to the directory >> [3/10]: configuring KDC >> [4/10]: initialize kerberos container >> [5/10]: adding default ACIs >> [6/10]: creating a keytab for the directory >> [7/10]: creating a keytab for the machine >> [8/10]: adding the password extension to the directory >> [9/10]: starting the KDC >> [10/10]: configuring KDC to start on boot >> Done configuring Kerberos KDC (krb5kdc). >> Configuring kadmin >> [1/2]: starting kadmin >> [2/2]: configuring kadmin to start on boot >> Done configuring kadmin. >> Configuring ipa_memcached >> [1/2]: starting ipa_memcached >> [2/2]: configuring ipa_memcached to start on boot >> Done configuring ipa_memcached. >> Configuring ipa-otpd >> [1/2]: starting ipa-otpd >> [2/2]: configuring ipa-otpd to start on boot >> Done configuring ipa-otpd. >> Configuring the web interface (httpd). Estimated time: 1 >> minute >> [1/19]: setting mod_nss port to 443 >> [2/19]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2 >> [3/19]: setting mod_nss password file >> [4/19]: enabling mod_nss renegotiate >> [5/19]: adding URL rewriting rules >> [6/19]: configuring httpd >> [7/19]: configure certmonger for renewals >> [8/19]: setting up ssl >> [9/19]: importing CA certificates from LDAP >> [10/19]: setting up browser autoconfig >> [11/19]: publish CA cert >> [12/19]: creating a keytab for httpd >> [13/19]: clean up any existing httpd ccache >> [14/19]: configuring SELinux for httpd >> [15/19]: create KDC proxy user >> [16/19]: create KDC proxy config >> [17/19]: enable KDC proxy >> [18/19]: restarting httpd >> [19/19]: configuring httpd to start on boot >> Done configuring the web interface (httpd). >> Applying LDAP updates >> Upgrading IPA: >> [1/9]: stopping directory server >> [2/9]: saving configuration >> [3/9]: disabling listeners >> [4/9]: enabling DS global lock >> [5/9]: starting directory server >> [6/9]: upgrading server >> [7/9]: stopping directory server >> [8/9]: restoring configuration >> [9/9]: starting directory server >> Done. >> Restarting the directory server >> Restarting the KDC >> Sample zone file for bind has been created in >> /tmp/sample.zone.Yjwpca.db >> Restarting the web server >> ============================================================================== >> Setup complete >> >> Next steps: >> 1. You must make sure these network ports are open: >> TCP Ports: >> * 80, 443: HTTP/HTTPS >> * 389, 636: LDAP/LDAPS >> * 88, 464: kerberos >> UDP Ports: >> * 88, 464: kerberos >> * 123: ntp >> >> 2. You can now obtain a kerberos ticket using the >> command: 'kinit admin' >> This ticket will allow you to use the IPA tools >> (e.g., ipa user-add) >> and the web user interface. >> >> Be sure to back up the CA certificates stored in >> /root/cacert.p12 >> These files are required to create replicas. The password >> for these >> files is the Directory Manager password >> [jjflynn22 at ipa-1 ~]$ kinit admin >> Password for admin at KKGPITT.ORG : >> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >> --add-service=ntp >> success >> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >> --add-service=http >> success >> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >> --add-service=https >> success >> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >> --add-service=ldap >> success >> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >> --add-service=ldaps >> success >> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >> --add-service=kerberos >> success >> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >> --add-service=kpasswd >> success >> [jjflynn22 at ipa-1 ~]$ sudo authconfig --enablemkhomedir >> --update >> [jjflynn22 at ipa-1 ~]$ sudo chkconfig sssd on >> Note: Forwarding request to 'systemctl enable sssd.service'. >> [jjflynn22 at ipa-1 ~]$ git config --global user.name >> "Joe Flynn" >> [jjflynn22 at ipa-1 ~]$ git config --global user.email >> "jjflynn22 at gmail.com " >> [jjflynn22 at ipa-1 ~]$ mkdir ~/.ssh >> [jjflynn22 at ipa-1 ~]$ cd ~/.ssh >> [jjflynn22 at ipa-1 .ssh]$ vi id_rsa >> [jjflynn22 at ipa-1 .ssh]$ vi id_rsa.pub >> [jjflynn22 at ipa-1 .ssh]$ chmod 700 ~/.ssh >> [jjflynn22 at ipa-1 .ssh]$ chmod 600 ~/.ssh/* >> [jjflynn22 at ipa-1 .ssh]$ ssh-add ~/.ssh/id_rsa >> Identity added: /home/jjflynn22/.ssh/id_rsa >> (/home/jjflynn22/.ssh/id_rsa) >> [jjflynn22 at ipa-1 .ssh]$ sudo yum install -y letsencrypt >> Loaded plugins: fastestmirror, langpacks >> Loading mirror speeds from cached hostfile >> * base: repo1.ash.innoscale.net >> >> * epel: mirror.cogentco.com >> * extras: chicago.gaminghost.co >> >> * updates: mirror.cs.vt.edu >> Resolving Dependencies >> --> Running transaction check >> ---> Package certbot.noarch 0:0.9.3-1.el7 will be installed >> --> Processing Dependency: python2-certbot = 0.9.3-1.el7 >> for package: certbot-0.9.3-1.el7.noarch >> --> Running transaction check >> ---> Package python2-certbot.noarch 0:0.9.3-1.el7 will be >> installed >> --> Processing Dependency: python2-acme = 0.9.3 for >> package: python2-certbot-0.9.3-1.el7.no >> arch >> --> Processing Dependency: python2-dialog >= 3.3.0 for >> package: python2-certbot-0.9.3-1.el7.no >> arch >> --> Processing Dependency: python2-configargparse >= >> 0.10.0 for package: python2-certbot-0.9.3-1.el7.no >> arch >> --> Processing Dependency: python-psutil >= 2.1.0 for >> package: python2-certbot-0.9.3-1.el7.no >> arch >> --> Processing Dependency: python-zope-interface for >> package: python2-certbot-0.9.3-1.el7.no >> arch >> --> Processing Dependency: python-zope-component for >> package: python2-certbot-0.9.3-1.el7.no >> arch >> --> Processing Dependency: python-parsedatetime for >> package: python2-certbot-0.9.3-1.el7.no >> arch >> --> Processing Dependency: python-mock for package: >> python2-certbot-0.9.3-1.el7.no >> arch >> --> Running transaction check >> ---> Package python-parsedatetime.noarch 0:1.5-3.el7 will >> be installed >> ---> Package python-psutil.x86_64 0:2.2.1-1.el7 will be >> installed >> ---> Package python-zope-component.noarch 1:4.1.0-1.el7 >> will be installed >> --> Processing Dependency: python-zope-event for package: >> 1:python-zope-component-4.1.0-1.el7.noarch >> ---> Package python-zope-interface.x86_64 0:4.0.5-4.el7 >> will be installed >> ---> Package python2-acme.noarch 0:0.9.3-1.el7 will be >> installed >> --> Processing Dependency: python-pyrfc3339 for package: >> python2-acme-0.9.3-1.el7.noarch >> --> Processing Dependency: python-ndg_httpsclient for >> package: python2-acme-0.9.3-1.el7.noarch >> ---> Package python2-configargparse.noarch 0:0.10.0-1.el7 >> will be installed >> ---> Package python2-dialog.noarch 0:3.3.0-6.el7 will be >> installed >> --> Processing Dependency: dialog for package: >> python2-dialog-3.3.0-6.el7.noarch >> ---> Package python2-mock.noarch 0:1.0.1-9.el7 will be >> installed >> --> Running transaction check >> ---> Package dialog.x86_64 0:1.2-4.20130523.el7 will be >> installed >> ---> Package python-ndg_httpsclient.noarch 0:0.3.2-1.el7 >> will be installed >> ---> Package python-zope-event.noarch 0:4.0.3-2.el7 will >> be installed >> ---> Package python2-pyrfc3339.noarch 0:1.0-2.el7 will be >> installed >> --> Finished Dependency Resolution >> >> Dependencies Resolved >> >> ============================================================================================================================= >> Package Arch Version Repository Size >> ============================================================================================================================= >> Installing: >> certbot noarch 0.9.3-1.el7 epel 16 k >> Installing for dependencies: >> dialog x86_64 1.2-4.20130523.el7 base 208 k >> python-ndg_httpsclient noarch 0.3.2-1.el7 >> epel 43 k >> python-parsedatetime noarch 1.5-3.el7 >> epel 61 k >> python-psutil x86_64 2.2.1-1.el7 epel 114 k >> python-zope-component noarch 1:4.1.0-1.el7 >> epel 110 k >> python-zope-event noarch 4.0.3-2.el7 >> epel 79 k >> python-zope-interface x86_64 4.0.5-4.el7 >> base 138 k >> python2-acme noarch 0.9.3-1.el7 epel 168 k >> python2-certbot noarch 0.9.3-1.el7 epel >> 361 k >> python2-configargparse noarch 0.10.0-1.el7 >> epel 28 k >> python2-dialog noarch 3.3.0-6.el7 epel 94 k >> python2-mock noarch 1.0.1-9.el7 epel 92 k >> python2-pyrfc3339 noarch 1.0-2.el7 epel >> 13 k >> >> Transaction Summary >> ============================================================================================================================= >> Install 1 Package (+13 Dependent packages) >> >> Total download size: 1.5 M >> Installed size: 6.3 M >> Downloading packages: >> (1/14): python-ndg_httpsclient-0.3.2-1.el7.noarch.rpm | >> 43 kB 00:00:00 >> (2/14): dialog-1.2-4.20130523.el7.x86_64.rpm | 208 kB >> 00:00:00 >> (3/14): certbot-0.9.3-1.el7.noarch.rpm | 16 kB 00:00:00 >> (4/14): python-parsedatetime-1.5-3.el7.noarch.rpm | 61 >> kB 00:00:00 >> (5/14): python-psutil-2.2.1-1.el7.x86_64.rpm | 114 kB >> 00:00:00 >> (6/14): python-zope-component-4.1.0-1.el7.noarch.rpm | >> 110 kB 00:00:00 >> (7/14): python-zope-interface-4.0.5-4.el7.x86_64.rpm | >> 138 kB 00:00:00 >> (8/14): python-zope-event-4.0.3-2.el7.noarch.rpm | 79 >> kB 00:00:00 >> (9/14): python2-certbot-0.9.3-1.el7.no >> arch.rpm | 361 kB >> 00:00:00 >> (10/14): python2-configargparse-0.10.0-1.el7.noarch.rpm >> | 28 kB 00:00:00 >> (11/14): python2-acme-0.9.3-1.el7.noarch.rpm | 168 kB >> 00:00:00 >> (12/14): python2-dialog-3.3.0-6.el7.noarch.rpm | 94 kB >> 00:00:00 >> (13/14): python2-pyrfc3339-1.0-2.el7.no >> arch.rpm | 13 kB >> 00:00:00 >> (14/14): python2-mock-1.0.1-9.el7.noarch.rpm | 92 kB >> 00:00:00 >> ----------------------------------------------------------------------------------------------------------------------------- >> Total 1.3 MB/s | 1.5 MB 00:00:01 >> Running transaction check >> Running transaction test >> Transaction test succeeded >> Running transaction >> Installing : python-zope-interface-4.0.5-4.el7.x86_64 1/14 >> Installing : python2-mock-1.0.1-9.el7.noarch 2/14 >> Installing : python-parsedatetime-1.5-3.el7.noarch 3/14 >> Installing : python-psutil-2.2.1-1.el7.x86_64 4/14 >> Installing : python-zope-event-4.0.3-2.el7.noarch 5/14 >> Installing : 1:python-zope-component-4.1.0-1.el7.noarch >> 6/14 >> Installing : python-ndg_httpsclient-0.3.2-1.el7.noarch >> 7/14 >> Installing : python2-pyrfc3339-1.0-2.el7.no >> arch 8/14 >> Installing : python2-acme-0.9.3-1.el7.noarch 9/14 >> Installing : python2-configargparse-0.10.0-1.el7.noarch >> 10/14 >> Installing : dialog-1.2-4.20130523.el7.x86_64 11/14 >> Installing : python2-dialog-3.3.0-6.el7.noarch 12/14 >> Installing : python2-certbot-0.9.3-1.el7.no >> arch 13/14 >> Installing : certbot-0.9.3-1.el7.noarch 14/14 >> Verifying : dialog-1.2-4.20130523.el7.x86_64 1/14 >> Verifying : certbot-0.9.3-1.el7.noarch 2/14 >> Verifying : python2-configargparse-0.10.0-1.el7.noarch >> 3/14 >> Verifying : python2-pyrfc3339-1.0-2.el7.no >> arch 4/14 >> Verifying : python-zope-interface-4.0.5-4.el7.x86_64 5/14 >> Verifying : python-ndg_httpsclient-0.3.2-1.el7.noarch >> 6/14 >> Verifying : python-zope-event-4.0.3-2.el7.noarch 7/14 >> Verifying : python-psutil-2.2.1-1.el7.x86_64 8/14 >> Verifying : python2-acme-0.9.3-1.el7.noarch 9/14 >> Verifying : python2-dialog-3.3.0-6.el7.noarch 10/14 >> Verifying : 1:python-zope-component-4.1.0-1.el7.noarch >> 11/14 >> Verifying : python-parsedatetime-1.5-3.el7.noarch 12/14 >> Verifying : python2-certbot-0.9.3-1.el7.no >> arch 13/14 >> Verifying : python2-mock-1.0.1-9.el7.noarch 14/14 >> >> Installed: >> certbot.noarch 0:0.9.3-1.el7 >> >> Dependency Installed: >> dialog.x86_64 0:1.2-4.20130523.el7 >> python-ndg_httpsclient.noarch 0:0.3.2-1.el7 >> python-parsedatetime.noarch 0:1.5-3.el7 >> python-psutil.x86_64 0:2.2.1-1.el7 >> python-zope-component.noarch 1:4.1.0-1.el7 >> python-zope-event.noarch 0:4.0.3-2.el7 >> python-zope-interface.x86_64 0:4.0.5-4.el7 >> python2-acme.noarch 0:0.9.3-1.el7 >> python2-certbot.noarch 0:0.9.3-1.el7 >> python2-configargparse.noarch 0:0.10.0-1.el7 >> python2-dialog.noarch 0:3.3.0-6.el7 python2-mock.noarch >> 0:1.0.1-9.el7 >> python2-pyrfc3339.noarch 0:1.0-2.el7 >> >> Complete! >> [jjflynn22 at ipa-1 .ssh]$ >> [jjflynn22 at ipa-1 .ssh]$ >> [jjflynn22 at ipa-1 .ssh]$ sudo cp -r /etc/httpd/alias >> /etc/httpd/alias_backup >> [jjflynn22 at ipa-1 .ssh]$ cd ~ >> [jjflynn22 at ipa-1 ~]$ git clone >> https://github.com/freeipa/freeipa-letsencrypt.git >> >> Cloning into 'freeipa-letsencrypt'... >> remote: Counting objects: 45, done. >> remote: Compressing objects: 100% (4/4), done. >> remote: Total 45 (delta 0), reused 0 (delta 0), >> pack-reused 41 >> Unpacking objects: 100% (45/45), done. >> [jjflynn22 at ipa-1 ~]$ sudo cp -r freeipa-letsencrypt >> /root/ipa-le >> [jjflynn22 at ipa-1 ~]$ sudo vi /root/ipa-le/renew-le.sh >> [jjflynn22 at ipa-1 ~]$ sudo yum install -y dnf >> Loaded plugins: fastestmirror, langpacks >> Loading mirror speeds from cached hostfile >> * base: repo1.ash.innoscale.net >> >> * epel: mirror.cogentco.com >> * extras: mirrors.advancedhosters.com >> >> * updates: mirror.cs.vt.edu >> Resolving Dependencies >> --> Running transaction check >> ---> Package dnf.noarch 0:0.6.4-2.el7 will be installed >> --> Processing Dependency: python-dnf = 0.6.4-2.el7 for >> package: dnf-0.6.4-2.el7.noarch >> --> Running transaction check >> ---> Package python-dnf.noarch 0:0.6.4-2.el7 will be >> installed >> --> Processing Dependency: dnf-conf = 0.6.4-2.el7 for >> package: python-dnf-0.6.4-2.el7.noarch >> --> Processing Dependency: python-librepo >= 1.7.5 for >> package: python-dnf-0.6.4-2.el7.noarch >> --> Processing Dependency: python-libcomps >= 0.1.6 for >> package: python-dnf-0.6.4-2.el7.noarch >> --> Processing Dependency: python-hawkey >= 0.5.3 for >> package: python-dnf-0.6.4-2.el7.noarch >> --> Running transaction check >> ---> Package dnf-conf.noarch 0:0.6.4-2.el7 will be installed >> ---> Package python-hawkey.x86_64 >> 0:0.5.8-2.git.0.202b194.el7 will be installed >> --> Processing Dependency: hawkey(x86-64) = >> 0.5.8-2.git.0.202b194.el7 for package: >> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >> --> Processing Dependency: libsolv.so.0(SOLV_1.0)(64bit) >> for package: python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >> --> Processing Dependency: libsolv.so.0()(64bit) for >> package: python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >> --> Processing Dependency: libhawkey.so.2()(64bit) for >> package: python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >> ---> Package python-libcomps.x86_64 0:0.1.6-13.el7 will >> be installed >> --> Processing Dependency: libcomps(x86-64) = >> 0.1.6-13.el7 for package: python-libcomps-0.1.6-13.el7.x86_64 >> --> Processing Dependency: libcomps.so.0.1.6()(64bit) for >> package: python-libcomps-0.1.6-13.el7.x86_64 >> ---> Package python-librepo.x86_64 0:1.7.16-1.el7 will be >> installed >> --> Processing Dependency: librepo(x86-64) = 1.7.16-1.el7 >> for package: python-librepo-1.7.16-1.el7.x86_64 >> --> Processing Dependency: librepo.so.0()(64bit) for >> package: python-librepo-1.7.16-1.el7.x86_64 >> --> Running transaction check >> ---> Package hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 >> will be installed >> ---> Package libcomps.x86_64 0:0.1.6-13.el7 will be installed >> ---> Package librepo.x86_64 0:1.7.16-1.el7 will be installed >> ---> Package libsolv.x86_64 0:0.6.11-1.el7 will be installed >> --> Finished Dependency Resolution >> >> Dependencies Resolved >> >> ============================================================================================================================= >> Package Arch Version Repository Size >> ============================================================================================================================= >> Installing: >> dnf noarch 0.6.4-2.el7 epel 209 k >> Installing for dependencies: >> dnf-conf noarch 0.6.4-2.el7 epel 61 k >> hawkey x86_64 0.5.8-2.git.0.202b194.el7 >> base 87 k >> libcomps x86_64 0.1.6-13.el7 epel 72 k >> librepo x86_64 1.7.16-1.el7 base 77 k >> libsolv x86_64 0.6.11-1.el7 base 316 k >> python-dnf noarch 0.6.4-2.el7 epel 407 k >> python-hawkey x86_64 0.5.8-2.git.0.202b194.el7 >> base 71 k >> python-libcomps x86_64 0.1.6-13.el7 >> epel 44 k >> python-librepo x86_64 1.7.16-1.el7 base >> 49 k >> >> Transaction Summary >> ============================================================================================================================= >> Install 1 Package (+9 Dependent packages) >> >> Total download size: 1.4 M >> Installed size: 4.1 M >> Downloading packages: >> (1/10): hawkey-0.5.8-2.git.0.202b194.el7.x86_64.rpm | 87 >> kB 00:00:00 >> (2/10): dnf-conf-0.6.4-2.el7.noarch.rpm | 61 kB 00:00:00 >> (3/10): dnf-0.6.4-2.el7.noarch.rpm | 209 kB 00:00:00 >> (4/10): librepo-1.7.16-1.el7.x86_64.rpm | 77 kB 00:00:00 >> (5/10): libcomps-0.1.6-13.el7.x86_64.rpm | 72 kB 00:00:00 >> (6/10): python-librepo-1.7.16-1.el7.x86_64.rpm | 49 kB >> 00:00:00 >> (7/10): python-libcomps-0.1.6-13.el7.x86_64.rpm | 44 kB >> 00:00:00 >> (8/10): >> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64.rpm | 71 >> kB 00:00:00 >> (9/10): python-dnf-0.6.4-2.el7.noarch.rpm | 407 kB 00:00:00 >> (10/10): libsolv-0.6.11-1.el7.x86_64.rpm | 316 kB 00:00:00 >> ----------------------------------------------------------------------------------------------------------------------------- >> Total 1.4 MB/s | 1.4 MB 00:00:01 >> Running transaction check >> Running transaction test >> Transaction test succeeded >> Running transaction >> Installing : libsolv-0.6.11-1.el7.x86_64 1/10 >> Installing : hawkey-0.5.8-2.git.0.202b194.el7.x86_64 2/10 >> Installing : >> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 3/10 >> Installing : dnf-conf-0.6.4-2.el7.noarch 4/10 >> Installing : libcomps-0.1.6-13.el7.x86_64 5/10 >> Installing : python-libcomps-0.1.6-13.el7.x86_64 6/10 >> Installing : librepo-1.7.16-1.el7.x86_64 7/10 >> Installing : python-librepo-1.7.16-1.el7.x86_64 8/10 >> Installing : python-dnf-0.6.4-2.el7.noarch 9/10 >> Installing : dnf-0.6.4-2.el7.noarch 10/10 >> Verifying : librepo-1.7.16-1.el7.x86_64 1/10 >> Verifying : python-libcomps-0.1.6-13.el7.x86_64 2/10 >> Verifying : >> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 3/10 >> Verifying : python-librepo-1.7.16-1.el7.x86_64 4/10 >> Verifying : python-dnf-0.6.4-2.el7.noarch 5/10 >> Verifying : libcomps-0.1.6-13.el7.x86_64 6/10 >> Verifying : hawkey-0.5.8-2.git.0.202b194.el7.x86_64 7/10 >> Verifying : dnf-conf-0.6.4-2.el7.noarch 8/10 >> Verifying : dnf-0.6.4-2.el7.noarch 9/10 >> Verifying : libsolv-0.6.11-1.el7.x86_64 10/10 >> >> Installed: >> dnf.noarch 0:0.6.4-2.el7 >> >> Dependency Installed: >> dnf-conf.noarch 0:0.6.4-2.el7 hawkey.x86_64 >> 0:0.5.8-2.git.0.202b194.el7 >> libcomps.x86_64 0:0.1.6-13.el7 librepo.x86_64 >> 0:1.7.16-1.el7 >> libsolv.x86_64 0:0.6.11-1.el7 python-dnf.noarch >> 0:0.6.4-2.el7 >> python-hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 >> python-libcomps.x86_64 0:0.1.6-13.el7 >> python-librepo.x86_64 0:1.7.16-1.el7 >> >> Complete! >> [jjflynn22 at ipa-1 ~]$ sudo yum remove -y epel-release >> Loaded plugins: fastestmirror, langpacks >> Resolving Dependencies >> --> Running transaction check >> ---> Package epel-release.noarch 0:7-6 will be erased >> --> Finished Dependency Resolution >> >> Dependencies Resolved >> >> ============================================================================================================================= >> Package Arch Version Repository Size >> ============================================================================================================================= >> Removing: >> epel-release noarch 7-6 @extras 24 k >> >> Transaction Summary >> ============================================================================================================================= >> Remove 1 Package >> >> Installed size: 24 k >> Downloading packages: >> Running transaction check >> Running transaction test >> Transaction test succeeded >> Running transaction >> Erasing : epel-release-7-6.noarch 1/1 >> Verifying : epel-release-7-6.noarch 1/1 >> >> Removed: >> epel-release.noarch 0:7-6 >> >> Complete! >> [jjflynn22 at ipa-1 ~]$ sudo dnf repolist >> CentOS-7 - Base 8.4 MB/s | 8.8 MB 00:01 >> CentOS-7 - Updates 4.5 MB/s | 12 MB 00:02 >> CentOS-7 - Extras 1.9 MB/s | 569 kB 00:00 >> Using metadata from Sun Dec 4 18:06:04 2016 >> repo id repo name status >> base CentOS-7 - Base 9,007 >> extras CentOS-7 - Extras 393 >> updates CentOS-7 - Updates 2,560 >> [jjflynn22 at ipa-1 ~]$ sudo /root/ipa-le/setup-le.sh >> Using metadata from Sun Dec 4 18:06:04 2016 >> Package certbot-0.9.3-1.el7.noarch is already installed, >> skipping. >> Dependencies resolved. >> Nothing to do. >> Directory Manager password: >> >> Installing CA certificate, please wait >> CA certificate successfully installed >> The ipa-cacert-manage command was successful >> ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: Not >> logging to a file >> ipa: DEBUG: Loading Index file from >> '/var/lib/ipa-client/sysrestore/sysrestore.index' >> ipa: DEBUG: importing all plugin modules in ipalib.plugins... >> ipa: DEBUG: importing plugin module ipalib.plugins.aci >> ipa: DEBUG: importing plugin module ipalib.plugins.automember >> ipa: DEBUG: importing plugin module ipalib.plugins.automount >> ipa: DEBUG: importing plugin module ipalib.plugins.baseldap >> ipa: DEBUG: importing plugin module ipalib.plugins.baseuser >> ipa: DEBUG: importing plugin module ipalib.plugins.batch >> ipa: DEBUG: importing plugin module ipalib.plugins.caacl >> ipa: DEBUG: importing plugin module ipalib.plugins.cert >> ipa: DEBUG: importing plugin module >> ipalib.plugins.certprofile >> ipa: DEBUG: importing plugin module ipalib.plugins.config >> ipa: DEBUG: importing plugin module ipalib.plugins.delegation >> ipa: DEBUG: importing plugin module ipalib.plugins.dns >> ipa: DEBUG: importing plugin module >> ipalib.plugins.domainlevel >> ipa: DEBUG: importing plugin module ipalib.plugins.group >> ipa: DEBUG: importing plugin module ipalib.plugins.hbacrule >> ipa: DEBUG: importing plugin module ipalib.plugins.hbacsvc >> ipa: DEBUG: importing plugin module >> ipalib.plugins.hbacsvcgroup >> ipa: DEBUG: importing plugin module ipalib.plugins.hbactest >> ipa: DEBUG: importing plugin module ipalib.plugins.host >> ipa: DEBUG: importing plugin module ipalib.plugins.hostgroup >> ipa: DEBUG: importing plugin module ipalib.plugins.idrange >> ipa: DEBUG: importing plugin module ipalib.plugins.idviews >> ipa: DEBUG: importing plugin module ipalib.plugins.internal >> ipa: DEBUG: importing plugin module ipalib.plugins.kerberos >> ipa: DEBUG: importing plugin module ipalib.plugins.krbtpolicy >> ipa: DEBUG: importing plugin module ipalib.plugins.migration >> ipa: DEBUG: importing plugin module ipalib.plugins.misc >> ipa: DEBUG: importing plugin module ipalib.plugins.netgroup >> ipa: DEBUG: importing plugin module ipalib.plugins.otpconfig >> ipa: DEBUG: importing plugin module ipalib.plugins.otptoken >> ipa: DEBUG: importing plugin module >> ipalib.plugins.otptoken_yubikey >> ipa: DEBUG: importing plugin module ipalib.plugins.passwd >> ipa: DEBUG: importing plugin module ipalib.plugins.permission >> ipa: DEBUG: importing plugin module ipalib.plugins.ping >> ipa: DEBUG: importing plugin module ipalib.plugins.pkinit >> ipa: DEBUG: importing plugin module ipalib.plugins.privilege >> ipa: DEBUG: importing plugin module ipalib.plugins.pwpolicy >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='klist' '-V' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout=Kerberos 5 version 1.13.2 >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: importing plugin module >> ipalib.plugins.radiusproxy >> ipa: DEBUG: importing plugin module >> ipalib.plugins.realmdomains >> ipa: DEBUG: importing plugin module ipalib.plugins.role >> ipa: DEBUG: importing plugin module ipalib.plugins.rpcclient >> ipa: DEBUG: importing plugin module >> ipalib.plugins.selfservice >> ipa: DEBUG: importing plugin module >> ipalib.plugins.selinuxusermap >> ipa: DEBUG: importing plugin module ipalib.plugins.server >> ipa: DEBUG: importing plugin module ipalib.plugins.service >> ipa: DEBUG: importing plugin module >> ipalib.plugins.servicedelegation >> ipa: DEBUG: importing plugin module ipalib.plugins.session >> ipa: DEBUG: importing plugin module ipalib.plugins.stageuser >> ipa: DEBUG: importing plugin module ipalib.plugins.sudocmd >> ipa: DEBUG: importing plugin module >> ipalib.plugins.sudocmdgroup >> ipa: DEBUG: importing plugin module ipalib.plugins.sudorule >> ipa: DEBUG: importing plugin module ipalib.plugins.topology >> ipa: DEBUG: importing plugin module ipalib.plugins.trust >> ipa: DEBUG: importing plugin module ipalib.plugins.user >> ipa: DEBUG: importing plugin module ipalib.plugins.vault >> ipa: DEBUG: importing plugin module ipalib.plugins.virtual >> ipa: DEBUG: Initializing principal >> host/ipa-1.kkgpitt.org at KKGPITT.ORG >> using keytab >> /etc/krb5.keytab >> ipa: DEBUG: using ccache /tmp/tmp-zgrScg/ccache >> ipa: DEBUG: Attempt 1/1: success >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='keyctl' 'search' '@s' 'user' >> 'ipa_session_cookie:host/ipa-1.kkgpitt.org at KKGPITT.ORG >> ' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout=134111920 >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='keyctl' 'pipe' '134111920' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: >> stdout=ipa_session=59c01d94b52f0586e30046bd36ef93a5; >> Domain=ipa-1.kkgpitt.org ; >> Path=/ipa; Expires=Sun, 04 Dec 2016 23:21:13 GMT; Secure; >> HttpOnly >> ipa: DEBUG: stderr= >> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: found >> session_cookie in persistent storage for principal >> 'host/ipa-1.kkgpitt.org at KKGPITT.ORG >> ', cookie: >> 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; >> Domain=ipa-1.kkgpitt.org ; >> Path=/ipa; Expires=Sun, 04 Dec 2016 23:21:13 GMT; Secure; >> HttpOnly' >> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: setting >> session_cookie into context >> 'ipa_session=59c01d94b52f0586e30046bd36ef93a5;' >> ipa.ipalib.plugins.rpcclient.rpcclient: INFO: trying >> https://ipa-1.kkgpitt.org/ipa/session/json >> >> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: Created >> connection context.rpcclient_71021840 >> ipa.ipalib.plugins.rpcclient.rpcclient: INFO: Forwarding >> 'ca_is_enabled' to json server >> 'https://ipa-1.kkgpitt.org/ipa/session/json >> ' >> ipa: DEBUG: NSSConnection init ipa-1.kkgpitt.org >> >> ipa: DEBUG: Connecting: 192.168.1.201:0 >> >> ipa: DEBUG: approved_usage = SSL Server intended_usage = >> SSL Server >> ipa: DEBUG: cert valid True for "CN=ipa-1.kkgpitt.org >> ,O=KKGPITT.ORG >> " >> ipa: DEBUG: handshake complete, peer = 192.168.1.201:443 >> >> ipa: DEBUG: Protocol: TLS1.2 >> ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_256_CBC_SHA >> ipa: DEBUG: received Set-Cookie >> 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; >> Domain=ipa-1.kkgpitt.org ; >> Path=/ipa; Expires=Sun, 04 Dec 2016 23:26:28 GMT; Secure; >> HttpOnly' >> ipa: DEBUG: storing cookie >> 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; >> Domain=ipa-1.kkgpitt.org ; >> Path=/ipa; Expires=Sun, 04 Dec 2016 23:26:28 GMT; Secure; >> HttpOnly' for principal >> host/ipa-1.kkgpitt.org at KKGPITT.ORG >> >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='keyctl' 'search' '@s' 'user' >> 'ipa_session_cookie:host/ipa-1.kkgpitt.org at KKGPITT.ORG >> ' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout=134111920 >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='keyctl' 'search' '@s' 'user' >> 'ipa_session_cookie:host/ipa-1.kkgpitt.org at KKGPITT.ORG >> ' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout=134111920 >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='keyctl' 'pupdate' '134111920' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: Destroyed >> connection context.rpcclient_71021840 >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing >> ldap://ipa-1.kkgpitt.org:389 >> from SchemaCache >> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving >> schema for SchemaCache url=ldap://ipa-1.kkgpitt.org:389 >> >> conn= >> ipa: DEBUG: Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/dirsrv/slapd-KKGPITT-ORG' '-A' '-n' 'KKGPITT.ORG >> IPA CA' '-t' 'CT,C,C' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/dirsrv/slapd-KKGPITT-ORG' '-A' '-n' 'DSTRootCAX3' >> '-t' 'C,,' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/bin/systemctl' 'is-active' >> 'dirsrv at KKGPITT-ORG.service >> ' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout=active >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/bin/systemctl' '--system' 'daemon-reload' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/bin/systemctl' 'restart' >> 'dirsrv at KKGPITT-ORG.service >> ' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/bin/systemctl' 'is-active' >> 'dirsrv at KKGPITT-ORG.service >> ' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout=active >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: wait_for_open_ports: localhost [389] timeout 300 >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/httpd/alias' '-A' '-n' 'KKGPITT.ORG >> IPA CA' '-t' 'CT,C,C' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/httpd/alias' '-A' '-n' 'DSTRootCAX3' '-t' 'C,,' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/bin/systemctl' 'is-active' 'httpd.service' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout=active >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/bin/systemctl' 'restart' 'httpd.service' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/bin/systemctl' 'is-active' 'httpd.service' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout=active >> >> ipa: DEBUG: stderr= >> ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: >> resubmitting certmonger request '20161204225818' >> ipa: DEBUG: certmonger request is in state >> dbus.String(u'GENERATING_CSR', variant_level=1) >> ipa: DEBUG: certmonger request is in state >> dbus.String(u'PRE_SAVE_CERT', variant_level=1) >> ipa: DEBUG: certmonger request is in state >> dbus.String(u'POST_SAVED_CERT', variant_level=1) >> ipa: DEBUG: certmonger request is in state >> dbus.String(u'POST_SAVED_CERT', variant_level=1) >> ipa: DEBUG: certmonger request is in state >> dbus.String(u'POST_SAVED_CERT', variant_level=1) >> ipa: DEBUG: certmonger request is in state >> dbus.String(u'MONITORING', variant_level=1) >> ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: modifying >> certmonger request '20161204225818' >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/ipa/nssdb' '-L' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> Certificate Nickname Trust Attributes >> SSL,S/MIME,JAR/XPI >> >> KKGPITT.ORG IPA CA CT,C,C >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/pki/nssdb' '-L' '-n' 'KKGPITT.ORG >> IPA CA' '-a' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout=-----BEGIN CERTIFICATE----- >> MIIDjTCCAnWgAwIBAgIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtLS0dQ >> SVRULk9SRzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MTIw >> NDIyNTczNFoXDTM2MTIwNDIyNTczNFowNjEUMBIGA1UECgwLS0tHUElUVC5PUkcx >> HjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEB >> . >> >> . >> >> BYuURWnoNBd110T0HFOnMOmN5ycnsMvCwCdUFuFKCsjNjCm5/oUCsWSVlad2bzlj >> 7gvnv3d6YmXwTzpOlOHpMu/S7y+JU5ErM9fp97R/vUvBz/7CM0MOKBgXMvfKTu6X >> PTROdl8lKofxA6TMvM+du020+o79dami0hWV/3cRN386huTDcWVn9gbud6hxX8U5 >> StsgHtJLlrm4tjLk8+S5VTDu9Y6EX7OsEX51RHwtrfNjEYdCa68AM2/slxdgf+5S >> IQ== >> -----END CERTIFICATE----- >> >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/pki/nssdb' '-D' '-n' 'KKGPITT.ORG >> IPA CA' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/pki/nssdb' '-L' '-n' 'KKGPITT.ORG >> IPA CA' '-a' >> ipa: DEBUG: Process finished, return code=255 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=certutil: Could not find cert: >> KKGPITT.ORG IPA CA >> : PR_FILE_NOT_FOUND_ERROR: File not found >> >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/ipa/nssdb' '-L' '-n' 'IPA CA' '-a' >> ipa: DEBUG: Process finished, return code=255 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA >> : PR_FILE_NOT_FOUND_ERROR: File not found >> >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/ipa/nssdb' '-L' '-n' 'External CA cert' '-a' >> ipa: DEBUG: Process finished, return code=255 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr=certutil: Could not find cert: >> External CA cert >> : PR_FILE_NOT_FOUND_ERROR: File not found >> >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/ipa/nssdb' '-A' '-n' 'KKGPITT.ORG >> IPA CA' '-t' 'CT,C,C' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/ipa/nssdb' '-A' '-n' 'DSTRootCAX3' '-t' 'C,,' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/pki/nssdb' '-A' '-n' 'KKGPITT.ORG >> IPA CA' '-t' 'CT,C,C' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/certutil' '-d' >> '/etc/pki/nssdb' '-A' '-n' 'DSTRootCAX3' '-t' 'C,,' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/update-ca-trust' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: INFO: Systemwide CA database updated. >> ipa: DEBUG: Starting external process >> ipa: DEBUG: args='/usr/bin/update-ca-trust' >> ipa: DEBUG: Process finished, return code=0 >> ipa: DEBUG: stdout= >> ipa: DEBUG: stderr= >> ipa: INFO: Systemwide CA database updated. >> ipa.ipaclient.ipa_certupdate.CertUpdate: INFO: The >> ipa-certupdate command was successful >> Directory Manager password: >> >> Installing CA certificate, please wait >> Not a valid CA certificate: (SEC_ERROR_UNKNOWN_ISSUER) >> Peer's Certificate issuer is not recognized. (visit >> http://www.freeipa.org/page/Troubleshooting >> for >> troubleshooting guide) >> [jjflynn22 at ipa-1 ~]$ >> >> >> >> > Hi, > > you seem to have an issue when the LetsEncryptAuthorityX3 is > being installed. The certificate from the CA that issued this > certificate (DSTRootCAX3) seems to be installed correctly. > Could you verify that DSTRootCAX3 is marked as trusted CA by > issuing: > > certutil -d /etc/httpd/alias/ -L > > The DSTRoootCAX3 should have C,, trust flags. > > There was an issue fixed last week that might caused this > issue if you've ever tried to install letsencrypt on this > particular VM before: > https://github.com/freeipa/freeipa-letsencrypt/issues/1#issuecomment-263546822 > If > that's the case, you will need to re-install IPA before the > letsencrypt solution will work. > > I was not able to reproduce your issue with a clean machine. > > -- > Tomas Krizek > > > -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjflynn22 at gmail.com Mon Dec 5 16:58:59 2016 From: jjflynn22 at gmail.com (Joseph Flynn) Date: Mon, 5 Dec 2016 11:58:59 -0500 Subject: [Freeipa-users] Let's Encrypt along with FreeIPA In-Reply-To: <0af9dbd3-e406-a615-f17d-9908a9d8b850@redhat.com> References: <608a680e-0761-1984-733a-f6a6cbd2600a@redhat.com> <0af9dbd3-e406-a615-f17d-9908a9d8b850@redhat.com> Message-ID: Thank you Tomas, those two do seem to be the same. I will try a fresh VM (is there a particular distribution that you've had the best luck with?) and try again. sudo openssl x509 -text -in /root/ipa-le/ca/DSTRootCAX3.pem | grep 'Subject:' sudo openssl x509 -text -in /root/ipa-le/ca/LetsEncryptAuthorityX3.pem | grep 'Issuer:' Subject: O=Digital Signature Trust Co., CN=DST Root CA X3 Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3 [jjflynn22 at ipa-1 ~]$ sudo certutil -d /etc/httpd/alias/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Signing-Cert u,u,u DSTRootCAX3 C,, ipaCert u,u,u Server-Cert u,u,u KKGPITT.ORG IPA CA CT,C,C On Mon, Dec 5, 2016 at 11:51 AM, Tomas Krizek wrote: > Please keep freeipa-users at redhat.com in CC. > > On 12/05/2016 05:23 PM, Joseph Flynn wrote: > > By the way Tomas, can you recommend a good read to better understand how > all of these certs play together in an architecture like this? I'm quite > confident in Linux usage an admin but must admit this is not quite clear to > me. > > The chain of trust on the Let's Encrypt side is explained in > https://letsencrypt.org/certificates/ On the FreeIPA side, there are some > articles on our wiki page related to Public Key Infrastructure, for example > http://www.freeipa.org/page/PKI > > > On Mon, Dec 5, 2016 at 11:19 AM, Joseph Flynn wrote: > >> Thank you for responding Tom. >> >> I created the CentOS 7 VM earlier in the week and did its updates and set >> the hostnames, etc and took a snapshot. I also tried on Ubuntu first but >> that had too many install hiccups. >> >> From that snapshot I have tried several times with the same results as >> recently as yesterday. >> >> Here is the output of your suggestion: >> >> [jjflynn22 at ipa-1 ~]$ sudo certutil -d /etc/httpd/alias/ -L >> [sudo] password for jjflynn22: >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> Signing-Cert u,u,u >> DSTRootCAX3 C,, >> ipaCert u,u,u >> Server-Cert u,u,u >> KKGPITT.ORG IPA CA CT,C,C >> > This seems correct, however this information can be misleading if > DSTRootCAX3 was installed in FreeIPA before. > > The last thing I can think of is to verify that the Subject Field of > DTSRootCAX3 is in fact the same as the Issuer Field in the LetsEncryptAuthorityX3 > certificate. I've checked the ones that are used in the git repo and they > are correct, so I can't see how this could be the issue, but just to verify: > > openssl x509 -text -in /root/ipa-le/ca/DSTRootCAX3.pem | grep 'Subject:' > openssl x509 -text -in /root/ipa-le/ca/LetsEncryptAuthorityX3.pem | grep > 'Issuer:' > > If that doesn't reveal any difference, I'd suggest to attempt to reproduce > the issue with a clean environment (new VM) and if you still encounter the > same problem, please open an issue and provide as much information as > possible, including software versions. https://github.com/freeipa/ > freeipa-letsencrypt/issues > > >> >> Joe >> >> >> >> On Mon, Dec 5, 2016 at 10:35 AM, Tomas Krizek wrote: >> >>> >>> >>> On 12/05/2016 12:25 AM, Joseph Flynn wrote: >>> >>> Sorry if this is not the appropriate forum for discussing this topic. >>> >>> I have installed a FreeIPA system on CentOS 7 and am trying to get the >>> Let's Encrypt scripts to work as defined in >>> https://github.com/freeipa/freeipa-letsencrypt >>> >>> I hand to tinker with a combination of enabling/disabling EPEL and this >>> new tool DNF that I am not too familiar with but eventually got the script >>> to run. >>> >>> It is ending with the following error: >>> >>> ipa: INFO: Systemwide CA database updated. >>>> ipa.ipaclient.ipa_certupdate.CertUpdate: INFO: The ipa-certupdate >>>> command was successful >>>> Directory Manager password: >>>> >>>> Installing CA certificate, please wait >>>> Not a valid CA certificate: (SEC_ERROR_UNKNOWN_ISSUER) Peer's >>>> Certificate issuer is not recognized. (visit >>>> http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) >>>> >>>> >>> Does anyone recognize this situation? >>> >>> I have installed this on a VirtualBox client in Bridge Network mode. >>> Prior to trying to use a real certificate, I could access the FreeIPA UI >>> from Firefox on both the VM and other computers in the home. I've gotten a >>> domain name and have that domain name pointed to my home router with a >>> handful of ports (those listed at the end of the FreeIPA install) forwarded >>> to my VM. >>> >>> For completeness, I have included the history below along with the full >>> output including a couple of highlighted areas that could be errors. >>> >>> Thanks for any assistance from anyone who might notice an error in my >>> ways. >>> Joe >>> >>> >>> History: >>> 1 ifconfig -a >>> 2 sudo yum -y update >>> 3 cat /etc/hostname >>> 4 sudo echo 192.168.1.201 ipa-1.kkgpitt.org ipa-1 >> /etc/hosts >>> 5 sudo vi /etc/hosts >>> 7 sudo reboot now >>> 8 hostname >>> 9 ifconfig -a >>> 11 sudo visudo >>> 12 sudo ls # just to set pw >>> 13 sudo yum install epel-release -y >>> 14 sudo yum install -y haveged >>> 15 sudo systemctl start haveged.service >>> 16 sudo ipa-server-install >>> 17 kinit admin >>> 18 firewall-cmd --permanent --add-service=ntp >>> 19 firewall-cmd --permanent --add-service=http >>> 20 firewall-cmd --permanent --add-service=https >>> 21 firewall-cmd --permanent --add-service=ldap >>> 22 firewall-cmd --permanent --add-service=ldaps >>> 23 firewall-cmd --permanent --add-service=kerberos >>> 24 firewall-cmd --permanent --add-service=kpasswd >>> 26 sudo authconfig --enablemkhomedir --update >>> 27 sudo chkconfig sssd on >>> 28 git config --global user.name "Joe Flynn" >>> 29 git config --global user.email "jjflynn22 at gmail.com" >>> 30 mkdir ~/.ssh >>> 31 cd ~/.ssh >>> 32 vi id_rsa >>> 33 vi id_rsa.pub >>> 34 chmod 700 ~/.ssh >>> 35 chmod 600 ~/.ssh/* >>> 36 ssh-add ~/.ssh/id_rsa >>> 37 sudo yum install -y letsencrypt >>> 38 sudo cp -r /etc/httpd/alias /etc/httpd/alias_backup >>> 39 cd ~ >>> 40 git clone https://github.com/freeipa/freeipa-letsencrypt.git >>> 41 sudo cp -r freeipa-letsencrypt /root/ipa-le >>> 42 sudo vi /root/ipa-le/renew-le.sh >>> 43 sudo yum install -y dnf >>> 44 sudo yum remove -y epel-release >>> 45 sudo dnf repolist >>> 46 sudo /root/ipa-le/setup-le.sh >>> 47 history >>> >>> >>> >>>> [jjflynn22 at ipa-1 ~]$ sudo visudo >>>> [sudo] password for jjflynn22: >>>> [jjflynn22 at ipa-1 ~]$ sudo yum install epel-release -y >>>> Loaded plugins: fastestmirror, langpacks >>>> base >>>> | 3.6 kB 00:00:00 >>>> extras >>>> | 3.4 kB 00:00:00 >>>> updates >>>> | 3.4 kB 00:00:00 >>>> Loading mirror speeds from cached hostfile >>>> * base: repo1.ash.innoscale.net >>>> * extras: mirrors.advancedhosters.com >>>> * updates: mirror.cs.vt.edu >>>> Resolving Dependencies >>>> --> Running transaction check >>>> ---> Package epel-release.noarch 0:7-6 will be installed >>>> --> Finished Dependency Resolution >>>> >>>> Dependencies Resolved >>>> >>>> ============================================================ >>>> ================================================================= >>>> Package Arch >>>> Version Repository Size >>>> ============================================================ >>>> ================================================================= >>>> Installing: >>>> epel-release noarch >>>> 7-6 extras 14 k >>>> >>>> Transaction Summary >>>> ============================================================ >>>> ================================================================= >>>> Install 1 Package >>>> >>>> Total download size: 14 k >>>> Installed size: 24 k >>>> Downloading packages: >>>> epel-release-7-6.noarch.rpm >>>> | 14 kB 00:00:00 >>>> Running transaction check >>>> Running transaction test >>>> Transaction test succeeded >>>> Running transaction >>>> Installing : epel-release-7-6.noarch >>>> >>>> 1/1 >>>> Verifying : epel-release-7-6.noarch >>>> >>>> 1/1 >>>> >>>> Installed: >>>> epel-release.noarch 0:7-6 >>>> >>>> >>>> >>>> Complete! >>>> [jjflynn22 at ipa-1 ~]$ sudo yum install -y haveged >>>> Loaded plugins: fastestmirror, langpacks >>>> epel/x86_64/metalink >>>> | 13 kB 00:00:00 >>>> epel >>>> | 4.3 kB 00:00:00 >>>> (1/3): epel/x86_64/updateinfo >>>> | 676 kB 00:00:00 >>>> (2/3): epel/x86_64/group_gz >>>> | 170 kB 00:00:00 >>>> (3/3): epel/x86_64/primary_db >>>> | 4.4 MB 00:00:01 >>>> Loading mirror speeds from cached hostfile >>>> * base: repo1.ash.innoscale.net >>>> * epel: ftp.osuosl.org >>>> * extras: mirror.fusioncloud.co >>>> * updates: ftp.osuosl.org >>>> Resolving Dependencies >>>> --> Running transaction check >>>> ---> Package haveged.x86_64 0:1.9.1-1.el7 will be installed >>>> --> Finished Dependency Resolution >>>> >>>> Dependencies Resolved >>>> >>>> ============================================================ >>>> ================================================================= >>>> Package Arch >>>> Version Repository Size >>>> ============================================================ >>>> ================================================================= >>>> Installing: >>>> haveged x86_64 >>>> 1.9.1-1.el7 epel 61 k >>>> >>>> Transaction Summary >>>> ============================================================ >>>> ================================================================= >>>> Install 1 Package >>>> >>>> Total download size: 61 k >>>> Installed size: 181 k >>>> Downloading packages: >>>> warning: /var/cache/yum/x86_64/7/epel/packages/haveged-1.9.1-1.el7.x86_64.rpm: >>>> Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY >>>> Public key for haveged-1.9.1-1.el7.x86_64.rpm is not installed >>>> haveged-1.9.1-1.el7.x86_64.rpm >>>> | 61 kB 00:00:00 >>>> Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 >>>> Importing GPG key 0x352C64E5: >>>> Userid : "Fedora EPEL (7) " >>>> Fingerprint: 91e9 7d7c 4a5e 96f1 7f3e 888f 6a2f aea2 352c 64e5 >>>> Package : epel-release-7-6.noarch (@extras) >>>> From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 >>>> Running transaction check >>>> Running transaction test >>>> Transaction test succeeded >>>> Running transaction >>>> Installing : haveged-1.9.1-1.el7.x86_64 >>>> >>>> 1/1 >>>> Verifying : haveged-1.9.1-1.el7.x86_64 >>>> >>>> 1/1 >>>> >>>> Installed: >>>> haveged.x86_64 0:1.9.1-1.el7 >>>> >>>> >>>> >>>> Complete! >>>> [jjflynn22 at ipa-1 ~]$ sudo systemctl start haveged.service >>>> [jjflynn22 at ipa-1 ~]$ >>>> [jjflynn22 at ipa-1 ~]$ >>>> [jjflynn22 at ipa-1 ~]$ >>>> [jjflynn22 at ipa-1 ~]$ >>>> [jjflynn22 at ipa-1 ~]$ sudo ipa-server-install >>>> >>>> The log file for this installation can be found in >>>> /var/log/ipaserver-install.log >>>> ============================================================ >>>> ================== >>>> This program will set up the IPA Server. >>>> >>>> This includes: >>>> * Configure a stand-alone CA (dogtag) for certificate management >>>> * Configure the Network Time Daemon (ntpd) >>>> * Create and configure an instance of Directory Server >>>> * Create and configure a Kerberos Key Distribution Center (KDC) >>>> * Configure Apache (httpd) >>>> >>>> To accept the default shown in brackets, press the Enter key. >>>> >>>> WARNING: conflicting time&date synchronization service 'chronyd' will >>>> be disabled >>>> in favor of ntpd >>>> >>>> Do you want to configure integrated DNS (BIND)? [no]: >>>> >>>> Enter the fully qualified domain name of the computer >>>> on which you're setting up server software. Using the form >>>> . >>>> Example: master.example.com. >>>> >>>> >>>> Server host name [ipa-1.kkgpitt.org]: >>>> >>>> The domain name has been determined based on the host name. >>>> >>>> Please confirm the domain name [kkgpitt.org]: >>>> >>>> The kerberos protocol requires a Realm name to be defined. >>>> This is typically the domain name converted to uppercase. >>>> >>>> Please provide a realm name [KKGPITT.ORG]: >>>> Certain directory server operations require an administrative user. >>>> This user is referred to as the Directory Manager and has full access >>>> to the Directory for system management tasks and will be added to the >>>> instance of directory server created for IPA. >>>> The password must be at least 8 characters long. >>>> >>>> Directory Manager password: >>>> Password (confirm): >>>> >>>> The IPA server requires an administrative user, named 'admin'. >>>> This user is a regular system account used for IPA server >>>> administration. >>>> >>>> IPA admin password: >>>> Password (confirm): >>>> >>>> >>>> The IPA Master Server will be configured with: >>>> Hostname: ipa-1.kkgpitt.org >>>> IP address(es): 192.168.1.201 >>>> Domain name: kkgpitt.org >>>> Realm name: KKGPITT.ORG >>>> >>>> Continue to configure the system with these values? [no]: yes >>>> >>>> The following operations may take some minutes to complete. >>>> Please wait until the prompt is returned. >>>> >>>> Configuring NTP daemon (ntpd) >>>> [1/4]: stopping ntpd >>>> [2/4]: writing configuration >>>> [3/4]: configuring ntpd to start on boot >>>> [4/4]: starting ntpd >>>> Done configuring NTP daemon (ntpd). >>>> Configuring directory server (dirsrv). Estimated time: 1 minute >>>> [1/42]: creating directory server user >>>> [2/42]: creating directory server instance >>>> [3/42]: adding default schema >>>> [4/42]: enabling memberof plugin >>>> [5/42]: enabling winsync plugin >>>> [6/42]: configuring replication version plugin >>>> [7/42]: enabling IPA enrollment plugin >>>> [8/42]: enabling ldapi >>>> [9/42]: configuring uniqueness plugin >>>> [10/42]: configuring uuid plugin >>>> [11/42]: configuring modrdn plugin >>>> [12/42]: configuring DNS plugin >>>> [13/42]: enabling entryUSN plugin >>>> [14/42]: configuring lockout plugin >>>> [15/42]: creating indices >>>> [16/42]: enabling referential integrity plugin >>>> [17/42]: configuring certmap.conf >>>> [18/42]: configure autobind for root >>>> [19/42]: configure new location for managed entries >>>> [20/42]: configure dirsrv ccache >>>> [21/42]: enable SASL mapping fallback >>>> [22/42]: restarting directory server >>>> [23/42]: adding default layout >>>> [24/42]: adding delegation layout >>>> [25/42]: creating container for managed entries >>>> [26/42]: configuring user private groups >>>> [27/42]: configuring netgroups from hostgroups >>>> [28/42]: creating default Sudo bind user >>>> [29/42]: creating default Auto Member layout >>>> [30/42]: adding range check plugin >>>> [31/42]: creating default HBAC rule allow_all >>>> [32/42]: adding entries for topology management >>>> [33/42]: initializing group membership >>>> [34/42]: adding master entry >>>> [35/42]: initializing domain level >>>> [36/42]: configuring Posix uid/gid generation >>>> [37/42]: adding replication acis >>>> [38/42]: enabling compatibility plugin >>>> [39/42]: activating sidgen plugin >>>> [40/42]: activating extdom plugin >>>> [41/42]: tuning directory server >>>> [42/42]: configuring directory to start on boot >>>> Done configuring directory server (dirsrv). >>>> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes >>>> 30 seconds >>>> [1/28]: creating certificate server user >>>> [2/28]: configuring certificate server instance >>>> [3/28]: stopping certificate server instance to update CS.cfg >>>> [4/28]: backing up CS.cfg >>>> [5/28]: disabling nonces >>>> [6/28]: set up CRL publishing >>>> [7/28]: enable PKIX certificate path discovery and validation >>>> [8/28]: starting certificate server instance >>>> [9/28]: creating RA agent certificate database >>>> [10/28]: importing CA chain to RA certificate database >>>> [11/28]: fixing RA database permissions >>>> [12/28]: setting up signing cert profile >>>> [13/28]: setting audit signing renewal to 2 years >>>> [14/28]: restarting certificate server >>>> [15/28]: requesting RA certificate from CA >>>> [16/28]: issuing RA agent certificate >>>> [17/28]: adding RA agent as a trusted user >>>> [18/28]: authorizing RA to modify profiles >>>> [19/28]: configure certmonger for renewals >>>> [20/28]: configure certificate renewals >>>> [21/28]: configure RA certificate renewal >>>> [22/28]: configure Server-Cert certificate renewal >>>> [23/28]: Configure HTTP to proxy connections >>>> [24/28]: restarting certificate server >>>> [25/28]: migrating certificate profiles to LDAP >>>> [26/28]: importing IPA certificate profiles >>>> [27/28]: adding default CA ACL >>>> [28/28]: updating IPA configuration >>>> Done configuring certificate server (pki-tomcatd). >>>> Configuring directory server (dirsrv). Estimated time: 10 seconds >>>> [1/3]: configuring ssl for ds instance >>>> [2/3]: restarting directory server >>>> [3/3]: adding CA certificate entry >>>> Done configuring directory server (dirsrv). >>>> Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds >>>> [1/10]: adding sasl mappings to the directory >>>> [2/10]: adding kerberos container to the directory >>>> [3/10]: configuring KDC >>>> [4/10]: initialize kerberos container >>>> [5/10]: adding default ACIs >>>> [6/10]: creating a keytab for the directory >>>> [7/10]: creating a keytab for the machine >>>> [8/10]: adding the password extension to the directory >>>> [9/10]: starting the KDC >>>> [10/10]: configuring KDC to start on boot >>>> Done configuring Kerberos KDC (krb5kdc). >>>> Configuring kadmin >>>> [1/2]: starting kadmin >>>> [2/2]: configuring kadmin to start on boot >>>> Done configuring kadmin. >>>> Configuring ipa_memcached >>>> [1/2]: starting ipa_memcached >>>> [2/2]: configuring ipa_memcached to start on boot >>>> Done configuring ipa_memcached. >>>> Configuring ipa-otpd >>>> [1/2]: starting ipa-otpd >>>> [2/2]: configuring ipa-otpd to start on boot >>>> Done configuring ipa-otpd. >>>> Configuring the web interface (httpd). Estimated time: 1 minute >>>> [1/19]: setting mod_nss port to 443 >>>> [2/19]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2 >>>> [3/19]: setting mod_nss password file >>>> [4/19]: enabling mod_nss renegotiate >>>> [5/19]: adding URL rewriting rules >>>> [6/19]: configuring httpd >>>> [7/19]: configure certmonger for renewals >>>> [8/19]: setting up ssl >>>> [9/19]: importing CA certificates from LDAP >>>> [10/19]: setting up browser autoconfig >>>> [11/19]: publish CA cert >>>> [12/19]: creating a keytab for httpd >>>> [13/19]: clean up any existing httpd ccache >>>> [14/19]: configuring SELinux for httpd >>>> [15/19]: create KDC proxy user >>>> [16/19]: create KDC proxy config >>>> [17/19]: enable KDC proxy >>>> [18/19]: restarting httpd >>>> [19/19]: configuring httpd to start on boot >>>> Done configuring the web interface (httpd). >>>> Applying LDAP updates >>>> Upgrading IPA: >>>> [1/9]: stopping directory server >>>> [2/9]: saving configuration >>>> [3/9]: disabling listeners >>>> [4/9]: enabling DS global lock >>>> [5/9]: starting directory server >>>> [6/9]: upgrading server >>>> [7/9]: stopping directory server >>>> [8/9]: restoring configuration >>>> [9/9]: starting directory server >>>> Done. >>>> Restarting the directory server >>>> Restarting the KDC >>>> Sample zone file for bind has been created in /tmp/sample.zone.Yjwpca.db >>>> Restarting the web server >>>> ============================================================ >>>> ================== >>>> Setup complete >>>> >>>> Next steps: >>>> 1. You must make sure these network ports are open: >>>> TCP Ports: >>>> * 80, 443: HTTP/HTTPS >>>> * 389, 636: LDAP/LDAPS >>>> * 88, 464: kerberos >>>> UDP Ports: >>>> * 88, 464: kerberos >>>> * 123: ntp >>>> >>>> 2. You can now obtain a kerberos ticket using the command: 'kinit >>>> admin' >>>> This ticket will allow you to use the IPA tools (e.g., ipa >>>> user-add) >>>> and the web user interface. >>>> >>>> Be sure to back up the CA certificates stored in /root/cacert.p12 >>>> These files are required to create replicas. The password for these >>>> files is the Directory Manager password >>>> [jjflynn22 at ipa-1 ~]$ kinit admin >>>> Password for admin at KKGPITT.ORG: >>>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=ntp >>>> success >>>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=http >>>> success >>>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=https >>>> success >>>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=ldap >>>> success >>>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=ldaps >>>> success >>>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=kerberos >>>> success >>>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent --add-service=kpasswd >>>> success >>>> [jjflynn22 at ipa-1 ~]$ sudo authconfig --enablemkhomedir --update >>>> [jjflynn22 at ipa-1 ~]$ sudo chkconfig sssd on >>>> Note: Forwarding request to 'systemctl enable sssd.service'. >>>> [jjflynn22 at ipa-1 ~]$ git config --global user.name "Joe Flynn" >>>> [jjflynn22 at ipa-1 ~]$ git config --global user.email " >>>> jjflynn22 at gmail.com" >>>> [jjflynn22 at ipa-1 ~]$ mkdir ~/.ssh >>>> [jjflynn22 at ipa-1 ~]$ cd ~/.ssh >>>> [jjflynn22 at ipa-1 .ssh]$ vi id_rsa >>>> [jjflynn22 at ipa-1 .ssh]$ vi id_rsa.pub >>>> [jjflynn22 at ipa-1 .ssh]$ chmod 700 ~/.ssh >>>> [jjflynn22 at ipa-1 .ssh]$ chmod 600 ~/.ssh/* >>>> [jjflynn22 at ipa-1 .ssh]$ ssh-add ~/.ssh/id_rsa >>>> Identity added: /home/jjflynn22/.ssh/id_rsa >>>> (/home/jjflynn22/.ssh/id_rsa) >>>> [jjflynn22 at ipa-1 .ssh]$ sudo yum install -y letsencrypt >>>> Loaded plugins: fastestmirror, langpacks >>>> Loading mirror speeds from cached hostfile >>>> * base: repo1.ash.innoscale.net >>>> * epel: mirror.cogentco.com >>>> * extras: chicago.gaminghost.co >>>> * updates: mirror.cs.vt.edu >>>> Resolving Dependencies >>>> --> Running transaction check >>>> ---> Package certbot.noarch 0:0.9.3-1.el7 will be installed >>>> --> Processing Dependency: python2-certbot = 0.9.3-1.el7 for package: >>>> certbot-0.9.3-1.el7.noarch >>>> --> Running transaction check >>>> ---> Package python2-certbot.noarch 0:0.9.3-1.el7 will be installed >>>> --> Processing Dependency: python2-acme = 0.9.3 for package: >>>> python2-certbot-0.9.3-1.el7.noarch >>>> --> Processing Dependency: python2-dialog >= 3.3.0 for package: >>>> python2-certbot-0.9.3-1.el7.noarch >>>> --> Processing Dependency: python2-configargparse >= 0.10.0 for >>>> package: python2-certbot-0.9.3-1.el7.noarch >>>> --> Processing Dependency: python-psutil >= 2.1.0 for package: >>>> python2-certbot-0.9.3-1.el7.noarch >>>> --> Processing Dependency: python-zope-interface for package: >>>> python2-certbot-0.9.3-1.el7.noarch >>>> --> Processing Dependency: python-zope-component for package: >>>> python2-certbot-0.9.3-1.el7.noarch >>>> --> Processing Dependency: python-parsedatetime for package: >>>> python2-certbot-0.9.3-1.el7.noarch >>>> --> Processing Dependency: python-mock for package: >>>> python2-certbot-0.9.3-1.el7.noarch >>>> --> Running transaction check >>>> ---> Package python-parsedatetime.noarch 0:1.5-3.el7 will be installed >>>> ---> Package python-psutil.x86_64 0:2.2.1-1.el7 will be installed >>>> ---> Package python-zope-component.noarch 1:4.1.0-1.el7 will be >>>> installed >>>> --> Processing Dependency: python-zope-event for package: >>>> 1:python-zope-component-4.1.0-1.el7.noarch >>>> ---> Package python-zope-interface.x86_64 0:4.0.5-4.el7 will be >>>> installed >>>> ---> Package python2-acme.noarch 0:0.9.3-1.el7 will be installed >>>> --> Processing Dependency: python-pyrfc3339 for package: >>>> python2-acme-0.9.3-1.el7.noarch >>>> --> Processing Dependency: python-ndg_httpsclient for package: >>>> python2-acme-0.9.3-1.el7.noarch >>>> ---> Package python2-configargparse.noarch 0:0.10.0-1.el7 will be >>>> installed >>>> ---> Package python2-dialog.noarch 0:3.3.0-6.el7 will be installed >>>> --> Processing Dependency: dialog for package: >>>> python2-dialog-3.3.0-6.el7.noarch >>>> ---> Package python2-mock.noarch 0:1.0.1-9.el7 will be installed >>>> --> Running transaction check >>>> ---> Package dialog.x86_64 0:1.2-4.20130523.el7 will be installed >>>> ---> Package python-ndg_httpsclient.noarch 0:0.3.2-1.el7 will be >>>> installed >>>> ---> Package python-zope-event.noarch 0:4.0.3-2.el7 will be installed >>>> ---> Package python2-pyrfc3339.noarch 0:1.0-2.el7 will be installed >>>> --> Finished Dependency Resolution >>>> >>>> Dependencies Resolved >>>> >>>> ============================================================ >>>> ================================================================= >>>> Package Arch >>>> Version Repository Size >>>> ============================================================ >>>> ================================================================= >>>> Installing: >>>> certbot noarch >>>> 0.9.3-1.el7 epel 16 k >>>> Installing for dependencies: >>>> dialog x86_64 >>>> 1.2-4.20130523.el7 base 208 k >>>> python-ndg_httpsclient noarch >>>> 0.3.2-1.el7 epel 43 k >>>> python-parsedatetime noarch >>>> 1.5-3.el7 epel 61 k >>>> python-psutil x86_64 >>>> 2.2.1-1.el7 epel 114 k >>>> python-zope-component noarch >>>> 1:4.1.0-1.el7 epel 110 k >>>> python-zope-event noarch >>>> 4.0.3-2.el7 epel 79 k >>>> python-zope-interface x86_64 >>>> 4.0.5-4.el7 base 138 k >>>> python2-acme noarch >>>> 0.9.3-1.el7 epel 168 k >>>> python2-certbot noarch >>>> 0.9.3-1.el7 epel 361 k >>>> python2-configargparse noarch >>>> 0.10.0-1.el7 epel 28 k >>>> python2-dialog noarch >>>> 3.3.0-6.el7 epel 94 k >>>> python2-mock noarch >>>> 1.0.1-9.el7 epel 92 k >>>> python2-pyrfc3339 noarch >>>> 1.0-2.el7 epel 13 k >>>> >>>> Transaction Summary >>>> ============================================================ >>>> ================================================================= >>>> Install 1 Package (+13 Dependent packages) >>>> >>>> Total download size: 1.5 M >>>> Installed size: 6.3 M >>>> Downloading packages: >>>> (1/14): python-ndg_httpsclient-0.3.2-1.el7.noarch.rpm >>>> | 43 kB 00:00:00 >>>> (2/14): dialog-1.2-4.20130523.el7.x86_64.rpm >>>> | 208 kB 00:00:00 >>>> (3/14): certbot-0.9.3-1.el7.noarch.rpm >>>> | 16 kB 00:00:00 >>>> (4/14): python-parsedatetime-1.5-3.el7.noarch.rpm >>>> | 61 kB 00:00:00 >>>> (5/14): python-psutil-2.2.1-1.el7.x86_64.rpm >>>> | 114 kB 00:00:00 >>>> (6/14): python-zope-component-4.1.0-1.el7.noarch.rpm >>>> | 110 kB 00:00:00 >>>> (7/14): python-zope-interface-4.0.5-4.el7.x86_64.rpm >>>> | 138 kB 00:00:00 >>>> (8/14): python-zope-event-4.0.3-2.el7.noarch.rpm >>>> | 79 kB 00:00:00 >>>> (9/14): python2-certbot-0.9.3-1.el7.noarch.rpm >>>> | 361 kB 00:00:00 >>>> (10/14): python2-configargparse-0.10.0-1.el7.noarch.rpm >>>> | 28 kB 00:00:00 >>>> (11/14): python2-acme-0.9.3-1.el7.noarch.rpm >>>> | 168 kB 00:00:00 >>>> (12/14): python2-dialog-3.3.0-6.el7.noarch.rpm >>>> | 94 kB 00:00:00 >>>> (13/14): python2-pyrfc3339-1.0-2.el7.noarch.rpm >>>> | 13 kB 00:00:00 >>>> (14/14): python2-mock-1.0.1-9.el7.noarch.rpm >>>> | 92 kB 00:00:00 >>>> ------------------------------------------------------------ >>>> ----------------------------------------------------------------- >>>> Total >>>> 1.3 MB/s | 1.5 MB 00:00:01 >>>> Running transaction check >>>> Running transaction test >>>> Transaction test succeeded >>>> Running transaction >>>> Installing : python-zope-interface-4.0.5-4. >>>> el7.x86_64 >>>> 1/14 >>>> Installing : python2-mock-1.0.1-9.el7.noarc >>>> h >>>> 2/14 >>>> Installing : python-parsedatetime-1.5-3.el7 >>>> .noarch >>>> 3/14 >>>> Installing : python-psutil-2.2.1-1.el7.x86_ >>>> 64 >>>> 4/14 >>>> Installing : python-zope-event-4.0.3-2.el7. >>>> noarch >>>> 5/14 >>>> Installing : 1:python-zope-component-4.1.0- >>>> 1.el7.noarch >>>> 6/14 >>>> Installing : python-ndg_httpsclient-0.3.2-1 >>>> .el7.noarch >>>> 7/14 >>>> Installing : python2-pyrfc3339-1.0-2.el7.no >>>> arch >>>> 8/14 >>>> Installing : python2-acme-0.9.3-1.el7.noarc >>>> h >>>> 9/14 >>>> Installing : python2-configargparse-0.10.0- >>>> 1.el7.noarch >>>> 10/14 >>>> Installing : dialog-1.2-4.20130523.el7.x86_ >>>> 64 >>>> 11/14 >>>> Installing : python2-dialog-3.3.0-6.el7.noa >>>> rch >>>> 12/14 >>>> Installing : python2-certbot-0.9.3-1.el7.no >>>> arch >>>> 13/14 >>>> Installing : certbot-0.9.3-1.el7.noarch >>>> >>>> 14/14 >>>> Verifying : dialog-1.2-4.20130523.el7.x86_ >>>> 64 >>>> 1/14 >>>> Verifying : certbot-0.9.3-1.el7.noarch >>>> >>>> 2/14 >>>> Verifying : python2-configargparse-0.10.0- >>>> 1.el7.noarch >>>> 3/14 >>>> Verifying : python2-pyrfc3339-1.0-2.el7.no >>>> arch >>>> 4/14 >>>> Verifying : python-zope-interface-4.0.5-4. >>>> el7.x86_64 >>>> 5/14 >>>> Verifying : python-ndg_httpsclient-0.3.2-1 >>>> .el7.noarch >>>> 6/14 >>>> Verifying : python-zope-event-4.0.3-2.el7. >>>> noarch >>>> 7/14 >>>> Verifying : python-psutil-2.2.1-1.el7.x86_ >>>> 64 >>>> 8/14 >>>> Verifying : python2-acme-0.9.3-1.el7.noarc >>>> h >>>> 9/14 >>>> Verifying : python2-dialog-3.3.0-6.el7.noa >>>> rch >>>> 10/14 >>>> Verifying : 1:python-zope-component-4.1.0- >>>> 1.el7.noarch >>>> 11/14 >>>> Verifying : python-parsedatetime-1.5-3.el7 >>>> .noarch >>>> 12/14 >>>> Verifying : python2-certbot-0.9.3-1.el7.no >>>> arch >>>> 13/14 >>>> Verifying : python2-mock-1.0.1-9.el7.noarc >>>> h >>>> 14/14 >>>> >>>> Installed: >>>> certbot.noarch 0:0.9.3-1.el7 >>>> >>>> >>>> >>>> Dependency Installed: >>>> dialog.x86_64 0:1.2-4.20130523.el7 >>>> python-ndg_httpsclient.noarch 0:0.3.2-1.el7 >>>> python-parsedatetime.noarch 0:1.5-3.el7 >>>> python-psutil.x86_64 0:2.2.1-1.el7 >>>> python-zope-component.noarch 1:4.1.0-1.el7 >>>> python-zope-event.noarch 0:4.0.3-2.el7 >>>> python-zope-interface.x86_64 0:4.0.5-4.el7 >>>> python2-acme.noarch 0:0.9.3-1.el7 >>>> python2-certbot.noarch 0:0.9.3-1.el7 >>>> python2-configargparse.noarch 0:0.10.0-1.el7 >>>> python2-dialog.noarch 0:3.3.0-6.el7 >>>> python2-mock.noarch 0:1.0.1-9.el7 >>>> python2-pyrfc3339.noarch 0:1.0-2.el7 >>>> >>>> Complete! >>>> [jjflynn22 at ipa-1 .ssh]$ >>>> [jjflynn22 at ipa-1 .ssh]$ >>>> [jjflynn22 at ipa-1 .ssh]$ sudo cp -r /etc/httpd/alias >>>> /etc/httpd/alias_backup >>>> [jjflynn22 at ipa-1 .ssh]$ cd ~ >>>> [jjflynn22 at ipa-1 ~]$ git clone https://github.com/freeipa/fre >>>> eipa-letsencrypt.git >>>> Cloning into 'freeipa-letsencrypt'... >>>> remote: Counting objects: 45, done. >>>> remote: Compressing objects: 100% (4/4), done. >>>> remote: Total 45 (delta 0), reused 0 (delta 0), pack-reused 41 >>>> Unpacking objects: 100% (45/45), done. >>>> [jjflynn22 at ipa-1 ~]$ sudo cp -r freeipa-letsencrypt /root/ipa-le >>>> [jjflynn22 at ipa-1 ~]$ sudo vi /root/ipa-le/renew-le.sh >>>> [jjflynn22 at ipa-1 ~]$ sudo yum install -y dnf >>>> Loaded plugins: fastestmirror, langpacks >>>> Loading mirror speeds from cached hostfile >>>> * base: repo1.ash.innoscale.net >>>> * epel: mirror.cogentco.com >>>> * extras: mirrors.advancedhosters.com >>>> * updates: mirror.cs.vt.edu >>>> Resolving Dependencies >>>> --> Running transaction check >>>> ---> Package dnf.noarch 0:0.6.4-2.el7 will be installed >>>> --> Processing Dependency: python-dnf = 0.6.4-2.el7 for package: >>>> dnf-0.6.4-2.el7.noarch >>>> --> Running transaction check >>>> ---> Package python-dnf.noarch 0:0.6.4-2.el7 will be installed >>>> --> Processing Dependency: dnf-conf = 0.6.4-2.el7 for package: >>>> python-dnf-0.6.4-2.el7.noarch >>>> --> Processing Dependency: python-librepo >= 1.7.5 for package: >>>> python-dnf-0.6.4-2.el7.noarch >>>> --> Processing Dependency: python-libcomps >= 0.1.6 for package: >>>> python-dnf-0.6.4-2.el7.noarch >>>> --> Processing Dependency: python-hawkey >= 0.5.3 for package: >>>> python-dnf-0.6.4-2.el7.noarch >>>> --> Running transaction check >>>> ---> Package dnf-conf.noarch 0:0.6.4-2.el7 will be installed >>>> ---> Package python-hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 will be >>>> installed >>>> --> Processing Dependency: hawkey(x86-64) = 0.5.8-2.git.0.202b194.el7 >>>> for package: python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >>>> --> Processing Dependency: libsolv.so.0(SOLV_1.0)(64bit) for package: >>>> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >>>> --> Processing Dependency: libsolv.so.0()(64bit) for package: >>>> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >>>> --> Processing Dependency: libhawkey.so.2()(64bit) for package: >>>> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >>>> ---> Package python-libcomps.x86_64 0:0.1.6-13.el7 will be installed >>>> --> Processing Dependency: libcomps(x86-64) = 0.1.6-13.el7 for package: >>>> python-libcomps-0.1.6-13.el7.x86_64 >>>> --> Processing Dependency: libcomps.so.0.1.6()(64bit) for package: >>>> python-libcomps-0.1.6-13.el7.x86_64 >>>> ---> Package python-librepo.x86_64 0:1.7.16-1.el7 will be installed >>>> --> Processing Dependency: librepo(x86-64) = 1.7.16-1.el7 for package: >>>> python-librepo-1.7.16-1.el7.x86_64 >>>> --> Processing Dependency: librepo.so.0()(64bit) for package: >>>> python-librepo-1.7.16-1.el7.x86_64 >>>> --> Running transaction check >>>> ---> Package hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 will be installed >>>> ---> Package libcomps.x86_64 0:0.1.6-13.el7 will be installed >>>> ---> Package librepo.x86_64 0:1.7.16-1.el7 will be installed >>>> ---> Package libsolv.x86_64 0:0.6.11-1.el7 will be installed >>>> --> Finished Dependency Resolution >>>> >>>> Dependencies Resolved >>>> >>>> ============================================================ >>>> ================================================================= >>>> Package Arch >>>> Version Repository Size >>>> ============================================================ >>>> ================================================================= >>>> Installing: >>>> dnf noarch >>>> 0.6.4-2.el7 epel 209 k >>>> Installing for dependencies: >>>> dnf-conf noarch >>>> 0.6.4-2.el7 epel 61 k >>>> hawkey x86_64 >>>> 0.5.8-2.git.0.202b194.el7 base 87 k >>>> libcomps x86_64 >>>> 0.1.6-13.el7 epel 72 k >>>> librepo x86_64 >>>> 1.7.16-1.el7 base 77 k >>>> libsolv x86_64 >>>> 0.6.11-1.el7 base 316 k >>>> python-dnf noarch >>>> 0.6.4-2.el7 epel 407 k >>>> python-hawkey x86_64 >>>> 0.5.8-2.git.0.202b194.el7 base 71 k >>>> python-libcomps x86_64 >>>> 0.1.6-13.el7 epel 44 k >>>> python-librepo x86_64 >>>> 1.7.16-1.el7 base 49 k >>>> >>>> Transaction Summary >>>> ============================================================ >>>> ================================================================= >>>> Install 1 Package (+9 Dependent packages) >>>> >>>> Total download size: 1.4 M >>>> Installed size: 4.1 M >>>> Downloading packages: >>>> (1/10): hawkey-0.5.8-2.git.0.202b194.el7.x86_64.rpm >>>> | 87 kB 00:00:00 >>>> (2/10): dnf-conf-0.6.4-2.el7.noarch.rpm >>>> | 61 kB 00:00:00 >>>> (3/10): dnf-0.6.4-2.el7.noarch.rpm >>>> | 209 kB 00:00:00 >>>> (4/10): librepo-1.7.16-1.el7.x86_64.rpm >>>> | 77 kB 00:00:00 >>>> (5/10): libcomps-0.1.6-13.el7.x86_64.rpm >>>> | 72 kB 00:00:00 >>>> (6/10): python-librepo-1.7.16-1.el7.x86_64.rpm >>>> | 49 kB 00:00:00 >>>> (7/10): python-libcomps-0.1.6-13.el7.x86_64.rpm >>>> | 44 kB 00:00:00 >>>> (8/10): python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64.rpm >>>> | 71 kB 00:00:00 >>>> (9/10): python-dnf-0.6.4-2.el7.noarch.rpm >>>> | 407 kB 00:00:00 >>>> (10/10): libsolv-0.6.11-1.el7.x86_64.rpm >>>> | 316 kB 00:00:00 >>>> ------------------------------------------------------------ >>>> ----------------------------------------------------------------- >>>> Total >>>> 1.4 MB/s | 1.4 MB 00:00:01 >>>> Running transaction check >>>> Running transaction test >>>> Transaction test succeeded >>>> Running transaction >>>> Installing : libsolv-0.6.11-1.el7.x86_64 >>>> >>>> 1/10 >>>> Installing : hawkey-0.5.8-2.git.0.202b194.e >>>> l7.x86_64 >>>> 2/10 >>>> Installing : python-hawkey-0.5.8-2.git.0.20 >>>> 2b194.el7.x86_64 >>>> 3/10 >>>> Installing : dnf-conf-0.6.4-2.el7.noarch >>>> >>>> 4/10 >>>> Installing : libcomps-0.1.6-13.el7.x86_64 >>>> >>>> 5/10 >>>> Installing : python-libcomps-0.1.6-13.el7.x >>>> 86_64 >>>> 6/10 >>>> Installing : librepo-1.7.16-1.el7.x86_64 >>>> >>>> 7/10 >>>> Installing : python-librepo-1.7.16-1.el7.x8 >>>> 6_64 >>>> 8/10 >>>> Installing : python-dnf-0.6.4-2.el7.noarch >>>> >>>> 9/10 >>>> Installing : dnf-0.6.4-2.el7.noarch >>>> >>>> 10/10 >>>> Verifying : librepo-1.7.16-1.el7.x86_64 >>>> >>>> 1/10 >>>> Verifying : python-libcomps-0.1.6-13.el7.x >>>> 86_64 >>>> 2/10 >>>> Verifying : python-hawkey-0.5.8-2.git.0.20 >>>> 2b194.el7.x86_64 >>>> 3/10 >>>> Verifying : python-librepo-1.7.16-1.el7.x8 >>>> 6_64 >>>> 4/10 >>>> Verifying : python-dnf-0.6.4-2.el7.noarch >>>> >>>> 5/10 >>>> Verifying : libcomps-0.1.6-13.el7.x86_64 >>>> >>>> 6/10 >>>> Verifying : hawkey-0.5.8-2.git.0.202b194.e >>>> l7.x86_64 >>>> 7/10 >>>> Verifying : dnf-conf-0.6.4-2.el7.noarch >>>> >>>> 8/10 >>>> Verifying : dnf-0.6.4-2.el7.noarch >>>> >>>> 9/10 >>>> Verifying : libsolv-0.6.11-1.el7.x86_64 >>>> >>>> 10/10 >>>> >>>> Installed: >>>> dnf.noarch 0:0.6.4-2.el7 >>>> >>>> >>>> >>>> Dependency Installed: >>>> dnf-conf.noarch 0:0.6.4-2.el7 >>>> hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 >>>> libcomps.x86_64 0:0.1.6-13.el7 >>>> librepo.x86_64 0:1.7.16-1.el7 >>>> libsolv.x86_64 0:0.6.11-1.el7 >>>> python-dnf.noarch 0:0.6.4-2.el7 >>>> python-hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 >>>> python-libcomps.x86_64 0:0.1.6-13.el7 >>>> python-librepo.x86_64 0:1.7.16-1.el7 >>>> >>>> Complete! >>>> [jjflynn22 at ipa-1 ~]$ sudo yum remove -y epel-release >>>> Loaded plugins: fastestmirror, langpacks >>>> Resolving Dependencies >>>> --> Running transaction check >>>> ---> Package epel-release.noarch 0:7-6 will be erased >>>> --> Finished Dependency Resolution >>>> >>>> Dependencies Resolved >>>> >>>> ============================================================ >>>> ================================================================= >>>> Package Arch >>>> Version Repository Size >>>> ============================================================ >>>> ================================================================= >>>> Removing: >>>> epel-release noarch >>>> 7-6 @extras 24 k >>>> >>>> Transaction Summary >>>> ============================================================ >>>> ================================================================= >>>> Remove 1 Package >>>> >>>> Installed size: 24 k >>>> Downloading packages: >>>> Running transaction check >>>> Running transaction test >>>> Transaction test succeeded >>>> Running transaction >>>> Erasing : epel-release-7-6.noarch >>>> >>>> 1/1 >>>> Verifying : epel-release-7-6.noarch >>>> >>>> 1/1 >>>> >>>> Removed: >>>> epel-release.noarch 0:7-6 >>>> >>>> >>>> >>>> Complete! >>>> [jjflynn22 at ipa-1 ~]$ sudo dnf repolist >>>> CentOS-7 - Base >>>> 8.4 MB/s | 8.8 MB 00:01 >>>> CentOS-7 - Updates >>>> 4.5 MB/s | 12 MB 00:02 >>>> CentOS-7 - Extras >>>> 1.9 MB/s | 569 kB 00:00 >>>> Using metadata from Sun Dec 4 18:06:04 2016 >>>> repo id repo >>>> name status >>>> base CentOS-7 - >>>> Base 9,007 >>>> extras CentOS-7 - >>>> Extras 393 >>>> updates CentOS-7 - >>>> Updates 2,560 >>>> [jjflynn22 at ipa-1 ~]$ sudo /root/ipa-le/setup-le.sh >>>> Using metadata from Sun Dec 4 18:06:04 2016 >>>> Package certbot-0.9.3-1.el7.noarch is already installed, skipping. >>>> Dependencies resolved. >>>> Nothing to do. >>>> Directory Manager password: >>>> >>>> Installing CA certificate, please wait >>>> CA certificate successfully installed >>>> The ipa-cacert-manage command was successful >>>> ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: Not logging to a file >>>> ipa: DEBUG: Loading Index file from '/var/lib/ipa-client/sysrestor >>>> e/sysrestore.index' >>>> ipa: DEBUG: importing all plugin modules in ipalib.plugins... >>>> ipa: DEBUG: importing plugin module ipalib.plugins.aci >>>> ipa: DEBUG: importing plugin module ipalib.plugins.automember >>>> ipa: DEBUG: importing plugin module ipalib.plugins.automount >>>> ipa: DEBUG: importing plugin module ipalib.plugins.baseldap >>>> ipa: DEBUG: importing plugin module ipalib.plugins.baseuser >>>> ipa: DEBUG: importing plugin module ipalib.plugins.batch >>>> ipa: DEBUG: importing plugin module ipalib.plugins.caacl >>>> ipa: DEBUG: importing plugin module ipalib.plugins.cert >>>> ipa: DEBUG: importing plugin module ipalib.plugins.certprofile >>>> ipa: DEBUG: importing plugin module ipalib.plugins.config >>>> ipa: DEBUG: importing plugin module ipalib.plugins.delegation >>>> ipa: DEBUG: importing plugin module ipalib.plugins.dns >>>> ipa: DEBUG: importing plugin module ipalib.plugins.domainlevel >>>> ipa: DEBUG: importing plugin module ipalib.plugins.group >>>> ipa: DEBUG: importing plugin module ipalib.plugins.hbacrule >>>> ipa: DEBUG: importing plugin module ipalib.plugins.hbacsvc >>>> ipa: DEBUG: importing plugin module ipalib.plugins.hbacsvcgroup >>>> ipa: DEBUG: importing plugin module ipalib.plugins.hbactest >>>> ipa: DEBUG: importing plugin module ipalib.plugins.host >>>> ipa: DEBUG: importing plugin module ipalib.plugins.hostgroup >>>> ipa: DEBUG: importing plugin module ipalib.plugins.idrange >>>> ipa: DEBUG: importing plugin module ipalib.plugins.idviews >>>> ipa: DEBUG: importing plugin module ipalib.plugins.internal >>>> ipa: DEBUG: importing plugin module ipalib.plugins.kerberos >>>> ipa: DEBUG: importing plugin module ipalib.plugins.krbtpolicy >>>> ipa: DEBUG: importing plugin module ipalib.plugins.migration >>>> ipa: DEBUG: importing plugin module ipalib.plugins.misc >>>> ipa: DEBUG: importing plugin module ipalib.plugins.netgroup >>>> ipa: DEBUG: importing plugin module ipalib.plugins.otpconfig >>>> ipa: DEBUG: importing plugin module ipalib.plugins.otptoken >>>> ipa: DEBUG: importing plugin module ipalib.plugins.otptoken_yubikey >>>> ipa: DEBUG: importing plugin module ipalib.plugins.passwd >>>> ipa: DEBUG: importing plugin module ipalib.plugins.permission >>>> ipa: DEBUG: importing plugin module ipalib.plugins.ping >>>> ipa: DEBUG: importing plugin module ipalib.plugins.pkinit >>>> ipa: DEBUG: importing plugin module ipalib.plugins.privilege >>>> ipa: DEBUG: importing plugin module ipalib.plugins.pwpolicy >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='klist' '-V' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout=Kerberos 5 version 1.13.2 >>>> >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: importing plugin module ipalib.plugins.radiusproxy >>>> ipa: DEBUG: importing plugin module ipalib.plugins.realmdomains >>>> ipa: DEBUG: importing plugin module ipalib.plugins.role >>>> ipa: DEBUG: importing plugin module ipalib.plugins.rpcclient >>>> ipa: DEBUG: importing plugin module ipalib.plugins.selfservice >>>> ipa: DEBUG: importing plugin module ipalib.plugins.selinuxusermap >>>> ipa: DEBUG: importing plugin module ipalib.plugins.server >>>> ipa: DEBUG: importing plugin module ipalib.plugins.service >>>> ipa: DEBUG: importing plugin module ipalib.plugins.servicedelegation >>>> ipa: DEBUG: importing plugin module ipalib.plugins.session >>>> ipa: DEBUG: importing plugin module ipalib.plugins.stageuser >>>> ipa: DEBUG: importing plugin module ipalib.plugins.sudocmd >>>> ipa: DEBUG: importing plugin module ipalib.plugins.sudocmdgroup >>>> ipa: DEBUG: importing plugin module ipalib.plugins.sudorule >>>> ipa: DEBUG: importing plugin module ipalib.plugins.topology >>>> ipa: DEBUG: importing plugin module ipalib.plugins.trust >>>> ipa: DEBUG: importing plugin module ipalib.plugins.user >>>> ipa: DEBUG: importing plugin module ipalib.plugins.vault >>>> ipa: DEBUG: importing plugin module ipalib.plugins.virtual >>>> ipa: DEBUG: Initializing principal host/ipa-1.kkgpitt.org at KKGPITT.ORG >>>> using keytab /etc/krb5.keytab >>>> ipa: DEBUG: using ccache /tmp/tmp-zgrScg/ccache >>>> ipa: DEBUG: Attempt 1/1: success >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:host/ >>>> ipa-1.kkgpitt.org at KKGPITT.ORG' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout=134111920 >>>> >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='keyctl' 'pipe' '134111920' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout=ipa_session=59c01d94b52f0586e30046bd36ef93a5; >>>> Domain=ipa-1.kkgpitt.org; Path=/ipa; Expires=Sun, 04 Dec 2016 23:21:13 >>>> GMT; Secure; HttpOnly >>>> ipa: DEBUG: stderr= >>>> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: found session_cookie in >>>> persistent storage for principal 'host/ipa-1.kkgpitt.org at KKGPITT.ORG', >>>> cookie: 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; Domain= >>>> ipa-1.kkgpitt.org; Path=/ipa; Expires=Sun, 04 Dec 2016 23:21:13 GMT; >>>> Secure; HttpOnly' >>>> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: setting session_cookie >>>> into context 'ipa_session=59c01d94b52f0586e30046bd36ef93a5;' >>>> ipa.ipalib.plugins.rpcclient.rpcclient: INFO: trying >>>> https://ipa-1.kkgpitt.org/ipa/session/json >>>> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: Created connection >>>> context.rpcclient_71021840 >>>> ipa.ipalib.plugins.rpcclient.rpcclient: INFO: Forwarding >>>> 'ca_is_enabled' to json server 'https://ipa-1.kkgpitt.org/ipa >>>> /session/json' >>>> ipa: DEBUG: NSSConnection init ipa-1.kkgpitt.org >>>> ipa: DEBUG: Connecting: 192.168.1.201:0 >>>> ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server >>>> ipa: DEBUG: cert valid True for "CN=ipa-1.kkgpitt.org,O=KKGPITT.ORG" >>>> ipa: DEBUG: handshake complete, peer = 192.168.1.201:443 >>>> ipa: DEBUG: Protocol: TLS1.2 >>>> ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_256_CBC_SHA >>>> ipa: DEBUG: received Set-Cookie 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; >>>> Domain=ipa-1.kkgpitt.org; Path=/ipa; Expires=Sun, 04 Dec 2016 23:26:28 >>>> GMT; Secure; HttpOnly' >>>> ipa: DEBUG: storing cookie 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; >>>> Domain=ipa-1.kkgpitt.org; Path=/ipa; Expires=Sun, 04 Dec 2016 23:26:28 >>>> GMT; Secure; HttpOnly' for principal host/ipa-1.kkgpitt.org at KKGPITT.ORG >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:host/ >>>> ipa-1.kkgpitt.org at KKGPITT.ORG' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout=134111920 >>>> >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:host/ >>>> ipa-1.kkgpitt.org at KKGPITT.ORG' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout=134111920 >>>> >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='keyctl' 'pupdate' '134111920' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: Destroyed connection >>>> context.rpcclient_71021840 >>>> ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing ldap:// >>>> ipa-1.kkgpitt.org:389 from SchemaCache >>>> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving schema for >>>> SchemaCache url=ldap://ipa-1.kkgpitt.org:389 >>>> conn= >>>> ipa: DEBUG: Loading Index file from '/var/lib/ipa/sysrestore/sysre >>>> store.index' >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-KKGPITT-ORG' >>>> '-A' '-n' 'KKGPITT.ORG IPA CA' '-t' 'CT,C,C' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/dirsrv/slapd-KKGPITT-ORG' >>>> '-A' '-n' 'DSTRootCAX3' '-t' 'C,,' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/bin/systemctl' 'is-active' ' >>>> dirsrv at KKGPITT-ORG.service' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout=active >>>> >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/bin/systemctl' '--system' 'daemon-reload' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/bin/systemctl' 'restart' 'dirsrv at KKGPITT-ORG.service >>>> ' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/bin/systemctl' 'is-active' ' >>>> dirsrv at KKGPITT-ORG.service' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout=active >>>> >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: wait_for_open_ports: localhost [389] timeout 300 >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/httpd/alias' '-A' '-n' ' >>>> KKGPITT.ORG IPA CA' '-t' 'CT,C,C' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/httpd/alias' '-A' '-n' >>>> 'DSTRootCAX3' '-t' 'C,,' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/bin/systemctl' 'is-active' 'httpd.service' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout=active >>>> >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/bin/systemctl' 'restart' 'httpd.service' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/bin/systemctl' 'is-active' 'httpd.service' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout=active >>>> >>>> ipa: DEBUG: stderr= >>>> ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: resubmitting >>>> certmonger request '20161204225818' >>>> ipa: DEBUG: certmonger request is in state >>>> dbus.String(u'GENERATING_CSR', variant_level=1) >>>> ipa: DEBUG: certmonger request is in state >>>> dbus.String(u'PRE_SAVE_CERT', variant_level=1) >>>> ipa: DEBUG: certmonger request is in state >>>> dbus.String(u'POST_SAVED_CERT', variant_level=1) >>>> ipa: DEBUG: certmonger request is in state >>>> dbus.String(u'POST_SAVED_CERT', variant_level=1) >>>> ipa: DEBUG: certmonger request is in state >>>> dbus.String(u'POST_SAVED_CERT', variant_level=1) >>>> ipa: DEBUG: certmonger request is in state dbus.String(u'MONITORING', >>>> variant_level=1) >>>> ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: modifying certmonger >>>> request '20161204225818' >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> Certificate Nickname Trust >>>> Attributes >>>> >>>> SSL,S/MIME,JAR/XPI >>>> >>>> KKGPITT.ORG IPA CA CT,C,C >>>> >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-L' '-n' ' >>>> KKGPITT.ORG IPA CA' '-a' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout=-----BEGIN CERTIFICATE----- >>>> MIIDjTCCAnWgAwIBAgIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtLS0dQ >>>> SVRULk9SRzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MTIw >>>> NDIyNTczNFoXDTM2MTIwNDIyNTczNFowNjEUMBIGA1UECgwLS0tHUElUVC5PUkcx >>>> HjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEB >>>> . >>> >>> . >>>> >>> BYuURWnoNBd110T0HFOnMOmN5ycnsMvCwCdUFuFKCsjNjCm5/oUCsWSVlad2bzlj >>>> 7gvnv3d6YmXwTzpOlOHpMu/S7y+JU5ErM9fp97R/vUvBz/7CM0MOKBgXMvfKTu6X >>>> PTROdl8lKofxA6TMvM+du020+o79dami0hWV/3cRN386huTDcWVn9gbud6hxX8U5 >>>> StsgHtJLlrm4tjLk8+S5VTDu9Y6EX7OsEX51RHwtrfNjEYdCa68AM2/slxdgf+5S >>>> IQ== >>>> -----END CERTIFICATE----- >>>> >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-D' '-n' ' >>>> KKGPITT.ORG IPA CA' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-L' '-n' ' >>>> KKGPITT.ORG IPA CA' '-a' >>>> ipa: DEBUG: Process finished, return code=255 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr=certutil: Could not find cert: KKGPITT.ORG IPA CA >>>> : PR_FILE_NOT_FOUND_ERROR: File not found >>>> >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L' '-n' >>>> 'IPA CA' '-a' >>>> ipa: DEBUG: Process finished, return code=255 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA >>>> : PR_FILE_NOT_FOUND_ERROR: File not found >>>> >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-L' '-n' >>>> 'External CA cert' '-a' >>>> ipa: DEBUG: Process finished, return code=255 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr=certutil: Could not find cert: External CA cert >>>> : PR_FILE_NOT_FOUND_ERROR: File not found >>>> >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-A' '-n' ' >>>> KKGPITT.ORG IPA CA' '-t' 'CT,C,C' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-A' '-n' >>>> 'DSTRootCAX3' '-t' 'C,,' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-A' '-n' ' >>>> KKGPITT.ORG IPA CA' '-t' 'CT,C,C' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-A' '-n' >>>> 'DSTRootCAX3' '-t' 'C,,' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/update-ca-trust' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: INFO: Systemwide CA database updated. >>>> ipa: DEBUG: Starting external process >>>> ipa: DEBUG: args='/usr/bin/update-ca-trust' >>>> ipa: DEBUG: Process finished, return code=0 >>>> ipa: DEBUG: stdout= >>>> ipa: DEBUG: stderr= >>>> ipa: INFO: Systemwide CA database updated. >>>> ipa.ipaclient.ipa_certupdate.CertUpdate: INFO: The ipa-certupdate >>>> command was successful >>>> Directory Manager password: >>>> >>>> Installing CA certificate, please wait >>>> Not a valid CA certificate: (SEC_ERROR_UNKNOWN_ISSUER) Peer's >>>> Certificate issuer is not recognized. (visit >>>> http://www.freeipa.org/page/Troubleshooting for troubleshooting guide) >>>> [jjflynn22 at ipa-1 ~]$ >>>> >>>> >>>> >>> >>> >>> Hi, >>> >>> you seem to have an issue when the LetsEncryptAuthorityX3 is being >>> installed. The certificate from the CA that issued this certificate >>> (DSTRootCAX3) seems to be installed correctly. Could you verify that >>> DSTRootCAX3 is marked as trusted CA by issuing: >>> >>> certutil -d /etc/httpd/alias/ -L >>> >>> The DSTRoootCAX3 should have C,, trust flags. >>> >>> There was an issue fixed last week that might caused this issue if >>> you've ever tried to install letsencrypt on this particular VM before: >>> https://github.com/freeipa/freeipa-letsencrypt/issues/1#issu >>> ecomment-263546822 If that's the case, you will need to re-install IPA >>> before the letsencrypt solution will work. >>> >>> I was not able to reproduce your issue with a clean machine. >>> >>> -- >>> Tomas Krizek >>> >>> >> > > -- > Tomas Krizek > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjflynn22 at gmail.com Mon Dec 5 17:02:51 2016 From: jjflynn22 at gmail.com (Joseph Flynn) Date: Mon, 5 Dec 2016 12:02:51 -0500 Subject: [Freeipa-users] Directory Manager Password Change | off topic In-Reply-To: <38C784D32FB4354DAED01CCB1BB5053517561B12@mail01.firstderivatives.com> References: <38C784D32FB4354DAED01CCB1BB5053517561B12@mail01.firstderivatives.com> Message-ID: Me too. Within minutes of my first posting, I have good old Kimmi offering me all kinds of favors. All of our emails are exposed to the group which I'd like to trust but we obviously can't. All it takes is for a spammer to join the group and they will eventually collect a group of active emails with a very targeted demographic. On Mon, Dec 5, 2016 at 11:45 AM, Stefan Uygur wrote: > Guys, > > Since I replied to the list I keep receiving spam emails, what is > happening? > > > > *From:* Stefan Uygur > *Sent:* 05 December 2016 16:40 > *To:* 'Callum Guy'; Florence Blanc-Renaud; freeipa-users at redhat.com > *Subject:* RE: [Freeipa-users] Directory Manager Password Change > > > > Glad you solved your issue. > > > > I?ve been there myself so don?t worry about it at all. > > > > *From:* Callum Guy [mailto:callum.guy at x-on.co.uk ] > *Sent:* 05 December 2016 16:37 > *To:* Stefan Uygur; Florence Blanc-Renaud; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Directory Manager Password Change > > > > Hi Stefan, > > > > Thanks for your input, I am able to clarify that I wasn't simply copying > and pasting in - the dollar sign was included in my password rather than > the example. But yes, no denying that my command line skills are to blame. > > > > Further to this problem I am happy to report that the issue is now solved. > My main issue was the dollar sign meaning that I had updated the DM > password incorrectly for FreeIPA. Secondly I appear to have caused an issue > with SSSD and it was a restart of this service which finally resolved the > issue for me. I doubt there is much to be learnt from my issue - definitely > user error. > > > > Thanks so much for your responses, very much appreciated. Apologies for > taking up your time. > > > > Callum > > > > > > > > On Mon, Dec 5, 2016 at 2:48 PM Stefan Uygur > wrote: > > Hi, > > I think you are copying and pasting the exact same commands from the > article, which is of course a wrong approach. Never copy/paste from web to > execute on your server. That $ signs indicates you can give any name you?d > like. > > > > Follow this article here: > > https://access.redhat.com/solutions/308623 > > > > Stefan > > > > > > *From:* freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces@ > redhat.com] *On Behalf Of *Callum Guy > *Sent:* 05 December 2016 13:38 > *To:* Florence Blanc-Renaud; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Directory Manager Password Change > > > > Hi Flo, > > > > I have indeed executed every step in order, including the one you have > indicated. > > > > The password I has used included a dollar sign and this meant that echo > -n $DM_PASSWORD > /root/dm_password didn't work as I had expected meaning > everything after the dollar was interpreted as a variable and was missing > in the file. I have corrected this and performed the full process again, > starting with the 389 reset however it is still not working correctly. > > > > I remain in the same state as before where the admin password has not been > changed - this confuses me as my understanding is that admin only exists as > the FreeIPA web admin user whose password I can change separately. Am i > misunderstanding, is there another admin user within FreeIPA which is > directly linked to the directory manager? > > > > Having run out of ideas I have just executed ipa-server-upgrade however > this hasn't helped. My situation remains as follows: > > > > *Works:* ldapsearch -x -D "cn=directory manager" -w *NEW_DM_PW *-s base > -b "" "objectclass=*" > > *Fails: *ldapsearch -h localhost -ZZ -p 389 -x -D > "uid=admin,ou=people,o=ipaca" -w *NEW_DM_PW *-b "" -s base > > > > Are you able to offer any other ideas? > > > > Other information: > > I can confirm that cacert.p12 has been updated by the actions performed. > > File /etc/pki/pki-tomcat/password.conf now contains a new line internaldb= > *NEW_DM_PW *(as per instruction 1 on FreeIPA link) > > > > Best Regards, > > > > Callum > > > > > > On Mon, Dec 5, 2016 at 1:08 PM Florence Blanc-Renaud > wrote: > > On 12/05/2016 01:05 PM, Callum Guy wrote: > > Hi All, > > > > I have been testing FreeIPA and now plan to migrate to production use - > > thanks for creating such a great application! > > > > During the test phase we have been using simple passwords for the admin > > and directory manager users however we need these changed before moving > > into production. I believe we can change the admin password using the > > web interface however as I understand it amending the directory manager > > password is not so straightforward. > > > > I have found this > > link https://www.freeipa.org/page/Howto/Change_Directory_ > Manager_Password however > > I am unsure if this is the correct procedure for our installation - > > certainly i am having no luck so far. > > > > We have the following setup: > > > > FreeIPA 4.2.0 - single master server (no replicas), multiple clients > > CentOS 7.2 > > > > I have tried the following steps in order: > > > > http://directory.fedoraproject.org/docs/389ds/howto/howto- > resetdirmgrpassword.html > > followed by > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > > > After completing that I am no longer able to authenticate user logins. > > The below covers my current situation: > > > > This works: > > ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" > > "objectclass=*" > > > > This does not work: > > ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" > > "objectclass=*" > > > > This works: > > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > > -W -b "" -s base > > OLDPASSWORD > > > > This does not work: > > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > > -W -b "" -s base > > NEWPASSWORD > > > Hi, > > your commands show that the Directory Manager password was properly > modified, but not admin's password. Did you run the step 3 Updating PKI > admin password of the procedure [1]? > ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W > -T /root/dm_password "uid=admin,ou=people,o=ipaca" > > Flo. > > [1] > https://www.freeipa.org/page/Howto/Change_Directory_ > Manager_Password#3._Update_PKI_admin_password > > > So i'm i a mixed up state! Is anyone able to offer advise on resolving > > this issue? > > > > Thank you, > > > > 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 <+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. > > > > > > > > > > *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. > > > > *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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkrizek at redhat.com Mon Dec 5 17:06:32 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Mon, 5 Dec 2016 18:06:32 +0100 Subject: [Freeipa-users] Let's Encrypt along with FreeIPA In-Reply-To: References: <608a680e-0761-1984-733a-f6a6cbd2600a@redhat.com> <0af9dbd3-e406-a615-f17d-9908a9d8b850@redhat.com> Message-ID: <568d8107-5884-cd62-534f-fb3f360e4257@redhat.com> On 12/05/2016 05:58 PM, Joseph Flynn wrote: > Thank you Tomas, those two do seem to be the same. I will try a fresh > VM (is there a particular distribution that you've had the best luck > with?) and try again. I've tested the procedure on Fedora 24. > > sudo openssl x509 -text -in /root/ipa-le/ca/DSTRootCAX3.pem | grep > 'Subject:' > sudo openssl x509 -text -in /root/ipa-le/ca/LetsEncryptAuthorityX3.pem > | grep 'Issuer:' > Subject: O=Digital Signature Trust Co., CN=DST Root CA X3 > Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3 > > > [jjflynn22 at ipa-1 ~]$ sudo certutil -d /etc/httpd/alias/ -L > > Certificate Nickname Trust > Attributes > SSL,S/MIME,JAR/XPI > > Signing-Cert u,u,u > DSTRootCAX3 C,, > ipaCert u,u,u > Server-Cert u,u,u > KKGPITT.ORG IPA > CA CT,C,C > > > On Mon, Dec 5, 2016 at 11:51 AM, Tomas Krizek >wrote: > > Please keep freeipa-users at redhat.com > in CC. > > On 12/05/2016 05:23 PM, Joseph Flynn wrote: >> By the way Tomas, can you recommend a good read to better >> understand how all of these certs play together in an >> architecture like this? I'm quite confident in Linux usage an >> admin but must admit this is not quite clear to me. > The chain of trust on the Let's Encrypt side is explained in > https://letsencrypt.org/certificates/ > On the FreeIPA side, there > are some articles on our wiki page related to Public Key > Infrastructure, for example http://www.freeipa.org/page/PKI > >> >> On Mon, Dec 5, 2016 at 11:19 AM, Joseph Flynn >> >wrote: >> >> Thank you for responding Tom. >> >> I created the CentOS 7 VM earlier in the week and did its >> updates and set the hostnames, etc and took a snapshot. I >> also tried on Ubuntu first but that had too many install hiccups. >> >> From that snapshot I have tried several times with the same >> results as recently as yesterday. >> >> Here is the output of your suggestion: >> >> [jjflynn22 at ipa-1 ~]$ sudo certutil -d /etc/httpd/alias/ -L >> [sudo] password for jjflynn22: >> >> Certificate Nickname Trust Attributes >> SSL,S/MIME,JAR/XPI >> >> Signing-Cert u,u,u >> DSTRootCAX3 C,, >> ipaCert u,u,u >> Server-Cert u,u,u >> KKGPITT.ORG IPA CA CT,C,C >> > This seems correct, however this information can be misleading if > DSTRootCAX3 was installed in FreeIPA before. > > The last thing I can think of is to verify that the Subject Field > of DTSRootCAX3 is in fact the same as the Issuer Field in the > LetsEncryptAuthorityX3 certificate. I've checked the ones that are > used in the git repo and they are correct, so I can't see how this > could be the issue, but just to verify: > > openssl x509 -text -in /root/ipa-le/ca/DSTRootCAX3.pem | grep > 'Subject:' > openssl x509 -text -in /root/ipa-le/ca/LetsEncryptAuthorityX3.pem > | grep 'Issuer:' > > If that doesn't reveal any difference, I'd suggest to attempt to > reproduce the issue with a clean environment (new VM) and if you > still encounter the same problem, please open an issue and provide > as much information as possible, including software versions. > https://github.com/freeipa/freeipa-letsencrypt/issues > >> >> >> >> Joe >> >> >> >> On Mon, Dec 5, 2016 at 10:35 AM, Tomas Krizek >> >wrote: >> >> >> >> On 12/05/2016 12:25 AM, Joseph Flynn wrote: >>> Sorry if this is not the appropriate forum for >>> discussing this topic. >>> >>> I have installed a FreeIPA system on CentOS 7 and am >>> trying to get the Let's Encrypt scripts to work as >>> defined in >>> https://github.com/freeipa/freeipa-letsencrypt >>> >>> >>> I hand to tinker with a combination of >>> enabling/disabling EPEL and this new tool DNF that I am >>> not too familiar with but eventually got the script to run. >>> >>> It is ending with the following error: >>> >>> ipa: INFO: Systemwide CA database updated. >>> ipa.ipaclient.ipa_certupdate.CertUpdate: INFO: The >>> ipa-certupdate command was successful >>> Directory Manager password: >>> >>> Installing CA certificate, please wait >>> Not a valid CA certificate: >>> (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer >>> is not recognized. (visit >>> http://www.freeipa.org/page/Troubleshooting >>> for >>> troubleshooting guide) >>> >>> >>> Does anyone recognize this situation? >>> >>> I have installed this on a VirtualBox client in Bridge >>> Network mode. Prior to trying to use a real >>> certificate, I could access the FreeIPA UI from Firefox >>> on both the VM and other computers in the home. I've >>> gotten a domain name and have that domain name pointed >>> to my home router with a handful of ports (those listed >>> at the end of the FreeIPA install) forwarded to my VM. >>> >>> For completeness, I have included the history below >>> along with the full output including a couple of >>> highlighted areas that could be errors. >>> >>> Thanks for any assistance from anyone who might notice >>> an error in my ways. >>> Joe >>> >>> >>> History: >>> 1 ifconfig -a >>> 2 sudo yum -y update >>> 3 cat /etc/hostname >>> 4 sudo echo 192.168.1.201 ipa-1.kkgpitt.org >>> ipa-1 >> /etc/hosts >>> 5 sudo vi /etc/hosts >>> 7 sudo reboot now >>> 8 hostname >>> 9 ifconfig -a >>> 11 sudo visudo >>> 12 sudo ls # just to set pw >>> 13 sudo yum install epel-release -y >>> 14 sudo yum install -y haveged >>> 15 sudo systemctl start haveged.service >>> 16 sudo ipa-server-install >>> 17 kinit admin >>> 18 firewall-cmd --permanent --add-service=ntp >>> 19 firewall-cmd --permanent --add-service=http >>> 20 firewall-cmd --permanent --add-service=https >>> 21 firewall-cmd --permanent --add-service=ldap >>> 22 firewall-cmd --permanent --add-service=ldaps >>> 23 firewall-cmd --permanent --add-service=kerberos >>> 24 firewall-cmd --permanent --add-service=kpasswd >>> 26 sudo authconfig --enablemkhomedir --update >>> 27 sudo chkconfig sssd on >>> 28 git config --global user.name "Joe >>> Flynn" >>> 29 git config --global user.email "jjflynn22 at gmail.com >>> " >>> 30 mkdir ~/.ssh >>> 31 cd ~/.ssh >>> 32 vi id_rsa >>> 33 vi id_rsa.pub >>> 34 chmod 700 ~/.ssh >>> 35 chmod 600 ~/.ssh/* >>> 36 ssh-add ~/.ssh/id_rsa >>> 37 sudo yum install -y letsencrypt >>> 38 sudo cp -r /etc/httpd/alias /etc/httpd/alias_backup >>> 39 cd ~ >>> 40 git clone >>> https://github.com/freeipa/freeipa-letsencrypt.git >>> >>> 41 sudo cp -r freeipa-letsencrypt /root/ipa-le >>> 42 sudo vi /root/ipa-le/renew-le.sh >>> 43 sudo yum install -y dnf >>> 44 sudo yum remove -y epel-release >>> 45 sudo dnf repolist >>> 46 sudo /root/ipa-le/setup-le.sh >>> 47 history >>> >>> >>> >>> [jjflynn22 at ipa-1 ~]$ sudo visudo >>> [sudo] password for jjflynn22: >>> [jjflynn22 at ipa-1 ~]$ sudo yum install epel-release -y >>> Loaded plugins: fastestmirror, langpacks >>> base | 3.6 kB 00:00:00 >>> extras | 3.4 kB 00:00:00 >>> updates | 3.4 kB 00:00:00 >>> Loading mirror speeds from cached hostfile >>> * base: repo1.ash.innoscale.net >>> >>> * extras: mirrors.advancedhosters.com >>> >>> * updates: mirror.cs.vt.edu >>> Resolving Dependencies >>> --> Running transaction check >>> ---> Package epel-release.noarch 0:7-6 will be installed >>> --> Finished Dependency Resolution >>> >>> Dependencies Resolved >>> >>> ============================================================================================================================= >>> Package Arch Version Repository Size >>> ============================================================================================================================= >>> Installing: >>> epel-release noarch 7-6 extras 14 k >>> >>> Transaction Summary >>> ============================================================================================================================= >>> Install 1 Package >>> >>> Total download size: 14 k >>> Installed size: 24 k >>> Downloading packages: >>> epel-release-7-6.noarch.rpm | 14 kB 00:00:00 >>> Running transaction check >>> Running transaction test >>> Transaction test succeeded >>> Running transaction >>> Installing : epel-release-7-6.noarch 1/1 >>> Verifying : epel-release-7-6.noarch 1/1 >>> >>> Installed: >>> epel-release.noarch 0:7-6 >>> >>> Complete! >>> [jjflynn22 at ipa-1 ~]$ sudo yum install -y haveged >>> Loaded plugins: fastestmirror, langpacks >>> epel/x86_64/metalink | 13 kB 00:00:00 >>> epel | 4.3 kB 00:00:00 >>> (1/3): epel/x86_64/updateinfo | 676 kB 00:00:00 >>> (2/3): epel/x86_64/group_gz | 170 kB 00:00:00 >>> (3/3): epel/x86_64/primary_db | 4.4 MB 00:00:01 >>> Loading mirror speeds from cached hostfile >>> * base: repo1.ash.innoscale.net >>> >>> * epel: ftp.osuosl.org >>> * extras: mirror.fusioncloud.co >>> >>> * updates: ftp.osuosl.org >>> Resolving Dependencies >>> --> Running transaction check >>> ---> Package haveged.x86_64 0:1.9.1-1.el7 will be >>> installed >>> --> Finished Dependency Resolution >>> >>> Dependencies Resolved >>> >>> ============================================================================================================================= >>> Package Arch Version >>> Repository Size >>> ============================================================================================================================= >>> Installing: >>> haveged x86_64 1.9.1-1.el7 >>> epel 61 k >>> >>> Transaction Summary >>> ============================================================================================================================= >>> Install 1 Package >>> >>> Total download size: 61 k >>> Installed size: 181 k >>> Downloading packages: >>> warning: >>> /var/cache/yum/x86_64/7/epel/packages/haveged-1.9.1-1.el7.x86_64.rpm: >>> Header V3 RSA/SHA256 Signature, key ID 352c64e5: NOKEY >>> Public key for haveged-1.9.1-1.el7.x86_64.rpm is not >>> installed >>> haveged-1.9.1-1.el7.x86_64.rpm | 61 kB 00:00:00 >>> Retrieving key from >>> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 >>> Importing GPG key 0x352C64E5: >>> Userid : "Fedora EPEL (7) >>> >> >" >>> Fingerprint: 91e9 7d7c 4a5e 96f1 7f3e 888f 6a2f >>> aea2 352c 64e5 >>> Package : epel-release-7-6.noarch (@extras) >>> From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 >>> Running transaction check >>> Running transaction test >>> Transaction test succeeded >>> Running transaction >>> Installing : haveged-1.9.1-1.el7.x86_64 1/1 >>> Verifying : haveged-1.9.1-1.el7.x86_64 1/1 >>> >>> Installed: >>> haveged.x86_64 0:1.9.1-1.el7 >>> >>> Complete! >>> [jjflynn22 at ipa-1 ~]$ sudo systemctl start >>> haveged.service >>> [jjflynn22 at ipa-1 ~]$ >>> [jjflynn22 at ipa-1 ~]$ >>> [jjflynn22 at ipa-1 ~]$ >>> [jjflynn22 at ipa-1 ~]$ >>> [jjflynn22 at ipa-1 ~]$ sudo ipa-server-install >>> >>> The log file for this installation can be found in >>> /var/log/ipaserver-install.log >>> ============================================================================== >>> This program will set up the IPA Server. >>> >>> This includes: >>> * Configure a stand-alone CA (dogtag) for >>> certificate management >>> * Configure the Network Time Daemon (ntpd) >>> * Create and configure an instance of Directory Server >>> * Create and configure a Kerberos Key Distribution >>> Center (KDC) >>> * Configure Apache (httpd) >>> >>> To accept the default shown in brackets, press the >>> Enter key. >>> >>> WARNING: conflicting time&date synchronization >>> service 'chronyd' will be disabled >>> in favor of ntpd >>> >>> Do you want to configure integrated DNS (BIND)? [no]: >>> >>> Enter the fully qualified domain name of the computer >>> on which you're setting up server software. Using >>> the form >>> . >>> Example: master.example.com . >>> >>> >>> Server host name [ipa-1.kkgpitt.org >>> ]: >>> >>> The domain name has been determined based on the >>> host name. >>> >>> Please confirm the domain name [kkgpitt.org >>> ]: >>> >>> The kerberos protocol requires a Realm name to be >>> defined. >>> This is typically the domain name converted to >>> uppercase. >>> >>> Please provide a realm name [KKGPITT.ORG >>> ]: >>> Certain directory server operations require an >>> administrative user. >>> This user is referred to as the Directory Manager >>> and has full access >>> to the Directory for system management tasks and >>> will be added to the >>> instance of directory server created for IPA. >>> The password must be at least 8 characters long. >>> >>> Directory Manager password: >>> Password (confirm): >>> >>> The IPA server requires an administrative user, >>> named 'admin'. >>> This user is a regular system account used for IPA >>> server administration. >>> >>> IPA admin password: >>> Password (confirm): >>> >>> >>> The IPA Master Server will be configured with: >>> Hostname: ipa-1.kkgpitt.org >>> IP address(es): 192.168.1.201 >>> Domain name: kkgpitt.org >>> Realm name: KKGPITT.ORG >>> >>> Continue to configure the system with these values? >>> [no]: yes >>> >>> The following operations may take some minutes to >>> complete. >>> Please wait until the prompt is returned. >>> >>> Configuring NTP daemon (ntpd) >>> [1/4]: stopping ntpd >>> [2/4]: writing configuration >>> [3/4]: configuring ntpd to start on boot >>> [4/4]: starting ntpd >>> Done configuring NTP daemon (ntpd). >>> Configuring directory server (dirsrv). Estimated >>> time: 1 minute >>> [1/42]: creating directory server user >>> [2/42]: creating directory server instance >>> [3/42]: adding default schema >>> [4/42]: enabling memberof plugin >>> [5/42]: enabling winsync plugin >>> [6/42]: configuring replication version plugin >>> [7/42]: enabling IPA enrollment plugin >>> [8/42]: enabling ldapi >>> [9/42]: configuring uniqueness plugin >>> [10/42]: configuring uuid plugin >>> [11/42]: configuring modrdn plugin >>> [12/42]: configuring DNS plugin >>> [13/42]: enabling entryUSN plugin >>> [14/42]: configuring lockout plugin >>> [15/42]: creating indices >>> [16/42]: enabling referential integrity plugin >>> [17/42]: configuring certmap.conf >>> [18/42]: configure autobind for root >>> [19/42]: configure new location for managed entries >>> [20/42]: configure dirsrv ccache >>> [21/42]: enable SASL mapping fallback >>> [22/42]: restarting directory server >>> [23/42]: adding default layout >>> [24/42]: adding delegation layout >>> [25/42]: creating container for managed entries >>> [26/42]: configuring user private groups >>> [27/42]: configuring netgroups from hostgroups >>> [28/42]: creating default Sudo bind user >>> [29/42]: creating default Auto Member layout >>> [30/42]: adding range check plugin >>> [31/42]: creating default HBAC rule allow_all >>> [32/42]: adding entries for topology management >>> [33/42]: initializing group membership >>> [34/42]: adding master entry >>> [35/42]: initializing domain level >>> [36/42]: configuring Posix uid/gid generation >>> [37/42]: adding replication acis >>> [38/42]: enabling compatibility plugin >>> [39/42]: activating sidgen plugin >>> [40/42]: activating extdom plugin >>> [41/42]: tuning directory server >>> [42/42]: configuring directory to start on boot >>> Done configuring directory server (dirsrv). >>> Configuring certificate server (pki-tomcatd). >>> Estimated time: 3 minutes 30 seconds >>> [1/28]: creating certificate server user >>> [2/28]: configuring certificate server instance >>> [3/28]: stopping certificate server instance to >>> update CS.cfg >>> [4/28]: backing up CS.cfg >>> [5/28]: disabling nonces >>> [6/28]: set up CRL publishing >>> [7/28]: enable PKIX certificate path discovery and >>> validation >>> [8/28]: starting certificate server instance >>> [9/28]: creating RA agent certificate database >>> [10/28]: importing CA chain to RA certificate database >>> [11/28]: fixing RA database permissions >>> [12/28]: setting up signing cert profile >>> [13/28]: setting audit signing renewal to 2 years >>> [14/28]: restarting certificate server >>> [15/28]: requesting RA certificate from CA >>> [16/28]: issuing RA agent certificate >>> [17/28]: adding RA agent as a trusted user >>> [18/28]: authorizing RA to modify profiles >>> [19/28]: configure certmonger for renewals >>> [20/28]: configure certificate renewals >>> [21/28]: configure RA certificate renewal >>> [22/28]: configure Server-Cert certificate renewal >>> [23/28]: Configure HTTP to proxy connections >>> [24/28]: restarting certificate server >>> [25/28]: migrating certificate profiles to LDAP >>> [26/28]: importing IPA certificate profiles >>> [27/28]: adding default CA ACL >>> [28/28]: updating IPA configuration >>> Done configuring certificate server (pki-tomcatd). >>> Configuring directory server (dirsrv). Estimated >>> time: 10 seconds >>> [1/3]: configuring ssl for ds instance >>> [2/3]: restarting directory server >>> [3/3]: adding CA certificate entry >>> Done configuring directory server (dirsrv). >>> Configuring Kerberos KDC (krb5kdc). Estimated time: >>> 30 seconds >>> [1/10]: adding sasl mappings to the directory >>> [2/10]: adding kerberos container to the directory >>> [3/10]: configuring KDC >>> [4/10]: initialize kerberos container >>> [5/10]: adding default ACIs >>> [6/10]: creating a keytab for the directory >>> [7/10]: creating a keytab for the machine >>> [8/10]: adding the password extension to the directory >>> [9/10]: starting the KDC >>> [10/10]: configuring KDC to start on boot >>> Done configuring Kerberos KDC (krb5kdc). >>> Configuring kadmin >>> [1/2]: starting kadmin >>> [2/2]: configuring kadmin to start on boot >>> Done configuring kadmin. >>> Configuring ipa_memcached >>> [1/2]: starting ipa_memcached >>> [2/2]: configuring ipa_memcached to start on boot >>> Done configuring ipa_memcached. >>> Configuring ipa-otpd >>> [1/2]: starting ipa-otpd >>> [2/2]: configuring ipa-otpd to start on boot >>> Done configuring ipa-otpd. >>> Configuring the web interface (httpd). Estimated >>> time: 1 minute >>> [1/19]: setting mod_nss port to 443 >>> [2/19]: setting mod_nss protocol list to TLSv1.0 - >>> TLSv1.2 >>> [3/19]: setting mod_nss password file >>> [4/19]: enabling mod_nss renegotiate >>> [5/19]: adding URL rewriting rules >>> [6/19]: configuring httpd >>> [7/19]: configure certmonger for renewals >>> [8/19]: setting up ssl >>> [9/19]: importing CA certificates from LDAP >>> [10/19]: setting up browser autoconfig >>> [11/19]: publish CA cert >>> [12/19]: creating a keytab for httpd >>> [13/19]: clean up any existing httpd ccache >>> [14/19]: configuring SELinux for httpd >>> [15/19]: create KDC proxy user >>> [16/19]: create KDC proxy config >>> [17/19]: enable KDC proxy >>> [18/19]: restarting httpd >>> [19/19]: configuring httpd to start on boot >>> Done configuring the web interface (httpd). >>> Applying LDAP updates >>> Upgrading IPA: >>> [1/9]: stopping directory server >>> [2/9]: saving configuration >>> [3/9]: disabling listeners >>> [4/9]: enabling DS global lock >>> [5/9]: starting directory server >>> [6/9]: upgrading server >>> [7/9]: stopping directory server >>> [8/9]: restoring configuration >>> [9/9]: starting directory server >>> Done. >>> Restarting the directory server >>> Restarting the KDC >>> Sample zone file for bind has been created in >>> /tmp/sample.zone.Yjwpca.db >>> Restarting the web server >>> ============================================================================== >>> Setup complete >>> >>> Next steps: >>> 1. You must make sure these network ports are open: >>> TCP Ports: >>> * 80, 443: HTTP/HTTPS >>> * 389, 636: LDAP/LDAPS >>> * 88, 464: kerberos >>> UDP Ports: >>> * 88, 464: kerberos >>> * 123: ntp >>> >>> 2. You can now obtain a kerberos ticket using >>> the command: 'kinit admin' >>> This ticket will allow you to use the IPA >>> tools (e.g., ipa user-add) >>> and the web user interface. >>> >>> Be sure to back up the CA certificates stored in >>> /root/cacert.p12 >>> These files are required to create replicas. The >>> password for these >>> files is the Directory Manager password >>> [jjflynn22 at ipa-1 ~]$ kinit admin >>> Password for admin at KKGPITT.ORG >>> : >>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >>> --add-service=ntp >>> success >>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >>> --add-service=http >>> success >>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >>> --add-service=https >>> success >>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >>> --add-service=ldap >>> success >>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >>> --add-service=ldaps >>> success >>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >>> --add-service=kerberos >>> success >>> [jjflynn22 at ipa-1 ~]$ firewall-cmd --permanent >>> --add-service=kpasswd >>> success >>> [jjflynn22 at ipa-1 ~]$ sudo authconfig >>> --enablemkhomedir --update >>> [jjflynn22 at ipa-1 ~]$ sudo chkconfig sssd on >>> Note: Forwarding request to 'systemctl enable >>> sssd.service'. >>> [jjflynn22 at ipa-1 ~]$ git config --global user.name >>> "Joe Flynn" >>> [jjflynn22 at ipa-1 ~]$ git config --global user.email >>> "jjflynn22 at gmail.com " >>> [jjflynn22 at ipa-1 ~]$ mkdir ~/.ssh >>> [jjflynn22 at ipa-1 ~]$ cd ~/.ssh >>> [jjflynn22 at ipa-1 .ssh]$ vi id_rsa >>> [jjflynn22 at ipa-1 .ssh]$ vi id_rsa.pub >>> [jjflynn22 at ipa-1 .ssh]$ chmod 700 ~/.ssh >>> [jjflynn22 at ipa-1 .ssh]$ chmod 600 ~/.ssh/* >>> [jjflynn22 at ipa-1 .ssh]$ ssh-add ~/.ssh/id_rsa >>> Identity added: /home/jjflynn22/.ssh/id_rsa >>> (/home/jjflynn22/.ssh/id_rsa) >>> [jjflynn22 at ipa-1 .ssh]$ sudo yum install -y letsencrypt >>> Loaded plugins: fastestmirror, langpacks >>> Loading mirror speeds from cached hostfile >>> * base: repo1.ash.innoscale.net >>> >>> * epel: mirror.cogentco.com >>> >>> * extras: chicago.gaminghost.co >>> >>> * updates: mirror.cs.vt.edu >>> Resolving Dependencies >>> --> Running transaction check >>> ---> Package certbot.noarch 0:0.9.3-1.el7 will be >>> installed >>> --> Processing Dependency: python2-certbot = >>> 0.9.3-1.el7 for package: certbot-0.9.3-1.el7.noarch >>> --> Running transaction check >>> ---> Package python2-certbot.noarch 0:0.9.3-1.el7 >>> will be installed >>> --> Processing Dependency: python2-acme = 0.9.3 for >>> package: python2-certbot-0.9.3-1.el7.no >>> arch >>> --> Processing Dependency: python2-dialog >= 3.3.0 >>> for package: python2-certbot-0.9.3-1.el7.no >>> arch >>> --> Processing Dependency: python2-configargparse >= >>> 0.10.0 for package: python2-certbot-0.9.3-1.el7.no >>> arch >>> --> Processing Dependency: python-psutil >= 2.1.0 >>> for package: python2-certbot-0.9.3-1.el7.no >>> arch >>> --> Processing Dependency: python-zope-interface for >>> package: python2-certbot-0.9.3-1.el7.no >>> arch >>> --> Processing Dependency: python-zope-component for >>> package: python2-certbot-0.9.3-1.el7.no >>> arch >>> --> Processing Dependency: python-parsedatetime for >>> package: python2-certbot-0.9.3-1.el7.no >>> arch >>> --> Processing Dependency: python-mock for package: >>> python2-certbot-0.9.3-1.el7.no >>> arch >>> --> Running transaction check >>> ---> Package python-parsedatetime.noarch 0:1.5-3.el7 >>> will be installed >>> ---> Package python-psutil.x86_64 0:2.2.1-1.el7 will >>> be installed >>> ---> Package python-zope-component.noarch >>> 1:4.1.0-1.el7 will be installed >>> --> Processing Dependency: python-zope-event for >>> package: 1:python-zope-component-4.1.0-1.el7.noarch >>> ---> Package python-zope-interface.x86_64 >>> 0:4.0.5-4.el7 will be installed >>> ---> Package python2-acme.noarch 0:0.9.3-1.el7 will >>> be installed >>> --> Processing Dependency: python-pyrfc3339 for >>> package: python2-acme-0.9.3-1.el7.noarch >>> --> Processing Dependency: python-ndg_httpsclient >>> for package: python2-acme-0.9.3-1.el7.noarch >>> ---> Package python2-configargparse.noarch >>> 0:0.10.0-1.el7 will be installed >>> ---> Package python2-dialog.noarch 0:3.3.0-6.el7 >>> will be installed >>> --> Processing Dependency: dialog for package: >>> python2-dialog-3.3.0-6.el7.noarch >>> ---> Package python2-mock.noarch 0:1.0.1-9.el7 will >>> be installed >>> --> Running transaction check >>> ---> Package dialog.x86_64 0:1.2-4.20130523.el7 will >>> be installed >>> ---> Package python-ndg_httpsclient.noarch >>> 0:0.3.2-1.el7 will be installed >>> ---> Package python-zope-event.noarch 0:4.0.3-2.el7 >>> will be installed >>> ---> Package python2-pyrfc3339.noarch 0:1.0-2.el7 >>> will be installed >>> --> Finished Dependency Resolution >>> >>> Dependencies Resolved >>> >>> ============================================================================================================================= >>> Package Arch Version >>> Repository Size >>> ============================================================================================================================= >>> Installing: >>> certbot noarch 0.9.3-1.el7 >>> epel 16 k >>> Installing for dependencies: >>> dialog x86_64 1.2-4.20130523.el7 >>> base 208 k >>> python-ndg_httpsclient noarch 0.3.2-1.el7 >>> epel 43 k >>> python-parsedatetime noarch 1.5-3.el7 >>> epel 61 k >>> python-psutil x86_64 2.2.1-1.el7 >>> epel 114 k >>> python-zope-component noarch >>> 1:4.1.0-1.el7 epel 110 k >>> python-zope-event noarch 4.0.3-2.el7 >>> epel 79 k >>> python-zope-interface x86_64 4.0.5-4.el7 >>> base 138 k >>> python2-acme noarch 0.9.3-1.el7 >>> epel 168 k >>> python2-certbot noarch 0.9.3-1.el7 >>> epel 361 k >>> python2-configargparse noarch >>> 0.10.0-1.el7 epel 28 k >>> python2-dialog noarch 3.3.0-6.el7 >>> epel 94 k >>> python2-mock noarch 1.0.1-9.el7 >>> epel 92 k >>> python2-pyrfc3339 noarch 1.0-2.el7 >>> epel 13 k >>> >>> Transaction Summary >>> ============================================================================================================================= >>> Install 1 Package (+13 Dependent packages) >>> >>> Total download size: 1.5 M >>> Installed size: 6.3 M >>> Downloading packages: >>> (1/14): >>> python-ndg_httpsclient-0.3.2-1.el7.noarch.rpm | 43 >>> kB 00:00:00 >>> (2/14): dialog-1.2-4.20130523.el7.x86_64.rpm | 208 >>> kB 00:00:00 >>> (3/14): certbot-0.9.3-1.el7.noarch.rpm | 16 kB >>> 00:00:00 >>> (4/14): python-parsedatetime-1.5-3.el7.noarch.rpm | >>> 61 kB 00:00:00 >>> (5/14): python-psutil-2.2.1-1.el7.x86_64.rpm | 114 >>> kB 00:00:00 >>> (6/14): python-zope-component-4.1.0-1.el7.noarch.rpm >>> | 110 kB 00:00:00 >>> (7/14): python-zope-interface-4.0.5-4.el7.x86_64.rpm >>> | 138 kB 00:00:00 >>> (8/14): python-zope-event-4.0.3-2.el7.noarch.rpm | >>> 79 kB 00:00:00 >>> (9/14): python2-certbot-0.9.3-1.el7.no >>> arch.rpm | >>> 361 kB 00:00:00 >>> (10/14): >>> python2-configargparse-0.10.0-1.el7.noarch.rpm | 28 >>> kB 00:00:00 >>> (11/14): python2-acme-0.9.3-1.el7.noarch.rpm | 168 >>> kB 00:00:00 >>> (12/14): python2-dialog-3.3.0-6.el7.noarch.rpm | 94 >>> kB 00:00:00 >>> (13/14): python2-pyrfc3339-1.0-2.el7.no >>> arch.rpm | >>> 13 kB 00:00:00 >>> (14/14): python2-mock-1.0.1-9.el7.noarch.rpm | 92 >>> kB 00:00:00 >>> ----------------------------------------------------------------------------------------------------------------------------- >>> Total 1.3 MB/s | 1.5 MB 00:00:01 >>> Running transaction check >>> Running transaction test >>> Transaction test succeeded >>> Running transaction >>> Installing : >>> python-zope-interface-4.0.5-4.el7.x86_64 1/14 >>> Installing : python2-mock-1.0.1-9.el7.noarch 2/14 >>> Installing : python-parsedatetime-1.5-3.el7.noarch >>> 3/14 >>> Installing : python-psutil-2.2.1-1.el7.x86_64 4/14 >>> Installing : python-zope-event-4.0.3-2.el7.noarch >>> 5/14 >>> Installing : >>> 1:python-zope-component-4.1.0-1.el7.noarch 6/14 >>> Installing : >>> python-ndg_httpsclient-0.3.2-1.el7.noarch 7/14 >>> Installing : python2-pyrfc3339-1.0-2.el7.no >>> arch 8/14 >>> Installing : python2-acme-0.9.3-1.el7.noarch 9/14 >>> Installing : >>> python2-configargparse-0.10.0-1.el7.noarch 10/14 >>> Installing : dialog-1.2-4.20130523.el7.x86_64 11/14 >>> Installing : python2-dialog-3.3.0-6.el7.noarch 12/14 >>> Installing : python2-certbot-0.9.3-1.el7.no >>> arch 13/14 >>> Installing : certbot-0.9.3-1.el7.noarch 14/14 >>> Verifying : dialog-1.2-4.20130523.el7.x86_64 1/14 >>> Verifying : certbot-0.9.3-1.el7.noarch 2/14 >>> Verifying : >>> python2-configargparse-0.10.0-1.el7.noarch 3/14 >>> Verifying : python2-pyrfc3339-1.0-2.el7.no >>> arch 4/14 >>> Verifying : >>> python-zope-interface-4.0.5-4.el7.x86_64 5/14 >>> Verifying : >>> python-ndg_httpsclient-0.3.2-1.el7.noarch 6/14 >>> Verifying : python-zope-event-4.0.3-2.el7.noarch >>> 7/14 >>> Verifying : python-psutil-2.2.1-1.el7.x86_64 8/14 >>> Verifying : python2-acme-0.9.3-1.el7.noarch 9/14 >>> Verifying : python2-dialog-3.3.0-6.el7.noarch 10/14 >>> Verifying : >>> 1:python-zope-component-4.1.0-1.el7.noarch 11/14 >>> Verifying : python-parsedatetime-1.5-3.el7.noarch >>> 12/14 >>> Verifying : python2-certbot-0.9.3-1.el7.no >>> arch 13/14 >>> Verifying : python2-mock-1.0.1-9.el7.noarch 14/14 >>> >>> Installed: >>> certbot.noarch 0:0.9.3-1.el7 >>> >>> Dependency Installed: >>> dialog.x86_64 0:1.2-4.20130523.el7 >>> python-ndg_httpsclient.noarch 0:0.3.2-1.el7 >>> python-parsedatetime.noarch 0:1.5-3.el7 >>> python-psutil.x86_64 0:2.2.1-1.el7 >>> python-zope-component.noarch 1:4.1.0-1.el7 >>> python-zope-event.noarch 0:4.0.3-2.el7 >>> python-zope-interface.x86_64 0:4.0.5-4.el7 >>> python2-acme.noarch 0:0.9.3-1.el7 >>> python2-certbot.noarch 0:0.9.3-1.el7 >>> python2-configargparse.noarch 0:0.10.0-1.el7 >>> python2-dialog.noarch 0:3.3.0-6.el7 >>> python2-mock.noarch 0:1.0.1-9.el7 >>> python2-pyrfc3339.noarch 0:1.0-2.el7 >>> >>> Complete! >>> [jjflynn22 at ipa-1 .ssh]$ >>> [jjflynn22 at ipa-1 .ssh]$ >>> [jjflynn22 at ipa-1 .ssh]$ sudo cp -r /etc/httpd/alias >>> /etc/httpd/alias_backup >>> [jjflynn22 at ipa-1 .ssh]$ cd ~ >>> [jjflynn22 at ipa-1 ~]$ git clone >>> https://github.com/freeipa/freeipa-letsencrypt.git >>> >>> Cloning into 'freeipa-letsencrypt'... >>> remote: Counting objects: 45, done. >>> remote: Compressing objects: 100% (4/4), done. >>> remote: Total 45 (delta 0), reused 0 (delta 0), >>> pack-reused 41 >>> Unpacking objects: 100% (45/45), done. >>> [jjflynn22 at ipa-1 ~]$ sudo cp -r freeipa-letsencrypt >>> /root/ipa-le >>> [jjflynn22 at ipa-1 ~]$ sudo vi /root/ipa-le/renew-le.sh >>> [jjflynn22 at ipa-1 ~]$ sudo yum install -y dnf >>> Loaded plugins: fastestmirror, langpacks >>> Loading mirror speeds from cached hostfile >>> * base: repo1.ash.innoscale.net >>> >>> * epel: mirror.cogentco.com >>> >>> * extras: mirrors.advancedhosters.com >>> >>> * updates: mirror.cs.vt.edu >>> Resolving Dependencies >>> --> Running transaction check >>> ---> Package dnf.noarch 0:0.6.4-2.el7 will be installed >>> --> Processing Dependency: python-dnf = 0.6.4-2.el7 >>> for package: dnf-0.6.4-2.el7.noarch >>> --> Running transaction check >>> ---> Package python-dnf.noarch 0:0.6.4-2.el7 will be >>> installed >>> --> Processing Dependency: dnf-conf = 0.6.4-2.el7 >>> for package: python-dnf-0.6.4-2.el7.noarch >>> --> Processing Dependency: python-librepo >= 1.7.5 >>> for package: python-dnf-0.6.4-2.el7.noarch >>> --> Processing Dependency: python-libcomps >= 0.1.6 >>> for package: python-dnf-0.6.4-2.el7.noarch >>> --> Processing Dependency: python-hawkey >= 0.5.3 >>> for package: python-dnf-0.6.4-2.el7.noarch >>> --> Running transaction check >>> ---> Package dnf-conf.noarch 0:0.6.4-2.el7 will be >>> installed >>> ---> Package python-hawkey.x86_64 >>> 0:0.5.8-2.git.0.202b194.el7 will be installed >>> --> Processing Dependency: hawkey(x86-64) = >>> 0.5.8-2.git.0.202b194.el7 for package: >>> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >>> --> Processing Dependency: >>> libsolv.so.0(SOLV_1.0)(64bit) for package: >>> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >>> --> Processing Dependency: libsolv.so.0()(64bit) for >>> package: python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >>> --> Processing Dependency: libhawkey.so.2()(64bit) >>> for package: >>> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 >>> ---> Package python-libcomps.x86_64 0:0.1.6-13.el7 >>> will be installed >>> --> Processing Dependency: libcomps(x86-64) = >>> 0.1.6-13.el7 for package: >>> python-libcomps-0.1.6-13.el7.x86_64 >>> --> Processing Dependency: >>> libcomps.so.0.1.6()(64bit) for package: >>> python-libcomps-0.1.6-13.el7.x86_64 >>> ---> Package python-librepo.x86_64 0:1.7.16-1.el7 >>> will be installed >>> --> Processing Dependency: librepo(x86-64) = >>> 1.7.16-1.el7 for package: >>> python-librepo-1.7.16-1.el7.x86_64 >>> --> Processing Dependency: librepo.so.0()(64bit) for >>> package: python-librepo-1.7.16-1.el7.x86_64 >>> --> Running transaction check >>> ---> Package hawkey.x86_64 >>> 0:0.5.8-2.git.0.202b194.el7 will be installed >>> ---> Package libcomps.x86_64 0:0.1.6-13.el7 will be >>> installed >>> ---> Package librepo.x86_64 0:1.7.16-1.el7 will be >>> installed >>> ---> Package libsolv.x86_64 0:0.6.11-1.el7 will be >>> installed >>> --> Finished Dependency Resolution >>> >>> Dependencies Resolved >>> >>> ============================================================================================================================= >>> Package Arch Version Repository Size >>> ============================================================================================================================= >>> Installing: >>> dnf noarch 0.6.4-2.el7 epel 209 k >>> Installing for dependencies: >>> dnf-conf noarch 0.6.4-2.el7 >>> epel 61 k >>> hawkey x86_64 0.5.8-2.git.0.202b194.el7 >>> base 87 k >>> libcomps x86_64 0.1.6-13.el7 >>> epel 72 k >>> librepo x86_64 1.7.16-1.el7 >>> base 77 k >>> libsolv x86_64 0.6.11-1.el7 base >>> 316 k >>> python-dnf noarch 0.6.4-2.el7 >>> epel 407 k >>> python-hawkey x86_64 0.5.8-2.git.0.202b194.el7 >>> base 71 k >>> python-libcomps x86_64 0.1.6-13.el7 >>> epel 44 k >>> python-librepo x86_64 1.7.16-1.el7 >>> base 49 k >>> >>> Transaction Summary >>> ============================================================================================================================= >>> Install 1 Package (+9 Dependent packages) >>> >>> Total download size: 1.4 M >>> Installed size: 4.1 M >>> Downloading packages: >>> (1/10): hawkey-0.5.8-2.git.0.202b194.el7.x86_64.rpm >>> | 87 kB 00:00:00 >>> (2/10): dnf-conf-0.6.4-2.el7.noarch.rpm | 61 kB >>> 00:00:00 >>> (3/10): dnf-0.6.4-2.el7.noarch.rpm | 209 kB 00:00:00 >>> (4/10): librepo-1.7.16-1.el7.x86_64.rpm | 77 kB >>> 00:00:00 >>> (5/10): libcomps-0.1.6-13.el7.x86_64.rpm | 72 kB >>> 00:00:00 >>> (6/10): python-librepo-1.7.16-1.el7.x86_64.rpm | 49 >>> kB 00:00:00 >>> (7/10): python-libcomps-0.1.6-13.el7.x86_64.rpm | >>> 44 kB 00:00:00 >>> (8/10): >>> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64.rpm >>> | 71 kB 00:00:00 >>> (9/10): python-dnf-0.6.4-2.el7.noarch.rpm | 407 kB >>> 00:00:00 >>> (10/10): libsolv-0.6.11-1.el7.x86_64.rpm | 316 kB >>> 00:00:00 >>> ----------------------------------------------------------------------------------------------------------------------------- >>> Total 1.4 MB/s | 1.4 MB 00:00:01 >>> Running transaction check >>> Running transaction test >>> Transaction test succeeded >>> Running transaction >>> Installing : libsolv-0.6.11-1.el7.x86_64 1/10 >>> Installing : >>> hawkey-0.5.8-2.git.0.202b194.el7.x86_64 2/10 >>> Installing : >>> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 3/10 >>> Installing : dnf-conf-0.6.4-2.el7.noarch 4/10 >>> Installing : libcomps-0.1.6-13.el7.x86_64 5/10 >>> Installing : python-libcomps-0.1.6-13.el7.x86_64 6/10 >>> Installing : librepo-1.7.16-1.el7.x86_64 7/10 >>> Installing : python-librepo-1.7.16-1.el7.x86_64 8/10 >>> Installing : python-dnf-0.6.4-2.el7.noarch 9/10 >>> Installing : dnf-0.6.4-2.el7.noarch 10/10 >>> Verifying : librepo-1.7.16-1.el7.x86_64 1/10 >>> Verifying : python-libcomps-0.1.6-13.el7.x86_64 2/10 >>> Verifying : >>> python-hawkey-0.5.8-2.git.0.202b194.el7.x86_64 3/10 >>> Verifying : python-librepo-1.7.16-1.el7.x86_64 4/10 >>> Verifying : python-dnf-0.6.4-2.el7.noarch 5/10 >>> Verifying : libcomps-0.1.6-13.el7.x86_64 6/10 >>> Verifying : >>> hawkey-0.5.8-2.git.0.202b194.el7.x86_64 7/10 >>> Verifying : dnf-conf-0.6.4-2.el7.noarch 8/10 >>> Verifying : dnf-0.6.4-2.el7.noarch 9/10 >>> Verifying : libsolv-0.6.11-1.el7.x86_64 10/10 >>> >>> Installed: >>> dnf.noarch 0:0.6.4-2.el7 >>> >>> Dependency Installed: >>> dnf-conf.noarch 0:0.6.4-2.el7 hawkey.x86_64 >>> 0:0.5.8-2.git.0.202b194.el7 >>> libcomps.x86_64 0:0.1.6-13.el7 librepo.x86_64 >>> 0:1.7.16-1.el7 >>> libsolv.x86_64 0:0.6.11-1.el7 python-dnf.noarch >>> 0:0.6.4-2.el7 >>> python-hawkey.x86_64 0:0.5.8-2.git.0.202b194.el7 >>> python-libcomps.x86_64 0:0.1.6-13.el7 >>> python-librepo.x86_64 0:1.7.16-1.el7 >>> >>> Complete! >>> [jjflynn22 at ipa-1 ~]$ sudo yum remove -y epel-release >>> Loaded plugins: fastestmirror, langpacks >>> Resolving Dependencies >>> --> Running transaction check >>> ---> Package epel-release.noarch 0:7-6 will be erased >>> --> Finished Dependency Resolution >>> >>> Dependencies Resolved >>> >>> ============================================================================================================================= >>> Package Arch Version Repository Size >>> ============================================================================================================================= >>> Removing: >>> epel-release noarch 7-6 @extras 24 k >>> >>> Transaction Summary >>> ============================================================================================================================= >>> Remove 1 Package >>> >>> Installed size: 24 k >>> Downloading packages: >>> Running transaction check >>> Running transaction test >>> Transaction test succeeded >>> Running transaction >>> Erasing : epel-release-7-6.noarch 1/1 >>> Verifying : epel-release-7-6.noarch 1/1 >>> >>> Removed: >>> epel-release.noarch 0:7-6 >>> >>> Complete! >>> [jjflynn22 at ipa-1 ~]$ sudo dnf repolist >>> CentOS-7 - Base 8.4 MB/s | 8.8 MB 00:01 >>> CentOS-7 - Updates 4.5 MB/s | 12 MB 00:02 >>> CentOS-7 - Extras 1.9 MB/s | 569 kB 00:00 >>> Using metadata from Sun Dec 4 18:06:04 2016 >>> repo id repo name status >>> base CentOS-7 - Base 9,007 >>> extras CentOS-7 - Extras 393 >>> updates CentOS-7 - Updates 2,560 >>> [jjflynn22 at ipa-1 ~]$ sudo /root/ipa-le/setup-le.sh >>> Using metadata from Sun Dec 4 18:06:04 2016 >>> Package certbot-0.9.3-1.el7.noarch is already >>> installed, skipping. >>> Dependencies resolved. >>> Nothing to do. >>> Directory Manager password: >>> >>> Installing CA certificate, please wait >>> CA certificate successfully installed >>> The ipa-cacert-manage command was successful >>> ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: Not >>> logging to a file >>> ipa: DEBUG: Loading Index file from >>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>> ipa: DEBUG: importing all plugin modules in >>> ipalib.plugins... >>> ipa: DEBUG: importing plugin module ipalib.plugins.aci >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.automember >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.automount >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.baseldap >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.baseuser >>> ipa: DEBUG: importing plugin module ipalib.plugins.batch >>> ipa: DEBUG: importing plugin module ipalib.plugins.caacl >>> ipa: DEBUG: importing plugin module ipalib.plugins.cert >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.certprofile >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.config >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.delegation >>> ipa: DEBUG: importing plugin module ipalib.plugins.dns >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.domainlevel >>> ipa: DEBUG: importing plugin module ipalib.plugins.group >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.hbacrule >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.hbacsvc >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.hbacsvcgroup >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.hbactest >>> ipa: DEBUG: importing plugin module ipalib.plugins.host >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.hostgroup >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.idrange >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.idviews >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.internal >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.kerberos >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.krbtpolicy >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.migration >>> ipa: DEBUG: importing plugin module ipalib.plugins.misc >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.netgroup >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.otpconfig >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.otptoken >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.otptoken_yubikey >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.passwd >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.permission >>> ipa: DEBUG: importing plugin module ipalib.plugins.ping >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.pkinit >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.privilege >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.pwpolicy >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='klist' '-V' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout=Kerberos 5 version 1.13.2 >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.radiusproxy >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.realmdomains >>> ipa: DEBUG: importing plugin module ipalib.plugins.role >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.rpcclient >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.selfservice >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.selinuxusermap >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.server >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.service >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.servicedelegation >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.session >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.stageuser >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.sudocmd >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.sudocmdgroup >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.sudorule >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.topology >>> ipa: DEBUG: importing plugin module ipalib.plugins.trust >>> ipa: DEBUG: importing plugin module ipalib.plugins.user >>> ipa: DEBUG: importing plugin module ipalib.plugins.vault >>> ipa: DEBUG: importing plugin module >>> ipalib.plugins.virtual >>> ipa: DEBUG: Initializing principal >>> host/ipa-1.kkgpitt.org at KKGPITT.ORG >>> using keytab >>> /etc/krb5.keytab >>> ipa: DEBUG: using ccache /tmp/tmp-zgrScg/ccache >>> ipa: DEBUG: Attempt 1/1: success >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='keyctl' 'search' '@s' 'user' >>> 'ipa_session_cookie:host/ipa-1.kkgpitt.org at KKGPITT.ORG >>> ' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout=134111920 >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='keyctl' 'pipe' '134111920' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: >>> stdout=ipa_session=59c01d94b52f0586e30046bd36ef93a5; >>> Domain=ipa-1.kkgpitt.org ; >>> Path=/ipa; Expires=Sun, 04 Dec 2016 23:21:13 GMT; >>> Secure; HttpOnly >>> ipa: DEBUG: stderr= >>> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: found >>> session_cookie in persistent storage for principal >>> 'host/ipa-1.kkgpitt.org at KKGPITT.ORG >>> ', cookie: >>> 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; >>> Domain=ipa-1.kkgpitt.org ; >>> Path=/ipa; Expires=Sun, 04 Dec 2016 23:21:13 GMT; >>> Secure; HttpOnly' >>> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: >>> setting session_cookie into context >>> 'ipa_session=59c01d94b52f0586e30046bd36ef93a5;' >>> ipa.ipalib.plugins.rpcclient.rpcclient: INFO: trying >>> https://ipa-1.kkgpitt.org/ipa/session/json >>> >>> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: >>> Created connection context.rpcclient_71021840 >>> ipa.ipalib.plugins.rpcclient.rpcclient: INFO: >>> Forwarding 'ca_is_enabled' to json server >>> 'https://ipa-1.kkgpitt.org/ipa/session/json >>> ' >>> ipa: DEBUG: NSSConnection init ipa-1.kkgpitt.org >>> >>> ipa: DEBUG: Connecting: 192.168.1.201:0 >>> >>> ipa: DEBUG: approved_usage = SSL Server >>> intended_usage = SSL Server >>> ipa: DEBUG: cert valid True for >>> "CN=ipa-1.kkgpitt.org >>> ,O=KKGPITT.ORG >>> " >>> ipa: DEBUG: handshake complete, peer = >>> 192.168.1.201:443 >>> ipa: DEBUG: Protocol: TLS1.2 >>> ipa: DEBUG: Cipher: TLS_RSA_WITH_AES_256_CBC_SHA >>> ipa: DEBUG: received Set-Cookie >>> 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; >>> Domain=ipa-1.kkgpitt.org ; >>> Path=/ipa; Expires=Sun, 04 Dec 2016 23:26:28 GMT; >>> Secure; HttpOnly' >>> ipa: DEBUG: storing cookie >>> 'ipa_session=59c01d94b52f0586e30046bd36ef93a5; >>> Domain=ipa-1.kkgpitt.org ; >>> Path=/ipa; Expires=Sun, 04 Dec 2016 23:26:28 GMT; >>> Secure; HttpOnly' for principal >>> host/ipa-1.kkgpitt.org at KKGPITT.ORG >>> >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='keyctl' 'search' '@s' 'user' >>> 'ipa_session_cookie:host/ipa-1.kkgpitt.org at KKGPITT.ORG >>> ' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout=134111920 >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='keyctl' 'search' '@s' 'user' >>> 'ipa_session_cookie:host/ipa-1.kkgpitt.org at KKGPITT.ORG >>> ' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout=134111920 >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='keyctl' 'pupdate' '134111920' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa.ipalib.plugins.rpcclient.rpcclient: DEBUG: >>> Destroyed connection context.rpcclient_71021840 >>> ipa.ipapython.ipaldap.SchemaCache: DEBUG: flushing >>> ldap://ipa-1.kkgpitt.org:389 >>> from SchemaCache >>> ipa.ipapython.ipaldap.SchemaCache: DEBUG: retrieving >>> schema for SchemaCache >>> url=ldap://ipa-1.kkgpitt.org:389 >>> >>> conn=>> 0x42a2fc8> >>> ipa: DEBUG: Loading Index file from >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/dirsrv/slapd-KKGPITT-ORG' '-A' '-n' >>> 'KKGPITT.ORG IPA CA' '-t' 'CT,C,C' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/dirsrv/slapd-KKGPITT-ORG' '-A' '-n' >>> 'DSTRootCAX3' '-t' 'C,,' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/bin/systemctl' 'is-active' >>> 'dirsrv at KKGPITT-ORG.service >>> ' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout=active >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/bin/systemctl' '--system' >>> 'daemon-reload' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/bin/systemctl' 'restart' >>> 'dirsrv at KKGPITT-ORG.service >>> ' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/bin/systemctl' 'is-active' >>> 'dirsrv at KKGPITT-ORG.service >>> ' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout=active >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: wait_for_open_ports: localhost [389] >>> timeout 300 >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/httpd/alias' '-A' '-n' 'KKGPITT.ORG >>> IPA CA' '-t' 'CT,C,C' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/httpd/alias' '-A' '-n' 'DSTRootCAX3' '-t' 'C,,' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/bin/systemctl' 'is-active' >>> 'httpd.service' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout=active >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/bin/systemctl' 'restart' >>> 'httpd.service' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/bin/systemctl' 'is-active' >>> 'httpd.service' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout=active >>> >>> ipa: DEBUG: stderr= >>> ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: >>> resubmitting certmonger request '20161204225818' >>> ipa: DEBUG: certmonger request is in state >>> dbus.String(u'GENERATING_CSR', variant_level=1) >>> ipa: DEBUG: certmonger request is in state >>> dbus.String(u'PRE_SAVE_CERT', variant_level=1) >>> ipa: DEBUG: certmonger request is in state >>> dbus.String(u'POST_SAVED_CERT', variant_level=1) >>> ipa: DEBUG: certmonger request is in state >>> dbus.String(u'POST_SAVED_CERT', variant_level=1) >>> ipa: DEBUG: certmonger request is in state >>> dbus.String(u'POST_SAVED_CERT', variant_level=1) >>> ipa: DEBUG: certmonger request is in state >>> dbus.String(u'MONITORING', variant_level=1) >>> ipa.ipaclient.ipa_certupdate.CertUpdate: DEBUG: >>> modifying certmonger request '20161204225818' >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/ipa/nssdb' '-L' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> Certificate Nickname Trust Attributes >>> SSL,S/MIME,JAR/XPI >>> >>> KKGPITT.ORG IPA CA CT,C,C >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/pki/nssdb' '-L' '-n' 'KKGPITT.ORG >>> IPA CA' '-a' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout=-----BEGIN CERTIFICATE----- >>> MIIDjTCCAnWgAwIBAgIBATANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKDAtLS0dQ >>> SVRULk9SRzEeMBwGA1UEAwwVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE2MTIw >>> NDIyNTczNFoXDTM2MTIwNDIyNTczNFowNjEUMBIGA1UECgwLS0tHUElUVC5PUkcx >>> HjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEB >>> . >>> >>> . >>> >>> BYuURWnoNBd110T0HFOnMOmN5ycnsMvCwCdUFuFKCsjNjCm5/oUCsWSVlad2bzlj >>> 7gvnv3d6YmXwTzpOlOHpMu/S7y+JU5ErM9fp97R/vUvBz/7CM0MOKBgXMvfKTu6X >>> PTROdl8lKofxA6TMvM+du020+o79dami0hWV/3cRN386huTDcWVn9gbud6hxX8U5 >>> StsgHtJLlrm4tjLk8+S5VTDu9Y6EX7OsEX51RHwtrfNjEYdCa68AM2/slxdgf+5S >>> IQ== >>> -----END CERTIFICATE----- >>> >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/pki/nssdb' '-D' '-n' 'KKGPITT.ORG >>> IPA CA' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/pki/nssdb' '-L' '-n' 'KKGPITT.ORG >>> IPA CA' '-a' >>> ipa: DEBUG: Process finished, return code=255 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr=certutil: Could not find cert: >>> KKGPITT.ORG IPA CA >>> : PR_FILE_NOT_FOUND_ERROR: File not found >>> >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/ipa/nssdb' '-L' '-n' 'IPA CA' '-a' >>> ipa: DEBUG: Process finished, return code=255 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr=certutil: Could not find cert: IPA CA >>> : PR_FILE_NOT_FOUND_ERROR: File not found >>> >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/ipa/nssdb' '-L' '-n' 'External CA cert' '-a' >>> ipa: DEBUG: Process finished, return code=255 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr=certutil: Could not find cert: >>> External CA cert >>> : PR_FILE_NOT_FOUND_ERROR: File not found >>> >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/ipa/nssdb' '-A' '-n' 'KKGPITT.ORG >>> IPA CA' '-t' 'CT,C,C' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/ipa/nssdb' '-A' '-n' 'DSTRootCAX3' '-t' 'C,,' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/pki/nssdb' '-A' '-n' 'KKGPITT.ORG >>> IPA CA' '-t' 'CT,C,C' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/certutil' '-d' >>> '/etc/pki/nssdb' '-A' '-n' 'DSTRootCAX3' '-t' 'C,,' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/update-ca-trust' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: INFO: Systemwide CA database updated. >>> ipa: DEBUG: Starting external process >>> ipa: DEBUG: args='/usr/bin/update-ca-trust' >>> ipa: DEBUG: Process finished, return code=0 >>> ipa: DEBUG: stdout= >>> ipa: DEBUG: stderr= >>> ipa: INFO: Systemwide CA database updated. >>> ipa.ipaclient.ipa_certupdate.CertUpdate: INFO: The >>> ipa-certupdate command was successful >>> Directory Manager password: >>> >>> Installing CA certificate, please wait >>> Not a valid CA certificate: >>> (SEC_ERROR_UNKNOWN_ISSUER) Peer's Certificate issuer >>> is not recognized. (visit >>> http://www.freeipa.org/page/Troubleshooting >>> for >>> troubleshooting guide) >>> [jjflynn22 at ipa-1 ~]$ >>> >>> >>> >>> >> Hi, >> >> you seem to have an issue when the LetsEncryptAuthorityX3 >> is being installed. The certificate from the CA that >> issued this certificate (DSTRootCAX3) seems to be >> installed correctly. Could you verify that DSTRootCAX3 is >> marked as trusted CA by issuing: >> >> certutil -d /etc/httpd/alias/ -L >> >> The DSTRoootCAX3 should have C,, trust flags. >> >> There was an issue fixed last week that might caused this >> issue if you've ever tried to install letsencrypt on this >> particular VM before: >> https://github.com/freeipa/freeipa-letsencrypt/issues/1#issuecomment-263546822 >> If >> that's the case, you will need to re-install IPA before >> the letsencrypt solution will work. >> >> I was not able to reproduce your issue with a clean machine. >> >> -- >> Tomas Krizek >> >> >> > > -- > Tomas Krizek > > -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjflynn22 at gmail.com Mon Dec 5 17:09:49 2016 From: jjflynn22 at gmail.com (Joseph Flynn) Date: Mon, 5 Dec 2016 12:09:49 -0500 Subject: [Freeipa-users] Directory Manager Password Change | off topic In-Reply-To: References: <38C784D32FB4354DAED01CCB1BB5053517561B12@mail01.firstderivatives.com> Message-ID: Ah, now SophiaB wants in on the action too. Looks like my lucky day. Seriously though, I think the community needs to anonymize participants out of necessity. On Mon, Dec 5, 2016 at 12:02 PM, Joseph Flynn wrote: > Me too. Within minutes of my first posting, I have good old Kimmi > offering me all kinds of favors. All of our emails are exposed to the > group which I'd like to trust but we obviously can't. All it takes is for > a spammer to join the group and they will eventually collect a group of > active emails with a very targeted demographic. > > On Mon, Dec 5, 2016 at 11:45 AM, Stefan Uygur > wrote: > >> Guys, >> >> Since I replied to the list I keep receiving spam emails, what is >> happening? >> >> >> >> *From:* Stefan Uygur >> *Sent:* 05 December 2016 16:40 >> *To:* 'Callum Guy'; Florence Blanc-Renaud; freeipa-users at redhat.com >> *Subject:* RE: [Freeipa-users] Directory Manager Password Change >> >> >> >> Glad you solved your issue. >> >> >> >> I?ve been there myself so don?t worry about it at all. >> >> >> >> *From:* Callum Guy [mailto:callum.guy at x-on.co.uk ] >> >> *Sent:* 05 December 2016 16:37 >> *To:* Stefan Uygur; Florence Blanc-Renaud; freeipa-users at redhat.com >> *Subject:* Re: [Freeipa-users] Directory Manager Password Change >> >> >> >> Hi Stefan, >> >> >> >> Thanks for your input, I am able to clarify that I wasn't simply copying >> and pasting in - the dollar sign was included in my password rather than >> the example. But yes, no denying that my command line skills are to blame. >> >> >> >> Further to this problem I am happy to report that the issue is now >> solved. My main issue was the dollar sign meaning that I had updated the DM >> password incorrectly for FreeIPA. Secondly I appear to have caused an issue >> with SSSD and it was a restart of this service which finally resolved the >> issue for me. I doubt there is much to be learnt from my issue - definitely >> user error. >> >> >> >> Thanks so much for your responses, very much appreciated. Apologies for >> taking up your time. >> >> >> >> Callum >> >> >> >> >> >> >> >> On Mon, Dec 5, 2016 at 2:48 PM Stefan Uygur >> wrote: >> >> Hi, >> >> I think you are copying and pasting the exact same commands from the >> article, which is of course a wrong approach. Never copy/paste from web to >> execute on your server. That $ signs indicates you can give any name you?d >> like. >> >> >> >> Follow this article here: >> >> https://access.redhat.com/solutions/308623 >> >> >> >> Stefan >> >> >> >> >> >> *From:* freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces@ >> redhat.com] *On Behalf Of *Callum Guy >> *Sent:* 05 December 2016 13:38 >> *To:* Florence Blanc-Renaud; freeipa-users at redhat.com >> *Subject:* Re: [Freeipa-users] Directory Manager Password Change >> >> >> >> Hi Flo, >> >> >> >> I have indeed executed every step in order, including the one you have >> indicated. >> >> >> >> The password I has used included a dollar sign and this meant that echo >> -n $DM_PASSWORD > /root/dm_password didn't work as I had expected >> meaning everything after the dollar was interpreted as a variable and was >> missing in the file. I have corrected this and performed the full process >> again, starting with the 389 reset however it is still not working >> correctly. >> >> >> >> I remain in the same state as before where the admin password has not >> been changed - this confuses me as my understanding is that admin only >> exists as the FreeIPA web admin user whose password I can change >> separately. Am i misunderstanding, is there another admin user within >> FreeIPA which is directly linked to the directory manager? >> >> >> >> Having run out of ideas I have just executed ipa-server-upgrade however >> this hasn't helped. My situation remains as follows: >> >> >> >> *Works:* ldapsearch -x -D "cn=directory manager" -w *NEW_DM_PW *-s >> base -b "" "objectclass=*" >> >> *Fails: *ldapsearch -h localhost -ZZ -p 389 -x -D >> "uid=admin,ou=people,o=ipaca" -w *NEW_DM_PW *-b "" -s base >> >> >> >> Are you able to offer any other ideas? >> >> >> >> Other information: >> >> I can confirm that cacert.p12 has been updated by the actions performed. >> >> File /etc/pki/pki-tomcat/password.conf now contains a new line >> internaldb=*NEW_DM_PW *(as per instruction 1 on FreeIPA link) >> >> >> >> Best Regards, >> >> >> >> Callum >> >> >> >> >> >> On Mon, Dec 5, 2016 at 1:08 PM Florence Blanc-Renaud >> wrote: >> >> On 12/05/2016 01:05 PM, Callum Guy wrote: >> > Hi All, >> > >> > I have been testing FreeIPA and now plan to migrate to production use - >> > thanks for creating such a great application! >> > >> > During the test phase we have been using simple passwords for the admin >> > and directory manager users however we need these changed before moving >> > into production. I believe we can change the admin password using the >> > web interface however as I understand it amending the directory manager >> > password is not so straightforward. >> > >> > I have found this >> > link https://www.freeipa.org/page/Howto/Change_Directory_Manager_ >> Password however >> > I am unsure if this is the correct procedure for our installation - >> > certainly i am having no luck so far. >> > >> > We have the following setup: >> > >> > FreeIPA 4.2.0 - single master server (no replicas), multiple clients >> > CentOS 7.2 >> > >> > I have tried the following steps in order: >> > >> > http://directory.fedoraproject.org/docs/389ds/howto/howto-re >> setdirmgrpassword.html >> > followed by >> > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password >> > >> > After completing that I am no longer able to authenticate user logins. >> > The below covers my current situation: >> > >> > This works: >> > ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" >> > "objectclass=*" >> > >> > This does not work: >> > ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" >> > "objectclass=*" >> > >> > This works: >> > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" >> > -W -b "" -s base >> > OLDPASSWORD >> > >> > This does not work: >> > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" >> > -W -b "" -s base >> > NEWPASSWORD >> > >> Hi, >> >> your commands show that the Directory Manager password was properly >> modified, but not admin's password. Did you run the step 3 Updating PKI >> admin password of the procedure [1]? >> ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W >> -T /root/dm_password "uid=admin,ou=people,o=ipaca" >> >> Flo. >> >> [1] >> https://www.freeipa.org/page/Howto/Change_Directory_Manager_ >> Password#3._Update_PKI_admin_password >> >> > So i'm i a mixed up state! Is anyone able to offer advise on resolving >> > this issue? >> > >> > Thank you, >> > >> > 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 <+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. >> > >> > >> > >> >> >> >> *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. >> >> >> >> *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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Mon Dec 5 17:43:07 2016 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 05 Dec 2016 17:43:07 +0000 Subject: [Freeipa-users] Directory Manager Password Change | off topic In-Reply-To: References: <38C784D32FB4354DAED01CCB1BB5053517561B12@mail01.firstderivatives.com> Message-ID: Ah yes, I hadn't even noticed as Google cleans that up automatically but I can confirm (explicit) contact from Kimmi and co. On Mon, Dec 5, 2016 at 5:24 PM Joseph Flynn wrote: Ah, now SophiaB wants in on the action too. Looks like my lucky day. Seriously though, I think the community needs to anonymize participants out of necessity. On Mon, Dec 5, 2016 at 12:02 PM, Joseph Flynn wrote: Me too. Within minutes of my first posting, I have good old Kimmi offering me all kinds of favors. All of our emails are exposed to the group which I'd like to trust but we obviously can't. All it takes is for a spammer to join the group and they will eventually collect a group of active emails with a very targeted demographic. On Mon, Dec 5, 2016 at 11:45 AM, Stefan Uygur wrote: Guys, Since I replied to the list I keep receiving spam emails, what is happening? *From:* Stefan Uygur *Sent:* 05 December 2016 16:40 *To:* 'Callum Guy'; Florence Blanc-Renaud; freeipa-users at redhat.com *Subject:* RE: [Freeipa-users] Directory Manager Password Change Glad you solved your issue. I?ve been there myself so don?t worry about it at all. *From:* Callum Guy [mailto:callum.guy at x-on.co.uk ] *Sent:* 05 December 2016 16:37 *To:* Stefan Uygur; Florence Blanc-Renaud; freeipa-users at redhat.com *Subject:* Re: [Freeipa-users] Directory Manager Password Change Hi Stefan, Thanks for your input, I am able to clarify that I wasn't simply copying and pasting in - the dollar sign was included in my password rather than the example. But yes, no denying that my command line skills are to blame. Further to this problem I am happy to report that the issue is now solved. My main issue was the dollar sign meaning that I had updated the DM password incorrectly for FreeIPA. Secondly I appear to have caused an issue with SSSD and it was a restart of this service which finally resolved the issue for me. I doubt there is much to be learnt from my issue - definitely user error. Thanks so much for your responses, very much appreciated. Apologies for taking up your time. Callum On Mon, Dec 5, 2016 at 2:48 PM Stefan Uygur wrote: Hi, I think you are copying and pasting the exact same commands from the article, which is of course a wrong approach. Never copy/paste from web to execute on your server. That $ signs indicates you can give any name you?d like. Follow this article here: https://access.redhat.com/solutions/308623 Stefan *From:* freeipa-users-bounces at redhat.com [mailto: freeipa-users-bounces at redhat.com] *On Behalf Of *Callum Guy *Sent:* 05 December 2016 13:38 *To:* Florence Blanc-Renaud; freeipa-users at redhat.com *Subject:* Re: [Freeipa-users] Directory Manager Password Change Hi Flo, I have indeed executed every step in order, including the one you have indicated. The password I has used included a dollar sign and this meant that echo -n $DM_PASSWORD > /root/dm_password didn't work as I had expected meaning everything after the dollar was interpreted as a variable and was missing in the file. I have corrected this and performed the full process again, starting with the 389 reset however it is still not working correctly. I remain in the same state as before where the admin password has not been changed - this confuses me as my understanding is that admin only exists as the FreeIPA web admin user whose password I can change separately. Am i misunderstanding, is there another admin user within FreeIPA which is directly linked to the directory manager? Having run out of ideas I have just executed ipa-server-upgrade however this hasn't helped. My situation remains as follows: *Works:* ldapsearch -x -D "cn=directory manager" -w *NEW_DM_PW *-s base -b "" "objectclass=*" *Fails: *ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" -w *NEW_DM_PW *-b "" -s base Are you able to offer any other ideas? Other information: I can confirm that cacert.p12 has been updated by the actions performed. File /etc/pki/pki-tomcat/password.conf now contains a new line internaldb= *NEW_DM_PW *(as per instruction 1 on FreeIPA link) Best Regards, Callum On Mon, Dec 5, 2016 at 1:08 PM Florence Blanc-Renaud wrote: On 12/05/2016 01:05 PM, Callum Guy wrote: > Hi All, > > I have been testing FreeIPA and now plan to migrate to production use - > thanks for creating such a great application! > > During the test phase we have been using simple passwords for the admin > and directory manager users however we need these changed before moving > into production. I believe we can change the admin password using the > web interface however as I understand it amending the directory manager > password is not so straightforward. > > I have found this > link https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password however > I am unsure if this is the correct procedure for our installation - > certainly i am having no luck so far. > > We have the following setup: > > FreeIPA 4.2.0 - single master server (no replicas), multiple clients > CentOS 7.2 > > I have tried the following steps in order: > > http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html > followed by > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > After completing that I am no longer able to authenticate user logins. > The below covers my current situation: > > This works: > ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" > "objectclass=*" > > This does not work: > ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" > "objectclass=*" > > This works: > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > -W -b "" -s base > OLDPASSWORD > > This does not work: > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > -W -b "" -s base > NEWPASSWORD > Hi, your commands show that the Directory Manager password was properly modified, but not admin's password. Did you run the step 3 Updating PKI admin password of the procedure [1]? ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W -T /root/dm_password "uid=admin,ou=people,o=ipaca" Flo. [1] https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password > So i'm i a mixed up state! Is anyone able to offer advise on resolving > this issue? > > Thank you, > > 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 <+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. > > > *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. *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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- *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 callum.guy at x-on.co.uk Mon Dec 5 17:45:22 2016 From: callum.guy at x-on.co.uk (Callum Guy) Date: Mon, 05 Dec 2016 17:45:22 +0000 Subject: [Freeipa-users] Directory Manager Password Change In-Reply-To: <38C784D32FB4354DAED01CCB1BB5053517561AF1@mail01.firstderivatives.com> References: <7783a1de-0924-250c-c057-7601f8724af6@redhat.com> <38C784D32FB4354DAED01CCB1BB5053517561A22@mail01.firstderivatives.com> <38C784D32FB4354DAED01CCB1BB5053517561AF1@mail01.firstderivatives.com> Message-ID: Thanks Stefan, what I didn't mention is that half way through our network engineer decided to implement a change that silently broke Kerberos authentication leaving me chasing my tail on the wrong problem. Anyway, time to move on - have a great day. On Mon, Dec 5, 2016 at 4:39 PM Stefan Uygur wrote: > Glad you solved your issue. > > > > I?ve been there myself so don?t worry about it at all. > > > > *From:* Callum Guy [mailto:callum.guy at x-on.co.uk] > *Sent:* 05 December 2016 16:37 > *To:* Stefan Uygur; Florence Blanc-Renaud; freeipa-users at redhat.com > > > *Subject:* Re: [Freeipa-users] Directory Manager Password Change > > > > Hi Stefan, > > > > Thanks for your input, I am able to clarify that I wasn't simply copying > and pasting in - the dollar sign was included in my password rather than > the example. But yes, no denying that my command line skills are to blame. > > > > Further to this problem I am happy to report that the issue is now solved. > My main issue was the dollar sign meaning that I had updated the DM > password incorrectly for FreeIPA. Secondly I appear to have caused an issue > with SSSD and it was a restart of this service which finally resolved the > issue for me. I doubt there is much to be learnt from my issue - definitely > user error. > > > > Thanks so much for your responses, very much appreciated. Apologies for > taking up your time. > > > > Callum > > > > > > > > On Mon, Dec 5, 2016 at 2:48 PM Stefan Uygur > wrote: > > Hi, > > I think you are copying and pasting the exact same commands from the > article, which is of course a wrong approach. Never copy/paste from web to > execute on your server. That $ signs indicates you can give any name you?d > like. > > > > Follow this article here: > > https://access.redhat.com/solutions/308623 > > > > Stefan > > > > > > *From:* freeipa-users-bounces at redhat.com [mailto: > freeipa-users-bounces at redhat.com] *On Behalf Of *Callum Guy > *Sent:* 05 December 2016 13:38 > *To:* Florence Blanc-Renaud; freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Directory Manager Password Change > > > > Hi Flo, > > > > I have indeed executed every step in order, including the one you have > indicated. > > > > The password I has used included a dollar sign and this meant that echo > -n $DM_PASSWORD > /root/dm_password didn't work as I had expected meaning > everything after the dollar was interpreted as a variable and was missing > in the file. I have corrected this and performed the full process again, > starting with the 389 reset however it is still not working correctly. > > > > I remain in the same state as before where the admin password has not been > changed - this confuses me as my understanding is that admin only exists as > the FreeIPA web admin user whose password I can change separately. Am i > misunderstanding, is there another admin user within FreeIPA which is > directly linked to the directory manager? > > > > Having run out of ideas I have just executed ipa-server-upgrade however > this hasn't helped. My situation remains as follows: > > > > *Works:* ldapsearch -x -D "cn=directory manager" -w *NEW_DM_PW *-s base > -b "" "objectclass=*" > > *Fails: *ldapsearch -h localhost -ZZ -p 389 -x -D > "uid=admin,ou=people,o=ipaca" -w *NEW_DM_PW *-b "" -s base > > > > Are you able to offer any other ideas? > > > > Other information: > > I can confirm that cacert.p12 has been updated by the actions performed. > > File /etc/pki/pki-tomcat/password.conf now contains a new line internaldb= > *NEW_DM_PW *(as per instruction 1 on FreeIPA link) > > > > Best Regards, > > > > Callum > > > > > > On Mon, Dec 5, 2016 at 1:08 PM Florence Blanc-Renaud > wrote: > > On 12/05/2016 01:05 PM, Callum Guy wrote: > > Hi All, > > > > I have been testing FreeIPA and now plan to migrate to production use - > > thanks for creating such a great application! > > > > During the test phase we have been using simple passwords for the admin > > and directory manager users however we need these changed before moving > > into production. I believe we can change the admin password using the > > web interface however as I understand it amending the directory manager > > password is not so straightforward. > > > > I have found this > > link > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > however > > I am unsure if this is the correct procedure for our installation - > > certainly i am having no luck so far. > > > > We have the following setup: > > > > FreeIPA 4.2.0 - single master server (no replicas), multiple clients > > CentOS 7.2 > > > > I have tried the following steps in order: > > > > > http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html > > followed by > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password > > > > After completing that I am no longer able to authenticate user logins. > > The below covers my current situation: > > > > This works: > > ldapsearch -x -D "cn=directory manager" -w NEWPASSWORD -s base -b "" > > "objectclass=*" > > > > This does not work: > > ldapsearch -x -D "cn=directory manager" -w OLDPASSWORD -s base -b "" > > "objectclass=*" > > > > This works: > > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > > -W -b "" -s base > > OLDPASSWORD > > > > This does not work: > > ldapsearch -h localhost -ZZ -p 389 -x -D "uid=admin,ou=people,o=ipaca" > > -W -b "" -s base > > NEWPASSWORD > > > Hi, > > your commands show that the Directory Manager password was properly > modified, but not admin's password. Did you run the step 3 Updating PKI > admin password of the procedure [1]? > ldappasswd -h localhost -ZZ -p $CA_PORT -x -D "cn=Directory Manager" -W > -T /root/dm_password "uid=admin,ou=people,o=ipaca" > > Flo. > > [1] > > https://www.freeipa.org/page/Howto/Change_Directory_Manager_Password#3._Update_PKI_admin_password > > > So i'm i a mixed up state! Is anyone able to offer advise on resolving > > this issue? > > > > Thank you, > > > > 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 <+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. > > > > > > > > > > *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. > > > > *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. > -- *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 rkudyba at fordham.edu Mon Dec 5 18:05:46 2016 From: rkudyba at fordham.edu (Robert Kudyba) Date: Mon, 5 Dec 2016 13:05:46 -0500 Subject: [Freeipa-users] Let's Encrypt along with FreeIPA In-Reply-To: <0af9dbd3-e406-a615-f17d-9908a9d8b850@redhat.com> References: <608a680e-0761-1984-733a-f6a6cbd2600a@redhat.com> <0af9dbd3-e406-a615-f17d-9908a9d8b850@redhat.com> Message-ID: >> you seem to have an issue when the LetsEncryptAuthorityX3 is being installed. The certificate from the CA that issued this certificate (DSTRootCAX3) seems to be installed correctly. Could you verify that DSTRootCAX3 is marked as trusted CA by issuing: >> >> certutil -d /etc/httpd/alias/ -L >> >> The DSTRoootCAX3 should have C,, trust flags. >> >> There was an issue fixed last week that might caused this issue if you've ever tried to install letsencrypt on this particular VM before:https://github.com/freeipa/freeipa-letsencrypt/issues/1#issuecomment-263546822 If that's the case, you will need to re-install IPA before the letsencrypt solution will work. I tried to uninstall FreeIPA and Letsencrypt for FreeIPA but I?m getting this: ipa-server-install -U --uninstall ipa.ipapython.install.cli.uninstall_tool(Server): ERROR Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA.. ipa.ipapython.install.cli.uninstall_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information [root at trill ~]# tail /var/log/ipaserver-uninstall.log File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 270, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 1047, in uninstall_check remove_master_from_managed_topology(api, options) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 310, in remove_master_from_managed_topology raise ScriptError(str(e)) 2016-12-05T17:53:05Z DEBUG The ipa-server-install command failed, exception: ScriptError: Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA.. 2016-12-05T17:53:05Z ERROR Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA.. 2016-12-05T17:53:05Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information Is there a better command? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkudyba at fordham.edu Mon Dec 5 19:15:11 2016 From: rkudyba at fordham.edu (Robert Kudyba) Date: Mon, 5 Dec 2016 14:15:11 -0500 Subject: [Freeipa-users] Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA Message-ID: Are there instructions to manually uninstall? I?m getting the below errors. ipa-server-install -U --uninstall ipa.ipapython.install.cli.uninstall_tool(Server): ERROR Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA.. ipa.ipapython.install.cli.uninstall_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information [root at trill ~]# cat /var/log/ipaserver-uninstall.log 2016-12-05T19:13:45Z DEBUG Logging to /var/log/ipaserver-uninstall.log 2016-12-05T19:13:45Z DEBUG ipa-server-install was invoked with arguments [] and options: {'no_dns_sshfp': None, 'ignore_topology_disconnect': None, 'verbose': False, 'ip_addresses': None, 'domainlevel': None, 'mkhomedir': None, 'no_pkinit': None, 'http_cert_files': None, 'no_ntp': None, 'subject': None, 'no_forwarders': None, 'external_ca_type': None, 'ssh_trust_dns': None, 'domain_name': None, 'idmax': None, 'http_cert_name': None, 'dirsrv_cert_files': None, 'no_dnssec_validation': None, 'ca_signing_algorithm': None, 'no_reverse': None, 'pkinit_cert_files': None, 'unattended': True, 'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns': None, 'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role': None, 'realm_name': None, 'forwarders': None, 'idstart': None, 'external_ca': None, 'pkinit_cert_name': None, 'no_ssh': None, 'external_cert_files': None, 'no_hbac_allow': None, 'forward_policy': None, 'dirsrv_cert_name': None, 'ca_cert_files': None, 'zonemgr': None, 'quiet': False, 'setup_dns': None, 'host_name': None, 'dirsrv_config_file': None, 'log_file': None, 'reverse_zones': None, 'allow_zone_overlap': None, 'uninstall': True} 2016-12-05T19:13:45Z DEBUG IPA version 4.4.2-1.fc25 2016-12-05T19:13:45Z DEBUG Starting external process 2016-12-05T19:13:45Z DEBUG args=/usr/sbin/selinuxenabled 2016-12-05T19:13:45Z DEBUG Process finished, return code=0 2016-12-05T19:13:45Z DEBUG stdout= 2016-12-05T19:13:45Z DEBUG stderr= 2016-12-05T19:13:45Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-12-05T19:13:45Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-12-05T19:13:45Z DEBUG httpd is configured 2016-12-05T19:13:45Z DEBUG kadmin is configured 2016-12-05T19:13:45Z DEBUG dirsrv is configured 2016-12-05T19:13:45Z DEBUG pki-tomcatd is configured 2016-12-05T19:13:45Z DEBUG install is not configured 2016-12-05T19:13:45Z DEBUG krb5kdc is configured 2016-12-05T19:13:45Z DEBUG ntpd is configured 2016-12-05T19:13:45Z DEBUG named is not configured 2016-12-05T19:13:45Z DEBUG ipa_memcached is configured 2016-12-05T19:13:45Z DEBUG filestore has files 2016-12-05T19:13:45Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2016-12-05T19:13:45Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2016-12-05T19:13:45Z DEBUG importing all plugin modules in ipaserver.plugins... 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.aci 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.automember 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.automount 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.baseldap 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.baseldap is not a valid plugin module 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.baseuser 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.batch 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.ca 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.caacl 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.cert 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.certprofile 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.config 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.delegation 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.dns 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.dnsserver 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.dogtag 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.domainlevel 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.group 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.hbac 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.hbac is not a valid plugin module 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.hbacrule 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.hbacsvc 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.hbacsvcgroup 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.hbactest 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.host 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.hostgroup 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.idrange 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.idviews 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.internal 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.join 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.krbtpolicy 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.ldap2 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.location 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.migration 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.misc 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.netgroup 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.otp 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.otp is not a valid plugin module 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.otpconfig 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.otptoken 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.passwd 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.permission 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.ping 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.pkinit 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.privilege 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.pwpolicy 2016-12-05T19:13:45Z DEBUG Starting external process 2016-12-05T19:13:45Z DEBUG args=klist -V 2016-12-05T19:13:45Z DEBUG Process finished, return code=0 2016-12-05T19:13:45Z DEBUG stdout=Kerberos 5 version 1.14.4 2016-12-05T19:13:45Z DEBUG stderr= 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.rabase 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.rabase is not a valid plugin module 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.radiusproxy 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.realmdomains 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.role 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.schema 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.selfservice 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.selinuxusermap 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.server 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.serverrole 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.serverroles 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.service 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.servicedelegation 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.session 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.stageuser 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.sudo 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.sudo is not a valid plugin module 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.sudocmd 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.sudocmdgroup 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.sudorule 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.topology 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.trust 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.user 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.vault 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.virtual 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.virtual is not a valid plugin module 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.xmlserver 2016-12-05T19:13:45Z DEBUG importing all plugin modules in ipaserver.install.plugins... 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.adtrust 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.ca_renewal_master 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.dns 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.fix_replica_agreements 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.rename_managed 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.update_ca_topology 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.update_idranges 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.update_managed_permissions 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.update_nis 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.update_pacs 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.update_passsync 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.update_referint 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.update_services 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.update_uniqueness 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.install.plugins.upload_cacrt 2016-12-05T19:13:47Z DEBUG Created connection context.ldap2_140085126450512 2016-12-05T19:13:47Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-CIS-FORDHAM-EDU.socket from SchemaCache 2016-12-05T19:13:47Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-CIS-FORDHAM-EDU.socket conn= 2016-12-05T19:13:47Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-CIS-FORDHAM-EDU.socket from SchemaCache 2016-12-05T19:13:47Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-CIS-FORDHAM-EDU.socket conn= 2016-12-05T19:13:47Z DEBUG raw: server_del((u'trill.cis.fordham.edu',), ignore_topology_disconnect=False, ignore_last_of_role=False, force=True, version=u'2.215') 2016-12-05T19:13:47Z DEBUG server_del((u'trill.cis.fordham.edu',), continue=False, ignore_topology_disconnect=False, ignore_last_of_role=False, force=True, version=u'2.215') 2016-12-05T19:13:47Z DEBUG raw: server_find(u'', sizelimit=0, version=u'2.215', no_members=False) 2016-12-05T19:13:47Z DEBUG server_find(None, sizelimit=0, all=False, raw=False, version=u'2.215', no_members=False, pkey_only=False) 2016-12-05T19:13:47Z DEBUG raw: topologysuffix_find(None, all=True, raw=True, version=u'2.215') 2016-12-05T19:13:47Z DEBUG topologysuffix_find(None, all=True, raw=True, version=u'2.215', pkey_only=False) 2016-12-05T19:13:47Z DEBUG raw: server_role_find(None, server_server=u'trill.cis.fordham.edu', status=u'enabled', version=u'2.215') 2016-12-05T19:13:47Z DEBUG server_role_find(None, server_server=u'trill.cis.fordham.edu', status=u'enabled', all=False, raw=False, version=u'2.215') 2016-12-05T19:13:47Z DEBUG raw: topologysegment_find(u'domain', None, sizelimit=0, version=u'2.215') 2016-12-05T19:13:47Z DEBUG topologysegment_find(u'domain', None, sizelimit=0, all=False, raw=False, version=u'2.215', pkey_only=False) 2016-12-05T19:13:47Z DEBUG raw: config_show(version=u'2.215') 2016-12-05T19:13:47Z DEBUG config_show(rights=False, all=False, raw=False, version=u'2.215') 2016-12-05T19:13:47Z DEBUG raw: dns_is_enabled(version=u'2.215') 2016-12-05T19:13:47Z DEBUG dns_is_enabled(version=u'2.215') 2016-12-05T19:13:47Z DEBUG raw: ca_is_enabled(version=u'2.215') 2016-12-05T19:13:47Z DEBUG ca_is_enabled(version=u'2.215') 2016-12-05T19:13:47Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 308, in run self.validate() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 317, in validate for nothing in self._validator(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 376, in __runner exc_handler(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 400, in _handle_validate_exception self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 395, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 366, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 363, 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 575, in _configure next(validator) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 376, in __runner exc_handler(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 400, in _handle_validate_exception self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 460, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 395, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 457, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 395, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 366, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 363, 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 71, in _uninstall for nothing in self._uninstaller(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 1376, in main uninstall_check(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 270, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 1047, in uninstall_check remove_master_from_managed_topology(api, options) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 310, in remove_master_from_managed_topology raise ScriptError(str(e)) 2016-12-05T19:13:47Z DEBUG The ipa-server-install command failed, exception: ScriptError: Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA.. 2016-12-05T19:13:47Z ERROR Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA.. 2016-12-05T19:13:47Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information -------------- next part -------------- An HTML attachment was scrubbed... URL: From raul at dias.com.br Mon Dec 5 20:30:05 2016 From: raul at dias.com.br (Raul Dias) Date: Mon, 5 Dec 2016 18:30:05 -0200 Subject: [Freeipa-users] IPA DNS Server and DNSMasq Message-ID: <88d6028f-c758-818b-4fad-0104be3f8acc@dias.com.br> This might be a bit offtopic. I am using dnsmasq with NetworkManger. So, my /etc/resolv.conf has nameserver 127.0.0.1. For some reason I can't get response from dnsmasq queries to the ipa server, it times out. OTOH, I can watch the DNS traffic between dnsmasq and the ipa server. The queries are fine (with answers). If I explicit change nameserver to ipa IP, the queries are fine. So, the problem is between dnsmasq and ipa bind. Has anyone seen anything like this? This is a Ubuntu 16.10 not a member of the ipa. -rsd -- Att. Raul Dias -------------- next part -------------- An HTML attachment was scrubbed... URL: From satavee at gmail.com Mon Dec 5 23:16:43 2016 From: satavee at gmail.com (Satavee Junwana) Date: Tue, 6 Dec 2016 06:16:43 +0700 Subject: [Freeipa-users] can manage user access from Serial Console & only use local users in case cannot reach IPA server ? Message-ID: Hi , I'm just testing IPA on CentOS 6, login via ssh is woking fine. I would like to try two steps but didnot find any documents- 1). can we manage user that access from serial interface. 2). in case IPA was failed, can we configure it to use local user Best Regards, sjw -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue Dec 6 01:02:21 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 6 Dec 2016 11:02:21 +1000 Subject: [Freeipa-users] Let's Encrypt along with FreeIPA In-Reply-To: References: <608a680e-0761-1984-733a-f6a6cbd2600a@redhat.com> <0af9dbd3-e406-a615-f17d-9908a9d8b850@redhat.com> Message-ID: <20161206010221.GF28337@dhcp-40-8.bne.redhat.com> On Mon, Dec 05, 2016 at 01:05:46PM -0500, Robert Kudyba wrote: > > >> you seem to have an issue when the LetsEncryptAuthorityX3 is being installed. The certificate from the CA that issued this certificate (DSTRootCAX3) seems to be installed correctly. Could you verify that DSTRootCAX3 is marked as trusted CA by issuing: > >> > >> certutil -d /etc/httpd/alias/ -L > >> > >> The DSTRoootCAX3 should have C,, trust flags. > >> > >> There was an issue fixed last week that might caused this issue if you've ever tried to install letsencrypt on this particular VM before:https://github.com/freeipa/freeipa-letsencrypt/issues/1#issuecomment-263546822 If that's the case, you will need to re-install IPA before the letsencrypt solution will work. > > I tried to uninstall FreeIPA and Letsencrypt for FreeIPA but I?m getting this: > > ipa-server-install -U --uninstall > ipa.ipapython.install.cli.uninstall_tool(Server): ERROR Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA.. > ipa.ipapython.install.cli.uninstall_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information > [root at trill ~]# tail /var/log/ipaserver-uninstall.log > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 270, in decorated > func(installer) > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 1047, in uninstall_check > remove_master_from_managed_topology(api, options) > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 310, in remove_master_from_managed_topology > raise ScriptError(str(e)) > > 2016-12-05T17:53:05Z DEBUG The ipa-server-install command failed, exception: ScriptError: Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA.. > 2016-12-05T17:53:05Z ERROR Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA.. > 2016-12-05T17:53:05Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information > > Is there a better command? > Try again with the `--ignore-last-of-role' flag. Cheers, Fraser > -- > Manage your subscription for 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 Tue Dec 6 06:35:19 2016 From: tk at mdevsys.com (TomK) Date: Tue, 6 Dec 2016 01:35:19 -0500 Subject: [Freeipa-users] Mapping users from AD to IPA KDC In-Reply-To: <20161205070232.gnntt334q5siv3va@redhat.com> References: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> <2c4ff955-ab05-80ea-f4ae-da217d21b285@mdevsys.com> <20161205070232.gnntt334q5siv3va@redhat.com> Message-ID: <1ee640af-4739-1e9b-bb49-c10601e6e08d@mdevsys.com> On 12/5/2016 2:02 AM, Alexander Bokovoy wrote: > On su, 04 joulu 2016, TomK wrote: >> Could not get much from logs and decided to start fresh. When I run >> this: >> >> ipa trust-add --type=ad mds.xyz --admin Administrator --password >> >> Trust works fine and id tom at mds.xyz returns a valid result. >> >> However when I run the following on both masters on a fresh new setup: >> >> ipa-adtrust-install --netbios-name=NIX -a "" >> ipa trust-add --type=ad "mds.xyz" --trust-secret >> >> and created a trust object in AD DC with the name of NIX and a >> non-transitive trust, the above did NOT work. I didn't get anything >> by typing id tom at mds.xyz. (I do not get an option for a Forest Trust >> as the gif on this page suggests: >> https://www.freeipa.org/page/Active_Directory_trust_setup . Possibly >> it's Server 2012 hence the difference in what's presented to me but >> another reason is that the name I type for the trust can't resolve to >> an IP for now: nix.mds.xyz . So I use NIX to match the bios name used >> on the ipa-adtrust-install command above. ) > The shared secret case for one-way trust is known to be broken. When a > shared half is created on AD side first, it is marked as not yet valid > by Windows and currently we cannot perform validation of it from IPA > side. Validating it from AD side is not possible as well as we don't > provide all interfaces Windows would like to use. > > And the fact you cannot see 'Forest Trust' type of the trust says also > that you have problems with reaching IPA masters from AD DC side for > probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and > UDP). Nothing I tried in AD Trust creation allowed me to make one with type Forest. Just realm. I recall I had a trust type of Forest but in trying various options I lost how I did that. Or perhaps I hadn't payed attention and it got created indirectly as part of another action I took. The domain functional level I'm using is Windows Server 2008. Using a lower value for testing. > >> I went back to the trust object in AD and set it to Transitive from >> Non-transitive. And all of a sudden I can resolve the AD ID's on the >> IP Servers and all is working fine. Great! >> >> I could not follow the section within the online document above for >> setting up forwarders. I had to delegate nix.mds.xyz from the two AD >> / DNS Clustered Windows Server 2012 servers to the two FreeIPA servers >> (idmipa01, idmipa02) . I found that the forwarding section doesn't >> quite jive well with delegation in Windows Server 2012. > Whatever you do to forward DNS in a DNS-compliant way should be enough. > The documentation typically tries to explain that there are multiple > ways to achieve this, from hackish to standards-compliant. > >> The remaining questions I need to ask is does the NetBIOS name used on >> the ipa-adtrust-install command above have to match the AD DC Trust >> object name? Any tie's between the naming of the two? ( Thinking no >> tie in but not 100% . Seems AD expects a domain that resolves to an IP ) > 100% tied, this is AD requirement. > > Each domain has domain name in NetBIOS, domain name in DNS, and SID. The > first two must be matching and on DNS level AD expects both to resolve > properly. It is a legacy from NT times that _all_ trusted domain objects > are named as NetBIOS$, as well as _all_ computer objects have the same > style names COMPUTER$. This is enforced on multiple levels, from SMB to > Kerberos. > > What 'resolve' means here is that DNS searches for different types of > SRV records should succeed, and then CLDAP ping to the servers which are > mentioned in the > _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.$DOMAIN > or _ldap._tcp.dc._msdcs.$DOMAIN should succeed too. > > >> Also, given this setup I have: >> >> 1) The two windows servers, winad01, winad02 are both DNS, AD servers >> and are clustered (NLB) >> >> 2) Have DNS delegation on nix.mds.xyz so FreeIPA servers will be >> authoritative for that subdomain. >> >> 3) AD Trust objects look for a resolvable domain (ie nix.mds.xyz) and >> current version of FreeIPA does not yet resolve nix.mds.xyz to any IP > No, this is not required. What required, is that trust object is > correctly set, and it involves a lot more than what you are outlining. > As you can see above, resolving nix.mds.xyz to IP is not required, but > DNS SRV records like _ldap._tcp.dc._msdcs.nix.mds.xyz should be > resolvable. > >> 4) IPA ipa-adtrust-install only accepts NetBIOS names. > ipa-adtrust-install configures what is missing from the base setup > related to the trust to AD. NetBIOS name is missing, thus is added. > >> >> Is it at all possible to setup a non-transitive trust with all that? >> ( I might just not be seeing the forest through the trees :) - Pun >> Intended. ) Still new to quite a bit of this so thank you for your >> patience and feedback. > Non-transitive trust is called 'external trust' in AD jargon. It can be > established to any domain in a forest. We support it from FreeIPA 4.4 > with --external=true option to 'ipa trust-add'. > > With non-transitive trust only users from directly trusted domain can be > seen and authenticated. > Hey Alex, Really appreciate the detailed reply. Will need more time to retry things then I can tonight however. In the meantime, here's a few updates. My IPA version is 4.2 right now. It came with the CentOS 7.2. Looking forward to 4.4. Not sure when you plan to include it as part of the latest CentOS base. Indeed some ports were not open (445). I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7: for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp 53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp 53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd --zone=public --permanent --add-port=$KEY; done [root at idmipa01 ~]# firewall-cmd --zone=public --list-all public (default) interfaces: sources: services: dhcpv6-client ntp ssh ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp 135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp 139/udp 138/udp 53/udp 636/tcp masquerade: no forward-ports: icmp-blocks: rich rules: [root at idmipa01 ~]# On Windows Side (The nslookup results were the same before the firewall change however.): PS C:\Users\Administrator.WINAD01.000\desktop\netcat> .\nc -vz idmipa01 389 Warning: inverse host lookup failed for 192.168.0.44: h_errno 11004: NO_DATA idmipa01.nix.mds.xyz [192.168.0.44] 389 (ldap) open PS C:\Users\Administrator.WINAD01.000\desktop\netcat> .\nc -vz idmipa01 445 Warning: inverse host lookup failed for 192.168.0.44: h_errno 11004: NO_DATA idmipa01.nix.mds.xyz [192.168.0.44] 445 (microsoft-ds): TIMEDOUT PS C:\Users\Administrator.WINAD01.000\desktop\netcat> .\nc -vz idmipa01 445 Warning: inverse host lookup failed for 192.168.0.44: h_errno 11004: NO_DATA idmipa01.nix.mds.xyz [192.168.0.44] 445 (microsoft-ds) open PS C:\Users\Administrator.WINAD01.000\desktop\netcat> nslookup Default Server: UnKnown Address: ::1 > set type=srv > _ldap._tcp.mds.xyz Server: UnKnown Address: ::1 _ldap._tcp.mds.xyz SRV service location: priority = 0 weight = 100 port = 389 svr hostname = winad02.mds.xyz _ldap._tcp.mds.xyz SRV service location: priority = 0 weight = 100 port = 389 svr hostname = winad01.mds.xyz winad02.mds.xyz internet address = 192.168.0.221 winad02.mds.xyz internet address = 192.168.0.223 winad01.mds.xyz internet address = 192.168.0.222 winad01.mds.xyz internet address = 192.168.0.224 winad01.mds.xyz internet address = 192.168.0.220 > _ldap._tcp.nix.mds.xyz Server: UnKnown Address: ::1 Non-authoritative answer: _ldap._tcp.nix.mds.xyz SRV service location: priority = 0 weight = 100 port = 389 svr hostname = idmipa01.nix.mds.xyz _ldap._tcp.nix.mds.xyz SRV service location: priority = 0 weight = 100 port = 389 svr hostname = idmipa02.nix.mds.xyz idmipa01.nix.mds.xyz internet address = 192.168.0.44 idmipa02.nix.mds.xyz internet address = 192.168.0.45 > quit PS C:\Users\Administrator.WINAD01.000\desktop\netcat> [root at idmipa01 ~]# dig SRV _ldap._tcp.mds.xyz ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> SRV _ldap._tcp.mds.xyz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61590 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 9 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_ldap._tcp.mds.xyz. IN SRV ;; ANSWER SECTION: _ldap._tcp.mds.xyz. 600 IN SRV 0 100 389 winad01.mds.xyz. _ldap._tcp.mds.xyz. 600 IN SRV 0 100 389 winad02.mds.xyz. ;; AUTHORITY SECTION: xyz. 75802 IN NS z.nic.xyz. xyz. 75802 IN NS generationxyz.nic.xyz. xyz. 75802 IN NS y.nic.xyz. xyz. 75802 IN NS x.nic.xyz. ;; ADDITIONAL SECTION: y.nic.xyz. 162201 IN A 185.24.64.42 y.nic.xyz. 162201 IN AAAA 2a04:2b00:13cc::1:42 z.nic.xyz. 162201 IN A 212.18.248.42 z.nic.xyz. 162201 IN AAAA 2a04:2b00:13ee::42 x.nic.xyz. 162201 IN A 194.169.218.42 x.nic.xyz. 162201 IN AAAA 2001:67c:13cc::1:42 generationxyz.nic.xyz. 162201 IN A 212.18.249.42 generationxyz.nic.xyz. 162201 IN AAAA 2a04:2b00:13ff::42 ;; Query time: 331 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Dec 06 00:11:31 EST 2016 ;; MSG SIZE rcvd: 373 [root at idmipa01 ~]# dig SRV _ldap._tcp.nix.mds.xyz ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.4 <<>> SRV _ldap._tcp.nix.mds.xyz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1651 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;_ldap._tcp.nix.mds.xyz. IN SRV ;; ANSWER SECTION: _ldap._tcp.nix.mds.xyz. 86400 IN SRV 0 100 389 idmipa01.nix.mds.xyz. _ldap._tcp.nix.mds.xyz. 86400 IN SRV 0 100 389 idmipa02.nix.mds.xyz. ;; AUTHORITY SECTION: nix.mds.xyz. 86400 IN NS idmipa02.nix.mds.xyz. nix.mds.xyz. 86400 IN NS idmipa01.nix.mds.xyz. ;; ADDITIONAL SECTION: idmipa01.nix.mds.xyz. 1200 IN A 192.168.0.44 idmipa02.nix.mds.xyz. 1200 IN A 192.168.0.45 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Dec 06 00:11:48 EST 2016 ;; MSG SIZE rcvd: 191 [root at idmipa01 ~]# On the AD side, I added the SRV records for the second AD DC, manually, since earlier there were no results printed on the AD DC command line for the second AD DC, when I typed the command _ldap._tcp.mds.xyz. One additional question I had with the setup is in regards to the failover. I see the ipa_server entry in /etc/sssd/sssd.conf pointing to two of the master IPA nodes. Where can I find the additional settings that control priority of the listed server or order they are checked? [root at ipaclient01 ~]# cat /etc/sssd/sssd.conf [domain/nix.mds.xyz] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = nix.mds.xyz id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipaclient01.nix.mds.xyz chpass_provider = ipa ipa_server = idmipa01.nix.mds.xyz, idmipa02.nix.mds.xyz ldap_tls_cacert = /etc/ipa/ca.crt [sssd] debug_level = 9 services = nss, sudo, pam, ssh config_file_version = 2 domains = nix.mds.xyz, mds.xyz [nss] debug_level = 9 homedir_substring = /home [pam] debug_level = 9 [sudo] debug_level = 9 [autofs] [ssh] debug_level = 9 [pac] debug_level = 9 [ifp] [domain/mds.xyz] ad_domain = mds.xyz krb5_realm = MDS.XYZ realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad [root at ipaclient01 ~]# What I ran to get the above is: 1) ipa-client-install --force-join -p admin -w "" --fixed-primary --server=idmipa01.nix.mds.xyz --server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ -U 2) realm join mds.xyz Then I could login using MDS.XYZ\tom at ipaclient01.nix.mds.xyz Bit ugly but works for now till I get a better login ID worked out using /etc/krb5.conf settings on the master. Currently it's the default: auth_to_local = RULE:[1:$1@$0](^.*@MDS.XYZ$)s/@MDS.XYZ/@mds.xyz/ auth_to_local = DEFAULT The kerberos / ldap records do resolve as expected: [root at idmipa01 ~]# nslookup > _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs Server: 127.0.0.1 Address: 127.0.0.1#53 *** Can't find _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs: No answer > set type=srv > _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs Server: 127.0.0.1 Address: 127.0.0.1#53 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.nix.mds.xyz service = 0 100 88 idmipa02.nix.mds.xyz. _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.nix.mds.xyz service = 0 100 88 idmipa01.nix.mds.xyz. > _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs Server: 127.0.0.1 Address: 127.0.0.1#53 _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.nix.mds.xyz service = 0 100 389 idmipa01.nix.mds.xyz. _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.nix.mds.xyz service = 0 100 389 idmipa02.nix.mds.xyz. > quit Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find quit: NXDOMAIN > exit [root at idmipa01 ~]# -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From flo at redhat.com Tue Dec 6 07:35:00 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 6 Dec 2016 08:35:00 +0100 Subject: [Freeipa-users] Server removal aborted: Deleting this server is not allowed as it would leave your installation without a CA In-Reply-To: References: Message-ID: On 12/05/2016 08:15 PM, Robert Kudyba wrote: > Are there instructions to manually uninstall? I?m getting the below errors. > > ipa-server-install -U --uninstall > ipa.ipapython.install.cli.uninstall_tool(Server): ERROR Server > removal aborted: Deleting this server is not allowed as it would leave > your installation without a CA.. > ipa.ipapython.install.cli.uninstall_tool(Server): ERROR The > ipa-server-install command failed. See /var/log/ipaserver-uninstall.log > for more information > [root at trill ~]# cat /var/log/ipaserver-uninstall.log > 2016-12-05T19:13:45Z DEBUG Logging to /var/log/ipaserver-uninstall.log > 2016-12-05T19:13:45Z DEBUG ipa-server-install was invoked with arguments > [] and options: {'no_dns_sshfp': None, 'ignore_topology_disconnect': > None, 'verbose': False, 'ip_addresses': None, 'domainlevel': None, > 'mkhomedir': None, 'no_pkinit': None, 'http_cert_files': None, 'no_ntp': > None, 'subject': None, 'no_forwarders': None, 'external_ca_type': None, > 'ssh_trust_dns': None, 'domain_name': None, 'idmax': None, > 'http_cert_name': None, 'dirsrv_cert_files': None, > 'no_dnssec_validation': None, 'ca_signing_algorithm': None, > 'no_reverse': None, 'pkinit_cert_files': None, 'unattended': True, > 'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns': None, > 'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role': None, > 'realm_name': None, 'forwarders': None, 'idstart': None, 'external_ca': > None, 'pkinit_cert_name': None, 'no_ssh': None, 'external_cert_files': > None, 'no_hbac_allow': None, 'forward_policy': None, 'dirsrv_cert_name': > None, 'ca_cert_files': None, 'zonemgr': None, 'quiet': False, > 'setup_dns': None, 'host_name': None, 'dirsrv_config_file': None, > 'log_file': None, 'reverse_zones': None, 'allow_zone_overlap': None, > 'uninstall': True} > 2016-12-05T19:13:45Z DEBUG IPA version 4.4.2-1.fc25 > 2016-12-05T19:13:45Z DEBUG Starting external process > 2016-12-05T19:13:45Z DEBUG args=/usr/sbin/selinuxenabled > 2016-12-05T19:13:45Z DEBUG Process finished, return code=0 > 2016-12-05T19:13:45Z DEBUG stdout= > 2016-12-05T19:13:45Z DEBUG stderr= > 2016-12-05T19:13:45Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2016-12-05T19:13:45Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2016-12-05T19:13:45Z DEBUG httpd is configured > 2016-12-05T19:13:45Z DEBUG kadmin is configured > 2016-12-05T19:13:45Z DEBUG dirsrv is configured > 2016-12-05T19:13:45Z DEBUG pki-tomcatd is configured > 2016-12-05T19:13:45Z DEBUG install is not configured > 2016-12-05T19:13:45Z DEBUG krb5kdc is configured > 2016-12-05T19:13:45Z DEBUG ntpd is configured > 2016-12-05T19:13:45Z DEBUG named is not configured > 2016-12-05T19:13:45Z DEBUG ipa_memcached is configured > 2016-12-05T19:13:45Z DEBUG filestore has files > 2016-12-05T19:13:45Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2016-12-05T19:13:45Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2016-12-05T19:13:45Z DEBUG importing all plugin modules in > ipaserver.plugins... > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.aci > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.automember > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.automount > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.baseldap > 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.baseldap is not a valid > plugin module > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.baseuser > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.batch > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.ca > > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.caacl > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.cert > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.certprofile > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.config > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.delegation > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.dns > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.dnsserver > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.dogtag > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.domainlevel > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.group > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.hbac > 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.hbac is not a valid plugin > module > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.hbacrule > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.hbacsvc > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.hbacsvcgroup > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.hbactest > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.host > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.hostgroup > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.idrange > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.idviews > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.internal > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.join > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.krbtpolicy > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.ldap2 > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.location > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.migration > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.misc > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.netgroup > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.otp > 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.otp is not a valid plugin > module > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.otpconfig > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.otptoken > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.passwd > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.permission > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.ping > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.pkinit > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.privilege > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.pwpolicy > 2016-12-05T19:13:45Z DEBUG Starting external process > 2016-12-05T19:13:45Z DEBUG args=klist -V > 2016-12-05T19:13:45Z DEBUG Process finished, return code=0 > 2016-12-05T19:13:45Z DEBUG stdout=Kerberos 5 version 1.14.4 > > 2016-12-05T19:13:45Z DEBUG stderr= > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.rabase > 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.rabase is not a valid > plugin module > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.radiusproxy > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.realmdomains > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.role > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.schema > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.selfservice > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.selinuxusermap > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.server > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.serverrole > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.serverroles > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.service > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.servicedelegation > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.session > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.stageuser > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.sudo > 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.sudo is not a valid plugin > module > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.sudocmd > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.sudocmdgroup > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.sudorule > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.topology > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.trust > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.user > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.vault > 2016-12-05T19:13:45Z DEBUG importing plugin module ipaserver.plugins.virtual > 2016-12-05T19:13:45Z DEBUG ipaserver.plugins.virtual is not a valid > plugin module > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.plugins.xmlserver > 2016-12-05T19:13:45Z DEBUG importing all plugin modules in > ipaserver.install.plugins... > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.adtrust > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.ca > _renewal_master > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.dns > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.fix_replica_agreements > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.rename_managed > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.update_ca_topology > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.update_idranges > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.update_managed_permissions > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.update_nis > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.update_pacs > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.update_passsync > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.update_referint > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.update_services > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.update_uniqueness > 2016-12-05T19:13:45Z DEBUG importing plugin module > ipaserver.install.plugins.upload_cacrt > 2016-12-05T19:13:47Z DEBUG Created connection context.ldap2_140085126450512 > 2016-12-05T19:13:47Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-CIS-FORDHAM-EDU.socket from SchemaCache > 2016-12-05T19:13:47Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-CIS-FORDHAM-EDU.socket > conn= > 2016-12-05T19:13:47Z DEBUG flushing > ldapi://%2fvar%2frun%2fslapd-CIS-FORDHAM-EDU.socket from SchemaCache > 2016-12-05T19:13:47Z DEBUG retrieving schema for SchemaCache > url=ldapi://%2fvar%2frun%2fslapd-CIS-FORDHAM-EDU.socket > conn= > 2016-12-05T19:13:47Z DEBUG raw: server_del((u'trill.cis.fordham.edu',), > ignore_topology_disconnect=False, ignore_last_of_role=False, force=True, > version=u'2.215') > 2016-12-05T19:13:47Z DEBUG server_del((u'trill.cis.fordham.edu',), > continue=False, ignore_topology_disconnect=False, > ignore_last_of_role=False, force=True, version=u'2.215') > 2016-12-05T19:13:47Z DEBUG raw: server_find(u'', sizelimit=0, > version=u'2.215', no_members=False) > 2016-12-05T19:13:47Z DEBUG server_find(None, sizelimit=0, all=False, > raw=False, version=u'2.215', no_members=False, pkey_only=False) > 2016-12-05T19:13:47Z DEBUG raw: topologysuffix_find(None, all=True, > raw=True, version=u'2.215') > 2016-12-05T19:13:47Z DEBUG topologysuffix_find(None, all=True, raw=True, > version=u'2.215', pkey_only=False) > 2016-12-05T19:13:47Z DEBUG raw: server_role_find(None, > server_server=u'trill.cis.fordham.edu', status=u'enabled', version=u'2.215') > 2016-12-05T19:13:47Z DEBUG server_role_find(None, > server_server=u'trill.cis.fordham.edu', status=u'enabled', all=False, > raw=False, version=u'2.215') > 2016-12-05T19:13:47Z DEBUG raw: topologysegment_find(u'domain', None, > sizelimit=0, version=u'2.215') > 2016-12-05T19:13:47Z DEBUG topologysegment_find(u'domain', None, > sizelimit=0, all=False, raw=False, version=u'2.215', pkey_only=False) > 2016-12-05T19:13:47Z DEBUG raw: config_show(version=u'2.215') > 2016-12-05T19:13:47Z DEBUG config_show(rights=False, all=False, > raw=False, version=u'2.215') > 2016-12-05T19:13:47Z DEBUG raw: dns_is_enabled(version=u'2.215') > 2016-12-05T19:13:47Z DEBUG dns_is_enabled(version=u'2.215') > 2016-12-05T19:13:47Z DEBUG raw: ca_is_enabled(version=u'2.215') > 2016-12-05T19:13:47Z DEBUG ca_is_enabled(version=u'2.215') > 2016-12-05T19:13:47Z DEBUG File > "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in > execute > return_value = self.run() > File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line > 318, in run > cfgr.run() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 308, in run > self.validate() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 317, in validate > for nothing in self._validator(): > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 376, in __runner > exc_handler(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 400, in _handle_validate_exception > self._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 395, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 366, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 363, 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 575, in _configure > next(validator) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 376, in __runner > exc_handler(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 400, in _handle_validate_exception > self._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 460, in _handle_exception > self.__parent._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 395, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 457, in _handle_exception > super(ComponentBase, self)._handle_exception(exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 395, in _handle_exception > six.reraise(*exc_info) > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 366, in __runner > step() > File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", > line 363, 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 71, in _uninstall > for nothing in self._uninstaller(self.parent): > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", > line 1376, in main > uninstall_check(self) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", > line 270, in decorated > func(installer) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", > line 1047, in uninstall_check > remove_master_from_managed_topology(api, options) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", > line 310, in remove_master_from_managed_topology > raise ScriptError(str(e)) > > 2016-12-05T19:13:47Z DEBUG The ipa-server-install command failed, > exception: ScriptError: Server removal aborted: Deleting this server is > not allowed as it would leave your installation without a CA.. > 2016-12-05T19:13:47Z ERROR Server removal aborted: Deleting this server > is not allowed as it would leave your installation without a CA.. > 2016-12-05T19:13:47Z ERROR The ipa-server-install command failed. See > /var/log/ipaserver-uninstall.log for more information > > > Hi, if this server is the last FreeIPA server, the --ignore-last-of-role option will allow uninstallation: ipa-server-install --uninstall --ignore-last-of-role -U But if the topology contains multiple FreeIPA servers, it is recommended to replicate the CA instance on another server with ipa-ca-install before uninstalling the server with the CA. HTH, Flo. From freeipa-users at redhat.com Tue Dec 6 11:04:12 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 06 Dec 2016 06:04:12 -0500 Subject: [Freeipa-users] Change of list behavior Message-ID: <1481022252.4311.156.camel@redhat.com> Dear freeipa-users, due to persisting spam and other issues with DMARC protection, I changed the list behavior to anonymize the user's address. We'll experiment with this mode for a little while and see if it works for the group. If you have major issues with this mode please write to the list owners (you can find address and names in the list's mailman page) and we'll discuss those issues. Thank you all for participating in this community, hopefully this change will improve our communication tool. Simo. -- Simo Sorce * Red Hat, Inc * New York From freeipa-users at redhat.com Tue Dec 6 12:51:26 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 13:51:26 +0100 Subject: [Freeipa-users] Importing Host Entries from /etc/hosts using sample nis-hosts.sh: Zone name error In-Reply-To: <82CE9E83-4883-409D-9CD7-6BACCD7CF692@fordham.edu> References: <5E209638-1EEE-465F-9815-8B670FB39F9F@fordham.edu> <584597FB.4090505@redhat.com> <82CE9E83-4883-409D-9CD7-6BACCD7CF692@fordham.edu> Message-ID: On 05.12.2016 17:42, Robert Kudyba wrote: > >>> ./nis-hosts.sh nisnamesubdomain.ourdomain.edu >>> >>> >>> Zone name: >>> ipa: ERROR: 'name' is required >>> awk: cmd. line:1: {print $3 "."subdomain.ourdomain.edu >>> >>> >>> "." nisname ".in-addr.arpa."} >>> awk: cmd. line:1: ^ syntax error >>> >>> Zone name: subdomain >>> ipa: ERROR: DNS is not configured >> >> Looks to me like the DNS component was not configured in IPA so all the >> dns-* commands will fail. > > Well I mentioned that we are using the university?s DNS rather than a > dedicated DNS server on the FreeIPA Fedora server. Where do I > configure that in the GUI? Since our department does not have > authority over the ouruniversity.edu domain > I figured it was best to use their?s red resolving DNS. > > > Hello, you cannot use ipa dns* commands without integrated IPA DNS installed to add DNS records you have to use the standard way your university system provides. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-users at redhat.com Tue Dec 6 13:01:12 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 14:01:12 +0100 Subject: [Freeipa-users] New IPA Servers In-Reply-To: References: Message-ID: <46d2705d-a784-6bd7-8d7a-36865e63a322@redhat.com> On 02.12.2016 17:11, Outback Dingo wrote: > Ok so trying to setup a replca to deploy 2 new freeipa servers on > AWS... migrating from old servers going away, It was suggested to > create a replica then promote it. > > this issue is.... the public ip for the new server is not the same as > the servers IP on AWS... > so which one do i use ??? > Hello, please use internal address otherwise IPA installer checks don't leave you to finish installation. Which version of IPA do you have? if older than 4.4 in domain level 1 please make sure you set the new CA renewal master to a new server, http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_4.0_or_later Martin From freeipa-users at redhat.com Tue Dec 6 13:28:33 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 13:28:33 +0000 Subject: [Freeipa-users] nfsv4+kerberos: group ID not mapped on newly create users, however user id is correct Message-ID: <89213DDB84447F44A8E8950A5C2185E048329785@SJN01013.jnmain00.corp.jndata.net> VERSION: 4.4.0, API_VERSION: 2.213 on rhel7. ipa server was recently upgraded to version 4.4 from version 4.2 and it seems that we are having problems with users created after the upgrade. Of course, it could be something I forgot. Our environment consist of an hds nfs server, a couple of ipa servers - rhel7 and a lot of clients - rhel6. The NFS server is not part of the idm domain, i.e. not joined, but of course has a keytab created on the ipa server. The NFS server provides common shares, mounted as krb5p on the clients. All this workes fine and the mapping is correct for all existing users. That is, if I log into a client, get a Kerberos ticket for myself and create a file on one of the shares, uid and gid are set to my uid and gid. But if I create a new user on the ipa server and do the same, the gid on the newly created file is "nobody(99)" whereas the uid is correct. I have tested with two different users - same result. klist shows the default principal to be correct. For user mqm uid=1414 gid=1414, rpc.gssd shows,that after finding the user credentials, for some reason there is a switch to machine credentials: Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handle_gssd_upcall: 'mech=krb5 uid=1414 enctypes=18,17,16,23,3,1,2 ' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: process_krb5_upcall: service is '' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: getting credentials for client with uid 1414 for server jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1622800027_u0vmh1' being considered, with preferred realm 'DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1622800027_u0vmh1' owned by 1622800027, not 1414 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1414_bVlw8x' being considered, with preferred realm 'DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1414_bVlw8x'(mqm at DOMAINE.COM) passed all checks and has mtime of 1481022999 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_machine_DOMAINE.COM' being considered, with preferred realm 'DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_machine_DOMAINE.COM' owned by 0, not 1414 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_0' being considered, with preferred realm 'DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_0' owned by 0, not 1414 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using FILE:/tmp/krb5cc_1414_bVlw8x as credentials cache for client with uid 1414 for server jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1414_bVlw8x Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context using fsuid 1414 (save_uid 0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating tcp client for server jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: port already set to 2049 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context with server nfs at jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: serialize_krb5_ctx: lucid version! Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: protocol 1 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: doing downcall lifetime_rec 86363 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 ' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: process_krb5_upcall: service is '*' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: Full hostname for 'jnsa-dnt2.domaine.com' is 'jnsa-dnt2.domaine.com' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: Full hostname for 'nfsclient.domaine.com' is 'nfsclient.domaine.com' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfsclient$@DOMAINE.COM while getting keytab entry for 'nfsclient$@DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfsclient$@DOMAINE.COM while getting keytab entry for 'nfsclient$@DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for root/nfsclient.domaine.com at DOMAINE.COM while getting keytab entry for 'root/nfsclient.domaine.com at DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfs/nfsclient.domaine.com at DOMAINE.COM while getting keytab entry for 'nfs/nfsclient.domaine.com at DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: Success getting keytab entry for 'host/nfsclient.domaine.com at DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_DOMAINE.COM' are good until 1481109339 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_DOMAINE.COM' are good until 1481109339 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using FILE:/tmp/krb5cc_machine_DOMAINE.COM as credentials cache for machine creds Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_DOMAINE.COM Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context using fsuid 0 (save_uid 0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating tcp client for server jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: port already set to 2049 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context with server nfs at jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: serialize_krb5_ctx: lucid version! Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: protocol 1 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: doing downcall lifetime_rec 86303 Regards Bjarne Blichfeldt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-users at redhat.com Tue Dec 6 14:00:55 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 15:00:55 +0100 Subject: [Freeipa-users] Problem with autofs Message-ID: <03B20024-1A61-4051-96AF-D5F4B82BD28C@ims.uni-hannover.de> Hello, i have setup an IPA environment using Fedora 24 for the clients and Scientific Linux 7.2 for the servers. All clients are mounting NFS4 shares on a central server. The setup is based on the Red Hat Documentation (Red_Hat_Enterprise_Linux-7-Linux_Domain_Identity_Authentication_and_Policy_Guide-en-US). Everything works well, except one issue: On the NFS servers i was also using the command ipa-client-automount to complete the installation process. As i mentioned, it is a NFS4 server with a basic setup, exports like this: /export 1xx.xx.xx.0/25(ro,root_squash,sec=krb5i,fsid=0) /export/appl 1xx.xx.xx.0/25(rw,root_squash,sec=krb5i) But starting the autofs service freezes some parts of the server. Especially ?ls? is not working and you have to wait a long time to login. After a while autofs is running. After some days login is no problem or only sometimes. The same with ?ls?. I never saw NFS problems, this services had no problems. But the server crashes now every two or four days. Rebooting and running again. Ok, it makes no sense to run autofs on a dedicated NFS server. So i disabled this service and i had no problems anymore. But i think, it must be possible to run it. So i think, there is somewhere a big bug. So i want to know, is here someone who is running a Kerberized NFS Server in an IPA environment and also have autofs problems on this server? I have a lot of core dumps and system messages. I am not able to analyze them. Of course, i can send them somewhere ? At least i want to know, is this behavior a know bug or is something wrong with my configuration? Thanx for any hints. Detlev -- Detlev | Institut fuer Mikroelektronische Systeme Habicht | D-30167 Hannover +49 511 76219662 habicht at ims.uni-hannover.de --------+-------- Handy +49 172 5415752 --------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-users at redhat.com Tue Dec 6 15:55:12 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 06 Dec 2016 10:55:12 -0500 Subject: [Freeipa-users] IPA versions for small scale hope-to-be-production use on CentOS 7? Message-ID: <5846DF60.9090802@sonsorol.org> Still trying to figure out why my AD users in various trusted forests can be resolved and "su - " but password checks via SSH logins fail. In the mean time I'm wondering if I should consider upgrading before I go much further into the troubleshooting tunnel. It really does seem like there has been a ton of action in the codebase specifically relating to AD trusts. Maybe I should upgrade first and then keep troubleshooting on the updated software. We are not yet in production. We have a standard CentOS 7 server running this software set: > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 > ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64 > python-iniparse-0.4-9.el7.noarch > sssd-ipa-1.13.0-40.el7_2.12.x86_64 > ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64 > ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64 > ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64 > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.19.x86_64 > python-libipa_hbac-1.13.0-40.el7_2.12.x86_64 > libipa_hbac-1.13.0-40.el7_2.12.x86_64 Would people generally recommend stepping up to the stable 4.3 release on CentOS 7? If so are there any repositories that would be a good source for grabbing RPMs? Is 4.4 still not being recommended for production use? Thanks! Chris From freeipa-users at redhat.com Tue Dec 6 16:14:00 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 17:14:00 +0100 Subject: [Freeipa-users] IPA versions for small scale hope-to-be-production use on CentOS 7? In-Reply-To: <5846DF60.9090802@sonsorol.org> References: <5846DF60.9090802@sonsorol.org> Message-ID: <20161206161400.GE22795@p.Speedport_W_724V_Typ_A_05011603_00_009> On Tue, Dec 06, 2016 at 10:55:12AM -0500, List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: > > Still trying to figure out why my AD users in various trusted forests can be > resolved and "su - " but password checks via SSH logins fail. Do you call 'su - ' as root or do you get a password prompt here as well. In case you do it as root, can you try if calling it as a user will accept the password or not? In the latter case it might be some general issue with password authentication and the krb5_child.log file with debug_level=10 in the [domain/...] section of sssd.conf might help to find the reason (maybe ticket validation?). bye, Sumit > > In the mean time I'm wondering if I should consider upgrading before I go > much further into the troubleshooting tunnel. It really does seem like there > has been a ton of action in the codebase specifically relating to AD trusts. > Maybe I should upgrade first and then keep troubleshooting on the updated > software. We are not yet in production. > > We have a standard CentOS 7 server running this software set: > > > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64 > > python-iniparse-0.4-9.el7.noarch > > sssd-ipa-1.13.0-40.el7_2.12.x86_64 > > ipa-python-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-client-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-admintools-4.2.0-15.0.1.el7.centos.19.x86_64 > > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.19.x86_64 > > python-libipa_hbac-1.13.0-40.el7_2.12.x86_64 > > libipa_hbac-1.13.0-40.el7_2.12.x86_64 > > Would people generally recommend stepping up to the stable 4.3 release on > CentOS 7? If so are there any repositories that would be a good source for > grabbing RPMs? Is 4.4 still not being recommended for production use? > > Thanks! > > 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 freeipa-users at redhat.com Tue Dec 6 16:23:02 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 17:23:02 +0100 Subject: [Freeipa-users] ns-slapd often hangs on CentOS 7 Message-ID: <20161206162300.GA12296@atkac-gd> Hello all, we recently updated our two freeipa clusters to CentOS 7 and both of them now suffers from often ns-slapd hangs. We use stock CentOS 7.2 packages with one exception - 389-ds-base-1.3.5.10-11 which comes from RHEL 7.3 together with backported fix https://fedorahosted.org/389/changeset/e2bc8fd60bf232cd4c1bc9a6860b7bd570a9dff1/ After update we are facing issue that random nodes in the cluster (we have two 6-nodes clusters) hang and stops to answer and must be manually restarted. It happens roughly twice a day which is pretty annoying. Symptoms are same every time, ns-slapd accepts connection but simply keeps it open and doesn't respond. Package versions: # rpm -q 389-ds-base{,-libs,-debuginfo} libdb{,-debuginfo} 389-ds-base-1.3.5.10-11.gdc1.x86_64 389-ds-base-libs-1.3.5.10-11.gdc1.x86_64 389-ds-base-debuginfo-1.3.5.10-11.gdc1.x86_64 libdb-5.3.21-19.el7.x86_64 libdb-debuginfo-5.3.21-19.el7.x86_64 (as I wrote above, that .gdc1 packages are rebuilt RHEL 7.3 packages with above fix) I captured pstack trace & db locks dump (db_stat -h /var/lib/dirsrv/slapd-PRODGDC-COM/db -N -CA) from the hung ns-slapd. Both files are attached. Do you have any clue where might be the problem? Thank you in advance for response. Regards, Adam -------------- next part -------------- Default locking region information: 305 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 150 Initial number of locks allocated 0 Initial number of lockers allocated 150 Initial number of lock objects allocated 10000 Maximum number of locks possible 10000 Maximum number of lockers possible 10000 Maximum number of lock objects possible 707 Current number of locks allocated 293 Current number of lockers allocated 363 Current number of lock objects allocated 30 Number of lock object partitions 8191 Size of object hash table 117 Number of current locks 723 Maximum number of locks at any one time 25 Maximum number of locks in any one bucket 1659 Maximum number of locks stolen by for an empty partition 89 Maximum number of locks stolen for any one partition 289 Number of current lockers 292 Maximum number of lockers at any one time 115 Number of current lock objects 441 Maximum number of lock objects at any one time 3 Maximum number of lock objects in any one bucket 1132 Maximum number of objects stolen by for an empty partition 45 Maximum number of objects stolen for any one partition 19M Total number of locks requested (19374435) 19M Total number of locks released (19367572) 0 Total number of locks upgraded 103 Total number of locks downgraded 1406 Lock requests not available due to conflicts, for which we waited 5075 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 2MB 288KB Region size 2819 The number of partition locks that required waiting (0%) 553 The maximum number of times any partition lock was waited for (0%) 0 The number of object queue operations that required waiting (0%) 62 The number of locker allocations that required waiting (0%) 1367 The number of region locks that required waiting (0%) 5 Maximum hash bucket length =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Environment Region type 1 Region ID /var/lib/dirsrv/slapd-PRODGDC-COM/db/__db.001 Region name 0x7f0ba133b000 Region address 0x7f0ba133b0a0 Region allocation head 0x7f0ba13432b0 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 750942 allocations, 0 failures, 750625 frees, 4 longest Allocations by power-of-two sizes: 1KB 750916 2KB 3 4KB 7 8KB 9 16KB 4 32KB 1 64KB 0 128KB 0 256KB 2 512KB 0 1024KB 1 REGION_SHARED Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock region parameters: 2 Lock region region mutex [1367/9417277 0% !Own] 16381 locker table size 8191 object table size 34128 obj_off 888776 locker_off 0 need_dd =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock conflict matrix: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 2 dd=288 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 2 READ 1 HELD userRoot/id2entry.db handle 0 3 dd=287 locks held 0 write locks 0 pid/thread 29929/139844000872192 flags 0 priority 100 4 dd=286 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 4 READ 1 HELD ipaca/id2entry.db handle 0 5 dd=285 locks held 0 write locks 0 pid/thread 29929/139843874981632 flags 0 priority 100 6 dd=284 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 6 READ 1 HELD ipaca/entryrdn.db handle 0 7 dd=283 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 8 dd=282 locks held 0 write locks 0 pid/thread 29929/139844009264896 flags 0 priority 100 9 dd=281 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 a dd=280 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 a READ 1 HELD ipaca/vlv#allcertspkitomcatindex.db handle 0 e dd=279 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 e READ 1 HELD ipaca/vlv#allnonrevokedcertspkitomcatindex.db handle 0 10 dd=278 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 10 READ 1 HELD ipaca/vlv#allrevokedcertspkitomcatindex.db handle 0 11 dd=277 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 11 READ 1 HELD ipaca/vlv#allrevokedcertsnotafterpkitomcatindex.db handle 0 14 dd=276 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 14 READ 1 HELD ipaca/vlv#allrevokedorrevokedexpiredcertspkitomcatindex.db handle 0 15 dd=275 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 15 READ 1 HELD ipaca/vlv#allvalidcertspkitomcatindex.db handle 0 16 dd=274 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 16 READ 1 HELD ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db handle 0 17 dd=273 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 17 READ 1 HELD ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db handle 0 18 dd=272 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 18 READ 1 HELD ipaca/vlv#caallpkitomcatindex.db handle 0 1d dd=271 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 1d READ 1 HELD ipaca/vlv#cacompletepkitomcatindex.db handle 0 1e dd=270 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 1e READ 1 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db handle 0 1f dd=269 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 1f READ 1 HELD ipaca/vlv#cacompleterenewalpkitomcatindex.db handle 0 20 dd=268 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 20 READ 1 HELD ipaca/vlv#cacompleterevocationpkitomcatindex.db handle 0 21 dd=267 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 21 READ 1 HELD ipaca/vlv#caenrollmentpkitomcatindex.db handle 0 22 dd=266 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 22 READ 1 HELD ipaca/vlv#capendingpkitomcatindex.db handle 0 24 dd=265 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 24 READ 1 HELD ipaca/vlv#capendingrenewalpkitomcatindex.db handle 0 2a dd=264 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 2a READ 1 HELD ipaca/vlv#carenewalpkitomcatindex.db handle 0 2b dd=263 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 2b READ 1 HELD ipaca/vlv#carevocationpkitomcatindex.db handle 0 2c dd=262 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 2c READ 1 HELD changelog/id2entry.db handle 0 2d dd=261 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 2e dd=260 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 2e READ 1 HELD changelog/entryusn.db handle 0 2f dd=259 locks held 0 write locks 0 pid/thread 29929/139845097302144 flags 0 priority 100 30 dd=258 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 30 READ 1 HELD userRoot/entryusn.db handle 0 31 dd=257 locks held 0 write locks 0 pid/thread 29929/139845097302144 flags 0 priority 100 32 dd=256 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 32 READ 1 HELD ipaca/entryusn.db handle 0 33 dd=255 locks held 0 write locks 0 pid/thread 29929/139845097302144 flags 0 priority 100 34 dd=254 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 34 READ 1 HELD userRoot/entryrdn.db handle 0 35 dd=253 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 36 dd=252 locks held 0 write locks 0 pid/thread 29929/139844059621120 flags 0 priority 100 37 dd=251 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 38 dd=250 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 38 READ 1 HELD userRoot/objectclass.db handle 0 39 dd=249 locks held 0 write locks 0 pid/thread 29929/139843916945152 flags 0 priority 100 3a dd=248 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 3a READ 1 HELD userRoot/ancestorid.db handle 0 3b dd=247 locks held 0 write locks 0 pid/thread 29929/139844059621120 flags 0 priority 100 3c dd=246 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 3c READ 1 HELD changelog/entryrdn.db handle 0 3d dd=245 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 3e dd=244 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 3f dd=243 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 40 dd=242 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 40 READ 1 HELD changelog/objectclass.db handle 0 41 dd=241 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 42 dd=240 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 43 dd=239 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 44 dd=238 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 44 READ 1 HELD ipaca/objectclass.db handle 0 45 dd=237 locks held 0 write locks 0 pid/thread 29929/139843933730560 flags 0 priority 100 46 dd=236 locks held 0 write locks 0 pid/thread 29929/139843933730560 flags 0 priority 100 47 dd=235 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 47 READ 1 HELD changelog/aci.db handle 0 48 dd=234 locks held 0 write locks 0 pid/thread 29929/139845097302144 flags 0 priority 100 49 dd=233 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 49 READ 1 HELD userRoot/aci.db handle 0 4a dd=232 locks held 0 write locks 0 pid/thread 29929/139845097302144 flags 0 priority 100 4b dd=231 locks held 0 write locks 0 pid/thread 29929/139843883374336 flags 0 priority 100 4c dd=230 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 4d dd=229 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 4d READ 1 HELD ipaca/aci.db handle 0 4e dd=228 locks held 0 write locks 0 pid/thread 29929/139845097302144 flags 0 priority 100 4f dd=227 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 4f READ 1 HELD userRoot/parentid.db handle 0 50 dd=226 locks held 0 write locks 0 pid/thread 29929/139843874981632 flags 0 priority 100 51 dd=225 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 52 dd=224 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 52 READ 1 HELD userRoot/nsuniqueid.db handle 0 53 dd=223 locks held 0 write locks 0 pid/thread 29929/139845097302144 flags 0 priority 100 54 dd=222 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 54 READ 1 HELD ipaca/nsuniqueid.db handle 0 55 dd=221 locks held 0 write locks 0 pid/thread 29929/139845097302144 flags 0 priority 100 56 dd=220 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 56 READ 1 HELD /var/lib/dirsrv/slapd-PRODGDC-COM/cldb/8dc3b81e-a69911e6-9e41e1de-22f7fdb9_56604b56000000600000.db handle 0 57 dd=219 locks held 0 write locks 0 pid/thread 29929/139844638455552 flags 0 priority 100 58 dd=218 locks held 0 write locks 0 pid/thread 29929/139844638455552 flags 0 priority 100 59 dd=217 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 59 READ 1 HELD /var/lib/dirsrv/slapd-PRODGDC-COM/cldb/55bc7594-a69911e6-9e41e1de-22f7fdb9_548f05c0000000040000.db handle 0 5a dd=216 locks held 0 write locks 0 pid/thread 29929/139844655240960 flags 0 priority 100 5b dd=215 locks held 0 write locks 0 pid/thread 29929/139844655240960 flags 0 priority 100 5c dd=214 locks held 0 write locks 0 pid/thread 29929/139845097302144 flags 0 priority 100 5d dd=213 locks held 0 write locks 0 pid/thread 29929/139845097302144 flags 0 priority 100 5e dd=212 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 5e READ 1 HELD changelog/nsuniqueid.db handle 0 5f dd=211 locks held 1 write locks 0 pid/thread 29929/139845097302144 flags 10 priority 100 5f READ 1 HELD changelog/changenumber.db handle 0 60 dd=210 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 61 dd=209 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 62 dd=208 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 62 READ 1 HELD userRoot/nsTombstoneCSN.db handle 0 63 dd=207 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 63 READ 1 HELD userRoot/nscpEntryDN.db handle 0 64 dd=206 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 64 READ 1 HELD userRoot/numsubordinates.db handle 0 65 dd=205 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 65 READ 1 HELD changelog/targetuniqueid.db handle 0 66 dd=204 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 66 READ 1 HELD changelog/parentid.db handle 0 67 dd=203 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 67 READ 1 HELD changelog/ancestorid.db handle 0 68 dd=202 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 68 READ 1 HELD changelog/numsubordinates.db handle 0 69 dd=201 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 69 READ 1 HELD userRoot/member.db handle 0 6a dd=200 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 6a READ 1 HELD userRoot/uniquemember.db handle 0 6b dd=199 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 6b READ 1 HELD userRoot/owner.db handle 0 6c dd=198 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 6c READ 1 HELD userRoot/seeAlso.db handle 0 6d dd=197 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 6d READ 1 HELD userRoot/ipaallowedtarget.db handle 0 6e dd=196 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 6e READ 1 HELD userRoot/ipaMemberCertProfile.db handle 0 6f dd=195 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 6f READ 1 HELD userRoot/ipaassignedidview.db handle 0 70 dd=194 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 70 READ 1 HELD userRoot/secretary.db handle 0 71 dd=193 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 71 READ 1 HELD userRoot/memberUser.db handle 0 72 dd=192 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 72 READ 1 HELD userRoot/memberdenycmd.db handle 0 73 dd=191 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 73 READ 1 HELD userRoot/memberallowcmd.db handle 0 74 dd=190 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 74 READ 1 HELD userRoot/manager.db handle 0 75 dd=189 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 75 READ 1 HELD userRoot/managedby.db handle 0 76 dd=188 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 76 READ 1 HELD userRoot/ipasudorunas.db handle 0 77 dd=187 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 77 READ 1 HELD userRoot/ipaMemberCa.db handle 0 78 dd=186 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 78 READ 1 HELD userRoot/ipasudorunasgroup.db handle 0 79 dd=185 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 79 READ 1 HELD userRoot/memberHost.db handle 0 7a dd=184 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 7a READ 1 HELD userRoot/sourcehost.db handle 0 7b dd=183 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 7b READ 1 HELD userRoot/memberservice.db handle 0 7c dd=182 locks held 1 write locks 0 pid/thread 29929/139844101584640 flags 10 priority 100 7c READ 1 HELD userRoot/ipatokenradiusconfiglink.db handle 0 7d dd=181 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 7e dd=180 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 7f dd=179 locks held 0 write locks 0 pid/thread 29929/139843992479488 flags 0 priority 100 80 dd=178 locks held 0 write locks 0 pid/thread 29929/139843874981632 flags 0 priority 100 81 dd=177 locks held 1 write locks 0 pid/thread 29929/139844051228416 flags 10 priority 100 81 READ 1 HELD userRoot/ipakrbprincipalalias.db handle 0 82 dd=176 locks held 0 write locks 0 pid/thread 29929/139844059621120 flags 0 priority 100 83 dd=175 locks held 1 write locks 0 pid/thread 29929/139844051228416 flags 10 priority 100 83 READ 1 HELD userRoot/krbPrincipalName.db handle 0 84 dd=174 locks held 0 write locks 0 pid/thread 29929/139844059621120 flags 0 priority 100 85 dd=173 locks held 0 write locks 0 pid/thread 29929/139843858196224 flags 0 priority 100 86 dd=172 locks held 0 write locks 0 pid/thread 29929/139844009264896 flags 0 priority 100 87 dd=171 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 88 dd=170 locks held 0 write locks 0 pid/thread 29929/139843916945152 flags 0 priority 100 89 dd=169 locks held 1 write locks 0 pid/thread 29929/139843958908672 flags 10 priority 100 89 READ 1 HELD changelog/seeAlso.db handle 0 8a dd=168 locks held 0 write locks 0 pid/thread 29929/139843858196224 flags 0 priority 100 8b dd=167 locks held 0 write locks 0 pid/thread 29929/139844093191936 flags 0 priority 100 8c dd=166 locks held 1 write locks 0 pid/thread 29929/139843958908672 flags 10 priority 100 8c READ 1 HELD ipaca/seeAlso.db handle 0 8d dd=165 locks held 0 write locks 0 pid/thread 29929/139843858196224 flags 0 priority 100 8e dd=164 locks held 1 write locks 0 pid/thread 29929/139843950515968 flags 10 priority 100 8e READ 1 HELD ipaca/parentid.db handle 0 8f dd=163 locks held 0 write locks 0 pid/thread 29929/139843950515968 flags 0 priority 100 90 dd=162 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 91 dd=161 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 92 dd=160 locks held 1 write locks 0 pid/thread 29929/139843984086784 flags 10 priority 100 92 READ 1 HELD userRoot/cn.db handle 0 93 dd=159 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 94 dd=158 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 95 dd=157 locks held 1 write locks 0 pid/thread 29929/139843958908672 flags 10 priority 100 95 READ 1 HELD userRoot/uid.db handle 0 96 dd=156 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 97 dd=155 locks held 0 write locks 0 pid/thread 29929/139843984086784 flags 0 priority 100 98 dd=154 locks held 1 write locks 0 pid/thread 29929/139844076406528 flags 10 priority 100 98 READ 1 HELD userRoot/fqdn.db handle 0 99 dd=153 locks held 0 write locks 0 pid/thread 29929/139843950515968 flags 0 priority 100 9a dd=152 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 9b dd=151 locks held 1 write locks 0 pid/thread 29929/139843900159744 flags 10 priority 100 9b READ 1 HELD userRoot/ipauniqueid.db handle 0 9c dd=150 locks held 1 write locks 0 pid/thread 29929/139843883374336 flags 10 priority 100 9c READ 1 HELD userRoot/memberOf.db handle 0 9d dd=149 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 9d READ 1 HELD ipaca/requestid.db handle 0 9e dd=148 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 9e READ 1 HELD ipaca/requeststate.db handle 0 9f dd=147 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 9f READ 1 HELD ipaca/dateOfCreate.db handle 0 a0 dd=146 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 a0 READ 1 HELD ipaca/requesttype.db handle 0 a1 dd=145 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 a1 READ 1 HELD ipaca/cn.db handle 0 a2 dd=144 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 a2 READ 1 HELD ipaca/ancestorid.db handle 0 a3 dd=143 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 a3 READ 1 HELD ipaca/numsubordinates.db handle 0 a4 dd=142 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 a5 dd=141 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 a5 READ 1 HELD ipaca/serialno.db handle 0 a6 dd=140 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 a6 READ 1 HELD ipaca/metaInfo.db handle 0 a7 dd=139 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 a7 READ 1 HELD ipaca/notbefore.db handle 0 a8 dd=138 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 a8 READ 1 HELD ipaca/notafter.db handle 0 a9 dd=137 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 a9 READ 1 HELD ipaca/duration.db handle 0 aa dd=136 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 aa READ 1 HELD ipaca/subjectname.db handle 0 ab dd=135 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 ab READ 1 HELD ipaca/publicKeyData.db handle 0 ac dd=134 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 ac READ 1 HELD ipaca/extension.db handle 0 ad dd=133 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 ad READ 1 HELD ipaca/certstatus.db handle 0 ae dd=132 locks held 1 write locks 0 pid/thread 29929/139844093191936 flags 10 priority 100 ae READ 1 HELD ipaca/issuedby.db handle 0 af dd=131 locks held 1 write locks 0 pid/thread 29929/139844076406528 flags 10 priority 100 af READ 1 HELD ipaca/revInfo.db handle 0 b0 dd=130 locks held 1 write locks 0 pid/thread 29929/139844076406528 flags 10 priority 100 b0 READ 1 HELD ipaca/revokedby.db handle 0 b1 dd=129 locks held 1 write locks 0 pid/thread 29929/139844076406528 flags 10 priority 100 b1 READ 1 HELD ipaca/revokedOn.db handle 0 b2 dd=128 locks held 0 write locks 0 pid/thread 29929/139844059621120 flags 0 priority 100 b3 dd=127 locks held 0 write locks 0 pid/thread 29929/139843967301376 flags 0 priority 100 b4 dd=126 locks held 0 write locks 0 pid/thread 29929/139844076406528 flags 0 priority 100 b5 dd=125 locks held 0 write locks 0 pid/thread 29929/139844093191936 flags 0 priority 100 b6 dd=124 locks held 0 write locks 0 pid/thread 29929/139843900159744 flags 0 priority 100 b7 dd=123 locks held 0 write locks 0 pid/thread 29929/139843900159744 flags 0 priority 100 b8 dd=122 locks held 0 write locks 0 pid/thread 29929/139844059621120 flags 0 priority 100 b9 dd=121 locks held 0 write locks 0 pid/thread 29929/139844000872192 flags 0 priority 100 ba dd=120 locks held 1 write locks 0 pid/thread 29929/139843833018112 flags 10 priority 100 ba READ 1 HELD userRoot/macAddress.db handle 0 bb dd=119 locks held 0 write locks 0 pid/thread 29929/139843833018112 flags 0 priority 100 bc dd=118 locks held 0 write locks 0 pid/thread 29929/139844059621120 flags 0 priority 100 bd dd=117 locks held 0 write locks 0 pid/thread 29929/139844042835712 flags 0 priority 100 be dd=116 locks held 0 write locks 0 pid/thread 29929/139844000872192 flags 0 priority 100 bf dd=115 locks held 0 write locks 0 pid/thread 29929/139843908552448 flags 0 priority 100 c0 dd=114 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 c1 dd=113 locks held 0 write locks 0 pid/thread 29929/139843849803520 flags 0 priority 100 c2 dd=112 locks held 0 write locks 0 pid/thread 29929/139844093191936 flags 0 priority 100 c3 dd=111 locks held 0 write locks 0 pid/thread 29929/139843883374336 flags 0 priority 100 c4 dd=110 locks held 0 write locks 0 pid/thread 29929/139844093191936 flags 0 priority 100 c5 dd=109 locks held 1 write locks 0 pid/thread 29929/139844017657600 flags 10 priority 100 c5 READ 1 HELD ipaca/description.db handle 0 c6 dd=108 locks held 0 write locks 0 pid/thread 29929/139843891767040 flags 0 priority 100 c7 dd=107 locks held 0 write locks 0 pid/thread 29929/139844009264896 flags 0 priority 100 c8 dd=106 locks held 0 write locks 0 pid/thread 29929/139844068013824 flags 0 priority 100 c9 dd=105 locks held 0 write locks 0 pid/thread 29929/139843967301376 flags 0 priority 100 ca dd=104 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 cb dd=103 locks held 0 write locks 0 pid/thread 29929/139843975694080 flags 0 priority 100 cc dd=102 locks held 0 write locks 0 pid/thread 29929/139843967301376 flags 0 priority 100 cd dd=101 locks held 0 write locks 0 pid/thread 29929/139843975694080 flags 0 priority 100 ce dd=100 locks held 0 write locks 0 pid/thread 29929/139843849803520 flags 0 priority 100 cf dd=99 locks held 1 write locks 0 pid/thread 29929/139843866588928 flags 10 priority 100 cf READ 1 HELD userRoot/userCertificate.db handle 0 d0 dd=98 locks held 0 write locks 0 pid/thread 29929/139844051228416 flags 0 priority 100 d1 dd=97 locks held 0 write locks 0 pid/thread 29929/139843891767040 flags 0 priority 100 d2 dd=96 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 d3 dd=95 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 d4 dd=94 locks held 0 write locks 0 pid/thread 29929/139844093191936 flags 0 priority 100 d5 dd=93 locks held 0 write locks 0 pid/thread 29929/139844093191936 flags 0 priority 100 d6 dd=92 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 d7 dd=91 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 d8 dd=90 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 d9 dd=89 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 da dd=88 locks held 0 write locks 0 pid/thread 29929/139843858196224 flags 0 priority 100 db dd=87 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 dc dd=86 locks held 0 write locks 0 pid/thread 29929/139844059621120 flags 0 priority 100 dd dd=85 locks held 0 write locks 0 pid/thread 29929/139844051228416 flags 0 priority 100 de dd=84 locks held 0 write locks 0 pid/thread 29929/139843975694080 flags 0 priority 100 df dd=83 locks held 0 write locks 0 pid/thread 29929/139843849803520 flags 0 priority 100 e0 dd=82 locks held 0 write locks 0 pid/thread 29929/139844655240960 flags 0 priority 100 e1 dd=81 locks held 0 write locks 0 pid/thread 29929/139844017657600 flags 0 priority 100 e2 dd=80 locks held 0 write locks 0 pid/thread 29929/139843849803520 flags 0 priority 100 e3 dd=79 locks held 0 write locks 0 pid/thread 29929/139844000872192 flags 0 priority 100 e4 dd=78 locks held 0 write locks 0 pid/thread 29929/139843967301376 flags 0 priority 100 e5 dd=77 locks held 0 write locks 0 pid/thread 29929/139843900159744 flags 0 priority 100 e6 dd=76 locks held 0 write locks 0 pid/thread 29929/139843874981632 flags 0 priority 100 e7 dd=75 locks held 0 write locks 0 pid/thread 29929/139843891767040 flags 0 priority 100 e8 dd=74 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 e9 dd=73 locks held 0 write locks 0 pid/thread 29929/139844093191936 flags 0 priority 100 ea dd=72 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 eb dd=71 locks held 0 write locks 0 pid/thread 29929/139843967301376 flags 0 priority 100 ec dd=70 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 ed dd=69 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 ee dd=68 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 ef dd=67 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 f0 dd=66 locks held 0 write locks 0 pid/thread 29929/139844026050304 flags 0 priority 100 f1 dd=65 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 f2 dd=64 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 f3 dd=63 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 f4 dd=62 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 f5 dd=61 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 f6 dd=60 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 f7 dd=59 locks held 0 write locks 0 pid/thread 29929/139844084799232 flags 0 priority 100 f7 READ 1 WAIT userRoot/objectclass.db page 6 f8 dd=58 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 f9 dd=57 locks held 0 write locks 0 pid/thread 29929/139843874981632 flags 0 priority 100 fa dd=56 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 fb dd=55 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 fc dd=54 locks held 0 write locks 0 pid/thread 29929/139844017657600 flags 0 priority 100 fd dd=53 locks held 0 write locks 0 pid/thread 29929/139843950515968 flags 0 priority 100 fd READ 1 WAIT userRoot/objectclass.db page 6 fe dd=52 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 ff dd=51 locks held 0 write locks 0 pid/thread 29929/139843883374336 flags 0 priority 100 100 dd=50 locks held 0 write locks 0 pid/thread 29929/139843984086784 flags 0 priority 100 101 dd=49 locks held 0 write locks 0 pid/thread 29929/139843925337856 flags 0 priority 100 102 dd=48 locks held 0 write locks 0 pid/thread 29929/139844026050304 flags 0 priority 100 103 dd=47 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 104 dd=46 locks held 0 write locks 0 pid/thread 29929/139844051228416 flags 0 priority 100 105 dd=45 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 106 dd=44 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 107 dd=43 locks held 0 write locks 0 pid/thread 29929/139844093191936 flags 0 priority 100 108 dd=42 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 109 dd=41 locks held 0 write locks 0 pid/thread 29929/139844026050304 flags 0 priority 100 10a dd=40 locks held 0 write locks 0 pid/thread 29929/139843874981632 flags 0 priority 100 10b dd=39 locks held 0 write locks 0 pid/thread 29929/139844026050304 flags 0 priority 100 10c dd=38 locks held 0 write locks 0 pid/thread 29929/139843891767040 flags 0 priority 100 10d dd=37 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 10e dd=36 locks held 0 write locks 0 pid/thread 29929/139843958908672 flags 0 priority 100 10f dd=35 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 110 dd=34 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 111 dd=33 locks held 0 write locks 0 pid/thread 29929/139843992479488 flags 0 priority 100 112 dd=32 locks held 0 write locks 0 pid/thread 29929/139844059621120 flags 0 priority 100 113 dd=31 locks held 0 write locks 0 pid/thread 29929/139844026050304 flags 0 priority 100 114 dd=30 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 115 dd=29 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 116 dd=28 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 117 dd=27 locks held 0 write locks 0 pid/thread 29929/139844084799232 flags 0 priority 100 118 dd=26 locks held 0 write locks 0 pid/thread 29929/139843925337856 flags 0 priority 100 119 dd=25 locks held 1 write locks 0 pid/thread 29929/139844084799232 flags 10 priority 100 119 READ 1 HELD userRoot/gidnumber.db handle 0 11a dd=24 locks held 0 write locks 0 pid/thread 29929/139844042835712 flags 0 priority 100 11b dd=23 locks held 1 write locks 0 pid/thread 29929/139843967301376 flags 10 priority 100 11b READ 1 HELD userRoot/uidnumber.db handle 0 11c dd=22 locks held 0 write locks 0 pid/thread 29929/139843849803520 flags 0 priority 100 11d dd=21 locks held 0 write locks 0 pid/thread 29929/139844084799232 flags 0 priority 100 11e dd=20 locks held 0 write locks 0 pid/thread 29929/139843975694080 flags 0 priority 100 11f dd=19 locks held 0 write locks 0 pid/thread 29929/139844051228416 flags 0 priority 100 120 dd=18 locks held 0 write locks 0 pid/thread 29929/139844051228416 flags 0 priority 100 121 dd=17 locks held 0 write locks 0 pid/thread 29929/139843874981632 flags 0 priority 100 122 dd=16 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 123 dd=15 locks held 0 write locks 0 pid/thread 29929/139843900159744 flags 0 priority 100 124 dd=14 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 125 dd=13 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 126 dd=12 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 127 dd=11 locks held 0 write locks 0 pid/thread 29929/139842742630144 flags 0 priority 100 128 dd=10 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 129 dd= 9 locks held 0 write locks 0 pid/thread 29929/139844638455552 flags 0 priority 100 12a dd= 8 locks held 0 write locks 0 pid/thread 29929/139843942123264 flags 0 priority 100 12b dd= 7 locks held 0 write locks 0 pid/thread 29929/139842734237440 flags 0 priority 100 12c dd= 6 locks held 0 write locks 0 pid/thread 29929/139843849803520 flags 0 priority 100 12d dd= 5 locks held 0 write locks 0 pid/thread 29929/139844009264896 flags 0 priority 100 12e dd= 4 locks held 0 write locks 0 pid/thread 29929/139844084799232 flags 0 priority 100 12f dd= 3 locks held 0 write locks 0 pid/thread 29929/139843916945152 flags 0 priority 100 130 dd= 2 locks held 0 write locks 0 pid/thread 29929/139843967301376 flags 0 priority 100 131 dd= 1 locks held 0 write locks 0 pid/thread 29929/139843958908672 flags 0 priority 100 8005eeef dd= 0 locks held 12 write locks 6 pid/thread 29929/139843925337856 flags 0 priority 100 8005eeef WRITE 1 HELD userRoot/objectclass.db page 6 8005eeef WRITE 1 HELD userRoot/objectclass.db page 0 8005eeef WRITE 1 HELD userRoot/objectclass.db page 7 8005eeef WRITE 1 HELD userRoot/objectclass.db page 5 8005eeef WRITE 2 HELD userRoot/objectclass.db page 3 8005eeef WRITE 1 HELD userRoot/id2entry.db page 5577 8005eeef READ 4 HELD userRoot/nsuniqueid.db page 14 8005eeef READ 2 HELD userRoot/entryrdn.db page 16 8005eeef READ 1 HELD userRoot/entryrdn.db page 3 8005eeef READ 1 HELD userRoot/entryrdn.db page 670 8005eeef READ 1 HELD userRoot/entryrdn.db page 665 8005eeef READ 1 HELD userRoot/nsuniqueid.db page 37 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 1e READ 1 HELD ipaca/vlv#cacompleteenrollmentpkitomcatindex.db handle 0 52 READ 1 HELD userRoot/nsuniqueid.db handle 0 2c READ 1 HELD changelog/id2entry.db handle 0 8005eeef READ 4 HELD userRoot/nsuniqueid.db page 14 8005eeef READ 1 HELD userRoot/nsuniqueid.db page 37 20 READ 1 HELD ipaca/vlv#cacompleterevocationpkitomcatindex.db handle 0 44 READ 1 HELD ipaca/objectclass.db handle 0 2e READ 1 HELD changelog/entryusn.db handle 0 62 READ 1 HELD userRoot/nsTombstoneCSN.db handle 0 92 READ 1 HELD userRoot/cn.db handle 0 2 READ 1 HELD userRoot/id2entry.db handle 0 1f READ 1 HELD ipaca/vlv#cacompleterenewalpkitomcatindex.db handle 0 83 READ 1 HELD userRoot/krbPrincipalName.db handle 0 5f READ 1 HELD changelog/changenumber.db handle 0 8c READ 1 HELD ipaca/seeAlso.db handle 0 4d READ 1 HELD ipaca/aci.db handle 0 72 READ 1 HELD userRoot/memberdenycmd.db handle 0 14 READ 1 HELD ipaca/vlv#allrevokedorrevokedexpiredcertspkitomcatindex.db handle 0 6b READ 1 HELD userRoot/owner.db handle 0 af READ 1 HELD ipaca/revInfo.db handle 0 30 READ 1 HELD userRoot/entryusn.db handle 0 9c READ 1 HELD userRoot/memberOf.db handle 0 59 READ 1 HELD /var/lib/dirsrv/slapd-PRODGDC-COM/cldb/55bc7594-a69911e6-9e41e1de-22f7fdb9_548f05c0000000040000.db handle 0 a9 READ 1 HELD ipaca/duration.db handle 0 e READ 1 HELD ipaca/vlv#allnonrevokedcertspkitomcatindex.db handle 0 65 READ 1 HELD changelog/targetuniqueid.db handle 0 ad READ 1 HELD ipaca/certstatus.db handle 0 8005eeef READ 1 HELD userRoot/entryrdn.db page 670 8005eeef READ 1 HELD userRoot/entryrdn.db page 665 71 READ 1 HELD userRoot/memberUser.db handle 0 9d READ 1 HELD ipaca/requestid.db handle 0 54 READ 1 HELD ipaca/nsuniqueid.db handle 0 ab READ 1 HELD ipaca/publicKeyData.db handle 0 75 READ 1 HELD userRoot/managedby.db handle 0 32 READ 1 HELD ipaca/entryusn.db handle 0 49 READ 1 HELD userRoot/aci.db handle 0 8005eeef READ 2 HELD userRoot/entryrdn.db page 16 8005eeef READ 1 HELD userRoot/entryrdn.db page 3 34 READ 1 HELD userRoot/entryrdn.db handle 0 7c READ 1 HELD userRoot/ipatokenradiusconfiglink.db handle 0 b0 READ 1 HELD ipaca/revokedby.db handle 0 a5 READ 1 HELD ipaca/serialno.db handle 0 2b READ 1 HELD ipaca/vlv#carevocationpkitomcatindex.db handle 0 119 READ 1 HELD userRoot/gidnumber.db handle 0 24 READ 1 HELD ipaca/vlv#capendingrenewalpkitomcatindex.db handle 0 2a READ 1 HELD ipaca/vlv#carenewalpkitomcatindex.db handle 0 b1 READ 1 HELD ipaca/revokedOn.db handle 0 11 READ 1 HELD ipaca/vlv#allrevokedcertsnotafterpkitomcatindex.db handle 0 6c READ 1 HELD userRoot/seeAlso.db handle 0 8e READ 1 HELD ipaca/parentid.db handle 0 17 READ 1 HELD ipaca/vlv#allvalidorrevokedcertspkitomcatindex.db handle 0 40 READ 1 HELD changelog/objectclass.db handle 0 56 READ 1 HELD /var/lib/dirsrv/slapd-PRODGDC-COM/cldb/8dc3b81e-a69911e6-9e41e1de-22f7fdb9_56604b56000000600000.db handle 0 8005eeef WRITE 1 HELD userRoot/id2entry.db page 5577 67 READ 1 HELD changelog/ancestorid.db handle 0 70 READ 1 HELD userRoot/secretary.db handle 0 a7 READ 1 HELD ipaca/notbefore.db handle 0 63 READ 1 HELD userRoot/nscpEntryDN.db handle 0 1d READ 1 HELD ipaca/vlv#cacompletepkitomcatindex.db handle 0 a READ 1 HELD ipaca/vlv#allcertspkitomcatindex.db handle 0 3a READ 1 HELD userRoot/ancestorid.db handle 0 6a READ 1 HELD userRoot/uniquemember.db handle 0 64 READ 1 HELD userRoot/numsubordinates.db handle 0 6d READ 1 HELD userRoot/ipaallowedtarget.db handle 0 5e READ 1 HELD changelog/nsuniqueid.db handle 0 68 READ 1 HELD changelog/numsubordinates.db handle 0 a0 READ 1 HELD ipaca/requesttype.db handle 0 77 READ 1 HELD userRoot/ipaMemberCa.db handle 0 c5 READ 1 HELD ipaca/description.db handle 0 ae READ 1 HELD ipaca/issuedby.db handle 0 ac READ 1 HELD ipaca/extension.db handle 0 6e READ 1 HELD userRoot/ipaMemberCertProfile.db handle 0 7b READ 1 HELD userRoot/memberservice.db handle 0 9e READ 1 HELD ipaca/requeststate.db handle 0 a8 READ 1 HELD ipaca/notafter.db handle 0 66 READ 1 HELD changelog/parentid.db handle 0 78 READ 1 HELD userRoot/ipasudorunasgroup.db handle 0 11b READ 1 HELD userRoot/uidnumber.db handle 0 cf READ 1 HELD userRoot/userCertificate.db handle 0 8005eeef WRITE 1 HELD userRoot/objectclass.db page 7 8005eeef WRITE 1 HELD userRoot/objectclass.db page 6 f7 READ 1 WAIT userRoot/objectclass.db page 6 fd READ 1 WAIT userRoot/objectclass.db page 6 8005eeef WRITE 1 HELD userRoot/objectclass.db page 5 8005eeef WRITE 2 HELD userRoot/objectclass.db page 3 8005eeef WRITE 1 HELD userRoot/objectclass.db page 0 38 READ 1 HELD userRoot/objectclass.db handle 0 a6 READ 1 HELD ipaca/metaInfo.db handle 0 22 READ 1 HELD ipaca/vlv#capendingpkitomcatindex.db handle 0 69 READ 1 HELD userRoot/member.db handle 0 6 READ 1 HELD ipaca/entryrdn.db handle 0 81 READ 1 HELD userRoot/ipakrbprincipalalias.db handle 0 9b READ 1 HELD userRoot/ipauniqueid.db handle 0 18 READ 1 HELD ipaca/vlv#caallpkitomcatindex.db handle 0 4 READ 1 HELD ipaca/id2entry.db handle 0 21 READ 1 HELD ipaca/vlv#caenrollmentpkitomcatindex.db handle 0 6f READ 1 HELD userRoot/ipaassignedidview.db handle 0 10 READ 1 HELD ipaca/vlv#allrevokedcertspkitomcatindex.db handle 0 95 READ 1 HELD userRoot/uid.db handle 0 a1 READ 1 HELD ipaca/cn.db handle 0 a2 READ 1 HELD ipaca/ancestorid.db handle 0 74 READ 1 HELD userRoot/manager.db handle 0 7a READ 1 HELD userRoot/sourcehost.db handle 0 15 READ 1 HELD ipaca/vlv#allvalidcertspkitomcatindex.db handle 0 a3 READ 1 HELD ipaca/numsubordinates.db handle 0 47 READ 1 HELD changelog/aci.db handle 0 aa READ 1 HELD ipaca/subjectname.db handle 0 98 READ 1 HELD userRoot/fqdn.db handle 0 3c READ 1 HELD changelog/entryrdn.db handle 0 9f READ 1 HELD ipaca/dateOfCreate.db handle 0 76 READ 1 HELD userRoot/ipasudorunas.db handle 0 79 READ 1 HELD userRoot/memberHost.db handle 0 89 READ 1 HELD changelog/seeAlso.db handle 0 73 READ 1 HELD userRoot/memberallowcmd.db handle 0 16 READ 1 HELD ipaca/vlv#allvalidcertsnotafterpkitomcatindex.db handle 0 4f READ 1 HELD userRoot/parentid.db handle 0 ba READ 1 HELD userRoot/macAddress.db handle 0 -------------- next part -------------- Thread 52 (Thread 0x7f3026807700 (LWP 29934)): #0 0x00007f30369c0413 in select () from /lib64/libc.so.6 #1 0x00007f3039155099 in DS_Sleep (ticks=ticks at entry=100) at ldap/servers/slapd/util.c:1072 #2 0x00007f302b48d7e7 in deadlock_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:4296 #3 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #4 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #5 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 51 (Thread 0x7f3026006700 (LWP 29935)): #0 0x00007f30369c0413 in select () from /lib64/libc.so.6 #1 0x00007f302f5d2bad in __os_sleep (usecs=, secs=, env=0x7f303b468fc0) at ../../src/os/os_yield.c:90 #2 __os_yield (env=env at entry=0x7f303b468fc0, secs=, secs at entry=1, usecs=, usecs at entry=0) at ../../src/os/os_yield.c:48 #3 0x00007f302f5ce2b3 in __memp_sync_int (env=env at entry=0x7f303b468fc0, dbmfp=dbmfp at entry=0x0, trickle_max=trickle_max at entry=0, flags=flags at entry=4, wrote_totalp=wrote_totalp at entry=0x0, interruptedp=interruptedp at entry=0x0) at ../../src/mp/mp_sync.c:483 #4 0x00007f302f5de752 in __txn_checkpoint (env=env at entry=0x7f303b468fc0, kbytes=kbytes at entry=0, minutes=minutes at entry=0, flags=flags at entry=0) at ../../src/txn/txn_chkpt.c:242 #5 0x00007f302f5deb74 in __txn_checkpoint_pp (dbenv=, kbytes=0, minutes=0, flags=0) at ../../src/txn/txn_chkpt.c:81 #6 0x00007f302b4919c7 in checkpoint_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:4525 #7 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #8 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #9 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 50 (Thread 0x7f3025805700 (LWP 29936)): #0 0x00007f30369c0413 in select () from /lib64/libc.so.6 #1 0x00007f3039155099 in DS_Sleep (ticks=ticks at entry=250) at ldap/servers/slapd/util.c:1072 #2 0x00007f302b48da5f in trickle_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:4722 #3 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #4 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #5 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 49 (Thread 0x7f3025004700 (LWP 29937)): #0 0x00007f30369c0413 in select () from /lib64/libc.so.6 #1 0x00007f3039155099 in DS_Sleep (ticks=) at ldap/servers/slapd/util.c:1072 #2 0x00007f302b4e1684 in perfctrs_wait (milliseconds=milliseconds at entry=1000, priv=, db_env=) at ldap/servers/slapd/back-ldbm/perfctrs.c:100 #3 0x00007f302b4886d7 in perf_threadmain (param=) at ldap/servers/slapd/back-ldbm/dblayer.c:3796 #4 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #5 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 48 (Thread 0x7f301ffff700 (LWP 29938)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f61f0 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007f3039141f78 in slapi_wait_condvar (cvar=0x7f303ba89160, timeout=timeout at entry=0x0) at ldap/servers/slapd/slapi2nspr.c:150 #3 0x00007f302e1c26fe in cos_cache_wait_on_change (arg=) at ldap/servers/plugins/cos/cos_cache.c:407 #4 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #5 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 47 (Thread 0x7f3039510700 (LWP 30255)): #0 0x00007f3036c9fa82 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f5c87 in pt_TimedWait () from /lib64/libnspr4.so #2 0x00007f30372f616e in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x00007f302b1e6d34 in _cl5TrimMain (param=) at ldap/servers/plugins/replication/cl5_api.c:3440 #4 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #5 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 46 (Thread 0x7f301f7fe700 (LWP 30256)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f61f0 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007f302b1fd904 in protocol_sleep (prp=0x7f303baca3c0, duration=4294967295) at ldap/servers/plugins/replication/repl5_inc_protocol.c:1248 #3 0x00007f302b200971 in repl5_inc_run (prp=0x7f303baca3c0) at ldap/servers/plugins/replication/repl5_inc_protocol.c:885 #4 0x00007f302b2051cc in prot_thread_main (arg=0x7f303bac8be0) at ldap/servers/plugins/replication/repl5_protocol.c:267 #5 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #6 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #7 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 45 (Thread 0x7f301effd700 (LWP 30257)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f61f0 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007f302b1fd904 in protocol_sleep (prp=0x7f303bac94a0, duration=4294967295) at ldap/servers/plugins/replication/repl5_inc_protocol.c:1248 #3 0x00007f302b200971 in repl5_inc_run (prp=0x7f303bac94a0) at ldap/servers/plugins/replication/repl5_inc_protocol.c:885 #4 0x00007f302b2051cc in prot_thread_main (arg=0x7f303bac9730) at ldap/servers/plugins/replication/repl5_protocol.c:267 #5 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #6 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #7 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 44 (Thread 0x7f301e7fc700 (LWP 30258)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f61f0 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007f302b1fd904 in protocol_sleep (prp=0x7f303bacc350, duration=4294967295) at ldap/servers/plugins/replication/repl5_inc_protocol.c:1248 #3 0x00007f302b200971 in repl5_inc_run (prp=0x7f303bacc350) at ldap/servers/plugins/replication/repl5_inc_protocol.c:885 #4 0x00007f302b2051cc in prot_thread_main (arg=0x7f303baccc40) at ldap/servers/plugins/replication/repl5_protocol.c:267 #5 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #6 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #7 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 43 (Thread 0x7f301dffb700 (LWP 30259)): #0 0x00007f3036c9fa82 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f5c87 in pt_TimedWait () from /lib64/libnspr4.so #2 0x00007f30372f616e in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x00007f302b1fd904 in protocol_sleep (prp=0x7f303bad2d30, duration=300000) at ldap/servers/plugins/replication/repl5_inc_protocol.c:1248 #4 0x00007f302b20103d in repl5_inc_run (prp=0x7f303bad2d30) at ldap/servers/plugins/replication/repl5_inc_protocol.c:811 #5 0x00007f302b2051cc in prot_thread_main (arg=0x7f303bacc790) at ldap/servers/plugins/replication/repl5_protocol.c:267 #6 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #7 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #8 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 42 (Thread 0x7f301d7fa700 (LWP 30260)): #0 0x00007f3036c9fa82 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f5c87 in pt_TimedWait () from /lib64/libnspr4.so #2 0x00007f30372f616e in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x00007f302b1fd904 in protocol_sleep (prp=0x7f303bad1f40, duration=300000) at ldap/servers/plugins/replication/repl5_inc_protocol.c:1248 #4 0x00007f302b20103d in repl5_inc_run (prp=0x7f303bad1f40) at ldap/servers/plugins/replication/repl5_inc_protocol.c:811 #5 0x00007f302b2051cc in prot_thread_main (arg=0x7f303bad2130) at ldap/servers/plugins/replication/repl5_protocol.c:267 #6 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #7 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #8 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 41 (Thread 0x7f301cff9700 (LWP 30261)): #0 0x00007f3036c9fa82 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f5c87 in pt_TimedWait () from /lib64/libnspr4.so #2 0x00007f30372f616e in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x00007f302b1fd904 in protocol_sleep (prp=0x7f303bad5bf0, duration=300000) at ldap/servers/plugins/replication/repl5_inc_protocol.c:1248 #4 0x00007f302b20103d in repl5_inc_run (prp=0x7f303bad5bf0) at ldap/servers/plugins/replication/repl5_inc_protocol.c:811 #5 0x00007f302b2051cc in prot_thread_main (arg=0x7f303bad4ed0) at ldap/servers/plugins/replication/repl5_protocol.c:267 #6 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #7 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #8 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 40 (Thread 0x7f2ffffff700 (LWP 30262)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f61f0 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007f3039141f78 in slapi_wait_condvar (cvar=0x7f303ba951d0, timeout=timeout at entry=0x0) at ldap/servers/slapd/slapi2nspr.c:150 #3 0x00007f3029b29efd in roles_cache_wait_on_change (arg=0x7f303bad60f0) at ldap/servers/plugins/roles/roles_cache.c:404 #4 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #5 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 39 (Thread 0x7f2fff7fe700 (LWP 30263)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f61f0 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007f3039141f78 in slapi_wait_condvar (cvar=0x7f303bad7e10, timeout=timeout at entry=0x0) at ldap/servers/slapd/slapi2nspr.c:150 #3 0x00007f3029b29efd in roles_cache_wait_on_change (arg=0x7f303bad5fd0) at ldap/servers/plugins/roles/roles_cache.c:404 #4 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #5 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 38 (Thread 0x7f2ffeffd700 (LWP 30264)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f61f0 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007f3039141f78 in slapi_wait_condvar (cvar=0x7f303ba90670, timeout=timeout at entry=0x0) at ldap/servers/slapd/slapi2nspr.c:150 #3 0x00007f3029b29efd in roles_cache_wait_on_change (arg=0x7f303bad5f20) at ldap/servers/plugins/roles/roles_cache.c:404 #4 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #5 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 37 (Thread 0x7f2ffe7fc700 (LWP 30265)): #0 0x00007f3036c9fa82 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f5c87 in pt_TimedWait () from /lib64/libnspr4.so #2 0x00007f30372f616e in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x00007f3039601a23 in housecleaning (cur_time=) at ldap/servers/slapd/house.c:48 #4 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #5 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 36 (Thread 0x7f2ffdffb700 (LWP 30266)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ffdffa660) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2feb75f880, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=pb at entry=0x7f2feb75f880) at ldap/servers/slapd/modify.c:599 #7 0x00007f303910da63 in slapi_modify_internal_pb (pb=pb at entry=0x7f2feb75f880) at ldap/servers/slapd/modify.c:454 #8 0x00007f302b20c164 in replica_write_ruv (r=r at entry=0x7f303ba35de0) at ldap/servers/plugins/replication/repl5_replica.c:3010 #9 0x00007f302b20c3ed in replica_update_state (when=, arg=) at ldap/servers/plugins/replication/repl5_replica.c:2943 #10 0x00007f30390e4d6a in eq_call_all () at ldap/servers/slapd/eventq.c:283 #11 eq_loop (arg=) at ldap/servers/slapd/eventq.c:330 #12 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #13 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #14 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 35 (Thread 0x7f2ffd7fa700 (LWP 30267)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ffd7f8e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2f60d4abe0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2f60d4abe0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ffd7f9a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ffd7f9a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ffd7f9a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ffd7f9a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ffd7f9a90, op=0x7f303bb86850, conn=0x7f301c543298) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 34 (Thread 0x7f2ffcff9700 (LWP 30268)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f302f4a62f3 in __db_pthread_mutex_condwait (env=0x7f303b468fc0, mutex=139844794050060, timespec=0x0, mutexp=) at ../../src/mutex/mut_pthread.c:321 #2 __db_hybrid_mutex_suspend (env=env at entry=0x7f303b468fc0, mutex=mutex at entry=4235, timespec=timespec at entry=0x0, exclusive=exclusive at entry=1) at ../../src/mutex/mut_pthread.c:577 #3 0x00007f302f4a5640 in __db_tas_mutex_lock_int (nowait=0, timeout=0, mutex=, env=0x7f303b468fc0) at ../../src/mutex/mut_tas.c:271 #4 __db_tas_mutex_lock (env=env at entry=0x7f303b468fc0, mutex=4235, timeout=timeout at entry=0) at ../../src/mutex/mut_tas.c:302 #5 0x00007f302f54fd3a in __lock_get_internal (lt=lt at entry=0x7f303b69e1e0, sh_locker=sh_locker at entry=0x7f3027777ee8, flags=flags at entry=0, obj=, lock_mode=, timeout=timeout at entry=0, lock=0x7f2ffcfea700) at ../../src/lock/lock.c:983 #6 0x00007f302f550820 in __lock_get (env=env at entry=0x7f303b468fc0, locker=0x7f3027777ee8, flags=0, obj=obj at entry=0x7f2fbc018a90, lock_mode=, lock=lock at entry=0x7f2ffcfea700) at ../../src/lock/lock.c:463 #7 0x00007f302f57c142 in __db_lget (dbc=dbc at entry=0x7f2fbc0189a0, action=action at entry=0, pgno=6, mode=, mode at entry=DB_LOCK_READ, lkflags=lkflags at entry=0, lockp=lockp at entry=0x7f2ffcfea700) at ../../src/db/db_meta.c:1255 #8 0x00007f302f4c3605 in __bam_search (dbc=dbc at entry=0x7f2fbc0189a0, root_pgno=1, root_pgno at entry=0, key=key at entry=0x7f2ffcfea9e0, flags=1409, slevel=slevel at entry=1, recnop=recnop at entry=0x0, exactp=exactp at entry=0x7f2ffcfea824) at ../../src/btree/bt_search.c:723 #9 0x00007f302f4ae256 in __bamc_search (dbc=dbc at entry=0x7f2fbc0189a0, root_pgno=root_pgno at entry=0, key=0x7f2ffcfea9e0, flags=, exactp=0x7f2ffcfea824) at ../../src/btree/bt_cursor.c:2804 #10 0x00007f302f4afd0f in __bamc_get (dbc=0x7f2fbc0189a0, key=, data=, flags=, pgnop=0x7f2ffcfea8c4) at ../../src/btree/bt_cursor.c:1099 #11 0x00007f302f568ca6 in __dbc_iget (dbc=0x7f2fe0452200, key=0x7f2ffcfea9e0, data=0x7f2ffcfeaa10, flags=26) at ../../src/db/db_cam.c:952 #12 0x00007f302f56947d in __dbc_get (dbc=dbc at entry=0x7f2fe0452200, key=key at entry=0x7f2ffcfea9e0, data=data at entry=0x7f2ffcfeaa10, flags=flags at entry=2074) at ../../src/db/db_cam.c:770 #13 0x00007f302f577b02 in __dbc_get_pp (dbc=0x7f2fe0452200, key=0x7f2ffcfea9e0, data=0x7f2ffcfeaa10, flags=2074) at ../../src/db/db_iface.c:2359 #14 0x00007f302b49c8a0 in idl_new_fetch (be=0x7f303b5ac670, db=, inkey=0x7f2ffcfecb60, txn=0x0, a=0x7f303b67f4d0, flag_err=0x7f2ffcff3c8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/idl_new.c:202 #15 0x00007f302b49c525 in idl_fetch_ext (be=be at entry=0x7f303b5ac670, db=, key=key at entry=0x7f2ffcfecb60, txn=txn at entry=0x0, a=, err=err at entry=0x7f2ffcff3c8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/idl_shim.c:101 #16 0x00007f302b4ab146 in index_read_ext_allids (pb=pb at entry=0x7f2ffcff8a90, be=be at entry=0x7f303b5ac670, type=type at entry=0x7f2fd801ee90 "objectClass", indextype=indextype at entry=0x7f302b4f2c87 "eq", val=, txn=txn at entry=0x7f2ffcff0e30, err=err at entry=0x7f2ffcff3c8c, unindexed=unindexed at entry=0x7f2ffcff0e24, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/index.c:1028 #17 0x00007f302b495234 in keys2idl (pb=pb at entry=0x7f2ffcff8a90, be=be at entry=0x7f303b5ac670, type=0x7f2fd801ee90 "objectClass", indextype=indextype at entry=0x7f302b4f2c87 "eq", ivals=, err=err at entry=0x7f2ffcff3c8c, unindexed=unindexed at entry=0x7f2ffcff0e24, txn=txn at entry=0x7f2ffcff0e30, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:986 #18 0x00007f302b4959d3 in ava_candidates (pb=pb at entry=0x7f2ffcff8a90, be=be at entry=0x7f303b5ac670, f=f at entry=0x7f2fd8e6eb10, ftype=, err=0x7f2ffcff3c8c, allidslimit=100000, range=0, nextf=0x0) at ldap/servers/slapd/back-ldbm/filterindex.c:288 #19 0x00007f302b495fc2 in filter_candidates_ext (pb=pb at entry=0x7f2ffcff8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fd974c7e0 "dc=prodgdc,dc=com", f=f at entry=0x7f2fd8e6eb10, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ffcff3c8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:111 #20 0x00007f302b497086 in list_candidates (pb=pb at entry=0x7f2ffcff8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fd974c7e0 "dc=prodgdc,dc=com", flist=flist at entry=0x7f2fd9e39970, ftype=, err=0x7f2ffcff3c8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:817 #21 0x00007f302b495f30 in filter_candidates_ext (pb=pb at entry=0x7f2ffcff8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fd974c7e0 "dc=prodgdc,dc=com", f=f at entry=0x7f2fd9e39970, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ffcff3c8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:144 #22 0x00007f302b497086 in list_candidates (pb=pb at entry=0x7f2ffcff8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fd974c7e0 "dc=prodgdc,dc=com", flist=flist at entry=0x7f2fd8b49400, ftype=, err=0x7f2ffcff3c8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:817 #23 0x00007f302b495f30 in filter_candidates_ext (pb=pb at entry=0x7f2ffcff8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fd974c7e0 "dc=prodgdc,dc=com", f=f at entry=0x7f2fd8b49400, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ffcff3c8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:144 #24 0x00007f302b497086 in list_candidates (pb=pb at entry=0x7f2ffcff8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fd974c7e0 "dc=prodgdc,dc=com", flist=flist at entry=0x7f2fd9d3b600, ftype=, err=0x7f2ffcff3c8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:817 #25 0x00007f302b495f30 in filter_candidates_ext (pb=pb at entry=0x7f2ffcff8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fd974c7e0 "dc=prodgdc,dc=com", f=0x7f2fd9d3b600, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ffcff3c8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:144 #26 0x00007f302b4d24b8 in subtree_candidates (pb=pb at entry=0x7f2ffcff8a90, be=0x7f303b5ac670, base=base at entry=0x7f2fd974c7e0 "dc=prodgdc,dc=com", e=e at entry=0x7f2fc6e36960, filter=0x7f2fd8b49400, managedsait=0, allids_before_scopingp=allids_before_scopingp at entry=0x7f2ffcff3c7c, err=err at entry=0x7f2ffcff3c8c) at ldap/servers/slapd/back-ldbm/ldbm_search.c:1210 #27 0x00007f302b4d3b9f in build_candidate_list (candidates=0x7f2ffcff3cb8, lookup_returned_allidsp=0x7f2ffcff3c7c, scope=, base=0x7f2fd974c7e0 "dc=prodgdc,dc=com", e=, be=, pb=0x7f2ffcff8a90) at ldap/servers/slapd/back-ldbm/ldbm_search.c:1015 #28 ldbm_back_search (pb=0x7f2ffcff8a90) at ldap/servers/slapd/back-ldbm/ldbm_search.c:657 #29 0x00007f3039113216 in op_shared_search (pb=pb at entry=0x7f2ffcff8a90, send_result=send_result at entry=1) at ldap/servers/slapd/opshared.c:806 #30 0x00007f303960b12e in do_search (pb=pb at entry=0x7f2ffcff8a90) at ldap/servers/slapd/search.c:349 #31 0x00007f30395f8a83 in connection_dispatch_operation (pb=0x7f2ffcff8a90, op=0x7f303c153300, conn=0x7f301c530f80) at ldap/servers/slapd/connection.c:651 #32 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #33 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #34 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #35 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 33 (Thread 0x7f2ffc7f8700 (LWP 30269)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ffc7f6e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fdc5ad300, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fdc5ad300) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ffc7f7a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ffc7f7a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ffc7f7a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ffc7f7a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ffc7f7a90, op=0x7f303bb7fcf0, conn=0x7f301c532e70) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 32 (Thread 0x7f2ffbff7700 (LWP 30270)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ffbff5e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fd29c1d60, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fd29c1d60) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ffbff6a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ffbff6a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ffbff6a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ffbff6a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ffbff6a90, op=0x7f303e94fde0, conn=0x7f301c544210) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 31 (Thread 0x7f2ffb7f6700 (LWP 30271)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ffb7f4e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2f5906eb30, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2f5906eb30) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ffb7f5a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ffb7f5a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ffb7f5a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ffb7f5a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ffb7f5a90, op=0x7f303d6a53f0, conn=0x7f301c537088) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 30 (Thread 0x7f2ffaff5700 (LWP 30272)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f302f4a62f3 in __db_pthread_mutex_condwait (env=0x7f303b468fc0, mutex=0, timespec=0x0, mutexp=) at ../../src/mutex/mut_pthread.c:321 #2 __db_hybrid_mutex_suspend (env=env at entry=0x7f303b468fc0, mutex=mutex at entry=3234, timespec=timespec at entry=0x0, exclusive=exclusive at entry=0) at ../../src/mutex/mut_pthread.c:577 #3 0x00007f302f4a5b37 in __db_tas_mutex_readlock_int (nowait=0, mutex=, env=0x7f303b468fc0) at ../../src/mutex/mut_tas.c:438 #4 __db_tas_mutex_readlock (env=env at entry=0x7f303b468fc0, mutex=3234) at ../../src/mutex/mut_tas.c:472 #5 0x00007f302f5bfd35 in __memp_fget (dbmfp=dbmfp at entry=0x7f303b472510, pgnoaddr=pgnoaddr at entry=0x7f303b78aaa0, ip=0x0, txn=0x0, flags=flags at entry=0, addrp=addrp at entry=0x7f303b78aa90) at ../../src/mp/mp_fget.c:317 #6 0x00007f302f569333 in __dbc_iget (dbc=0x7f2fd86684f0, key=0x7f2ffafe69e0, data=, flags=17) at ../../src/db/db_cam.c:1050 #7 0x00007f302f56947d in __dbc_get (dbc=dbc at entry=0x7f2fd86684f0, key=key at entry=0x7f2ffafe69e0, data=data at entry=0x7f2ffafe6a10, flags=flags at entry=2065) at ../../src/db/db_cam.c:770 #8 0x00007f302f577b02 in __dbc_get_pp (dbc=0x7f2fd86684f0, key=0x7f2ffafe69e0, data=0x7f2ffafe6a10, flags=2065) at ../../src/db/db_iface.c:2359 #9 0x00007f302b49ca42 in idl_new_fetch (be=0x7f303b5ac670, db=, inkey=, txn=, a=0x7f303b67f4d0, flag_err=0x7f2ffafefc8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/idl_new.c:280 #10 0x00007f302b49c525 in idl_fetch_ext (be=be at entry=0x7f303b5ac670, db=, key=key at entry=0x7f2ffafe8b60, txn=txn at entry=0x0, a=, err=err at entry=0x7f2ffafefc8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/idl_shim.c:101 #11 0x00007f302b4ab146 in index_read_ext_allids (pb=pb at entry=0x7f2ffaff4a90, be=be at entry=0x7f303b5ac670, type=type at entry=0x7f2f8cac87e0 "objectClass", indextype=indextype at entry=0x7f302b4f2c87 "eq", val=, txn=txn at entry=0x7f2ffafece30, err=err at entry=0x7f2ffafefc8c, unindexed=unindexed at entry=0x7f2ffafece24, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/index.c:1028 #12 0x00007f302b495234 in keys2idl (pb=pb at entry=0x7f2ffaff4a90, be=be at entry=0x7f303b5ac670, type=0x7f2f8cac87e0 "objectClass", indextype=indextype at entry=0x7f302b4f2c87 "eq", ivals=, err=err at entry=0x7f2ffafefc8c, unindexed=unindexed at entry=0x7f2ffafece24, txn=txn at entry=0x7f2ffafece30, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:986 #13 0x00007f302b4959d3 in ava_candidates (pb=pb at entry=0x7f2ffaff4a90, be=be at entry=0x7f303b5ac670, f=f at entry=0x7f2f8d0f4740, ftype=, err=0x7f2ffafefc8c, allidslimit=100000, range=0, nextf=0x0) at ldap/servers/slapd/back-ldbm/filterindex.c:288 #14 0x00007f302b495fc2 in filter_candidates_ext (pb=pb at entry=0x7f2ffaff4a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2f8ccf7670 "dc=prodgdc,dc=com", f=f at entry=0x7f2f8d0f4740, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ffafefc8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:111 #15 0x00007f302b497086 in list_candidates (pb=pb at entry=0x7f2ffaff4a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2f8ccf7670 "dc=prodgdc,dc=com", flist=flist at entry=0x7f2f8f01b670, ftype=, err=0x7f2ffafefc8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:817 #16 0x00007f302b495f30 in filter_candidates_ext (pb=pb at entry=0x7f2ffaff4a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2f8ccf7670 "dc=prodgdc,dc=com", f=f at entry=0x7f2f8f01b670, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ffafefc8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:144 #17 0x00007f302b497086 in list_candidates (pb=pb at entry=0x7f2ffaff4a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2f8ccf7670 "dc=prodgdc,dc=com", flist=flist at entry=0x7f2fc88969a0, ftype=, err=0x7f2ffafefc8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:817 #18 0x00007f302b495f30 in filter_candidates_ext (pb=pb at entry=0x7f2ffaff4a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2f8ccf7670 "dc=prodgdc,dc=com", f=f at entry=0x7f2fc88969a0, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ffafefc8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:144 #19 0x00007f302b497086 in list_candidates (pb=pb at entry=0x7f2ffaff4a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2f8ccf7670 "dc=prodgdc,dc=com", flist=flist at entry=0x7f2f8ea71a00, ftype=, err=0x7f2ffafefc8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:817 #20 0x00007f302b495f30 in filter_candidates_ext (pb=pb at entry=0x7f2ffaff4a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2f8ccf7670 "dc=prodgdc,dc=com", f=0x7f2f8ea71a00, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ffafefc8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:144 #21 0x00007f302b4d24b8 in subtree_candidates (pb=pb at entry=0x7f2ffaff4a90, be=0x7f303b5ac670, base=base at entry=0x7f2f8ccf7670 "dc=prodgdc,dc=com", e=e at entry=0x7f2fc6e36960, filter=0x7f2fc88969a0, managedsait=0, allids_before_scopingp=allids_before_scopingp at entry=0x7f2ffafefc7c, err=err at entry=0x7f2ffafefc8c) at ldap/servers/slapd/back-ldbm/ldbm_search.c:1210 #22 0x00007f302b4d3b9f in build_candidate_list (candidates=0x7f2ffafefcb8, lookup_returned_allidsp=0x7f2ffafefc7c, scope=, base=0x7f2f8ccf7670 "dc=prodgdc,dc=com", e=, be=, pb=0x7f2ffaff4a90) at ldap/servers/slapd/back-ldbm/ldbm_search.c:1015 #23 ldbm_back_search (pb=0x7f2ffaff4a90) at ldap/servers/slapd/back-ldbm/ldbm_search.c:657 #24 0x00007f3039113216 in op_shared_search (pb=pb at entry=0x7f2ffaff4a90, send_result=send_result at entry=1) at ldap/servers/slapd/opshared.c:806 #25 0x00007f303960b12e in do_search (pb=pb at entry=0x7f2ffaff4a90) at ldap/servers/slapd/search.c:349 #26 0x00007f30395f8a83 in connection_dispatch_operation (pb=0x7f2ffaff4a90, op=0x7f303c0d6850, conn=0x7f301c531958) at ldap/servers/slapd/connection.c:651 #27 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #28 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #29 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #30 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 29 (Thread 0x7f2ffa7f4700 (LWP 30273)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ffa7f2e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2f715028b0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2f715028b0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ffa7f3a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ffa7f3a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ffa7f3a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ffa7f3a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ffa7f3a90, op=0x7f3040377280, conn=0x7f301c5425f0) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 28 (Thread 0x7f2ff9ff3700 (LWP 30274)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff9ff1e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fc1282e10, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fc1282e10) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff9ff2a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff9ff2a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff9ff2a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff9ff2a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff9ff2a90, op=0x7f303ba64aa0, conn=0x7f301c5439a0) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 27 (Thread 0x7f2ff97f2700 (LWP 30275)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff97f0e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fc4ef04c0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fc4ef04c0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff97f1a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff97f1a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff97f1a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff97f1a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff97f1a90, op=0x7f303e240f60, conn=0x7f301c543dd8) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 26 (Thread 0x7f2ff8ff1700 (LWP 30276)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff8fefe30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fb8ea3e10, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fb8ea3e10) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff8ff0a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff8ff0a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff8ff0a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff8ff0a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff8ff0a90, op=0x7f30402eac90, conn=0x7f301c5428c0) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 25 (Thread 0x7f2ff87f0700 (LWP 30277)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff87eee30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fbed859b0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fbed859b0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff87efa90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff87efa90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff87efa90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff87efa90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff87efa90, op=0x7f3040160820, conn=0x7f301c537e98) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 24 (Thread 0x7f2ff7fef700 (LWP 30278)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff7fede30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2f7d710ea0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2f7d710ea0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff7feea90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff7feea90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff7feea90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff7feea90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff7feea90, op=0x7f303efe7a70, conn=0x7f301c536f20) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 23 (Thread 0x7f2ff77ee700 (LWP 30279)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff77ece30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fb5044880, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fb5044880) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff77eda90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff77eda90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff77eda90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff77eda90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff77eda90, op=0x7f303bab4980, conn=0x7f301c536db8) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 22 (Thread 0x7f2ff6fed700 (LWP 30280)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff6febe30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f303ff96ac0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f303ff96ac0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff6feca90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff6feca90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff6feca90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff6feca90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff6feca90, op=0x7f303bac0110, conn=0x7f301c543130) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 21 (Thread 0x7f2ff67ec700 (LWP 30281)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff67eae30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fb52fe770, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fb52fe770) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff67eba90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff67eba90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff67eba90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff67eba90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff67eba90, op=0x7f303c17bd40, conn=0x7f301c542cf8) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 20 (Thread 0x7f2ff5feb700 (LWP 30282)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff5fe9e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fb2ae18a0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fb2ae18a0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff5feaa90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff5feaa90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff5feaa90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff5feaa90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff5feaa90, op=0x7f303b780770, conn=0x7f301c547780) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 19 (Thread 0x7f2ff57ea700 (LWP 30283)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff57e8e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fbbff6730, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fbbff6730) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff57e9a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff57e9a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff57e9a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff57e9a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff57e9a90, op=0x7f303c0a6010, conn=0x7f301c542b90) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 18 (Thread 0x7f2ff4fe9700 (LWP 30284)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f302f4a62f3 in __db_pthread_mutex_condwait (env=0x7f303b468fc0, mutex=658892300, timespec=0x0, mutexp=) at ../../src/mutex/mut_pthread.c:321 #2 __db_hybrid_mutex_suspend (env=env at entry=0x7f303b468fc0, mutex=mutex at entry=4241, timespec=timespec at entry=0x0, exclusive=exclusive at entry=1) at ../../src/mutex/mut_pthread.c:577 #3 0x00007f302f4a5640 in __db_tas_mutex_lock_int (nowait=0, timeout=0, mutex=, env=0x7f303b468fc0) at ../../src/mutex/mut_tas.c:271 #4 __db_tas_mutex_lock (env=env at entry=0x7f303b468fc0, mutex=4241, timeout=timeout at entry=0) at ../../src/mutex/mut_tas.c:302 #5 0x00007f302f54fd3a in __lock_get_internal (lt=lt at entry=0x7f303b69e1e0, sh_locker=sh_locker at entry=0x7f3027780640, flags=flags at entry=0, obj=, lock_mode=, timeout=timeout at entry=0, lock=0x7f2ff4fda700) at ../../src/lock/lock.c:983 #6 0x00007f302f550820 in __lock_get (env=env at entry=0x7f303b468fc0, locker=0x7f3027780640, flags=0, obj=obj at entry=0x7f2fb08ba8d0, lock_mode=, lock=lock at entry=0x7f2ff4fda700) at ../../src/lock/lock.c:463 #7 0x00007f302f57c142 in __db_lget (dbc=dbc at entry=0x7f2fb08ba7e0, action=action at entry=0, pgno=6, mode=, mode at entry=DB_LOCK_READ, lkflags=lkflags at entry=0, lockp=lockp at entry=0x7f2ff4fda700) at ../../src/db/db_meta.c:1255 #8 0x00007f302f4c3605 in __bam_search (dbc=dbc at entry=0x7f2fb08ba7e0, root_pgno=1, root_pgno at entry=0, key=key at entry=0x7f2ff4fda9e0, flags=1409, slevel=slevel at entry=1, recnop=recnop at entry=0x0, exactp=exactp at entry=0x7f2ff4fda824) at ../../src/btree/bt_search.c:723 #9 0x00007f302f4ae256 in __bamc_search (dbc=dbc at entry=0x7f2fb08ba7e0, root_pgno=root_pgno at entry=0, key=0x7f2ff4fda9e0, flags=, exactp=0x7f2ff4fda824) at ../../src/btree/bt_cursor.c:2804 #10 0x00007f302f4afd0f in __bamc_get (dbc=0x7f2fb08ba7e0, key=, data=, flags=, pgnop=0x7f2ff4fda8c4) at ../../src/btree/bt_cursor.c:1099 #11 0x00007f302f568ca6 in __dbc_iget (dbc=0x7f2fb4b32410, key=0x7f2ff4fda9e0, data=0x7f2ff4fdaa10, flags=26) at ../../src/db/db_cam.c:952 #12 0x00007f302f56947d in __dbc_get (dbc=dbc at entry=0x7f2fb4b32410, key=key at entry=0x7f2ff4fda9e0, data=data at entry=0x7f2ff4fdaa10, flags=flags at entry=2074) at ../../src/db/db_cam.c:770 #13 0x00007f302f577b02 in __dbc_get_pp (dbc=0x7f2fb4b32410, key=0x7f2ff4fda9e0, data=0x7f2ff4fdaa10, flags=2074) at ../../src/db/db_iface.c:2359 #14 0x00007f302b49c8a0 in idl_new_fetch (be=0x7f303b5ac670, db=, inkey=0x7f2ff4fdcb60, txn=0x0, a=0x7f303b67f4d0, flag_err=0x7f2ff4fe3c8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/idl_new.c:202 #15 0x00007f302b49c525 in idl_fetch_ext (be=be at entry=0x7f303b5ac670, db=, key=key at entry=0x7f2ff4fdcb60, txn=txn at entry=0x0, a=, err=err at entry=0x7f2ff4fe3c8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/idl_shim.c:101 #16 0x00007f302b4ab146 in index_read_ext_allids (pb=pb at entry=0x7f2ff4fe8a90, be=be at entry=0x7f303b5ac670, type=type at entry=0x7f2fc6acb540 "objectClass", indextype=indextype at entry=0x7f302b4f2c87 "eq", val=, txn=txn at entry=0x7f2ff4fe0e30, err=err at entry=0x7f2ff4fe3c8c, unindexed=unindexed at entry=0x7f2ff4fe0e24, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/index.c:1028 #17 0x00007f302b495234 in keys2idl (pb=pb at entry=0x7f2ff4fe8a90, be=be at entry=0x7f303b5ac670, type=0x7f2fc6acb540 "objectClass", indextype=indextype at entry=0x7f302b4f2c87 "eq", ivals=, err=err at entry=0x7f2ff4fe3c8c, unindexed=unindexed at entry=0x7f2ff4fe0e24, txn=txn at entry=0x7f2ff4fe0e30, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:986 #18 0x00007f302b4959d3 in ava_candidates (pb=pb at entry=0x7f2ff4fe8a90, be=be at entry=0x7f303b5ac670, f=f at entry=0x7f2fc56c8930, ftype=, err=0x7f2ff4fe3c8c, allidslimit=100000, range=0, nextf=0x0) at ldap/servers/slapd/back-ldbm/filterindex.c:288 #19 0x00007f302b495fc2 in filter_candidates_ext (pb=pb at entry=0x7f2ff4fe8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fc6ae29e0 "dc=prodgdc,dc=com", f=f at entry=0x7f2fc56c8930, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ff4fe3c8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:111 #20 0x00007f302b497086 in list_candidates (pb=pb at entry=0x7f2ff4fe8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fc6ae29e0 "dc=prodgdc,dc=com", flist=flist at entry=0x7f2fc6d9b7f0, ftype=, err=0x7f2ff4fe3c8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:817 #21 0x00007f302b495f30 in filter_candidates_ext (pb=pb at entry=0x7f2ff4fe8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fc6ae29e0 "dc=prodgdc,dc=com", f=f at entry=0x7f2fc6d9b7f0, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ff4fe3c8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:144 #22 0x00007f302b497086 in list_candidates (pb=pb at entry=0x7f2ff4fe8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fc6ae29e0 "dc=prodgdc,dc=com", flist=flist at entry=0x7f2fc6e6ead0, ftype=, err=0x7f2ff4fe3c8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:817 #23 0x00007f302b495f30 in filter_candidates_ext (pb=pb at entry=0x7f2ff4fe8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fc6ae29e0 "dc=prodgdc,dc=com", f=f at entry=0x7f2fc6e6ead0, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ff4fe3c8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:144 #24 0x00007f302b497086 in list_candidates (pb=pb at entry=0x7f2ff4fe8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fc6ae29e0 "dc=prodgdc,dc=com", flist=flist at entry=0x7f2fc6e85bb0, ftype=, err=0x7f2ff4fe3c8c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:817 #25 0x00007f302b495f30 in filter_candidates_ext (pb=pb at entry=0x7f2ff4fe8a90, be=be at entry=0x7f303b5ac670, base=base at entry=0x7f2fc6ae29e0 "dc=prodgdc,dc=com", f=0x7f2fc6e85bb0, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f2ff4fe3c8c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:144 #26 0x00007f302b4d24b8 in subtree_candidates (pb=pb at entry=0x7f2ff4fe8a90, be=0x7f303b5ac670, base=base at entry=0x7f2fc6ae29e0 "dc=prodgdc,dc=com", e=e at entry=0x7f2fc6e36960, filter=0x7f2fc6e6ead0, managedsait=0, allids_before_scopingp=allids_before_scopingp at entry=0x7f2ff4fe3c7c, err=err at entry=0x7f2ff4fe3c8c) at ldap/servers/slapd/back-ldbm/ldbm_search.c:1210 #27 0x00007f302b4d3b9f in build_candidate_list (candidates=0x7f2ff4fe3cb8, lookup_returned_allidsp=0x7f2ff4fe3c7c, scope=, base=0x7f2fc6ae29e0 "dc=prodgdc,dc=com", e=, be=, pb=0x7f2ff4fe8a90) at ldap/servers/slapd/back-ldbm/ldbm_search.c:1015 #28 ldbm_back_search (pb=0x7f2ff4fe8a90) at ldap/servers/slapd/back-ldbm/ldbm_search.c:657 #29 0x00007f3039113216 in op_shared_search (pb=pb at entry=0x7f2ff4fe8a90, send_result=send_result at entry=1) at ldap/servers/slapd/opshared.c:806 #30 0x00007f303960b12e in do_search (pb=pb at entry=0x7f2ff4fe8a90) at ldap/servers/slapd/search.c:349 #31 0x00007f30395f8a83 in connection_dispatch_operation (pb=0x7f2ff4fe8a90, op=0x7f304033ce80, conn=0x7f301c531c28) at ldap/servers/slapd/connection.c:651 #32 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #33 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #34 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #35 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x7f2ff47e8700 (LWP 30285)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff47e6e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fc189f460, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fc189f460) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff47e7a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff47e7a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff47e7a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff47e7a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff47e7a90, op=0x7f303e24c050, conn=0x7f301c544648) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x7f2ff3fe7700 (LWP 30286)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff3fe5e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2f7017c920, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2f7017c920) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff3fe6a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff3fe6a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff3fe6a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff3fe6a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff3fe6a90, op=0x7f303ba4d660, conn=0x7f301c542e60) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x7f2ff37e6700 (LWP 30287)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f302f4a62f3 in __db_pthread_mutex_condwait (env=0x7f303b468fc0, mutex=139843925320352, timespec=0x0, mutexp=) at ../../src/mutex/mut_pthread.c:321 #2 __db_hybrid_mutex_suspend (env=env at entry=0x7f303b468fc0, mutex=mutex at entry=3304, timespec=timespec at entry=0x0, exclusive=exclusive at entry=1) at ../../src/mutex/mut_pthread.c:577 #3 0x00007f302f4a5640 in __db_tas_mutex_lock_int (nowait=0, timeout=0, mutex=, env=0x7f303b468fc0) at ../../src/mutex/mut_tas.c:271 #4 __db_tas_mutex_lock (env=env at entry=0x7f303b468fc0, mutex=3304, timeout=timeout at entry=0) at ../../src/mutex/mut_tas.c:302 #5 0x00007f302f5bfe1b in __memp_fget (dbmfp=dbmfp at entry=0x7f303b472510, pgnoaddr=pgnoaddr at entry=0x7f2ff37e25bc, ip=0x0, txn=0x7f2f8ede8050, flags=0, flags at entry=2, addrp=addrp at entry=0x7f2ff37e25c8) at ../../src/mp/mp_fget.c:311 #6 0x00007f302f4c3211 in __bam_search (dbc=dbc at entry=0x7f2fcc683b90, root_pgno=root_pgno at entry=17, key=key at entry=0x7f2ff37e2990, flags=12802, slevel=slevel at entry=1, recnop=recnop at entry=0x0, exactp=exactp at entry=0x7f2ff37e277c) at ../../src/btree/bt_search.c:806 #7 0x00007f302f4ae256 in __bamc_search (dbc=dbc at entry=0x7f2fcc683b90, root_pgno=17, key=key at entry=0x7f2ff37e2990, flags=flags at entry=19, exactp=exactp at entry=0x7f2ff37e277c) at ../../src/btree/bt_cursor.c:2804 #8 0x00007f302f4b26c4 in __bamc_put (dbc=0x7f2fcc683b90, key=0x7f2ff37e2a70, data=0x7f2ff37e2990, flags=19, pgnop=0x0) at ../../src/btree/bt_cursor.c:2114 #9 0x00007f302f5696d5 in __dbc_iput (dbc=0x7f2fcc684e20, key=0x7f2ff37e2a70, data=0x7f2ff37e2990, flags=19) at ../../src/db/db_cam.c:2155 #10 0x00007f302f56b6cd in __dbc_put (dbc=, key=key at entry=0x7f2ff37e2a70, data=data at entry=0x7f2ff37e2990, flags=, flags at entry=19) at ../../src/db/db_cam.c:2049 #11 0x00007f302f564a0e in __db_put (dbp=dbp at entry=0x7f303b78a290, ip=, txn=, key=key at entry=0x7f2ff37e2a70, data=data at entry=0x7f2ff37e2990, flags=flags at entry=19) at ../../src/db/db_am.c:583 #12 0x00007f302f579fa4 in __db_put_pp (dbp=0x7f303b78a290, txn=0x7f2f8ede8050, key=0x7f2ff37e2a70, data=0x7f2ff37e2990, flags=) at ../../src/db/db_iface.c:1661 #13 0x00007f302b49d9df in idl_new_insert_key (be=, db=, key=, id=10860, txn=, a=, disposition=0x0) at ldap/servers/slapd/back-ldbm/idl_new.c:864 #14 0x00007f302b49c575 in idl_insert_key (be=be at entry=0x7f303b5ac670, db=db at entry=0x7f303b78a290, key=key at entry=0x7f2ff37e2a70, id=id at entry=10860, txn=txn at entry=0x7f2f8ede8050, a=a at entry=0x7f303b67f4d0, disposition=disposition at entry=0x0) at ldap/servers/slapd/back-ldbm/idl_shim.c:115 #15 0x00007f302b4acc65 in addordel_values_sv (be=be at entry=0x7f303b5ac670, db=0x7f303b78a290, indextype=, vals=, id=id at entry=10860, flags=flags at entry=1, txn=txn at entry=0x7f2ff37e5190, a=0x7f303b67f4d0, idl_disposition=idl_disposition at entry=0x0, buffer_handle=buffer_handle at entry=0x0, type=) at ldap/servers/slapd/back-ldbm/index.c:1932 #16 0x00007f302b4ad90a in index_addordel_values_ext_sv (be=be at entry=0x7f303b5ac670, type=, vals=0x7f2fc8896a60, evals=evals at entry=0x0, id=10860, flags=flags at entry=1, txn=txn at entry=0x7f2ff37e5190, idl_disposition=idl_disposition at entry=0x0, buffer_handle=buffer_handle at entry=0x0) at ldap/servers/slapd/back-ldbm/index.c:2069 #17 0x00007f302b4add44 in index_addordel_values_sv (be=be at entry=0x7f303b5ac670, type=, vals=, evals=evals at entry=0x0, id=, flags=flags at entry=1, txn=txn at entry=0x7f2ff37e5190) at ldap/servers/slapd/back-ldbm/index.c:1991 #18 0x00007f302b4ade0a in index_addordel_entry (be=0x7f303b5ac670, e=0x7f2f8cfa3c60, flags=flags at entry=1, txn=0x7f2ff37e5190) at ldap/servers/slapd/back-ldbm/index.c:445 #19 0x00007f302b4b0cca in ldbm_back_add (pb=0x7f2ff37e5a90) at ldap/servers/slapd/back-ldbm/ldbm_add.c:986 #20 0x00007f30390c2ee8 in op_shared_add (pb=pb at entry=0x7f2ff37e5a90) at ldap/servers/slapd/add.c:699 #21 0x00007f30390c41b0 in do_add (pb=pb at entry=0x7f2ff37e5a90) at ldap/servers/slapd/add.c:226 #22 0x00007f30395f89c3 in connection_dispatch_operation (pb=0x7f2ff37e5a90, op=0x7f303f4013f0, conn=0x7f301c5578d8) at ldap/servers/slapd/connection.c:612 #23 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #24 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #25 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #26 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x7f2ff2fe5700 (LWP 30288)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff2fe3e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fd64a08c0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fd64a08c0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff2fe4a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff2fe4a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff2fe4a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff2fe4a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff2fe4a90, op=0x7f30414a7020, conn=0x7f301c5444e0) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x7f2ff27e4700 (LWP 30289)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff27e2e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fd38d9a10, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fd38d9a10) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff27e3a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff27e3a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff27e3a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff27e3a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff27e3a90, op=0x7f303d680630, conn=0x7f301c541d80) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x7f2ff1fe3700 (LWP 30290)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff1fe1e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2f8448f820, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2f8448f820) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff1fe2a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff1fe2a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff1fe2a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff1fe2a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff1fe2a90, op=0x7f3041592570, conn=0x7f301c5440a8) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x7f2ff17e2700 (LWP 30291)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff17e0e30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fd801bd50, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fd801bd50) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff17e1a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff17e1a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff17e1a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff17e1a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff17e1a90, op=0x7f303ba44b90, conn=0x7f301c53bb10) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x7f2ff0fe1700 (LWP 30292)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff0fdfe30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f30002eb6f0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f30002eb6f0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff0fe0a90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff0fe0a90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff0fe0a90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff0fe0a90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff0fe0a90, op=0x7f303c091310, conn=0x7f301c543f40) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x7f2ff07e0700 (LWP 30293)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2ff07dee30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fe59d4df0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fe59d4df0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2ff07dfa90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2ff07dfa90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2ff07dfa90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2ff07dfa90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2ff07dfa90, op=0x7f303b8d2270, conn=0x7f301c53b9a8) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x7f2feffdf700 (LWP 30294)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2feffdde30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2f604c7110, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2f604c7110) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2feffdea90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2feffdea90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2feffdea90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2feffdea90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2feffdea90, op=0x7f303c0c60e0, conn=0x7f301c542758) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x7f2fef7de700 (LWP 30295)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2fef7dce30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f2fe9efc4a0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f2fe9efc4a0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2fef7dda90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2fef7dda90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2fef7dda90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2fef7dda90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2fef7dda90, op=0x7f303c12f110, conn=0x7f301c542320) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x7f2feefdd700 (LWP 30296)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f6463 in PR_EnterMonitor () from /lib64/libnspr4.so #2 0x00007f302b48b212 in dblayer_lock_backend (be=) at ldap/servers/slapd/back-ldbm/dblayer.c:3734 #3 0x00007f302b4902c6 in dblayer_txn_begin (be=0x7f303b5ac670, parent_txn=0x0, txn=txn at entry=0x7f2feefdbe30) at ldap/servers/slapd/back-ldbm/dblayer.c:3453 #4 0x00007f302b4ccc6c in ldbm_back_modify (pb=) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:538 #5 0x00007f303910c42b in op_shared_modify (pb=pb at entry=0x7f30055075e0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1055 #6 0x00007f303910cf64 in modify_internal_pb (pb=0x7f30055075e0) at ldap/servers/slapd/modify.c:599 #7 0x00007f302d17fbbb in ipalockout_postop () from /usr/lib64/dirsrv/plugins/libipa_lockout.so #8 0x00007f303911ec88 in plugin_call_func (list=0x7f303b36d480, operation=operation at entry=501, pb=pb at entry=0x7f2feefdca90, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:2049 #9 0x00007f303911ef13 in plugin_call_list (pb=0x7f2feefdca90, operation=501, list=) at ldap/servers/slapd/plugin.c:1993 #10 plugin_call_plugins (pb=pb at entry=0x7f2feefdca90, whichfunction=whichfunction at entry=501) at ldap/servers/slapd/plugin.c:445 #11 0x00007f30395f1af8 in do_bind (pb=pb at entry=0x7f2feefdca90) at ldap/servers/slapd/bind.c:392 #12 0x00007f30395f8abd in connection_dispatch_operation (pb=0x7f2feefdca90, op=0x7f3041366230, conn=0x7f301c537790) at ldap/servers/slapd/connection.c:602 #13 connection_threadmain () at ldap/servers/slapd/connection.c:1759 #14 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #15 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #16 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7f2fee7dc700 (LWP 30297)): #0 0x00007f30369c0413 in select () from /lib64/libc.so.6 #1 0x00007f3039155099 in DS_Sleep (ticks=ticks at entry=1000) at ldap/servers/slapd/util.c:1072 #2 0x00007f30395f99e5 in time_thread (nothing=) at ldap/servers/slapd/daemon.c:277 #3 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #4 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #5 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f2faeffe700 (LWP 30301)): #0 0x00007f3036c9f6d5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f61f0 in PR_WaitCondVar () from /lib64/libnspr4.so #2 0x00007f3039605c45 in ps_send_results (arg=) at ldap/servers/slapd/psearch.c:302 #3 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #4 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #5 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f2fac7fa700 (LWP 30467)): #0 0x00007f3036c9fa82 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f5c87 in pt_TimedWait () from /lib64/libnspr4.so #2 0x00007f30372f616e in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x00007f302dfb741c in sync_send_results (arg=) at ldap/servers/plugins/sync/sync_persist.c:578 #4 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #5 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f2facffb700 (LWP 25180)): #0 0x00007f3036c9fa82 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007f30372f5c87 in pt_TimedWait () from /lib64/libnspr4.so #2 0x00007f30372f616e in PR_WaitCondVar () from /lib64/libnspr4.so #3 0x00007f302dfb741c in sync_send_results (arg=) at ldap/servers/plugins/sync/sync_persist.c:578 #4 0x00007f30372fb96b in _pt_root () from /lib64/libnspr4.so #5 0x00007f3036c9bdc5 in start_thread () from /lib64/libpthread.so.0 #6 0x00007f30369c8ced in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f3039592880 (LWP 29929)): #0 0x00007f30369be69d in poll () from /lib64/libc.so.6 #1 0x00007f30372f7b17 in _pr_poll_with_poll () from /lib64/libnspr4.so #2 0x00007f30395fd799 in slapd_daemon (ports=ports at entry=0x7ffd4927b750) at ldap/servers/slapd/daemon.c:1242 #3 0x00007f30395ef253 in main (argc=5, argv=0x7ffd4927bd88) at ldap/servers/slapd/main.c:1143 From freeipa-users at redhat.com Tue Dec 6 16:45:18 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 06 Dec 2016 11:45:18 -0500 Subject: [Freeipa-users] IPA versions for small scale hope-to-be-production use on CentOS 7? In-Reply-To: <20161206161400.GE22795@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <5846DF60.9090802@sonsorol.org> <20161206161400.GE22795@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <5846EB1E.2090608@sonsorol.org> It's certainly some sort of TGT ticket issue; I just need to find the proper bits of log to sanitize and post back to this list. I'll do that under another thread though to keep this one clean. Trying to figure out if upgrading to 4.3 or even 4.4 would be "wise" on a CentOS-7 system we hope to put into production once the password checking problem is resolved for SSH users. List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: > In the latter case it might be some general issue with password > authentication and the krb5_child.log file with debug_level=10 in the > [domain/...] section of sssd.conf might help to find the reason (maybe > ticket validation?). From freeipa-users at redhat.com Tue Dec 6 17:11:46 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 18:11:46 +0100 Subject: [Freeipa-users] IPA versions for small scale hope-to-be-production use on CentOS 7? In-Reply-To: <5846EB1E.2090608@sonsorol.org> References: <5846DF60.9090802@sonsorol.org> <20161206161400.GE22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <5846EB1E.2090608@sonsorol.org> Message-ID: <20161206171146.GG22795@p.Speedport_W_724V_Typ_A_05011603_00_009> On Tue, Dec 06, 2016 at 11:45:18AM -0500, List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: > > It's certainly some sort of TGT ticket issue; I just need to find the proper > bits of log to sanitize and post back to this list. I'll do that under > another thread though to keep this one clean. Trying to figure out if > upgrading to 4.3 or even 4.4 would be "wise" on a CentOS-7 system we hope to > put into production once the password checking problem is resolved for SSH > users. I would prefer to look at the sanitize krb5_child.log file first before saying if updating might help or not. There is one case related to enterprise principal and alternative domain suffixes on the AD side where updating to 4.4 would help. But there are other cases related to ticket validation where updating won't help at all. bye, Sumit > > List dedicated to discussions about use, configuration and deployment of the > IPA server. wrote: > > In the latter case it might be some general issue with password > > authentication and the krb5_child.log file with debug_level=10 in the > > [domain/...] section of sssd.conf might help to find the reason (maybe > > ticket validation?). > > -- > Manage your subscription for 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-users at redhat.com Tue Dec 6 17:45:18 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 06 Dec 2016 12:45:18 -0500 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts Message-ID: <5846F92E.3010900@sonsorol.org> #### This is a new thread related to one I started today about upgrading FreeIPA software before continuing troubleshooting work ... New post here so I don't pollute the other thread. #### Looking for additional eyeballs or tips on this ongoing problem. The short summary is we can't check passwords for AD users. SSSD is running in debug-10 mode and we have tons of logs I've got 2 interesting things to trace down, would be interested in feedback on which may be best to concentrate on ... 1. In the SAMBA logs there are very clear and interesting "message=Cannot contact any KDC for realm 'COMPANY-IDM.ORG'" which seems very straightforward and interesting 2. However the SSSD logs contain more worrisome messages about TGT ticket errors Should I concentrate on the samba logs that talk about being unable to find the KDC? That seems more straightforward at the moment. Thanks! -Chris Basic IDM Setup --------------- 1. We run COMPANY-IDM.ORG as our IPA server and realm within AWS 2. We operate hosts as company-aws.org (basically IPA clients have different DNS domain) in AWS 3. COMPANY-IDM.ORG has 1-way trusts to many remote AD Forests at remote corporate sites including COMPANY.ORG Situation ---------- 1. Lots of 1-way trusts to COMPANY.ORG via our COMPANY-IDM.ORG IPA server 2. We can enumerate AD users via "id " command 3. Groups, uid etc. all resolvable for AD users 4. As root we can "sudo - user at nafta.company.org" and it works fine but ... 5. Anything involving password checking fails (SSH and "sudo - user" as non-root) IPA Server /etc/krb5.conf: ------------------------ includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [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 } [dbmodules] COMPANY-IDM.ORG = { db_library = ipadb.so } IPA server /etc/sssd/sssd.conf ------------------------------ [domain/company-idm.org] krb5_validate = false debug_level = 10 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = company-idm.org id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = usaeilidmp001.company-idm.org chpass_provider = ipa ipa_server = usaeilidmp001.company-idm.org ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = company-idm.org [nss] memcache_timeout = 600 homedir_substring = /home [pam] debug_level = 10 [sudo] [autofs] [ssh] debug_level = 10 [pac] [ifp] /var/log/sssd/krb5_child.log ------------- Tue Dec 6 15:36:47 2016) [[sssd[krb5_child[4004]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Dec 6 15:36:47 2016) [[sssd[krb5_child[4004]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [COMPANY.ORG] (Tue Dec 6 15:36:47 2016) [[sssd[krb5_child[4004]]]] [sss_child_krb5_trace_cb] (0x4000): [4004] 1481038607.821494: Getting initial credentials for user at COMPANY.ORG (Tue Dec 6 15:36:47 2016) [[sssd[krb5_child[4004]]]] [sss_child_krb5_trace_cb] (0x4000): [4004] 1481038607.823470: Sending request (169 bytes) to COMPANY.ORG (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.3566: Resolving hostname friawadsgc16.company.org. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.93116: Sending initial UDP request to dgram 15.141.1.63:88 (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.179995: Received answer (118 bytes) from dgram 15.141.1.63:88 (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.269806: Response was not from master KDC (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.269869: Received error from KDC: -1765328316/Realm not local to KDC (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.269902: Retrying AS request with master KDC (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.269911: Getting initial credentials for user at COMPANY.ORG (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [sss_child_krb5_trace_cb] (0x4000): [4004] 1481038608.269956: Sending request (169 bytes) to COMPANY.ORG (master) (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328316} during pre-auth. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [k5c_send_data] (0x0200): Received error code 0 (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [pack_response_packet] (0x2000): response packet size: [4] (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [k5c_send_data] (0x4000): Response sent. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4004]]]] [main] (0x0400): krb5_child completed successfully (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [main] (0x0400): krb5_child started. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [unpack_buffer] (0x1000): total buffer size: [158] (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [unpack_buffer] (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false] enterprise principal [false] offline [true] UPN [user at COMPANY.ORG] (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1843770609] old_ccname: [KEYRING:persistent:1843770609] keytab: [/etc/krb5.keytab] (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [switch_creds] (0x0200): Switch user to [1843770609][1843770609]. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1843770609] and is not active and TGT is valid. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [main] (0x2000): Running as [1843770609][1843770609]. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [become_user] (0x0200): Already user [1843770609]. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [k5c_setup] (0x2000): Running as [1843770609][1843770609]. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [main] (0x0400): Will perform offline auth (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [k5c_send_data] (0x0200): Received error code 0 (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [pack_response_packet] (0x2000): response packet size: [53] (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [k5c_send_data] (0x4000): Response sent. (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [main] (0x0400): krb5_child completed successfully /etc/samba/smb.conf ------------------- ### Added by IPA Installer ### [global] debug pid = yes config backend = registry /var/log/samba/smbd.log ------------------------ 2016/12/06 14:56:42, 0] ../source3/smbd/server.c:1241(main) smbd version 4.2.10 started. Copyright Andrew Tridgell and the Samba Team 1992-2014 [2016/12/06 14:56:42.272249, 1] ipa_sam.c:4686(pdb_init_ipasam) pdb_init_ipasam: support for pdb_enum_upn_suffixes enabled for domain company-idm.org [2016/12/06 14:56:43.364455, 1] ../source3/rpc_server/epmd.c:150(start_epmd) Forking Endpoint Mapper Daemon [2016/12/06 14:56:43.366678, 0] ../lib/util/become_daemon.c:124(daemon_ready) STATUS=daemon 'smbd' finished starting up and ready to serve connections [2016/12/06 14:56:43.366722, 1] ../source3/rpc_server/lsasd.c:837(start_lsasd) Forking LSA Service Daemon [2016/12/06 15:08:28, 0] ../source3/smbd/server.c:1241(main) smbd version 4.2.10 started. Copyright Andrew Tridgell and the Samba Team 1992-2014 [2016/12/06 15:09:11.688374, 0] ipa_sam.c:4208(bind_callback_cleanup) kerberos error: code=-1765328228, message=Cannot contact any KDC for realm 'COMPANY-IDM.ORG' [2016/12/06 15:09:11.688513, 0] ../source3/lib/smbldap.c:998(smbldap_connect_system) failed to bind to server ldapi://%2fvar%2frun%2fslapd-COMPANY-IDM-ORG.socket with dn="[Anonymous bind]" Error: Local error (unknown) [2016/12/06 15:09:11.688639, 1] ../source3/lib/smbldap.c:1206(get_cached_ldap_connect) Connection to LDAP server failed for the 1 try! Another /var/log/samba log: --------------------------- kerberos error: code=-1765328228, message=Cannot contact any KDC for realm 'COMPANY-IDM.ORG' [2016/12/06 15:32:00.850742, 1] ../source3/lib/smbldap.c:1206(get_cached_ldap_connect) Connection to LDAP server failed for the 14 try! [2016/12/06 15:32:01.851630, 0] ipa_sam.c:4208(bind_callback_cleanup) kerberos error: code=-1765328228, message=Cannot contact any KDC for realm 'COMPANY-IDM.ORG' [2016/12/06 15:32:01.851707, 1] ../source3/lib/smbldap.c:1206(get_cached_ldap_connect) Connection to LDAP server failed for the 15 try! [2016/12/06 15:32:02.852728, 0] ipa_sam.c:4208(bind_callback_cleanup) kerberos error: code=-1765328228, message=Cannot contact any KDC for realm 'COMPANY-IDM.ORG' [2016/12/06 15:32:02.852797, 1] ../source3/lib/smbldap.c:1206(get_cached_ldap_connect) Connection to LDAP server failed for the 16 try! sssd_pam.log ------------ Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: user at nafta.company.org (Tue Dec 6 15:36:52 2016) [sssd[pam]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/NAFTA.COMPANY.ORG/user] (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_initgr_check_timeout] (0x2000): User [user at nafta.company.org] found in PAM cache. (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [user at NAFTA.COMPANY.ORG] (Tue Dec 6 15:36:52 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7ff54d25f1e0 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7ff54d261310 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7ff54d25f1e0 "ltdb_callback" (Tue Dec 6 15:36:52 2016) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7ff54d261310 "ltdb_timeout" (Tue Dec 6 15:36:52 2016) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7ff54d25f1e0 "ltdb_callback" (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [user at NAFTA.COMPANY.ORG] (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is user at NAFTA.COMPANY.ORG (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: NAFTA.COMPANY.ORG (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): user: user at NAFTA.COMPANY.ORG (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: localhost (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 4001 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: user at nafta.company.org (Tue Dec 6 15:36:52 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7ff54d262940 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7ff54d262940 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7ff54d2590f0 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [6 (Permission denied)][NAFTA.COMPANY.ORG] (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [6]: Permission denied. (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 84 (Tue Dec 6 15:36:52 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7ff54d25e620][19] (Tue Dec 6 15:36:52 2016) [sssd[pam]] [pam_initgr_cache_remove] (0x2000): [user at nafta.company.org] removed from PAM initgroup cache (Tue Dec 6 15:36:52 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7ff54d25e620][19] (Tue Dec 6 15:36:52 2016) [sssd[pam]] [client_recv] (0x0200): Client disconnected! From freeipa-users at redhat.com Tue Dec 6 18:02:11 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 19:02:11 +0100 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <5846F92E.3010900@sonsorol.org> References: <5846F92E.3010900@sonsorol.org> Message-ID: <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> On Tue, Dec 06, 2016 at 12:45:18PM -0500, List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: > #### > This is a new thread related to one I started today about upgrading FreeIPA > software before continuing troubleshooting work ... > > New post here so I don't pollute the other thread. > #### > > > Looking for additional eyeballs or tips on this ongoing problem. The short > summary > is we can't check passwords for AD users. > > SSSD is running in debug-10 mode and we have tons of logs > > I've got 2 interesting things to trace down, would be interested in feedback > on > which may be best to concentrate on ... > > > 1. In the SAMBA logs there are very clear and interesting "message=Cannot > contact any KDC for realm 'COMPANY-IDM.ORG'" > which seems very straightforward and interesting you can ignore those, samba is not involved in the authentication. > > 2. However the SSSD logs contain more worrisome messages about TGT ticket > errors > > > Should I concentrate on the samba logs that talk about being unable to find > the KDC? > That seems more straightforward at the moment. > > > Thanks! > > -Chris > > > > > ... > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [main] (0x0400): > krb5_child started. > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [unpack_buffer] > (0x1000): total buffer size: [158] > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false] > enterprise principal [false] offline [true] UPN [user at COMPANY.ORG] ^^^^^^^^^^^^^^^ The backend switch to offline mode, please send the SSSD domain logs around this time as well. If possible please start about 5 minutes earlier. bye, Sumit From freeipa-users at redhat.com Tue Dec 6 20:17:33 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 06 Dec 2016 15:17:33 -0500 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <5846F92E.3010900@sonsorol.org> <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <58471CDD.8070703@sonsorol.org> Appreciate the assistance! Is there a better debug level balance than 10 for this sort of situation? The domain logs were several hundred MBs by the time I started looking for useful info if there is a different level I can use that would better at producing actionable error/log messages I'll gladly switch ... List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: >> (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [main] (0x0400): >> > krb5_child started. >> > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [unpack_buffer] >> > (0x1000): total buffer size: [158] >> > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [unpack_buffer] >> > (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false] >> > enterprise principal [false] offline [true] UPN [user at COMPANY.ORG] > > ^^^^^^^^^^^^^^^ > > The backend switch to offline mode, please send the SSSD domain logs > around this time as well. If possible please start about 5 minutes > earlier. > > bye, > Sumit I searched through the massive SSSD domain logs and had trouble finding the right area so here are the lines surrounding my own username when I tried to authenticate via SSH using AD credentials: /var/log/sssd/sssd_DOMAIN.log (Sanitized) ------------------------------------------- (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [be_req_set_domain] (0x0400): Changing request domain from [company-idm.org] to [NAFTA.COMPANY.ORG] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7f78cb39e850 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7f78cb3b7200 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): Running timer event 0x7f78cb39e850 "ltdb_callback" (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): Destroying timer event 0x7f78cb3b7200 "ltdb_timeout" (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): Ending timer event 0x7f78cb39e850 "ltdb_callback" (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view [Default Trust View] with filter [(&(objectClass=ipaUserOverride)(uid=t859531))]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_print_server] (0x2000): Searching 10.127.64.11 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaUserOverride)(uid=t859531))][cn=Default Trust View,cn=views,cn=accounts,dc=companyidm,dc=org]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 118 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_op_add] (0x2000): New operation 118 timeout 60 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_result] (0x2000): Trace: sh[0x7f78cb2224a0], connected[1], ops[0x7f78cb39efa0], ldap[0x7f78cb1cfb40] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_op_destructor] (0x2000): Operation 117 finished (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-299502267-823518204-725345543-160433))]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success) (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_result] (0x2000): Trace: sh[0x7f78cb2224a0], connected[1], ops[0x7f78cb39efa0], ldap[0x7f78cb1cfb40] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_op_destructor] (0x2000): Operation 118 finished (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ipa_get_ad_override_done] (0x4000): No override found with filter [(&(objectClass=ipaUserOverride)(uid=t859531))]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_initgr_send] (0x4000): Retrieving info for initgroups call (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [dc=nafta,dc=company,dc=org] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_print_server] (0x2000): Searching 15.189.131.14 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=t859531)(objectclass=user)(objectSID=*))][dc=nafta,dc=company,dc=org]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPrincipalName] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [primaryGroupID] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 9 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_op_add] (0x2000): New operation 9 timeout 6 (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_result] (0x2000): Trace: sh[0x7f78cb2224a0], connected[1], ops[(nil)], ldap[0x7f78cb1cfb40] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_result] (0x2000): Trace: sh[0x7f78cb39e540], connected[1], ops[0x7f78cb39eb60], ldap[0x7f78cb396250] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=Dagdigian Chris USRE:t859531,OU=USRC,OU=Users,OU=usr,OU=objects,DC=NAFTA,DC=SYNGENTA,DC=ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [whenChanged] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberOf] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [uSNChanged] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [name] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectGUID] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [userAccountControl] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [primaryGroupID] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectSid] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [sAMAccountName] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [userPrincipalName] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_result] (0x2000): Trace: sh[0x7f78cb39e540], connected[1], ops[0x7f78cb39eb60], ldap[0x7f78cb396250] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_op_destructor] (0x2000): Operation 9 finished (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_initgr_user] (0x4000): Receiving info for the user (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_initgr_user] (0x4000): Storing the user (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_save_user] (0x0400): Save user (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_get_primary_name] (0x0400): Processing object t859531 at NAFTA.COMPANY.ORG (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_save_user] (0x0400): Processing user t859531 at NAFTA.COMPANY.ORG (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_save_user] (0x1000): Mapping user [t859531 at NAFTA.COMPANY.ORG] objectSID [S-1-5-21-1801674531-1767777339-682003330-170609] to unix ID (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_save_user] (0x2000): Adding originalDN [CN=Dagdigian Chris USRE:t859531,OU=USRC,OU=Users,OU=usr,OU=objects,DC=NAFTA,DC=SYNGENTA,DC=ORG] to attributes of [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_save_user] (0x0400): Adding original memberOf attributes to [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding original mod-Timestamp [20161205151624.0Z] to attributes of [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_save_user] (0x0400): Adding user principal [t859531 at COMPANY.ORG] to attributes of [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowLastChange is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMin is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowMax is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowWarning is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowInactive is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowExpire is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): shadowFlag is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): krbLastPwdChange is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): krbPasswordExpiration is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): pwdAttribute is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedService is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): adAccountExpires is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): Adding adUserAccountControl [512] to attributes of [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): nsAccountLock is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): authorizedHost is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginDisabled is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginExpirationTime is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): ndsLoginAllowedTimeMap is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): sshPublicKey is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): authType is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_attrs_add_ldap_attr] (0x2000): userCertificate is not available for [t859531 at NAFTA.COMPANY.ORG]. (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sysdb_attrs_get_aliases] (0x2000): Domain is case-insensitive; will add lowercased aliases (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [sdap_save_user] (0x0400): Storing info for user t859531 at NAFTA.COMPANY.ORG (Tue Dec 6 18:24:22 2016) [sssd[be[company-idm.org]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [main] (0x0400): krb5_child started. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [unpack_buffer] (0x1000): total buffer size: [52] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [unpack_buffer] (0x0100): cmd [249] uid [1843770609] gid [1843770609] validate [false] enterprise principal [false] offline [false] UPN [t859531 at COMPANY.ORG] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG in keytab. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [match_principal] (0x1000): Principal matched to the sample (host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG). (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [main] (0x2000): Running as [1843770609][1843770609]. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [k5c_setup] (0x2000): Running as [1843770609][1843770609]. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [main] (0x0400): Will perform pre-auth (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [COMPANY.ORG] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.93516: Getting initial credentials for t859531 at COMPANY.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.95456: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_COMPANY-IDM.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.95498: Retrieving host/usaeilidmp001.company-idm.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 Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.95541: Sending request (169 bytes) to COMPANY.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.96088: Resolving hostname friawadsgc16.company.org. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.96518: Sending initial UDP request to dgram 15.141.1.63:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.183474: Received answer (118 bytes) from dgram 15.141.1.63:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.183759: Response was not from master KDC (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.183788: Received error from KDC: -1765328316/Realm not local to KDC (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.183802: Following referral to realm NAFTA.COMPANY.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.183820: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_COMPANY-IDM.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.183848: Retrieving host/usaeilidmp001.company-idm.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 Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.183891: Sending request (181 bytes) to NAFTA.COMPANY.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.186283: Resolving hostname usetwadsfsmo03.nafta.company.org. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.186492: Sending initial UDP request to dgram 15.189.131.30:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.206711: Received answer (205 bytes) from dgram 15.189.131.30:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398017: Response was not from master KDC (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398114: Received error from KDC: -1765328359/Additional pre-authentication required (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398168: Processing preauth types: 16, 15, 19, 2 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398188: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGt859531", params "" (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398210: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398233: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398244: Preauth module pkinit (16) (real) returned: 22/Invalid argument (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398255: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398262: Preauth module pkinit (14) (real) returned: 22/Invalid argument (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_krb5_prompter] (0x0020): Cannot handle password prompts. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398278: Preauth module encrypted_timestamp (2) (real) returned: -1765328254/Cannot read password (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398292: Retrying AS request with master KDC (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398303: Getting initial credentials for t859531 at COMPANY.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398322: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_COMPANY-IDM.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398345: Retrieving host/usaeilidmp001.company-idm.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 Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [sss_child_krb5_trace_cb] (0x4000): [12405] 1481054230.398368: Sending request (169 bytes) to COMPANY.ORG (master) (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [22} during pre-auth. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [k5c_send_data] (0x0200): Received error code 0 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [pack_response_packet] (0x2000): response packet size: [4] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [k5c_send_data] (0x4000): Response sent. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12405]]]] [main] (0x0400): krb5_child completed successfully (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [main] (0x0400): krb5_child started. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [unpack_buffer] (0x1000): total buffer size: [158] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [unpack_buffer] (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false] enterprise principal [false] offline [false] UPN [t859531 at COMPANY.ORG] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1843770609] old_ccname: [KEYRING:persistent:1843770609] keytab: [/etc/krb5.keytab] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [switch_creds] (0x0200): Switch user to [1843770609][1843770609]. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1843770609] and is not active and TGT is valid. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG in keytab. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [match_principal] (0x1000): Principal matched to the sample (host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG). (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [main] (0x2000): Running as [1843770609][1843770609]. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [k5c_setup] (0x2000): Running as [1843770609][1843770609]. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [main] (0x0400): Will perform online auth (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [COMPANY.ORG] (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.699127: Getting initial credentials for t859531 at COMPANY.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.701031: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_COMPANY-IDM.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.701076: Retrieving host/usaeilidmp001.company-idm.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 Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.701129: Sending request (169 bytes) to COMPANY.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.701679: Resolving hostname usetwadsgc01.company.org. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.702086: Sending initial UDP request to dgram 15.189.131.10:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.733238: Received answer (118 bytes) from dgram 15.189.131.10:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.733453: Response was not from master KDC (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.733480: Received error from KDC: -1765328316/Realm not local to KDC (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.733493: Following referral to realm NAFTA.COMPANY.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.733509: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_COMPANY-IDM.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.733535: Retrieving host/usaeilidmp001.company-idm.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 Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.733568: Sending request (181 bytes) to NAFTA.COMPANY.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.735973: Resolving hostname usetwadsfsmo04.nafta.company.org. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.736149: Sending initial UDP request to dgram 15.189.131.31:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.768127: Received answer (205 bytes) from dgram 15.189.131.31:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.768302: Response was not from master KDC (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.768332: Received error from KDC: -1765328359/Additional pre-authentication required (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.768358: Processing preauth types: 16, 15, 19, 2 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.768375: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGt859531", params "" (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.768396: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.768414: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.768423: Preauth module pkinit (16) (real) returned: 22/Invalid argument (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.768433: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.768440: Preauth module pkinit (14) (real) returned: 22/Invalid argument (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.777142: AS key obtained for encrypted timestamp: aes256-cts/3D3B (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.777191: Encrypted timestamp (for 1481054230.710717): plain 301AA011180F32303136313230363139353731305AA10502030AD83D, encrypted 132EB7BE35E113EC6EF0D40BB7DF9D9A8116AE8F79B0C80787726DA03B0FA30704B7EBB257E72B38528722EB36F04C5AEFAFBDA8DFBFF908 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.777204: Preauth module encrypted_timestamp (2) (real) returned: 0/Success (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.777211: Produced preauth for next request: 2 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.777226: Sending request (260 bytes) to NAFTA.COMPANY.ORG (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.779526: Resolving hostname friawadsgc02.nafta.company.org. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.779717: Sending initial UDP request to dgram 15.141.1.11:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.876715: Received answer (108 bytes) from dgram 15.141.1.11:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.876974: Response was not from master KDC (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.877004: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.877014: Request or response is too big for UDP; retrying with TCP (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.877028: Sending request (260 bytes) to NAFTA.COMPANY.ORG (tcp only) (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.878309: Resolving hostname frgowadsgc02.nafta.company.org. (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.878512: Initiating TCP connection to stream 15.141.1.16:88 (Tue Dec 6 19:57:10 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054230.965515: Sending TCP request to stream 15.141.1.16:88 (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054231.99940: Received answer (2071 bytes) from stream 15.141.1.16:88 (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054231.99963: Terminating TCP connection to stream 15.141.1.16:88 (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054231.100136: Response was not from master KDC (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054231.100180: Processing preauth types: 19 (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054231.100193: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGt859531", params "" (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054231.100202: Produced preauth for next request: (empty) (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054231.100211: AS key determined by preauth: aes256-cts/3D3B (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054231.100256: Decrypted AS reply; session key is: aes256-cts/4E6F (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_child_krb5_trace_cb] (0x4000): [12406] 1481054231.100264: FAST negotiation: unavailable (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_krb5_expire_callback_func] (0x2000): exp_time: [2742397] (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [get_and_save_tgt] (0x0100): TGT validation is disabled. (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_get_ccache_name_for_principal] (0x4000): Location: [KEYRING:persistent:1843770609] (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [sss_get_ccache_name_for_principal] (0x4000): tmp_ccname: [KEYRING:persistent:1843770609:krb_ccache_OVBc5zF] (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [create_ccache] (0x4000): Initializing ccache of type [KEYRING] (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [create_ccache] (0x4000): CC supports switch (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [create_ccache] (0x4000): returning: 0 (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the same, none will be deleted. (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [k5c_send_data] (0x0200): Received error code 0 (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [pack_response_packet] (0x2000): response packet size: [144] (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [k5c_send_data] (0x4000): Response sent. (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [main] (0x0400): krb5_child completed successfully (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [main] (0x0400): krb5_child started. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [unpack_buffer] (0x1000): total buffer size: [52] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [unpack_buffer] (0x0100): cmd [249] uid [1843770609] gid [1843770609] validate [false] enterprise principal [false] offline [false] UPN [t859531 at COMPANY.ORG] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG in keytab. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [match_principal] (0x1000): Principal matched to the sample (host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG). (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [main] (0x2000): Running as [1843770609][1843770609]. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [k5c_setup] (0x2000): Running as [1843770609][1843770609]. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [main] (0x0400): Will perform pre-auth (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [COMPANY.ORG] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.72549: Getting initial credentials for t859531 at COMPANY.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.74479: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_COMPANY-IDM.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.74521: Retrieving host/usaeilidmp001.company-idm.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 Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.74571: Sending request (169 bytes) to COMPANY.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.75143: Resolving hostname friawadsgc11.company.org. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.75586: Sending initial UDP request to dgram 15.141.1.51:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.161933: Received answer (118 bytes) from dgram 15.141.1.51:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.162191: Response was not from master KDC (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.162223: Received error from KDC: -1765328316/Realm not local to KDC (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.162237: Following referral to realm NAFTA.COMPANY.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.162254: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_COMPANY-IDM.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.162282: Retrieving host/usaeilidmp001.company-idm.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 Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.162313: Sending request (181 bytes) to NAFTA.COMPANY.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.164790: Resolving hostname friawadsgc12.nafta.company.org. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.164994: Sending initial UDP request to dgram 15.141.1.52:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255512: Received answer (205 bytes) from dgram 15.141.1.52:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255774: Response was not from master KDC (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255815: Received error from KDC: -1765328359/Additional pre-authentication required (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255848: Processing preauth types: 16, 15, 19, 2 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255869: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGt859531", params "" (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255891: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255915: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255926: Preauth module pkinit (16) (real) returned: 22/Invalid argument (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255937: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255944: Preauth module pkinit (14) (real) returned: 22/Invalid argument (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_krb5_prompter] (0x0020): Cannot handle password prompts. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255970: Preauth module encrypted_timestamp (2) (real) returned: -1765328254/Cannot read password (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255984: Retrying AS request with master KDC (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.255992: Getting initial credentials for t859531 at COMPANY.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.256011: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_COMPANY-IDM.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.256035: Retrieving host/usaeilidmp001.company-idm.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 Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [sss_child_krb5_trace_cb] (0x4000): [12415] 1481054234.256059: Sending request (169 bytes) to COMPANY.ORG (master) (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [22} during pre-auth. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [k5c_send_data] (0x0200): Received error code 0 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [pack_response_packet] (0x2000): response packet size: [4] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [k5c_send_data] (0x4000): Response sent. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12415]]]] [main] (0x0400): krb5_child completed successfully (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [main] (0x0400): krb5_child started. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [unpack_buffer] (0x1000): total buffer size: [158] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [unpack_buffer] (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false] enterprise principal [false] offline [false] UPN [t859531 at COMPANY.ORG] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1843770609] old_ccname: [KEYRING:persistent:1843770609] keytab: [/etc/krb5.keytab] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [switch_creds] (0x0200): Switch user to [1843770609][1843770609]. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [switch_creds] (0x0200): Switch user to [0][0]. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [k5c_check_old_ccache] (0x4000): Ccache_file is [KEYRING:persistent:1843770609] and is not active and TGT is valid. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [k5c_precreate_ccache] (0x4000): Recreating ccache (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [find_principal_in_keytab] (0x4000): Trying to find principal host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG in keytab. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [match_principal] (0x1000): Principal matched to the sample (host/usaeilidmp001.company-idm.org at COMPANY-IDM.ORG). (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [become_user] (0x0200): Trying to become user [1843770609][1843770609]. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [main] (0x2000): Running as [1843770609][1843770609]. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [k5c_setup] (0x2000): Running as [1843770609][1843770609]. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [main] (0x0400): Will perform online auth (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [COMPANY.ORG] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.281781: Getting initial credentials for t859531 at COMPANY.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.283707: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_COMPANY-IDM.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.283753: Retrieving host/usaeilidmp001.company-idm.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 Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.283795: Sending request (169 bytes) to COMPANY.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.284321: Resolving hostname frgowadsgc01.company.org. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.284716: Sending initial UDP request to dgram 15.141.1.15:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.377848: Received answer (118 bytes) from dgram 15.141.1.15:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.378147: Response was not from master KDC (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.378179: Received error from KDC: -1765328316/Realm not local to KDC (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.378192: Following referral to realm NAFTA.COMPANY.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.378210: FAST armor ccache: MEMORY:/var/lib/sss/db/fast_ccache_COMPANY-IDM.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.378239: Retrieving host/usaeilidmp001.company-idm.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 Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.378272: Sending request (181 bytes) to NAFTA.COMPANY.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.380656: Resolving hostname usetwadsgc02.nafta.company.org. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.380857: Sending initial UDP request to dgram 15.189.131.11:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.405841: Received answer (205 bytes) from dgram 15.189.131.11:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.406076: Response was not from master KDC (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.406110: Received error from KDC: -1765328359/Additional pre-authentication required (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.406139: Processing preauth types: 16, 15, 19, 2 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.406159: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGt859531", params "" (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.406181: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.406199: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.406209: Preauth module pkinit (16) (real) returned: 22/Invalid argument (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.406238: PKINIT client has no configured identity; giving up (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.406246: Preauth module pkinit (14) (real) returned: 22/Invalid argument (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.414944: AS key obtained for encrypted timestamp: aes256-cts/3D3B (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.414987: Encrypted timestamp (for 1481054234.344243): plain 301AA011180F32303136313230363139353731345AA10502030540B3, encrypted B631BC6CF58EA1A8B3431F6A23C06ED1A79B8EF46B43B2A4682FC240D272DACCEF2E176992C934484EB60475122E3E3F21A382D9DC362344 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.415000: Preauth module encrypted_timestamp (2) (real) returned: 0/Success (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.415006: Produced preauth for next request: 2 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.415022: Sending request (260 bytes) to NAFTA.COMPANY.ORG (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.417353: Resolving hostname usetwadsfsmo03.nafta.company.org. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.417542: Sending initial UDP request to dgram 15.189.131.30:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.438536: Received answer (108 bytes) from dgram 15.189.131.30:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.438704: Response was not from master KDC (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.438728: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.438738: Request or response is too big for UDP; retrying with TCP (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.438750: Sending request (260 bytes) to NAFTA.COMPANY.ORG (tcp only) (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.439936: Resolving hostname friawadsgc02.nafta.company.org. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.440123: Initiating TCP connection to stream 15.141.1.11:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.526159: Sending TCP request to stream 15.141.1.11:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.630381: Received answer (2071 bytes) from stream 15.141.1.11:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.630405: Terminating TCP connection to stream 15.141.1.11:88 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.630616: Response was not from master KDC (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.630656: Processing preauth types: 19 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.630667: Selected etype info: etype aes256-cts, salt "NAFTA.COMPANY.ORGt859531", params "" (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.630676: Produced preauth for next request: (empty) (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.630686: AS key determined by preauth: aes256-cts/3D3B (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.630735: Decrypted AS reply; session key is: aes256-cts/C0BE (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_child_krb5_trace_cb] (0x4000): [12417] 1481054234.630742: FAST negotiation: unavailable (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_krb5_expire_callback_func] (0x2000): exp_time: [2742394] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [get_and_save_tgt] (0x0100): TGT validation is disabled. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_get_ccache_name_for_principal] (0x4000): Location: [KEYRING:persistent:1843770609] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [sss_get_ccache_name_for_principal] (0x4000): tmp_ccname: [KEYRING:persistent:1843770609:krb_ccache_OVBc5zF] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [create_ccache] (0x4000): Initializing ccache of type [KEYRING] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [create_ccache] (0x4000): CC supports switch (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [create_ccache] (0x4000): returning: 0 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the same, none will be deleted. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [k5c_send_data] (0x0200): Received error code 0 (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [pack_response_packet] (0x2000): response packet size: [144] (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [k5c_send_data] (0x4000): Response sent. (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [main] (0x0400): krb5_child completed successfully From freeipa-users at redhat.com Tue Dec 6 20:37:35 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 22:37:35 +0200 Subject: [Freeipa-users] Mapping users from AD to IPA KDC In-Reply-To: <1ee640af-4739-1e9b-bb49-c10601e6e08d@mdevsys.com> References: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> <2c4ff955-ab05-80ea-f4ae-da217d21b285@mdevsys.com> <20161205070232.gnntt334q5siv3va@redhat.com> <1ee640af-4739-1e9b-bb49-c10601e6e08d@mdevsys.com> Message-ID: <20161206203735.l56lefuf5w5hye5t@redhat.com> On ti, 06 joulu 2016, TomK wrote: >On 12/5/2016 2:02 AM, Alexander Bokovoy wrote: >>On su, 04 joulu 2016, TomK wrote: >>>Could not get much from logs and decided to start fresh. When I run >>>this: >>> >>>ipa trust-add --type=ad mds.xyz --admin Administrator --password >>> >>>Trust works fine and id tom at mds.xyz returns a valid result. >>> >>>However when I run the following on both masters on a fresh new setup: >>> >>>ipa-adtrust-install --netbios-name=NIX -a "" >>>ipa trust-add --type=ad "mds.xyz" --trust-secret >>> >>>and created a trust object in AD DC with the name of NIX and a >>>non-transitive trust, the above did NOT work. I didn't get anything >>>by typing id tom at mds.xyz. (I do not get an option for a Forest Trust >>>as the gif on this page suggests: >>>https://www.freeipa.org/page/Active_Directory_trust_setup . Possibly >>>it's Server 2012 hence the difference in what's presented to me but >>>another reason is that the name I type for the trust can't resolve to >>>an IP for now: nix.mds.xyz . So I use NIX to match the bios name used >>>on the ipa-adtrust-install command above. ) >>The shared secret case for one-way trust is known to be broken. When a >>shared half is created on AD side first, it is marked as not yet valid >>by Windows and currently we cannot perform validation of it from IPA >>side. Validating it from AD side is not possible as well as we don't >>provide all interfaces Windows would like to use. >> >>And the fact you cannot see 'Forest Trust' type of the trust says also >>that you have problems with reaching IPA masters from AD DC side for >>probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and >>UDP). >Nothing I tried in AD Trust creation allowed me to make one with type >Forest. Just realm. I recall I had a trust type of Forest but in >trying various options I lost how I did that. Or perhaps I hadn't >payed attention and it got created indirectly as part of another >action I took. The domain functional level I'm using is Windows >Server 2008. Using a lower value for testing. This (inability to chose Forest trust type) simply means AD DC is unable to probe IPA DC. You said below that SMB port towards IPA DC was closed. Also make sure to remove incorrect trust from Windows side. While we are removing a trust object named as our NetBIOS name, it only works for the proper trusted domain/forests, not for wrong 'realm trust' type. > >My IPA version is 4.2 right now. It came with the CentOS 7.2. >Looking forward to 4.4. Not sure when you plan to include it as part >of the latest CentOS base. Indeed some ports were not open (445). >I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7: > >for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp >53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp >53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd >--zone=public --permanent --add-port=$KEY; done > >[root at idmipa01 ~]# firewall-cmd --zone=public --list-all >public (default) > interfaces: > sources: > services: dhcpv6-client ntp ssh > ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp >135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp >139/udp 138/udp 53/udp 636/tcp > masquerade: no > forward-ports: > icmp-blocks: > rich rules: > >[root at idmipa01 ~]# > >On Windows Side (The nslookup results were the same before the >firewall change however.): Firewall changes cannot affect DNS as you already had DNS port open. >On the AD side, I added the SRV records for the second AD DC, >manually, since earlier there were no results printed on the AD DC >command line for the second AD DC, when I typed the command >_ldap._tcp.mds.xyz. > >One additional question I had with the setup is in regards to the >failover. I see the ipa_server entry in /etc/sssd/sssd.conf pointing >to two of the master IPA nodes. Where can I find the additional >settings that control priority of the listed server or order they are >checked? You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections FAILOVER and SERVICE DISCOVER. >What I ran to get the above is: > >1) ipa-client-install --force-join -p admin -w "" >--fixed-primary --server=idmipa01.nix.mds.xyz >--server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ >-U >2) realm join mds.xyz This is wrong. You have effectively joined this IPA client to AD and IPA at the same time. It should not be done this way (read http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain for details). Instead, you need to identify why the trust does not work properly. Use tcpdump to intercept the traffic between your AD DCs and IPA DCs while establishing the trust. You can send the trace to me off-list. -- / Alexander Bokovoy From freeipa-users at redhat.com Tue Dec 6 21:11:21 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 16:11:21 -0500 Subject: [Freeipa-users] lowest-privilege method of checking for out of sync FreeIPA masters? Message-ID: Hello, There's a method to check the replication status of FreeIPA masters by looking at objectClass=nsDS5ReplicationAgreement in the "cn=mapping tree,cn=config" part of LDAP. Unfortunately that requires Directory Admin level privileges. Is there a method to check those replication agreement details that uses a much lower privilege? We'd like to add a replication test to our Zabbix monitoring system, and we don't want to use the directory admin user ID :) Thanks! Anthony Clark -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-users at redhat.com Tue Dec 6 21:15:53 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 16:15:53 -0500 Subject: [Freeipa-users] Made a bit of install progress, next error Message-ID: Volunteers, I moved over to a Fedora VM which was way more difficult than it should be. All kinds of problems with Guest Additions and I ended up having to run server mode with no GUI. Now I run an Ubuntu VM from which I ssh into my Fedora VM. Anyway... The install made it a further step than before. I get a quick blue screen pop up at the end then an error saying: [image: Inline image 1] An unexpected error occurred: > The request message was malformed :: DNS name does not have enough labels > Please see the logfiles in /var/log/letsencrypt for more details. > When I run the cert checker util I get this https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org Full log below. Any suggestions? Is it not pulling my proper hostname? Thanks, Joe [jjflynn22 at ipa-a ~]$ cat /etc/hosts 192.168.1.211 ipa-a.kkgpitt.org ipa-a 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 [jjflynn22 at ipa-a ~]$ sudo cat /var/log/letsencrypt/letsencrypt.log [sudo] password for jjflynn22: 2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level set at 20 2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log 2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3 2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments: ['--standalone', '--csr', '/root/ipa-le/httpd-csr.der', '--email', 'xxxxx at gmail.com', '--agree-tos'] 2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone) 2016-12-06 20:57:43,995:DEBUG:certbot.plugins.selection:Requested authenticator standalone and installer None 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Single candidate plugin: * standalone Description: Spin up a temporary webserver Interfaces: IAuthenticator, IPlugin Entry point: standalone = certbot.plugins.standalone:Authenticator Initialized: Prep: True 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Selected authenticator and installer None 2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account: 2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {} 2016-12-06 20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-12-06 20:57:44,500:DEBUG:requests.packages.urllib3.connectionpool:"GET /directory HTTP/1.1" 200 280 2016-12-06 20:57:44,506:DEBUG:root:Received . Headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT', 'Boulder-Request-Id': 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}. Content: '{\n "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"\n}' 2016-12-06 20:57:44,506:DEBUG:acme.client:Received response (headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT', 'Boulder-Request-Id': 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}): '{\n "new-authz": " https://acme-v01.api.letsencrypt.org/acme/new-authz",\n "new-cert": " https://acme-v01.api.letsencrypt.org/acme/new-cert",\n "new-reg": " https://acme-v01.api.letsencrypt.org/acme/new-reg",\n "revoke-cert": " https://acme-v01.api.letsencrypt.org/acme/revoke-cert"\n}' 2016-12-06 20:57:44,506:DEBUG:certbot.client:CSR: CSR(file='/root/ipa-le/httpd-csr.der', data='0\x82\x02x0\x82\x01`\x02\x01\x000\x101\x0e0\x0c\x06\x03U\x04\x03\x13\x05ipa-a0\x82\x01"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x01\x0f\x000\x82\x01\n\x02\x82\x01\x01\x00\xdau1L\xa6T\xc8\x93\xc0P\x93\xb3\xd2\xcb \xe2PU\xf0\x94=\x1c\n\x1e\xe5\xfe\xed<\xfa\xb1d-\x92\xebeD\xb1\x0eq9\xf1\xfa\xb5p\xdc\x12qN\x96\x0b\x1f\x13\xab\xae ....... 99\xc0\xb0\x07N\xdd5\x9e1\xb8\xdc\x8c\xc1N\xc1\x04\xa1\xd0\xfc\xc2$f\x84e\xd4\xf7i\x1a\x1c~,\x80\xea/~j\xea\xa2\xf3\xe9\x96\xfe5j\xa4\xb4X\x12L\xd5\xe5\xb0\x99|\xb8\xd1\xed\xa3\xf2\xd5\xf0\x94\xc3"\xe8\x9dT\x17\xcf\x12$oVE\x83\xd1\x96\xac\xa1\xf9F\xd2mO\xe9$\xa7\x00_\xaa\xc6\xa3j\xa1\xbaX8\xa43K\x18os\xe1\xf4L(\xf9\xac\'\xc5\x9a\xdc\xf5s\xc6`\x97\xe6\xea\xf8\xcc\xfa\xe1U_\xff\x86\xf0\x82\xab\xaf\xb9\x92q\x06\x0f\xa5}]\x9c\xb1\x84b\x85<\xed\x92,g\x0e\xeaoAi|\xc5\n\x92', form='der'), domains: [u'ipa-a'] 2016-12-06 20:57:44,507:DEBUG:root:Requesting fresh nonce 2016-12-06 20:57:44,507:DEBUG:root:Sending HEAD request to https://acme-v01.api.letsencrypt.org/acme/new-authz. args: (), kwargs: {} 2016-12-06 20:57:44,608:DEBUG:requests.packages.urllib3.connectionpool:"HEAD /acme/new-authz HTTP/1.1" 405 0 2016-12-06 20:57:44,609:DEBUG:root:Received . Headers: {'Content-Length': '91', 'Pragma': 'no-cache', 'Boulder-Request-Id': 'c2cMPhHqlO5kTv8xJ5dfIs4NCD2KMqn8X-IxPzutDAI', 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'keep-alive', 'Allow': 'POST', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', 'Content-Type': 'application/problem+json', 'Replay-Nonce': '3fq9edUYLFJwQKDU-oaLVpQdUglFemQpGNbwZ-AtmfI'}. Content: '' 2016-12-06 20:57:44,609:DEBUG:acme.client:Storing nonce: '\xdd\xfa\xbdy\xd5\x18,Rp@ \xa0\xd4\xfa\x86\x8bV\x94\x1dR\tEzd)\x18\xd6\xf0g\xe0-\x99\xf2' 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted empty fields: combinations=None, challenges=None, expires=None, status=None 2016-12-06 20:57:44,610:DEBUG:acme.client:Serialized JSON: {"identifier": {"type": "dns", "value": "ipa-a"}, "resource": "new-authz"} 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted empty fields: kid=None, x5c=(), crit=(), jwk=None, typ=None, jku=None, cty=None, x5tS256=None, x5u=None, alg=None, x5t=None 2016-12-06 20:57:44,612:DEBUG:acme.jose.json_util:Omitted empty fields: kid=None, x5c=(), crit=(), typ=None, jku=None, cty=None, x5tS256=None, x5u=None, x5t=None, nonce=None 2016-12-06 20:57:44,612:DEBUG:root:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/new-authz. args: (), kwargs: {'data': '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "vmM8XoN-WDCdPcaMNxu9zlLEJBBN-W_pIkG-Afw5uawBBXWHbWyzUeb06LypMM94LcTi0drWTf00Fdv5SiVKMAwwAoqH-Xzv5LHBwYmqNFGr-W6cphQjNTP21IP87NKxG87OdvvOMjE--oMuJJMYWbyAAcOZNhIobWp969EMGu9Oi5JeQI1bLqIHS317xWDPD_EMTmhnVxZGBuS5gs_ObYejnJmGyu4_Bn1yLIDlBuphYsHg0pWoAgjZQAr3NI4N7oVrB-LiW21-k9I-LH3dijxVLBe_7jfKsIsVTJyzMzl-g2iAeogYHfRngkhnQVXfhSleeZbfHwKXPs5FdmnHBw"}}, "protected": "eyJub25jZSI6ICIzZnE5ZWRVWUxGSndRS0RVLW9hTFZwUWRVZ2xGZW1RcEdOYndaLUF0bWZJIn0", "payload": "eyJpZGVudGlmaWVyIjogeyJ0eXBlIjogImRucyIsICJ2YWx1ZSI6ICJpcGEtYSJ9LCAicmVzb3VyY2UiOiAibmV3LWF1dGh6In0", "signature": "sDGSJkUMIFVRr7YGU33exEVslJFZlZoTuyv74F_XtloybjzZFg81r8ONbCUXtU6Q1COsA1M9df_vpL1b8Pz2bhfgEkG7taiaHDEyK-PGx5cn9U4vgSp3uZMNfVGFK-0gSYxLIsI0AgEIV8rTVKVw5kHVhn8Ob7gCuBgz1QkGr8WefqAcJ6vxycvbPBXh3GlpHylKDNTEsH5kbdKtfg5bKJu8RDLFBhAZCFub61EwkeT7HfvhsWkaXJQhoolWiFn_3PjAZCEZzPL5igCOW0V65OEp6O3wdnC4FwS0BwxE0CxB2QA2mXMdvX4SILRf5mhzhTOmdTL0gLYXffI1XErbvg"}'} 2016-12-06 20:57:44,728:DEBUG:requests.packages.urllib3.connectionpool:"POST /acme/new-authz HTTP/1.1" 400 109 2016-12-06 20:57:44,730:DEBUG:root:Received . Headers: {'Content-Length': '109', 'Boulder-Request-Id': 'z34CxBq8_BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'close', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Pragma': 'no-cache', 'Boulder-Requester': '6994631', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', 'Content-Type': 'application/problem+json', 'Replay-Nonce': 'YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}. Content: '{\n "type": "urn:acme:error:malformed",\n "detail": "DNS name does not have enough labels",\n "status": 400\n}' 2016-12-06 20:57:44,730:DEBUG:acme.client:Storing nonce: "b\x84\x8d\xa4\xb4\xf5D\x94\x8d\xe6\xd5\x15\x11k\xa3\xaf\x18\xd9\xe0\xbchS\xe8\xca\x9d\xcb'\xd5\xa3}\x1cR" 2016-12-06 20:57:44,730:DEBUG:acme.client:Received response (headers: {'Content-Length': '109', 'Boulder-Request-Id': 'z34CxBq8_BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'close', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Pragma': 'no-cache', 'Boulder-Requester': '6994631', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', 'Content-Type': 'application/problem+json', 'Replay-Nonce': 'YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}): '{\n "type": "urn:acme:error:malformed",\n "detail": "DNS name does not have enough labels",\n "status": 400\n}' 2016-12-06 20:57:44,735:DEBUG:certbot.main:Exiting abnormally: Traceback (most recent call last): File "/usr/bin/letsencrypt", line 9, in load_entry_point('certbot==0.9.3', 'console_scripts', 'certbot')() File "/usr/lib/python2.7/site-packages/certbot/main.py", line 776, in main return config.func(config, plugins) File "/usr/lib/python2.7/site-packages/certbot/main.py", line 566, in obtain_cert _csr_obtain_cert(config, le_client) File "/usr/lib/python2.7/site-packages/certbot/main.py", line 535, in _csr_obtain_cert certr, chain = le_client.obtain_certificate_from_csr(config.domains, csr, typ) File "/usr/lib/python2.7/site-packages/certbot/client.py", line 229, in obtain_certificate_from_csr authzr = self.auth_handler.get_authorizations(domains) File "/usr/lib/python2.7/site-packages/certbot/auth_handler.py", line 68, in get_authorizations domain, self.account.regr.new_authzr_uri) File "/usr/lib/python2.7/site-packages/acme/client.py", line 210, in request_domain_challenges typ=messages.IDENTIFIER_FQDN, value=domain), new_authzr_uri) File "/usr/lib/python2.7/site-packages/acme/client.py", line 190, in request_challenges new_authz) File "/usr/lib/python2.7/site-packages/acme/client.py", line 649, in post return self._check_response(response, content_type=content_type) File "/usr/lib/python2.7/site-packages/acme/client.py", line 565, in _check_response raise messages.Error.from_json(jobj) Error: urn:acme:error:malformed :: The request message was malformed :: DNS name does not have enough labels -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12140 bytes Desc: not available URL: From freeipa-users at redhat.com Tue Dec 6 23:09:11 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 18:09:11 -0500 Subject: [Freeipa-users] lowest-privilege method of checking for out of sync FreeIPA masters? In-Reply-To: References: Message-ID: <58474517.1020201@redhat.com> List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: > Hello, > > There's a method to check the replication status of FreeIPA masters by > looking at objectClass=nsDS5ReplicationAgreement in the "cn=mapping > tree,cn=config" part of LDAP. > > Unfortunately that requires Directory Admin level privileges. > > Is there a method to check those replication agreement details that uses > a much lower privilege? We'd like to add a replication test to our > Zabbix monitoring system, and we don't want to use the directory admin > user ID :) Create a privilege containing the permission "Read Replication Agreements", add that to a new role, and your user to that role and that should do it. rob From freeipa-users at redhat.com Wed Dec 7 02:57:22 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Wed, 7 Dec 2016 09:57:22 +0700 Subject: [Freeipa-users] can manage user access from Serial Console & only use local users in case cannot reach IPA server ? Message-ID: Hi , I'm just testing IPA on CentOS 6, login via ssh is woking fine. I would like to try two steps but didnot find any documents- 1). can we manage user that access from serial interface. 2). in case IPA was failed, can we configure it to use local user Best Regards, sjw -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-users at redhat.com Wed Dec 7 04:32:30 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Tue, 6 Dec 2016 23:32:30 -0500 Subject: [Freeipa-users] Mapping users from AD to IPA KDC In-Reply-To: <20161206203735.l56lefuf5w5hye5t@redhat.com> References: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> <2c4ff955-ab05-80ea-f4ae-da217d21b285@mdevsys.com> <20161205070232.gnntt334q5siv3va@redhat.com> <1ee640af-4739-1e9b-bb49-c10601e6e08d@mdevsys.com> <20161206203735.l56lefuf5w5hye5t@redhat.com> Message-ID: <56356ff9-f7c1-e0a6-7f20-59c9eca07004@mdevsys.com> On 12/6/2016 3:37 PM, Alexander Bokovoy wrote: > On ti, 06 joulu 2016, TomK wrote: >> On 12/5/2016 2:02 AM, Alexander Bokovoy wrote: >>> On su, 04 joulu 2016, TomK wrote: >>>> Could not get much from logs and decided to start fresh. When I run >>>> this: >>>> >>>> ipa trust-add --type=ad mds.xyz --admin Administrator --password >>>> >>>> Trust works fine and id tom at mds.xyz returns a valid result. >>>> >>>> However when I run the following on both masters on a fresh new setup: >>>> >>>> ipa-adtrust-install --netbios-name=NIX -a "" >>>> ipa trust-add --type=ad "mds.xyz" --trust-secret >>>> >>>> and created a trust object in AD DC with the name of NIX and a >>>> non-transitive trust, the above did NOT work. I didn't get anything >>>> by typing id tom at mds.xyz. (I do not get an option for a Forest Trust >>>> as the gif on this page suggests: >>>> https://www.freeipa.org/page/Active_Directory_trust_setup . Possibly >>>> it's Server 2012 hence the difference in what's presented to me but >>>> another reason is that the name I type for the trust can't resolve to >>>> an IP for now: nix.mds.xyz . So I use NIX to match the bios name used >>>> on the ipa-adtrust-install command above. ) >>> The shared secret case for one-way trust is known to be broken. When a >>> shared half is created on AD side first, it is marked as not yet valid >>> by Windows and currently we cannot perform validation of it from IPA >>> side. Validating it from AD side is not possible as well as we don't >>> provide all interfaces Windows would like to use. >>> >>> And the fact you cannot see 'Forest Trust' type of the trust says also >>> that you have problems with reaching IPA masters from AD DC side for >>> probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and >>> UDP). >> Nothing I tried in AD Trust creation allowed me to make one with type >> Forest. Just realm. I recall I had a trust type of Forest but in >> trying various options I lost how I did that. Or perhaps I hadn't >> payed attention and it got created indirectly as part of another >> action I took. The domain functional level I'm using is Windows >> Server 2008. Using a lower value for testing. > This (inability to chose Forest trust type) simply means AD DC is unable > to probe IPA DC. You said below that SMB port towards IPA DC was closed. > > Also make sure to remove incorrect trust from Windows side. While we are > removing a trust object named as our NetBIOS name, it only works for the > proper trusted domain/forests, not for wrong 'realm trust' type. > >> >> My IPA version is 4.2 right now. It came with the CentOS 7.2. >> Looking forward to 4.4. Not sure when you plan to include it as part >> of the latest CentOS base. Indeed some ports were not open (445). >> I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7: >> >> for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp >> 53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp >> 53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd >> --zone=public --permanent --add-port=$KEY; done >> >> [root at idmipa01 ~]# firewall-cmd --zone=public --list-all >> public (default) >> interfaces: >> sources: >> services: dhcpv6-client ntp ssh >> ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp >> 135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp >> 139/udp 138/udp 53/udp 636/tcp >> masquerade: no >> forward-ports: >> icmp-blocks: >> rich rules: >> >> [root at idmipa01 ~]# >> >> On Windows Side (The nslookup results were the same before the >> firewall change however.): > Firewall changes cannot affect DNS as you already had DNS port open. > >> On the AD side, I added the SRV records for the second AD DC, >> manually, since earlier there were no results printed on the AD DC >> command line for the second AD DC, when I typed the command >> _ldap._tcp.mds.xyz. >> >> One additional question I had with the setup is in regards to the >> failover. I see the ipa_server entry in /etc/sssd/sssd.conf pointing >> to two of the master IPA nodes. Where can I find the additional >> settings that control priority of the listed server or order they are >> checked? > You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections > FAILOVER and SERVICE DISCOVER. > >> What I ran to get the above is: >> >> 1) ipa-client-install --force-join -p admin -w "" >> --fixed-primary --server=idmipa01.nix.mds.xyz >> --server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ -U >> 2) realm join mds.xyz > This is wrong. You have effectively joined this IPA client to AD and IPA > at the same time. It should not be done this way (read > http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain > for details). > > Instead, you need to identify why the trust does not work properly. > Use tcpdump to intercept the traffic between your AD DCs and IPA DCs > while establishing the trust. > > You can send the trace to me off-list. > > > Ok, let me take these away and get back to you. ( On realm, thank you. Hadn't reviewed the changes it did fully before logging off. ) -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From freeipa-users at redhat.com Wed Dec 7 07:37:35 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Wed, 7 Dec 2016 08:37:35 +0100 Subject: [Freeipa-users] can manage user access from Serial Console & only use local users in case cannot reach IPA server ? In-Reply-To: References: Message-ID: <20161207073735.dj5k63xc5g6cix5j@hendrix> On Wed, Dec 07, 2016 at 09:57:22AM +0700, List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: > Hi , > I'm just testing IPA on CentOS 6, login via ssh is woking fine. > > I would like to try two steps but didnot find any documents- > 1). can we manage user that access from serial interface. > 2). in case IPA was failed, can we configure it to use local user Note that sssd caches user lookups and even credential hashes, so provided your user logged in at least once before, he would be able to log in even during a server outage. From freeipa-users at redhat.com Wed Dec 7 07:48:08 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Wed, 7 Dec 2016 08:48:08 +0100 Subject: [Freeipa-users] What should the --hostname option do? Message-ID: <20161207074808.GA12252@redhat.com> Hello, the --hostname option to the installer currently modifies the hostname of the machine. In some environments, namely in unprivileged containers, that operation is not denied. In some cases, it is possible to change the FQDN of the container from outside, for example with docker run's -h option. However, in some environments, namely in OpenShift, there is not such possibility. I have found out that disabling the change by turning /bin/hostnamectl and /usr/bin/domainname makes ipa-server-install pass while the server gets configured with the hostname specified as the parameter to --hostname option so it does not seem to be essential for the FQDN to change. Of course, some operations might no longer work, like ssh to the FreeIPA machine as sshd would need to be set with GSSAPIStrictAcceptorCheck no. I wonder if either change of the --hostname semantics, or some new option would be useful, to specify the hostname to be used by the FreeIPA software while not touching the configuration of the hostname for the machine. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From freeipa-users at redhat.com Wed Dec 7 08:22:35 2016 From: freeipa-users at redhat.com (List dedicated to discussions about use, configuration and deployment of the IPA server.) Date: Wed, 7 Dec 2016 10:22:35 +0200 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. Message-ID: I know the Quick Start Guide and Deployment Recommendations cover this in depth, but there are still some ambiguities. I'm trying to figure out if a company like us, lautus.net should use a DNS subdomain like ipa.lautus.net for the IPA domain, or not. On the one hand 2.3.1 of the Linux Domain Identity, Authentication, and Policy Guide says "The integrated DNS server provided by IdM is not designed to be used as a general-purpose DNS server. It only supports features related to IdM deployment and maintenance". OK, so lautus.net should continue to be hosted by DNS servers elsewhere that delegate say, ipa.lautus.net to FreeIPA. But on the other hand the same doc is full of examples where a Kerberos realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example 2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm should be the same as the ipa DNS domain, just uppercased. So example 2.2. implies that example.com is running their DNS domain on FreeIPA, for everything, not just for IPA SRV and TXT entries. And when ipa-client-install is run on somehost.lautus.net, it also defaults to LAUTUS.NET for Kerberos domain, as if the default expectation is that your toplevel company DNS name would be your kerberos domain. And when I install a trial IPA server on host ipa-server-1.lautus.net using "ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones in the Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS ipa-server-1.lautus.net". In other words the IPA server defaults to thinking it owns the domain above ipa.lautus.net too. Which goes against 2.3.1 above. The docs say I should manually add SRV records to a parent DNS domain like lautus.net if IPA does not manage that with integrated DNS. But then what's the point of the integrated DNS, if the docs say the integrated DNS is not supposed to be used as a general-purpose DNS server? In that case, everybody is always gonna need to manually add SRV records every time they add a IPA replication peer anyway, unless they run their company DNS on the integrated DNS server, which the docs seem to discourage? -- Pieter Nagel Lautus Solutions (Pty) Ltd Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng 0832587540 -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-users at redhat.com Wed Dec 7 08:58:19 2016 From: freeipa-users at redhat.com (freeIPA users list) Date: Wed, 7 Dec 2016 10:58:19 +0200 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: References: Message-ID: <20161207085819.q5onuspvbrog6hee@redhat.com> On ke, 07 joulu 2016, List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: >I know the Quick Start Guide and Deployment Recommendations cover this in >depth, but there are still some ambiguities. > >I'm trying to figure out if a company like us, lautus.net should use a DNS >subdomain like ipa.lautus.net for the IPA domain, or not. It is really depending on your deployment details. If you already have some other Kerberized environment in place and you are not going to replace it by FreeIPA, then you need to make sure that new FreeIPA deployment would not conflict with the existing one. This is the rule dictated by the way how Kerberos realms are organized and particularly so for Active Directory deployments as that one has even more serious limitations towards what can be part of the Active Directory domain/forest structure. >On the one hand 2.3.1 of the Linux Domain Identity, Authentication, and >Policy Guide says "The integrated DNS server provided by IdM is not >designed to be used as a general-purpose DNS server. It only supports >features related to IdM deployment and maintenance". OK, so lautus.net >should continue to be hosted by DNS servers elsewhere that delegate say, >ipa.lautus.net to FreeIPA. You definitely can use IPA DNS server for the purpose of hosting your primary DNS servers if all features provided by IPA DNS server cover your needs. As I said, it really depends on your specific deployment considerations. The guide is trying to hint that all things that ISC BIND supports aren't necessarily will be working in the IPA version -- like a split-horizon feature -- so it is not a general-purpose DNS server in that sense. >But on the other hand the same doc is full of examples where a Kerberos >realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example >2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm >should be the same as the ipa DNS domain, just uppercased. So example 2.2. >implies that example.com is running their DNS domain on FreeIPA, for >everything, not just for IPA SRV and TXT entries. It assumes for the most of configurations that you are setting up FreeIPA as the only Kerberos environment, thus talking about EXAMPLE.COM. >And when ipa-client-install is run on somehost.lautus.net, it also defaults >to LAUTUS.NET for Kerberos domain, as if the default expectation is that >your toplevel company DNS name would be your kerberos domain. Yes, as with *any* decent Kerberos implementation. >And when I install a trial IPA server on host ipa-server-1.lautus.net using >"ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain >ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones in the >Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS >ipa-server-1.lautus.net". In other words the IPA server defaults to >thinking it owns the domain above ipa.lautus.net too. Which goes against >2.3.1 above. Yes and no. What you see with "@ NS ..." is a glue record -- you are supposed to have a glue record for IPA domain in the upstream domain, this is how domain delegation works in DNS world. >The docs say I should manually add SRV records to a parent DNS domain like >lautus.net if IPA does not manage that with integrated DNS. But then what's >the point of the integrated DNS, if the docs say the integrated DNS is not >supposed to be used as a general-purpose DNS server? In that case, >everybody is always gonna need to manually add SRV records every time they >add a IPA replication peer anyway, unless they run their company DNS on the >integrated DNS server, which the docs seem to discourage? See above. -- / Alexander Bokovoy From simo at redhat.com Wed Dec 7 09:03:15 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 07 Dec 2016 04:03:15 -0500 Subject: [Freeipa-users] Reverting anonymous posting Message-ID: <1481101395.4311.161.camel@redhat.com> Enough people complained they cannot cope with the change I made recently. So I am reverting this change and will try to find a better solution for the spam issue the list user's are subject to. Thanks for your understanding, Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Wed Dec 7 09:50:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Dec 2016 10:50:13 +0100 Subject: [Freeipa-users] What should the --hostname option do? In-Reply-To: <20161207074808.GA12252@redhat.com> References: <20161207074808.GA12252@redhat.com> Message-ID: On 07.12.2016 08:48, List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: > Hello, > > the --hostname option to the installer currently modifies the hostname > of the machine. In some environments, namely in unprivileged > containers, that operation is not denied. In some cases, it is > possible to change the FQDN of the container from outside, for example > with docker run's -h option. However, in some environments, namely in > OpenShift, there is not such possibility. > > I have found out that disabling the change by turning /bin/hostnamectl > and /usr/bin/domainname makes ipa-server-install pass while the server > gets configured with the hostname specified as the parameter to > --hostname option so it does not seem to be essential for the FQDN to > change. Of course, some operations might no longer work, like ssh to > the FreeIPA machine as sshd would need to be set with > GSSAPIStrictAcceptorCheck no. > > I wonder if either change of the --hostname semantics, or some new > option would be useful, to specify the hostname to be used by the > FreeIPA software while not touching the configuration of the hostname > for the machine. > I agree that --hostname options should not touch system's hostname, I don't see reason why application installer should change system hostname. I'd start with deprecating current behavior of this option in next release As you mentioned we need find what cases can be broken when we will use different local and external hostname, but anyway we have do this for containers. Martin^2 From sbose at redhat.com Wed Dec 7 10:11:48 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 7 Dec 2016 11:11:48 +0100 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <58471CDD.8070703@sonsorol.org> References: <5846F92E.3010900@sonsorol.org> <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58471CDD.8070703@sonsorol.org> Message-ID: <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> On Tue, Dec 06, 2016 at 03:17:33PM -0500, List dedicated to discussions about use, configuration and deployment of the IPA server. wrote: > > Appreciate the assistance! > > Is there a better debug level balance than 10 for this sort of situation? > The domain logs were several hundred MBs by the time I started looking for > useful info if there is a different level I can use that would better at > producing actionable error/log messages I'll gladly switch ... > > > List dedicated to discussions about use, configuration and deployment of the > IPA server. wrote: > > > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [main] (0x0400): > > > > krb5_child started. > > > > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [unpack_buffer] > > > > (0x1000): total buffer size: [158] > > > > (Tue Dec 6 15:36:48 2016) [[sssd[krb5_child[4005]]]] [unpack_buffer] > > > > (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false] > > > > enterprise principal [false] offline [true] UPN [user at COMPANY.ORG] > > > > ^^^^^^^^^^^^^^^ > > > > The backend switch to offline mode, please send the SSSD domain logs > > around this time as well. If possible please start about 5 minutes > > earlier. > > > > bye, > > Sumit > > I searched through the massive SSSD domain logs and had trouble finding the > right area so here are the lines surrounding my own username when I tried to > authenticate via SSH using AD credentials: > > ... > ... > [sss_krb5_expire_callback_func] (0x2000): exp_time: [2742397] > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [get_and_save_tgt] > (0x0100): TGT validation is disabled. > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] > [sss_get_ccache_name_for_principal] (0x4000): Location: > [KEYRING:persistent:1843770609] > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] > [sss_get_ccache_name_for_principal] (0x4000): tmp_ccname: > [KEYRING:persistent:1843770609:krb_ccache_OVBc5zF] > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [create_ccache] > (0x4000): Initializing ccache of type [KEYRING] > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [create_ccache] > (0x4000): CC supports switch > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [create_ccache] > (0x4000): returning: 0 > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] > [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the > same, none will be deleted. > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] > [pack_response_packet] (0x2000): response packet size: [144] > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [k5c_send_data] > (0x4000): Response sent. > (Tue Dec 6 19:57:11 2016) [[sssd[krb5_child[12406]]]] [main] (0x0400): > krb5_child completed successfully ... > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] > [sss_krb5_expire_callback_func] (0x2000): exp_time: [2742394] > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [get_and_save_tgt] > (0x0100): TGT validation is disabled. > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] > [sss_get_ccache_name_for_principal] (0x4000): Location: > [KEYRING:persistent:1843770609] > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] > [sss_get_ccache_name_for_principal] (0x4000): tmp_ccname: > [KEYRING:persistent:1843770609:krb_ccache_OVBc5zF] > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [create_ccache] > (0x4000): Initializing ccache of type [KEYRING] > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [create_ccache] > (0x4000): CC supports switch > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [create_ccache] > (0x4000): returning: 0 > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] > [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the > same, none will be deleted. > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [k5c_send_data] > (0x0200): Received error code 0 > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] > [pack_response_packet] (0x2000): response packet size: [144] > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [k5c_send_data] > (0x4000): Response sent. > (Tue Dec 6 19:57:14 2016) [[sssd[krb5_child[12417]]]] [main] (0x0400): > krb5_child completed successfully > > Both authentications where successful against the backend. For the logs it looks like you use an alternative domain suffix on the AD side so that all user if other domains in the forest can use the forest root suffix as realm, in the user principal (user at NAFTA.COMPANY.ORG -> user at COMPANY.ORG). I would expect that there are messages like "UPN used in the request ...differ by more than just the case." in the domain log at 'Tue Dec 6 19:57:11' and 'Tue Dec 6 19:57:14'. If that's the case updating to 4.4 would help because in this release IPA can forward the enterprise principals properly and SSSD will not reject the changed principal because sSSD will be aware of the change. But there are workarounds to make it work with your version as well, please see e.g. the suggestion from https://www.redhat.com/archives/freeipa-users/2016-May/msg00205.html . HTH bye, Sumit From th at casalogic.dk Wed Dec 7 10:13:33 2016 From: th at casalogic.dk (Troels Hansen) Date: Wed, 7 Dec 2016 11:13:33 +0100 (CET) Subject: [Freeipa-users] Services missing in web-ui Message-ID: <1142144358.1147148.1481105613460.JavaMail.zimbra@casalogic.dk> I have a strange issue in IPA 4.4.0-12 (RHEL 7.3) Navigating to Identity -> Services reveals 5 services. 2 cifs, 2 dogtag and one empty line... cifs/host1.domain at REALM cifs/host2.domain at REALM dogtag/ipa01.domain at REALM dogtag/ipa02.domain at REALM However, from CLI everything looks OK: # ipa service-find ------------------- 11 services matched ------------------- Principal name: ldap/ipa02.domain at REALM Principal alias: ldap/ipa02.domain at REALM Certificate: ....... ....... Keytab: True Principal name: ldap/ipa01.domain at REALM Principal alias: ldap/ipa01.domain at REALM Certificate: ....... ....... Keytab: True Principal name: HTTP/ipa02.domain at REALM Principal alias: HTTP/ipa02.domain at REALM Certificate: ........ ....... Keytab: True Principal name: cifs/rhellxudv01.domain at REALM Principal alias: cifs/rhellxudv01.domain at REALM Keytab: True Principal name: cifs/ipa02.domain at REALM Principal alias: cifs/ipa02.domain at REALM Keytab: True Principal name: nfs/profil01.domain at REALM Principal alias: nfs/profil01.domain at REALM Keytab: True Principal name: cifs/ipa01.domain at REALM Principal alias: cifs/ipa01.domain at REALM Keytab: True Principal name: dogtag/ipa02.domain at REALM Principal alias: dogtag/ipa02.domain at REALM Keytab: True Principal name: dogtag/ipa01.domain at REALM Principal alias: dogtag/ipa01.domain at REALM Keytab: True Principal name: cifs/rhellxudv02.domain at REALM Principal alias: cifs/rhellxudv02.domain at REALM Keytab: True Principal name: HTTP/ipa01.domain at REALM Principal alias: HTTP/ipa01.domain at REALM Certificate: .............. .............. Keytab: True ----------------------------- Number of entries returned 11 ----------------------------- (some lines truncated.....) soooo... somsthing must be disrupting the view in web-ui, Tried in Chrome 43 and IE 11 Looking at what gets requested by the browser at /ipa/session/json I can see in the json that it gets the correct content: result: {count: 11, result: [,?], summary: "11 services matched", truncated: false} count: 11 result: [,?] 0: {dn: "krbprincipalname=cifs/rhellxudv01.domain at REALM,cn=services,cn=accounts,dc=domain",?} 1: {dn: "krbprincipalname=dogtag/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} 2: {dn: "krbprincipalname=nfs/profil01.domain at REALM,cn=services,cn=accounts,dc=domain",?} 3: {dn: "krbprincipalname=cifs/rhellxudv02.domain at REALM,cn=services,cn=accounts,dc=domain",?} 4: {dn: "krbprincipalname=dogtag/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} 5: {dn: "krbprincipalname=HTTP/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} 6: {dn: "krbprincipalname=cifs/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} 7: {dn: "krbprincipalname=cifs/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} 8: {dn: "krbprincipalname=ldap/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} 9: {dn: "krbprincipalname=HTTP/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} 10: {dn: "krbprincipalname=ldap/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} summary: "11 services matched" truncated: false So this is obviously only a web-ui problem, but I can't see what causes the problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fujisan43 at gmail.com Wed Dec 7 10:46:45 2016 From: fujisan43 at gmail.com (Fujisan) Date: Wed, 7 Dec 2016 11:46:45 +0100 Subject: [Freeipa-users] Services missing in web-ui In-Reply-To: <1142144358.1147148.1481105613460.JavaMail.zimbra@casalogic.dk> References: <1142144358.1147148.1481105613460.JavaMail.zimbra@casalogic.dk> Message-ID: I have the same issue with version 4.4.2 $ rpm -qa|grep freeipa freeipa-server-4.4.2-1.fc25.x86_64 freeipa-python-compat-4.4.2-1.fc25.noarch freeipa-server-common-4.4.2-1.fc25.noarch freeipa-common-4.4.2-1.fc25.noarch freeipa-server-trust-ad-4.4.2-1.fc25.x86_64 freeipa-client-4.4.2-1.fc25.x86_64 freeipa-client-common-4.4.2-1.fc25.noarch ?F.? On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen wrote: > I have a strange issue in IPA 4.4.0-12 (RHEL 7.3) > > > Navigating to Identity -> Services reveals 5 services. 2 cifs, 2 dogtag > and one empty line... > > cifs/host1.domain at REALM > cifs/host2.domain at REALM > dogtag/ipa01.domain at REALM > dogtag/ipa02.domain at REALM > > > > However, from CLI everything looks OK: > > # ipa service-find > ------------------- > 11 services matched > ------------------- > Principal name: ldap/ipa02.domain at REALM > Principal alias: ldap/ipa02.domain at REALM > Certificate: ....... > ....... > > > Keytab: True > > Principal name: ldap/ipa01.domain at REALM > Principal alias: ldap/ipa01.domain at REALM > Certificate: ....... > ....... > > > Keytab: True > > Principal name: HTTP/ipa02.domain at REALM > Principal alias: HTTP/ipa02.domain at REALM > Certificate: ........ > ....... > > > > Keytab: True > > Principal name: cifs/rhellxudv01.domain at REALM > Principal alias: cifs/rhellxudv01.domain at REALM > Keytab: True > > > > Principal name: cifs/ipa02.domain at REALM > Principal alias: cifs/ipa02.domain at REALM > Keytab: True > > > > Principal name: nfs/profil01.domain at REALM > Principal alias: nfs/profil01.domain at REALM > Keytab: True > > > > Principal name: cifs/ipa01.domain at REALM > Principal alias: cifs/ipa01.domain at REALM > Keytab: True > > Principal name: dogtag/ipa02.domain at REALM > Principal alias: dogtag/ipa02.domain at REALM > Keytab: True > > > > Principal name: dogtag/ipa01.domain at REALM > Principal alias: dogtag/ipa01.domain at REALM > Keytab: True > > > > Principal name: cifs/rhellxudv02.domain at REALM > Principal alias: cifs/rhellxudv02.domain at REALM > Keytab: True > > > > Principal name: HTTP/ipa01.domain at REALM > Principal alias: HTTP/ipa01.domain at REALM > Certificate: .............. > .............. > Keytab: True > > > > ----------------------------- > Number of entries returned 11 > ----------------------------- > > > > > (some lines truncated.....) > > > soooo... somsthing must be disrupting the view in web-ui, > > > Tried in Chrome 43 and IE 11 > > > Looking at what gets requested by the browser at /ipa/session/json I can > see in the json that it gets the correct content: > > > result: {count: 11, result: [,?], summary: "11 services matched", > truncated: false} > count: 11 > result: [,?] > 0: {dn: "krbprincipalname=cifs/rhellxudv01.domain at REALM,cn=services, > cn=accounts,dc=domain",?} > 1: {dn: "krbprincipalname=dogtag/ipa01.domain at REALM,cn=services,cn= > accounts,dc=domain",?} > 2: {dn: "krbprincipalname=nfs/profil01.domain at REALM,cn=services,cn= > accounts,dc=domain",?} > 3: {dn: "krbprincipalname=cifs/rhellxudv02.domain at REALM,cn=services, > cn=accounts,dc=domain",?} > 4: {dn: "krbprincipalname=dogtag/ipa02.domain at REALM,cn=services,cn= > accounts,dc=domain",?} > 5: {dn: "krbprincipalname=HTTP/ipa01.domain at REALM,cn=services,cn=acc > ounts,dc=domain",?} > 6: {dn: "krbprincipalname=cifs/ipa02.domain at REALM,cn=services,cn=acc > ounts,dc=domain",?} > 7: {dn: "krbprincipalname=cifs/ipa01.domain at REALM,cn=services,cn=acc > ounts,dc=domain",?} > 8: {dn: "krbprincipalname=ldap/ipa01.domain at REALM,cn=services,cn=acc > ounts,dc=domain",?} > 9: {dn: "krbprincipalname=HTTP/ipa02.domain at REALM,cn=services,cn=acc > ounts,dc=domain",?} > 10: {dn: "krbprincipalname=ldap/ipa02.domain at REALM,cn=services,cn=acc > ounts,dc=domain",?} > summary: "11 services matched" > truncated: false > > > > So this is obviously only a web-ui problem, but I can't see what causes > the problem? > > -- > Manage your subscription for 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 fujisan43 at gmail.com Wed Dec 7 10:48:56 2016 From: fujisan43 at gmail.com (Fujisan) Date: Wed, 7 Dec 2016 11:48:56 +0100 Subject: [Freeipa-users] Services missing in web-ui In-Reply-To: References: <1142144358.1147148.1481105613460.JavaMail.zimbra@casalogic.dk> Message-ID: And with Firefox 50.0.2. F. On Wed, Dec 7, 2016 at 11:46 AM, Fujisan wrote: > I have the same issue with version 4.4.2 > > $ rpm -qa|grep freeipa > freeipa-server-4.4.2-1.fc25.x86_64 > freeipa-python-compat-4.4.2-1.fc25.noarch > freeipa-server-common-4.4.2-1.fc25.noarch > freeipa-common-4.4.2-1.fc25.noarch > freeipa-server-trust-ad-4.4.2-1.fc25.x86_64 > freeipa-client-4.4.2-1.fc25.x86_64 > freeipa-client-common-4.4.2-1.fc25.noarch > > > ?F.? > > > On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen wrote: > >> I have a strange issue in IPA 4.4.0-12 (RHEL 7.3) >> >> >> Navigating to Identity -> Services reveals 5 services. 2 cifs, 2 dogtag >> and one empty line... >> >> cifs/host1.domain at REALM >> cifs/host2.domain at REALM >> dogtag/ipa01.domain at REALM >> dogtag/ipa02.domain at REALM >> >> >> >> However, from CLI everything looks OK: >> >> # ipa service-find >> ------------------- >> 11 services matched >> ------------------- >> Principal name: ldap/ipa02.domain at REALM >> Principal alias: ldap/ipa02.domain at REALM >> Certificate: ....... >> ....... >> >> >> Keytab: True >> >> Principal name: ldap/ipa01.domain at REALM >> Principal alias: ldap/ipa01.domain at REALM >> Certificate: ....... >> ....... >> >> >> Keytab: True >> >> Principal name: HTTP/ipa02.domain at REALM >> Principal alias: HTTP/ipa02.domain at REALM >> Certificate: ........ >> ....... >> >> >> >> Keytab: True >> >> Principal name: cifs/rhellxudv01.domain at REALM >> Principal alias: cifs/rhellxudv01.domain at REALM >> Keytab: True >> >> >> >> Principal name: cifs/ipa02.domain at REALM >> Principal alias: cifs/ipa02.domain at REALM >> Keytab: True >> >> >> >> Principal name: nfs/profil01.domain at REALM >> Principal alias: nfs/profil01.domain at REALM >> Keytab: True >> >> >> >> Principal name: cifs/ipa01.domain at REALM >> Principal alias: cifs/ipa01.domain at REALM >> Keytab: True >> >> Principal name: dogtag/ipa02.domain at REALM >> Principal alias: dogtag/ipa02.domain at REALM >> Keytab: True >> >> >> >> Principal name: dogtag/ipa01.domain at REALM >> Principal alias: dogtag/ipa01.domain at REALM >> Keytab: True >> >> >> >> Principal name: cifs/rhellxudv02.domain at REALM >> Principal alias: cifs/rhellxudv02.domain at REALM >> Keytab: True >> >> >> >> Principal name: HTTP/ipa01.domain at REALM >> Principal alias: HTTP/ipa01.domain at REALM >> Certificate: .............. >> .............. >> Keytab: True >> >> >> >> ----------------------------- >> Number of entries returned 11 >> ----------------------------- >> >> >> >> >> (some lines truncated.....) >> >> >> soooo... somsthing must be disrupting the view in web-ui, >> >> >> Tried in Chrome 43 and IE 11 >> >> >> Looking at what gets requested by the browser at /ipa/session/json I can >> see in the json that it gets the correct content: >> >> >> result: {count: 11, result: [,?], summary: "11 services matched", >> truncated: false} >> count: 11 >> result: [,?] >> 0: {dn: "krbprincipalname=cifs/rhellxudv01.domain at REALM,cn=services, >> cn=accounts,dc=domain",?} >> 1: {dn: "krbprincipalname=dogtag/ipa01.domain at REALM,cn=services,cn=a >> ccounts,dc=domain",?} >> 2: {dn: "krbprincipalname=nfs/profil01.domain at REALM,cn=services,cn=a >> ccounts,dc=domain",?} >> 3: {dn: "krbprincipalname=cifs/rhellxudv02.domain at REALM,cn=services, >> cn=accounts,dc=domain",?} >> 4: {dn: "krbprincipalname=dogtag/ipa02.domain at REALM,cn=services,cn=a >> ccounts,dc=domain",?} >> 5: {dn: "krbprincipalname=HTTP/ipa01.domain at REALM,cn=services,cn=acc >> ounts,dc=domain",?} >> 6: {dn: "krbprincipalname=cifs/ipa02.domain at REALM,cn=services,cn=acc >> ounts,dc=domain",?} >> 7: {dn: "krbprincipalname=cifs/ipa01.domain at REALM,cn=services,cn=acc >> ounts,dc=domain",?} >> 8: {dn: "krbprincipalname=ldap/ipa01.domain at REALM,cn=services,cn=acc >> ounts,dc=domain",?} >> 9: {dn: "krbprincipalname=HTTP/ipa02.domain at REALM,cn=services,cn=acc >> ounts,dc=domain",?} >> 10: {dn: "krbprincipalname=ldap/ipa02.domain at REALM,cn=services,cn=acc >> ounts,dc=domain",?} >> summary: "11 services matched" >> truncated: false >> >> >> >> So this is obviously only a web-ui problem, but I can't see what causes >> the problem? >> >> -- >> Manage your subscription for 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 pvomacka at redhat.com Wed Dec 7 10:58:55 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 7 Dec 2016 11:58:55 +0100 Subject: [Freeipa-users] Services missing in web-ui In-Reply-To: References: <1142144358.1147148.1481105613460.JavaMail.zimbra@casalogic.dk> Message-ID: Hello, it is caused by missing canonical name on services which were created in older versions of FreeIPA. Fixed ticket here: https://fedorahosted.org/freeipa/ticket/6397 . On 12/07/2016 11:48 AM, Fujisan wrote: > And with Firefox 50.0.2. > > F. > > On Wed, Dec 7, 2016 at 11:46 AM, Fujisan > wrote: > > I have the same issue with version 4.4.2 > > $ rpm -qa|grep freeipa > freeipa-server-4.4.2-1.fc25.x86_64 > freeipa-python-compat-4.4.2-1.fc25.noarch > freeipa-server-common-4.4.2-1.fc25.noarch > freeipa-common-4.4.2-1.fc25.no > arch > freeipa-server-trust-ad-4.4.2-1.fc25.x86_64 > freeipa-client-4.4.2-1.fc25.x86_64 > freeipa-client-common-4.4.2-1.fc25.noarch > > > ?F.? > > > On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen > wrote: > > I have a strange issue in IPA 4.4.0-12 (RHEL 7.3) > > > Navigating to Identity -> Services reveals 5 services. 2 cifs, > 2 dogtag and one empty line... > > cifs/host1.domain at REALM > cifs/host2.domain at REALM > dogtag/ipa01.domain at REALM > dogtag/ipa02.domain at REALM > > > > However, from CLI everything looks OK: > > # ipa service-find > ------------------- > 11 services matched > ------------------- > Principal name: ldap/ipa02.domain at REALM > Principal alias: ldap/ipa02.domain at REALM > Certificate: ....... > ....... > > > Keytab: True > > Principal name: ldap/ipa01.domain at REALM > Principal alias: ldap/ipa01.domain at REALM > Certificate: ....... > ....... > > > Keytab: True > > Principal name: HTTP/ipa02.domain at REALM > Principal alias: HTTP/ipa02.domain at REALM > Certificate: ........ > ....... > > > > Keytab: True > > Principal name: cifs/rhellxudv01.domain at REALM > Principal alias: cifs/rhellxudv01.domain at REALM > Keytab: True > > > > Principal name: cifs/ipa02.domain at REALM > Principal alias: cifs/ipa02.domain at REALM > Keytab: True > > > > Principal name: nfs/profil01.domain at REALM > Principal alias: nfs/profil01.domain at REALM > Keytab: True > > > > Principal name: cifs/ipa01.domain at REALM > Principal alias: cifs/ipa01.domain at REALM > Keytab: True > > Principal name: dogtag/ipa02.domain at REALM > Principal alias: dogtag/ipa02.domain at REALM > Keytab: True > > > > Principal name: dogtag/ipa01.domain at REALM > Principal alias: dogtag/ipa01.domain at REALM > Keytab: True > > > > Principal name: cifs/rhellxudv02.domain at REALM > Principal alias: cifs/rhellxudv02.domain at REALM > Keytab: True > > > > Principal name: HTTP/ipa01.domain at REALM > Principal alias: HTTP/ipa01.domain at REALM > Certificate: .............. > .............. > Keytab: True > > > > ----------------------------- > Number of entries returned 11 > ----------------------------- > > > > > (some lines truncated.....) > > > soooo... somsthing must be disrupting the view in web-ui, > > > Tried in Chrome 43 and IE 11 > > > Looking at what gets requested by the browser at > /ipa/session/json I can see in the json that it gets the > correct content: > > > result: {count: 11, result: [,?], summary: "11 services > matched", truncated: false} > count: 11 > result: [,?] > 0: {dn: > "krbprincipalname=cifs/rhellxudv01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 1: {dn: > "krbprincipalname=dogtag/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 2: {dn: > "krbprincipalname=nfs/profil01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 3: {dn: > "krbprincipalname=cifs/rhellxudv02.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 4: {dn: > "krbprincipalname=dogtag/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 5: {dn: > "krbprincipalname=HTTP/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 6: {dn: > "krbprincipalname=cifs/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 7: {dn: > "krbprincipalname=cifs/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 8: {dn: > "krbprincipalname=ldap/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 9: {dn: > "krbprincipalname=HTTP/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 10: {dn: > "krbprincipalname=ldap/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} > summary: "11 services matched" > truncated: false > > > > So this is obviously only a web-ui problem, but I can't see > what causes the problem? > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > > > > -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: From th at casalogic.dk Wed Dec 7 11:43:09 2016 From: th at casalogic.dk (Troels Hansen) Date: Wed, 7 Dec 2016 12:43:09 +0100 (CET) Subject: [Freeipa-users] Services missing in web-ui In-Reply-To: References: <1142144358.1147148.1481105613460.JavaMail.zimbra@casalogic.dk> Message-ID: <64734557.1149689.1481110989323.JavaMail.zimbra@casalogic.dk> Looks great...... Pavel, as a RedHat internal, should I create a ticket to have this fixed in the RedHat version, or does it already have a internal Red Hat bugzilla case? ----- On Dec 7, 2016, at 11:58 AM, Pavel Vomacka wrote: > Hello, > it is caused by missing canonical name on services which were created in older > versions of FreeIPA. Fixed ticket here: > https://fedorahosted.org/freeipa/ticket/6397 . > On 12/07/2016 11:48 AM, Fujisan wrote: >> And with Firefox 50.0.2. >> F. >> On Wed, Dec 7, 2016 at 11:46 AM, Fujisan < fujisan43 at gmail.com > wrote: >>> I have the same issue with version 4.4.2 >>> $ rpm -qa|grep freeipa >>> freeipa-server-4.4.2-1.fc25.x86_64 >>> freeipa-python-compat-4.4.2-1.fc25.noarch >>> freeipa-server-common-4.4.2-1.fc25.noarch >>> freeipa-common-4.4.2-1.fc25.no arch >>> freeipa-server-trust-ad-4.4.2-1.fc25.x86_64 >>> freeipa-client-4.4.2-1.fc25.x86_64 >>> freeipa-client-common-4.4.2-1.fc25.noarch >>> ?F.? >>> On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen < th at casalogic.dk > wrote: >>>> I have a strange issue in IPA 4.4.0-12 (RHEL 7.3) >>>> Navigating to Identity -> Services reveals 5 services. 2 cifs, 2 dogtag and one >>>> empty line... >>>> cifs/host1.domain at REALM >>>> cifs/host2.domain at REALM >>>> dogtag/ipa01.domain at REALM >>>> dogtag/ipa02.domain at REALM >>>> However, from CLI everything looks OK: >>>> # ipa service-find >>>> ------------------- >>>> 11 services matched >>>> ------------------- >>>> Principal name: ldap/ipa02.domain at REALM >>>> Principal alias: ldap/ipa02.domain at REALM >>>> Certificate: ....... >>>> ....... >>>> Keytab: True >>>> Principal name: ldap/ipa01.domain at REALM >>>> Principal alias: ldap/ipa01.domain at REALM >>>> Certificate: ....... >>>> ....... >>>> Keytab: True >>>> Principal name: HTTP/ipa02.domain at REALM >>>> Principal alias: HTTP/ipa02.domain at REALM >>>> Certificate: ........ >>>> ....... >>>> Keytab: True >>>> Principal name: cifs/rhellxudv01.domain at REALM >>>> Principal alias: cifs/rhellxudv01.domain at REALM >>>> Keytab: True >>>> Principal name: cifs/ipa02.domain at REALM >>>> Principal alias: cifs/ipa02.domain at REALM >>>> Keytab: True >>>> Principal name: nfs/profil01.domain at REALM >>>> Principal alias: nfs/profil01.domain at REALM >>>> Keytab: True >>>> Principal name: cifs/ipa01.domain at REALM >>>> Principal alias: cifs/ipa01.domain at REALM >>>> Keytab: True >>>> Principal name: dogtag/ipa02.domain at REALM >>>> Principal alias: dogtag/ipa02.domain at REALM >>>> Keytab: True >>>> Principal name: dogtag/ipa01.domain at REALM >>>> Principal alias: dogtag/ipa01.domain at REALM >>>> Keytab: True >>>> Principal name: cifs/rhellxudv02.domain at REALM >>>> Principal alias: cifs/rhellxudv02.domain at REALM >>>> Keytab: True >>>> Principal name: HTTP/ipa01.domain at REALM >>>> Principal alias: HTTP/ipa01.domain at REALM >>>> Certificate: .............. >>>> .............. >>>> Keytab: True >>>> ----------------------------- >>>> Number of entries returned 11 >>>> ----------------------------- >>>> (some lines truncated.....) >>>> soooo... somsthing must be disrupting the view in web-ui, >>>> Tried in Chrome 43 and IE 11 >>>> Looking at what gets requested by the browser at /ipa/session/json I can see in >>>> the json that it gets the correct content: >>>> result: {count: 11, result: [,?], summary: "11 services matched", truncated: >>>> false} >>>> count: 11 >>>> result: [,?] >>>> 0: {dn: >>>> "krbprincipalname=cifs/rhellxudv01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> 1: {dn: >>>> "krbprincipalname=dogtag/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> 2: {dn: >>>> "krbprincipalname=nfs/profil01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> 3: {dn: >>>> "krbprincipalname=cifs/rhellxudv02.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> 4: {dn: >>>> "krbprincipalname=dogtag/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> 5: {dn: >>>> "krbprincipalname=HTTP/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> 6: {dn: >>>> "krbprincipalname=cifs/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> 7: {dn: >>>> "krbprincipalname=cifs/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> 8: {dn: >>>> "krbprincipalname=ldap/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> 9: {dn: >>>> "krbprincipalname=HTTP/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> 10: {dn: >>>> "krbprincipalname=ldap/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>> summary: "11 services matched" >>>> truncated: false >>>> So this is obviously only a web-ui problem, but I can't see what causes the >>>> problem? >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go to http://freeipa.org for more info on the project > -- > Pavel^3 Vomacka -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From th at casalogic.dk Wed Dec 7 12:26:08 2016 From: th at casalogic.dk (Troels Hansen) Date: Wed, 7 Dec 2016 13:26:08 +0100 (CET) Subject: [Freeipa-users] Services missing in web-ui In-Reply-To: <64734557.1149689.1481110989323.JavaMail.zimbra@casalogic.dk> References: <1142144358.1147148.1481105613460.JavaMail.zimbra@casalogic.dk> <64734557.1149689.1481110989323.JavaMail.zimbra@casalogic.dk> Message-ID: <1043158772.1150613.1481113568075.JavaMail.zimbra@casalogic.dk> Sorry. Didn't see this..... https://bugzilla.redhat.com/show_bug.cgi?id=1387782 ----- On Dec 7, 2016, at 12:43 PM, Troels Hansen wrote: > Looks great...... Pavel, as a RedHat internal, should I create a ticket to have > this fixed in the RedHat version, or does it already have a internal Red Hat > bugzilla case? > ----- On Dec 7, 2016, at 11:58 AM, Pavel Vomacka wrote: >> Hello, >> it is caused by missing canonical name on services which were created in older >> versions of FreeIPA. Fixed ticket here: >> https://fedorahosted.org/freeipa/ticket/6397 . >> On 12/07/2016 11:48 AM, Fujisan wrote: >>> And with Firefox 50.0.2. >>> F. >>> On Wed, Dec 7, 2016 at 11:46 AM, Fujisan < fujisan43 at gmail.com > wrote: >>>> I have the same issue with version 4.4.2 >>>> $ rpm -qa|grep freeipa >>>> freeipa-server-4.4.2-1.fc25.x86_64 >>>> freeipa-python-compat-4.4.2-1.fc25.noarch >>>> freeipa-server-common-4.4.2-1.fc25.noarch >>>> freeipa-common-4.4.2-1.fc25.no arch >>>> freeipa-server-trust-ad-4.4.2-1.fc25.x86_64 >>>> freeipa-client-4.4.2-1.fc25.x86_64 >>>> freeipa-client-common-4.4.2-1.fc25.noarch >>>> ?F.? >>>> On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen < th at casalogic.dk > wrote: >>>>> I have a strange issue in IPA 4.4.0-12 (RHEL 7.3) >>>>> Navigating to Identity -> Services reveals 5 services. 2 cifs, 2 dogtag and one >>>>> empty line... >>>>> cifs/host1.domain at REALM >>>>> cifs/host2.domain at REALM >>>>> dogtag/ipa01.domain at REALM >>>>> dogtag/ipa02.domain at REALM >>>>> However, from CLI everything looks OK: >>>>> # ipa service-find >>>>> ------------------- >>>>> 11 services matched >>>>> ------------------- >>>>> Principal name: ldap/ipa02.domain at REALM >>>>> Principal alias: ldap/ipa02.domain at REALM >>>>> Certificate: ....... >>>>> ....... >>>>> Keytab: True >>>>> Principal name: ldap/ipa01.domain at REALM >>>>> Principal alias: ldap/ipa01.domain at REALM >>>>> Certificate: ....... >>>>> ....... >>>>> Keytab: True >>>>> Principal name: HTTP/ipa02.domain at REALM >>>>> Principal alias: HTTP/ipa02.domain at REALM >>>>> Certificate: ........ >>>>> ....... >>>>> Keytab: True >>>>> Principal name: cifs/rhellxudv01.domain at REALM >>>>> Principal alias: cifs/rhellxudv01.domain at REALM >>>>> Keytab: True >>>>> Principal name: cifs/ipa02.domain at REALM >>>>> Principal alias: cifs/ipa02.domain at REALM >>>>> Keytab: True >>>>> Principal name: nfs/profil01.domain at REALM >>>>> Principal alias: nfs/profil01.domain at REALM >>>>> Keytab: True >>>>> Principal name: cifs/ipa01.domain at REALM >>>>> Principal alias: cifs/ipa01.domain at REALM >>>>> Keytab: True >>>>> Principal name: dogtag/ipa02.domain at REALM >>>>> Principal alias: dogtag/ipa02.domain at REALM >>>>> Keytab: True >>>>> Principal name: dogtag/ipa01.domain at REALM >>>>> Principal alias: dogtag/ipa01.domain at REALM >>>>> Keytab: True >>>>> Principal name: cifs/rhellxudv02.domain at REALM >>>>> Principal alias: cifs/rhellxudv02.domain at REALM >>>>> Keytab: True >>>>> Principal name: HTTP/ipa01.domain at REALM >>>>> Principal alias: HTTP/ipa01.domain at REALM >>>>> Certificate: .............. >>>>> .............. >>>>> Keytab: True >>>>> ----------------------------- >>>>> Number of entries returned 11 >>>>> ----------------------------- >>>>> (some lines truncated.....) >>>>> soooo... somsthing must be disrupting the view in web-ui, >>>>> Tried in Chrome 43 and IE 11 >>>>> Looking at what gets requested by the browser at /ipa/session/json I can see in >>>>> the json that it gets the correct content: >>>>> result: {count: 11, result: [,?], summary: "11 services matched", truncated: >>>>> false} >>>>> count: 11 >>>>> result: [,?] >>>>> 0: {dn: >>>>> "krbprincipalname=cifs/rhellxudv01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> 1: {dn: >>>>> "krbprincipalname=dogtag/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> 2: {dn: >>>>> "krbprincipalname=nfs/profil01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> 3: {dn: >>>>> "krbprincipalname=cifs/rhellxudv02.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> 4: {dn: >>>>> "krbprincipalname=dogtag/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> 5: {dn: >>>>> "krbprincipalname=HTTP/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> 6: {dn: >>>>> "krbprincipalname=cifs/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> 7: {dn: >>>>> "krbprincipalname=cifs/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> 8: {dn: >>>>> "krbprincipalname=ldap/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> 9: {dn: >>>>> "krbprincipalname=HTTP/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> 10: {dn: >>>>> "krbprincipalname=ldap/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} >>>>> summary: "11 services matched" >>>>> truncated: false >>>>> So this is obviously only a web-ui problem, but I can't see what causes the >>>>> problem? >>>>> -- >>>>> Manage your subscription for the Freeipa-users mailing list: >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> Go to http://freeipa.org for more info on the project >> -- >> Pavel^3 Vomacka > -- > 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. -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvomacka at redhat.com Wed Dec 7 12:33:26 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Wed, 7 Dec 2016 13:33:26 +0100 Subject: [Freeipa-users] Services missing in web-ui In-Reply-To: <1043158772.1150613.1481113568075.JavaMail.zimbra@casalogic.dk> References: <1142144358.1147148.1481105613460.JavaMail.zimbra@casalogic.dk> <64734557.1149689.1481110989323.JavaMail.zimbra@casalogic.dk> <1043158772.1150613.1481113568075.JavaMail.zimbra@casalogic.dk> Message-ID: <08dbad3f-2e1c-db2d-ca6c-ef355d59e9c3@redhat.com> I'm glad that you found it, and I'm sorry, I should have attached the BZ in the first mail. On 12/07/2016 01:26 PM, Troels Hansen wrote: > Sorry. Didn't see this..... > > https://bugzilla.redhat.com/show_bug.cgi?id=1387782 > > > > ----- On Dec 7, 2016, at 12:43 PM, Troels Hansen wrote: > > Looks great...... Pavel, as a RedHat internal, should I create > a ticket to have this fixed in the RedHat version, or does it > already have a internal Red Hat bugzilla case? > > > ----- On Dec 7, 2016, at 11:58 AM, Pavel Vomacka > wrote: > > Hello, > > it is caused by missing canonical name on services which were > created in older versions of FreeIPA. Fixed ticket here: > https://fedorahosted.org/freeipa/ticket/6397 . > > On 12/07/2016 11:48 AM, Fujisan wrote: > > And with Firefox 50.0.2. > > F. > > On Wed, Dec 7, 2016 at 11:46 AM, Fujisan > > wrote: > > I have the same issue with version 4.4.2 > > $ rpm -qa|grep freeipa > freeipa-server-4.4.2-1.fc25.x86_64 > freeipa-python-compat-4.4.2-1.fc25.noarch > freeipa-server-common-4.4.2-1.fc25.noarch > freeipa-common-4.4.2-1.fc25.no > arch > freeipa-server-trust-ad-4.4.2-1.fc25.x86_64 > freeipa-client-4.4.2-1.fc25.x86_64 > freeipa-client-common-4.4.2-1.fc25.noarch > > > ?F.? > > > On Wed, Dec 7, 2016 at 11:13 AM, Troels Hansen > > wrote: > > I have a strange issue in IPA 4.4.0-12 (RHEL 7.3) > > > Navigating to Identity -> Services reveals 5 > services. 2 cifs, 2 dogtag and one empty line... > > cifs/host1.domain at REALM > cifs/host2.domain at REALM > dogtag/ipa01.domain at REALM > dogtag/ipa02.domain at REALM > > > > However, from CLI everything looks OK: > > # ipa service-find > ------------------- > 11 services matched > ------------------- > Principal name: ldap/ipa02.domain at REALM > Principal alias: ldap/ipa02.domain at REALM > Certificate: ....... > ....... > > > Keytab: True > > Principal name: ldap/ipa01.domain at REALM > Principal alias: ldap/ipa01.domain at REALM > Certificate: ....... > ....... > > > Keytab: True > > Principal name: HTTP/ipa02.domain at REALM > Principal alias: HTTP/ipa02.domain at REALM > Certificate: ........ > ....... > > > > Keytab: True > > Principal name: cifs/rhellxudv01.domain at REALM > Principal alias: cifs/rhellxudv01.domain at REALM > Keytab: True > > > > Principal name: cifs/ipa02.domain at REALM > Principal alias: cifs/ipa02.domain at REALM > Keytab: True > > > > Principal name: nfs/profil01.domain at REALM > Principal alias: nfs/profil01.domain at REALM > Keytab: True > > > > Principal name: cifs/ipa01.domain at REALM > Principal alias: cifs/ipa01.domain at REALM > Keytab: True > > Principal name: dogtag/ipa02.domain at REALM > Principal alias: dogtag/ipa02.domain at REALM > Keytab: True > > > > Principal name: dogtag/ipa01.domain at REALM > Principal alias: dogtag/ipa01.domain at REALM > Keytab: True > > > > Principal name: cifs/rhellxudv02.domain at REALM > Principal alias: cifs/rhellxudv02.domain at REALM > Keytab: True > > > > Principal name: HTTP/ipa01.domain at REALM > Principal alias: HTTP/ipa01.domain at REALM > Certificate: .............. > .............. > Keytab: True > > > > ----------------------------- > Number of entries returned 11 > ----------------------------- > > > > > (some lines truncated.....) > > > soooo... somsthing must be disrupting the view in > web-ui, > > > Tried in Chrome 43 and IE 11 > > > Looking at what gets requested by the browser at > /ipa/session/json I can see in the json that it > gets the correct content: > > > result: {count: 11, result: [,?], summary: "11 > services matched", truncated: false} > count: 11 > result: [,?] > 0: {dn: > "krbprincipalname=cifs/rhellxudv01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 1: {dn: > "krbprincipalname=dogtag/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 2: {dn: > "krbprincipalname=nfs/profil01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 3: {dn: > "krbprincipalname=cifs/rhellxudv02.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 4: {dn: > "krbprincipalname=dogtag/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 5: {dn: > "krbprincipalname=HTTP/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 6: {dn: > "krbprincipalname=cifs/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 7: {dn: > "krbprincipalname=cifs/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 8: {dn: > "krbprincipalname=ldap/ipa01.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 9: {dn: > "krbprincipalname=HTTP/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} > 10: {dn: > "krbprincipalname=ldap/ipa02.domain at REALM,cn=services,cn=accounts,dc=domain",?} > summary: "11 services matched" > truncated: false > > > > So this is obviously only a web-ui problem, but I > can't see what causes the problem? > > > -- > Manage your subscription for the Freeipa-users > mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > > > > > > > -- > Pavel^3 Vomacka > > > > -- > > 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. > > > -- > > 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. -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: From nharrington at i-neda.com Wed Dec 7 13:10:53 2016 From: nharrington at i-neda.com (Neal Harrington | i-Neda Ltd) Date: Wed, 7 Dec 2016 13:10:53 +0000 Subject: [Freeipa-users] Loss of initial master in multi master setup In-Reply-To: <584035D8.7090601@redhat.com> References: <96c3ee7b-d0e5-fe87-9585-e4a46ff0991b@redhat.com> <584035D8.7090601@redhat.com> Message-ID: > From: Rob Crittenden > Martin Babinsky wrote: > > On 12/01/2016 01:28 PM, Neal Harrington | i-Neda Ltd wrote: > >> Hi IPA Gurus, > >> > >> > >> I had a 3 site multi master IPA replication setup (1 office and 2 > >> datacentres) with 2 IPA servers at each site. Each server was > >> replicating successfully to 3 other servers (the other local site > >> server and one server at each of the two remote sites). Everything is > >> running on the default packages from CentOS 7.2 and each server is a > >> full replica (ipa-replica-install > >> /var/lib/ipa/replica-info-id-myserver.fqdn.com.gpg --setup-ca > >> --setup-dns --mkhomedir --forwarder 8.8.8.8) > >> > >> > >> Everything was ticking over nicely until we had notice that the > >> office site was moving on short notice. > >> > >> > >> I successfully created IPA servers at the new site, setup replication > >> again between the new office and the two datacentres that were to > >> remain online, tested and everything worked as expected - > >> unfortunately in the rush I did not have time to properly retire the > >> IPA servers in the old office. > >> > >> > >> The problem this has caused is that I only ever created users in one > >> of the IPA servers in the original office - so only those servers > >> have a DNA range and I am now unable to create new users on the active > servers. > >> The original office servers are still in the IPA replication and > >> powered on but offline so potential split brain? > >> > >> > >> I now have two things I would like to know before proceeding: > >> > >> * Is the best fix here to force remove the original IPA servers and > >> manually add a new dna range significantly different from the > >> original to avoid overlaps? > >> * Is there anything else I should check? I can't see any issues > >> however did not notice the DNA range until I tried to create a user. > >> > >> Any pointers greatly appreciated. > >> > >> > >> Thanks, > >> > >> Neal. > >> > >> > >> > >> > >> > >> > > > > Hi Neal, > > > > If you already disconnected/decomissioned the old masters then I thnk > > the best you can do is option a, i.e. re-set DNA ranges on replicas to > > new values while avioding overlap with old ranges. > > > > We have an upstream document[1] describing the procedure. Hope it > helps. > > > > Also make sure that you migrated CA renewal and CRL master > > responsibilities to the new replicas, otherwise you may get problems > > with expiring certificates which are really hard to solve. See the > > following guide for details. [2] > > > > [1] http://www.freeipa.org/page/V3/Recover_DNA_Ranges > > [2] > > > http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_ > Master > > > > You may want to look at this too, http://blog-rcritten.rhcloud.com/?p=50 > > rob Hi Rob & Martin, Thanks for the pointers, I am now able to create new users on different servers - however everything to do with replication seems to be failing. I have changed my replication from a mesh to a long chain and run "ipa-replica-manage -v re-initialize --from " and the same for ipa-csreplica-manage along the chain which succeeds (and any passwords/user creation etc I have done at the start of the chain is pulled through) however replication fails immediately after. I was hoping that re-initializing the chain like this would flush out any "bad" entries - probably wishful thinking. "Ipa-replica-manage -v list" only shows servers in the chain. "Ipa-replica-manage list-ruv" did show the two original servers which I lost connection to and I removed those which successfully removed them from all servers so that part of replication seems to be working. When I do an LDAP search I still see those old masters though (and also see one previously retired server with two different ID's - blue-auth01). Will I need to manually delete these? (example search and output below) Apart from manually deleting the dead servers from LDAP, what else should I do to get replication working again? I'm watching for the CentOS 7.3 release to be able to upgrade to IPA 4.3 as I've seen a few posts about the better handling of replication etc in that version. In the meantime the errors log (copy below) indicates I need to re-initialize which I've done several times without any improvement. Thanks in advance, Neal. [root at office-auth04 ~]# ldapsearch -h $(hostname -f) -D "cn=directory manager" -W -b "o=ipaca" "(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" nscpentrywsi Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: cn: replica nscpentrywsi: createTimestamp: 20161122150144Z nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: modifyTimestamp: 20161204152409Z nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-office-auth04.int.i-neda.com-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config nscpentrywsi: nsDS5ReplicaId: 1495 nscpentrywsi: nsDS5ReplicaName: 725aa31e-b0c411e6-b5d989ac-8f24d4e5 nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsState:: 1wUAAAAAAAAXNURYAAAAAAAAAAAAAAAAUCAAAAAAAAACAAAAAAAAAA== nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: numSubordinates: 1 nscpentrywsi: nsds50ruv: {replicageneration} 575ee7d2000000600000 [0/694] nscpentrywsi: nsds50ruv: {replica 1495 ldap://office-auth04.int.i-neda.com:389} 58347e61000005d70000 58445505000005d70000 nscpentrywsi: nsds50ruv: {replica 91 ldap://power-auth01.int.i-neda.com:389} 577549ad0000005b0000 583457150008005b0000 nscpentrywsi: nsds50ruv: {replica 86 ldap://power-auth02.int.i-neda.com:389} 57754d7b000000560000 583469ad000000560000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://blue-auth04.int.i-neda.com:389} 583469b5000005730000 5841c354000305730000 nscpentrywsi: nsds50ruv: {replica 96 ldap://office-auth01.int.i-neda.com:389} 575ee96e000000600000 58349d69000400600000 nscpentrywsi: nsds50ruv: {replica 97 ldap://office-auth02.int.i-neda.com:389} 575ee993000000610000 5820979e000700610000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://blue-auth02.int.i-neda.com:389} 5783b6fb000004470000 582de13b000d04470000 nscpentrywsi: nsds50ruv: {replica 81 ldap://blue-auth01.int.i-neda.com:389} 5783b6fc000800510000 5783b719000800510000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://blue-auth01.int.i-neda.com:389} 5784d185000004ab0000 5784d1af005604ab0000 nscpentrywsi: nsds50ruv: {replica 76 ldap://blue-auth03.int.i-neda.com:389} 5819fea00000004c0000 58306e950000004c0000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://office-auth03.int.i-neda.com:389} 582f1d660009050f0000 582f1d7c000a050f0000 nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://office-auth04.int.i-neda.com:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://power-auth01.int.i-neda.com:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 86 ldap://power-auth02.int.i-neda.com:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://blue-auth04.int.i-neda.com:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://office-auth01.int.i-neda.com:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://office-auth02.int.i-neda.com:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://blue-auth02.int.i-neda.com:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 81 ldap://blue-auth01.int.i-neda.com:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://blue-auth01.int.i-neda.com:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 76 ldap://blue-auth03.int.i-neda.com:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://office-auth03.int.i-neda.com:389} 00000000 nscpentrywsi: nsds5ReplicaChangeCount: 2 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Extract from /var/log/dirsrv/REALM/errors from power-auth01 which is one down from the "start" of the chain (office-auth04): [07/Dec/2016:12:07:16 +0000] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=int,dc=i-neda,dc=com is going offline; disabling replication [07/Dec/2016:12:07:17 +0000] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [07/Dec/2016:12:07:21 +0000] - import userRoot: Workers finished; cleaning up... [07/Dec/2016:12:07:21 +0000] - import userRoot: Workers cleaned up. [07/Dec/2016:12:07:21 +0000] - import userRoot: Indexing complete. Post-processing... [07/Dec/2016:12:07:21 +0000] - import userRoot: Generating numsubordinates (this may take several minutes to complete)... [07/Dec/2016:12:07:21 +0000] - import userRoot: Generating numSubordinates complete. [07/Dec/2016:12:07:21 +0000] - import userRoot: Gathering ancestorid non-leaf IDs... [07/Dec/2016:12:07:21 +0000] - import userRoot: Finished gathering ancestorid non-leaf IDs. [07/Dec/2016:12:07:21 +0000] - import userRoot: Creating ancestorid index (new idl)... [07/Dec/2016:12:07:21 +0000] - import userRoot: Created ancestorid index (new idl). [07/Dec/2016:12:07:21 +0000] - import userRoot: Flushing caches... [07/Dec/2016:12:07:21 +0000] - import userRoot: Closing files... [07/Dec/2016:12:07:22 +0000] - import userRoot: Import complete. Processed 777 entries in 5 seconds. (155.40 entries/sec) [07/Dec/2016:12:07:22 +0000] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=int,dc=i-neda,dc=com is coming online; enabling replication [07/Dec/2016:12:07:22 +0000] NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for replica dc=int,dc=i-neda,dc=com does not match the data in the changelog. Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. [07/Dec/2016:12:07:22 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=int,dc=i-neda,dc=com--no CoS Templates found, which should be added before the CoS Definition. [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target ou=sudoers,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=users,cn=compat,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=int,dc=i-neda,dc=com does not exist [07/Dec/2016:12:07:22 +0000] agmt="cn=meTopower-auth02.int.i-neda.com" (power-auth02:389) - Can't locate CSN 5847f3fd0000000d0000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [07/Dec/2016:12:07:22 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meTopower-auth02.int.i-neda.com" (power-auth02:389): CSN 5847f3fd0000000d0000 not found, we aren't as up to date, or we purged [07/Dec/2016:12:07:22 +0000] NSMMReplicationPlugin - agmt="cn=meTopower-auth02.int.i-neda.com" (power-auth02:389): Data required to update replica has been purged. The replica must be reinitialized. [07/Dec/2016:12:07:22 +0000] NSMMReplicationPlugin - agmt="cn=meTopower-auth02.int.i-neda.com" (power-auth02:389): Incremental update failed and requires administrator action [07/Dec/2016:12:07:22 +0000] agmt="cn=meTooffice-auth04.int.i-neda.com" (office-auth04:389) - Can't locate CSN 584412d7000200050000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [07/Dec/2016:12:07:22 +0000] NSMMReplicationPlugin - changelog program - agmt="cn=meTooffice-auth04.int.i-neda.com" (office-auth04:389): CSN 584412d7000200050000 not found, we aren't as up to date, or we purged [07/Dec/2016:12:07:22 +0000] NSMMReplicationPlugin - agmt="cn=meTooffice-auth04.int.i-neda.com" (office-auth04:389): Data required to update replica has been purged. The replica must be reinitialized. [07/Dec/2016:12:07:22 +0000] NSMMReplicationPlugin - agmt="cn=meTooffice-auth04.int.i-neda.com" (office-auth04:389): Incremental update failed and requires administrator action [07/Dec/2016:12:07:30 +0000] attrlist_replace - attr_replace (nsslapd-referral, ldap://office-auth04.int.i-neda.com:389/o%3Dipaca) failed. [07/Dec/2016:12:07:30 +0000] attrlist_replace - attr_replace (nsslapd-referral, ldap://office-auth04.int.i-neda.com:389/o%3Dipaca) failed. [07/Dec/2016:12:07:30 +0000] attrlist_replace - attr_replace (nsslapd-referral, ldap://office-auth04.int.i-neda.com:389/o%3Dipaca) failed. [07/Dec/2016:12:07:30 +0000] NSMMReplicationPlugin - multimaster_be_state_change: replica o=ipaca is going offline; disabling replication [07/Dec/2016:12:07:31 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=int,dc=i-neda,dc=com--no CoS Templates found, which should be added before the CoS Definition. [07/Dec/2016:12:07:31 +0000] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [07/Dec/2016:12:07:36 +0000] attrlist_replace - attr_replace (nsslapd-referral, ldap://office-auth04.int.i-neda.com:389/o%3Dipaca) failed. [07/Dec/2016:12:07:36 +0000] attrlist_replace - attr_replace (nsslapd-referral, ldap://office-auth04.int.i-neda.com:389/o%3Dipaca) failed. [07/Dec/2016:12:07:36 +0000] attrlist_replace - attr_replace (nsslapd-referral, ldap://office-auth04.int.i-neda.com:389/o%3Dipaca) failed. [07/Dec/2016:12:07:36 +0000] - import ipaca: Workers finished; cleaning up... [07/Dec/2016:12:07:36 +0000] - import ipaca: Workers cleaned up. [07/Dec/2016:12:07:36 +0000] - import ipaca: Indexing complete. Post-processing... [07/Dec/2016:12:07:36 +0000] - import ipaca: Generating numsubordinates (this may take several minutes to complete)... [07/Dec/2016:12:07:36 +0000] - import ipaca: Generating numSubordinates complete. [07/Dec/2016:12:07:36 +0000] - import ipaca: Gathering ancestorid non-leaf IDs... [07/Dec/2016:12:07:36 +0000] - import ipaca: Finished gathering ancestorid non-leaf IDs. [07/Dec/2016:12:07:36 +0000] - import ipaca: Creating ancestorid index (new idl)... [07/Dec/2016:12:07:36 +0000] - import ipaca: Created ancestorid index (new idl). [07/Dec/2016:12:07:36 +0000] - import ipaca: Flushing caches... [07/Dec/2016:12:07:36 +0000] - import ipaca: Closing files... [07/Dec/2016:12:07:36 +0000] - import ipaca: Import complete. Processed 375 entries in 6 seconds. (62.50 entries/sec) [07/Dec/2016:12:07:36 +0000] NSMMReplicationPlugin - multimaster_be_state_change: replica o=ipaca is coming online; enabling replication [07/Dec/2016:12:07:36 +0000] NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for replica o=ipaca does not match the data in the changelog. Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. [07/Dec/2016:12:07:36 +0000] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=int,dc=i-neda,dc=com--no CoS Templates found, which should be added before the CoS Definition. Thanks in advance for any hints, Neal. From tk at mdevsys.com Wed Dec 7 13:17:56 2016 From: tk at mdevsys.com (TomK) Date: Wed, 7 Dec 2016 08:17:56 -0500 Subject: [Freeipa-users] Mapping users from AD to IPA KDC In-Reply-To: <56356ff9-f7c1-e0a6-7f20-59c9eca07004@mdevsys.com> References: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> <2c4ff955-ab05-80ea-f4ae-da217d21b285@mdevsys.com> <20161205070232.gnntt334q5siv3va@redhat.com> <1ee640af-4739-1e9b-bb49-c10601e6e08d@mdevsys.com> <20161206203735.l56lefuf5w5hye5t@redhat.com> <56356ff9-f7c1-e0a6-7f20-59c9eca07004@mdevsys.com> Message-ID: <729de833-5bda-7194-68af-ae1d6250d921@mdevsys.com> On 12/6/2016 11:32 PM, TomK wrote: > On 12/6/2016 3:37 PM, Alexander Bokovoy wrote: >> On ti, 06 joulu 2016, TomK wrote: >>> On 12/5/2016 2:02 AM, Alexander Bokovoy wrote: >>>> On su, 04 joulu 2016, TomK wrote: >>>>> Could not get much from logs and decided to start fresh. When I run >>>>> this: >>>>> >>>>> ipa trust-add --type=ad mds.xyz --admin Administrator --password >>>>> >>>>> Trust works fine and id tom at mds.xyz returns a valid result. >>>>> >>>>> However when I run the following on both masters on a fresh new setup: >>>>> >>>>> ipa-adtrust-install --netbios-name=NIX -a "" >>>>> ipa trust-add --type=ad "mds.xyz" --trust-secret >>>>> >>>>> and created a trust object in AD DC with the name of NIX and a >>>>> non-transitive trust, the above did NOT work. I didn't get anything >>>>> by typing id tom at mds.xyz. (I do not get an option for a Forest Trust >>>>> as the gif on this page suggests: >>>>> https://www.freeipa.org/page/Active_Directory_trust_setup . Possibly >>>>> it's Server 2012 hence the difference in what's presented to me but >>>>> another reason is that the name I type for the trust can't resolve to >>>>> an IP for now: nix.mds.xyz . So I use NIX to match the bios name used >>>>> on the ipa-adtrust-install command above. ) >>>> The shared secret case for one-way trust is known to be broken. When a >>>> shared half is created on AD side first, it is marked as not yet valid >>>> by Windows and currently we cannot perform validation of it from IPA >>>> side. Validating it from AD side is not possible as well as we don't >>>> provide all interfaces Windows would like to use. >>>> >>>> And the fact you cannot see 'Forest Trust' type of the trust says also >>>> that you have problems with reaching IPA masters from AD DC side for >>>> probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and >>>> UDP). >>> Nothing I tried in AD Trust creation allowed me to make one with type >>> Forest. Just realm. I recall I had a trust type of Forest but in >>> trying various options I lost how I did that. Or perhaps I hadn't >>> payed attention and it got created indirectly as part of another >>> action I took. The domain functional level I'm using is Windows >>> Server 2008. Using a lower value for testing. >> This (inability to chose Forest trust type) simply means AD DC is unable >> to probe IPA DC. You said below that SMB port towards IPA DC was closed. >> >> Also make sure to remove incorrect trust from Windows side. While we are >> removing a trust object named as our NetBIOS name, it only works for the >> proper trusted domain/forests, not for wrong 'realm trust' type. >> >>> >>> My IPA version is 4.2 right now. It came with the CentOS 7.2. >>> Looking forward to 4.4. Not sure when you plan to include it as part >>> of the latest CentOS base. Indeed some ports were not open (445). >>> I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7: >>> >>> for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp >>> 53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp >>> 53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd >>> --zone=public --permanent --add-port=$KEY; done >>> >>> [root at idmipa01 ~]# firewall-cmd --zone=public --list-all >>> public (default) >>> interfaces: >>> sources: >>> services: dhcpv6-client ntp ssh >>> ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp >>> 135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp >>> 139/udp 138/udp 53/udp 636/tcp >>> masquerade: no >>> forward-ports: >>> icmp-blocks: >>> rich rules: >>> >>> [root at idmipa01 ~]# >>> >>> On Windows Side (The nslookup results were the same before the >>> firewall change however.): >> Firewall changes cannot affect DNS as you already had DNS port open. >> >>> On the AD side, I added the SRV records for the second AD DC, >>> manually, since earlier there were no results printed on the AD DC >>> command line for the second AD DC, when I typed the command >>> _ldap._tcp.mds.xyz. >>> >>> One additional question I had with the setup is in regards to the >>> failover. I see the ipa_server entry in /etc/sssd/sssd.conf pointing >>> to two of the master IPA nodes. Where can I find the additional >>> settings that control priority of the listed server or order they are >>> checked? >> You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections >> FAILOVER and SERVICE DISCOVER. >> >>> What I ran to get the above is: >>> >>> 1) ipa-client-install --force-join -p admin -w "" >>> --fixed-primary --server=idmipa01.nix.mds.xyz >>> --server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz >>> --realm=NIX.MDS.XYZ -U >>> 2) realm join mds.xyz >> This is wrong. You have effectively joined this IPA client to AD and IPA >> at the same time. It should not be done this way (read >> http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain >> for details). >> >> Instead, you need to identify why the trust does not work properly. >> Use tcpdump to intercept the traffic between your AD DCs and IPA DCs >> while establishing the trust. >> >> You can send the trace to me off-list. >> >> >> > > Ok, let me take these away and get back to you. ( On realm, thank you. > Hadn't reviewed the changes it did fully before logging off. ) > Removed the direct mds.xyz domain directly (my bad). Currently I get this on using MDS.XYZ\tom to login with or tom at MDS.XYZ when trying ssh directly. From command line the user is visible (not enough time to get to the rest. Not sure if the system error breaks this though so want to run it by you): [root at ipaclient01 sssd]# id tom at mds.xyz uid=155601104(tom at mds.xyz) gid=155601104(tom at mds.xyz) groups=155601104(tom at mds.xyz),155600513(domain users at mds.xyz),155601107(nixadmins at mds.xyz),1746600039(nixadmins) [root at ipaclient01 sssd]# (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [tom at mds.xyz] (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is tom at mds.xyz (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: mds.xyz (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): user: tom at mds.xyz (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: 192.168.0.208 (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 6297 (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: MDS.XYZ\tom (Wed Dec 7 08:11:59 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f7e7ed32700 (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Wed Dec 7 08:11:59 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f7e7ed32700 (Wed Dec 7 08:11:59 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f7e7ed2e7f0 (Wed Dec 7 08:11:59 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][mds.xyz] (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. (Wed Dec 7 08:11:59 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 24 (Wed Dec 7 08:11:59 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f7e7ed38210][20] (Wed Dec 7 08:12:04 2016) [sssd[pam]] [pam_initgr_cache_remove] (0x2000): [MDS.XYZ\tom] removed from PAM initgroup cache (Wed Dec 7 08:12:09 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f7e7ed29d00 (Wed Dec 7 08:12:09 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Dec 7 08:12:09 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Wed Dec 7 08:12:09 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [tom at mds.xyz] (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is tom at mds.xyz (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): domain: mds.xyz (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): user: tom at mds.xyz (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: 192.168.0.208 (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 6293 (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_print_data] (0x0100): logon name: tom at mds.xyz (Wed Dec 7 08:11:15 2016) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7f7e7ed34340 (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Wed Dec 7 08:11:15 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7f7e7ed34340 (Wed Dec 7 08:11:15 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f7e7ed2e7f0 (Wed Dec 7 08:11:15 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][mds.xyz] (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. (Wed Dec 7 08:11:15 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 24 (Wed Dec 7 08:11:15 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7f7e7ed35900][19] (Wed Dec 7 08:11:19 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7f7e7ed29d00 (Wed Dec 7 08:11:19 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Dec 7 08:11:19 2016) [sssd[pam]] [sbus_message_handler] (0x2000): Received SBUS method org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service (Wed Dec 7 08:11:19 2016) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Wed Dec 7 08:11:20 2016) [sssd[pam]] [pam_initgr_cache_remove] (0x2000): [tom at mds.xyz] removed from PAM initgroup cache -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From pieter at lautus.net Wed Dec 7 13:33:41 2016 From: pieter at lautus.net (Pieter Nagel) Date: Wed, 7 Dec 2016 15:33:41 +0200 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: <20161207085819.q5onuspvbrog6hee@redhat.com> References: <20161207085819.q5onuspvbrog6hee@redhat.com> Message-ID: Thanks, that helps a lot. Yes and no. What you see with "@ NS ..." is a glue record -- you are > supposed to have a glue record for IPA domain in the upstream domain, > this is how domain delegation works in DNS world. Except what i saw was the other way around. The FreeIPA server has an NSrecord claiming that it is authoritative the parent domain, but its parent domain is hosted at dnsmadeeasy: ~ dig @8.8.8.8 -t NS lautus.net lautus.net. 86399 IN NS ns15.dnsmadeeasy.com. ~ dig @8.8.8.8 -t NS ipa.lautus.net ipa.lautus.net. 86399 IN NS ipa-hetzner-cpt4-01.lautus.net. But as far as the FreeIPA DNS is concerned, it is authoritative for everything: ~ dig @ipa-hetzner-cpt4-01.lautus.net -t NS lautus.net lautus.net. 86400 IN NS ipa-hetzner-cpt4-01.lautus.net. ~ dig @ipa-hetzner-cpt4-01.lautus.net -t NS ipa.lautus.net ipa.lautus.net. 86400 IN NS ipa-hetzner-cpt4-01.lautus.net. -- Pieter Nagel Lautus Solutions (Pty) Ltd Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng 0832587540 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dag at sonsorol.org Wed Dec 7 13:37:27 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 07 Dec 2016 08:37:27 -0500 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <5846F92E.3010900@sonsorol.org> <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58471CDD.8070703@sonsorol.org> <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <58481097.5050304@sonsorol.org> Sumit, Thank you so much for your assistance and eyeballs on the massive logset. I've repeatedly found the level of support on this list to be fantastic. Some day I'll have enough hands-on experience to repay in kind ... We do actually use a different domain for the clients: Our clients are "company-aws.org" while being managed by "company-idm.org" and talking to AD forests and many child domains in "company.org". It's a fairly hairy setup driven mostly by "above my pay grade" distrust of IaaS cloud environments like AWS VPCs combined with existing use of Kerberos that we don't want to break. Hence putting IDM/IPA in a separate domain and realm altogether. I actually DID see the "UPN used in the request .. differ" error messages all over the place. I will try the workaround linked to below and report back. Follow-up on the 4.4 release: For people using CentOS/RHEL 7.x is it recommended to use IPA 4.4 code in production? Our needs are pretty simple once you get beyond the complex AD environment - we just need simple SSH password authentication and a bit of RBAC feature for a small to midsize cloud footprint. I'm guessing that running 4.4 if we have passwords working would not be all that risky for us. It really does seem like a large amount of recent IPA development has focused on AD integration so I'm actually fairly interested and motivated to step up from our 4.2 version. Regards, Chris Sumit Bose wrote: > > Both authentications where successful against the backend. For the logs > it looks like you use an alternative domain suffix on the AD side so > that all user if other domains in the forest can use the forest root > suffix as realm, in the user principal (user at NAFTA.COMPANY.ORG -> > user at COMPANY.ORG). > > I would expect that there are messages like "UPN used in the request > ...differ by more than just the case." in the domain log at 'TueDec 6 > 19:57:11' and 'TueDec 6 19:57:14'. > > If that's the case updating to4.4 would help because in this release > IPA can forward the enterprise principals properly and SSSD will not > reject the changed principal because sSSD will be aware of the change. > > But there are workarounds to make it work with your version as well, > please see e.g. the suggestion from > https://www.redhat.com/archives/freeipa-users/2016-May/msg00205.html . > > HTH > > bye, > Sumit From b.candler at pobox.com Wed Dec 7 13:57:45 2016 From: b.candler at pobox.com (Brian Candler) Date: Wed, 7 Dec 2016 13:57:45 +0000 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: <20161207085819.q5onuspvbrog6hee@redhat.com> References: <20161207085819.q5onuspvbrog6hee@redhat.com> Message-ID: <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> On 07/12/2016 08:58, freeIPA users list wrote: > On ke, 07 joulu 2016, List dedicated to discussions about use, > configuration and deployment of the IPA server. wrote: >> I know the Quick Start Guide and Deployment Recommendations cover >> this in >> depth, but there are still some ambiguities. >> >> I'm trying to figure out if a company like us, lautus.net should use >> a DNS >> subdomain like ipa.lautus.net for the IPA domain, or not. > It is really depending on your deployment details. > > If you already have some other Kerberized environment in place and you > are not going to replace it by FreeIPA, then you need to make sure that > new FreeIPA deployment would not conflict with the existing one. Or if you think there's a chance you might want to add another Kerberized environment later (e.g. "ad.lautus.net") > >> should continue to be hosted by DNS servers elsewhere that delegate say, >> ipa.lautus.net to FreeIPA. The question of whether you host ipa.lautus.net DNS (or indeed lautus.net DNS) in FreeIPA is a different issue. If you're happy with your existing DNS infrastructure, then you can either delegate ipa.lautus.net to your FreeIPA servers (with NS records); or run FreeIPA without DNS, and simply import the ipa.lautus.net SRV records directly into the lautus.net domain. Having FreeIPA host the ipa.lautus.net domain means these SRV records are populated automatically, but it's not really that hard to add them to an existing DNS service. OTOH, if you *don't* already have a good authoritative internal DNS service with a UI that you like, then you might want to use FreeIPA for this anyway. You can easily create extra zones in FreeIPA. I would be a bit wary about putting FreeIPA servers out on the public Internet though. For one thing, the default config is an open resolver (which you can tighten easily enough). I also have a deep distrust of Java, but maybe that's just me. > >> But on the other hand the same doc is full of examples where a Kerberos >> realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example >> 2.2. of secion 2.3.4. But the same guide also says that the Kerberos >> realm >> should be the same as the ipa DNS domain, just uppercased. So example >> 2.2. >> implies that example.com is running their DNS domain on FreeIPA, for >> everything, not just for IPA SRV and TXT entries. The Kerberos realm always has a corresponding DNS domain, so realm IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net". But with FreeIPA you can still manage hosts called foo.lautus.net or bar.int.lautus.net. At worst you'd have some extra [domain_realm] mappings in krb5.conf (Aside: Active Directory is much more fussy, and basically doesn't work if the hosts don't have hostnames within the same DNS domain as their kerberos realm - and indeed have reverse DNS as well as forward) > >> And when ipa-client-install is run on somehost.lautus.net, it also >> defaults >> to LAUTUS.NET for Kerberos domain, as if the default expectation is that >> your toplevel company DNS name would be your kerberos domain. But you can override that. > > >> And when I install a trial IPA server on host ipa-server-1.lautus.net >> using >> "ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain >> ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones >> in the >> Web UI, I see not only ipa.lautus.net, but also lautus, with record >> "@ NS >> ipa-server-1.lautus.net". In other words the IPA server defaults to >> thinking it owns the domain above ipa.lautus.net too. Which goes against >> 2.3.1 above. Interesting. What does "ipa dnszone-find --pkey-only" show? It seems like it's created an authoritative zone both for the server's own domain (lautus.net if the server is xxx.lautus.net) as well as the realm's domain (ipa.lautus.net) I don't know why it's doing that. Now I've checked with another system here: the hostname is "ipa-1.int.example.com" and the realm is "ipa.example.com", and you're right, it is authoritative for both: Zone name: int.example.com. Zone name: ipa.example.com. This isn't what I wanted. The int.example.com domain is hosted externally and I didn't want to override it. Right now it's hiding all names in int.example.com that it doesn't know about. I would expect that it's possible to remove this zone, but I'd need to test that doesn't stop other hosts called xxx.int.example.com from joining. > Yes and no. What you see with "@ NS ..." is a glue record -- you are > supposed to have a glue record for IPA domain in the upstream domain, > this is how domain delegation works in DNS world. Aside: technically that's not a glue record. A glue record is an A or AAAA record when the NS record points to a host within the subdomain which is being delegated. It is to solve the chicken-and-egg situation of how to contact a nameserver for a domain before you've contacted a nameserver for the domain. In your case, if you already have working DNS for lautus.net, then you don't want FreeIPA to be authoritative for lautus.net as well. Regards, Brian. From rcritten at redhat.com Wed Dec 7 14:21:13 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 7 Dec 2016 09:21:13 -0500 Subject: [Freeipa-users] What should the --hostname option do? In-Reply-To: References: <20161207074808.GA12252@redhat.com> Message-ID: <58481AD9.9050503@redhat.com> Martin Basti wrote: > > > On 07.12.2016 08:48, List dedicated to discussions about use, > configuration and deployment of the IPA server. wrote: >> Hello, >> >> the --hostname option to the installer currently modifies the hostname >> of the machine. In some environments, namely in unprivileged >> containers, that operation is not denied. In some cases, it is >> possible to change the FQDN of the container from outside, for example >> with docker run's -h option. However, in some environments, namely in >> OpenShift, there is not such possibility. >> >> I have found out that disabling the change by turning /bin/hostnamectl >> and /usr/bin/domainname makes ipa-server-install pass while the server >> gets configured with the hostname specified as the parameter to >> --hostname option so it does not seem to be essential for the FQDN to >> change. Of course, some operations might no longer work, like ssh to >> the FreeIPA machine as sshd would need to be set with >> GSSAPIStrictAcceptorCheck no. >> >> I wonder if either change of the --hostname semantics, or some new >> option would be useful, to specify the hostname to be used by the >> FreeIPA software while not touching the configuration of the hostname >> for the machine. >> > > I agree that --hostname options should not touch system's hostname, I > don't see reason why application installer should change system hostname. It was done for sanity because a staggering number of users it seems don't properly set their hostname. > I'd start with deprecating current behavior of this option in next release IMHO it is a pretty significant change of behavior. > As you mentioned we need find what cases can be broken when we will use > different local and external hostname, but anyway we have do this for > containers. Agreed. Something needs to happen, I'm just not convinced it should happen in --hostname. I generally oppose new options but one might be warranted in this case to handle things. rob From dag at sonsorol.org Wed Dec 7 14:23:46 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 07 Dec 2016 09:23:46 -0500 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <5846F92E.3010900@sonsorol.org> <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58471CDD.8070703@sonsorol.org> <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <58481B72.1020408@sonsorol.org> Confirmed that adding the following to /etc/sssd/ssd.conf on the SERVER fixed SSH password checks on the server itself! ldap_user_principal = nosuchattr subdomain_inherit = ldap_user_principal The core problem does appear to be the "... UPN is quite different" error when we try to login as user at NAFTA.COMPANY.ORG which then gets shortened to user at COMPANY.ORG. It's hard to read the volume of debug_level 10 logs but it's clear that it's getting hung up with principals when talking to the remote AD servers. I can now login to the IPA server with my standard AD credentials which has been impossible until just now. However no luck on IPA clients. Can you confirm that the above sssd.conf workaround is for the IPA server only as the thread you linked to indicates or is this a change I should push down to clients? I'm going to build some fresh clients just in case. And knowing that this workaround seems to be getting close to totally resolving our issue would you recommend IPA-4.4 for our environment where we have lots of AD trusts in play combined with DNS-DOMAIN differences between the IPA realm and the managed clients? Or is it better to stick with the workaround settings + the IPA-4.2 release that comes with CentOS/RHEL-7? Thanks! Chris Sumit Bose wrote: > Both authentications where successful against the backend. For the logs > it looks like you use an alternative domain suffix on the AD side so > that all user if other domains in the forest can use the forest root > suffix as realm, in the user principal (user at NAFTA.COMPANY.ORG -> > user at COMPANY.ORG). > > I would expect that there are messages like "UPN used in the request > ...differ by more than just the case." in the domain log at 'TueDec 6 > 19:57:11' and 'TueDec 6 19:57:14'. > > If that's the case updating to4.4 would help because in this release > IPA can forward the enterprise principals properly and SSSD will not > reject the changed principal because sSSD will be aware of the change. > > But there are workarounds to make it work with your version as well, > please see e.g. the suggestion from > https://www.redhat.com/archives/freeipa-users/2016-May/msg00205.html . From mbasti at redhat.com Wed Dec 7 14:32:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Dec 2016 15:32:07 +0100 Subject: [Freeipa-users] What should the --hostname option do? In-Reply-To: <58481AD9.9050503@redhat.com> References: <20161207074808.GA12252@redhat.com> <58481AD9.9050503@redhat.com> Message-ID: On 07.12.2016 15:21, Rob Crittenden wrote: > Martin Basti wrote: >> >> On 07.12.2016 08:48, List dedicated to discussions about use, >> configuration and deployment of the IPA server. wrote: >>> Hello, >>> >>> the --hostname option to the installer currently modifies the hostname >>> of the machine. In some environments, namely in unprivileged >>> containers, that operation is not denied. In some cases, it is >>> possible to change the FQDN of the container from outside, for example >>> with docker run's -h option. However, in some environments, namely in >>> OpenShift, there is not such possibility. >>> >>> I have found out that disabling the change by turning /bin/hostnamectl >>> and /usr/bin/domainname makes ipa-server-install pass while the server >>> gets configured with the hostname specified as the parameter to >>> --hostname option so it does not seem to be essential for the FQDN to >>> change. Of course, some operations might no longer work, like ssh to >>> the FreeIPA machine as sshd would need to be set with >>> GSSAPIStrictAcceptorCheck no. >>> >>> I wonder if either change of the --hostname semantics, or some new >>> option would be useful, to specify the hostname to be used by the >>> FreeIPA software while not touching the configuration of the hostname >>> for the machine. >>> >> I agree that --hostname options should not touch system's hostname, I >> don't see reason why application installer should change system hostname. > It was done for sanity because a staggering number of users it seems > don't properly set their hostname. Then we should have checks and prevent installation, but this needs proper design and must cover containers, AWS, etc. to count with various scenarios. > >> I'd start with deprecating current behavior of this option in next release > IMHO it is a pretty significant change of behavior. True, so as mentioned later, rather just deprecate this option. > >> As you mentioned we need find what cases can be broken when we will use >> different local and external hostname, but anyway we have do this for >> containers. > Agreed. Something needs to happen, I'm just not convinced it should > happen in --hostname. I generally oppose new options but one might be > warranted in this case to handle things. Maybe --external-hostname or so, noted, we will cover it in design. > > rob From rcritten at redhat.com Wed Dec 7 14:43:26 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 7 Dec 2016 09:43:26 -0500 Subject: [Freeipa-users] What should the --hostname option do? In-Reply-To: References: <20161207074808.GA12252@redhat.com> <58481AD9.9050503@redhat.com> Message-ID: <5848200E.2070508@redhat.com> Martin Basti wrote: > > > On 07.12.2016 15:21, Rob Crittenden wrote: >> Martin Basti wrote: >>> >>> On 07.12.2016 08:48, List dedicated to discussions about use, >>> configuration and deployment of the IPA server. wrote: >>>> Hello, >>>> >>>> the --hostname option to the installer currently modifies the hostname >>>> of the machine. In some environments, namely in unprivileged >>>> containers, that operation is not denied. In some cases, it is >>>> possible to change the FQDN of the container from outside, for example >>>> with docker run's -h option. However, in some environments, namely in >>>> OpenShift, there is not such possibility. >>>> >>>> I have found out that disabling the change by turning /bin/hostnamectl >>>> and /usr/bin/domainname makes ipa-server-install pass while the server >>>> gets configured with the hostname specified as the parameter to >>>> --hostname option so it does not seem to be essential for the FQDN to >>>> change. Of course, some operations might no longer work, like ssh to >>>> the FreeIPA machine as sshd would need to be set with >>>> GSSAPIStrictAcceptorCheck no. >>>> >>>> I wonder if either change of the --hostname semantics, or some new >>>> option would be useful, to specify the hostname to be used by the >>>> FreeIPA software while not touching the configuration of the hostname >>>> for the machine. >>>> >>> I agree that --hostname options should not touch system's hostname, I >>> don't see reason why application installer should change system >>> hostname. >> It was done for sanity because a staggering number of users it seems >> don't properly set their hostname. > > Then we should have checks and prevent installation, but this needs > proper design and must cover containers, AWS, etc. to count with various > scenarios. > >> >>> I'd start with deprecating current behavior of this option in next >>> release >> IMHO it is a pretty significant change of behavior. > True, so as mentioned later, rather just deprecate this option. Would be hard to do. Think about something like puppet, it would need to become version-aware. > >> >>> As you mentioned we need find what cases can be broken when we will use >>> different local and external hostname, but anyway we have do this for >>> containers. >> Agreed. Something needs to happen, I'm just not convinced it should >> happen in --hostname. I generally oppose new options but one might be >> warranted in this case to handle things. > > Maybe --external-hostname or so, noted, we will cover it in design. > >> >> rob > From jjflynn22 at gmail.com Wed Dec 7 15:37:11 2016 From: jjflynn22 at gmail.com (Joseph Flynn) Date: Wed, 7 Dec 2016 10:37:11 -0500 Subject: [Freeipa-users] Let's Encrypt Install: Made a bit of install progress, next error Message-ID: Sorry, I wasn't clear in my earlier subject line. This is related to the Lets Encrypt installation. I tried to pull some more relevant items from the log below. I don't actually see all of the elements of my FQDN (ipa-a.kkgpitt.org) only references to the host (ipa-a) in the log, but am not sure what a good log should include. Thanks for any assistance, Joe On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn wrote: > Volunteers, > > I moved over to a Fedora VM which was way more difficult than it should > be. All kinds of problems with Guest Additions and I ended up having to > run server mode with no GUI. Now I run an Ubuntu VM from which I ssh into > my Fedora VM. Anyway... > > The install made it a further step than before. I get a quick blue screen > pop up at the end then an error saying: > [image: Inline image 1] > > An unexpected error occurred: >> The request message was malformed :: DNS name does not have enough labels >> Please see the logfiles in /var/log/letsencrypt for more details. >> > > When I run the cert checker util I get this > https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org > > Full log below. > > Any suggestions? Is it not pulling my proper hostname? > > Thanks, > Joe > > > > > > [jjflynn22 at ipa-a ~]$ cat /etc/hosts > 192.168.1.211 ipa-a.kkgpitt.org ipa-a > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 > > > > > [jjflynn22 at ipa-a ~]$ sudo cat /var/log/letsencrypt/letsencrypt.log > [sudo] password for jjflynn22: > 2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level set at 20 > 2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to > /var/log/letsencrypt/letsencrypt.log > 2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3 > 2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments: ['--standalone', > '--csr', '/root/ipa-le/httpd-csr.der', '--email', 'xxxxx at gmail.com', > '--agree-tos'] > 2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered plugins: > PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null, > PluginEntryPoint#manual,PluginEntryPoint#standalone) > 2016-12-06 20:57:43,995:DEBUG:certbot.plugins.selection:Requested > authenticator standalone and installer None > 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Single candidate > plugin: * standalone > Description: Spin up a temporary webserver > Interfaces: IAuthenticator, IPlugin > Entry point: standalone = certbot.plugins.standalone:Authenticator > Initialized: 0x7fc3dc6fccd0> > Prep: True > 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Selected > authenticator 0x7fc3dc6fccd0> and installer None > 2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account: 7446b15565eb5a2fc5850f3ad97dc6dc)> > 2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to > https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {} > 2016-12-06 20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting > new HTTPS connection (1): acme-v01.api.letsencrypt.org > 2016-12-06 20:57:44,500:DEBUG:requests.packages.urllib3.connectionpool:"GET > /directory HTTP/1.1" 200 280 > 2016-12-06 20:57:44,506:DEBUG:root:Received . Headers: > {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT', > 'Boulder-Request-Id': 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', > 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', > 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': > 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', > 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', > 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}. Content: > '{\n "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n > "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n > "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n > "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"\n}' > 2016-12-06 20:57:44,506:DEBUG:acme.client:Received response [200]> (headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 > 20:57:46 GMT', 'Boulder-Request-Id': 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', > 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', > 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': > 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', > 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', > 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}): '{\n > "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n > "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n > "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n > "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"\n}' > 2016-12-06 20:57:44,506:DEBUG:certbot.client:CSR: > CSR(file='/root/ipa-le/httpd-csr.der', data='0\x82\x02x0\x82\x01`\ > x02\x01\x000\x101\x0e0\x0c\x06\x03U\x04\x03\x13\x05ipa-a > 0\x82\x01"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\ > x03\x82\x01\x0f\x000\x82\x01\n\x02\x82\x01\x01\x00\xdau1L\ > xa6T\xc8\x93\xc0P\x93\xb3\xd2\xcb \xe2PU\xf0\x94=\x1c\n\x1e\xe5\ > xfe\xed<\xfa\xb1d-\x92\xebeD\xb1\x0eq9\xf1\xfa\xb5p\xdc\ > x12qN\x96\x0b\x1f\x13\xab\xae > > ....... > > 99\xc0\xb0\x07N\xdd5\x9e1\xb8\xdc\x8c\xc1N\xc1\x04\xa1\xd0\ > xfc\xc2$f\x84e\xd4\xf7i\x1a\x1c~,\x80\xea/~j\xea\xa2\xf3\ > xe9\x96\xfe5j\xa4\xb4X\x12L\xd5\xe5\xb0\x99|\xb8\xd1\xed\ > xa3\xf2\xd5\xf0\x94\xc3"\xe8\x9dT\x17\xcf\x12$oVE\x83\xd1\ > x96\xac\xa1\xf9F\xd2mO\xe9$\xa7\x00_\xaa\xc6\xa3j\xa1\ > xbaX8\xa43K\x18os\xe1\xf4L(\xf9\xac\'\xc5\x9a\xdc\xf5s\ > xc6`\x97\xe6\xea\xf8\xcc\xfa\xe1U_\xff\x86\xf0\x82\xab\xaf\ > xb9\x92q\x06\x0f\xa5}]\x9c\xb1\x84b\x85<\xed\x92,g\x0e\xeaoAi|\xc5\n\x92', > form='der'), domains: [u'ipa-a'] > 2016-12-06 20:57:44,507:DEBUG:root:Requesting fresh nonce > 2016-12-06 20:57:44,507:DEBUG:root:Sending HEAD request to > https://acme-v01.api.letsencrypt.org/acme/new-authz. args: (), kwargs: {} > 2016-12-06 20:57:44,608:DEBUG:requests.packages.urllib3.connectionpool:"HEAD > /acme/new-authz HTTP/1.1" 405 0 > 2016-12-06 20:57:44,609:DEBUG:root:Received . Headers: > {'Content-Length': '91', 'Pragma': 'no-cache', 'Boulder-Request-Id': ' > c2cMPhHqlO5kTv8xJ5dfIs4NCD2KMqn8X-IxPzutDAI', 'Expires': 'Tue, 06 Dec > 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'keep-alive', 'Allow': > 'POST', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 > Dec 2016 20:57:46 GMT', 'Content-Type': 'application/problem+json', > 'Replay-Nonce': '3fq9edUYLFJwQKDU-oaLVpQdUglFemQpGNbwZ-AtmfI'}. Content: > '' > 2016-12-06 20:57:44,609:DEBUG:acme.client:Storing nonce: > '\xdd\xfa\xbdy\xd5\x18,Rp@\xa0\xd4\xfa\x86\x8bV\x94\x1dR\ > tEzd)\x18\xd6\xf0g\xe0-\x99\xf2' > 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted empty fields: > combinations=None, challenges=None, expires=None, status=None > 2016-12-06 20:57:44,610:DEBUG:acme.client:Serialized JSON: {"identifier": > {"type": "dns", "value": "ipa-a"}, "resource": "new-authz"} > 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted empty fields: > kid=None, x5c=(), crit=(), jwk=None, typ=None, jku=None, cty=None, > x5tS256=None, x5u=None, alg=None, x5t=None > 2016-12-06 20:57:44,612:DEBUG:acme.jose.json_util:Omitted empty fields: > kid=None, x5c=(), crit=(), typ=None, jku=None, cty=None, x5tS256=None, > x5u=None, x5t=None, nonce=None > 2016-12-06 20:57:44,612:DEBUG:root:Sending POST request to > https://acme-v01.api.letsencrypt.org/acme/new-authz. args: (), kwargs: > {'data': '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", > "n": "vmM8XoN-WDCdPcaMNxu9zlLEJBBN-W_pIkG-Afw5uawBBXWHbWyzUeb06LypMM94Lc > Ti0drWTf00Fdv5SiVKMAwwAoqH-Xzv5LHBwYmqNFGr-W6cphQjNTP21IP87NKxG87OdvvOMjE > --oMuJJMYWbyAAcOZNhIobWp969EMGu9Oi5JeQI1bLqIHS317xWDPD_ > EMTmhnVxZGBuS5gs_ObYejnJmGyu4_Bn1yLIDlBuphYsHg0pWoAgjZQAr3NI > 4N7oVrB-LiW21-k9I-LH3dijxVLBe_7jfKsIsVTJyzMzl- > g2iAeogYHfRngkhnQVXfhSleeZbfHwKXPs5FdmnHBw"}}, "protected": " > eyJub25jZSI6ICIzZnE5ZWRVWUxGSndRS0RVLW9hTFZwUWRVZ2xGZW1RcEdOYndaLUF0bWZJIn0", > "payload": "eyJpZGVudGlmaWVyIjogeyJ0eXBlIjogImRucyIsICJ2YWx1ZSI6ICJpcGEt > YSJ9LCAicmVzb3VyY2UiOiAibmV3LWF1dGh6In0", "signature": " > sDGSJkUMIFVRr7YGU33exEVslJFZlZoTuyv74F_XtloybjzZFg81r8ONbCUXtU6Q1COsA > 1M9df_vpL1b8Pz2bhfgEkG7taiaHDEyK-PGx5cn9U4vgSp3uZMNfVGFK- > 0gSYxLIsI0AgEIV8rTVKVw5kHVhn8Ob7gCuBgz1QkGr8WefqAcJ6vxycvbPB > Xh3GlpHylKDNTEsH5kbdKtfg5bKJu8RDLFBhAZCFub61EwkeT7HfvhsWkaXJQhoolWiFn_ > 3PjAZCEZzPL5igCOW0V65OEp6O3wdnC4FwS0BwxE0CxB2QA2mXMdvX4SILRf > 5mhzhTOmdTL0gLYXffI1XErbvg"}'} > 2016-12-06 20:57:44,728:DEBUG:requests.packages.urllib3.connectionpool:"POST > /acme/new-authz HTTP/1.1" 400 109 > 2016-12-06 20:57:44,730:DEBUG:root:Received . Headers: > {'Content-Length': '109', 'Boulder-Request-Id': 'z34CxBq8_ > BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': 'Tue, 06 Dec 2016 > 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'close', 'Cache-Control': > 'max-age=0, no-cache, no-store', 'Pragma': 'no-cache', 'Boulder-Requester': > '6994631', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', 'Content-Type': > 'application/problem+json', 'Replay-Nonce': ' > YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}. Content: '{\n "type": > "urn:acme:error:malformed",\n "detail": "DNS name does not have enough > labels",\n "status": 400\n}' > 2016-12-06 20:57:44,730:DEBUG:acme.client:Storing nonce: > "b\x84\x8d\xa4\xb4\xf5D\x94\x8d\xe6\xd5\x15\x11k\xa3\xaf\ > x18\xd9\xe0\xbchS\xe8\xca\x9d\xcb'\xd5\xa3}\x1cR" > 2016-12-06 20:57:44,730:DEBUG:acme.client:Received response [400]> (headers: {'Content-Length': '109', 'Boulder-Request-Id': 'z34CxBq8_ > BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': 'Tue, 06 Dec 2016 > 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'close', 'Cache-Control': > 'max-age=0, no-cache, no-store', 'Pragma': 'no-cache', 'Boulder-Requester': > '6994631', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', 'Content-Type': > 'application/problem+json', 'Replay-Nonce': ' > YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}): '{\n "type": > "urn:acme:error:malformed",\n "detail": "DNS name does not have enough > labels",\n "status": 400\n}' > 2016-12-06 20:57:44,735:DEBUG:certbot.main:Exiting abnormally: > Traceback (most recent call last): > File "/usr/bin/letsencrypt", line 9, in > load_entry_point('certbot==0.9.3', 'console_scripts', 'certbot')() > File "/usr/lib/python2.7/site-packages/certbot/main.py", line 776, in > main > return config.func(config, plugins) > File "/usr/lib/python2.7/site-packages/certbot/main.py", line 566, in > obtain_cert > _csr_obtain_cert(config, le_client) > File "/usr/lib/python2.7/site-packages/certbot/main.py", line 535, in > _csr_obtain_cert > certr, chain = le_client.obtain_certificate_from_csr(config.domains, > csr, typ) > File "/usr/lib/python2.7/site-packages/certbot/client.py", line 229, in > obtain_certificate_from_csr > authzr = self.auth_handler.get_authorizations(domains) > File "/usr/lib/python2.7/site-packages/certbot/auth_handler.py", line > 68, in get_authorizations > domain, self.account.regr.new_authzr_uri) > File "/usr/lib/python2.7/site-packages/acme/client.py", line 210, in > request_domain_challenges > typ=messages.IDENTIFIER_FQDN, value=domain), new_authzr_uri) > File "/usr/lib/python2.7/site-packages/acme/client.py", line 190, in > request_challenges > new_authz) > File "/usr/lib/python2.7/site-packages/acme/client.py", line 649, in > post > return self._check_response(response, content_type=content_type) > File "/usr/lib/python2.7/site-packages/acme/client.py", line 565, in > _check_response > raise messages.Error.from_json(jobj) > Error: urn:acme:error:malformed :: The request message was malformed :: > DNS name does not have enough labels > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12140 bytes Desc: not available URL: From mbasti at redhat.com Wed Dec 7 15:50:49 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Dec 2016 16:50:49 +0100 Subject: [Freeipa-users] Let's Encrypt Install: Made a bit of install progress, next error In-Reply-To: References: Message-ID: <99caef02-1c86-92e3-bdb4-a5206d80b9f8@redhat.com> What does `hostname` command return? On 07.12.2016 16:37, Joseph Flynn wrote: > Sorry, I wasn't clear in my earlier subject line. This is related to > the Lets Encrypt installation. > > I tried to pull some more relevant items from the log below. I don't > actually see all of the elements of my FQDN (ipa-a.kkgpitt.org > ) only references to the host (ipa-a) in the > log, but am not sure what a good log should include. > > Thanks for any assistance, > Joe > > > On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn > wrote: > > Volunteers, > > I moved over to a Fedora VM which was way more difficult than it > should be. All kinds of problems with Guest Additions and I ended > up having to run server mode with no GUI. Now I run an Ubuntu VM > from which I ssh into my Fedora VM. Anyway... > > The install made it a further step than before. I get a quick > blue screen pop up at the end then an error saying: > Inline image 1 > > An unexpected error occurred: > The request message was malformed :: DNS name does not have > enough labels > Please see the logfiles in /var/log/letsencrypt for more details. > > > When I run the cert checker util I get this > https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org > > > > Full log below. > > Any suggestions? Is it not pulling my proper hostname? > > Thanks, > Joe > > > > > > [jjflynn22 at ipa-a ~]$ cat /etc/hosts > 192.168.1.211ipa-a.kkgpitt.org ipa-a > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 > > > > > [jjflynn22 at ipa-a ~]$ sudo cat /var/log/letsencrypt/letsencrypt.log > [sudo] password for jjflynn22: > 2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level set > at 20 > 2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to > /var/log/letsencrypt/letsencrypt.log > 2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3 > 2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments: > ['--standalone', '--csr', '/root/ipa-le/httpd-csr.der', '--email', > 'xxxxx at gmail.com ', '--agree-tos'] > 2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered plugins: > PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone) > 2016-12-06 20:57:43,995:DEBUG:certbot.plugins.selection:Requested > authenticator standalone and installer None > 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Single > candidate plugin: * standalone > Description: Spin up a temporary webserver > Interfaces: IAuthenticator, IPlugin > Entry point: standalone = certbot.plugins.standalone:Authenticator > Initialized: 0x7fc3dc6fccd0> > Prep: True > 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Selected > authenticator 0x7fc3dc6fccd0> and installer None > 2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account: > > 2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to > https://acme-v01.api.letsencrypt.org/directory > . args: (), kwargs: {} > 2016-12-06 > 20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting > new HTTPS connection (1): acme-v01.api.letsencrypt.org > > 2016-12-06 > 20:57:44,500:DEBUG:requests.packages.urllib3.connectionpool:"GET > /directory HTTP/1.1" 200 280 > 2016-12-06 20:57:44,506:DEBUG:root:Received . > Headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 > 20:57:46 GMT', 'Boulder-Request-Id': > 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', > 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', > 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': > 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 > 20:57:46 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': > 'application/json', 'Replay-Nonce': > 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}. Content: '{\n > "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz > ",\n > "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert > ",\n > "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg > ",\n > "revoke-cert": > "https://acme-v01.api.letsencrypt.org/acme/revoke-cert > "\n}' > 2016-12-06 20:57:44,506:DEBUG:acme.client:Received response > (headers: {'Content-Length': '280', 'Expires': > 'Tue, 06 Dec 2016 20:57:46 GMT', 'Boulder-Request-Id': > 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', > 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', > 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': > 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 > 20:57:46 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': > 'application/json', 'Replay-Nonce': > 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}): '{\n > "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz > ",\n > "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert > ",\n > "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg > ",\n > "revoke-cert": > "https://acme-v01.api.letsencrypt.org/acme/revoke-cert > "\n}' > 2016-12-06 20:57:44,506:DEBUG:certbot.client:CSR: > CSR(file='/root/ipa-le/httpd-csr.der', > data='0\x82\x02x0\x82\x01`\x02\x01\x000\x101\x0e0\x0c\x06\x03U\x04\x03\x13\x05ipa-a0\x82\x01"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x01\x0f\x000\x82\x01\n\x02\x82\x01\x01\x00\xdau1L\xa6T\xc8\x93\xc0P\x93\xb3\xd2\xcb > \xe2PU\xf0\x94=\x1c\n\x1e\xe5\xfe\xed<\xfa\xb1d-\x92\xebeD\xb1\x0eq9\xf1\xfa\xb5p\xdc\x12qN\x96\x0b\x1f\x13\xab\xae > > ....... > > 99\xc0\xb0\x07N\xdd5\x9e1\xb8\xdc\x8c\xc1N\xc1\x04\xa1\xd0\xfc\xc2$f\x84e\xd4\xf7i\x1a\x1c~,\x80\xea/~j\xea\xa2\xf3\xe9\x96\xfe5j\xa4\xb4X\x12L\xd5\xe5\xb0\x99|\xb8\xd1\xed\xa3\xf2\xd5\xf0\x94\xc3"\xe8\x9dT\x17\xcf\x12$oVE\x83\xd1\x96\xac\xa1\xf9F\xd2mO\xe9$\xa7\x00_\xaa\xc6\xa3j\xa1\xbaX8\xa43K\x18os\xe1\xf4L(\xf9\xac\'\xc5\x9a\xdc\xf5s\xc6`\x97\xe6\xea\xf8\xcc\xfa\xe1U_\xff\x86\xf0\x82\xab\xaf\xb9\x92q\x06\x0f\xa5}]\x9c\xb1\x84b\x85<\xed\x92,g\x0e\xeaoAi|\xc5\n\x92', > form='der'), domains: [u'ipa-a'] > 2016-12-06 20:57:44,507:DEBUG:root:Requesting fresh nonce > 2016-12-06 20:57:44,507:DEBUG:root:Sending HEAD request to > https://acme-v01.api.letsencrypt.org/acme/new-authz > . args: (), > kwargs: {} > 2016-12-06 > 20:57:44,608:DEBUG:requests.packages.urllib3.connectionpool:"HEAD > /acme/new-authz HTTP/1.1" 405 0 > 2016-12-06 20:57:44,609:DEBUG:root:Received . > Headers: {'Content-Length': '91', 'Pragma': 'no-cache', > 'Boulder-Request-Id': > 'c2cMPhHqlO5kTv8xJ5dfIs4NCD2KMqn8X-IxPzutDAI', 'Expires': 'Tue, 06 > Dec 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': > 'keep-alive', 'Allow': 'POST', 'Cache-Control': 'max-age=0, > no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', > 'Content-Type': 'application/problem+json', 'Replay-Nonce': > '3fq9edUYLFJwQKDU-oaLVpQdUglFemQpGNbwZ-AtmfI'}. Content: '' > 2016-12-06 20:57:44,609:DEBUG:acme.client:Storing nonce: > '\xdd\xfa\xbdy\xd5\x18,Rp@\xa0\xd4\xfa\x86\x8bV\x94\x1dR\tEzd)\x18\xd6\xf0g\xe0-\x99\xf2' > 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted empty > fields: combinations=None, challenges=None, expires=None, status=None > 2016-12-06 20:57:44,610:DEBUG:acme.client:Serialized JSON: > {"identifier": {"type": "dns", "value": "ipa-a"}, "resource": > "new-authz"} > 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted empty > fields: kid=None, x5c=(), crit=(), jwk=None, typ=None, jku=None, > cty=None, x5tS256=None, x5u=None, alg=None, x5t=None > 2016-12-06 20:57:44,612:DEBUG:acme.jose.json_util:Omitted empty > fields: kid=None, x5c=(), crit=(), typ=None, jku=None, cty=None, > x5tS256=None, x5u=None, x5t=None, nonce=None > 2016-12-06 20:57:44,612:DEBUG:root:Sending POST request to > https://acme-v01.api.letsencrypt.org/acme/new-authz > . args: (), > kwargs: {'data': '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", > "kty": "RSA", "n": > "vmM8XoN-WDCdPcaMNxu9zlLEJBBN-W_pIkG-Afw5uawBBXWHbWyzUeb06LypMM94LcTi0drWTf00Fdv5SiVKMAwwAoqH-Xzv5LHBwYmqNFGr-W6cphQjNTP21IP87NKxG87OdvvOMjE--oMuJJMYWbyAAcOZNhIobWp969EMGu9Oi5JeQI1bLqIHS317xWDPD_EMTmhnVxZGBuS5gs_ObYejnJmGyu4_Bn1yLIDlBuphYsHg0pWoAgjZQAr3NI4N7oVrB-LiW21-k9I-LH3dijxVLBe_7jfKsIsVTJyzMzl-g2iAeogYHfRngkhnQVXfhSleeZbfHwKXPs5FdmnHBw"}}, > "protected": > "eyJub25jZSI6ICIzZnE5ZWRVWUxGSndRS0RVLW9hTFZwUWRVZ2xGZW1RcEdOYndaLUF0bWZJIn0", > "payload": > "eyJpZGVudGlmaWVyIjogeyJ0eXBlIjogImRucyIsICJ2YWx1ZSI6ICJpcGEtYSJ9LCAicmVzb3VyY2UiOiAibmV3LWF1dGh6In0", > "signature": > "sDGSJkUMIFVRr7YGU33exEVslJFZlZoTuyv74F_XtloybjzZFg81r8ONbCUXtU6Q1COsA1M9df_vpL1b8Pz2bhfgEkG7taiaHDEyK-PGx5cn9U4vgSp3uZMNfVGFK-0gSYxLIsI0AgEIV8rTVKVw5kHVhn8Ob7gCuBgz1QkGr8WefqAcJ6vxycvbPBXh3GlpHylKDNTEsH5kbdKtfg5bKJu8RDLFBhAZCFub61EwkeT7HfvhsWkaXJQhoolWiFn_3PjAZCEZzPL5igCOW0V65OEp6O3wdnC4FwS0BwxE0CxB2QA2mXMdvX4SILRf5mhzhTOmdTL0gLYXffI1XErbvg"}'} > 2016-12-06 > 20:57:44,728:DEBUG:requests.packages.urllib3.connectionpool:"POST > /acme/new-authz HTTP/1.1" 400 109 > 2016-12-06 20:57:44,730:DEBUG:root:Received . > Headers: {'Content-Length': '109', 'Boulder-Request-Id': > 'z34CxBq8_BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': 'Tue, 06 > Dec 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'close', > 'Cache-Control': 'max-age=0, no-cache, no-store', 'Pragma': > 'no-cache', 'Boulder-Requester': '6994631', 'Date': 'Tue, 06 Dec > 2016 20:57:46 GMT', 'Content-Type': 'application/problem+json', > 'Replay-Nonce': 'YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}. > Content: '{\n "type": "urn:acme:error:malformed",\n "detail": > "DNS name does not have enough labels",\n "status": 400\n}' > 2016-12-06 20:57:44,730:DEBUG:acme.client:Storing nonce: > "b\x84\x8d\xa4\xb4\xf5D\x94\x8d\xe6\xd5\x15\x11k\xa3\xaf\x18\xd9\xe0\xbchS\xe8\xca\x9d\xcb'\xd5\xa3}\x1cR" > 2016-12-06 20:57:44,730:DEBUG:acme.client:Received response > (headers: {'Content-Length': '109', > 'Boulder-Request-Id': > 'z34CxBq8_BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': 'Tue, 06 > Dec 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'close', > 'Cache-Control': 'max-age=0, no-cache, no-store', 'Pragma': > 'no-cache', 'Boulder-Requester': '6994631', 'Date': 'Tue, 06 Dec > 2016 20:57:46 GMT', 'Content-Type': 'application/problem+json', > 'Replay-Nonce': 'YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}): > '{\n "type": "urn:acme:error:malformed",\n "detail": "DNS name > does not have enough labels",\n "status": 400\n}' > 2016-12-06 20:57:44,735:DEBUG:certbot.main:Exiting abnormally: > Traceback (most recent call last): > File "/usr/bin/letsencrypt", line 9, in > load_entry_point('certbot==0.9.3', 'console_scripts', 'certbot')() > File "/usr/lib/python2.7/site-packages/certbot/main.py", line > 776, in main > return config.func(config, plugins) > File "/usr/lib/python2.7/site-packages/certbot/main.py", line > 566, in obtain_cert > _csr_obtain_cert(config, le_client) > File "/usr/lib/python2.7/site-packages/certbot/main.py", line > 535, in _csr_obtain_cert > certr, chain = > le_client.obtain_certificate_from_csr(config.domains, csr, typ) > File "/usr/lib/python2.7/site-packages/certbot/client.py", line > 229, in obtain_certificate_from_csr > authzr = self.auth_handler.get_authorizations(domains) > File "/usr/lib/python2.7/site-packages/certbot/auth_handler.py", > line 68, in get_authorizations > domain, self.account.regr.new_authzr_uri) > File "/usr/lib/python2.7/site-packages/acme/client.py", line > 210, in request_domain_challenges > typ=messages.IDENTIFIER_FQDN, value=domain), new_authzr_uri) > File "/usr/lib/python2.7/site-packages/acme/client.py", line > 190, in request_challenges > new_authz) > File "/usr/lib/python2.7/site-packages/acme/client.py", line > 649, in post > return self._check_response(response, content_type=content_type) > File "/usr/lib/python2.7/site-packages/acme/client.py", line > 565, in _check_response > raise messages.Error.from_json(jobj) > Error: urn:acme:error:malformed :: The request message was > malformed :: DNS name does not have enough labels > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 12140 bytes Desc: not available URL: From jjflynn22 at gmail.com Wed Dec 7 15:52:37 2016 From: jjflynn22 at gmail.com (Joseph Flynn) Date: Wed, 7 Dec 2016 10:52:37 -0500 Subject: [Freeipa-users] Let's Encrypt Install: Made a bit of install progress, next error In-Reply-To: <99caef02-1c86-92e3-bdb4-a5206d80b9f8@redhat.com> References: <99caef02-1c86-92e3-bdb4-a5206d80b9f8@redhat.com> Message-ID: Damn, I thought I already fixed that but didn't. Hold while I rerun... I bet that was it. On Wed, Dec 7, 2016 at 10:50 AM, Martin Basti wrote: > What does `hostname` command return? > > On 07.12.2016 16:37, Joseph Flynn wrote: > > Sorry, I wasn't clear in my earlier subject line. This is related to the > Lets Encrypt installation. > > I tried to pull some more relevant items from the log below. I don't > actually see all of the elements of my FQDN (ipa-a.kkgpitt.org) only > references to the host (ipa-a) in the log, but am not sure what a good log > should include. > > Thanks for any assistance, > Joe > > > On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn wrote: > >> Volunteers, >> >> I moved over to a Fedora VM which was way more difficult than it should >> be. All kinds of problems with Guest Additions and I ended up having to >> run server mode with no GUI. Now I run an Ubuntu VM from which I ssh into >> my Fedora VM. Anyway... >> >> The install made it a further step than before. I get a quick blue >> screen pop up at the end then an error saying: >> [image: Inline image 1] >> >> An unexpected error occurred: >>> The request message was malformed :: DNS name does not have enough labels >>> Please see the logfiles in /var/log/letsencrypt for more details. >>> >> >> When I run the cert checker util I get this >> https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org >> >> Full log below. >> >> Any suggestions? Is it not pulling my proper hostname? >> >> Thanks, >> Joe >> >> >> >> >> >> [jjflynn22 at ipa-a ~]$ cat /etc/hosts >> 192.168.1.211 ipa-a.kkgpitt.org ipa-a >> 127.0.0.1 localhost localhost.localdomain localhost4 >> localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 >> localhost6.localdomain6 >> >> >> >> >> [jjflynn22 at ipa-a ~]$ sudo cat /var/log/letsencrypt/letsencrypt.log >> [sudo] password for jjflynn22: >> 2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level set at 20 >> 2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to >> /var/log/letsencrypt/letsencrypt.log >> 2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3 >> 2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments: ['--standalone', >> '--csr', '/root/ipa-le/httpd-csr.der', '--email', 'xxxxx at gmail.com', >> '--agree-tos'] >> 2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered plugins: >> PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint# >> null,PluginEntryPoint#manual,PluginEntryPoint#standalone) >> 2016-12-06 20:57:43,995:DEBUG:certbot.plugins.selection:Requested >> authenticator standalone and installer None >> 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Single candidate >> plugin: * standalone >> Description: Spin up a temporary webserver >> Interfaces: IAuthenticator, IPlugin >> Entry point: standalone = certbot.plugins.standalone:Authenticator >> Initialized: > 0x7fc3dc6fccd0> >> Prep: True >> 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Selected >> authenticator > 0x7fc3dc6fccd0> and installer None >> 2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account: >> >> 2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to >> https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {} >> 2016-12-06 20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting >> new HTTPS connection (1): acme-v01.api.letsencrypt.org >> 2016-12-06 20:57:44,500:DEBUG:requests.packages.urllib3.connectionpool:"GET >> /directory HTTP/1.1" 200 280 >> 2016-12-06 20:57:44,506:DEBUG:root:Received . Headers: >> {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT', >> 'Boulder-Request-Id': 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', >> 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', >> 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': >> 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', >> 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', >> 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}. Content: >> '{\n "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n >> "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n >> "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n >> "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert >> "\n}' >> 2016-12-06 20:57:44,506:DEBUG:acme.client:Received response > [200]> (headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 >> 20:57:46 GMT', 'Boulder-Request-Id': 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', >> 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', >> 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': >> 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', >> 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', >> 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}): '{\n >> "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n >> "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n >> "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n >> "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert >> "\n}' >> 2016-12-06 20:57:44,506:DEBUG:certbot.client:CSR: >> CSR(file='/root/ipa-le/httpd-csr.der', data='0\x82\x02x0\x82\x01`\x02 >> \x01\x000\x101\x0e0\x0c\x06\x03U\x04\x03\x13\x05ipa-a0\ >> x82\x01"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\ >> x82\x01\x0f\x000\x82\x01\n\x02\x82\x01\x01\x00\xdau1L\xa6T\xc8\x93\xc0P\x93\xb3\xd2\xcb >> \xe2PU\xf0\x94=\x1c\n\x1e\xe5\xfe\xed<\xfa\xb1d-\x92\xebeD\x >> b1\x0eq9\xf1\xfa\xb5p\xdc\x12qN\x96\x0b\x1f\x13\xab\xae >> >> ....... >> >> 99\xc0\xb0\x07N\xdd5\x9e1\xb8\xdc\x8c\xc1N\xc1\x04\xa1\xd0\x >> fc\xc2$f\x84e\xd4\xf7i\x1a\x1c~,\x80\xea/~j\xea\xa2\xf3\xe9\ >> x96\xfe5j\xa4\xb4X\x12L\xd5\xe5\xb0\x99|\xb8\xd1\xed\xa3\ >> xf2\xd5\xf0\x94\xc3"\xe8\x9dT\x17\xcf\x12$oVE\x83\xd1\x96\ >> xac\xa1\xf9F\xd2mO\xe9$\xa7\x00_\xaa\xc6\xa3j\xa1\xbaX8\ >> xa43K\x18os\xe1\xf4L(\xf9\xac\'\xc5\x9a\xdc\xf5s\xc6`\x97\ >> xe6\xea\xf8\xcc\xfa\xe1U_\xff\x86\xf0\x82\xab\xaf\xb9\x92q\ >> x06\x0f\xa5}]\x9c\xb1\x84b\x85<\xed\x92,g\x0e\xeaoAi|\xc5\n\x92', >> form='der'), domains: [u'ipa-a'] >> 2016-12-06 20:57:44,507:DEBUG:root:Requesting fresh nonce >> 2016-12-06 20:57:44,507:DEBUG:root:Sending HEAD request to >> https://acme-v01.api.letsencrypt.org/acme/new-authz. args: (), kwargs: {} >> 2016-12-06 20:57:44,608:DEBUG:requests.packages.urllib3.connectionpool:"HEAD >> /acme/new-authz HTTP/1.1" 405 0 >> 2016-12-06 20:57:44,609:DEBUG:root:Received . Headers: >> {'Content-Length': '91', 'Pragma': 'no-cache', 'Boulder-Request-Id': >> 'c2cMPhHqlO5kTv8xJ5dfIs4NCD2KMqn8X-IxPzutDAI', 'Expires': 'Tue, 06 Dec >> 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'keep-alive', 'Allow': >> 'POST', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 >> Dec 2016 20:57:46 GMT', 'Content-Type': 'application/problem+json', >> 'Replay-Nonce': '3fq9edUYLFJwQKDU-oaLVpQdUglFemQpGNbwZ-AtmfI'}. Content: >> '' >> 2016-12-06 20:57:44,609:DEBUG:acme.client:Storing nonce: >> '\xdd\xfa\xbdy\xd5\x18,Rp@\xa0\xd4\xfa\x86\x8bV\x94\x1dR\tEz >> d)\x18\xd6\xf0g\xe0-\x99\xf2' >> 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted empty fields: >> combinations=None, challenges=None, expires=None, status=None >> 2016-12-06 20:57:44,610:DEBUG:acme.client:Serialized JSON: >> {"identifier": {"type": "dns", "value": "ipa-a"}, "resource": >> "new-authz"} >> 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted empty fields: >> kid=None, x5c=(), crit=(), jwk=None, typ=None, jku=None, cty=None, >> x5tS256=None, x5u=None, alg=None, x5t=None >> 2016-12-06 20:57:44,612:DEBUG:acme.jose.json_util:Omitted empty fields: >> kid=None, x5c=(), crit=(), typ=None, jku=None, cty=None, x5tS256=None, >> x5u=None, x5t=None, nonce=None >> 2016-12-06 20:57:44,612:DEBUG:root:Sending POST request to >> https://acme-v01.api.letsencrypt.org/acme/new-authz. args: (), kwargs: >> {'data': '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", >> "n": "vmM8XoN-WDCdPcaMNxu9zlLEJBBN-W_pIkG-Afw5uawBBXWHbWyzUeb06Ly >> pMM94LcTi0drWTf00Fdv5SiVKMAwwAoqH-Xzv5LHBwYmqNFGr-W6cphQjNTP >> 21IP87NKxG87OdvvOMjE--oMuJJMYWbyAAcOZNhIobWp969EMGu9Oi5JeQI1 >> bLqIHS317xWDPD_EMTmhnVxZGBuS5gs_ObYejnJmGyu4_Bn1yLIDlBuphYsH >> g0pWoAgjZQAr3NI4N7oVrB-LiW21-k9I-LH3dijxVLBe_7jfKsIsVTJyzMz >> l-g2iAeogYHfRngkhnQVXfhSleeZbfHwKXPs5FdmnHBw"}}, "protected": >> "eyJub25jZSI6ICIzZnE5ZWRVWUxGSndRS0RVLW9hTFZwUWRVZ2xGZW1RcEdOYndaLUF0bWZJIn0", >> "payload": "eyJpZGVudGlmaWVyIjogeyJ0eXBlIjogImRucyIsICJ2YWx1ZSI6ICJpcGE >> tYSJ9LCAicmVzb3VyY2UiOiAibmV3LWF1dGh6In0", "signature": >> "sDGSJkUMIFVRr7YGU33exEVslJFZlZoTuyv74F_XtloybjzZFg81r8ONbCU >> XtU6Q1COsA1M9df_vpL1b8Pz2bhfgEkG7taiaHDEyK-PGx5cn9U4vgSp3uZM >> NfVGFK-0gSYxLIsI0AgEIV8rTVKVw5kHVhn8Ob7gCuBgz1QkGr8WefqAcJ6v >> xycvbPBXh3GlpHylKDNTEsH5kbdKtfg5bKJu8RDLFBhAZCFub61EwkeT7Hfv >> hsWkaXJQhoolWiFn_3PjAZCEZzPL5igCOW0V65OEp6O3wdnC4FwS0BwxE0Cx >> B2QA2mXMdvX4SILRf5mhzhTOmdTL0gLYXffI1XErbvg"}'} >> 2016-12-06 20:57:44,728:DEBUG:requests.packages.urllib3.connectionpool:"POST >> /acme/new-authz HTTP/1.1" 400 109 >> 2016-12-06 20:57:44,730:DEBUG:root:Received . Headers: >> {'Content-Length': '109', 'Boulder-Request-Id': >> 'z34CxBq8_BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': 'Tue, 06 Dec >> 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'close', >> 'Cache-Control': 'max-age=0, no-cache, no-store', 'Pragma': 'no-cache', >> 'Boulder-Requester': '6994631', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', >> 'Content-Type': 'application/problem+json', 'Replay-Nonce': >> 'YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}. Content: '{\n "type": >> "urn:acme:error:malformed",\n "detail": "DNS name does not have enough >> labels",\n "status": 400\n}' >> 2016-12-06 20:57:44,730:DEBUG:acme.client:Storing nonce: >> "b\x84\x8d\xa4\xb4\xf5D\x94\x8d\xe6\xd5\x15\x11k\xa3\xaf\x18 >> \xd9\xe0\xbchS\xe8\xca\x9d\xcb'\xd5\xa3}\x1cR" >> 2016-12-06 20:57:44,730:DEBUG:acme.client:Received response > [400]> (headers: {'Content-Length': '109', 'Boulder-Request-Id': >> 'z34CxBq8_BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': 'Tue, 06 Dec >> 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'close', >> 'Cache-Control': 'max-age=0, no-cache, no-store', 'Pragma': 'no-cache', >> 'Boulder-Requester': '6994631', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', >> 'Content-Type': 'application/problem+json', 'Replay-Nonce': >> 'YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}): '{\n "type": >> "urn:acme:error:malformed",\n "detail": "DNS name does not have enough >> labels",\n "status": 400\n}' >> 2016-12-06 20:57:44,735:DEBUG:certbot.main:Exiting abnormally: >> Traceback (most recent call last): >> File "/usr/bin/letsencrypt", line 9, in >> load_entry_point('certbot==0.9.3', 'console_scripts', 'certbot')() >> File "/usr/lib/python2.7/site-packages/certbot/main.py", line 776, in >> main >> return config.func(config, plugins) >> File "/usr/lib/python2.7/site-packages/certbot/main.py", line 566, in >> obtain_cert >> _csr_obtain_cert(config, le_client) >> File "/usr/lib/python2.7/site-packages/certbot/main.py", line 535, in >> _csr_obtain_cert >> certr, chain = le_client.obtain_certificate_from_csr(config.domains, >> csr, typ) >> File "/usr/lib/python2.7/site-packages/certbot/client.py", line 229, >> in obtain_certificate_from_csr >> authzr = self.auth_handler.get_authorizations(domains) >> File "/usr/lib/python2.7/site-packages/certbot/auth_handler.py", line >> 68, in get_authorizations >> domain, self.account.regr.new_authzr_uri) >> File "/usr/lib/python2.7/site-packages/acme/client.py", line 210, in >> request_domain_challenges >> typ=messages.IDENTIFIER_FQDN, value=domain), new_authzr_uri) >> File "/usr/lib/python2.7/site-packages/acme/client.py", line 190, in >> request_challenges >> new_authz) >> File "/usr/lib/python2.7/site-packages/acme/client.py", line 649, in >> post >> return self._check_response(response, content_type=content_type) >> File "/usr/lib/python2.7/site-packages/acme/client.py", line 565, in >> _check_response >> raise messages.Error.from_json(jobj) >> Error: urn:acme:error:malformed :: The request message was malformed :: >> DNS name does not have enough labels >> >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 12140 bytes Desc: not available URL: From mbasti at redhat.com Wed Dec 7 15:56:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 7 Dec 2016 16:56:13 +0100 Subject: [Freeipa-users] Let's Encrypt Install: Made a bit of install progress, next error In-Reply-To: References: <99caef02-1c86-92e3-bdb4-a5206d80b9f8@redhat.com> Message-ID: <9c6d8980-6835-0388-71de-40c695f46ba1@redhat.com> Please make sure you use `hostnamectl set-hostname FQDN` to set all hostnames on system (static, tentaive, current ....) Martin On 07.12.2016 16:52, Joseph Flynn wrote: > Damn, I thought I already fixed that but didn't. Hold while I > rerun... I bet that was it. > > On Wed, Dec 7, 2016 at 10:50 AM, Martin Basti > wrote: > > What does `hostname` command return? > > > On 07.12.2016 16:37, Joseph Flynn wrote: >> Sorry, I wasn't clear in my earlier subject line. This is >> related to the Lets Encrypt installation. >> >> I tried to pull some more relevant items from the log below. I >> don't actually see all of the elements of my FQDN >> (ipa-a.kkgpitt.org ) only references to >> the host (ipa-a) in the log, but am not sure what a good log >> should include. >> >> Thanks for any assistance, >> Joe >> >> >> On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn > > wrote: >> >> Volunteers, >> >> I moved over to a Fedora VM which was way more difficult than >> it should be. All kinds of problems with Guest Additions and >> I ended up having to run server mode with no GUI. Now I run >> an Ubuntu VM from which I ssh into my Fedora VM. Anyway... >> >> The install made it a further step than before. I get a >> quick blue screen pop up at the end then an error saying: >> Inline image 1 >> >> An unexpected error occurred: >> The request message was malformed :: DNS name does not >> have enough labels >> Please see the logfiles in /var/log/letsencrypt for more >> details. >> >> >> When I run the cert checker util I get this >> https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org >> >> >> >> Full log below. >> >> Any suggestions? Is it not pulling my proper hostname? >> >> Thanks, >> Joe >> >> >> >> >> >> [jjflynn22 at ipa-a ~]$ cat /etc/hosts >> 192.168.1.211ipa-a.kkgpitt.org ipa-a >> 127.0.0.1 localhost localhost.localdomain localhost4 >> localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 >> localhost6.localdomain6 >> >> >> >> >> [jjflynn22 at ipa-a ~]$ sudo cat >> /var/log/letsencrypt/letsencrypt.log >> [sudo] password for jjflynn22: >> 2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level >> set at 20 >> 2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to >> /var/log/letsencrypt/letsencrypt.log >> 2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3 >> 2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments: >> ['--standalone', '--csr', '/root/ipa-le/httpd-csr.der', >> '--email', 'xxxxx at gmail.com ', >> '--agree-tos'] >> 2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered >> plugins: >> PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone) >> 2016-12-06 >> 20:57:43,995:DEBUG:certbot.plugins.selection:Requested >> authenticator standalone and installer None >> 2016-12-06 >> 20:57:44,019:DEBUG:certbot.plugins.selection:Single candidate >> plugin: * standalone >> Description: Spin up a temporary webserver >> Interfaces: IAuthenticator, IPlugin >> Entry point: standalone = >> certbot.plugins.standalone:Authenticator >> Initialized: > thenticator object at >> 0x7fc3dc6fccd0> >> Prep: True >> 2016-12-06 >> 20:57:44,019:DEBUG:certbot.plugins.selection:Selected >> authenticator > thenticator object at >> 0x7fc3dc6fccd0> and installer None >> 2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account: >> >> 2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to >> https://acme-v01.api.letsencrypt.org/directory >> . args: (), >> kwargs: {} >> 2016-12-06 >> 20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting >> new HTTPS connection (1): acme-v01.api.letsencrypt.org >> >> 2016-12-06 20:57:44,500:DEBUG:requests.pa >> ckages.urllib3.connectionpool:"GET >> /directory HTTP/1.1" 200 280 >> 2016-12-06 20:57:44,506:DEBUG:root:Received . >> Headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec >> 2016 20:57:46 GMT', 'Boulder-Request-Id': >> 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', >> 'Strict-Transport-Security': 'max-age=604800', 'Server': >> 'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache', >> 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': >> 'Tue, 06 Dec 2016 20:57:46 GMT', 'X-Frame-Options': 'DENY', >> 'Content-Type': 'application/json', 'Replay-Nonce': >> 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}. Content: >> '{\n "new-authz": >> "https://acme-v01.api.letsencrypt.org/acme/new-authz >> ",\n >> "new-cert": >> "https://acme-v01.api.letsencrypt.org/acme/new-cert >> ",\n >> "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg >> ",\n >> "revoke-cert": >> "https://acme-v01.api.letsencrypt.org/acme/revoke-cert >> "\n}' >> 2016-12-06 20:57:44,506:DEBUG:acme.client:Received response >> (headers: {'Content-Length': '280', >> 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT', >> 'Boulder-Request-Id': >> 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', >> 'Strict-Transport-Security': 'max-age=604800', 'Server': >> 'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache', >> 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': >> 'Tue, 06 Dec 2016 20:57:46 GMT', 'X-Frame-Options': 'DENY', >> 'Content-Type': 'application/json', 'Replay-Nonce': >> 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}): '{\n >> "new-authz": >> "https://acme-v01.api.letsencrypt.org/acme/new-authz >> ",\n >> "new-cert": >> "https://acme-v01.api.letsencrypt.org/acme/new-cert >> ",\n >> "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg >> ",\n >> "revoke-cert": >> "https://acme-v01.api.letsencrypt.org/acme/revoke-cert >> "\n}' >> 2016-12-06 20:57:44,506:DEBUG:certbot.client:CSR: >> CSR(file='/root/ipa-le/httpd-csr.der', >> data='0\x82\x02x0\x82\x01`\x02\x01\x000\x101\x0e0\x0c\x06\x03U\x04\x03\x13\x05ipa-a0\x82\x01"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x01\x0f\x000\x82\x01\n\x02\x82\x01\x01\x00\xdau1L\xa6T\xc8\x93\xc0P\x93\xb3\xd2\xcb >> \xe2PU\xf0\x94=\x1c\n\x1e\xe5\xfe\xed<\xfa\xb1d-\x92\xebeD\xb1\x0eq9\xf1\xfa\xb5p\xdc\x12qN\x96\x0b\x1f\x13\xab\xae >> >> ....... >> >> 99\xc0\xb0\x07N\xdd5\x9e1\xb8\xdc\x8c\xc1N\xc1\x04\xa1\xd0\xfc\xc2$f\x84e\xd4\xf7i\x1a\x1c~,\x80\xea/~j\xea\xa2\xf3\xe9\x96\xfe5j\xa4\xb4X\x12L\xd5\xe5\xb0\x99|\xb8\xd1\xed\xa3\xf2\xd5\xf0\x94\xc3"\xe8\x9dT\x17\xcf\x12$oVE\x83\xd1\x96\xac\xa1\xf9F\xd2mO\xe9$\xa7\x00_\xaa\xc6\xa3j\xa1\xbaX8\xa43K\x18os\xe1\xf4L(\xf9\xac\'\xc5\x9a\xdc\xf5s\xc6`\x97\xe6\xea\xf8\xcc\xfa\xe1U_\xff\x86\xf0\x82\xab\xaf\xb9\x92q\x06\x0f\xa5}]\x9c\xb1\x84b\x85<\xed\x92,g\x0e\xeaoAi|\xc5\n\x92', >> form='der'), domains: [u'ipa-a'] >> 2016-12-06 20:57:44,507:DEBUG:root:Requesting fresh nonce >> 2016-12-06 20:57:44,507:DEBUG:root:Sending HEAD request to >> https://acme-v01.api.letsencrypt.org/acme/new-authz >> . args: >> (), kwargs: {} >> 2016-12-06 20:57:44,608:DEBUG:requests.pa >> ckages.urllib3.connectionpool:"HEAD >> /acme/new-authz HTTP/1.1" 405 0 >> 2016-12-06 20:57:44,609:DEBUG:root:Received . >> Headers: {'Content-Length': '91', 'Pragma': 'no-cache', >> 'Boulder-Request-Id': >> 'c2cMPhHqlO5kTv8xJ5dfIs4NCD2KMqn8X-IxPzutDAI', 'Expires': >> 'Tue, 06 Dec 2016 20:57:46 GMT', 'Server': 'nginx', >> 'Connection': 'keep-alive', 'Allow': 'POST', 'Cache-Control': >> 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 >> 20:57:46 GMT', 'Content-Type': 'application/problem+json', >> 'Replay-Nonce': >> '3fq9edUYLFJwQKDU-oaLVpQdUglFemQpGNbwZ-AtmfI'}. Content: '' >> 2016-12-06 20:57:44,609:DEBUG:acme.client:Storing nonce: >> '\xdd\xfa\xbdy\xd5\x18,Rp@\xa0\xd4\xfa\x86\x8bV\x94\x1dR\tEzd)\x18\xd6\xf0g\xe0-\x99\xf2' >> 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted >> empty fields: combinations=None, challenges=None, >> expires=None, status=None >> 2016-12-06 20:57:44,610:DEBUG:acme.client:Serialized JSON: >> {"identifier": {"type": "dns", "value": "ipa-a"}, "resource": >> "new-authz"} >> 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted >> empty fields: kid=None, x5c=(), crit=(), jwk=None, typ=None, >> jku=None, cty=None, x5tS256=None, x5u=None, alg=None, x5t=None >> 2016-12-06 20:57:44,612:DEBUG:acme.jose.json_util:Omitted >> empty fields: kid=None, x5c=(), crit=(), typ=None, jku=None, >> cty=None, x5tS256=None, x5u=None, x5t=None, nonce=None >> 2016-12-06 20:57:44,612:DEBUG:root:Sending POST request to >> https://acme-v01.api.letsencrypt.org/acme/new-authz >> . args: >> (), kwargs: {'data': '{"header": {"alg": "RS256", "jwk": >> {"e": "AQAB", "kty": "RSA", "n": >> "vmM8XoN-WDCdPcaMNxu9zlLEJBBN-W_pIkG-Afw5uawBBXWHbWyzUeb06LypMM94LcTi0drWTf00Fdv5SiVKMAwwAoqH-Xzv5LHBwYmqNFGr-W6cphQjNTP21IP87NKxG87OdvvOMjE--oMuJJMYWbyAAcOZNhIobWp969EMGu9Oi5JeQI1bLqIHS317xWDPD_EMTmhnVxZGBuS5gs_ObYejnJmGyu4_Bn1yLIDlBuphYsHg0pWoAgjZQAr3NI4N7oVrB-LiW21-k9I-LH3dijxVLBe_7jfKsIsVTJyzMzl-g2iAeogYHfRngkhnQVXfhSleeZbfHwKXPs5FdmnHBw"}}, >> "protected": >> "eyJub25jZSI6ICIzZnE5ZWRVWUxGSndRS0RVLW9hTFZwUWRVZ2xGZW1RcEdOYndaLUF0bWZJIn0", >> "payload": >> "eyJpZGVudGlmaWVyIjogeyJ0eXBlIjogImRucyIsICJ2YWx1ZSI6ICJpcGEtYSJ9LCAicmVzb3VyY2UiOiAibmV3LWF1dGh6In0", >> "signature": >> "sDGSJkUMIFVRr7YGU33exEVslJFZlZoTuyv74F_XtloybjzZFg81r8ONbCUXtU6Q1COsA1M9df_vpL1b8Pz2bhfgEkG7taiaHDEyK-PGx5cn9U4vgSp3uZMNfVGFK-0gSYxLIsI0AgEIV8rTVKVw5kHVhn8Ob7gCuBgz1QkGr8WefqAcJ6vxycvbPBXh3GlpHylKDNTEsH5kbdKtfg5bKJu8RDLFBhAZCFub61EwkeT7HfvhsWkaXJQhoolWiFn_3PjAZCEZzPL5igCOW0V65OEp6O3wdnC4FwS0BwxE0CxB2QA2mXMdvX4SILRf5mhzhTOmdTL0gLYXffI1XErbvg"}'} >> 2016-12-06 20:57:44,728:DEBUG:requests.pa >> ckages.urllib3.connectionpool:"POST >> /acme/new-authz HTTP/1.1" 400 109 >> 2016-12-06 20:57:44,730:DEBUG:root:Received . >> Headers: {'Content-Length': '109', 'Boulder-Request-Id': >> 'z34CxBq8_BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': >> 'Tue, 06 Dec 2016 20:57:46 GMT', 'Server': 'nginx', >> 'Connection': 'close', 'Cache-Control': 'max-age=0, no-cache, >> no-store', 'Pragma': 'no-cache', 'Boulder-Requester': >> '6994631', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', >> 'Content-Type': 'application/problem+json', 'Replay-Nonce': >> 'YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}. Content: >> '{\n "type": "urn:acme:error:malformed",\n "detail": "DNS >> name does not have enough labels",\n "status": 400\n}' >> 2016-12-06 20:57:44,730:DEBUG:acme.client:Storing nonce: >> "b\x84\x8d\xa4\xb4\xf5D\x94\x8d\xe6\xd5\x15\x11k\xa3\xaf\x18\xd9\xe0\xbchS\xe8\xca\x9d\xcb'\xd5\xa3}\x1cR" >> 2016-12-06 20:57:44,730:DEBUG:acme.client:Received response >> (headers: {'Content-Length': '109', >> 'Boulder-Request-Id': >> 'z34CxBq8_BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': >> 'Tue, 06 Dec 2016 20:57:46 GMT', 'Server': 'nginx', >> 'Connection': 'close', 'Cache-Control': 'max-age=0, no-cache, >> no-store', 'Pragma': 'no-cache', 'Boulder-Requester': >> '6994631', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', >> 'Content-Type': 'application/problem+json', 'Replay-Nonce': >> 'YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}): '{\n >> "type": "urn:acme:error:malformed",\n "detail": "DNS name >> does not have enough labels",\n "status": 400\n}' >> 2016-12-06 20:57:44,735:DEBUG:certbot.main:Exiting abnormally: >> Traceback (most recent call last): >> File "/usr/bin/letsencrypt", line 9, in >> load_entry_point('certbot==0.9.3', 'console_scripts', >> 'certbot')() >> File "/usr/lib/python2.7/site-packages/certbot/main.py", >> line 776, in main >> return config.func(config, plugins) >> File "/usr/lib/python2.7/site-packages/certbot/main.py", >> line 566, in obtain_cert >> _csr_obtain_cert(config, le_client) >> File "/usr/lib/python2.7/site-packages/certbot/main.py", >> line 535, in _csr_obtain_cert >> certr, chain = >> le_client.obtain_certificate_from_csr(config.domains, csr, typ) >> File "/usr/lib/python2.7/site-packages/certbot/client.py", >> line 229, in obtain_certificate_from_csr >> authzr = self.auth_handler.get_authorizations(domains) >> File >> "/usr/lib/python2.7/site-packages/certbot/auth_handler.py", >> line 68, in get_authorizations >> domain, self.account.regr.new_authzr_uri) >> File "/usr/lib/python2.7/site-packages/acme/client.py", >> line 210, in request_domain_challenges >> typ=messages.IDENTIFIER_FQDN, value=domain), new_authzr_uri) >> File "/usr/lib/python2.7/site-packages/acme/client.py", >> line 190, in request_challenges >> new_authz) >> File "/usr/lib/python2.7/site-packages/acme/client.py", >> line 649, in post >> return self._check_response(response, >> content_type=content_type) >> File "/usr/lib/python2.7/site-packages/acme/client.py", >> line 565, in _check_response >> raise messages.Error.from_json(jobj) >> Error: urn:acme:error:malformed :: The request message was >> malformed :: DNS name does not have enough labels >> >> >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 12140 bytes Desc: not available URL: From pspacek at redhat.com Wed Dec 7 16:21:16 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 7 Dec 2016 17:21:16 +0100 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> Message-ID: On 7.12.2016 14:57, Brian Candler wrote: > On 07/12/2016 08:58, freeIPA users list wrote: >> On ke, 07 joulu 2016, List dedicated to discussions about use, configuration >> and deployment of the IPA server. wrote: >>> I know the Quick Start Guide and Deployment Recommendations cover this in >>> depth, but there are still some ambiguities. >>> >>> I'm trying to figure out if a company like us, lautus.net should use a DNS >>> subdomain like ipa.lautus.net for the IPA domain, or not. >> It is really depending on your deployment details. >> >> If you already have some other Kerberized environment in place and you >> are not going to replace it by FreeIPA, then you need to make sure that >> new FreeIPA deployment would not conflict with the existing one. > Or if you think there's a chance you might want to add another Kerberized > environment later (e.g. "ad.lautus.net") > >> >>> should continue to be hosted by DNS servers elsewhere that delegate say, >>> ipa.lautus.net to FreeIPA. > The question of whether you host ipa.lautus.net DNS (or indeed lautus.net DNS) > in FreeIPA is a different issue. > > If you're happy with your existing DNS infrastructure, then you can either > delegate ipa.lautus.net to your FreeIPA servers (with NS records); or run > FreeIPA without DNS, and simply import the ipa.lautus.net SRV records directly > into the lautus.net domain. > > Having FreeIPA host the ipa.lautus.net domain means these SRV records are > populated automatically, but it's not really that hard to add them to an > existing DNS service. > > OTOH, if you *don't* already have a good authoritative internal DNS service > with a UI that you like, then you might want to use FreeIPA for this anyway. > You can easily create extra zones in FreeIPA. > > I would be a bit wary about putting FreeIPA servers out on the public Internet > though. For one thing, the default config is an open resolver (which you can > tighten easily enough). I also have a deep distrust of Java, but maybe that's > just me. Speaking of DNS, it is just BIND. Configure it accordingly and you should be find. Please note that FreeIPA DNS is not intended as general-purpose DNS: http://www.freeipa.org/page/DNS#Initial_Considerations It is tailored for FreeIPA use-cases and might lack special features. >>> But on the other hand the same doc is full of examples where a Kerberos >>> realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example >>> 2.2. of secion 2.3.4. But the same guide also says that the Kerberos realm >>> should be the same as the ipa DNS domain, just uppercased. So example 2.2. >>> implies that example.com is running their DNS domain on FreeIPA, for >>> everything, not just for IPA SRV and TXT entries. > The Kerberos realm always has a corresponding DNS domain, so realm > IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net". > > But with FreeIPA you can still manage hosts called foo.lautus.net or > bar.int.lautus.net. At worst you'd have some extra [domain_realm] mappings in > krb5.conf Yes. Ideally you will be able to add _kerberos TXT records to relevant DNS domains so explicit mapping will not be necessary. I will have a look how we can clarify the guide to make this less confusing... > > (Aside: Active Directory is much more fussy, and basically doesn't work if the > hosts don't have hostnames within the same DNS domain as their kerberos realm > - and indeed have reverse DNS as well as forward) > >> >>> And when ipa-client-install is run on somehost.lautus.net, it also defaults >>> to LAUTUS.NET for Kerberos domain, as if the default expectation is that >>> your toplevel company DNS name would be your kerberos domain. > But you can override that. > >> >> >>> And when I install a trial IPA server on host ipa-server-1.lautus.net using >>> "ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain >>> ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones in the >>> Web UI, I see not only ipa.lautus.net, but also lautus, with record "@ NS >>> ipa-server-1.lautus.net". In other words the IPA server defaults to >>> thinking it owns the domain above ipa.lautus.net too. Which goes against >>> 2.3.1 above. > Interesting. What does "ipa dnszone-find --pkey-only" show? > > It seems like it's created an authoritative zone both for the server's own > domain (lautus.net if the server is xxx.lautus.net) as well as the realm's > domain (ipa.lautus.net) > > I don't know why it's doing that. Now I've checked with another system here: > the hostname is "ipa-1.int.example.com" and the realm is "ipa.example.com", > and you're right, it is authoritative for both: > > Zone name: int.example.com. > Zone name: ipa.example.com. > > This isn't what I wanted. The int.example.com domain is hosted externally and > I didn't want to override it. Right now it's hiding all names in > int.example.com that it doesn't know about. > > I would expect that it's possible to remove this zone, but I'd need to test > that doesn't stop other hosts called xxx.int.example.com from joining. Removing the zone should work just fine in IPA 4.4 and newer. In older versions you can delete the zone but it might get re-created when one of installers is re-run. (Then feel free to delete it again :-) IPA 4.4 will detect that the zone already exists somewhere else and do not create it. >> Yes and no. What you see with "@ NS ..." is a glue record -- you are >> supposed to have a glue record for IPA domain in the upstream domain, >> this is how domain delegation works in DNS world. > Aside: technically that's not a glue record. A glue record is an A or AAAA > record when the NS record points to a host within the subdomain which is being > delegated. It is to solve the chicken-and-egg situation of how to contact a > nameserver for a domain before you've contacted a nameserver for the domain. > > In your case, if you already have working DNS for lautus.net, then you don't > want FreeIPA to be authoritative for lautus.net as well. Right. Decide who should be authoritative and amend configuration accordingly. -- Petr^2 Spacek From jjflynn22 at gmail.com Wed Dec 7 16:26:08 2016 From: jjflynn22 at gmail.com (Joseph Flynn) Date: Wed, 7 Dec 2016 11:26:08 -0500 Subject: [Freeipa-users] Let's Encrypt Install: Made a bit of install progress, next error In-Reply-To: <9c6d8980-6835-0388-71de-40c695f46ba1@redhat.com> References: <99caef02-1c86-92e3-bdb4-a5206d80b9f8@redhat.com> <9c6d8980-6835-0388-71de-40c695f46ba1@redhat.com> Message-ID: Man, I feel silly. I thought i had that set earlier by using the network setup during the install. Maybe different distributions handle that differently. I have it corrected via your suggestion Martin Thanks you!! To the next stage... Seems like partial success. Is there another step needed to install the cert that appears to have been created in my home directory? [image: Inline image 1] IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /home/jjflynn22/0001_chain.pem. Your cert will expire on 2017-03-07. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le certutil: unable to open "/root/ipa-le/0000_cert.pem" for reading (-5950, 2). On Wed, Dec 7, 2016 at 10:56 AM, Martin Basti wrote: > Please make sure you use `hostnamectl set-hostname FQDN` to set all > hostnames on system (static, tentaive, current ....) > Martin > > On 07.12.2016 16:52, Joseph Flynn wrote: > > Damn, I thought I already fixed that but didn't. Hold while I rerun... > I bet that was it. > > On Wed, Dec 7, 2016 at 10:50 AM, Martin Basti wrote: > >> What does `hostname` command return? >> >> On 07.12.2016 16:37, Joseph Flynn wrote: >> >> Sorry, I wasn't clear in my earlier subject line. This is related to the >> Lets Encrypt installation. >> >> I tried to pull some more relevant items from the log below. I don't >> actually see all of the elements of my FQDN (ipa-a.kkgpitt.org) only >> references to the host (ipa-a) in the log, but am not sure what a good log >> should include. >> >> Thanks for any assistance, >> Joe >> >> >> On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn wrote: >> >>> Volunteers, >>> >>> I moved over to a Fedora VM which was way more difficult than it should >>> be. All kinds of problems with Guest Additions and I ended up having to >>> run server mode with no GUI. Now I run an Ubuntu VM from which I ssh into >>> my Fedora VM. Anyway... >>> >>> The install made it a further step than before. I get a quick blue >>> screen pop up at the end then an error saying: >>> [image: Inline image 1] >>> >>> An unexpected error occurred: >>>> The request message was malformed :: DNS name does not have enough >>>> labels >>>> Please see the logfiles in /var/log/letsencrypt for more details. >>>> >>> >>> When I run the cert checker util I get this >>> https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org >>> >>> Full log below. >>> >>> Any suggestions? Is it not pulling my proper hostname? >>> >>> Thanks, >>> Joe >>> >>> >>> >>> >>> >>> [jjflynn22 at ipa-a ~]$ cat /etc/hosts >>> 192.168.1.211 ipa-a.kkgpitt.org ipa-a >>> 127.0.0.1 localhost localhost.localdomain localhost4 >>> localhost4.localdomain4 >>> ::1 localhost localhost.localdomain localhost6 >>> localhost6.localdomain6 >>> >>> >>> >>> >>> [jjflynn22 at ipa-a ~]$ sudo cat /var/log/letsencrypt/letsencrypt.log >>> [sudo] password for jjflynn22: >>> 2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level set at 20 >>> 2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to >>> /var/log/letsencrypt/letsencrypt.log >>> 2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3 >>> 2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments: ['--standalone', >>> '--csr', '/root/ipa-le/httpd-csr.der', '--email', 'xxxxx at gmail.com', >>> '--agree-tos'] >>> 2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered plugins: >>> PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#nu >>> ll,PluginEntryPoint#manual,PluginEntryPoint#standalone) >>> 2016-12-06 20:57:43,995:DEBUG:certbot.plugins.selection:Requested >>> authenticator standalone and installer None >>> 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Single >>> candidate plugin: * standalone >>> Description: Spin up a temporary webserver >>> Interfaces: IAuthenticator, IPlugin >>> Entry point: standalone = certbot.plugins.standalone:Authenticator >>> Initialized: >> 0x7fc3dc6fccd0> >>> Prep: True >>> 2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Selected >>> authenticator >> 0x7fc3dc6fccd0> and installer None >>> 2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account: >>> >>> 2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to >>> https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {} >>> 2016-12-06 20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting >>> new HTTPS connection (1): acme-v01.api.letsencrypt.org >>> 2016-12-06 20:57:44,500:DEBUG:requests.packages.urllib3.connectionpool:"GET >>> /directory HTTP/1.1" 200 280 >>> 2016-12-06 20:57:44,506:DEBUG:root:Received . Headers: >>> {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 20:57:46 GMT', >>> 'Boulder-Request-Id': 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', >>> 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', >>> 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': >>> 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', >>> 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', >>> 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}. >>> Content: '{\n "new-authz": "https://acme-v01.api.letsencr >>> ypt.org/acme/new-authz",\n "new-cert": "https://acme-v01.api.letsencr >>> ypt.org/acme/new-cert",\n "new-reg": "https://acme-v01.api.letsencr >>> ypt.org/acme/new-reg",\n "revoke-cert": "https://acme-v01.api.letsencr >>> ypt.org/acme/revoke-cert"\n}' >>> 2016-12-06 20:57:44,506:DEBUG:acme.client:Received response >> [200]> (headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016 >>> 20:57:46 GMT', 'Boulder-Request-Id': 'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0', >>> 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', >>> 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': >>> 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', >>> 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', >>> 'Replay-Nonce': 'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}): '{\n >>> "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n >>> "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n >>> "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n >>> "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert >>> "\n}' >>> 2016-12-06 20:57:44,506:DEBUG:certbot.client:CSR: >>> CSR(file='/root/ipa-le/httpd-csr.der', data='0\x82\x02x0\x82\x01`\x02 >>> \x01\x000\x101\x0e0\x0c\x06\x03U\x04\x03\x13\x05ipa-a0\x82\ >>> x01"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\ >>> x01\x0f\x000\x82\x01\n\x02\x82\x01\x01\x00\xdau1L\xa6T\xc8\x93\xc0P\x93\xb3\xd2\xcb >>> \xe2PU\xf0\x94=\x1c\n\x1e\xe5\xfe\xed<\xfa\xb1d-\x92\xebeD\x >>> b1\x0eq9\xf1\xfa\xb5p\xdc\x12qN\x96\x0b\x1f\x13\xab\xae >>> >>> ....... >>> >>> 99\xc0\xb0\x07N\xdd5\x9e1\xb8\xdc\x8c\xc1N\xc1\x04\xa1\xd0\x >>> fc\xc2$f\x84e\xd4\xf7i\x1a\x1c~,\x80\xea/~j\xea\xa2\xf3\xe9\ >>> x96\xfe5j\xa4\xb4X\x12L\xd5\xe5\xb0\x99|\xb8\xd1\xed\xa3\xf2 >>> \xd5\xf0\x94\xc3"\xe8\x9dT\x17\xcf\x12$oVE\x83\xd1\x96\xac\ >>> xa1\xf9F\xd2mO\xe9$\xa7\x00_\xaa\xc6\xa3j\xa1\xbaX8\xa43K\ >>> x18os\xe1\xf4L(\xf9\xac\'\xc5\x9a\xdc\xf5s\xc6`\x97\xe6\xea\ >>> xf8\xcc\xfa\xe1U_\xff\x86\xf0\x82\xab\xaf\xb9\x92q\x06\x0f\ >>> xa5}]\x9c\xb1\x84b\x85<\xed\x92,g\x0e\xeaoAi|\xc5\n\x92', form='der'), >>> domains: [u'ipa-a'] >>> 2016-12-06 20:57:44,507:DEBUG:root:Requesting fresh nonce >>> 2016-12-06 20:57:44,507:DEBUG:root:Sending HEAD request to >>> https://acme-v01.api.letsencrypt.org/acme/new-authz. args: (), kwargs: >>> {} >>> 2016-12-06 20:57:44,608:DEBUG:requests.packages.urllib3.connectionpool:"HEAD >>> /acme/new-authz HTTP/1.1" 405 0 >>> 2016-12-06 20:57:44,609:DEBUG:root:Received . Headers: >>> {'Content-Length': '91', 'Pragma': 'no-cache', 'Boulder-Request-Id': >>> 'c2cMPhHqlO5kTv8xJ5dfIs4NCD2KMqn8X-IxPzutDAI', 'Expires': 'Tue, 06 Dec >>> 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'keep-alive', 'Allow': >>> 'POST', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 >>> Dec 2016 20:57:46 GMT', 'Content-Type': 'application/problem+json', >>> 'Replay-Nonce': '3fq9edUYLFJwQKDU-oaLVpQdUglFemQpGNbwZ-AtmfI'}. >>> Content: '' >>> 2016-12-06 20:57:44,609:DEBUG:acme.client:Storing nonce: >>> '\xdd\xfa\xbdy\xd5\x18,Rp@\xa0\xd4\xfa\x86\x8bV\x94\x1dR\tEz >>> d)\x18\xd6\xf0g\xe0-\x99\xf2' >>> 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted empty fields: >>> combinations=None, challenges=None, expires=None, status=None >>> 2016-12-06 20:57:44,610:DEBUG:acme.client:Serialized JSON: >>> {"identifier": {"type": "dns", "value": "ipa-a"}, "resource": >>> "new-authz"} >>> 2016-12-06 20:57:44,610:DEBUG:acme.jose.json_util:Omitted empty fields: >>> kid=None, x5c=(), crit=(), jwk=None, typ=None, jku=None, cty=None, >>> x5tS256=None, x5u=None, alg=None, x5t=None >>> 2016-12-06 20:57:44,612:DEBUG:acme.jose.json_util:Omitted empty fields: >>> kid=None, x5c=(), crit=(), typ=None, jku=None, cty=None, x5tS256=None, >>> x5u=None, x5t=None, nonce=None >>> 2016-12-06 20:57:44,612:DEBUG:root:Sending POST request to >>> https://acme-v01.api.letsencrypt.org/acme/new-authz. args: (), kwargs: >>> {'data': '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", >>> "n": "vmM8XoN-WDCdPcaMNxu9zlLEJBBN-W_pIkG-Afw5uawBBXWHbWyzUeb06Ly >>> pMM94LcTi0drWTf00Fdv5SiVKMAwwAoqH-Xzv5LHBwYmqNFGr-W6cphQjNTP >>> 21IP87NKxG87OdvvOMjE--oMuJJMYWbyAAcOZNhIobWp969EMGu9Oi5JeQI1 >>> bLqIHS317xWDPD_EMTmhnVxZGBuS5gs_ObYejnJmGyu4_Bn1yLIDlBuphYsH >>> g0pWoAgjZQAr3NI4N7oVrB-LiW21-k9I-LH3dijxVLBe_7jfKsIsVTJyzMzl >>> -g2iAeogYHfRngkhnQVXfhSleeZbfHwKXPs5FdmnHBw"}}, "protected": >>> "eyJub25jZSI6ICIzZnE5ZWRVWUxGSndRS0RVLW9hTFZwUWRVZ2xGZW1RcEdOYndaLUF0bWZJIn0", >>> "payload": "eyJpZGVudGlmaWVyIjogeyJ0eXBlIjogImRucyIsICJ2YWx1ZSI6ICJpcGE >>> tYSJ9LCAicmVzb3VyY2UiOiAibmV3LWF1dGh6In0", "signature": >>> "sDGSJkUMIFVRr7YGU33exEVslJFZlZoTuyv74F_XtloybjzZFg81r8ONbCU >>> XtU6Q1COsA1M9df_vpL1b8Pz2bhfgEkG7taiaHDEyK-PGx5cn9U4vgSp3uZM >>> NfVGFK-0gSYxLIsI0AgEIV8rTVKVw5kHVhn8Ob7gCuBgz1QkGr8WefqAcJ6v >>> xycvbPBXh3GlpHylKDNTEsH5kbdKtfg5bKJu8RDLFBhAZCFub61EwkeT7Hfv >>> hsWkaXJQhoolWiFn_3PjAZCEZzPL5igCOW0V65OEp6O3wdnC4FwS0BwxE0Cx >>> B2QA2mXMdvX4SILRf5mhzhTOmdTL0gLYXffI1XErbvg"}'} >>> 2016-12-06 20:57:44,728:DEBUG:requests.packages.urllib3.connectionpool:"POST >>> /acme/new-authz HTTP/1.1" 400 109 >>> 2016-12-06 20:57:44,730:DEBUG:root:Received . Headers: >>> {'Content-Length': '109', 'Boulder-Request-Id': >>> 'z34CxBq8_BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': 'Tue, 06 Dec >>> 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'close', >>> 'Cache-Control': 'max-age=0, no-cache, no-store', 'Pragma': 'no-cache', >>> 'Boulder-Requester': '6994631', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', >>> 'Content-Type': 'application/problem+json', 'Replay-Nonce': >>> 'YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}. Content: '{\n "type": >>> "urn:acme:error:malformed",\n "detail": "DNS name does not have enough >>> labels",\n "status": 400\n}' >>> 2016-12-06 20:57:44,730:DEBUG:acme.client:Storing nonce: >>> "b\x84\x8d\xa4\xb4\xf5D\x94\x8d\xe6\xd5\x15\x11k\xa3\xaf\x18 >>> \xd9\xe0\xbchS\xe8\xca\x9d\xcb'\xd5\xa3}\x1cR" >>> 2016-12-06 20:57:44,730:DEBUG:acme.client:Received response >> [400]> (headers: {'Content-Length': '109', 'Boulder-Request-Id': >>> 'z34CxBq8_BBQbE6zM00YjU8c08FeXh24WHyCG1xAYJE', 'Expires': 'Tue, 06 Dec >>> 2016 20:57:46 GMT', 'Server': 'nginx', 'Connection': 'close', >>> 'Cache-Control': 'max-age=0, no-cache, no-store', 'Pragma': 'no-cache', >>> 'Boulder-Requester': '6994631', 'Date': 'Tue, 06 Dec 2016 20:57:46 GMT', >>> 'Content-Type': 'application/problem+json', 'Replay-Nonce': >>> 'YoSNpLT1RJSN5tUVEWujrxjZ4LxoU-jKncsn1aN9HFI'}): '{\n "type": >>> "urn:acme:error:malformed",\n "detail": "DNS name does not have enough >>> labels",\n "status": 400\n}' >>> 2016-12-06 20:57:44,735:DEBUG:certbot.main:Exiting abnormally: >>> Traceback (most recent call last): >>> File "/usr/bin/letsencrypt", line 9, in >>> load_entry_point('certbot==0.9.3', 'console_scripts', 'certbot')() >>> File "/usr/lib/python2.7/site-packages/certbot/main.py", line 776, in >>> main >>> return config.func(config, plugins) >>> File "/usr/lib/python2.7/site-packages/certbot/main.py", line 566, in >>> obtain_cert >>> _csr_obtain_cert(config, le_client) >>> File "/usr/lib/python2.7/site-packages/certbot/main.py", line 535, in >>> _csr_obtain_cert >>> certr, chain = le_client.obtain_certificate_from_csr(config.domains, >>> csr, typ) >>> File "/usr/lib/python2.7/site-packages/certbot/client.py", line 229, >>> in obtain_certificate_from_csr >>> authzr = self.auth_handler.get_authorizations(domains) >>> File "/usr/lib/python2.7/site-packages/certbot/auth_handler.py", line >>> 68, in get_authorizations >>> domain, self.account.regr.new_authzr_uri) >>> File "/usr/lib/python2.7/site-packages/acme/client.py", line 210, in >>> request_domain_challenges >>> typ=messages.IDENTIFIER_FQDN, value=domain), new_authzr_uri) >>> File "/usr/lib/python2.7/site-packages/acme/client.py", line 190, in >>> request_challenges >>> new_authz) >>> File "/usr/lib/python2.7/site-packages/acme/client.py", line 649, in >>> post >>> return self._check_response(response, content_type=content_type) >>> File "/usr/lib/python2.7/site-packages/acme/client.py", line 565, in >>> _check_response >>> raise messages.Error.from_json(jobj) >>> Error: urn:acme:error:malformed :: The request message was malformed :: >>> DNS name does not have enough labels >>> >>> >>> >>> >>> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 12140 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 28624 bytes Desc: not available URL: From dag at sonsorol.org Wed Dec 7 16:34:12 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 07 Dec 2016 11:34:12 -0500 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <5846F92E.3010900@sonsorol.org> <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58471CDD.8070703@sonsorol.org> <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <58483A04.20000@sonsorol.org> Our problem is largely solved but we are using some "do not use in production!" settings so I wanted to both recap our solution and ask some follow up questions. Our setup: ------------- - FreeIPA 4.2 running on CentOS-7 in AWS VPC - Edge-case split DNS setup. Our cloud clients are "company-aws.org" while IPA is "company-ipa.org" realm/domain - Massive need to authenticate against AD Forest COMPANY.COM which includes a ton of child domains (NAFTA.COMPANY.COM, etc.) Problem ----------- - AD users are recognized and can be enumerated as long as I use username at NAFTA.COMPANY.COM - "su - " works as root to become the AD user - All methods that require password check (SSH login mainly) failed The breakthrough was the advice from Sumit to add the ldap_user_principal and subdomain_inherit settings. The core problem on our end seemed to be issues with having the AD user UPN get sorted out. Something was failing when user at NAFTA.COMPANY.COM was shortened to user at COMPANY.COM and we saw the recurring error about " ... UPN is quite different ... " in the sssd domain logs. Solution (Server Side) ----------------------------- In /etc/sssd/sssd.conf: ldap_user_principal = nosuchattr subdomain_inherit = ldap_user_principal krb5_validate = false Solution (IPA client side) -------------------------------- In /etc/sssd/sssd.conf: krb5_validate = false I think the main problem is obvious. Even Sumit was clear to state that "krb5_validate = false" should be used for testing only. However if we remove that setting password checking breaks. So the basic "what next question" for the experts is: 1. Do we chase down whatever config error we have that requires krb5_validate=false ? 2. Or do we assume that that problem is related to the UPN problem and related AD-across-child-domains that appear to be resolved in IPA-4.4? I keep getting the sense that massive AD-related things have been improved recently in 4.3 and 4.4 My gut feeling is that it is our odd UPN issue that is breaking things so rather than bend over backwards to try to figure out why krb5_validate=false on our IPA-4.2 setup I'm sort of leaning towards trying to go for an upgrade to IPA-4.4 and hope that whatever issue forced us to disable krb5_validate is resolved in the new updates. Am I being stupid (again?) Obviously the krb5_validate=false setting needs to be fixed. Just not sure if I should work on a fix within 4.2 or move to 4.4 and see if it gets resolved as part of other changes. Regards, Chris From jochen at jochen.org Wed Dec 7 16:54:53 2016 From: jochen at jochen.org (Jochen Hein) Date: Wed, 07 Dec 2016 17:54:53 +0100 Subject: [Freeipa-users] Certificates missing (was: Re: Services missing in web-ui) In-Reply-To: (Pavel Vomacka's message of "Wed, 7 Dec 2016 11:58:55 +0100") References: <1142144358.1147148.1481105613460.JavaMail.zimbra@casalogic.dk> Message-ID: <83inqv3ciq.fsf_-_@echidna.jochen.org> I'm unsure if it is related to ticket 6397... Pavel Vomacka writes: > it is caused by missing canonical name on services which were created > in older versions of FreeIPA. Fixed ticket here: > https://fedorahosted.org/freeipa/ticket/6397 . Symptom: In the web UI on 4.3 on Fedora 24 I have 43 certificates, on the 4.4 replica on CentOS 7.3(CR) I see only 16 certificates. System history: Old master is 4.3, upgraded from 4.2. Both replicas are new with CentOS. Yesterday I moved the CA from 4.3 to a 4.4 IDM. After that I created a certificate for a new service principal. I can see the new certificate I can see in both web UIs. Analysis: Looking at the ipa cli tool, cert-find is consistent with the web UI: 4.3: ----------------------------- Number of entries returned 43 ----------------------------- 4.4: -------------------------------------- Anzahl der zur?ckgegebenen Eintr?ge 16 -------------------------------------- Looking at both LDAP servers, I do find the same number of entries. I looked at ou=ca,ou=requests,o=ipaca. So replications seems to work fine (and ipa-replica-manage confirms it). Right now I have two guesses: My system is hit with https://fedorahosted.org/freeipa/ticket/6397 I do have some certificates for services, and some for hosts. So my hope would be that updated packages might fix it. But analysing the certificates in the web UI is futil: - On CentOS(freeipa 4.4) the certificate list in web UI only displays serial number, subject, issuing CA(empty), and status(empty). That's not quite correct. In the certificate list I can not select a certificate and can get more details... 4.3 has only serial number, subject, and status, but with valid values. I can click on the serial number and get more details about the certficate. Since I can't see all services in 4.4 due to ticket 6397 more analysis is hard. - using "ipa cert-show --all" on 4.4 has more infos about the certificates, but on 4.3 it doesn't show more info. So right now I'm somewhat stuck how to proceed further. 4.3 seems to be ok, so I hesitate to update the fredora system to 25 (with IPA 4.4). I didn't find the files from #6397 to manually apply the patch, so I'm more or less stuck. Any ideas? Jochen -- The only problem with troubleshooting is that the trouble shoots back. From jochen at jochen.org Wed Dec 7 17:51:27 2016 From: jochen at jochen.org (Jochen Hein) Date: Wed, 07 Dec 2016 18:51:27 +0100 Subject: [Freeipa-users] Certificates missing In-Reply-To: <83inqv3ciq.fsf_-_@echidna.jochen.org> (Jochen Hein's message of "Wed, 07 Dec 2016 17:54:53 +0100") References: <1142144358.1147148.1481105613460.JavaMail.zimbra@casalogic.dk> <83inqv3ciq.fsf_-_@echidna.jochen.org> Message-ID: <83eg1j39wg.fsf@echidna.jochen.org> Jochen Hein writes: > I'm unsure if it is related to ticket 6397... It seems it was. CentOS 7.3/CR had new packages today and both problems are fixed for me. Thanks! Jochen -- The only problem with troubleshooting is that the trouble shoots back. From jamesaharrisonuk at yahoo.co.uk Wed Dec 7 18:19:06 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Wed, 7 Dec 2016 18:19:06 +0000 (UTC) Subject: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account References: <206623988.2535008.1481134746445.ref@mail.yahoo.com> Message-ID: <206623988.2535008.1481134746445@mail.yahoo.com> Hi all, I am trying to authenticate an ubuntu Precise (12.06) fully patched system. Its enrolled into a FreeIPA server. The following trace is the output of syslog auth sssd/*.log and full debug (-ddd) from the sshd service. I am getting a PAM error at the end of the procedure. Also I cant seem to authenticate against the public ssh key from the id override user. I appreciate any help you can send my way. Best regards, James Harrison Below is more information root at jamesprecise:~# kinit x_james.harrison at AD.DOMAIN.LOCAL Password for x_james.harrison at AD.DOMAIN.LOCAL: root at jamesprecise:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: x_james.harrison at AD.DOMAIN.LOCAL Valid starting???? Expires??????????? Service principal 07/12/16 17:56:30? 08/12/16 03:56:30? krbtgt/AD.DOMAIN.LOCAL at AD.DOMAIN.LOCAL ??? renew until 08/12/16 17:56:23 root at jamesprecise:~# id x_james.harrison at AD.DOMAIN.LOCAL uid=1039812876(x_james.harrison at ad.domain.local) gid=1039812876(x_james.harrison at ad.domain.local) groups=1039812876(x_james.harrison at ad.domain.local) root at pul-lv-ipa-02 ~]# ipa? idoverrideuser-show External_AD_views x_james.harrison at ad.domain.local ? Anchor to override: x_james.harrison at ad.domain.local ? User login: x_james.harrison ? Login shell: /bin/bash ? SSH public key: ssh-rsa ????????????????? AAAAB3NzaC1yc2EAAAADAQABAAABAQDK1pj2U7H9olLs1xKmcmZVEBMWpaHjxF2LttsdfqfQxm810qMru/WsvzHqu0m5Ugu0FYsPxRLQrAEB8WPsPoh5Y0q5qYPgm5aDOZZEXfCPyuRwdQ+XLfQJ3gnGjW4r/XLEiNVpO9eKsFs0ifspNAJ1ndddddddddddddddd7h40rlHlOIqV/z8Omg6XnFBh9dIfiXtpYDOxe+512RpjtHE98s+NfIpUTT7MGNLHB5o/DqFXEJPH7Pp1bKwxWNvfCb5a71vcE695dQ31QYVYwpSwFmFogewgpV/OCb+S4SUdUq1xg0fmkhYr3d4UXFr91MDimyOBWk9Aai7NkOHPszmHJp ????????????????? JamesHarrison Here are the software versions: root at jamesprecise:# dpkg -l | grep -i freeipa ii? freeipa-client???????????????????????????? 3.3.4-0ubuntu3.1~precise0.1??????? FreeIPA centralized identity framework -- client ii? libipa-hbac0?????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? FreeIPA HBAC Evaluator library ii? python-freeipa???????????????????????????? 3.3.4-0ubuntu3.1~precise0.1??????? FreeIPA centralized identity framework -- python modules ii? python-libipa-hbac???????????????????????? 1.11.5-1ubuntu3~precise1?????????? Python bindings for the FreeIPA HBAC Evaluator library root at jamesprecise:# dpkg -l | grep -i openssh-server ii? openssh-server???????????????????????????? 1:5.9p1-5ubuntu1.10??????????????? secure shell (SSH) server, for secure access from remote machines root at jamesprecise:/var/log# dpkg -l | grep -i sssd ii? libsss-idmap0????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? ID mapping library for SSSD ii? sssd?????????????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- metapackage ii? sssd-ad??????????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- Active Directory back end ii? sssd-ad-common???????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- PAC responder ii? sssd-common??????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- common files ii? sssd-ipa?????????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- IPA back end ii? sssd-krb5????????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- Kerberos back end ii? sssd-krb5-common?????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- Kerberos helpers ii? sssd-ldap????????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- LDAP back end ii? sssd-proxy???????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- proxy back end ii? sudo?????????????????????????????????????? 1.8.9p5-1ubuntu1.1~sssd1?????????? Provide limited super user privileges to specific users Ubuntu PPAs: root at jamesprecise:~# ls -l /etc/apt/sources.list.d/ total 16 -rw-r--r-- 1 root root 65 Dec? 7 08:48 freeipa-ppa-precise.list -rw-r--r-- 1 root root 61 Dec? 7 08:48 ppa_freeipa_ppa_precise.list -rw-r--r-- 1 root root 62 Dec? 7 08:48 ppa_sssd_updates_precise.list -rw-r--r-- 1 root root 66 Dec? 7 08:48 sssd-updates-precise.list cat /etc/pam.d/common-session session??? [default=1]??????????? pam_permit.so session??? requisite??????????? pam_deny.so session??? required??????????? pam_permit.so session optional??????????? pam_umask.so session??? required??????????????????????? pam_mkhomedir.so umask=0022 skel=/etc/skel session??? required??? pam_unix.so session??? optional??????????? pam_sss.so session??? [success=ok default=ignore]??? pam_ldap.so minimum_uid=1000 root at jamesprecise:~# root at jamesprecise:~# cat /etc/pam.d/common-auth auth??? [success=3 default=ignore]??? pam_unix.so nullok_secure auth??? [success=2 default=ignore]??? pam_sss.so use_first_pass auth??? [success=1 default=ignore]??? pam_ldap.so minimum_uid=1000 use_first_pass auth??? requisite??????????? pam_deny.so auth??? required??????????? pam_permit.so root at jamesprecise:~# cat /etc/pam.d/common-account account??? [success=1 new_authtok_reqd=done default=ignore]??? pam_unix.so account??? requisite??????????? pam_deny.so account??? required??????????? pam_permit.so account??? sufficient??????????? pam_localuser.so account??? [default=bad success=ok user_unknown=ignore]??? pam_sss.so account??? [success=ok new_authtok_reqd=done ignore=ignore user_unknown=ignore authinfo_unavail=ignore default=bad]??? pam_ldap.so minimum_uid=1000 root at jamesprecise:~# cat /etc/krb5.conf #File modified by ipa-client-install includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] ? default_realm = FREEIPA-REALM ? dns_lookup_realm = true ? dns_lookup_kdc = true ? rdns = false ? ticket_lifetime = 24h ? forwardable = yes #? ignore_acceptor_hostname = true [realms] ? FREEIPA-REALM = { ??? pkinit_anchors = FILE:/etc/ipa/ca.crt ? } [domain_realm] ? .freeipa.domain.com = FREEIPA-REALM ? freeipa.domain.com = FREEIPA-REALM root at jamesprecise:~# cat /etc/sssd/sssd.conf [domain/freeipa.domain.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = freeipa.domain.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = jamesprecise.freeipa.domain.com chpass_provider = ipa ipa_server = tx-lv-ipa-02.freeipa.domain.com ldap_tls_cacert = /etc/ipa/ca.crt debug_level = 5 [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = freeipa.domain.com [nss] [pam] [sudo] [autofs] [ssh] [pac] Below if the trace output as appeared on my screen: root at jamesprecise:/var/log# /usr/sbin/sshd -ddd debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 773 debug2: parse_server_config: config /etc/ssh/sshd_config len 773 debug3: /etc/ssh/sshd_config:5 setting Port 2230 debug3: /etc/ssh/sshd_config:9 setting Protocol 2 debug3: /etc/ssh/sshd_config:11 setting HostKey /etc/ssh/ssh_host_rsa_key debug3: /etc/ssh/sshd_config:12 setting HostKey /etc/ssh/ssh_host_dsa_key debug3: /etc/ssh/sshd_config:13 setting HostKey /etc/ssh/ssh_host_ecdsa_key debug3: /etc/ssh/sshd_config:16 setting UsePrivilegeSeparation yes debug3: /etc/ssh/sshd_config:19 setting KeyRegenerationInterval 3600 debug3: /etc/ssh/sshd_config:20 setting ServerKeyBits 1024 debug3: /etc/ssh/sshd_config:23 setting SyslogFacility AUTH debug3: /etc/ssh/sshd_config:24 setting LogLevel VERBOSE debug3: /etc/ssh/sshd_config:27 setting LoginGraceTime 120 debug3: /etc/ssh/sshd_config:28 setting PermitRootLogin without-password debug3: /etc/ssh/sshd_config:29 setting StrictModes yes debug3: /etc/ssh/sshd_config:31 setting RSAAuthentication yes debug3: /etc/ssh/sshd_config:32 setting AuthorizedKeysFile %h/.ssh/authorized_keys debug3: /etc/ssh/sshd_config:35 setting IgnoreRhosts yes debug3: /etc/ssh/sshd_config:37 setting RhostsRSAAuthentication no debug3: /etc/ssh/sshd_config:39 setting HostbasedAuthentication no debug3: /etc/ssh/sshd_config:44 setting PermitEmptyPasswords no debug3: /etc/ssh/sshd_config:48 setting ChallengeResponseAuthentication no debug3: /etc/ssh/sshd_config:51 setting PasswordAuthentication no debug3: /etc/ssh/sshd_config:63 setting X11Forwarding no debug3: /etc/ssh/sshd_config:64 setting X11DisplayOffset 10 debug3: /etc/ssh/sshd_config:65 setting PrintMotd no debug3: /etc/ssh/sshd_config:66 setting PrintLastLog yes debug3: /etc/ssh/sshd_config:67 setting TCPKeepAlive yes debug3: /etc/ssh/sshd_config:74 setting AcceptEnv LANG LC_* debug3: /etc/ssh/sshd_config:76 setting Subsystem sftp /usr/lib/openssh/sftp-server debug3: /etc/ssh/sshd_config:87 setting PubkeyAuthentication yes debug3: /etc/ssh/sshd_config:88 setting UsePAM yes debug1: sshd version OpenSSH_5.9p1 Debian-5ubuntu1.10 debug3: Incorrect RSA1 identifier debug1: read PEM private key done: type RSA debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: private host key: #0 type 1 RSA debug3: Incorrect RSA1 identifier debug1: read PEM private key done: type DSA debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 debug1: private host key: #1 type 2 DSA debug3: Incorrect RSA1 identifier debug1: read PEM private key done: type ECDSA debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-256 debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-256 debug1: private host key: #2 type 3 ECDSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddd' debug3: oom_adjust_setup Set /proc/self/oom_score_adj from 0 to -1000 debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 2230 on 0.0.0.0. Server listening on 0.0.0.0 port 2230. debug2: fd 4 setting O_NONBLOCK debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY debug1: Bind to port 2230 on ::. Server listening on :: port 2230. debug3: fd 5 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 773 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 ==> auth.log <== Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: recv_rexec_state: entering fd = 5 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: ssh_msg_recv entering Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: recv_rexec_state: done Dec? 7 17:31:47 jamesprecise sshd[1839]: debug2: parse_server_config: config rexec len 773 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:5 setting Port 2230 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:9 setting Protocol 2 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:11 setting HostKey /etc/ssh/ssh_host_rsa_key Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:12 setting HostKey /etc/ssh/ssh_host_dsa_key Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:13 setting HostKey /etc/ssh/ssh_host_ecdsa_key Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:16 setting UsePrivilegeSeparation yes Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:19 setting KeyRegenerationInterval 3600 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:20 setting ServerKeyBits 1024 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:23 setting SyslogFacility AUTH Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:24 setting LogLevel VERBOSE Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:27 setting LoginGraceTime 120 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:28 setting PermitRootLogin without-password Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:29 setting StrictModes yes Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:31 setting RSAAuthentication yes Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:32 setting AuthorizedKeysFile %h/.ssh/authorized_keys Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:35 setting IgnoreRhosts yes Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:37 setting RhostsRSAAuthentication no Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:39 setting HostbasedAuthentication no Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:44 setting PermitEmptyPasswords no Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:48 setting ChallengeResponseAuthentication no Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:51 setting PasswordAuthentication no Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:63 setting X11Forwarding no Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:64 setting X11DisplayOffset 10 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:65 setting PrintMotd no Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:66 setting PrintLastLog yes Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:67 setting TCPKeepAlive yes Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:74 setting AcceptEnv LANG LC_* Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:76 setting Subsystem sftp /usr/lib/openssh/sftp-server Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:87 setting PubkeyAuthentication yes Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: rexec:88 setting UsePAM yes Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: sshd version OpenSSH_5.9p1 Debian-5ubuntu1.10 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: Incorrect RSA1 identifier Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: read PEM private key done: type RSA Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: private host key: #0 type 1 RSA Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: Incorrect RSA1 identifier Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: read PEM private key done: type DSA Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: private host key: #1 type 2 DSA Dec? 7 17:31:47 jamesprecise sshd[1839]: debug3: Incorrect RSA1 identifier Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: read PEM private key done: type ECDSA Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-256 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-256 Dec? 7 17:31:47 jamesprecise sshd[1839]: debug1: private host key: #2 type 3 ECDSA debug1: inetd sockets after dupping: 3, 3 Connection from 10.10.10.10 port 45036 debug1: Client protocol version 2.0; client software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.10 debug2: fd 3 setting O_NONBLOCK debug2: Network child is on pid 1840 debug3: preauth child monitor started debug3: privsep user:group 105:65534 [preauth] debug1: permanently_set_uid: 105/65534 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [preauth] debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [preauth] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 [preauth] debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] debug2: kex_parse_kexinit:? [preauth] debug2: kex_parse_kexinit:? [preauth] debug2: kex_parse_kexinit: first_kex_follows 0? [preauth] debug2: kex_parse_kexinit: reserved 0? [preauth] debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c [preauth] debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa [preauth] debug2: kex_parse_kexinit: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc [preauth] debug2: kex_parse_kexinit: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc [preauth] debug2: kex_parse_kexinit: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: kex_parse_kexinit: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib [preauth] debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib [preauth] debug2: kex_parse_kexinit:? [preauth] debug2: kex_parse_kexinit:? [preauth] debug2: kex_parse_kexinit: first_kex_follows 0? [preauth] debug2: kex_parse_kexinit: reserved 0? [preauth] debug2: mac_setup: found umac-64 at openssh.com [preauth] debug1: kex: client->server aes128-ctr umac-64 at openssh.com none [preauth] debug2: mac_setup: found umac-64 at openssh.com [preauth] debug1: kex: server->client aes128-ctr umac-64 at openssh.com none [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] debug3: mm_key_sign entering [preauth] debug3: mm_request_send entering: type 5 [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 5 debug3: mm_answer_sign debug3: mm_answer_sign: signature 0x7fcb152fe1a0(100) debug3: mm_request_send entering: type 6 debug2: monitor_read: 5 used once, disabling now debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth] debug3: mm_request_receive_expect entering: type 6 [preauth] debug3: mm_request_receive entering [preauth] debug2: kex_derive_keys [preauth] debug2: set_newkeys: mode 1 [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] debug2: set_newkeys: mode 0 [preauth] debug1: SSH2_MSG_NEWKEYS received [preauth] debug1: KEX done [preauth] debug1: userauth-request for user a_aaaaaaa.aaaaa at xxxxxxx.xxxx service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug3: mm_getpwnamallow entering [preauth] debug3: mm_request_send entering: type 7 [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 7 debug3: mm_answer_pwnamallow debug3: Trying to reverse map address 10.10.10.10. debug2: parse_server_config: config reprocess config len 773 debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 8 debug2: monitor_read: 7 used once, disabling now debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth] debug3: mm_request_receive_expect entering: type 8 [preauth] debug3: mm_request_receive entering [preauth] debug2: input_userauth_request: setting up authctxt for a_aaaaaaa.aaaaa at xxxxxxx.xxxx [preauth] debug3: mm_start_pam entering [preauth] debug3: mm_request_send entering: type 50 [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 50 debug1: PAM: initializing for "a_aaaaaaa.aaaaa at xxxxxxx.xxxx" debug1: PAM: setting PAM_RHOST to "10.10.10.10" debug1: PAM: setting PAM_TTY to "ssh" debug2: monitor_read: 50 used once, disabling now debug3: mm_inform_authserv entering [preauth] debug3: mm_request_send entering: type 3 [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style=, role= debug2: monitor_read: 3 used once, disabling now debug2: input_userauth_request: try method none [preauth] debug1: userauth-request for user a_aaaaaaa.aaaaa at xxxxxxx.xxxx service ssh-connection method publickey [preauth] debug1: attempt 1 failures 0 [preauth] debug2: input_userauth_request: try method publickey [preauth] debug1: test whether pkalg/pkblob are acceptable [preauth] debug3: mm_key_allowed entering [preauth] debug3: mm_request_send entering: type 21 [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 21 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x7fcb15302ec0 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: temporarily_use_uid: 1039812876/1039812876 (e=0/0) ==> sssd/sssd_freeipa.domain.com.log <== (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=a_aaaaaaa.aaaaa] (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,Account info lookup failed debug1: trying public key file /home/xxxxxxx.xxxx/a_aaaaaaa.aaaaa/.ssh/authorized_keys debug1: fd 8 clearing O_NONBLOCK debug1: matching key found: file /home/xxxxxxx.xxxx/a_aaaaaaa.aaaaa/.ssh/authorized_keys, line 8 Found matching RSA key: a6:61:f3:d1:f6:87:4f:e2:27:49:88:f8:09:93:11:27 debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x7fcb15302ec0 is allowed debug3: mm_request_send entering: type 22 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] debug3: mm_request_receive_expect entering: type 22 [preauth] debug3: mm_request_receive entering [preauth] debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth] Postponed publickey for a_aaaaaaa.aaaaa at xxxxxxx.xxxx from 10.10.10.10 port 45036 ssh2 [preauth] debug1: userauth-request for user a_aaaaaaa.aaaaa at xxxxxxx.xxxx service ssh-connection method publickey [preauth] debug1: attempt 2 failures 0 [preauth] debug2: input_userauth_request: try method publickey [preauth] debug3: mm_key_allowed entering [preauth] debug3: mm_request_send entering: type 21 [preauth] debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] debug3: mm_request_receive_expect entering: type 22 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 21 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x7fcb153143e0 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: temporarily_use_uid: 1039812876/1039812876 (e=0/0) debug1: trying public key file /home/xxxxxxx.xxxx/a_aaaaaaa.aaaaa/.ssh/authorized_keys debug1: fd 8 clearing O_NONBLOCK debug1: matching key found: file /home/xxxxxxx.xxxx/a_aaaaaaa.aaaaa/.ssh/authorized_keys, line 8 Found matching RSA key: a6:61:f3:d1:f6:87:4f:e2:27:49:88:f8:09:93:11:27 debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x7fcb153143e0 is allowed debug3: mm_request_send entering: type 22 debug3: mm_key_verify entering [preauth] debug3: mm_request_send entering: type 23 [preauth] debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY [preauth] debug3: mm_request_receive_expect entering: type 24 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 23 debug1: ssh_rsa_verify: signature correct debug3: mm_answer_keyverify: key 0x7fcb153143e0 signature verified debug3: mm_request_send entering: type 24 debug3: mm_request_receive_expect entering: type 51 debug3: mm_request_receive entering debug1: do_pam_account: called (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [be_get_account_info] (0x0100): Got request for [3][1][name=a_aaaaaaa.aaaaa] (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,95,Account info lookup failed (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [be_pam_handler] (0x0100): Got request with the following data (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): domain: xxxxxxx.xxxx (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): user: a_aaaaaaa.aaaaa at xxxxxxx.xxxx (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): service: sshd (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): tty: ssh (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): ruser: (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): rhost: 10.10.10.10 (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): authtok type: 0 (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): newauthtok type: 0 (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): priv: 1 (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [pam_print_data] (0x0100): cli_pid: 1839 (Wed Dec? 7 17:31:47 2016) [sssd[be[freeipa.domain.com]]] [ipa_hostgroup_info_done] (0x0200): Dereferenced host group: servers (Wed Dec? 7 17:31:48 2016) [sssd[be[freeipa.domain.com]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Wed Dec? 7 17:31:48 2016) [sssd[be[freeipa.domain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules (Wed Dec? 7 17:31:48 2016) [sssd[be[freeipa.domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 6, ) [Success] (Wed Dec? 7 17:31:48 2016) [sssd[be[freeipa.domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [6][xxxxxxx.xxxx] ==> auth.log <== Dec? 7 17:31:48 jamesprecise sshd[1839]: pam_sss(sshd:account): Access denied for user a_aaaaaaa.aaaaa at xxxxxxx.xxxx: 6 (Permission denied) ==> sssd/sssd_freeipa.domain.com.log <== (Wed Dec? 7 17:31:48 2016) [sssd[be[freeipa.domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [6][xxxxxxx.xxxx] debug3: PAM: do_pam_account pam_acct_mgmt = 6 (Permission denied) debug3: mm_request_send entering: type 52 Failed publickey for a_aaaaaaa.aaaaa at xxxxxxx.xxxx from 10.10.10.10 port 45036 ssh2 debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa [preauth] debug3: mm_do_pam_account entering [preauth] debug3: mm_request_send entering: type 51 [preauth] debug3: mm_request_receive_expect entering: type 52 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_do_pam_account returning 0 [preauth] Access denied for user a_aaaaaaa.aaaaa at xxxxxxx.xxxx by PAM account configuration [preauth] debug1: do_cleanup [preauth] debug3: PAM: sshpam_thread_cleanup entering [preauth] debug1: monitor_read_log: child log fd closed debug3: mm_request_receive entering debug1: do_cleanup debug1: PAM: cleanup debug3: PAM: sshpam_thread_cleanup entering root at jamesprecise:/var/log# (Wed Dec? 7 17:31:56 2016) [sssd[be[freeipa.domain.com]]] [sdap_id_conn_data_expire_handler] (0x0080): connection is about to expire, releasing it (Wed Dec? 7 17:32:04 2016) [sssd[be[freeipa.domain.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Wed Dec? 7 17:32:04 2016) [sssd[be[freeipa.domain.com]]] [be_resolve_server_process] (0x0200): Found address for server freeipa.server.com: [11.11.11.11] TTL 1177 (Wed Dec? 7 17:32:04 2016) [sssd[be[freeipa.domain.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Wed Dec? 7 17:32:04 2016) [sssd[be[freeipa.domain.com]]] [be_resolve_server_process] (0x0200): Found address for server freeipa.server.com: [11.11.11.11] TTL 1177 ==> sssd/ldap_child.log <== (Wed Dec? 7 17:32:04 2016) [[sssd[ldap_child[1841]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/client-freeipa.com at freeipa.domain.com] (Wed Dec? 7 17:32:04 2016) [[sssd[ldap_child[1841]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [default] (Wed Dec? 7 17:32:04 2016) [[sssd[ldap_child[1841]]]] [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals ==> syslog <== Dec? 7 17:32:04 jamesprecise kernel: [ 5423.086166] type=1400 audit(1481131924.403:53): apparmor="ALLOWED" operation="open" parent=952 profile="/usr/sbin/sssd" name="/var/lib/sss/pubconf/krb5.include.d/" pid=1841 comm="ldap_child" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Dec? 7 17:32:04 jamesprecise kernel: [ 5423.086190] type=1400 audit(1481131924.403:54): apparmor="ALLOWED" operation="open" parent=952 profile="/usr/sbin/sssd" name="/var/lib/sss/pubconf/krb5.include.d/domain_realm_freeipa-realm" pid=1841 comm="ldap_child" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 ==> sssd/sssd_freeipa.domain.com.log <== (Wed Dec? 7 17:32:04 2016) [sssd[be[freeipa.domain.com]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Wed Dec? 7 17:32:04 2016) [sssd[be[freeipa.domain.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/client-freeipa.com (Wed Dec? 7 17:32:05 2016) [sssd[be[freeipa.domain.com]]] [child_sig_handler] (0x0100): child [1841] finished successfully. (Wed Dec? 7 17:32:05 2016) [sssd[be[freeipa.domain.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'freeipa.server.com' as 'working' (Wed Dec? 7 17:32:05 2016) [sssd[be[freeipa.domain.com]]] [set_server_common_status] (0x0100): Marking server 'freeipa.server.com' as 'working' (Wed Dec? 7 17:32:05 2016) [sssd[be[freeipa.domain.com]]] [sdap_sudo_set_usn] (0x0200): SUDO higher USN value: [572244] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Dec 7 21:21:39 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 7 Dec 2016 22:21:39 +0100 Subject: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account In-Reply-To: <206623988.2535008.1481134746445@mail.yahoo.com> References: <206623988.2535008.1481134746445.ref@mail.yahoo.com> <206623988.2535008.1481134746445@mail.yahoo.com> Message-ID: <20161207212139.wzutonjafhht7zwj@hendrix> On Wed, Dec 07, 2016 at 06:19:06PM +0000, James Harrison wrote: > Hi all, > > I am trying to authenticate an ubuntu Precise (12.06) fully patched system. Its enrolled into a FreeIPA server. The following trace is the output of syslog auth sssd/*.log and full debug (-ddd) from the sshd service. > > I am getting a PAM error at the end of the procedure. Also I cant seem to authenticate against the public ssh key from the id override user. > > I appreciate any help you can send my way. > > Best regards, > > James Harrison > Below is more information > > > root at jamesprecise:~# kinit x_james.harrison at AD.DOMAIN.LOCAL > Password for x_james.harrison at AD.DOMAIN.LOCAL: > > root at jamesprecise:~# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: x_james.harrison at AD.DOMAIN.LOCAL > > Valid starting???? Expires??????????? Service principal > 07/12/16 17:56:30? 08/12/16 03:56:30? krbtgt/AD.DOMAIN.LOCAL at AD.DOMAIN.LOCAL > ??? renew until 08/12/16 17:56:23 > > root at jamesprecise:~# id x_james.harrison at AD.DOMAIN.LOCAL > uid=1039812876(x_james.harrison at ad.domain.local) gid=1039812876(x_james.harrison at ad.domain.local) groups=1039812876(x_james.harrison at ad.domain.local) HBAC denied the login, which is probably related to the supplementary groups not being resolved. This ancient SSSD version doesn't support returning supplementary groups unless you log in -- during the login attempt, the PAC responder should be able to decode the group memberships from the PAC and store the groups. So I'd look if the PAC responder is enabled and running and see if the krb5_child resolves the SIDs during password authentication (or if PAC responder is contacted during password-less authentication). > root at pul-lv-ipa-02 ~]# ipa? idoverrideuser-show External_AD_views x_james.harrison at ad.domain.local > ? Anchor to override: x_james.harrison at ad.domain.local > ? User login: x_james.harrison > ? Login shell: /bin/bash > ? SSH public key: ssh-rsa > ????????????????? AAAAB3NzaC1yc2EAAAADAQABAAABAQDK1pj2U7H9olLs1xKmcmZVEBMWpaHjxF2LttsdfqfQxm810qMru/WsvzHqu0m5Ugu0FYsPxRLQrAEB8WPsPoh5Y0q5qYPgm5aDOZZEXfCPyuRwdQ+XLfQJ3gnGjW4r/XLEiNVpO9eKsFs0ifspNAJ1ndddddddddddddddd7h40rlHlOIqV/z8Omg6XnFBh9dIfiXtpYDOxe+512RpjtHE98s+NfIpUTT7MGNLHB5o/DqFXEJPH7Pp1bKwxWNvfCb5a71vcE695dQ31QYVYwpSwFmFogewgpV/OCb+S4SUdUq1xg0fmkhYr3d4UXFr91MDimyOBWk9Aai7NkOHPszmHJp > ????????????????? JamesHarrison Overrides are not supported with this version. > > > Here are the software versions: > > root at jamesprecise:# dpkg -l | grep -i freeipa > ii? freeipa-client???????????????????????????? 3.3.4-0ubuntu3.1~precise0.1??????? FreeIPA centralized identity framework -- client > ii? libipa-hbac0?????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? FreeIPA HBAC Evaluator library > ii? python-freeipa???????????????????????????? 3.3.4-0ubuntu3.1~precise0.1??????? FreeIPA centralized identity framework -- python modules > ii? python-libipa-hbac???????????????????????? 1.11.5-1ubuntu3~precise1?????????? Python bindings for the FreeIPA HBAC Evaluator library > > root at jamesprecise:# dpkg -l | grep -i openssh-server > ii? openssh-server???????????????????????????? 1:5.9p1-5ubuntu1.10??????????????? secure shell (SSH) server, for secure access from remote machines > > > root at jamesprecise:/var/log# dpkg -l | grep -i sssd > ii? libsss-idmap0????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? ID mapping library for SSSD > ii? sssd?????????????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- metapackage > ii? sssd-ad??????????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- Active Directory back end > ii? sssd-ad-common???????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- PAC responder > ii? sssd-common??????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- common files > ii? sssd-ipa?????????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- IPA back end > ii? sssd-krb5????????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- Kerberos back end > ii? sssd-krb5-common?????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- Kerberos helpers > ii? sssd-ldap????????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- LDAP back end > ii? sssd-proxy???????????????????????????????? 1.11.5-1ubuntu3~precise1?????????? System Security Services Daemon -- proxy back end > ii? sudo?????????????????????????????????????? 1.8.9p5-1ubuntu1.1~sssd1?????????? Provide limited super user privileges to specific users All is all, I would suggest to upgrade to something more recent.. From BJB at jndata.dk Thu Dec 8 07:57:00 2016 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Thu, 8 Dec 2016 07:57:00 +0000 Subject: [Freeipa-users] nfsv4+kerberos: group ID not mapped on newly create users, however user id is correct Message-ID: <89213DDB84447F44A8E8950A5C2185E04832AC30@SJN01013.jnmain00.corp.jndata.net> Anybody have any suggestion as how to continue debugging this? The nfs server resolves usernames by loopkup in free-ipa lda. After a lot of digging, I see the 4.4 introduced "krbcanonicalname", no idea if that is relevant. Are there some update ldap procedure I am missing? Just in case I ran a ipa-server-upgrade, which did not resolve the issue. Regards Bjarne Blichfeldt. From: Bjarne Blichfeldt Sent: 6. december 2016 14:29 To: freeipa-users at redhat.com Subject: nfsv4+kerberos: group ID not mapped on newly create users, however user id is correct VERSION: 4.4.0, API_VERSION: 2.213 on rhel7. ipa server was recently upgraded to version 4.4 from version 4.2 and it seems that we are having problems with users created after the upgrade. Of course, it could be something I forgot. Our environment consist of an hds nfs server, a couple of ipa servers - rhel7 and a lot of clients - rhel6. The NFS server is not part of the idm domain, i.e. not joined, but of course has a keytab created on the ipa server. The NFS server provides common shares, mounted as krb5p on the clients. All this workes fine and the mapping is correct for all existing users. That is, if I log into a client, get a Kerberos ticket for myself and create a file on one of the shares, uid and gid are set to my uid and gid. But if I create a new user on the ipa server and do the same, the gid on the newly created file is "nobody(99)" whereas the uid is correct. I have tested with two different users - same result. klist shows the default principal to be correct. For user mqm uid=1414 gid=1414, rpc.gssd shows,that after finding the user credentials, for some reason there is a switch to machine credentials: Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handle_gssd_upcall: 'mech=krb5 uid=1414 enctypes=18,17,16,23,3,1,2 ' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: process_krb5_upcall: service is '' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: getting credentials for client with uid 1414 for server jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1622800027_u0vmh1' being considered, with preferred realm 'DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1622800027_u0vmh1' owned by 1622800027, not 1414 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1414_bVlw8x' being considered, with preferred realm 'DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1414_bVlw8x'(mqm at DOMAINE.COM) passed all checks and has mtime of 1481022999 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_machine_DOMAINE.COM' being considered, with preferred realm 'DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_machine_DOMAINE.COM' owned by 0, not 1414 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_0' being considered, with preferred realm 'DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_0' owned by 0, not 1414 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using FILE:/tmp/krb5cc_1414_bVlw8x as credentials cache for client with uid 1414 for server jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1414_bVlw8x Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context using fsuid 1414 (save_uid 0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating tcp client for server jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: port already set to 2049 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context with server nfs at jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: serialize_krb5_ctx: lucid version! Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: protocol 1 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: doing downcall lifetime_rec 86363 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 ' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: process_krb5_upcall: service is '*' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: Full hostname for 'jnsa-dnt2.domaine.com' is 'jnsa-dnt2.domaine.com' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: Full hostname for 'nfsclient.domaine.com' is 'nfsclient.domaine.com' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfsclient$@DOMAINE.COM while getting keytab entry for 'nfsclient$@DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfsclient$@DOMAINE.COM while getting keytab entry for 'nfsclient$@DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for root/nfsclient.domaine.com at DOMAINE.COM while getting keytab entry for 'root/nfsclient.domaine.com at DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfs/nfsclient.domaine.com at DOMAINE.COM while getting keytab entry for 'nfs/nfsclient.domaine.com at DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: Success getting keytab entry for 'host/nfsclient.domaine.com at DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_DOMAINE.COM' are good until 1481109339 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_DOMAINE.COM' are good until 1481109339 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using FILE:/tmp/krb5cc_machine_DOMAINE.COM as credentials cache for machine creds Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_DOMAINE.COM Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context using fsuid 0 (save_uid 0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating tcp client for server jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: port already set to 2049 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context with server nfs at jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: serialize_krb5_ctx: lucid version! Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: protocol 1 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: doing downcall lifetime_rec 86303 Regards Bjarne Blichfeldt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Dec 8 08:33:01 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 8 Dec 2016 09:33:01 +0100 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <58483A04.20000@sonsorol.org> References: <5846F92E.3010900@sonsorol.org> <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58471CDD.8070703@sonsorol.org> <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58483A04.20000@sonsorol.org> Message-ID: <20161208083301.GC3013@p.Speedport_W_724V_Typ_A_05011603_00_009> On Wed, Dec 07, 2016 at 11:34:12AM -0500, Chris Dagdigian wrote: > > Our problem is largely solved but we are using some "do not use in > production!" settings so I wanted to both recap our solution and ask some > follow up questions. > > Our setup: > ------------- > - FreeIPA 4.2 running on CentOS-7 in AWS VPC > - Edge-case split DNS setup. Our cloud clients are "company-aws.org" while > IPA is "company-ipa.org" realm/domain > - Massive need to authenticate against AD Forest COMPANY.COM which includes > a ton of child domains (NAFTA.COMPANY.COM, etc.) > > Problem > ----------- > - AD users are recognized and can be enumerated as long as I use > username at NAFTA.COMPANY.COM > - "su - " works as root to become the AD user > - All methods that require password check (SSH login mainly) failed > > The breakthrough was the advice from Sumit to add the ldap_user_principal > and subdomain_inherit settings. The core problem on our end seemed to be > issues with having the AD user UPN get sorted out. Something was failing > when user at NAFTA.COMPANY.COM was shortened to user at COMPANY.COM and we saw the > recurring error about " ... UPN is quite different ... " in the sssd domain > logs. > > > Solution (Server Side) > ----------------------------- > In /etc/sssd/sssd.conf: > ldap_user_principal = nosuchattr > subdomain_inherit = ldap_user_principal > krb5_validate = false > > > Solution (IPA client side) > -------------------------------- > In /etc/sssd/sssd.conf: > krb5_validate = false > > > I think the main problem is obvious. Even Sumit was clear to state that > "krb5_validate = false" should be used for testing only. > > However if we remove that setting password checking breaks. > > > So the basic "what next question" for the experts is: > > > 1. Do we chase down whatever config error we have that requires > krb5_validate=false ? > 2. Or do we assume that that problem is related to the UPN problem and > related AD-across-child-domains that appear to be resolved in IPA-4.4? I > keep getting the sense that massive AD-related things have been improved > recently in 4.3 and 4.4 > > My gut feeling is that it is our odd UPN issue that is breaking things so > rather than bend over backwards to try to figure out why krb5_validate=false > on our IPA-4.2 setup I'm sort of leaning towards trying to go for an upgrade > to IPA-4.4 and hope that whatever issue forced us to disable krb5_validate > is resolved in the new updates. The issues with the UPNs are far from odd and do not need fixing on the AD side. As said before IPA-4.4 can handle them properly but the ldap_user_principal/subdomain_inherit workaround for older versions can be used for production. > > Am I being stupid (again?) Obviously the krb5_validate=false setting needs > to be fixed. Just not sure if I should work on a fix within 4.2 or move to > 4.4 and see if it gets resolved as part of other changes. The validation issue might have different reasons. One might be https://fedorahosted.org/sssd/ticket/3103 where SSSD creates a wrong Kerberos configuration snippet. Fixes are available for sssd-1.13 and later. But there might be other reasons as well. If you don't mind please send the krb5_child.log with debug_level=10 covering an authentication attempt with 'krb5_validate = true' and the content of /var/lib/sss/pubconf/krb5.include.d/domain_realm_your_domain. bye, Sumit > > > Regards, > Chris > > > > > > From dkupka at redhat.com Thu Dec 8 08:39:55 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 8 Dec 2016 09:39:55 +0100 Subject: [Freeipa-users] nfsv4+kerberos: group ID not mapped on newly create users, however user id is correct In-Reply-To: <89213DDB84447F44A8E8950A5C2185E04832AC30@SJN01013.jnmain00.corp.jndata.net> References: <89213DDB84447F44A8E8950A5C2185E04832AC30@SJN01013.jnmain00.corp.jndata.net> Message-ID: On 08/12/16 08:57, Bjarne Blichfeldt wrote: > Anybody have any suggestion as how to continue debugging this? The nfs server resolves usernames by loopkup in free-ipa lda. > > After a lot of digging, I see the 4.4 introduced "krbcanonicalname", no idea if that is relevant. Are there some update ldap procedure I am missing? Just in case I ran a ipa-server-upgrade, which did not resolve the issue. > > > > Regards > Bjarne Blichfeldt. > > From: Bjarne Blichfeldt > Sent: 6. december 2016 14:29 > To: freeipa-users at redhat.com > Subject: nfsv4+kerberos: group ID not mapped on newly create users, however user id is correct > > VERSION: 4.4.0, API_VERSION: 2.213 on rhel7. > > ipa server was recently upgraded to version 4.4 from version 4.2 and it seems that we are having problems with users created after the upgrade. Of course, it could be > something I forgot. > > Our environment consist of an hds nfs server, a couple of ipa servers - rhel7 and a lot of clients - rhel6. The NFS server is not part of the idm domain, i.e. not joined, but of course has a keytab created on the ipa server. The NFS server provides common shares, mounted as krb5p on the clients. > > All this workes fine and the mapping is correct for all existing users. That is, if I log into a client, get a Kerberos ticket for myself and create a file on > one of the shares, uid and gid are set to my uid and gid. > > But if I create a new user on the ipa server and do the same, the gid on the newly created file is "nobody(99)" whereas the uid is correct. > I have tested with two different users - same result. > > klist shows the default principal to be correct. > For user mqm uid=1414 gid=1414, rpc.gssd shows,that after finding the user credentials, for some reason there is a switch to machine credentials: > > > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handle_gssd_upcall: 'mech=krb5 uid=1414 enctypes=18,17,16,23,3,1,2 ' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: process_krb5_upcall: service is '' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: getting credentials for client with uid 1414 for server jnsa-dnt2.domaine.com > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1622800027_u0vmh1' being considered, with preferred realm 'DOMAINE.COM' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1622800027_u0vmh1' owned by 1622800027, not 1414 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1414_bVlw8x' being considered, with preferred realm 'DOMAINE.COM' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_1414_bVlw8x'(mqm at DOMAINE.COM) passed all checks and has mtime of 1481022999 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_machine_DOMAINE.COM' being considered, with preferred realm 'DOMAINE.COM' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_machine_DOMAINE.COM' owned by 0, not 1414 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_0' being considered, with preferred realm 'DOMAINE.COM' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: CC file '/tmp/krb5cc_0' owned by 0, not 1414 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using FILE:/tmp/krb5cc_1414_bVlw8x as credentials cache for client with uid 1414 for server jnsa-dnt2.domaine.com > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1414_bVlw8x > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context using fsuid 1414 (save_uid 0) > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating tcp client for server jnsa-dnt2.domaine.com > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: port already set to 2049 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context with server nfs at jnsa-dnt2.domaine.com > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: serialize_krb5_ctx: lucid version! > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: protocol 1 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: doing downcall lifetime_rec 86363 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 ' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: process_krb5_upcall: service is '*' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: Full hostname for 'jnsa-dnt2.domaine.com' is 'jnsa-dnt2.domaine.com' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: Full hostname for 'nfsclient.domaine.com' is 'nfsclient.domaine.com' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfsclient$@DOMAINE.COM while getting keytab entry for 'nfsclient$@DOMAINE.COM' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfsclient$@DOMAINE.COM while getting keytab entry for 'nfsclient$@DOMAINE.COM' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for root/nfsclient.domaine.com at DOMAINE.COM while getting keytab entry for 'root/nfsclient.domaine.com at DOMAINE.COM' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfs/nfsclient.domaine.com at DOMAINE.COM while getting keytab entry for 'nfs/nfsclient.domaine.com at DOMAINE.COM' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: Success getting keytab entry for 'host/nfsclient.domaine.com at DOMAINE.COM' > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_DOMAINE.COM' are good until 1481109339 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_DOMAINE.COM' are good until 1481109339 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using FILE:/tmp/krb5cc_machine_DOMAINE.COM as credentials cache for machine creds > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_DOMAINE.COM > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context using fsuid 0 (save_uid 0) > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating tcp client for server jnsa-dnt2.domaine.com > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: port already set to 2049 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context with server nfs at jnsa-dnt2.domaine.com > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: serialize_krb5_ctx: lucid version! > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: protocol 1 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 > Dec 6 12:17:16 nfsclient rpc.gssd[1607]: doing downcall lifetime_rec 86303 > > Regards > Bjarne Blichfeldt. > > > > Hello, I'm almost sure that 'krbcanonicalname' has nothing to do with this. Adding krbcanonicalname attribute was done to allow principal aliases (multiple kerberos principals for one user/host/service), see [1] for details. Unfortunately, I don't know what's wrong. SSSD is taking care of resolving users and groups on enrolled systems. "id mgm" should output something like "id=1414(mgm) gid=1414(mgm) groups=1414(mgm)" if it works properly. [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases -- David Kupka From pieter at lautus.net Thu Dec 8 08:50:42 2016 From: pieter at lautus.net (Pieter Nagel) Date: Thu, 8 Dec 2016 10:50:42 +0200 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> Message-ID: On Wed, Dec 7, 2016 at 3:57 PM, Brian Candler wrote: > The Kerberos realm always has a corresponding DNS domain, so realm > IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net". > This is the crux of what I find unclear. The docs make it sound as if the DNS domain that corresponds to the Kerberos realm needs to be the exact same DNS domain that the FreeIPA internal DNS is actively managing. But I get the impression in this thread that the DNS domain that corresponds to the Kerberos realm just needs to be a DNS domain that belongs to the organisation using FreeIPA. Concrete scenario, I wonder if this will work: A greenfields deployment, no other kerberos, no Active Directory. Internal DNS to be int.lautus.net and FreeIPA manages that DNS domain and adds internal hosts to it as they enroll. Public-facing servers are manually registered in lautus.net DNS which is hosted elsewhere. But FreeIPA is installed with realm LAUTUS.NET so it adds _kerberos entries for realm LAUTUS.NET to int.lautus.net, and I manually copy those entries to lautus.net, so everone agrees that they belong to the same realm. The reason I want the realm to be LAUTUS.NET is because it makes more sense to me that the internal desktops in the subdomain int.lautus.net to enroll into a realm related to the parent DNS domain, than it makes sense for the public-facing servers in the parent lautus.net domain enroll into a realm related to an internal DNS subdomain. Or am I making an issue of a cosmetic triviality, and it is not all all strange in the kerberos realm to enroll a server into a realm related to a DNS subdomain it is not part of? -- Pieter Nagel Lautus Solutions (Pty) Ltd Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng 0832587540 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Dec 8 08:59:23 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 8 Dec 2016 10:59:23 +0200 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> Message-ID: <20161208085923.qh6mauratg3z4f5v@redhat.com> On to, 08 joulu 2016, Pieter Nagel wrote: >On Wed, Dec 7, 2016 at 3:57 PM, Brian Candler wrote: > >> The Kerberos realm always has a corresponding DNS domain, so realm >> IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net". >> > >This is the crux of what I find unclear. The docs make it sound as if the >DNS domain that corresponds to the Kerberos realm needs to be the exact >same DNS domain that the FreeIPA internal DNS is actively managing. But I >get the impression in this thread that the DNS domain that corresponds to >the Kerberos realm just needs to be a DNS domain that belongs to the >organisation using FreeIPA. It is really simply: your DNS domain named as your Kerberos realm must be under your control, one way or another, to allow automatic discovery of resources to work. This is how Kerberos automatic service discovery is designed to work. If you are not using Kerberos automatic discovery; if all your KDC resources are fixed in krb5.conf on all machines, all your SSSD configurations on all IPA machines are fixed to point to exact servers with no fallback to automatic service discovery; if you are not using trust to Active Directory forests, you can ignore that requirement. In majority of deployments, however, people are relying on automatic service discovery for multiple reasons or using trust to AD feature. These deployments must follow the rules defined by those who invented automatic service discovery and technologies like Active Directory. Overall, documentation might be too dense on the details, but it is a balance between giving the necessary details and giving too many details. >Concrete scenario, I wonder if this will work: > >A greenfields deployment, no other kerberos, no Active Directory. Internal >DNS to be int.lautus.net and FreeIPA manages that DNS domain and adds >internal hosts to it as they enroll. Public-facing servers are manually >registered in lautus.net DNS which is hosted elsewhere. But FreeIPA is >installed with realm LAUTUS.NET so it adds _kerberos entries for realm >LAUTUS.NET to int.lautus.net, and I manually copy those entries to >lautus.net, so everone agrees that they belong to the same realm. > >The reason I want the realm to be LAUTUS.NET is because it makes more sense >to me that the internal desktops in the subdomain int.lautus.net to enroll >into a realm related to the parent DNS domain, than it makes sense for the >public-facing servers in the parent lautus.net domain enroll into a realm >related to an internal DNS subdomain. Or am I making an issue of a cosmetic >triviality, and it is not all all strange in the kerberos realm to enroll a >server into a realm related to a DNS subdomain it is not part of? > >-- >Pieter Nagel >Lautus Solutions (Pty) Ltd >Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng >0832587540 >-- >Manage your subscription for 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 pieter at lautus.net Thu Dec 8 09:12:14 2016 From: pieter at lautus.net (Pieter Nagel) Date: Thu, 8 Dec 2016 11:12:14 +0200 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: <20161208085923.qh6mauratg3z4f5v@redhat.com> References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> <20161208085923.qh6mauratg3z4f5v@redhat.com> Message-ID: On Thu, Dec 8, 2016 at 10:59 AM, Alexander Bokovoy wrote: > It is really simply: your DNS domain named as your Kerberos realm must > be under your control, one way or another, to allow automatic discovery > of resources to work. > Thanks, this explanation makes it crystal clear. This exact phrasing would have made the docs much clearer too, IMO. Setting the realm to the DNS domain that the FreeIPA internal DNS server serves is just one simple out-of-the box way to get DNS domain named as your Kerberos realm that is under your control, in other words. -- Pieter Nagel Lautus Solutions (Pty) Ltd Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng 0832587540 -------------- next part -------------- An HTML attachment was scrubbed... URL: From BJB at jndata.dk Thu Dec 8 10:24:54 2016 From: BJB at jndata.dk (Bjarne Blichfeldt) Date: Thu, 8 Dec 2016 10:24:54 +0000 Subject: [Freeipa-users] nfsv4+kerberos: group ID not mapped on newly create users, however user id is correct In-Reply-To: References: <89213DDB84447F44A8E8950A5C2185E04832AC30@SJN01013.jnmain00.corp.jndata.net> Message-ID: <89213DDB84447F44A8E8950A5C2185E04832AD0B@SJN01013.jnmain00.corp.jndata.net> > -----Original Message----- > From: David Kupka [mailto:dkupka at redhat.com] > Sent: 8. december 2016 09:40 > To: Bjarne Blichfeldt ; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] nfsv4+kerberos: group ID not mapped on newly > create users, however user id is correct > > On 08/12/16 08:57, Bjarne Blichfeldt wrote: > > Anybody have any suggestion as how to continue debugging this? The nfs server > resolves usernames by loopkup in free-ipa lda. > > > > After a lot of digging, I see the 4.4 introduced "krbcanonicalname", no idea if that > is relevant. Are there some update ldap procedure I am missing? Just in case I ran > a ipa-server-upgrade, which did not resolve the issue. > > > > :snip > > > > > > Hello, > I'm almost sure that 'krbcanonicalname' has nothing to do with this. > Adding krbcanonicalname attribute was done to allow principal aliases (multiple > kerberos principals for one user/host/service), see [1] for details. > > Unfortunately, I don't know what's wrong. SSSD is taking care of resolving users > and groups on enrolled systems. "id mgm" should output something like > "id=1414(mgm) gid=1414(mgm) groups=1414(mgm)" if it works properly. > > [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases > > -- > David Kupka Thank you for that info. That led me somewhat further by increasing the debug on sssd which led me to : Dec 8 10:42:48 client nfsidmap[6663]: key: 0xae72f5 type: uid value: mqm2 at REALM.COM timeout 600 Dec 8 10:42:48 client nfsidmap[6663]: nfs4_name_to_uid: calling nsswitch->name_to_uid Dec 8 10:42:48 client nfsidmap[6663]: nss_getpwnam: name 'mqm2 at REALM.COM' domain 'REALM.COM': resulting localname 'mqm2' Dec 8 10:42:48 client nfsidmap[6663]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Dec 8 10:42:48 client nfsidmap[6663]: nfs4_name_to_uid: final return value is 0 Dec 8 10:42:48 client nfsidmap[6665]: key: 0xf56593 type: gid value: Null timeout 600 ^^^^^^^^^ Dec 8 10:42:48 client nfsidmap[6665]: nfs4_name_to_gid: calling nsswitch->name_to_gid Dec 8 10:42:48 client nfsidmap[6665]: nfs4_name_to_gid: nsswitch->name_to_gid returned -22 Dec 8 10:42:48 client nfsidmap[6665]: nfs4_name_to_gid: final return value is -22Seems nfsidmap is not called with a gid value. It seems nfsidmap is not called with a proper gid. hm, the saga continues... -- Regards Bjarne Blichfeldt. From b.candler at pobox.com Thu Dec 8 11:01:16 2016 From: b.candler at pobox.com (Brian Candler) Date: Thu, 8 Dec 2016 11:01:16 +0000 Subject: [Freeipa-users] Removing DNS component Message-ID: <2b0f3893-c4a0-c3aa-fc31-8b47ae462ccc@pobox.com> FreeIPA (4.2.0) was installed with the DNS component enabled, but I want to pull this out. Is it possible to remove it and clean up the records which were already there? e.g. is it sufficient just to delete everything under cn=dns,dc=example,dc=com ? I notice there are bunch of permissions entries in other parts of the tree which reference these with ipaPermTarget, do they have to go too? Or would I have to re-install from scratch? Thanks, Brian. From lslebodn at redhat.com Thu Dec 8 11:22:49 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 8 Dec 2016 12:22:49 +0100 Subject: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account In-Reply-To: <206623988.2535008.1481134746445@mail.yahoo.com> References: <206623988.2535008.1481134746445.ref@mail.yahoo.com> <206623988.2535008.1481134746445@mail.yahoo.com> Message-ID: <20161208112248.GA15828@10.4.128.1> On (07/12/16 18:19), James Harrison wrote: >Hi all, > >I am trying to authenticate an ubuntu Precise (12.06) fully patched system. Its enrolled into a FreeIPA server. The following trace is the output of syslog auth sssd/*.log and full debug (-ddd) from the sshd service. > Are you able to reproduce with ubuntu 14.04 and sssd from trusty-updates(1.11.8-0ubuntu0.3) You might also consig=der to test sssd-1.13.4 (in ubuntu 16.04) or at least 1.12.5-1~trusty1 from ppa https://launchpad.net/~sssd LS From david.klima at vig.cz Thu Dec 8 12:37:43 2016 From: david.klima at vig.cz (=?iso-8859-1?Q?Kl=EDma_David?=) Date: Thu, 8 Dec 2016 12:37:43 +0000 Subject: [Freeipa-users] FreeIPA behind Apache Reverse Proxy and Load Balancer Message-ID: Hi Simo, I think this is not true, because part of IPA web UI is IPA JSON API also - and there is problem with loadbalancing, as you can see there https://www.redhat.com/archives/freeipa-users/2016-October/msg00223.html. David From simo at redhat.com Thu Dec 8 12:47:56 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 08 Dec 2016 07:47:56 -0500 Subject: [Freeipa-users] FreeIPA behind Apache Reverse Proxy and Load Balancer In-Reply-To: References: Message-ID: <1481201276.7156.7.camel@redhat.com> On Thu, 2016-12-08 at 12:37 +0000, Kl?ma David wrote: > Hi Simo, I think this is not true, because part of IPA web UI is IPA > JSON API also - and there is problem with loadbalancing, as you can > see there > https://www.redhat.com/archives/freeipa-users/2016-October/msg00223.html. Sorry David, it is not clear to me what you are objecting to, please be more specific or quote the specific part of my previous reply that you find questionable. Simo. -- Simo Sorce * Red Hat, Inc * New York From email at jacobdevans.com Wed Dec 7 13:59:58 2016 From: email at jacobdevans.com (Jacob Evans) Date: Wed, 7 Dec 2016 08:59:58 -0500 (EST) Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: References: <20161207085819.q5onuspvbrog6hee@redhat.com> Message-ID: <692486424.32512.1481119198371@vegas.jacobdevans.com> Pieter, If you are comfortable with duplicating your external records internally, you CAN use this domain, however I've always preferred to have internal only and external only domains (we actually register domains externally that are internal use only). so for example, lautus.net is your external domain, for internal you could use a subdomain like ipa.lautus.net or lautus.tech. Split DNS isn't wrong, but it never makes things easier. your SRV records would only need to be duplicated if your users are @lautus.net and not @ipa.lautus.net or @ad.lautus.net. I hope this helps, this is all general dns infrastructure, so you could also checkout any other resources on building domain/forest infrastructure recommendations Good Luck, Jacob From: "Pieter Nagel" To: "freeipa-users" Sent: Wednesday, December 7, 2016 8:33:41 AM Subject: Re: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. Thanks, that helps a lot. Yes and no. What you see with "@ NS ..." is a glue record -- you are supposed to have a glue record for IPA domain in the upstream domain, this is how domain delegation works in DNS world. Except what i saw was the other way around. The FreeIPA server has an NSrecord claiming that it is authoritative the parent domain, but its parent domain is hosted at dnsmadeeasy: ~ dig @ [ http://8.8.8.8/ | 8.8.8.8 ] -t NS [ http://lautus.net/ | lautus.net ] [ http://lautus.net/ | lautus.net ] . 86399 IN NS [ http://ns15.dnsmadeeasy.com/ | ns15.dnsmadeeasy.com ] . ~ dig @ [ http://8.8.8.8/ | 8.8.8.8 ] -t NS [ http://ipa.lautus.net/ | ipa.lautus.net ] [ http://ipa.lautus.net/ | ipa.lautus.net ] . 86399 IN NS [ http://ipa-hetzner-cpt4-01.lautus.net/ | ipa-hetzner-cpt4-01.lautus.net ] . But as far as the FreeIPA DNS is concerned, it is authoritative for everything: ~ dig @ [ http://ipa-hetzner-cpt4-01.lautus.net/ | ipa-hetzner-cpt4-01.lautus.net ] -t NS [ http://lautus.net/ | lautus.net ] [ http://lautus.net/ | lautus.net ] . 86400 IN NS [ http://ipa-hetzner-cpt4-01.lautus.net/ | ipa-hetzner-cpt4-01.lautus.net ] . ~ dig @ [ http://ipa-hetzner-cpt4-01.lautus.net/ | ipa-hetzner-cpt4-01.lautus.net ] -t NS [ http://ipa.lautus.net/ | ipa.lautus.net ] [ http://ipa.lautus.net/ | ipa.lautus.net ] . 86400 IN NS [ http://ipa-hetzner-cpt4-01.lautus.net/ | ipa-hetzner-cpt4-01.lautus.net ] . -- Pieter Nagel Lautus Solutions (Pty) Ltd Building 27, The Woodlands, 20 Woodlands Drive, Woodmead, Gauteng 0832587540 -- Manage your subscription for 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: Evans, Jacob.vcf Type: text/directory Size: 454 bytes Desc: not available URL: From dag at sonsorol.org Thu Dec 8 14:29:34 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Thu, 08 Dec 2016 09:29:34 -0500 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <20161208083301.GC3013@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <5846F92E.3010900@sonsorol.org> <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58471CDD.8070703@sonsorol.org> <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58483A04.20000@sonsorol.org> <20161208083301.GC3013@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <58496E4E.9040503@sonsorol.org> Sumit Bose wrote: >> > Am I being stupid (again?) Obviously the krb5_validate=false setting needs >> > to be fixed. Just not sure if I should work on a fix within 4.2 or move to >> > 4.4 and see if it gets resolved as part of other changes. > > The validation issue might have different reasons. One might be > https://fedorahosted.org/sssd/ticket/3103 where SSSD creates a wrong > Kerberos configuration snippet. Fixes are available for sssd-1.13 and > later. But there might be other reasons as well. > > If you don't mind please send the krb5_child.log with debug_level=10 > covering an authentication attempt with 'krb5_validate = true' and the > content of /var/lib/sss/pubconf/krb5.include.d/domain_realm_your_domain. Thanks Sumit, Info you requested is attached. These logs are from a client machine. I confirmed that I could not authenticate with krb5_validate = True and that I could authenticate when I switched krb5_validate=false. I set the value to "True", turned up debug logging to 10 and then stopped SSSD service after my 3 login tries to try to constrain the log volume. Still ended up with 1200+ lines in krb5_child.log though Here is the info you requested (sanitized) URL to krb5_child.log since it is pretty lengthy: ------------------------------------------------------------- http://chrisdag.me/krb5_child.log.txt And we actually had 2 domain_realm* files which is I think due to our difference in DNS for client hostnames vs DNS for the IPA server: Our CAPATH info does look like that SSSD issue you mentioned (ticket 3103) ... This is domain_realm_companyaws_org: ------------------------------------------------------ [domain_realm] .COMPANY.ORG = COMPANY.ORG COMPANY.ORG = COMPANY.ORG .EAME.COMPANY.ORG = EAME.COMPANY.ORG EAME.COMPANY.ORG = EAME.COMPANY.ORG .APAC.COMPANY.ORG = APAC.COMPANY.ORG APAC.COMPANY.ORG = APAC.COMPANY.ORG .LATAM.COMPANY.ORG = LATAM.COMPANY.ORG LATAM.COMPANY.ORG = LATAM.COMPANY.ORG .NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG [capaths] COMPANY.ORG = { COMPANYAWS.ORG = COMPANY.ORG } COMPANYAWS.ORG = { COMPANY.ORG = COMPANY.ORG } EAME.COMPANY.ORG = { COMPANYAWS.ORG = COMPANY.ORG } COMPANYAWS.ORG = { EAME.COMPANY.ORG = COMPANY.ORG } APAC.COMPANY.ORG = { COMPANYAWS.ORG = COMPANY.ORG } COMPANYAWS.ORG = { APAC.COMPANY.ORG = COMPANY.ORG } LATAM.COMPANY.ORG = { COMPANYAWS.ORG = COMPANY.ORG } COMPANYAWS.ORG = { LATAM.COMPANY.ORG = COMPANY.ORG } NAFTA.COMPANY.ORG = { COMPANYAWS.ORG = COMPANY.ORG } COMPANYAWS.ORG = { NAFTA.COMPANY.ORG = COMPANY.ORG } And this is domain_realm_companyidm_org: ------------------------------------------------------------ [domain_realm] .COMPANY.ORG = COMPANY.ORG COMPANY.ORG = COMPANY.ORG .EAME.COMPANY.ORG = EAME.COMPANY.ORG EAME.COMPANY.ORG = EAME.COMPANY.ORG .APAC.COMPANY.ORG = APAC.COMPANY.ORG APAC.COMPANY.ORG = APAC.COMPANY.ORG .LATAM.COMPANY.ORG = LATAM.COMPANY.ORG LATAM.COMPANY.ORG = LATAM.COMPANY.ORG .NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG [capaths] COMPANYAWS.ORG = { COMPANYIDM.ORG = COMPANYAWS.ORG } COMPANYIDM.ORG = { COMPANYAWS.ORG = COMPANYAWS.ORG } COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } COMPANYIDM.ORG = { COMPANY.ORG = COMPANY.ORG } EAME.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } COMPANYIDM.ORG = { EAME.COMPANY.ORG = COMPANY.ORG } APAC.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } COMPANYIDM.ORG = { APAC.COMPANY.ORG = COMPANY.ORG } LATAM.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } COMPANYIDM.ORG = { LATAM.COMPANY.ORG = COMPANY.ORG } NAFTA.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } COMPANYIDM.ORG = { NAFTA.COMPANY.ORG = COMPANY.ORG } From mbasti at redhat.com Thu Dec 8 14:38:26 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Dec 2016 15:38:26 +0100 Subject: [Freeipa-users] FreeIPA server docker images have been migrated to freeipa organization Message-ID: Hello, I would like to announce that FreeIPA server docker images have been migrated to freeipa organization: * images: https://hub.docker.com/r/freeipa/freeipa-server/ * sources: https://github.com/freeipa/freeipa-container * additional info: http://www.freeipa.org/page/Docker Happy hacking, Martin From jamesaharrisonuk at yahoo.co.uk Thu Dec 8 15:02:08 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Thu, 8 Dec 2016 15:02:08 +0000 (UTC) Subject: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account In-Reply-To: <20161208112248.GA15828@10.4.128.1> References: <206623988.2535008.1481134746445.ref@mail.yahoo.com> <206623988.2535008.1481134746445@mail.yahoo.com> <20161208112248.GA15828@10.4.128.1> Message-ID: <563729005.652190.1481209328358@mail.yahoo.com> Hi,I would prefer not to compile anything. It means we have to maintain the package, rather than the distro maintainers. Trusty has a completely different set of errors to Precise.? Xenial works with no problems. I run a script that allows the system to join the IPA domain (the same script regardless of Ubuntu distro): ( $P_W is read in from stdin) ipa-client-install \ ???? --server="$IPA_SERVER" \ ???? --domain=dns.domain.com \ ???? --principal=admin \ ???? --password="$P_W" \ ???? --preserve-sssd \ ???? --mkhomedir \ ???? --no-ntp \ ???? -U Enter (Admins) Password:?? Confirm Password: Hostname: jamestrusty.dns.domain.com Realm: IPA.REALM.COM DNS Domain: dns.domain.com IPA Server: pul-lv-ipa-01.dns.domain.com BaseDN: dc=int,dc=worldfirst,dc=com Synchronizing time with KDC... Dec? 8 14:50:58 jamestrusty ntpdate[2448]: ntpdate 4.2.6p5 at 1.2349-o Wed Oct? 5 12:35:26 UTC 2016 (1) Dec? 8 14:50:58 jamestrusty ntpdate[2448]: the NTP socket is in use, exiting ... ... ... ... ... Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Successfully retrieved CA cert ??? Subject:???? CN=SOMECERT ??? Issuer:????? CN=SOMECERT ??? Valid From:? Wed Mar 12 00:00:00 2014 UTC ??? Valid Until: Sun Mar 11 23:59:59 3029 UTC Enrolled in IPA realm IPA.REALM.COM Created /etc/ipa/default.conf New SSSD config will be created Configured /etc/sssd/sssd.conf Failed to add CA to the default NSS database. Installation failed. Rolling back changes. Unenrolling client from IPA server Unenrolling host failed: Error getting default Kerberos realm: Configuration file does not specify default realm. Removing Kerberos service principals from /etc/krb5.keytab Disabling client Kerberos and LDAP configurations Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted SSSD service could not be stopped Client uninstall complete. From: Lukas Slebodnik To: James Harrison Cc: "freeipa-users at redhat.com" Sent: Thursday, 8 December 2016, 11:22 Subject: Re: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account On (07/12/16 18:19), James Harrison wrote: >Hi all, > >I am trying to authenticate an ubuntu Precise (12.06) fully patched system. Its enrolled into a FreeIPA server. The following trace is the output of syslog auth sssd/*.log and full debug (-ddd) from the sshd service. > Are you able to reproduce with ubuntu 14.04 and sssd from trusty-updates(1.11.8-0ubuntu0.3) You might also consig=der to test sssd-1.13.4 (in ubuntu 16.04) or at least 1.12.5-1~trusty1 from ppa https://launchpad.net/~sssd LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesaharrisonuk at yahoo.co.uk Thu Dec 8 15:27:37 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Thu, 8 Dec 2016 15:27:37 +0000 (UTC) Subject: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account In-Reply-To: <563729005.652190.1481209328358@mail.yahoo.com> References: <206623988.2535008.1481134746445.ref@mail.yahoo.com> <206623988.2535008.1481134746445@mail.yahoo.com> <20161208112248.GA15828@10.4.128.1> <563729005.652190.1481209328358@mail.yahoo.com> Message-ID: <2051201645.699881.1481210857958@mail.yahoo.com> Hi,An update. I just got Trusty enrolled into FreeIPA by removing everything in: /etc/pki/nssdb and running: /usr/bin/certutil -N --empty-password -d /etc/pki/nssdb ... before the client-install is run. I get user IDs with Freeipa and AD domains: root at jamestrusty:/etc/pki/nssdb# id x_james.harrison at IPA.REALM.COMuid=1082600009(x_james.harrison) gid=1082600009(x_james.harrison) groups=1082600009(x_james.harrison),1082600000(admins),1082600010(ipausers) root at jamestrusty:/etc/pki/nssdb# id x_james.harrison at AD.DOMAIN.LOCAL uid=1039812876(x_james.harrison at ad.domain.local) gid=1039812876(x_james.harrison at ad.domain.local) groups=1039812876(x_james.harrison at ad.domain.locall) However auth issues still the same as Precise. Doesnt accept the ssh public key stored with the IPA user or the Trust ID view user. Xenial has no problems. Regards,James Harrison From: James Harrison To: "freeipa-users at redhat.com" Sent: Thursday, 8 December 2016, 15:02 Subject: Re: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account Hi,I would prefer not to compile anything. It means we have to maintain the package, rather than the distro maintainers. Trusty has a completely different set of errors to Precise.? Xenial works with no problems. I run a script that allows the system to join the IPA domain (the same script regardless of Ubuntu distro): ( $P_W is read in from stdin) ipa-client-install \ ???? --server="$IPA_SERVER" \ ???? --domain=dns.domain.com \ ???? --principal=admin \ ???? --password="$P_W" \ ???? --preserve-sssd \ ???? --mkhomedir \ ???? --no-ntp \ ???? -U Enter (Admins) Password:?? Confirm Password: Hostname: jamestrusty.dns.domain.com Realm: IPA.REALM.COM DNS Domain: dns.domain.com IPA Server: pul-lv-ipa-01.dns.domain.com BaseDN: dc=int,dc=worldfirst,dc=com Synchronizing time with KDC... Dec? 8 14:50:58 jamestrusty ntpdate[2448]: ntpdate 4.2.6p5 at 1.2349-o Wed Oct? 5 12:35:26 UTC 2016 (1) Dec? 8 14:50:58 jamestrusty ntpdate[2448]: the NTP socket is in use, exiting ... ... ... ... ... Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Successfully retrieved CA cert ??? Subject:???? CN=SOMECERT ??? Issuer:????? CN=SOMECERT ??? Valid From:? Wed Mar 12 00:00:00 2014 UTC ??? Valid Until: Sun Mar 11 23:59:59 3029 UTC Enrolled in IPA realm IPA.REALM.COM Created /etc/ipa/default.conf New SSSD config will be created Configured /etc/sssd/sssd.conf Failed to add CA to the default NSS database. Installation failed. Rolling back changes. Unenrolling client from IPA server Unenrolling host failed: Error getting default Kerberos realm: Configuration file does not specify default realm. Removing Kerberos service principals from /etc/krb5.keytab Disabling client Kerberos and LDAP configurations Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted SSSD service could not be stopped Client uninstall complete. From: Lukas Slebodnik To: James Harrison Cc: "freeipa-users at redhat.com" Sent: Thursday, 8 December 2016, 11:22 Subject: Re: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account On (07/12/16 18:19), James Harrison wrote: >Hi all, > >I am trying to authenticate an ubuntu Precise (12.06) fully patched system. Its enrolled into a FreeIPA server. The following trace is the output of syslog auth sssd/*.log and full debug (-ddd) from the sshd service. > Are you able to reproduce with ubuntu 14.04 and sssd from trusty-updates(1.11.8-0ubuntu0.3) You might also consig=der to test sssd-1.13.4 (in ubuntu 16.04) or at least 1.12.5-1~trusty1 from ppa https://launchpad.net/~sssd LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Dec 8 15:28:44 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 8 Dec 2016 10:28:44 -0500 Subject: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account In-Reply-To: <563729005.652190.1481209328358@mail.yahoo.com> References: <206623988.2535008.1481134746445.ref@mail.yahoo.com> <206623988.2535008.1481134746445@mail.yahoo.com> <20161208112248.GA15828@10.4.128.1> <563729005.652190.1481209328358@mail.yahoo.com> Message-ID: <58497C2C.9050304@redhat.com> James Harrison wrote: > > Hi, > I would prefer not to compile anything. It means we have to maintain the > package, rather than the distro maintainers. > > Trusty has a completely different set of errors to Precise. > > Xenial works with no problems. > > I run a script that allows the system to join the IPA domain (the same > script regardless of Ubuntu distro): > > ( $P_W is read in from stdin) > > ipa-client-install \ > --server="$IPA_SERVER" \ > --domain=dns.domain.com \ > --principal=admin \ > --password="$P_W" \ > --preserve-sssd \ > --mkhomedir \ > --no-ntp \ > -U > > > Enter (Admins) Password: > Confirm Password: > Hostname: jamestrusty.dns.domain.com > Realm: IPA.REALM.COM > DNS Domain: dns.domain.com > IPA Server: pul-lv-ipa-01.dns.domain.com > BaseDN: dc=int,dc=worldfirst,dc=com > > Synchronizing time with KDC... > Dec 8 14:50:58 jamestrusty ntpdate[2448]: ntpdate 4.2.6p5 at 1.2349-o Wed > Oct 5 12:35:26 UTC 2016 (1) > Dec 8 14:50:58 jamestrusty ntpdate[2448]: the NTP socket is in use, exiting > ... > ... > ... > ... > ... > Unable to sync time with IPA NTP server, assuming the time is in sync. > Please check that 123 UDP port is opened. > Successfully retrieved CA cert > Subject: CN=SOMECERT > Issuer: CN=SOMECERT > Valid From: Wed Mar 12 00:00:00 2014 UTC > Valid Until: Sun Mar 11 23:59:59 3029 UTC > > Enrolled in IPA realm IPA.REALM.COM > Created /etc/ipa/default.conf > New SSSD config will be created > Configured /etc/sssd/sssd.conf > Failed to add CA to the default NSS database. > Installation failed. Rolling back changes. > Unenrolling client from IPA server > Unenrolling host failed: Error getting default Kerberos realm: > Configuration file does not specify default realm. > > Removing Kerberos service principals from /etc/krb5.keytab > Disabling client Kerberos and LDAP configurations > Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to > /etc/sssd/sssd.conf.deleted > SSSD service could not be stopped > Client uninstall complete. The stdout is usually not very helpful, /var/log/ipaclient-install.log contains the real details. Still, were I to guess, the required NSS database (and directory) doesn't exist. This would be located in either /etc/ipa/nssdb or /etc/pki/nssdb. rob > > > ------------------------------------------------------------------------ > *From:* Lukas Slebodnik > *To:* James Harrison > *Cc:* "freeipa-users at redhat.com" > *Sent:* Thursday, 8 December 2016, 11:22 > *Subject:* Re: [Freeipa-users] Problem with Free IPA Client Ubuntu > Precise (12.04) authenticating with AD account > > On (07/12/16 18:19), James Harrison wrote: >>Hi all, >> >>I am trying to authenticate an ubuntu Precise (12.06) fully patched > system. Its enrolled into a FreeIPA server. The following trace is the > output of syslog auth sssd/*.log and full debug (-ddd) from the sshd > service. >> > Are you able to reproduce with ubuntu 14.04 > and sssd from trusty-updates(1.11.8-0ubuntu0.3) > You might also consig=der to test sssd-1.13.4 (in ubuntu 16.04) > or at least 1.12.5-1~trusty1 from ppa > https://launchpad.net/~sssd > > > LS > > > > From jamesaharrisonuk at yahoo.co.uk Thu Dec 8 15:50:13 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Thu, 8 Dec 2016 15:50:13 +0000 (UTC) Subject: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account In-Reply-To: <20161208112248.GA15828@10.4.128.1> References: <206623988.2535008.1481134746445.ref@mail.yahoo.com> <206623988.2535008.1481134746445@mail.yahoo.com> <20161208112248.GA15828@10.4.128.1> Message-ID: <973918580.735644.1481212213594@mail.yahoo.com> I tried to clone the git repos and I got access right errors James From: Lukas Slebodnik To: James Harrison Cc: "freeipa-users at redhat.com" Sent: Thursday, 8 December 2016, 11:22 Subject: Re: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account On (07/12/16 18:19), James Harrison wrote: >Hi all, > >I am trying to authenticate an ubuntu Precise (12.06) fully patched system. Its enrolled into a FreeIPA server. The following trace is the output of syslog auth sssd/*.log and full debug (-ddd) from the sshd service. > Are you able to reproduce with ubuntu 14.04 and sssd from trusty-updates(1.11.8-0ubuntu0.3) You might also consig=der to test sssd-1.13.4 (in ubuntu 16.04) or at least 1.12.5-1~trusty1 from ppa https://launchpad.net/~sssd LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesaharrisonuk at yahoo.co.uk Thu Dec 8 16:10:12 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Thu, 8 Dec 2016 16:10:12 +0000 (UTC) Subject: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account In-Reply-To: <20161208112248.GA15828@10.4.128.1> References: <206623988.2535008.1481134746445.ref@mail.yahoo.com> <206623988.2535008.1481134746445@mail.yahoo.com> <20161208112248.GA15828@10.4.128.1> Message-ID: <953139400.790469.1481213412430@mail.yahoo.com> Hi,From this URL: https://launchpad.net/~sssd/+archive/ubuntu/updates i updated sssd on Trusty and I can now ssh to it using a FreeIPA user's? credentials. AD Still doesn't work. Thanks From: Lukas Slebodnik To: James Harrison Cc: "freeipa-users at redhat.com" Sent: Thursday, 8 December 2016, 11:22 Subject: Re: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account On (07/12/16 18:19), James Harrison wrote: >Hi all, > >I am trying to authenticate an ubuntu Precise (12.06) fully patched system. Its enrolled into a FreeIPA server. The following trace is the output of syslog auth sssd/*.log and full debug (-ddd) from the sshd service. > Are you able to reproduce with ubuntu 14.04 and sssd from trusty-updates(1.11.8-0ubuntu0.3) You might also consig=der to test sssd-1.13.4 (in ubuntu 16.04) or at least 1.12.5-1~trusty1 from ppa https://launchpad.net/~sssd LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Dec 8 16:33:26 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 8 Dec 2016 17:33:26 +0100 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <58496E4E.9040503@sonsorol.org> References: <5846F92E.3010900@sonsorol.org> <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58471CDD.8070703@sonsorol.org> <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58483A04.20000@sonsorol.org> <20161208083301.GC3013@p.Speedport_W_724V_Typ_A_05011603_00_009> <58496E4E.9040503@sonsorol.org> Message-ID: <20161208163325.GF3013@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, Dec 08, 2016 at 09:29:34AM -0500, Chris Dagdigian wrote: > > Sumit Bose wrote: > > > > Am I being stupid (again?) Obviously the krb5_validate=false setting needs > > > > to be fixed. Just not sure if I should work on a fix within 4.2 or move to > > > > 4.4 and see if it gets resolved as part of other changes. > > > > The validation issue might have different reasons. One might be > > https://fedorahosted.org/sssd/ticket/3103 where SSSD creates a wrong > > Kerberos configuration snippet. Fixes are available for sssd-1.13 and > > later. But there might be other reasons as well. > > > > If you don't mind please send the krb5_child.log with debug_level=10 > > covering an authentication attempt with 'krb5_validate = true' and the > > content of /var/lib/sss/pubconf/krb5.include.d/domain_realm_your_domain. > > Thanks Sumit, > > Info you requested is attached. These logs are from a client machine. I > confirmed that I could not authenticate with krb5_validate = True and that I > could authenticate when I switched krb5_validate=false. I set the value to > "True", turned up debug logging to 10 and then stopped SSSD service after my > 3 login tries to try to constrain the log volume. > > Still ended up with 1200+ lines in krb5_child.log though > > Here is the info you requested (sanitized) > > URL to krb5_child.log since it is pretty lengthy: > ------------------------------------------------------------- > http://chrisdag.me/krb5_child.log.txt > > > And we actually had 2 domain_realm* files which is I think due to our > difference in DNS for client hostnames vs DNS for the IPA server: > Our CAPATH info does look like that SSSD issue you mentioned (ticket 3103) > ... > > > This is domain_realm_companyaws_org: > ------------------------------------------------------ > [domain_realm] > .COMPANY.ORG = COMPANY.ORG > COMPANY.ORG = COMPANY.ORG > .EAME.COMPANY.ORG = EAME.COMPANY.ORG > EAME.COMPANY.ORG = EAME.COMPANY.ORG > .APAC.COMPANY.ORG = APAC.COMPANY.ORG > APAC.COMPANY.ORG = APAC.COMPANY.ORG > .LATAM.COMPANY.ORG = LATAM.COMPANY.ORG > LATAM.COMPANY.ORG = LATAM.COMPANY.ORG > .NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG > NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG > [capaths] > COMPANY.ORG = { > COMPANYAWS.ORG = COMPANY.ORG > } > COMPANYAWS.ORG = { > COMPANY.ORG = COMPANY.ORG > } > EAME.COMPANY.ORG = { > COMPANYAWS.ORG = COMPANY.ORG > } > COMPANYAWS.ORG = { > EAME.COMPANY.ORG = COMPANY.ORG > } > APAC.COMPANY.ORG = { > COMPANYAWS.ORG = COMPANY.ORG > } > COMPANYAWS.ORG = { > APAC.COMPANY.ORG = COMPANY.ORG > } > LATAM.COMPANY.ORG = { > COMPANYAWS.ORG = COMPANY.ORG > } > COMPANYAWS.ORG = { > LATAM.COMPANY.ORG = COMPANY.ORG > } > NAFTA.COMPANY.ORG = { > COMPANYAWS.ORG = COMPANY.ORG > } > COMPANYAWS.ORG = { > NAFTA.COMPANY.ORG = COMPANY.ORG > } > > > > > And this is domain_realm_companyidm_org: > ------------------------------------------------------------ > [domain_realm] > .COMPANY.ORG = COMPANY.ORG > COMPANY.ORG = COMPANY.ORG > .EAME.COMPANY.ORG = EAME.COMPANY.ORG > EAME.COMPANY.ORG = EAME.COMPANY.ORG > .APAC.COMPANY.ORG = APAC.COMPANY.ORG > APAC.COMPANY.ORG = APAC.COMPANY.ORG > .LATAM.COMPANY.ORG = LATAM.COMPANY.ORG > LATAM.COMPANY.ORG = LATAM.COMPANY.ORG > .NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG > NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG > [capaths] > COMPANYAWS.ORG = { > COMPANYIDM.ORG = COMPANYAWS.ORG > } > COMPANYIDM.ORG = { > COMPANYAWS.ORG = COMPANYAWS.ORG > } > COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > COMPANYIDM.ORG = { > COMPANY.ORG = COMPANY.ORG > } > EAME.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > COMPANYIDM.ORG = { > EAME.COMPANY.ORG = COMPANY.ORG > } > APAC.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > COMPANYIDM.ORG = { > APAC.COMPANY.ORG = COMPANY.ORG > } > LATAM.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > COMPANYIDM.ORG = { > LATAM.COMPANY.ORG = COMPANY.ORG > } > NAFTA.COMPANY.ORG = { > COMPANYIDM.ORG = COMPANY.ORG > } > COMPANYIDM.ORG = { > NAFTA.COMPANY.ORG = COMPANY.ORG > } Yes, you are right the capaths are wrong. Adding: [capaths] COMPANYAWS.ORG = { COMPANYIDM.ORG = COMPANYAWS.ORG } COMPANYIDM.ORG = { COMPANYAWS.ORG = COMPANYAWS.ORG COMPANY.ORG = COMPANY.ORG EAME.COMPANY.ORG = COMPANY.ORG APAC.COMPANY.ORG = COMPANY.ORG LATAM.COMPANY.ORG = COMPANY.ORG NAFTA.COMPANY.ORG = COMPANY.ORG } COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } EAME.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } APAC.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } LATAM.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } NAFTA.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } at the very beginning of /etc/krb5.conf before and include or includedir directives should fix it. With the broken configuration libkrb5 thinks that there direct trust between NAFTA.COMPANY.ORG and COMPANYIDM.ORG which is not the case, everything has to go via COMPANY.ORG because that's the domain which trusts COMPANYIDM.ORG. Updating SSSD to a version with the fix might help as well. HTH bye, Sumit From dag at sonsorol.org Thu Dec 8 16:37:25 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Thu, 08 Dec 2016 11:37:25 -0500 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <20161208163325.GF3013@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <5846F92E.3010900@sonsorol.org> <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58471CDD.8070703@sonsorol.org> <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58483A04.20000@sonsorol.org> <20161208083301.GC3013@p.Speedport_W_724V_Typ_A_05011603_00_009> <58496E4E.9040503@sonsorol.org> <20161208163325.GF3013@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <58498C45.5080403@sonsorol.org> Massive thank you; will test ASAP. We mainly have to support CentOS/RHEL-6 and CentOS/RHEL-7 clients. Is there any established guidance on upgrading SSSD in these environments? Some sort of trusted repo where RPMs are built? I can hit the wiki and website but figured I'd ask as well. Not sure what other dependencies the SSSD framework may have or pull in. Sumit Bose wrote: > } > > at the very beginning of /etc/krb5.conf before and include or includedir > directives should fix it. With the broken configuration libkrb5 thinks > that there direct trust between NAFTA.COMPANY.ORG and COMPANYIDM.ORG > which is not the case, everything has to go via COMPANY.ORG because > that's the domain which trusts COMPANYIDM.ORG. > > Updating SSSD to a version with the fix might help as well. > > HTH From mbasti at redhat.com Thu Dec 8 17:05:53 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 8 Dec 2016 18:05:53 +0100 Subject: [Freeipa-users] Removing DNS component In-Reply-To: <2b0f3893-c4a0-c3aa-fc31-8b47ae462ccc@pobox.com> References: <2b0f3893-c4a0-c3aa-fc31-8b47ae462ccc@pobox.com> Message-ID: <9b5b3cf9-22cd-19d9-8111-8fb8d9ea4e60@redhat.com> On 08.12.2016 12:01, Brian Candler wrote: > FreeIPA (4.2.0) was installed with the DNS component enabled, but I > want to pull this out. Is it possible to remove it and clean up the > records which were already there? > > e.g. is it sufficient just to delete everything under > cn=dns,dc=example,dc=com ? I notice there are bunch of permissions > entries in other parts of the tree which reference these with > ipaPermTarget, do they have to go too? > > Or would I have to re-install from scratch? > > Thanks, > > Brian. > Hello, I suggest to keep DNS tree there and all permissions, just remove all zones using IPA API and disable DNS service and dnssyncd service in LDAP, because removing DNS completely is unsupported and untested dn: cn=DNS,cn=vm-028.ipa.test,cn=masters,cn=ipa,cn=etc,$SUFFIX objectClass: ipaConfigObject objectClass: nsContainer objectClass: top ipaConfigString: startOrder 30 ipaConfigString: enabledService <--- remove this cn: DNS dn: cn=DNSKeySync,cn=vm-028.ipa.test,cn=masters,cn=ipa,$SUFFIX objectClass: nsContainer objectClass: top ipaConfigString: dnssecVersion 1 ipaConfigString: startOrder 110 ipaConfigString: enabledService <---- remove this cn: DNSKeySync It will keep ipa dns* command working but without any effect in case you *really* want to remove DNS completely, disable services ^, and revert everything added by https://github.com/freeipa/freeipa/blob/master/install/share/dns.ldif and https://github.com/freeipa/freeipa/blob/master/install/share/dnssec.ldif But unsupported, nobody knows what may happen. Martin From b.candler at pobox.com Thu Dec 8 19:55:30 2016 From: b.candler at pobox.com (Brian Candler) Date: Thu, 8 Dec 2016 19:55:30 +0000 Subject: [Freeipa-users] Removing DNS component In-Reply-To: <9b5b3cf9-22cd-19d9-8111-8fb8d9ea4e60@redhat.com> References: <2b0f3893-c4a0-c3aa-fc31-8b47ae462ccc@pobox.com> <9b5b3cf9-22cd-19d9-8111-8fb8d9ea4e60@redhat.com> Message-ID: <40d4cfab-80fb-3bc4-2ed5-97c7dde1afca@pobox.com> On 08/12/2016 17:05, Martin Basti wrote: > I suggest to keep DNS tree there and all permissions, just remove all > zones using IPA API and disable DNS service and dnssyncd service in > LDAP, because removing DNS completely is unsupported and untested > > dn: cn=DNS,cn=vm-028.ipa.test,cn=masters,cn=ipa,cn=etc,$SUFFIX > objectClass: ipaConfigObject > objectClass: nsContainer > objectClass: top > ipaConfigString: startOrder 30 > ipaConfigString: enabledService <--- remove this > cn: DNS > > > dn: cn=DNSKeySync,cn=vm-028.ipa.test,cn=masters,cn=ipa,$SUFFIX > objectClass: nsContainer > objectClass: top > ipaConfigString: dnssecVersion 1 > ipaConfigString: startOrder 110 > ipaConfigString: enabledService <---- remove this > cn: DNSKeySync > > It will keep ipa dns* command working but without any effect That did the job - nothing listening on port 53 now. Thank you! Regards, Brian. From william.muriithi at gmail.com Thu Dec 8 20:56:43 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 8 Dec 2016 15:56:43 -0500 Subject: [Freeipa-users] Intergrating vino or krfb to IPA server Message-ID: Hello, I am trying to see if either of the two desktop manager may be able to work with FreeIPA and I haven't had much luck. It seem like for example vino should be able to do so - see link below, but I haven't been able to do it or find article from those who have attemptd it before https://fedoraproject.org/wiki/Features/VirtVNCAuth Would be great if anybody in this list who have gone through such an expericence could share their experience. It doesn't need to be with vino or krfb specifically, but any VNC implementation that support physical console would be a great start Regards, William From kashmancy at gmail.com Thu Dec 8 21:15:53 2016 From: kashmancy at gmail.com (Harry Kashouli) Date: Thu, 8 Dec 2016 13:15:53 -0800 Subject: [Freeipa-users] Naming a FreeIPA domain and router differences Message-ID: Hi all, I want to make sure I'm understanding how to name my FreeIPA server. (following names are placeholders) On my router, I've set the domain to localdomain, so my server automatically gets the full name as server.localdomain. I want my FreeIPA domain to be domain.custom.com because I own the custom.com domain; so when I'm setting it up, I answer the "server host name" question as pc.domain.custom.com. Is this wrong? Does the domain on my router have to match the FreeIPA domain in any way? Thanks, -Harry -------------- next part -------------- An HTML attachment was scrubbed... URL: From kashmancy at gmail.com Thu Dec 8 21:40:17 2016 From: kashmancy at gmail.com (Harry Kashouli) Date: Thu, 8 Dec 2016 13:40:17 -0800 Subject: [Freeipa-users] Naming a FreeIPA domain and router differences In-Reply-To: References: Message-ID: Ah, I think I totally misread the DNS page, the first time... https://www.freeipa.org/page/DNS Looks like I should put the router on int.custom.com as a domain, and I can create the freeipa domain as domain.custom.com -Harry On 8 December 2016 at 13:15, Harry Kashouli wrote: > Hi all, > > I want to make sure I'm understanding how to name my FreeIPA server. > > (following names are placeholders) > On my router, I've set the domain to localdomain, so my server > automatically gets the full name as server.localdomain. I want my FreeIPA > domain to be domain.custom.com because I own the custom.com domain; so > when I'm setting it up, I answer the "server host name" question as > pc.domain.custom.com. > > Is this wrong? Does the domain on my router have to match the FreeIPA > domain in any way? > > Thanks, > -Harry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Fri Dec 9 02:28:32 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 8 Dec 2016 21:28:32 -0500 Subject: [Freeipa-users] (no subject) Message-ID: Hello I have indirect map that I would like to list the keys but from command line. I am able to see every key on the home directories map, but it display just names for the rest of the maps. Looking at the man page, I believe this would be my solution. -m, --dumpmaps [ ] With no parameters, list information about the configured automounter maps, then exit. If the dumpmaps option is given and is followed by two parameters, " " then simple "" pairs that would be read in by a map read are printed to stdout if the given map type and map name are found in the map configuration. My maps looks like this: Mount point: /projects source(s): lookup_nss_read_map: reading map sss auto.projects do_init: parse(sun): init gathered global options: (null) lookup_nss_read_map: reading map files auto.projects instance type(s): sss map: auto.projects quetzal | -fstype=autofs ldap:auto.projects-quetzal tercel | -fstype=autofs ldap:auto.projects-tercel After reading the above map page, I was hoping the below command would list keys on one of the projects map. It doesn't work though. automount --dumpmaps map autofs map tercel The info page isn't also any better. I wonder if someone can explain the use of these keys by an example. Would be very grateful " " Regards, William From rcritten at redhat.com Fri Dec 9 03:35:56 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 8 Dec 2016 22:35:56 -0500 Subject: [Freeipa-users] (no subject) In-Reply-To: References: Message-ID: <584A269C.7050908@redhat.com> William Muriithi wrote: > Hello > > I have indirect map that I would like to list the keys but from > command line. I am able to see every key on the home directories map, > but it display just names for the rest of the maps. > > Looking at the man page, I believe this would be my solution. > > -m, --dumpmaps [ ] > With no parameters, list information about the > configured automounter maps, then exit. > If the dumpmaps option is given and is followed by two > parameters, " " then simple "" pairs > that would be read in > by a map read are printed to stdout if the given map > type and map name are found in the map configuration. > > > > My maps looks like this: > > Mount point: /projects > > source(s): > lookup_nss_read_map: reading map sss auto.projects > do_init: parse(sun): init gathered global options: (null) > lookup_nss_read_map: reading map files auto.projects > > instance type(s): sss > map: auto.projects > quetzal | -fstype=autofs ldap:auto.projects-quetzal > tercel | -fstype=autofs ldap:auto.projects-tercel > > > After reading the above map page, I was hoping the below command would > list keys on one of the projects map. It doesn't work though. > > automount --dumpmaps map autofs map tercel > > The info page isn't also any better. I wonder if someone can explain > the use of these keys by an example. Would be very grateful > > " " You don't include "map" in the name of the thing. I think you want: automount --dumpmaps sss auto.projects rob From tk at mdevsys.com Fri Dec 9 07:53:06 2016 From: tk at mdevsys.com (TomK) Date: Fri, 9 Dec 2016 02:53:06 -0500 Subject: [Freeipa-users] Mapping users from AD to IPA KDC In-Reply-To: <20161206203735.l56lefuf5w5hye5t@redhat.com> References: <57881a32-60c5-9804-3695-34f3d7dbe718@mdevsys.com> <20161202134304.GK8701@p.Speedport_W_724V_Typ_A_05011603_00_009> <2c4ff955-ab05-80ea-f4ae-da217d21b285@mdevsys.com> <20161205070232.gnntt334q5siv3va@redhat.com> <1ee640af-4739-1e9b-bb49-c10601e6e08d@mdevsys.com> <20161206203735.l56lefuf5w5hye5t@redhat.com> Message-ID: <65f4c633-434d-bd78-cfb1-adef3a84fdad@mdevsys.com> On 12/6/2016 3:37 PM, Alexander Bokovoy wrote: > On ti, 06 joulu 2016, TomK wrote: >> On 12/5/2016 2:02 AM, Alexander Bokovoy wrote: >>> On su, 04 joulu 2016, TomK wrote: >>>> Could not get much from logs and decided to start fresh. When I run >>>> this: >>>> >>>> ipa trust-add --type=ad mds.xyz --admin Administrator --password >>>> >>>> Trust works fine and id tom at mds.xyz returns a valid result. >>>> >>>> However when I run the following on both masters on a fresh new setup: >>>> >>>> ipa-adtrust-install --netbios-name=NIX -a "" >>>> ipa trust-add --type=ad "mds.xyz" --trust-secret >>>> >>>> and created a trust object in AD DC with the name of NIX and a >>>> non-transitive trust, the above did NOT work. I didn't get anything >>>> by typing id tom at mds.xyz. (I do not get an option for a Forest Trust >>>> as the gif on this page suggests: >>>> https://www.freeipa.org/page/Active_Directory_trust_setup . Possibly >>>> it's Server 2012 hence the difference in what's presented to me but >>>> another reason is that the name I type for the trust can't resolve to >>>> an IP for now: nix.mds.xyz . So I use NIX to match the bios name used >>>> on the ipa-adtrust-install command above. ) >>> The shared secret case for one-way trust is known to be broken. When a >>> shared half is created on AD side first, it is marked as not yet valid >>> by Windows and currently we cannot perform validation of it from IPA >>> side. Validating it from AD side is not possible as well as we don't >>> provide all interfaces Windows would like to use. >>> >>> And the fact you cannot see 'Forest Trust' type of the trust says also >>> that you have problems with reaching IPA masters from AD DC side for >>> probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and >>> UDP). >> Nothing I tried in AD Trust creation allowed me to make one with type >> Forest. Just realm. I recall I had a trust type of Forest but in >> trying various options I lost how I did that. Or perhaps I hadn't >> payed attention and it got created indirectly as part of another >> action I took. The domain functional level I'm using is Windows >> Server 2008. Using a lower value for testing. > This (inability to chose Forest trust type) simply means AD DC is unable > to probe IPA DC. You said below that SMB port towards IPA DC was closed. > > Also make sure to remove incorrect trust from Windows side. While we are > removing a trust object named as our NetBIOS name, it only works for the > proper trusted domain/forests, not for wrong 'realm trust' type. > Removed the incorrect trust and recreated per your online pages. This time forest was visible. >> >> My IPA version is 4.2 right now. It came with the CentOS 7.2. >> Looking forward to 4.4. Not sure when you plan to include it as part >> of the latest CentOS base. Indeed some ports were not open (445). >> I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7: >> >> for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp >> 53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp >> 53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd >> --zone=public --permanent --add-port=$KEY; done >> >> [root at idmipa01 ~]# firewall-cmd --zone=public --list-all >> public (default) >> interfaces: >> sources: >> services: dhcpv6-client ntp ssh >> ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp >> 135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp >> 139/udp 138/udp 53/udp 636/tcp >> masquerade: no >> forward-ports: >> icmp-blocks: >> rich rules: >> >> [root at idmipa01 ~]# >> >> On Windows Side (The nslookup results were the same before the >> firewall change however.): > Firewall changes cannot affect DNS as you already had DNS port open. > >> On the AD side, I added the SRV records for the second AD DC, >> manually, since earlier there were no results printed on the AD DC >> command line for the second AD DC, when I typed the command >> _ldap._tcp.mds.xyz. >> >> One additional question I had with the setup is in regards to the >> failover. I see the ipa_server entry in /etc/sssd/sssd.conf pointing >> to two of the master IPA nodes. Where can I find the additional >> settings that control priority of the listed server or order they are >> checked? > You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections > FAILOVER and SERVICE DISCOVER. > >> What I ran to get the above is: >> >> 1) ipa-client-install --force-join -p admin -w "" >> --fixed-primary --server=idmipa01.nix.mds.xyz >> --server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ -U >> 2) realm join mds.xyz > This is wrong. You have effectively joined this IPA client to AD and IPA > at the same time. It should not be done this way (read > http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain > for details). > > Instead, you need to identify why the trust does not work properly. > Use tcpdump to intercept the traffic between your AD DCs and IPA DCs > while establishing the trust. > > You can send the trace to me off-list. > > > Sending you a document with the details. -- Cheers, Tom K. ------------------------------------------------------------------------------------- Living on earth is expensive, but it includes a free trip around the sun. From pspacek at redhat.com Fri Dec 9 07:56:59 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 9 Dec 2016 08:56:59 +0100 Subject: [Freeipa-users] Naming a FreeIPA domain and router differences In-Reply-To: References: Message-ID: On 8.12.2016 22:40, Harry Kashouli wrote: > Ah, I think I totally misread the DNS page, the first time... > https://www.freeipa.org/page/DNS > > > Looks like I should put the router on int.custom.com as a domain, and I can > create the freeipa domain as domain.custom.com It depends on you how you want to name the machines. FreeIPA does not care as long as requirements in the DNS page are met. Meeting the requirements is significantly easier when you use actual names you own as it mitigates risk of name collisions. If you have some specific question do not hesitate to ask. Petr^2 Spacek > > -Harry > > On 8 December 2016 at 13:15, Harry Kashouli wrote: > >> Hi all, >> >> I want to make sure I'm understanding how to name my FreeIPA server. >> >> (following names are placeholders) >> On my router, I've set the domain to localdomain, so my server >> automatically gets the full name as server.localdomain. I want my FreeIPA >> domain to be domain.custom.com because I own the custom.com domain; so >> when I'm setting it up, I answer the "server host name" question as >> pc.domain.custom.com. >> >> Is this wrong? Does the domain on my router have to match the FreeIPA >> domain in any way? >> >> Thanks, >> -Harry >> > > > -- Petr^2 Spacek From lslebodn at redhat.com Fri Dec 9 09:09:34 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 9 Dec 2016 10:09:34 +0100 Subject: [Freeipa-users] Problem with Free IPA Client Ubuntu Precise (12.04) authenticating with AD account In-Reply-To: <953139400.790469.1481213412430@mail.yahoo.com> References: <206623988.2535008.1481134746445.ref@mail.yahoo.com> <206623988.2535008.1481134746445@mail.yahoo.com> <20161208112248.GA15828@10.4.128.1> <953139400.790469.1481213412430@mail.yahoo.com> Message-ID: <20161209090933.GB12659@10.4.128.1> On (08/12/16 16:10), James Harrison wrote: >Hi,From this URL: https://launchpad.net/~sssd/+archive/ubuntu/updates >i updated sssd on Trusty and I can now ssh to it using a FreeIPA user's? credentials. AD Still doesn't work. >Thanks > That just mean that 1.12.5-1~trusty1 has still some bugs which are fixed in sssd-1.13.4 (in ubuntu 16.04). You mentioned that in different mail. I would recommend to use LTS version of sssd-1.13 which is the oldest version maintaned by upstream. You might file bugs to ubuntu for fixing old version of sssd in trusty (1.11) but it will be much simpler to ask for backporting 1.13.4 into launchpad. Based on ubuntu page[1] precise(12.04) will be EOL very soon you should really consider to use newer version The ideal would be to use ubuntu 16.04. LS [1] https://www.ubuntu.com/info/release-end-of-life From deepak_dimri at hotmail.com Fri Dec 9 10:52:01 2016 From: deepak_dimri at hotmail.com (Deepak Dimri) Date: Fri, 9 Dec 2016 10:52:01 +0000 Subject: [Freeipa-users] IPA Server & LDAP Replication Monitoring Message-ID: Hi All, Has any one worked on IPA server integration with collectd for its and LDAP replication? I am newbie to collectd and still exploring its plug-ins option. Would be thankful if some one can share some insight on it.. Thanks, Deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.candler at pobox.com Fri Dec 9 11:14:09 2016 From: b.candler at pobox.com (Brian Candler) Date: Fri, 9 Dec 2016 11:14:09 +0000 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> Message-ID: <49977f4b-008e-4bcb-d21d-f5922db40813@pobox.com> On 08/12/2016 08:50, Pieter Nagel wrote: > > Concrete scenario, I wonder if this will work: > > A greenfields deployment, no other kerberos, no Active Directory. > Internal DNS to be int.lautus.net and FreeIPA > manages that DNS domain and adds internal hosts to it as they enroll. > Public-facing servers are manually registered in lautus.net > DNS which is hosted elsewhere. But FreeIPA is > installed with realm LAUTUS.NET so it adds > _kerberos entries for realm LAUTUS.NET to > int.lautus.net , and I manually copy those > entries to lautus.net , so everone agrees that they > belong to the same realm. > > The reason I want the realm to be LAUTUS.NET is > because it makes more sense to me that the internal desktops in the > subdomain int.lautus.net to enroll into a > realm related to the parent DNS domain I see a red flag with "desktops". Do you mean Windows desktops? Then you are talking Active Directory (or the Samba implementation of AD) and there are very specific rules for how the hostnames and the realms interact. If you are talking Linux/BSD desktops, then it doesn't matter. Personally I would do it the other way round than you propose: let machines foo.lautus.net and bar.int.lautus.net use IPA.LAUTUS.NET as their kerberos realm, because this gives you the *option* of adding a distinct kerberos realm like AD.LAUTUS.NET later. If you ever introduce Active Directory into your network then you don't want it to be either a subdomain or a parent domain of your IPA domain, unless you enjoy pain. Changing your IPA realm later is also extremely painful. > , than it makes sense for the public-facing servers in the parent > lautus.net domain enroll into a realm related to > an internal DNS subdomain. It's not really a problem. In the DNS you create TXT records: _kerberos.lautus.net. TXT "IPA.LAUTUS.NET" _kerberos.int.lautus.net TXT "IPA.LAUTUS.NET" and the auto-mapping of hosts to realms just works (in the *nix world anyway) Personally I would have no problem publishing _kerberos.lautus.net. TXT "IPA.LAUTUS.NET" in the public DNS. It's up to you whether you put *.ipa.lautus.net and *.int.lautus.net in the public DNS. > Or am I making an issue of a cosmetic triviality, and it is not all > all strange in the kerberos realm to enroll a server into a realm > related to a DNS subdomain it is not part of? > In my opinion, not at all strange. You have three things: 1. The DNS domain of the host 2. The Kerberos realm that the host is in 3. The DNS domain of the Kerberos realm 2+3 are bound together, but 1 does not need to relate to 2+3 (unless you are Microsoft) Regards, Brian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Dec 9 11:52:48 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 9 Dec 2016 13:52:48 +0200 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: <49977f4b-008e-4bcb-d21d-f5922db40813@pobox.com> References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> <49977f4b-008e-4bcb-d21d-f5922db40813@pobox.com> Message-ID: <20161209115248.c776ja75mcyfsjpv@redhat.com> On pe, 09 joulu 2016, Brian Candler wrote: >On 08/12/2016 08:50, Pieter Nagel wrote: >> >>Concrete scenario, I wonder if this will work: >> >>A greenfields deployment, no other kerberos, no Active Directory. >>Internal DNS to be int.lautus.net and >>FreeIPA manages that DNS domain and adds internal hosts to it as >>they enroll. Public-facing servers are manually registered in >>lautus.net DNS which is hosted elsewhere. But >>FreeIPA is installed with realm LAUTUS.NET so it >>adds _kerberos entries for realm LAUTUS.NET to >>int.lautus.net , and I manually copy those >>entries to lautus.net , so everone agrees that >>they belong to the same realm. >> >>The reason I want the realm to be LAUTUS.NET is >>because it makes more sense to me that the internal desktops in the >>subdomain int.lautus.net to enroll into a >>realm related to the parent DNS domain >I see a red flag with "desktops". Do you mean Windows desktops? Then >you are talking Active Directory (or the Samba implementation of AD) >and there are very specific rules for how the hostnames and the realms >interact. > >If you are talking Linux/BSD desktops, then it doesn't matter. >Personally I would do it the other way round than you propose: let >machines foo.lautus.net and bar.int.lautus.net use IPA.LAUTUS.NET as >their kerberos realm, because this gives you the *option* of adding a >distinct kerberos realm like AD.LAUTUS.NET later. > >If you ever introduce Active Directory into your network then you >don't want it to be either a subdomain or a parent domain of your IPA >domain, unless you enjoy pain. This is not a big deal, really. Red Hat customers routinely deploy IPA as a subdomain or a parent domain to Active Directory deployments. >Changing your IPA realm later is also extremely painful. Right now there is no a procedure to do so. Partially because realm name is part of the salt used by Kerberos hashes. >>, than it makes sense for the public-facing servers in the parent >>lautus.net domain enroll into a realm related to >>an internal DNS subdomain. >It's not really a problem. In the DNS you create TXT records: > >_kerberos.lautus.net. TXT "IPA.LAUTUS.NET" >_kerberos.int.lautus.net TXT "IPA.LAUTUS.NET" > >and the auto-mapping of hosts to realms just works (in the *nix world >anyway) Correct. Windows systems don't request _kerberos TXT record at all. >Personally I would have no problem publishing >_kerberos.lautus.net. TXT "IPA.LAUTUS.NET" >in the public DNS. It's up to you whether you put *.ipa.lautus.net and >*.int.lautus.net in the public DNS. > >>Or am I making an issue of a cosmetic triviality, and it is not all >>all strange in the kerberos realm to enroll a server into a realm >>related to a DNS subdomain it is not part of? >> >In my opinion, not at all strange. You have three things: > >1. The DNS domain of the host >2. The Kerberos realm that the host is in >3. The DNS domain of the Kerberos realm > >2+3 are bound together, but 1 does not need to relate to 2+3 (unless >you are Microsoft) Even in Microsoft world there are means to add DNS domains to the same Active Directory domain (they are called name routing suffixes). They aren't flexible enough though and you are not advised to create many of them (to the tune of thousands) because they are checked every time a Kerberos ticket is issued by the AD DC. -- / Alexander Bokovoy From sbose at redhat.com Fri Dec 9 12:17:24 2016 From: sbose at redhat.com (Sumit Bose) Date: Fri, 9 Dec 2016 13:17:24 +0100 Subject: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts In-Reply-To: <58498C45.5080403@sonsorol.org> References: <5846F92E.3010900@sonsorol.org> <20161206180211.GI22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58471CDD.8070703@sonsorol.org> <20161207101148.GJ22795@p.Speedport_W_724V_Typ_A_05011603_00_009> <58483A04.20000@sonsorol.org> <20161208083301.GC3013@p.Speedport_W_724V_Typ_A_05011603_00_009> <58496E4E.9040503@sonsorol.org> <20161208163325.GF3013@p.Speedport_W_724V_Typ_A_05011603_00_009> <58498C45.5080403@sonsorol.org> Message-ID: <20161209121724.GL3013@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, Dec 08, 2016 at 11:37:25AM -0500, Chris Dagdigian wrote: > > Massive thank you; will test ASAP. > > We mainly have to support CentOS/RHEL-6 and CentOS/RHEL-7 clients. Is there > any established guidance on upgrading SSSD in these environments? Some sort > of trusted repo where RPMs are built? I can hit the wiki and website but > figured I'd ask as well. Not sure what other dependencies the SSSD framework > may have or pull in. You might want to have a look at https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/ . Lukas is doing a great job here in providing test-builds of the latest versions release in Fedora for other/older platforms. But please note those are test-build. You have to wait until CentOS release the 7.3 packages to have an 'official' sssd-1.14 build. HTH bye, Sumit > > Sumit Bose wrote: > > } > > > > at the very beginning of /etc/krb5.conf before and include or includedir > > directives should fix it. With the broken configuration libkrb5 thinks > > that there direct trust between NAFTA.COMPANY.ORG and COMPANYIDM.ORG > > which is not the case, everything has to go via COMPANY.ORG because > > that's the domain which trusts COMPANYIDM.ORG. > > > > Updating SSSD to a version with the fix might help as well. > > > > HTH > From sbingram at gmail.com Fri Dec 9 21:56:01 2016 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 9 Dec 2016 13:56:01 -0800 Subject: [Freeipa-users] Kerberos realm for different domain Message-ID: Can you have a domain that belongs to a Kerberos realm with a completely different domain? For example, could example.com belong to the ANOTHERDOMAIN.COM realm as long as we control DNS for both and have all the necessary SRV and TXT records to locate it and krb5.conf is configured properly? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Sat Dec 10 17:44:26 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Sat, 10 Dec 2016 12:44:26 -0500 Subject: [Freeipa-users] (no subject) In-Reply-To: <584A269C.7050908@redhat.com> References: <584A269C.7050908@redhat.com> Message-ID: Hello Rob, Thanks >> After reading the above map page, I was hoping the below command would >> list keys on one of the projects map. It doesn't work though. >> >> automount --dumpmaps map autofs map tercel >> >> The info page isn't also any better. I wonder if someone can explain >> the use of these keys by an example. Would be very grateful >> >> " " > > You don't include "map" in the name of the thing. I think you want: > > automount --dumpmaps sss auto.projects > Thanks, this indeed is working. Thanks for clarifying the man page. Its however not listing any keys on map created as child to master using the flag below. --parentmap=auto.master This seem like a bug. Could this be a corner case that was missed? Thanks again Regards, William > From william.muriithi at gmail.com Sat Dec 10 17:50:36 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Sat, 10 Dec 2016 12:50:36 -0500 Subject: [Freeipa-users] Kerberos realm for different domain Message-ID: Stephen > > Can you have a domain that belongs to a Kerberos realm with a completely > different domain? For example, could example.com belong to the > ANOTHERDOMAIN.COM realm as long as we control DNS for both and have all the > necessary SRV and TXT records to locate it and krb5.conf is configured > properly? This will indeed work. Its however highly discouraged by FreeIPA. For example, if you do go this way, you will never be able to establish trust relationship with Active directory as Active directory will not accept this setup. Also, you will be on untested territory. I don't think may people use this setup, so the code may not be well exercised in such a setup. On the positive side, you could help FreeIPA project flash out any bug that such a setup may expose. Regards, William From abokovoy at redhat.com Sat Dec 10 18:20:33 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 10 Dec 2016 20:20:33 +0200 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: References: Message-ID: <20161210182033.gylow3y3gemkinfj@redhat.com> On la, 10 joulu 2016, William Muriithi wrote: >Stephen >> >> Can you have a domain that belongs to a Kerberos realm with a completely >> different domain? For example, could example.com belong to the >> ANOTHERDOMAIN.COM realm as long as we control DNS for both and have all the >> necessary SRV and TXT records to locate it and krb5.conf is configured >> properly? > >This will indeed work. Its however highly discouraged by FreeIPA. No, it is not. >For example, if you do go this way, you will never be able to >establish trust relationship with Active directory as Active directory >will not accept this setup. This is not true at all. >Also, you will be on untested territory. I don't think may people use >this setup, so the code may not be well exercised in such a setup. On >the positive side, you could help FreeIPA project flash out any bug >that such a setup may expose. No, this is very well charted territory. Read a number of threads we had just last week and before, last few months. In short, the situation Stephen asks an advice on is a very normal case. -- / Alexander Bokovoy From rcritten at redhat.com Sun Dec 11 01:52:06 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 10 Dec 2016 20:52:06 -0500 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <584A269C.7050908@redhat.com> Message-ID: <584CB146.3080602@redhat.com> William Muriithi wrote: > Hello Rob, > > Thanks > >>> After reading the above map page, I was hoping the below command would >>> list keys on one of the projects map. It doesn't work though. >>> >>> automount --dumpmaps map autofs map tercel >>> >>> The info page isn't also any better. I wonder if someone can explain >>> the use of these keys by an example. Would be very grateful >>> >>> " " >> >> You don't include "map" in the name of the thing. I think you want: >> >> automount --dumpmaps sss auto.projects >> > Thanks, this indeed is working. Thanks for clarifying the man page. > Its however not listing any keys on map created as child to master > using the flag below. > --parentmap=auto.master > > This seem like a bug. Could this be a corner case that was missed? Hard to say without seeing your maps and keys. You could run `ipa automountlocation-tofiles default` to see what IPA thinks things look like. rob From william.muriithi at gmail.com Sun Dec 11 14:51:03 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Sun, 11 Dec 2016 09:51:03 -0500 Subject: [Freeipa-users] (no subject) In-Reply-To: <584CB146.3080602@redhat.com> References: <584A269C.7050908@redhat.com> <584CB146.3080602@redhat.com> Message-ID: Hi Rob, > > >> automount --dumpmaps sss auto.projects > >> > > Thanks, this indeed is working. Thanks for clarifying the man page. > > Its however not listing any keys on map created as child to master > > using the flag below. > > --parentmap=auto.master > > > > This seem like a bug. Could this be a corner case that was missed? > > Hard to say without seeing your maps and keys. > > You could run `ipa automountlocation-tofiles default` to see what IPA > thinks things look like. > I had checked with the above command a two weeks ago and indeed have a better result that way. Also, though I added the maps using a script (cli interface), I do see them displayed correctly and nicely on the FreeIPA GUI. Finally, they do seem to work fine as I haven't heard issue with the maps for the last 4 weeks we have been using this setup. We had them initially on the file and only migrated then to LDAP recently. Its after this migration that I noticed that some script that used to parse the auto maps as a files are now broken and have been attempting to fix then since. Regards, William From pspacek at redhat.com Mon Dec 12 07:15:25 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 12 Dec 2016 08:15:25 +0100 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: <20161210182033.gylow3y3gemkinfj@redhat.com> References: <20161210182033.gylow3y3gemkinfj@redhat.com> Message-ID: <4afb3008-b2cd-9549-e3cb-0d24bceec308@redhat.com> On 10.12.2016 19:20, Alexander Bokovoy wrote: > On la, 10 joulu 2016, William Muriithi wrote: >> Stephen >>> >>> Can you have a domain that belongs to a Kerberos realm with a completely >>> different domain? For example, could example.com belong to the >>> ANOTHERDOMAIN.COM realm as long as we control DNS for both and have all the >>> necessary SRV and TXT records to locate it and krb5.conf is configured >>> properly? >> >> This will indeed work. Its however highly discouraged by FreeIPA. > No, it is not. > >> For example, if you do go this way, you will never be able to >> establish trust relationship with Active directory as Active directory >> will not accept this setup. > This is not true at all. > >> Also, you will be on untested territory. I don't think may people use >> this setup, so the code may not be well exercised in such a setup. On >> the positive side, you could help FreeIPA project flash out any bug >> that such a setup may expose. > No, this is very well charted territory. Read a number of threads we had > just last week and before, last few months. > > In short, the situation Stephen asks an advice on is a very normal case. Let me clear up this confusion: The important thing is to have Kerberos REALM = uppercase version of DNS domain containing all the SRV records (let's call this DNS domain "primary" DNS domain). If this condition is fulfilled, AD trusts and other auto-detection procedures will work. You can add arbitrary number of FreeIPA clients to "secondary" DNS domains as long as they do not overlap with AD-managed domains and it will just work. Does it clear the confusion? -- Petr^2 Spacek From dkupka at redhat.com Mon Dec 12 07:31:50 2016 From: dkupka at redhat.com (David Kupka) Date: Mon, 12 Dec 2016 08:31:50 +0100 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: References: Message-ID: <65e8d18c-7c5f-4f82-57cb-8aa6069db84c@redhat.com> On 09/12/16 22:56, Stephen Ingram wrote: > Can you have a domain that belongs to a Kerberos realm with a completely > different domain? For example, could example.com belong to the > ANOTHERDOMAIN.COM realm as long as we control DNS for both and have all the > necessary SRV and TXT records to locate it and krb5.conf is configured > properly? > > Steve > > > Hello Steve, yes you can do it. DNS domain and Kerberos realm are two different things. It's common and AFAIK recommended to capitalize DNS domain to get the realm but it's not required. If you really want to have them different make sure: a) anotherdomain.com is under your control, b) you don't already have other Kerberos instance (FreeIPA, MIT KRB5, MS AD, ...) with ANOTHERDOMAIN.COM realm deployed. With FreeIPA you can run # ipa-server-install --domain example.com --realm ANOTHERDOMAIN.COM But before you do, why do you want to have the realm different from the domain? -- David Kupka From simo at redhat.com Mon Dec 12 10:04:50 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 12 Dec 2016 05:04:50 -0500 Subject: [Freeipa-users] Change in list archives accessibility Message-ID: <1481537090.7156.19.camel@redhat.com> Dear freeipa-users, in an attempt to identify how the recent wave of spamming activity targets mailing list posters, I have temporarily disabled free access to the archives. This is not a permanent change and public access will be restored shortly. Regards, Simo. -- Simo Sorce * Red Hat, Inc * New York From rob.verduijn at gmail.com Mon Dec 12 19:53:16 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 12 Dec 2016 20:53:16 +0100 Subject: [Freeipa-users] ipa fails to start after centos 7.3 upgrade Message-ID: Hello, I've recently upgraded to centos 7.3. Didn't intend to so soon but should have checked the anounce lists before launching my ansible update playbook. Most of my servers came through, and mostly also the ipa server. There were duplicate rpms and a failed rpm upgrade. After some yum magic the rpm duplicates where gone and all the updates installed. Manually running ipa-server-upgrade also seems to finish properly. However ipactl start keeps failing on the ntpd service. Not a big surprise since its running chronyd. I now start the ipa server with 'ipactl start --ignore-service-failure' Is there a way to explain the script that it should check for chronyd instead of ntpd ? I also see this a lot in the logs: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type Is that a serious error ? Rob Verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From titleistfour at gmail.com Mon Dec 12 21:32:02 2016 From: titleistfour at gmail.com (jay) Date: Mon, 12 Dec 2016 15:32:02 -0600 Subject: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails Message-ID: Hello, I have been testing freeipa on CentOS 7 for a while now with a relatively simple setup, just a single server and 12 or so Linux clients in AWS. I went to rebuild the environment today and part of my Ansible playbook failed with this error ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (503) This is the command that failed /usr/bin/ipa cert-show 1 --out=/root/cacert.crt I noticed the version I was using on Friday was ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64. But now I'm getting ipa-server-4.4.0-14.el7.centos.x86_64 installed, so the repo was updated over the weekend. Is there a known issue running cert-show with this version? I can't find anything in the debug logs that point to something wrong. Running 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n ipaCert' work just fine. Can someone offer some advice or pointer to what might be going on? I'm invoking the install with these options and it has worked flawlessly before this new version 2016-12-12T21:05:21Z DEBUG ipa-server-install was invoked with arguments [] and options: {'no_dns_ sshfp': None, 'ignore_topology_disconnect': None, 'verbose': False, 'ip_addresses': [CheckedIPAddr ess('172.31.0.235')], 'domainlevel': None, 'mkhomedir': None, 'http_cert_files': None, 'no_ntp': N one, 'reverse_zones': None, 'no_forwarders': None, 'external_ca_type': None, 'ssh_trust_dns': True , 'domain_name': 'ipa.us-west-2.compute.internal', 'idmax': None, 'http_cert_name': None, 'dirsrv_ cert_files': None, 'no_dnssec_validation': None, 'ca_signing_algorithm': None, 'no_reverse': None, 'subject': None, 'unattended': True, 'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns' : None, 'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role': None, 'realm_name': 'IPA.U S-WEST-2.COMPUTE.INTERNAL', 'forwarders': [CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte rnal_ca': None, 'no_ssh': None, 'external_cert_files': None, 'no_hbac_allow': None, 'forward_polic y': None, 'dirsrv_cert_name': None, 'ca_cert_files': None, 'zonemgr': None, 'quiet': False, 'setup _dns': True, 'host_name': 'ip-172-31-0-235.us-west-2.compute.internal', 'dirsrv_config_file': None , 'log_file': None, 'allow_zone_overlap': None, 'uninstall': False} 2016-12-12T21:05:21Z DEBUG IPA version 4.4.0-14.el7.centos Thank you Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From beeth2006 at gmail.com Tue Dec 13 04:44:45 2016 From: beeth2006 at gmail.com (beeth beeth) Date: Mon, 12 Dec 2016 23:44:45 -0500 Subject: [Freeipa-users] Failed ipa-client-install with IPA Replica Message-ID: I have two IPA servers ipaprd1.example.com and ipaprd2.example.com, running ipa 4.4 on RHEL7. When I tried to install/configure the client on a RHEL6 system(called ipadev6), I had issue when I tried to enroll it with the replica(ipaprd2), while no issue with the primary(ipaprd1): # ipa-client-install --domain=ipa.example.com --server=ipaprd1.example.com --server=ipaprd2.example.com --hostname=ipadev6.example.com LDAP Error: Protocol error: unsupported extended operation Autodiscovery of servers for failover cannot work with this configuration. If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Proceed with fixed values and no DNS discovery? [no] Then I tried to run ipa-client-install to enroll with the replica(ipaprd2), with debug mode, I got this: # ipa-client-install --domain=ipa.example.com --server=ipaprd2.example.com --hostname=ipadev6.example.com -d /usr/sbin/ipa-client-install was invoked with options: {'domain': ' ipa.example.com', 'force': False, 'realm_name': None, 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'on_master': False, 'ntp_server': None, 'nisdomain': None, 'no_nisdomain': False, 'principal': None, 'hostname': 'ipadev6.example.com', 'no_ac': False, 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'kinit_attempts': 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True, 'force_join': False, 'ca_cert_file': None, 'server': ['ipaprd2.example.com'], 'prompt_password': False, 'permit': False, 'debug': True, 'preserve_sssd': False, 'uninstall': False} missing options might be asked for interactively later Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' [IPA Discovery] Starting IPA discovery with domain=ipa.example.com, servers=[' ipaprd2.example.com'], hostname=ipadev6.example.com Server and domain forced [Kerberos realm search] Search DNS for TXT record of _kerberos.ipa.example.com. No DNS record found Search DNS for SRV record of _kerberos._udp.ipa.example.com. No DNS record found SRV record for KDC not found! Domain: ipa.example.com [LDAP server check] Verifying that ipaprd2.example.com (realm None) is an IPA server Init LDAP connection with: ldap://ipaprd2.example.com:389 LDAP Error: Protocol error: unsupported extended operation Discovery result: UNKNOWN_ERROR; server=None, domain=ipa.example.com, kdc=None, basedn=None Validated servers: will use discovered domain: ipa.example.com IPA Server not found [IPA Discovery] Starting IPA discovery with domain=ipa.example.com, servers=[' ipaprd2.example.com'], hostname=ipadev6.example.com Server and domain forced [Kerberos realm search] Search DNS for TXT record of _kerberos.ipa.example.com. No DNS record found Search DNS for SRV record of _kerberos._udp.ipa.example.com. No DNS record found SRV record for KDC not found! Domain: ipa.example.com [LDAP server check] Verifying that ipaprd2.example.com (realm None) is an IPA server Init LDAP connection with: ldap://ipaprd2.example.com:389 LDAP Error: Protocol error: unsupported extended operation Discovery result: UNKNOWN_ERROR; server=None, domain=ipa.example.com, kdc=None, basedn=None Validated servers: Failed to verify that ipaprd2.example.com is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) (ipaprd2.example.com: Provided as option) Installation failed. Rolling back changes. IPA client is not configured on this system. I double checked the services running on the replica, all looked well: ports are listening, and I could telnet the ports from the client(ipadev6). I could run "ldapserach" command to talk to the replica(ipaprd2) from this client(ipadev6), with pulling out all the LDAP records. Also, I have another test box running RHEL7, and no issue at all to run the exact same ipa-client-install command on that RHEL7 box. So could there be a bug on the ipa-client software on RHEL6, to talk to IPA sever running on RHEL7? Please advise. Thank you! Best regards, Beeth -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Tue Dec 13 06:52:42 2016 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 12 Dec 2016 22:52:42 -0800 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: <65e8d18c-7c5f-4f82-57cb-8aa6069db84c@redhat.com> References: <65e8d18c-7c5f-4f82-57cb-8aa6069db84c@redhat.com> Message-ID: On Sun, Dec 11, 2016 at 11:31 PM, David Kupka wrote: > > yes you can do it. DNS domain and Kerberos realm are two different things. > It's common and AFAIK recommended to capitalize DNS domain to get the realm > but it's not required. > If you really want to have them different make sure: > a) anotherdomain.com is under your control, > b) you don't already have other Kerberos instance (FreeIPA, MIT KRB5, MS > AD, ...) with ANOTHERDOMAIN.COM realm > deployed. > > With FreeIPA you can run > # ipa-server-install --domain example.com --realm ANOTHERDOMAIN.COM > > > But before you do, why do you want to have the realm different from the > domain? David- We have multiple domains that we want to manage under one Kerberos realm. I see that's it's possible for FreeIPA to manage multiple realms, but, for simplicity, I'd rather use just one and have all domains underneath: REALM.COM controls example1.com, example2.com, example3.com, etc. Since we control all domain's DNS, we would create text records for each of the example{x}.com domains pointing to REALM.COM Kerberos realm. We would also create SRV records for each of the example{x}.com domains directing Kerberos lookups to REALM.COM. I know it's a little unorthodox, but I'd like to do it so we can keep everything in one easily managed lot. Steve P.S. I got several pornny spammy replies to this message. Is someone sneaking into this list somehow? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Tue Dec 13 07:33:12 2016 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 13 Dec 2016 10:33:12 +0300 Subject: [Freeipa-users] From where can i get latest IPA repo for centos Message-ID: HI List, >From where can i get latest IPA repo for centos. the repo which i was using on copr is not working now. please anyone help me to sort it out. Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Dec 13 07:52:56 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 13 Dec 2016 09:52:56 +0200 Subject: [Freeipa-users] From where can i get latest IPA repo for centos In-Reply-To: References: Message-ID: <20161213075255.jwnlpfgvhctrzngp@redhat.com> On ti, 13 joulu 2016, Ben .T.George wrote: >HI List, > >>From where can i get latest IPA repo for centos. the repo which i was using >on copr is not working now. > >please anyone help me to sort it out. CentOS 7.3 was pushed out to public over weekend. The most recent IPA version there is 4.4. -- / Alexander Bokovoy From flo at redhat.com Tue Dec 13 07:56:05 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 13 Dec 2016 08:56:05 +0100 Subject: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails In-Reply-To: References: Message-ID: <54dd53a6-69b3-5b08-9add-530d411d8e28@redhat.com> On 12/12/2016 10:32 PM, jay wrote: > Hello, > > I have been testing freeipa on CentOS 7 for a while now with a > relatively simple setup, just a single server and 12 or so Linux clients > in AWS. I went to rebuild the environment today and part of my Ansible > playbook failed with this error > > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (503) > > This is the command that failed > > /usr/bin/ipa cert-show 1 --out=/root/cacert.crt > > I noticed the version I was using on Friday was > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64. But now I'm getting > ipa-server-4.4.0-14.el7.centos.x86_64 installed, so the repo was updated > over the weekend. > > Is there a known issue running cert-show with this version? I can't > find anything in the debug logs that point to something wrong. Running > 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n ipaCert' work > just fine. > > Can someone offer some advice or pointer to what might be going on? I'm > invoking the install with these options and it has worked flawlessly > before this new version > > 2016-12-12T21:05:21Z DEBUG ipa-server-install was invoked with arguments > [] and options: {'no_dns_ > sshfp': None, 'ignore_topology_disconnect': None, 'verbose': False, > 'ip_addresses': [CheckedIPAddr > ess('172.31.0.235')], 'domainlevel': None, 'mkhomedir': None, > 'http_cert_files': None, 'no_ntp': N > one, 'reverse_zones': None, 'no_forwarders': None, 'external_ca_type': > None, 'ssh_trust_dns': True > , 'domain_name': 'ipa.us-west-2.compute.internal', 'idmax': None, > 'http_cert_name': None, 'dirsrv_ > cert_files': None, 'no_dnssec_validation': None, 'ca_signing_algorithm': > None, 'no_reverse': None, > 'subject': None, 'unattended': True, 'auto_reverse': None, > 'auto_forwarders': None, 'no_host_dns' > : None, 'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role': > None, 'realm_name': 'IPA.U > S-WEST-2.COMPUTE.INTERNAL', 'forwarders': > [CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte > rnal_ca': None, 'no_ssh': None, 'external_cert_files': None, > 'no_hbac_allow': None, 'forward_polic > y': None, 'dirsrv_cert_name': None, 'ca_cert_files': None, 'zonemgr': > None, 'quiet': False, 'setup > _dns': True, 'host_name': 'ip-172-31-0-235.us-west-2.compute.internal', > 'dirsrv_config_file': None > , 'log_file': None, 'allow_zone_overlap': None, 'uninstall': False} > 2016-12-12T21:05:21Z DEBUG IPA version 4.4.0-14.el7.centos > > Thank you > Jay > > Hi, the ipa cert-show command is communicating with Dogtag, using port 443. Can you check if Dogtag is properly responding on this port? $ SSL_DIR=/etc/httpd/alias/ curl -v -E ipaCert:`cat /etc/httpd/alias/pwdfile.txt` https://hostname.domainname:443/ca/agent/ca/displayBySerial?serialNumber=1 -o out.html The issue can be that Dogtag is down, or a SSL issue (the certificate ipaCert in /etc/httpd/alias is used to authenticate the client to Dogtag). HTH, Flo. From dkupka at redhat.com Tue Dec 13 09:11:45 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 13 Dec 2016 10:11:45 +0100 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: References: <65e8d18c-7c5f-4f82-57cb-8aa6069db84c@redhat.com> Message-ID: On 13/12/16 07:52, Stephen Ingram wrote: > On Sun, Dec 11, 2016 at 11:31 PM, David Kupka wrote: > >> >> yes you can do it. DNS domain and Kerberos realm are two different things. >> It's common and AFAIK recommended to capitalize DNS domain to get the realm >> but it's not required. >> If you really want to have them different make sure: >> a) anotherdomain.com is under your control, >> b) you don't already have other Kerberos instance (FreeIPA, MIT KRB5, MS >> AD, ...) with ANOTHERDOMAIN.COM realm >> deployed. >> >> With FreeIPA you can run >> # ipa-server-install --domain example.com --realm ANOTHERDOMAIN.COM >> >> >> But before you do, why do you want to have the realm different from the >> domain? > > > David- > > We have multiple domains that we want to manage under one Kerberos realm. I > see that's it's possible for FreeIPA to manage multiple realms, but, for > simplicity, I'd rather use just one and have all domains underneath: > > REALM.COM > controls example1.com, example2.com, example3.com, etc. > > Since we control all domain's DNS, we would create text records for each of > the example{x}.com domains pointing to REALM.COM Kerberos realm. We would > also create SRV records for each of the example{x}.com domains directing > Kerberos lookups to REALM.COM. I know it's a little unorthodox, but I'd > like to do it so we can keep everything in one easily managed lot. > > Steve > > P.S. I got several pornny spammy replies to this message. Is someone > sneaking into this list somehow? > Hello Steve, in fact it's not possible to manage multiple Kerberos realms in one FreeIPA deployment. And judging from your description it also isn't what you want. On the other hand, having one realm and multiple DNS domains is standard situation and usually the name of the realm is derived from the primary domain (e.g. the one that matches organization name). If all your domains are equal just pick the one that you're most sure you'll keep under your control. Regarding the spamming problem, we're all receiving it and the main problem is that the spam is not targeting freeipa-users@ list but the individual addresses in conversations. There's not much we can do but Simo is trying to find a solution. -- David Kupka From peljasz at yahoo.co.uk Tue Dec 13 11:14:17 2016 From: peljasz at yahoo.co.uk (lejeczek) Date: Tue, 13 Dec 2016 11:14:17 +0000 Subject: [Freeipa-users] ipa.p11-kit: Permission denied Message-ID: hi all I see this when I restart httpd: [Tue Dec 13 10:26:06.945668 2016] [core:notice] [pid 47548] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' p11-kit: couldn't open and map file: /etc/pki/ca-trust/source/ipa.p11-kit: Permission denied p11-kit: couldn't open and map file: /etc/pki/ca-trust/source/ipa.p11-kit: Permission denied ... and I wonder if it has something to do with IPA? And if yes then is it critical? IPA seems to work normal. many thanks, L. From bentech4you at gmail.com Tue Dec 13 12:44:15 2016 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 13 Dec 2016 15:44:15 +0300 Subject: [Freeipa-users] How to disable First time password change on IPA user Message-ID: HI How to disable first time password change on newly created user from web UI Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Tue Dec 13 13:46:32 2016 From: dkupka at redhat.com (David Kupka) Date: Tue, 13 Dec 2016 14:46:32 +0100 Subject: [Freeipa-users] Failed ipa-client-install with IPA Replica In-Reply-To: References: Message-ID: <794d723f-9994-2281-1add-c5d0d1167257@redhat.com> On 13/12/16 05:44, beeth beeth wrote: > I have two IPA servers ipaprd1.example.com and ipaprd2.example.com, running > ipa 4.4 on RHEL7. When I tried to install/configure the client on a RHEL6 > system(called ipadev6), I had issue when I tried to enroll it with the > replica(ipaprd2), while no issue with the primary(ipaprd1): > > # ipa-client-install --domain=ipa.example.com --server=ipaprd1.example.com > --server=ipaprd2.example.com --hostname=ipadev6.example.com > LDAP Error: Protocol error: unsupported extended operation > Autodiscovery of servers for failover cannot work with this configuration. > If you proceed with the installation, services will be configured to always > access the discovered server for all operations and will not fail over to > other servers in case of failure. > Proceed with fixed values and no DNS discovery? [no] > > Then I tried to run ipa-client-install to enroll with the replica(ipaprd2), > with debug mode, I got this: > > # ipa-client-install --domain=ipa.example.com --server=ipaprd2.example.com > --hostname=ipadev6.example.com -d > /usr/sbin/ipa-client-install was invoked with options: {'domain': ' > ipa.example.com', 'force': False, 'realm_name': None, > 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir': False, > 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'on_master': > False, 'ntp_server': None, 'nisdomain': None, 'no_nisdomain': False, > 'principal': None, 'hostname': 'ipadev6.example.com', 'no_ac': False, > 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'kinit_attempts': > 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True, 'force_join': > False, 'ca_cert_file': None, 'server': ['ipaprd2.example.com'], > 'prompt_password': False, 'permit': False, 'debug': True, 'preserve_sssd': > False, 'uninstall': False} > missing options might be asked for interactively later > Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' > [IPA Discovery] > Starting IPA discovery with domain=ipa.example.com, servers=[' > ipaprd2.example.com'], hostname=ipadev6.example.com > Server and domain forced > [Kerberos realm search] > Search DNS for TXT record of _kerberos.ipa.example.com. > No DNS record found > Search DNS for SRV record of _kerberos._udp.ipa.example.com. > No DNS record found > SRV record for KDC not found! Domain: ipa.example.com > [LDAP server check] > Verifying that ipaprd2.example.com (realm None) is an IPA server > Init LDAP connection with: ldap://ipaprd2.example.com:389 > LDAP Error: Protocol error: unsupported extended operation > Discovery result: UNKNOWN_ERROR; server=None, domain=ipa.example.com, > kdc=None, basedn=None > Validated servers: > will use discovered domain: ipa.example.com > IPA Server not found > [IPA Discovery] > Starting IPA discovery with domain=ipa.example.com, servers=[' > ipaprd2.example.com'], hostname=ipadev6.example.com > Server and domain forced > [Kerberos realm search] > Search DNS for TXT record of _kerberos.ipa.example.com. > No DNS record found > Search DNS for SRV record of _kerberos._udp.ipa.example.com. > No DNS record found > SRV record for KDC not found! Domain: ipa.example.com > [LDAP server check] > Verifying that ipaprd2.example.com (realm None) is an IPA server > Init LDAP connection with: ldap://ipaprd2.example.com:389 > LDAP Error: Protocol error: unsupported extended operation > Discovery result: UNKNOWN_ERROR; server=None, domain=ipa.example.com, > kdc=None, basedn=None > Validated servers: > Failed to verify that ipaprd2.example.com is an IPA Server. > This may mean that the remote server is not up or is not reachable due to > network or firewall settings. > Please make sure the following ports are opened in the firewall settings: > TCP: 80, 88, 389 > UDP: 88 (at least one of TCP/UDP ports 88 has to be open) > Also note that following ports are necessary for ipa-client working > properly after enrollment: > TCP: 464 > UDP: 464, 123 (if NTP enabled) > (ipaprd2.example.com: Provided as option) > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > > I double checked the services running on the replica, all looked well: > ports are listening, and I could telnet the ports from the client(ipadev6). > I could run "ldapserach" command to talk to the replica(ipaprd2) from this > client(ipadev6), with pulling out all the LDAP records. > > Also, I have another test box running RHEL7, and no issue at all to run the > exact same ipa-client-install command on that RHEL7 box. So could there be > a bug on the ipa-client software on RHEL6, to talk to IPA sever running on > RHEL7? Please advise. Thank you! > > Best regards, > Beeth > > > Hello Beeth, I've tried to reproduce the problem you described with 7.3 (ipa-server 4.4.0-12) on master and replica and 6.9 (ipa-client 3.0.0-51) on client and it worked for me as expected. I've done these steps: [master] # ipa-server-install -a Secret123 -p Secret123 --domain example.test --realm EXAMPLE.TEST --setup-dns --auto-forwarders -U [replica] # ipa-client-install -p admin -w Secret123 --domain example.test --server master.example.test -U [replica] # ipa-replica-install [client] # ipa-client-install -p admin -w Secret123 --domain example.test --server replica.example.test -U [client] # id admin Is there anything you've done differently? -- David Kupka From titleistfour at gmail.com Tue Dec 13 14:46:58 2016 From: titleistfour at gmail.com (jay) Date: Tue, 13 Dec 2016 08:46:58 -0600 Subject: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails In-Reply-To: <54dd53a6-69b3-5b08-9add-530d411d8e28@redhat.com> References: <54dd53a6-69b3-5b08-9add-530d411d8e28@redhat.com> Message-ID: Thank you for the response Flo. So I do see Apache running and listening on port 443. However, running that command I get a 503 * Trying 172.31.0.254... * Connected to ip-172-31-0-254.us-west-2.compute.internal (172.31.0.254) port 443 (#0) * Initializing NSS with certpath: sql:/etc/httpd/alias * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 * Server certificate: * subject: CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-WEST-2.COMPUTE.INTERNAL * start date: Dec 13 14:33:16 2016 GMT * expire date: Dec 14 14:33:16 2018 GMT * common name: ip-172-31-0-254.us-west-2.compute.internal * issuer: CN=Certificate Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL > GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1 > User-Agent: curl/7.29.0 > Host: ip-172-31-0-254.us-west-2.compute.internal > Accept: */* > * NSS: using client certificate: ipaCert * subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INTERNAL * start date: Dec 13 14:32:28 2016 GMT * expire date: Dec 03 14:32:28 2018 GMT * common name: IPA RA * issuer: CN=Certificate Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL < HTTP/1.1 503 Service Unavailable < Date: Tue, 13 Dec 2016 14:44:00 GMT < Server: Apache < Content-Length: 299 < Connection: close < Content-Type: text/html; charset=iso-8859-1 [root at ip-172-31-0-254 ~]# cat out.html 503 Service Unavailable

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

[root at ip-172-31-0-254 ~]# What would cause the service to be unavailable? Maybe the installer changed and I need to provide another option now that I didn't have to before the version upgrade? Thanks, Jay On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud wrote: > On 12/12/2016 10:32 PM, jay wrote: > >> Hello, >> >> I have been testing freeipa on CentOS 7 for a while now with a >> relatively simple setup, just a single server and 12 or so Linux clients >> in AWS. I went to rebuild the environment today and part of my Ansible >> playbook failed with this error >> >> ipa: ERROR: Certificate operation cannot be completed: Unable to >> communicate with CMS (503) >> >> This is the command that failed >> >> /usr/bin/ipa cert-show 1 --out=/root/cacert.crt >> >> I noticed the version I was using on Friday was >> ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64. But now I'm getting >> ipa-server-4.4.0-14.el7.centos.x86_64 installed, so the repo was updated >> over the weekend. >> >> Is there a known issue running cert-show with this version? I can't >> find anything in the debug logs that point to something wrong. Running >> 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n ipaCert' work >> just fine. >> >> Can someone offer some advice or pointer to what might be going on? I'm >> invoking the install with these options and it has worked flawlessly >> before this new version >> >> 2016-12-12T21:05:21Z DEBUG ipa-server-install was invoked with arguments >> [] and options: {'no_dns_ >> sshfp': None, 'ignore_topology_disconnect': None, 'verbose': False, >> 'ip_addresses': [CheckedIPAddr >> ess('172.31.0.235')], 'domainlevel': None, 'mkhomedir': None, >> 'http_cert_files': None, 'no_ntp': N >> one, 'reverse_zones': None, 'no_forwarders': None, 'external_ca_type': >> None, 'ssh_trust_dns': True >> , 'domain_name': 'ipa.us-west-2.compute.internal', 'idmax': None, >> 'http_cert_name': None, 'dirsrv_ >> cert_files': None, 'no_dnssec_validation': None, 'ca_signing_algorithm': >> None, 'no_reverse': None, >> 'subject': None, 'unattended': True, 'auto_reverse': None, >> 'auto_forwarders': None, 'no_host_dns' >> : None, 'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role': >> None, 'realm_name': 'IPA.U >> S-WEST-2.COMPUTE.INTERNAL', 'forwarders': >> [CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte >> rnal_ca': None, 'no_ssh': None, 'external_cert_files': None, >> 'no_hbac_allow': None, 'forward_polic >> y': None, 'dirsrv_cert_name': None, 'ca_cert_files': None, 'zonemgr': >> None, 'quiet': False, 'setup >> _dns': True, 'host_name': 'ip-172-31-0-235.us-west-2.compute.internal', >> 'dirsrv_config_file': None >> , 'log_file': None, 'allow_zone_overlap': None, 'uninstall': False} >> 2016-12-12T21:05:21Z DEBUG IPA version 4.4.0-14.el7.centos >> >> Thank you >> Jay >> >> >> > Hi, > > the ipa cert-show command is communicating with Dogtag, using port 443. > Can you check if Dogtag is properly responding on this port? > > $ SSL_DIR=/etc/httpd/alias/ curl -v -E ipaCert:`cat > /etc/httpd/alias/pwdfile.txt` https://hostname.domainname:44 > 3/ca/agent/ca/displayBySerial?serialNumber=1 -o out.html > > The issue can be that Dogtag is down, or a SSL issue (the certificate > ipaCert in /etc/httpd/alias is used to authenticate the client to Dogtag). > > HTH, > Flo. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From titleistfour at gmail.com Tue Dec 13 15:41:18 2016 From: titleistfour at gmail.com (jay) Date: Tue, 13 Dec 2016 09:41:18 -0600 Subject: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails In-Reply-To: References: <54dd53a6-69b3-5b08-9add-530d411d8e28@redhat.com> Message-ID: Maybe this will help more, I noticed this error in the Apache logs [Tue Dec 13 09:33:37.774921 2016] [:error] [pid 2309] ipa: INFO: [jsonserver_kerb] admin at IPA.US-WEST-2.COMPUTE.INTERNAL: cert_show/1(u'1', version=u'2.213'): CertificateOperationError [Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316] (111)Connection refused: AH00957: AJP: attempt to connect to 127.0.0.1:8009 (localhost) failed [Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 60s [Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316] [client 172.31.0.254:39646] AH00896: failed to make connection to backend: localhost [Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR: ra.get_certificate(): Unable to communicate with CMS (503) So whatever is running on port 8009 isn't responding or setup properly. Jay On Tue, Dec 13, 2016 at 8:46 AM, jay wrote: > Thank you for the response Flo. So I do see Apache running and listening > on port 443. However, running that command I get a 503 > > * Trying 172.31.0.254... > * Connected to ip-172-31-0-254.us-west-2.compute.internal (172.31.0.254) > port 443 (#0) > * Initializing NSS with certpath: sql:/etc/httpd/alias > * CAfile: /etc/pki/tls/certs/ca-bundle.crt > CApath: none > * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > * Server certificate: > * subject: CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US- > WEST-2.COMPUTE.INTERNAL > * start date: Dec 13 14:33:16 2016 GMT > * expire date: Dec 14 14:33:16 2018 GMT > * common name: ip-172-31-0-254.us-west-2.compute.internal > * issuer: CN=Certificate Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL > > GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1 > > User-Agent: curl/7.29.0 > > Host: ip-172-31-0-254.us-west-2.compute.internal > > Accept: */* > > > * NSS: using client certificate: ipaCert > * subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INTERNAL > * start date: Dec 13 14:32:28 2016 GMT > * expire date: Dec 03 14:32:28 2018 GMT > * common name: IPA RA > * issuer: CN=Certificate Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL > < HTTP/1.1 503 Service Unavailable > < Date: Tue, 13 Dec 2016 14:44:00 GMT > < Server: Apache > < Content-Length: 299 > < Connection: close > < Content-Type: text/html; charset=iso-8859-1 > > [root at ip-172-31-0-254 ~]# cat out.html > > > 503 Service Unavailable > >

Service Unavailable

>

The server is temporarily unable to service your > request due to maintenance downtime or capacity > problems. Please try again later.

> > [root at ip-172-31-0-254 ~]# > > > What would cause the service to be unavailable? Maybe the installer > changed and I need to provide another option now that I didn't have to > before the version upgrade? > > Thanks, > Jay > > On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud > wrote: > >> On 12/12/2016 10:32 PM, jay wrote: >> >>> Hello, >>> >>> I have been testing freeipa on CentOS 7 for a while now with a >>> relatively simple setup, just a single server and 12 or so Linux clients >>> in AWS. I went to rebuild the environment today and part of my Ansible >>> playbook failed with this error >>> >>> ipa: ERROR: Certificate operation cannot be completed: Unable to >>> communicate with CMS (503) >>> >>> This is the command that failed >>> >>> /usr/bin/ipa cert-show 1 --out=/root/cacert.crt >>> >>> I noticed the version I was using on Friday was >>> ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64. But now I'm getting >>> ipa-server-4.4.0-14.el7.centos.x86_64 installed, so the repo was updated >>> over the weekend. >>> >>> Is there a known issue running cert-show with this version? I can't >>> find anything in the debug logs that point to something wrong. Running >>> 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n ipaCert' work >>> just fine. >>> >>> Can someone offer some advice or pointer to what might be going on? I'm >>> invoking the install with these options and it has worked flawlessly >>> before this new version >>> >>> 2016-12-12T21:05:21Z DEBUG ipa-server-install was invoked with arguments >>> [] and options: {'no_dns_ >>> sshfp': None, 'ignore_topology_disconnect': None, 'verbose': False, >>> 'ip_addresses': [CheckedIPAddr >>> ess('172.31.0.235')], 'domainlevel': None, 'mkhomedir': None, >>> 'http_cert_files': None, 'no_ntp': N >>> one, 'reverse_zones': None, 'no_forwarders': None, 'external_ca_type': >>> None, 'ssh_trust_dns': True >>> , 'domain_name': 'ipa.us-west-2.compute.internal', 'idmax': None, >>> 'http_cert_name': None, 'dirsrv_ >>> cert_files': None, 'no_dnssec_validation': None, 'ca_signing_algorithm': >>> None, 'no_reverse': None, >>> 'subject': None, 'unattended': True, 'auto_reverse': None, >>> 'auto_forwarders': None, 'no_host_dns' >>> : None, 'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role': >>> None, 'realm_name': 'IPA.U >>> S-WEST-2.COMPUTE.INTERNAL', 'forwarders': >>> [CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte >>> rnal_ca': None, 'no_ssh': None, 'external_cert_files': None, >>> 'no_hbac_allow': None, 'forward_polic >>> y': None, 'dirsrv_cert_name': None, 'ca_cert_files': None, 'zonemgr': >>> None, 'quiet': False, 'setup >>> _dns': True, 'host_name': 'ip-172-31-0-235.us-west-2.compute.internal', >>> 'dirsrv_config_file': None >>> , 'log_file': None, 'allow_zone_overlap': None, 'uninstall': False} >>> 2016-12-12T21:05:21Z DEBUG IPA version 4.4.0-14.el7.centos >>> >>> Thank you >>> Jay >>> >>> >>> >> Hi, >> >> the ipa cert-show command is communicating with Dogtag, using port 443. >> Can you check if Dogtag is properly responding on this port? >> >> $ SSL_DIR=/etc/httpd/alias/ curl -v -E ipaCert:`cat >> /etc/httpd/alias/pwdfile.txt` https://hostname.domainname:44 >> 3/ca/agent/ca/displayBySerial?serialNumber=1 -o out.html >> >> The issue can be that Dogtag is down, or a SSL issue (the certificate >> ipaCert in /etc/httpd/alias is used to authenticate the client to Dogtag). >> >> HTH, >> Flo. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.driscoll at oracle.com Tue Dec 13 16:06:38 2016 From: mike.driscoll at oracle.com (Mike Driscoll) Date: Tue, 13 Dec 2016 08:06:38 -0800 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: Any thoughts about this sizelimit bug? Mike > On Nov 28, 2016, at 14:44, 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 From mbasti at redhat.com Tue Dec 13 16:17:23 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 13 Dec 2016 17:17:23 +0100 Subject: [Freeipa-users] DNS search timeouts and incomplete results In-Reply-To: References: <65B5DD10-9792-44C7-BD17-E3A45BDDE2FD@oracle.com> Message-ID: <362fb289-4f70-a3ec-e185-319e217ebf61@redhat.com> Tomas already replied to you, copying here as archives are currently offline to prevent spam """ 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. """ Martin On 13.12.2016 17:06, Mike Driscoll wrote: > Any thoughts about this sizelimit bug? > > Mike > > > >> On Nov 28, 2016, at 14:44, 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 > From flo at redhat.com Tue Dec 13 16:20:27 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 13 Dec 2016 17:20:27 +0100 Subject: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails In-Reply-To: References: <54dd53a6-69b3-5b08-9add-530d411d8e28@redhat.com> Message-ID: <05016e1c-5ed3-9813-0513-625508783c00@redhat.com> On 12/13/2016 04:41 PM, jay wrote: > Maybe this will help more, I noticed this error in the Apache logs > > [Tue Dec 13 09:33:37.774921 2016] [:error] [pid 2309] ipa: INFO: > [jsonserver_kerb] admin at IPA.US-WEST-2.COMPUTE.INTERNAL: > cert_show/1(u'1', version=u'2.213'): CertificateOperationError > [Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316] > (111)Connection refused: AH00957: AJP: attempt to connect to > 127.0.0.1:8009 (localhost) failed > [Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959: > ap_proxy_connect_backend disabling worker for (localhost) for 60s > [Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316] [client > 172.31.0.254:39646 ] AH00896: failed to make > connection to backend: localhost > [Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR: > ra.get_certificate(): Unable to communicate with CMS (503) > > > So whatever is running on port 8009 isn't responding or setup properly. > > Jay > > On Tue, Dec 13, 2016 at 8:46 AM, jay > wrote: > > Thank you for the response Flo. So I do see Apache running and > listening on port 443. However, running that command I get a 503 > > * Trying 172.31.0.254... > * Connected to ip-172-31-0-254.us-west-2.compute.internal > (172.31.0.254) port 443 (#0) > * Initializing NSS with certpath: sql:/etc/httpd/alias > * CAfile: /etc/pki/tls/certs/ca-bundle.crt > CApath: none > * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > * Server certificate: > * subject: > CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-WEST-2.COMPUTE.INTERNAL > * start date: Dec 13 14:33:16 2016 GMT > * expire date: Dec 14 14:33:16 2018 GMT > * common name: ip-172-31-0-254.us-west-2.compute.internal > * issuer: CN=Certificate > Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL > > GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1 > > User-Agent: curl/7.29.0 > > Host: ip-172-31-0-254.us-west-2.compute.internal > > Accept: */* > > > * NSS: using client certificate: ipaCert > * subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INTERNAL > * start date: Dec 13 14:32:28 2016 GMT > * expire date: Dec 03 14:32:28 2018 GMT > * common name: IPA RA > * issuer: CN=Certificate > Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL > < HTTP/1.1 503 Service Unavailable > < Date: Tue, 13 Dec 2016 14:44:00 GMT > < Server: Apache > < Content-Length: 299 > < Connection: close > < Content-Type: text/html; charset=iso-8859-1 > > [root at ip-172-31-0-254 ~]# cat out.html > > > 503 Service Unavailable > >

Service Unavailable

>

The server is temporarily unable to service your > request due to maintenance downtime or capacity > problems. Please try again later.

> > [root at ip-172-31-0-254 ~]# > > > What would cause the service to be unavailable? Maybe the installer > changed and I need to provide another option now that I didn't have > to before the version upgrade? > Hi Jay, I am not completely familiar with Tomcat, but I understand so far that the httpd server is configured to redirect requests on displayBySerial to Tomcat with this setting in the file /etc/httpd/conf.d/ipa-pki-proxy.conf: NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require ProxyPassMatch ajp://localhost:8009 ProxyPassReverse ajp://localhost:8009 And this port must be configured in /etc/pki/pki-tomcat/server.xml: In my setup I also have /etc/hosts defining localhost: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 Can you check that you also have those settings? If yes, then I assume that Tomcat is not able to create the AJP connector on port 8009. When PKI is started, you should find a trace of the connector initialization in /var/log/pki/pki-tomcat/catalina.$DATE.log: 12-Dec-2016 13:54:17.579 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 12-Dec-2016 13:54:25.076 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] 12-Dec-2016 13:56:33.683 INFO [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.processApplication RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.dogtagpki.server.ca.rest.CAApplication Next steps to debug would be to increase Tomcat logs. Flo. > Thanks, > Jay > > On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud > > wrote: > > On 12/12/2016 10:32 PM, jay wrote: > > Hello, > > I have been testing freeipa on CentOS 7 for a while now with a > relatively simple setup, just a single server and 12 or so > Linux clients > in AWS. I went to rebuild the environment today and part of > my Ansible > playbook failed with this error > > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (503) > > This is the command that failed > > /usr/bin/ipa cert-show 1 --out=/root/cacert.crt > > I noticed the version I was using on Friday was > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64. But now I'm > getting > ipa-server-4.4.0-14.el7.centos.x86_64 installed, so the repo > was updated > over the weekend. > > Is there a known issue running cert-show with this version? > I can't > find anything in the debug logs that point to something > wrong. Running > 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n > ipaCert' work > just fine. > > Can someone offer some advice or pointer to what might be > going on? I'm > invoking the install with these options and it has worked > flawlessly > before this new version > > 2016-12-12T21:05:21Z DEBUG ipa-server-install was invoked > with arguments > [] and options: {'no_dns_ > sshfp': None, 'ignore_topology_disconnect': None, 'verbose': > False, > 'ip_addresses': [CheckedIPAddr > ess('172.31.0.235')], 'domainlevel': None, 'mkhomedir': None, > 'http_cert_files': None, 'no_ntp': N > one, 'reverse_zones': None, 'no_forwarders': None, > 'external_ca_type': > None, 'ssh_trust_dns': True > , 'domain_name': 'ipa.us-west-2.compute.internal', 'idmax': > None, > 'http_cert_name': None, 'dirsrv_ > cert_files': None, 'no_dnssec_validation': None, > 'ca_signing_algorithm': > None, 'no_reverse': None, > 'subject': None, 'unattended': True, 'auto_reverse': None, > 'auto_forwarders': None, 'no_host_dns' > : None, 'no_sshd': None, 'no_ui_redirect': None, > 'ignore_last_of_role': > None, 'realm_name': 'IPA.U > S-WEST-2.COMPUTE.INTERNAL', 'forwarders': > [CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte > rnal_ca': None, 'no_ssh': None, 'external_cert_files': None, > 'no_hbac_allow': None, 'forward_polic > y': None, 'dirsrv_cert_name': None, 'ca_cert_files': None, > 'zonemgr': > None, 'quiet': False, 'setup > _dns': True, 'host_name': 'ip-172-31-0-235.us-west-2.com > pute.internal', > 'dirsrv_config_file': None > , 'log_file': None, 'allow_zone_overlap': None, 'uninstall': > False} > 2016-12-12T21:05:21Z DEBUG IPA version 4.4.0-14.el7.centos > > Thank you > Jay > > > > Hi, > > the ipa cert-show command is communicating with Dogtag, using > port 443. Can you check if Dogtag is properly responding on this > port? > > $ SSL_DIR=/etc/httpd/alias/ curl -v -E ipaCert:`cat > /etc/httpd/alias/pwdfile.txt` > https://hostname.domainname:443/ca/agent/ca/displayBySerial?serialNumber=1 > > -o out.html > > The issue can be that Dogtag is down, or a SSL issue (the > certificate ipaCert in /etc/httpd/alias is used to authenticate > the client to Dogtag). > > HTH, > Flo. > > > > > From titleistfour at gmail.com Tue Dec 13 16:29:33 2016 From: titleistfour at gmail.com (jay) Date: Tue, 13 Dec 2016 10:29:33 -0600 Subject: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails In-Reply-To: <05016e1c-5ed3-9813-0513-625508783c00@redhat.com> References: <54dd53a6-69b3-5b08-9add-530d411d8e28@redhat.com> <05016e1c-5ed3-9813-0513-625508783c00@redhat.com> Message-ID: Well Flo, the issue was IPV6 was disabled. As soon as I enabled it again, added that /etc/hosts entry back, and rebooted the server, things are working again! So is that now a requirement for 4.4.x? Server worked fine on 4.2 without IPV6 enabled. Or has that always been a requirement and I just got lucky somehow. I'm looking through the docs now. Regardless, thank you very much for the help Flo! Jay On Tue, Dec 13, 2016 at 10:20 AM, Florence Blanc-Renaud wrote: > On 12/13/2016 04:41 PM, jay wrote: > >> Maybe this will help more, I noticed this error in the Apache logs >> >> [Tue Dec 13 09:33:37.774921 2016] [:error] [pid 2309] ipa: INFO: >> [jsonserver_kerb] admin at IPA.US-WEST-2.COMPUTE.INTERNAL: >> cert_show/1(u'1', version=u'2.213'): CertificateOperationError >> [Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316] >> (111)Connection refused: AH00957: AJP: attempt to connect to >> 127.0.0.1:8009 (localhost) failed >> [Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959: >> ap_proxy_connect_backend disabling worker for (localhost) for 60s >> [Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316] [client >> 172.31.0.254:39646 ] AH00896: failed to make >> connection to backend: localhost >> [Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR: >> ra.get_certificate(): Unable to communicate with CMS (503) >> >> >> So whatever is running on port 8009 isn't responding or setup properly. >> >> Jay >> >> On Tue, Dec 13, 2016 at 8:46 AM, jay > > wrote: >> >> Thank you for the response Flo. So I do see Apache running and >> listening on port 443. However, running that command I get a 503 >> >> * Trying 172.31.0.254... >> * Connected to ip-172-31-0-254.us-west-2.compute.internal >> (172.31.0.254) port 443 (#0) >> * Initializing NSS with certpath: sql:/etc/httpd/alias >> * CAfile: /etc/pki/tls/certs/ca-bundle.crt >> CApath: none >> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> * Server certificate: >> * subject: >> CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-WEST- >> 2.COMPUTE.INTERNAL >> * start date: Dec 13 14:33:16 2016 GMT >> * expire date: Dec 14 14:33:16 2018 GMT >> * common name: ip-172-31-0-254.us-west-2.compute.internal >> * issuer: CN=Certificate >> Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL >> > GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1 >> > User-Agent: curl/7.29.0 >> > Host: ip-172-31-0-254.us-west-2.compute.internal >> > Accept: */* >> > >> * NSS: using client certificate: ipaCert >> * subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INTERNAL >> * start date: Dec 13 14:32:28 2016 GMT >> * expire date: Dec 03 14:32:28 2018 GMT >> * common name: IPA RA >> * issuer: CN=Certificate >> Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL >> < HTTP/1.1 503 Service Unavailable >> < Date: Tue, 13 Dec 2016 14:44:00 GMT >> < Server: Apache >> < Content-Length: 299 >> < Connection: close >> < Content-Type: text/html; charset=iso-8859-1 >> >> [root at ip-172-31-0-254 ~]# cat out.html >> >> >> 503 Service Unavailable >> >>

Service Unavailable

>>

The server is temporarily unable to service your >> request due to maintenance downtime or capacity >> problems. Please try again later.

>> >> [root at ip-172-31-0-254 ~]# >> >> >> What would cause the service to be unavailable? Maybe the installer >> changed and I need to provide another option now that I didn't have >> to before the version upgrade? >> >> Hi Jay, > > I am not completely familiar with Tomcat, but I understand so far that the > httpd server is configured to redirect requests on displayBySerial to > Tomcat with this setting in the file /etc/httpd/conf.d/ipa-pki-proxy.conf: > > agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/ > eeca/ca/profileSubmitSSLClient|^/kra/agent/kra/connector"> > NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate > NSSVerifyClient require > ProxyPassMatch ajp://localhost:8009 > ProxyPassReverse ajp://localhost:8009 > > > And this port must be configured in /etc/pki/pki-tomcat/server.xml: > protocol="AJP/1.3" > redirectPort="8443" > address="::1" /> > > In my setup I also have /etc/hosts defining localhost: > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 > > > Can you check that you also have those settings? If yes, then I assume > that Tomcat is not able to create the AJP connector on port 8009. > When PKI is started, you should find a trace of the connector > initialization in /var/log/pki/pki-tomcat/catalina.$DATE.log: > > 12-Dec-2016 13:54:17.579 INFO [main] org.apache.coyote.AbstractProtocol.init > Initializing ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] > 12-Dec-2016 13:54:25.076 INFO [main] org.apache.coyote.AbstractProtocol.start > Starting ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:1-8009"] > 12-Dec-2016 13:56:33.683 INFO [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.processApplication > RESTEASY002225: Deploying javax.ws.rs.core.Application: class > org.dogtagpki.server.ca.rest.CAApplication > > Next steps to debug would be to increase Tomcat logs. > Flo. > > > Thanks, >> Jay >> >> On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud >> > wrote: >> >> On 12/12/2016 10:32 PM, jay wrote: >> >> Hello, >> >> I have been testing freeipa on CentOS 7 for a while now with a >> relatively simple setup, just a single server and 12 or so >> Linux clients >> in AWS. I went to rebuild the environment today and part of >> my Ansible >> playbook failed with this error >> >> ipa: ERROR: Certificate operation cannot be completed: Unable >> to >> communicate with CMS (503) >> >> This is the command that failed >> >> /usr/bin/ipa cert-show 1 --out=/root/cacert.crt >> >> I noticed the version I was using on Friday was >> ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64. But now I'm >> getting >> ipa-server-4.4.0-14.el7.centos.x86_64 installed, so the repo >> was updated >> over the weekend. >> >> Is there a known issue running cert-show with this version? >> I can't >> find anything in the debug logs that point to something >> wrong. Running >> 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n >> ipaCert' work >> just fine. >> >> Can someone offer some advice or pointer to what might be >> going on? I'm >> invoking the install with these options and it has worked >> flawlessly >> before this new version >> >> 2016-12-12T21:05:21Z DEBUG ipa-server-install was invoked >> with arguments >> [] and options: {'no_dns_ >> sshfp': None, 'ignore_topology_disconnect': None, 'verbose': >> False, >> 'ip_addresses': [CheckedIPAddr >> ess('172.31.0.235')], 'domainlevel': None, 'mkhomedir': None, >> 'http_cert_files': None, 'no_ntp': N >> one, 'reverse_zones': None, 'no_forwarders': None, >> 'external_ca_type': >> None, 'ssh_trust_dns': True >> , 'domain_name': 'ipa.us-west-2.compute.internal', 'idmax': >> None, >> 'http_cert_name': None, 'dirsrv_ >> cert_files': None, 'no_dnssec_validation': None, >> 'ca_signing_algorithm': >> None, 'no_reverse': None, >> 'subject': None, 'unattended': True, 'auto_reverse': None, >> 'auto_forwarders': None, 'no_host_dns' >> : None, 'no_sshd': None, 'no_ui_redirect': None, >> 'ignore_last_of_role': >> None, 'realm_name': 'IPA.U >> S-WEST-2.COMPUTE.INTERNAL', 'forwarders': >> [CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte >> rnal_ca': None, 'no_ssh': None, 'external_cert_files': None, >> 'no_hbac_allow': None, 'forward_polic >> y': None, 'dirsrv_cert_name': None, 'ca_cert_files': None, >> 'zonemgr': >> None, 'quiet': False, 'setup >> _dns': True, 'host_name': 'ip-172-31-0-235.us-west-2.com >> pute.internal', >> 'dirsrv_config_file': None >> , 'log_file': None, 'allow_zone_overlap': None, 'uninstall': >> False} >> 2016-12-12T21:05:21Z DEBUG IPA version 4.4.0-14.el7.centos >> >> Thank you >> Jay >> >> >> >> Hi, >> >> the ipa cert-show command is communicating with Dogtag, using >> port 443. Can you check if Dogtag is properly responding on this >> port? >> >> $ SSL_DIR=/etc/httpd/alias/ curl -v -E ipaCert:`cat >> /etc/httpd/alias/pwdfile.txt` >> https://hostname.domainname:443/ca/agent/ca/displayBySerial? >> serialNumber=1 >> > ?serialNumber=1> >> -o out.html >> >> The issue can be that Dogtag is down, or a SSL issue (the >> certificate ipaCert in /etc/httpd/alias is used to authenticate >> the client to Dogtag). >> >> HTH, >> Flo. >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.driscoll at oracle.com Tue Dec 13 16:47:15 2016 From: mike.driscoll at oracle.com (Mike Driscoll) Date: Tue, 13 Dec 2016 08:47:15 -0800 Subject: [Freeipa-users] DNS search timeouts and incomplete results In-Reply-To: <362fb289-4f70-a3ec-e185-319e217ebf61@redhat.com> References: <65B5DD10-9792-44C7-BD17-E3A45BDDE2FD@oracle.com> <362fb289-4f70-a3ec-e185-319e217ebf61@redhat.com> Message-ID: <368D6938-CE4F-4518-8B17-5B9BF8E7F953@oracle.com> Thanks Martin. That is the cause... $ ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep nsslapd-sizelimit Enter LDAP Password: nsslapd-sizelimit: 2000 This command results in a similar problem that only 100 of 270 record names were returned. $ ipa dnsrecord-find mydomain.com qa If I specify these limits, I get all 270 records as expected. $ ipa dnsrecord-find mydomain.com qa --sizelimit=10000 --timelimit=20 I have the impression this default size limit meets most needs. Is my approach wrong when wanting to dump the entire DNS list of records via ipa dnsrecord-find? Mike > On Dec 13, 2016, at 08:17, Martin Basti wrote: > > Tomas already replied to you, copying here as archives are currently offline to prevent spam > > """ > > 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. > > """ > > Martin > > > On 13.12.2016 17:06, Mike Driscoll wrote: >> Any thoughts about this sizelimit bug? >> >> Mike >> >> >> >>> On Nov 28, 2016, at 14:44, 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 >> > From mbasti at redhat.com Tue Dec 13 17:03:08 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 13 Dec 2016 18:03:08 +0100 Subject: [Freeipa-users] DNS search timeouts and incomplete results In-Reply-To: <368D6938-CE4F-4518-8B17-5B9BF8E7F953@oracle.com> References: <65B5DD10-9792-44C7-BD17-E3A45BDDE2FD@oracle.com> <362fb289-4f70-a3ec-e185-319e217ebf61@redhat.com> <368D6938-CE4F-4518-8B17-5B9BF8E7F953@oracle.com> Message-ID: <09194b27-c6b9-c846-99ab-8501059db1e3@redhat.com> Receiving huge list of entries is not a cheap operation, that's why there is a default max limit set to 100/2000 entries. You have to count with that. Maybe direct AXFR from DNS may be more suitable for you, to get the complete list of DNS records per zone. But if you are fine with speed, memory and CPU consumption on server side, there is no issue why dnsrecord-find shouldn't be used. Martin On 13.12.2016 17:47, Mike Driscoll wrote: > Thanks Martin. That is the cause... > > $ ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep nsslapd-sizelimit > Enter LDAP Password: > nsslapd-sizelimit: 2000 > > This command results in a similar problem that only 100 of 270 record names were returned. > $ ipa dnsrecord-find mydomain.com qa > > If I specify these limits, I get all 270 records as expected. > $ ipa dnsrecord-find mydomain.com qa --sizelimit=10000 --timelimit=20 > > I have the impression this default size limit meets most needs. Is my approach wrong when wanting to dump the entire DNS list of records via ipa dnsrecord-find? > > Mike > > >> On Dec 13, 2016, at 08:17, Martin Basti wrote: >> >> Tomas already replied to you, copying here as archives are currently offline to prevent spam >> >> """ >> >> 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. >> >> """ >> >> Martin >> >> >> On 13.12.2016 17:06, Mike Driscoll wrote: >>> Any thoughts about this sizelimit bug? >>> >>> Mike >>> >>> >>> >>>> On Nov 28, 2016, at 14:44, 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 From jrichard at placeiq.com Wed Dec 14 01:10:58 2016 From: jrichard at placeiq.com (Jim Richard) Date: Tue, 13 Dec 2016 20:10:58 -0500 Subject: [Freeipa-users] ACIerrors is httpd log In-Reply-To: <5841F5B9.1060405@redhat.com> References: <4B8D5975-7858-4CC2-99AF-FC1E4D6EEB93@placeiq.com> <583C8806.1030809@redhat.com> <5840F109.1040507@redhat.com> <5BEF9BE5-D289-4616-BC11-A02CE4366877@placeiq.com> <5841F5B9.1060405@redhat.com> Message-ID: <20726A29-B7D0-4C40-8D3A-35AE87597F5A@placeiq.com> just now getting back to this, have been truncating httpd logs via cron since then to keep from filing up my disk. So, does this ring any bells :) [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: IPA: virtual verify retrieve certificate [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: Not granted by ACI to retrieve certificate, looking at principal [Wed Dec 14 00:38:39 2016] [error] ipa: INFO: host/phoenix-168.nym1.placeiq.net at PLACEIQ.NET: cert_request(u'MIID4zCCAssCAQAwPTEUMBIGA1UEChMLUExBQ0VJUS5ORVQxJTAjBgNVBAMTHHBob2VuaXgtMTY4Lm55bTEucGxhY2VpcS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDboyDDyTaP4+LxYThfy1w7C67TN2qBp8JjA7Y55gnthyUp/PUUXmm3FUQ4yG4cBqDSxZcUWzl+eA33/ceSIp0HtVl34ZkkUitY1hmUvu2nh16ReR65YC+qRqkAIypOilLdPzXIWZ7u5LbM/Xpj3/Npzm18UupAAznNXkZnojuPmAQ+ulPGypyefLnhr5my6hIaR1atTm1ZvHTG3raMJOJhFe4jMeI/tgPVdNCUfOUdEKhmmCm5KivxhTtHMEcH+8obuQnbaSokJscxlzHBLiyQGqhAn5gznXg0mlVCC0H4mwdB1g2g9cG+SxSua/7XCm+AnGXlc75MZAt594QBTc3fAgMBAAGgggFfMHsGCSqGSIb3DQEJFDFuHmwASQBQAEEAIABNAGEAYwBoAGkAbgBlACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAALQAgAHAAaABvAGUAbgBpAHgALQAxADYAOAAuAG4AeQBtADEALgBwAGwAYQBjAGUAaQBxAC4AbgBlAHQwgd8GCSqGSIb3DQEJDjGB0TCBzjCBmwYDVR0RAQEABIGQMIGNoD0GCisGAQQBgjcUAgOgLwwtaG9zdC9waG9lbml4LTE2OC5ueW0xLnBsYWNlaXEubmV0QFBMQUNFSVEuTkVUoEwGBisGAQUCAqBCMECgDRsLUExBQ0VJUS5ORVShLzAtoAMCAQGhJjAkGwRob3N0GxxwaG9lbml4LTE2OC5ueW0xLnBsYWNlaXEubmV0MAwGA1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFKDhj0rZ6mZwJfrJx3pCI12dct5WMA0GCSqGSIb3DQEBCwUAA4IBAQC/zeFtiiiJXi9bws2NWx2u/vB7aTVRci2yb9wb70dUzcpeJ3qRTqsE5I+D3MHxLYnixrG4iMEaWgEyuJy4SIWqW1YVSrHwhJZufyRnxy7luNXON+TBBBI0Gro5gICy9XiDKbA/q6clYzEbwDLe6Es/U5/h4Bl/ziV61KYCJN0P1bMWI21A73iP3EQHx2lefYxI8BJN68hJLQiK+E0IWGCqfvipTHA0bHYSQy6WFmmS96v0wr93jy783iromycZeXWzFJyx+LruVPmPOewmUOJ2Y2NJNPJv35pPYUw5Dt2hlLgWZ18po8C+XYqvMbzxM2DFlxMX3Ff+ZiwCRYSGknFI', principal=u'host/phoenix-168.nym1.placeiq.net at PLACEIQ.NET', add=True): ACIError [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: response: ACIError: Insufficient access: Gettext('not allowed to perform this command', domain='ipa', localedir=None) [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: no session id in request, generating empty session data with id=9beb89831ebfca453453ad48feaaa4d0 [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: store session: session_id=9beb89831ebfca453453ad48feaaa4d0 start_timestamp=2016-12-14T00:38:39 access_timestamp=2016-12-14T00:38:39 expiration_timestamp=1970-01-01T00:00:00 [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: finalize_kerberos_acquisition: xmlserver ccache_name="FILE:/tmp/krb5cc_apache_SQg9kf" session_id="9beb89831ebfca453453ad48feaaa4d0" [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: reading ccache data from file "/tmp/krb5cc_apache_SQg9kf" [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: get_credential_times: principal=krbtgt/PLACEIQ.NET at PLACEIQ.NET, authtime=12/14/16 00:38:36, starttime=12/14/16 00:38:37, endtime=12/15/16 00:38:36, renew_till=01/01/70 00:00:00 [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: KRB5_CCache FILE:/tmp/krb5cc_apache_SQg9kf endtime=1481762316 (12/15/16 00:38:36) [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1481762016 expiration=1481677119.46 (2016-12-14T00:58:39) [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: store session: session_id=9beb89831ebfca453453ad48feaaa4d0 start_timestamp=2016-12-14T00:38:39 access_timestamp=2016-12-14T00:38:39 expiration_timestamp=2016-12-14T00:58:39 [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: Destroyed connection context.ldap2 Jim Richard SYSTEM ADMINISTRATOR III (646) 338-8905 > On Dec 2, 2016, at 5:29 PM, Rob Crittenden wrote: > > Jim Richard wrote: >> Hmm ya. So before I rebuilt anything I thought maybe it was my DNS >> records but it looks like that?s not it. >> >> More background, I used to have sso-109 and sso-110, both CA?s. I >> rebuilt sso-110 without CA. >> >> My DNS is external, BIND on another host. >> >> Using the following (at the end of the message) host/key issue as an >> example. On this host, in sssd.conf, ipa_server and krb5_server values >> are both _srv_ so that means they?ll discover from DNS right? >> >> But in my krb5.conf I have: >> >> [realms] >> PLACEIQ.NET = { >> kdc = sso-110.nym1.placeiq.net :88 >> master_kdc = sso-110.nym1.placeiq.net >> :88 >> admin_server = sso-110.nym1.placeiq.net >> :749 >> default_domain = placeiq.net >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> } >> >> >> Is there any other IPA related config file that might reference a host name? >> >> I?ll include my DNS records at the end here, do they look correct for a >> two server setup, one with a CA (sso-109) and the other no CA (sso-110)? >> >> I never have been sure about the ?kerberos-master? entries, what makes >> an IPA host a ?kerberos master? and is this related to the CA in any way? >> >> ; ldap servers >> _ldap._tcp IN SRV 0 100 389 sso-109.nym1.placeiq.net >> . >> _ldap._tcp IN SRV 0 100 389 sso-110.nym1.placeiq.net >> . >> >> ;kerberos realm >> _kerberos IN TXT PLACEIQ.NET >> >> ; kerberos servers >> _kerberos._tcp IN SRV 0 100 88 sso-109.nym1.placeiq.net >> . >> _kerberos._tcp IN SRV 0 100 88 sso-110.nym1.placeiq.net >> . >> >> _kerberos._udp IN SRV 0 100 88 sso-109.nym1.placeiq.net >> . >> _kerberos._udp IN SRV 0 100 88 sso-110.nym1.placeiq.net >> . >> >> _kerberos-master._tcp IN SRV 0 100 88 sso-109.nym1.placeiq.net >> . >> _kerberos-master._udp IN SRV 0 100 88 sso-109.nym1.placeiq.net >> . >> _kerberos-adm._tcp IN SRV 0 100 749 sso-109.nym1.placeiq.net >> . >> _kerberos-adm._udp IN SRV 0 100 749 sso-109.nym1.placeiq.net >> . >> >> _kpasswd._tcp IN SRV 0 100 464 sso-109.nym1.placeiq.net >> . >> _kpasswd._tcp IN SRV 0 100 464 sso-110.nym1.placeiq.net >> . >> >> _kpasswd._udp IN SRV 0 100 464 sso-109.nym1.placeiq.net >> . >> _kpasswd._udp IN SRV 0 100 464 sso-110.nym1.placeiq.net >> . >> >> ; CNAME for IPA CA replicas (used for CRL, OCSP) >> ipa-ca IN A 10.1.41.109 >> >> >> >> Number of certificates and requests being tracked: 1. >> Request ID '20141110221330': >> status: MONITORING >> ca-error: Server at https://sso-110.nym1.placeiq.net/ipa/xml >> denied our request, giving up: 2100 (RPC failed at server. Insufficient >> access: not allowed to perform this command). >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - >> phoenix-142.nym1.placeiq.net >> ',token='NSS Certificate DB' >> certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA >> Machine Certificate - phoenix-142.nym1.placeiq.net >> ',token='NSS Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=PLACEIQ.NET >> subject: CN=phoenix-142.nym1.placeiq.net >> ,O=PLACEIQ.NET >> expires: 2016-11-10 22:13:31 UTC >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: >> post-save command: >> track: yes >> auto-renew: yes >> >> >> >> We are moving to latest version on RHEL so we?ll have paid support but >> before than, gaining this understanding is massively valuable :) > > I'm pretty certain this has nothing to do with servers being removed. > IPA isn't saying it can't find something, it's saying you aren't allowed > to do something. > > Why that is the case I don't know. A way to maybe find out would involve > enabling debugging on the server. You can do this by creating > /etc/ipa/server.conf with these contents: > > [global] > debug=True > > Restart httpd and watch. I'd leave it on just long enough to see the > problem, then turn it off again given you are already having disk space > issues. > > There is no way to dynamically do this w/o restarting the service. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkupka at redhat.com Wed Dec 14 06:37:35 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 14 Dec 2016 07:37:35 +0100 Subject: [Freeipa-users] How to disable First time password change on IPA user In-Reply-To: References: Message-ID: <1cf3c30f-71d9-9576-668a-c889691ee72d@redhat.com> On 13/12/16 13:44, Ben .T.George wrote: > HI > > How to disable first time password change on newly created user from web UI > > Regards, > Ben > > > Hi Ben, AFAIK this is not possible to do using the API. One hacky way I can think of is modifying the krbPasswordExpiration attribute in the 389ds after creation of the user. $ sudo ldapmodify -D "cn=Directory Manager" -w Secret123 -h $HOSTNAME << END_LDIF dn: uid=tuser,cn=users,cn=accounts,dc=example,dc=com changetype: modify replace: krbPasswordExpiration krbPasswordExpiration: $(date -u -d "@$(($(date +'%s')+(90*24*3600)))" +'%Y%m%d%H%M%S'Z) END_LDIF It works but I would not recommend using it in production environment. -- David Kupka From flo at redhat.com Wed Dec 14 08:39:08 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 14 Dec 2016 09:39:08 +0100 Subject: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails In-Reply-To: References: <54dd53a6-69b3-5b08-9add-530d411d8e28@redhat.com> <05016e1c-5ed3-9813-0513-625508783c00@redhat.com> Message-ID: <6a4efe4d-d15c-46e3-dad5-2c86fccea278@redhat.com> On 12/13/2016 05:29 PM, jay wrote: > Well Flo, the issue was IPV6 was disabled. As soon as I enabled it > again, added that /etc/hosts entry back, and rebooted the server, things > are working again! > > So is that now a requirement for 4.4.x? Server worked fine on 4.2 Hi Jay, this behavior was introduced with the fix for ticket 4291 (CA not start during ipa server install in pure IPv6 env) in FreeIPA 4.4.1 [1]. I agree that the doc [2] does not explicitely mention that IPv6 is required, but it sort of suggests that it should be set up. I found an e-mail thread mentioning why IPv6 should not be disabled [3], and also on freeipa.org a wiki for Deployment recommendations [4]. I will open a documentation bug asking to add this requirement in Red Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide. Flo [1] https://fedorahosted.org/freeipa/ticket/4291 [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs [3] https://www.redhat.com/mailman/private/freeipa-users/2015-September/msg00175.html [4] http://www.freeipa.org/page/Deployment_Recommendations#Active_Directory_Integration > without IPV6 enabled. Or has that always been a requirement and I just > got lucky somehow. I'm looking through the docs now. > > Regardless, thank you very much for the help Flo! > > Jay > > On Tue, Dec 13, 2016 at 10:20 AM, Florence Blanc-Renaud > wrote: > > On 12/13/2016 04:41 PM, jay wrote: > > Maybe this will help more, I noticed this error in the Apache logs > > [Tue Dec 13 09:33:37.774921 2016 ] [:error] > [pid 2309] ipa: INFO: > [jsonserver_kerb] admin at IPA.US-WEST-2.COMPUTE.IN > TERNAL: > cert_show/1(u'1', version=u'2.213'): CertificateOperationError > [Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316] > (111)Connection refused: AH00957: AJP: attempt to connect to > 127.0.0.1:8009 > (localhost) failed > [Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959: > ap_proxy_connect_backend disabling worker for (localhost) for 60s > [Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316] > [client > 172.31.0.254:39646 > ] AH00896: failed to make > connection to backend: localhost > [Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR: > ra.get_certificate(): Unable to communicate with CMS (503) > > > So whatever is running on port 8009 isn't responding or setup > properly. > > Jay > > On Tue, Dec 13, 2016 at 8:46 AM, jay > >> > wrote: > > Thank you for the response Flo. So I do see Apache running and > listening on port 443. However, running that command I get > a 503 > > * Trying 172.31.0.254... > * Connected to ip-172-31-0-254.us-west-2.compute.internal > (172.31.0.254) port 443 (#0) > * Initializing NSS with certpath: sql:/etc/httpd/alias > * CAfile: /etc/pki/tls/certs/ca-bundle.crt > CApath: none > * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > * Server certificate: > * subject: > > CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-WEST-2.COMPUTE.INTERNAL > * start date: Dec 13 14:33:16 2016 GMT > * expire date: Dec 14 14:33:16 2018 GMT > * common name: ip-172-31-0-254.us-west-2.compute.internal > * issuer: CN=Certificate > Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL > > GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1 > > User-Agent: curl/7.29.0 > > Host: ip-172-31-0-254.us-west-2.compute.internal > > Accept: */* > > > * NSS: using client certificate: ipaCert > * subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INT > ERNAL > * start date: Dec 13 14:32:28 2016 GMT > * expire date: Dec 03 14:32:28 2018 GMT > * common name: IPA RA > * issuer: CN=Certificate > Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL > < HTTP/1.1 503 Service Unavailable > < Date: Tue, 13 Dec 2016 14:44:00 GMT > < Server: Apache > < Content-Length: 299 > < Connection: close > < Content-Type: text/html; charset=iso-8859-1 > > [root at ip-172-31-0-254 ~]# cat out.html > > > 503 Service Unavailable > >

Service Unavailable

>

The server is temporarily unable to service your > request due to maintenance downtime or capacity > problems. Please try again later.

> > [root at ip-172-31-0-254 ~]# > > > What would cause the service to be unavailable? Maybe the > installer > changed and I need to provide another option now that I > didn't have > to before the version upgrade? > > Hi Jay, > > I am not completely familiar with Tomcat, but I understand so far > that the httpd server is configured to redirect requests on > displayBySerial to Tomcat with this setting in the file > /etc/httpd/conf.d/ipa-pki-proxy.conf: > > "^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient|^/kra/agent/kra/connector"> > NSSOptions +StdEnvVars +ExportCertData +StrictRequire > +OptRenegotiate > NSSVerifyClient require > ProxyPassMatch ajp://localhost:8009 > ProxyPassReverse ajp://localhost:8009 > > > And this port must be configured in /etc/pki/pki-tomcat/server.xml: > protocol="AJP/1.3" > redirectPort="8443" > address="::1" /> > > In my setup I also have /etc/hosts defining localhost: > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 > > > Can you check that you also have those settings? If yes, then I > assume that Tomcat is not able to create the AJP connector on port 8009. > When PKI is started, you should find a trace of the connector > initialization in /var/log/pki/pki-tomcat/catalina.$DATE.log: > > 12-Dec-2016 13:54:17.579 INFO [main] > org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler > ["ajp-nio-0:0:0:0:0:0:0:1-8009"] > 12-Dec-2016 13:54:25.076 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["ajp-nio-0:0:0:0:0:0:0:1-8009"] > 12-Dec-2016 13:56:33.683 INFO [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.processApplication > RESTEASY002225: Deploying javax.ws.rs.core.Application: class > org.dogtagpki.server.ca.rest.CAApplication > > Next steps to debug would be to increase Tomcat logs. > Flo. > > > Thanks, > Jay > > On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud > > >> wrote: > > On 12/12/2016 10:32 PM, jay wrote: > > Hello, > > I have been testing freeipa on CentOS 7 for a while > now with a > relatively simple setup, just a single server and 12 > or so > Linux clients > in AWS. I went to rebuild the environment today and > part of > my Ansible > playbook failed with this error > > ipa: ERROR: Certificate operation cannot be > completed: Unable to > communicate with CMS (503) > > This is the command that failed > > /usr/bin/ipa cert-show 1 --out=/root/cacert.crt > > I noticed the version I was using on Friday was > ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64. But > now I'm > getting > ipa-server-4.4.0-14.el7.centos.x86_64 installed, so > the repo > was updated > over the weekend. > > Is there a known issue running cert-show with this > version? > I can't > find anything in the debug logs that point to something > wrong. Running > 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n > ipaCert' work > just fine. > > Can someone offer some advice or pointer to what > might be > going on? I'm > invoking the install with these options and it has > worked > flawlessly > before this new version > > 2016-12-12T21:05:21Z DEBUG ipa-server-install was > invoked > with arguments > [] and options: {'no_dns_ > sshfp': None, 'ignore_topology_disconnect': None, > 'verbose': > False, > 'ip_addresses': [CheckedIPAddr > ess('172.31.0.235')], 'domainlevel': None, > 'mkhomedir': None, > 'http_cert_files': None, 'no_ntp': N > one, 'reverse_zones': None, 'no_forwarders': None, > 'external_ca_type': > None, 'ssh_trust_dns': True > , 'domain_name': 'ipa.us-west-2.compute.internal', > 'idmax': > None, > 'http_cert_name': None, 'dirsrv_ > cert_files': None, 'no_dnssec_validation': None, > 'ca_signing_algorithm': > None, 'no_reverse': None, > 'subject': None, 'unattended': True, > 'auto_reverse': None, > 'auto_forwarders': None, 'no_host_dns' > : None, 'no_sshd': None, 'no_ui_redirect': None, > 'ignore_last_of_role': > None, 'realm_name': 'IPA.U > S-WEST-2.COMPUTE.INTERNAL', 'forwarders': > [CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte > rnal_ca': None, 'no_ssh': None, > 'external_cert_files': None, > 'no_hbac_allow': None, 'forward_polic > y': None, 'dirsrv_cert_name': None, 'ca_cert_files': > None, > 'zonemgr': > None, 'quiet': False, 'setup > _dns': True, 'host_name': > 'ip-172-31-0-235.us-west-2.com > > >pute.internal', > 'dirsrv_config_file': None > , 'log_file': None, 'allow_zone_overlap': None, > 'uninstall': > False} > 2016-12-12T21:05:21Z DEBUG IPA version > 4.4.0-14.el7.centos > > Thank you > Jay > > > > Hi, > > the ipa cert-show command is communicating with Dogtag, > using > port 443. Can you check if Dogtag is properly responding > on this > port? > > $ SSL_DIR=/etc/httpd/alias/ curl -v -E ipaCert:`cat > /etc/httpd/alias/pwdfile.txt` > > https://hostname.domainname:443/ca/agent/ca/displayBySerial?serialNumber=1 > > > > > -o out.html > > The issue can be that Dogtag is down, or a SSL issue (the > certificate ipaCert in /etc/httpd/alias is used to > authenticate > the client to Dogtag). > > HTH, > Flo. > > > > > > > > > From abokovoy at redhat.com Wed Dec 14 09:15:55 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 14 Dec 2016 11:15:55 +0200 Subject: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails In-Reply-To: <6a4efe4d-d15c-46e3-dad5-2c86fccea278@redhat.com> References: <54dd53a6-69b3-5b08-9add-530d411d8e28@redhat.com> <05016e1c-5ed3-9813-0513-625508783c00@redhat.com> <6a4efe4d-d15c-46e3-dad5-2c86fccea278@redhat.com> Message-ID: <20161214091554.ks6t7glsmpvnjgmv@redhat.com> On ke, 14 joulu 2016, Florence Blanc-Renaud wrote: >On 12/13/2016 05:29 PM, jay wrote: >>Well Flo, the issue was IPV6 was disabled. As soon as I enabled it >>again, added that /etc/hosts entry back, and rebooted the server, things >>are working again! >> >>So is that now a requirement for 4.4.x? Server worked fine on 4.2 >Hi Jay, > >this behavior was introduced with the fix for ticket 4291 (CA not >start during ipa server install in pure IPv6 env) in FreeIPA 4.4.1 >[1]. > >I agree that the doc [2] does not explicitely mention that IPv6 is >required, but it sort of suggests that it should be set up. We actually require IPv6 stack on IPA masters for very long time. There is no reason why IPv6 stack should be disabled. You may lack addresses, even local ones, but given that IPv4 and IPv6 share the same port space, a single API is recommended to be used in implementing networking applications by the documentation in ipv6(7): ---- IPv4 connections can be handled with the v6 API by using the v4-mapped-on-v6 address type; thus a program needs to support only this API type to support both protocols. This is handled transparently by the address handling functions in the C library. IPv4 and IPv6 share the local port space. When you get an IPv4 connection or packet to a IPv6 socket, its source address will be mapped to v6 and it will be mapped to v6. ---- Thus, most of IPA code actually is implemented using this approach. You need to have IPv6 enabled in the kernel but not necessary used. This is mentioned as a requirement in the Windows Integration guide but it is valid for a normal IPA install as well: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-req-ipv6 >I found an e-mail thread mentioning why IPv6 should not be disabled >[3], and also on freeipa.org a wiki for Deployment recommendations >[4]. > >I will open a documentation bug asking to add this requirement in Red >Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and >Policy Guide. > >Flo > >[1] https://fedorahosted.org/freeipa/ticket/4291 >[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs >[3] https://www.redhat.com/mailman/private/freeipa-users/2015-September/msg00175.html >[4] http://www.freeipa.org/page/Deployment_Recommendations#Active_Directory_Integration > >>without IPV6 enabled. Or has that always been a requirement and I just >>got lucky somehow. I'm looking through the docs now. >> >>Regardless, thank you very much for the help Flo! >> >>Jay >> >>On Tue, Dec 13, 2016 at 10:20 AM, Florence Blanc-Renaud >> wrote: >> >> On 12/13/2016 04:41 PM, jay wrote: >> >> Maybe this will help more, I noticed this error in the Apache logs >> >> [Tue Dec 13 09:33:37.774921 2016 ] [:error] >> [pid 2309] ipa: INFO: >> [jsonserver_kerb] admin at IPA.US-WEST-2.COMPUTE.IN >> TERNAL: >> cert_show/1(u'1', version=u'2.213'): CertificateOperationError >> [Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316] >> (111)Connection refused: AH00957: AJP: attempt to connect to >> 127.0.0.1:8009 >> (localhost) failed >> [Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959: >> ap_proxy_connect_backend disabling worker for (localhost) for 60s >> [Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316] >> [client >> 172.31.0.254:39646 >> ] AH00896: failed to make >> connection to backend: localhost >> [Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR: >> ra.get_certificate(): Unable to communicate with CMS (503) >> >> >> So whatever is running on port 8009 isn't responding or setup >> properly. >> >> Jay >> >> On Tue, Dec 13, 2016 at 8:46 AM, jay > >> >> >> wrote: >> >> Thank you for the response Flo. So I do see Apache running and >> listening on port 443. However, running that command I get >> a 503 >> >> * Trying 172.31.0.254... >> * Connected to ip-172-31-0-254.us-west-2.compute.internal >> (172.31.0.254) port 443 (#0) >> * Initializing NSS with certpath: sql:/etc/httpd/alias >> * CAfile: /etc/pki/tls/certs/ca-bundle.crt >> CApath: none >> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> * Server certificate: >> * subject: >> >> CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-WEST-2.COMPUTE.INTERNAL >> * start date: Dec 13 14:33:16 2016 GMT >> * expire date: Dec 14 14:33:16 2018 GMT >> * common name: ip-172-31-0-254.us-west-2.compute.internal >> * issuer: CN=Certificate >> Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL >> > GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1 >> > User-Agent: curl/7.29.0 >> > Host: ip-172-31-0-254.us-west-2.compute.internal >> > Accept: */* >> > >> * NSS: using client certificate: ipaCert >> * subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INT >> ERNAL >> * start date: Dec 13 14:32:28 2016 GMT >> * expire date: Dec 03 14:32:28 2018 GMT >> * common name: IPA RA >> * issuer: CN=Certificate >> Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL >> < HTTP/1.1 503 Service Unavailable >> < Date: Tue, 13 Dec 2016 14:44:00 GMT >> < Server: Apache >> < Content-Length: 299 >> < Connection: close >> < Content-Type: text/html; charset=iso-8859-1 >> >> [root at ip-172-31-0-254 ~]# cat out.html >> >> >> 503 Service Unavailable >> >>

Service Unavailable

>>

The server is temporarily unable to service your >> request due to maintenance downtime or capacity >> problems. Please try again later.

>> >> [root at ip-172-31-0-254 ~]# >> >> >> What would cause the service to be unavailable? Maybe the >> installer >> changed and I need to provide another option now that I >> didn't have >> to before the version upgrade? >> >> Hi Jay, >> >> I am not completely familiar with Tomcat, but I understand so far >> that the httpd server is configured to redirect requests on >> displayBySerial to Tomcat with this setting in the file >> /etc/httpd/conf.d/ipa-pki-proxy.conf: >> >> > "^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient|^/kra/agent/kra/connector"> >> NSSOptions +StdEnvVars +ExportCertData +StrictRequire >> +OptRenegotiate >> NSSVerifyClient require >> ProxyPassMatch ajp://localhost:8009 >> ProxyPassReverse ajp://localhost:8009 >> >> >> And this port must be configured in /etc/pki/pki-tomcat/server.xml: >> > protocol="AJP/1.3" >> redirectPort="8443" >> address="::1" /> >> >> In my setup I also have /etc/hosts defining localhost: >> 127.0.0.1 localhost localhost.localdomain localhost4 >> localhost4.localdomain4 >> ::1 localhost localhost.localdomain localhost6 >> localhost6.localdomain6 >> >> >> Can you check that you also have those settings? If yes, then I >> assume that Tomcat is not able to create the AJP connector on port 8009. >> When PKI is started, you should find a trace of the connector >> initialization in /var/log/pki/pki-tomcat/catalina.$DATE.log: >> >> 12-Dec-2016 13:54:17.579 INFO [main] >> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler >> ["ajp-nio-0:0:0:0:0:0:0:1-8009"] >> 12-Dec-2016 13:54:25.076 INFO [main] >> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler >> ["ajp-nio-0:0:0:0:0:0:0:1-8009"] >> 12-Dec-2016 13:56:33.683 INFO [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.processApplication >> RESTEASY002225: Deploying javax.ws.rs.core.Application: class >> org.dogtagpki.server.ca.rest.CAApplication >> >> Next steps to debug would be to increase Tomcat logs. >> Flo. >> >> >> Thanks, >> Jay >> >> On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud >> >> >> wrote: >> >> On 12/12/2016 10:32 PM, jay wrote: >> >> Hello, >> >> I have been testing freeipa on CentOS 7 for a while >> now with a >> relatively simple setup, just a single server and 12 >> or so >> Linux clients >> in AWS. I went to rebuild the environment today and >> part of >> my Ansible >> playbook failed with this error >> >> ipa: ERROR: Certificate operation cannot be >> completed: Unable to >> communicate with CMS (503) >> >> This is the command that failed >> >> /usr/bin/ipa cert-show 1 --out=/root/cacert.crt >> >> I noticed the version I was using on Friday was >> ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64. But >> now I'm >> getting >> ipa-server-4.4.0-14.el7.centos.x86_64 installed, so >> the repo >> was updated >> over the weekend. >> >> Is there a known issue running cert-show with this >> version? >> I can't >> find anything in the debug logs that point to something >> wrong. Running >> 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n >> ipaCert' work >> just fine. >> >> Can someone offer some advice or pointer to what >> might be >> going on? I'm >> invoking the install with these options and it has >> worked >> flawlessly >> before this new version >> >> 2016-12-12T21:05:21Z DEBUG ipa-server-install was >> invoked >> with arguments >> [] and options: {'no_dns_ >> sshfp': None, 'ignore_topology_disconnect': None, >> 'verbose': >> False, >> 'ip_addresses': [CheckedIPAddr >> ess('172.31.0.235')], 'domainlevel': None, >> 'mkhomedir': None, >> 'http_cert_files': None, 'no_ntp': N >> one, 'reverse_zones': None, 'no_forwarders': None, >> 'external_ca_type': >> None, 'ssh_trust_dns': True >> , 'domain_name': 'ipa.us-west-2.compute.internal', >> 'idmax': >> None, >> 'http_cert_name': None, 'dirsrv_ >> cert_files': None, 'no_dnssec_validation': None, >> 'ca_signing_algorithm': >> None, 'no_reverse': None, >> 'subject': None, 'unattended': True, >> 'auto_reverse': None, >> 'auto_forwarders': None, 'no_host_dns' >> : None, 'no_sshd': None, 'no_ui_redirect': None, >> 'ignore_last_of_role': >> None, 'realm_name': 'IPA.U >> S-WEST-2.COMPUTE.INTERNAL', 'forwarders': >> [CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte >> rnal_ca': None, 'no_ssh': None, >> 'external_cert_files': None, >> 'no_hbac_allow': None, 'forward_polic >> y': None, 'dirsrv_cert_name': None, 'ca_cert_files': >> None, >> 'zonemgr': >> None, 'quiet': False, 'setup >> _dns': True, 'host_name': >> 'ip-172-31-0-235.us-west-2.com >> >> > >pute.internal', >> 'dirsrv_config_file': None >> , 'log_file': None, 'allow_zone_overlap': None, >> 'uninstall': >> False} >> 2016-12-12T21:05:21Z DEBUG IPA version >> 4.4.0-14.el7.centos >> >> Thank you >> Jay >> >> >> >> Hi, >> >> the ipa cert-show command is communicating with Dogtag, >> using >> port 443. Can you check if Dogtag is properly responding >> on this >> port? >> >> $ SSL_DIR=/etc/httpd/alias/ curl -v -E ipaCert:`cat >> /etc/httpd/alias/pwdfile.txt` >> >> https://hostname.domainname:443/ca/agent/ca/displayBySerial?serialNumber=1 >> >> >> > > >> -o out.html >> >> The issue can be that Dogtag is down, or a SSL issue (the >> certificate ipaCert in /etc/httpd/alias is used to >> authenticate >> the client to Dogtag). >> >> HTH, >> Flo. >> >> >> >> >> >> >> >> >> > >-- >Manage your subscription for 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 b.candler at pobox.com Wed Dec 14 11:06:25 2016 From: b.candler at pobox.com (Brian Candler) Date: Wed, 14 Dec 2016 11:06:25 +0000 Subject: [Freeipa-users] ipa fails to start after centos 7.3 upgrade In-Reply-To: References: Message-ID: <7939848d-d56a-1df1-031f-c47defa73203@pobox.com> On 12/12/2016 19:53, Rob Verduijn wrote: > I've recently upgraded to centos 7.3. > Didn't intend to so soon but should have checked the anounce lists > before launching my ansible update playbook. > > Most of my servers came through, and mostly also the ipa server. > There were duplicate rpms and a failed rpm upgrade. > After some yum magic the rpm duplicates where gone and all the updates > installed. > > Manually running ipa-server-upgrade also seems to finish properly. > > However > ipactl start keeps failing on the ntpd service. > Not a big surprise since its running chronyd. > > I now start the ipa server with 'ipactl start --ignore-service-failure' > > Is there a way to explain the script that it should check for chronyd > instead of ntpd ? Aside: I also have a use case for running without ntp. I run freeipa inside an lxd container (*), so ntpd is running on the outer host, not in the container. However unlike you, after upgrading to CentOS 7.3 / FreeIPA 4.4.0 inside the container I don't see any problem: [root at ipa-2 ~]# ipactl stop Stopping ipa-otpd Service Stopping pki-tomcatd Service Stopping ntpd Service Stopping ipa-custodia Service Stopping httpd Service Stopping ipa_memcached Service Stopping kadmin Service Stopping krb5kdc Service Stopping Directory Service ipa: INFO: The ipactl command was successful [root at ipa-2 ~]# ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting ipa_memcached Service Starting httpd Service Starting ipa-custodia Service Starting ntpd Service Starting pki-tomcatd Service Starting ipa-otpd Service ipa: INFO: The ipactl command was successful [root at ipa-2 ~]# ntpd won't run inside the container, which is expected: [root at ipa-2 ~]# systemctl status ntpd ? ntpd.service - Network Time Service Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2016-12-14 10:51:09 UTC; 2min 18s ago Process: 1357 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 1358 (code=exited, status=255) Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listen normally on 4 eth0:1 10.0.0.149 UDP 123 Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listen normally on 5 lo ::1 UDP 123 Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listen normally on 6 eth0 fe80::216:3eff:fef2:a083 UDP 123 Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listening on routing socket on fd #23 for interface updates Dec 14 10:51:09 ipa-2.int.cityfibre.com ntpd[1358]: 0.0.0.0 c016 06 restart Dec 14 10:51:09 ipa-2.int.cityfibre.com ntpd[1358]: 0.0.0.0 c012 02 freq_set ntpd 0.000 PPM Dec 14 10:51:09 ipa-2.int.cityfibre.com ntpd[1358]: 0.0.0.0 c011 01 freq_not_set Dec 14 10:51:09 ipa-2.int.cityfibre.com systemd[1]: ntpd.service: main process exited, code=exited, status=255/n/a Dec 14 10:51:09 ipa-2.int.cityfibre.com systemd[1]: Unit ntpd.service entered failed state. Dec 14 10:51:09 ipa-2.int.cityfibre.com systemd[1]: ntpd.service failed. But ipactl is not complaining, which is good. But I don't know why it works for me and not for you. Anyway, I hope that for future reference this use case remains supported. In a container environment like lxd or docker, you *cannot* run ntpd (but that doesn't mean the time isn't synced!) Regards, Brian. (*) Aside: this makes snapshotting IPA a breeze. From simo at redhat.com Wed Dec 14 11:46:48 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Dec 2016 06:46:48 -0500 Subject: [Freeipa-users] Change in list archives accessibility In-Reply-To: <1481537090.7156.19.camel@redhat.com> References: <1481537090.7156.19.camel@redhat.com> Message-ID: <1481716008.3127.73.camel@redhat.com> On Mon, 2016-12-12 at 05:04 -0500, Simo Sorce wrote: > Dear freeipa-users, > in an attempt to identify how the recent wave of spamming activity > targets mailing list posters, I have temporarily disabled free access to > the archives. > This is not a permanent change and public access will be restored > shortly. Dear freeipa-users, I am going to conclude this experiment now, public access to the list archives is invaluable for searches. Apologies in advance if the spam issue will resurface, we are studying a way to deal with it w/o compromising public access for search and archive purposes. If you have an ideas/complaints/suggestions feel free to contact the mailing list owners address. Simo. -- Simo Sorce * Red Hat, Inc * New York From beeth2006 at gmail.com Wed Dec 14 12:08:00 2016 From: beeth2006 at gmail.com (beeth beeth) Date: Wed, 14 Dec 2016 07:08:00 -0500 Subject: [Freeipa-users] Failed ipa-client-install with IPA Replica In-Reply-To: <794d723f-9994-2281-1add-c5d0d1167257@redhat.com> References: <794d723f-9994-2281-1add-c5d0d1167257@redhat.com> Message-ID: Thanks David. I installed both the master and replica IPA servers with third-party certificates(Verisign), but I doubt that could be the issue, because I had no problem to run the same ipa-client-install command on a RHEL7 machine(of course, the --hostname used a different hostname of the server). And I had no problem to run the ipa-client-install command with --server= on such RHEL6 machine. So what could cause the LDAP communication failed during the client enrollment with the replica? Is there a way I can troubleshoot this by running some commands? So far I did telnet to check the open ports, as well as run the ldapsearch towards the replica. Thanks again! On Tue, Dec 13, 2016 at 8:46 AM, David Kupka wrote: > On 13/12/16 05:44, beeth beeth wrote: > >> I have two IPA servers ipaprd1.example.com and ipaprd2.example.com, >> running >> ipa 4.4 on RHEL7. When I tried to install/configure the client on a RHEL6 >> system(called ipadev6), I had issue when I tried to enroll it with the >> replica(ipaprd2), while no issue with the primary(ipaprd1): >> >> # ipa-client-install --domain=ipa.example.com --server= >> ipaprd1.example.com >> --server=ipaprd2.example.com --hostname=ipadev6.example.com >> LDAP Error: Protocol error: unsupported extended operation >> Autodiscovery of servers for failover cannot work with this configuration. >> If you proceed with the installation, services will be configured to >> always >> access the discovered server for all operations and will not fail over to >> other servers in case of failure. >> Proceed with fixed values and no DNS discovery? [no] >> >> Then I tried to run ipa-client-install to enroll with the >> replica(ipaprd2), >> with debug mode, I got this: >> >> # ipa-client-install --domain=ipa.example.com --server= >> ipaprd2.example.com >> --hostname=ipadev6.example.com -d >> /usr/sbin/ipa-client-install was invoked with options: {'domain': ' >> ipa.example.com', 'force': False, 'realm_name': None, >> 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir': False, >> 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'on_master': >> False, 'ntp_server': None, 'nisdomain': None, 'no_nisdomain': False, >> 'principal': None, 'hostname': 'ipadev6.example.com', 'no_ac': False, >> 'unattended': None, 'sssd': True, 'trust_sshfp': False, 'kinit_attempts': >> 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True, >> 'force_join': >> False, 'ca_cert_file': None, 'server': ['ipaprd2.example.com'], >> 'prompt_password': False, 'permit': False, 'debug': True, 'preserve_sssd': >> False, 'uninstall': False} >> missing options might be asked for interactively later >> Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' >> [IPA Discovery] >> Starting IPA discovery with domain=ipa.example.com, servers=[' >> ipaprd2.example.com'], hostname=ipadev6.example.com >> Server and domain forced >> [Kerberos realm search] >> Search DNS for TXT record of _kerberos.ipa.example.com. >> No DNS record found >> Search DNS for SRV record of _kerberos._udp.ipa.example.com. >> No DNS record found >> SRV record for KDC not found! Domain: ipa.example.com >> [LDAP server check] >> Verifying that ipaprd2.example.com (realm None) is an IPA server >> Init LDAP connection with: ldap://ipaprd2.example.com:389 >> LDAP Error: Protocol error: unsupported extended operation >> Discovery result: UNKNOWN_ERROR; server=None, domain=ipa.example.com, >> kdc=None, basedn=None >> Validated servers: >> will use discovered domain: ipa.example.com >> IPA Server not found >> [IPA Discovery] >> Starting IPA discovery with domain=ipa.example.com, servers=[' >> ipaprd2.example.com'], hostname=ipadev6.example.com >> Server and domain forced >> [Kerberos realm search] >> Search DNS for TXT record of _kerberos.ipa.example.com. >> No DNS record found >> Search DNS for SRV record of _kerberos._udp.ipa.example.com. >> No DNS record found >> SRV record for KDC not found! Domain: ipa.example.com >> [LDAP server check] >> Verifying that ipaprd2.example.com (realm None) is an IPA server >> Init LDAP connection with: ldap://ipaprd2.example.com:389 >> LDAP Error: Protocol error: unsupported extended operation >> Discovery result: UNKNOWN_ERROR; server=None, domain=ipa.example.com, >> kdc=None, basedn=None >> Validated servers: >> Failed to verify that ipaprd2.example.com is an IPA Server. >> This may mean that the remote server is not up or is not reachable due to >> network or firewall settings. >> Please make sure the following ports are opened in the firewall settings: >> TCP: 80, 88, 389 >> UDP: 88 (at least one of TCP/UDP ports 88 has to be open) >> Also note that following ports are necessary for ipa-client working >> properly after enrollment: >> TCP: 464 >> UDP: 464, 123 (if NTP enabled) >> (ipaprd2.example.com: Provided as option) >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> >> I double checked the services running on the replica, all looked well: >> ports are listening, and I could telnet the ports from the >> client(ipadev6). >> I could run "ldapserach" command to talk to the replica(ipaprd2) from this >> client(ipadev6), with pulling out all the LDAP records. >> >> Also, I have another test box running RHEL7, and no issue at all to run >> the >> exact same ipa-client-install command on that RHEL7 box. So could there be >> a bug on the ipa-client software on RHEL6, to talk to IPA sever running on >> RHEL7? Please advise. Thank you! >> >> Best regards, >> Beeth >> >> >> >> Hello Beeth, > I've tried to reproduce the problem you described with 7.3 (ipa-server > 4.4.0-12) on master and replica and 6.9 (ipa-client 3.0.0-51) on client and > it worked for me as expected. > I've done these steps: > [master] # ipa-server-install -a Secret123 -p Secret123 --domain > example.test --realm EXAMPLE.TEST --setup-dns --auto-forwarders -U > [replica] # ipa-client-install -p admin -w Secret123 --domain example.test > --server master.example.test -U > [replica] # ipa-replica-install > [client] # ipa-client-install -p admin -w Secret123 --domain example.test > --server replica.example.test -U > [client] # id admin > > Is there anything you've done differently? > > -- > David Kupka > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Wed Dec 14 12:57:57 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Wed, 14 Dec 2016 13:57:57 +0100 Subject: [Freeipa-users] Failed ipa-client-install with IPA Replica In-Reply-To: References: <794d723f-9994-2281-1add-c5d0d1167257@redhat.com> Message-ID: On 12/14/2016 01:08 PM, beeth beeth wrote: > Thanks David. I installed both the master and replica IPA servers with > third-party certificates(Verisign), but I doubt that could be the issue, > because I had no problem to run the same ipa-client-install command on a > RHEL7 machine(of course, the --hostname used a different hostname of the > server). And I had no problem to run the ipa-client-install command with > --server= on such RHEL6 machine. So what could cause the LDAP > communication failed during the client enrollment with the replica? Is > there a way I can troubleshoot this by running some commands? So far I > did telnet to check the open ports, as well as run the ldapsearch > towards the replica. Thanks again! > > > On Tue, Dec 13, 2016 at 8:46 AM, David Kupka > wrote: > > On 13/12/16 05:44, beeth beeth wrote: > > I have two IPA servers ipaprd1.example.com > and ipaprd2.example.com > , running > ipa 4.4 on RHEL7. When I tried to install/configure the client > on a RHEL6 > system(called ipadev6), I had issue when I tried to enroll it > with the > replica(ipaprd2), while no issue with the primary(ipaprd1): > > # ipa-client-install --domain=ipa.example.com > --server=ipaprd1.example.com > > --server=ipaprd2.example.com > --hostname=ipadev6.example.com > LDAP Error: Protocol error: unsupported extended operation > Autodiscovery of servers for failover cannot work with this > configuration. > If you proceed with the installation, services will be > configured to always > access the discovered server for all operations and will not > fail over to > other servers in case of failure. > Proceed with fixed values and no DNS discovery? [no] > > Then I tried to run ipa-client-install to enroll with the > replica(ipaprd2), > with debug mode, I got this: > > # ipa-client-install --domain=ipa.example.com > --server=ipaprd2.example.com > > --hostname=ipadev6.example.com -d > /usr/sbin/ipa-client-install was invoked with options: {'domain': ' > ipa.example.com ', 'force': False, > 'realm_name': None, > 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir': > False, > 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, > 'on_master': > False, 'ntp_server': None, 'nisdomain': None, 'no_nisdomain': False, > 'principal': None, 'hostname': 'ipadev6.example.com > ', 'no_ac': False, > 'unattended': None, 'sssd': True, 'trust_sshfp': False, > 'kinit_attempts': > 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True, > 'force_join': > False, 'ca_cert_file': None, 'server': ['ipaprd2.example.com > '], > 'prompt_password': False, 'permit': False, 'debug': True, > 'preserve_sssd': > False, 'uninstall': False} > missing options might be asked for interactively later > Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > Loading StateFile from > '/var/lib/ipa-client/sysrestore/sysrestore.state' > [IPA Discovery] > Starting IPA discovery with domain=ipa.example.com > , servers=[' > ipaprd2.example.com '], > hostname=ipadev6.example.com > Server and domain forced > [Kerberos realm search] > Search DNS for TXT record of _kerberos.ipa.example.com > . > No DNS record found > Search DNS for SRV record of _kerberos._udp.ipa.example.com > . > No DNS record found > SRV record for KDC not found! Domain: ipa.example.com > > [LDAP server check] > Verifying that ipaprd2.example.com > (realm None) is an IPA server > Init LDAP connection with: ldap://ipaprd2.example.com:389 > > LDAP Error: Protocol error: unsupported extended operation > Discovery result: UNKNOWN_ERROR; server=None, > domain=ipa.example.com , > kdc=None, basedn=None > Validated servers: > will use discovered domain: ipa.example.com > IPA Server not found > [IPA Discovery] > Starting IPA discovery with domain=ipa.example.com > , servers=[' > ipaprd2.example.com '], > hostname=ipadev6.example.com > Server and domain forced > [Kerberos realm search] > Search DNS for TXT record of _kerberos.ipa.example.com > . > No DNS record found > Search DNS for SRV record of _kerberos._udp.ipa.example.com > . > No DNS record found > SRV record for KDC not found! Domain: ipa.example.com > > [LDAP server check] > Verifying that ipaprd2.example.com > (realm None) is an IPA server > Init LDAP connection with: ldap://ipaprd2.example.com:389 > > LDAP Error: Protocol error: unsupported extended operation > Discovery result: UNKNOWN_ERROR; server=None, > domain=ipa.example.com , > kdc=None, basedn=None > Validated servers: > Failed to verify that ipaprd2.example.com > is an IPA Server. > This may mean that the remote server is not up or is not > reachable due to > network or firewall settings. > Please make sure the following ports are opened in the firewall > settings: > TCP: 80, 88, 389 > UDP: 88 (at least one of TCP/UDP ports 88 has to be open) > Also note that following ports are necessary for ipa-client working > properly after enrollment: > TCP: 464 > UDP: 464, 123 (if NTP enabled) > (ipaprd2.example.com : Provided as > option) > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > > I double checked the services running on the replica, all looked > well: > ports are listening, and I could telnet the ports from the > client(ipadev6). > I could run "ldapserach" command to talk to the replica(ipaprd2) > from this > client(ipadev6), with pulling out all the LDAP records. > > Also, I have another test box running RHEL7, and no issue at all > to run the > exact same ipa-client-install command on that RHEL7 box. So > could there be > a bug on the ipa-client software on RHEL6, to talk to IPA sever > running on > RHEL7? Please advise. Thank you! > Hi Beeth, you may want to check the access and errors log of the Directory Server in /var/log/dirsrv/slapd-DOMAIN. The extended operations are logged in the access log with the tag "EXT oid=...", but a failing operation related to unsupported extended operation will probably log a "RESULT err=2". So I would first check access log and look for such a failure. With the OID we will be able to understand which operation is failing and which part could be misconfigured. HTH, Flo. > Best regards, > Beeth > > > > Hello Beeth, > I've tried to reproduce the problem you described with 7.3 > (ipa-server 4.4.0-12) on master and replica and 6.9 (ipa-client > 3.0.0-51) on client and it worked for me as expected. > I've done these steps: > [master] # ipa-server-install -a Secret123 -p Secret123 --domain > example.test --realm EXAMPLE.TEST --setup-dns --auto-forwarders -U > [replica] # ipa-client-install -p admin -w Secret123 --domain > example.test --server master.example.test -U > [replica] # ipa-replica-install > [client] # ipa-client-install -p admin -w Secret123 --domain > example.test --server replica.example.test -U > [client] # id admin > > Is there anything you've done differently? > > -- > David Kupka > > > > From CTO at sshchicago.org Wed Dec 14 14:27:46 2016 From: CTO at sshchicago.org (Christian McNamara) Date: Wed, 14 Dec 2016 08:27:46 -0600 Subject: [Freeipa-users] Replica Creation Issue Message-ID: Hi all, I recently inherited a FreeIPA system that I believe is running v3.0, and I'm trying to upgrade to the latest version. Following documentation, I'm trying to create a replica but I'm running into problems connecting to the LDAP server. Here's the output I get when trying to prepare a replica: $ sudo ipa-replica-prepare auth4.sshchicago.org --ip-address 172.31.31.36 Directory Manager (existing master) password: Preparing replica for auth4.sshchicago.org from auth3.sshchicago.org preparation of replica failed: cannot connect to u'ldaps:// auth3.sshchicago.org: 7390': LDAP Server Down cannot connect to u'ldaps://auth3.sshchicago.org:7390': LDAP Server Down File "/usr/sbin/ipa-replica-prepare", line 529, in main() File "/usr/sbin/ipa-replica-prepare", line 391, in main update_pki_admin_password(dirman_password) File "/usr/sbin/ipa-replica-prepare", line 247, in update_pki_admin_password bind_pw=dirman_password File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in connect conn = self.create_connection(*args, **kw) File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line 846, in create_connection self.handle_errors(e) File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line 736, in handle_errors error=u'LDAP Server Down') It says that our LDAP server is down, but it's trying to connect using the wrong port number. Our LDAP server runs on 389, not 7390, and I can't figure out how to specify this to the prepare script. Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Dec 14 14:54:07 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Dec 2016 09:54:07 -0500 Subject: [Freeipa-users] ACIerrors is httpd log In-Reply-To: <20726A29-B7D0-4C40-8D3A-35AE87597F5A@placeiq.com> References: <4B8D5975-7858-4CC2-99AF-FC1E4D6EEB93@placeiq.com> <583C8806.1030809@redhat.com> <5840F109.1040507@redhat.com> <5BEF9BE5-D289-4616-BC11-A02CE4366877@placeiq.com> <5841F5B9.1060405@redhat.com> <20726A29-B7D0-4C40-8D3A-35AE87597F5A@placeiq.com> Message-ID: <58515D0F.9020802@redhat.com> Jim Richard wrote: > just now getting back to this, have been truncating httpd logs via cron > since then to keep from filing up my disk. > > So, does this ring any bells :) No but the complete, unredacted logs were VERY helpful, thanks. So the code looks like this in 3.0, which IIRC you are running: try: self.check_access() except errors.ACIError, acierr: self.debug("Not granted by ACI to retrieve certificate, looking at principal") bind_principal = getattr(context, 'principal') if not bind_principal.startswith('host/'): raise acierr By default hosts aren't in the ACI that allows one to retrieve certs but if you bind as one it is later given a pass. It would seem that is failing, though it is also clear from the log that the client is binding with a host principal, so I'm baffled. I think it would probably be best to add more debug logging around these lines to try to see what is going on, something like: self.debug("bind_principal = %s", bind_principal) And then later, the same aci error can be raised after checking the hostname. I'd add in a debug log there too, to look soemthing like: if hostname != cert.subject.common_name: #pylint: disable=E1101 self.debug('hostname %s doesn't match subject %s', hostname, cert.subject.common_name) raise acierr You'd make these changes in /usr/lib/python2.7/site-packages/ipalib/plugins/cert.py then restart httpd. I'd make a backup of the file first to make reverting easier. rob > > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: IPA: virtual verify > retrieve certificate > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: Not granted by ACI to > retrieve certificate, looking at principal > [Wed Dec 14 00:38:39 2016] [error] ipa: INFO: > host/phoenix-168.nym1.placeiq.net at PLACEIQ.NET > : > cert_request(u'MIID4zCCAssCAQAwPTEUMBIGA1UEChMLUExBQ0VJUS5ORVQxJTAjBgNVBAMTHHBob2VuaXgtMTY4Lm55bTEucGxhY2VpcS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDboyDDyTaP4+LxYThfy1w7C67TN2qBp8JjA7Y55gnthyUp/PUUXmm3FUQ4yG4cBqDSxZcUWzl+eA33/ceSIp0HtVl34ZkkUitY1hmUvu2nh16ReR65YC+qRqkAIypOilLdPzXIWZ7u5LbM/Xpj3/Npzm18UupAAznNXkZnojuPmAQ+ulPGypyefLnhr5my6hIaR1atTm1ZvHTG3raMJOJhFe4jMeI/tgPVdNCUfOUdEKhmmCm5KivxhTtHMEcH+8obuQnbaSokJscxlzHBLiyQGqhAn5gznXg0mlVCC0H4mwdB1g2g9cG+SxSua/7XCm+AnGXlc75MZAt594QBTc3fAgMBAAGgggFfMHsGCSqGSIb3DQEJFDFuHmwASQBQAEEAIABNAGEAYwBoAGkAbgBlACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAALQAgAHAAaABvAGUAbgBpAHgALQAxADYAOAAuAG4AeQBtADEALgBwAGwAYQBjAGUAaQBxAC4AbgBlAHQwgd8GCSqGSIb3DQEJDjGB0TCBzjCBmwYDVR0RAQEABIGQMIGNoD0GCisGAQQBgjcUAgOgLwwtaG9zdC9waG9lbml4LTE2OC5ueW0xLnBsYWNlaXEubmV0QFBMQUNFSVEuTkVUoEwGBisGAQUCAqBCMECgDRsLUExBQ0VJUS5ORVShLzAtoAMCAQGhJjAkGwRob3N0GxxwaG9lbml4LTE2OC5ueW0xLnBsYWNlaXEubmV0MAwGA1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFKDhj0rZ6mZwJfrJx3pCI12dct5WMA0GCSqG! SIb3DQEBCw UAA4IBAQC/zeFtiiiJXi9bws2NWx2u/vB7aTVRci2yb9wb70dUzcpeJ3qRTqsE5I+D3MHxLYnixrG4iMEaWgEyuJy4SIWqW1YVSrHwhJZufyRnxy7luNXON+TBBBI0Gro5gICy9XiDKbA/q6clYzEbwDLe6Es/U5/h4Bl/ziV61KYCJN0P1bMWI21A73iP3EQHx2lefYxI8BJN68hJLQiK+E0IWGCqfvipTHA0bHYSQy6WFmmS96v0wr93jy783iromycZeXWzFJyx+LruVPmPOewmUOJ2Y2NJNPJv35pPYUw5Dt2hlLgWZ18po8C+XYqvMbzxM2DFlxMX3Ff+ZiwCRYSGknFI', > principal=u'host/phoenix-168.nym1.placeiq.net at PLACEIQ.NET > ', > add=True): ACIError > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: response: ACIError: > Insufficient access: Gettext('not allowed to perform this command', > domain='ipa', localedir=None) > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: no session id in request, > generating empty session data with id=9beb89831ebfca453453ad48feaaa4d0 > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: store session: > session_id=9beb89831ebfca453453ad48feaaa4d0 > start_timestamp=2016-12-14T00:38:39 access_timestamp=2016-12-14T00:38:39 > expiration_timestamp=1970-01-01T00:00:00 > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: > finalize_kerberos_acquisition: xmlserver > ccache_name="FILE:/tmp/krb5cc_apache_SQg9kf" > session_id="9beb89831ebfca453453ad48feaaa4d0" > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: reading ccache data from > file "/tmp/krb5cc_apache_SQg9kf" > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: get_credential_times: > principal=krbtgt/PLACEIQ.NET at PLACEIQ.NET > , authtime=12/14/16 > 00:38:36, starttime=12/14/16 00:38:37, endtime=12/15/16 00:38:36, > renew_till=01/01/70 00:00:00 > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: KRB5_CCache > FILE:/tmp/krb5cc_apache_SQg9kf endtime=1481762316 (12/15/16 00:38:36) > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: > set_session_expiration_time: duration_type=inactivity_timeout > duration=1200 max_age=1481762016 expiration=1481677119.46 > (2016-12-14T00:58:39) > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: store session: > session_id=9beb89831ebfca453453ad48feaaa4d0 > start_timestamp=2016-12-14T00:38:39 access_timestamp=2016-12-14T00:38:39 > expiration_timestamp=2016-12-14T00:58:39 > [Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: Destroyed connection > context.ldap2 > > > > > > Jim Richard > > > > SYSTEM ADMINISTRATOR III > /(646) 338-8905 / > > > PlaceIQ:Alibaba > > > > > >> On Dec 2, 2016, at 5:29 PM, Rob Crittenden > > wrote: >> >> Jim Richard wrote: >>> Hmm ya. So before I rebuilt anything I thought maybe it was my DNS >>> records but it looks like that?s not it. >>> >>> More background, I used to have sso-109 and sso-110, both CA?s. I >>> rebuilt sso-110 without CA. >>> >>> My DNS is external, BIND on another host. >>> >>> Using the following (at the end of the message) host/key issue as an >>> example. On this host, in sssd.conf, ipa_server and krb5_server values >>> are both _srv_ so that means they?ll discover from DNS right? >>> >>> But in my krb5.conf I have: >>> >>> [realms] >>> PLACEIQ.NET = { >>> kdc = sso-110.nym1.placeiq.net >>> :88 >>> master_kdc = sso-110.nym1.placeiq.net >>> >>> :88 >>> admin_server = sso-110.nym1.placeiq.net >>> >>> :749 >>> default_domain = placeiq.net >>> pkinit_anchors = FILE:/etc/ipa/ca.crt >>> } >>> >>> >>> Is there any other IPA related config file that might reference a >>> host name? >>> >>> I?ll include my DNS records at the end here, do they look correct for a >>> two server setup, one with a CA (sso-109) and the other no CA (sso-110)? >>> >>> I never have been sure about the ?kerberos-master? entries, what makes >>> an IPA host a ?kerberos master? and is this related to the CA in any way? >>> >>> ; ldap servers >>> _ldap._tcp IN SRV 0 100 389 sso-109.nym1.placeiq.net >>> >>> . >>> _ldap._tcp IN SRV 0 100 389 sso-110.nym1.placeiq.net >>> >>> . >>> >>> ;kerberos realm >>> _kerberos IN TXT PLACEIQ.NET >>> >>> >>> ; kerberos servers >>> _kerberos._tcp IN SRV 0 100 88 >>> sso-109.nym1.placeiq.net >>> . >>> _kerberos._tcp IN SRV 0 100 88 >>> sso-110.nym1.placeiq.net >>> . >>> >>> _kerberos._udp IN SRV 0 100 88 >>> sso-109.nym1.placeiq.net >>> . >>> _kerberos._udp IN SRV 0 100 88 >>> sso-110.nym1.placeiq.net >>> . >>> >>> _kerberos-master._tcp IN SRV 0 100 88 >>> sso-109.nym1.placeiq.net >>> . >>> _kerberos-master._udp IN SRV 0 100 88 >>> sso-109.nym1.placeiq.net >>> . >>> _kerberos-adm._tcp IN SRV 0 100 749 >>> sso-109.nym1.placeiq.net >>> . >>> _kerberos-adm._udp IN SRV 0 100 749 >>> sso-109.nym1.placeiq.net >>> . >>> >>> _kpasswd._tcp IN SRV 0 100 464 >>> sso-109.nym1.placeiq.net >>> . >>> _kpasswd._tcp IN SRV 0 100 464 >>> sso-110.nym1.placeiq.net >>> . >>> >>> _kpasswd._udp IN SRV 0 100 464 >>> sso-109.nym1.placeiq.net >>> . >>> _kpasswd._udp IN SRV 0 100 464 >>> sso-110.nym1.placeiq.net >>> . >>> >>> ; CNAME for IPA CA replicas (used for CRL, OCSP) >>> ipa-ca IN A 10.1.41.109 >>> >>> >>> >>> Number of certificates and requests being tracked: 1. >>> Request ID '20141110221330': >>> status: MONITORING >>> ca-error: Server at https://sso-110.nym1.placeiq.net/ipa/xml >>> denied our request, giving up: 2100 (RPC failed at server. Insufficient >>> access: not allowed to perform this command). >>> stuck: no >>> key pair storage: >>> type=NSSDB,location='/etc/pki/nssdb',nickname='IPA Machine Certificate - >>> phoenix-142.nym1.placeiq.net >>> ',token='NSS Certificate DB' >>> certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='IPA >>> Machine Certificate - phoenix-142.nym1.placeiq.net >>> ',token='NSS Certificate DB' >>> CA: IPA >>> issuer: CN=Certificate Authority,O=PLACEIQ.NET >>> >>> subject: CN=phoenix-142.nym1.placeiq.net >>> ,O=PLACEIQ.NET >>> expires: 2016-11-10 22:13:31 UTC >>> key usage: >>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >>> eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: >>> post-save command: >>> track: yes >>> auto-renew: yes >>> >>> >>> >>> We are moving to latest version on RHEL so we?ll have paid support but >>> before than, gaining this understanding is massively valuable :) >> >> I'm pretty certain this has nothing to do with servers being removed. >> IPA isn't saying it can't find something, it's saying you aren't allowed >> to do something. >> >> Why that is the case I don't know. A way to maybe find out would involve >> enabling debugging on the server. You can do this by creating >> /etc/ipa/server.conf with these contents: >> >> [global] >> debug=True >> >> Restart httpd and watch. I'd leave it on just long enough to see the >> problem, then turn it off again given you are already having disk space >> issues. >> >> There is no way to dynamically do this w/o restarting the service. >> >> rob >> > From jamesaharrisonuk at yahoo.co.uk Wed Dec 14 15:18:52 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Wed, 14 Dec 2016 15:18:52 +0000 (UTC) Subject: [Freeipa-users] Free IPA Openssh client install error References: <786768425.4911135.1481728732808.ref@mail.yahoo.com> Message-ID: <786768425.4911135.1481728732808@mail.yahoo.com> Hi,I installed the freeipa client on an Ubuntu Precise system (12.04) I get the following message at the end of the install: "Installed OpenSSH server does not support dynamically loading authorized user keys. Public key authentication of IPA users will not be available." Any clues? Is there a fix? Best regards,James Harrison -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Wed Dec 14 15:39:24 2016 From: sbose at redhat.com (Sumit Bose) Date: Wed, 14 Dec 2016 16:39:24 +0100 Subject: [Freeipa-users] Free IPA Openssh client install error In-Reply-To: <786768425.4911135.1481728732808@mail.yahoo.com> References: <786768425.4911135.1481728732808.ref@mail.yahoo.com> <786768425.4911135.1481728732808@mail.yahoo.com> Message-ID: <20161214153924.GL15074@p> On Wed, Dec 14, 2016 at 03:18:52PM +0000, James Harrison wrote: > Hi,I installed the freeipa client on an Ubuntu Precise system (12.04) > > I get the following message at the end of the install: > "Installed OpenSSH server does not support dynamically loading authorized user keys. Public key authentication of IPA users will not be available." > > Any clues? Is there a fix? Either OpenSSH on Ubuntu 12.04 does not support the AuthorizedKeysCommand sshd option or the checks ipa-client-install is trying do not match. ipa-client-install calls sshd -t -f /dev/null -o AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys -o AuthorizedKeysCommandUser=nobody to check if sshd supports the option. It also tries 'AuthorizedKeysCommand' with 'AuthorizedKeysCommandRunAs' and 'PubKeyAgent' with 'PubKeyAgentRunAs'. Do you see related messages in /var/log/ipaclient-install.log ? HTH bye, Sumit > > Best regards,James Harrison > -- > Manage your subscription for 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 jamesaharrisonuk at yahoo.co.uk Wed Dec 14 15:47:52 2016 From: jamesaharrisonuk at yahoo.co.uk (James Harrison) Date: Wed, 14 Dec 2016 15:47:52 +0000 (UTC) Subject: [Freeipa-users] Free IPA Openssh client install error In-Reply-To: <786768425.4911135.1481728732808@mail.yahoo.com> References: <786768425.4911135.1481728732808.ref@mail.yahoo.com> <786768425.4911135.1481728732808@mail.yahoo.com> Message-ID: <863043119.4951356.1481730472746@mail.yahoo.com> In the ipaclient-install.log I see: 2016-12-14T14:58:10Z DEBUG stderr= 2016-12-14T14:58:10Z DEBUG Backing up system configuration file '/etc/ssh/ssh_config' 2016-12-14T14:58:10Z DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' 2016-12-14T14:58:10Z INFO Configured /etc/ssh/ssh_config 2016-12-14T14:58:10Z DEBUG Backing up system configuration file '/etc/ssh/sshd_config' 2016-12-14T14:58:10Z DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' 2016-12-14T14:58:10Z DEBUG Starting external process 2016-12-14T14:58:10Z DEBUG args=sshd -t -f /dev/null -o AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys -o AuthorizedKeysCommandUser=nobody 2016-12-14T14:58:10Z DEBUG Process finished, return code=1 2016-12-14T14:58:10Z DEBUG stdout= 2016-12-14T14:58:10Z DEBUG stderr=command-line: line 0: Bad configuration option: AuthorizedKeysCommand^M 2016-12-14T14:58:10Z DEBUG Starting external process 2016-12-14T14:58:10Z DEBUG args=sshd -t -f /dev/null -o AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys -o AuthorizedKeysCommandRunAs=nobody 2016-12-14T14:58:10Z DEBUG Process finished, return code=1 2016-12-14T14:58:10Z DEBUG stdout= 2016-12-14T14:58:10Z DEBUG stderr=command-line: line 0: Bad configuration option: AuthorizedKeysCommand^M 2016-12-14T14:58:10Z DEBUG Starting external process 2016-12-14T14:58:10Z DEBUG args=sshd -t -f /dev/null -o PubKeyAgent=/usr/bin/sss_ssh_authorizedkeys %u -o PubKeyAgentRunAs=nobody 2016-12-14T14:58:10Z DEBUG Process finished, return code=1 2016-12-14T14:58:10Z DEBUG stdout= 2016-12-14T14:58:10Z DEBUG stderr=command-line: line 0: Bad configuration option: PubKeyAgent^M 2016-12-14T14:58:10Z WARNING Installed OpenSSH server does not support dynamically loading authorized user keys. Public key authentication of IPA users will not be available. From: James Harrison To: "freeipa-users at redhat.com" Sent: Wednesday, 14 December 2016, 15:18 Subject: Free IPA Openssh client install error Hi,I installed the freeipa client on an Ubuntu Precise system (12.04) I get the following message at the end of the install: "Installed OpenSSH server does not support dynamically loading authorized user keys. Public key authentication of IPA users will not be available." Any clues? Is there a fix? Best regards,James Harrison -------------- next part -------------- An HTML attachment was scrubbed... URL: From heralt at gmail.com Wed Dec 14 15:59:02 2016 From: heralt at gmail.com (Serhii Honchar) Date: Wed, 14 Dec 2016 15:59:02 +0000 Subject: [Freeipa-users] FreeIPA and vSphere Message-ID: Hello, trying to get vSphere authenticate users using FreeIPA. I've made scheme changes as recommended in howto http://www.freeipa.org/page/HowTo/vsphere5_integration. But then faced following issue: Vsphere using "pagedResultsControl" and sets it's criticality to "True" on all it's requests to LDAP server: --- Lightweight Directory Access Protocol LDAPMessage searchRequest(2) "cn=users,cn=compat,dc=XXX,dc=XXX" wholeSubtree messageID: 2 protocolOp: searchRequest (3) [Response In: 17] * controls: 1 item * * Control * * controlType: 1.2.840.113556.1.4.319 (pagedResultsControl) * * criticality: True * * SearchControlValue * * size: 100 * * cookie: * --- When requesting from "cn=accounts" subtree things go ok, and reply also contain "pagedResultsControl" block: --- Lightweight Directory Access Protocol LDAPMessage searchResDone(2) success [1 result] messageID: 2 protocolOp: searchResDone (5) searchResDone resultCode: success (0) matchedDN: errorMessage: [Response To: 15] [Time: 0.065699000 seconds] * controls: 1 item* * Control* * controlType: 1.2.840.113556.1.4.319 (pagedResultsControl)* * SearchControlValue* * size: 0* * cookie: * --- and vSphere accepts the results of such queries without any problem, except the fact that there are no some required attributes in objects in this subtree. But on same requests to "cn=compat" subtree (where all required attributes added) something goest wrong, and replies doesn't contain "pagedResultsControl" block (the result set itself is identical, absence of controls block is only difference) : --- Lightweight Directory Access Protocol LDAPMessage searchResDone(2) success [1 result] messageID: 2 protocolOp: searchResDone (5) [Response To: 15] [Time: 0.001349000 seconds] --- Thus vSphere doesn't accept the results of queries to "cn=compat" subtree regardless of their results. Such behavior also seems to be violating RFC2696 which stands: --- If the server does not support this control, the server MUST return an error of unsupportedCriticalExtension if the client requested it as critical, otherwise the server SHOULD ignore the control. The remainder of this section assumes the server does not ignore the client's pagedResultsControl. Each time the server returns a set of results to the client when processing a search request containing the pagedResultsControl, the server includes the pagedResultsControl control in the searchResultDone message. --- Please help me to find the answers for following questions: 1) why the replies for the requests to "cn=compat" subtree don't contain controls block? 2) is it possible to configure ns-slapd/slapi-nis to force replies for queries to "cn=compat" subtree either to return a unsupportedCriticalExtension or to contain a valid control block in case when the request contains controls with "criticality" set to "True"? -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Dec 14 16:24:31 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 14 Dec 2016 18:24:31 +0200 Subject: [Freeipa-users] FreeIPA and vSphere In-Reply-To: References: Message-ID: <20161214162431.3swqt4h3slw62zya@redhat.com> On ke, 14 joulu 2016, Serhii Honchar wrote: >Hello, > >trying to get vSphere authenticate users using FreeIPA. >I've made scheme changes as recommended in howto >http://www.freeipa.org/page/HowTo/vsphere5_integration. >But then faced following issue: >Vsphere using "pagedResultsControl" and sets it's criticality to "True" on >all it's requests to LDAP server: >--- >Lightweight Directory Access Protocol > LDAPMessage searchRequest(2) "cn=users,cn=compat,dc=XXX,dc=XXX" >wholeSubtree > messageID: 2 > protocolOp: searchRequest (3) > [Response In: 17] > * controls: 1 item * >* Control * >* controlType: 1.2.840.113556.1.4.319 (pagedResultsControl) * >* criticality: True * >* SearchControlValue * >* size: 100 * >* cookie: * >--- > >When requesting from "cn=accounts" subtree things go ok, and reply also >contain "pagedResultsControl" block: >--- >Lightweight Directory Access Protocol > LDAPMessage searchResDone(2) success [1 result] > messageID: 2 > protocolOp: searchResDone (5) > searchResDone > resultCode: success (0) > matchedDN: > errorMessage: > [Response To: 15] > [Time: 0.065699000 seconds] > * controls: 1 item* >* Control* >* controlType: 1.2.840.113556.1.4.319 (pagedResultsControl)* >* SearchControlValue* >* size: 0* >* cookie: * >--- >and vSphere accepts the results of such queries without any problem, except >the fact that there are no some required attributes in objects in this >subtree. > >But on same requests to "cn=compat" subtree (where all required attributes >added) something goest wrong, and replies doesn't contain >"pagedResultsControl" block (the result set itself is identical, absence of >controls block is only difference) : That's correct because slapi-nis plugin does not support paged results control for the virtual subtree. -- / Alexander Bokovoy From heralt at gmail.com Wed Dec 14 16:34:35 2016 From: heralt at gmail.com (Serhii Honchar) Date: Wed, 14 Dec 2016 16:34:35 +0000 Subject: [Freeipa-users] FreeIPA and vSphere In-Reply-To: <20161214162431.3swqt4h3slw62zya@redhat.com> References: <20161214162431.3swqt4h3slw62zya@redhat.com> Message-ID: Alexander, as per RFC2696 in such case: --- If the server does not support this control, the server MUST return an error of unsupportedCriticalExtension if the client requested it as critical, --- So in case slapi-nis plugin doesn't support "paged results control", it is quite incorrect to absolutely ignore control regardless of their "criticality". To comply with RFC2696 slapi-nis plugin shall reply with "unsupportedCriticalExtension" error in such cases. Am i right? ??, 14 ????. 2016 ? 18:24 Alexander Bokovoy ????: > On ke, 14 joulu 2016, Serhii Honchar wrote: > >Hello, > > > >trying to get vSphere authenticate users using FreeIPA. > >I've made scheme changes as recommended in howto > >http://www.freeipa.org/page/HowTo/vsphere5_integration. > >But then faced following issue: > >Vsphere using "pagedResultsControl" and sets it's criticality to "True" on > >all it's requests to LDAP server: > >--- > >Lightweight Directory Access Protocol > > LDAPMessage searchRequest(2) "cn=users,cn=compat,dc=XXX,dc=XXX" > >wholeSubtree > > messageID: 2 > > protocolOp: searchRequest (3) > > [Response In: 17] > > * controls: 1 item * > >* Control * > >* controlType: 1.2.840.113556.1.4.319 > (pagedResultsControl) * > >* criticality: True * > >* SearchControlValue * > >* size: 100 * > >* cookie: * > >--- > > > >When requesting from "cn=accounts" subtree things go ok, and reply also > >contain "pagedResultsControl" block: > >--- > >Lightweight Directory Access Protocol > > LDAPMessage searchResDone(2) success [1 result] > > messageID: 2 > > protocolOp: searchResDone (5) > > searchResDone > > resultCode: success (0) > > matchedDN: > > errorMessage: > > [Response To: 15] > > [Time: 0.065699000 seconds] > > * controls: 1 item* > >* Control* > >* controlType: 1.2.840.113556.1.4.319 > (pagedResultsControl)* > >* SearchControlValue* > >* size: 0* > >* cookie: * > >--- > >and vSphere accepts the results of such queries without any problem, > except > >the fact that there are no some required attributes in objects in this > >subtree. > > > >But on same requests to "cn=compat" subtree (where all required attributes > >added) something goest wrong, and replies doesn't contain > >"pagedResultsControl" block (the result set itself is identical, absence > of > >controls block is only difference) : > That's correct because slapi-nis plugin does not support paged results > control for the virtual subtree. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dag at sonsorol.org Wed Dec 14 16:50:26 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 14 Dec 2016 11:50:26 -0500 Subject: [Freeipa-users] Confirming no extra/special ports need to be opened for replication traffic? Message-ID: <58517852.7070401@sonsorol.org> Been reading various generations of documentation to find out if I need additional TCP or UDP ports opened for IPA replication between VPN-connected dataceners. I think the modern answer is no? We just need the standard IPA ports open between all of the IPA master/replicas that chat to each other? TCP Ports: * 80, 443: HTTP/HTTPS * 389, 636: LDAP/LDAPS * 88, 464: kerberos * 53: bind UDP Ports: * 88, 464: kerberos * 53: bind * 123: ntp -Chris From mbabinsk at redhat.com Wed Dec 14 17:17:15 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Wed, 14 Dec 2016 18:17:15 +0100 Subject: [Freeipa-users] Confirming no extra/special ports need to be opened for replication traffic? In-Reply-To: <58517852.7070401@sonsorol.org> References: <58517852.7070401@sonsorol.org> Message-ID: <5515ddc0-e40f-c06c-c1dd-9e77b297271e@redhat.com> On 12/14/2016 05:50 PM, Chris Dagdigian wrote: > > Been reading various generations of documentation to find out if I need > additional TCP or UDP ports opened for IPA replication between > VPN-connected dataceners. > > I think the modern answer is no? We just need the standard IPA ports > open between all of the IPA master/replicas that chat to each other? > > TCP Ports: > * 80, 443: HTTP/HTTPS > * 389, 636: LDAP/LDAPS > * 88, 464: kerberos > * 53: bind > UDP Ports: > * 88, 464: kerberos > * 53: bind > * 123: ntp > > > -Chris > > Hi Chris, IIRC in IPA v3.0 there was 7389 port used for CA replication, but in more recent versions this is not required anymore. -- Martin^3 Babinsky From abokovoy at redhat.com Wed Dec 14 17:29:10 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 14 Dec 2016 19:29:10 +0200 Subject: [Freeipa-users] FreeIPA and vSphere In-Reply-To: References: <20161214162431.3swqt4h3slw62zya@redhat.com> Message-ID: <20161214172910.356xqy2id3gdrrtq@redhat.com> On ke, 14 joulu 2016, Serhii Honchar wrote: >Alexander, >as per RFC2696 in such case: >--- > >If the server does not support this control, the server > MUST return an error of unsupportedCriticalExtension if the client > requested it as critical, > >--- >So in case slapi-nis plugin doesn't support "paged results control", it is >quite incorrect to absolutely ignore control regardless of their >"criticality". To comply with RFC2696 slapi-nis plugin shall reply >with "unsupportedCriticalExtension" >error in such cases. Am i right? That's right, but slapi-nis never supported paged search results before and I'm not sure we want it to do that with the current code as it is not trivial at all. You may file a bug about paged results but I suspect it will start working with the refactoring of slapi-nis we plan for global catalog support in FreeIPA 4.5/4.6 where we'll move content of the slapi-nis virtual memory cache to a proper database backend in a separate 389-ds instance. -- / Alexander Bokovoy From dag at sonsorol.org Wed Dec 14 17:34:27 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 14 Dec 2016 12:34:27 -0500 Subject: [Freeipa-users] Confirming no extra/special ports need to be opened for replication traffic? In-Reply-To: <5515ddc0-e40f-c06c-c1dd-9e77b297271e@redhat.com> References: <58517852.7070401@sonsorol.org> <5515ddc0-e40f-c06c-c1dd-9e77b297271e@redhat.com> Message-ID: <585182A3.1080900@sonsorol.org> Much appreciated, thank you! Martin Babinsky wrote: > IIRC in IPA v3.0 there was 7389 port used for CA replication, but in > more recent versions this is not required anymore. From tommy.nikjoo at armourcomms.com Wed Dec 14 17:35:35 2016 From: tommy.nikjoo at armourcomms.com (Tommy Nikjoo) Date: Wed, 14 Dec 2016 17:35:35 +0000 Subject: [Freeipa-users] ipa-server-install fails at DogTag restart Message-ID: <6d359fec-b985-1daf-475f-f2ff503964b7@armourcomms.com> Hi, I'm trying to install FreeIPA on CentOS 7 using the yum package, but I keep getting an error when it tries to restart DogTag [26/31]: restarting certificate server ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart the Dogtag instance.See the installation log for details. [27/31]: migrating certificate profiles to LDAP [error] NetworkError: cannot connect to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': '' ipa.ipapython.install.cli.install_tool(Server): ERROR cannot connect to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': '' ipa.ipapython.install.cli.install_tool(Server): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information The log shows the following error 2016-12-14T16:53:05Z DEBUG NSSConnection init ldap.example.com 2016-12-14T16:53:05Z DEBUG Connecting: x.x.x.x:0 2016-12-14T16:53:05Z DEBUG approved_usage = SSL Server intended_usage = SSL Server 2016-12-14T16:53:05Z DEBUG cert valid True for "CN=ldap.example.com,O=EXAMPLE.COM" 2016-12-14T16:53:05Z DEBUG handshake complete, peer = x.x.x.x:8443 2016-12-14T16:53:05Z DEBUG Protocol: TLS1.2 2016-12-14T16:53:05Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA 2016-12-14T16:53:05Z DEBUG response status 200 2016-12-14T16:53:05Z DEBUG response headers {'content-length': '205', 'set-cookie': 'JSESSIONID=9B6C767CDBED07088646235E68E831E0; Path=/ca/; Secure; HttpOnly', 'expires': 'Thu, 01 Jan 1970 00:00:00 UTC', 'server': 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed, 14 Dec 2016 16:53:05 GMT', 'content-type': 'application/xml'} 2016-12-14T16:53:05Z DEBUG response body 'iparaCertificate Manager AgentsRegistration Manager Agents' 2016-12-14T16:53:05Z DEBUG request POST https://ldap.example.com:8443/ca/rest/profiles/raw 2016-12-14T16:53:05Z DEBUG request body 'profileId=IECUserRoles\nclassId=caEnrollImpl\ndesc=Enroll user certificates with IECUserRoles extension via IPA-RA agent authentication.\nvisible=false\nenable=true\nenableBy=admin\nauth.instance_id=raCertAuth\nname=IPA-RA Agent-Authenticated Server Certificate Enrollment\ninput.list=i1,i2\ninput.i1.class_id=certReqInputImpl\ninput.i2.class_id=submitterInfoInputImpl\noutput.list=o1\noutput.o1.class_id=certOutputImpl\npolicyset.list=serverCertSet\npolicyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12\npolicyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl\npolicyset.serverCertSet.1.constraint.name=Subject Name Constraint\npolicyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+\npolicyset.serverCertSet.1.constraint.params.accept=true\npolicyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl\npolicyset.serverCertSet.1.default.name=Subject Name Default\npolicyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, O=EXAMPLE.COM\npolicyset.serverCertSet.2.constraint.class_id=validityConstraintImpl\npolicyset.serverCertSet.2.constraint.name=Validity Constraint\npolicyset.serverCertSet.2.constraint.params.range=740\npolicyset.serverCertSet.2.constraint.params.notBeforeCheck=false\npolicyset.serverCertSet.2.constraint.params.notAfterCheck=false\npolicyset.serverCertSet.2.default.class_id=validityDefaultImpl\npolicyset.serverCertSet.2.default.name=Validity Default\npolicyset.serverCertSet.2.default.params.range=731\npolicyset.serverCertSet.2.default.params.startTime=0\npolicyset.serverCertSet.3.constraint.class_id=keyConstraintImpl\npolicyset.serverCertSet.3.constraint.name=Key Constraint\npolicyset.serverCertSet.3.constraint.params.keyType=RSA\npolicyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096\npolicyset.serverCertSet.3.default.class_id=userKeyDefaultImpl\npolicyset.serverCertSet.3.default.name=Key Default\npolicyset.serverCertSet.4.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.4.constraint.name=No Constraint\npolicyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.4.default.name=Authority Key Identifier Default\npolicyset.serverCertSet.5.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.5.constraint.name=No Constraint\npolicyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl\npolicyset.serverCertSet.5.default.name=AIA Extension Default\npolicyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true\npolicyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName\npolicyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp\npolicyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1\npolicyset.serverCertSet.5.default.params.authInfoAccessCritical=false\npolicyset.serverCertSet.5.default.params.authInfoAccessNumADs=1\npolicyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl\npolicyset.serverCertSet.6.constraint.name=Key Usage Extension Constraint\npolicyset.serverCertSet.6.constraint.params.keyUsageCritical=true\npolicyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true\npolicyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true\npolicyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyCertSign=false\npolicyset.serverCertSet.6.constraint.params.keyUsageCrlSign=false\npolicyset.serverCertSet.6.constraint.params.keyUsageEncipherOnly=false\npolicyset.serverCertSet.6.constraint.params.keyUsageDecipherOnly=false\npolicyset.serverCertSet.6.default.class_id=keyUsageExtDefaultImpl\npolicyset.serverCertSet.6.default.name=Key Usage Default\npolicyset.serverCertSet.6.default.params.keyUsageCritical=true\npolicyset.serverCertSet.6.default.params.keyUsageDigitalSignature=true\npolicyset.serverCertSet.6.default.params.keyUsageNonRepudiation=true\npolicyset.serverCertSet.6.default.params.keyUsageDataEncipherment=true\npolicyset.serverCertSet.6.default.params.keyUsageKeyEncipherment=true\npolicyset.serverCertSet.6.default.params.keyUsageKeyAgreement=false\npolicyset.serverCertSet.6.default.params.keyUsageKeyCertSign=false\npolicyset.serverCertSet.6.default.params.keyUsageCrlSign=false\npolicyset.serverCertSet.6.default.params.keyUsageEncipherOnly=false\npolicyset.serverCertSet.6.default.params.keyUsageDecipherOnly=false\npolicyset.serverCertSet.7.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.7.constraint.name=No Constraint\npolicyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl\npolicyset.serverCertSet.7.default.name=Extended Key Usage Extension Default\npolicyset.serverCertSet.7.default.params.exKeyUsageCritical=false\npolicyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2\npolicyset.serverCertSet.8.constraint.class_id=signingAlgConstraintImpl\npolicyset.serverCertSet.8.constraint.name=No Constraint\npolicyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC\npolicyset.serverCertSet.8.default.class_id=signingAlgDefaultImpl\npolicyset.serverCertSet.8.default.name=Signing Alg\npolicyset.serverCertSet.8.default.params.signingAlg=-\npolicyset.serverCertSet.9.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.9.constraint.name=No Constraint\npolicyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl\npolicyset.serverCertSet.9.default.name=CRL Distribution Points Extension Default\npolicyset.serverCertSet.9.default.params.crlDistPointsCritical=false\npolicyset.serverCertSet.9.default.params.crlDistPointsNum=1\npolicyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true\npolicyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate Authority,o=ipaca\npolicyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName\npolicyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://ipa-ca.example.com/ipa/crl/MasterCRL.bin\npolicyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName\npolicyset.serverCertSet.9.default.params.crlDistPointsReasons_0=\npolicyset.serverCertSet.10.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.10.constraint.name=No Constraint\npolicyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.10.default.name=Subject Key Identifier Extension Default\npolicyset.serverCertSet.10.default.params.critical=false\npolicyset.serverCertSet.11.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.11.constraint.name=No Constraint\npolicyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl\npolicyset.serverCertSet.11.default.name=User Supplied Extension Default\npolicyset.serverCertSet.11.default.params.userExtOID=2.5.29.17\npolicyset.serverCertSet.12.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.12.constraint.name=No Constraint\npolicyset.serverCertSet.12.default.class_id=userExtensionDefaultImpl\npolicyset.serverCertSet.12.default.name=IECUserRoles Extension Default\npolicyset.serverCertSet.12.default.params.userExtOID=1.2.840.10070.8.1\n' Is there anything I can do to get around this? Thanks, Tommy From simo at redhat.com Wed Dec 14 18:16:01 2016 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Dec 2016 13:16:01 -0500 Subject: [Freeipa-users] FreeIPA and vSphere In-Reply-To: <20161214172910.356xqy2id3gdrrtq@redhat.com> References: <20161214162431.3swqt4h3slw62zya@redhat.com> <20161214172910.356xqy2id3gdrrtq@redhat.com> Message-ID: <1481739361.3127.89.camel@redhat.com> On Wed, 2016-12-14 at 19:29 +0200, Alexander Bokovoy wrote: > On ke, 14 joulu 2016, Serhii Honchar wrote: > >Alexander, > >as per RFC2696 in such case: > >--- > > > >If the server does not support this control, the server > > MUST return an error of unsupportedCriticalExtension if the client > > requested it as critical, > > > >--- > >So in case slapi-nis plugin doesn't support "paged results control", it is > >quite incorrect to absolutely ignore control regardless of their > >"criticality". To comply with RFC2696 slapi-nis plugin shall reply > >with "unsupportedCriticalExtension" > >error in such cases. Am i right? > That's right, but slapi-nis never supported paged search results before > and I'm not sure we want it to do that with the current code as it is > not trivial at all. > > You may file a bug about paged results but I suspect it will start > working with the refactoring of slapi-nis we plan for global catalog > support in FreeIPA 4.5/4.6 where we'll move content of the slapi-nis > virtual memory cache to a proper database backend in a separate 389-ds > instance. Yes it is definitely a bug, but not an easy fix, please do file a bug, however it will take some time before we can fix it. Simo. -- Simo Sorce * Red Hat, Inc * New York From beeth2006 at gmail.com Wed Dec 14 18:49:04 2016 From: beeth2006 at gmail.com (beeth beeth) Date: Wed, 14 Dec 2016 13:49:04 -0500 Subject: [Freeipa-users] Failed ipa-client-install with IPA Replica In-Reply-To: References: <794d723f-9994-2281-1add-c5d0d1167257@redhat.com> Message-ID: Hi Flo, Thanks for the great hint! I reran the ipa-client-install on the rhel6 box(ipadev6), and monitored the access log file you mentioned on the replica: # ipa-client-install --domain=ipa.example.com --server=ipaprd2.example.com --hostname=ipadev6.example.com -d ( ipaprd2 = primary IPA server on RHEL7; ipadev6 = replica on RHEL6 ) AFTER about 3 seconds, I saw these on the replica ipaprd2: [14/Dec/2016:13:11:41.071421132 -0500] conn=1040 fd=73 slot=73 connection from to [14/Dec/2016:13:11:41.071880026 -0500] conn=1040 op=0 EXT oid="1.3.6.1.4.1.1466.20037" [14/Dec/2016:13:11:41.071964217 -0500] conn=1040 op=0 RESULT err=2 tag=120 nentries=0 etime=0 [14/Dec/2016:13:11:41.073275674 -0500] conn=1040 op=1 UNBIND [14/Dec/2016:13:11:41.073307101 -0500] conn=1040 op=1 fd=73 closed - U1 [14/Dec/2016:13:11:41.074782496 -0500] conn=1041 fd=73 slot=73 connection from to [14/Dec/2016:13:11:41.074985233 -0500] conn=1041 op=0 EXT oid="1.3.6.1.4.1.1466.20037" [14/Dec/2016:13:11:41.075022849 -0500] conn=1041 op=0 RESULT err=2 tag=120 nentries=0 etime=0 [14/Dec/2016:13:11:41.075448887 -0500] conn=1041 op=1 UNBIND [14/Dec/2016:13:11:41.075460964 -0500] conn=1041 op=1 fd=73 closed - U1 [14/Dec/2016:13:11:49.006146850 -0500] conn=1029 op=8 UNBIND [14/Dec/2016:13:11:49.006181982 -0500] conn=1029 op=8 fd=66 closed - U1 So I did see the err=2, and oid="1.3.6.1.4.1.1466.20037", I checked the oid and got: 1.3.6.1.4.1.1466.20037: StartTLS Request (RFC 4511) It looked to be related with TLS... pease advise. Thanks! On Wed, Dec 14, 2016 at 7:57 AM, Florence Blanc-Renaud wrote: > On 12/14/2016 01:08 PM, beeth beeth wrote: > >> Thanks David. I installed both the master and replica IPA servers with >> third-party certificates(Verisign), but I doubt that could be the issue, >> because I had no problem to run the same ipa-client-install command on a >> RHEL7 machine(of course, the --hostname used a different hostname of the >> server). And I had no problem to run the ipa-client-install command with >> --server= on such RHEL6 machine. So what could cause the LDAP >> communication failed during the client enrollment with the replica? Is >> there a way I can troubleshoot this by running some commands? So far I >> did telnet to check the open ports, as well as run the ldapsearch >> towards the replica. Thanks again! >> >> >> On Tue, Dec 13, 2016 at 8:46 AM, David Kupka > > wrote: >> >> On 13/12/16 05:44, beeth beeth wrote: >> >> I have two IPA servers ipaprd1.example.com >> and ipaprd2.example.com >> , running >> ipa 4.4 on RHEL7. When I tried to install/configure the client >> on a RHEL6 >> system(called ipadev6), I had issue when I tried to enroll it >> with the >> replica(ipaprd2), while no issue with the primary(ipaprd1): >> >> # ipa-client-install --domain=ipa.example.com >> --server=ipaprd1.example.com >> >> --server=ipaprd2.example.com >> --hostname=ipadev6.example.com >> LDAP Error: Protocol error: unsupported extended operation >> Autodiscovery of servers for failover cannot work with this >> configuration. >> If you proceed with the installation, services will be >> configured to always >> access the discovered server for all operations and will not >> fail over to >> other servers in case of failure. >> Proceed with fixed values and no DNS discovery? [no] >> >> Then I tried to run ipa-client-install to enroll with the >> replica(ipaprd2), >> with debug mode, I got this: >> >> # ipa-client-install --domain=ipa.example.com >> --server=ipaprd2.example.com >> >> --hostname=ipadev6.example.com -d >> /usr/sbin/ipa-client-install was invoked with options: {'domain': >> ' >> ipa.example.com ', 'force': False, >> 'realm_name': None, >> 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir': >> False, >> 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, >> 'on_master': >> False, 'ntp_server': None, 'nisdomain': None, 'no_nisdomain': >> False, >> 'principal': None, 'hostname': 'ipadev6.example.com >> ', 'no_ac': False, >> 'unattended': None, 'sssd': True, 'trust_sshfp': False, >> 'kinit_attempts': >> 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True, >> 'force_join': >> False, 'ca_cert_file': None, 'server': ['ipaprd2.example.com >> '], >> 'prompt_password': False, 'permit': False, 'debug': True, >> 'preserve_sssd': >> False, 'uninstall': False} >> missing options might be asked for interactively later >> Loading Index file from >> '/var/lib/ipa-client/sysrestore/sysrestore.index' >> Loading StateFile from >> '/var/lib/ipa-client/sysrestore/sysrestore.state' >> [IPA Discovery] >> Starting IPA discovery with domain=ipa.example.com >> , servers=[' >> ipaprd2.example.com '], >> hostname=ipadev6.example.com >> Server and domain forced >> [Kerberos realm search] >> Search DNS for TXT record of _kerberos.ipa.example.com >> . >> No DNS record found >> Search DNS for SRV record of _kerberos._udp.ipa.example.com >> . >> No DNS record found >> SRV record for KDC not found! Domain: ipa.example.com >> >> [LDAP server check] >> Verifying that ipaprd2.example.com >> (realm None) is an IPA server >> Init LDAP connection with: ldap://ipaprd2.example.com:389 >> >> LDAP Error: Protocol error: unsupported extended operation >> Discovery result: UNKNOWN_ERROR; server=None, >> domain=ipa.example.com , >> kdc=None, basedn=None >> Validated servers: >> will use discovered domain: ipa.example.com < >> http://ipa.example.com> >> IPA Server not found >> [IPA Discovery] >> Starting IPA discovery with domain=ipa.example.com >> , servers=[' >> ipaprd2.example.com '], >> hostname=ipadev6.example.com >> Server and domain forced >> [Kerberos realm search] >> Search DNS for TXT record of _kerberos.ipa.example.com >> . >> No DNS record found >> Search DNS for SRV record of _kerberos._udp.ipa.example.com >> . >> No DNS record found >> SRV record for KDC not found! Domain: ipa.example.com >> >> [LDAP server check] >> Verifying that ipaprd2.example.com >> (realm None) is an IPA server >> Init LDAP connection with: ldap://ipaprd2.example.com:389 >> >> LDAP Error: Protocol error: unsupported extended operation >> Discovery result: UNKNOWN_ERROR; server=None, >> domain=ipa.example.com , >> kdc=None, basedn=None >> Validated servers: >> Failed to verify that ipaprd2.example.com >> is an IPA Server. >> This may mean that the remote server is not up or is not >> reachable due to >> network or firewall settings. >> Please make sure the following ports are opened in the firewall >> settings: >> TCP: 80, 88, 389 >> UDP: 88 (at least one of TCP/UDP ports 88 has to be open) >> Also note that following ports are necessary for ipa-client >> working >> properly after enrollment: >> TCP: 464 >> UDP: 464, 123 (if NTP enabled) >> (ipaprd2.example.com : Provided as >> option) >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> >> I double checked the services running on the replica, all looked >> well: >> ports are listening, and I could telnet the ports from the >> client(ipadev6). >> I could run "ldapserach" command to talk to the replica(ipaprd2) >> from this >> client(ipadev6), with pulling out all the LDAP records. >> >> Also, I have another test box running RHEL7, and no issue at all >> to run the >> exact same ipa-client-install command on that RHEL7 box. So >> could there be >> a bug on the ipa-client software on RHEL6, to talk to IPA sever >> running on >> RHEL7? Please advise. Thank you! >> >> Hi Beeth, > > you may want to check the access and errors log of the Directory Server in > /var/log/dirsrv/slapd-DOMAIN. The extended operations are logged in the > access log with the tag "EXT oid=...", but a failing operation related to > unsupported extended operation will probably log a "RESULT err=2". > > So I would first check access log and look for such a failure. With the > OID we will be able to understand which operation is failing and which part > could be misconfigured. > > HTH, > Flo. > > Best regards, >> Beeth >> >> >> >> Hello Beeth, >> I've tried to reproduce the problem you described with 7.3 >> (ipa-server 4.4.0-12) on master and replica and 6.9 (ipa-client >> 3.0.0-51) on client and it worked for me as expected. >> I've done these steps: >> [master] # ipa-server-install -a Secret123 -p Secret123 --domain >> example.test --realm EXAMPLE.TEST --setup-dns --auto-forwarders -U >> [replica] # ipa-client-install -p admin -w Secret123 --domain >> example.test --server master.example.test -U >> [replica] # ipa-replica-install >> [client] # ipa-client-install -p admin -w Secret123 --domain >> example.test --server replica.example.test -U >> [client] # id admin >> >> Is there anything you've done differently? >> >> -- >> David Kupka >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Wed Dec 14 22:48:09 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 15 Dec 2016 08:48:09 +1000 Subject: [Freeipa-users] ipa-server-install fails at DogTag restart In-Reply-To: <6d359fec-b985-1daf-475f-f2ff503964b7@armourcomms.com> References: <6d359fec-b985-1daf-475f-f2ff503964b7@armourcomms.com> Message-ID: <20161214224809.GA4232@dhcp-40-8.bne.redhat.com> On Wed, Dec 14, 2016 at 05:35:35PM +0000, Tommy Nikjoo wrote: > Hi, > > I'm trying to install FreeIPA on CentOS 7 using the yum package, but I > keep getting an error when it tries to restart DogTag > > [26/31]: restarting certificate server > ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart > the Dogtag instance.See the installation log for details. > [27/31]: migrating certificate profiles to LDAP > [error] NetworkError: cannot connect to > 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': '' > ipa.ipapython.install.cli.install_tool(Server): ERROR cannot connect > to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': '' > ipa.ipapython.install.cli.install_tool(Server): ERROR The > ipa-server-install command failed. See /var/log/ipaserver-install.log > for more information > > > The log shows the following error > > 2016-12-14T16:53:05Z DEBUG NSSConnection init ldap.example.com > 2016-12-14T16:53:05Z DEBUG Connecting: x.x.x.x:0 > 2016-12-14T16:53:05Z DEBUG approved_usage = SSL Server intended_usage = > SSL Server > 2016-12-14T16:53:05Z DEBUG cert valid True for > "CN=ldap.example.com,O=EXAMPLE.COM" > 2016-12-14T16:53:05Z DEBUG handshake complete, peer = x.x.x.x:8443 > 2016-12-14T16:53:05Z DEBUG Protocol: TLS1.2 > 2016-12-14T16:53:05Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA > 2016-12-14T16:53:05Z DEBUG response status 200 > 2016-12-14T16:53:05Z DEBUG response headers {'content-length': '205', > 'set-cookie': 'JSESSIONID=9B6C767CDBED07088646235E68E831E0; Path=/ca/; > Secure; HttpOnly', 'expires': 'Thu, 01 Jan 1970 00:00:00 UTC', 'server': > 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed, 14 Dec > 2016 16:53:05 GMT', 'content-type': 'application/xml'} > 2016-12-14T16:53:05Z DEBUG response body ' encoding="UTF-8" standalone="yes"?> id="ipara">iparaCertificate Manager > AgentsRegistration Manager Agents' > 2016-12-14T16:53:05Z DEBUG request POST > https://ldap.example.com:8443/ca/rest/profiles/raw > 2016-12-14T16:53:05Z DEBUG request body > 'profileId=IECUserRoles\nclassId=caEnrollImpl\ndesc=Enroll user > certificates with IECUserRoles extension via IPA-RA agent > authentication.\nvisible=false\nenable=true\nenableBy=admin\nauth.instance_id=raCertAuth\nname=IPA-RA > Agent-Authenticated Server Certificate > Enrollment\ninput.list=i1,i2\ninput.i1.class_id=certReqInputImpl\ninput.i2.class_id=submitterInfoInputImpl\noutput.list=o1\noutput.o1.class_id=certOutputImpl\npolicyset.list=serverCertSet\npolicyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12\npolicyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl\npolicyset.serverCertSet.1.constraint.name=Subject > Name > Constraint\npolicyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+\npolicyset.serverCertSet.1.constraint.params.accept=true\npolicyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl\npolicyset.serverCertSet.1.default.name=Subject > Name > Default\npolicyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, > O=EXAMPLE.COM\npolicyset.serverCertSet.2.constraint.class_id=validityConstraintImpl\npolicyset.serverCertSet.2.constraint.name=Validity > Constraint\npolicyset.serverCertSet.2.constraint.params.range=740\npolicyset.serverCertSet.2.constraint.params.notBeforeCheck=false\npolicyset.serverCertSet.2.constraint.params.notAfterCheck=false\npolicyset.serverCertSet.2.default.class_id=validityDefaultImpl\npolicyset.serverCertSet.2.default.name=Validity > Default\npolicyset.serverCertSet.2.default.params.range=731\npolicyset.serverCertSet.2.default.params.startTime=0\npolicyset.serverCertSet.3.constraint.class_id=keyConstraintImpl\npolicyset.serverCertSet.3.constraint.name=Key > Constraint\npolicyset.serverCertSet.3.constraint.params.keyType=RSA\npolicyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096\npolicyset.serverCertSet.3.default.class_id=userKeyDefaultImpl\npolicyset.serverCertSet.3.default.name=Key > Default\npolicyset.serverCertSet.4.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.4.constraint.name=No > Constraint\npolicyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.4.default.name=Authority > Key Identifier > Default\npolicyset.serverCertSet.5.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.5.constraint.name=No > Constraint\npolicyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl\npolicyset.serverCertSet.5.default.name=AIA > Extension > Default\npolicyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true\npolicyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName\npolicyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp\npolicyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1\npolicyset.serverCertSet.5.default.params.authInfoAccessCritical=false\npolicyset.serverCertSet.5.default.params.authInfoAccessNumADs=1\npolicyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl\npolicyset.serverCertSet.6.constraint.name=Key > Usage Extension > Constraint\npolicyset.serverCertSet.6.constraint.params.keyUsageCritical=true\npolicyset.serverCertSet.6.constraint.params.keyUsageDigitalSignature=true\npolicyset.serverCertSet.6.constraint.params.keyUsageNonRepudiation=true\npolicyset.serverCertSet.6.constraint.params.keyUsageDataEncipherment=true\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyEncipherment=true\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyAgreement=false\npolicyset.serverCertSet.6.constraint.params.keyUsageKeyCertSign=false\npolicyset.serverCertSet.6.constraint.params.keyUsageCrlSign=false\npolicyset.serverCertSet.6.constraint.params.keyUsageEncipherOnly=false\npolicyset.serverCertSet.6.constraint.params.keyUsageDecipherOnly=false\npolicyset.serverCertSet.6.default.class_id=keyUsageExtDefaultImpl\npolicyset.serverCertSet.6.default.name=Key > Usage > Default\npolicyset.serverCertSet.6.default.params.keyUsageCritical=true\npolicyset.serverCertSet.6.default.params.keyUsageDigitalSignature=true\npolicyset.serverCertSet.6.default.params.keyUsageNonRepudiation=true\npolicyset.serverCertSet.6.default.params.keyUsageDataEncipherment=true\npolicyset.serverCertSet.6.default.params.keyUsageKeyEncipherment=true\npolicyset.serverCertSet.6.default.params.keyUsageKeyAgreement=false\npolicyset.serverCertSet.6.default.params.keyUsageKeyCertSign=false\npolicyset.serverCertSet.6.default.params.keyUsageCrlSign=false\npolicyset.serverCertSet.6.default.params.keyUsageEncipherOnly=false\npolicyset.serverCertSet.6.default.params.keyUsageDecipherOnly=false\npolicyset.serverCertSet.7.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.7.constraint.name=No > Constraint\npolicyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl\npolicyset.serverCertSet.7.default.name=Extended > Key Usage Extension > Default\npolicyset.serverCertSet.7.default.params.exKeyUsageCritical=false\npolicyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2\npolicyset.serverCertSet.8.constraint.class_id=signingAlgConstraintImpl\npolicyset.serverCertSet.8.constraint.name=No > Constraint\npolicyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC\npolicyset.serverCertSet.8.default.class_id=signingAlgDefaultImpl\npolicyset.serverCertSet.8.default.name=Signing > Alg\npolicyset.serverCertSet.8.default.params.signingAlg=-\npolicyset.serverCertSet.9.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.9.constraint.name=No > Constraint\npolicyset.serverCertSet.9.default.class_id=crlDistributionPointsExtDefaultImpl\npolicyset.serverCertSet.9.default.name=CRL > Distribution Points Extension > Default\npolicyset.serverCertSet.9.default.params.crlDistPointsCritical=false\npolicyset.serverCertSet.9.default.params.crlDistPointsNum=1\npolicyset.serverCertSet.9.default.params.crlDistPointsEnable_0=true\npolicyset.serverCertSet.9.default.params.crlDistPointsIssuerName_0=CN=Certificate > Authority,o=ipaca\npolicyset.serverCertSet.9.default.params.crlDistPointsIssuerType_0=DirectoryName\npolicyset.serverCertSet.9.default.params.crlDistPointsPointName_0=http://ipa-ca.example.com/ipa/crl/MasterCRL.bin\npolicyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName\npolicyset.serverCertSet.9.default.params.crlDistPointsReasons_0=\npolicyset.serverCertSet.10.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.10.constraint.name=No > Constraint\npolicyset.serverCertSet.10.default.class_id=subjectKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.10.default.name=Subject > Key Identifier Extension > Default\npolicyset.serverCertSet.10.default.params.critical=false\npolicyset.serverCertSet.11.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.11.constraint.name=No > Constraint\npolicyset.serverCertSet.11.default.class_id=userExtensionDefaultImpl\npolicyset.serverCertSet.11.default.name=User > Supplied Extension > Default\npolicyset.serverCertSet.11.default.params.userExtOID=2.5.29.17\npolicyset.serverCertSet.12.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.12.constraint.name=No > Constraint\npolicyset.serverCertSet.12.default.class_id=userExtensionDefaultImpl\npolicyset.serverCertSet.12.default.name=IECUserRoles > Extension > Default\npolicyset.serverCertSet.12.default.params.userExtOID=1.2.840.10070.8.1\n' > > Is there anything I can do to get around this? > > Thanks, > > Tommy > Could you look at `journalctl -u pki-tomcatd at pki-tomcat' and see if there are any errors there? Also could you provide more of /var/log/ipaserver-install.log and /var/log/pki/pki-tomcat/ca/debug ? Thanks, Fraser From pvoborni at redhat.com Thu Dec 15 12:21:48 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Dec 2016 13:21:48 +0100 Subject: [Freeipa-users] Replica Creation Issue In-Reply-To: References: Message-ID: <37a09b19-58a5-1598-10cc-ded3bd51fab8@redhat.com> On 12/14/2016 03:27 PM, Christian McNamara wrote: > Hi all, > > I recently inherited a FreeIPA system that I believe is running v3.0, and I'm > trying to upgrade to the latest version. Following documentation, I'm trying to > create a replica but I'm running into problems connecting to the LDAP server. > Here's the output I get when trying to prepare a replica: > > $ sudo ipa-replica-prepare auth4.sshchicago.org > --ip-address 172.31.31.36 > Directory Manager (existing master) password: > > Preparing replica for auth4.sshchicago.org > from auth3.sshchicago.org > preparation of replica failed: cannot connect to > u'ldaps://auth3.sshchicago.org : > > 7390': > LDAP Server Down > cannot connect to u'ldaps://auth3.sshchicago.org:7390 > ': LDAP Server Down > File "/usr/sbin/ipa-replica-prepare", line 529, in > main() > > File "/usr/sbin/ipa-replica-prepare", line 391, in main > update_pki_admin_password(dirman_password) > > File "/usr/sbin/ipa-replica-prepare", line 247, in update_pki_admin_password > bind_pw=dirman_password > > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in > connect > conn = self.create_connection(*args, **kw) > > File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line > 846, > > in create_connection > self.handle_errors(e) > > File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line > 736, > > in handle_errors > error=u'LDAP Server Down') > > > It says that our LDAP server is down, but it's trying to connect using the wrong > port number. Our LDAP server runs on 389, not 7390, and I can't figure out how > to specify this to the prepare script. > > Any ideas? > IPA 3.0 has 2 instances of directory server. One for domain data second for PKI CA data. IPA 4.x instances have them merged. So port 7390 is ldaps for of PKI-IPA DS instance, e.g. equivalent for 636 port of domain DS instance. Similar mapping is with 7389 and 389 ports. Therefore I'd check if PKI-IPA is running or if it is listening there. Relevant logs are in: /var/log/dirsrv/slapd-PKI-IPA/errors Example of `ipactl restart`: Shutting down dirsrv: DOM-189-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM... [ OK ] PKI-IPA... [ OK ] Starting dirsrv: DOM-189-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM... [ OK ] PKI-IPA... [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [ OK ] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Starting Kerberos 5 Admin Server: [ OK ] Restarting DNS Service Stopping named: . [ OK ] Starting named: [ OK ] Restarting MEMCACHE Service Stopping ipa_memcached: [ OK ] Starting ipa_memcached: [ OK ] Restarting HTTP Service Stopping httpd: [ OK ] Starting httpd: [ OK ] Restarting CA Service [ OK ] Starting pki-ca: [ OK ] -- Petr Vobornik From pvoborni at redhat.com Thu Dec 15 12:47:12 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Dec 2016 13:47:12 +0100 Subject: [Freeipa-users] ipa fails to start after centos 7.3 upgrade In-Reply-To: References: Message-ID: <590bde66-1927-88f1-8ec4-d1e8c9b4ee74@redhat.com> On 12/12/2016 08:53 PM, Rob Verduijn wrote: > Hello, > > I've recently upgraded to centos 7.3. > Didn't intend to so soon but should have checked the anounce lists before > launching my ansible update playbook. > > Most of my servers came through, and mostly also the ipa server. > There were duplicate rpms and a failed rpm upgrade. > After some yum magic the rpm duplicates where gone and all the updates installed. > > Manually running ipa-server-upgrade also seems to finish properly. > > However > ipactl start keeps failing on the ntpd service. > Not a big surprise since its running chronyd. > > I now start the ipa server with 'ipactl start --ignore-service-failure' > > Is there a way to explain the script that it should check for chronyd instead of > ntpd ? > > I also see this a lot in the logs: > dns_rdatatype_fromtext() failed for attribute > 'idnsTemplateAttribute;cnamerecord': unknown class/type > > Is that a serious error ? > > Rob Verduijn > This looks like 7.3 update incorrectly added NTP service to IPA server services (which is displayed as NTP role in `ipa server-show $server`). A workaround might be to disable the service or remove the service entry. Disabling is IMHO safer. IPA CLI tools don't allow enabling/disabling of services so it must be done by LDAP mod. It can be done by removing 'enabledService' config value from server's service entry, e.g.: dn: cn=NTP,cn=$SERVER_FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX changetype: modify delete: ipaConfigString ipaConfigString: enabledService - Where $SERVER_FQDN is e.g. ipa.example.com and $SUFFIX is e.g. dc=example,dc=com Rob, have you originally installed the replica with NTPD and then later switched manually to chrony? -- Petr Vobornik From mark.steele at autodesk.com Thu Dec 15 15:38:14 2016 From: mark.steele at autodesk.com (Mark Steele) Date: Thu, 15 Dec 2016 15:38:14 +0000 Subject: [Freeipa-users] Kerberos and 2fa with mac OS X client Message-ID: <68CD225F-502A-43D4-BBB0-A9A5218D55E3@autodesk.com> Hi, Has anyone managed to make this work and if so, is there some documentation for doing so? I can successfully authenticate to my linux servers using 2FA, but am unable to get my Mac to be able to get a ticket with kinit. Kinit returns: ?password incorrect?, and isn?t prompting for the second factor. I?ve also tried appending the second factor to the password (like when logging into the UI). Any help would be appreciated. Thanks Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Thu Dec 15 15:52:20 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 15 Dec 2016 16:52:20 +0100 Subject: [Freeipa-users] Failed ipa-client-install with IPA Replica In-Reply-To: References: <794d723f-9994-2281-1add-c5d0d1167257@redhat.com> Message-ID: On 12/14/2016 07:49 PM, beeth beeth wrote: > Hi Flo, > > Thanks for the great hint! I reran the ipa-client-install on the rhel6 > box(ipadev6), and monitored the access log file you mentioned on the > replica: > > # ipa-client-install --domain=ipa.example.com > --server=ipaprd2.example.com > --hostname=ipadev6.example.com -d > > ( ipaprd2 = primary IPA server on RHEL7; ipadev6 = replica on RHEL6 ) > > AFTER about 3 seconds, I saw these on the replica ipaprd2: > [14/Dec/2016:13:11:41.071421132 -0500] conn=1040 fd=73 slot=73 > connection from to > [14/Dec/2016:13:11:41.071880026 -0500] conn=1040 op=0 EXT > oid="1.3.6.1.4.1.1466.20037" > [14/Dec/2016:13:11:41.071964217 -0500] conn=1040 op=0 RESULT err=2 > tag=120 nentries=0 etime=0 > [14/Dec/2016:13:11:41.073275674 -0500] conn=1040 op=1 UNBIND > [14/Dec/2016:13:11:41.073307101 -0500] conn=1040 op=1 fd=73 closed - U1 > [14/Dec/2016:13:11:41.074782496 -0500] conn=1041 fd=73 slot=73 > connection from to > [14/Dec/2016:13:11:41.074985233 -0500] conn=1041 op=0 EXT > oid="1.3.6.1.4.1.1466.20037" > [14/Dec/2016:13:11:41.075022849 -0500] conn=1041 op=0 RESULT err=2 > tag=120 nentries=0 etime=0 > [14/Dec/2016:13:11:41.075448887 -0500] conn=1041 op=1 UNBIND > [14/Dec/2016:13:11:41.075460964 -0500] conn=1041 op=1 fd=73 closed - U1 > [14/Dec/2016:13:11:49.006146850 -0500] conn=1029 op=8 UNBIND > [14/Dec/2016:13:11:49.006181982 -0500] conn=1029 op=8 fd=66 closed - U1 > > So I did see the err=2, and oid="1.3.6.1.4.1.1466.20037", I checked the > oid and got: > > 1.3.6.1.4.1.1466.20037: StartTLS Request (RFC 4511) > > It looked to be related with TLS... pease advise. Thanks! > > Hi, when the replica got installed, the installer must have configured the directory server for SSL and start TLS. I tend to suspect an expired certificate issue rather than a misconfiguration. Could you please check that dirsrv certificate is still valid? $ certutil -L -d /etc/dirsrv/slapd-DOMAIN-COM/ -n Server-Cert |grep Not Not Before: Wed Dec 14 16:56:02 2016 Not After : Sat Dec 15 16:56:02 2018 If the certificate is still valid, you may want to read 389-ds How-To to make sure that SSL is properly setup: http://directory.fedoraproject.org/docs/389ds/howto/howto-ssl.html#deploy-the-settings Flo. > > On Wed, Dec 14, 2016 at 7:57 AM, Florence Blanc-Renaud > wrote: > > On 12/14/2016 01:08 PM, beeth beeth wrote: > > Thanks David. I installed both the master and replica IPA > servers with > third-party certificates(Verisign), but I doubt that could be > the issue, > because I had no problem to run the same ipa-client-install > command on a > RHEL7 machine(of course, the --hostname used a different > hostname of the > server). And I had no problem to run the ipa-client-install > command with > --server= on such RHEL6 machine. So what could cause the > LDAP > communication failed during the client enrollment with the > replica? Is > there a way I can troubleshoot this by running some commands? So > far I > did telnet to check the open ports, as well as run the ldapsearch > towards the replica. Thanks again! > > > On Tue, Dec 13, 2016 at 8:46 AM, David Kupka > >> wrote: > > On 13/12/16 05:44, beeth beeth wrote: > > I have two IPA servers ipaprd1.example.com > > and ipaprd2.example.com > > , running > ipa 4.4 on RHEL7. When I tried to install/configure the > client > on a RHEL6 > system(called ipadev6), I had issue when I tried to > enroll it > with the > replica(ipaprd2), while no issue with the primary(ipaprd1): > > # ipa-client-install --domain=ipa.example.com > > --server=ipaprd1.example.com > > > --server=ipaprd2.example.com > > --hostname=ipadev6.example.com > > LDAP Error: Protocol error: unsupported extended operation > Autodiscovery of servers for failover cannot work with this > configuration. > If you proceed with the installation, services will be > configured to always > access the discovered server for all operations and will not > fail over to > other servers in case of failure. > Proceed with fixed values and no DNS discovery? [no] > > Then I tried to run ipa-client-install to enroll with the > replica(ipaprd2), > with debug mode, I got this: > > # ipa-client-install --domain=ipa.example.com > > --server=ipaprd2.example.com > > > --hostname=ipadev6.example.com > -d > /usr/sbin/ipa-client-install was invoked with options: > {'domain': ' > ipa.example.com > ', 'force': False, > 'realm_name': None, > 'krb5_offline_passwords': True, 'primary': False, > 'mkhomedir': > False, > 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, > 'on_master': > False, 'ntp_server': None, 'nisdomain': None, > 'no_nisdomain': False, > 'principal': None, 'hostname': 'ipadev6.example.com > > ', 'no_ac': False, > 'unattended': None, 'sssd': True, 'trust_sshfp': False, > 'kinit_attempts': > 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': > True, > 'force_join': > False, 'ca_cert_file': None, 'server': > ['ipaprd2.example.com > '], > 'prompt_password': False, 'permit': False, 'debug': True, > 'preserve_sssd': > False, 'uninstall': False} > missing options might be asked for interactively later > Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > Loading StateFile from > '/var/lib/ipa-client/sysrestore/sysrestore.state' > [IPA Discovery] > Starting IPA discovery with domain=ipa.example.com > > , servers=[' > ipaprd2.example.com > '], > hostname=ipadev6.example.com > > Server and domain forced > [Kerberos realm search] > Search DNS for TXT record of _kerberos.ipa.example.com > > >. > No DNS record found > Search DNS for SRV record of > _kerberos._udp.ipa.example.com > . > No DNS record found > SRV record for KDC not found! Domain: ipa.example.com > > > [LDAP server check] > Verifying that ipaprd2.example.com > > (realm None) is an IPA server > Init LDAP connection with: > ldap://ipaprd2.example.com:389 > > > LDAP Error: Protocol error: unsupported extended operation > Discovery result: UNKNOWN_ERROR; server=None, > domain=ipa.example.com > , > kdc=None, basedn=None > Validated servers: > will use discovered domain: ipa.example.com > > IPA Server not found > [IPA Discovery] > Starting IPA discovery with domain=ipa.example.com > > , servers=[' > ipaprd2.example.com > '], > hostname=ipadev6.example.com > > Server and domain forced > [Kerberos realm search] > Search DNS for TXT record of _kerberos.ipa.example.com > > >. > No DNS record found > Search DNS for SRV record of > _kerberos._udp.ipa.example.com > . > No DNS record found > SRV record for KDC not found! Domain: ipa.example.com > > > [LDAP server check] > Verifying that ipaprd2.example.com > > (realm None) is an IPA server > Init LDAP connection with: > ldap://ipaprd2.example.com:389 > > > LDAP Error: Protocol error: unsupported extended operation > Discovery result: UNKNOWN_ERROR; server=None, > domain=ipa.example.com > , > kdc=None, basedn=None > Validated servers: > Failed to verify that ipaprd2.example.com > > is an IPA Server. > This may mean that the remote server is not up or is not > reachable due to > network or firewall settings. > Please make sure the following ports are opened in the > firewall > settings: > TCP: 80, 88, 389 > UDP: 88 (at least one of TCP/UDP ports 88 has to be > open) > Also note that following ports are necessary for > ipa-client working > properly after enrollment: > TCP: 464 > UDP: 464, 123 (if NTP enabled) > (ipaprd2.example.com > : Provided as > option) > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > > I double checked the services running on the replica, > all looked > well: > ports are listening, and I could telnet the ports from the > client(ipadev6). > I could run "ldapserach" command to talk to the > replica(ipaprd2) > from this > client(ipadev6), with pulling out all the LDAP records. > > Also, I have another test box running RHEL7, and no > issue at all > to run the > exact same ipa-client-install command on that RHEL7 box. So > could there be > a bug on the ipa-client software on RHEL6, to talk to > IPA sever > running on > RHEL7? Please advise. Thank you! > > Hi Beeth, > > you may want to check the access and errors log of the Directory > Server in /var/log/dirsrv/slapd-DOMAIN. The extended operations are > logged in the access log with the tag "EXT oid=...", but a failing > operation related to unsupported extended operation will probably > log a "RESULT err=2". > > So I would first check access log and look for such a failure. With > the OID we will be able to understand which operation is failing and > which part could be misconfigured. > > HTH, > Flo. > > Best regards, > Beeth > > > > Hello Beeth, > I've tried to reproduce the problem you described with 7.3 > (ipa-server 4.4.0-12) on master and replica and 6.9 (ipa-client > 3.0.0-51) on client and it worked for me as expected. > I've done these steps: > [master] # ipa-server-install -a Secret123 -p Secret123 --domain > example.test --realm EXAMPLE.TEST --setup-dns > --auto-forwarders -U > [replica] # ipa-client-install -p admin -w Secret123 --domain > example.test --server master.example.test -U > [replica] # ipa-replica-install > [client] # ipa-client-install -p admin -w Secret123 --domain > example.test --server replica.example.test -U > [client] # id admin > > Is there anything you've done differently? > > -- > David Kupka > > > > > > From sbose at redhat.com Thu Dec 15 15:53:04 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 15 Dec 2016 16:53:04 +0100 Subject: [Freeipa-users] Kerberos and 2fa with mac OS X client In-Reply-To: <68CD225F-502A-43D4-BBB0-A9A5218D55E3@autodesk.com> References: <68CD225F-502A-43D4-BBB0-A9A5218D55E3@autodesk.com> Message-ID: <20161215155304.GB3623@p.Speedport_W_724V_Typ_A_05011603_00_011> On Thu, Dec 15, 2016 at 03:38:14PM +0000, Mark Steele wrote: > Hi, > > Has anyone managed to make this work and if so, is there some documentation for doing so? > > I can successfully authenticate to my linux servers using 2FA, but am unable to get my Mac to be able to get a ticket with kinit. > > Kinit returns: ?password incorrect?, and isn?t prompting for the second factor. I?ve also tried appending the second factor to the password (like when logging into the UI). > > Any help would be appreciated. For 2FA FAST is needed http://www.freeipa.org/page/V4/OTP#kinit_Method. For MacOS I found https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/kinit.1.html and according to this the MacOS kinit does not support FAST, i.e. using an armor credential cache. But maybe there are newer or alternative versions which supports it? HTH bye, Sumit > > > Thanks > > Mark > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From abokovoy at redhat.com Thu Dec 15 16:20:50 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 15 Dec 2016 18:20:50 +0200 Subject: [Freeipa-users] Kerberos and 2fa with mac OS X client In-Reply-To: <20161215155304.GB3623@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <68CD225F-502A-43D4-BBB0-A9A5218D55E3@autodesk.com> <20161215155304.GB3623@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <20161215162050.ywowkgfs4pxegrnt@redhat.com> On to, 15 joulu 2016, Sumit Bose wrote: >On Thu, Dec 15, 2016 at 03:38:14PM +0000, Mark Steele wrote: >> Hi, >> >> Has anyone managed to make this work and if so, is there some documentation for doing so? >> >> I can successfully authenticate to my linux servers using 2FA, but am >> unable to get my Mac to be able to get a ticket with kinit. >> >> Kinit returns: ?password incorrect?, and isn?t prompting for the >> second factor. I?ve also tried appending the second factor to the >> password (like when logging into the UI). >> >> Any help would be appreciated. > >For 2FA FAST is needed http://www.freeipa.org/page/V4/OTP#kinit_Method. >For MacOS I found >https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/kinit.1.html >and according to this the MacOS kinit does not support FAST, i.e. using >an armor credential cache. But maybe there are newer or alternative >versions which supports it? Starting with Mac OS X 10.8, Heimdal does support FAST. kinit --fast-armor-cache /path/to/ccache In Mac OS X numbering scheme for Heimdal this is version 247.6 or later. -- / Alexander Bokovoy From mark.steele at autodesk.com Thu Dec 15 18:50:53 2016 From: mark.steele at autodesk.com (Mark Steele) Date: Thu, 15 Dec 2016 18:50:53 +0000 Subject: [Freeipa-users] Kerberos and 2fa with mac OS X client In-Reply-To: <20161215162050.ywowkgfs4pxegrnt@redhat.com> References: <68CD225F-502A-43D4-BBB0-A9A5218D55E3@autodesk.com> <20161215155304.GB3623@p.Speedport_W_724V_Typ_A_05011603_00_011> <20161215162050.ywowkgfs4pxegrnt@redhat.com> Message-ID: Still no luck. klist Credentials cache: API:4FE16A36-A5AB-476F-8B49-4B427E816279 Principal: admin at INT.DOMAIN.COM Issued Expires Principal Dec 15 13:45:09 2016 Dec 16 13:45:07 2016 krbtgt/INT.DOMAIN.COM at INT.DOMAIN.COM KRB5_TRACE=/dev/stdout kinit --fast-armor-cache=API:4FE16A36-A5AB-476F-8B49-4B427E816279 mark.steele at INT.DOMAIN.COM 2016-12-15T13:35:35 set-error: -1765328242: Reached end of credential caches 2016-12-15T13:35:35 set-error: -1765328243: Principal mark.steele at INT.DOMAIN.COM not found in any credential cache mark.steele at INT.DOMAIN.COM's password: 2016-12-15T13:35:50 set-error: -1765328234: Encryption type des-cbc-md5-deprecated not supported 2016-12-15T13:35:50 Adding PA mech: SRP 2016-12-15T13:35:50 Adding PA mech: ENCRYPTED_CHALLENGE 2016-12-15T13:35:50 Adding PA mech: ENCRYPTED_TIMESTAMP 2016-12-15T13:35:50 krb5_get_init_creds: loop 1 2016-12-15T13:35:50 KDC sent 0 patypes 2016-12-15T13:35:50 Trying to find service kdc for realm INT.DOMAIN.COM flags 0 2016-12-15T13:35:50 configuration file for realm INT.DOMAIN.COM found 2016-12-15T13:35:50 submissing new requests to new host 2016-12-15T13:35:50 connecting to host: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 2016-12-15T13:35:50 writing packet: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 2016-12-15T13:35:51 Configuration exists for realm INT.DOMAIN.COM, wont go to DNS 2016-12-15T13:35:51 out of hosts, waiting for replies 2016-12-15T13:36:01 retrying sending to: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 2016-12-15T13:36:01 writing packet: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 2016-12-15T13:36:12 retrying sending to: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 2016-12-15T13:36:12 writing packet: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 2016-12-15T13:36:23 host timed out: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 2016-12-15T13:36:23 no more hosts to send/recv packets to/from trying to pulling more hosts 2016-12-15T13:36:23 set-error: -1765328228: unable to reach any KDC in realm INT.DOMAIN.COM, tried 1 KDC 2016-12-15T13:36:23 krb5_sendto_context INT.DOMAIN.COM done: -1765328228 hosts 1 packets 3 wc: 33.115489 nr: 0.000804 kh: 0.000915 tid: 00000001 kinit: krb5_get_init_creds: unable to reach any KDC in realm INT.DOMAIN.COM, tried 1 KDC mac client config (OS 10.11.1): cat /etc/krb5.conf [libdefaults] default_realm = INT.DOMAIN.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes renewable = true [realms] INT.DOMAIN.COM = { kdc = ds01.int.domain.com:88 master_kdc = ds01.int.domain.com:88 admin_server = ds01.int.domain.com:749 default_domain = int.domain.com pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .int.domain.com = INT.DOMAIN.COM int.domain.com = INT.DOMAIN.COM On the freeipa server?s krb5kdc.log: krb5kdc: Realm not local to KDC - while dispatching (udp) When authenticating with a non 2FA user, works fine. Anyone can hit me with a clue-stick? Cheers, Mark On 2016-12-15, 11:20 AM, "freeipa-users-bounces at redhat.com on behalf of Alexander Bokovoy" wrote: On to, 15 joulu 2016, Sumit Bose wrote: >On Thu, Dec 15, 2016 at 03:38:14PM +0000, Mark Steele wrote: >> Hi, >> >> Has anyone managed to make this work and if so, is there some documentation for doing so? >> >> I can successfully authenticate to my linux servers using 2FA, but am >> unable to get my Mac to be able to get a ticket with kinit. >> >> Kinit returns: ?password incorrect?, and isn?t prompting for the >> second factor. I?ve also tried appending the second factor to the >> password (like when logging into the UI). >> >> Any help would be appreciated. > >For 2FA FAST is needed http://www.freeipa.org/page/V4/OTP#kinit_Method. >For MacOS I found >https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/kinit.1.html >and according to this the MacOS kinit does not support FAST, i.e. using >an armor credential cache. But maybe there are newer or alternative >versions which supports it? Starting with Mac OS X 10.8, Heimdal does support FAST. kinit --fast-armor-cache /path/to/ccache In Mac OS X numbering scheme for Heimdal this is version 247.6 or later. -- / 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 beeth2006 at gmail.com Thu Dec 15 19:01:25 2016 From: beeth2006 at gmail.com (beeth beeth) Date: Thu, 15 Dec 2016 14:01:25 -0500 Subject: [Freeipa-users] Failed ipa-client-install with IPA Replica In-Reply-To: References: <794d723f-9994-2281-1add-c5d0d1167257@redhat.com> Message-ID: Hi Flo, That's a good point! I checked the dirsrv certificate and confirmed valid(good until later next year). Since I had no problem to enroll another new IPA client(RHEL7 box instead of RHEL6) to such replica server, I thought it might not be a server end issue. However, when I tried to restart the DIRSRV service on the replica server, I found these messages in the log file /var/log/dirsrv/slapd-IPA-EXAMPLE-COM/errors: [15/Dec/2016:13:38:15.891301246 -0500] 389-Directory/1.3.5.10 B2016.257.1817 starting up [15/Dec/2016:13:38:15.911777373 -0500] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match [15/Dec/2016:13:38:15.926320306 -0500] WARNING: changelog: entry cache size 2097152 B is less than db size 5488640 B; We recommend to increase the entry cache size nsslapd-cachememsize. [15/Dec/2016:13:38:16.132155534 -0500] schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup! [15/Dec/2016:13:38:16.167896279 -0500] NSACLPlugin - The ACL target cn=dns,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.173317345 -0500] NSACLPlugin - The ACL target cn=dns,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.178354342 -0500] NSACLPlugin - The ACL target cn=keys,cn=sec,cn=dns,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.183579322 -0500] NSACLPlugin - The ACL target cn=dns,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.188786976 -0500] NSACLPlugin - The ACL target cn=dns,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.193275650 -0500] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.197580407 -0500] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.201863256 -0500] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.206318629 -0500] NSACLPlugin - The ACL target ou=sudoers,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.211559100 -0500] NSACLPlugin - The ACL target cn=users,cn=compat,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.216146819 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.220786596 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.225594942 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.229986749 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.234518367 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.238763121 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.243031116 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.247507984 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.252327210 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.259046910 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.263856581 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.269301704 -0500] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.283511408 -0500] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.287853825 -0500] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does not exist [15/Dec/2016:13:38:16.395872649 -0500] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [15/Dec/2016:13:38:16.405404114 -0500] Skipping CoS Definition cn=Password Policy,cn=accounts,dc=ipa,dc=example,dc=com--no CoS Templates found, which should be added before the CoS Definition. [15/Dec/2016:13:38:16.463117873 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/ipaprd2.example.com at IPA.EXAMPLE.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) [15/Dec/2016:13:38:16.471256279 -0500] schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds! [15/Dec/2016:13:38:16.479213976 -0500] slapd started. Listening on All Interfaces port 389 for LDAP requests [15/Dec/2016:13:38:16.483683353 -0500] Listening on /var/run/slapd-IPA-EXAMPLE-COM.socket for LDAPI requests [15/Dec/2016:13:38:21.634319974 -0500] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=ipa,dc=example,dc=com [15/Dec/2016:13:38:21.639855161 -0500] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=ipa,dc=example,dc=com [15/Dec/2016:13:38:21.653406463 -0500] schema-compat-plugin - no RDN for cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com, unsetting domain/map/id "cn=compat,dc=ipa,dc=example,dc=com"/"cn=groups"/("cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com") [15/Dec/2016:13:38:21.714897614 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=ipa,dc=example,dc=com [15/Dec/2016:13:38:21.719933118 -0500] schema-compat-plugin - Finished plugin initialization. [15/Dec/2016:13:38:36.591969481 -0500] ipa-topology-plugin - ipa_topo_util_get_replica_conf: server configuration missing [15/Dec/2016:13:38:36.598683009 -0500] ipa-topology-plugin - ipa_topo_util_get_replica_conf: cannot create replica Any idea? BTW, everything ran well on IPA 4.2(server installation and client installation), as you once assisted me couple months ago, until we set up a new IPA environment with RHEL7.3 instead of RHEL7.2, then the IPA version changed from 4.2 to 4.4. Last time you guided me about the change since IPA 4.3, for the newly introduced domain level concept, and the way how the replica should be installed was changed too... Thanks again! On Thu, Dec 15, 2016 at 10:52 AM, Florence Blanc-Renaud wrote: > On 12/14/2016 07:49 PM, beeth beeth wrote: > >> Hi Flo, >> >> Thanks for the great hint! I reran the ipa-client-install on the rhel6 >> box(ipadev6), and monitored the access log file you mentioned on the >> replica: >> >> # ipa-client-install --domain=ipa.example.com >> --server=ipaprd2.example.com >> --hostname=ipadev6.example.com -d >> >> ( ipaprd2 = primary IPA server on RHEL7; ipadev6 = replica on RHEL6 ) >> >> AFTER about 3 seconds, I saw these on the replica ipaprd2: >> [14/Dec/2016:13:11:41.071421132 -0500] conn=1040 fd=73 slot=73 >> connection from to >> [14/Dec/2016:13:11:41.071880026 -0500] conn=1040 op=0 EXT >> oid="1.3.6.1.4.1.1466.20037" >> [14/Dec/2016:13:11:41.071964217 -0500] conn=1040 op=0 RESULT err=2 >> tag=120 nentries=0 etime=0 >> [14/Dec/2016:13:11:41.073275674 -0500] conn=1040 op=1 UNBIND >> [14/Dec/2016:13:11:41.073307101 -0500] conn=1040 op=1 fd=73 closed - U1 >> [14/Dec/2016:13:11:41.074782496 -0500] conn=1041 fd=73 slot=73 >> connection from to >> [14/Dec/2016:13:11:41.074985233 -0500] conn=1041 op=0 EXT >> oid="1.3.6.1.4.1.1466.20037" >> [14/Dec/2016:13:11:41.075022849 -0500] conn=1041 op=0 RESULT err=2 >> tag=120 nentries=0 etime=0 >> [14/Dec/2016:13:11:41.075448887 -0500] conn=1041 op=1 UNBIND >> [14/Dec/2016:13:11:41.075460964 -0500] conn=1041 op=1 fd=73 closed - U1 >> [14/Dec/2016:13:11:49.006146850 -0500] conn=1029 op=8 UNBIND >> [14/Dec/2016:13:11:49.006181982 -0500] conn=1029 op=8 fd=66 closed - U1 >> >> So I did see the err=2, and oid="1.3.6.1.4.1.1466.20037", I checked the >> oid and got: >> >> 1.3.6.1.4.1.1466.20037: StartTLS Request (RFC 4511) >> >> It looked to be related with TLS... pease advise. Thanks! >> >> >> Hi, > > when the replica got installed, the installer must have configured the > directory server for SSL and start TLS. I tend to suspect an expired > certificate issue rather than a misconfiguration. Could you please check > that dirsrv certificate is still valid? > > $ certutil -L -d /etc/dirsrv/slapd-DOMAIN-COM/ -n Server-Cert |grep Not > Not Before: Wed Dec 14 16:56:02 2016 > Not After : Sat Dec 15 16:56:02 2018 > > If the certificate is still valid, you may want to read 389-ds How-To to > make sure that SSL is properly setup: > http://directory.fedoraproject.org/docs/389ds/howto/howto- > ssl.html#deploy-the-settings > > Flo. > > >> On Wed, Dec 14, 2016 at 7:57 AM, Florence Blanc-Renaud > > wrote: >> >> On 12/14/2016 01:08 PM, beeth beeth wrote: >> >> Thanks David. I installed both the master and replica IPA >> servers with >> third-party certificates(Verisign), but I doubt that could be >> the issue, >> because I had no problem to run the same ipa-client-install >> command on a >> RHEL7 machine(of course, the --hostname used a different >> hostname of the >> server). And I had no problem to run the ipa-client-install >> command with >> --server= on such RHEL6 machine. So what could cause the >> LDAP >> communication failed during the client enrollment with the >> replica? Is >> there a way I can troubleshoot this by running some commands? So >> far I >> did telnet to check the open ports, as well as run the ldapsearch >> towards the replica. Thanks again! >> >> >> On Tue, Dec 13, 2016 at 8:46 AM, David Kupka > >> >> wrote: >> >> On 13/12/16 05:44, beeth beeth wrote: >> >> I have two IPA servers ipaprd1.example.com >> >> and ipaprd2.example.com >> >> , running >> ipa 4.4 on RHEL7. When I tried to install/configure the >> client >> on a RHEL6 >> system(called ipadev6), I had issue when I tried to >> enroll it >> with the >> replica(ipaprd2), while no issue with the >> primary(ipaprd1): >> >> # ipa-client-install --domain=ipa.example.com >> >> --server=ipaprd1.example.com >> >> >> --server=ipaprd2.example.com >> >> --hostname=ipadev6.example.com >> >> LDAP Error: Protocol error: unsupported extended operation >> Autodiscovery of servers for failover cannot work with >> this >> configuration. >> If you proceed with the installation, services will be >> configured to always >> access the discovered server for all operations and will >> not >> fail over to >> other servers in case of failure. >> Proceed with fixed values and no DNS discovery? [no] >> >> Then I tried to run ipa-client-install to enroll with the >> replica(ipaprd2), >> with debug mode, I got this: >> >> # ipa-client-install --domain=ipa.example.com >> >> --server=ipaprd2.example.com >> >> >> --hostname=ipadev6.example.com >> -d >> >> /usr/sbin/ipa-client-install was invoked with options: >> {'domain': ' >> ipa.example.com >> ', 'force': False, >> 'realm_name': None, >> 'krb5_offline_passwords': True, 'primary': False, >> 'mkhomedir': >> False, >> 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, >> 'on_master': >> False, 'ntp_server': None, 'nisdomain': None, >> 'no_nisdomain': False, >> 'principal': None, 'hostname': 'ipadev6.example.com >> >> ', 'no_ac': False, >> 'unattended': None, 'sssd': True, 'trust_sshfp': False, >> 'kinit_attempts': >> 5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': >> True, >> 'force_join': >> False, 'ca_cert_file': None, 'server': >> ['ipaprd2.example.com >> '], >> 'prompt_password': False, 'permit': False, 'debug': True, >> 'preserve_sssd': >> False, 'uninstall': False} >> missing options might be asked for interactively later >> Loading Index file from >> '/var/lib/ipa-client/sysrestore/sysrestore.index' >> Loading StateFile from >> '/var/lib/ipa-client/sysrestore/sysrestore.state' >> [IPA Discovery] >> Starting IPA discovery with domain=ipa.example.com >> >> , servers=[' >> ipaprd2.example.com >> '], >> hostname=ipadev6.example.com >> >> Server and domain forced >> [Kerberos realm search] >> Search DNS for TXT record of _kerberos.ipa.example.com >> >> > >. >> No DNS record found >> Search DNS for SRV record of >> _kerberos._udp.ipa.example.com >> . >> No DNS record found >> SRV record for KDC not found! Domain: ipa.example.com >> >> >> [LDAP server check] >> Verifying that ipaprd2.example.com >> >> (realm None) is an IPA server >> Init LDAP connection with: >> ldap://ipaprd2.example.com:389 >> > > >> LDAP Error: Protocol error: unsupported extended operation >> Discovery result: UNKNOWN_ERROR; server=None, >> domain=ipa.example.com >> , >> kdc=None, basedn=None >> Validated servers: >> will use discovered domain: ipa.example.com >> >> IPA Server not found >> [IPA Discovery] >> Starting IPA discovery with domain=ipa.example.com >> >> , servers=[' >> ipaprd2.example.com >> '], >> hostname=ipadev6.example.com >> >> Server and domain forced >> [Kerberos realm search] >> Search DNS for TXT record of _kerberos.ipa.example.com >> >> > >. >> No DNS record found >> Search DNS for SRV record of >> _kerberos._udp.ipa.example.com >> . >> No DNS record found >> SRV record for KDC not found! Domain: ipa.example.com >> >> >> [LDAP server check] >> Verifying that ipaprd2.example.com >> >> (realm None) is an IPA server >> Init LDAP connection with: >> ldap://ipaprd2.example.com:389 >> > > >> LDAP Error: Protocol error: unsupported extended operation >> Discovery result: UNKNOWN_ERROR; server=None, >> domain=ipa.example.com >> , >> kdc=None, basedn=None >> Validated servers: >> Failed to verify that ipaprd2.example.com >> >> is an IPA Server. >> This may mean that the remote server is not up or is not >> reachable due to >> network or firewall settings. >> Please make sure the following ports are opened in the >> firewall >> settings: >> TCP: 80, 88, 389 >> UDP: 88 (at least one of TCP/UDP ports 88 has to be >> open) >> Also note that following ports are necessary for >> ipa-client working >> properly after enrollment: >> TCP: 464 >> UDP: 464, 123 (if NTP enabled) >> (ipaprd2.example.com >> : Provided as >> option) >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> >> I double checked the services running on the replica, >> all looked >> well: >> ports are listening, and I could telnet the ports from the >> client(ipadev6). >> I could run "ldapserach" command to talk to the >> replica(ipaprd2) >> from this >> client(ipadev6), with pulling out all the LDAP records. >> >> Also, I have another test box running RHEL7, and no >> issue at all >> to run the >> exact same ipa-client-install command on that RHEL7 box. >> So >> could there be >> a bug on the ipa-client software on RHEL6, to talk to >> IPA sever >> running on >> RHEL7? Please advise. Thank you! >> >> Hi Beeth, >> >> you may want to check the access and errors log of the Directory >> Server in /var/log/dirsrv/slapd-DOMAIN. The extended operations are >> logged in the access log with the tag "EXT oid=...", but a failing >> operation related to unsupported extended operation will probably >> log a "RESULT err=2". >> >> So I would first check access log and look for such a failure. With >> the OID we will be able to understand which operation is failing and >> which part could be misconfigured. >> >> HTH, >> Flo. >> >> Best regards, >> Beeth >> >> >> >> Hello Beeth, >> I've tried to reproduce the problem you described with 7.3 >> (ipa-server 4.4.0-12) on master and replica and 6.9 >> (ipa-client >> 3.0.0-51) on client and it worked for me as expected. >> I've done these steps: >> [master] # ipa-server-install -a Secret123 -p Secret123 >> --domain >> example.test --realm EXAMPLE.TEST --setup-dns >> --auto-forwarders -U >> [replica] # ipa-client-install -p admin -w Secret123 --domain >> example.test --server master.example.test -U >> [replica] # ipa-replica-install >> [client] # ipa-client-install -p admin -w Secret123 --domain >> example.test --server replica.example.test -U >> [client] # id admin >> >> Is there anything you've done differently? >> >> -- >> David Kupka >> >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Dec 15 20:23:58 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 15 Dec 2016 22:23:58 +0200 Subject: [Freeipa-users] Kerberos and 2fa with mac OS X client In-Reply-To: References: <68CD225F-502A-43D4-BBB0-A9A5218D55E3@autodesk.com> <20161215155304.GB3623@p.Speedport_W_724V_Typ_A_05011603_00_011> <20161215162050.ywowkgfs4pxegrnt@redhat.com> Message-ID: <20161215202358.pe4mvmrayrx72efj@redhat.com> On to, 15 joulu 2016, Mark Steele wrote: >Still no luck. > > >klist >Credentials cache: API:4FE16A36-A5AB-476F-8B49-4B427E816279 > Principal: admin at INT.DOMAIN.COM > > Issued Expires Principal >Dec 15 13:45:09 2016 Dec 16 13:45:07 2016 krbtgt/INT.DOMAIN.COM at INT.DOMAIN.COM > > >KRB5_TRACE=/dev/stdout kinit --fast-armor-cache=API:4FE16A36-A5AB-476F-8B49-4B427E816279 mark.steele at INT.DOMAIN.COM >2016-12-15T13:35:35 set-error: -1765328242: Reached end of credential caches >2016-12-15T13:35:35 set-error: -1765328243: Principal mark.steele at INT.DOMAIN.COM not found in any credential cache >mark.steele at INT.DOMAIN.COM's password: >2016-12-15T13:35:50 set-error: -1765328234: Encryption type des-cbc-md5-deprecated not supported >2016-12-15T13:35:50 Adding PA mech: SRP >2016-12-15T13:35:50 Adding PA mech: ENCRYPTED_CHALLENGE >2016-12-15T13:35:50 Adding PA mech: ENCRYPTED_TIMESTAMP >2016-12-15T13:35:50 krb5_get_init_creds: loop 1 >2016-12-15T13:35:50 KDC sent 0 patypes >2016-12-15T13:35:50 Trying to find service kdc for realm INT.DOMAIN.COM flags 0 >2016-12-15T13:35:50 configuration file for realm INT.DOMAIN.COM found >2016-12-15T13:35:50 submissing new requests to new host >2016-12-15T13:35:50 connecting to host: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 >2016-12-15T13:35:50 writing packet: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 >2016-12-15T13:35:51 Configuration exists for realm INT.DOMAIN.COM, wont go to DNS >2016-12-15T13:35:51 out of hosts, waiting for replies >2016-12-15T13:36:01 retrying sending to: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 >2016-12-15T13:36:01 writing packet: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 >2016-12-15T13:36:12 retrying sending to: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 >2016-12-15T13:36:12 writing packet: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 >2016-12-15T13:36:23 host timed out: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 >2016-12-15T13:36:23 no more hosts to send/recv packets to/from trying to pulling more hosts >2016-12-15T13:36:23 set-error: -1765328228: unable to reach any KDC in realm INT.DOMAIN.COM, tried 1 KDC >2016-12-15T13:36:23 krb5_sendto_context INT.DOMAIN.COM done: -1765328228 hosts 1 packets 3 wc: 33.115489 nr: 0.000804 kh: 0.000915 tid: 00000001 >kinit: krb5_get_init_creds: unable to reach any KDC in realm INT.DOMAIN.COM, tried 1 KDC >mac client config (OS 10.11.1): > >cat /etc/krb5.conf >[libdefaults] > default_realm = INT.DOMAIN.COM > dns_lookup_realm = true > dns_lookup_kdc = true > ticket_lifetime = 24h > forwardable = yes > renewable = true > > >[realms] > INT.DOMAIN.COM = { > kdc = ds01.int.domain.com:88 > master_kdc = ds01.int.domain.com:88 > admin_server = ds01.int.domain.com:749 > default_domain = int.domain.com > pkinit_anchors = FILE:/etc/ipa/ca.crt >} > >[domain_realm] > .int.domain.com = INT.DOMAIN.COM > int.domain.com = INT.DOMAIN.COM > >On the freeipa server?s krb5kdc.log: > >krb5kdc: Realm not local to KDC - while dispatching (udp) > >When authenticating with a non 2FA user, works fine. > >Anyone can hit me with a clue-stick? This does not look like related to the FAST processing, but what does ipa-otpd log looks like (journalctl-wise)? -- / Alexander Bokovoy From b.candler at pobox.com Thu Dec 15 22:59:22 2016 From: b.candler at pobox.com (Brian Candler) Date: Thu, 15 Dec 2016 22:59:22 +0000 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: References: <65e8d18c-7c5f-4f82-57cb-8aa6069db84c@redhat.com> Message-ID: > On Sun, Dec 11, 2016 at 11:31 PM, David Kupka > wrote: > > > yes you can do it. DNS domain and Kerberos realm are two different > things. It's common and AFAIK recommended to capitalize DNS domain > to get the realm but it's not required. > If you really want to have them different make sure: > a) anotherdomain.com is under your > control, > b) you don't already have other Kerberos instance (FreeIPA, MIT > KRB5, MS AD, ...) with ANOTHERDOMAIN.COM > realm deployed. > > With FreeIPA you can run > # ipa-server-install --domain example.com > --realm ANOTHERDOMAIN.COM > > > But before you do, why do you want to have the realm different > from the domain? > > Question: what "domain" does the --domain option to ipa-server-install actually refer to? The man page just says " Your DNS domain name". But what does it actually alter? 1. the DNS domain which holds the kerberos realm location information? I don't think so; I think if you are searching for realm FOO.COM you'll always look in the DNS under "foo.com", that's a fixed relationship. 2. the DNS name of the IPA server itself? But if set up correctly, it already has an FQDN (as reported by "hostname -f"). And if you give the "--hostname" option, that's a FQDN not a bare hostname. 3. the DNS zone which IPA is authoritative for? But you can run IPA without integrated DNS. 4. the LDAP base DN? I guess that could be it: e.g. "--domain foo.com" puts everything under tree "dc=foo,dc=com"? 5. something else? Thanks, Brian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Dec 16 07:39:55 2016 From: sbose at redhat.com (Sumit Bose) Date: Fri, 16 Dec 2016 08:39:55 +0100 Subject: [Freeipa-users] Kerberos and 2fa with mac OS X client In-Reply-To: References: <68CD225F-502A-43D4-BBB0-A9A5218D55E3@autodesk.com> <20161215155304.GB3623@p.Speedport_W_724V_Typ_A_05011603_00_011> <20161215162050.ywowkgfs4pxegrnt@redhat.com> Message-ID: <20161216073955.GE3623@p.Speedport_W_724V_Typ_A_05011603_00_011> On Thu, Dec 15, 2016 at 06:50:53PM +0000, Mark Steele wrote: > Still no luck. > > > klist > Credentials cache: API:4FE16A36-A5AB-476F-8B49-4B427E816279 > Principal: admin at INT.DOMAIN.COM > > Issued Expires Principal > Dec 15 13:45:09 2016 Dec 16 13:45:07 2016 krbtgt/INT.DOMAIN.COM at INT.DOMAIN.COM > > > KRB5_TRACE=/dev/stdout kinit --fast-armor-cache=API:4FE16A36-A5AB-476F-8B49-4B427E816279 mark.steele at INT.DOMAIN.COM > 2016-12-15T13:35:35 set-error: -1765328242: Reached end of credential caches > 2016-12-15T13:35:35 set-error: -1765328243: Principal mark.steele at INT.DOMAIN.COM not found in any credential cache > mark.steele at INT.DOMAIN.COM's password: > 2016-12-15T13:35:50 set-error: -1765328234: Encryption type des-cbc-md5-deprecated not supported > 2016-12-15T13:35:50 Adding PA mech: SRP > 2016-12-15T13:35:50 Adding PA mech: ENCRYPTED_CHALLENGE > 2016-12-15T13:35:50 Adding PA mech: ENCRYPTED_TIMESTAMP > 2016-12-15T13:35:50 krb5_get_init_creds: loop 1 > 2016-12-15T13:35:50 KDC sent 0 patypes > 2016-12-15T13:35:50 Trying to find service kdc for realm INT.DOMAIN.COM flags 0 > 2016-12-15T13:35:50 configuration file for realm INT.DOMAIN.COM found > 2016-12-15T13:35:50 submissing new requests to new host > 2016-12-15T13:35:50 connecting to host: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 > 2016-12-15T13:35:50 writing packet: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 > 2016-12-15T13:35:51 Configuration exists for realm INT.DOMAIN.COM, wont go to DNS > 2016-12-15T13:35:51 out of hosts, waiting for replies > 2016-12-15T13:36:01 retrying sending to: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 > 2016-12-15T13:36:01 writing packet: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 > 2016-12-15T13:36:12 retrying sending to: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 > 2016-12-15T13:36:12 writing packet: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 > 2016-12-15T13:36:23 host timed out: udp 10.44.4.50:kerberos (ds01.int.domain.com) tid: 00000001 Your client does not fall back to TCP. It is at least recommended to use TCP with OTP (see https://fedorahosted.org/freeipa/ticket/4725). Iirc with heimdal you can use kdc = tcp/ds01.int.domain.com:88 to force the client using TCP. HTH bye, Sumit > 2016-12-15T13:36:23 no more hosts to send/recv packets to/from trying to pulling more hosts > 2016-12-15T13:36:23 set-error: -1765328228: unable to reach any KDC in realm INT.DOMAIN.COM, tried 1 KDC > 2016-12-15T13:36:23 krb5_sendto_context INT.DOMAIN.COM done: -1765328228 hosts 1 packets 3 wc: 33.115489 nr: 0.000804 kh: 0.000915 tid: 00000001 > kinit: krb5_get_init_creds: unable to reach any KDC in realm INT.DOMAIN.COM, tried 1 KDC > > > mac client config (OS 10.11.1): > > cat /etc/krb5.conf > [libdefaults] > default_realm = INT.DOMAIN.COM > dns_lookup_realm = true > dns_lookup_kdc = true > ticket_lifetime = 24h > forwardable = yes > renewable = true > > > [realms] > INT.DOMAIN.COM = { > kdc = ds01.int.domain.com:88 > master_kdc = ds01.int.domain.com:88 > admin_server = ds01.int.domain.com:749 > default_domain = int.domain.com > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .int.domain.com = INT.DOMAIN.COM > int.domain.com = INT.DOMAIN.COM > > On the freeipa server?s krb5kdc.log: > > krb5kdc: Realm not local to KDC - while dispatching (udp) > > When authenticating with a non 2FA user, works fine. > > Anyone can hit me with a clue-stick? > > Cheers, > > Mark > > > > On 2016-12-15, 11:20 AM, "freeipa-users-bounces at redhat.com on behalf of Alexander Bokovoy" wrote: > > On to, 15 joulu 2016, Sumit Bose wrote: > >On Thu, Dec 15, 2016 at 03:38:14PM +0000, Mark Steele wrote: > >> Hi, > >> > >> Has anyone managed to make this work and if so, is there some documentation for doing so? > >> > >> I can successfully authenticate to my linux servers using 2FA, but am > >> unable to get my Mac to be able to get a ticket with kinit. > >> > >> Kinit returns: ?password incorrect?, and isn?t prompting for the > >> second factor. I?ve also tried appending the second factor to the > >> password (like when logging into the UI). > >> > >> Any help would be appreciated. > > > >For 2FA FAST is needed http://www.freeipa.org/page/V4/OTP#kinit_Method. > >For MacOS I found > >https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/kinit.1.html > >and according to this the MacOS kinit does not support FAST, i.e. using > >an armor credential cache. But maybe there are newer or alternative > >versions which supports it? > Starting with Mac OS X 10.8, Heimdal does support FAST. > > kinit --fast-armor-cache /path/to/ccache > > In Mac OS X numbering scheme for Heimdal this is version 247.6 or later. > > -- > / 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 abokovoy at redhat.com Fri Dec 16 08:21:32 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 16 Dec 2016 10:21:32 +0200 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: References: <65e8d18c-7c5f-4f82-57cb-8aa6069db84c@redhat.com> Message-ID: <20161216082132.rcd6zpeb3omenvq4@redhat.com> On to, 15 joulu 2016, Brian Candler wrote: >>On Sun, Dec 11, 2016 at 11:31 PM, David Kupka >> wrote: >> >> >> yes you can do it. DNS domain and Kerberos realm are two different >> things. It's common and AFAIK recommended to capitalize DNS domain >> to get the realm but it's not required. >> If you really want to have them different make sure: >> a) anotherdomain.com is under your >> control, >> b) you don't already have other Kerberos instance (FreeIPA, MIT >> KRB5, MS AD, ...) with ANOTHERDOMAIN.COM >> realm deployed. >> >> With FreeIPA you can run >> # ipa-server-install --domain example.com >> --realm ANOTHERDOMAIN.COM >> >> >> But before you do, why do you want to have the realm different >> from the domain? >> >> > >Question: what "domain" does the --domain option to ipa-server-install >actually refer to? > >The man page just says " Your DNS domain name". But what does it >actually alter? > >1. the DNS domain which holds the kerberos realm location information? >I don't think so; I think if you are searching for realm FOO.COM >you'll always look in the DNS under "foo.com", that's a fixed >relationship. > >2. the DNS name of the IPA server itself? But if set up correctly, it >already has an FQDN (as reported by "hostname -f"). And if you give >the "--hostname" option, that's a FQDN not a bare hostname. > >3. the DNS zone which IPA is authoritative for? But you can run IPA >without integrated DNS. > >4. the LDAP base DN? I guess that could be it: e.g. "--domain foo.com" >puts everything under tree "dc=foo,dc=com"? > >5. something else? It is a combination of some of the above. LDAP base DN is generated based on the realm name. DNS domain specified in --domain option is considered a DNS domain we are authoritative for in the case we install with integrated DNS server. Kerberos realm name effectively forces use of the DNS domain equal to the realm name as your primary DNS domain (forest root domain in terms of Active Directory), but given that we could remap DNS and realm relationship with krb5.conf, we are at a bit more flexibility than Active Directory design allows here. So you can have IPA masters with FQDNs in totally different DNS domains than dictated by their Kerberos realm and --domain options. In such situation you would need to make sure there are additional hints for the IPA clients to properly find these IPA masters, but nothing dramatically serious. You can have Kerberos realm and --domain options to point to different DNS domains too, though we would not recommend that in a longer term given you'd still need to own DNS domain named as your Kerberos realm to have autodiscovery working. After all, these are *flexibility* options. They are not supposed to make sense in all combinations. Where they aren't making sense, you are allowed to shoot yourself in your feet if you know what you are doing. -- / Alexander Bokovoy From b.candler at pobox.com Fri Dec 16 09:32:42 2016 From: b.candler at pobox.com (Brian Candler) Date: Fri, 16 Dec 2016 09:32:42 +0000 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: <20161216082132.rcd6zpeb3omenvq4@redhat.com> References: <65e8d18c-7c5f-4f82-57cb-8aa6069db84c@redhat.com> <20161216082132.rcd6zpeb3omenvq4@redhat.com> Message-ID: <399eafb9-16e4-c2a2-aedf-f94cc7b9d957@pobox.com> On 16/12/2016 08:21, Alexander Bokovoy wrote: > > So you can have IPA masters with FQDNs in totally different DNS domains > than dictated by their Kerberos realm and --domain options. That I understand - not only can the IPA masters have FQDNs in different DNS domains, but indeed the member machines of that realm as well. What was unclear to me was whether "ipa-server-install --domain xxx" affects the content of the database being built (and therefore replicated later to the slaves), or is just something local to the host itself. In the manpage for "ipa-client-install" it's much clearer: in that case, it says that --domain is the starting domain for LDAP server auto-discovery. To clarify, there are several DNS auto-discovery mechanisms. Two of them are described in the MIT docs at https://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Using-DNS (1) Map hostname aaa.bbb.ccc to realm xxx.yyy.zzz Look for TXT records for _kerberos.aaa.bbb.ccc, _kerberos.bbb.ccc, _kerberos.ccc. The TXT record gives the realm that this host belongs to. (2) Realm xxx.yyy.zzz to Kerberos servers for that realm Given realm xxx.yyy.zzz, look for in the DNS for SRV records for _kerberos._udp.xxx.yyy.zzz _kerberos-master._udp.xxx.yyy.zzz _kpasswd._udp.xxx.yyy.zzz This is all very clear. Now, the manpage for ipa-client-install describes another one, which is where I get a bit fuzzy: (3) DNS Autodiscovery Client installer by default tries to search for _ldap._tcp.DOMAIN DNS SRV records for all domains that are parent to its hostname. For exam- ple, if a client machine has a hostname 'client1.lab.example.com', the installer will try to retrieve an IPA server hostname from _ldap._tcp.lab.example.com, _ldap._tcp.example.com and _ldap._tcp.com DNS SRV records, respectively. The discovered domain is then used to configure client components (e.g. SSSD and Kerberos 5 configuration) on the machine. What it doesn't actually say (but I believe must be true) is that what it calls the "discovered domain" is in fact the *realm* to use. If so, effectively this is algorithm (2) in reverse: instead of using it for realm to SRV mapping, you hunt for a domain which contains the right SRV records and use this to infer your realm. Is that right? (Is this a mechanism modelled on Active Directory? Otherwise, I would have thought you could use MIT algorithm (1) to discover your realm) > > After all, these are *flexibility* options. They are not supposed to > make sense in all combinations. Where they aren't making sense, you are > allowed to shoot yourself in your feet if you know what you are doing. > Absolutely, and I don't want to get this wrong and have to start again :-) OK, I have a final question on the planning of realms and DNS. As we've already said, in an IPA-only installation, the machines which are members of the realms can happily have hostnames which are unrelated to the realm name: e.g. IPA.EXAMPLE.COM | | | machines .foo.com machines .bar.com A user in IPA.EXAMPLE.COM can login to host .foo.com, either because their krb5.conf has a static domain->realm mapping, or there's a DNS entry: _kerberos.foo.com TXT "IPA.EXAMPLE.COM" However, suppose I plan to end up with a trust to an Active Directory / Samba4 realm: AD.EXAMPLE.COM <--trust--> IPA.EXAMPLE.COM | | | | | | users machines I want to allow users in the AD.EXAMPLE.COM realm to login to machines in the IPA.EXAMPLE.COM realm. Will this still work when the machines are in different DNS domains? Or at this point, am I forced to give all the machines hostnames of the form .ipa.example.com ? If the latter is true, it would be wise for me to start naming my hosts .ipa.example.com in the first place. Thanks, Brian. From abokovoy at redhat.com Fri Dec 16 10:19:00 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 16 Dec 2016 12:19:00 +0200 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: <399eafb9-16e4-c2a2-aedf-f94cc7b9d957@pobox.com> References: <65e8d18c-7c5f-4f82-57cb-8aa6069db84c@redhat.com> <20161216082132.rcd6zpeb3omenvq4@redhat.com> <399eafb9-16e4-c2a2-aedf-f94cc7b9d957@pobox.com> Message-ID: <20161216101900.ldzxzicneih7sgvj@redhat.com> On pe, 16 joulu 2016, Brian Candler wrote: >On 16/12/2016 08:21, Alexander Bokovoy wrote: >> >>So you can have IPA masters with FQDNs in totally different DNS domains >>than dictated by their Kerberos realm and --domain options. > >That I understand - not only can the IPA masters have FQDNs in >different DNS domains, but indeed the member machines of that realm as >well. > >What was unclear to me was whether "ipa-server-install --domain xxx" >affects the content of the database being built (and therefore >replicated later to the slaves), or is just something local to the >host itself. > >In the manpage for "ipa-client-install" it's much clearer: in that >case, it says that --domain is the starting domain for LDAP server >auto-discovery. > >To clarify, there are several DNS auto-discovery mechanisms. Two of >them are described in the MIT docs at >https://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Using-DNS > >(1) Map hostname aaa.bbb.ccc to realm xxx.yyy.zzz > >Look for TXT records for _kerberos.aaa.bbb.ccc, _kerberos.bbb.ccc, >_kerberos.ccc. The TXT record gives the realm that this host belongs >to. > >(2) Realm xxx.yyy.zzz to Kerberos servers for that realm > >Given realm xxx.yyy.zzz, look for in the DNS for SRV records for >_kerberos._udp.xxx.yyy.zzz >_kerberos-master._udp.xxx.yyy.zzz >_kpasswd._udp.xxx.yyy.zzz > >This is all very clear. > >Now, the manpage for ipa-client-install describes another one, which >is where I get a bit fuzzy: > >(3) > > DNS Autodiscovery > Client installer by default tries to search for >_ldap._tcp.DOMAIN DNS SRV records for all domains that are parent to >its hostname. For example, if a client machine has a hostname >'client1.lab.example.com', the installer will try to retrieve >an IPA server hostname from _ldap._tcp.lab.example.com, >_ldap._tcp.example.com and _ldap._tcp.com DNS SRV records, >respectively. The discovered domain is then used to configure client >components (e.g. SSSD and Kerberos 5 configuration) on >the machine. > >What it doesn't actually say (but I believe must be true) is that what >it calls the "discovered domain" is in fact the *realm* to use. If >so, effectively this is algorithm (2) in reverse: instead of using it >for realm to SRV mapping, you hunt for a domain which contains the >right SRV records and use this to infer your realm. > >Is that right? In case of IPA client you need to deal with both Kerberos realm and application-level LDAP servers. The latter aren't related to Kerberos realm themselves. However, authentication to them is based on GSSAPI and thus Kerberos. So discovery of the LDAP servers is done via SRV records according to https://tools.ietf.org/html/draft-ietf-ldapext-locate-08 and RFC2782 but Kerberos configuration is done based on the corresponding DNS SRV records too (_ldap versus _kerberos for two different purposes). It became customary when Active Directory was introduced in 2000, that when both _ldap..domain and _kerberos..domain DNS SRV records exist, they are assumed to be explaining the services from the same Kerberos realm. On MIT Kerberos side use of DNS TXT record allows you to easily discover the actual name of the realm too. On Active Directory side it is not the case but there realm name is equal to the DNS domain name for the AD domains and additional DNS domains are actually discovered through completely different means -- by using netr_DsRGetForestTrustInformation function over LSA pipe. >(Is this a mechanism modelled on Active Directory? Otherwise, I would >have thought you could use MIT algorithm (1) to discover your realm) https://tools.ietf.org/html/draft-ietf-ldapext-locate-08 was driven by Microsoft and since early 2000s was implemented in many LDAP libraries. Needless to say, OpenLDAP utilities supports DNS SRV records discovery too, see -H option in ldapsearch manual page for example. >>After all, these are *flexibility* options. They are not supposed to >>make sense in all combinations. Where they aren't making sense, you are >>allowed to shoot yourself in your feet if you know what you are doing. >> >Absolutely, and I don't want to get this wrong and have to start again :-) > >OK, I have a final question on the planning of realms and DNS. > >As we've already said, in an IPA-only installation, the machines which >are members of the realms can happily have hostnames which are >unrelated to the realm name: e.g. > > IPA.EXAMPLE.COM > | | | >machines .foo.com >machines .bar.com > >A user in IPA.EXAMPLE.COM can login to host .foo.com, either >because their krb5.conf has a static domain->realm mapping, or there's >a DNS entry: _kerberos.foo.com TXT "IPA.EXAMPLE.COM" > >However, suppose I plan to end up with a trust to an Active Directory >/ Samba4 realm: > >AD.EXAMPLE.COM <--trust--> IPA.EXAMPLE.COM > | | | | | | > users machines > >I want to allow users in the AD.EXAMPLE.COM realm to login to machines >in the IPA.EXAMPLE.COM realm. > >Will this still work when the machines are in different DNS domains? Yes, it will. Here is the catch: you need to make sure these different DNS domains all mentioned in 'ipa realmdomains-show' and if not, they should be added by use of 'ipa realmdomains-mod'. None of these domains must overlap with Active Directory domains, of course. When trust is established, Active Directory DCs will retrieve and validate list of name routing suffixes associated with IPA forest using netr_DsRGetForestTrustInformation LSA RPC call. 'ipa realmdomains-*' commands manage what exactly we return there. We automatically manage realm domains list if IPA does control the DNS server -- adding a DNS zone will cause an entry added to the 'ipa realmdomains-*'. However, if DNS domains are managed externally, it is your duty to manage realm domains too. -- / Alexander Bokovoy From b.candler at pobox.com Fri Dec 16 10:40:06 2016 From: b.candler at pobox.com (Brian Candler) Date: Fri, 16 Dec 2016 10:40:06 +0000 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: <20161216101900.ldzxzicneih7sgvj@redhat.com> References: <65e8d18c-7c5f-4f82-57cb-8aa6069db84c@redhat.com> <20161216082132.rcd6zpeb3omenvq4@redhat.com> <399eafb9-16e4-c2a2-aedf-f94cc7b9d957@pobox.com> <20161216101900.ldzxzicneih7sgvj@redhat.com> Message-ID: <9cd89854-eff4-b50c-f9b4-03a4ee4a5f04@pobox.com> On 16/12/2016 10:19, Alexander Bokovoy wrote: >> I want to allow users in the AD.EXAMPLE.COM realm to login to >> machines in the IPA.EXAMPLE.COM realm. >> >> Will this still work when the machines are in different DNS domains? > Yes, it will. Here is the catch: you need to make sure these different > DNS domains all mentioned in 'ipa realmdomains-show' and if not, they > should be added by use of 'ipa realmdomains-mod'. None of these domains > must overlap with Active Directory domains, of course. Fantastic answer. Thank you so much for taking the time to explain this. Regards, Brian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Fri Dec 16 10:51:57 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Fri, 16 Dec 2016 11:51:57 +0100 Subject: [Freeipa-users] ipa fails to start after centos 7.3 upgrade In-Reply-To: <590bde66-1927-88f1-8ec4-d1e8c9b4ee74@redhat.com> References: <590bde66-1927-88f1-8ec4-d1e8c9b4ee74@redhat.com> Message-ID: 2016-12-15 13:47 GMT+01:00 Petr Vobornik : > On 12/12/2016 08:53 PM, Rob Verduijn wrote: > > Hello, > > > > I've recently upgraded to centos 7.3. > > Didn't intend to so soon but should have checked the anounce lists before > > launching my ansible update playbook. > > > > Most of my servers came through, and mostly also the ipa server. > > There were duplicate rpms and a failed rpm upgrade. > > After some yum magic the rpm duplicates where gone and all the updates > installed. > > > > Manually running ipa-server-upgrade also seems to finish properly. > > > > However > > ipactl start keeps failing on the ntpd service. > > Not a big surprise since its running chronyd. > > > > I now start the ipa server with 'ipactl start --ignore-service-failure' > > > > Is there a way to explain the script that it should check for chronyd > instead of > > ntpd ? > > > > I also see this a lot in the logs: > > dns_rdatatype_fromtext() failed for attribute > > 'idnsTemplateAttribute;cnamerecord': unknown class/type > > > > Is that a serious error ? > > > > Rob Verduijn > > > > This looks like 7.3 update incorrectly added NTP service to IPA server > services (which is displayed as NTP role in `ipa server-show $server`). > > A workaround might be to disable the service or remove the service > entry. Disabling is IMHO safer. IPA CLI tools don't allow > enabling/disabling of services so it must be done by LDAP mod. > > It can be done by removing 'enabledService' config value from server's > service entry, e.g.: > > dn: cn=NTP,cn=$SERVER_FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX > changetype: modify > delete: ipaConfigString > ipaConfigString: enabledService > - > > Where $SERVER_FQDN is e.g. ipa.example.com and $SUFFIX is e.g. > dc=example,dc=com > > > Rob, have you originally installed the replica with NTPD and then later > switched manually to chrony? > > -- > Petr Vobornik > Hello, I can't remember if I installed and configured freeipa and then switched to chronyd or the other way around. I had my ntpd/ntpdate services masked because I got tired of stopping and disabling them all the time. It seems ipactl can't deal with that. Currently I unmasked the services and enabled them (disabling chronyd) so that the server boots properly. I will try your ldiff to see if I can switch back, since I do not use my ipa server as a time source for clients. I'll let you know the results. Rob Verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkrizek at redhat.com Fri Dec 16 11:22:46 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Fri, 16 Dec 2016 12:22:46 +0100 Subject: [Freeipa-users] Announcing bind-dyndb-ldap version 11.0 Message-ID: <49b328f1-0050-2fce-7c6e-30d6093683ad@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 11.0. It can be downloaded fromhttps://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora Rawhide. Latest news: 11.0 ==== [1] The plugin was ported to BIND 9.11. Minimal BIND version is now 9.11.0rc1. https://fedorahosted.org/bind-dyndb-ldap/ticket/161 [2] Configuration format in named.conf is different and incompatible with all previous versions. Please see README.md. [3] Obsolete plugin options were removed: cache_ttl, psearch, serial_autoincrement, zone_refresh. == Upgrading == A server can be upgraded by installing updated RPM. If your named.conf has configuration for dyndb, you need to manually update it to reflect the new configuration format. Please see README.md for more information. BIND has to be manually restarted afterwards. == Limited compatibility with BIND 9 == bind-dyndb-ldap version 11.0 is only compatible with BIND 9.11 and newer. == Known Issues == There are the following issues in Fedora Rawhide: - 1403352: New FreeIPA installations generate old and incompatible configuration in named.conf. - 1404409: Using GSSAPI authentication for 389-ds results in an error, simple bind is not affected. - named-pkcs11 does not start with dyndb configured. named is not affected. We are currently working on resolving these issues. == Feedback == Please provide comments, report bugs, and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Tomas Krizek From flo at redhat.com Fri Dec 16 14:54:32 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Fri, 16 Dec 2016 15:54:32 +0100 Subject: [Freeipa-users] Failed ipa-client-install with IPA Replica In-Reply-To: References: <794d723f-9994-2281-1add-c5d0d1167257@redhat.com> Message-ID: On 12/15/2016 08:01 PM, beeth beeth wrote: > Hi Flo, > > That's a good point! I checked the dirsrv certificate and confirmed > valid(good until later next year). > Since I had no problem to enroll another new IPA client(RHEL7 box > instead of RHEL6) to such replica server, I thought it might not be a > server end issue. However, when I tried to restart the DIRSRV service on > the replica server, I found these messages in the log > file /var/log/dirsrv/slapd-IPA-EXAMPLE-COM/errors: > > [15/Dec/2016:13:38:15.891301246 -0500] 389-Directory/1.3.5.10 > B2016.257.1817 starting up > [15/Dec/2016:13:38:15.911777373 -0500] default_mr_indexer_create: > warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match > [15/Dec/2016:13:38:15.926320306 -0500] WARNING: changelog: entry cache > size 2097152 B is less than db size 5488640 B; We recommend to increase > the entry cache size nsslapd-cachememsize. > [15/Dec/2016:13:38:16.132155534 -0500] schema-compat-plugin - scheduled > schema-compat-plugin tree scan in about 5 seconds after the server startup! > [15/Dec/2016:13:38:16.167896279 -0500] NSACLPlugin - The ACL target > cn=dns,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.173317345 -0500] NSACLPlugin - The ACL target > cn=dns,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.178354342 -0500] NSACLPlugin - The ACL target > cn=keys,cn=sec,cn=dns,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.183579322 -0500] NSACLPlugin - The ACL target > cn=dns,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.188786976 -0500] NSACLPlugin - The ACL target > cn=dns,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.193275650 -0500] NSACLPlugin - The ACL target > cn=groups,cn=compat,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.197580407 -0500] NSACLPlugin - The ACL target > cn=computers,cn=compat,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.201863256 -0500] NSACLPlugin - The ACL target > cn=ng,cn=compat,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.206318629 -0500] NSACLPlugin - The ACL target > ou=sudoers,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.211559100 -0500] NSACLPlugin - The ACL target > cn=users,cn=compat,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.216146819 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.220786596 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.225594942 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.229986749 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.234518367 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.238763121 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.243031116 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.247507984 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.252327210 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.259046910 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.263856581 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.269301704 -0500] NSACLPlugin - The ACL target > cn=ad,cn=etc,dc=ipa,dc=example,dc=com does not exist > [15/Dec/2016:13:38:16.283511408 -0500] NSACLPlugin - The ACL target > cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does > not exist > [15/Dec/2016:13:38:16.287853825 -0500] NSACLPlugin - The ACL target > cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does > not exist > [15/Dec/2016:13:38:16.395872649 -0500] NSACLPlugin - The ACL target > cn=automember rebuild membership,cn=tasks,cn=config does not exist > [15/Dec/2016:13:38:16.405404114 -0500] Skipping CoS Definition > cn=Password Policy,cn=accounts,dc=ipa,dc=example,dc=com--no CoS > Templates found, which should be added before the CoS Definition. > [15/Dec/2016:13:38:16.463117873 -0500] set_krb5_creds - Could not get > initial credentials for principal > [ldap/ipaprd2.example.com at IPA.EXAMPLE.COM > ] in keytab > [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) > [15/Dec/2016:13:38:16.471256279 -0500] schema-compat-plugin - > schema-compat-plugin tree scan will start in about 5 seconds! > [15/Dec/2016:13:38:16.479213976 -0500] slapd started. Listening on All > Interfaces port 389 for LDAP requests > [15/Dec/2016:13:38:16.483683353 -0500] Listening on > /var/run/slapd-IPA-EXAMPLE-COM.socket for LDAPI requests > [15/Dec/2016:13:38:21.634319974 -0500] schema-compat-plugin - warning: > no entries set up under ou=sudoers,dc=ipa,dc=example,dc=com > [15/Dec/2016:13:38:21.639855161 -0500] schema-compat-plugin - warning: > no entries set up under cn=ng, cn=compat,dc=ipa,dc=example,dc=com > [15/Dec/2016:13:38:21.653406463 -0500] schema-compat-plugin - no RDN for > cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com, unsetting > domain/map/id > "cn=compat,dc=ipa,dc=example,dc=com"/"cn=groups"/("cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com") > [15/Dec/2016:13:38:21.714897614 -0500] schema-compat-plugin - warning: > no entries set up under cn=computers, cn=compat,dc=ipa,dc=example,dc=com > [15/Dec/2016:13:38:21.719933118 -0500] schema-compat-plugin - Finished > plugin initialization. > [15/Dec/2016:13:38:36.591969481 -0500] ipa-topology-plugin - > ipa_topo_util_get_replica_conf: server configuration missing > [15/Dec/2016:13:38:36.598683009 -0500] ipa-topology-plugin - > ipa_topo_util_get_replica_conf: cannot create replica > > Any idea? > BTW, everything ran well on IPA 4.2(server installation and client > installation), as you once assisted me couple months ago, until we set > up a new IPA environment with RHEL7.3 instead of RHEL7.2, then the IPA > version changed from 4.2 to 4.4. Last time you guided me about the > change since IPA 4.3, for the newly introduced domain level concept, and > the way how the replica should be installed was changed too... Thanks again! > Hi Beeth, I managed to reproduce your issue with IPA master installed without dns and without integrated CA. Can you check on your RHEL 6 client if there is a file /etc/ipa/ca.crt? If yes, check its content with $ sudo openssl x509 -noout -text -in /etc/ipa/ca.crt and compare with the CA certificate stored on the master or the replica (at the same location /etc/ipa/ca.crt). The certificate should be the one for the CA that signed your HTTPd and LDAP server certs (ie Verisign). If the certificate is different, it is probably a left-over CA certificate corresponding to a previous installation. You can just delete the file on the client and re-run ipa-client-install. Flo. > > On Thu, Dec 15, 2016 at 10:52 AM, Florence Blanc-Renaud > wrote: > > On 12/14/2016 07:49 PM, beeth beeth wrote: > > Hi Flo, > > Thanks for the great hint! I reran the ipa-client-install on the > rhel6 > box(ipadev6), and monitored the access log file you mentioned on the > replica: > > # ipa-client-install --domain=ipa.example.com > > --server=ipaprd2.example.com > > --hostname=ipadev6.example.com > -d > > ( ipaprd2 = primary IPA server on RHEL7; ipadev6 = replica on > RHEL6 ) > > AFTER about 3 seconds, I saw these on the replica ipaprd2: > [14/Dec/2016:13:11:41.071421132 -0500] conn=1040 fd=73 slot=73 > connection from to > [14/Dec/2016:13:11:41.071880026 -0500] conn=1040 op=0 EXT > oid="1.3.6.1.4.1.1466.20037" > [14/Dec/2016:13:11:41.071964217 -0500] conn=1040 op=0 RESULT err=2 > tag=120 nentries=0 etime=0 > [14/Dec/2016:13:11:41.073275674 -0500] conn=1040 op=1 UNBIND > [14/Dec/2016:13:11:41.073307101 -0500] conn=1040 op=1 fd=73 > closed - U1 > [14/Dec/2016:13:11:41.074782496 -0500] conn=1041 fd=73 slot=73 > connection from to > [14/Dec/2016:13:11:41.074985233 -0500] conn=1041 op=0 EXT > oid="1.3.6.1.4.1.1466.20037" > [14/Dec/2016:13:11:41.075022849 -0500] conn=1041 op=0 RESULT err=2 > tag=120 nentries=0 etime=0 > [14/Dec/2016:13:11:41.075448887 -0500] conn=1041 op=1 UNBIND > [14/Dec/2016:13:11:41.075460964 -0500] conn=1041 op=1 fd=73 > closed - U1 > [14/Dec/2016:13:11:49.006146850 -0500] conn=1029 op=8 UNBIND > [14/Dec/2016:13:11:49.006181982 -0500] conn=1029 op=8 fd=66 > closed - U1 > > So I did see the err=2, and oid="1.3.6.1.4.1.1466.20037", I > checked the > oid and got: > > 1.3.6.1.4.1.1466.20037: StartTLS Request (RFC 4511) > > It looked to be related with TLS... pease advise. Thanks! > > > Hi, > > when the replica got installed, the installer must have configured > the directory server for SSL and start TLS. I tend to suspect an > expired certificate issue rather than a misconfiguration. Could you > please check that dirsrv certificate is still valid? > > $ certutil -L -d /etc/dirsrv/slapd-DOMAIN-COM/ -n Server-Cert |grep Not > Not Before: Wed Dec 14 16:56:02 2016 > Not After : Sat Dec 15 16:56:02 2018 > > If the certificate is still valid, you may want to read 389-ds > How-To to make sure that SSL is properly setup: > http://directory.fedoraproject.org/docs/389ds/howto/howto-ssl.html#deploy-the-settings > > > Flo. > > > On Wed, Dec 14, 2016 at 7:57 AM, Florence Blanc-Renaud > > >> wrote: > > On 12/14/2016 01:08 PM, beeth beeth wrote: > > Thanks David. I installed both the master and replica IPA > servers with > third-party certificates(Verisign), but I doubt that > could be > the issue, > because I had no problem to run the same ipa-client-install > command on a > RHEL7 machine(of course, the --hostname used a different > hostname of the > server). And I had no problem to run the ipa-client-install > command with > --server= on such RHEL6 machine. So what could > cause the > LDAP > communication failed during the client enrollment with the > replica? Is > there a way I can troubleshoot this by running some > commands? So > far I > did telnet to check the open ports, as well as run the > ldapsearch > towards the replica. Thanks again! > > > On Tue, Dec 13, 2016 at 8:46 AM, David Kupka > > > > > >>> wrote: > > On 13/12/16 05:44, beeth beeth wrote: > > I have two IPA servers ipaprd1.example.com > > > and > ipaprd2.example.com > > , running > ipa 4.4 on RHEL7. When I tried to > install/configure the > client > on a RHEL6 > system(called ipadev6), I had issue when I tried to > enroll it > with the > replica(ipaprd2), while no issue with the > primary(ipaprd1): > > # ipa-client-install --domain=ipa.example.com > > > > --server=ipaprd1.example.com > > > --server=ipaprd2.example.com > > > --hostname=ipadev6.example.com > > > LDAP Error: Protocol error: unsupported extended > operation > Autodiscovery of servers for failover cannot > work with this > configuration. > If you proceed with the installation, services > will be > configured to always > access the discovered server for all operations > and will not > fail over to > other servers in case of failure. > Proceed with fixed values and no DNS discovery? [no] > > Then I tried to run ipa-client-install to enroll > with the > replica(ipaprd2), > with debug mode, I got this: > > # ipa-client-install --domain=ipa.example.com > > > > --server=ipaprd2.example.com > > > --hostname=ipadev6.example.com > > -d > > /usr/sbin/ipa-client-install was invoked with > options: > {'domain': ' > ipa.example.com > > ', 'force': False, > 'realm_name': None, > 'krb5_offline_passwords': True, 'primary': False, > 'mkhomedir': > False, > 'create_sshfp': True, 'conf_sshd': True, > 'conf_ntp': True, > 'on_master': > False, 'ntp_server': None, 'nisdomain': None, > 'no_nisdomain': False, > 'principal': None, 'hostname': > 'ipadev6.example.com > > ', 'no_ac': False, > 'unattended': None, 'sssd': True, 'trust_sshfp': > False, > 'kinit_attempts': > 5, 'dns_updates': False, 'conf_sudo': True, > 'conf_ssh': > True, > 'force_join': > False, 'ca_cert_file': None, 'server': > ['ipaprd2.example.com > > '], > 'prompt_password': False, 'permit': False, > 'debug': True, > 'preserve_sssd': > False, 'uninstall': False} > missing options might be asked for interactively > later > Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > Loading StateFile from > '/var/lib/ipa-client/sysrestore/sysrestore.state' > [IPA Discovery] > Starting IPA discovery with > domain=ipa.example.com > > , servers=[' > ipaprd2.example.com > > '], > hostname=ipadev6.example.com > > > Server and domain forced > [Kerberos realm search] > Search DNS for TXT record of > _kerberos.ipa.example.com > > > > >>. > No DNS record found > Search DNS for SRV record of > _kerberos._udp.ipa.example.com > > . > No DNS record found > SRV record for KDC not found! Domain: > ipa.example.com > > > [LDAP server check] > Verifying that ipaprd2.example.com > > > (realm None) is an IPA server > Init LDAP connection with: > ldap://ipaprd2.example.com:389 > > > > >> > LDAP Error: Protocol error: unsupported extended > operation > Discovery result: UNKNOWN_ERROR; server=None, > domain=ipa.example.com > > , > kdc=None, basedn=None > Validated servers: > will use discovered domain: ipa.example.com > > > IPA Server not found > [IPA Discovery] > Starting IPA discovery with > domain=ipa.example.com > > , servers=[' > ipaprd2.example.com > > '], > hostname=ipadev6.example.com > > > Server and domain forced > [Kerberos realm search] > Search DNS for TXT record of > _kerberos.ipa.example.com > > > > >>. > No DNS record found > Search DNS for SRV record of > _kerberos._udp.ipa.example.com > > . > No DNS record found > SRV record for KDC not found! Domain: > ipa.example.com > > > [LDAP server check] > Verifying that ipaprd2.example.com > > > (realm None) is an IPA server > Init LDAP connection with: > ldap://ipaprd2.example.com:389 > > > > >> > LDAP Error: Protocol error: unsupported extended > operation > Discovery result: UNKNOWN_ERROR; server=None, > domain=ipa.example.com > > , > kdc=None, basedn=None > Validated servers: > Failed to verify that ipaprd2.example.com > > > is an IPA Server. > This may mean that the remote server is not up > or is not > reachable due to > network or firewall settings. > Please make sure the following ports are opened > in the > firewall > settings: > TCP: 80, 88, 389 > UDP: 88 (at least one of TCP/UDP ports 88 > has to be > open) > Also note that following ports are necessary for > ipa-client working > properly after enrollment: > TCP: 464 > UDP: 464, 123 (if NTP enabled) > (ipaprd2.example.com > > : Provided as > option) > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > > I double checked the services running on the > replica, > all looked > well: > ports are listening, and I could telnet the > ports from the > client(ipadev6). > I could run "ldapserach" command to talk to the > replica(ipaprd2) > from this > client(ipadev6), with pulling out all the LDAP > records. > > Also, I have another test box running RHEL7, and no > issue at all > to run the > exact same ipa-client-install command on that > RHEL7 box. So > could there be > a bug on the ipa-client software on RHEL6, to > talk to > IPA sever > running on > RHEL7? Please advise. Thank you! > > Hi Beeth, > > you may want to check the access and errors log of the Directory > Server in /var/log/dirsrv/slapd-DOMAIN. The extended > operations are > logged in the access log with the tag "EXT oid=...", but a > failing > operation related to unsupported extended operation will > probably > log a "RESULT err=2". > > So I would first check access log and look for such a > failure. With > the OID we will be able to understand which operation is > failing and > which part could be misconfigured. > > HTH, > Flo. > > Best regards, > Beeth > > > > Hello Beeth, > I've tried to reproduce the problem you described > with 7.3 > (ipa-server 4.4.0-12) on master and replica and 6.9 > (ipa-client > 3.0.0-51) on client and it worked for me as expected. > I've done these steps: > [master] # ipa-server-install -a Secret123 -p > Secret123 --domain > example.test --realm EXAMPLE.TEST --setup-dns > --auto-forwarders -U > [replica] # ipa-client-install -p admin -w Secret123 > --domain > example.test --server master.example.test -U > [replica] # ipa-replica-install > [client] # ipa-client-install -p admin -w Secret123 > --domain > example.test --server replica.example.test -U > [client] # id admin > > Is there anything you've done differently? > > -- > David Kupka > > > > > > > > From rob.verduijn at gmail.com Fri Dec 16 17:53:32 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Fri, 16 Dec 2016 18:53:32 +0100 Subject: [Freeipa-users] FYI incorrect configuration when using ipa-client-automount Message-ID: Hello, I've was being bugged by a non functional automounter. So I tried a fresh centos7.3 install (minimal) with only the additional package ipa-client. I did the installation and update to latest patch level and reboot. Then ran ipa-client-install --enable-dns-updates Did the yes/admin account/auth And I had a fully functional freeipa-domain-client. Then I ran ipa-client-automount yes again. and no functional automounter. It appeared that the 'ipa-client-automount' tool did not adjust the /etc/nsswitch.conf file properly. In one occasion it replaced 'automount: files nisplus' with 'automount: files' in another it did not change it at all. After editing /etc/nsswitch.conf and setting it to 'automount: files sss' all was working as expected. Because there is not mention about centos on https://fedorahosted.org/freeipa/ and I'm used to seeing closed not supported on the redhat bugzilla when the word centos is mentioned I've posterd it in the centos buglist : https://bugs.centos.org/view.php?id=12415 Cheers Rob Verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfw113 at psu.edu Fri Dec 16 18:54:30 2016 From: mfw113 at psu.edu (Mike Waite) Date: Fri, 16 Dec 2016 13:54:30 -0500 Subject: [Freeipa-users] Add text to web login page Message-ID: <2e16101d257cd$d61be430$8253ac90$@psu.edu> I need to add a login banner to the login page for freeIPA, is there a setting that I could easily change for this? Thanks, -- Mike Waite From mexigabacho at gmail.com Fri Dec 16 20:35:40 2016 From: mexigabacho at gmail.com (Christopher Young) Date: Fri, 16 Dec 2016 15:35:40 -0500 Subject: [Freeipa-users] Replica issue / Certificate Authority Message-ID: I'm hoping to provide enough information to get some help to a very important issue that I'm currently having. I have two IPA servers at a single location that recently had a replication issue that I eventually resolved by reinitializing one of the masters/replicas with one that seemed to be the most 'good'. In any case, somewhere in this process, the new IPA 4.4 was release with/for CentOS 7.3. At this moment, regular replication seems to be working properly (in that I don't have any obvious issues and web interfaces on both systems seem to be consistent for updates EXCEPT when it comes to the certificates). Before I get to the errors, here is the output of some of the commands that I would expect anyone would need: ---------- [root at ipa01 ~]# ipa-replica-manage list ipa01.passur.local: master ipa02.passur.local: master ----- [root at ipa01 ~]# ipa-replica-manage list -v ipa01.passur.local ipa02.passur.local: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2016-12-16 20:25:40+00:00 ----- [root at ipa01 ~]# ipa-replica-manage list -v ipa02.passur.local ipa01.passur.local: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2016-12-16 20:25:40+00:00 ----- [root at ipa01 ~]# ipa-replica-manage list-ruv Replica Update Vectors: ipa01.passur.local:389: 4 ipa02.passur.local:389: 6 Certificate Server Replica Update Vectors: ipa02.passur.local:389: 97 ipa01.passur.local:389: 96 ---------- After the yum updates were applied to each system, I noticed that the results of 'ipa-server-upgrade' were quite different. The 'ipa02' system went through without errors (this was also the system I used to reinitialize the other when I had a replication issue recently). On 'ipa01', I have following at the end of the 'ipaupgrade.log' file: ---------- 2016-12-14T18:09:26Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2016-12-14T18:09: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/ipaserver/install/ipa_server_upgrade.py", line 46, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1863, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1785, in upgrade_configuration ca_enable_ldap_profile_subsystem(ca) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 336, in ca_enable_ldap_profile_subsystem cainstance.migrate_profiles_to_ldap() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1984, in migrate_profiles_to_ldap _create_dogtag_profile(profile_id, profile_data, overwrite=False) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1990, in _create_dogtag_profile with api.Backend.ra_certprofile as profile_api: File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 2060, in __enter__ raise errors.RemoteRetrieveError(reason=_('Failed to authenticate to CA REST API')) 2016-12-14T18:09:26Z DEBUG The ipa-server-upgrade command failed, exception: RemoteRetrieveError: Failed to authenticate to CA REST API 2016-12-14T18:09:26Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: RemoteRetrieveError: Failed to authenticate to CA REST API 2016-12-14T18:09:26Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information ---------- In addition, when I go to the IPA web interface on the 'ipa01' system, I get the following when I try to view any of the certificates: ---------- IPA Error 4301: CertificateOperationError Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ---------- I was wondering if there was a method for taking all the CA details/tree/what have you from my 'ipa02' system and using it to repopulate the 'ipa01'. Since everything else seems to be working correctly after a reinitialize on 'ipa01', I thought this would be the safest way, but I'm opening any solutions as I need to get this fixed ASAP. Please let me know any additional details that may help OR if there is a procedure that I could use to quickly and easily recreate 'ipa01' WITH the certificate authority properly working on both. I may need some educate there. Thanks! -- Chris From mexigabacho at gmail.com Fri Dec 16 20:47:53 2016 From: mexigabacho at gmail.com (Christopher Young) Date: Fri, 16 Dec 2016 15:47:53 -0500 Subject: [Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA Error 4301: CertificateOperationError) In-Reply-To: References: <8776E3A1-A1DE-42FA-9C11-B32BDFC88D48@high5games.com> <11A7EF75-24E7-4F02-9BB7-B128EF8005E9@high5games.com> <575B0B96.8070502@redhat.com> <4FD7DA07-768F-4EFF-AECB-F49007407213@high5games.com> <575B2E7D.4050206@redhat.com> <55BB6337-5F5F-449C-802E-1DC2097046D8@high5games.com> Message-ID: I have a similar issue (see my recent list post), and I was wondering if this was ever fixed? CA appears to work one system (master/replica) but not the other. On Mon, Jun 13, 2016 at 4:41 AM, Petr Vobornik wrote: > On 06/12/2016 07:05 PM, Dan.Finkelstein at high5games.com wrote: >> The restore I was referring to was a red herring; we ended up wiping the server >> and saving ipa-backup files, which was the only way we could successfully >> reconfigure/reinitialize IPA on the host. >> > > As Rob wrote, please check PKI logs. The most important ones here are: > > /var/log/pki/pki-tomcat/ca/selftests.log > /var/log/pki/pki-tomcat/ca/debug > > Debug log usually has additional info for possible cause logged in > selftest log. > > >> *From: *Rob Crittenden >> *Date: *Friday, June 10, 2016 at 17:17 >> *To: *Daniel Finkestein , >> "freeipa-users at redhat.com" >> *Subject: *Re: [Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA Error >> 4301: CertificateOperationError) >> >> Dan.Finkelstein at high5games.com wrote: >> >> And, from the 'ipactl -d --ignore-service-failures restart' we get this: >> >> ipa: DEBUG: stderr= >> >> ipa: DEBUG: wait_for_open_ports: localhost [8080, 8443] timeout 300 >> >> ipa: DEBUG: Waiting until the CA is running >> >> ipa: DEBUG: Starting external process >> >> ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' >> >> '--no-check-certificate' >> >> 'https://ipa.example.com:8443/ca/admin/ca/getStatus' >> >> ipa: DEBUG: Process finished, return code=4 >> >> ipa: DEBUG: stdout= >> >> ipa: DEBUG: stderr=--2016-06-10 15:29:38-- >> >> https://ipa.example.com:8443/ca/admin/ca/getStatus >> >> Resolving ipa.example.com (ipa.example.com)... 10.55.10.31 >> >> Connecting to ipa.example.com (ipa.example.com)|10.55.10.31|:8443... >> >> connected. >> >> Unable to establish SSL connection. >> >> ipa: DEBUG: The CA status is: check interrupted due to error: Command >> >> ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' >> >> 'https://ipa.example.com:8443/ca/admin/ca/getStatus'' returned non-zero >> >> exit status 4 >> >> ipa: DEBUG: Waiting for CA to start... >> >> ipa: DEBUG: Starting external process >> >> ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' >> >> '--no-check-certificate' >> >> 'https://ipa.example.com:8443/ca/admin/ca/getStatus' >> >> ipa: DEBUG: Process finished, return code=4 >> >> ipa: DEBUG: stdout= >> >> ipa: DEBUG: stderr=--2016-06-10 15:29:43-- >> >> https://ipa.example.com:8443/ca/admin/ca/getStatus >> >> Resolving ipa.example.com (ipa.example.com)... 10.55.10.31 >> >> Connecting to ipa.example.com (ipa.example.com)|10.55.10.31|:8443... >> >> connected. >> >> Unable to establish SSL connection. >> >> ipa: DEBUG: The CA status is: check interrupted due to error: Command >> >> ''/usr/bin/wget' '-S' '-O' '-' '--timeout=30' '--no-check-certificate' >> >> 'https://ipa.example.com:8443/ca/admin/ca/getStatus'' returned non-zero >> >> exit status 4 >> >> ipa: DEBUG: Waiting for CA to start... >> >> ipa: DEBUG: Starting external process >> >> ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30' >> >> '--no-check-certificate' >> >> 'https://ipa.example.com:8443/ca/admin/ca/getStatus' >> >> Which leads me to believe that tomcat doesn't have the right certificate(s). >> >> I don't think that's the problem. I'd check the pki logs to see if it >> >> started and if not, why. Note that it is quite possible for tomcat to >> >> start and the CA to fail because tomcat is just a container. >> >> In a previous e-mail you said something about a restore, what was that? >> >> rob >> >> >> >> *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: *> > on behalf of Daniel >> >> Finkestein > > >> >> *Date: *Friday, June 10, 2016 at 14:52 >> >> *To: *"freeipa-users at redhat.com " >> > >> >> *Subject: *Re: [Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA >> >> Error 4301: CertificateOperationError) >> >> That?s exactly right, and we got the files and links back to serviceable >> >> order. Now we're (merely) facing issues with our restored certificate >> >> store, which the pki-tomcatd process is not happy with. All IPA services >> >> start normally except for tomcat, which spits out SSL errors (and we're >> >> pretty sure must be related to bad certs? somewhere). >> >> Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) >> >> Internal Database Error encountered: Could not connect to LDAP server >> >> host ipa.example.com port 636 Error netscape.ldap.LDAPException: IO >> >> Error creating JSS SSL Socket (-1) >> >> at >> >> com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:673) >> >> at >> >> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1107) >> >> at >> >> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1013) >> >> at >> >> com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:510) >> >> at com.netscape.certsrv.apps.CMS.init(CMS.java:187) >> >> at com.netscape.certsrv.apps.CMS.start(CMS.java:1601) >> >> 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) >> >> I think we might be willing to toss out the existing certificate store >> >> and start anew, which fortunately should preserve the DNS, user, group, >> >> etc., data already in LDAP. If we wanted to create a new trust and >> >> self-signed cert for the server, how are those steps different from >> >> promoting a replica to a cert-signing master? >> >> Thanks, >> >> Dan > >> >> /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: *Rob Crittenden > >> >> *Date: *Friday, June 10, 2016 at 14:48 >> >> *To: *Daniel Finkestein > >, >> >> "freeipa-users at redhat.com " >> > >> >> *Subject: *Re: [Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA >> >> Error 4301: CertificateOperationError) >> >> I'd reinstall some rpms to properly create these: >> >> tomcat >> >> pki-base >> >> pki-server >> >> I'm not positive it will fix permissions, rpm -V on the same may point >> >> out problems as well. >> >> rob >> >> >> > > > -- > Petr Vobornik > > -- > Manage your subscription for 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 mexigabacho at gmail.com Fri Dec 16 21:04:59 2016 From: mexigabacho at gmail.com (Christopher Young) Date: Fri, 16 Dec 2016 16:04:59 -0500 Subject: [Freeipa-users] Replica issue / Certificate Authority In-Reply-To: References: Message-ID: Ok. I think I have a 'hint' here, but I could use some help getting this fixed. Comparing the two IPA servers, I found the following (modified SOME of the output myself): on 'ipa02' (the 'good' one): ----- ipa cert-show 1 Issuing CA: ipa Certificate: <<>> Subject: CN=Certificate Authority,O=xxxx.LOCAL Issuer: CN=Certificate Authority,O=xxxx.LOCAL Not Before: Thu Jan 01 06:23:38 2015 UTC Not After: Mon Jan 01 06:23:38 2035 UTC Fingerprint (MD5): a6:aa:88:d4:66:e2:70:c1:e3:8c:37:0b:f3:eb:19:7d Fingerprint (SHA1): 11:c2:5a:58:bc:77:55:37:39:9b:13:b1:1a:a2:02:50:be:2e:a0:7f Serial number: 1 Serial number (hex): 0x1 Revoked: False ------ on 'ipa01' ----- ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) ----- Thinking about this, I decided to just start checking for inconsistencies and I noticed the following: ipa02: ----------- [root at ipa02 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a | openssl x509 -text | head Certificate: Data: Version: 3 (0x2) Serial Number: 268304413 (0xffe001d) Signature Algorithm: sha256WithRSAEncryption Issuer: O=xxxxx.LOCAL, CN=Certificate Authority Validity Not Before: Nov 23 18:19:31 2016 GMT Not After : Nov 13 18:19:31 2018 GMT Subject: O=xxxxx.LOCAL, CN=IPA RA ---------- ipa01: ---------- [root at ipa01 tmp]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a | openssl x509 -text | head Certificate: Data: Version: 3 (0x2) Serial Number: 7 (0x7) Signature Algorithm: sha256WithRSAEncryption Issuer: O=xxxx.LOCAL, CN=Certificate Authority Validity Not Before: Jan 1 06:24:23 2015 GMT Not After : Dec 21 06:24:23 2016 GMT Subject: O=xxxx.LOCAL, CN=IPA RA ---------- So, it looks like somewhere in the process, the certificate got renewed but not updated on 'ipa01'? I apologize as I'm trying to understand this. I believe that my end goal is probably still the same (verify replication and get things working properly on the 'ipa01' system. Any help is very much appreciated! -- Chris On Fri, Dec 16, 2016 at 3:35 PM, Christopher Young wrote: > I'm hoping to provide enough information to get some help to a very > important issue that I'm currently having. > > I have two IPA servers at a single location that recently had a > replication issue that I eventually resolved by reinitializing one of > the masters/replicas with one that seemed to be the most 'good'. > > In any case, somewhere in this process, the new IPA 4.4 was release > with/for CentOS 7.3. > > At this moment, regular replication seems to be working properly (in > that I don't have any obvious issues and web interfaces on both > systems seem to be consistent for updates EXCEPT when it comes to the > certificates). > > Before I get to the errors, here is the output of some of the commands > that I would expect anyone would need: > > ---------- > [root at ipa01 ~]# ipa-replica-manage list > ipa01.passur.local: master > ipa02.passur.local: master > ----- > [root at ipa01 ~]# ipa-replica-manage list -v ipa01.passur.local > ipa02.passur.local: replica > last init status: None > last init ended: 1970-01-01 00:00:00+00:00 > last update status: Error (0) Replica acquired successfully: > Incremental update succeeded > last update ended: 2016-12-16 20:25:40+00:00 > ----- > [root at ipa01 ~]# ipa-replica-manage list -v ipa02.passur.local > ipa01.passur.local: replica > last init status: None > last init ended: 1970-01-01 00:00:00+00:00 > last update status: Error (0) Replica acquired successfully: > Incremental update succeeded > last update ended: 2016-12-16 20:25:40+00:00 > ----- > [root at ipa01 ~]# ipa-replica-manage list-ruv > Replica Update Vectors: > ipa01.passur.local:389: 4 > ipa02.passur.local:389: 6 > Certificate Server Replica Update Vectors: > ipa02.passur.local:389: 97 > ipa01.passur.local:389: 96 > ---------- > > > After the yum updates were applied to each system, I noticed that the > results of 'ipa-server-upgrade' were quite different. The 'ipa02' > system went through without errors (this was also the system I used to > reinitialize the other when I had a replication issue recently). > > > > On 'ipa01', I have following at the end of the 'ipaupgrade.log' file: > ---------- > 2016-12-14T18:09:26Z ERROR IPA server upgrade failed: Inspect > /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. > 2016-12-14T18:09: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/ipaserver/install/ipa_server_upgrade.py", > line 46, in run > server.upgrade() > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 1863, in upgrade > upgrade_configuration() > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 1785, in upgrade_configuration > ca_enable_ldap_profile_subsystem(ca) > File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > line 336, in ca_enable_ldap_profile_subsystem > cainstance.migrate_profiles_to_ldap() > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 1984, in migrate_profiles_to_ldap > _create_dogtag_profile(profile_id, profile_data, overwrite=False) > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 1990, in _create_dogtag_profile > with api.Backend.ra_certprofile as profile_api: > File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", > line 2060, in __enter__ > raise errors.RemoteRetrieveError(reason=_('Failed to authenticate > to CA REST API')) > > 2016-12-14T18:09:26Z DEBUG The ipa-server-upgrade command failed, > exception: RemoteRetrieveError: Failed to authenticate to CA REST API > 2016-12-14T18:09:26Z ERROR Unexpected error - see > /var/log/ipaupgrade.log for details: > RemoteRetrieveError: Failed to authenticate to CA REST API > 2016-12-14T18:09:26Z ERROR The ipa-server-upgrade command failed. See > /var/log/ipaupgrade.log for more information > ---------- > > > In addition, when I go to the IPA web interface on the 'ipa01' system, > I get the following when I try to view any of the certificates: > ---------- > IPA Error 4301: CertificateOperationError > > Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) > ---------- > > > I was wondering if there was a method for taking all the CA > details/tree/what have you from my 'ipa02' system and using it to > repopulate the 'ipa01'. Since everything else seems to be working > correctly after a reinitialize on 'ipa01', I thought this would be the > safest way, but I'm opening any solutions as I need to get this fixed > ASAP. > > Please let me know any additional details that may help OR if there is > a procedure that I could use to quickly and easily recreate 'ipa01' > WITH the certificate authority properly working on both. I may need > some educate there. > > > Thanks! > > -- Chris From rcritten at redhat.com Fri Dec 16 22:29:18 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Dec 2016 17:29:18 -0500 Subject: [Freeipa-users] Replica issue / Certificate Authority In-Reply-To: References: Message-ID: <58546ABE.30203@redhat.com> Christopher Young wrote: > Ok. I think I have a 'hint' here, but I could use some help getting this fixed. > > Comparing the two IPA servers, I found the following (modified SOME of > the output myself): You're right about the ipaCert. I'd export the renewed cert from your working server using the same certutil command, just direct it to a file instead. Then import it into the non-working server and restart the httpd service. That should do it. Or you can try restarting certmonger on the non-working server to see if that triggers it to pull in the updated cert. Theoretically this should do it as well but given potential past replication problems it is possible the entry doesn't exist. getcert list -n ipaCert on each will show some basic information. The important thing is to see if there is some root cause that will make this blow up again at renewal time. rob > > on 'ipa02' (the 'good' one): > ----- > ipa cert-show 1 > Issuing CA: ipa > Certificate: <<>> > Subject: CN=Certificate Authority,O=xxxx.LOCAL > Issuer: CN=Certificate Authority,O=xxxx.LOCAL > Not Before: Thu Jan 01 06:23:38 2015 UTC > Not After: Mon Jan 01 06:23:38 2035 UTC > Fingerprint (MD5): a6:aa:88:d4:66:e2:70:c1:e3:8c:37:0b:f3:eb:19:7d > Fingerprint (SHA1): > 11:c2:5a:58:bc:77:55:37:39:9b:13:b1:1a:a2:02:50:be:2e:a0:7f > Serial number: 1 > Serial number (hex): 0x1 > Revoked: False > ------ > > > on 'ipa01' > ----- > ipa cert-show 1 > ipa: ERROR: Certificate operation cannot be completed: EXCEPTION > (Invalid Credential.) > ----- > > Thinking about this, I decided to just start checking for > inconsistencies and I noticed the following: > > ipa02: > ----------- > [root at ipa02 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a | > openssl x509 -text | head > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 268304413 (0xffe001d) > Signature Algorithm: sha256WithRSAEncryption > Issuer: O=xxxxx.LOCAL, CN=Certificate Authority > Validity > Not Before: Nov 23 18:19:31 2016 GMT > Not After : Nov 13 18:19:31 2018 GMT > Subject: O=xxxxx.LOCAL, CN=IPA RA > > ---------- > ipa01: > ---------- > [root at ipa01 tmp]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a | > openssl x509 -text | head > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 7 (0x7) > Signature Algorithm: sha256WithRSAEncryption > Issuer: O=xxxx.LOCAL, CN=Certificate Authority > Validity > Not Before: Jan 1 06:24:23 2015 GMT > Not After : Dec 21 06:24:23 2016 GMT > Subject: O=xxxx.LOCAL, CN=IPA RA > > ---------- > > So, it looks like somewhere in the process, the certificate got > renewed but not updated on 'ipa01'? I apologize as I'm trying to > understand this. I believe that my end goal is probably still the > same (verify replication and get things working properly on the > 'ipa01' system. > > Any help is very much appreciated! > > -- Chris > > > On Fri, Dec 16, 2016 at 3:35 PM, Christopher Young > wrote: >> I'm hoping to provide enough information to get some help to a very >> important issue that I'm currently having. >> >> I have two IPA servers at a single location that recently had a >> replication issue that I eventually resolved by reinitializing one of >> the masters/replicas with one that seemed to be the most 'good'. >> >> In any case, somewhere in this process, the new IPA 4.4 was release >> with/for CentOS 7.3. >> >> At this moment, regular replication seems to be working properly (in >> that I don't have any obvious issues and web interfaces on both >> systems seem to be consistent for updates EXCEPT when it comes to the >> certificates). >> >> Before I get to the errors, here is the output of some of the commands >> that I would expect anyone would need: >> >> ---------- >> [root at ipa01 ~]# ipa-replica-manage list >> ipa01.passur.local: master >> ipa02.passur.local: master >> ----- >> [root at ipa01 ~]# ipa-replica-manage list -v ipa01.passur.local >> ipa02.passur.local: replica >> last init status: None >> last init ended: 1970-01-01 00:00:00+00:00 >> last update status: Error (0) Replica acquired successfully: >> Incremental update succeeded >> last update ended: 2016-12-16 20:25:40+00:00 >> ----- >> [root at ipa01 ~]# ipa-replica-manage list -v ipa02.passur.local >> ipa01.passur.local: replica >> last init status: None >> last init ended: 1970-01-01 00:00:00+00:00 >> last update status: Error (0) Replica acquired successfully: >> Incremental update succeeded >> last update ended: 2016-12-16 20:25:40+00:00 >> ----- >> [root at ipa01 ~]# ipa-replica-manage list-ruv >> Replica Update Vectors: >> ipa01.passur.local:389: 4 >> ipa02.passur.local:389: 6 >> Certificate Server Replica Update Vectors: >> ipa02.passur.local:389: 97 >> ipa01.passur.local:389: 96 >> ---------- >> >> >> After the yum updates were applied to each system, I noticed that the >> results of 'ipa-server-upgrade' were quite different. The 'ipa02' >> system went through without errors (this was also the system I used to >> reinitialize the other when I had a replication issue recently). >> >> >> >> On 'ipa01', I have following at the end of the 'ipaupgrade.log' file: >> ---------- >> 2016-12-14T18:09:26Z ERROR IPA server upgrade failed: Inspect >> /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. >> 2016-12-14T18:09: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/ipaserver/install/ipa_server_upgrade.py", >> line 46, in run >> server.upgrade() >> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >> line 1863, in upgrade >> upgrade_configuration() >> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >> line 1785, in upgrade_configuration >> ca_enable_ldap_profile_subsystem(ca) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", >> line 336, in ca_enable_ldap_profile_subsystem >> cainstance.migrate_profiles_to_ldap() >> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 1984, in migrate_profiles_to_ldap >> _create_dogtag_profile(profile_id, profile_data, overwrite=False) >> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 1990, in _create_dogtag_profile >> with api.Backend.ra_certprofile as profile_api: >> File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", >> line 2060, in __enter__ >> raise errors.RemoteRetrieveError(reason=_('Failed to authenticate >> to CA REST API')) >> >> 2016-12-14T18:09:26Z DEBUG The ipa-server-upgrade command failed, >> exception: RemoteRetrieveError: Failed to authenticate to CA REST API >> 2016-12-14T18:09:26Z ERROR Unexpected error - see >> /var/log/ipaupgrade.log for details: >> RemoteRetrieveError: Failed to authenticate to CA REST API >> 2016-12-14T18:09:26Z ERROR The ipa-server-upgrade command failed. See >> /var/log/ipaupgrade.log for more information >> ---------- >> >> >> In addition, when I go to the IPA web interface on the 'ipa01' system, >> I get the following when I try to view any of the certificates: >> ---------- >> IPA Error 4301: CertificateOperationError >> >> Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) >> ---------- >> >> >> I was wondering if there was a method for taking all the CA >> details/tree/what have you from my 'ipa02' system and using it to >> repopulate the 'ipa01'. Since everything else seems to be working >> correctly after a reinitialize on 'ipa01', I thought this would be the >> safest way, but I'm opening any solutions as I need to get this fixed >> ASAP. >> >> Please let me know any additional details that may help OR if there is >> a procedure that I could use to quickly and easily recreate 'ipa01' >> WITH the certificate authority properly working on both. I may need >> some educate there. >> >> >> Thanks! >> >> -- Chris > From brian at interlinx.bc.ca Sat Dec 17 03:53:07 2016 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Fri, 16 Dec 2016 22:53:07 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} Message-ID: <1481946787.11959.7.camel@interlinx.bc.ca> Hi, After upgrading to EL 7.3 which included an upgrade of IPA from 4.2.0- 15.0.1.el7.centos.19 to 4.4.0-14.el7.centos I'm getting: 22:01:00 ipa-dnskeysyncd ipa : INFO LDAP bind... 22:01:00 ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} 22:01:00 ipa-dnskeysyncd Traceback (most recent call last): 22:01:00 ipa-dnskeysyncd File "/usr/libexec/ipa/ipa-dnskeysyncd", line 90, in 22:01:00 ipa-dnskeysyncd ldap_connection.sasl_interactive_bind_s("", ipaldap.SASL_GSSAPI) 22:01:00 ipa-dnskeysyncd File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 850, in sasl_interactive_bind_s 22:01:00 ipa-dnskeysyncd res = self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_s,*args,**kwargs) 22:01:00 ipa-dnskeysyncd File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 818, in _apply_method_s 22:01:00 ipa-dnskeysyncd return func(self,*args,**kwargs) 22:01:00 ipa-dnskeysyncd File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 229, in sasl_interactive_bind_s 22:01:00 ipa-dnskeysyncd return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) 22:01:00 ipa-dnskeysyncd File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in _ldap_call 22:01:00 ipa-dnskeysyncd result = func(*args,**kwargs) 22:01:00 ipa-dnskeysyncd INVALID_CREDENTIALS: {'desc': 'Invalid credentials'} 22:01:01 systemd ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILURE 22:01:01 systemd Unit ipa-dnskeysyncd.service entered failed state. 22:01:01 systemd ipa-dnskeysyncd.service failed. But I also had to fall back to simple authentication of bind with arg "auth_method simple"; arg "bind_dn uid=admin,cn=users,cn=accounts,dc=example.com"; arg "password my_password"; in /etc/named.conf due to: 21:12:19 LDAP error: Invalid credentials: bind to LDAP server failed trying to start bind via systemctl start ipa. Seems like something's gotten fouled up during that upgrade. Any ideas? Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From brian at interlinx.bc.ca Sat Dec 17 18:30:21 2016 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Sat, 17 Dec 2016 13:30:21 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <1481946787.11959.7.camel@interlinx.bc.ca> References: <1481946787.11959.7.camel@interlinx.bc.ca> Message-ID: <1481999421.11959.23.camel@interlinx.bc.ca> On Fri, 2016-12-16 at 22:53 -0500, Brian J. Murrell wrote: > Hi, > > After upgrading to EL 7.3 which included an upgrade of IPA from > 4.2.0- > 15.0.1.el7.centos.19 to 4.4.0-14.el7.centos I'm getting:? > > 22:01:00 ipa-dnskeysyncd ipa?????????: INFO?????LDAP bind... > 22:01:00 ipa-dnskeysyncd ipa?????????: ERROR????Login to LDAP server I wonder if this is related: https://bugzilla.redhat.com/show_bug.cgi?id=1405716 SELinux is preventing /usr/bin/python2.7 from read access on the file unix. It has started to show up as of this IPA upgrade also. Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From jochen at jochen.org Sat Dec 17 21:45:52 2016 From: jochen at jochen.org (Jochen Hein) Date: Sat, 17 Dec 2016 22:45:52 +0100 Subject: [Freeipa-users] ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server Message-ID: <83shpm1b73.fsf@echidna.jochen.org> I'm running a privacyidea server, which has my tokens and provides external RADIUS access for other services like FreeIPA. When a user authenticates I have the following communications: 1. IPA Client -> IPA server (Kerberos) 2. IPA Server (kdc) -> ipa-otpd (internal radius) [*] 3. ipa-otpd -> FreeRADIUS for privacyidea 4. FreeRADIUS -> privacyidea (OTP-PIN/yubikey OTP) 5. privacyidea -> privacyidea (yubico validation server) [*] Here is where the trouble starts: Since we have a couple of TCP/IP sessions with SSL handshakes it takes a couple of seconds (mostly 6-8 seconds) to establish communication and get the answer from privacyidea back. man kdc.conf has: ,---- | [otp] | timeout An integer which specifies the time in seconds | during which the KDC should attempt to contact the | RADIUS server. This tag is the total time across | all retries and should be less than the time which | an OTP value remains valid for. The default is 5 | seconds. | | retries This tag specifies the number of retries to make to | the RADIUS server. The default is 3 retries (4 | tries). `---- So I've added the following to /var/kerberos/krb5kdc/kdc.conf and restarted kdc: ,---- | [otp] | DEFAULT = { | timeout = 15 | retries = 0 | strip_realm = false | } `---- After that I can use my OTP tokens without problems. With the default timeout of five seconds I had to have luck to get an authentication back. Would it be possible to raise the timeout to 10 seconds as a default? That sould work for me too. Is there a better way to add my configuration to kdc.conf, so it will survive upgrades? I didn't find any obvious place, nor some place where something for ipa-otp had been configured. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From bentech4you at gmail.com Sun Dec 18 09:04:57 2016 From: bentech4you at gmail.com (Ben .T.George) Date: Sun, 18 Dec 2016 12:04:57 +0300 Subject: [Freeipa-users] How to implement sudo rules Message-ID: Hi List, please help me to implement sudo rules. i have did below steps and still not working for me. 1. created "Sudo Command Groups" 2. Added some command (/bin/yum) and included in sudo group 3. created "sudo Rule" on that * added sudo Option as "!authenticate" * Added User Group. * Added one Host * And under Run command, selected the Sudo Rule Group. I tried logout and login again on client with IPA user which is member of user group. When i am running yum, getting error that user is not allowed to execute command. Please anyone help to correct my steps. Regards Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sun Dec 18 09:27:25 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 18 Dec 2016 11:27:25 +0200 Subject: [Freeipa-users] ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server In-Reply-To: <83shpm1b73.fsf@echidna.jochen.org> References: <83shpm1b73.fsf@echidna.jochen.org> Message-ID: <20161218092725.gmsznodxdrwhjgbt@redhat.com> On la, 17 joulu 2016, Jochen Hein wrote: > >I'm running a privacyidea server, which has my tokens and provides >external RADIUS access for other services like FreeIPA. When a user >authenticates I have the following communications: > >1. IPA Client -> IPA server (Kerberos) >2. IPA Server (kdc) -> ipa-otpd (internal radius) [*] >3. ipa-otpd -> FreeRADIUS for privacyidea >4. FreeRADIUS -> privacyidea (OTP-PIN/yubikey OTP) >5. privacyidea -> privacyidea (yubico validation server) > >[*] Here is where the trouble starts: Since we have a couple of TCP/IP >sessions with SSL handshakes it takes a couple of seconds (mostly 6-8 >seconds) to establish communication and get the answer from privacyidea >back. > >man kdc.conf has: >,---- >| [otp] >| timeout An integer which specifies the time in seconds >| during which the KDC should attempt to contact the >| RADIUS server. This tag is the total time across >| all retries and should be less than the time which >| an OTP value remains valid for. The default is 5 >| seconds. >| >| retries This tag specifies the number of retries to make to >| the RADIUS server. The default is 3 retries (4 >| tries). >`---- > >So I've added the following to /var/kerberos/krb5kdc/kdc.conf and restarted kdc: > >,---- >| [otp] >| DEFAULT = { >| timeout = 15 >| retries = 0 >| strip_realm = false >| } >`---- > >After that I can use my OTP tokens without problems. With the default >timeout of five seconds I had to have luck to get an authentication >back. Would it be possible to raise the timeout to 10 seconds as a >default? That sould work for me too. > >Is there a better way to add my configuration to kdc.conf, so it will >survive upgrades? I didn't find any obvious place, nor some place where >something for ipa-otp had been configured. You don't state which FreeIPA version you are using: distribution, package version, etc. There was a bug fixed in RHEL 7.3 / Fedora 25 about timeouts in OTP handling both in MIT Kerberos and FreeIPA's ipa-otpd daemon. -- / Alexander Bokovoy From jochen at jochen.org Sun Dec 18 10:25:55 2016 From: jochen at jochen.org (Jochen Hein) Date: Sun, 18 Dec 2016 11:25:55 +0100 Subject: [Freeipa-users] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server In-Reply-To: <20161218092725.gmsznodxdrwhjgbt@redhat.com> (Alexander Bokovoy's message of "Sun, 18 Dec 2016 11:27:25 +0200") References: <83shpm1b73.fsf@echidna.jochen.org> <20161218092725.gmsznodxdrwhjgbt@redhat.com> Message-ID: <83oa091qks.fsf@echidna.jochen.org> Alexander Bokovoy writes: >>So I've added the following to /var/kerberos/krb5kdc/kdc.conf and restarted kdc: >> >>,---- >>| [otp] >>| DEFAULT = { >>| timeout = 15 >>| retries = 0 >>| strip_realm = false >>| } >>`---- >> >>After that I can use my OTP tokens without problems. With the default >>timeout of five seconds I had to have luck to get an authentication >>back. Would it be possible to raise the timeout to 10 seconds as a >>default? That sould work for me too. >> >>Is there a better way to add my configuration to kdc.conf, so it will >>survive upgrades? I didn't find any obvious place, nor some place where >>something for ipa-otp had been configured. > You don't state which FreeIPA version you are using: distribution, > package version, etc. There was a bug fixed in RHEL 7.3 / Fedora 25 > about timeouts in OTP handling both in MIT Kerberos and FreeIPA's > ipa-otpd daemon. I'm running my old master on Fedora 24 (freeipa-server-4.3.2-2.fc24.x86_64) and the new on CentOS 7.3 (ipa-server-4.4.0-14.el7.centos.x86_64). I've seen the bugs and checked in CentOS git that the fix is in the package. And beside the timeout it now seems to work. We have two timeouts to consider: 1. KDC to ipa-otd: this can be changed in /var/kerberos/krb5kdc/kdc.conf. I think the timeout should be larger then the (largest) second timeout - and I think retries=0 is best. This is for communication between KDC and ipa-otd. 2. There is a timeout in each RADIUS server config in IPA for the communication from ipa-otp to external RADIUS servers: ,---- | [root at freeipa krb5kdc]# ipa radiusproxy-find | ----------------------------- | 1 RADIUS proxy server matched | ----------------------------- | RADIUS proxy server name: athene | Server: athene.jochen.org | Timeout: 10 | Retries: 0 | User attribute: User-Name | ------------------------------------- | Anzahl der zur?ckgegebenen Eintr?ge 1 | ------------------------------------- `---- Again I think that for OTPs we are probably best with retries=0. On older clients it might be helpful to add "udp_preference_limit = 0" to /etc/krb5.conf - at least on my Debian/Ubuntu machines. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From abokovoy at redhat.com Sun Dec 18 10:33:32 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 18 Dec 2016 12:33:32 +0200 Subject: [Freeipa-users] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server In-Reply-To: <83oa091qks.fsf@echidna.jochen.org> References: <83shpm1b73.fsf@echidna.jochen.org> <20161218092725.gmsznodxdrwhjgbt@redhat.com> <83oa091qks.fsf@echidna.jochen.org> Message-ID: <20161218103332.ipv3v7u3rarduyyu@redhat.com> On su, 18 joulu 2016, Jochen Hein wrote: >Alexander Bokovoy writes: > >>>So I've added the following to /var/kerberos/krb5kdc/kdc.conf and restarted kdc: >>> >>>,---- >>>| [otp] >>>| DEFAULT = { >>>| timeout = 15 >>>| retries = 0 >>>| strip_realm = false >>>| } >>>`---- >>> >>>After that I can use my OTP tokens without problems. With the default >>>timeout of five seconds I had to have luck to get an authentication >>>back. Would it be possible to raise the timeout to 10 seconds as a >>>default? That sould work for me too. >>> >>>Is there a better way to add my configuration to kdc.conf, so it will >>>survive upgrades? I didn't find any obvious place, nor some place where >>>something for ipa-otp had been configured. > >> You don't state which FreeIPA version you are using: distribution, >> package version, etc. There was a bug fixed in RHEL 7.3 / Fedora 25 >> about timeouts in OTP handling both in MIT Kerberos and FreeIPA's >> ipa-otpd daemon. > >I'm running my old master on Fedora 24 >(freeipa-server-4.3.2-2.fc24.x86_64) and the new on CentOS 7.3 >(ipa-server-4.4.0-14.el7.centos.x86_64). I've seen the bugs and checked >in CentOS git that the fix is in the package. And beside the timeout it >now seems to work. > >We have two timeouts to consider: > >1. KDC to ipa-otd: this can be changed in >/var/kerberos/krb5kdc/kdc.conf. I think the timeout should be larger >then the (largest) second timeout - and I think retries=0 is best. >This is for communication between KDC and ipa-otd. > >2. There is a timeout in each RADIUS server config in IPA for the >communication from ipa-otp to external RADIUS servers: >,---- >| [root at freeipa krb5kdc]# ipa radiusproxy-find >| ----------------------------- >| 1 RADIUS proxy server matched >| ----------------------------- >| RADIUS proxy server name: athene >| Server: athene.jochen.org >| Timeout: 10 >| Retries: 0 >| User attribute: User-Name >| ------------------------------------- >| Anzahl der zur?ckgegebenen Eintr?ge 1 >| ------------------------------------- >`---- >Again I think that for OTPs we are probably best with retries=0. > >On older clients it might be helpful to add "udp_preference_limit = 0" >to /etc/krb5.conf - at least on my Debian/Ubuntu machines. Ok. It would probably make sense to file a ticket to FreeIPA tracker to get these changes in FreeIPA 4.5. -- / Alexander Bokovoy From jhrozek at redhat.com Sun Dec 18 21:10:42 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 18 Dec 2016 22:10:42 +0100 Subject: [Freeipa-users] How to implement sudo rules In-Reply-To: References: Message-ID: I hope this helps pinpoint the issue: https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO > On 18 Dec 2016, at 10:04, Ben .T.George wrote: > > Hi List, > > please help me to implement sudo rules. > > i have did below steps and still not working for me. > > 1. created "Sudo Command Groups" > 2. Added some command (/bin/yum) and included in sudo group > 3. created "sudo Rule" on that > * added sudo Option as "!authenticate" > * Added User Group. > * Added one Host > * And under Run command, selected the Sudo Rule Group. > > I tried logout and login again on client with IPA user which is member of user group. > > When i am running yum, getting error that user is not allowed to execute command. > > > Please anyone help to correct my steps. > > Regards > Ben > -- > Manage your subscription for 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 ftweedal at redhat.com Sun Dec 18 23:10:57 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 19 Dec 2016 09:10:57 +1000 Subject: [Freeipa-users] Replica issue / Certificate Authority In-Reply-To: <58546ABE.30203@redhat.com> References: <58546ABE.30203@redhat.com> Message-ID: <20161218231057.GD4232@dhcp-40-8.bne.redhat.com> On Fri, Dec 16, 2016 at 05:29:18PM -0500, Rob Crittenden wrote: > Christopher Young wrote: > > Ok. I think I have a 'hint' here, but I could use some help getting this fixed. > > > > Comparing the two IPA servers, I found the following (modified SOME of > > the output myself): > > You're right about the ipaCert. I'd export the renewed cert from your > working server using the same certutil command, just direct it to a file > instead. Then import it into the non-working server and restart the > httpd service. That should do it. > I agree that this should fix it. You could also try running `ipa-certupdate' as root, if the correct certificate is to be found in cn=certificates,cn=ipa,cn=etc,{basedn} Once everything is working again, you should check: 1. renewal master configuration is correct 2. certmonger tracking requests for the IPA RA cert are correct on both servers 3. the correct certificate is in cn=certificates,cn=ipa,cn=etc,{basedn} Thanks, Fraser > Or you can try restarting certmonger on the non-working server to see if > > that triggers it to pull in the updated cert. Theoretically this should > do it as well but given potential past replication problems it is > possible the entry doesn't exist. > > getcert list -n ipaCert on each will show some basic information. The > important thing is to see if there is some root cause that will make > this blow up again at renewal time. > > rob > > > > > on 'ipa02' (the 'good' one): > > ----- > > ipa cert-show 1 > > Issuing CA: ipa > > Certificate: <<>> > > Subject: CN=Certificate Authority,O=xxxx.LOCAL > > Issuer: CN=Certificate Authority,O=xxxx.LOCAL > > Not Before: Thu Jan 01 06:23:38 2015 UTC > > Not After: Mon Jan 01 06:23:38 2035 UTC > > Fingerprint (MD5): a6:aa:88:d4:66:e2:70:c1:e3:8c:37:0b:f3:eb:19:7d > > Fingerprint (SHA1): > > 11:c2:5a:58:bc:77:55:37:39:9b:13:b1:1a:a2:02:50:be:2e:a0:7f > > Serial number: 1 > > Serial number (hex): 0x1 > > Revoked: False > > ------ > > > > > > on 'ipa01' > > ----- > > ipa cert-show 1 > > ipa: ERROR: Certificate operation cannot be completed: EXCEPTION > > (Invalid Credential.) > > ----- > > > > Thinking about this, I decided to just start checking for > > inconsistencies and I noticed the following: > > > > ipa02: > > ----------- > > [root at ipa02 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a | > > openssl x509 -text | head > > Certificate: > > Data: > > Version: 3 (0x2) > > Serial Number: 268304413 (0xffe001d) > > Signature Algorithm: sha256WithRSAEncryption > > Issuer: O=xxxxx.LOCAL, CN=Certificate Authority > > Validity > > Not Before: Nov 23 18:19:31 2016 GMT > > Not After : Nov 13 18:19:31 2018 GMT > > Subject: O=xxxxx.LOCAL, CN=IPA RA > > > > ---------- > > ipa01: > > ---------- > > [root at ipa01 tmp]# certutil -L -d /etc/httpd/alias/ -n ipaCert -a | > > openssl x509 -text | head > > Certificate: > > Data: > > Version: 3 (0x2) > > Serial Number: 7 (0x7) > > Signature Algorithm: sha256WithRSAEncryption > > Issuer: O=xxxx.LOCAL, CN=Certificate Authority > > Validity > > Not Before: Jan 1 06:24:23 2015 GMT > > Not After : Dec 21 06:24:23 2016 GMT > > Subject: O=xxxx.LOCAL, CN=IPA RA > > > > ---------- > > > > So, it looks like somewhere in the process, the certificate got > > renewed but not updated on 'ipa01'? I apologize as I'm trying to > > understand this. I believe that my end goal is probably still the > > same (verify replication and get things working properly on the > > 'ipa01' system. > > > > Any help is very much appreciated! > > > > -- Chris > > > > > > On Fri, Dec 16, 2016 at 3:35 PM, Christopher Young > > wrote: > >> I'm hoping to provide enough information to get some help to a very > >> important issue that I'm currently having. > >> > >> I have two IPA servers at a single location that recently had a > >> replication issue that I eventually resolved by reinitializing one of > >> the masters/replicas with one that seemed to be the most 'good'. > >> > >> In any case, somewhere in this process, the new IPA 4.4 was release > >> with/for CentOS 7.3. > >> > >> At this moment, regular replication seems to be working properly (in > >> that I don't have any obvious issues and web interfaces on both > >> systems seem to be consistent for updates EXCEPT when it comes to the > >> certificates). > >> > >> Before I get to the errors, here is the output of some of the commands > >> that I would expect anyone would need: > >> > >> ---------- > >> [root at ipa01 ~]# ipa-replica-manage list > >> ipa01.passur.local: master > >> ipa02.passur.local: master > >> ----- > >> [root at ipa01 ~]# ipa-replica-manage list -v ipa01.passur.local > >> ipa02.passur.local: replica > >> last init status: None > >> last init ended: 1970-01-01 00:00:00+00:00 > >> last update status: Error (0) Replica acquired successfully: > >> Incremental update succeeded > >> last update ended: 2016-12-16 20:25:40+00:00 > >> ----- > >> [root at ipa01 ~]# ipa-replica-manage list -v ipa02.passur.local > >> ipa01.passur.local: replica > >> last init status: None > >> last init ended: 1970-01-01 00:00:00+00:00 > >> last update status: Error (0) Replica acquired successfully: > >> Incremental update succeeded > >> last update ended: 2016-12-16 20:25:40+00:00 > >> ----- > >> [root at ipa01 ~]# ipa-replica-manage list-ruv > >> Replica Update Vectors: > >> ipa01.passur.local:389: 4 > >> ipa02.passur.local:389: 6 > >> Certificate Server Replica Update Vectors: > >> ipa02.passur.local:389: 97 > >> ipa01.passur.local:389: 96 > >> ---------- > >> > >> > >> After the yum updates were applied to each system, I noticed that the > >> results of 'ipa-server-upgrade' were quite different. The 'ipa02' > >> system went through without errors (this was also the system I used to > >> reinitialize the other when I had a replication issue recently). > >> > >> > >> > >> On 'ipa01', I have following at the end of the 'ipaupgrade.log' file: > >> ---------- > >> 2016-12-14T18:09:26Z ERROR IPA server upgrade failed: Inspect > >> /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. > >> 2016-12-14T18:09: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/ipaserver/install/ipa_server_upgrade.py", > >> line 46, in run > >> server.upgrade() > >> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > >> line 1863, in upgrade > >> upgrade_configuration() > >> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > >> line 1785, in upgrade_configuration > >> ca_enable_ldap_profile_subsystem(ca) > >> File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", > >> line 336, in ca_enable_ldap_profile_subsystem > >> cainstance.migrate_profiles_to_ldap() > >> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > >> line 1984, in migrate_profiles_to_ldap > >> _create_dogtag_profile(profile_id, profile_data, overwrite=False) > >> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > >> line 1990, in _create_dogtag_profile > >> with api.Backend.ra_certprofile as profile_api: > >> File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", > >> line 2060, in __enter__ > >> raise errors.RemoteRetrieveError(reason=_('Failed to authenticate > >> to CA REST API')) > >> > >> 2016-12-14T18:09:26Z DEBUG The ipa-server-upgrade command failed, > >> exception: RemoteRetrieveError: Failed to authenticate to CA REST API > >> 2016-12-14T18:09:26Z ERROR Unexpected error - see > >> /var/log/ipaupgrade.log for details: > >> RemoteRetrieveError: Failed to authenticate to CA REST API > >> 2016-12-14T18:09:26Z ERROR The ipa-server-upgrade command failed. See > >> /var/log/ipaupgrade.log for more information > >> ---------- > >> > >> > >> In addition, when I go to the IPA web interface on the 'ipa01' system, > >> I get the following when I try to view any of the certificates: > >> ---------- > >> IPA Error 4301: CertificateOperationError > >> > >> Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) > >> ---------- > >> > >> > >> I was wondering if there was a method for taking all the CA > >> details/tree/what have you from my 'ipa02' system and using it to > >> repopulate the 'ipa01'. Since everything else seems to be working > >> correctly after a reinitialize on 'ipa01', I thought this would be the > >> safest way, but I'm opening any solutions as I need to get this fixed > >> ASAP. > >> > >> Please let me know any additional details that may help OR if there is > >> a procedure that I could use to quickly and easily recreate 'ipa01' > >> WITH the certificate authority properly working on both. I may need > >> some educate there. > >> > >> > >> Thanks! > >> > >> -- 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 mbasti at redhat.com Mon Dec 19 08:42:03 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Dec 2016 09:42:03 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <1481999421.11959.23.camel@interlinx.bc.ca> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> Message-ID: <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> On 17.12.2016 19:30, Brian J. Murrell wrote: > On Fri, 2016-12-16 at 22:53 -0500, Brian J. Murrell wrote: >> Hi, >> >> After upgrading to EL 7.3 which included an upgrade of IPA from >> 4.2.0- >> 15.0.1.el7.centos.19 to 4.4.0-14.el7.centos I'm getting: >> >> 22:01:00 ipa-dnskeysyncd ipa : INFO LDAP bind... >> 22:01:00 ipa-dnskeysyncd ipa : ERROR Login to LDAP server > I wonder if this is related: > > https://bugzilla.redhat.com/show_bug.cgi?id=1405716 > SELinux is preventing /usr/bin/python2.7 from read access on the file > unix. > > It has started to show up as of this IPA upgrade also. > > Cheers, > b. > > Hello, could you recheck with SElinux in permissive mode? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at interlinx.bc.ca Mon Dec 19 12:19:25 2016 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Mon, 19 Dec 2016 07:19:25 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> Message-ID: <1482149965.28211.15.camel@interlinx.bc.ca> On Mon, 2016-12-19 at 09:42 +0100, Martin Basti wrote: > > Hello, > > could you recheck with SElinux in permissive mode? Yeah, still happens even after doing: # setenforce 0 Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From cmcnamara at sshchicago.org Fri Dec 16 19:58:46 2016 From: cmcnamara at sshchicago.org (Christian McNamara) Date: Fri, 16 Dec 2016 13:58:46 -0600 Subject: [Freeipa-users] Replica Creation Issue In-Reply-To: <37a09b19-58a5-1598-10cc-ded3bd51fab8@redhat.com> References: <37a09b19-58a5-1598-10cc-ded3bd51fab8@redhat.com> Message-ID: It seems like it is indeed not running. ipactl restart is only starting one dirsrv. I recently learned this server is itself a replica of an earlier server. Is it possible it was never meant to be a CA? -- Christian McNamara Christian McNamara Chief Technology Officer South Side Hackerspace: Chicago On Thu, Dec 15, 2016 at 6:21 AM, Petr Vobornik wrote: > On 12/14/2016 03:27 PM, Christian McNamara wrote: > > Hi all, > > > > I recently inherited a FreeIPA system that I believe is running v3.0, > and I'm > > trying to upgrade to the latest version. Following documentation, I'm > trying to > > create a replica but I'm running into problems connecting to the LDAP > server. > > Here's the output I get when trying to prepare a replica: > > > > $ sudo ipa-replica-prepare auth4.sshchicago.org > > --ip-address 172.31.31.36 > > Directory Manager (existing master) password: > > > > Preparing replica for auth4.sshchicago.org < > http://auth4.sshchicago.org> > > from auth3.sshchicago.org > > preparation of replica failed: cannot connect to > > u'ldaps://auth3.sshchicago.org : > > > > > 7390': > > LDAP Server Down > > cannot connect to u'ldaps://auth3.sshchicago.org:7390 > > ': LDAP Server Down > > File "/usr/sbin/ipa-replica-prepare", line 529, in > > main() > > > > File "/usr/sbin/ipa-replica-prepare", line 391, in main > > update_pki_admin_password(dirman_password) > > > > File "/usr/sbin/ipa-replica-prepare", line 247, in > update_pki_admin_password > > bind_pw=dirman_password > > > > File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line > 63, in > > connect > > conn = self.create_connection(*args, **kw) > > > > File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", > line > > 846, > > > > in create_connection > > self.handle_errors(e) > > > > File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", > line > > 736, > > > > in handle_errors > > error=u'LDAP Server Down') > > > > > > It says that our LDAP server is down, but it's trying to connect using > the wrong > > port number. Our LDAP server runs on 389, not 7390, and I can't figure > out how > > to specify this to the prepare script. > > > > Any ideas? > > > > IPA 3.0 has 2 instances of directory server. One for domain data second > for PKI CA data. IPA 4.x instances have them merged. > > So port 7390 is ldaps for of PKI-IPA DS instance, e.g. equivalent for > 636 port of domain DS instance. Similar mapping is with 7389 and 389 > ports. > > Therefore I'd check if PKI-IPA is running or if it is listening there. > > Relevant logs are in: > /var/log/dirsrv/slapd-PKI-IPA/errors > > Example of `ipactl restart`: > > Shutting down dirsrv: > DOM-189-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM... [ OK ] > PKI-IPA... [ OK ] > Starting dirsrv: > DOM-189-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM... [ OK ] > PKI-IPA... [ OK ] > Restarting KDC Service > Stopping Kerberos 5 KDC: [ OK ] > Starting Kerberos 5 KDC: [ OK ] > Restarting KPASSWD Service > Stopping Kerberos 5 Admin Server: [ OK ] > Starting Kerberos 5 Admin Server: [ OK ] > Restarting DNS Service > Stopping named: . [ OK ] > Starting named: [ OK ] > Restarting MEMCACHE Service > Stopping ipa_memcached: [ OK ] > Starting ipa_memcached: [ OK ] > Restarting HTTP Service > Stopping httpd: [ OK ] > Starting httpd: [ OK ] > Restarting CA Service [ OK ] > Starting pki-ca: [ OK ] > > -- > Petr Vobornik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Mon Dec 19 13:07:15 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 19 Dec 2016 14:07:15 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd not starting Message-ID: Hello, I'm running ipa on centos 7.3 with the latest patches applied. It seem to run fine however the ipa-dnskeysyncd keeps failing to start and I keep seeing this message in my logs: ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind... python2[25663]: GSSAPI client step 1 python2[25663]: GSSAPI client step 1 ns-slapd[2569]: GSSAPI server step 1 python2[25663]: GSSAPI client step 1 ns-slapd[2569]: GSSAPI server step 2 python2[25663]: GSSAPI client step 2 ns-slapd[2569]: GSSAPI server step 3 ipa-dnskeysyncd[25663]: ipa : INFO Commencing sync process ipa-dnskeysyncd[25663]: ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BIND python2[25674]: GSSAPI client step 1 python2[25674]: GSSAPI client step 1 ns-slapd[2569]: GSSAPI server step 1 python2[25674]: GSSAPI client step 1 ns-slapd[2569]: GSSAPI server step 2 python2[25674]: GSSAPI client step 2 ns-slapd[2569]: GSSAPI server step 3 ipa-dnskeysyncd[25663]: Traceback (most recent call last): ipa-dnskeysyncd[25663]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 110, in ipa-dnskeysyncd[25663]: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search): ipa-dnskeysyncd[25663]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_poll ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone() ipa-dnskeysyncd[25663]: File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 115, in syncrepl_refreshdone ipa-dnskeysyncd[25663]: self.hsm_replica_sync() ipa-dnskeysyncd[25663]: File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 181, in hsm_replica_sync ipa-dnskeysyncd[25663]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) ipa-dnskeysyncd[25663]: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, in run ipa-dnskeysyncd[25663]: raise CalledProcessError(p.returncode, arg_string, str(output)) ipa-dnskeysyncd[25663]: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1 systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILURE systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. systemd[1]: ipa-dnskeysyncd.service failed. for some reason the ipa-dnskeysyncd keeops crashing. Anybody know where to start looking for this one ? Rob Verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Dec 19 14:50:21 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 19 Dec 2016 15:50:21 +0100 Subject: [Freeipa-users] Kerberos realm for different domain In-Reply-To: References: <65e8d18c-7c5f-4f82-57cb-8aa6069db84c@redhat.com> Message-ID: <8379103e-999d-6fbf-de70-12d0df27fac4@redhat.com> On 15.12.2016 23:59, Brian Candler wrote: >> On Sun, Dec 11, 2016 at 11:31 PM, David Kupka > > wrote: >> >> >> yes you can do it. DNS domain and Kerberos realm are two different >> things. It's common and AFAIK recommended to capitalize DNS domain >> to get the realm but it's not required. >> If you really want to have them different make sure: >> a) anotherdomain.com is under your >> control, >> b) you don't already have other Kerberos instance (FreeIPA, MIT >> KRB5, MS AD, ...) with ANOTHERDOMAIN.COM >> realm deployed. >> >> With FreeIPA you can run >> # ipa-server-install --domain example.com >> --realm ANOTHERDOMAIN.COM >> >> >> But before you do, why do you want to have the realm different >> from the domain? >> >> > > Question: what "domain" does the --domain option to ipa-server-install > actually refer to? > > The man page just says " Your DNS domain name". But what does it actually alter? > > 1. the DNS domain which holds the kerberos realm location information? I don't > think so; I think if you are searching for realm FOO.COM you'll always look in > the DNS under "foo.com", that's a fixed relationship. > > 2. the DNS name of the IPA server itself? But if set up correctly, it already > has an FQDN (as reported by "hostname -f"). And if you give the "--hostname" > option, that's a FQDN not a bare hostname. > > 3. the DNS zone which IPA is authoritative for? But you can run IPA without > integrated DNS. > > 4. the LDAP base DN? I guess that could be it: e.g. "--domain foo.com" puts > everything under tree "dc=foo,dc=com"? > > 5. something else? I've tried to clarify things in man pages and on web as well. Please have a look to changes and let us know if it is better or not, and preferably what can be improved and in which way :-) The modified deployment page is here: http://www.freeipa.org/page/Deployment_Recommendations Man page changes and changes in description of installer options are here: https://github.com/freeipa/freeipa/pull/352 -- Petr^2 Spacek From pspacek at redhat.com Mon Dec 19 14:52:14 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 19 Dec 2016 15:52:14 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd not starting In-Reply-To: References: Message-ID: On 19.12.2016 14:07, Rob Verduijn wrote: > Hello, > > I'm running ipa on centos 7.3 with the latest patches applied. > > It seem to run fine however the ipa-dnskeysyncd keeps failing to start and > I keep seeing this message in my logs: > > ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind... > python2[25663]: GSSAPI client step 1 > python2[25663]: GSSAPI client step 1 > ns-slapd[2569]: GSSAPI server step 1 > python2[25663]: GSSAPI client step 1 > ns-slapd[2569]: GSSAPI server step 2 > python2[25663]: GSSAPI client step 2 > ns-slapd[2569]: GSSAPI server step 3 > ipa-dnskeysyncd[25663]: ipa : INFO Commencing sync process > ipa-dnskeysyncd[25663]: ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO > Initial LDAP dump is done, sychronizing with ODS and BIND > python2[25674]: GSSAPI client step 1 > python2[25674]: GSSAPI client step 1 > ns-slapd[2569]: GSSAPI server step 1 > python2[25674]: GSSAPI client step 1 > ns-slapd[2569]: GSSAPI server step 2 > python2[25674]: GSSAPI client step 2 > ns-slapd[2569]: GSSAPI server step 3 > ipa-dnskeysyncd[25663]: Traceback (most recent call last): > ipa-dnskeysyncd[25663]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 110, > in > ipa-dnskeysyncd[25663]: while ldap_connection.syncrepl_poll(all=1, > msgid=ldap_search): > ipa-dnskeysyncd[25663]: File > "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in > syncrepl_poll > ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone() > ipa-dnskeysyncd[25663]: File > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 115, > in syncrepl_refreshdone > ipa-dnskeysyncd[25663]: self.hsm_replica_sync() > ipa-dnskeysyncd[25663]: File > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 181, > in hsm_replica_sync > ipa-dnskeysyncd[25663]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) > ipa-dnskeysyncd[25663]: File > "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, in run > ipa-dnskeysyncd[25663]: raise CalledProcessError(p.returncode, arg_string, > str(output)) > ipa-dnskeysyncd[25663]: subprocess.CalledProcessError: Command > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1 > systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, > status=1/FAILURE > systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. > systemd[1]: ipa-dnskeysyncd.service failed. > > for some reason the ipa-dnskeysyncd keeops crashing. > Anybody know where to start looking for this one ? Please raise the debug level so we can see something in the logs: http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_returns_no_data -- Petr^2 Spacek From rob.verduijn at gmail.com Mon Dec 19 15:07:45 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 19 Dec 2016 16:07:45 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd not starting In-Reply-To: References: Message-ID: 2016-12-19 15:52 GMT+01:00 Petr Spacek : > On 19.12.2016 14:07, Rob Verduijn wrote: > > Hello, > > > > I'm running ipa on centos 7.3 with the latest patches applied. > > > > It seem to run fine however the ipa-dnskeysyncd keeps failing to start > and > > I keep seeing this message in my logs: > > > > ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind... > > python2[25663]: GSSAPI client step 1 > > python2[25663]: GSSAPI client step 1 > > ns-slapd[2569]: GSSAPI server step 1 > > python2[25663]: GSSAPI client step 1 > > ns-slapd[2569]: GSSAPI server step 2 > > python2[25663]: GSSAPI client step 2 > > ns-slapd[2569]: GSSAPI server step 3 > > ipa-dnskeysyncd[25663]: ipa : INFO Commencing sync process > > ipa-dnskeysyncd[25663]: ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO > > Initial LDAP dump is done, sychronizing with ODS and BIND > > python2[25674]: GSSAPI client step 1 > > python2[25674]: GSSAPI client step 1 > > ns-slapd[2569]: GSSAPI server step 1 > > python2[25674]: GSSAPI client step 1 > > ns-slapd[2569]: GSSAPI server step 2 > > python2[25674]: GSSAPI client step 2 > > ns-slapd[2569]: GSSAPI server step 3 > > ipa-dnskeysyncd[25663]: Traceback (most recent call last): > > ipa-dnskeysyncd[25663]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line > 110, > > in > > ipa-dnskeysyncd[25663]: while ldap_connection.syncrepl_poll(all=1, > > msgid=ldap_search): > > ipa-dnskeysyncd[25663]: File > > "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in > > syncrepl_poll > > ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone() > > ipa-dnskeysyncd[25663]: File > > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line > 115, > > in syncrepl_refreshdone > > ipa-dnskeysyncd[25663]: self.hsm_replica_sync() > > ipa-dnskeysyncd[25663]: File > > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line > 181, > > in hsm_replica_sync > > ipa-dnskeysyncd[25663]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) > > ipa-dnskeysyncd[25663]: File > > "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, in > run > > ipa-dnskeysyncd[25663]: raise CalledProcessError(p.returncode, > arg_string, > > str(output)) > > ipa-dnskeysyncd[25663]: subprocess.CalledProcessError: Command > > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status > 1 > > systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, > > status=1/FAILURE > > systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. > > systemd[1]: ipa-dnskeysyncd.service failed. > > > > for some reason the ipa-dnskeysyncd keeops crashing. > > Anybody know where to start looking for this one ? > > Please raise the debug level so we can see something in the logs: > > http://www.freeipa.org/page/Troubleshooting#ipa_command_ > crashes_or_returns_no_data > > -- > 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 > Hello, The file /etc/ipa/ipa.conf or the file /etc/ipa/server.conf do not exist on my system. How to set debugging in this case ? Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Mon Dec 19 15:27:57 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 19 Dec 2016 16:27:57 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd not starting In-Reply-To: References: Message-ID: 2016-12-19 16:07 GMT+01:00 Rob Verduijn : > > > > 2016-12-19 15:52 GMT+01:00 Petr Spacek : > >> On 19.12.2016 14:07, Rob Verduijn wrote: >> > Hello, >> > >> > I'm running ipa on centos 7.3 with the latest patches applied. >> > >> > It seem to run fine however the ipa-dnskeysyncd keeps failing to start >> and >> > I keep seeing this message in my logs: >> > >> > ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind... >> > python2[25663]: GSSAPI client step 1 >> > python2[25663]: GSSAPI client step 1 >> > ns-slapd[2569]: GSSAPI server step 1 >> > python2[25663]: GSSAPI client step 1 >> > ns-slapd[2569]: GSSAPI server step 2 >> > python2[25663]: GSSAPI client step 2 >> > ns-slapd[2569]: GSSAPI server step 3 >> > ipa-dnskeysyncd[25663]: ipa : INFO Commencing sync process >> > ipa-dnskeysyncd[25663]: ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO >> > Initial LDAP dump is done, sychronizing with ODS and BIND >> > python2[25674]: GSSAPI client step 1 >> > python2[25674]: GSSAPI client step 1 >> > ns-slapd[2569]: GSSAPI server step 1 >> > python2[25674]: GSSAPI client step 1 >> > ns-slapd[2569]: GSSAPI server step 2 >> > python2[25674]: GSSAPI client step 2 >> > ns-slapd[2569]: GSSAPI server step 3 >> > ipa-dnskeysyncd[25663]: Traceback (most recent call last): >> > ipa-dnskeysyncd[25663]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line >> 110, >> > in >> > ipa-dnskeysyncd[25663]: while ldap_connection.syncrepl_poll(all=1, >> > msgid=ldap_search): >> > ipa-dnskeysyncd[25663]: File >> > "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in >> > syncrepl_poll >> > ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone() >> > ipa-dnskeysyncd[25663]: File >> > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line >> 115, >> > in syncrepl_refreshdone >> > ipa-dnskeysyncd[25663]: self.hsm_replica_sync() >> > ipa-dnskeysyncd[25663]: File >> > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line >> 181, >> > in hsm_replica_sync >> > ipa-dnskeysyncd[25663]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) >> > ipa-dnskeysyncd[25663]: File >> > "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, in >> run >> > ipa-dnskeysyncd[25663]: raise CalledProcessError(p.returncode, >> arg_string, >> > str(output)) >> > ipa-dnskeysyncd[25663]: subprocess.CalledProcessError: Command >> > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit >> status 1 >> > systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, >> > status=1/FAILURE >> > systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. >> > systemd[1]: ipa-dnskeysyncd.service failed. >> > >> > for some reason the ipa-dnskeysyncd keeops crashing. >> > Anybody know where to start looking for this one ? >> >> Please raise the debug level so we can see something in the logs: >> >> http://www.freeipa.org/page/Troubleshooting#ipa_command_cras >> hes_or_returns_no_data >> >> -- >> 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 >> > > Hello, > > The file /etc/ipa/ipa.conf or the file /etc/ipa/server.conf do not exist > on my system. > How to set debugging in this case ? > > Rob > I've set the debug level in /etc/ipa/default.conf now I get this output systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILURE systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. systemd[1]: ipa-dnskeysyncd.service failed. systemd[1]: ipa-dnskeysyncd.service holdoff time over, scheduling restart. systemd[1]: Started IPA key daemon. systemd[1]: Starting IPA key daemon... ipa-dnskeysyncd[30568]: ipa : INFO LDAP bind... python2[30568]: GSSAPI client step 1 python2[30568]: GSSAPI client step 1 ns-slapd[26744]: GSSAPI server step 1 python2[30568]: GSSAPI client step 1 ns-slapd[26744]: GSSAPI server step 2 python2[30568]: GSSAPI client step 2 ns-slapd[26744]: GSSAPI server step 3 ipa-dnskeysyncd[30568]: ipa : INFO Commencing sync process ipa-dnskeysyncd[30568]: ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP dump is done, sychronizing with ODS and BIND python2[30579]: GSSAPI client step 1 python2[30579]: GSSAPI client step 1 ns-slapd[26744]: GSSAPI server step 1 python2[30579]: GSSAPI client step 1 ns-slapd[26744]: GSSAPI server step 2 python2[30579]: GSSAPI client step 2 ns-slapd[26744]: GSSAPI server step 3 python2[30579]: ObjectStore.cpp(59): Failed to enumerate object store in /var/lib/softhsm/tokens/ python2[30579]: SoftHSM.cpp(476): Could not load the object store ipa-dnskeysyncd[30568]: Traceback (most recent call last): ipa-dnskeysyncd[30568]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 110, in ipa-dnskeysyncd[30568]: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search): ipa-dnskeysyncd[30568]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_poll ipa-dnskeysyncd[30568]: self.syncrepl_refreshdone() ipa-dnskeysyncd[30568]: File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 115, in syncrepl_refreshdone ipa-dnskeysyncd[30568]: self.hsm_replica_sync() ipa-dnskeysyncd[30568]: File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 181, in hsm_replica_sync ipa-dnskeysyncd[30568]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) ipa-dnskeysyncd[30568]: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, in run ipa-dnskeysyncd[30568]: raise CalledProcessError(p.returncode, arg_string, str(output)) ipa-dnskeysyncd[30568]: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Dec 19 16:06:18 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Dec 2016 17:06:18 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd not starting In-Reply-To: References: Message-ID: On 19.12.2016 16:27, Rob Verduijn wrote: > > > 2016-12-19 16:07 GMT+01:00 Rob Verduijn >: > > > > > 2016-12-19 15:52 GMT+01:00 Petr Spacek >: > > On 19.12.2016 14:07, Rob Verduijn wrote: > > Hello, > > > > I'm running ipa on centos 7.3 with the latest patches applied. > > > > It seem to run fine however the ipa-dnskeysyncd keeps > failing to start and > > I keep seeing this message in my logs: > > > > ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind... > > python2[25663]: GSSAPI client step 1 > > python2[25663]: GSSAPI client step 1 > > ns-slapd[2569]: GSSAPI server step 1 > > python2[25663]: GSSAPI client step 1 > > ns-slapd[2569]: GSSAPI server step 2 > > python2[25663]: GSSAPI client step 2 > > ns-slapd[2569]: GSSAPI server step 3 > > ipa-dnskeysyncd[25663]: ipa : INFO Commencing > sync process > > ipa-dnskeysyncd[25663]: > ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO > > Initial LDAP dump is done, sychronizing with ODS and BIND > > python2[25674]: GSSAPI client step 1 > > python2[25674]: GSSAPI client step 1 > > ns-slapd[2569]: GSSAPI server step 1 > > python2[25674]: GSSAPI client step 1 > > ns-slapd[2569]: GSSAPI server step 2 > > python2[25674]: GSSAPI client step 2 > > ns-slapd[2569]: GSSAPI server step 3 > > ipa-dnskeysyncd[25663]: Traceback (most recent call last): > > ipa-dnskeysyncd[25663]: File > "/usr/libexec/ipa/ipa-dnskeysyncd", line 110, > > in > > ipa-dnskeysyncd[25663]: while > ldap_connection.syncrepl_poll(all=1, > > msgid=ldap_search): > > ipa-dnskeysyncd[25663]: File > > "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line > 405, in > > syncrepl_poll > > ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone() > > ipa-dnskeysyncd[25663]: File > > > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", > line 115, > > in syncrepl_refreshdone > > ipa-dnskeysyncd[25663]: self.hsm_replica_sync() > > ipa-dnskeysyncd[25663]: File > > > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", > line 181, > > in hsm_replica_sync > > ipa-dnskeysyncd[25663]: > ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) > > ipa-dnskeysyncd[25663]: File > > "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", > line 494, in run > > ipa-dnskeysyncd[25663]: raise > CalledProcessError(p.returncode, arg_string, > > str(output)) > > ipa-dnskeysyncd[25663]: subprocess.CalledProcessError: Command > > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero > exit status 1 > > systemd[1]: ipa-dnskeysyncd.service: main process exited, > code=exited, > > status=1/FAILURE > > systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. > > systemd[1]: ipa-dnskeysyncd.service failed. > > > > for some reason the ipa-dnskeysyncd keeops crashing. > > Anybody know where to start looking for this one ? > > Please raise the debug level so we can see something in the logs: > > http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_returns_no_data > > > -- > 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 > > > Hello, > > The file /etc/ipa/ipa.conf or the file /etc/ipa/server.conf do not > exist on my system. > How to set debugging in this case ? > > Rob > > > I've set the debug level in /etc/ipa/default.conf > > now I get this output > systemd[1]: ipa-dnskeysyncd.service: main process exited, > code=exited, status=1/FAILURE > systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. > systemd[1]: ipa-dnskeysyncd.service failed. > systemd[1]: ipa-dnskeysyncd.service holdoff time over, scheduling > restart. > systemd[1]: Started IPA key daemon. > systemd[1]: Starting IPA key daemon... > ipa-dnskeysyncd[30568]: ipa : INFO LDAP bind... > python2[30568]: GSSAPI client step 1 > python2[30568]: GSSAPI client step 1 > ns-slapd[26744]: GSSAPI server step 1 > python2[30568]: GSSAPI client step 1 > ns-slapd[26744]: GSSAPI server step 2 > python2[30568]: GSSAPI client step 2 > ns-slapd[26744]: GSSAPI server step 3 > ipa-dnskeysyncd[30568]: ipa : INFO Commencing sync process > ipa-dnskeysyncd[30568]: ipa.ipapython.dnssec.keysyncer.KeySyncer: > INFO Initial LDAP dump is done, sychronizing with ODS and BIND > python2[30579]: GSSAPI client step 1 > python2[30579]: GSSAPI client step 1 > ns-slapd[26744]: GSSAPI server step 1 > python2[30579]: GSSAPI client step 1 > ns-slapd[26744]: GSSAPI server step 2 > python2[30579]: GSSAPI client step 2 > ns-slapd[26744]: GSSAPI server step 3 > python2[30579]: ObjectStore.cpp(59): Failed to enumerate object store > in /var/lib/softhsm/tokens/ > python2[30579]: SoftHSM.cpp(476): Could not load the object store > ipa-dnskeysyncd[30568]: Traceback (most recent call last): > ipa-dnskeysyncd[30568]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line > 110, in > ipa-dnskeysyncd[30568]: while ldap_connection.syncrepl_poll(all=1, > msgid=ldap_search): > ipa-dnskeysyncd[30568]: File > "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in > syncrepl_poll > ipa-dnskeysyncd[30568]: self.syncrepl_refreshdone() > ipa-dnskeysyncd[30568]: File > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line > 115, in syncrepl_refreshdone > ipa-dnskeysyncd[30568]: self.hsm_replica_sync() > ipa-dnskeysyncd[30568]: File > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line > 181, in hsm_replica_sync > ipa-dnskeysyncd[30568]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) > ipa-dnskeysyncd[30568]: File > "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, in run > ipa-dnskeysyncd[30568]: raise CalledProcessError(p.returncode, > arg_string, str(output)) > ipa-dnskeysyncd[30568]: subprocess.CalledProcessError: Command > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status > > > Hello, do you have selinux in enforcing mode? Any AVCs ? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Dec 19 16:26:12 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Dec 2016 17:26:12 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <1482149965.28211.15.camel@interlinx.bc.ca> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> Message-ID: On 19.12.2016 13:19, Brian J. Murrell wrote: > On Mon, 2016-12-19 at 09:42 +0100, Martin Basti wrote: >> Hello, >> >> could you recheck with SElinux in permissive mode? > Yeah, still happens even after doing: > > # setenforce 0 > > Cheers, > b. could you please kinit as service? kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa-dnskeysyncd/$(hostname) Martin From rob.verduijn at gmail.com Mon Dec 19 16:51:39 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 19 Dec 2016 17:51:39 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd not starting In-Reply-To: References: Message-ID: 2016-12-19 17:06 GMT+01:00 Martin Basti : > > > On 19.12.2016 16:27, Rob Verduijn wrote: > > > > 2016-12-19 16:07 GMT+01:00 Rob Verduijn : > >> >> >> >> 2016-12-19 15:52 GMT+01:00 Petr Spacek : >> >>> On 19.12.2016 14:07, Rob Verduijn wrote: >>> > Hello, >>> > >>> > I'm running ipa on centos 7.3 with the latest patches applied. >>> > >>> > It seem to run fine however the ipa-dnskeysyncd keeps failing to start >>> and >>> > I keep seeing this message in my logs: >>> > >>> > ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind... >>> > python2[25663]: GSSAPI client step 1 >>> > python2[25663]: GSSAPI client step 1 >>> > ns-slapd[2569]: GSSAPI server step 1 >>> > python2[25663]: GSSAPI client step 1 >>> > ns-slapd[2569]: GSSAPI server step 2 >>> > python2[25663]: GSSAPI client step 2 >>> > ns-slapd[2569]: GSSAPI server step 3 >>> > ipa-dnskeysyncd[25663]: ipa : INFO Commencing sync process >>> > ipa-dnskeysyncd[25663]: ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO >>> > Initial LDAP dump is done, sychronizing with ODS and BIND >>> > python2[25674]: GSSAPI client step 1 >>> > python2[25674]: GSSAPI client step 1 >>> > ns-slapd[2569]: GSSAPI server step 1 >>> > python2[25674]: GSSAPI client step 1 >>> > ns-slapd[2569]: GSSAPI server step 2 >>> > python2[25674]: GSSAPI client step 2 >>> > ns-slapd[2569]: GSSAPI server step 3 >>> > ipa-dnskeysyncd[25663]: Traceback (most recent call last): >>> > ipa-dnskeysyncd[25663]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line >>> 110, >>> > in >>> > ipa-dnskeysyncd[25663]: while ldap_connection.syncrepl_poll(all=1, >>> > msgid=ldap_search): >>> > ipa-dnskeysyncd[25663]: File >>> > "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in >>> > syncrepl_poll >>> > ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone() >>> > ipa-dnskeysyncd[25663]: File >>> > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", >>> line 115, >>> > in syncrepl_refreshdone >>> > ipa-dnskeysyncd[25663]: self.hsm_replica_sync() >>> > ipa-dnskeysyncd[25663]: File >>> > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", >>> line 181, >>> > in hsm_replica_sync >>> > ipa-dnskeysyncd[25663]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) >>> > ipa-dnskeysyncd[25663]: File >>> > "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, in >>> run >>> > ipa-dnskeysyncd[25663]: raise CalledProcessError(p.returncode, >>> arg_string, >>> > str(output)) >>> > ipa-dnskeysyncd[25663]: subprocess.CalledProcessError: Command >>> > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit >>> status 1 >>> > systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, >>> > status=1/FAILURE >>> > systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. >>> > systemd[1]: ipa-dnskeysyncd.service failed. >>> > >>> > for some reason the ipa-dnskeysyncd keeops crashing. >>> > Anybody know where to start looking for this one ? >>> >>> Please raise the debug level so we can see something in the logs: >>> >>> http://www.freeipa.org/page/Troubleshooting#ipa_command_cras >>> hes_or_returns_no_data >>> >>> -- >>> 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 >>> >> >> Hello, >> >> The file /etc/ipa/ipa.conf or the file /etc/ipa/server.conf do not exist >> on my system. >> How to set debugging in this case ? >> >> Rob >> > > I've set the debug level in /etc/ipa/default.conf > > now I get this output > systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, > status=1/FAILURE > systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. > systemd[1]: ipa-dnskeysyncd.service failed. > systemd[1]: ipa-dnskeysyncd.service holdoff time over, scheduling restart. > systemd[1]: Started IPA key daemon. > systemd[1]: Starting IPA key daemon... > ipa-dnskeysyncd[30568]: ipa : INFO LDAP bind... > python2[30568]: GSSAPI client step 1 > python2[30568]: GSSAPI client step 1 > ns-slapd[26744]: GSSAPI server step 1 > python2[30568]: GSSAPI client step 1 > ns-slapd[26744]: GSSAPI server step 2 > python2[30568]: GSSAPI client step 2 > ns-slapd[26744]: GSSAPI server step 3 > ipa-dnskeysyncd[30568]: ipa : INFO Commencing sync process > ipa-dnskeysyncd[30568]: ipa.ipapython.dnssec.keysyncer.KeySyncer: > INFO Initial LDAP dump is done, sychronizing with ODS and BIND > python2[30579]: GSSAPI client step 1 > python2[30579]: GSSAPI client step 1 > ns-slapd[26744]: GSSAPI server step 1 > python2[30579]: GSSAPI client step 1 > ns-slapd[26744]: GSSAPI server step 2 > python2[30579]: GSSAPI client step 2 > ns-slapd[26744]: GSSAPI server step 3 > python2[30579]: ObjectStore.cpp(59): Failed to enumerate object store in > /var/lib/softhsm/tokens/ > python2[30579]: SoftHSM.cpp(476): Could not load the object store > ipa-dnskeysyncd[30568]: Traceback (most recent call last): > ipa-dnskeysyncd[30568]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line > 110, in > ipa-dnskeysyncd[30568]: while ldap_connection.syncrepl_poll(all=1, > msgid=ldap_search): > ipa-dnskeysyncd[30568]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", > line 405, in syncrepl_poll > ipa-dnskeysyncd[30568]: self.syncrepl_refreshdone() > ipa-dnskeysyncd[30568]: File "/usr/lib/python2.7/site- > packages/ipapython/dnssec/keysyncer.py", line 115, in syncrepl_refreshdone > ipa-dnskeysyncd[30568]: self.hsm_replica_sync() > ipa-dnskeysyncd[30568]: File "/usr/lib/python2.7/site- > packages/ipapython/dnssec/keysyncer.py", line 181, in hsm_replica_sync > ipa-dnskeysyncd[30568]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) > ipa-dnskeysyncd[30568]: File "/usr/lib/python2.7/site- > packages/ipapython/ipautil.py", line 494, in run > ipa-dnskeysyncd[30568]: raise CalledProcessError(p.returncode, > arg_string, str(output)) > ipa-dnskeysyncd[30568]: subprocess.CalledProcessError: Command > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status > > > > > Hello, do you have selinux in enforcing mode? Any AVCs ? > > Martin > yes but ipa-dnskeysyncd still fails to start when selinux is in permissive mode I did : ipactl stop setenforce 0 service auditd rotate ipactl start and see one avc denied type=AVC msg=audit(1482164681.053:5195): avc: denied { read } for pid=1993 comm="ipa-dnskeysync-" name="tokens" dev="dm-7" ino=16818968 scontext=system_u:system_r:ipa_dnskey_t:s0 tcontext=system_u:object_r:named_cache_t:s0 tclass=dir I gues that is one little bit of selinux that needs adjustment, however there is still no running ipa-dnskeysyncd. I found that this error appears before the previous one. ipa-dnskeysyncd[1981]: ipa: DEBUG: ipaserver.plugins.virtual is not a valid plugin module ipa-dnskeysyncd[1981]: ipa: DEBUG: importing plugin module ipaserver.plugins.xmlserver ipa-dnskeysyncd[1981]: ipa : DEBUG Kerberos principal: ipa-dnskeysyncd/freeipa01.tjako.thuis ipa-dnskeysyncd[1981]: ipa : DEBUG Initializing principal ipa-dnskeysyncd/freeipa01.tjako.thuis using keytab /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa-dnskeysyncd[1981]: ipa : DEBUG using ccache /tmp/ipa-dnskeysync-replica.ccache ipa-dnskeysyncd[1981]: ipa : DEBUG Attempt 1/5: success ipa-dnskeysyncd[1981]: ipa : DEBUG Got TGT ipa-dnskeysyncd[1981]: ipa : DEBUG Connecting to LDAP ipa-dnskeysyncd[1981]: ipa : DEBUG Connected ipa-dnskeysyncd[1981]: Traceback (most recent call last): ipa-dnskeysyncd[1981]: File "/usr/libexec/ipa/ipa-dnskeysync-replica", line 159, in ipa-dnskeysyncd[1981]: open(paths.DNSSEC_SOFTHSM_PIN).read()) ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site-packages/ipapython/dnssec/localhsm.py", line 95, in __init__ ipa-dnskeysyncd[1981]: self.p11 = _ipap11helper.P11_Helper(slot, pin, library) ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site-packages/ipapython/p11helper.py", line 837, in __init__ ipa-dnskeysyncd[1981]: check_return_value(rv, "open session") ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site-packages/ipapython/p11helper.py", line 576, in check_return_value ipa-dnskeysyncd[1981]: raise Error(errmsg) ipa-dnskeysyncd[1981]: ipapython.p11helper.Error: Error at open session: 0xe1 ipa-dnskeysyncd[1981]: Exception AttributeError: "'LocalHSM' object has no attribute 'p11'" in > ignored ipa-dnskeysyncd[1981]: Traceback (most recent call last): ipa-dnskeysyncd[1981]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 110, in ipa-dnskeysyncd[1981]: while ldap_connection.syncrepl_poll(all=1, msgid=ldap_search): ipa-dnskeysyncd[1981]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in syncrepl_poll ipa-dnskeysyncd[1981]: self.syncrepl_refreshdone() ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 115, in syncrepl_refreshdone ipa-dnskeysyncd[1981]: self.hsm_replica_sync() ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line 181, in hsm_replica_sync ipa-dnskeysyncd[1981]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, in run ipa-dnskeysyncd[1981]: raise CalledProcessError(p.returncode, arg_string, str(output)) ipa-dnskeysyncd[1981]: subprocess.CalledProcessError: Command '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1 systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, status=1/FAILURE systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. systemd[1]: ipa-dnskeysyncd.service failed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Mon Dec 19 17:53:47 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 19 Dec 2016 18:53:47 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd not starting In-Reply-To: References: Message-ID: On 19.12.2016 17:51, Rob Verduijn wrote: > 2016-12-19 17:06 GMT+01:00 Martin Basti >: > > > > On 19.12.2016 16:27, Rob Verduijn wrote: >> >> >> 2016-12-19 16:07 GMT+01:00 Rob Verduijn > >: >> >> >> >> >> 2016-12-19 15:52 GMT+01:00 Petr Spacek > >: >> >> On 19.12.2016 14:07, Rob Verduijn wrote: >> > Hello, >> > >> > I'm running ipa on centos 7.3 with the latest patches >> applied. >> > >> > It seem to run fine however the ipa-dnskeysyncd keeps >> failing to start and >> > I keep seeing this message in my logs: >> > >> > ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind... >> > python2[25663]: GSSAPI client step 1 >> > python2[25663]: GSSAPI client step 1 >> > ns-slapd[2569]: GSSAPI server step 1 >> > python2[25663]: GSSAPI client step 1 >> > ns-slapd[2569]: GSSAPI server step 2 >> > python2[25663]: GSSAPI client step 2 >> > ns-slapd[2569]: GSSAPI server step 3 >> > ipa-dnskeysyncd[25663]: ipa : INFO Commencing >> sync process >> > ipa-dnskeysyncd[25663]: >> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO >> > Initial LDAP dump is done, sychronizing with ODS and BIND >> > python2[25674]: GSSAPI client step 1 >> > python2[25674]: GSSAPI client step 1 >> > ns-slapd[2569]: GSSAPI server step 1 >> > python2[25674]: GSSAPI client step 1 >> > ns-slapd[2569]: GSSAPI server step 2 >> > python2[25674]: GSSAPI client step 2 >> > ns-slapd[2569]: GSSAPI server step 3 >> > ipa-dnskeysyncd[25663]: Traceback (most recent call last): >> > ipa-dnskeysyncd[25663]: File >> "/usr/libexec/ipa/ipa-dnskeysyncd", line 110, >> > in >> > ipa-dnskeysyncd[25663]: while >> ldap_connection.syncrepl_poll(all=1, >> > msgid=ldap_search): >> > ipa-dnskeysyncd[25663]: File >> > "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", >> line 405, in >> > syncrepl_poll >> > ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone() >> > ipa-dnskeysyncd[25663]: File >> > >> "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", >> line 115, >> > in syncrepl_refreshdone >> > ipa-dnskeysyncd[25663]: self.hsm_replica_sync() >> > ipa-dnskeysyncd[25663]: File >> > >> "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", >> line 181, >> > in hsm_replica_sync >> > ipa-dnskeysyncd[25663]: >> ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) >> > ipa-dnskeysyncd[25663]: File >> > >> "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", >> line 494, in run >> > ipa-dnskeysyncd[25663]: raise >> CalledProcessError(p.returncode, arg_string, >> > str(output)) >> > ipa-dnskeysyncd[25663]: subprocess.CalledProcessError: >> Command >> > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned >> non-zero exit status 1 >> > systemd[1]: ipa-dnskeysyncd.service: main process >> exited, code=exited, >> > status=1/FAILURE >> > systemd[1]: Unit ipa-dnskeysyncd.service entered failed >> state. >> > systemd[1]: ipa-dnskeysyncd.service failed. >> > >> > for some reason the ipa-dnskeysyncd keeops crashing. >> > Anybody know where to start looking for this one ? >> >> Please raise the debug level so we can see something in >> the logs: >> >> http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_returns_no_data >> >> >> -- >> 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 >> >> >> Hello, >> >> The file /etc/ipa/ipa.conf or the file /etc/ipa/server.conf >> do not exist on my system. >> How to set debugging in this case ? >> >> Rob >> >> >> I've set the debug level in /etc/ipa/default.conf >> >> now I get this output >> systemd[1]: ipa-dnskeysyncd.service: main process exited, >> code=exited, status=1/FAILURE >> systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. >> systemd[1]: ipa-dnskeysyncd.service failed. >> systemd[1]: ipa-dnskeysyncd.service holdoff time over, >> scheduling restart. >> systemd[1]: Started IPA key daemon. >> systemd[1]: Starting IPA key daemon... >> ipa-dnskeysyncd[30568]: ipa : INFO LDAP bind... >> python2[30568]: GSSAPI client step 1 >> python2[30568]: GSSAPI client step 1 >> ns-slapd[26744]: GSSAPI server step 1 >> python2[30568]: GSSAPI client step 1 >> ns-slapd[26744]: GSSAPI server step 2 >> python2[30568]: GSSAPI client step 2 >> ns-slapd[26744]: GSSAPI server step 3 >> ipa-dnskeysyncd[30568]: ipa : INFO Commencing sync process >> ipa-dnskeysyncd[30568]: >> ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO Initial LDAP >> dump is done, sychronizing with ODS and BIND >> python2[30579]: GSSAPI client step 1 >> python2[30579]: GSSAPI client step 1 >> ns-slapd[26744]: GSSAPI server step 1 >> python2[30579]: GSSAPI client step 1 >> ns-slapd[26744]: GSSAPI server step 2 >> python2[30579]: GSSAPI client step 2 >> ns-slapd[26744]: GSSAPI server step 3 >> python2[30579]: ObjectStore.cpp(59): Failed to enumerate object >> store in /var/lib/softhsm/tokens/ >> python2[30579]: SoftHSM.cpp(476): Could not load the object store >> ipa-dnskeysyncd[30568]: Traceback (most recent call last): >> ipa-dnskeysyncd[30568]: File "/usr/libexec/ipa/ipa-dnskeysyncd", >> line 110, in >> ipa-dnskeysyncd[30568]: while >> ldap_connection.syncrepl_poll(all=1, msgid=ldap_search): >> ipa-dnskeysyncd[30568]: File >> "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, >> in syncrepl_poll >> ipa-dnskeysyncd[30568]: self.syncrepl_refreshdone() >> ipa-dnskeysyncd[30568]: File >> "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", >> line 115, in syncrepl_refreshdone >> ipa-dnskeysyncd[30568]: self.hsm_replica_sync() >> ipa-dnskeysyncd[30568]: File >> "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", >> line 181, in hsm_replica_sync >> ipa-dnskeysyncd[30568]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) >> ipa-dnskeysyncd[30568]: File >> "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >> 494, in run >> ipa-dnskeysyncd[30568]: raise CalledProcessError(p.returncode, >> arg_string, str(output)) >> ipa-dnskeysyncd[30568]: subprocess.CalledProcessError: Command >> '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit >> status >> >> >> > > Hello, do you have selinux in enforcing mode? Any AVCs ? > > Martin > > > > yes > > but ipa-dnskeysyncd still fails to start when selinux is in permissive > mode > > I did : > ipactl stop > setenforce 0 > service auditd rotate > ipactl start > > and see one avc denied > type=AVC msg=audit(1482164681.053:5195): avc: denied { read } for > pid=1993 comm="ipa-dnskeysync-" name="tokens" dev="dm-7" ino=16818968 > scontext=system_u:system_r:ipa_dnskey_t:s0 > tcontext=system_u:object_r:named_cache_t:s0 tclass=dir > > I gues that is one little bit of selinux that needs adjustment, > > however there is still no running ipa-dnskeysyncd. > > I found that this error appears before the previous one. > > ipa-dnskeysyncd[1981]: ipa: DEBUG: ipaserver.plugins.virtual is not a > valid plugin module > ipa-dnskeysyncd[1981]: ipa: DEBUG: importing plugin module > ipaserver.plugins.xmlserver > ipa-dnskeysyncd[1981]: ipa : DEBUG Kerberos principal: > ipa-dnskeysyncd/freeipa01.tjako.thuis > ipa-dnskeysyncd[1981]: ipa : DEBUG Initializing principal > ipa-dnskeysyncd/freeipa01.tjako.thuis using keytab > /etc/ipa/dnssec/ipa-dnskeysyncd.keytab > ipa-dnskeysyncd[1981]: ipa : DEBUG using ccache > /tmp/ipa-dnskeysync-replica.ccache > ipa-dnskeysyncd[1981]: ipa : DEBUG Attempt 1/5: success > ipa-dnskeysyncd[1981]: ipa : DEBUG Got TGT > ipa-dnskeysyncd[1981]: ipa : DEBUG Connecting to LDAP > ipa-dnskeysyncd[1981]: ipa : DEBUG Connected > ipa-dnskeysyncd[1981]: Traceback (most recent call last): > ipa-dnskeysyncd[1981]: File "/usr/libexec/ipa/ipa-dnskeysync-replica", > line 159, in > ipa-dnskeysyncd[1981]: open(paths.DNSSEC_SOFTHSM_PIN).read()) > ipa-dnskeysyncd[1981]: File > "/usr/lib/python2.7/site-packages/ipapython/dnssec/localhsm.py", line > 95, in __init__ > ipa-dnskeysyncd[1981]: self.p11 = _ipap11helper.P11_Helper(slot, pin, > library) > ipa-dnskeysyncd[1981]: File > "/usr/lib/python2.7/site-packages/ipapython/p11helper.py", line 837, > in __init__ > ipa-dnskeysyncd[1981]: check_return_value(rv, "open session") > ipa-dnskeysyncd[1981]: File > "/usr/lib/python2.7/site-packages/ipapython/p11helper.py", line 576, > in check_return_value > ipa-dnskeysyncd[1981]: raise Error(errmsg) > ipa-dnskeysyncd[1981]: ipapython.p11helper.Error: Error at open > session: 0xe1 > ipa-dnskeysyncd[1981]: Exception AttributeError: "'LocalHSM' object > has no attribute 'p11'" in > ignored > ipa-dnskeysyncd[1981]: Traceback (most recent call last): > ipa-dnskeysyncd[1981]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line > 110, in > ipa-dnskeysyncd[1981]: while ldap_connection.syncrepl_poll(all=1, > msgid=ldap_search): > ipa-dnskeysyncd[1981]: File > "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in > syncrepl_poll > ipa-dnskeysyncd[1981]: self.syncrepl_refreshdone() > ipa-dnskeysyncd[1981]: File > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line > 115, in syncrepl_refreshdone > ipa-dnskeysyncd[1981]: self.hsm_replica_sync() > ipa-dnskeysyncd[1981]: File > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", line > 181, in hsm_replica_sync > ipa-dnskeysyncd[1981]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) > ipa-dnskeysyncd[1981]: File > "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, in run > ipa-dnskeysyncd[1981]: raise CalledProcessError(p.returncode, > arg_string, str(output)) > ipa-dnskeysyncd[1981]: subprocess.CalledProcessError: Command > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1 > systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, > status=1/FAILURE > systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. > systemd[1]: ipa-dnskeysyncd.service failed. > > Selinux caused that key has not been created in HSM database, you have to temporarily set selinux to permisive, and run ipa-dns-install again to fix it. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen at jochen.org Mon Dec 19 18:22:19 2016 From: jochen at jochen.org (Jochen Hein) Date: Mon, 19 Dec 2016 19:22:19 +0100 Subject: [Freeipa-users] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server In-Reply-To: <20161218103332.ipv3v7u3rarduyyu@redhat.com> (Alexander Bokovoy's message of "Sun, 18 Dec 2016 12:33:32 +0200") References: <83shpm1b73.fsf@echidna.jochen.org> <20161218092725.gmsznodxdrwhjgbt@redhat.com> <83oa091qks.fsf@echidna.jochen.org> <20161218103332.ipv3v7u3rarduyyu@redhat.com> Message-ID: <834m1z22zo.fsf@echidna.jochen.org> Alexander Bokovoy writes: > On su, 18 joulu 2016, Jochen Hein wrote: > Ok. It would probably make sense to file a ticket to FreeIPA tracker to > get these changes in FreeIPA 4.5. I'm now fighting against my privacyidea server, but if I can test something more and am sure about the needed changes I'll file a ticket. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From brian at interlinx.bc.ca Mon Dec 19 20:24:45 2016 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Mon, 19 Dec 2016 15:24:45 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> Message-ID: <1482179085.28211.36.camel@interlinx.bc.ca> On Mon, 2016-12-19 at 17:26 +0100, Martin Basti wrote: > > On 19.12.2016 13:19, Brian J. Murrell wrote: > > On Mon, 2016-12-19 at 09:42 +0100, Martin Basti wrote: > > > Hello, > > > > > > could you recheck with SElinux in permissive mode? > > > > Yeah, still happens even after doing: > > > > # setenforce 0 > > > > Cheers, > > b. > > could you please kinit as service? > > > kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa- > dnskeysyncd/$(hostname) # kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa-dnskeysyncd/server.example.com # klist Ticket cache: KEYRING:persistent:0:0 Default principal: ipa-dnskeysyncd/server.example.com at EXAMPLE.COM Valid starting Expires Service principal 19/12/16 15:20:20 20/12/16 15:20:20 krbtgt/EXAMPLE.COM at EXAMPLE.COM Seems to have worked. FWIW, I was not asked for any password. Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From rob.verduijn at gmail.com Mon Dec 19 21:03:13 2016 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Mon, 19 Dec 2016 22:03:13 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd not starting In-Reply-To: References: Message-ID: 2016-12-19 18:53 GMT+01:00 Martin Basti : > > > On 19.12.2016 17:51, Rob Verduijn wrote: > > 2016-12-19 17:06 GMT+01:00 Martin Basti : > >> >> >> On 19.12.2016 16:27, Rob Verduijn wrote: >> >> >> >> 2016-12-19 16:07 GMT+01:00 Rob Verduijn : >> >>> >>> >>> >>> 2016-12-19 15:52 GMT+01:00 Petr Spacek : >>> >>>> On 19.12.2016 14:07, Rob Verduijn wrote: >>>> > Hello, >>>> > >>>> > I'm running ipa on centos 7.3 with the latest patches applied. >>>> > >>>> > It seem to run fine however the ipa-dnskeysyncd keeps failing to >>>> start and >>>> > I keep seeing this message in my logs: >>>> > >>>> > ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind... >>>> > python2[25663]: GSSAPI client step 1 >>>> > python2[25663]: GSSAPI client step 1 >>>> > ns-slapd[2569]: GSSAPI server step 1 >>>> > python2[25663]: GSSAPI client step 1 >>>> > ns-slapd[2569]: GSSAPI server step 2 >>>> > python2[25663]: GSSAPI client step 2 >>>> > ns-slapd[2569]: GSSAPI server step 3 >>>> > ipa-dnskeysyncd[25663]: ipa : INFO Commencing sync process >>>> > ipa-dnskeysyncd[25663]: ipa.ipapython.dnssec.keysyncer.KeySyncer: >>>> INFO >>>> > Initial LDAP dump is done, sychronizing with ODS and BIND >>>> > python2[25674]: GSSAPI client step 1 >>>> > python2[25674]: GSSAPI client step 1 >>>> > ns-slapd[2569]: GSSAPI server step 1 >>>> > python2[25674]: GSSAPI client step 1 >>>> > ns-slapd[2569]: GSSAPI server step 2 >>>> > python2[25674]: GSSAPI client step 2 >>>> > ns-slapd[2569]: GSSAPI server step 3 >>>> > ipa-dnskeysyncd[25663]: Traceback (most recent call last): >>>> > ipa-dnskeysyncd[25663]: File "/usr/libexec/ipa/ipa-dnskeysyncd", >>>> line 110, >>>> > in >>>> > ipa-dnskeysyncd[25663]: while ldap_connection.syncrepl_poll(all=1, >>>> > msgid=ldap_search): >>>> > ipa-dnskeysyncd[25663]: File >>>> > "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line 405, in >>>> > syncrepl_poll >>>> > ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone() >>>> > ipa-dnskeysyncd[25663]: File >>>> > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", >>>> line 115, >>>> > in syncrepl_refreshdone >>>> > ipa-dnskeysyncd[25663]: self.hsm_replica_sync() >>>> > ipa-dnskeysyncd[25663]: File >>>> > "/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py", >>>> line 181, >>>> > in hsm_replica_sync >>>> > ipa-dnskeysyncd[25663]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) >>>> > ipa-dnskeysyncd[25663]: File >>>> > "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 494, >>>> in run >>>> > ipa-dnskeysyncd[25663]: raise CalledProcessError(p.returncode, >>>> arg_string, >>>> > str(output)) >>>> > ipa-dnskeysyncd[25663]: subprocess.CalledProcessError: Command >>>> > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit >>>> status 1 >>>> > systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, >>>> > status=1/FAILURE >>>> > systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. >>>> > systemd[1]: ipa-dnskeysyncd.service failed. >>>> > >>>> > for some reason the ipa-dnskeysyncd keeops crashing. >>>> > Anybody know where to start looking for this one ? >>>> >>>> Please raise the debug level so we can see something in the logs: >>>> >>>> http://www.freeipa.org/page/Troubleshooting#ipa_command_cras >>>> hes_or_returns_no_data >>>> >>>> -- >>>> 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 >>>> >>> >>> Hello, >>> >>> The file /etc/ipa/ipa.conf or the file /etc/ipa/server.conf do not exist >>> on my system. >>> How to set debugging in this case ? >>> >>> Rob >>> >> >> I've set the debug level in /etc/ipa/default.conf >> >> now I get this output >> systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, >> status=1/FAILURE >> systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. >> systemd[1]: ipa-dnskeysyncd.service failed. >> systemd[1]: ipa-dnskeysyncd.service holdoff time over, scheduling >> restart. >> systemd[1]: Started IPA key daemon. >> systemd[1]: Starting IPA key daemon... >> ipa-dnskeysyncd[30568]: ipa : INFO LDAP bind... >> python2[30568]: GSSAPI client step 1 >> python2[30568]: GSSAPI client step 1 >> ns-slapd[26744]: GSSAPI server step 1 >> python2[30568]: GSSAPI client step 1 >> ns-slapd[26744]: GSSAPI server step 2 >> python2[30568]: GSSAPI client step 2 >> ns-slapd[26744]: GSSAPI server step 3 >> ipa-dnskeysyncd[30568]: ipa : INFO Commencing sync process >> ipa-dnskeysyncd[30568]: ipa.ipapython.dnssec.keysyncer.KeySyncer: >> INFO Initial LDAP dump is done, sychronizing with ODS and BIND >> python2[30579]: GSSAPI client step 1 >> python2[30579]: GSSAPI client step 1 >> ns-slapd[26744]: GSSAPI server step 1 >> python2[30579]: GSSAPI client step 1 >> ns-slapd[26744]: GSSAPI server step 2 >> python2[30579]: GSSAPI client step 2 >> ns-slapd[26744]: GSSAPI server step 3 >> python2[30579]: ObjectStore.cpp(59): Failed to enumerate object store in >> /var/lib/softhsm/tokens/ >> python2[30579]: SoftHSM.cpp(476): Could not load the object store >> ipa-dnskeysyncd[30568]: Traceback (most recent call last): >> ipa-dnskeysyncd[30568]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line >> 110, in >> ipa-dnskeysyncd[30568]: while ldap_connection.syncrepl_poll(all=1, >> msgid=ldap_search): >> ipa-dnskeysyncd[30568]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", >> line 405, in syncrepl_poll >> ipa-dnskeysyncd[30568]: self.syncrepl_refreshdone() >> ipa-dnskeysyncd[30568]: File "/usr/lib/python2.7/site-packa >> ges/ipapython/dnssec/keysyncer.py", line 115, in syncrepl_refreshdone >> ipa-dnskeysyncd[30568]: self.hsm_replica_sync() >> ipa-dnskeysyncd[30568]: File "/usr/lib/python2.7/site-packa >> ges/ipapython/dnssec/keysyncer.py", line 181, in hsm_replica_sync >> ipa-dnskeysyncd[30568]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) >> ipa-dnskeysyncd[30568]: File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", >> line 494, in run >> ipa-dnskeysyncd[30568]: raise CalledProcessError(p.returncode, >> arg_string, str(output)) >> ipa-dnskeysyncd[30568]: subprocess.CalledProcessError: Command >> '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status >> >> >> >> >> Hello, do you have selinux in enforcing mode? Any AVCs ? >> >> Martin >> > > > yes > > but ipa-dnskeysyncd still fails to start when selinux is in permissive mode > > I did : > ipactl stop > setenforce 0 > service auditd rotate > ipactl start > > and see one avc denied > type=AVC msg=audit(1482164681.053:5195): avc: denied { read } for > pid=1993 comm="ipa-dnskeysync-" name="tokens" dev="dm-7" ino=16818968 > scontext=system_u:system_r:ipa_dnskey_t:s0 tcontext=system_u:object_r:named_cache_t:s0 > tclass=dir > > I gues that is one little bit of selinux that needs adjustment, > > however there is still no running ipa-dnskeysyncd. > > I found that this error appears before the previous one. > > ipa-dnskeysyncd[1981]: ipa: DEBUG: ipaserver.plugins.virtual is not a > valid plugin module > ipa-dnskeysyncd[1981]: ipa: DEBUG: importing plugin module > ipaserver.plugins.xmlserver > ipa-dnskeysyncd[1981]: ipa : DEBUG Kerberos principal: > ipa-dnskeysyncd/freeipa01.tjako.thuis > ipa-dnskeysyncd[1981]: ipa : DEBUG Initializing principal > ipa-dnskeysyncd/freeipa01.tjako.thuis using keytab /etc/ipa/dnssec/ipa- > dnskeysyncd.keytab > ipa-dnskeysyncd[1981]: ipa : DEBUG using ccache > /tmp/ipa-dnskeysync-replica.ccache > ipa-dnskeysyncd[1981]: ipa : DEBUG Attempt 1/5: success > ipa-dnskeysyncd[1981]: ipa : DEBUG Got TGT > ipa-dnskeysyncd[1981]: ipa : DEBUG Connecting to LDAP > ipa-dnskeysyncd[1981]: ipa : DEBUG Connected > ipa-dnskeysyncd[1981]: Traceback (most recent call last): > ipa-dnskeysyncd[1981]: File "/usr/libexec/ipa/ipa-dnskeysync-replica", > line 159, in > ipa-dnskeysyncd[1981]: open(paths.DNSSEC_SOFTHSM_PIN).read()) > ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site- > packages/ipapython/dnssec/localhsm.py", line 95, in __init__ > ipa-dnskeysyncd[1981]: self.p11 = _ipap11helper.P11_Helper(slot, pin, > library) > ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site- > packages/ipapython/p11helper.py", line 837, in __init__ > ipa-dnskeysyncd[1981]: check_return_value(rv, "open session") > ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site- > packages/ipapython/p11helper.py", line 576, in check_return_value > ipa-dnskeysyncd[1981]: raise Error(errmsg) > ipa-dnskeysyncd[1981]: ipapython.p11helper.Error: Error at open session: > 0xe1 > ipa-dnskeysyncd[1981]: Exception AttributeError: "'LocalHSM' object has no > attribute 'p11'" in > ignored > ipa-dnskeysyncd[1981]: Traceback (most recent call last): > ipa-dnskeysyncd[1981]: File "/usr/libexec/ipa/ipa-dnskeysyncd", line 110, > in > ipa-dnskeysyncd[1981]: while ldap_connection.syncrepl_poll(all=1, > msgid=ldap_search): > ipa-dnskeysyncd[1981]: File "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", > line 405, in syncrepl_poll > ipa-dnskeysyncd[1981]: self.syncrepl_refreshdone() > ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site- > packages/ipapython/dnssec/keysyncer.py", line 115, in syncrepl_refreshdone > ipa-dnskeysyncd[1981]: self.hsm_replica_sync() > ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site- > packages/ipapython/dnssec/keysyncer.py", line 181, in hsm_replica_sync > ipa-dnskeysyncd[1981]: ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA]) > ipa-dnskeysyncd[1981]: File "/usr/lib/python2.7/site- > packages/ipapython/ipautil.py", line 494, in run > ipa-dnskeysyncd[1981]: raise CalledProcessError(p.returncode, arg_string, > str(output)) > ipa-dnskeysyncd[1981]: subprocess.CalledProcessError: Command > '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero exit status 1 > systemd[1]: ipa-dnskeysyncd.service: main process exited, code=exited, > status=1/FAILURE > systemd[1]: Unit ipa-dnskeysyncd.service entered failed state. > systemd[1]: ipa-dnskeysyncd.service failed. > > > > Selinux caused that key has not been created in HSM database, you have to > temporarily set selinux to permisive, and run ipa-dns-install again to fix > it. > > Martin > Thanx That seemed to do the trick. Two more questions. Now I even have more AVC deny records (same kind as before) type=AVC msg=audit(1482164681.053:5195): avc: denied { read } for pid=1993 comm="ipa-dnskeysync-" name="tokens" dev="dm-7" ino=16818968 scontext=system_u:system_r:ipa_dnskey_t:s0 tcontext=system_u:object_r:named_cache_t:s0 tclass=dir How do I deal with those, I don't want to break it again by turning on enforcing mode again. Will a simple audit2allow do ? Or is there a better way ? Second question. I now have a ton off these messages in my logs: DSRetroclPlugin - delete_changerecord: could not delete change record<5 digit number> (rc: 32) What are those, is that a journal being replayed ? Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at collective-sense.com Tue Dec 20 00:33:47 2016 From: md at collective-sense.com (Maciej Drobniuch) Date: Tue, 20 Dec 2016 01:33:47 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server Message-ID: Hi All! I get the following message while adding a new hostname. "The host was added but the DNS update failed with: DNS reverse zone in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" The reverse zone is configured and working. When I am manually adding the PTR record to the reverse zone - all OK While adding a new host, the A record is being created but the PTR fails with the message above. Reinstalling centos+IPA worked once but I had to reinstall again because of problems with kerberos(probably dependencies). Not sure what is the root cause of the issue. VERSION: 4.4.0, API_VERSION: 2.213 CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Any help appreciated! -- Best regards Maciej Drobniuch Network Security Engineer Collective-sense LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Dec 20 08:07:25 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 20 Dec 2016 09:07:25 +0100 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> <20161208085923.qh6mauratg3z4f5v@redhat.com> Message-ID: On 8.12.2016 10:12, Pieter Nagel wrote: > On Thu, Dec 8, 2016 at 10:59 AM, Alexander Bokovoy > wrote: > >> It is really simply: your DNS domain named as your Kerberos realm must >> be under your control, one way or another, to allow automatic discovery >> of resources to work. >> > > Thanks, this explanation makes it crystal clear. This exact phrasing would > have made the docs much clearer too, IMO. > > Setting the realm to the DNS domain that the FreeIPA internal DNS server > serves is just one simple out-of-the box way to get DNS domain named as > your Kerberos realm that is under your control, in other words. I've tried to clarify things in man pages and on web as well. Please have a look to changes and let us know if it is better or not, and preferably what can be improved and in which way The modified deployment page is here: http://www.freeipa.org/page/Deployment_Recommendations Man page changes and changes in description of installer options are here: https://github.com/freeipa/freeipa/pull/352 -- Petr^2 Spacek From daniel at schimpfoessl.com Mon Dec 19 18:15:17 2016 From: daniel at schimpfoessl.com (Daniel Schimpfoessl) Date: Mon, 19 Dec 2016 12:15:17 -0600 Subject: [Freeipa-users] Asking for help with crashed freeIPA istance Message-ID: Good day and happy holidays, I have been running a freeIPA instance for a few years and been very happy. Recently the certificate expired and I updated it using the documented methods. At first all seemed fine. Added a Nagios monitor for the certificate expiration and restarted the server (single server). I have weekly snapshots, daily backups (using Amanda on the entire disk). One day the services relying on IPA failed to authenticate. Looking at the server the ipa service had stopped. Restarting the service fails. Restoring a few weeks old snapshot does not start either. Resetting the date to a few month back does not work either as httpd fails to start . I am at a loss. Here a few details: # ipa --version VERSION: 4.4.0, API_VERSION: 2.213 # /usr/sbin/ipactl start ... out -> Failed to start pki-tomcatd Service /var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP server host ipa.myorg.com port 636 Error netscape.ldap.LDAPException: Authentication failed (48) 2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted due to error: Retrieving CA status failed with status 500 Any help would be appreciated as all connected services are now down. Thanks, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvomacka at redhat.com Tue Dec 20 09:46:19 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Tue, 20 Dec 2016 10:46:19 +0100 Subject: [Freeipa-users] Add text to web login page In-Reply-To: <2e16101d257cd$d61be430$8253ac90$@psu.edu> References: <2e16101d257cd$d61be430$8253ac90$@psu.edu> Message-ID: <44413b7c-a363-25ca-2b69-87a0620d2f8c@redhat.com> Hello Mike, the safest way is to create a WebUI plugin. Several examples of plugins can be found here: https://pvoborni.fedorapeople.org/plugins/ . I recommend to look at loginauth. And here is documentation about plugins: https://pvoborni.fedorapeople.org/doc/#!/guide/Plugins On 12/16/2016 07:54 PM, Mike Waite wrote: > I need to add a login banner to the login page for freeIPA, is there a > setting that I could easily change for this? > > Thanks, > -- > Mike Waite > > -- Pavel^3 Vomacka -------------- next part -------------- An HTML attachment was scrubbed... URL: From nirajkumar.singh at accenture.com Tue Dec 20 09:58:54 2016 From: nirajkumar.singh at accenture.com (nirajkumar.singh at accenture.com) Date: Tue, 20 Dec 2016 09:58:54 +0000 Subject: [Freeipa-users] FreeIPA User Authorization Guidelines Required Message-ID: <56954719c90c4e2d88fd89ba428dabba@BLUPR42MB0194.048d.mgd.msft.net> Hi FreeIPA Team, We have performed installation of FreeIPA Master Server and Client Server. We are successful with user creation with home directory and sudo configuration. Regarding Authentication we have some questions: 1. Can we implement authorized key authentication for these servers. Is there any way in FreeIPA we can automate the ppk key generation for each individual user? 2. If Not Automated key generation what are the possible ways for more secured authentication other than password authentication? Thanks and Regards, Niraj Kumar Singh Mobile: +91-9663212985 Email: nirajkumar.singh at accenture.com ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Tue Dec 20 10:18:58 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 20 Dec 2016 11:18:58 +0100 Subject: [Freeipa-users] Asking for help with crashed freeIPA istance In-Reply-To: References: Message-ID: <729a8aed-4f22-ba26-3089-58c675bd64e0@redhat.com> On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote: > Good day and happy holidays, > > I have been running a freeIPA instance for a few years and been very > happy. Recently the certificate expired and I updated it using the > documented methods. At first all seemed fine. Added a Nagios monitor for > the certificate expiration and restarted the server (single server). I > have weekly snapshots, daily backups (using Amanda on the entire disk). > > One day the services relying on IPA failed to authenticate. Looking at > the server the ipa service had stopped. Restarting the service fails. > Restoring a few weeks old snapshot does not start either. Resetting the > date to a few month back does not work either as httpd fails to start . > > I am at a loss. > > Here a few details: > # ipa --version > VERSION: 4.4.0, API_VERSION: 2.213 > > > # /usr/sbin/ipactl start > ... > out -> Failed to start pki-tomcatd Service > /var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP server > host ipa.myorg.com port 636 Error > netscape.ldap.LDAPException: Authentication failed (48) > 2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted due to > error: Retrieving CA status failed with status 500 > > Any help would be appreciated as all connected services are now down. > > Thanks, > > Daniel > > > > Hi Daniel, more information would be required to understand what is going on. First of all, which certificate did you renew? Can you check with $ getcert list if other certificates also expired? PKI fails to start and the error seems linked to the SSL connection with the LDAP server. You may want to check if the LDAP server is listening on the LDAPs port: - start the stack with $ ipactl start --force - check the LDAPs port with $ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w password -b "" -s base The communication between PKI and the LDAP server is authenticated with the certificate 'subsystemCert cert-pki-ca' located in /etc/pki/pki-tomcat/alias, so you may also want to check if it is still valid. The directory server access logs (in /var/log/dirsrv/slapd-DOMAIN-COM/access) would also show the connection with logs similar to: [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to 10.34.58.150 [...] conn=47 TLS1.2 128-bit AES; client CN=CA Subsystem,O=DOMAIN.COM; issuer CN=Certificate Authority,O=DOMAIN.COM [...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=pkidbuser,ou=people,o=ipaca" HTH, Flo From bentech4you at gmail.com Tue Dec 20 10:19:15 2016 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 20 Dec 2016 13:19:15 +0300 Subject: [Freeipa-users] Sudo rule implementation Message-ID: Hi List, please help me to implement sudo rules. i have did below steps and still not working for me. 1. created "Sudo Command Groups" 2. Added some command (/bin/yum) and included in sudo group 3. created "sudo Rule" on that * added sudo Option as "!authenticate" * Added User Group. * Added one Host * And under Run command, selected the Sudo Rule Group. 4. entry on nsswitch.conf : sudoers: files sss 5. entry on sssd.conf : services = nss, sudo, pam, ssh and i tried removing "!authenticate" and changed to Anyone, Any Host and Any Command, Also under As Whom to Anyone and Any Group - I tried logout and login again on client with IPA user which is member of user group. When i am running yum, getting error that user is not allowed to execute command. Please anyone help to correct my steps. Regards Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Dec 20 10:55:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 20 Dec 2016 11:55:36 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <1482179085.28211.36.camel@interlinx.bc.ca> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> Message-ID: On 19.12.2016 21:24, Brian J. Murrell wrote: > On Mon, 2016-12-19 at 17:26 +0100, Martin Basti wrote: >> On 19.12.2016 13:19, Brian J. Murrell wrote: >>> On Mon, 2016-12-19 at 09:42 +0100, Martin Basti wrote: >>>> Hello, >>>> >>>> could you recheck with SElinux in permissive mode? >>> Yeah, still happens even after doing: >>> >>> # setenforce 0 >>> >>> Cheers, >>> b. >> could you please kinit as service? >> >> >> kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa- >> dnskeysyncd/$(hostname) > # kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa-dnskeysyncd/server.example.com > # klist > Ticket cache: KEYRING:persistent:0:0 > Default principal: ipa-dnskeysyncd/server.example.com at EXAMPLE.COM > > Valid starting Expires Service principal > 19/12/16 15:20:20 20/12/16 15:20:20 krbtgt/EXAMPLE.COM at EXAMPLE.COM > > Seems to have worked. FWIW, I was not asked for any password. > > Cheers, > b. > > The password is the keytab file So there are actually no issues with credentials, it needs more debugging, in past we have similar case but we haven't found the root cause why it doesn't have the right credentials after kinit. Are you willing to do more basic level code debugging? BTW this is used only with DNSSEC feature. I you don't use DNSSEC signing you can ignore this failing service (ipactl start --ignore-service-failures) Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Tue Dec 20 11:09:30 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Dec 2016 12:09:30 +0100 Subject: [Freeipa-users] FreeIPA User Authorization Guidelines Required In-Reply-To: <56954719c90c4e2d88fd89ba428dabba@BLUPR42MB0194.048d.mgd.msft.net> References: <56954719c90c4e2d88fd89ba428dabba@BLUPR42MB0194.048d.mgd.msft.net> Message-ID: <5e9e7cea-aaf5-44dd-21ef-ced44b4f7b08@redhat.com> On 12/20/2016 10:58 AM, nirajkumar.singh at accenture.com wrote: > Hi FreeIPA Team, > > We have performed installation of FreeIPA Master Server and Client Server. We > are successful with user creation with home directory and sudo configuration. > > Regarding Authentication we have some questions: > > 1.Can we implement authorized key authentication for these servers. Is there any > way in FreeIPA we can automate the ppk key generation for each individual user? FreeIPA/IdM supports central management of public SSH keys: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/user-keys.html > > 2.If Not Automated key generation what are the possible ways for more secured > authentication other than password authentication? It supports Two Factor Authentication via integrated OTP support or third party RADIUS server: OTP: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/otp.html RADIUS proxy: 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 > > Thanks and Regards, > > Niraj Kumar Singh > > Mobile: +91-9663212985 > > Email: nirajkumar.singh at accenture.com > > > -------------------------------------------------------------------------------- > > This message is for the designated recipient only and may contain privileged, > proprietary, or otherwise confidential information. If you have received it in > error, please notify the sender immediately and delete the original. Any other > use of the e-mail by you is prohibited. Where allowed by local law, electronic > communications with Accenture and its affiliates, including e-mail and instant > messaging (including content), may be scanned by our systems for the purposes of > information security and assessment of internal compliance with Accenture policy. > ______________________________________________________________________________________ > > www.accenture.com > > > -- Petr Vobornik From jhrozek at redhat.com Tue Dec 20 11:24:45 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 20 Dec 2016 12:24:45 +0100 Subject: [Freeipa-users] Sudo rule implementation In-Reply-To: References: Message-ID: <20161220112445.uvcxknf7dt6ketfm@hendrix> On Tue, Dec 20, 2016 at 01:19:15PM +0300, Ben .T.George wrote: > Hi List, > > please help me to implement sudo rules. > > i have did below steps and still not working for me. > > 1. created "Sudo Command Groups" > 2. Added some command (/bin/yum) and included in sudo group > 3. created "sudo Rule" on that > * added sudo Option as "!authenticate" > * Added User Group. > * Added one Host > * And under Run command, selected the Sudo Rule Group. > 4. entry on nsswitch.conf : sudoers: files sss > 5. entry on sssd.conf : services = nss, sudo, pam, ssh > > and i tried removing "!authenticate" and changed to Anyone, Any Host and Any > Command, > Also under As Whom to Anyone and Any Group > - I tried logout and login again on client with IPA user which is member of > user group. > > When i am running yum, getting error that user is not allowed to execute > command. > > > Please anyone help to correct my steps. > > Regards > Ben Please follow: https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO especially the sudo logs are often helpful to see what rules is sssd returning to sudo. From brian at interlinx.bc.ca Tue Dec 20 11:41:05 2016 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Tue, 20 Dec 2016 06:41:05 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> Message-ID: <1482234065.28211.55.camel@interlinx.bc.ca> On Tue, 2016-12-20 at 11:55 +0100, Martin Basti wrote: > > So there are actually no issues with credentials, it needs more? > debugging, in past we have similar case but we haven't found the > root? > cause why it doesn't have the right credentials after kinit. So, to be clear, all I did was kinit. I didn't do anything after that once the credentials were acquired. Should I have or did you just want me to test that credential file was usable? I did that as root. Here's the permissions on that keytab just in case there is a problem there: # ls -lZ /etc/ipa/dnssec/ipa-dnskeysyncd.keytab -r--r-----. root ods unconfined_u:object_r:etc_t:s0???/etc/ipa/dnssec/ipa-dnskeysyncd.keytab restorecon says that the selinux labels are ok. The file is not in the RPM (i.e. as a config file) so I have no reference for the permissions of it. > Are you? > willing to do more basic level code debugging? Absolutely. > BTW this is used only with DNSSEC feature. I you don't use DNSSEC? > signing you can ignore this failing service (ipactl start? > --ignore-service-failures) Let's also not lose sight of the other problem that occurred at the same upgrade and that's the having to fall back to simple authentication of bind with: ??????? arg "auth_method simple"; ??????? arg "bind_dn uid=admin,cn=users,cn=accounts,dc=example.com"; ??????? arg "password my_password"; in /etc/named.conf due to: 21:12:19 LDAP error: Invalid credentials: bind to LDAP server failed trying to start bind via systemctl start ipa. Is it most likely that these two problems are in fact not related? Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From flo at redhat.com Tue Dec 20 14:43:59 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 20 Dec 2016 15:43:59 +0100 Subject: [Freeipa-users] Failed ipa-client-install with IPA Replica In-Reply-To: References: <794d723f-9994-2281-1add-c5d0d1167257@redhat.com> Message-ID: On 12/16/2016 03:54 PM, Florence Blanc-Renaud wrote: > On 12/15/2016 08:01 PM, beeth beeth wrote: >> Hi Flo, >> >> That's a good point! I checked the dirsrv certificate and confirmed >> valid(good until later next year). >> Since I had no problem to enroll another new IPA client(RHEL7 box >> instead of RHEL6) to such replica server, I thought it might not be a >> server end issue. However, when I tried to restart the DIRSRV service on >> the replica server, I found these messages in the log >> file /var/log/dirsrv/slapd-IPA-EXAMPLE-COM/errors: >> >> [15/Dec/2016:13:38:15.891301246 -0500] 389-Directory/1.3.5.10 >> B2016.257.1817 starting up >> [15/Dec/2016:13:38:15.911777373 -0500] default_mr_indexer_create: >> warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match >> [15/Dec/2016:13:38:15.926320306 -0500] WARNING: changelog: entry cache >> size 2097152 B is less than db size 5488640 B; We recommend to increase >> the entry cache size nsslapd-cachememsize. >> [15/Dec/2016:13:38:16.132155534 -0500] schema-compat-plugin - scheduled >> schema-compat-plugin tree scan in about 5 seconds after the server >> startup! >> [15/Dec/2016:13:38:16.167896279 -0500] NSACLPlugin - The ACL target >> cn=dns,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.173317345 -0500] NSACLPlugin - The ACL target >> cn=dns,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.178354342 -0500] NSACLPlugin - The ACL target >> cn=keys,cn=sec,cn=dns,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.183579322 -0500] NSACLPlugin - The ACL target >> cn=dns,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.188786976 -0500] NSACLPlugin - The ACL target >> cn=dns,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.193275650 -0500] NSACLPlugin - The ACL target >> cn=groups,cn=compat,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.197580407 -0500] NSACLPlugin - The ACL target >> cn=computers,cn=compat,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.201863256 -0500] NSACLPlugin - The ACL target >> cn=ng,cn=compat,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.206318629 -0500] NSACLPlugin - The ACL target >> ou=sudoers,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.211559100 -0500] NSACLPlugin - The ACL target >> cn=users,cn=compat,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.216146819 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.220786596 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.225594942 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.229986749 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.234518367 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.238763121 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.243031116 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.247507984 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.252327210 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.259046910 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.263856581 -0500] NSACLPlugin - The ACL target >> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.269301704 -0500] NSACLPlugin - The ACL target >> cn=ad,cn=etc,dc=ipa,dc=example,dc=com does not exist >> [15/Dec/2016:13:38:16.283511408 -0500] NSACLPlugin - The ACL target >> cn=casigningcert >> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does >> not exist >> [15/Dec/2016:13:38:16.287853825 -0500] NSACLPlugin - The ACL target >> cn=casigningcert >> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does >> not exist >> [15/Dec/2016:13:38:16.395872649 -0500] NSACLPlugin - The ACL target >> cn=automember rebuild membership,cn=tasks,cn=config does not exist >> [15/Dec/2016:13:38:16.405404114 -0500] Skipping CoS Definition >> cn=Password Policy,cn=accounts,dc=ipa,dc=example,dc=com--no CoS >> Templates found, which should be added before the CoS Definition. >> [15/Dec/2016:13:38:16.463117873 -0500] set_krb5_creds - Could not get >> initial credentials for principal >> [ldap/ipaprd2.example.com at IPA.EXAMPLE.COM >> ] in keytab >> [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) >> [15/Dec/2016:13:38:16.471256279 -0500] schema-compat-plugin - >> schema-compat-plugin tree scan will start in about 5 seconds! >> [15/Dec/2016:13:38:16.479213976 -0500] slapd started. Listening on All >> Interfaces port 389 for LDAP requests >> [15/Dec/2016:13:38:16.483683353 -0500] Listening on >> /var/run/slapd-IPA-EXAMPLE-COM.socket for LDAPI requests >> [15/Dec/2016:13:38:21.634319974 -0500] schema-compat-plugin - warning: >> no entries set up under ou=sudoers,dc=ipa,dc=example,dc=com >> [15/Dec/2016:13:38:21.639855161 -0500] schema-compat-plugin - warning: >> no entries set up under cn=ng, cn=compat,dc=ipa,dc=example,dc=com >> [15/Dec/2016:13:38:21.653406463 -0500] schema-compat-plugin - no RDN for >> cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com, unsetting >> domain/map/id >> "cn=compat,dc=ipa,dc=example,dc=com"/"cn=groups"/("cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com") >> >> [15/Dec/2016:13:38:21.714897614 -0500] schema-compat-plugin - warning: >> no entries set up under cn=computers, cn=compat,dc=ipa,dc=example,dc=com >> [15/Dec/2016:13:38:21.719933118 -0500] schema-compat-plugin - Finished >> plugin initialization. >> [15/Dec/2016:13:38:36.591969481 -0500] ipa-topology-plugin - >> ipa_topo_util_get_replica_conf: server configuration missing >> [15/Dec/2016:13:38:36.598683009 -0500] ipa-topology-plugin - >> ipa_topo_util_get_replica_conf: cannot create replica >> >> Any idea? >> BTW, everything ran well on IPA 4.2(server installation and client >> installation), as you once assisted me couple months ago, until we set >> up a new IPA environment with RHEL7.3 instead of RHEL7.2, then the IPA >> version changed from 4.2 to 4.4. Last time you guided me about the >> change since IPA 4.3, for the newly introduced domain level concept, and >> the way how the replica should be installed was changed too... Thanks >> again! >> > Hi Beeth, > > I managed to reproduce your issue with IPA master installed without dns > and without integrated CA. > > Can you check on your RHEL 6 client if there is a file /etc/ipa/ca.crt? > If yes, check its content with > $ sudo openssl x509 -noout -text -in /etc/ipa/ca.crt > and compare with the CA certificate stored on the master or the replica > (at the same location /etc/ipa/ca.crt). The certificate should be the > one for the CA that signed your HTTPd and LDAP server certs (ie Verisign). > > If the certificate is different, it is probably a left-over CA > certificate corresponding to a previous installation. You can just > delete the file on the client and re-run ipa-client-install. > > Flo. > To follow-up on this issue: it happens only in CA-less environment and when the client has an old /etc/ipa/ca.crt file. If the /etc/ipa/ca.crt file is present, the client installer connects to the IPA LDAP server using startTLS to perform basic checks (instead of using a simple ldap conn otherwise). But there is a bug in ipa-replica-install which does not set up startTLS on the LDAP replica (see ticket 6226 [1]). This explains why the issue does not happen if you specify only the master during ipa-client-install, or if your client does not have any /etc/ipa/ca.crt. Hope this clarifies, Flo [1] https://fedorahosted.org/freeipa/ticket/6226 >> >> On Thu, Dec 15, 2016 at 10:52 AM, Florence Blanc-Renaud > > wrote: >> >> On 12/14/2016 07:49 PM, beeth beeth wrote: >> >> Hi Flo, >> >> Thanks for the great hint! I reran the ipa-client-install on the >> rhel6 >> box(ipadev6), and monitored the access log file you mentioned >> on the >> replica: >> >> # ipa-client-install --domain=ipa.example.com >> >> --server=ipaprd2.example.com >> >> --hostname=ipadev6.example.com >> -d >> >> ( ipaprd2 = primary IPA server on RHEL7; ipadev6 = replica on >> RHEL6 ) >> >> AFTER about 3 seconds, I saw these on the replica ipaprd2: >> [14/Dec/2016:13:11:41.071421132 -0500] conn=1040 fd=73 slot=73 >> connection from to >> [14/Dec/2016:13:11:41.071880026 -0500] conn=1040 op=0 EXT >> oid="1.3.6.1.4.1.1466.20037" >> [14/Dec/2016:13:11:41.071964217 -0500] conn=1040 op=0 RESULT >> err=2 >> tag=120 nentries=0 etime=0 >> [14/Dec/2016:13:11:41.073275674 -0500] conn=1040 op=1 UNBIND >> [14/Dec/2016:13:11:41.073307101 -0500] conn=1040 op=1 fd=73 >> closed - U1 >> [14/Dec/2016:13:11:41.074782496 -0500] conn=1041 fd=73 slot=73 >> connection from to >> [14/Dec/2016:13:11:41.074985233 -0500] conn=1041 op=0 EXT >> oid="1.3.6.1.4.1.1466.20037" >> [14/Dec/2016:13:11:41.075022849 -0500] conn=1041 op=0 RESULT >> err=2 >> tag=120 nentries=0 etime=0 >> [14/Dec/2016:13:11:41.075448887 -0500] conn=1041 op=1 UNBIND >> [14/Dec/2016:13:11:41.075460964 -0500] conn=1041 op=1 fd=73 >> closed - U1 >> [14/Dec/2016:13:11:49.006146850 -0500] conn=1029 op=8 UNBIND >> [14/Dec/2016:13:11:49.006181982 -0500] conn=1029 op=8 fd=66 >> closed - U1 >> >> So I did see the err=2, and oid="1.3.6.1.4.1.1466.20037", I >> checked the >> oid and got: >> >> 1.3.6.1.4.1.1466.20037: StartTLS Request (RFC 4511) >> >> It looked to be related with TLS... pease advise. Thanks! >> >> >> Hi, >> >> when the replica got installed, the installer must have configured >> the directory server for SSL and start TLS. I tend to suspect an >> expired certificate issue rather than a misconfiguration. Could you >> please check that dirsrv certificate is still valid? >> >> $ certutil -L -d /etc/dirsrv/slapd-DOMAIN-COM/ -n Server-Cert >> |grep Not >> Not Before: Wed Dec 14 16:56:02 2016 >> Not After : Sat Dec 15 16:56:02 2018 >> >> If the certificate is still valid, you may want to read 389-ds >> How-To to make sure that SSL is properly setup: >> >> http://directory.fedoraproject.org/docs/389ds/howto/howto-ssl.html#deploy-the-settings >> >> >> >> >> >> Flo. >> >> >> On Wed, Dec 14, 2016 at 7:57 AM, Florence Blanc-Renaud >> >> >> wrote: >> >> On 12/14/2016 01:08 PM, beeth beeth wrote: >> >> Thanks David. I installed both the master and replica IPA >> servers with >> third-party certificates(Verisign), but I doubt that >> could be >> the issue, >> because I had no problem to run the same >> ipa-client-install >> command on a >> RHEL7 machine(of course, the --hostname used a different >> hostname of the >> server). And I had no problem to run the >> ipa-client-install >> command with >> --server= on such RHEL6 machine. So what could >> cause the >> LDAP >> communication failed during the client enrollment with >> the >> replica? Is >> there a way I can troubleshoot this by running some >> commands? So >> far I >> did telnet to check the open ports, as well as run the >> ldapsearch >> towards the replica. Thanks again! >> >> >> On Tue, Dec 13, 2016 at 8:46 AM, David Kupka >> >> > >> >> >>> wrote: >> >> On 13/12/16 05:44, beeth beeth wrote: >> >> I have two IPA servers ipaprd1.example.com >> >> >> and >> ipaprd2.example.com >> >> , running >> ipa 4.4 on RHEL7. When I tried to >> install/configure the >> client >> on a RHEL6 >> system(called ipadev6), I had issue when I >> tried to >> enroll it >> with the >> replica(ipaprd2), while no issue with the >> primary(ipaprd1): >> >> # ipa-client-install --domain=ipa.example.com >> >> >> >> --server=ipaprd1.example.com >> >> >> --server=ipaprd2.example.com >> >> >> --hostname=ipadev6.example.com >> >> >> LDAP Error: Protocol error: unsupported extended >> operation >> Autodiscovery of servers for failover cannot >> work with this >> configuration. >> If you proceed with the installation, services >> will be >> configured to always >> access the discovered server for all operations >> and will not >> fail over to >> other servers in case of failure. >> Proceed with fixed values and no DNS >> discovery? [no] >> >> Then I tried to run ipa-client-install to enroll >> with the >> replica(ipaprd2), >> with debug mode, I got this: >> >> # ipa-client-install --domain=ipa.example.com >> >> >> >> --server=ipaprd2.example.com >> >> >> --hostname=ipadev6.example.com >> >> >> -d >> >> /usr/sbin/ipa-client-install was invoked with >> options: >> {'domain': ' >> ipa.example.com >> >> ', 'force': False, >> 'realm_name': None, >> 'krb5_offline_passwords': True, 'primary': False, >> 'mkhomedir': >> False, >> 'create_sshfp': True, 'conf_sshd': True, >> 'conf_ntp': True, >> 'on_master': >> False, 'ntp_server': None, 'nisdomain': None, >> 'no_nisdomain': False, >> 'principal': None, 'hostname': >> 'ipadev6.example.com >> >> ', 'no_ac': False, >> 'unattended': None, 'sssd': True, 'trust_sshfp': >> False, >> 'kinit_attempts': >> 5, 'dns_updates': False, 'conf_sudo': True, >> 'conf_ssh': >> True, >> 'force_join': >> False, 'ca_cert_file': None, 'server': >> ['ipaprd2.example.com >> >> '], >> 'prompt_password': False, 'permit': False, >> 'debug': True, >> 'preserve_sssd': >> False, 'uninstall': False} >> missing options might be asked for interactively >> later >> Loading Index file from >> '/var/lib/ipa-client/sysrestore/sysrestore.index' >> Loading StateFile from >> '/var/lib/ipa-client/sysrestore/sysrestore.state' >> [IPA Discovery] >> Starting IPA discovery with >> domain=ipa.example.com >> >> , servers=[' >> ipaprd2.example.com >> >> '], >> hostname=ipadev6.example.com >> >> >> Server and domain forced >> [Kerberos realm search] >> Search DNS for TXT record of >> _kerberos.ipa.example.com >> > > >> > >> > >>. >> No DNS record found >> Search DNS for SRV record of >> _kerberos._udp.ipa.example.com >> >> . >> No DNS record found >> SRV record for KDC not found! Domain: >> ipa.example.com >> >> >> [LDAP server check] >> Verifying that ipaprd2.example.com >> >> >> (realm None) is an IPA server >> Init LDAP connection with: >> ldap://ipaprd2.example.com:389 >> > > >> > >> > >> >> LDAP Error: Protocol error: unsupported extended >> operation >> Discovery result: UNKNOWN_ERROR; server=None, >> domain=ipa.example.com >> >> , >> kdc=None, basedn=None >> Validated servers: >> will use discovered domain: ipa.example.com >> >> >> IPA Server not found >> [IPA Discovery] >> Starting IPA discovery with >> domain=ipa.example.com >> >> , servers=[' >> ipaprd2.example.com >> >> '], >> hostname=ipadev6.example.com >> >> >> Server and domain forced >> [Kerberos realm search] >> Search DNS for TXT record of >> _kerberos.ipa.example.com >> > > >> > >> > >>. >> No DNS record found >> Search DNS for SRV record of >> _kerberos._udp.ipa.example.com >> >> . >> No DNS record found >> SRV record for KDC not found! Domain: >> ipa.example.com >> >> >> [LDAP server check] >> Verifying that ipaprd2.example.com >> >> >> (realm None) is an IPA server >> Init LDAP connection with: >> ldap://ipaprd2.example.com:389 >> > > >> > >> > >> >> LDAP Error: Protocol error: unsupported extended >> operation >> Discovery result: UNKNOWN_ERROR; server=None, >> domain=ipa.example.com >> >> , >> kdc=None, basedn=None >> Validated servers: >> Failed to verify that ipaprd2.example.com >> >> >> is an IPA Server. >> This may mean that the remote server is not up >> or is not >> reachable due to >> network or firewall settings. >> Please make sure the following ports are opened >> in the >> firewall >> settings: >> TCP: 80, 88, 389 >> UDP: 88 (at least one of TCP/UDP ports 88 >> has to be >> open) >> Also note that following ports are necessary for >> ipa-client working >> properly after enrollment: >> TCP: 464 >> UDP: 464, 123 (if NTP enabled) >> (ipaprd2.example.com >> >> : Provided as >> option) >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> >> I double checked the services running on the >> replica, >> all looked >> well: >> ports are listening, and I could telnet the >> ports from the >> client(ipadev6). >> I could run "ldapserach" command to talk to the >> replica(ipaprd2) >> from this >> client(ipadev6), with pulling out all the LDAP >> records. >> >> Also, I have another test box running RHEL7, >> and no >> issue at all >> to run the >> exact same ipa-client-install command on that >> RHEL7 box. So >> could there be >> a bug on the ipa-client software on RHEL6, to >> talk to >> IPA sever >> running on >> RHEL7? Please advise. Thank you! >> >> Hi Beeth, >> >> you may want to check the access and errors log of the >> Directory >> Server in /var/log/dirsrv/slapd-DOMAIN. The extended >> operations are >> logged in the access log with the tag "EXT oid=...", but a >> failing >> operation related to unsupported extended operation will >> probably >> log a "RESULT err=2". >> >> So I would first check access log and look for such a >> failure. With >> the OID we will be able to understand which operation is >> failing and >> which part could be misconfigured. >> >> HTH, >> Flo. >> >> Best regards, >> Beeth >> >> >> >> Hello Beeth, >> I've tried to reproduce the problem you described >> with 7.3 >> (ipa-server 4.4.0-12) on master and replica and 6.9 >> (ipa-client >> 3.0.0-51) on client and it worked for me as expected. >> I've done these steps: >> [master] # ipa-server-install -a Secret123 -p >> Secret123 --domain >> example.test --realm EXAMPLE.TEST --setup-dns >> --auto-forwarders -U >> [replica] # ipa-client-install -p admin -w Secret123 >> --domain >> example.test --server master.example.test -U >> [replica] # ipa-replica-install >> [client] # ipa-client-install -p admin -w Secret123 >> --domain >> example.test --server replica.example.test -U >> [client] # id admin >> >> Is there anything you've done differently? >> >> -- >> David Kupka >> >> >> >> >> >> >> >> > From daniel at schimpfoessl.com Tue Dec 20 15:36:46 2016 From: daniel at schimpfoessl.com (Daniel Schimpfoessl) Date: Tue, 20 Dec 2016 09:36:46 -0600 Subject: [Freeipa-users] Asking for help with crashed freeIPA istance In-Reply-To: <729a8aed-4f22-ba26-3089-58c675bd64e0@redhat.com> References: <729a8aed-4f22-ba26-3089-58c675bd64e0@redhat.com> Message-ID: Thanks for getting back to me. getcert list | grep expires shows dates years in the future for all certificates [image: Inline-Bild 1] ipactl start --force Eventually the system started with: Forced start, ignoring pki-tomcatd Service, continuing normal operations. systemctl status ipa shows: failed ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w password -b "" -s base ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w *********** -b "" -s base [image: Inline-Bild 2] The logs have thousands of lines like it, what am I looking for specifically? Daniel 2016-12-20 4:18 GMT-06:00 Florence Blanc-Renaud : > On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote: > >> Good day and happy holidays, >> >> I have been running a freeIPA instance for a few years and been very >> happy. Recently the certificate expired and I updated it using the >> documented methods. At first all seemed fine. Added a Nagios monitor for >> the certificate expiration and restarted the server (single server). I >> have weekly snapshots, daily backups (using Amanda on the entire disk). >> >> One day the services relying on IPA failed to authenticate. Looking at >> the server the ipa service had stopped. Restarting the service fails. >> Restoring a few weeks old snapshot does not start either. Resetting the >> date to a few month back does not work either as httpd fails to start . >> >> I am at a loss. >> >> Here a few details: >> # ipa --version >> VERSION: 4.4.0, API_VERSION: 2.213 >> >> >> # /usr/sbin/ipactl start >> ... >> out -> Failed to start pki-tomcatd Service >> /var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP server >> host ipa.myorg.com port 636 Error >> netscape.ldap.LDAPException: Authentication failed (48) >> 2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted due to >> error: Retrieving CA status failed with status 500 >> >> Any help would be appreciated as all connected services are now down. >> >> Thanks, >> >> Daniel >> >> >> >> >> Hi Daniel, > > more information would be required to understand what is going on. First > of all, which certificate did you renew? Can you check with > $ getcert list > if other certificates also expired? > > PKI fails to start and the error seems linked to the SSL connection with > the LDAP server. You may want to check if the LDAP server is listening on > the LDAPs port: > - start the stack with > $ ipactl start --force > - check the LDAPs port with > $ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w > password -b "" -s base > > The communication between PKI and the LDAP server is authenticated with > the certificate 'subsystemCert cert-pki-ca' located in > /etc/pki/pki-tomcat/alias, so you may also want to check if it is still > valid. > The directory server access logs (in /var/log/dirsrv/slapd-DOMAIN-COM/access) > would also show the connection with logs similar to: > > [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to > 10.34.58.150 > [...] conn=47 TLS1.2 128-bit AES; client CN=CA Subsystem,O=DOMAIN.COM; > issuer CN=Certificate Authority,O=DOMAIN.COM > [...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca > [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL > [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 > dn="uid=pkidbuser,ou=people,o=ipaca" > > > > HTH, > Flo > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 8557 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 3927 bytes Desc: not available URL: From gnotrica at candeal.com Tue Dec 20 19:27:37 2016 From: gnotrica at candeal.com (Gady Notrica) Date: Tue, 20 Dec 2016 19:27:37 +0000 Subject: [Freeipa-users] ipa-replica-install command failed Message-ID: <0984AB34E553F54B8705D776686863E70FBD2BC5@cd-exchange01.CD-PRD.candeal.ca> Hello, Need some help installing replica - FREEIPA on Centos 7. My networking is run, DNS is up on the master IPA all ports are opened. But I can't isolate the problem. Any help? ------ Error: The ipa-replica-install command failed, exception: SystemExit: 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. ------ Command # ipa-replica-install --setup-dns --setup-ca --no-forwarder --ip-address=172.20.10.100 /var/lib/ipa/replica-info-sys-sec-repl.ipa.domain.com.gpg Directory Manager (existing master) password: Run connection check to master admin at IPA.DOMAIN.COM password: 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. ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information ----- LOG at /var/log/ipareplica-install.log 2016-12-20T19:14:50Z DEBUG stdout=Check connection from replica to remote master ' sys-pri-repl.ipa.domain.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 RPC connection to remote master Retrying using SSH... 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 sys-pri-repl.ipa.domain.com [172.20.10.99] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 6r:0e:15:55:dk:17:86:27:53:02:02:89:c7:98:20:11 Warning: Permanently added 'sys-pri-repl.ipa.domain.com,172.20.10.99' (ECDSA) to the list of known hosts. debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic Connection closed by 172.20.10.99 2016-12-20T19:14:50Z DEBUG stderr=Could not SSH to remote host. 2016-12-20T19:14:50Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 318, in run cfgr.run() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 308, in run self.validate() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 317, in validate for nothing in self._validator(): File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 564, in _configure next(validator) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 372, in __runner self._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 449, in _handle_exception self.__parent._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 446, in _handle_exception super(ComponentBase, self)._handle_exception(exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 394, in _handle_exception six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 362, in __runner step() File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 359, in step = lambda: next(self.__gen) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from six.reraise(*exc_info) File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from value = gen.send(prev_value) File "/usr/lib/python2.7/site-packages/ipapython/install/common.py", line 63, in _install for nothing in self._installer(self.parent): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 1716, in main install_check(self) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 364, in decorated func(installer) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py", line 761, in install_check ca_cert_file=cafile) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 106, in replica_conn_check "\nIf the check results are not valid it can be skipped with --skip-conncheck parameter.") 2016-12-20T19:14:50Z DEBUG The ipa-replica-install command failed, exception: SystemExit: 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. 2016-12-20T19:14:50Z 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. 2016-12-20T19:14:50Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen at jochen.org Tue Dec 20 22:32:27 2016 From: jochen at jochen.org (Jochen Hein) Date: Tue, 20 Dec 2016 23:32:27 +0100 Subject: [Freeipa-users] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server In-Reply-To: <20161218103332.ipv3v7u3rarduyyu@redhat.com> (Alexander Bokovoy's message of "Sun, 18 Dec 2016 12:33:32 +0200") References: <83shpm1b73.fsf@echidna.jochen.org> <20161218092725.gmsznodxdrwhjgbt@redhat.com> <83oa091qks.fsf@echidna.jochen.org> <20161218103332.ipv3v7u3rarduyyu@redhat.com> Message-ID: <83wpeuz0xw.fsf@echidna.jochen.org> Alexander Bokovoy writes: >>1. KDC to ipa-otd: this can be changed in >>/var/kerberos/krb5kdc/kdc.conf. I think the timeout should be larger >>then the (largest) second timeout - and I think retries=0 is best. >>This is for communication between KDC and ipa-otd. >> >>2. There is a timeout in each RADIUS server config in IPA for the >>communication from ipa-otp to external RADIUS servers: >>`---- >>Again I think that for OTPs we are probably best with retries=0. >> >>On older clients it might be helpful to add "udp_preference_limit = 0" >>to /etc/krb5.conf - at least on my Debian/Ubuntu machines. > Ok. It would probably make sense to file a ticket to FreeIPA tracker to > get these changes in FreeIPA 4.5. I think I've won my fight... Here's what I've learned. The short story is that probably no timeout should be changed. Shall I still file a ticket concerning retry counts? Authentication of IPA users against RADIUS were mostly failing, but not always. There were hints about timeouts almost everywhere. Multiple authentication requests from kerberos, timeouts from sssd, but that should have sent me on the right track from the start: Dec 19 22:11:51 freeipa1 ipa-otpd: LDAP: ldapi://%2Fvar%2Frun%2Fslapd-JOCHEN-ORG.socket Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: request received Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: user query start Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: user query end: uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: radius query start: cn=athene,cn=radiusproxy,dc=jochen,dc=org Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: radius query end: athene.jochen.org Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: forward start: jkellner at jochen.org / athene.jochen.org Dec 19 22:12:01 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: forward end: Connection timed out Dec 19 22:12:01 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: response sent: Access-Reject or: Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: request received Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: user query start Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: user query end: uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: radius query start: cn=athene,cn=radiusproxy,dc=jochen,dc=org Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: radius query end: athene.jochen.org Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: forward start: jkellner at jochen.org / athene.jochen.org Dec 20 22:40:31 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: forward end: Access-Accept Dec 20 22:40:31 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: response sent: Access-Accept Why is there such a long delay? The Log of the RADIUS server has: Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Config File /opt/privacyIDEA/rlm_perl.ini found! Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Debugging config: true Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Default URL https://athene.jochen.org/validate/check Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Looking for config for auth-type Perl Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Auth-Type: Perl Tue Dec 20 22:40:30 2016 : Info: rlm_perl: url: https://athene.jochen.org/validate/check Tue Dec 20 22:40:30 2016 : Info: rlm_perl: user sent to privacyidea: jkellner at jochen.org Tue Dec 20 22:40:30 2016 : Info: rlm_perl: realm sent to privacyidea: jochen.org Tue Dec 20 22:40:30 2016 : Info: rlm_perl: resolver sent to privacyidea: Tue Dec 20 22:40:30 2016 : Info: rlm_perl: client sent to privacyidea: 192.168.30.121 Tue Dec 20 22:40:30 2016 : Info: rlm_perl: state sent to privacyidea: Tue Dec 20 22:40:31 2016 : Info: rlm_perl: privacyIDEA access granted Tue Dec 20 22:40:31 2016 : Info: rlm_perl: return RLM_MODULE_OK So RADIUS thinks, it got a request a 30 seconds, but why did we wait so long? I took a tcpdump and saw: 22:40:23.364355 IP6 freeipa1.jochen.org.41198 > athene.jochen.org.radius: RADIUS, Access-Request (1), id: 0x10 length: 134 22:40:30.872136 IP freeipa1.jochen.org.44314 > athene.jochen.org.radius: RADIUS, Access-Request (1), id: 0x9c length: 134 22:40:31.572217 IP athene.jochen.org.radius > freeipa1.jochen.org.44314: RADIUS, Access-Accept (2), id: 0x9c length: 48 So, we received an IPv6 packet, but didn't react. Some seconds later IPA-OTP retried with IPv4 and succeeded. A quick check showed that freeradius did not listen on IPv6. After fixing that, a request looks like this: Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: request received Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: user query start Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: user query end: uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: radius query start: cn=athene,cn=radiusproxy,dc=jochen,dc=org Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: radius query end: athene.jochen.org Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: forward start: jkellner at jochen.org / athene.jochen.org Dec 20 22:54:58 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: forward end: Access-Accept Dec 20 22:54:58 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: response sent: Access-Accept and Tue Dec 20 22:54:57 2016 : Info: rlm_perl: Config File /opt/privacyIDEA/rlm_perl.ini found! Tue Dec 20 22:54:57 2016 : Info: rlm_perl: Debugging config: true Tue Dec 20 22:54:57 2016 : Info: rlm_perl: Default URL https://athene.jochen.org/validate/check Tue Dec 20 22:54:57 2016 : Info: rlm_perl: Looking for config for auth-type Perl Tue Dec 20 22:54:57 2016 : Info: rlm_perl: Auth-Type: Perl Tue Dec 20 22:54:57 2016 : Info: rlm_perl: url: https://athene.jochen.org/validate/check Tue Dec 20 22:54:57 2016 : Info: rlm_perl: user sent to privacyidea: jkellner at jochen.org Tue Dec 20 22:54:57 2016 : Info: rlm_perl: realm sent to privacyidea: jochen.org Tue Dec 20 22:54:57 2016 : Info: rlm_perl: resolver sent to privacyidea: Tue Dec 20 22:54:57 2016 : Info: rlm_perl: client sent to privacyidea: Tue Dec 20 22:54:57 2016 : Info: rlm_perl: state sent to privacyidea: Tue Dec 20 22:54:58 2016 : Info: rlm_perl: privacyIDEA access granted Tue Dec 20 22:54:58 2016 : Info: rlm_perl: return RLM_MODULE_OK 22:54:57.623116 IP6 fd23:e163:19f7:1234:5054:ff:fe07:ff5a.39817 > athene.jochen.org.radius: RADIUS, Access-Request (1), id: 0x23 length: 134 22:54:58.778278 IP6 athene.jochen.org.radius > fd23:e163:19f7:1234:5054:ff:fe07:ff5a.39817: RADIUS, Access-Accept (2), id: 0x23 length: 48 Runtime is quite short and stable, so I'll go mostly back to the default timeouts. I've learned about the following timeouts for RADIUS authentication, every single one can hit you when RADIUS takes a long time (which it souldn't): * sssd has a default kerberos timeout of six seconds. Can be changed in /etc/sssd/sssd.conf: krb5_auth_timeout, which also seems to work for auth_provider = ipa, but is not documented in sssd-ipa(5). * There is a timeout for krb5kdc talking to ipa-otpd. Can be change in /var/kerberos/krb5kdc/kdc.conf with: [otp] DEFAULT = { timeout = 15 retries = 0 strip_realm = false } * In IPA there is also a radius-timeout which can be changed in the webui or with "ipa radiusproxy-mod --timeout=INT" I found it quite challenging to wrap my head around the hole process from PAM/SSS/KRB5/IPA-OTPD to FreeRADIUS/privacyidea, but now I'm quite happy with what I've learned. Thanks for you help. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From abokovoy at redhat.com Tue Dec 20 22:43:40 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 21 Dec 2016 00:43:40 +0200 Subject: [Freeipa-users] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server In-Reply-To: <83wpeuz0xw.fsf@echidna.jochen.org> References: <83shpm1b73.fsf@echidna.jochen.org> <20161218092725.gmsznodxdrwhjgbt@redhat.com> <83oa091qks.fsf@echidna.jochen.org> <20161218103332.ipv3v7u3rarduyyu@redhat.com> <83wpeuz0xw.fsf@echidna.jochen.org> Message-ID: <20161220224340.qf74cbvdn7kujy2s@redhat.com> On ti, 20 joulu 2016, Jochen Hein wrote: >Alexander Bokovoy writes: > >>>1. KDC to ipa-otd: this can be changed in >>>/var/kerberos/krb5kdc/kdc.conf. I think the timeout should be larger >>>then the (largest) second timeout - and I think retries=0 is best. >>>This is for communication between KDC and ipa-otd. >>> >>>2. There is a timeout in each RADIUS server config in IPA for the >>>communication from ipa-otp to external RADIUS servers: >>>`---- >>>Again I think that for OTPs we are probably best with retries=0. >>> >>>On older clients it might be helpful to add "udp_preference_limit = 0" >>>to /etc/krb5.conf - at least on my Debian/Ubuntu machines. > >> Ok. It would probably make sense to file a ticket to FreeIPA tracker to >> get these changes in FreeIPA 4.5. > >I think I've won my fight... Here's what I've learned. The short story is >that probably no timeout should be changed. Shall I still file a ticket >concerning retry counts? > >Authentication of IPA users against RADIUS were mostly failing, but >not always. There were hints about timeouts almost everywhere. >Multiple authentication requests from kerberos, timeouts from sssd, >but that should have sent me on the right track from the start: > >Dec 19 22:11:51 freeipa1 ipa-otpd: LDAP: ldapi://%2Fvar%2Frun%2Fslapd-JOCHEN-ORG.socket >Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: request received >Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: user query start >Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: user query end: uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org >Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: radius query start: cn=athene,cn=radiusproxy,dc=jochen,dc=org >Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: radius query end: athene.jochen.org >Dec 19 22:11:51 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: forward start: jkellner at jochen.org / athene.jochen.org >Dec 19 22:12:01 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: forward end: Connection timed out >Dec 19 22:12:01 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: response sent: Access-Reject > >or: > >Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: request received >Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: user query start >Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: user query end: uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org >Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: radius query start: cn=athene,cn=radiusproxy,dc=jochen,dc=org >Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: radius query end: athene.jochen.org >Dec 20 22:40:23 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: forward start: jkellner at jochen.org / athene.jochen.org >Dec 20 22:40:31 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: forward end: Access-Accept >Dec 20 22:40:31 freeipa1 ipa-otpd: jkellner at JOCHEN.ORG: response sent: Access-Accept > >Why is there such a long delay? The Log of the RADIUS server has: > >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Config File /opt/privacyIDEA/rlm_perl.ini found! >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Debugging config: true >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Default URL https://athene.jochen.org/validate/check >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Looking for config for auth-type Perl >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: Auth-Type: Perl >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: url: https://athene.jochen.org/validate/check >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: user sent to privacyidea: jkellner at jochen.org >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: realm sent to privacyidea: jochen.org >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: resolver sent to privacyidea: >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: client sent to privacyidea: 192.168.30.121 >Tue Dec 20 22:40:30 2016 : Info: rlm_perl: state sent to privacyidea: >Tue Dec 20 22:40:31 2016 : Info: rlm_perl: privacyIDEA access granted >Tue Dec 20 22:40:31 2016 : Info: rlm_perl: return RLM_MODULE_OK > >So RADIUS thinks, it got a request a 30 seconds, but why did we wait so long? >I took a tcpdump and saw: > >22:40:23.364355 IP6 freeipa1.jochen.org.41198 > athene.jochen.org.radius: RADIUS, Access-Request (1), id: 0x10 length: 134 >22:40:30.872136 IP freeipa1.jochen.org.44314 > athene.jochen.org.radius: RADIUS, Access-Request (1), id: 0x9c length: 134 >22:40:31.572217 IP athene.jochen.org.radius > freeipa1.jochen.org.44314: RADIUS, Access-Accept (2), id: 0x9c length: 48 > >So, we received an IPv6 packet, but didn't react. Some seconds later IPA-OTP >retried with IPv4 and succeeded. A quick check showed that freeradius >did not listen on IPv6. After fixing that, a request looks like this: > >Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: request received >Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: user query start >Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: user query end: uid=jkellner,cn=users,cn=accounts,dc=jochen,dc=org >Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: radius query start: cn=athene,cn=radiusproxy,dc=jochen,dc=org >Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: radius query end: athene.jochen.org >Dec 20 22:54:57 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: forward start: jkellner at jochen.org / athene.jochen.org >Dec 20 22:54:58 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: forward end: Access-Accept >Dec 20 22:54:58 freeipa2 ipa-otpd: jkellner at JOCHEN.ORG: response sent: Access-Accept > >and > >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: Config File /opt/privacyIDEA/rlm_perl.ini found! >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: Debugging config: true >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: Default URL https://athene.jochen.org/validate/check >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: Looking for config for auth-type Perl >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: Auth-Type: Perl >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: url: https://athene.jochen.org/validate/check >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: user sent to privacyidea: jkellner at jochen.org >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: realm sent to privacyidea: jochen.org >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: resolver sent to privacyidea: >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: client sent to privacyidea: >Tue Dec 20 22:54:57 2016 : Info: rlm_perl: state sent to privacyidea: >Tue Dec 20 22:54:58 2016 : Info: rlm_perl: privacyIDEA access granted >Tue Dec 20 22:54:58 2016 : Info: rlm_perl: return RLM_MODULE_OK > >22:54:57.623116 IP6 fd23:e163:19f7:1234:5054:ff:fe07:ff5a.39817 > athene.jochen.org.radius: RADIUS, Access-Request (1), id: 0x23 length: 134 >22:54:58.778278 IP6 athene.jochen.org.radius > fd23:e163:19f7:1234:5054:ff:fe07:ff5a.39817: RADIUS, Access-Accept (2), id: 0x23 length: 48 > >Runtime is quite short and stable, so I'll go mostly back to the default timeouts. This is a great investigative work, thanks! >I've learned about the following timeouts for RADIUS authentication, >every single one can hit you when RADIUS takes a long time (which it souldn't): > >* sssd has a default kerberos timeout of six seconds. > Can be changed in /etc/sssd/sssd.conf: krb5_auth_timeout, > which also seems to work for auth_provider = ipa, but is not > documented in sssd-ipa(5). sssd-ipa(5) says: -------- The IPA provider accepts the same options used by the sssd-ldap(5) identity provider and the sssd-krb5(5) authentication provider with some exceptions described below. -------- I'm not sure how much we could improve here. > >* There is a timeout for krb5kdc talking to ipa-otpd. > Can be change in /var/kerberos/krb5kdc/kdc.conf with: >[otp] > DEFAULT = { > timeout = 15 > retries = 0 > strip_realm = false > } > >* In IPA there is also a radius-timeout which can be changed in the webui > or with "ipa radiusproxy-mod --timeout=INT" > >I found it quite challenging to wrap my head around the hole process >from PAM/SSS/KRB5/IPA-OTPD to FreeRADIUS/privacyidea, but now I'm quite >happy with what I've learned. It would be good to write an article on the wiki that covers privacyidea integration and explains the workflow. Technically, we have most of Kerberos client (SSS) -> KDC -> IPA-OTPD -> FreeRADIUS covered in http://www.freeipa.org/page/V4/OTP and http://www.freeipa.org/page/V4/OTP/Detail, but they lack timeouts description. -- / Alexander Bokovoy From jochen at jochen.org Tue Dec 20 23:02:50 2016 From: jochen at jochen.org (Jochen Hein) Date: Wed, 21 Dec 2016 00:02:50 +0100 Subject: [Freeipa-users] Valid Sender ? - Re: ipa-otpd: timeout from kerberos when talking to an external 'slow' RADIUS server In-Reply-To: <20161220224340.qf74cbvdn7kujy2s@redhat.com> (Alexander Bokovoy's message of "Wed, 21 Dec 2016 00:43:40 +0200") References: <83shpm1b73.fsf@echidna.jochen.org> <20161218092725.gmsznodxdrwhjgbt@redhat.com> <83oa091qks.fsf@echidna.jochen.org> <20161218103332.ipv3v7u3rarduyyu@redhat.com> <83wpeuz0xw.fsf@echidna.jochen.org> <20161220224340.qf74cbvdn7kujy2s@redhat.com> Message-ID: <83shpiyzj9.fsf@echidna.jochen.org> Alexander Bokovoy writes: >>* sssd has a default kerberos timeout of six seconds. >> Can be changed in /etc/sssd/sssd.conf: krb5_auth_timeout, >> which also seems to work for auth_provider = ipa, but is not >> documented in sssd-ipa(5). > sssd-ipa(5) says: > -------- > The IPA provider accepts the same options used by the > sssd-ldap(5) identity provider and the sssd-krb5(5) > authentication provider with some exceptions described > below. > -------- > > I'm not sure how much we could improve here. I just scanned the option list and did not read the complete text. > It would be good to write an article on the wiki that covers privacyidea > integration and explains the workflow. Cornelius from Privacyidea already asked me for this, but I first wanted to get something stable and useful running. Now it looks like that is done I'll try to write something up. > Technically, we have most of > Kerberos client (SSS) -> KDC -> IPA-OTPD -> FreeRADIUS covered in > http://www.freeipa.org/page/V4/OTP and > http://www.freeipa.org/page/V4/OTP/Detail, but they lack timeouts > description. Yes, these pages helped my a lot. Jochen -- The only problem with troubleshooting is that the trouble shoots back. From ianchen.op at gmail.com Wed Dec 21 04:11:40 2016 From: ianchen.op at gmail.com (Ian Chen) Date: Wed, 21 Dec 2016 12:11:40 +0800 Subject: [Freeipa-users] freeipa 4.1 replication conflict resolve issue Message-ID: hello list, I tried to search for answer, but not solution come up yet. please help. the setup with multiple nodes has IPA version: ipa-server-4.1.0-18.el7.centos.4.x86_64 after adding a replication with an old node, replicaiton conflict occured. ---- node104 dn: nsuniqueid=5820a804-af9211e6-bbce8d9c-0794b841+uid=test2,cn=users,cn=acco unts,dc=... uid: test2 nsds5ReplConflict: namingConflict uid=test2,cn=users,cn=accounts,dc=... krbPrincipalName: test2 at ... krbLastPwdChange: 20161220054653Z krbPasswordExpiration: 20170320054653Z ipaUniqueID: 606b2260-af92-11e6-a928-0050568faf9d ---- node203 dn: uid=test2,cn=users,cn=accounts,dc=... uid: test2 krbPrincipalName: test2 at ... krbLastPwdChange: 20161220054653Z krbPasswordExpiration: 20170320054653Z ipaUniqueID: 606b2260-af92-11e6-a928-0050568faf9d I tried rename RDN following this https://mkosek.fedorapeople.org/publican_site/en-US/FreeIPA/3.4/html/FreeIPA_Guide/ipa-replica-manage.html but when trying to delete uid, then change RDN back to uid, there is this error modifying entry "cn=TempValue,cn=users,cn=accounts,dc=..." ldap_modify: Object class violation (65) additional info: missing attribute "uid" required by object class "posixAccount" I cannot delete object class posixAccount then add it back -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Dec 21 07:24:19 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 Dec 2016 08:24:19 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <1482234065.28211.55.camel@interlinx.bc.ca> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> Message-ID: <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> On 20.12.2016 12:41, Brian J. Murrell wrote: > On Tue, 2016-12-20 at 11:55 +0100, Martin Basti wrote: >> >> So there are actually no issues with credentials, it needs more >> debugging, in past we have similar case but we haven't found the >> root >> cause why it doesn't have the right credentials after kinit. > > So, to be clear, all I did was kinit. I didn't do anything after that > once the credentials were acquired. Should I have or did you just want > me to test that credential file was usable? I did that as root. > Here's the permissions on that keytab just in case there is a problem > there: > > # ls -lZ /etc/ipa/dnssec/ipa-dnskeysyncd.keytab > -r--r-----. root ods unconfined_u:object_r:etc_t:s0 /etc/ipa/dnssec/ipa-dnskeysyncd.keytab > > restorecon says that the selinux labels are ok. The file is not in the > RPM (i.e. as a config file) so I have no reference for the permissions > of it. > >> Are you >> willing to do more basic level code debugging? > > Absolutely. > >> BTW this is used only with DNSSEC feature. I you don't use DNSSEC >> signing you can ignore this failing service (ipactl start >> --ignore-service-failures) > > Let's also not lose sight of the other problem that occurred at the > same upgrade and that's the having to fall back to simple > authentication of bind with: > > arg "auth_method simple"; > arg "bind_dn uid=admin,cn=users,cn=accounts,dc=example.com"; > arg "password my_password"; > > in /etc/named.conf due to: > > 21:12:19 LDAP error: Invalid credentials: bind to LDAP server failed > > trying to start bind via systemctl start ipa. > > Is it most likely that these two problems are in fact not related? I guess that they are related because it is basically the very same problem. The keytab does not work when used from the server application. The question is: Why is that? You can try to add line KRB5_TRACE=/dev/stdout to /etc/sysconfig/ipa-dnskeysyncd and see if there will be some additional information in the the journal. Maybe you will have to use path like /var/lib/ipa/dnssec/debug.log instead of /dev/stderr and then look into the new file. -- Petr^2 Spacek From bentech4you at gmail.com Wed Dec 21 07:24:51 2016 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 21 Dec 2016 10:24:51 +0300 Subject: [Freeipa-users] Sudo rule implementation In-Reply-To: <20161220112445.uvcxknf7dt6ketfm@hendrix> References: <20161220112445.uvcxknf7dt6ketfm@hendrix> Message-ID: HI, thanks for your information. I have validated logs. i destroyed the current kerberos ticket and re-initiated, then the issue solved. Regards, Ben On Tue, Dec 20, 2016 at 2:24 PM, Jakub Hrozek wrote: > On Tue, Dec 20, 2016 at 01:19:15PM +0300, Ben .T.George wrote: > > Hi List, > > > > please help me to implement sudo rules. > > > > i have did below steps and still not working for me. > > > > 1. created "Sudo Command Groups" > > 2. Added some command (/bin/yum) and included in sudo group > > 3. created "sudo Rule" on that > > * added sudo Option as "!authenticate" > > * Added User Group. > > * Added one Host > > * And under Run command, selected the Sudo Rule Group. > > 4. entry on nsswitch.conf : sudoers: files sss > > 5. entry on sssd.conf : services = nss, sudo, pam, ssh > > > > and i tried removing "!authenticate" and changed to Anyone, Any Host and > Any > > Command, > > Also under As Whom to Anyone and Any Group > > - I tried logout and login again on client with IPA user which is member > of > > user group. > > > > When i am running yum, getting error that user is not allowed to execute > > command. > > > > > > Please anyone help to correct my steps. > > > > Regards > > Ben > > Please follow: > https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO > especially the sudo logs are often helpful to see what rules is sssd > returning to sudo. > > -- > Manage your subscription for 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 mbasti at redhat.com Wed Dec 21 09:39:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 21 Dec 2016 10:39:29 +0100 Subject: [Freeipa-users] [PTO] 2016-12-21 -- 2017-01-02 Message-ID: Merry Christmas and Happy New Year 2017 Martin From nirajkumar.singh at accenture.com Wed Dec 21 09:39:29 2016 From: nirajkumar.singh at accenture.com (nirajkumar.singh at accenture.com) Date: Wed, 21 Dec 2016 09:39:29 +0000 Subject: [Freeipa-users] FreeIPA User Authorization Guidelines Required In-Reply-To: <5e9e7cea-aaf5-44dd-21ef-ced44b4f7b08@redhat.com> References: <56954719c90c4e2d88fd89ba428dabba@BLUPR42MB0194.048d.mgd.msft.net> <5e9e7cea-aaf5-44dd-21ef-ced44b4f7b08@redhat.com> Message-ID: Hi Petr, Is there any way to automatically create .PPK and Public ssh key for new users created? Thanks, Niraj Kumar -----Original Message----- From: Petr Vobornik [mailto:pvoborni at redhat.com] Sent: 20 December 2016 16:40 To: Singh, NirajKumar ; freeipa-users at redhat.com Cc: Morikawa, Hirofumi Subject: Re: [Freeipa-users] FreeIPA User Authorization Guidelines Required On 12/20/2016 10:58 AM, nirajkumar.singh at accenture.com wrote: > Hi FreeIPA Team, > > We have performed installation of FreeIPA Master Server and Client > Server. We are successful with user creation with home directory and sudo configuration. > > Regarding Authentication we have some questions: > > 1.Can we implement authorized key authentication for these servers. Is > there any way in FreeIPA we can automate the ppk key generation for each individual user? FreeIPA/IdM supports central management of public SSH keys: https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2DUS_Red-5FHat-5FEnterprise-5FLinux_7_html_Linux-5FDomain-5FIdentity-5FAuthentication-5Fand-5FPolicy-5FGuide_user-2Dkeys.html&d=DgIC-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=J_tjNpkwndknzRvQ2_H1bSGILs8ve3v6B5UQit18NC0&m=tfQVRIRjW-wT95LvX5PLzw9edRibMixUTKVUIIwijLE&s=ldieGGgCFsQtjTOIEa7mxR1OkAz88yCH_8Pw_lbwyhw&e= > > 2.If Not Automated key generation what are the possible ways for more > secured authentication other than password authentication? It supports Two Factor Authentication via integrated OTP support or third party RADIUS server: OTP: https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2DUS_Red-5FHat-5FEnterprise-5FLinux_7_html_Linux-5FDomain-5FIdentity-5FAuthentication-5Fand-5FPolicy-5FGuide_otp.html&d=DgIC-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=J_tjNpkwndknzRvQ2_H1bSGILs8ve3v6B5UQit18NC0&m=tfQVRIRjW-wT95LvX5PLzw9edRibMixUTKVUIIwijLE&s=nPIf9X-15LZzI5un06oWEsFYIkL8kU2LcxbsS4G6JyU&e= RADIUS proxy: https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2DUS_Red-5FHat-5FEnterprise-5FLinux_7_html_Linux-5FDomain-5FIdentity-5FAuthentication-5Fand-5FPolicy-5FGuide_otp.html-23migrating-2Dproprietary-2Dotp&d=DgIC-g&c=eIGjsITfXP_y-DLLX0uEHXJvU8nOHrUK8IrwNKOtkVU&r=J_tjNpkwndknzRvQ2_H1bSGILs8ve3v6B5UQit18NC0&m=tfQVRIRjW-wT95LvX5PLzw9edRibMixUTKVUIIwijLE&s=2BLd2lichlzyifLuvJw2eNEtVghd0SYlGtO9P2vxsCk&e= > > Thanks and Regards, > > Niraj Kumar Singh > > Mobile: +91-9663212985 > > Email: nirajkumar.singh at accenture.com > > > > ---------------------------------------------------------------------- > ---------- > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise confidential information. If you > have received it in error, please notify the sender immediately and > delete the original. Any other use of the e-mail by you is prohibited. > Where allowed by local law, electronic communications with Accenture > and its affiliates, including e-mail and instant messaging (including > content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. > ______________________________________________________________________ > ________________ > > www.accenture.com > > > -- Petr Vobornik ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com From lkrispen at redhat.com Wed Dec 21 11:08:08 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 21 Dec 2016 12:08:08 +0100 Subject: [Freeipa-users] freeipa 4.1 replication conflict resolve issue In-Reply-To: References: Message-ID: <585A6298.5060901@redhat.com> On 12/21/2016 05:11 AM, Ian Chen wrote: > hello list, > > I tried to search for answer, but not solution come up yet. please help. > > the setup with multiple nodes has IPA version: > ipa-server-4.1.0-18.el7.centos.4.x86_64 > > > after adding a replication with an old node, replicaiton conflict occured. > > ---- node104 > dn: > nsuniqueid=5820a804-af9211e6-bbce8d9c-0794b841+uid=test2,cn=users,cn=acco > unts,dc=... > uid: test2 > nsds5ReplConflict: namingConflict uid=test2,cn=users,cn=accounts,dc=... > krbPrincipalName: test2 at ... > krbLastPwdChange: 20161220054653Z > krbPasswordExpiration: 20170320054653Z > ipaUniqueID: 606b2260-af92-11e6-a928-0050568faf9d > > > ---- node203 > dn: uid=test2,cn=users,cn=accounts,dc=... > uid: test2 > krbPrincipalName: test2 at ... > krbLastPwdChange: 20161220054653Z > krbPasswordExpiration: 20170320054653Z > ipaUniqueID: 606b2260-af92-11e6-a928-0050568faf9d > > > I tried rename RDN following this > https://mkosek.fedorapeople.org/publican_site/en-US/FreeIPA/3.4/html/FreeIPA_Guide/ipa-replica-manage.html > > but when trying to delete uid, then change RDN back to uid, there is > this error > > modifying entry "cn=TempValue,cn=users,cn=accounts,dc=..." > ldap_modify: Object class violation (65) > additional info: missing attribute "uid" required by object class > "posixAccount" > > I cannot delete object class posixAccount then add it back I cannot see which commands you really tried to execute and failed, so could you provide the full log of what you did if you want to follow the steps in the IPA doc. But I do not think that you need to go thru the MOD/MODRDN/... sequence if you do not want to keep both entries. If a conflict arises, one entry keeps the original dn, the other gets a dn with "nsuniquid=....+..." and the nsds5ReplConflict attribute. you can check the entries and inmost cases you just want to keep the "original" and just delete the conflict entry > > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at interlinx.bc.ca Wed Dec 21 12:05:07 2016 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Wed, 21 Dec 2016 07:05:07 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> Message-ID: <1482321907.28211.102.camel@interlinx.bc.ca> On Wed, 2016-12-21 at 08:24 +0100, Petr Spacek wrote: > > You can try to add line > KRB5_TRACE=/dev/stdout > to > /etc/sysconfig/ipa-dnskeysyncd [27472] 1482320667.240500: Retrieving ipa-dnskeysyncd/server.example.com at EXAMPLE.COM from FILE:/etc/ipa/dnssec/ipa-dnskeysyncd.keytab (vno 0, enctype 0) with result: 0/Success [27472] 1482320667.240567: Getting initial credentials for ipa-dnskeysyncd/server.example.com at EXAMPLE.COM [27472] 1482320667.241542: Looked up etypes in keytab: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts [27472] 1482320667.241619: Sending request (207 bytes) to EXAMPLE.COM [27472] 1482320667.241952: Resolving hostname server.example.com [27472] 1482320667.242781: Initiating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.243067: Sending TCP request to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.248018: Received answer (336 bytes) from stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.248054: Terminating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.248215: Response was from master KDC [27472] 1482320667.248250: Received error from KDC: -1765328359/Additional pre-authentication required [27472] 1482320667.248304: Processing preauth types: 136, 19, 2, 133 [27472] 1482320667.248317: Selected etype info: etype aes256-cts, salt "EXAMPLE.COMipa-dnskeysyncdserver.example.com", params "" [27472] 1482320667.248327: Received cookie: MIT [27472] 1482320667.248400: Retrieving ipa-dnskeysyncd/server.example.com at EXAMPLE.COM from FILE:/etc/ipa/dnssec/ipa-dnskeysyncd.keytab (vno 0, enctype aes256-cts) with result: 0/Success [27472] 1482320667.248424: AS key obtained for encrypted timestamp: aes256-cts/BCCF [27472] 1482320667.248498: Encrypted timestamp (for 1482320667.247961): plain [redacted], encrypted [redacted] [27472] 1482320667.248512: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [27472] 1482320667.248520: Produced preauth for next request: 133, 2 [27472] 1482320667.248540: Sending request (302 bytes) to EXAMPLE.COM [27472] 1482320667.248561: Resolving hostname server.example.com [27472] 1482320667.248841: Initiating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.249050: Sending TCP request to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.512953: Received answer (837 bytes) from stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.512974: Terminating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.513076: Response was from master KDC [27472] 1482320667.513117: Processing preauth types: 19 [27472] 1482320667.513131: Selected etype info: etype aes256-cts, salt "EXAMPLE.COMipa-dnskeysyncdserver.example.com", params "" [27472] 1482320667.513143: Produced preauth for next request: (empty) [27472] 1482320667.513159: AS key determined by preauth: aes256-cts/BCCF [27472] 1482320667.513244: Decrypted AS reply; session key is: aes256-cts/BD92 [27472] 1482320667.513271: FAST negotiation: available [27472] 1482320667.513297: Initializing FILE:/tmp/ipa-dnskeysyncd.ccache with default princ ipa-dnskeysyncd/server.example.com at EXAMPLE.COM [27472] 1482320667.513881: Storing ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krbtgt/EXAMPLE.COM at EXAMPLE.COM in FILE:/tmp/ipa-dnskeysyncd.ccache [27472] 1482320667.513974: Storing config in FILE:/tmp/ipa-dnskeysyncd.ccache for krbtgt/EXAMPLE.COM at EXAMPLE.COM: fast_avail: yes [27472] 1482320667.514022: Storing ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.COM\@EXAMPLE.COM at X-CACHECONF: in FILE:/tmp/ipa-dnskeysyncd.ccache [27472] 1482320667.514065: Storing config in FILE:/tmp/ipa-dnskeysyncd.ccache for krbtgt/EXAMPLE.COM at EXAMPLE.COM: pa_type: 2 [27472] 1482320667.514102: Storing ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.COM\@EXAMPLE.COM at X-CACHECONF: in FILE:/tmp/ipa-dnskeysyncd.ccache [27472] 1482320667.514181: Storing config in FILE:/tmp/ipa-dnskeysyncd.ccache for : refresh_time: 1482363867 [27472] 1482320667.514220: Storing ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time at X-CACHECONF: in FILE:/tmp/ipa-dnskeysyncd.ccache [27472] 1482320667.619828: ccselect module realm chose cache FILE:/tmp/ipa-dnskeysyncd.ccache with client principal ipa-dnskeysyncd/server.example.com at EXAMPLE.COM for server principal ldap/server.example.com at EXAMPLE.COM [27472] 1482320667.692119: Getting credentials ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM using ccache FILE:/tmp/ipa-dnskeysyncd.ccache [27472] 1482320667.692241: Retrieving ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM from FILE:/tmp/ipa-dnskeysyncd.ccache with result: -1765328243/Matching credential not found (filename: /tmp/ipa-dnskeysyncd.ccache) [27472] 1482320667.692330: Retrieving ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krbtgt/EXAMPLE.COM at EXAMPLE.COM from FILE:/tmp/ipa-dnskeysyncd.ccache with result: 0/Success [27472] 1482320667.692342: Starting with TGT for client realm: ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krbtgt/EXAMPLE.COM at EXAMPLE.COM [27472] 1482320667.692350: Requesting tickets for ldap/server.example.com at EXAMPLE.COM, referrals on [27472] 1482320667.692383: Generated subkey for TGS request: aes256-cts/60D5 [27472] 1482320667.692436: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts [27472] 1482320667.692530: Encoding request body and padata into FAST request [27472] 1482320667.692611: Sending request (1023 bytes) to EXAMPLE.COM [27472] 1482320667.692799: Resolving hostname server.example.com [27472] 1482320667.693065: Initiating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.693299: Sending TCP request to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.697728: Received answer (973 bytes) from stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.697748: Terminating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 [27472] 1482320667.697849: Response was from master KDC [27472] 1482320667.697879: Decoding FAST response [27472] 1482320667.698004: FAST reply key: aes256-cts/03A5 [27472] 1482320667.698103: TGS reply is for ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM with session key aes256-cts/F2D7 [27472] 1482320667.698130: TGS request result: 0/Success [27472] 1482320667.698138: Received creds for desired service ldap/server.example.com at EXAMPLE.COM [27472] 1482320667.698150: Storing ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM in FILE:/tmp/ipa-dnskeysyncd.ccache [27472] 1482320667.698320: Creating authenticator for ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM, seqnum 370535193, subkey aes256-cts/D075, session key aes256-cts/F2D7 The only thing I see there that is concerning is: [27472] 1482320667.692241: Retrieving ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM from FILE:/tmp/ipa-dnskeysyncd.ccache with result: -1765328243/Matching credential not found (filename: /tmp/ipa-dnskeysyncd.ccache) Is that the problem? Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From sjuhasz at chemaxon.com Wed Dec 21 13:07:08 2016 From: sjuhasz at chemaxon.com (Sandor Juhasz) Date: Wed, 21 Dec 2016 14:07:08 +0100 (CET) Subject: [Freeipa-users] modify schema - add group email and display attribute Message-ID: <795612095.18818.1482325628676.JavaMail.zimbra@chemaxon.com> Hi, i would like to modify schema to have group objects extended with email and display name attribute. The reason is that we are trying to sync our ldap to our google apps. I don't know how much this doc http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf can be applied to groups. Neither did i find a supported attribute syntax for email, maybe PrintableString 1.3.6.1.4.1.1466.115.121.1.58 For values which contain strings containing alphabetic, numeral, and select punctuation characters (as defined in RFC 4517 ). but i am not sure if that could hold email addresses. It would be pretty to have it exposed via ipalib and js plugins as well. If someone could help me out on extending schema, i would be really happy. S?ndor Juh?sz System Administrator ChemAxon Ltd . Building Hx, GraphiSoft Park, Z?hony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Dec 21 14:04:01 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 Dec 2016 15:04:01 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <1482321907.28211.102.camel@interlinx.bc.ca> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> <1482321907.28211.102.camel@interlinx.bc.ca> Message-ID: On 21.12.2016 13:05, Brian J. Murrell wrote: > On Wed, 2016-12-21 at 08:24 +0100, Petr Spacek wrote: >> >> You can try to add line >> KRB5_TRACE=/dev/stdout >> to >> /etc/sysconfig/ipa-dnskeysyncd > > [27472] 1482320667.240500: Retrieving ipa-dnskeysyncd/server.example.com at EXAMPLE.COM from FILE:/etc/ipa/dnssec/ipa-dnskeysyncd.keytab (vno 0, enctype 0) with result: 0/Success > [27472] 1482320667.240567: Getting initial credentials for ipa-dnskeysyncd/server.example.com at EXAMPLE.COM > [27472] 1482320667.241542: Looked up etypes in keytab: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts > [27472] 1482320667.241619: Sending request (207 bytes) to EXAMPLE.COM > [27472] 1482320667.241952: Resolving hostname server.example.com > [27472] 1482320667.242781: Initiating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.243067: Sending TCP request to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.248018: Received answer (336 bytes) from stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.248054: Terminating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.248215: Response was from master KDC > [27472] 1482320667.248250: Received error from KDC: -1765328359/Additional pre-authentication required > [27472] 1482320667.248304: Processing preauth types: 136, 19, 2, 133 > [27472] 1482320667.248317: Selected etype info: etype aes256-cts, salt "EXAMPLE.COMipa-dnskeysyncdserver.example.com", params "" > [27472] 1482320667.248327: Received cookie: MIT > [27472] 1482320667.248400: Retrieving ipa-dnskeysyncd/server.example.com at EXAMPLE.COM from FILE:/etc/ipa/dnssec/ipa-dnskeysyncd.keytab (vno 0, enctype aes256-cts) with result: 0/Success > [27472] 1482320667.248424: AS key obtained for encrypted timestamp: aes256-cts/BCCF > [27472] 1482320667.248498: Encrypted timestamp (for 1482320667.247961): plain [redacted], encrypted [redacted] > [27472] 1482320667.248512: Preauth module encrypted_timestamp (2) (real) returned: 0/Success > [27472] 1482320667.248520: Produced preauth for next request: 133, 2 > [27472] 1482320667.248540: Sending request (302 bytes) to EXAMPLE.COM > [27472] 1482320667.248561: Resolving hostname server.example.com > [27472] 1482320667.248841: Initiating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.249050: Sending TCP request to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.512953: Received answer (837 bytes) from stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.512974: Terminating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.513076: Response was from master KDC > [27472] 1482320667.513117: Processing preauth types: 19 > [27472] 1482320667.513131: Selected etype info: etype aes256-cts, salt "EXAMPLE.COMipa-dnskeysyncdserver.example.com", params "" > [27472] 1482320667.513143: Produced preauth for next request: (empty) > [27472] 1482320667.513159: AS key determined by preauth: aes256-cts/BCCF > [27472] 1482320667.513244: Decrypted AS reply; session key is: aes256-cts/BD92 > [27472] 1482320667.513271: FAST negotiation: available > [27472] 1482320667.513297: Initializing FILE:/tmp/ipa-dnskeysyncd.ccache with default princ ipa-dnskeysyncd/server.example.com at EXAMPLE.COM > [27472] 1482320667.513881: Storing ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krbtgt/EXAMPLE.COM at EXAMPLE.COM in FILE:/tmp/ipa-dnskeysyncd.ccache > [27472] 1482320667.513974: Storing config in FILE:/tmp/ipa-dnskeysyncd.ccache for krbtgt/EXAMPLE.COM at EXAMPLE.COM: fast_avail: yes > [27472] 1482320667.514022: Storing ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.COM\@EXAMPLE.COM at X-CACHECONF: in FILE:/tmp/ipa-dnskeysyncd.ccache > [27472] 1482320667.514065: Storing config in FILE:/tmp/ipa-dnskeysyncd.ccache for krbtgt/EXAMPLE.COM at EXAMPLE.COM: pa_type: 2 > [27472] 1482320667.514102: Storing ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.COM\@EXAMPLE.COM at X-CACHECONF: in FILE:/tmp/ipa-dnskeysyncd.ccache > [27472] 1482320667.514181: Storing config in FILE:/tmp/ipa-dnskeysyncd.ccache for : refresh_time: 1482363867 > [27472] 1482320667.514220: Storing ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krb5_ccache_conf_data/refresh_time at X-CACHECONF: in FILE:/tmp/ipa-dnskeysyncd.ccache > [27472] 1482320667.619828: ccselect module realm chose cache FILE:/tmp/ipa-dnskeysyncd.ccache with client principal ipa-dnskeysyncd/server.example.com at EXAMPLE.COM for server principal ldap/server.example.com at EXAMPLE.COM > [27472] 1482320667.692119: Getting credentials ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM using ccache FILE:/tmp/ipa-dnskeysyncd.ccache > [27472] 1482320667.692241: Retrieving ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM from FILE:/tmp/ipa-dnskeysyncd.ccache with result: -1765328243/Matching credential not found (filename: /tmp/ipa-dnskeysyncd.ccache) > [27472] 1482320667.692330: Retrieving ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krbtgt/EXAMPLE.COM at EXAMPLE.COM from FILE:/tmp/ipa-dnskeysyncd.ccache with result: 0/Success > [27472] 1482320667.692342: Starting with TGT for client realm: ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> krbtgt/EXAMPLE.COM at EXAMPLE.COM > [27472] 1482320667.692350: Requesting tickets for ldap/server.example.com at EXAMPLE.COM, referrals on > [27472] 1482320667.692383: Generated subkey for TGS request: aes256-cts/60D5 > [27472] 1482320667.692436: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts > [27472] 1482320667.692530: Encoding request body and padata into FAST request > [27472] 1482320667.692611: Sending request (1023 bytes) to EXAMPLE.COM > [27472] 1482320667.692799: Resolving hostname server.example.com > [27472] 1482320667.693065: Initiating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.693299: Sending TCP request to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.697728: Received answer (973 bytes) from stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.697748: Terminating TCP connection to stream fd31:aeb1:48df:0:214:d1ff:fe13:45ac:88 > [27472] 1482320667.697849: Response was from master KDC > [27472] 1482320667.697879: Decoding FAST response > [27472] 1482320667.698004: FAST reply key: aes256-cts/03A5 > [27472] 1482320667.698103: TGS reply is for ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM with session key aes256-cts/F2D7 > [27472] 1482320667.698130: TGS request result: 0/Success > [27472] 1482320667.698138: Received creds for desired service ldap/server.example.com at EXAMPLE.COM > [27472] 1482320667.698150: Storing ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM in FILE:/tmp/ipa-dnskeysyncd.ccache > [27472] 1482320667.698320: Creating authenticator for ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM, seqnum 370535193, subkey aes256-cts/D075, session key aes256-cts/F2D7 > > The only thing I see there that is concerning is: > > [27472] 1482320667.692241: Retrieving ipa-dnskeysyncd/server.example.com at EXAMPLE.COM -> ldap/server.example.com at EXAMPLE.COM from FILE:/tmp/ipa-dnskeysyncd.ccache with result: -1765328243/Matching credential not found (filename: /tmp/ipa-dnskeysyncd.ccache) > > Is that the problem? No, this is fine. It just shows that the credential was not found in credentials cache. The next part of the log shows that the code goes not and retrieves fresh credential from KDC and stores it into the credentials cache. So, the Kerberos part certainly works... Next step is to look into access log from LDAP server to see what is logged in there. Please look into /var/log/dirsrv/slapd-*/access and look for lines concerning ipa-dnskeysyncd/server.example.com at EXAMPLE.COM principal. I'm really curious what you will find out :-) -- Petr^2 Spacek From lkrispen at redhat.com Wed Dec 21 14:34:03 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 21 Dec 2016 15:34:03 +0100 Subject: [Freeipa-users] modify schema - add group email and display attribute In-Reply-To: <795612095.18818.1482325628676.JavaMail.zimbra@chemaxon.com> References: <795612095.18818.1482325628676.JavaMail.zimbra@chemaxon.com> Message-ID: <585A92DB.5080907@redhat.com> On 12/21/2016 02:07 PM, Sandor Juhasz wrote: > Hi, > > i would like to modify schema to have group objects extended with > email and display name attribute. > The reason is that we are trying to sync our ldap to our google apps. > > I don't know how much this > doc http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf > can be applied to groups. Neither did i find a supported attribute > syntax for email, maybe > PrintableString 1.3.6.1.4.1.1466.115.121.1.58 For values which > contain strings containing alphabetic, numeral, and select punctuation > characters (as defined in RFC 4517 ). > > but i am not sure if that could hold email addresses. why don't you just use the mail attribute ? only define a new auxilliary objectclass allowing mail and displayname > > It would be pretty to have it exposed via ipalib and js plugins as well. > If someone could help me out on extending schema, i would be really happy. > > *S?ndor Juh?sz* > System Administrator > *ChemAxon**Ltd*. > Building Hx, GraphiSoft Park, Z?hony utca 7, Budapest, Hungary, H-1031 > Cell: +36704258964 > > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Wed Dec 21 14:37:03 2016 From: callum.guy at x-on.co.uk (Callum Guy) Date: Wed, 21 Dec 2016 14:37:03 +0000 Subject: [Freeipa-users] IPA Services Message-ID: Hi All, I am looking to find out all the services which FreeIPA has installed and which must be up and running as part of normal operations. I am clear on the various systems which have been installed on the master server (we run no replicas) however I'm not sure what resource I should refer to in order to improve my understanding. To get started on this I have retrieved a list of running services using "systemctl -t service". Our installation is working pretty well and although we have been experiencing the odd stability issue we had believed that this is due to wider platform changes rather than any issues with the installation. In the service list I am seeing lots of duplicate and failed services and it is not clear how to interpret the output and whether this is to be expected? The attached screenshot should explain my question. Can anyone offer any guidance for the severity of this issue? The most pressing question is how/why we have multiple 389 instances for various casings of our domain. The other issue is the large number of OTP service daemons - is that an issue?! Thanks in advance, 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-services-error.PNG Type: image/png Size: 83811 bytes Desc: not available URL: From fay.y.wang at gmail.com Tue Dec 20 19:27:12 2016 From: fay.y.wang at gmail.com (fay wang) Date: Tue, 20 Dec 2016 11:27:12 -0800 Subject: [Freeipa-users] Failed to promote ipa client to ipa replica Message-ID: Hi, I have no luck in promoting ipa client to ipa replica. In my replica system where ipa client is installed: certutil -L -d /etc/dirsrv/slapd-XXXX does not have Server-Cert. Please help! Thanks, fay -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at interlinx.bc.ca Wed Dec 21 14:53:31 2016 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Wed, 21 Dec 2016 09:53:31 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> <1482321907.28211.102.camel@interlinx.bc.ca> Message-ID: <1482332011.25536.2.camel@interlinx.bc.ca> On Wed, 2016-12-21 at 15:04 +0100, Petr Spacek wrote: > > I'm really curious what you will find out :-) It seems to be like this, over and over again: [21/Dec/2016:09:39:02.124732240 -0500] conn=77025 fd=107 slot=107 connection from 10.75.22.1 to 10.75.22.247 [21/Dec/2016:09:39:02.125630906 -0500] conn=77025 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domaincontrollerfunctionality defaultnamingcontext lastusn highestcommittedusn aci" [21/Dec/2016:09:39:02.131312941 -0500] conn=77025 op=0 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.138517633 -0500] conn=75097 op=14926 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=host/pc.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=host/pc.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.140094769 -0500] conn=75097 op=14926 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.140571682 -0500] conn=75097 op=14927 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.140877517 -0500] conn=75097 op=14927 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.141169433 -0500] conn=75097 op=14928 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.142218937 -0500] conn=75097 op=14928 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.142565212 -0500] conn=75097 op=14929 SRCH base="cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [21/Dec/2016:09:39:02.143021565 -0500] conn=75097 op=14929 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.145295331 -0500] conn=75097 op=14930 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=host/pc.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=host/pc.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.146427034 -0500] conn=75097 op=14930 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.146896867 -0500] conn=75097 op=14931 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.147152183 -0500] conn=75097 op=14931 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.147429299 -0500] conn=75097 op=14932 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.148387405 -0500] conn=75097 op=14932 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.148744479 -0500] conn=75097 op=14933 SRCH base="cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [21/Dec/2016:09:39:02.149055795 -0500] conn=75097 op=14933 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.149713865 -0500] conn=75097 op=14934 SRCH base="fqdn=pc.example.com,cn=computers,cn=accounts,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass uid cn fqdn gidNumber krbPrincipalName krbCanonicalName krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbLastAdminUnlock krbTicketFlags ipaNTSecurityIdentifier ipaNTLogonScript ipaNTProfilePath ipaNTHomeDirectory ipaNTHomeDirectoryDrive" [21/Dec/2016:09:39:02.150630331 -0500] conn=75097 op=14934 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.150776369 -0500] conn=75097 op=14935 SRCH base="cn=pc.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [21/Dec/2016:09:39:02.151089444 -0500] conn=75097 op=14935 RESULT err=32 tag=101 nentries=0 etime=0 [21/Dec/2016:09:39:02.151857793 -0500] conn=75097 op=14936 MOD dn="fqdn=pc.example.com,cn=computers,cn=accounts,dc=example,dc=com" [21/Dec/2016:09:39:02.228204527 -0500] conn=75097 op=14936 RESULT err=0 tag=103 nentries=0 etime=0 [21/Dec/2016:09:39:02.232937016 -0500] conn=75097 op=14937 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.234262797 -0500] conn=75097 op=14937 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.235419139 -0500] conn=75097 op=14938 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/server.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=ldap/server.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.236482483 -0500] conn=75097 op=14938 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.236850958 -0500] conn=75097 op=14939 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.237134434 -0500] conn=75097 op=14939 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.237491908 -0500] conn=75097 op=14940 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=host/pc.example.com at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.238406374 -0500] conn=75097 op=14940 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.238753209 -0500] conn=75097 op=14941 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.239000766 -0500] conn=75097 op=14941 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.241077854 -0500] conn=77025 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [21/Dec/2016:09:39:02.248835018 -0500] conn=77025 op=1 RESULT err=49 tag=97 nentries=0 etime=0 - SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied) [21/Dec/2016:09:39:02.249350570 -0500] conn=77025 op=2 UNBIND [21/Dec/2016:09:39:02.249415849 -0500] conn=77025 op=2 fd=107 closed - U1 [21/Dec/2016:09:39:02.281596927 -0500] conn=77026 fd=107 slot=107 connection from 10.75.22.1 to 10.75.22.247 [21/Dec/2016:09:39:02.282507153 -0500] conn=77026 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domaincontrollerfunctionality defaultnamingcontext lastusn highestcommittedusn aci" [21/Dec/2016:09:39:02.288174388 -0500] conn=77026 op=0 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.294448214 -0500] conn=75097 op=14942 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=host/pc.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=host/pc.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.295686515 -0500] conn=75097 op=14942 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.296099469 -0500] conn=75097 op=14943 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.296358585 -0500] conn=75097 op=14943 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.296667021 -0500] conn=75097 op=14944 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.297771804 -0500] conn=75097 op=14944 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.298107679 -0500] conn=75097 op=14945 SRCH base="cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [21/Dec/2016:09:39:02.298422754 -0500] conn=75097 op=14945 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.300721320 -0500] conn=75097 op=14946 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=host/pc.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=host/pc.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.301907262 -0500] conn=75097 op=14946 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.302325296 -0500] conn=75097 op=14947 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.302574052 -0500] conn=75097 op=14947 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.302872847 -0500] conn=75097 op=14948 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.303854233 -0500] conn=75097 op=14948 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.304210307 -0500] conn=75097 op=14949 SRCH base="cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [21/Dec/2016:09:39:02.304517943 -0500] conn=75097 op=14949 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.305142293 -0500] conn=75097 op=14950 SRCH base="fqdn=pc.example.com,cn=computers,cn=accounts,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass uid cn fqdn gidNumber krbPrincipalName krbCanonicalName krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbLastAdminUnlock krbTicketFlags ipaNTSecurityIdentifier ipaNTLogonScript ipaNTProfilePath ipaNTHomeDirectory ipaNTHomeDirectoryDrive" [21/Dec/2016:09:39:02.305858043 -0500] conn=75097 op=14950 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.305969041 -0500] conn=75097 op=14951 SRCH base="cn=pc.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [21/Dec/2016:09:39:02.306251277 -0500] conn=75097 op=14951 RESULT err=32 tag=101 nentries=0 etime=0 [21/Dec/2016:09:39:02.306937826 -0500] conn=75097 op=14952 MOD dn="fqdn=pc.example.com,cn=computers,cn=accounts,dc=example,dc=com" [21/Dec/2016:09:39:02.353106214 -0500] conn=75097 op=14952 RESULT err=0 tag=103 nentries=0 etime=0 [21/Dec/2016:09:39:02.357520588 -0500] conn=75097 op=14953 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.358848568 -0500] conn=75097 op=14953 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.359992071 -0500] conn=75097 op=14954 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/server.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=ldap/server.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.361037295 -0500] conn=75097 op=14954 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.361364090 -0500] conn=75097 op=14955 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.361613606 -0500] conn=75097 op=14955 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.361986521 -0500] conn=75097 op=14956 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=host/pc.example.com at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.362830028 -0500] conn=75097 op=14956 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.363182383 -0500] conn=75097 op=14957 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.363426979 -0500] conn=75097 op=14957 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.365514668 -0500] conn=77026 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [21/Dec/2016:09:39:02.370637191 -0500] conn=77026 op=1 RESULT err=49 tag=97 nentries=0 etime=0 - SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied) [21/Dec/2016:09:39:02.371496018 -0500] conn=77026 op=2 UNBIND [21/Dec/2016:09:39:02.371562337 -0500] conn=77026 op=2 fd=107 closed - U1 [21/Dec/2016:09:39:02.372286766 -0500] conn=77027 fd=107 slot=107 connection from 10.75.22.1 to 10.75.22.247 [21/Dec/2016:09:39:02.382612891 -0500] conn=77027 op=0 SRCH base="" scope=0 filter="(objectClass=*)" attrs="* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domaincontrollerfunctionality defaultnamingcontext lastusn highestcommittedusn aci" [21/Dec/2016:09:39:02.388362885 -0500] conn=77027 op=0 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.395620016 -0500] conn=75098 op=18691 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=host/pc.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=host/pc.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.396899117 -0500] conn=75098 op=18691 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.397309511 -0500] conn=75098 op=18692 SRCH base="cn=ipaConfig,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="ipaConfigString ipaKrbAuthzData ipaUserAuthType" [21/Dec/2016:09:39:02.397602626 -0500] conn=75098 op=18692 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.398124059 -0500] conn=75098 op=18693 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.398370775 -0500] conn=75098 op=18693 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.398813768 -0500] conn=75098 op=18694 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.400461664 -0500] conn=75098 op=18694 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.400695780 -0500] conn=75098 op=18695 SRCH base="cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [21/Dec/2016:09:39:02.402169438 -0500] conn=75098 op=18695 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.403857733 -0500] conn=75097 op=14958 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=host/pc.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=host/pc.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.405165473 -0500] conn=75097 op=14958 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.405692105 -0500] conn=75097 op=14959 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.406007820 -0500] conn=75097 op=14959 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.406323576 -0500] conn=75097 op=14960 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.407464679 -0500] conn=75097 op=14960 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.407948271 -0500] conn=75097 op=14961 SRCH base="cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [21/Dec/2016:09:39:02.408308106 -0500] conn=75097 op=14961 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.409006775 -0500] conn=75097 op=14962 SRCH base="fqdn=pc.example.com,cn=computers,cn=accounts,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass uid cn fqdn gidNumber krbPrincipalName krbCanonicalName krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbLastAdminUnlock krbTicketFlags ipaNTSecurityIdentifier ipaNTLogonScript ipaNTProfilePath ipaNTHomeDirectory ipaNTHomeDirectoryDrive" [21/Dec/2016:09:39:02.409762364 -0500] conn=75097 op=14962 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.409913642 -0500] conn=75097 op=14963 SRCH base="cn=pc.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL [21/Dec/2016:09:39:02.410201917 -0500] conn=75097 op=14963 RESULT err=32 tag=101 nentries=0 etime=0 [21/Dec/2016:09:39:02.411004985 -0500] conn=75097 op=14964 MOD dn="fqdn=pc.example.com,cn=computers,cn=accounts,dc=example,dc=com" [21/Dec/2016:09:39:02.461237272 -0500] conn=75097 op=14964 RESULT err=0 tag=103 nentries=0 etime=0 [21/Dec/2016:09:39:02.465516328 -0500] conn=75097 op=14965 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.466852468 -0500] conn=75097 op=14965 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.467991651 -0500] conn=75097 op=14966 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/server.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=ldap/server.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.469040355 -0500] conn=75097 op=14966 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.469379230 -0500] conn=75097 op=14967 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.469634186 -0500] conn=75097 op=14967 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.470022780 -0500] conn=75097 op=14968 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=host/pc.example.com at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:02.470907487 -0500] conn=75097 op=14968 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.471257082 -0500] conn=75097 op=14969 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:02.471524638 -0500] conn=75097 op=14969 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:02.473712725 -0500] conn=77027 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [21/Dec/2016:09:39:02.478818768 -0500] conn=77027 op=1 RESULT err=49 tag=97 nentries=0 etime=0 - SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied) [21/Dec/2016:09:39:02.479284241 -0500] conn=77027 op=2 UNBIND [21/Dec/2016:09:39:02.479350120 -0500] conn=77027 op=2 fd=107 closed - U1 [21/Dec/2016:09:39:11.861226250 -0500] conn=75097 op=14971 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ipa-dnskeysyncd/server.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=ipa-dnskeysyncd/server.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:11.861921719 -0500] conn=75097 op=14971 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:11.862203634 -0500] conn=75097 op=14972 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:11.862337952 -0500] conn=75097 op=14972 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:11.862512310 -0500] conn=75097 op=14973 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:11.863068501 -0500] conn=75097 op=14973 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:11.863353256 -0500] conn=75097 op=14974 SRCH base="cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [21/Dec/2016:09:39:11.863515653 -0500] conn=75097 op=14974 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:11.865776297 -0500] conn=75097 op=14975 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ipa-dnskeysyncd/server.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=ipa-dnskeysyncd/server.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:11.866325568 -0500] conn=75097 op=14975 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:11.866617004 -0500] conn=75097 op=14976 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:11.866787921 -0500] conn=75097 op=14976 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:11.866964438 -0500] conn=75097 op=14977 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:11.867409671 -0500] conn=75097 op=14977 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:11.867694147 -0500] conn=75097 op=14978 SRCH base="cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [21/Dec/2016:09:39:11.867852224 -0500] conn=75097 op=14978 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:11.868205098 -0500] conn=75097 op=14979 SRCH base="krbprincipalname=ipa-dnskeysyncd/server.example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass uid cn fqdn gidNumber krbPrincipalName krbCanonicalName krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbLastAdminUnlock krbTicketFlags ipaNTSecurityIdentifier ipaNTLogonScript ipaNTProfilePath ipaNTHomeDirectory ipaNTHomeDirectoryDrive" [21/Dec/2016:09:39:11.870079068 -0500] conn=75097 op=14979 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:11.870220706 -0500] conn=75097 op=14980 MOD dn="krbprincipalname=ipa-dnskeysyncd/server.example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com" [21/Dec/2016:09:39:11.938719410 -0500] conn=75097 op=14980 RESULT err=0 tag=103 nentries=0 etime=1 [21/Dec/2016:09:39:12.003351818 -0500] conn=77028 fd=107 slot=107 connection from local to /var/run/slapd-EXAMPLE.COM.socket [21/Dec/2016:09:39:12.039069522 -0500] conn=75097 op=14981 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/EXAMPLE.COM at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=krbtgt/EXAMPLE.COM at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:12.039736952 -0500] conn=75097 op=14981 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:12.040392623 -0500] conn=75097 op=14982 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/server.example.com at EXAMPLE.COM)(krbPrincipalName:caseIgnoreIA5Match:=ldap/server.example.com at EXAMPLE.COM)))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:12.040921415 -0500] conn=75097 op=14982 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:12.041183611 -0500] conn=75097 op=14983 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:12.041312649 -0500] conn=75097 op=14983 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:12.041561525 -0500] conn=75097 op=14984 SRCH base="dc=example,dc=com" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=ipa-dnskeysyncd/server.example.com at EXAMPLE.COM))" attrs="krbPrincipalName krbCanonicalName krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbPrincipalAuthInd krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType ipatokenRadiusConfigLink objectClass" [21/Dec/2016:09:39:12.042005838 -0500] conn=75097 op=14984 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:12.042255995 -0500] conn=75097 op=14985 SRCH base="cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [21/Dec/2016:09:39:12.042381353 -0500] conn=75097 op=14985 RESULT err=0 tag=101 nentries=1 etime=0 [21/Dec/2016:09:39:12.064476101 -0500] conn=77028 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [21/Dec/2016:09:39:12.067486416 -0500] conn=77028 op=0 RESULT err=49 tag=97 nentries=0 etime=0 - SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied) [21/Dec/2016:09:39:12.192506861 -0500] conn=77028 op=1 UNBIND [21/Dec/2016:09:39:12.192549740 -0500] conn=77028 op=1 fd=107 closed - U1 [21/Dec/2016:09:39:13.518816766 -0500] conn=33 op=2575 SRCH base="ou=sessions,ou=Security Domain,o=ipaca" scope=2 filter="(objectClass=securityDomainSessionEntry)" attrs="cn" [21/Dec/2016:09:39:13.519167321 -0500] conn=33 op=2575 RESULT err=32 tag=101 nentries=0 etime=0 Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Wed Dec 21 15:27:02 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 21 Dec 2016 10:27:02 -0500 Subject: [Freeipa-users] Asking for help with crashed freeIPA istance In-Reply-To: References: <729a8aed-4f22-ba26-3089-58c675bd64e0@redhat.com> Message-ID: <585A9F46.7080207@redhat.com> Daniel Schimpfoessl wrote: > Thanks for getting back to me. > > getcert list | grep expires shows dates years in the future for all > certificates > Inline-Bild 1 > > ipactl start --force > > Eventually the system started with: > Forced start, ignoring pki-tomcatd Service, continuing normal > operations. > > systemctl status ipa shows: failed I don't think this is a certificate problem at all. I think the timing with your renewal is just coincidence. Did you change your Directory Manager password at some point? > > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w > password -b "" -s base > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w > *********** -b "" -s base > Inline-Bild 2 You need the -x flag to indicate simple bind. rob > The logs have thousands of lines like it, what am I looking for > specifically? > > Daniel > > > 2016-12-20 4:18 GMT-06:00 Florence Blanc-Renaud >: > > On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote: > > Good day and happy holidays, > > I have been running a freeIPA instance for a few years and been very > happy. Recently the certificate expired and I updated it using the > documented methods. At first all seemed fine. Added a Nagios > monitor for > the certificate expiration and restarted the server (single > server). I > have weekly snapshots, daily backups (using Amanda on the entire > disk). > > One day the services relying on IPA failed to authenticate. > Looking at > the server the ipa service had stopped. Restarting the service > fails. > Restoring a few weeks old snapshot does not start either. > Resetting the > date to a few month back does not work either as httpd fails to > start . > > I am at a loss. > > Here a few details: > # ipa --version > VERSION: 4.4.0, API_VERSION: 2.213 > > > # /usr/sbin/ipactl start > ... > out -> Failed to start pki-tomcatd Service > /var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP server > host ipa.myorg.com > port 636 Error > netscape.ldap.LDAPException: Authentication failed (48) > 2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted > due to > error: Retrieving CA status failed with status 500 > > Any help would be appreciated as all connected services are now > down. > > Thanks, > > Daniel > > > > > Hi Daniel, > > more information would be required to understand what is going on. > First of all, which certificate did you renew? Can you check with > $ getcert list > if other certificates also expired? > > PKI fails to start and the error seems linked to the SSL connection > with the LDAP server. You may want to check if the LDAP server is > listening on the LDAPs port: > - start the stack with > $ ipactl start --force > - check the LDAPs port with > $ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w > password -b "" -s base > > The communication between PKI and the LDAP server is authenticated > with the certificate 'subsystemCert cert-pki-ca' located in > /etc/pki/pki-tomcat/alias, so you may also want to check if it is > still valid. > The directory server access logs (in > /var/log/dirsrv/slapd-DOMAIN-COM/access) would also show the > connection with logs similar to: > > [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to > 10.34.58.150 > [...] conn=47 TLS1.2 128-bit AES; client CN=CA > Subsystem,O=DOMAIN.COM ; issuer CN=Certificate > Authority,O=DOMAIN.COM > [...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca > [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL > [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 > dn="uid=pkidbuser,ou=people,o=ipaca" > > > > HTH, > Flo > > > > From sjuhasz at chemaxon.com Wed Dec 21 15:39:32 2016 From: sjuhasz at chemaxon.com (Sandor Juhasz) Date: Wed, 21 Dec 2016 16:39:32 +0100 (CET) Subject: [Freeipa-users] modify schema - add group email and display attribute In-Reply-To: <585A92DB.5080907@redhat.com> References: <795612095.18818.1482325628676.JavaMail.zimbra@chemaxon.com> <585A92DB.5080907@redhat.com> Message-ID: <1935325431.129080.1482334772814.JavaMail.zimbra@chemaxon.com> That would be perfect solution. How do i do it? ldapmodify: dn: cn=schema changetype: modify add: objectclasses objectclasses: ( NAME 'googleGroup' SUP groupofnames STRUCTURAL MAY ( mail $ displayname ) X-ORIGIN 'Extending FreeIPA' ) What to use for ? Then i just ipa config-mod --addattr=ipaGroupObjectClasses=googleGroup Then groupmail.py from ipalib.plugins import group from ipalib.parameters import Str from ipalib import _ group.group.takes_params = group.group.takes_params + ( Str('mail?', cli_name='mail', label=_('mail'), ), ) group.group.default_attributes.append('mail') Then groupdisplayname.py from ipalib.plugins import group from ipalib.parameters import Str from ipalib import _ group.group.takes_params = group.group.takes_params + ( Str('displayname?', cli_name='displayname', label=_('dispalayname'), ), ) group.group.default_attributes.append('displayname') And finally update js somehow... S?ndor Juh?sz System Administrator ChemAxon Ltd . Building Hx, GraphiSoft Park, Z?hony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 From: "Ludwig Krispenz" To: freeipa-users at redhat.com Sent: Wednesday, December 21, 2016 3:34:03 PM Subject: Re: [Freeipa-users] modify schema - add group email and display attribute On 12/21/2016 02:07 PM, Sandor Juhasz wrote: Hi, i would like to modify schema to have group objects extended with email and display name attribute. The reason is that we are trying to sync our ldap to our google apps. I don't know how much this doc http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf can be applied to groups. Neither did i find a supported attribute syntax for email, maybe PrintableString 1.3.6.1.4.1.1466.115.121.1.58 For values which contain strings containing alphabetic, numeral, and select punctuation characters (as defined in RFC 4517 ). but i am not sure if that could hold email addresses. why don't you just use the mail attribute ? only define a new auxilliary objectclass allowing mail and displayname BQ_BEGIN It would be pretty to have it exposed via ipalib and js plugins as well. If someone could help me out on extending schema, i would be really happy. S?ndor Juh?sz System Administrator ChemAxon Ltd . Building Hx, GraphiSoft Park, Z?hony utca 7, Budapest, Hungary, H-1031 Cell: +36704258964 BQ_END -- Red Hat GmbH, http://www.de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -- Manage your subscription for 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 mbasti at redhat.com Wed Dec 21 16:23:29 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 21 Dec 2016 17:23:29 +0100 Subject: [Freeipa-users] freeipa 4.1 replication conflict resolve issue In-Reply-To: <585A6298.5060901@redhat.com> References: <585A6298.5060901@redhat.com> Message-ID: On 21.12.2016 12:08, Ludwig Krispenz wrote: > > On 12/21/2016 05:11 AM, Ian Chen wrote: >> hello list, >> >> I tried to search for answer, but not solution come up yet. please help. >> >> the setup with multiple nodes has IPA version: >> ipa-server-4.1.0-18.el7.centos.4.x86_64 >> >> >> after adding a replication with an old node, replicaiton conflict >> occured. >> >> ---- node104 >> dn: >> nsuniqueid=5820a804-af9211e6-bbce8d9c-0794b841+uid=test2,cn=users,cn=acco >> unts,dc=... >> uid: test2 >> nsds5ReplConflict: namingConflict uid=test2,cn=users,cn=accounts,dc=... >> krbPrincipalName: test2 at ... >> krbLastPwdChange: 20161220054653Z >> krbPasswordExpiration: 20170320054653Z >> ipaUniqueID: 606b2260-af92-11e6-a928-0050568faf9d >> >> >> ---- node203 >> dn: uid=test2,cn=users,cn=accounts,dc=... >> uid: test2 >> krbPrincipalName: test2 at ... >> krbLastPwdChange: 20161220054653Z >> krbPasswordExpiration: 20170320054653Z >> ipaUniqueID: 606b2260-af92-11e6-a928-0050568faf9d >> >> >> I tried rename RDN following this >> https://mkosek.fedorapeople.org/publican_site/en-US/FreeIPA/3.4/html/FreeIPA_Guide/ipa-replica-manage.html hello, guide ^ is deprecated, please use the https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html For replication conflict is useful this guide https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html Martin >> >> but when trying to delete uid, then change RDN back to uid, there is >> this error >> >> modifying entry "cn=TempValue,cn=users,cn=accounts,dc=..." >> ldap_modify: Object class violation (65) >> additional info: missing attribute "uid" required by object class >> "posixAccount" >> >> I cannot delete object class posixAccount then add it back > I cannot see which commands you really tried to execute and failed, so > could you provide the full log of what you did if you want to follow > the steps in the IPA doc. > > But I do not think that you need to go thru the MOD/MODRDN/... > sequence if you do not want to keep both entries. If a conflict > arises, one entry keeps the original dn, the other gets a dn with > "nsuniquid=....+..." and the nsds5ReplConflict attribute. you can > check the entries and inmost cases you just want to keep the > "original" and just delete the conflict entry >> >> > > -- > Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Dec 21 16:28:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 21 Dec 2016 17:28:39 +0100 Subject: [Freeipa-users] Failed to promote ipa client to ipa replica In-Reply-To: References: Message-ID: <85031740-c94f-fff0-e1f2-8b88b1fd3b7d@redhat.com> On 20.12.2016 20:27, fay wang wrote: > Hi, I have no luck in promoting ipa client to ipa replica. In my > replica system where ipa client is installed: > > certutil -L -d /etc/dirsrv/slapd-XXXX > > does not have Server-Cert. > > Please help! > > Thanks, > fay > > > > Which commands did you used to promote replica? Can you show us the output of that commands? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Dec 21 16:43:19 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 21 Dec 2016 17:43:19 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: Message-ID: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> Hello all :) On 20.12.2016 01:33, Maciej Drobniuch wrote: > Hi All! > > I get the following message while adding a new hostname. > > "The host was added but the DNS update failed with: DNS reverse zone > in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165 what will be in SOA answer? What is the name of reverse zone you have on IPA DNS server? Martin > > The reverse zone is configured and working. > When I am manually adding the PTR record to the reverse zone - all OK > > While adding a new host, the A record is being created but the PTR > fails with the message above. > > Reinstalling centos+IPA worked once but I had to reinstall again > because of problems with kerberos(probably dependencies). > > Not sure what is the root cause of the issue. > > VERSION: 4.4.0, API_VERSION: 2.213 > > CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 > UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > > Any help appreciated! > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-sense LLC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Dec 21 16:50:13 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 Dec 2016 17:50:13 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <1482332011.25536.2.camel@interlinx.bc.ca> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> <1482321907.28211.102.camel@interlinx.bc.ca> <1482332011.25536.2.camel@interlinx.bc.ca> Message-ID: Okay, I believe that this is the problem: On 21.12.2016 15:53, Brian J. Murrell wrote: > [21/Dec/2016:09:39:12.003351818 -0500] conn=77028 fd=107 slot=107 connection from local to /var/run/slapd-EXAMPLE.COM.socket ... > [21/Dec/2016:09:39:12.064476101 -0500] conn=77028 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI > [21/Dec/2016:09:39:12.067486416 -0500] conn=77028 op=0 RESULT err=49 tag=97 nentries=0 etime=0 - SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Permission denied) > [21/Dec/2016:09:39:12.192506861 -0500] conn=77028 op=1 UNBIND > [21/Dec/2016:09:39:12.192549740 -0500] conn=77028 op=1 fd=107 closed - U1 I have no idea why it is returning Permission denied. Is it reproducible when you run this? $ kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa-dnskeysyncd/server.example.com $ ldapsearch -Y GSSAPI -H /var/run/slapd-EXAMPLE.COM.socket ? We need to find out why it is blowing up on GSSAPI negotiation. Wild guess is that /etc/dirsrv/ds.keytab could have wrong permissions. It should have -rw-------. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 If you manage to reproduce it, you can attach strace to the running dirsrv process and see what call is failing (if it is a system call)... I'm CCing LDAP server gurus to see if it rings a bell. -- Petr^2 Spacek From ayeja at uci.cu Wed Dec 21 16:53:09 2016 From: ayeja at uci.cu (=?utf-8?Q?Ing=2E_Adrian_Hern=C3=A1ndez?= Yeja) Date: Wed, 21 Dec 2016 11:53:09 -0500 (CST) Subject: [Freeipa-users] (no subject) In-Reply-To: <307059444.1696642.1482338695692.JavaMail.zimbra@uci.cu> Message-ID: <140435579.1697103.1482339189401.JavaMail.zimbra@uci.cu> Hi folks, I need authenticate my users against a squid proxy server using FreeIPA. I know is possible (https://www.freeipa.org/page/Squid_Integration_with_FreeIPA_using_Single_Sign_On) but my users are not necessarily authenticated in a FreeIPA domain, so my question is if it's possible to allow this requirement either a third application or a specific configuration. Regards. ?La @universidad_uci es Fidel. Los j?venes no fallaremos. #HastaSiempreComandante #HastalaVictoriaSiempre From piolet.y at gmail.com Wed Dec 21 17:05:30 2016 From: piolet.y at gmail.com (Youenn PIOLET) Date: Wed, 21 Dec 2016 18:05:30 +0100 Subject: [Freeipa-users] (no subject) In-Reply-To: <140435579.1697103.1482339189401.JavaMail.zimbra@uci.cu> References: <307059444.1696642.1482338695692.JavaMail.zimbra@uci.cu> <140435579.1697103.1482339189401.JavaMail.zimbra@uci.cu> Message-ID: Hi Adrian, You can use basic_ldap_auth to connect to FreeIPA using LDAP instead of negotiate_kerberos_auth : auth_param basic program /usr/lib/squid3/basic_ldap_auth -R \ -b "cn=accounts,dc=example,dc=com" \ -f uid=%s -h -ZZ auth_param basic children 10 auth_param basic realm infra.msv auth_param basic credentialsttl 30 second Regards, -- Youenn Piolet piolet.y at gmail.com 2016-12-21 17:53 GMT+01:00 Ing. Adrian Hern?ndez Yeja : > Hi folks, I need authenticate my users against a squid proxy server using > FreeIPA. I know is possible (https://www.freeipa.org/page/ > Squid_Integration_with_FreeIPA_using_Single_Sign_On) but my users are not > necessarily authenticated in a FreeIPA domain, so my question is if it's > possible to allow this requirement either a third application or a specific > configuration. > > Regards. > > ?La @universidad_uci es Fidel. Los j?venes no fallaremos. > #HastaSiempreComandante > #HastalaVictoriaSiempre > > -- > Manage your subscription for 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 jaril.nambiar at gmail.com Wed Dec 21 17:56:58 2016 From: jaril.nambiar at gmail.com (Jaril Nambiar) Date: Wed, 21 Dec 2016 23:26:58 +0530 Subject: [Freeipa-users] Windows 7 Authentication Failed with FreeIPA Message-ID: <585ac26e.833d630a.1cadb.974d@mx.google.com> Hi Concern, This email is regarding an issue while using a workgroup Windows-7 client is trying to login the freeIPA realm. It is showing 'There are currently no log on server available to service the logon request' . The guide is to setup for Windows XP. Am I able to create the same in Windows 7 client or not. Requesting your support to fulfill my reuirement. Referred Links: http://www.freeipa.org/page/Windows_authentication_against_FreeIPA http://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Win dows/Linux)_-_Step_by_step https://mkosek.fedorapeople.org/publican_site/en-US/FreeIPA/3.4/html/FreeIPA _Guide/Configuring_Microsoft_Windows.html Thank you, Jaril V V Ph: +91-9987027659 Email: jaril.nambiar at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 176459 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 51778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 43467 bytes Desc: not available URL: From brian at interlinx.bc.ca Wed Dec 21 18:22:47 2016 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Wed, 21 Dec 2016 13:22:47 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> <1482321907.28211.102.camel@interlinx.bc.ca> <1482332011.25536.2.camel@interlinx.bc.ca> Message-ID: <1482344567.7132.10.camel@interlinx.bc.ca> On Wed, 2016-12-21 at 17:50 +0100, Petr Spacek wrote: > Okay, I believe that this is the problem: > > On 21.12.2016 15:53, Brian J. Murrell wrote: > > [21/Dec/2016:09:39:12.003351818 -0500] conn=77028 fd=107 slot=107 > > connection from local to /var/run/slapd-EXAMPLE.COM.socket > > ... > > [21/Dec/2016:09:39:12.064476101 -0500] conn=77028 op=0 BIND dn="" > > method=sasl version=3 mech=GSSAPI > > [21/Dec/2016:09:39:12.067486416 -0500] conn=77028 op=0 RESULT > > err=49 tag=97 nentries=0 etime=0 - SASL(-1): generic failure: > > GSSAPI Error: Unspecified GSS failure.??Minor code may provide more > > information (Permission denied) > > [21/Dec/2016:09:39:12.192506861 -0500] conn=77028 op=1 UNBIND > > [21/Dec/2016:09:39:12.192549740 -0500] conn=77028 op=1 fd=107 > > closed - U1 > > I have no idea why it is returning Permission denied. > > Is it reproducible when you run this? > $ kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab > ipa-dnskeysyncd/server.example.com > $ ldapsearch -Y GSSAPI -H /var/run/slapd-EXAMPLE.COM.socket > ? # klist Ticket cache: KEYRING:persistent:0:0 Default principal: ipa-dnskeysyncd/server.example.com at EXAMPLE.COM Valid starting Expires Service principal 21/12/16 13:05:16 22/12/16 13:02:12 ldap/server.example.com at EXAMPLE.COM 21/12/16 13:02:12 22/12/16 13:02:12 krbtgt/EXAMPLE.COM at EXAMPLE.COM # ldapsearch -Y GSSAPI -H ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE.COM.socket SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) > > We need to find out why it is blowing up on GSSAPI negotiation. > > Wild guess is that /etc/dirsrv/ds.keytab could have wrong > permissions. It > should have > -rw-------. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 # ls -lZ /etc/dirsrv/ds.keytab -rw-------. dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 /etc/dirsrv/ds.keytab > If you manage to reproduce it, you can attach strace to the running > dirsrv By that I assume you mean the ns-slapd. The strace (minus poll/select/futex noise) is attached. > process and see what call is failing (if it is a system call)... Perhaps this one: [pid 13449] open("/etc/krb5.keytab", O_RDONLY) = -1 EACCES (Permission denied) # ls -lZ /etc/krb5.keytab -rw-------. root root system_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab But looking into the backup of this system, even a week and a month ago, that file had the same permissions/ownership. And changing it to 644 temporarily doesn't fix the "ldap_sasl_interactive_bind_s: Invalid credentials (49)" from ldapsearch. Cheers, b. -------------- next part -------------- 8967 restart_syscall(<... resuming interrupted call ...> 13414 restart_syscall(<... resuming interrupted call ...> 13413 restart_syscall(<... resuming interrupted call ...> 12933 restart_syscall(<... resuming interrupted call ...>) = 0 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 12933 accept(8, {sa_family=AF_LOCAL, NULL}, [2]) = 65 12933 fcntl(65, F_GETFL) = 0x2 (flags O_RDWR) 12933 fcntl(65, F_SETFL, O_RDWR|O_NONBLOCK) = 0 12933 setsockopt(65, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 12933 getpeername(65, {sa_family=AF_LOCAL, NULL}, [2]) = 0 12933 getsockname(65, {sa_family=AF_LOCAL, sun_path="/var/run/slapd-EXAMPLE.COM.socket"}, [40]) = 0 12933 getsockopt(65, SOL_SOCKET, SO_PEERCRED, {pid=16254, uid=0, gid=0}, [12]) = 0 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 8967 <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out) 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 13442 recvfrom(65, "0\202\2\316\2\1\1`\202\2\307\2\1\3\4\0\243\202\2\276\4\6GSSAPI\4\202\2\262"..., 512, 0, NULL, NULL) = 512 13442 recvfrom(65, "\237\23\203^\177$\376[\345\20\223t\3052\326\305\352\355i\277\207V\214\n\312M\210h=\2\233="..., 512, 0, NULL, NULL) = 210 13442 write(51, "\0", 1) = 1 13442 sendto(59, "<39>Dec 21 13:16:42 ns-slapd: GS"..., 51, MSG_NOSIGNAL, NULL, 0) = 51 13442 lstat("/etc/gss/mech", 0x7feac37ecd00) = -1 ENOENT (No such file or directory) 13442 openat(AT_FDCWD, "/etc/gss/mech.d", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 107 13442 getdents(107, /* 3 entries */, 32768) = 88 13442 getdents(107, /* 0 entries */, 32768) = 0 13442 close(107) = 0 13442 lstat("/etc/gss/mech.d/gssproxy.conf", {st_mode=S_IFREG|0644, st_size=189, ...}) = 0 13442 stat("/usr/lib64/gssproxy/proxymech.so", {st_mode=S_IFREG|0755, st_size=110960, ...}) = 0 13442 stat("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 open("/etc/krb5.conf", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cba000 13442 read(107, "includedir /var/lib/sss/pubconf/"..., 1024) = 780 13442 openat(AT_FDCWD, "/var/lib/sss/pubconf/krb5.include.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 108 13442 getdents(108, /* 5 entries */, 32768) = 176 13442 open("/var/lib/sss/pubconf/krb5.include.d//krb5_libdefaults", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[libdefaults]\n canonicalize = tr"..., 4096) = 35 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//localauth_plugin", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=98, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[plugins]\n localauth = {\n modul"..., 4096) = 98 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//domain_realm_example_com", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=15, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[domain_realm]\n", 4096) = 15 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 getdents(108, /* 0 entries */, 32768) = 0 13442 close(108) = 0 13442 read(107, "", 1024) = 0 13442 close(107) = 0 13442 munmap(0x7feaf3cba000, 4096) = 0 13442 open("/dev/urandom", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 13442 read(107, "t\232a\376\355j\6:\264\20\322\252#\307\252\3\37\310x\3168!Vc\371\262M\3161\203\rK"..., 64) = 64 13442 close(107) = 0 13442 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 107 13442 fstat(107, {st_mode=S_IFREG|0644, st_size=616, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cba000 13442 read(107, "127.0.0.1 localhost localhost."..., 1024) = 616 13442 read(107, "", 1024) = 0 13442 close(107) = 0 13442 munmap(0x7feaf3cba000, 4096) = 0 13442 socket(PF_NETLINK, SOCK_RAW, 0) = 107 13442 bind(107, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 13442 getsockname(107, {sa_family=AF_NETLINK, pid=12933, groups=00000000}, [12]) = 0 13442 sendto(107, "\24\0\0\0\26\0\1\3\n\307ZX\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 13442 recvmsg(107, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"L\0\0\0\24\0\2\0\n\307ZX\2052\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 404 13442 recvmsg(107, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"H\0\0\0\24\0\2\0\n\307ZX\2052\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 504 13442 recvmsg(107, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\n\307ZX\2052\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 13442 close(107) = 0 13442 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 107 13442 connect(107, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "fd31:aeb1:48df:0:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 13442 getsockname(107, {sa_family=AF_INET6, sin6_port=htons(60060), inet_pton(AF_INET6, "fd31:aeb1:48df:0:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 13442 connect(107, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0 13442 connect(107, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "[ipv6_prefix1]:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 13442 getsockname(107, {sa_family=AF_INET6, sin6_port=htons(39732), inet_pton(AF_INET6, "[ipv6_prefix1]:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 13442 connect(107, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0 13442 connect(107, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "[ipv6_prefix2]:0:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 13442 getsockname(107, {sa_family=AF_INET6, sin6_port=htons(45163), inet_pton(AF_INET6, "[ipv6_prefix3]:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 13442 connect(107, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0 13442 connect(107, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "[ipv6_prefix3]:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 13442 getsockname(107, {sa_family=AF_INET6, sin6_port=htons(50089), inet_pton(AF_INET6, "[ipv6_prefix3]:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 13442 connect(107, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0 13442 connect(107, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.75.22.247")}, 16) = 0 13442 getsockname(107, {sa_family=AF_INET6, sin6_port=htons(57720), inet_pton(AF_INET6, "::ffff:10.75.22.247", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 13442 close(107) = 0 13442 stat("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 open("/etc/krb5.conf", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cba000 13442 read(107, "includedir /var/lib/sss/pubconf/"..., 1024) = 780 13442 openat(AT_FDCWD, "/var/lib/sss/pubconf/krb5.include.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 108 13442 getdents(108, /* 5 entries */, 32768) = 176 13442 open("/var/lib/sss/pubconf/krb5.include.d//krb5_libdefaults", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[libdefaults]\n canonicalize = tr"..., 4096) = 35 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//localauth_plugin", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=98, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[plugins]\n localauth = {\n modul"..., 4096) = 98 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//domain_realm_example_com", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=15, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[domain_realm]\n", 4096) = 15 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 getdents(108, /* 0 entries */, 32768) = 0 13442 close(108) = 0 13442 read(107, "", 1024) = 0 13442 close(107) = 0 13442 munmap(0x7feaf3cba000, 4096) = 0 13442 open("/dev/urandom", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 13442 read(107, "\1\313~\27y\301\273\231\350+\364\t\305\312\261MY$\246\253x|S9u\255\364\244\265\343\23 "..., 64) = 64 13442 close(107) = 0 13442 open("/etc/krb5.keytab", O_RDONLY) = -1 EACCES (Permission denied) 13442 stat("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 open("/etc/krb5.conf", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cba000 13442 read(107, "includedir /var/lib/sss/pubconf/"..., 1024) = 780 13442 openat(AT_FDCWD, "/var/lib/sss/pubconf/krb5.include.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 108 13442 getdents(108, /* 5 entries */, 32768) = 176 13442 open("/var/lib/sss/pubconf/krb5.include.d//krb5_libdefaults", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[libdefaults]\n canonicalize = tr"..., 4096) = 35 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//localauth_plugin", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=98, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[plugins]\n localauth = {\n modul"..., 4096) = 98 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//domain_realm_example_com", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=15, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[domain_realm]\n", 4096) = 15 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 getdents(108, /* 0 entries */, 32768) = 0 13442 close(108) = 0 13442 read(107, "", 1024) = 0 13442 close(107) = 0 13442 munmap(0x7feaf3cba000, 4096) = 0 13442 open("/dev/urandom", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 13442 read(107, "y\331\247\350\335\273\366\257\245=\361\233\276#\304\357\6\2251\276\7\344\372\301\335\221\262\305\26f\301f"..., 64) = 64 13442 close(107) = 0 13442 stat("/usr/lib64/gssproxy/proxymech.so", {st_mode=S_IFREG|0755, st_size=110960, ...}) = 0 13442 stat("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 open("/etc/krb5.conf", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cba000 13442 read(107, "includedir /var/lib/sss/pubconf/"..., 1024) = 780 13442 openat(AT_FDCWD, "/var/lib/sss/pubconf/krb5.include.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 108 13442 getdents(108, /* 5 entries */, 32768) = 176 13442 open("/var/lib/sss/pubconf/krb5.include.d//krb5_libdefaults", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[libdefaults]\n canonicalize = tr"..., 4096) = 35 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//localauth_plugin", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=98, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[plugins]\n localauth = {\n modul"..., 4096) = 98 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//domain_realm_example_com", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=15, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[domain_realm]\n", 4096) = 15 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 getdents(108, /* 0 entries */, 32768) = 0 13442 close(108) = 0 13442 read(107, "", 1024) = 0 13442 close(107) = 0 13442 munmap(0x7feaf3cba000, 4096) = 0 13442 open("/dev/urandom", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 13442 read(107, "\333\310\fT\300-RA\243\305\30\332V<:\230\5\27\274\215>\262YV\345\324b\314#,\263F"..., 64) = 64 13442 close(107) = 0 13442 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 107 13442 fstat(107, {st_mode=S_IFREG|0644, st_size=616, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cba000 13442 read(107, "127.0.0.1 localhost localhost."..., 1024) = 616 13442 read(107, "", 1024) = 0 13442 close(107) = 0 13442 munmap(0x7feaf3cba000, 4096) = 0 13442 socket(PF_NETLINK, SOCK_RAW, 0) = 107 13442 bind(107, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 13442 getsockname(107, {sa_family=AF_NETLINK, pid=12933, groups=00000000}, [12]) = 0 13442 sendto(107, "\24\0\0\0\26\0\1\3\n\307ZX\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 13442 recvmsg(107, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"L\0\0\0\24\0\2\0\n\307ZX\2052\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 404 13442 recvmsg(107, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"H\0\0\0\24\0\2\0\n\307ZX\2052\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 504 13442 recvmsg(107, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\n\307ZX\2052\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 13442 close(107) = 0 13442 socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 107 13442 connect(107, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "fd31:aeb1:48df:0:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 13442 getsockname(107, {sa_family=AF_INET6, sin6_port=htons(44027), inet_pton(AF_INET6, "fd31:aeb1:48df:0:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 13442 connect(107, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0 13442 connect(107, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "[ipv6_prefix1]:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 13442 getsockname(107, {sa_family=AF_INET6, sin6_port=htons(39984), inet_pton(AF_INET6, "[ipv6_prefix1]:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 13442 connect(107, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0 13442 connect(107, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "[ipv6_prefix2]:0:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 13442 getsockname(107, {sa_family=AF_INET6, sin6_port=htons(37062), inet_pton(AF_INET6, "[ipv6_prefix3]:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 13442 connect(107, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0 13442 connect(107, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "[ipv6_prefix3]:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 13442 getsockname(107, {sa_family=AF_INET6, sin6_port=htons(37446), inet_pton(AF_INET6, "[ipv6_prefix3]:214:d1ff:fe13:45ac", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 13442 connect(107, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0 13442 connect(107, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.75.22.247")}, 16) = 0 13442 getsockname(107, {sa_family=AF_INET6, sin6_port=htons(48649), inet_pton(AF_INET6, "::ffff:10.75.22.247", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 13442 close(107) = 0 13442 stat("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 open("/etc/krb5.conf", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cba000 13442 read(107, "includedir /var/lib/sss/pubconf/"..., 1024) = 780 13442 openat(AT_FDCWD, "/var/lib/sss/pubconf/krb5.include.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 108 13442 getdents(108, /* 5 entries */, 32768) = 176 13442 open("/var/lib/sss/pubconf/krb5.include.d//krb5_libdefaults", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[libdefaults]\n canonicalize = tr"..., 4096) = 35 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//localauth_plugin", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=98, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[plugins]\n localauth = {\n modul"..., 4096) = 98 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//domain_realm_example_com", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=15, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[domain_realm]\n", 4096) = 15 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 getdents(108, /* 0 entries */, 32768) = 0 13442 close(108) = 0 13442 read(107, "", 1024) = 0 13442 close(107) = 0 13442 munmap(0x7feaf3cba000, 4096) = 0 13442 open("/dev/urandom", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 13442 read(107, "\334\337\2\5^\334\343{\306\235\30\2551\240\320\337\10\264\361S\3740\257\370;\330\17`\332\10C("..., 64) = 64 13442 close(107) = 0 13442 open("/etc/krb5.keytab", O_RDONLY) = -1 EACCES (Permission denied) 13442 stat("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 open("/etc/krb5.conf", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFREG|0644, st_size=780, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cba000 13442 read(107, "includedir /var/lib/sss/pubconf/"..., 1024) = 780 13442 openat(AT_FDCWD, "/var/lib/sss/pubconf/krb5.include.d/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 108 13442 getdents(108, /* 5 entries */, 32768) = 176 13442 open("/var/lib/sss/pubconf/krb5.include.d//krb5_libdefaults", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=35, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[libdefaults]\n canonicalize = tr"..., 4096) = 35 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//localauth_plugin", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=98, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[plugins]\n localauth = {\n modul"..., 4096) = 98 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 open("/var/lib/sss/pubconf/krb5.include.d//domain_realm_example_com", O_RDONLY) = 111 13442 fstat(111, {st_mode=S_IFREG|0644, st_size=15, ...}) = 0 13442 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7feaf3cb9000 13442 read(111, "[domain_realm]\n", 4096) = 15 13442 read(111, "", 4096) = 0 13442 close(111) = 0 13442 munmap(0x7feaf3cb9000, 4096) = 0 13442 getdents(108, /* 0 entries */, 32768) = 0 13442 close(108) = 0 13442 read(107, "", 1024) = 0 13442 close(107) = 0 13442 munmap(0x7feaf3cba000, 4096) = 0 13442 open("/dev/urandom", O_RDONLY) = 107 13442 fcntl(107, F_SETFD, FD_CLOEXEC) = 0 13442 fstat(107, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 13442 read(107, "\244\243\211(\301\227\26x\262X\26<\2\201b\377p33\232q\302\351$\301\347\213\247n\17w\177"..., 64) = 64 13442 close(107) = 0 13442 sendto(65, "0\f\2\1\1a\7\n\0011\4\0\4\0", 14, 0, NULL, 0 12933 read(50, 13442 <... sendto resumed> ) = 14 12933 <... read resumed> "\0", 200) = 1 13442 write(51, "\0", 1 12933 getpeername(7, 13442 <... write resumed> ) = 1 12933 <... getpeername resumed> 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 12933 read(50, "\0", 200) = 1 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 13450 recvfrom(65, "0\5\2\1\2B\0", 512, 0, NULL, NULL) = 7 13450 write(51, "\0", 1) = 1 12933 read(50, "\0", 200) = 1 12933 close(65) = 0 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 13414 <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out) 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) 12933 getpeername(7, 0x7ffc9bff1450, [112]) = -1 ENOTCONN (Transport endpoint is not connected) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From beeth2006 at gmail.com Wed Dec 21 18:52:39 2016 From: beeth2006 at gmail.com (beeth beeth) Date: Wed, 21 Dec 2016 13:52:39 -0500 Subject: [Freeipa-users] Failed ipa-client-install with IPA Replica In-Reply-To: References: <794d723f-9994-2281-1add-c5d0d1167257@redhat.com> Message-ID: Hi Flo, First of all, thanks a lot for taking your time to reproduced the issue from your end, you have been very helpful and you are the best! Here're the what I observed after some more tests: 1. In this case I used Entrust(www.entrust.com) certificate service, and they provided root-G2-L1K certificate chain. In the /etc/ipa/ca.crt file on the primary IPA server ipaprd1, I saw 3 certificates(root, G2 and L1K) as the root chain. When I checked the ca.crt file on the RHEL6 IPA client(called ipadev6), I only saw one certificate, the L1K one, which didn't look right. So I followed your advise to remove it, then the ipa-client-install could finish without the LDAP error. But after the installation, I found the ca.crt file on such RHEL6 box still had only one certificate(L1K). Meanwhile, when I checked the RHEL7 IPA client(called ipadev7, which I mentioned before that it was always working), the /etc/ipa/ca.crt file has 3 certificate, the complete root chain. I have no clue why the IPA client installation on RHEL7 box is so smooth but not the RHEL6 box, while they both enrolled with the exact same primary & replica IPA server. The bug document you mentioned doesn't explain this. 2. During the client installation on ipadev6(RHEL6 box), with ca.crt file manually removed, I saw the following message: A RA is not configured on the server. Not requesting host certificate. The installation stuck there for about 3~4 minutes before it continued to the next step, then it finished eventually with "Client configuration complete". Any idea about such message? Thanks!! On Tue, Dec 20, 2016 at 9:43 AM, Florence Blanc-Renaud wrote: > On 12/16/2016 03:54 PM, Florence Blanc-Renaud wrote: > >> On 12/15/2016 08:01 PM, beeth beeth wrote: >> >>> Hi Flo, >>> >>> That's a good point! I checked the dirsrv certificate and confirmed >>> valid(good until later next year). >>> Since I had no problem to enroll another new IPA client(RHEL7 box >>> instead of RHEL6) to such replica server, I thought it might not be a >>> server end issue. However, when I tried to restart the DIRSRV service on >>> the replica server, I found these messages in the log >>> file /var/log/dirsrv/slapd-IPA-EXAMPLE-COM/errors: >>> >>> [15/Dec/2016:13:38:15.891301246 -0500] 389-Directory/1.3.5.10 >>> B2016.257.1817 starting up >>> [15/Dec/2016:13:38:15.911777373 -0500] default_mr_indexer_create: >>> warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match >>> [15/Dec/2016:13:38:15.926320306 -0500] WARNING: changelog: entry cache >>> size 2097152 B is less than db size 5488640 B; We recommend to increase >>> the entry cache size nsslapd-cachememsize. >>> [15/Dec/2016:13:38:16.132155534 -0500] schema-compat-plugin - scheduled >>> schema-compat-plugin tree scan in about 5 seconds after the server >>> startup! >>> [15/Dec/2016:13:38:16.167896279 -0500] NSACLPlugin - The ACL target >>> cn=dns,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.173317345 -0500] NSACLPlugin - The ACL target >>> cn=dns,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.178354342 -0500] NSACLPlugin - The ACL target >>> cn=keys,cn=sec,cn=dns,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.183579322 -0500] NSACLPlugin - The ACL target >>> cn=dns,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.188786976 -0500] NSACLPlugin - The ACL target >>> cn=dns,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.193275650 -0500] NSACLPlugin - The ACL target >>> cn=groups,cn=compat,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.197580407 -0500] NSACLPlugin - The ACL target >>> cn=computers,cn=compat,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.201863256 -0500] NSACLPlugin - The ACL target >>> cn=ng,cn=compat,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.206318629 -0500] NSACLPlugin - The ACL target >>> ou=sudoers,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.211559100 -0500] NSACLPlugin - The ACL target >>> cn=users,cn=compat,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.216146819 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.220786596 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.225594942 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.229986749 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.234518367 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.238763121 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.243031116 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.247507984 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.252327210 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.259046910 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.263856581 -0500] NSACLPlugin - The ACL target >>> cn=vaults,cn=kra,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.269301704 -0500] NSACLPlugin - The ACL target >>> cn=ad,cn=etc,dc=ipa,dc=example,dc=com does not exist >>> [15/Dec/2016:13:38:16.283511408 -0500] NSACLPlugin - The ACL target >>> cn=casigningcert >>> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does >>> not exist >>> [15/Dec/2016:13:38:16.287853825 -0500] NSACLPlugin - The ACL target >>> cn=casigningcert >>> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=ipa,dc=example,dc=com does >>> not exist >>> [15/Dec/2016:13:38:16.395872649 -0500] NSACLPlugin - The ACL target >>> cn=automember rebuild membership,cn=tasks,cn=config does not exist >>> [15/Dec/2016:13:38:16.405404114 -0500] Skipping CoS Definition >>> cn=Password Policy,cn=accounts,dc=ipa,dc=example,dc=com--no CoS >>> Templates found, which should be added before the CoS Definition. >>> [15/Dec/2016:13:38:16.463117873 -0500] set_krb5_creds - Could not get >>> initial credentials for principal >>> [ldap/ipaprd2.example.com at IPA.EXAMPLE.COM >>> ] in keytab >>> [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see e-text)) >>> [15/Dec/2016:13:38:16.471256279 -0500] schema-compat-plugin - >>> schema-compat-plugin tree scan will start in about 5 seconds! >>> [15/Dec/2016:13:38:16.479213976 -0500] slapd started. Listening on All >>> Interfaces port 389 for LDAP requests >>> [15/Dec/2016:13:38:16.483683353 -0500] Listening on >>> /var/run/slapd-IPA-EXAMPLE-COM.socket for LDAPI requests >>> [15/Dec/2016:13:38:21.634319974 -0500] schema-compat-plugin - warning: >>> no entries set up under ou=sudoers,dc=ipa,dc=example,dc=com >>> [15/Dec/2016:13:38:21.639855161 -0500] schema-compat-plugin - warning: >>> no entries set up under cn=ng, cn=compat,dc=ipa,dc=example,dc=com >>> [15/Dec/2016:13:38:21.653406463 -0500] schema-compat-plugin - no RDN for >>> cn=cdm_users,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com, unsetting >>> domain/map/id >>> "cn=compat,dc=ipa,dc=example,dc=com"/"cn=groups"/("cn=cdm_us >>> ers,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com") >>> >>> [15/Dec/2016:13:38:21.714897614 -0500] schema-compat-plugin - warning: >>> no entries set up under cn=computers, cn=compat,dc=ipa,dc=example,dc=com >>> [15/Dec/2016:13:38:21.719933118 -0500] schema-compat-plugin - Finished >>> plugin initialization. >>> [15/Dec/2016:13:38:36.591969481 -0500] ipa-topology-plugin - >>> ipa_topo_util_get_replica_conf: server configuration missing >>> [15/Dec/2016:13:38:36.598683009 -0500] ipa-topology-plugin - >>> ipa_topo_util_get_replica_conf: cannot create replica >>> >>> Any idea? >>> BTW, everything ran well on IPA 4.2(server installation and client >>> installation), as you once assisted me couple months ago, until we set >>> up a new IPA environment with RHEL7.3 instead of RHEL7.2, then the IPA >>> version changed from 4.2 to 4.4. Last time you guided me about the >>> change since IPA 4.3, for the newly introduced domain level concept, and >>> the way how the replica should be installed was changed too... Thanks >>> again! >>> >>> Hi Beeth, >> >> I managed to reproduce your issue with IPA master installed without dns >> and without integrated CA. >> >> Can you check on your RHEL 6 client if there is a file /etc/ipa/ca.crt? >> If yes, check its content with >> $ sudo openssl x509 -noout -text -in /etc/ipa/ca.crt >> and compare with the CA certificate stored on the master or the replica >> (at the same location /etc/ipa/ca.crt). The certificate should be the >> one for the CA that signed your HTTPd and LDAP server certs (ie Verisign). >> >> If the certificate is different, it is probably a left-over CA >> certificate corresponding to a previous installation. You can just >> delete the file on the client and re-run ipa-client-install. >> >> Flo. >> >> > To follow-up on this issue: it happens only in CA-less environment and > when the client has an old /etc/ipa/ca.crt file. > > If the /etc/ipa/ca.crt file is present, the client installer connects to > the IPA LDAP server using startTLS to perform basic checks (instead of > using a simple ldap conn otherwise). But there is a bug in > ipa-replica-install which does not set up startTLS on the LDAP replica (see > ticket 6226 [1]). > > This explains why the issue does not happen if you specify only the master > during ipa-client-install, or if your client does not have any > /etc/ipa/ca.crt. > > Hope this clarifies, > Flo > > > [1] https://fedorahosted.org/freeipa/ticket/6226 > > >>> On Thu, Dec 15, 2016 at 10:52 AM, Florence Blanc-Renaud >> > wrote: >>> >>> On 12/14/2016 07:49 PM, beeth beeth wrote: >>> >>> Hi Flo, >>> >>> Thanks for the great hint! I reran the ipa-client-install on the >>> rhel6 >>> box(ipadev6), and monitored the access log file you mentioned >>> on the >>> replica: >>> >>> # ipa-client-install --domain=ipa.example.com >>> >>> --server=ipaprd2.example.com >>> >>> --hostname=ipadev6.example.com >>> -d >>> >>> ( ipaprd2 = primary IPA server on RHEL7; ipadev6 = replica on >>> RHEL6 ) >>> >>> AFTER about 3 seconds, I saw these on the replica ipaprd2: >>> [14/Dec/2016:13:11:41.071421132 -0500] conn=1040 fd=73 slot=73 >>> connection from to >>> [14/Dec/2016:13:11:41.071880026 -0500] conn=1040 op=0 EXT >>> oid="1.3.6.1.4.1.1466.20037" >>> [14/Dec/2016:13:11:41.071964217 -0500] conn=1040 op=0 RESULT >>> err=2 >>> tag=120 nentries=0 etime=0 >>> [14/Dec/2016:13:11:41.073275674 -0500] conn=1040 op=1 UNBIND >>> [14/Dec/2016:13:11:41.073307101 -0500] conn=1040 op=1 fd=73 >>> closed - U1 >>> [14/Dec/2016:13:11:41.074782496 -0500] conn=1041 fd=73 slot=73 >>> connection from to >>> [14/Dec/2016:13:11:41.074985233 -0500] conn=1041 op=0 EXT >>> oid="1.3.6.1.4.1.1466.20037" >>> [14/Dec/2016:13:11:41.075022849 -0500] conn=1041 op=0 RESULT >>> err=2 >>> tag=120 nentries=0 etime=0 >>> [14/Dec/2016:13:11:41.075448887 -0500] conn=1041 op=1 UNBIND >>> [14/Dec/2016:13:11:41.075460964 -0500] conn=1041 op=1 fd=73 >>> closed - U1 >>> [14/Dec/2016:13:11:49.006146850 -0500] conn=1029 op=8 UNBIND >>> [14/Dec/2016:13:11:49.006181982 -0500] conn=1029 op=8 fd=66 >>> closed - U1 >>> >>> So I did see the err=2, and oid="1.3.6.1.4.1.1466.20037", I >>> checked the >>> oid and got: >>> >>> 1.3.6.1.4.1.1466.20037: StartTLS Request (RFC 4511) >>> >>> It looked to be related with TLS... pease advise. Thanks! >>> >>> >>> Hi, >>> >>> when the replica got installed, the installer must have configured >>> the directory server for SSL and start TLS. I tend to suspect an >>> expired certificate issue rather than a misconfiguration. Could you >>> please check that dirsrv certificate is still valid? >>> >>> $ certutil -L -d /etc/dirsrv/slapd-DOMAIN-COM/ -n Server-Cert >>> |grep Not >>> Not Before: Wed Dec 14 16:56:02 2016 >>> Not After : Sat Dec 15 16:56:02 2018 >>> >>> If the certificate is still valid, you may want to read 389-ds >>> How-To to make sure that SSL is properly setup: >>> >>> http://directory.fedoraproject.org/docs/389ds/howto/howto- >>> ssl.html#deploy-the-settings >>> >>> >>> >> ssl.html#deploy-the-settings> >>> >>> >>> Flo. >>> >>> >>> On Wed, Dec 14, 2016 at 7:57 AM, Florence Blanc-Renaud >>> >>> >> wrote: >>> >>> On 12/14/2016 01:08 PM, beeth beeth wrote: >>> >>> Thanks David. I installed both the master and replica IPA >>> servers with >>> third-party certificates(Verisign), but I doubt that >>> could be >>> the issue, >>> because I had no problem to run the same >>> ipa-client-install >>> command on a >>> RHEL7 machine(of course, the --hostname used a different >>> hostname of the >>> server). And I had no problem to run the >>> ipa-client-install >>> command with >>> --server= on such RHEL6 machine. So what could >>> cause the >>> LDAP >>> communication failed during the client enrollment with >>> the >>> replica? Is >>> there a way I can troubleshoot this by running some >>> commands? So >>> far I >>> did telnet to check the open ports, as well as run the >>> ldapsearch >>> towards the replica. Thanks again! >>> >>> >>> On Tue, Dec 13, 2016 at 8:46 AM, David Kupka >>> >>> > >>> >>> >>> wrote: >>> >>> On 13/12/16 05:44, beeth beeth wrote: >>> >>> I have two IPA servers ipaprd1.example.com >>> >>> >>> and >>> ipaprd2.example.com >>> >>> , running >>> ipa 4.4 on RHEL7. When I tried to >>> install/configure the >>> client >>> on a RHEL6 >>> system(called ipadev6), I had issue when I >>> tried to >>> enroll it >>> with the >>> replica(ipaprd2), while no issue with the >>> primary(ipaprd1): >>> >>> # ipa-client-install --domain=ipa.example.com >>> >>> >>> >>> --server=ipaprd1.example.com >>> >>> >>> --server=ipaprd2.example.com >>> >>> >> > >>> --hostname=ipadev6.example.com >>> >>> >> > >>> LDAP Error: Protocol error: unsupported extended >>> operation >>> Autodiscovery of servers for failover cannot >>> work with this >>> configuration. >>> If you proceed with the installation, services >>> will be >>> configured to always >>> access the discovered server for all operations >>> and will not >>> fail over to >>> other servers in case of failure. >>> Proceed with fixed values and no DNS >>> discovery? [no] >>> >>> Then I tried to run ipa-client-install to enroll >>> with the >>> replica(ipaprd2), >>> with debug mode, I got this: >>> >>> # ipa-client-install --domain=ipa.example.com >>> >>> >>> >>> --server=ipaprd2.example.com >>> >>> >>> --hostname=ipadev6.example.com >>> >>> >>> -d >>> >>> /usr/sbin/ipa-client-install was invoked with >>> options: >>> {'domain': ' >>> ipa.example.com >>> >>> ', 'force': False, >>> 'realm_name': None, >>> 'krb5_offline_passwords': True, 'primary': False, >>> 'mkhomedir': >>> False, >>> 'create_sshfp': True, 'conf_sshd': True, >>> 'conf_ntp': True, >>> 'on_master': >>> False, 'ntp_server': None, 'nisdomain': None, >>> 'no_nisdomain': False, >>> 'principal': None, 'hostname': >>> 'ipadev6.example.com >>> >>> ', 'no_ac': False, >>> 'unattended': None, 'sssd': True, 'trust_sshfp': >>> False, >>> 'kinit_attempts': >>> 5, 'dns_updates': False, 'conf_sudo': True, >>> 'conf_ssh': >>> True, >>> 'force_join': >>> False, 'ca_cert_file': None, 'server': >>> ['ipaprd2.example.com >>> >>> '], >>> 'prompt_password': False, 'permit': False, >>> 'debug': True, >>> 'preserve_sssd': >>> False, 'uninstall': False} >>> missing options might be asked for interactively >>> later >>> Loading Index file from >>> '/var/lib/ipa-client/sysrestor >>> e/sysrestore.index' >>> Loading StateFile from >>> '/var/lib/ipa-client/sysrestor >>> e/sysrestore.state' >>> [IPA Discovery] >>> Starting IPA discovery with >>> domain=ipa.example.com >>> >>> , servers=[' >>> ipaprd2.example.com >>> >>> '], >>> hostname=ipadev6.example.com >>> >>> >> > >>> Server and domain forced >>> [Kerberos realm search] >>> Search DNS for TXT record of >>> _kerberos.ipa.example.com >>> >> > >>> >> >>> >> >>. >>> No DNS record found >>> Search DNS for SRV record of >>> _kerberos._udp.ipa.example.com >>> >>> . >>> No DNS record found >>> SRV record for KDC not found! Domain: >>> ipa.example.com >>> >>> >>> [LDAP server check] >>> Verifying that ipaprd2.example.com >>> >>> >> > >>> (realm None) is an IPA server >>> Init LDAP connection with: >>> ldap://ipaprd2.example.com:389 >>> >> > >>> >> >>> >> >> >>> LDAP Error: Protocol error: unsupported extended >>> operation >>> Discovery result: UNKNOWN_ERROR; server=None, >>> domain=ipa.example.com >>> >>> , >>> kdc=None, basedn=None >>> Validated servers: >>> will use discovered domain: ipa.example.com >>> >>> >>> IPA Server not found >>> [IPA Discovery] >>> Starting IPA discovery with >>> domain=ipa.example.com >>> >>> , servers=[' >>> ipaprd2.example.com >>> >>> '], >>> hostname=ipadev6.example.com >>> >>> >> > >>> Server and domain forced >>> [Kerberos realm search] >>> Search DNS for TXT record of >>> _kerberos.ipa.example.com >>> >> > >>> >> >>> >> >>. >>> No DNS record found >>> Search DNS for SRV record of >>> _kerberos._udp.ipa.example.com >>> >>> . >>> No DNS record found >>> SRV record for KDC not found! Domain: >>> ipa.example.com >>> >>> >>> [LDAP server check] >>> Verifying that ipaprd2.example.com >>> >>> >> > >>> (realm None) is an IPA server >>> Init LDAP connection with: >>> ldap://ipaprd2.example.com:389 >>> >> > >>> >> >>> >> >> >>> LDAP Error: Protocol error: unsupported extended >>> operation >>> Discovery result: UNKNOWN_ERROR; server=None, >>> domain=ipa.example.com >>> >>> , >>> kdc=None, basedn=None >>> Validated servers: >>> Failed to verify that ipaprd2.example.com >>> >>> >>> is an IPA Server. >>> This may mean that the remote server is not up >>> or is not >>> reachable due to >>> network or firewall settings. >>> Please make sure the following ports are opened >>> in the >>> firewall >>> settings: >>> TCP: 80, 88, 389 >>> UDP: 88 (at least one of TCP/UDP ports 88 >>> has to be >>> open) >>> Also note that following ports are necessary for >>> ipa-client working >>> properly after enrollment: >>> TCP: 464 >>> UDP: 464, 123 (if NTP enabled) >>> (ipaprd2.example.com >>> >>> : Provided as >>> option) >>> Installation failed. Rolling back changes. >>> IPA client is not configured on this system. >>> >>> >>> I double checked the services running on the >>> replica, >>> all looked >>> well: >>> ports are listening, and I could telnet the >>> ports from the >>> client(ipadev6). >>> I could run "ldapserach" command to talk to the >>> replica(ipaprd2) >>> from this >>> client(ipadev6), with pulling out all the LDAP >>> records. >>> >>> Also, I have another test box running RHEL7, >>> and no >>> issue at all >>> to run the >>> exact same ipa-client-install command on that >>> RHEL7 box. So >>> could there be >>> a bug on the ipa-client software on RHEL6, to >>> talk to >>> IPA sever >>> running on >>> RHEL7? Please advise. Thank you! >>> >>> Hi Beeth, >>> >>> you may want to check the access and errors log of the >>> Directory >>> Server in /var/log/dirsrv/slapd-DOMAIN. The extended >>> operations are >>> logged in the access log with the tag "EXT oid=...", but a >>> failing >>> operation related to unsupported extended operation will >>> probably >>> log a "RESULT err=2". >>> >>> So I would first check access log and look for such a >>> failure. With >>> the OID we will be able to understand which operation is >>> failing and >>> which part could be misconfigured. >>> >>> HTH, >>> Flo. >>> >>> Best regards, >>> Beeth >>> >>> >>> >>> Hello Beeth, >>> I've tried to reproduce the problem you described >>> with 7.3 >>> (ipa-server 4.4.0-12) on master and replica and 6.9 >>> (ipa-client >>> 3.0.0-51) on client and it worked for me as expected. >>> I've done these steps: >>> [master] # ipa-server-install -a Secret123 -p >>> Secret123 --domain >>> example.test --realm EXAMPLE.TEST --setup-dns >>> --auto-forwarders -U >>> [replica] # ipa-client-install -p admin -w Secret123 >>> --domain >>> example.test --server master.example.test -U >>> [replica] # ipa-replica-install >>> [client] # ipa-client-install -p admin -w Secret123 >>> --domain >>> example.test --server replica.example.test -U >>> [client] # id admin >>> >>> Is there anything you've done differently? >>> >>> -- >>> David Kupka >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucas.diedrich at gmail.com Wed Dec 21 18:52:48 2016 From: lucas.diedrich at gmail.com (Lucas Diedrich) Date: Wed, 21 Dec 2016 18:52:48 +0000 Subject: [Freeipa-users] Ipa cert automatic renew Failing. Message-ID: Hello guys, I'm having some trouble with, whats is happening with my server is that i'm hiting an old BUG (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to mbasti over irc he oriented me to send this to the email list. The problem is, i got on CA Master, so because of this problem the CA Master certificates couldn't be renewd, so now i promoted another master to be the CA. And the problem still persist. This is the certs from my new CA ( https://paste.fedoraproject.org/510617/14823448/), this is the certs from my old CA ( https://paste.fedoraproject.org/510618/44871148/) This is the log then i restart pki-tomcat( "CA port 636 Error netscape.ldap.LDAPException: Authentication failed (49)") This is the log from dirsrv when i restart pki-tomcat ( https://paste.fedoraproject.org/510614/23446801/) Basically my CA is not working anymore... Anyway, i tried lots of thing but couldn't fix this, anyone has some idea? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at interlinx.bc.ca Wed Dec 21 20:36:34 2016 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Wed, 21 Dec 2016 15:36:34 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <1482344567.7132.10.camel@interlinx.bc.ca> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> <1482321907.28211.102.camel@interlinx.bc.ca> <1482332011.25536.2.camel@interlinx.bc.ca> <1482344567.7132.10.camel@interlinx.bc.ca> Message-ID: <1482352594.7132.18.camel@interlinx.bc.ca> Some additional information. I can't seem to use the CLI either. Perhaps that is expected: # kinit admin Password for admin at EXAMPLE.COM: # klist Ticket cache: KEYRING:persistent:0:krb_ccache_3jm4X9m Default principal: admin at EXAMPLE.COM Valid starting Expires Service principal 21/12/16 15:29:20 22/12/16 15:29:17 krbtgt/EXAMPLE.COM at EXAMPLE.COM # ipa host-find ipa: ERROR: Insufficient access: Invalid credentials When I do that (the ipa host-find) /var/log/krb5kdc.log says: Dec 21 15:29:28 server.example.com krb5kdc[13548](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) fd31:aeb1:48df:0:214:d1ff:fe13:45ac: ISSUE: authtime 1482352160, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for HTTP/server.example.com at EXAMPLE.COM Dec 21 15:29:28 server.example.com krb5kdc[13548](info): closing down fd 12 Dec 21 15:29:28 server.example.com krb5kdc[13548](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) fd31:aeb1:48df:0:214:d1ff:fe13:45ac: ISSUE: authtime 1482352160, etypes {rep=18 tkt=18 ses=18}, HTTP/server.example.com at EXAMPLE.COM for ldap/server.example.com at EXAMPLE.COM Dec 21 15:29:28 server.example.com krb5kdc[13548](info): ... CONSTRAINED-DELEGATION s4u-client=admin at EXAMPLE.COM Dec 21 15:29:28 server.example.com krb5kdc[13548](info): closing down fd 12 Not sure if that's helpful or not but it's something new (to me) so I thought I would add it to the case. Most unfortunately I need to access IPA to do some configuration changes so this is getting more unfortunate than just some errors in a log now. :-( Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From ayeja at uci.cu Wed Dec 21 20:59:56 2016 From: ayeja at uci.cu (=?utf-8?Q?Ing=2E_Adrian_Hern=C3=A1ndez?= Yeja) Date: Wed, 21 Dec 2016 15:59:56 -0500 (CST) Subject: [Freeipa-users] (trust domain AD) In-Reply-To: References: <307059444.1696642.1482338695692.JavaMail.zimbra@uci.cu> <140435579.1697103.1482339189401.JavaMail.zimbra@uci.cu> Message-ID: <1543393059.1714069.1482353996495.JavaMail.zimbra@uci.cu> Hi Youenn, thanks for your quick response. Actually I need to create a trust domain with an AD for disable NTLM auth and take advantage of FreeIPA. I thought to use Kerberos instead NTLM. It is possible to create a trust domain with AD and authenticate users with LDAP (FreeIPA)? ----- Mensaje original ----- De: "Youenn PIOLET" Para: "Ing. Adrian Hern?ndez Yeja" CC: freeipa-users at redhat.com Enviados: Mi?rcoles, 21 de Diciembre 2016 13:05:30 Asunto: Re: [Freeipa-users] (no subject) Hi Adrian, You can use basic_ldap_auth to connect to FreeIPA using LDAP instead of negotiate_kerberos_auth : auth_param basic program /usr/lib/squid3/basic_ldap_auth -R \ -b "cn=accounts,dc=example,dc=com" \ -f uid=%s -h -ZZ auth_param basic children 10 auth_param basic realm infra.msv auth_param basic credentialsttl 30 second Regards, -- Youenn Piolet piolet.y at gmail.com 2016-12-21 17:53 GMT+01:00 Ing. Adrian Hern?ndez Yeja < ayeja at uci.cu > : Hi folks, I need authenticate my users against a squid proxy server using FreeIPA. I know is possible ( https://www.freeipa.org/page/Squid_Integration_with_FreeIPA_using_Single_Sign_On ) but my users are not necessarily authenticated in a FreeIPA domain, so my question is if it's possible to allow this requirement either a third application or a specific configuration. Regards. La @universidad_uci es Fidel. Los j?venes no fallaremos. #HastaSiempreComandante #HastalaVictoriaSiempre -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project ?La @universidad_uci es Fidel. Los j?venes no fallaremos. #HastaSiempreComandante #HastalaVictoriaSiempre -------------- next part -------------- An HTML attachment was scrubbed... URL: From rstory at tislabs.com Wed Dec 21 21:26:27 2016 From: rstory at tislabs.com (Robert Story) Date: Wed, 21 Dec 2016 16:26:27 -0500 Subject: [Freeipa-users] backing up and starting over... Message-ID: <20161221162627.453d15b4@ispx.vb.futz.org> I'm running a small instance of freeipa on CentOS 7 in our lab, for about 20 machines. Since CentOS 7.3 came out and upgraded from 4.2 to 4.4, things have gotten flaky. e.g. clicking on a user get the spinning 'Working' dialog and can take 3-5 minutes to load the page. But often it will die with 'internal error'. Is there a way to back up data so that I can re-install 4.4 and restore the data? Specifically users+uids/groups+gids, HBAC and sudo rules? Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From abokovoy at redhat.com Thu Dec 22 07:12:55 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Dec 2016 09:12:55 +0200 Subject: [Freeipa-users] Windows 7 Authentication Failed with FreeIPA In-Reply-To: <585ac26e.833d630a.1cadb.974d@mx.google.com> References: <585ac26e.833d630a.1cadb.974d@mx.google.com> Message-ID: <20161222071255.4topkzshafxxh6l7@redhat.com> On ke, 21 joulu 2016, Jaril Nambiar wrote: >Hi Concern, > > > >This email is regarding an issue while using a workgroup Windows-7 client is >trying to login the freeIPA realm. It is showing 'There are currently no >log on server available to service the logon request' . The guide is to >setup for Windows XP. Am I able to create the same in Windows 7 client or >not. Requesting your support to fulfill my reuirement. Joining Windows clients to FreeIPA realm is not supported. Login to Windows clients with FreeIPA users is not supported. This is explained in the first link you referred to. Everything else in the first link is a hackish attempt with no promise to work. If it doesn't work, it doesn't. > > > >Referred Links: > >http://www.freeipa.org/page/Windows_authentication_against_FreeIPA > >http://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Win >dows/Linux)_-_Step_by_step > >https://mkosek.fedorapeople.org/publican_site/en-US/FreeIPA/3.4/html/FreeIPA >_Guide/Configuring_Microsoft_Windows.html > > > > > > > > > > > > > > > > > >Thank you, > >Jaril V V > >Ph: +91-9987027659 > >Email: jaril.nambiar at gmail.com > > > >-- >Manage your subscription for the Freeipa-users mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-users >Go to http://freeipa.org for more info on the project -- / Alexander Bokovoy From pspacek at redhat.com Thu Dec 22 07:24:40 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Dec 2016 08:24:40 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <1482352594.7132.18.camel@interlinx.bc.ca> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> <1482321907.28211.102.camel@interlinx.bc.ca> <1482332011.25536.2.camel@interlinx.bc.ca> <1482344567.7132.10.camel@interlinx.bc.ca> <1482352594.7132.18.camel@interlinx.bc.ca> Message-ID: <01d1c775-5945-2ca0-b180-1d78a61a5bd2@redhat.com> On 21.12.2016 21:36, Brian J. Murrell wrote: > Some additional information. I can't seem to use the CLI either. > Perhaps that is expected: > > # kinit admin > Password for admin at EXAMPLE.COM: > > # klist > Ticket cache: KEYRING:persistent:0:krb_ccache_3jm4X9m > Default principal: admin at EXAMPLE.COM > > Valid starting Expires Service principal > 21/12/16 15:29:20 22/12/16 15:29:17 krbtgt/EXAMPLE.COM at EXAMPLE.COM > > # ipa host-find > ipa: ERROR: Insufficient access: Invalid credentials > > When I do that (the ipa host-find) /var/log/krb5kdc.log says: > > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) fd31:aeb1:48df:0:214:d1ff:fe13:45ac: ISSUE: authtime 1482352160, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for HTTP/server.example.com at EXAMPLE.COM > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): closing down fd 12 > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) fd31:aeb1:48df:0:214:d1ff:fe13:45ac: ISSUE: authtime 1482352160, etypes {rep=18 tkt=18 ses=18}, HTTP/server.example.com at EXAMPLE.COM for ldap/server.example.com at EXAMPLE.COM > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): ... CONSTRAINED-DELEGATION s4u-client=admin at EXAMPLE.COM > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): closing down fd 12 > > Not sure if that's helpful or not but it's something new (to me) so I > thought I would add it to the case. > > Most unfortunately I need to access IPA to do some configuration > changes so this is getting more unfortunate than just some errors in a > log now. :-( Yes, this will be manifestation of the same problem. Interestingly the LDAP server should use the ds.keytab file instead of krb5.keytab. We need someone from DS team of with deep Kerberos/gssproxy knowledge to look into it. Simo, Ludwig, how can this happen? -- Petr^2 Spacek From abokovoy at redhat.com Thu Dec 22 07:30:36 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Dec 2016 09:30:36 +0200 Subject: [Freeipa-users] IPA Services In-Reply-To: References: Message-ID: <20161222073036.n34nkibftbftvbx6@redhat.com> On ke, 21 joulu 2016, Callum Guy wrote: >Hi All, > >I am looking to find out all the services which FreeIPA has installed and >which must be up and running as part of normal operations. I am clear on >the various systems which have been installed on the master server (we run >no replicas) however I'm not sure what resource I should refer to in order >to improve my understanding. > >To get started on this I have retrieved a list of running services using >"systemctl -t service". > >Our installation is working pretty well and although we have been >experiencing the odd stability issue we had believed that this is due to >wider platform changes rather than any issues with the installation. In the >service list I am seeing lots of duplicate and failed services and it is >not clear how to interpret the output and whether this is to be expected? > >The attached screenshot should explain my question. > >Can anyone offer any guidance for the severity of this issue? The most >pressing question is how/why we have multiple 389 instances for various >casings of our domain. The other issue is the large number of OTP service >daemons - is that an issue?! Multiple 389-ds instances look like an error on your side -- IPA installer does not setup more than one 389-ds instance at all in versions which run on the systemd-enabled systems. Perhaps, these were unfinished failed installation attempts where install failed in the middle and no clean-up was done, though I can't imagine how that couldn't cause a trigger in ipa-server-install as it actually checks if there was already an IPA master configured on the same host. As to ipa-otpd, this is expected -- ipa-otpd uses socket activation and is launched on demand whenever Kerberos KDC needs it. If you have multiple KDC threads (default is one per CPU core), you get as many ipa-otpd instances launched too. -- / Alexander Bokovoy From flo at redhat.com Thu Dec 22 08:25:52 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 22 Dec 2016 09:25:52 +0100 Subject: [Freeipa-users] backing up and starting over... In-Reply-To: <20161221162627.453d15b4@ispx.vb.futz.org> References: <20161221162627.453d15b4@ispx.vb.futz.org> Message-ID: On 12/21/2016 10:26 PM, Robert Story wrote: > I'm running a small instance of freeipa on CentOS 7 in our lab, for about 20 > machines. Since CentOS 7.3 came out and upgraded from 4.2 to 4.4, things > have gotten flaky. e.g. clicking on a user get the spinning 'Working' > dialog and can take 3-5 minutes to load the page. But often it will die > with 'internal error'. > > Is there a way to back up data so that I can re-install 4.4 and restore the > data? Specifically users+uids/groups+gids, HBAC and sudo rules? > > > Robert > > > Hi, you can find more information about backup and restore procedure in this guide [1]. But, as stated in the documentation, the safest method would rather be to install a replica [2]. HTH, Flo [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/backup-restore.html [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-replica.html From georgijsr at scandiweb.com Thu Dec 22 08:31:46 2016 From: georgijsr at scandiweb.com (Georgijs Radovs) Date: Thu, 22 Dec 2016 10:31:46 +0200 Subject: [Freeipa-users] FreeIPA 4.4 - Can't find topology segment, nsunique attribute Message-ID: <32fd2114-85c1-c84c-d5ab-dc2c7e7cbd68@scandiweb.com> Hello everyone! Today, I've updated 2 FreeIPA servers from version 4.2 to version 4.4. Both of these servers are Masters and CAs, both are replicating between each other. But, when I run *ipa topologysegment-find* to view replication agreements for *domain* and *ca* suffixes it returns zero results. Web UI also does not show any agreements, but when I try to create a replication agreement between both servers, I get error that agreement already exists. Also, when viewing directory using ldap browser, I found these containers: DN: cn=ca+nsuniqueid=7252d047-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com DN: cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com Both of them contain topology segments, which I'm trying to create, but they do not show up anywhere. How do I remove nsuniqueid attribute or delete those containers? -- From md at collective-sense.com Thu Dec 22 08:37:25 2016 From: md at collective-sense.com (Maciej Drobniuch) Date: Thu, 22 Dec 2016 09:37:25 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> Message-ID: Hi Martin Thank you for reply. 1. The dig is returning proper PTR record. I've added it manually to the zone and it's working. 2. The problem exists while adding host entries or A records with "create reverse" option. 3. If I'll bind a host with ipa-client-install the PTR record gets created in the reverse zone and it works 4. The resolv.conf file has only the IPA server IP addres/localhost added. Cheers! M. On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti wrote: > Hello all :) > > On 20.12.2016 01:33, Maciej Drobniuch wrote: > > Hi All! > > I get the following message while adding a new hostname. > > "The host was added but the DNS update failed with: DNS reverse zone > in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" > > > IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165 what > will be in SOA answer? > > What is the name of reverse zone you have on IPA DNS server? > > > Martin > > > The reverse zone is configured and working. > When I am manually adding the PTR record to the reverse zone - all OK > > While adding a new host, the A record is being created but the PTR fails > with the message above. > > Reinstalling centos+IPA worked once but I had to reinstall again because > of problems with kerberos(probably dependencies). > > Not sure what is the root cause of the issue. > > VERSION: 4.4.0, API_VERSION: 2.213 > > CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC > 2015 x86_64 x86_64 x86_64 GNU/Linux > > Any help appreciated! > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-sense LLC > > > > -- Best regards Maciej Drobniuch Network Security Engineer Collective-sense LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo at redhat.com Thu Dec 22 08:54:35 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 22 Dec 2016 09:54:35 +0100 Subject: [Freeipa-users] Ipa cert automatic renew Failing. In-Reply-To: References: Message-ID: On 12/21/2016 07:52 PM, Lucas Diedrich wrote: > Hello guys, > > I'm having some trouble with, whats is happening with my server is that > i'm hiting an old BUG > (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to mbasti > over irc he oriented me to send this to the email list. > > The problem is, i got on CA Master, so because of this problem the CA > Master certificates couldn't be renewd, so now i promoted another master > to be the CA. And the problem still persist. > > This is the certs from my new CA > (https://paste.fedoraproject.org/510617/14823448/), > this is the certs from my old CA > (https://paste.fedoraproject.org/510618/44871148/) > This is the log then i restart pki-tomcat( "CA port 636 Error > netscape.ldap.LDAPException: Authentication failed (49)") > This is the log from dirsrv when i restart pki-tomcat > (https://paste.fedoraproject.org/510614/23446801/) > > Basically my CA is not working anymore... > > Anyway, i tried lots of thing but couldn't fix this, anyone has some idea? > > > Hi, Pki-tomcat is using the LDAP server as a data store, meaning that it needs to authenticate to LDAP. In order to do that, pki-tomcat is using the certificate 'subsystemCert cert-pki-ca' stored in /etc/pki/pki-tomcat/alias. For the authentication to succeed, the certificate must be stored in a user entry (uid=pkidbuser,ou=people,o=ipaca). Can you check the content of this entry, especially the usercertificate attribute? It should match the certificate used by pki-tomcat: $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- $ kinit admin $ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate dn: uid=pkidbuser,ou=people,o=ipaca usercertificate:: The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this certificate in the directive ca.subsystem.cert. A possible cause for the entries not being updated is the bug 1366915 [1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE linux on Fedora 24. Flo [1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188 From mbabinsk at redhat.com Thu Dec 22 09:01:23 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 22 Dec 2016 10:01:23 +0100 Subject: [Freeipa-users] FreeIPA 4.4 - Can't find topology segment, nsunique attribute In-Reply-To: <32fd2114-85c1-c84c-d5ab-dc2c7e7cbd68@scandiweb.com> References: <32fd2114-85c1-c84c-d5ab-dc2c7e7cbd68@scandiweb.com> Message-ID: On 12/22/2016 09:31 AM, Georgijs Radovs wrote: > Hello everyone! > > Today, I've updated 2 FreeIPA servers from version 4.2 to version 4.4. > > Both of these servers are Masters and CAs, both are replicating between > each other. > > But, when I run > > *ipa topologysegment-find* to view replication agreements for *domain* > and *ca* suffixes > > it returns zero results. > > Web UI also does not show any agreements, but when I try to create a > replication agreement between both servers, I get error that agreement > already exists. > > Also, when viewing directory using ldap browser, I found these containers: > > DN: > cn=ca+nsuniqueid=7252d047-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com > > > DN: > cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com > > > Both of them contain topology segments, which I'm trying to create, but > they do not show up anywhere. > > How do I remove nsuniqueid attribute or delete those containers? > Hi Georgijs, these entries come from replication conflicts, please see the following guide on how to solve them: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html Also as a side note, such conflicts may come from upgrading IPA masters at once which is not recommended. Make sure that when you upgrade the topology you only upgrade one master at time. -- Martin^3 Babinsky From mbabinsk at redhat.com Thu Dec 22 09:06:23 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 22 Dec 2016 10:06:23 +0100 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <1482344567.7132.10.camel@interlinx.bc.ca> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> <1482321907.28211.102.camel@interlinx.bc.ca> <1482332011.25536.2.camel@interlinx.bc.ca> <1482344567.7132.10.camel@interlinx.bc.ca> Message-ID: <7d7c9cfb-c580-deec-3845-f7c8e97986bf@redhat.com> On 12/21/2016 07:22 PM, Brian J. Murrell wrote: > On Wed, 2016-12-21 at 17:50 +0100, Petr Spacek wrote: >> Okay, I believe that this is the problem: >> >> On 21.12.2016 15:53, Brian J. Murrell wrote: >>> [21/Dec/2016:09:39:12.003351818 -0500] conn=77028 fd=107 slot=107 >>> connection from local to /var/run/slapd-EXAMPLE.COM.socket >> >> ... >>> [21/Dec/2016:09:39:12.064476101 -0500] conn=77028 op=0 BIND dn="" >>> method=sasl version=3 mech=GSSAPI >>> [21/Dec/2016:09:39:12.067486416 -0500] conn=77028 op=0 RESULT >>> err=49 tag=97 nentries=0 etime=0 - SASL(-1): generic failure: >>> GSSAPI Error: Unspecified GSS failure. Minor code may provide more >>> information (Permission denied) >>> [21/Dec/2016:09:39:12.192506861 -0500] conn=77028 op=1 UNBIND >>> [21/Dec/2016:09:39:12.192549740 -0500] conn=77028 op=1 fd=107 >>> closed - U1 >> >> I have no idea why it is returning Permission denied. >> >> Is it reproducible when you run this? >> $ kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab >> ipa-dnskeysyncd/server.example.com >> $ ldapsearch -Y GSSAPI -H /var/run/slapd-EXAMPLE.COM.socket >> ? > > # klist > Ticket cache: KEYRING:persistent:0:0 > Default principal: ipa-dnskeysyncd/server.example.com at EXAMPLE.COM > > Valid starting Expires Service principal > 21/12/16 13:05:16 22/12/16 13:02:12 ldap/server.example.com at EXAMPLE.COM > 21/12/16 13:02:12 22/12/16 13:02:12 krbtgt/EXAMPLE.COM at EXAMPLE.COM > > # ldapsearch -Y GSSAPI -H ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE.COM.socket > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Invalid credentials (49) > >> >> We need to find out why it is blowing up on GSSAPI negotiation. >> >> Wild guess is that /etc/dirsrv/ds.keytab could have wrong >> permissions. It >> should have >> -rw-------. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 > > # ls -lZ /etc/dirsrv/ds.keytab > -rw-------. dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 /etc/dirsrv/ds.keytab > >> If you manage to reproduce it, you can attach strace to the running >> dirsrv > > By that I assume you mean the ns-slapd. > > The strace (minus poll/select/futex noise) is attached. > >> > process and see what call is failing (if it is a system call)... > > Perhaps this one: > > [pid 13449] open("/etc/krb5.keytab", O_RDONLY) = -1 EACCES (Permission denied) > > # ls -lZ /etc/krb5.keytab > -rw-------. root root system_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab > > But looking into the backup of this system, even a week and a month > ago, that file had the same permissions/ownership. And changing it to > 644 temporarily doesn't fix the "ldap_sasl_interactive_bind_s: Invalid > credentials (49)" from ldapsearch. > > Cheers, > b. > > > Hi Brian, DS should use /etc/sysconfig/dirsrv to set its KRB5_KTNAME env variable to /etc/dirsrv/ds.keytab. I guess that it cannot get this info from the file, thus it falls back to Kerberos library default which is /etc/krb5.keytab. That obviosuly fails because it is accesible only to root and contains keys only to host/, nfs/, and cifs/ (if you have Samba) principals. Can you please verify that /etc/sysconfig/dirsrv file exists and that it contains the following lines?: KRB5_CCNAME=/tmp/krb5cc_389 KRB5_KTNAME=/etc/dirsrv/ds.keytab If not, please add this line to the file, restart dirsrv and try IPA commands again. -- Martin^3 Babinsky From lkrispen at redhat.com Thu Dec 22 09:10:40 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 22 Dec 2016 10:10:40 +0100 Subject: [Freeipa-users] FreeIPA 4.4 - Can't find topology segment, nsunique attribute In-Reply-To: <32fd2114-85c1-c84c-d5ab-dc2c7e7cbd68@scandiweb.com> References: <32fd2114-85c1-c84c-d5ab-dc2c7e7cbd68@scandiweb.com> Message-ID: <585B9890.9050702@redhat.com> Hi On 12/22/2016 09:31 AM, Georgijs Radovs wrote: > Hello everyone! > > Today, I've updated 2 FreeIPA servers from version 4.2 to version 4.4. > > Both of these servers are Masters and CAs, both are replicating > between each other. > > But, when I run > > *ipa topologysegment-find* to view replication agreements for *domain* > and *ca* suffixes > > it returns zero results. > > Web UI also does not show any agreements, but when I try to create a > replication agreement between both servers, I get error that agreement > already exists. > > Also, when viewing directory using ldap browser, I found these > containers: > > DN: > cn=ca+nsuniqueid=7252d047-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com > > DN: > cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com > > Both of them contain topology segments, which I'm trying to create, > but they do not show up anywhere. this is unfortunatly the result of raising the domainlevel and creating segments while replication conflict entries exist. In the next update we will prevent this by checking for conflicts before raising domainlevel. > > How do I remove nsuniqueid attribute or delete those containers? not so simple, I'll try to sketch the options for cn=domain, the procedure for cn=ca is then the same. So lets say you have: cn=domain,cn=topology,cn=ipa,cn=etc,dc=example,dc=com cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com cn=segment1,cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com and what you want is: cn=domain,cn=topology,cn=ipa,cn=etc,dc=example,dc=com cn=segment1,cn=domain,cn=topology,cn=ipa,cn=etc,dc=example,dc=com unfortunately the segment is below the conflict entry. so you have two options: - remove the "normal" entry and then rename the conflict entry, this will leave child parent relationship and the dn of the segment should be adjusted automatically - move the segment to the "normal" entry (it could be rejected by the topology plugin, so you would have to disable it temporariliy on the server where you run this) and then remove the "conflict" entry -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander From georgijsr at scandiweb.com Thu Dec 22 09:41:45 2016 From: georgijsr at scandiweb.com (Georgijs Radovs) Date: Thu, 22 Dec 2016 11:41:45 +0200 Subject: [Freeipa-users] FreeIPA 4.4 - Can't find topology segment, nsunique attribute In-Reply-To: References: <32fd2114-85c1-c84c-d5ab-dc2c7e7cbd68@scandiweb.com> Message-ID: <967d645b-9da1-2bf4-e849-ef92500181d7@scandiweb.com> Hello, Martin! Thank you for your help, conflicts resolved. All is well. FreeIPA is awesome! ) On 2016.12.22. 11:01, Martin Babinsky wrote: > On 12/22/2016 09:31 AM, Georgijs Radovs wrote: >> Hello everyone! >> >> Today, I've updated 2 FreeIPA servers from version 4.2 to version 4.4. >> >> Both of these servers are Masters and CAs, both are replicating between >> each other. >> >> But, when I run >> >> *ipa topologysegment-find* to view replication agreements for *domain* >> and *ca* suffixes >> >> it returns zero results. >> >> Web UI also does not show any agreements, but when I try to create a >> replication agreement between both servers, I get error that agreement >> already exists. >> >> Also, when viewing directory using ldap browser, I found these >> containers: >> >> DN: >> cn=ca+nsuniqueid=7252d047-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com >> >> >> >> DN: >> cn=domain+nsuniqueid=7252d000-c76611e6-a1fcaefe-5d4473a3,cn=topology,cn=ipa,cn=etc,dc=example,dc=com >> >> >> >> Both of them contain topology segments, which I'm trying to create, but >> they do not show up anywhere. >> >> How do I remove nsuniqueid attribute or delete those containers? >> > > Hi Georgijs, > > these entries come from replication conflicts, please see the > following guide on how to solve them: > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > > > Also as a side note, such conflicts may come from upgrading IPA > masters at once which is not recommended. Make sure that when you > upgrade the topology you only upgrade one master at time. > -- From mbasti at redhat.com Thu Dec 22 09:48:36 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Dec 2016 10:48:36 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> Message-ID: On 22.12.2016 09:37, Maciej Drobniuch wrote: > Hi Martin > > Thank you for reply. > > 1. The dig is returning proper PTR record. I've added it manually to > the zone and it's working. I was asking for SOA and zone name, IMO there is nothing secret about reverse zone name from private address space what returns this command on server? python -c 'import netaddr; from dns import resolver; ip = netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; print resolver.zone_for_name(revn)' > 2. The problem exists while adding host entries or A records with > "create reverse" option. That's why I asked to run dig, the code uses DNS system to determine zone. > 3. If I'll bind a host with ipa-client-install the PTR record gets > created in the reverse zone and it works Ok > 4. The resolv.conf file has only the IPA server IP addres/localhost added. Have you changed it recently? Martin > > Cheers! > M. > > On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti > wrote: > > Hello all :) > > > On 20.12.2016 01:33, Maciej Drobniuch wrote: >> Hi All! >> >> I get the following message while adding a new hostname. >> >> "The host was added but the DNS update failed with: DNS reverse >> zone in-addr.arpa. for IP address 10.0.0.165 is not managed by >> this server" > > IPA failed to get correct reverse zone, can you try dig -x > 10.0.0.165 what will be in SOA answer? > > What is the name of reverse zone you have on IPA DNS server? > > > Martin > >> >> The reverse zone is configured and working. >> When I am manually adding the PTR record to the reverse zone - all OK >> >> While adding a new host, the A record is being created but the >> PTR fails with the message above. >> >> Reinstalling centos+IPA worked once but I had to reinstall again >> because of problems with kerberos(probably dependencies). >> >> Not sure what is the root cause of the issue. >> >> VERSION: 4.4.0, API_VERSION: 2.213 >> >> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 >> 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> Any help appreciated! >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-sense LLC >> >> > > > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-sense LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at collective-sense.com Thu Dec 22 09:57:23 2016 From: md at collective-sense.com (Maciej Drobniuch) Date: Thu, 22 Dec 2016 10:57:23 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> Message-ID: Hi Martin Appreciate your help! On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti wrote: > > > On 22.12.2016 09:37, Maciej Drobniuch wrote: > > Hi Martin > > Thank you for reply. > > 1. The dig is returning proper PTR record. I've added it manually to the > zone and it's working. > > > I was asking for SOA and zone name, IMO there is nothing secret about > reverse zone name from private address space > > what returns this command on server? > python -c 'import netaddr; from dns import resolver; ip = > netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; print > resolver.zone_for_name(revn)' > > > # python -c 'import netaddr; from dns import resolver; ip = netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; print resolver.zone_for_name(revn)' 165.0.0.10.in-addr.arpa. in-addr.arpa. 2. The problem exists while adding host entries or A records with "create > reverse" option. > > That's why I asked to run dig, the code uses DNS system to determine zone. > > 3. If I'll bind a host with ipa-client-install the PTR record gets created > in the reverse zone and it works > > Ok > Manually creating the PTR record works fine as well. > > > 4. The resolv.conf file has only the IPA server IP addres/localhost added. > > > Have you changed it recently? > Yes, it pointed to outside 8.8.8.8, so the OS did not see the local reverse zone. Now it's pointing to localhost. And I get dig the PTRs. (I've manually created the ptr) # dig -x 10.0.0.165 ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;165.0.0.10.in-addr.arpa. IN PTR ;; ANSWER SECTION: 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int. ;; AUTHORITY SECTION: 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int. ;; ADDITIONAL SECTION: freeipa1.cs.int. 1200 IN A 10.0.0.200 ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: czw gru 22 04:51:23 EST 2016 ;; MSG SIZE rcvd: 124 > > > Martin > > > > Cheers! > M. > > On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti wrote: > >> Hello all :) >> >> On 20.12.2016 01:33, Maciej Drobniuch wrote: >> >> Hi All! >> >> I get the following message while adding a new hostname. >> >> "The host was added but the DNS update failed with: DNS reverse zone >> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" >> >> >> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165 >> what will be in SOA answer? >> >> What is the name of reverse zone you have on IPA DNS server? >> >> >> Martin >> >> >> The reverse zone is configured and working. >> When I am manually adding the PTR record to the reverse zone - all OK >> >> While adding a new host, the A record is being created but the PTR fails >> with the message above. >> >> Reinstalling centos+IPA worked once but I had to reinstall again because >> of problems with kerberos(probably dependencies). >> >> Not sure what is the root cause of the issue. >> >> VERSION: 4.4.0, API_VERSION: 2.213 >> >> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 >> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> >> Any help appreciated! >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-sense LLC >> >> >> >> > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-sense LLC > > > -- Best regards Maciej Drobniuch Network Security Engineer 2410 Camino Ramon, Suite 129 San Ramon, CA 94583 -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.candler at pobox.com Thu Dec 22 11:42:01 2016 From: b.candler at pobox.com (Brian Candler) Date: Thu, 22 Dec 2016 11:42:01 +0000 Subject: [Freeipa-users] NTLM SASL? Message-ID: <66200f76-5b0a-c622-17a0-08b130edc42a@pobox.com> Question: does FreeIPA (or specifically the 389 directory server) implement the NTLM SASL mechanism? It appears not at first attempt: # yum install cyrus-sasl-ntlm # ldapsearch -Y NTLM SASL/NTLM authentication started ldap_sasl_interactive_bind_s: Authentication method not supported (7) additional info: sasl mechanism not supported Now, under cn=config, I see: nsslapd-allowed-sasl-mechanisms: (i.e. empty). I tried changing this to "NTLM" and it accepted the change. If I try changing it to "ntlm" I get "Server is unwilling to perform" - which is a good sign, since clearly "NTLM" is valid. However even after restarting the server, I still get "sasl mechanism not supported" when I try the bind. -=-=-=- The reason I'm asking: I'm using FreeRADIUS for MSCHAP authentication, and one of the things MSCHAP supports is a password change feature for expired passwords. FreeRADIUS lets me shell out to an external process to perform the password change: local_cpw = "%{exec:/usr/local/sbin/freeipa-passwd '%{mschap:User-Name}' '%{MS-CHAP-New-Cleartext-Password}' '%{control:NT-Password}'" Now, the last argument is the user's *old* NTLM password hash. So ideally I would use this to authenticate to the FreeIPA server to perform the password change - this would avoid the freeipa-passwd script having to have any privileged credentials of its own. But the only way I can think of doing that would be via a SASL NTLM bind. Regards, Brian. From mbasti at redhat.com Thu Dec 22 12:02:18 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Dec 2016 13:02:18 +0100 Subject: [Freeipa-users] backing up and starting over... In-Reply-To: References: <20161221162627.453d15b4@ispx.vb.futz.org> Message-ID: Hello, can you elaborate more about errors? On 22.12.2016 09:25, Florence Blanc-Renaud wrote: > On 12/21/2016 10:26 PM, Robert Story wrote: >> I'm running a small instance of freeipa on CentOS 7 in our lab, for >> about 20 >> machines. Since CentOS 7.3 came out and upgraded from 4.2 to 4.4, things >> have gotten flaky. e.g. clicking on a user get the spinning 'Working' >> dialog and can take 3-5 minutes to load the page. But often it will die >> with 'internal error'. Could you check in /var/log/httpd/error_log what is it? Does cli work well? ipa user-find Martin >> >> Is there a way to back up data so that I can re-install 4.4 and >> restore the >> data? Specifically users+uids/groups+gids, HBAC and sudo rules? >> >> >> Robert >> >> >> > Hi, > > you can find more information about backup and restore procedure in > this guide [1]. But, as stated in the documentation, the safest method > would rather be to install a replica [2]. > > HTH, > Flo > > [1] > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/backup-restore.html > [2] > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-replica.html > From lucas.diedrich at gmail.com Thu Dec 22 12:15:02 2016 From: lucas.diedrich at gmail.com (Lucas Diedrich) Date: Thu, 22 Dec 2016 12:15:02 +0000 Subject: [Freeipa-users] Ipa cert automatic renew Failing. In-Reply-To: References: Message-ID: Florence, for some creepy reason the cert from pkidbuser is different from subsystem certs, and this pkidbuser is outdated now, but i can't manage one way to re-issue it. I had to change the CA server because of that, and the Selinux in the old CA Server was disabled, on the new one is in Permissive mode but doesn't a warning in /var/log/audit/audit.log. This is the pkidbuser cert: https://paste.fedoraproject.org/511023/24084431/ This is the subsystem cert: https://paste.fedoraproject.org/511025/14824085/ The ca.subsystem.cert matches the pkidbuser cert. lucasdiedrich. Em qui, 22 de dez de 2016 ?s 06:54, Florence Blanc-Renaud escreveu: > On 12/21/2016 07:52 PM, Lucas Diedrich wrote: > > Hello guys, > > > > I'm having some trouble with, whats is happening with my server is that > > i'm hiting an old BUG > > (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to mbasti > > over irc he oriented me to send this to the email list. > > > > The problem is, i got on CA Master, so because of this problem the CA > > Master certificates couldn't be renewd, so now i promoted another master > > to be the CA. And the problem still persist. > > > > This is the certs from my new CA > > (https://paste.fedoraproject.org/510617/14823448/), > > this is the certs from my old CA > > (https://paste.fedoraproject.org/510618/44871148/) > > This is the log then i restart pki-tomcat( "CA port 636 Error > > netscape.ldap.LDAPException: Authentication failed (49)") > > This is the log from dirsrv when i restart pki-tomcat > > (https://paste.fedoraproject.org/510614/23446801/) > > > > Basically my CA is not working anymore... > > > > Anyway, i tried lots of thing but couldn't fix this, anyone has some > idea? > > > > > > > Hi, > > Pki-tomcat is using the LDAP server as a data store, meaning that it > needs to authenticate to LDAP. In order to do that, pki-tomcat is using > the certificate 'subsystemCert cert-pki-ca' stored in > /etc/pki/pki-tomcat/alias. For the authentication to succeed, the > certificate must be stored in a user entry > (uid=pkidbuser,ou=people,o=ipaca). > > Can you check the content of this entry, especially the usercertificate > attribute? It should match the certificate used by pki-tomcat: > > $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' > -a > -----BEGIN CERTIFICATE----- > [...] > -----END CERTIFICATE----- > > $ kinit admin > $ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate > dn: uid=pkidbuser,ou=people,o=ipaca > usercertificate:: > > The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this > certificate in the directive ca.subsystem.cert. > > > A possible cause for the entries not being updated is the bug 1366915 > [1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE linux > on Fedora 24. > > Flo > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Dec 22 12:23:03 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 Dec 2016 07:23:03 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <01d1c775-5945-2ca0-b180-1d78a61a5bd2@redhat.com> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> <1482321907.28211.102.camel@interlinx.bc.ca> <1482332011.25536.2.camel@interlinx.bc.ca> <1482344567.7132.10.camel@interlinx.bc.ca> <1482352594.7132.18.camel@interlinx.bc.ca> <01d1c775-5945-2ca0-b180-1d78a61a5bd2@redhat.com> Message-ID: <1482409383.3801.36.camel@redhat.com> On Thu, 2016-12-22 at 08:24 +0100, Petr Spacek wrote: > On 21.12.2016 21:36, Brian J. Murrell wrote: > > Some additional information. I can't seem to use the CLI either. > > Perhaps that is expected: > > > > # kinit admin > > Password for admin at EXAMPLE.COM: > > > > # klist > > Ticket cache: KEYRING:persistent:0:krb_ccache_3jm4X9m > > Default principal: admin at EXAMPLE.COM > > > > Valid starting Expires Service principal > > 21/12/16 15:29:20 22/12/16 15:29:17 krbtgt/EXAMPLE.COM at EXAMPLE.COM > > > > # ipa host-find > > ipa: ERROR: Insufficient access: Invalid credentials > > > > When I do that (the ipa host-find) /var/log/krb5kdc.log says: > > > > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) fd31:aeb1:48df:0:214:d1ff:fe13:45ac: ISSUE: authtime 1482352160, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for HTTP/server.example.com at EXAMPLE.COM > > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): closing down fd 12 > > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) fd31:aeb1:48df:0:214:d1ff:fe13:45ac: ISSUE: authtime 1482352160, etypes {rep=18 tkt=18 ses=18}, HTTP/server.example.com at EXAMPLE.COM for ldap/server.example.com at EXAMPLE.COM > > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): ... CONSTRAINED-DELEGATION s4u-client=admin at EXAMPLE.COM > > Dec 21 15:29:28 server.example.com krb5kdc[13548](info): closing down fd 12 > > > > Not sure if that's helpful or not but it's something new (to me) so I > > thought I would add it to the case. > > > > Most unfortunately I need to access IPA to do some configuration > > changes so this is getting more unfortunate than just some errors in a > > log now. :-( > > Yes, this will be manifestation of the same problem. Interestingly the LDAP > server should use the ds.keytab file instead of krb5.keytab. > > We need someone from DS team of with deep Kerberos/gssproxy knowledge to look > into it. > > Simo, Ludwig, how can this happen? As Martin said, incorrect configuration of DS makes it fall back to use the default keytab. Either /etc/sysconfig/dirsrv or the DS systemd unit file must specify the correct keytab in the KRB5_KTNAME environment variable. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Thu Dec 22 12:36:47 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Dec 2016 14:36:47 +0200 Subject: [Freeipa-users] NTLM SASL? In-Reply-To: <66200f76-5b0a-c622-17a0-08b130edc42a@pobox.com> References: <66200f76-5b0a-c622-17a0-08b130edc42a@pobox.com> Message-ID: <20161222123647.wmj3fwbfyknq5wig@redhat.com> On to, 22 joulu 2016, Brian Candler wrote: >Question: does FreeIPA (or specifically the 389 directory server) >implement the NTLM SASL mechanism? No, it doesn't. Even if you install cyrus-sasl-ntlm module, 389-ds will not be able to authenticate: [22/Dec/2016:14:16:08.920773153 +0200] conn=20 fd=109 slot=109 SSL connection from 192.168.5.196 to 192.168.5.196 [22/Dec/2016:14:16:08.926439405 +0200] conn=20 TLS1.2 128-bit AES [22/Dec/2016:14:16:08.929793115 +0200] conn=20 op=0 BIND dn="uid=foobar,cn=users,cn=accounts,dc=split,dc=test" method=sasl version=3 mech=NTLM [22/Dec/2016:14:16:08.930458789 +0200] conn=20 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [22/Dec/2016:14:16:11.841985315 +0200] conn=20 op=1 BIND dn="uid=foobar,cn=users,cn=accounts,dc=split,dc=test" method=sasl version=3 mech=NTLM [22/Dec/2016:14:16:11.843719821 +0200] conn=20 op=1 RESULT err=49 tag=97 nentries=0 etime=0 - SASL(-14): authorization failure: [22/Dec/2016:14:16:11.843761905 +0200] conn=20 op=2 UNBIND [22/Dec/2016:14:16:11.843771888 +0200] conn=20 op=2 fd=109 closed - U1 The reason for that is due to how SASL support is implemented in 389-ds: it only supports those SASL mechanisms which don't require direct access to the userPassword attribute (GSSAPI). Alternatively, if userPassword contains a clear-text password, those SASL mechanisms that require access to the clear text password will also work. FreeIPA does not store clear text password, so no chance for SASL DIGEST-MD5 or SASL NTLM. >-=-=-=- > >The reason I'm asking: I'm using FreeRADIUS for MSCHAP authentication, >and one of the things MSCHAP supports is a password change feature for >expired passwords. FreeRADIUS lets me shell out to an external process >to perform the password change: > > local_cpw = "%{exec:/usr/local/sbin/freeipa-passwd >'%{mschap:User-Name}' '%{MS-CHAP-New-Cleartext-Password}' >'%{control:NT-Password}'" > >Now, the last argument is the user's *old* NTLM password hash. So >ideally I would use this to authenticate to the FreeIPA server to >perform the password change - this would avoid the freeipa-passwd >script having to have any privileged credentials of its own. > >But the only way I can think of doing that would be via a SASL NTLM bind. Sorry, this is not going to work. -- / Alexander Bokovoy From mbasti at redhat.com Thu Dec 22 12:41:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Dec 2016 13:41:44 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> Message-ID: On 22.12.2016 10:57, Maciej Drobniuch wrote: > Hi Martin > > Appreciate your help! > > On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti > wrote: > > > > On 22.12.2016 09:37, Maciej Drobniuch wrote: >> Hi Martin >> >> Thank you for reply. >> >> 1. The dig is returning proper PTR record. I've added it manually >> to the zone and it's working. > > I was asking for SOA and zone name, IMO there is nothing secret > about reverse zone name from private address space > > what returns this command on server? > python -c 'import netaddr; from dns import resolver; ip = > netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print > revn; print resolver.zone_for_name(revn)' > > > # python -c 'import netaddr; from dns import resolver; ip = > netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; > print resolver.zone_for_name(revn)' > 165.0.0.10.in-addr.arpa. > in-addr.arpa. It looks that python-dns failed to find proper zone, what is supposed to be authoritative zone for that record in your system? How do your reverse zones look? > >> 2. The problem exists while adding host entries or A records with >> "create reverse" option. > That's why I asked to run dig, the code uses DNS system to > determine zone. > >> 3. If I'll bind a host with ipa-client-install the PTR record >> gets created in the reverse zone and it works > Ok > > Manually creating the PTR record works fine as well. > > > >> 4. The resolv.conf file has only the IPA server IP >> addres/localhost added. > > Have you changed it recently? > > Yes, it pointed to outside 8.8.8.8, so the OS did not see the local > reverse zone. > Now it's pointing to localhost. And I get dig the PTRs. (I've manually > created the ptr) > > # dig -x 10.0.0.165 > > ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 > > ;; OPT PSEUDOSECTION: > ; E: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;165.0.0.10.in-addr.arpa.INPTR > > ;; ANSWER SECTION: > 165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int > . > > ;; AUTHORITY SECTION: > 1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int . > This authority section looks suspicious, I would expect something like 0.0.10.in-addr.arpa. Back to question about your reverse zones. > ;; ADDITIONAL SECTION: > freeipa1.cs.int .1200INA10.0.0.200 > > ;; Query time: 3 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: czw gru 22 04:51:23 EST 2016 > ;; MSG SIZE rcvd: 124 > > > > Martin > > >> >> Cheers! >> M. >> >> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti > > wrote: >> >> Hello all :) >> >> >> On 20.12.2016 01:33, Maciej Drobniuch wrote: >>> Hi All! >>> >>> I get the following message while adding a new hostname. >>> >>> "The host was added but the DNS update failed with: DNS >>> reverse zone in-addr.arpa. for IP address 10.0.0.165 is not >>> managed by this server" >> >> IPA failed to get correct reverse zone, can you try dig -x >> 10.0.0.165 what will be in SOA answer? >> >> What is the name of reverse zone you have on IPA DNS server? >> >> >> Martin >> >>> >>> The reverse zone is configured and working. >>> When I am manually adding the PTR record to the reverse zone >>> - all OK >>> >>> While adding a new host, the A record is being created but >>> the PTR fails with the message above. >>> >>> Reinstalling centos+IPA worked once but I had to reinstall >>> again because of problems with kerberos(probably dependencies). >>> >>> Not sure what is the root cause of the issue. >>> >>> VERSION: 4.4.0, API_VERSION: 2.213 >>> >>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar >>> 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> >>> Any help appreciated! >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> Collective-sense LLC >>> >>> >> >> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-sense LLC > > > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > 2410 Camino Ramon, Suite 129 > San Ramon, CA 94583 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Dec 22 12:48:35 2016 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 Dec 2016 07:48:35 -0500 Subject: [Freeipa-users] NTLM SASL? In-Reply-To: <66200f76-5b0a-c622-17a0-08b130edc42a@pobox.com> References: <66200f76-5b0a-c622-17a0-08b130edc42a@pobox.com> Message-ID: <1482410915.3801.40.camel@redhat.com> On Thu, 2016-12-22 at 11:42 +0000, Brian Candler wrote: > Question: does FreeIPA (or specifically the 389 directory server) > implement the NTLM SASL mechanism? > > It appears not at first attempt: > > # yum install cyrus-sasl-ntlm > # ldapsearch -Y NTLM > SASL/NTLM authentication started > ldap_sasl_interactive_bind_s: Authentication method not supported (7) > additional info: sasl mechanism not supported > > Now, under cn=config, I see: > > nsslapd-allowed-sasl-mechanisms: > > (i.e. empty). > > I tried changing this to "NTLM" and it accepted the change. If I try > changing it to "ntlm" I get "Server is unwilling to perform" - which is > a good sign, since clearly "NTLM" is valid. > > However even after restarting the server, I still get "sasl mechanism > not supported" when I try the bind. > > -=-=-=- > > The reason I'm asking: I'm using FreeRADIUS for MSCHAP authentication, > and one of the things MSCHAP supports is a password change feature for > expired passwords. FreeRADIUS lets me shell out to an external process > to perform the password change: > > local_cpw = "%{exec:/usr/local/sbin/freeipa-passwd > '%{mschap:User-Name}' '%{MS-CHAP-New-Cleartext-Password}' > '%{control:NT-Password}'" > > Now, the last argument is the user's *old* NTLM password hash. So > ideally I would use this to authenticate to the FreeIPA server to > perform the password change - this would avoid the freeipa-passwd script > having to have any privileged credentials of its own. > > But the only way I can think of doing that would be via a SASL NTLM bind. Sorry Brian but we do not support SASL NTLM or SASL SPNEGO/NTLM at this time, to do that you not only need the mechanism but also a way for that mechanism to either contact a NT-like Domain Controller or have direct access to the NT password hashes for any user you want to authenticate, and none of that is set up by default. We are planning to enable the integrated Samba server (which is used for trusts only at the moment) to provide NTLM services for radius servers, but it is not ready yet, although you may try to experiment with it. Simo. -- Simo Sorce * Red Hat, Inc * New York From flo at redhat.com Thu Dec 22 13:13:52 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 22 Dec 2016 14:13:52 +0100 Subject: [Freeipa-users] Ipa cert automatic renew Failing. In-Reply-To: References: Message-ID: <689e233d-1c18-eae0-2841-3a5374f7b205@redhat.com> On 12/22/2016 01:15 PM, Lucas Diedrich wrote: > Florence, for some creepy reason the cert from pkidbuser is different > from subsystem certs, and this pkidbuser is outdated now, but i can't > manage one way to re-issue it. I had to change the CA server because of > that, and the Selinux in the old CA Server was disabled, on the new one > is in Permissive mode but doesn't a warning in /var/log/audit/audit.log. > > This is the pkidbuser cert: https://paste.fedoraproject.org/511023/24084431/ > This is the subsystem cert: https://paste.fedoraproject.org/511025/14824085/ > The ca.subsystem.cert matches the pkidbuser cert. > > lucasdiedrich. > Hi, you can try to manually call the post-save command that certmonger should have issued after putting the certificate in /etc/pki/pki-tomcat/alias: on the renewal master: $ sudo /usr/libexec/ipa/certmonger/stop_pkicad $ sudo /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" Then check the journal log that should display the following if everything goes well: $ sudo journalctl --since today | grep renew_ca_cert [...] renew_ca_cert[6478]: Updating entry uid=CA-ipaserver.domain.com-8443,ou=people,o=ipaca [...] renew_ca_cert[6478]: Updating entry uid=pkidbuser,ou=people,o=ipaca [...] renew_ca_cert[6478]: Starting pki_tomcatd [...] renew_ca_cert[6478]: Started pki_tomcatd If the operation does not succeed, you will have to check the LDAP server logs in /etc/dirsrv/slapd-DOMAIN/access. HTH, Flo. > Em qui, 22 de dez de 2016 ?s 06:54, Florence Blanc-Renaud > > escreveu: > > On 12/21/2016 07:52 PM, Lucas Diedrich wrote: > > Hello guys, > > > > I'm having some trouble with, whats is happening with my server is > that > > i'm hiting an old BUG > > (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to > mbasti > > over irc he oriented me to send this to the email list. > > > > The problem is, i got on CA Master, so because of this problem the CA > > Master certificates couldn't be renewd, so now i promoted another > master > > to be the CA. And the problem still persist. > > > > This is the certs from my new CA > > (https://paste.fedoraproject.org/510617/14823448/), > > this is the certs from my old CA > > (https://paste.fedoraproject.org/510618/44871148/) > > This is the log then i restart pki-tomcat( "CA port 636 Error > > netscape.ldap.LDAPException: Authentication failed (49)") > > This is the log from dirsrv when i restart pki-tomcat > > (https://paste.fedoraproject.org/510614/23446801/) > > > > Basically my CA is not working anymore... > > > > Anyway, i tried lots of thing but couldn't fix this, anyone has > some idea? > > > > > > > Hi, > > Pki-tomcat is using the LDAP server as a data store, meaning that it > needs to authenticate to LDAP. In order to do that, pki-tomcat is using > the certificate 'subsystemCert cert-pki-ca' stored in > /etc/pki/pki-tomcat/alias. For the authentication to succeed, the > certificate must be stored in a user entry > (uid=pkidbuser,ou=people,o=ipaca). > > Can you check the content of this entry, especially the usercertificate > attribute? It should match the certificate used by pki-tomcat: > > $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert > cert-pki-ca' -a > -----BEGIN CERTIFICATE----- > [...] > -----END CERTIFICATE----- > > $ kinit admin > $ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate > dn: uid=pkidbuser,ou=people,o=ipaca > usercertificate:: > > The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this > certificate in the directive ca.subsystem.cert. > > > A possible cause for the entries not being updated is the bug 1366915 > [1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE linux > on Fedora 24. > > Flo > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188 > > > From rstory at tislabs.com Thu Dec 22 13:29:15 2016 From: rstory at tislabs.com (Robert Story) Date: Thu, 22 Dec 2016 08:29:15 -0500 Subject: [Freeipa-users] backing up and starting over... In-Reply-To: References: <20161221162627.453d15b4@ispx.vb.futz.org> Message-ID: <20161222082915.6593664d@ispx.vb.futz.org> On Thu, 22 Dec 2016 13:02:18 +0100 Martin wrote: MB> On 22.12.2016 09:25, Florence Blanc-Renaud wrote: MB> > On 12/21/2016 10:26 PM, Robert Story wrote: MB> >> I'm running a small instance of freeipa on CentOS 7 in our lab, for MB> >> about 20 MB> >> machines. Since CentOS 7.3 came out and upgraded from 4.2 to 4.4, things MB> >> have gotten flaky. e.g. clicking on a user get the spinning 'Working' MB> >> dialog and can take 3-5 minutes to load the page. But often it will die MB> >> with 'internal error'. MB> MB> Could you check in /var/log/httpd/error_log what is it? MB> Does cli work well? ipa user-find Yes, cli works, and ldap mostly works, but not always. GUI works occasionally. Here's one: mod_wsgi (pid=6358): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. Traceback (most recent call last): File "/usr/share/ipa/wsgi.py", line 49, in application return api.Backend.wsgi_dispatch(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 262, in __call__ return self.route(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 274, in route return app(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 833, in __call__ self.create_context(ccache=ipa_ccache_name) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 123, in create_context self.Backend.ldap2.connect(ccache=ccache) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect conn = self.create_connection(*args, **kw) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 205, in create_connection client_controls=clientctrls) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1108, in gssapi_bind '', auth_tokens, server_controls, client_controls) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1007, in error_handler raise errors.DatabaseError(desc=desc, info=info) DatabaseError: Server is unwilling to perform: Too many failed logins. and this: ipa: INFO: 401 Unauthorized: kinit: Clients credentials have been revoked while getting initial credentials and ipa: ERROR: non-public: IOError: request data read error Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 358, in wsgi_execute data = read_input(environ) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 195, in read_input return environ['wsgi.input'].read(length) IOError: request data read error rstory at EXAMPLE: None: IOError and AH00163: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.4.0 mod_nss/1.0.14 NSS/3.21 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' ipa: INFO: *** PROCESS START *** ipa: INFO: *** PROCESS START *** ipa: INFO: 401 Unauthorized: kinit: Cannot contact any KDC for realm 'EXAMPLE' while getting initial credentials [pid 3714] ipa: INFO: 401 Unauthorized: kinit: Cannot contact any KDC for realm 'EXAMPLE' while getting initial credentials [pid 3715] ipa: ERROR: release_ipa_ccache: ccache_name (FILE:/var/run/ipa_memcached/krbcc_3714) != KRB5CCNAME environment variable (/var/run/httpd/ipa/krbcache/krb5ccache) 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 'EXAMPLE') mod_wsgi (pid=3714): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. Traceback (most recent call last): File "/usr/share/ipa/wsgi.py", line 49, in application return api.Backend.wsgi_dispatch(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 262, in __call__ return self.route(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 274, in route return app(environ, start_response) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 978, in __call__ self.kinit(user, self.api.env.realm, password, ipa_ccache_name) File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 1010, in kinit raise CCacheError(message=unicode(e)) CCacheError: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529639068): Cannot contact any KDC for realm 'EXAMPLE' AH00170: caught SIGWINCH, shutting down gracefully and Script timed out before returning headers: wsgi.py, referer: https://auth-1.example/ipa/ui/ Script timed out before returning headers: wsgi.py, referer: https://auth-1.example/ipa/ui/ Script timed out before returning headers: wsgi.py, referer: https://auth-1.example/ipa/ui/ and SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate Robert -- Senior Software Engineer @ Parsons -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From flo at redhat.com Thu Dec 22 13:54:29 2016 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 22 Dec 2016 14:54:29 +0100 Subject: [Freeipa-users] [Freeipa-devel] Certificate expiration consequences In-Reply-To: References: Message-ID: <5336bebe-cca6-9775-0b1b-fcaee3f5ce21@redhat.com> On 12/22/2016 12:22 PM, Pablo Hinojosa wrote: > Hi all, > > I have realized my Freeipa webui ssl certificate is near to expire. It > is supposed to auto-renew but it seems I am affected by this bug/defect > (maybe due to a > missconfigured installation). Here > you can check current > status with getcert list. > > My main priority is to know if LDAP login will work when certificated is > expired. Will I have problems with it? Will login blocked? or it will > work as expected. > > Thanks for your support > > Cheers, > > -- > > Pablo Hinojosa > System administrator > Kanteron Systems (kanteron.com ) > > > Hi Pablo, (moving this discussion to freeipa-users). you probably have other certificates already expired in your deployment (auditSigningCert cert-pki-ca, ocspSigningCert cert-pki-ca, subsystemCert cert-pki-ca, Server-Cert cert-pki-ca in /etc/pki/pki-tomcat/alias and ipaCert in /etc/httpd/alias). The best thing to do would be to fix this problem first, and the HTTPd and LDAP server certificates should be able to renew automatically. The following document [1] may help you. The general idea is to find which certificate expired first, go back in time (by changing the date of your server) and manually renew the certificates. If your LDAP and HTTP certificates are already expired, the documentation [2] explains how to start IPA stack and also lists the limitations when running with expired certificates. HTH, Flo. [1] https://access.redhat.com/solutions/643753 [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/expired-certs.html From b.candler at pobox.com Thu Dec 22 14:03:45 2016 From: b.candler at pobox.com (Brian Candler) Date: Thu, 22 Dec 2016 14:03:45 +0000 Subject: [Freeipa-users] NTLM SASL? In-Reply-To: <66200f76-5b0a-c622-17a0-08b130edc42a@pobox.com> References: <66200f76-5b0a-c622-17a0-08b130edc42a@pobox.com> Message-ID: On 22/12/2016 11:42, Brian Candler wrote: > Now, under cn=config, I see: > > nsslapd-allowed-sasl-mechanisms: > > (i.e. empty). > > I tried changing this to "NTLM" and it accepted the change. Aside: I'm also stuck changing it back to what it was :-( None of these works: dn: cn=config changetype: modify replace: nsslapd-allowed-sasl-mechanisms nsslapd-allowed-sasl-mechanisms: - # Server is unwilling to perform (53) dn: cn=config changetype: modify delete: nsslapd-allowed-sasl-mechanisms - # Server is unwilling to perform (53) # additional info: Deleting attributes is not allowed dn: cn=config changetype: modify replace: nsslapd-allowed-sasl-mechanisms - # accepted, but doesn't change the value of the attribute So for now, I've set "nsslapd-allowed-sasl-mechanisms: GSSAPI EXTERNAL". But that means this server is in a different config state to its replica peers, which I wonder might bite me one day. Thanks, Brian. From abokovoy at redhat.com Thu Dec 22 14:08:00 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Dec 2016 16:08:00 +0200 Subject: [Freeipa-users] NTLM SASL? In-Reply-To: References: <66200f76-5b0a-c622-17a0-08b130edc42a@pobox.com> Message-ID: <20161222140800.shgp3du6wi25k6de@redhat.com> On to, 22 joulu 2016, Brian Candler wrote: >On 22/12/2016 11:42, Brian Candler wrote: >>Now, under cn=config, I see: >> >> nsslapd-allowed-sasl-mechanisms: >> >>(i.e. empty). >> >>I tried changing this to "NTLM" and it accepted the change. > >Aside: I'm also stuck changing it back to what it was :-( > >None of these works: > >dn: cn=config >changetype: modify >replace: nsslapd-allowed-sasl-mechanisms >nsslapd-allowed-sasl-mechanisms: >- ># Server is unwilling to perform (53) > >dn: cn=config >changetype: modify >delete: nsslapd-allowed-sasl-mechanisms >- ># Server is unwilling to perform (53) ># additional info: Deleting attributes is not allowed > >dn: cn=config >changetype: modify >replace: nsslapd-allowed-sasl-mechanisms >- ># accepted, but doesn't change the value of the attribute > >So for now, I've set "nsslapd-allowed-sasl-mechanisms: GSSAPI >EXTERNAL". But that means this server is in a different config state >to its replica peers, which I wonder might bite me one day. You can shut the server down (ipactl stop), change the value in the config (/etc/dirsrv/slapd-INSTANCE/dse.ldif) and start the server again (ipactl start). -- / Alexander Bokovoy From b.candler at pobox.com Thu Dec 22 14:32:09 2016 From: b.candler at pobox.com (Brian Candler) Date: Thu, 22 Dec 2016 14:32:09 +0000 Subject: [Freeipa-users] NTLM SASL? In-Reply-To: <1482410915.3801.40.camel@redhat.com> References: <66200f76-5b0a-c622-17a0-08b130edc42a@pobox.com> <1482410915.3801.40.camel@redhat.com> Message-ID: On 22/12/2016 12:48, Simo Sorce wrote: > Sorry Brian but we do not support SASL NTLM or SASL SPNEGO/NTLM at this > time, to do that you not only need the mechanism but also a way for that > mechanism to either contact a NT-like Domain Controller or have direct > access to the NT password hashes for any user you want to authenticate, > and none of that is set up by default. I installed ipa-server-trust-ad, and FreeIPA is storing the ipaNTHash attribute. The RADIUS server uses a privileged principal which has permissions to read out this attribute, and then it uses that to authenticate users. All works nicely - even password changing for expired passwords over MSCHAPv2. However the password-change script currently needs a privileged FreeIPA principal (permitted to change anyone's password), which also needs to be in passSyncManagersDNs so that the changed passwords aren't immediately expired. And unfortunately that means it also bypasses FreeIPA's password complexity tests, so I have to implement those externally. Some FreeRADIUS config snippets below, in case anyone's interested. > We are planning to enable the integrated Samba server (which is used for > trusts only at the moment) to provide NTLM services for radius servers, > but it is not ready yet, although you may try to experiment with it. I could give it a try, although if it's not in 4.4.0 I'd have to set up a separate testbed for it. If the new code includes NTLM password changing that would certainly simplify things a lot. Cheers, Brian. # mods-available/ldap update { control:NT-Password := 'ipaNTHash' control:Tmp-String-9 := 'krbPasswordExpiration' } user { base_dn = "${..base_dn}" filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})" scope = "one" # https://www.redhat.com/archives/freeipa-users/2011-June/msg00078.html access_attribute = "nsaccountlock" access_positive = no } group { membership_attribute = 'memberOf' name_attributes = 'cn' cacheable_dn = 'yes' cacheable_name = 'no' } # mods-available/eap eap { mschapv2 { send_error = yes } } # mods-available/mschap local_cpw = "%{exec:/usr/local/sbin/freeipa-passwd '%{mschap:User-Name}' '%{MS-CHAP-New-Cleartext-Password}' '%{control:NT-Password}'}" # policy.d password_expiry { # https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/doc/modules/mschap.rst # http://wiki.freeradius.org/config/run_time_variables if (&control:Tmp-String-9 < "%D%H%G00Z") { update control { &SMB-Account-Ctrl-Text := '[Ue]' } } else { update control { &SMB-Account-Ctrl-Text := '[U]' } } } From dag at sonsorol.org Thu Dec 22 14:36:10 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Thu, 22 Dec 2016 09:36:10 -0500 Subject: [Freeipa-users] really dumb question - is an IPA replica automatically a client as well? Message-ID: <585BE4DA.1010800@sonsorol.org> Working on a messy multi-AD / multi-child-domain environment ... Just deployed my 1st replica server after the v4.4 upgrade The IPA replica seems fine and "ipactl status" reports no issues. The webUI clearly shows all of the values/config that came over from the master However the replica server does not resolve or enumerate any users in any of the trusted AD domains despite sssd.conf and krb5.com being similar to the IPA master. No obvious errors or blocked traffic although I have not yet enabled debug=10 logging yet. Before I begin the standard krb5 and sssd troubleshooting I wanted to ask the dumb question first -- does an IPA replica automatically get enrolled as a managed client? Should I expect it to recognize the remote AD user IDs by default? Chris From abokovoy at redhat.com Thu Dec 22 14:42:59 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Dec 2016 16:42:59 +0200 Subject: [Freeipa-users] really dumb question - is an IPA replica automatically a client as well? In-Reply-To: <585BE4DA.1010800@sonsorol.org> References: <585BE4DA.1010800@sonsorol.org> Message-ID: <20161222144259.tz7huw5qxvoniqug@redhat.com> On to, 22 joulu 2016, Chris Dagdigian wrote: > >Working on a messy multi-AD / multi-child-domain environment ... > >Just deployed my 1st replica server after the v4.4 upgrade > >The IPA replica seems fine and "ipactl status" reports no issues. The >webUI clearly shows all of the values/config that came over from the >master > >However the replica server does not resolve or enumerate any users in >any of the trusted AD domains despite sssd.conf and krb5.com being >similar to the IPA master. No obvious errors or blocked traffic >although I have not yet enabled debug=10 logging yet. > >Before I begin the standard krb5 and sssd troubleshooting I wanted to >ask the dumb question first -- does an IPA replica automatically get >enrolled as a managed client? Should I expect it to recognize the >remote AD user IDs by default? It is a managed client for itself. I.e. it only talks to itself. And the replica is not automatically resolving users and groups from the trusted AD domains. To do so, it needs to be at least a trust agent. See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-controller-agent for details. -- / Alexander Bokovoy From b.candler at pobox.com Thu Dec 22 14:48:39 2016 From: b.candler at pobox.com (Brian Candler) Date: Thu, 22 Dec 2016 14:48:39 +0000 Subject: [Freeipa-users] NTLM SASL? In-Reply-To: <20161222140800.shgp3du6wi25k6de@redhat.com> References: <66200f76-5b0a-c622-17a0-08b130edc42a@pobox.com> <20161222140800.shgp3du6wi25k6de@redhat.com> Message-ID: <290ba805-9f37-bc47-d2cb-4448233b4f6e@pobox.com> On 22/12/2016 14:08, Alexander Bokovoy wrote: >> dn: cn=config >> changetype: modify >> replace: nsslapd-allowed-sasl-mechanisms >> - >> # accepted, but doesn't change the value of the attribute >> >> So for now, I've set "nsslapd-allowed-sasl-mechanisms: GSSAPI >> EXTERNAL". But that means this server is in a different config state >> to its replica peers, which I wonder might bite me one day. > You can shut the server down (ipactl stop), change the value in the > config (/etc/dirsrv/slapd-INSTANCE/dse.ldif) and start the server again > (ipactl start). Thank you. I looked in this file and the setting wasn't there! But a bit more investigation showed that the following update *does* update the config in dse.ldif: dn: cn=config changetype: modify replace: nsslapd-allowed-sasl-mechanisms - However the doesn't become visible until you restart the server. Until then, doing an ldapsearch on cn=config returns the previous value of this attribute. Anyway, all is good now. Thanks again, Brian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dag at sonsorol.org Thu Dec 22 16:27:01 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Thu, 22 Dec 2016 11:27:01 -0500 Subject: [Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on? Message-ID: <585BFED5.4090804@sonsorol.org> Hi folks, Summary: Replica w/ Trust agents can't resolve AD users. Not sure which debug_level=log error I should focus on. Would appreciate extra eyeballs on this .. Have a brand new replica (v4.4) running and after installing the AD trust agents I still can't recognize users who exist in the trusted AD domains. Running at debug_level=10 for logging as usual however deleting the logs and doing a fresh reboot followed by trying to resolve a users still make 4000+ log entries so rather than include it here I've posted a sanitized sssd_domain.log file here: http://chrisdag.me/sssd_companyidm.org.log.txt There are two sets of messages in that massive log file that concern me but I don't know enough yet to figure out which one to focus on. The first set of messages show what appears to be a fatal error in connecting to the local ldap:// server on the replica. However - - dirsirv logs look fine - the various ldapsearch commands in the Free-IPA troublehooting page work to query both the replica and the remote master - 'ipactl status' shows directory services running - no firewall blocking and AWS VPC flowLogs show no REJECT traffic whatsoever for the NIC on the replica But I still see this scary section in the logs right after startup: This is about line #577 in the log where I see some scary LDAP related errors: > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] > (0x0400): Creating [shanetest.org] as subdomain of [companyidm.org]! > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] > (0x0400): Creating [companyaws.org] as subdomain of [companyidm.org]! > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] > (0x0400): Creating [COMPANY.ORG] as subdomain of [companyidm.org]! > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] > (0x0400): Creating [child2.shanetest.org] as subdomain of > [companyidm.org]! > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] > (0x0400): Creating [EAME.COMPANY.ORG] as subdomain of [companyidm.org]! > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] > (0x0400): Creating [APAC.COMPANY.ORG] as subdomain of [companyidm.org]! > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] > (0x0400): Creating [LATAM.COMPANY.ORG] as subdomain of [companyidm.org]! > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] > (0x0400): Creating [NAFTA.COMPANY.ORG] as subdomain of [companyidm.org]! > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [link_forest_roots] (0x2000): [companyidm.org] is a forest root > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [link_forest_roots] (0x2000): [shanetest.org] is a forest root > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [link_forest_roots] (0x2000): [shanetest.org] is a forest root of > [child2.shanetest.org] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [link_forest_roots] (0x2000): [companyaws.org] is a forest root > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of > [EAME.COMPANY.ORG] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of > [APAC.COMPANY.ORG] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of > [LATAM.COMPANY.ORG] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of > [NAFTA.COMPANY.ORG] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sss_write_domain_mappings] (0x0200): Mapping file for domain > [companyidm.org] is > [/var/lib/sss/pubconf/krb5.include.d/domain_realm_companyidm_org] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [become_user] > (0x0200): Trying to become user [0][0]. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [become_user] > (0x0200): Already user [0]. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [main] (0x0400): > Backend provider (companyidm.org) started! > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [ipa_server_trusted_dom_setup_send] (0x1000): Trust direction of > subdom shanetest.org from forest shanetest.org is: one-way inbound: > local domain trusts the remote domain > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for > shanetest.org > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [ipa_getkeytab_send] (0x0400): Retrieving keytab for > companyidm$@SHANETEST.ORG from usaeilidmp002.companyidm.org into > /var/lib/sss/keytabs/shanetest.org.keytabRw7Iai using ccache > /var/lib/sss/db/ccache_companyidm.ORG > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [child_handler_setup] (0x2000): Setting up signal handler up for pid [649] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [child_handler_setup] (0x2000): Signal handler set up for pid [649] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [sbus_dispatch] > (0x4000): dbus conn: 0x7f4f63ae1600 > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [sbus_dispatch] > (0x4000): dbus conn: 0x7f4f63ae1600 > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [be_ptask_execute] (0x0400): Task [Subdomains Refresh]: executing > task, timeout 14400 seconds > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sdap_id_op_connect_step] (0x4000): beginning to connect > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [get_server_status] (0x1000): Status of server > 'usaeilidmp002.companyidm.org' is 'name not resolved' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [get_port_status] (0x1000): Port status of port 0 for server > 'usaeilidmp002.companyidm.org' is 'neutral' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to > 6 seconds > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [get_server_status] (0x1000): Status of server > 'usaeilidmp002.companyidm.org' is 'name not resolved' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [resolv_is_address] (0x4000): [usaeilidmp002.companyidm.org] does not > look like an IP address > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [resolv_gethostbyname_step] (0x2000): Querying files > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record > of 'usaeilidmp002.companyidm.org' in files > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [set_server_common_status] (0x0100): Marking server > 'usaeilidmp002.companyidm.org' as 'resolving name' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [set_server_common_status] (0x0100): Marking server > 'usaeilidmp002.companyidm.org' as 'name resolved' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [be_resolve_server_process] (0x1000): Saving the first resolved server > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [be_resolve_server_process] (0x0200): Found address for server > usaeilidmp002.companyidm.org: [10.127.66.11] TTL 7200 > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [ipa_resolve_callback] (0x0400): Constructed uri > 'ldap://usaeilidmp002.companyidm.org' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [unique_filename_destructor] (0x2000): Unlinking > [/var/lib/sss/pubconf/.krb5info_dummy_k6Y0iO] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [unlink_dbg] > (0x2000): File already removed: > [/var/lib/sss/pubconf/.krb5info_dummy_k6Y0iO] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x4000): Using file descriptor [21] for > the connection. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_connect_send] (0x0020): connect failed [101][Network is > unreachable]. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for > connecting > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request > failed: [101]: Network is unreachable. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_state_destructor] (0x0400): closing socket [21] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sss_ldap_init_sys_connect_done] (0x0020): sssd_async_socket_init > request failed: [101]: Network is unreachable. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request > failed: [101]: Network is unreachable. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sdap_handle_release] (0x2000): Trace: sh[0x7f4f63b0a5f0], > connected[0], ops[(nil)], ldap[(nil)], destructor_lock[0], > release_memory[0] > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. > Called from: src/providers/ldap/sdap_async_connection.c: > sdap_cli_connect_done: 1572 > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [fo_set_port_status] (0x0100): Marking port 0 of server > 'usaeilidmp002.companyidm.org' as 'not working' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [fo_set_port_status] (0x0400): Marking port 0 of duplicate server > 'usaeilidmp002.companyidm.org' as 'not working' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [get_server_status] (0x1000): Status of server > 'usaeilidmp002.companyidm.org' is 'name resolved' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [get_port_status] (0x1000): Port status of port 0 for server > 'usaeilidmp002.companyidm.org' is 'not working' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [fo_resolve_service_send] (0x0020): No available servers for service 'IPA' > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [be_resolve_server_done] (0x1000): Server resolution failed: [5]: > Input/output error > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline > (5 [Input/output error]) > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [be_mark_offline] (0x2000): Going offline The second scary thing I see relates to some "Invalid Argument" errors related to ipa_get_*_acct stuff that I see when I try to resolve my AD user account: > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] [sbus_dispatch] > (0x4000): dbus conn: 0x7f4f63b1d290 > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] [sbus_dispatch] > (0x4000): Dispatching. > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sbus_message_handler] (0x2000): Received SBUS method > org.freedesktop.sssd.dataprovider.getAccountInfo on path > /org/freedesktop/sssd/dataprovider > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [dp_get_account_info_handler] (0x0200): Got request for > [0x1][BE_REQ_USER][1][name=t859531 at nafta.COMPANY.ORG] > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] [dp_attach_req] > (0x0400): DP Request [Account #43]: New request. Flags [0x0001]. > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] [dp_attach_req] > (0x0400): Number of active DP request: 1 > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_id_op_connect_step] (0x4000): reusing cached connection > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides > in view [Default Trust View] with filter > [(&(objectClass=ipaUserOverride)(uid=t859531))]. > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_print_server] (0x2000): Searching 10.127.66.11:389 > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [(&(objectClass=ipaUserOverride)(uid=t859531))][cn=Default Trust > View,cn=views,cn=accounts,dc=companyidm,dc=org]. > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 14 > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] [sdap_op_add] > (0x2000): New operation 14 timeout 6 > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_process_result] (0x2000): Trace: sh[0x7f4f63ace530], > connected[1], ops[0x7f4f63ada1c0], ldap[0x7f4f63b28720] > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > errmsg set > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_op_destructor] (0x2000): Operation 14 finished > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [ipa_get_ad_override_done] (0x4000): No override found with filter > [(&(objectClass=ipaUserOverride)(uid=t859531))]. > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_id_op_destroy] (0x4000): releasing operation connection > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [be_mark_dom_offline] (0x1000): Marking subdomain NAFTA.COMPANY.ORG > offline > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [be_mark_subdom_offline] (0x1000): Marking subdomain NAFTA.COMPANY.ORG > as inactive > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed: > [22]: Invalid argument. > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: > [22]: Invalid argument. > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_id_op_destroy] (0x4000): releasing operation connection > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] [dp_req_done] > (0x0400): DP Request [Account #43]: Request handler finished [0]: Success > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] [_dp_req_recv] > (0x0400): DP Request [Account #43]: Receiving request data. > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [dp_req_reply_list_success] (0x0400): DP Request [Account #43]: > Finished. Success. > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [dp_req_reply_std] (0x1000): DP Request [Account #43]: Returning > [Internal Error]: 3,22,Invalid argument > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [dp_table_value_destructor] (0x0400): Removing > [0:1:0x0001:1:1::NAFTA.COMPANY.ORG:name=t859531 at nafta.COMPANY.ORG] > from reply table > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [dp_req_destructor] (0x0400): DP Request [Account #43]: Request removed. > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [dp_req_destructor] (0x0400): Number of active DP request: 0 > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_process_result] (0x2000): Trace: sh[0x7f4f63ace530], > connected[1], ops[(nil)], ldap[0x7f4f63b28720] > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] > [sdap_process_result] (0x2000): Trace: end of ldap_result list > (Thu Dec 22 15:49:49 2016) [sssd[be[companyidm.org]]] [sbus_dispatch] > (0x4000): dbus conn: 0x7f4f63b1d290 Regards, Chris From b.candler at pobox.com Thu Dec 22 16:53:01 2016 From: b.candler at pobox.com (Brian Candler) Date: Thu, 22 Dec 2016 16:53:01 +0000 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> <20161208085923.qh6mauratg3z4f5v@redhat.com> Message-ID: <46c90ace-0100-aaf6-c702-8d8e048068ad@pobox.com> On 20/12/2016 08:07, Petr Spacek wrote: > I've tried to clarify things in man pages and on web as well. Please have a > look to changes and let us know if it is better or not, and preferably what > can be improved and in which way > > The modified deployment page is here: > http://www.freeipa.org/page/Deployment_Recommendations > > Man page changes and changes in description of installer options are here: > https://github.com/freeipa/freeipa/pull/352 Thank you for working on this. This is getting clearer, but I would like to expand a little more. (1) This introduces a concept of an "IPA Primary Domain". Is that just the DNS domain which holds the SRV records which point to the realm's kerberos/ldap servers, or does it have any other function? In other words, what other effects would there be from choosing a different IP Primary Domain? Let me give a specific example. - IPA server hostname is ipa.foo.example.com - I want to create kerberos realm BAR.EXAMPLE.COM Which IPA primary domain should I choose? The expected place for SRV records for realm BAR.EXAMPLE.COM would be in the DNS under domain bar.example.com. So I'm thinking that "--domain bar.example.com" is the right thing - and can't think why you'd ever want to do anything else. (2) I'm trying to work out how --domain, --realm, --server and systemhostname influence each other, if one or more is not provided. For ipa-server-install, testing suggests: * --domain defaults to the domain part of the system hostname * --realm defaults to the uppercased --domain * (--server is obviously itself :-) For ipa-client-install it seems a bit more complex. Based on the manpage, I believe the sequence is something like this: * If --domain is not specified, then it's the domain from the system hostname * If --server is not specified, then it hunts for servers based on the --domain (looking in that domain and its parents until suitable SRV records are found) * If --realm is not specified, then it sends a query to the --server(s) to ask what realm they are in But the manpage says you can specify both --server and --domain: "Client machine can also be configured without a DNS autodiscovery at all. When both --server and --domain options are used, client installer will use the specified server and domain directly." In that case, I can't see what the --domain is used for here, if it's only purpose is to locate servers (and you've already told it which --server to use) Thanks, Brian. From lucas.diedrich at gmail.com Thu Dec 22 17:40:42 2016 From: lucas.diedrich at gmail.com (Lucas Diedrich) Date: Thu, 22 Dec 2016 17:40:42 +0000 Subject: [Freeipa-users] Ipa cert automatic renew Failing. In-Reply-To: <689e233d-1c18-eae0-2841-3a5374f7b205@redhat.com> References: <689e233d-1c18-eae0-2841-3a5374f7b205@redhat.com> Message-ID: Yey!! It fixed the problem over the new CA Master now, i finally can see and search for the certs. But, in the replicas i can't browse for them, it prompts me this (IPA Error 4301: CertificateOperationError), should i ran the post-save command in all replicas? Thanks. Em qui, 22 de dez de 2016 ?s 11:13, Florence Blanc-Renaud escreveu: > On 12/22/2016 01:15 PM, Lucas Diedrich wrote: > > Florence, for some creepy reason the cert from pkidbuser is different > > from subsystem certs, and this pkidbuser is outdated now, but i can't > > manage one way to re-issue it. I had to change the CA server because of > > that, and the Selinux in the old CA Server was disabled, on the new one > > is in Permissive mode but doesn't a warning in /var/log/audit/audit.log. > > > > This is the pkidbuser cert: > https://paste.fedoraproject.org/511023/24084431/ > > This is the subsystem cert: > https://paste.fedoraproject.org/511025/14824085/ > > The ca.subsystem.cert matches the pkidbuser cert. > > > > lucasdiedrich. > > > Hi, > > you can try to manually call the post-save command that certmonger > should have issued after putting the certificate in > /etc/pki/pki-tomcat/alias: > on the renewal master: > $ sudo /usr/libexec/ipa/certmonger/stop_pkicad > $ sudo /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert > cert-pki-ca" > > Then check the journal log that should display the following if > everything goes well: > $ sudo journalctl --since today | grep renew_ca_cert > [...] renew_ca_cert[6478]: Updating entry > uid=CA-ipaserver.domain.com-8443,ou=people,o=ipaca > [...] renew_ca_cert[6478]: Updating entry uid=pkidbuser,ou=people,o=ipaca > [...] renew_ca_cert[6478]: Starting pki_tomcatd > [...] renew_ca_cert[6478]: Started pki_tomcatd > > If the operation does not succeed, you will have to check the LDAP > server logs in /etc/dirsrv/slapd-DOMAIN/access. > > HTH, > Flo. > > > Em qui, 22 de dez de 2016 ?s 06:54, Florence Blanc-Renaud > > > escreveu: > > > > On 12/21/2016 07:52 PM, Lucas Diedrich wrote: > > > Hello guys, > > > > > > I'm having some trouble with, whats is happening with my server is > > that > > > i'm hiting an old BUG > > > (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to > > mbasti > > > over irc he oriented me to send this to the email list. > > > > > > The problem is, i got on CA Master, so because of this problem the > CA > > > Master certificates couldn't be renewd, so now i promoted another > > master > > > to be the CA. And the problem still persist. > > > > > > This is the certs from my new CA > > > (https://paste.fedoraproject.org/510617/14823448/), > > > this is the certs from my old CA > > > (https://paste.fedoraproject.org/510618/44871148/) > > > This is the log then i restart pki-tomcat( "CA port 636 Error > > > netscape.ldap.LDAPException: Authentication failed (49)") > > > This is the log from dirsrv when i restart pki-tomcat > > > (https://paste.fedoraproject.org/510614/23446801/) > > > > > > Basically my CA is not working anymore... > > > > > > Anyway, i tried lots of thing but couldn't fix this, anyone has > > some idea? > > > > > > > > > > > Hi, > > > > Pki-tomcat is using the LDAP server as a data store, meaning that it > > needs to authenticate to LDAP. In order to do that, pki-tomcat is > using > > the certificate 'subsystemCert cert-pki-ca' stored in > > /etc/pki/pki-tomcat/alias. For the authentication to succeed, the > > certificate must be stored in a user entry > > (uid=pkidbuser,ou=people,o=ipaca). > > > > Can you check the content of this entry, especially the > usercertificate > > attribute? It should match the certificate used by pki-tomcat: > > > > $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert > > cert-pki-ca' -a > > -----BEGIN CERTIFICATE----- > > [...] > > -----END CERTIFICATE----- > > > > $ kinit admin > > $ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b > > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate > > dn: uid=pkidbuser,ou=people,o=ipaca > > usercertificate:: > > > > The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this > > certificate in the directive ca.subsystem.cert. > > > > > > A possible cause for the entries not being updated is the bug 1366915 > > [1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE > linux > > on Fedora 24. > > > > Flo > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915 > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188 > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Dec 22 20:53:52 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 22 Dec 2016 21:53:52 +0100 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: <46c90ace-0100-aaf6-c702-8d8e048068ad@pobox.com> References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> <20161208085923.qh6mauratg3z4f5v@redhat.com> <46c90ace-0100-aaf6-c702-8d8e048068ad@pobox.com> Message-ID: <1dd7c51c-6e3c-fee7-c384-50ab1f2656e4@redhat.com> On 22.12.2016 17:53, Brian Candler wrote: > On 20/12/2016 08:07, Petr Spacek wrote: >> I've tried to clarify things in man pages and on web as well. Please >> have a >> look to changes and let us know if it is better or not, and >> preferably what >> can be improved and in which way >> >> The modified deployment page is here: >> http://www.freeipa.org/page/Deployment_Recommendations >> >> Man page changes and changes in description of installer options are >> here: >> https://github.com/freeipa/freeipa/pull/352 > > Thank you for working on this. > > This is getting clearer, but I would like to expand a little more. > > (1) This introduces a concept of an "IPA Primary Domain". Is that > just the DNS domain which holds the SRV records which point to the > realm's kerberos/ldap servers, or does it have any other function? In > other words, what other effects would there be from choosing a > different IP Primary Domain? it holds SRV records, A/AAAA records for CA LDAP tree is constructed from the domain (cn=accounts,dc=example,dc=com) > > Let me give a specific example. > > - IPA server hostname is ipa.foo.example.com > - I want to create kerberos realm BAR.EXAMPLE.COM > > Which IPA primary domain should I choose? > > The expected place for SRV records for realm BAR.EXAMPLE.COM would be > in the DNS under domain bar.example.com. So I'm thinking that > "--domain bar.example.com" is the right thing - and can't think why > you'd ever want to do anything else. > > Then use bar.example.com, IPA servers can have names outside the IPA domain name space. Different people wants different things, that's why the option is there. > > (2) I'm trying to work out how --domain, --realm, --server and > systemhostname influence each other, if one or more is not provided. > > For ipa-server-install, testing suggests: > > * --domain defaults to the domain part of the system hostname > * --realm defaults to the uppercased --domain > * (--server is obviously itself :-) > > For ipa-client-install it seems a bit more complex. Based on the > manpage, I believe the sequence is something like this: > > * If --domain is not specified, then it's the domain from the system > hostname > * If --server is not specified, then it hunts for servers based on the > --domain (looking in that domain and its parents until suitable SRV > records are found) > * If --realm is not specified, then it sends a query to the > --server(s) to ask what realm they are in > > But the manpage says you can specify both --server and --domain: > > "Client machine can also be configured without a DNS > autodiscovery at all. When both > --server and --domain options are used, client installer will > use the specified server > and domain directly." Server and client can be in different DNS domains, that's probably why it has separate options. I know that it is not clear how client determine domain and server, but there were more important things to fix, this may be improved in future. > > In that case, I can't see what the --domain is used for here, if it's > only purpose is to locate servers (and you've already told it which > --server to use) > > Thanks, > > Brian. > Martin From abokovoy at redhat.com Thu Dec 22 21:34:01 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Dec 2016 23:34:01 +0200 Subject: [Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on? In-Reply-To: <585BFED5.4090804@sonsorol.org> References: <585BFED5.4090804@sonsorol.org> Message-ID: <20161222213401.r5flw4brgoskuunh@redhat.com> On to, 22 joulu 2016, Chris Dagdigian wrote: >Hi folks, > >Summary: Replica w/ Trust agents can't resolve AD users. Not sure >which debug_level=log error I should focus on. Would appreciate extra >eyeballs on this .. > >Have a brand new replica (v4.4) running and after installing the AD >trust agents I still can't recognize users who exist in the trusted AD >domains. > >Running at debug_level=10 for logging as usual however deleting the >logs and doing a fresh reboot followed by trying to resolve a users >still make 4000+ log entries so rather than include it here I've >posted a sanitized sssd_domain.log file here: > >http://chrisdag.me/sssd_companyidm.org.log.txt > >There are two sets of messages in that massive log file that concern >me but I don't know enough yet to figure out which one to focus on. > >The first set of messages show what appears to be a fatal error in >connecting to the local ldap:// server on the replica. > >However - > - dirsirv logs look fine > - the various ldapsearch commands in the Free-IPA troublehooting page >work to query both the replica and the remote master > - 'ipactl status' shows directory services running > - no firewall blocking and AWS VPC flowLogs show no REJECT traffic >whatsoever for the NIC on the replica Can you show us ldap_child.log and krb5_child.log from /var/log/sssd on the replica? There seem to be something weird with networking stack, because at 15:43:13 the next attempt to connect gets 'connection refused'. May be 389-ds is just warming up and there is not enough CPU or I/O to handle the load? (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] [be_resolve_server_process] (0x0200): Found address for server usaeilidmp002.companyidm.org: [10.127.66.11] TTL 7200 (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] [sssd_async_socket_init_send] (0x4000): Using file descriptor [27] for the connection. (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] [sssd_async_connect_done] (0x0020): connect failed [111][Connection refused]. (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] [sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request failed: [111]: Connection refused. this is definitely is different from the result of two seconds before: (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [sssd_async_socket_init_send] (0x4000): Using file descriptor [21] for the connection. (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [sssd_async_connect_send] (0x0020): connect failed [101][Network is unreachable]. (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request failed: [101]: Network is unreachable. (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [sssd_async_socket_state_destructor] (0x0400): closing socket [21] (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [sss_ldap_init_sys_connect_done] (0x0020): sssd_async_socket_init request failed: [101]: Network is unreachable. (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: [101]: Network is unreachable. Later, in a minute it seems to respond just well: (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sssd_async_socket_init_send] (0x4000): Using file descriptor [27] for the connection. (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://usaeilidmp002.companyidm.org:389/??base] with fd [27]. (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_print_server] (0x2000): Searching 10.127.66.11:389 ... (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultNamingContext] (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastUSN] (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_process_result] (0x2000): Trace: sh[0x7f4f63ace530], connected[1], ops[0x7f4f63b283d0], ldap[0x7f4f63b28720] (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_op_destructor] (0x2000): Operation 1 finished (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_get_rootdse_done] (0x2000): Got rootdse So, sssd on the replica is able to retrieve information from the replica's LDAP server. It also is able to retrieve the trust topology information and retrieve the trusted domain objects to use against the forest root domains your deployment trusts. But at the point when it tries to contact global catalog and domain controllers from the trusted domains, it cannot access them, so it considers them offline. Can you show us your /etc/krb5.conf on this replica, content of files in /var/lib/sss/pubconf/krb5.include.d subdirectory which get included into /etc/krb5.conf, and the logs I asked above? Can you make sure that the replica is actually able to reach AD DCs for the trusted domains (ports tcp/3268, tcp/389, tcp/88, udp/88, udp/53 at least)? >The second scary thing I see relates to some "Invalid Argument" errors >related to ipa_get_*_acct stuff that I see when I try to resolve my AD >user account: These are coming from the failure to contact trusted domain's GC or LDAP servers. Looking at the code flow, it seems an attempt to actually connect to the server failed and there was no retry allowed (internally), so SSSD marked the subdomain it tried to connect to as 'offline'. So I'd bet you have something blocking access from the replica towards domain controllers of those AD domains. -- / Alexander Bokovoy From rstory at tislabs.com Thu Dec 22 21:48:10 2016 From: rstory at tislabs.com (Robert Story) Date: Thu, 22 Dec 2016 16:48:10 -0500 Subject: [Freeipa-users] backing up and starting over... In-Reply-To: References: <20161221162627.453d15b4@ispx.vb.futz.org> Message-ID: <20161222164810.4fb711c0@ispx.vb.futz.org> On Thu, 22 Dec 2016 09:25:52 +0100 Florence wrote: FBR> you can find more information about backup and restore procedure in this FBR> guide [1]. But, as stated in the documentation, the safest method would FBR> rather be to install a replica [2]. FBR> [...] FBR> [2] FBR> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-replica.html I tried to create a replica. It went well for the directory server, but then: Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 seconds [1/27]: creating certificate server user [2/27]: configuring certificate server instance ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ' 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/pki-tomcat [error] RuntimeError: CA configuration failed. from ipa-replica-install.log: 2016-12-22T21:00:53Z DEBUG Starting external process 2016-12-22T21:00:53Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ 2016-12-22T21:10:08Z DEBUG Process finished, return code=1 2016-12-22T21:10:08Z DEBUG stdout=Log file: /var/log/pki/pki-ca-spawn.20161222160055.log Loading deployment configuration from /tmp/tmpqYyqJJ. Installing CA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. Importing certificates from /tmp/ca.p12: ... Import complete --------------- Imported certificates in /etc/pki/pki-tomcat/alias: Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u caSigningCert cert-pki-ca CTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Installation failed: Please check the CA logs in /var/log/pki/pki-tomcat/ca. 2016-12-22T21:10:08Z DEBUG stderr= 2016-12-22T21:10:08Z CRITICAL Failed to configure CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ' returned non-zero exit status 1 2016-12-22T21:10:08Z CRITICAL See the installation logs and the following files/directories for more information: 2016-12-22T21:10:08Z CRITICAL /var/log/pki/pki-tomcat 2016-12-22T21:10:08Z 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/cainstance.py", line 590, in __spawn_instance DogtagInstance.spawn_instance(self, cfg_file) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 181, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 420, in handle_setup_error raise RuntimeError("%s configuration failed." % self.subsystem) RuntimeError: CA configuration failed. 2016-12-22T21:10:08Z DEBUG [error] RuntimeError: CA configuration failed. 2016-12-22T21:10:08Z 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 1718, in main install(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 822, in install ca.install_step_0(False, config, options) File "/usr/lib/python2.7/site-packages/ipaserver/install/ca.py", line 140, in install_step_0 ra_p12=getattr(options, 'ra_p12', None)) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1562, in install_replica_ca subject_base=config.subject_base) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 437, in configure_instance self.start_creation(runtime=210) 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/cainstance.py", line 590, in __spawn_instance DogtagInstance.spawn_instance(self, cfg_file) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 181, in spawn_instance self.handle_setup_error(e) File "/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py", line 420, in handle_setup_error raise RuntimeError("%s configuration failed." % self.subsystem) 2016-12-22T21:10:08Z DEBUG The ipa-replica-install command failed, exception: RuntimeError: CA configuration failed. 2016-12-22T21:10:08Z ERROR CA configuration failed. 2016-12-22T21:10:08Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information /var/log/pki/pki-tomcat/ca/system: 0.localhost-startStop-1 - [22/Dec/2016:16:02:38 EST] [13] [3] authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value /var/log/pki/pki-tomcat/ca/debug: 22/Dec/2016:16:05:47][http-bio-8443-exec-3]: === Subsystem Configuration === [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: SystemConfigService: validate clone URI: https://auth-1.example:443 [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: SystemConfigService: import certificate chain from master [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: ConfigurationUtils: Searching for SecureAdminPort in CA hosts [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: ConfigurationUtils: host: auth-1.example [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: ConfigurationUtils: SecurePort port: 443 [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: ConfigurationUtils: SecureAdminPort port found: 443 [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: ConfigurationUtils.importCertChain() [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: ConfigurationUtils: GET https://auth-1.example:443/ca/admin/ca/getCertChain [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: Server certificate: [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: - subject: CN=auth-1.example,O=EXAMPLE [22/Dec/2016:16:05:47][http-bio-8443-exec-3]: - issuer: CN=Certificate Authority,O=EXAMPLE [22/Dec/2016:16:06:48][http-bio-8443-exec-3]: SystemConfigService: get configuration entries from master [22/Dec/2016:16:06:48][http-bio-8443-exec-3]: updateNumberRange start host=auth-1.example adminPort=443 eePort=443 [22/Dec/2016:16:06:48][http-bio-8443-exec-3]: ConfigurationUtils: POST https://auth-1.example:443/ca/admin/ca/updateNumberRange [22/Dec/2016:16:06:48][http-bio-8443-exec-3]: Server certificate: [22/Dec/2016:16:06:48][http-bio-8443-exec-3]: - subject: CN=auth-1.example,O=EXAMPLE [22/Dec/2016:16:06:48][http-bio-8443-exec-3]: - issuer: CN=Certificate Authority,O=EXAMPLE [22/Dec/2016:16:07:48][http-bio-8443-exec-3]: updateNumberRange: Failed to contact master using admin portjavax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error [22/Dec/2016:16:07:48][http-bio-8443-exec-3]: updateNumberRange: Attempting to contact master using EE port [22/Dec/2016:16:07:48][http-bio-8443-exec-3]: ConfigurationUtils: POST https://auth-1.example:443/ca/ee/ca/updateNumberRange [22/Dec/2016:16:07:48][http-bio-8443-exec-3]: Server certificate: [22/Dec/2016:16:07:48][http-bio-8443-exec-3]: - subject: CN=auth-1.example,O=EXAMPLE [22/Dec/2016:16:07:48][http-bio-8443-exec-3]: - issuer: CN=Certificate Authority,O=EXAMPLE javax.ws.rs.NotFoundException: HTTP 404 Not Found at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(ClientInvocation.java:181) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:154) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:444) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.post(ClientInvocationBuilder.java:201) at com.netscape.certsrv.client.PKIConnection.post(PKIConnection.java:476) ... So this looks like the culprit: [22/Dec/2016:16:07:48][http-bio-8443-exec-3]: updateNumberRange: Failed to contact master using admin portjavax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error Any suggestions on how to fix this? Or do I need to switch to the backup/restore method? Robert -- Senior Software Engineer @ Parsons -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From daniel at schimpfoessl.com Fri Dec 23 00:08:24 2016 From: daniel at schimpfoessl.com (Daniel Schimpfoessl) Date: Thu, 22 Dec 2016 18:08:24 -0600 Subject: [Freeipa-users] Asking for help with crashed freeIPA istance In-Reply-To: <585A9F46.7080207@redhat.com> References: <729a8aed-4f22-ba26-3089-58c675bd64e0@redhat.com> <585A9F46.7080207@redhat.com> Message-ID: I do not believe I changed the DM password. I know I had to update the admin passwords regularly. Only during the startup using ipactl start --force I am able to connect to the service using the password for DM and it returns: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # dn: objectClass: top namingContexts: cn=changelog namingContexts: dc=myorg,dc=com namingContexts: o=ipaca defaultnamingcontext: dc=myorg,dc=com supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 supportedExtension: 2.16.840.1.113730.3.5.10 supportedExtension: 2.16.840.1.113730.3.8.10.3 supportedExtension: 2.16.840.1.113730.3.8.10.4 supportedExtension: 2.16.840.1.113730.3.8.10.4.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 2.16.840.1.113730.3.8.10.1 supportedExtension: 2.16.840.1.113730.3.8.10.5 supportedExtension: 2.16.840.1.113730.3.5.3 supportedExtension: 2.16.840.1.113730.3.5.12 supportedExtension: 2.16.840.1.113730.3.5.5 supportedExtension: 2.16.840.1.113730.3.5.6 supportedExtension: 2.16.840.1.113730.3.5.9 supportedExtension: 2.16.840.1.113730.3.5.4 supportedExtension: 2.16.840.1.113730.3.6.5 supportedExtension: 2.16.840.1.113730.3.6.6 supportedExtension: 2.16.840.1.113730.3.6.7 supportedExtension: 2.16.840.1.113730.3.6.8 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.15 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 supportedControl: 1.3.6.1.4.1.4203.666.5.16 supportedControl: 2.16.840.1.113730.3.8.10.6 supportedControl: 2.16.840.1.113730.3.4.14 supportedControl: 2.16.840.1.113730.3.4.20 supportedControl: 1.3.6.1.4.1.1466.29539.12 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.13 supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: GSSAPI supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: ANONYMOUS supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: 389 Project vendorVersion: 389-Directory/1.3.4.0 B2016.215.1556 dataversion: 020161222235947020161222235947020161222235947 netscapemdsuffix: cn=ldap://dc=wwgwho01,dc=myorg,dc=com:389 lastusn: 8690425 changeLog: cn=changelog firstchangenumber: 2752153 lastchangenumber: 2752346 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 2016-12-21 9:27 GMT-06:00 Rob Crittenden : > Daniel Schimpfoessl wrote: > > Thanks for getting back to me. > > > > getcert list | grep expires shows dates years in the future for all > > certificates > > Inline-Bild 1 > > > > ipactl start --force > > > > Eventually the system started with: > > Forced start, ignoring pki-tomcatd Service, continuing normal > > operations. > > > > systemctl status ipa shows: failed > > I don't think this is a certificate problem at all. I think the timing > with your renewal is just coincidence. > > Did you change your Directory Manager password at some point? > > > > > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w > > password -b "" -s base > > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w > > *********** -b "" -s base > > Inline-Bild 2 > > You need the -x flag to indicate simple bind. > > rob > > > The logs have thousands of lines like it, what am I looking for > > specifically? > > > > Daniel > > > > > > 2016-12-20 4:18 GMT-06:00 Florence Blanc-Renaud > >: > > > > On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote: > > > > Good day and happy holidays, > > > > I have been running a freeIPA instance for a few years and been > very > > happy. Recently the certificate expired and I updated it using > the > > documented methods. At first all seemed fine. Added a Nagios > > monitor for > > the certificate expiration and restarted the server (single > > server). I > > have weekly snapshots, daily backups (using Amanda on the entire > > disk). > > > > One day the services relying on IPA failed to authenticate. > > Looking at > > the server the ipa service had stopped. Restarting the service > > fails. > > Restoring a few weeks old snapshot does not start either. > > Resetting the > > date to a few month back does not work either as httpd fails to > > start . > > > > I am at a loss. > > > > Here a few details: > > # ipa --version > > VERSION: 4.4.0, API_VERSION: 2.213 > > > > > > # /usr/sbin/ipactl start > > ... > > out -> Failed to start pki-tomcatd Service > > /var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP > server > > host ipa.myorg.com > > port 636 Error > > netscape.ldap.LDAPException: Authentication failed (48) > > 2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted > > due to > > error: Retrieving CA status failed with status 500 > > > > Any help would be appreciated as all connected services are now > > down. > > > > Thanks, > > > > Daniel > > > > > > > > > > Hi Daniel, > > > > more information would be required to understand what is going on. > > First of all, which certificate did you renew? Can you check with > > $ getcert list > > if other certificates also expired? > > > > PKI fails to start and the error seems linked to the SSL connection > > with the LDAP server. You may want to check if the LDAP server is > > listening on the LDAPs port: > > - start the stack with > > $ ipactl start --force > > - check the LDAPs port with > > $ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w > > password -b "" -s base > > > > The communication between PKI and the LDAP server is authenticated > > with the certificate 'subsystemCert cert-pki-ca' located in > > /etc/pki/pki-tomcat/alias, so you may also want to check if it is > > still valid. > > The directory server access logs (in > > /var/log/dirsrv/slapd-DOMAIN-COM/access) would also show the > > connection with logs similar to: > > > > [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to > > 10.34.58.150 > > [...] conn=47 TLS1.2 128-bit AES; client CN=CA > > Subsystem,O=DOMAIN.COM ; issuer CN=Certificate > > Authority,O=DOMAIN.COM > > [...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipaca > > [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL > > [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 > > dn="uid=pkidbuser,ou=people,o=ipaca" > > > > > > > > HTH, > > Flo > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rstory at tislabs.com Fri Dec 23 06:12:42 2016 From: rstory at tislabs.com (Robert Story) Date: Fri, 23 Dec 2016 01:12:42 -0500 Subject: [Freeipa-users] backing up and starting over... In-Reply-To: <20161222164810.4fb711c0@ispx.vb.futz.org> References: <20161221162627.453d15b4@ispx.vb.futz.org> <20161222164810.4fb711c0@ispx.vb.futz.org> Message-ID: <20161223011242.3972200b@ispx.vb.futz.org> On Thu, 22 Dec 2016 16:48:10 -0500 Robert wrote: RS> I tried to create a replica. It went well for the directory server, but RS> then: RS> RS> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30 RS> seconds [1/27]: creating certificate server user RS> [2/27]: configuring certificate server instance RS> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to configure RS> CA instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpqYyqJJ' returned RS> non-zero exit status 1 ipa.ipaserver.install.cainstance.CAInstance: RS> CRITICAL See the installation logs and the following files/directories for RS> more information: ipa.ipaserver.install.cainstance.CAInstance: RS> CRITICAL /var/log/pki/pki-tomcat [error] RuntimeError: CA configuration RS> failed. RS> [...] RS> So this looks like the culprit: RS> RS> [22/Dec/2016:16:07:48][http-bio-8443-exec-3]: updateNumberRange: Failed to contact master using admin portjavax.ws.rs.InternalServerErrorException: HTTP 500 Internal Server Error So eventually I found proxy errors like this in a logfile: proxy_ajp:error (70007)The timeout specified has expired: I added large timeouts to /etc/httpd/conf.d/ipa-pki-proxy.conf Timeout 900 ProxyTimeout 900 This allowed my replica install to complete. However, when I logged in to the new replica, I was getting the same long timeout trying to load users. The error log had this: [Fri Dec 23 00:50:39.206858 2016] [proxy_ajp:error] [pid 31182] [client 10.71.10.118:49784] AH00896: failed to make connection to backend: localhost This started ringing a little bell in my head about localhost and ipv4 vs ipv6. I disabled ipv6 in /etc/sysctl.conf, and voila, users load in less than 5 seconds instead of 5 minutes or timing out. Hopefully this will also resolve the other weirdness I've been seeing. I'm keeping my fingers crossed. Robert -- Senior Software Engineer @ Parsons -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From kempd7 at gmail.com Fri Dec 23 01:38:38 2016 From: kempd7 at gmail.com (Dan Kemp) Date: Thu, 22 Dec 2016 20:38:38 -0500 Subject: [Freeipa-users] Upgrade to 4.4.0 Breaks login. Message-ID: Hello, I recently ran an upgrade of my freeipa servers, and most of the clients to 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install and server update, I can no longer log in to update clients via ssh. Login to non-update clients works as before. The SSH connections fail with: Connection closed by UNKNOWN I ran sssd with debugging on a failing 4.4.0 client and got this error log: (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit ldb transaction (nesting: 2) (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_create_buffer] (0x4000): buffer size: 45 (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [437] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] (0x2000): Signal handler set up for pid [437] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)], ldap[0x560c04c32d60] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler] (0x0400): All data has been sent! (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): selinux_child started. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): Running with effective IDs: [0][0]. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): Running with real IDs [0][0]. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): context initialized (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] (0x2000): seuser length: 12 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] (0x2000): seuser: unconfined_u (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] (0x2000): mls_range length: 14 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] (0x2000): mls_range: s0-s0:c0.c1023 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] (0x2000): username length: 7 (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] (0x2000): username: ipauser (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): performing selinux operations (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [sss_semanage_init] (0x0020): SELinux policy not managed (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [get_seuser] (0x0020): Cannot create SELinux handle (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls: unknown (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [sss_semanage_init] (0x0020): SELinux policy not managed (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [set_seuser] (0x0020): Cannot init SELinux management (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): Cannot set SELinux login context. (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): selinux_child failed! (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler] (0x0400): EOF received, client finished (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done] (0x0020): selinux_child_parse_response failed: [22][Invalid argument] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400): DP Request [PAM SELinux #3]: Request handler finished [0]: Success (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv] (0x0400): DP Request [PAM SELinux #3]: Receiving request data. (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] (0x0400): DP Request [PAM SELinux #3]: Request removed. (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] (0x0400): Number of active DP request: 0 (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply] (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local] (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] (0x1000): Waiting for child [437]. (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] (0x0020): child [437] failed with status [1]. (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x55f4be11f4c0 (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x55f4be1191b0 (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4 (System error)][domain.local] (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: System error. (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 39 (Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x55f4be11f980][19] (Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x55f4be11f980][19] (Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_recv] (0x0200): Client disconnected! (Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_close_fn] (0x2000): Terminated client [0x55f4be11f980][19] (Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x5604f5217c60][22] (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client disconnected! (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): Terminated client [0x5604f5217c60][22] (Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x5604f5216b20][21] (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client disconnected! (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): Terminated client [0x5604f5216b20][21] SeLinux is disabled, as I am running the clients in LXC containers on a debian host. My setup is pretty simple, and was working before (and connections to 4.2.0 clients are still functional!). Nothing looks amiss in the ssh logs. Thanks for any help, -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Dec 23 09:29:55 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 23 Dec 2016 10:29:55 +0100 Subject: [Freeipa-users] Upgrade to 4.4.0 Breaks login. In-Reply-To: References: Message-ID: <20161223092955.ydbgqnzxeivthwdd@hendrix> On Thu, Dec 22, 2016 at 08:38:38PM -0500, Dan Kemp wrote: > Hello, > > I recently ran an upgrade of my freeipa servers, and most of the clients to > 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install > and server update, I can no longer log in to update clients via ssh. Login > to non-update clients works as before. > > The SSH connections fail with: > > Connection closed by UNKNOWN > > I ran sssd with debugging on a failing 4.4.0 client and got this error log: > > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit > ldb transaction (nesting: 2) > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit > ldb transaction (nesting: 1) > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit > ldb transaction (nesting: 0) > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] > [selinux_child_create_buffer] (0x4000): buffer size: 45 > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] > (0x2000): Setting up signal handler up for pid [437] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] > (0x2000): Signal handler set up for pid [437] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] > (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)], > ldap[0x560c04c32d60] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] > (0x2000): Trace: end of ldap_result list > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler] > (0x0400): All data has been sent! > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): > selinux_child started. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): > Running with effective IDs: [0][0]. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): > Running with real IDs [0][0]. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): > context initialized > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): seuser length: 12 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): seuser: unconfined_u > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): mls_range length: 14 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): mls_range: s0-s0:c0.c1023 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): username length: 7 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): username: ipauser > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): > performing selinux operations > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [sss_semanage_init] > (0x0020): SELinux policy not managed > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [get_seuser] > (0x0020): Cannot create SELinux handle > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] > [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls: > unknown > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [sss_semanage_init] > (0x0020): SELinux policy not managed > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [set_seuser] > (0x0020): Cannot init SELinux management > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): > Cannot set SELinux login context. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): > selinux_child failed! > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler] > (0x0400): EOF received, client finished > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done] > (0x0020): selinux_child_parse_response failed: [22][Invalid argument] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400): > DP Request [PAM SELinux #3]: Request handler finished [0]: Success > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv] > (0x0400): DP Request [PAM SELinux #3]: Receiving request data. > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] > (0x0400): DP Request [PAM SELinux #3]: Request removed. > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] > (0x0400): Number of active DP request: 0 > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply] > (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] > (0x1000): Waiting for child [437]. > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] > (0x0020): child [437] failed with status [1]. > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): > 0x55f4be11f4c0 > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: > 0x55f4be1191b0 > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): > Dispatching. > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): > received: [4 (System error)][domain.local] > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply > called with result [4]: System error. > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 39 > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x55f4be11f980][19] > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x55f4be11f980][19] > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_recv] (0x0200): Client > disconnected! > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_close_fn] (0x2000): > Terminated client [0x55f4be11f980][19] > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x5604f5217c60][22] > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client > disconnected! > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): > Terminated client [0x5604f5217c60][22] > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x5604f5216b20][21] > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client > disconnected! > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): > Terminated client [0x5604f5216b20][21] > > > SeLinux is disabled, as I am running the clients in LXC containers on a > debian host. My setup is pretty simple, and was working before (and > connections to 4.2.0 clients are still functional!). Nothing looks amiss in > the ssh logs. If you don't use SELinux, then I'm quite sure you can just set: selinux_provider=none in the domain section of sssd.conf, then selinux_child won't be called at all. But to be honest I'm not sure what exactly can cause the error about sss_semanage_init(). Looking at libsemanage, they just connecto to the policy store (typically /etc/selinux/targeted/modules/). The only idea I have is that the store might not be there in the LXC container or, the LXC container might not support extended FS attributes that are IIRC used to store SELinux labels. Stracing the selinux child (see https://fedorahosted.org/sssd/wiki/DevelTips#UsingstracetotracktheSSSDprocesses) might give a better idea which exact syscall failed. From abokovoy at redhat.com Fri Dec 23 09:31:34 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 23 Dec 2016 11:31:34 +0200 Subject: [Freeipa-users] Upgrade to 4.4.0 Breaks login. In-Reply-To: References: Message-ID: <20161223093134.zk25q7xaj7zhdq7b@redhat.com> On to, 22 joulu 2016, Dan Kemp wrote: >Hello, > >I recently ran an upgrade of my freeipa servers, and most of the clients to >4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install >and server update, I can no longer log in to update clients via ssh. Login >to non-update clients works as before. > >The SSH connections fail with: > >Connection closed by UNKNOWN > >I ran sssd with debugging on a failing 4.4.0 client and got this error log: > >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >ldb transaction (nesting: 2) >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >ldb transaction (nesting: 1) >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >ldb transaction (nesting: 0) >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] >[selinux_child_create_buffer] (0x4000): buffer size: 45 >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] >(0x2000): Setting up signal handler up for pid [437] >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] >(0x2000): Signal handler set up for pid [437] >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] >(0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)], >ldap[0x560c04c32d60] >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] >(0x2000): Trace: end of ldap_result list >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler] >(0x0400): All data has been sent! >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): >selinux_child started. >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): >Running with effective IDs: [0][0]. >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): >Running with real IDs [0][0]. >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): >context initialized >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >(0x2000): seuser length: 12 >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >(0x2000): seuser: unconfined_u >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >(0x2000): mls_range length: 14 >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >(0x2000): mls_range: s0-s0:c0.c1023 >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >(0x2000): username length: 7 >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >(0x2000): username: ipauser >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): >performing selinux operations >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [sss_semanage_init] >(0x0020): SELinux policy not managed >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [get_seuser] >(0x0020): Cannot create SELinux handle >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] >[seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls: >unknown >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [sss_semanage_init] >(0x0020): SELinux policy not managed >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [set_seuser] >(0x0020): Cannot init SELinux management >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): >Cannot set SELinux login context. >(Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): >selinux_child failed! >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler] >(0x0400): EOF received, client finished >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done] >(0x0020): selinux_child_parse_response failed: [22][Invalid argument] >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400): >DP Request [PAM SELinux #3]: Request handler finished [0]: Success >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv] >(0x0400): DP Request [PAM SELinux #3]: Receiving request data. >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] >(0x0400): DP Request [PAM SELinux #3]: Request removed. >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] >(0x0400): Number of active DP request: 0 >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply] >(0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local] >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] >(0x1000): Waiting for child [437]. >(Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] >(0x0020): child [437] failed with status [1]. >(Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): >0x55f4be11f4c0 >(Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: >0x55f4be1191b0 >(Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): >Dispatching. >(Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): >received: [4 (System error)][domain.local] >(Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply >called with result [4]: System error. >(Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 39 >(Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle >timer re-set for client [0x55f4be11f980][19] >(Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle >timer re-set for client [0x55f4be11f980][19] >(Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_recv] (0x0200): Client >disconnected! >(Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_close_fn] (0x2000): >Terminated client [0x55f4be11f980][19] >(Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle >timer re-set for client [0x5604f5217c60][22] >(Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client >disconnected! >(Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): >Terminated client [0x5604f5217c60][22] >(Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle >timer re-set for client [0x5604f5216b20][21] >(Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client >disconnected! >(Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): >Terminated client [0x5604f5216b20][21] > > >SeLinux is disabled, as I am running the clients in LXC containers on a >debian host. My setup is pretty simple, and was working before (and >connections to 4.2.0 clients are still functional!). Nothing looks amiss in >the ssh logs. Add selinux_provider=none to the domain section if you are not using SELinux at all. -- / Alexander Bokovoy From jhrozek at redhat.com Fri Dec 23 09:40:19 2016 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 23 Dec 2016 10:40:19 +0100 Subject: [Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on? In-Reply-To: <20161222213401.r5flw4brgoskuunh@redhat.com> References: <585BFED5.4090804@sonsorol.org> <20161222213401.r5flw4brgoskuunh@redhat.com> Message-ID: <20161223094019.hkbsejtsbt6lpauy@hendrix> On Thu, Dec 22, 2016 at 11:34:01PM +0200, Alexander Bokovoy wrote: > On to, 22 joulu 2016, Chris Dagdigian wrote: > > Hi folks, > > > > Summary: Replica w/ Trust agents can't resolve AD users. Not sure which > > debug_level=log error I should focus on. Would appreciate extra eyeballs > > on this .. > > > > Have a brand new replica (v4.4) running and after installing the AD > > trust agents I still can't recognize users who exist in the trusted AD > > domains. > > > > Running at debug_level=10 for logging as usual however deleting the logs > > and doing a fresh reboot followed by trying to resolve a users still > > make 4000+ log entries so rather than include it here I've posted a > > sanitized sssd_domain.log file here: > > > > http://chrisdag.me/sssd_companyidm.org.log.txt > > > > There are two sets of messages in that massive log file that concern me > > but I don't know enough yet to figure out which one to focus on. > > > > The first set of messages show what appears to be a fatal error in > > connecting to the local ldap:// server on the replica. > > > > However - > > - dirsirv logs look fine > > - the various ldapsearch commands in the Free-IPA troublehooting page > > work to query both the replica and the remote master > > - 'ipactl status' shows directory services running > > - no firewall blocking and AWS VPC flowLogs show no REJECT traffic > > whatsoever for the NIC on the replica > Can you show us ldap_child.log and krb5_child.log from /var/log/sssd on > the replica? > > There seem to be something weird with networking stack, because at > 15:43:13 the next attempt to connect gets 'connection refused'. May be > 389-ds is just warming up and there is not enough CPU or I/O to handle > the load? > > (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] > [be_resolve_server_process] (0x0200): Found address for server usaeilidmp002.companyidm.org: [10.127.66.11] TTL 7200 > (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x4000): Using file descriptor [27] for the connection. > (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting > (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] > [sssd_async_connect_done] (0x0020): connect failed [111][Connection refused]. > (Thu Dec 22 15:43:13 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request failed: [111]: Connection refused. > > this is definitely is different from the result of two seconds before: > > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x4000): Using file descriptor [21] for the connection. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_connect_send] (0x0020): connect failed [101][Network is unreachable]. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_done] (0x0020): sdap_async_sys_connect request failed: [101]: Network is unreachable. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_state_destructor] (0x0400): closing socket [21] (Thu Dec > 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sss_ldap_init_sys_connect_done] (0x0020): sssd_async_socket_init request failed: [101]: Network is unreachable. > (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] > [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed: [101]: Network is unreachable. > > Later, in a minute it seems to respond just well: > > > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x4000): Using file descriptor [27] for the connection. > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sssd_async_socket_init_send] (0x0400): Setting 6 seconds timeout for connecting > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://usaeilidmp002.companyidm.org:389/??base] with fd [27]. > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_get_rootdse_send] (0x4000): Getting rootdse > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_print_server] (0x2000): Searching 10.127.66.11:389 > ... > > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range] > (0x2000): No sub-attributes for [supportedSASLMechanisms] > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range] > (0x2000): No sub-attributes for [defaultNamingContext] > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] [sdap_parse_range] > (0x2000): No sub-attributes for [lastUSN] > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_process_result] (0x2000): Trace: sh[0x7f4f63ace530], connected[1], ops[0x7f4f63b283d0], ldap[0x7f4f63b28720] > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_op_destructor] (0x2000): Operation 1 finished > (Thu Dec 22 15:44:28 2016) [sssd[be[companyidm.org]]] > [sdap_get_rootdse_done] (0x2000): Got rootdse > > So, sssd on the replica is able to retrieve information from the > replica's LDAP server. It also is able to retrieve the trust topology > information and retrieve the trusted domain objects to use against the > forest root domains your deployment trusts. > > But at the point when it tries to contact global catalog and domain > controllers from the trusted domains, it cannot access them, so it > considers them offline. > > Can you show us your /etc/krb5.conf on this replica, content of files in > /var/lib/sss/pubconf/krb5.include.d subdirectory which get included into > /etc/krb5.conf, and the logs I asked above? > > Can you make sure that the replica is actually able to reach AD DCs for > the trusted domains (ports tcp/3268, tcp/389, tcp/88, udp/88, udp/53 at > least)? In addition, can you also see if the keytab with the trust principal is there? Probably it would be /var/lib/sss/keytabs/shanetest.org. At 15:43:11, sssd tried to fetch the keytab for this trust: (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for shanetest.org (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_send] (0x0400): Retrieving keytab for companyidm$@SHANETEST.ORG from usaeilidmp002.companyidm.org into /var/lib/sss/keytabs/shanetest.org.keytabRw7Iai using ccache /var/lib/sss/db/ccache_companyidm.ORG But fails: SASL Bind failed Can't contact LDAP server (-1) ! Failed to bind to server! Failed to get keytab (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_done] (0x0040): ipa-getkeytab failed with status [2304] (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_recv] (0x2000): ipa-getkeytab status 2304 (Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_server_trust_1way_kt_done] (0x0080): ipa_getkeytab_recv failed: 1432158265 What I don't see in the logs, though is that if we try and re-fetch the keytab after going online (we should, though). > > > The second scary thing I see relates to some "Invalid Argument" errors > > related to ipa_get_*_acct stuff that I see when I try to resolve my AD > > user account: > These are coming from the failure to contact trusted domain's GC or LDAP > servers. Looking at the code flow, it seems an attempt to actually > connect to the server failed and there was no retry allowed > (internally), so SSSD marked the subdomain it tried to connect to as > 'offline'. > > So I'd bet you have something blocking access from the replica towards > domain controllers of those AD domains. > > -- > / 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 b.candler at pobox.com Fri Dec 23 09:47:32 2016 From: b.candler at pobox.com (Brian Candler) Date: Fri, 23 Dec 2016 09:47:32 +0000 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: <1dd7c51c-6e3c-fee7-c384-50ab1f2656e4@redhat.com> References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> <20161208085923.qh6mauratg3z4f5v@redhat.com> <46c90ace-0100-aaf6-c702-8d8e048068ad@pobox.com> <1dd7c51c-6e3c-fee7-c384-50ab1f2656e4@redhat.com> Message-ID: <15e532e0-58ca-b829-9aab-22af484f705c@pobox.com> On 22/12/2016 20:53, Martin Basti wrote: > >> (1) This introduces a concept of an "IPA Primary Domain". Is that >> just the DNS domain which holds the SRV records which point to the >> realm's kerberos/ldap servers, or does it have any other function? In >> other words, what other effects would there be from choosing a >> different IP Primary Domain? > > it holds SRV records, A/AAAA records for CA > > LDAP tree is constructed from the domain (cn=accounts,dc=example,dc=com) > No, I don't believe that's true: the LDAP tree is constructed from the *realm* not the *domain*. I just checked this by creating a Centos7 lxd container with hostname "ipa.foo.example.com", running the following command: # ipa-server-install --domain bar.example.com --realm QUX.EXAMPLE.COM --setup-dns -p Abcd1234 -a Defg5678 and accepting defaults for everything else. What I get is: *** an LDAP tree rooted at dc=qux,dc=example,dc=com => this proves the LDAP tree is constructed from the --realm, not the --domain. *** the DNS zone "bar.example.com" (in addition to the reverse zone) The bar.example.com contains both types of DNS mapping: hostname to realm and realm to servers. (1) _kerberos TXT "QUX.EXAMPLE.COM" i.e. "hosts with hostnames under domain bar.example.com belong to realm QUX.EXAMPLE.COM" (2) _kerberos._tcp SRV 0 100 88 ipatest.foo.example.com. # plus _kerberos._ldap etc => this shows the SRV records are put under the --domain *** in krb5.conf a default realm of QUX.EXAMPLE.COM, and the following realm to server mapping: [realms] QUX.EXAMPLE.COM = { kdc = ipatest.foo.example.com:88 master_kdc = ipatest.foo.example.com:88 admin_server = ipatest.foo.example.com:749 default_domain = bar.example.com pkinit_anchors = FILE:/etc/ipa/ca.crt } Aha: there is "default_domain" in there! It's a property of the realm! Checking the MIT kerberos documentation: http://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html "default_domain This tag specifies the domain used to expand hostnames when translating Kerberos 4 service principals to Kerberos 5 principals (for example, when converting rcmd.hostname to host/hostname.domain)." So it seems that's only a legacy setting for dealing with kerberos 4 :-( *** /etc/sssd/sssd.conf [domain/bar.example.com] krb5_realm = QUX.EXAMPLE.COM ipa_domain = bar.example.com [sssd] domains = bar.example.com But in sssd, "A domain is a database containing user information" - from sssd.conf(5). So really it's just a label for a group of settings, nothing to do with a DNS domain. *** CA grepping through /etc I see some other settings based on the domain, in particular the CA hostname is here: /etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp However the installation process didn't actually create this DNS entry, so the ipa-ca hostname is not resolvable. Since it has the bar.example.com master zone, maybe it should add this record? *** During the installation I get a reasonable warning: WARNING: Realm name does not match the domain name. You will not be able to estabilish trusts with Active Directory unless the realm name of the IPA server matches its domain name. But I think this also highlights confusion between "the IPA domain" and "the server's domain name". It's clear is that the *realm* is something that's common to all the IPA servers. However it's also clear that each IPA server's *hostname* can be in a different *domain*, e.g. they could be srv1.bar.com srv2.baz.com But "the IPA primary domain" (where the SRV records are stored) is an attribute of the realm collectively, not of the individual servers. So it might be clearer if it said: WARNING: Realm name does not match the domain name. You will not be able to establish trusts with Active Directory unless the IPA realm matches the IPA primary domain. > > Then use bar.example.com, IPA servers can have names outside the IPA > domain name space. > > Different people wants different things, that's why the option is there. > Indeed, but the "--domain" option to ipa-server-install appears to be orthogonal to the domain name of the IPA servers themselves. This is a primary source of confusion I think. Regards, Brian. From b.candler at pobox.com Fri Dec 23 10:15:50 2016 From: b.candler at pobox.com (Brian Candler) Date: Fri, 23 Dec 2016 10:15:50 +0000 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: <15e532e0-58ca-b829-9aab-22af484f705c@pobox.com> References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> <20161208085923.qh6mauratg3z4f5v@redhat.com> <46c90ace-0100-aaf6-c702-8d8e048068ad@pobox.com> <1dd7c51c-6e3c-fee7-c384-50ab1f2656e4@redhat.com> <15e532e0-58ca-b829-9aab-22af484f705c@pobox.com> Message-ID: On 23/12/2016 09:47, Brian Candler wrote: > /etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp > > > However the installation process didn't actually create this DNS > entry, so the ipa-ca hostname is not resolvable. Aside: I think this was because ipatest.foo.example.com was only in /etc/hosts, not in the DNS. Installation message: ipa : ERROR unable to resolve host name ipatest.foo.example.com. to IP address, ipa-ca DNS record will be incomplete But if it had used gethostent() or similar, it would have worked: # getent hosts ipatest.foo.example.com 100.64.2.3 ipatest.foo.example.com ipatest Regards, Brian. From abokovoy at redhat.com Fri Dec 23 10:31:00 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 23 Dec 2016 12:31:00 +0200 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> <20161208085923.qh6mauratg3z4f5v@redhat.com> <46c90ace-0100-aaf6-c702-8d8e048068ad@pobox.com> <1dd7c51c-6e3c-fee7-c384-50ab1f2656e4@redhat.com> <15e532e0-58ca-b829-9aab-22af484f705c@pobox.com> Message-ID: <20161223103100.jn4ic5r5jyzl6o3o@redhat.com> On pe, 23 joulu 2016, Brian Candler wrote: >On 23/12/2016 09:47, Brian Candler wrote: >>/etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp >> >> >>However the installation process didn't actually create this DNS >>entry, so the ipa-ca hostname is not resolvable. > >Aside: I think this was because ipatest.foo.example.com was only in >/etc/hosts, not in the DNS. Installation message: > >ipa : ERROR unable to resolve host name >ipatest.foo.example.com. to IP address, ipa-ca DNS record will be >incomplete > >But if it had used gethostent() or similar, it would have worked: > ># getent hosts ipatest.foo.example.com >100.64.2.3 ipatest.foo.example.com ipatest ipa-ca used to be a CNAME, you cannot handle CNAME via /etc/hosts. However, multiple replicas cannot me specified via CNAME, so we had to fix https://fedorahosted.org/freeipa/ticket/3547. The ipa-ca A record is now handled as part of the server upgrade which also should be run at the very end of a normal install. -- / Alexander Bokovoy From b.candler at pobox.com Fri Dec 23 10:42:51 2016 From: b.candler at pobox.com (Brian Candler) Date: Fri, 23 Dec 2016 10:42:51 +0000 Subject: [Freeipa-users] Still unclear about relation between IPA DNS domain and company DNS domain. In-Reply-To: <20161223103100.jn4ic5r5jyzl6o3o@redhat.com> References: <20161207085819.q5onuspvbrog6hee@redhat.com> <708fe5fc-e534-c2a6-b30c-e801c2eda156@pobox.com> <20161208085923.qh6mauratg3z4f5v@redhat.com> <46c90ace-0100-aaf6-c702-8d8e048068ad@pobox.com> <1dd7c51c-6e3c-fee7-c384-50ab1f2656e4@redhat.com> <15e532e0-58ca-b829-9aab-22af484f705c@pobox.com> <20161223103100.jn4ic5r5jyzl6o3o@redhat.com> Message-ID: <42302d39-a667-8902-a0de-9f18d8a13c0c@pobox.com> On 23/12/2016 10:31, Alexander Bokovoy wrote: > ipa-ca used to be a CNAME, you cannot handle CNAME via /etc/hosts. > However, multiple replicas cannot me specified via CNAME, so we had to > fix https://fedorahosted.org/freeipa/ticket/3547. Absolutely - I have no problem with ipa-ca being real A record(s) pointing to the server itself. All I'm saying is that at installation time, it already knew the IP address of the server - by local hostname resolution, and because ipa-server-install asks you to list the IP addresses of the server explicitly. > The ipa-ca A record is now handled as part of the server upgrade which > also should be run at the very end of a normal install. Are you are supposed to manually run "ipa-server-upgrade" even after a clean install? I've just tested that, and yes, one of the steps is: ... [Add missing CA DNS records] Updating DNS system records << pauses here >> unable to resolve host name ipatest.foo.example.com. to IP address, ipa-ca DNS record will be incomplete ... So you're right: that would have fixed it *if* I'd created the foo.example.com zone first, and added the host to it, which in real life I would have done (since other hosts must be able to resolve the IPA server's hostname) I already opened https://fedorahosted.org/freeipa/ticket/6579 which suggested using local resolution, e.g. via gethostent(). But feel free to close it if you don't think this is needed. Regards, Brian. From eivind at gluping.no Fri Dec 23 10:43:33 2016 From: eivind at gluping.no (Eivind Olsen) Date: Fri, 23 Dec 2016 11:43:33 +0100 Subject: [Freeipa-users] Still trying to implement password expiration warnings Message-ID: <95c3695fc6f131a2966da1b3b59c92a0@gluping.no> Hello. Earlier this year I tried to re-implement a "password expiration warning" email when using IPA 4.x. I hit a wall and ended up deciding to look at this later. Now is later :) The plan is to use ldapsearch to check for krbLastPwdChange and compare it to krbPasswordExpiration, but these attributes seem to be hidden unless one is authenticating (through Kerberos?). This is with RHEL 7 and IPA 4.2.0. I have done: # ipa service-add PWDREMIND/script.host.fqdn # ipa-getkeytab -s script.host.fqdn -k /etc/gssproxy/pwdremind.keytab -p PWDREMIND/script.host.fqdn ...and I have a file /etc/gssproxy/pwdremind.keytab I added a section to /etc/gssproxy/gssproxy.conf : [service/PWDREMIND] mechs = krb5 cred_store = client_keytab:/etc/gssproxy/pwdremind.keytab cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U cred_usage = initiate euid = 0 debug = true In my "pwdcheck.sh" script I have the following: #!/bin/bash export GSS_USE_PROXY="yes" ldapsearch -z 500 -Y GSSAPI -h ipa.host.fqdn -b cn=users,cn=accounts,dc=example,dc=net "(&(!(nsAccountLock=TRUE))(krbLastPwdChange<=$(date +%Y%m%d --date='-1 week')000000Z)(krbPasswordExpiration<=$(date +%Y%m%d --date='+1 week')000000Z))" uid |grep ^uid|cut -d: -f2 |while read uid do ldapsearch -z 500 -Y GSSAPI -h ipa.host.fqdn -b cn=users,cn=accounts,dc=example,dc=net "uid=${uid}" mail|grep ^mail|cut -d: -f2 | while read mail do echo "password expires in less than a week: username=$uid mail=$mail" done done Checking the journalctl for gssproxy I get: Dec 23 11:36:35 script.host.fqdn gssproxy[26977]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Dec 23 11:36:35 script.host.fqdn gssproxy[26976]: gssproxy[26977]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found Does anyone see where things are going wrong here or have some suggestions on what I should try? Regards Eivind Olsen From dag at sonsorol.org Fri Dec 23 14:57:27 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Fri, 23 Dec 2016 09:57:27 -0500 Subject: [Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on? In-Reply-To: <20161222213401.r5flw4brgoskuunh@redhat.com> References: <585BFED5.4090804@sonsorol.org> <20161222213401.r5flw4brgoskuunh@redhat.com> Message-ID: <585D3B57.6000301@sonsorol.org> Really appreciate the high-level of insight and support on this list. Very refreshing! Alexander Bokovoy wrote: > Can you show us ldap_child.log and krb5_child.log from /var/log/sssd on > the replica? krb5_child.log is totally empty (strange) as I thought I had debug_level = 10 set everywhere ldap_child.log is posted at this URL due to length: http://chrisdag.me/ldap_child.log.sanitized.txt > There seem to be something weird with networking stack, because at > 15:43:13 the next attempt to connect gets 'connection refused'. May be > 389-ds is just warming up and there is not enough CPU or I/O to handle > the load? > So, sssd on the replica is able to retrieve information from the > replica's LDAP server. It also is able to retrieve the trust topology > information and retrieve the trusted domain objects to use against the > forest root domains your deployment trusts. > > But at the point when it tries to contact global catalog and domain > controllers from the trusted domains, it cannot access them, so it > considers them offline. > > Can you show us your /etc/krb5.conf on this replica, content of files in > /var/lib/sss/pubconf/krb5.include.d subdirectory which get included into > /etc/krb5.conf, and the logs I asked above? Here is sanitized krb5.conf from the replica. The CAPATH information was provided by someone on this list to resolve a problem with the CAPATHs being wrong by default on v4.2 with our complex AD environment. We've since made an Ansible playbook to update the krb5.conf file on our client machines. We comment out the include path again based on our v4.2 issues howeve includedir /etc/krb5.conf.d/ ## Disabled due to SSSD Bug related to CA paths ## across different AD trusts # includedir /var/lib/sss/pubconf/krb5.include.d/ ## This is the manual COMPANY fix: [capaths] COMPANYAWS.ORG = { COMPANYIDM.ORG = COMPANYAWS.ORG } COMPANYIDM.ORG = { COMPANYAWS.ORG = COMPANYAWS.ORG COMPANY.ORG = COMPANY.ORG EAME.COMPANY.ORG = COMPANY.ORG APAC.COMPANY.ORG = COMPANY.ORG LATAM.COMPANY.ORG = COMPANY.ORG NAFTA.COMPANY.ORG = COMPANY.ORG } COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } EAME.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } APAC.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } LATAM.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } NAFTA.COMPANY.ORG = { COMPANYIDM.ORG = COMPANY.ORG } [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = COMPANYIDM.ORG dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} canonicalize = true [realms] COMPANYIDM.ORG = { kdc = usaeilidmp002.COMPANYidm.org:88 master_kdc = usaeilidmp002.COMPANYidm.org:88 admin_server = usaeilidmp002.COMPANYidm.org:749 default_domain = COMPANYidm.org pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .COMPANYidm.org = COMPANYIDM.ORG COMPANYidm.org = COMPANYIDM.ORG usaeilidmp002.COMPANYidm.org = COMPANYIDM.ORG [dbmodules] COMPANYIDM.ORG = { db_library = ipadb.so } ## Also from the include path we had previously commented out [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so } > > Can you make sure that the replica is actually able to reach AD DCs for > the trusted domains (ports tcp/3268, tcp/389, tcp/88, udp/88, udp/53 at > least)? I'm going to see if I can come up with a new verification method. My normal way of "proving" connectivity in this AWS environment is to use the VPC flow logs to search for REJECT alerts between the NIC on this IPA server and the remote AD domain controller. This was very effective in proving on our master IPA that something was blocking UDP:88 to a few remote controllers. Sadly I can't find any REJECT messages for this replica server so I've been assuming connectivity was totally fine. Will try to test via other methods. From dag at sonsorol.org Fri Dec 23 14:58:19 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Fri, 23 Dec 2016 09:58:19 -0500 Subject: [Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on? In-Reply-To: <20161223094019.hkbsejtsbt6lpauy@hendrix> References: <585BFED5.4090804@sonsorol.org> <20161222213401.r5flw4brgoskuunh@redhat.com> <20161223094019.hkbsejtsbt6lpauy@hendrix> Message-ID: <585D3B8B.4070903@sonsorol.org> Oddly enough the keytab location on the replica is sort of empty ... ls -al /var/lib/sss/keytabs/ total 4 drwx------. 2 sssd sssd 32 Dec 23 13:58 . drwxr-xr-x. 9 root root 94 Dec 19 17:05 .. -rw------- 1 sssd sssd 219 Dec 20 20:40 company.org.keytab Jakub Hrozek wrote: > In addition, can you also see if the keytab with the trust principal is > there? Probably it would be /var/lib/sss/keytabs/shanetest.org. > > At15:43:11, sssd tried to fetch the keytab for this trust: > (ThuDec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for shanetest.org > (ThuDec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_send] (0x0400): Retrieving keytab forcompanyidm$@SHANETEST.ORG from usaeilidmp002.companyidm.org into /var/lib/sss/keytabs/shanetest.org.keytabRw7Iai using ccache /var/lib/sss/db/ccache_companyidm.ORG > > But fails: > SASL Bind failed Can't contact LDAP server (-1) ! > Failed to bind to server! > Failed to get keytab > (ThuDec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_done] (0x0040): ipa-getkeytab failed with status [2304] > (ThuDec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_recv] (0x2000): ipa-getkeytab status 2304 > (ThuDec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [ipa_server_trust_1way_kt_done] (0x0080): ipa_getkeytab_recv failed: 1432158265 > > What I don't see in the logs, though is that if we try and re-fetch the > keytab after going online (we should, though). From lslebodn at redhat.com Fri Dec 23 21:04:46 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 23 Dec 2016 22:04:46 +0100 Subject: [Freeipa-users] Upgrade to 4.4.0 Breaks login. In-Reply-To: <20161223092955.ydbgqnzxeivthwdd@hendrix> References: <20161223092955.ydbgqnzxeivthwdd@hendrix> Message-ID: <20161223210445.GA23026@10.4.128.1> On (23/12/16 10:29), Jakub Hrozek wrote: >On Thu, Dec 22, 2016 at 08:38:38PM -0500, Dan Kemp wrote: >> Hello, >> >> I recently ran an upgrade of my freeipa servers, and most of the clients to >> 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install >> and server update, I can no longer log in to update clients via ssh. Login >> to non-update clients works as before. >> >> The SSH connections fail with: >> >> Connection closed by UNKNOWN >> >> I ran sssd with debugging on a failing 4.4.0 client and got this error log: >> >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >> ldb transaction (nesting: 2) >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >> ldb transaction (nesting: 1) >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >> ldb transaction (nesting: 0) >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] >> [selinux_child_create_buffer] (0x4000): buffer size: 45 >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] >> (0x2000): Setting up signal handler up for pid [437] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] >> (0x2000): Signal handler set up for pid [437] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] >> (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)], >> ldap[0x560c04c32d60] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] >> (0x2000): Trace: end of ldap_result list >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler] >> (0x0400): All data has been sent! >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): >> selinux_child started. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): >> Running with effective IDs: [0][0]. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): >> Running with real IDs [0][0]. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): >> context initialized >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): seuser length: 12 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): seuser: unconfined_u >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): mls_range length: 14 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): mls_range: s0-s0:c0.c1023 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): username length: 7 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): username: ipauser >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): >> performing selinux operations >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [sss_semanage_init] >> (0x0020): SELinux policy not managed >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [get_seuser] >> (0x0020): Cannot create SELinux handle >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] >> [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls: >> unknown >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [sss_semanage_init] >> (0x0020): SELinux policy not managed >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [set_seuser] >> (0x0020): Cannot init SELinux management >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): >> Cannot set SELinux login context. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): >> selinux_child failed! >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler] >> (0x0400): EOF received, client finished >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done] >> (0x0020): selinux_child_parse_response failed: [22][Invalid argument] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400): >> DP Request [PAM SELinux #3]: Request handler finished [0]: Success >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv] >> (0x0400): DP Request [PAM SELinux #3]: Receiving request data. >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] >> (0x0400): DP Request [PAM SELinux #3]: Request removed. >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] >> (0x0400): Number of active DP request: 0 >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply] >> (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] >> (0x1000): Waiting for child [437]. >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] >> (0x0020): child [437] failed with status [1]. >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): >> 0x55f4be11f4c0 >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: >> 0x55f4be1191b0 >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): >> Dispatching. >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): >> received: [4 (System error)][domain.local] >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply >> called with result [4]: System error. >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 39 >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle >> timer re-set for client [0x55f4be11f980][19] >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle >> timer re-set for client [0x55f4be11f980][19] >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_recv] (0x0200): Client >> disconnected! >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_close_fn] (0x2000): >> Terminated client [0x55f4be11f980][19] >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle >> timer re-set for client [0x5604f5217c60][22] >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client >> disconnected! >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): >> Terminated client [0x5604f5217c60][22] >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle >> timer re-set for client [0x5604f5216b20][21] >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client >> disconnected! >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): >> Terminated client [0x5604f5216b20][21] >> >> >> SeLinux is disabled, as I am running the clients in LXC containers on a >> debian host. My setup is pretty simple, and was working before (and >> connections to 4.2.0 clients are still functional!). Nothing looks amiss in >> the ssh logs. > Coudl you provide an output of "sestatus" from host and from LXC container? >If you don't use SELinux, then I'm quite sure you can just set: > selinux_provider=none >in the domain section of sssd.conf, then selinux_child won't be called >at all. > >But to be honest I'm not sure what exactly can cause the error about >sss_semanage_init(). Looking at libsemanage, they just connecto to the >policy store (typically /etc/selinux/targeted/modules/). The only idea I >have is that the store might not be there in the LXC container or, the >LXC container might not support extended FS attributes that are IIRC >used to store SELinux labels. > >Stracing the selinux child (see >https://fedorahosted.org/sssd/wiki/DevelTips#UsingstracetotracktheSSSDprocesses) >might give a better idea which exact syscall failed. > IMHO, LXC container is not created in best way. Did you mount bind /sys from host? Because all SElinux related code should check /sys/fs/selinux/ and /sys/fs/selinux/enforce. And they should not fail with SELinux in disabled mode. LS From jcnt at use.startmail.com Sat Dec 24 00:58:03 2016 From: jcnt at use.startmail.com (Josh) Date: Fri, 23 Dec 2016 19:58:03 -0500 Subject: [Freeipa-users] updating certificates In-Reply-To: <5783A8E6.4010407@redhat.com> References: <961a039c237577e3b3a460ab3a33e6d5.startmail@www.startmail.com> <57728EB8.2050805@redhat.com> <5783A8E6.4010407@redhat.com> Message-ID: <16f61b80-8f88-c861-bd40-3a8bdb48c093@use.startmail.com> Hi Rob, I'd like to really clarify renew certificate process. I can successfully update certificates in /etc/dirsrv/slapd-domain and /etc/httpd/alias but any new ipa client gets expired certificate still present someplace in LDAP. I was trying to use ipa-server-certinstall, described in https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/third-party-certs-http-ldap.html but document does not cover the case where intermediate certificate is required. Josh. On 07/11/2016 10:10 AM, Rob Crittenden wrote: > jcnt at use.startmail.com wrote: >> On Tuesday, June 28, 2016 10:50 AM, Rob Crittenden >> wrote: >>> jcnt at use.startmail.com wrote: >>>> Greetings, >>>> >>>> About a year ago I installed my freeipa server with certificates from >>>> startssl using command line options --dirsrv-cert-file >>>> --http-cert-file >>>> etc. >>>> The certificate is about to expire, what is the proper way to >>>> update it >>>> in all places? >>> >>> It depends on whether you kept the original CSR or not. If you kept the >>> original CSR and are just renewing the certificate(s) then when you get >>> the new one, use certutil to add the updated cert to the appropriate >>> NSS >>> database like: >>> >>> # certutil -A -n Server-Cert -d /etc/httpd/alias -t u,u,u -a -i >>> /path/to/new.crt >>> >> >> Rob, >> >> Thank you, that worked just fine, except that I had to update an >> intermediate certificate as well. >> >> Two questions, please: >> >> 1. I noticed a strange discrepancy in behavior between >> /etc/httpd/alias and /etc/dirsrv/slapd-domain. >> In both places original intermediate certificate is listed with empty >> ",," trust attributes so I initially added new intermediate >> certificate with empty attributes as well. >> certutils -V showed valid certificate in /etc/httpd/alias and not >> trusted in /etc/dirsrv/slapd-domain so I had to modify intermediate >> certificate with -t "C,," > > Hmm, not sure. Did the CA chain change in between the issuance of the > two certs? > > Adding a new certificate shouldn't affect the trust of any other certs > so I'm not sure what happened. It could be that those subordinate CAs > were loaded the first time incorrectly but weren't used so it wasn't > noticed, I'm not really sure. > >> 2. Just out of curiosity I wanted to list private keys and is >> prompted for a password: >> # certutil -K -d /etc/httpd/alias/ >> certutil: Checking token "NSS Certificate DB" in slot "NSS User >> Private Key and Certificate Services" >> Enter Password or Pin for "NSS Certificate DB": >> >> Which one of the many provided by a user passwords is used by >> ipa-server-install command during NSS database initialization? > > In each NSS directory there is a pwdfile.txt which contains the PIN > for the internal token. You can add -f /etc/httpd/alias/pwdfile.txt to > your command to list the private keys. > > rob From jcnt at use.startmail.com Sat Dec 24 02:44:23 2016 From: jcnt at use.startmail.com (Josh) Date: Fri, 23 Dec 2016 21:44:23 -0500 Subject: [Freeipa-users] updating certificates In-Reply-To: <98acba84-d06a-64dd-4521-57cbcfc21ade@redhat.com> References: <961a039c237577e3b3a460ab3a33e6d5.startmail@www.startmail.com> <57728EB8.2050805@redhat.com> <61e11459-f429-2d93-c0f4-d489911b0ecf@use.startmail.com> <98acba84-d06a-64dd-4521-57cbcfc21ade@redhat.com> Message-ID: <57e43dc2-d28c-0464-77f6-9a238ef5047a@use.startmail.com> Hi Flo, looks like ipa-certupdate requires /etc/ipa/nssdb to be already updated so it seems useless if existing certificates expired. I am experimenting on another server with expired certificates. Was able to successfully update /etc/httpd/alias and /etc/dirsrv/slapd-INSTANCE but ipa command still returns with SEC_ERROR_UNTRUSTED_ISSUER even though I updated /etc/ipa/nssdb with new intermediate certificate from startcom. Am I missing something else here? Josh. On 08/10/2016 04:22 AM, Florence Blanc-Renaud wrote: > Hi Josh, > > depending on your IPA version, you may consider using > ipa-server-certinstall and ipa-certupdate. > > ipa-server-certinstall can be used to install a new certificate for > Apache/LDAP servers, and ipa-certupdate to update the NSS DBs with the > CA certificates found in the LDAP server. > > Flo. > > On 08/09/2016 05:48 PM, Josh wrote: >> Rob, >> >> One must also update /etc/ipa/nssdb the same way, otherwise ipa cli tool >> gets SEC_ERROR_UNTRUSTED_ISSUER ! >> >> It would be nice to have an IPA tool to update all certificates in all >> required places. >> >> Also, why would I need to add CA that already in system ca-trust to the >> private IPA nssdb? >> >> Josh. >> >> >> On 06/28/2016 10:50 AM, Rob Crittenden wrote: >>> jcnt at use.startmail.com wrote: >>>> Greetings, >>>> >>>> About a year ago I installed my freeipa server with certificates from >>>> startssl using command line options --dirsrv-cert-file >>>> --http-cert-file >>>> etc. >>>> The certificate is about to expire, what is the proper way to >>>> update it >>>> in all places? >>> >>> It depends on whether you kept the original CSR or not. If you kept >>> the original CSR and are just renewing the certificate(s) then when >>> you get the new one, use certutil to add the updated cert to the >>> appropriate NSS database like: >>> >>> # certutil -A -n Server-Cert -d /etc/httpd/alias -t u,u,u -a -i >>> /path/to/new.crt >>> >>> If you need to generate a new CSR then you can use >>> ipa-server-certinstall to install the updated key and crt files. >>> >>> In either case probably worth backing up /etc/httpd/alias/*.db and >>> /etc/dirsrv/slapd-INSTANCE/*.db. >>> >>> rob >>> >> > From jcnt at use.startmail.com Sat Dec 24 04:54:33 2016 From: jcnt at use.startmail.com (Josh) Date: Fri, 23 Dec 2016 23:54:33 -0500 Subject: [Freeipa-users] section 2.3.6. Installing Without a CA - then how to update expired certificates in LDAP? Message-ID: <0a7ca3db-c076-c3c1-ecc4-01c86e2eef8a@use.startmail.com> I discussed this problem once before and got partial answers but I would like to finally resolve it. Scenario: 1. Install IPA without a CA, according to section 2.3.6 as of now in latest RHEL7 Linux Domain Identity, Authentication and Policy Guide. 2. Install a client and note certificates it receives from IPA LDAP. 3. Near expiration term obtain a new set of certificates (server and intermediate), note that intermediate certificate common name has changed. 4. run "ipa-server-certinstall -d -w key cert" to update all certificates. command asks for directory manager password, I suppose it should update its contents but 5. Install another client and observe that it receives original certificates and no ipa command works. 6. ipa-certupdate, when run, pulls original set from LDAP as if nothing was updated. Workaround is to manually install new intermediate certificate on all systems /etc/ipa/nssdb by certutil -d /etc/ipa/nssdb/ -A -n "StartCom Class 1 DV Server CA - StartCom Ltd." -t C,, -i /tmp/1_Intermediate.crt In LDAP under cn=certificates,cn=ipa,cn=etc,dc=example,dc=org I still see previous version of intermediate certificate with a different common name: StartCom Class 1 Primary Intermediate Server CA,OU=Secure Digital Certificate Signing,O=StartCom Ltd.,C=IL Please help me replace it by any means. Best Regards, Josh. From Dan.Finkelstein at high5games.com Sat Dec 24 08:33:37 2016 From: Dan.Finkelstein at high5games.com (Dan.Finkelstein at high5games.com) Date: Sat, 24 Dec 2016 08:33:37 +0000 Subject: [Freeipa-users] IPA 4.4.0: clcache_load_buffer_bulk error Message-ID: <9D9635E5-85D4-4612-8F16-172DDE464133@high5games.com> Since upgrading to IPA 4.4.0 and CentOS-7.3, our master has been outputting the follow line repeatedly in its slapd error logs: [24/Dec/2016:08:11:36.684385818 +0000] clcache_load_buffer_bulk - changelog record with csn (585e4369001500040000) not found for DB_NEXT What does it mean and, if repair is needed, what should I do? Thanks and regards, 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 lucas.diedrich at gmail.com Mon Dec 26 19:26:26 2016 From: lucas.diedrich at gmail.com (Lucas Diedrich) Date: Mon, 26 Dec 2016 19:26:26 +0000 Subject: [Freeipa-users] Ipa cert automatic renew Failing. In-Reply-To: <689e233d-1c18-eae0-2841-3a5374f7b205@redhat.com> References: <689e233d-1c18-eae0-2841-3a5374f7b205@redhat.com> Message-ID: Florence, at first i thought the problem was fixed, but it wasn't complety. So now, i'm at the CA Master, and when i try to see some certificates it prompts me this "[root at ipa2 ~]# ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: EXCEPTION (Invalid Credential.) " The same thing show over the Web Interface, i searched a little bit and found that probably it didn't updated the *ipara* user, but can't confirm that, any sugestions? Thanks, Em qui, 22 de dez de 2016 ?s 11:13, Florence Blanc-Renaud escreveu: > On 12/22/2016 01:15 PM, Lucas Diedrich wrote: > > Florence, for some creepy reason the cert from pkidbuser is different > > from subsystem certs, and this pkidbuser is outdated now, but i can't > > manage one way to re-issue it. I had to change the CA server because of > > that, and the Selinux in the old CA Server was disabled, on the new one > > is in Permissive mode but doesn't a warning in /var/log/audit/audit.log. > > > > This is the pkidbuser cert: > https://paste.fedoraproject.org/511023/24084431/ > > This is the subsystem cert: > https://paste.fedoraproject.org/511025/14824085/ > > The ca.subsystem.cert matches the pkidbuser cert. > > > > lucasdiedrich. > > > Hi, > > you can try to manually call the post-save command that certmonger > should have issued after putting the certificate in > /etc/pki/pki-tomcat/alias: > on the renewal master: > $ sudo /usr/libexec/ipa/certmonger/stop_pkicad > $ sudo /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert > cert-pki-ca" > > Then check the journal log that should display the following if > everything goes well: > $ sudo journalctl --since today | grep renew_ca_cert > [...] renew_ca_cert[6478]: Updating entry > uid=CA-ipaserver.domain.com-8443,ou=people,o=ipaca > [...] renew_ca_cert[6478]: Updating entry uid=pkidbuser,ou=people,o=ipaca > [...] renew_ca_cert[6478]: Starting pki_tomcatd > [...] renew_ca_cert[6478]: Started pki_tomcatd > > If the operation does not succeed, you will have to check the LDAP > server logs in /etc/dirsrv/slapd-DOMAIN/access. > > HTH, > Flo. > > > Em qui, 22 de dez de 2016 ?s 06:54, Florence Blanc-Renaud > > > escreveu: > > > > On 12/21/2016 07:52 PM, Lucas Diedrich wrote: > > > Hello guys, > > > > > > I'm having some trouble with, whats is happening with my server is > > that > > > i'm hiting an old BUG > > > (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to > > mbasti > > > over irc he oriented me to send this to the email list. > > > > > > The problem is, i got on CA Master, so because of this problem the > CA > > > Master certificates couldn't be renewd, so now i promoted another > > master > > > to be the CA. And the problem still persist. > > > > > > This is the certs from my new CA > > > (https://paste.fedoraproject.org/510617/14823448/), > > > this is the certs from my old CA > > > (https://paste.fedoraproject.org/510618/44871148/) > > > This is the log then i restart pki-tomcat( "CA port 636 Error > > > netscape.ldap.LDAPException: Authentication failed (49)") > > > This is the log from dirsrv when i restart pki-tomcat > > > (https://paste.fedoraproject.org/510614/23446801/) > > > > > > Basically my CA is not working anymore... > > > > > > Anyway, i tried lots of thing but couldn't fix this, anyone has > > some idea? > > > > > > > > > > > Hi, > > > > Pki-tomcat is using the LDAP server as a data store, meaning that it > > needs to authenticate to LDAP. In order to do that, pki-tomcat is > using > > the certificate 'subsystemCert cert-pki-ca' stored in > > /etc/pki/pki-tomcat/alias. For the authentication to succeed, the > > certificate must be stored in a user entry > > (uid=pkidbuser,ou=people,o=ipaca). > > > > Can you check the content of this entry, especially the > usercertificate > > attribute? It should match the certificate used by pki-tomcat: > > > > $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert > > cert-pki-ca' -a > > -----BEGIN CERTIFICATE----- > > [...] > > -----END CERTIFICATE----- > > > > $ kinit admin > > $ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b > > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate > > dn: uid=pkidbuser,ou=people,o=ipaca > > usercertificate:: > > > > The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this > > certificate in the directive ca.subsystem.cert. > > > > > > A possible cause for the entries not being updated is the bug 1366915 > > [1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE > linux > > on Fedora 24. > > > > Flo > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915 > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188 > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucas.diedrich at gmail.com Mon Dec 26 19:45:42 2016 From: lucas.diedrich at gmail.com (Lucas Diedrich) Date: Mon, 26 Dec 2016 19:45:42 +0000 Subject: [Freeipa-users] Ipa cert automatic renew Failing. In-Reply-To: References: <689e233d-1c18-eae0-2841-3a5374f7b205@redhat.com> Message-ID: OK!, i got it, i just executed the second script: "sudo /usr/libexec/ipa/certmonger/renew_ra_cert "subsystemCert cert-pki-ca"", and fixed that problem, there another script called renew_ra_cert_pre, should i run this too? Thanks. Em seg, 26 de dez de 2016 ?s 17:26, Lucas Diedrich escreveu: > Florence, at first i thought the problem was fixed, but it wasn't complety. > > So now, i'm at the CA Master, and when i try to see some certificates it > prompts me this "[root at ipa2 ~]# ipa cert-show 1 > ipa: ERROR: Certificate operation cannot be completed: EXCEPTION (Invalid > Credential.) > " > The same thing show over the Web Interface, i searched a little bit and > found that probably it didn't updated the *ipara* user, but can't confirm > that, any sugestions? > > Thanks, > > Em qui, 22 de dez de 2016 ?s 11:13, Florence Blanc-Renaud > escreveu: > > On 12/22/2016 01:15 PM, Lucas Diedrich wrote: > > Florence, for some creepy reason the cert from pkidbuser is different > > from subsystem certs, and this pkidbuser is outdated now, but i can't > > manage one way to re-issue it. I had to change the CA server because of > > that, and the Selinux in the old CA Server was disabled, on the new one > > is in Permissive mode but doesn't a warning in /var/log/audit/audit.log. > > > > This is the pkidbuser cert: > https://paste.fedoraproject.org/511023/24084431/ > > This is the subsystem cert: > https://paste.fedoraproject.org/511025/14824085/ > > The ca.subsystem.cert matches the pkidbuser cert. > > > > lucasdiedrich. > > > Hi, > > you can try to manually call the post-save command that certmonger > should have issued after putting the certificate in > /etc/pki/pki-tomcat/alias: > on the renewal master: > $ sudo /usr/libexec/ipa/certmonger/stop_pkicad > $ sudo /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert > cert-pki-ca" > > Then check the journal log that should display the following if > everything goes well: > $ sudo journalctl --since today | grep renew_ca_cert > [...] renew_ca_cert[6478]: Updating entry > uid=CA-ipaserver.domain.com-8443,ou=people,o=ipaca > [...] renew_ca_cert[6478]: Updating entry uid=pkidbuser,ou=people,o=ipaca > [...] renew_ca_cert[6478]: Starting pki_tomcatd > [...] renew_ca_cert[6478]: Started pki_tomcatd > > If the operation does not succeed, you will have to check the LDAP > server logs in /etc/dirsrv/slapd-DOMAIN/access. > > HTH, > Flo. > > > Em qui, 22 de dez de 2016 ?s 06:54, Florence Blanc-Renaud > > > escreveu: > > > > On 12/21/2016 07:52 PM, Lucas Diedrich wrote: > > > Hello guys, > > > > > > I'm having some trouble with, whats is happening with my server is > > that > > > i'm hiting an old BUG > > > (https://bugzilla.redhat.com/show_bug.cgi?id=1033273). Talking to > > mbasti > > > over irc he oriented me to send this to the email list. > > > > > > The problem is, i got on CA Master, so because of this problem the > CA > > > Master certificates couldn't be renewd, so now i promoted another > > master > > > to be the CA. And the problem still persist. > > > > > > This is the certs from my new CA > > > (https://paste.fedoraproject.org/510617/14823448/), > > > this is the certs from my old CA > > > (https://paste.fedoraproject.org/510618/44871148/) > > > This is the log then i restart pki-tomcat( "CA port 636 Error > > > netscape.ldap.LDAPException: Authentication failed (49)") > > > This is the log from dirsrv when i restart pki-tomcat > > > (https://paste.fedoraproject.org/510614/23446801/) > > > > > > Basically my CA is not working anymore... > > > > > > Anyway, i tried lots of thing but couldn't fix this, anyone has > > some idea? > > > > > > > > > > > Hi, > > > > Pki-tomcat is using the LDAP server as a data store, meaning that it > > needs to authenticate to LDAP. In order to do that, pki-tomcat is > using > > the certificate 'subsystemCert cert-pki-ca' stored in > > /etc/pki/pki-tomcat/alias. For the authentication to succeed, the > > certificate must be stored in a user entry > > (uid=pkidbuser,ou=people,o=ipaca). > > > > Can you check the content of this entry, especially the > usercertificate > > attribute? It should match the certificate used by pki-tomcat: > > > > $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert > > cert-pki-ca' -a > > -----BEGIN CERTIFICATE----- > > [...] > > -----END CERTIFICATE----- > > > > $ kinit admin > > $ ldapsearch -Y GSSAPI -h `hostname` -p 389 -b > > uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" usercertificate > > dn: uid=pkidbuser,ou=people,o=ipaca > > usercertificate:: > > > > The file /etc/pki/pki-tomcat/ca/CS.cfg should also contain this > > certificate in the directive ca.subsystem.cert. > > > > > > A possible cause for the entries not being updated is the bug 1366915 > > [1] linked to SE linux on RHEL7, or bug 1365188 [2] linked to SE > linux > > on Fedora 24. > > > > Flo > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1366915 > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1365188 > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlosla1987 at gmail.com Mon Dec 26 19:51:29 2016 From: carlosla1987 at gmail.com (=?UTF-8?Q?Carlos_Ra=C3=BAl_Laguna?=) Date: Mon, 26 Dec 2016 14:51:29 -0500 Subject: [Freeipa-users] Unable to add attributes to default user schema Message-ID: Hello everyone, I am trying to add a new attribute ?mailQuota? to the default user schema, so far i add the objectclass mailrecipient to the default user objectclasses which contain this specific atribute but so far i only capable to add the attribute manually with user-mod --addattr=mailQuota=102400 but when invoke config-mod --addattr=mailQuota=102400 i get ipa: ERROR: attribute "mailQuota" not allowed. Any way to get around this, also does https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf is still relevant for freeipa 4.3.2 ? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From outbackdingo at gmail.com Mon Dec 26 23:25:39 2016 From: outbackdingo at gmail.com (Outback Dingo) Date: Mon, 26 Dec 2016 18:25:39 -0500 Subject: [Freeipa-users] IPA Servers out of sync - DNS records Message-ID: Seems my secondary ipa server is somehow out of sync with the master, is there any way to force a sync update ? From kempd7 at gmail.com Fri Dec 23 12:43:13 2016 From: kempd7 at gmail.com (Dan Kemp) Date: Fri, 23 Dec 2016 07:43:13 -0500 Subject: [Freeipa-users] Upgrade to 4.4.0 Breaks login. In-Reply-To: <20161223093134.zk25q7xaj7zhdq7b@redhat.com> References: <20161223093134.zk25q7xaj7zhdq7b@redhat.com> Message-ID: That did it, thanks! I could have sworn I tried that, maybe I ended up putting it in in the wrong section. I wish whatever changed going from 4.2.0 to 4.4.0 that made SELinux required, took the selinux enforcement level into account and updated the file accordingly. On Fri, Dec 23, 2016 at 4:31 AM, Alexander Bokovoy wrote: > On to, 22 joulu 2016, Dan Kemp wrote: > >> Hello, >> >> I recently ran an upgrade of my freeipa servers, and most of the clients >> to >> 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install >> and server update, I can no longer log in to update clients via ssh. Login >> to non-update clients works as before. >> >> The SSH connections fail with: >> >> Connection closed by UNKNOWN >> >> I ran sssd with debugging on a failing 4.4.0 client and got this error >> log: >> >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >> ldb transaction (nesting: 2) >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >> ldb transaction (nesting: 1) >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit >> ldb transaction (nesting: 0) >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] >> [selinux_child_create_buffer] (0x4000): buffer size: 45 >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] >> (0x2000): Setting up signal handler up for pid [437] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] >> (0x2000): Signal handler set up for pid [437] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] >> (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)], >> ldap[0x560c04c32d60] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] >> (0x2000): Trace: end of ldap_result list >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler] >> (0x0400): All data has been sent! >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): >> selinux_child started. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): >> Running with effective IDs: [0][0]. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): >> Running with real IDs [0][0]. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): >> context initialized >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): seuser length: 12 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): seuser: unconfined_u >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): mls_range length: 14 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): mls_range: s0-s0:c0.c1023 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): username length: 7 >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] >> (0x2000): username: ipauser >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): >> performing selinux operations >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] >> [sss_semanage_init] >> (0x0020): SELinux policy not managed >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [get_seuser] >> (0x0020): Cannot create SELinux handle >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] >> [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls: >> unknown >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] >> [sss_semanage_init] >> (0x0020): SELinux policy not managed >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [set_seuser] >> (0x0020): Cannot init SELinux management >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): >> Cannot set SELinux login context. >> (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): >> selinux_child failed! >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler] >> (0x0400): EOF received, client finished >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done] >> (0x0020): selinux_child_parse_response failed: [22][Invalid argument] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] >> (0x0400): >> DP Request [PAM SELinux #3]: Request handler finished [0]: Success >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv] >> (0x0400): DP Request [PAM SELinux #3]: Receiving request data. >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] >> (0x0400): DP Request [PAM SELinux #3]: Request removed. >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] >> (0x0400): Number of active DP request: 0 >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply] >> (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local] >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] >> (0x1000): Waiting for child [437]. >> (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] >> (0x0020): child [437] failed with status [1]. >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): >> 0x55f4be11f4c0 >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus >> conn: >> 0x55f4be1191b0 >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): >> Dispatching. >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): >> received: [4 (System error)][domain.local] >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply >> called with result [4]: System error. >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 39 >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle >> timer re-set for client [0x55f4be11f980][19] >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle >> timer re-set for client [0x55f4be11f980][19] >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_recv] (0x0200): Client >> disconnected! >> (Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_close_fn] (0x2000): >> Terminated client [0x55f4be11f980][19] >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle >> timer re-set for client [0x5604f5217c60][22] >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client >> disconnected! >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): >> Terminated client [0x5604f5217c60][22] >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle >> timer re-set for client [0x5604f5216b20][21] >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client >> disconnected! >> (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): >> Terminated client [0x5604f5216b20][21] >> >> >> SeLinux is disabled, as I am running the clients in LXC containers on a >> debian host. My setup is pretty simple, and was working before (and >> connections to 4.2.0 clients are still functional!). Nothing looks amiss >> in >> the ssh logs. >> > Add selinux_provider=none to the domain section if you are not using > SELinux at all. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Dec 27 10:59:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Dec 2016 11:59:44 +0100 Subject: [Freeipa-users] IPA Servers out of sync - DNS records In-Reply-To: References: Message-ID: <4b91efa8-7c41-b093-0978-be14414817c8@redhat.com> On 27.12.2016 00:25, Outback Dingo wrote: > Seems my secondary ipa server is somehow out of sync with the master, > is there any way to force a sync update ? > Can you elaborate more? What exactly from DNS records is out of sync? Martin From md at collective-sense.com Tue Dec 27 11:07:55 2016 From: md at collective-sense.com (Maciej Drobniuch) Date: Tue, 27 Dec 2016 12:07:55 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> Message-ID: Hi Martin! Thank you for your time! On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti wrote: > > > On 22.12.2016 10:57, Maciej Drobniuch wrote: > > Hi Martin > > Appreciate your help! > > On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti wrote: > >> >> >> On 22.12.2016 09:37, Maciej Drobniuch wrote: >> >> Hi Martin >> >> Thank you for reply. >> >> 1. The dig is returning proper PTR record. I've added it manually to the >> zone and it's working. >> >> >> I was asking for SOA and zone name, IMO there is nothing secret about >> reverse zone name from private address space >> >> what returns this command on server? >> python -c 'import netaddr; from dns import resolver; ip = >> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; >> print resolver.zone_for_name(revn)' >> >> >> # python -c 'import netaddr; from dns import resolver; ip = > netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; print > resolver.zone_for_name(revn)' > 165.0.0.10.in-addr.arpa. > in-addr.arpa. > > > It looks that python-dns failed to find proper zone, what is supposed to > be authoritative zone for that record in your system? > How do your reverse zones look? > I have the reverse zone added. 0.0.10.in-addr.arpa. Do you know maybe how python/ipa is determining what's the dns server for the internal zone? As far I understood this is not a "access rights issue". It's a DNS PTR resolution problem with python(ipa's using python) ? > > > > 2. The problem exists while adding host entries or A records with "create >> reverse" option. >> >> That's why I asked to run dig, the code uses DNS system to determine zone. >> >> 3. If I'll bind a host with ipa-client-install the PTR record gets >> created in the reverse zone and it works >> >> Ok >> > Manually creating the PTR record works fine as well. > >> >> >> 4. The resolv.conf file has only the IPA server IP addres/localhost added. >> >> >> Have you changed it recently? >> > Yes, it pointed to outside 8.8.8.8, so the OS did not see the local > reverse zone. > Now it's pointing to localhost. And I get dig the PTRs. (I've manually > created the ptr) > > # dig -x 10.0.0.165 > > ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 > > ;; OPT PSEUDOSECTION: > ; E: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;165.0.0.10.in-addr.arpa. IN PTR > > ;; ANSWER SECTION: > 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int. > > ;; AUTHORITY SECTION: > 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int. > > > This authority section looks suspicious, I would expect something like > 0.0.10.in-addr.arpa. > > Back to question about your reverse zones. > I've intentionally hid our internal ip space, sorry, good catch my finger has slipped :). > > > ;; ADDITIONAL SECTION: > freeipa1.cs.int. 1200 IN A 10.0.0.200 > > ;; Query time: 3 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: czw gru 22 04:51:23 EST 2016 > ;; MSG SIZE rcvd: 124 > >> >> >> Martin >> >> >> >> Cheers! >> M. >> >> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti wrote: >> >>> Hello all :) >>> >>> On 20.12.2016 01:33, Maciej Drobniuch wrote: >>> >>> Hi All! >>> >>> I get the following message while adding a new hostname. >>> >>> "The host was added but the DNS update failed with: DNS reverse zone >>> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" >>> >>> >>> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165 >>> what will be in SOA answer? >>> >>> What is the name of reverse zone you have on IPA DNS server? >>> >>> >>> Martin >>> >>> >>> The reverse zone is configured and working. >>> When I am manually adding the PTR record to the reverse zone - all OK >>> >>> While adding a new host, the A record is being created but the PTR >>> fails with the message above. >>> >>> Reinstalling centos+IPA worked once but I had to reinstall again because >>> of problems with kerberos(probably dependencies). >>> >>> Not sure what is the root cause of the issue. >>> >>> VERSION: 4.4.0, API_VERSION: 2.213 >>> >>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 >>> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>> >>> Any help appreciated! >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> Collective-sense LLC >>> >>> >>> >>> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-sense LLC >> >> >> > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > 2410 Camino Ramon, Suite 129 > San Ramon, CA 94583 > > > Happy new year! -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Dec 27 11:08:39 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Dec 2016 12:08:39 +0100 Subject: [Freeipa-users] Unable to add attributes to default user schema In-Reply-To: References: Message-ID: <59ace638-1b56-4af4-8fc8-fa53afe40c84@redhat.com> On 26.12.2016 20:51, Carlos Ra?l Laguna wrote: > Hello everyone, > > I am trying to add a new attribute ?mailQuota? to the default user > schema, so far i add the objectclass mailrecipient to the default user > objectclasses which contain this specific atribute but so far i only > capable to add the attribute manually with user-mod > --addattr=mailQuota=102400 but when invoke config-mod > --addattr=mailQuota=102400 i get ipa: ERROR: attribute "mailQuota" not > allowed. Any way to get around this, also does > https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf is > still relevant for freeipa 4.3.2 ? > > Thanks in advance > > Hello, this is not right, config-mod --addattr=mailQuota=102400 this is not a way how to set a new attr with default value for users, to set custom value you need to use custom user_add pre-callback, slide 17 HTH Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Dec 27 11:24:12 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Dec 2016 12:24:12 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> Message-ID: <9e9c9e3c-aa42-3919-15d0-35d9951e4412@redhat.com> On 27.12.2016 12:07, Maciej Drobniuch wrote: > Hi Martin! > > Thank you for your time! > > On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti > wrote: > > > > On 22.12.2016 10:57, Maciej Drobniuch wrote: >> Hi Martin >> >> Appreciate your help! >> >> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti > > wrote: >> >> >> >> On 22.12.2016 09:37, Maciej Drobniuch wrote: >>> Hi Martin >>> >>> Thank you for reply. >>> >>> 1. The dig is returning proper PTR record. I've added it >>> manually to the zone and it's working. >> >> I was asking for SOA and zone name, IMO there is nothing >> secret about reverse zone name from private address space >> >> what returns this command on server? >> python -c 'import netaddr; from dns import resolver; ip = >> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print >> revn; print resolver.zone_for_name(revn)' >> >> >> # python -c 'import netaddr; from dns import resolver; ip = >> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print >> revn; print resolver.zone_for_name(revn)' >> 165.0.0.10.in-addr.arpa. >> in-addr.arpa. > > It looks that python-dns failed to find proper zone, what is > supposed to be authoritative zone for that record in your system? > How do your reverse zones look? > > I have the reverse zone added. > 0.0.10.in-addr.arpa. > > Do you know maybe how python/ipa is determining what's the dns server > for the internal zone? > As far I understood this is not a "access rights issue". It's a DNS > PTR resolution problem with python(ipa's using python) ? It doesn't care about resolver, python-dns is checking SOA records, it removes labels from left and tries to find best match zone what returns dig 0.0.10.in-addr.arpa. SOA ? > > > >> >>> 2. The problem exists while adding host entries or A records >>> with "create reverse" option. >> That's why I asked to run dig, the code uses DNS system to >> determine zone. >> >>> 3. If I'll bind a host with ipa-client-install the PTR >>> record gets created in the reverse zone and it works >> Ok >> >> Manually creating the PTR record works fine as well. >> >> >> >>> 4. The resolv.conf file has only the IPA server IP >>> addres/localhost added. >> >> Have you changed it recently? >> >> Yes, it pointed to outside 8.8.8.8, so the OS did not see the >> local reverse zone. >> Now it's pointing to localhost. And I get dig the PTRs. (I've >> manually created the ptr) >> >> # dig -x 10.0.0.165 >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592 >> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, >> ADDITIONAL: 2 >> >> ;; OPT PSEUDOSECTION: >> ; E: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;165.0.0.10.in-addr.arpa.INPTR >> >> ;; ANSWER SECTION: >> 165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int >> . >> >> ;; AUTHORITY SECTION: >> 1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int >> . >> > > This authority section looks suspicious, I would expect something > like 0.0.10.in-addr.arpa. > > Back to question about your reverse zones. > > I've intentionally hid our internal ip space, sorry, good catch my > finger has slipped :). So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig returned in authority section. > > >> ;; ADDITIONAL SECTION: >> freeipa1.cs.int .1200INA10.0.0.200 >> >> ;; Query time: 3 msec >> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> ;; WHEN: czw gru 22 04:51:23 EST 2016 >> ;; MSG SIZE rcvd: 124 >> >> >> >> Martin >> >> >>> >>> Cheers! >>> M. >>> >>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti >>> > wrote: >>> >>> Hello all :) >>> >>> >>> On 20.12.2016 01:33, Maciej Drobniuch wrote: >>>> Hi All! >>>> >>>> I get the following message while adding a new hostname. >>>> >>>> "The host was added but the DNS update failed with: DNS >>>> reverse zone in-addr.arpa. for IP address 10.0.0.165 is >>>> not managed by this server" >>> >>> IPA failed to get correct reverse zone, can you try dig >>> -x 10.0.0.165 what will be in SOA answer? >>> >>> What is the name of reverse zone you have on IPA DNS server? >>> >>> >>> Martin >>> >>>> >>>> The reverse zone is configured and working. >>>> When I am manually adding the PTR record to the reverse >>>> zone - all OK >>>> >>>> While adding a new host, the A record is being created >>>> but the PTR fails with the message above. >>>> >>>> Reinstalling centos+IPA worked once but I had to >>>> reinstall again because of problems with >>>> kerberos(probably dependencies). >>>> >>>> Not sure what is the root cause of the issue. >>>> >>>> VERSION: 4.4.0, API_VERSION: 2.213 >>>> >>>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri >>>> Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>> >>>> Any help appreciated! >>>> -- >>>> Best regards >>>> >>>> Maciej Drobniuch >>>> Network Security Engineer >>>> Collective-sense LLC >>>> >>>> >>> >>> >>> >>> >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> Collective-sense LLC >> >> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> 2410 Camino Ramon, Suite 129 >> San Ramon, CA 94583 > > > Happy new year! > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From outbackdingo at gmail.com Tue Dec 27 11:40:35 2016 From: outbackdingo at gmail.com (Outback Dingo) Date: Tue, 27 Dec 2016 06:40:35 -0500 Subject: [Freeipa-users] IPA Servers out of sync - DNS records In-Reply-To: <4b91efa8-7c41-b093-0978-be14414817c8@redhat.com> References: <4b91efa8-7c41-b093-0978-be14414817c8@redhat.com> Message-ID: On Tue, Dec 27, 2016 at 5:59 AM, Martin Basti wrote: > > > On 27.12.2016 00:25, Outback Dingo wrote: >> >> Seems my secondary ipa server is somehow out of sync with the master, >> is there any way to force a sync update ? >> > > Can you elaborate more? > > What exactly from DNS records is out of sync? > > Martin it appears as though at least one A record is missing there might be more but thats the first i noticed From mbasti at redhat.com Tue Dec 27 11:47:32 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Dec 2016 12:47:32 +0100 Subject: [Freeipa-users] IPA Servers out of sync - DNS records In-Reply-To: References: <4b91efa8-7c41-b093-0978-be14414817c8@redhat.com> Message-ID: On 27.12.2016 12:40, Outback Dingo wrote: > On Tue, Dec 27, 2016 at 5:59 AM, Martin Basti wrote: >> >> On 27.12.2016 00:25, Outback Dingo wrote: >>> Seems my secondary ipa server is somehow out of sync with the master, >>> is there any way to force a sync update ? >>> >> Can you elaborate more? >> >> What exactly from DNS records is out of sync? >> >> Martin > > it appears as though at least one A record is missing there might be > more but thats the first i noticed Can you please search for replication conflicts https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html and do you have any replication errors in /var/log/dirsrv/slapd-*/errors log on servers? Martin From outbackdingo at gmail.com Tue Dec 27 11:55:41 2016 From: outbackdingo at gmail.com (Outback Dingo) Date: Tue, 27 Dec 2016 06:55:41 -0500 Subject: [Freeipa-users] IPA Servers out of sync - DNS records In-Reply-To: References: <4b91efa8-7c41-b093-0978-be14414817c8@redhat.com> Message-ID: On Tue, Dec 27, 2016 at 6:47 AM, Martin Basti wrote: > > > On 27.12.2016 12:40, Outback Dingo wrote: >> >> On Tue, Dec 27, 2016 at 5:59 AM, Martin Basti wrote: >>> >>> >>> On 27.12.2016 00:25, Outback Dingo wrote: >>>> >>>> Seems my secondary ipa server is somehow out of sync with the master, >>>> is there any way to force a sync update ? >>>> >>> Can you elaborate more? >>> >>> What exactly from DNS records is out of sync? >>> >>> Martin >> >> >> it appears as though at least one A record is missing there might be >> more but thats the first i noticed > > > > Can you please search for replication conflicts > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > > and do you have any replication errors in /var/log/dirsrv/slapd-*/errors > log on servers? > > Martin from the master ipa [root at ipa dingo]# cat /var/log/dirsrv/slapd-*/errors 389-Directory/1.3.4.0 B2016.215.1556 ipa.optimcloud.com:636 (/etc/dirsrv/slapd-OPTIMCLOUD-COM) [20/Dec/2016:22:38:51 -0500] - SSL alert: Configured NSS Ciphers [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_RSA_WITH_AES_256_GCM_SHA384: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [20/Dec/2016:22:38:51 -0500] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [20/Dec/2016:22:38:51 -0500] - 389-Directory/1.3.4.0 B2016.215.1556 starting up [20/Dec/2016:22:38:51 -0500] - WARNING: changelog: entry cache size 2097152B is less than db size 4169728B; We recommend to increase the entry cache size nsslapd-cachememsize. [20/Dec/2016:22:38:51 -0500] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [20/Dec/2016:22:38:52 -0500] schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup! [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target ou=sudoers,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=users,cn=compat,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [20/Dec/2016:22:38:52 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=optimcloud,dc=com--no CoS Templates found, which should be added before the CoS Definition. [20/Dec/2016:22:38:53 -0500] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=optimcloud,dc=com. Check if DB RUV needs to be updated [20/Dec/2016:22:38:53 -0500] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated [20/Dec/2016:22:38:53 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/ipa.optimcloud.com at OPTIMCLOUD.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [20/Dec/2016:22:38:53 -0500] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 111 (Connection refused) [20/Dec/2016:22:38:53 -0500] NSMMReplicationPlugin - agmt="cn=masterAgreement1-ipa2.optimcloud.com-pki-tomcat" (ipa2:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) () [20/Dec/2016:22:38:53 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 111 (Connection refused) [20/Dec/2016:22:38:53 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [20/Dec/2016:22:38:53 -0500] NSMMReplicationPlugin - agmt="cn=meToipa2.optimcloud.com" (ipa2:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [20/Dec/2016:22:38:53 -0500] schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds! [20/Dec/2016:22:38:53 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [20/Dec/2016:22:38:53 -0500] - Listening on All Interfaces port 636 for LDAPS requests [20/Dec/2016:22:38:53 -0500] - Listening on /var/run/slapd-OPTIMCLOUD-COM.socket for LDAPI requests [20/Dec/2016:22:38:57 -0500] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=optimcloud,dc=com [20/Dec/2016:22:38:58 -0500] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=optimcloud,dc=com [20/Dec/2016:22:38:58 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=optimcloud,dc=com [20/Dec/2016:22:38:58 -0500] schema-compat-plugin - Finished plugin initialization. [20/Dec/2016:22:38:58 -0500] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:38:58 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:38:58 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [20/Dec/2016:22:39:05 -0500] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:39:05 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:39:05 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [20/Dec/2016:22:39:17 -0500] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:39:17 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:39:17 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [20/Dec/2016:22:39:41 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:39:41 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [20/Dec/2016:22:39:41 -0500] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:40:29 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:40:29 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [20/Dec/2016:22:40:29 -0500] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:42:05 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:42:05 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [20/Dec/2016:22:42:05 -0500] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:45:17 -0500] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:45:17 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [20/Dec/2016:22:45:17 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - agmt="cn=masterAgreement1-ipa2.optimcloud.com-pki-tomcat" (ipa2:389): Replication bind with SIMPLE auth resumed [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - agmt="cn=meToipa2.optimcloud.com" (ipa2:389): Replication bind with GSSAPI auth resumed [20/Dec/2016:22:50:14 -0500] agmt="cn=masterAgreement1-ipa2.optimcloud.com-pki-tomcat" (ipa2:389) - Can't locate CSN 5852cec0000000600000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - agmt="cn=masterAgreement1-ipa2.optimcloud.com-pki-tomcat" (ipa2:389): Missing data encountered [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - agmt="cn=masterAgreement1-ipa2.optimcloud.com-pki-tomcat" (ipa2:389): Incremental update failed and requires administrator action [20/Dec/2016:22:50:14 -0500] agmt="cn=meToipa2.optimcloud.com" (ipa2:389) - Can't locate CSN 58528dac000200040000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - agmt="cn=meToipa2.optimcloud.com" (ipa2:389): Missing data encountered [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - agmt="cn=meToipa2.optimcloud.com" (ipa2:389): Incremental update failed and requires administrator action from the ipa2 slave [root at ipa2 dingo]# cat /var/log/dirsrv/slapd-*/errors 389-Directory/1.3.4.0 B2016.215.1556 ipa2.optimcloud.com:636 (/etc/dirsrv/slapd-OPTIMCLOUD-COM) [20/Dec/2016:22:49:22 -0500] - SSL alert: Configured NSS Ciphers [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_RSA_WITH_AES_256_GCM_SHA384: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [20/Dec/2016:22:49:22 -0500] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [20/Dec/2016:22:49:22 -0500] - 389-Directory/1.3.4.0 B2016.215.1556 starting up [20/Dec/2016:22:49:22 -0500] - WARNING: changelog: entry cache size 2097152B is less than db size 4104192B; We recommend to increase the entry cache size nsslapd-cachememsize. [20/Dec/2016:22:49:22 -0500] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [20/Dec/2016:22:49:22 -0500] schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup! [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target ou=sudoers,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=users,cn=compat,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not exist [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [20/Dec/2016:22:49:22 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=optimcloud,dc=com--no CoS Templates found, which should be added before the CoS Definition. [20/Dec/2016:22:49:24 -0500] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated [20/Dec/2016:22:49:24 -0500] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=optimcloud,dc=com. Check if DB RUV needs to be updated [20/Dec/2016:22:49:24 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/ipa2.optimcloud.com at OPTIMCLOUD.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [20/Dec/2016:22:49:24 -0500] schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds! [20/Dec/2016:22:49:24 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Succ ess) [20/Dec/2016:22:49:24 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) [20/Dec/2016:22:49:24 -0500] NSMMReplicationPlugin - agmt="cn=meToipa.optimcloud.com" (ipa:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) [20/Dec/2016:22:49:24 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [20/Dec/2016:22:49:24 -0500] - Listening on All Interfaces port 636 for LDAPS requests [20/Dec/2016:22:49:24 -0500] - Listening on /var/run/slapd-OPTIMCLOUD-COM.socket for LDAPI requests [20/Dec/2016:22:49:27 -0500] NSMMReplicationPlugin - agmt="cn=meToipa.optimcloud.com" (ipa:389): Replication bind with GSSAPI auth resumed [20/Dec/2016:22:49:28 -0500] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=optimcloud,dc=com [20/Dec/2016:22:49:28 -0500] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=optimcloud,dc=com [20/Dec/2016:22:49:28 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=optimcloud,dc=com [20/Dec/2016:22:49:29 -0500] schema-compat-plugin - Finished plugin initialization. [22/Dec/2016:21:01:17 -0500] - SSL alert: Configured NSS Ciphers [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_RSA_WITH_AES_256_GCM_SHA384: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [22/Dec/2016:21:01:17 -0500] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [22/Dec/2016:21:01:17 -0500] - 389-Directory/1.3.4.0 B2016.215.1556 starting up [22/Dec/2016:21:01:18 -0500] - WARNING: changelog: entry cache size 2097152B is less than db size 4096000B; We recommend to increase the entry cache size nsslapd-cachememsize. [22/Dec/2016:21:01:18 -0500] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [22/Dec/2016:21:01:19 -0500] schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup! [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target ou=sudoers,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=users,cn=compat,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not exist [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [22/Dec/2016:21:01:19 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=optimcloud,dc=com--no CoS Templates found, which should be added before the CoS Definition. [22/Dec/2016:21:01:21 -0500] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica o=ipaca. Check if DB RUV needs to be updated [22/Dec/2016:21:01:21 -0500] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: disordely shutdown for replica dc=optimcloud,dc=com. Check if DB RUV needs to be updated [22/Dec/2016:21:01:21 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/ipa2.optimcloud.com at OPTIMCLOUD.COM] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [22/Dec/2016:21:01:21 -0500] schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds! [22/Dec/2016:21:01:21 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) errno 0 (Succ ess) [22/Dec/2016:21:01:21 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -2 (Local error) [22/Dec/2016:21:01:21 -0500] NSMMReplicationPlugin - agmt="cn=meToipa.optimcloud.com" (ipa:389): Replication bind with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available)) [22/Dec/2016:21:01:21 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [22/Dec/2016:21:01:21 -0500] - Listening on All Interfaces port 636 for LDAPS requests [22/Dec/2016:21:01:21 -0500] - Listening on /var/run/slapd-OPTIMCLOUD-COM.socket for LDAPI requests [22/Dec/2016:21:01:24 -0500] NSMMReplicationPlugin - agmt="cn=meToipa.optimcloud.com" (ipa:389): Replication bind with GSSAPI auth resumed [22/Dec/2016:21:01:25 -0500] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=optimcloud,dc=com [22/Dec/2016:21:01:26 -0500] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=optimcloud,dc=com [22/Dec/2016:21:01:26 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=optimcloud,dc=com [22/Dec/2016:21:01:26 -0500] schema-compat-plugin - Finished plugin initialization. From mbasti at redhat.com Tue Dec 27 12:04:11 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Dec 2016 13:04:11 +0100 Subject: [Freeipa-users] IPA Servers out of sync - DNS records In-Reply-To: References: <4b91efa8-7c41-b093-0978-be14414817c8@redhat.com> Message-ID: <67928c0b-9c50-0f6b-e7c0-6476446fc771@redhat.com> On 27.12.2016 12:55, Outback Dingo wrote: > On Tue, Dec 27, 2016 at 6:47 AM, Martin Basti wrote: >> >> On 27.12.2016 12:40, Outback Dingo wrote: >>> On Tue, Dec 27, 2016 at 5:59 AM, Martin Basti wrote: >>>> >>>> On 27.12.2016 00:25, Outback Dingo wrote: >>>>> Seems my secondary ipa server is somehow out of sync with the master, >>>>> is there any way to force a sync update ? >>>>> >>>> Can you elaborate more? >>>> >>>> What exactly from DNS records is out of sync? >>>> >>>> Martin >>> >>> it appears as though at least one A record is missing there might be >>> more but thats the first i noticed >> >> >> Can you please search for replication conflicts >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html >> >> and do you have any replication errors in /var/log/dirsrv/slapd-*/errors >> log on servers? >> >> Martin > from the master ipa > > [root at ipa dingo]# cat /var/log/dirsrv/slapd-*/errors > 389-Directory/1.3.4.0 B2016.215.1556 > ipa.optimcloud.com:636 (/etc/dirsrv/slapd-OPTIMCLOUD-COM) > > [20/Dec/2016:22:38:51 -0500] - SSL alert: Configured NSS Ciphers > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_GCM_SHA384: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] - SSL alert: > TLS_RSA_WITH_SEED_CBC_SHA: enabled > [20/Dec/2016:22:38:51 -0500] SSL Initialization - Configured SSL > version range: min: TLS1.0, max: TLS1.2 > [20/Dec/2016:22:38:51 -0500] - 389-Directory/1.3.4.0 B2016.215.1556 starting up > [20/Dec/2016:22:38:51 -0500] - WARNING: changelog: entry cache size > 2097152B is less than db size 4169728B; We recommend to increase the > entry cache size nsslapd-cachememsize. > [20/Dec/2016:22:38:51 -0500] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. > [20/Dec/2016:22:38:52 -0500] schema-compat-plugin - scheduled > schema-compat-plugin tree scan in about 5 seconds after the server > startup! > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=groups,cn=compat,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=computers,cn=compat,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=ng,cn=compat,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > ou=sudoers,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=users,cn=compat,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=ad,cn=etc,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not > exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not > exist > [20/Dec/2016:22:38:52 -0500] NSACLPlugin - The ACL target > cn=automember rebuild membership,cn=tasks,cn=config does not exist > [20/Dec/2016:22:38:52 -0500] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=optimcloud,dc=com--no CoS Templates found, which > should be added before the CoS Definition. > [20/Dec/2016:22:38:53 -0500] NSMMReplicationPlugin - > replica_check_for_data_reload: Warning: disordely shutdown for replica > dc=optimcloud,dc=com. Check if DB RUV needs to be updated > [20/Dec/2016:22:38:53 -0500] NSMMReplicationPlugin - > replica_check_for_data_reload: Warning: disordely shutdown for replica > o=ipaca. Check if DB RUV needs to be updated > [20/Dec/2016:22:38:53 -0500] set_krb5_creds - Could not get initial > credentials for principal [ldap/ipa.optimcloud.com at OPTIMCLOUD.COM] in > keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any > KDC for requested realm) > [20/Dec/2016:22:38:53 -0500] slapi_ldap_bind - Error: could not send > startTLS request: error -1 (Can't contact LDAP server) errno 111 > (Connection refused) > [20/Dec/2016:22:38:53 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-ipa2.optimcloud.com-pki-tomcat" (ipa2:389): > Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact > LDAP server) () > [20/Dec/2016:22:38:53 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 111 (Connection refused) > [20/Dec/2016:22:38:53 -0500] slapi_ldap_bind - Error: could not > perform interactive bind for id [] authentication mechanism [GSSAPI]: > error -1 (Can't contact LDAP server) > [20/Dec/2016:22:38:53 -0500] NSMMReplicationPlugin - > agmt="cn=meToipa2.optimcloud.com" (ipa2:389): Replication bind with > GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () > [20/Dec/2016:22:38:53 -0500] schema-compat-plugin - > schema-compat-plugin tree scan will start in about 5 seconds! > [20/Dec/2016:22:38:53 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [20/Dec/2016:22:38:53 -0500] - Listening on All Interfaces port 636 > for LDAPS requests > [20/Dec/2016:22:38:53 -0500] - Listening on > /var/run/slapd-OPTIMCLOUD-COM.socket for LDAPI requests > [20/Dec/2016:22:38:57 -0500] schema-compat-plugin - warning: no > entries set up under ou=sudoers,dc=optimcloud,dc=com > [20/Dec/2016:22:38:58 -0500] schema-compat-plugin - warning: no > entries set up under cn=ng, cn=compat,dc=optimcloud,dc=com > [20/Dec/2016:22:38:58 -0500] schema-compat-plugin - warning: no > entries set up under cn=computers, cn=compat,dc=optimcloud,dc=com > [20/Dec/2016:22:38:58 -0500] schema-compat-plugin - Finished plugin > initialization. > [20/Dec/2016:22:38:58 -0500] slapi_ldap_bind - Error: could not send > startTLS request: error -1 (Can't contact LDAP server) errno 107 > (Transport endpoint is not connected) > [20/Dec/2016:22:38:58 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > [20/Dec/2016:22:38:58 -0500] slapi_ldap_bind - Error: could not > perform interactive bind for id [] authentication mechanism [GSSAPI]: > error -1 (Can't contact LDAP server) > [20/Dec/2016:22:39:05 -0500] slapi_ldap_bind - Error: could not send > startTLS request: error -1 (Can't contact LDAP server) errno 107 > (Transport endpoint is not connected) > [20/Dec/2016:22:39:05 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > [20/Dec/2016:22:39:05 -0500] slapi_ldap_bind - Error: could not > perform interactive bind for id [] authentication mechanism [GSSAPI]: > error -1 (Can't contact LDAP server) > [20/Dec/2016:22:39:17 -0500] slapi_ldap_bind - Error: could not send > startTLS request: error -1 (Can't contact LDAP server) errno 107 > (Transport endpoint is not connected) > [20/Dec/2016:22:39:17 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > [20/Dec/2016:22:39:17 -0500] slapi_ldap_bind - Error: could not > perform interactive bind for id [] authentication mechanism [GSSAPI]: > error -1 (Can't contact LDAP server) > [20/Dec/2016:22:39:41 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > [20/Dec/2016:22:39:41 -0500] slapi_ldap_bind - Error: could not > perform interactive bind for id [] authentication mechanism [GSSAPI]: > error -1 (Can't contact LDAP server) > [20/Dec/2016:22:39:41 -0500] slapi_ldap_bind - Error: could not send > startTLS request: error -1 (Can't contact LDAP server) errno 107 > (Transport endpoint is not connected) > [20/Dec/2016:22:40:29 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > [20/Dec/2016:22:40:29 -0500] slapi_ldap_bind - Error: could not > perform interactive bind for id [] authentication mechanism [GSSAPI]: > error -1 (Can't contact LDAP server) > [20/Dec/2016:22:40:29 -0500] slapi_ldap_bind - Error: could not send > startTLS request: error -1 (Can't contact LDAP server) errno 107 > (Transport endpoint is not connected) > [20/Dec/2016:22:42:05 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > [20/Dec/2016:22:42:05 -0500] slapi_ldap_bind - Error: could not > perform interactive bind for id [] authentication mechanism [GSSAPI]: > error -1 (Can't contact LDAP server) > [20/Dec/2016:22:42:05 -0500] slapi_ldap_bind - Error: could not send > startTLS request: error -1 (Can't contact LDAP server) errno 107 > (Transport endpoint is not connected) > [20/Dec/2016:22:45:17 -0500] slapi_ldap_bind - Error: could not send > startTLS request: error -1 (Can't contact LDAP server) errno 107 > (Transport endpoint is not connected) > [20/Dec/2016:22:45:17 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > [20/Dec/2016:22:45:17 -0500] slapi_ldap_bind - Error: could not > perform interactive bind for id [] authentication mechanism [GSSAPI]: > error -1 (Can't contact LDAP server) > [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-ipa2.optimcloud.com-pki-tomcat" (ipa2:389): > Replication bind with SIMPLE auth resumed > [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - > agmt="cn=meToipa2.optimcloud.com" (ipa2:389): Replication bind with > GSSAPI auth resumed > [20/Dec/2016:22:50:14 -0500] > agmt="cn=masterAgreement1-ipa2.optimcloud.com-pki-tomcat" (ipa2:389) - > Can't locate CSN 5852cec0000000600000 in the changelog (DB rc=-30988). > If replication stops, the consumer may need to be reinitialized. > [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-ipa2.optimcloud.com-pki-tomcat" (ipa2:389): > Missing data encountered > [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - > agmt="cn=masterAgreement1-ipa2.optimcloud.com-pki-tomcat" (ipa2:389): > Incremental update failed and requires administrator action > [20/Dec/2016:22:50:14 -0500] agmt="cn=meToipa2.optimcloud.com" > (ipa2:389) - Can't locate CSN 58528dac000200040000 in the changelog > (DB rc=-30988). If replication stops, the consumer may need to be > reinitialized. > [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - > agmt="cn=meToipa2.optimcloud.com" (ipa2:389): Missing data encountered > [20/Dec/2016:22:50:14 -0500] NSMMReplicationPlugin - > agmt="cn=meToipa2.optimcloud.com" (ipa2:389): Incremental update > failed and requires administrator action > > from the ipa2 slave > > [root at ipa2 dingo]# cat /var/log/dirsrv/slapd-*/errors > 389-Directory/1.3.4.0 B2016.215.1556 > ipa2.optimcloud.com:636 (/etc/dirsrv/slapd-OPTIMCLOUD-COM) > > [20/Dec/2016:22:49:22 -0500] - SSL alert: Configured NSS Ciphers > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_GCM_SHA384: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] - SSL alert: > TLS_RSA_WITH_SEED_CBC_SHA: enabled > [20/Dec/2016:22:49:22 -0500] SSL Initialization - Configured SSL > version range: min: TLS1.0, max: TLS1.2 > [20/Dec/2016:22:49:22 -0500] - 389-Directory/1.3.4.0 B2016.215.1556 starting up > [20/Dec/2016:22:49:22 -0500] - WARNING: changelog: entry cache size > 2097152B is less than db size 4104192B; We recommend to increase the > entry cache size nsslapd-cachememsize. > [20/Dec/2016:22:49:22 -0500] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. > [20/Dec/2016:22:49:22 -0500] schema-compat-plugin - scheduled > schema-compat-plugin tree scan in about 5 seconds after the server > startup! > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=groups,cn=compat,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=computers,cn=compat,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=ng,cn=compat,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > ou=sudoers,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=users,cn=compat,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=ad,cn=etc,dc=optimcloud,dc=com does not exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not > exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not > exist > [20/Dec/2016:22:49:22 -0500] NSACLPlugin - The ACL target > cn=automember rebuild membership,cn=tasks,cn=config does not exist > [20/Dec/2016:22:49:22 -0500] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=optimcloud,dc=com--no CoS Templates found, which > should be added before the CoS Definition. > [20/Dec/2016:22:49:24 -0500] NSMMReplicationPlugin - > replica_check_for_data_reload: Warning: disordely shutdown for replica > o=ipaca. Check if DB RUV needs to be updated > [20/Dec/2016:22:49:24 -0500] NSMMReplicationPlugin - > replica_check_for_data_reload: Warning: disordely shutdown for replica > dc=optimcloud,dc=com. Check if DB RUV needs to be updated > [20/Dec/2016:22:49:24 -0500] set_krb5_creds - Could not get initial > credentials for principal [ldap/ipa2.optimcloud.com at OPTIMCLOUD.COM] in > keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any > KDC for requested realm) > [20/Dec/2016:22:49:24 -0500] schema-compat-plugin - > schema-compat-plugin tree scan will start in about 5 seconds! > [20/Dec/2016:22:49:24 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (No Kerberos > credentials available)) errno 0 (Succ > ess) > [20/Dec/2016:22:49:24 -0500] slapi_ldap_bind - Error: could not > perform interactive bind for id [] authentication mechanism [GSSAPI]: > error -2 (Local error) > [20/Dec/2016:22:49:24 -0500] NSMMReplicationPlugin - > agmt="cn=meToipa.optimcloud.com" (ipa:389): Replication bind with > GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic > failure: GSSAPI Error: Unspecified GSS failure. Minor code may > provide more information (No Kerberos credentials available)) > [20/Dec/2016:22:49:24 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [20/Dec/2016:22:49:24 -0500] - Listening on All Interfaces port 636 > for LDAPS requests > [20/Dec/2016:22:49:24 -0500] - Listening on > /var/run/slapd-OPTIMCLOUD-COM.socket for LDAPI requests > [20/Dec/2016:22:49:27 -0500] NSMMReplicationPlugin - > agmt="cn=meToipa.optimcloud.com" (ipa:389): Replication bind with > GSSAPI auth resumed > [20/Dec/2016:22:49:28 -0500] schema-compat-plugin - warning: no > entries set up under ou=sudoers,dc=optimcloud,dc=com > [20/Dec/2016:22:49:28 -0500] schema-compat-plugin - warning: no > entries set up under cn=ng, cn=compat,dc=optimcloud,dc=com > [20/Dec/2016:22:49:28 -0500] schema-compat-plugin - warning: no > entries set up under cn=computers, cn=compat,dc=optimcloud,dc=com > [20/Dec/2016:22:49:29 -0500] schema-compat-plugin - Finished plugin > initialization. > [22/Dec/2016:21:01:17 -0500] - SSL alert: Configured NSS Ciphers > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_GCM_SHA384: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_RSA_WITH_AES_256_CBC_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_GCM_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_RSA_WITH_AES_128_CBC_SHA256: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] - SSL alert: > TLS_RSA_WITH_SEED_CBC_SHA: enabled > [22/Dec/2016:21:01:17 -0500] SSL Initialization - Configured SSL > version range: min: TLS1.0, max: TLS1.2 > [22/Dec/2016:21:01:17 -0500] - 389-Directory/1.3.4.0 B2016.215.1556 starting up > [22/Dec/2016:21:01:18 -0500] - WARNING: changelog: entry cache size > 2097152B is less than db size 4096000B; We recommend to increase the > entry cache size nsslapd-cachememsize. > [22/Dec/2016:21:01:18 -0500] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. > [22/Dec/2016:21:01:19 -0500] schema-compat-plugin - scheduled > schema-compat-plugin tree scan in about 5 seconds after the server > startup! > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=groups,cn=compat,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=computers,cn=compat,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=ng,cn=compat,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > ou=sudoers,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=users,cn=compat,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=ad,cn=etc,dc=optimcloud,dc=com does not exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not > exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not > exist > [22/Dec/2016:21:01:19 -0500] NSACLPlugin - The ACL target > cn=automember rebuild membership,cn=tasks,cn=config does not exist > [22/Dec/2016:21:01:19 -0500] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=optimcloud,dc=com--no CoS Templates found, which > should be added before the CoS Definition. > [22/Dec/2016:21:01:21 -0500] NSMMReplicationPlugin - > replica_check_for_data_reload: Warning: disordely shutdown for replica > o=ipaca. Check if DB RUV needs to be updated > [22/Dec/2016:21:01:21 -0500] NSMMReplicationPlugin - > replica_check_for_data_reload: Warning: disordely shutdown for replica > dc=optimcloud,dc=com. Check if DB RUV needs to be updated > [22/Dec/2016:21:01:21 -0500] set_krb5_creds - Could not get initial > credentials for principal [ldap/ipa2.optimcloud.com at OPTIMCLOUD.COM] in > keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any > KDC for requested realm) > [22/Dec/2016:21:01:21 -0500] schema-compat-plugin - > schema-compat-plugin tree scan will start in about 5 seconds! > [22/Dec/2016:21:01:21 -0500] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (No Kerberos > credentials available)) errno 0 (Succ > ess) > [22/Dec/2016:21:01:21 -0500] slapi_ldap_bind - Error: could not > perform interactive bind for id [] authentication mechanism [GSSAPI]: > error -2 (Local error) > [22/Dec/2016:21:01:21 -0500] NSMMReplicationPlugin - > agmt="cn=meToipa.optimcloud.com" (ipa:389): Replication bind with > GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic > failure: GSSAPI Error: Unspecified GSS failure. Minor code may > provide more information (No Kerberos credentials available)) > [22/Dec/2016:21:01:21 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [22/Dec/2016:21:01:21 -0500] - Listening on All Interfaces port 636 > for LDAPS requests > [22/Dec/2016:21:01:21 -0500] - Listening on > /var/run/slapd-OPTIMCLOUD-COM.socket for LDAPI requests > [22/Dec/2016:21:01:24 -0500] NSMMReplicationPlugin - > agmt="cn=meToipa.optimcloud.com" (ipa:389): Replication bind with > GSSAPI auth resumed > [22/Dec/2016:21:01:25 -0500] schema-compat-plugin - warning: no > entries set up under ou=sudoers,dc=optimcloud,dc=com > [22/Dec/2016:21:01:26 -0500] schema-compat-plugin - warning: no > entries set up under cn=ng, cn=compat,dc=optimcloud,dc=com > [22/Dec/2016:21:01:26 -0500] schema-compat-plugin - warning: no > entries set up under cn=computers, cn=compat,dc=optimcloud,dc=com > [22/Dec/2016:21:01:26 -0500] schema-compat-plugin - Finished plugin > initialization. According to log, it looks that replication has been restored a week ago can you use https://github.com/peterpakos/ipa_check_consistency to check what else is missing? If it finds missing entries, probably re-initialization will be needed Martin From md at collective-sense.com Tue Dec 27 12:04:17 2016 From: md at collective-sense.com (Maciej Drobniuch) Date: Tue, 27 Dec 2016 13:04:17 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: <9e9c9e3c-aa42-3919-15d0-35d9951e4412@redhat.com> References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> <9e9c9e3c-aa42-3919-15d0-35d9951e4412@redhat.com> Message-ID: $ dig 0.0.10.in-addr.arpa ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;0.0.10.in-addr.arpa. IN A ;; AUTHORITY SECTION: 0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int. 1482653944 3600 900 1209600 3600 ;; Query time: 197 msec ;; SERVER: 10.0.0.200#53(10.0.0.200) ;; WHEN: Tue Dec 27 13:02:24 CET 2016 ;; MSG SIZE rcvd: 111 On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti wrote: > > > On 27.12.2016 12:07, Maciej Drobniuch wrote: > > Hi Martin! > > Thank you for your time! > > On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti wrote: > >> >> >> On 22.12.2016 10:57, Maciej Drobniuch wrote: >> >> Hi Martin >> >> Appreciate your help! >> >> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti wrote: >> >>> >>> >>> On 22.12.2016 09:37, Maciej Drobniuch wrote: >>> >>> Hi Martin >>> >>> Thank you for reply. >>> >>> 1. The dig is returning proper PTR record. I've added it manually to the >>> zone and it's working. >>> >>> >>> I was asking for SOA and zone name, IMO there is nothing secret about >>> reverse zone name from private address space >>> >>> what returns this command on server? >>> python -c 'import netaddr; from dns import resolver; ip = >>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; >>> print resolver.zone_for_name(revn)' >>> >>> >>> # python -c 'import netaddr; from dns import resolver; ip = >> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; >> print resolver.zone_for_name(revn)' >> 165.0.0.10.in-addr.arpa. >> in-addr.arpa. >> >> >> It looks that python-dns failed to find proper zone, what is supposed to >> be authoritative zone for that record in your system? >> How do your reverse zones look? >> > I have the reverse zone added. > 0.0.10.in-addr.arpa. > > Do you know maybe how python/ipa is determining what's the dns server for > the internal zone? > As far I understood this is not a "access rights issue". It's a DNS PTR > resolution problem with python(ipa's using python) ? > > > It doesn't care about resolver, python-dns is checking SOA records, it > removes labels from left and tries to find best match zone > > what returns dig 0.0.10.in-addr.arpa. SOA ? > > > > >> >> >> >> 2. The problem exists while adding host entries or A records with "create >>> reverse" option. >>> >>> That's why I asked to run dig, the code uses DNS system to determine >>> zone. >>> >>> 3. If I'll bind a host with ipa-client-install the PTR record gets >>> created in the reverse zone and it works >>> >>> Ok >>> >> Manually creating the PTR record works fine as well. >> >>> >>> >>> 4. The resolv.conf file has only the IPA server IP addres/localhost >>> added. >>> >>> >>> Have you changed it recently? >>> >> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local >> reverse zone. >> Now it's pointing to localhost. And I get dig the PTRs. (I've manually >> created the ptr) >> >> # dig -x 10.0.0.165 >> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592 >> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 >> >> ;; OPT PSEUDOSECTION: >> ; E: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;165.0.0.10.in-addr.arpa. IN PTR >> >> ;; ANSWER SECTION: >> 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int. >> >> ;; AUTHORITY SECTION: >> 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int. >> >> >> This authority section looks suspicious, I would expect something like >> 0.0.10.in-addr.arpa. >> >> Back to question about your reverse zones. >> > I've intentionally hid our internal ip space, sorry, good catch my finger > has slipped :). > > > So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig returned > in authority section. > > > >> >> ;; ADDITIONAL SECTION: >> freeipa1.cs.int. 1200 IN A 10.0.0.200 >> >> ;; Query time: 3 msec >> ;; SERVER: 127.0.0.1#53(127.0.0.1) >> ;; WHEN: czw gru 22 04:51:23 EST 2016 >> ;; MSG SIZE rcvd: 124 >> >>> >>> >>> Martin >>> >>> >>> >>> Cheers! >>> M. >>> >>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti wrote: >>> >>>> Hello all :) >>>> >>>> On 20.12.2016 01:33, Maciej Drobniuch wrote: >>>> >>>> Hi All! >>>> >>>> I get the following message while adding a new hostname. >>>> >>>> "The host was added but the DNS update failed with: DNS reverse zone >>>> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" >>>> >>>> >>>> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165 >>>> what will be in SOA answer? >>>> >>>> What is the name of reverse zone you have on IPA DNS server? >>>> >>>> >>>> Martin >>>> >>>> >>>> The reverse zone is configured and working. >>>> When I am manually adding the PTR record to the reverse zone - all OK >>>> >>>> While adding a new host, the A record is being created but the PTR >>>> fails with the message above. >>>> >>>> Reinstalling centos+IPA worked once but I had to reinstall again >>>> because of problems with kerberos(probably dependencies). >>>> >>>> Not sure what is the root cause of the issue. >>>> >>>> VERSION: 4.4.0, API_VERSION: 2.213 >>>> >>>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 >>>> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>> >>>> Any help appreciated! >>>> -- >>>> Best regards >>>> >>>> Maciej Drobniuch >>>> Network Security Engineer >>>> Collective-sense LLC >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> Collective-sense LLC >>> >>> >>> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> 2410 Camino Ramon, Suite 129 >> San Ramon, CA 94583 >> >> >> > Happy new year! > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-Sense,LLC > > > -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Dec 27 12:09:55 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Dec 2016 13:09:55 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> <9e9c9e3c-aa42-3919-15d0-35d9951e4412@redhat.com> Message-ID: On 27.12.2016 13:04, Maciej Drobniuch wrote: > $ dig 0.0.10.in-addr.arpa > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;0.0.10.in-addr.arpa.INA > > ;; AUTHORITY SECTION: > 0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int . > hostmaster.cs.int . 1482653944 3600 900 > 1209600 3600 > > ;; Query time: 197 msec > ;; SERVER: 10.0.0.200#53(10.0.0.200) > ;; WHEN: Tue Dec 27 13:02:24 CET 2016 > ;; MSG SIZE rcvd: 111 > > Hmm, this query doesn't contain ANSWER section, that may be reason why python-dns failed. could you check with: python -c 'from dns import resolver; a = resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print a.rrset.name' > On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti > wrote: > > > > On 27.12.2016 12:07, Maciej Drobniuch wrote: >> Hi Martin! >> >> Thank you for your time! >> >> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti > > wrote: >> >> >> >> On 22.12.2016 10:57, Maciej Drobniuch wrote: >>> Hi Martin >>> >>> Appreciate your help! >>> >>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti >>> > wrote: >>> >>> >>> >>> On 22.12.2016 09:37, Maciej Drobniuch wrote: >>>> Hi Martin >>>> >>>> Thank you for reply. >>>> >>>> 1. The dig is returning proper PTR record. I've added >>>> it manually to the zone and it's working. >>> >>> I was asking for SOA and zone name, IMO there is nothing >>> secret about reverse zone name from private address space >>> >>> what returns this command on server? >>> python -c 'import netaddr; from dns import resolver; ip >>> = netaddr.IPAddress("10.0.0.165"); revn = >>> ip.reverse_dns; print revn; print >>> resolver.zone_for_name(revn)' >>> >>> >>> # python -c 'import netaddr; from dns import resolver; ip = >>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; >>> print revn; print resolver.zone_for_name(revn)' >>> 165.0.0.10.in-addr.arpa. >>> in-addr.arpa. >> >> It looks that python-dns failed to find proper zone, what is >> supposed to be authoritative zone for that record in your system? >> How do your reverse zones look? >> >> I have the reverse zone added. >> 0.0.10.in-addr.arpa. >> >> Do you know maybe how python/ipa is determining what's the dns >> server for the internal zone? >> As far I understood this is not a "access rights issue". It's a >> DNS PTR resolution problem with python(ipa's using python) ? > > It doesn't care about resolver, python-dns is checking SOA > records, it removes labels from left and tries to find best match zone > > what returns dig 0.0.10.in-addr.arpa. SOA ? > > >> >> >> >>> >>>> 2. The problem exists while adding host entries or A >>>> records with "create reverse" option. >>> That's why I asked to run dig, the code uses DNS system >>> to determine zone. >>> >>>> 3. If I'll bind a host with ipa-client-install the PTR >>>> record gets created in the reverse zone and it works >>> Ok >>> >>> Manually creating the PTR record works fine as well. >>> >>> >>> >>>> 4. The resolv.conf file has only the IPA server IP >>>> addres/localhost added. >>> >>> Have you changed it recently? >>> >>> Yes, it pointed to outside 8.8.8.8, so the OS did not see >>> the local reverse zone. >>> Now it's pointing to localhost. And I get dig the PTRs. >>> (I've manually created the ptr) >>> >>> # dig -x 10.0.0.165 >>> >>> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165 >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592 >>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, >>> ADDITIONAL: 2 >>> >>> ;; OPT PSEUDOSECTION: >>> ; E: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;165.0.0.10.in-addr.arpa.INPTR >>> >>> ;; ANSWER SECTION: >>> 165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int >>> . >>> >>> ;; AUTHORITY SECTION: >>> 1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int >>> . >>> >> >> This authority section looks suspicious, I would expect >> something like 0.0.10.in-addr.arpa. >> >> Back to question about your reverse zones. >> >> I've intentionally hid our internal ip space, sorry, good catch >> my finger has slipped :). > > So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig > returned in authority section. > > >> >> >>> ;; ADDITIONAL SECTION: >>> freeipa1.cs.int .1200INA10.0.0.200 >>> >>> ;; Query time: 3 msec >>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >>> ;; WHEN: czw gru 22 04:51:23 EST 2016 >>> ;; MSG SIZE rcvd: 124 >>> >>> >>> >>> Martin >>> >>> >>>> >>>> Cheers! >>>> M. >>>> >>>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti >>>> > wrote: >>>> >>>> Hello all :) >>>> >>>> >>>> On 20.12.2016 01:33, Maciej Drobniuch wrote: >>>>> Hi All! >>>>> >>>>> I get the following message while adding a new >>>>> hostname. >>>>> >>>>> "The host was added but the DNS update failed >>>>> with: DNS reverse zone in-addr.arpa. for IP >>>>> address 10.0.0.165 is not managed by this server" >>>> >>>> IPA failed to get correct reverse zone, can you try >>>> dig -x 10.0.0.165 what will be in SOA answer? >>>> >>>> What is the name of reverse zone you have on IPA >>>> DNS server? >>>> >>>> >>>> Martin >>>> >>>>> >>>>> The reverse zone is configured and working. >>>>> When I am manually adding the PTR record to the >>>>> reverse zone - all OK >>>>> >>>>> While adding a new host, the A record is being >>>>> created but the PTR fails with the message above. >>>>> >>>>> Reinstalling centos+IPA worked once but I had to >>>>> reinstall again because of problems with >>>>> kerberos(probably dependencies). >>>>> >>>>> Not sure what is the root cause of the issue. >>>>> >>>>> VERSION: 4.4.0, API_VERSION: 2.213 >>>>> >>>>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 >>>>> SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 >>>>> x86_64 GNU/Linux >>>>> >>>>> Any help appreciated! >>>>> -- >>>>> Best regards >>>>> >>>>> Maciej Drobniuch >>>>> Network Security Engineer >>>>> Collective-sense LLC >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards >>>> >>>> Maciej Drobniuch >>>> Network Security Engineer >>>> Collective-sense LLC >>> >>> >>> >>> >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> 2410 Camino Ramon, Suite 129 >>> San Ramon, CA 94583 >> >> >> Happy new year! >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-Sense,LLC > > > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at collective-sense.com Tue Dec 27 12:21:54 2016 From: md at collective-sense.com (Maciej Drobniuch) Date: Tue, 27 Dec 2016 13:21:54 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> <9e9c9e3c-aa42-3919-15d0-35d9951e4412@redhat.com> Message-ID: # python -c 'from dns import resolver; a = resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print a.rrset.name' 0.0.10.in-addr.arpa. On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti wrote: > > > On 27.12.2016 13:04, Maciej Drobniuch wrote: > > $ dig 0.0.10.in-addr.arpa > > ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;0.0.10.in-addr.arpa. IN A > > ;; AUTHORITY SECTION: > 0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int. > 1482653944 3600 900 1209600 3600 > > ;; Query time: 197 msec > ;; SERVER: 10.0.0.200#53(10.0.0.200) > ;; WHEN: Tue Dec 27 13:02:24 CET 2016 > ;; MSG SIZE rcvd: 111 > > > Hmm, this query doesn't contain ANSWER section, that may be reason why > python-dns failed. > > could you check with: > > python -c 'from dns import resolver; a = resolver.query("0.0.10.in-addr.arpa.", > "SOA", "IN"); print a.rrset.name' > > > > On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti wrote: > >> >> >> On 27.12.2016 12:07, Maciej Drobniuch wrote: >> >> Hi Martin! >> >> Thank you for your time! >> >> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti wrote: >> >>> >>> >>> On 22.12.2016 10:57, Maciej Drobniuch wrote: >>> >>> Hi Martin >>> >>> Appreciate your help! >>> >>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti >>> wrote: >>> >>>> >>>> >>>> On 22.12.2016 09:37, Maciej Drobniuch wrote: >>>> >>>> Hi Martin >>>> >>>> Thank you for reply. >>>> >>>> 1. The dig is returning proper PTR record. I've added it manually to >>>> the zone and it's working. >>>> >>>> >>>> I was asking for SOA and zone name, IMO there is nothing secret about >>>> reverse zone name from private address space >>>> >>>> what returns this command on server? >>>> python -c 'import netaddr; from dns import resolver; ip = >>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; >>>> print resolver.zone_for_name(revn)' >>>> >>>> >>>> # python -c 'import netaddr; from dns import resolver; ip = >>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; >>> print resolver.zone_for_name(revn)' >>> 165.0.0.10.in-addr.arpa. >>> in-addr.arpa. >>> >>> >>> It looks that python-dns failed to find proper zone, what is supposed to >>> be authoritative zone for that record in your system? >>> How do your reverse zones look? >>> >> I have the reverse zone added. >> 0.0.10.in-addr.arpa. >> >> Do you know maybe how python/ipa is determining what's the dns server for >> the internal zone? >> As far I understood this is not a "access rights issue". It's a DNS PTR >> resolution problem with python(ipa's using python) ? >> >> >> It doesn't care about resolver, python-dns is checking SOA records, it >> removes labels from left and tries to find best match zone >> >> what returns dig 0.0.10.in-addr.arpa. SOA ? >> >> >> >> >>> >>> >>> >>> 2. The problem exists while adding host entries or A records with >>>> "create reverse" option. >>>> >>>> That's why I asked to run dig, the code uses DNS system to determine >>>> zone. >>>> >>>> 3. If I'll bind a host with ipa-client-install the PTR record gets >>>> created in the reverse zone and it works >>>> >>>> Ok >>>> >>> Manually creating the PTR record works fine as well. >>> >>>> >>>> >>>> 4. The resolv.conf file has only the IPA server IP addres/localhost >>>> added. >>>> >>>> >>>> Have you changed it recently? >>>> >>> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local >>> reverse zone. >>> Now it's pointing to localhost. And I get dig the PTRs. (I've manually >>> created the ptr) >>> >>> # dig -x 10.0.0.165 >>> >>> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165 >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592 >>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 >>> >>> ;; OPT PSEUDOSECTION: >>> ; E: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;165.0.0.10.in-addr.arpa. IN PTR >>> >>> ;; ANSWER SECTION: >>> 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int. >>> >>> ;; AUTHORITY SECTION: >>> 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int. >>> >>> >>> This authority section looks suspicious, I would expect something like >>> 0.0.10.in-addr.arpa. >>> >>> Back to question about your reverse zones. >>> >> I've intentionally hid our internal ip space, sorry, good catch my finger >> has slipped :). >> >> >> So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig >> returned in authority section. >> >> >> >>> >>> ;; ADDITIONAL SECTION: >>> freeipa1.cs.int. 1200 IN A 10.0.0.200 >>> >>> ;; Query time: 3 msec >>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >>> ;; WHEN: czw gru 22 04:51:23 EST 2016 >>> ;; MSG SIZE rcvd: 124 >>> >>>> >>>> >>>> Martin >>>> >>>> >>>> >>>> Cheers! >>>> M. >>>> >>>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti >>>> wrote: >>>> >>>>> Hello all :) >>>>> >>>>> On 20.12.2016 01:33, Maciej Drobniuch wrote: >>>>> >>>>> Hi All! >>>>> >>>>> I get the following message while adding a new hostname. >>>>> >>>>> "The host was added but the DNS update failed with: DNS reverse zone >>>>> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" >>>>> >>>>> >>>>> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165 >>>>> what will be in SOA answer? >>>>> >>>>> What is the name of reverse zone you have on IPA DNS server? >>>>> >>>>> >>>>> Martin >>>>> >>>>> >>>>> The reverse zone is configured and working. >>>>> When I am manually adding the PTR record to the reverse zone - all OK >>>>> >>>>> While adding a new host, the A record is being created but the PTR >>>>> fails with the message above. >>>>> >>>>> Reinstalling centos+IPA worked once but I had to reinstall again >>>>> because of problems with kerberos(probably dependencies). >>>>> >>>>> Not sure what is the root cause of the issue. >>>>> >>>>> VERSION: 4.4.0, API_VERSION: 2.213 >>>>> >>>>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 >>>>> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>> >>>>> Any help appreciated! >>>>> -- >>>>> Best regards >>>>> >>>>> Maciej Drobniuch >>>>> Network Security Engineer >>>>> Collective-sense LLC >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards >>>> >>>> Maciej Drobniuch >>>> Network Security Engineer >>>> Collective-sense LLC >>>> >>>> >>>> >>> >>> >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> 2410 Camino Ramon, Suite 129 >>> San Ramon, CA 94583 >>> >>> >>> >> Happy new year! >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-Sense,LLC >> >> >> > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-Sense,LLC > > > -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From outbackdingo at gmail.com Tue Dec 27 12:21:17 2016 From: outbackdingo at gmail.com (Outback Dingo) Date: Tue, 27 Dec 2016 07:21:17 -0500 Subject: [Freeipa-users] IPA Servers out of sync - DNS records In-Reply-To: <67928c0b-9c50-0f6b-e7c0-6476446fc771@redhat.com> References: <4b91efa8-7c41-b093-0978-be14414817c8@redhat.com> <67928c0b-9c50-0f6b-e7c0-6476446fc771@redhat.com> Message-ID: > According to log, it looks that replication has been restored a week ago > > can you use https://github.com/peterpakos/ipa_check_consistency to check > what else is missing? > > If it finds missing entries, probably re-initialization will be needed > > Martin really odd... i just did a yum update -y during our conversation on both servers, now ipa2 is synced again... From outbackdingo at gmail.com Tue Dec 27 12:22:18 2016 From: outbackdingo at gmail.com (Outback Dingo) Date: Tue, 27 Dec 2016 07:22:18 -0500 Subject: [Freeipa-users] List SPAM Message-ID: Im still getting nude porn spam emails and pics from a user Kimi Rachel From mbasti at redhat.com Tue Dec 27 12:28:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Dec 2016 13:28:07 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> <9e9c9e3c-aa42-3919-15d0-35d9951e4412@redhat.com> Message-ID: <8cd4ff33-7fc1-b786-ae63-a7b1a02f039b@redhat.com> I just noticed previously you sent wrong dig, I need dig 0.0.10.in-addr.arpa. SOA instead of the A rtype On 27.12.2016 13:21, Maciej Drobniuch wrote: > # python -c 'from dns import resolver; a = > resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print > a.rrset.name ' > 0.0.10.in-addr.arpa. > > On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti > wrote: > > > > On 27.12.2016 13:04, Maciej Drobniuch wrote: >> $ dig 0.0.10.in-addr.arpa >> >> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232 >> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, >> ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;0.0.10.in-addr.arpa.INA >> >> ;; AUTHORITY SECTION: >> 0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int >> . hostmaster.cs.int >> . 1482653944 3600 900 1209600 3600 >> >> ;; Query time: 197 msec >> ;; SERVER: 10.0.0.200#53(10.0.0.200) >> ;; WHEN: Tue Dec 27 13:02:24 CET 2016 >> ;; MSG SIZE rcvd: 111 >> >> > Hmm, this query doesn't contain ANSWER section, that may be reason > why python-dns failed. > > could you check with: > > python -c 'from dns import resolver; a = > resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print > a.rrset.name ' > > > >> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti > > wrote: >> >> >> >> On 27.12.2016 12:07, Maciej Drobniuch wrote: >>> Hi Martin! >>> >>> Thank you for your time! >>> >>> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti >>> > wrote: >>> >>> >>> >>> On 22.12.2016 10:57, Maciej Drobniuch wrote: >>>> Hi Martin >>>> >>>> Appreciate your help! >>>> >>>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti >>>> > wrote: >>>> >>>> >>>> >>>> On 22.12.2016 09:37, Maciej Drobniuch wrote: >>>>> Hi Martin >>>>> >>>>> Thank you for reply. >>>>> >>>>> 1. The dig is returning proper PTR record. I've >>>>> added it manually to the zone and it's working. >>>> >>>> I was asking for SOA and zone name, IMO there is >>>> nothing secret about reverse zone name from private >>>> address space >>>> >>>> what returns this command on server? >>>> python -c 'import netaddr; from dns import >>>> resolver; ip = netaddr.IPAddress("10.0.0.165"); >>>> revn = ip.reverse_dns; print revn; print >>>> resolver.zone_for_name(revn)' >>>> >>>> >>>> # python -c 'import netaddr; from dns import resolver; >>>> ip = netaddr.IPAddress("10.0.0.165"); revn = >>>> ip.reverse_dns; print revn; print >>>> resolver.zone_for_name(revn)' >>>> 165.0.0.10.in-addr.arpa. >>>> in-addr.arpa. >>> >>> It looks that python-dns failed to find proper zone, >>> what is supposed to be authoritative zone for that >>> record in your system? >>> How do your reverse zones look? >>> >>> I have the reverse zone added. >>> 0.0.10.in-addr.arpa. >>> >>> Do you know maybe how python/ipa is determining what's the >>> dns server for the internal zone? >>> As far I understood this is not a "access rights issue". >>> It's a DNS PTR resolution problem with python(ipa's using >>> python) ? >> >> It doesn't care about resolver, python-dns is checking SOA >> records, it removes labels from left and tries to find best >> match zone >> >> what returns dig 0.0.10.in-addr.arpa. SOA ? >> >> >>> >>> >>> >>>> >>>>> 2. The problem exists while adding host entries or >>>>> A records with "create reverse" option. >>>> That's why I asked to run dig, the code uses DNS >>>> system to determine zone. >>>> >>>>> 3. If I'll bind a host with ipa-client-install the >>>>> PTR record gets created in the reverse zone and it >>>>> works >>>> Ok >>>> >>>> Manually creating the PTR record works fine as well. >>>> >>>> >>>> >>>>> 4. The resolv.conf file has only the IPA server IP >>>>> addres/localhost added. >>>> >>>> Have you changed it recently? >>>> >>>> Yes, it pointed to outside 8.8.8.8, so the OS did not >>>> see the local reverse zone. >>>> Now it's pointing to localhost. And I get dig the PTRs. >>>> (I've manually created the ptr) >>>> >>>> # dig -x 10.0.0.165 >>>> >>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165 >>>> ;; global options: +cmd >>>> ;; Got answer: >>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592 >>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: >>>> 1, ADDITIONAL: 2 >>>> >>>> ;; OPT PSEUDOSECTION: >>>> ; E: version: 0, flags:; udp: 4096 >>>> ;; QUESTION SECTION: >>>> ;165.0.0.10.in-addr.arpa.INPTR >>>> >>>> ;; ANSWER SECTION: >>>> 165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int >>>> . >>>> >>>> ;; AUTHORITY SECTION: >>>> 1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int >>>> . >>>> >>> >>> This authority section looks suspicious, I would expect >>> something like 0.0.10.in-addr.arpa. >>> >>> Back to question about your reverse zones. >>> >>> I've intentionally hid our internal ip space, sorry, good >>> catch my finger has slipped :). >> >> So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what >> dig returned in authority section. >> >> >>> >>> >>>> ;; ADDITIONAL SECTION: >>>> freeipa1.cs.int .1200INA10.0.0.200 >>>> >>>> ;; Query time: 3 msec >>>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >>>> ;; WHEN: czw gru 22 04:51:23 EST 2016 >>>> ;; MSG SIZE rcvd: 124 >>>> >>>> >>>> >>>> Martin >>>> >>>> >>>>> >>>>> Cheers! >>>>> M. >>>>> >>>>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti >>>>> > wrote: >>>>> >>>>> Hello all :) >>>>> >>>>> >>>>> On 20.12.2016 01:33, Maciej Drobniuch wrote: >>>>>> Hi All! >>>>>> >>>>>> I get the following message while adding a >>>>>> new hostname. >>>>>> >>>>>> "The host was added but the DNS update failed >>>>>> with: DNS reverse zone in-addr.arpa. for IP >>>>>> address 10.0.0.165 is not managed by this server" >>>>> >>>>> IPA failed to get correct reverse zone, can >>>>> you try dig -x 10.0.0.165 what will be in SOA >>>>> answer? >>>>> >>>>> What is the name of reverse zone you have on >>>>> IPA DNS server? >>>>> >>>>> >>>>> Martin >>>>> >>>>>> >>>>>> The reverse zone is configured and working. >>>>>> When I am manually adding the PTR record to >>>>>> the reverse zone - all OK >>>>>> >>>>>> While adding a new host, the A record is >>>>>> being created but the PTR fails with the >>>>>> message above. >>>>>> >>>>>> Reinstalling centos+IPA worked once but I had >>>>>> to reinstall again because of problems with >>>>>> kerberos(probably dependencies). >>>>>> >>>>>> Not sure what is the root cause of the issue. >>>>>> >>>>>> VERSION: 4.4.0, API_VERSION: 2.213 >>>>>> >>>>>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 >>>>>> #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 >>>>>> x86_64 x86_64 GNU/Linux >>>>>> >>>>>> Any help appreciated! >>>>>> -- >>>>>> Best regards >>>>>> >>>>>> Maciej Drobniuch >>>>>> Network Security Engineer >>>>>> Collective-sense LLC >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards >>>>> >>>>> Maciej Drobniuch >>>>> Network Security Engineer >>>>> Collective-sense LLC >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards >>>> >>>> Maciej Drobniuch >>>> Network Security Engineer >>>> 2410 Camino Ramon, Suite 129 >>>> San Ramon, CA 94583 >>> >>> >>> Happy new year! >>> >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> Collective-Sense,LLC >> >> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-Sense,LLC > > > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Dec 27 12:32:42 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Dec 2016 13:32:42 +0100 Subject: [Freeipa-users] List SPAM In-Reply-To: References: Message-ID: <5beedf04-1769-9abf-62d0-14401f6bbb7c@redhat.com> On 27.12.2016 13:22, Outback Dingo wrote: > Im still getting nude porn spam emails and pics from a user > > Kimi Rachel > It is not a user, it is a SPAM bot mining public archives. We don't have any control about it we can just un-publish archives (tested, spam stopped after that) but they contain a lot of information for users. JFTR the email is changing. From md at collective-sense.com Tue Dec 27 12:35:38 2016 From: md at collective-sense.com (Maciej Drobniuch) Date: Tue, 27 Dec 2016 13:35:38 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: <8cd4ff33-7fc1-b786-ae63-a7b1a02f039b@redhat.com> References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> <9e9c9e3c-aa42-3919-15d0-35d9951e4412@redhat.com> <8cd4ff33-7fc1-b786-ae63-a7b1a02f039b@redhat.com> Message-ID: # dig soa 0.0.10.in-addr.arpa. ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;0.0.10.in-addr.arpa. IN SOA ;; ANSWER SECTION: 0.0.10.in-addr.arpa. 86400 IN SOA freeipa1.cs.int. hostmaster.cs.int. 1482653944 3600 900 1209600 3600 ;; AUTHORITY SECTION: 0.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int. 0.0.10.in-addr.arpa. 86400 IN NS freeipa2.cs.int. 0.0.10.in-addr.arpa. 86400 IN NS krkfreeipa.cs.int. ;; ADDITIONAL SECTION: freeipa1.cs.int. 1200 IN A 10.0.0.200 freeipa2.cs.int. 1200 IN A 10.0.1.200 krkfreeipa.cs.int. 1200 IN A 10.0.2.6 ;; Query time: 15 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: wto gru 27 07:33:41 EST 2016 ;; MSG SIZE rcvd: 333 On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti wrote: > I just noticed previously you sent wrong dig, I need > > dig 0.0.10.in-addr.arpa. SOA instead of the A rtype > > > > > On 27.12.2016 13:21, Maciej Drobniuch wrote: > > # python -c 'from dns import resolver; a = resolver.query("0.0.10.in-addr.arpa.", > "SOA", "IN"); print a.rrset.name' > 0.0.10.in-addr.arpa. > > On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti wrote: > >> >> >> On 27.12.2016 13:04, Maciej Drobniuch wrote: >> >> $ dig 0.0.10.in-addr.arpa >> >> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232 >> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;0.0.10.in-addr.arpa. IN A >> >> ;; AUTHORITY SECTION: >> 0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int. >> 1482653944 3600 900 1209600 3600 >> >> ;; Query time: 197 msec >> ;; SERVER: 10.0.0.200#53(10.0.0.200) >> ;; WHEN: Tue Dec 27 13:02:24 CET 2016 >> ;; MSG SIZE rcvd: 111 >> >> >> Hmm, this query doesn't contain ANSWER section, that may be reason why >> python-dns failed. >> >> could you check with: >> >> python -c 'from dns import resolver; a = resolver.query("0.0.10.in-addr.arpa.", >> "SOA", "IN"); print a.rrset.name' >> >> >> >> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti wrote: >> >>> >>> >>> On 27.12.2016 12:07, Maciej Drobniuch wrote: >>> >>> Hi Martin! >>> >>> Thank you for your time! >>> >>> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti wrote: >>> >>>> >>>> >>>> On 22.12.2016 10:57, Maciej Drobniuch wrote: >>>> >>>> Hi Martin >>>> >>>> Appreciate your help! >>>> >>>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti >>>> wrote: >>>> >>>>> >>>>> >>>>> On 22.12.2016 09:37, Maciej Drobniuch wrote: >>>>> >>>>> Hi Martin >>>>> >>>>> Thank you for reply. >>>>> >>>>> 1. The dig is returning proper PTR record. I've added it manually to >>>>> the zone and it's working. >>>>> >>>>> >>>>> I was asking for SOA and zone name, IMO there is nothing secret about >>>>> reverse zone name from private address space >>>>> >>>>> what returns this command on server? >>>>> python -c 'import netaddr; from dns import resolver; ip = >>>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; >>>>> print resolver.zone_for_name(revn)' >>>>> >>>>> >>>>> # python -c 'import netaddr; from dns import resolver; ip = >>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; >>>> print resolver.zone_for_name(revn)' >>>> 165.0.0.10.in-addr.arpa. >>>> in-addr.arpa. >>>> >>>> >>>> It looks that python-dns failed to find proper zone, what is supposed >>>> to be authoritative zone for that record in your system? >>>> How do your reverse zones look? >>>> >>> I have the reverse zone added. >>> 0.0.10.in-addr.arpa. >>> >>> Do you know maybe how python/ipa is determining what's the dns server >>> for the internal zone? >>> As far I understood this is not a "access rights issue". It's a DNS PTR >>> resolution problem with python(ipa's using python) ? >>> >>> >>> It doesn't care about resolver, python-dns is checking SOA records, it >>> removes labels from left and tries to find best match zone >>> >>> what returns dig 0.0.10.in-addr.arpa. SOA ? >>> >>> >>> >>> >>>> >>>> >>>> >>>> 2. The problem exists while adding host entries or A records with >>>>> "create reverse" option. >>>>> >>>>> That's why I asked to run dig, the code uses DNS system to determine >>>>> zone. >>>>> >>>>> 3. If I'll bind a host with ipa-client-install the PTR record gets >>>>> created in the reverse zone and it works >>>>> >>>>> Ok >>>>> >>>> Manually creating the PTR record works fine as well. >>>> >>>>> >>>>> >>>>> 4. The resolv.conf file has only the IPA server IP addres/localhost >>>>> added. >>>>> >>>>> >>>>> Have you changed it recently? >>>>> >>>> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local >>>> reverse zone. >>>> Now it's pointing to localhost. And I get dig the PTRs. (I've manually >>>> created the ptr) >>>> >>>> # dig -x 10.0.0.165 >>>> >>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165 >>>> ;; global options: +cmd >>>> ;; Got answer: >>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592 >>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 >>>> >>>> ;; OPT PSEUDOSECTION: >>>> ; E: version: 0, flags:; udp: 4096 >>>> ;; QUESTION SECTION: >>>> ;165.0.0.10.in-addr.arpa. IN PTR >>>> >>>> ;; ANSWER SECTION: >>>> 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int. >>>> >>>> ;; AUTHORITY SECTION: >>>> 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int. >>>> >>>> >>>> This authority section looks suspicious, I would expect something like >>>> 0.0.10.in-addr.arpa. >>>> >>>> Back to question about your reverse zones. >>>> >>> I've intentionally hid our internal ip space, sorry, good catch my >>> finger has slipped :). >>> >>> >>> So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig >>> returned in authority section. >>> >>> >>> >>>> >>>> ;; ADDITIONAL SECTION: >>>> freeipa1.cs.int. 1200 IN A 10.0.0.200 >>>> >>>> ;; Query time: 3 msec >>>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >>>> ;; WHEN: czw gru 22 04:51:23 EST 2016 >>>> ;; MSG SIZE rcvd: 124 >>>> >>>>> >>>>> >>>>> Martin >>>>> >>>>> >>>>> >>>>> Cheers! >>>>> M. >>>>> >>>>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti >>>>> wrote: >>>>> >>>>>> Hello all :) >>>>>> >>>>>> On 20.12.2016 01:33, Maciej Drobniuch wrote: >>>>>> >>>>>> Hi All! >>>>>> >>>>>> I get the following message while adding a new hostname. >>>>>> >>>>>> "The host was added but the DNS update failed with: DNS reverse zone >>>>>> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" >>>>>> >>>>>> >>>>>> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165 >>>>>> what will be in SOA answer? >>>>>> >>>>>> What is the name of reverse zone you have on IPA DNS server? >>>>>> >>>>>> >>>>>> Martin >>>>>> >>>>>> >>>>>> The reverse zone is configured and working. >>>>>> When I am manually adding the PTR record to the reverse zone - all OK >>>>>> >>>>>> While adding a new host, the A record is being created but the PTR >>>>>> fails with the message above. >>>>>> >>>>>> Reinstalling centos+IPA worked once but I had to reinstall again >>>>>> because of problems with kerberos(probably dependencies). >>>>>> >>>>>> Not sure what is the root cause of the issue. >>>>>> >>>>>> VERSION: 4.4.0, API_VERSION: 2.213 >>>>>> >>>>>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 >>>>>> 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>> >>>>>> Any help appreciated! >>>>>> -- >>>>>> Best regards >>>>>> >>>>>> Maciej Drobniuch >>>>>> Network Security Engineer >>>>>> Collective-sense LLC >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards >>>>> >>>>> Maciej Drobniuch >>>>> Network Security Engineer >>>>> Collective-sense LLC >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards >>>> >>>> Maciej Drobniuch >>>> Network Security Engineer >>>> 2410 Camino Ramon, Suite 129 >>>> San Ramon, CA 94583 >>>> >>>> >>>> >>> Happy new year! >>> >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> Collective-Sense,LLC >>> >>> >>> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-Sense,LLC >> >> >> > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-Sense,LLC > > > -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at collective-sense.com Tue Dec 27 12:41:59 2016 From: md at collective-sense.com (Maciej Drobniuch) Date: Tue, 27 Dec 2016 13:41:59 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> <9e9c9e3c-aa42-3919-15d0-35d9951e4412@redhat.com> <8cd4ff33-7fc1-b786-ae63-a7b1a02f039b@redhat.com> Message-ID: Martin, Your troubleshooting style put me on the right track. The alternative DNS servers had Ipv6 AAAA records that did not resolv properly. After deleting those records adding A records (with reverse PTR check) and adding host works fine. The PTR record is created in the GUI and works fine. Thank you very much for your time and help with this! Cheers! M. On Tue, Dec 27, 2016 at 1:35 PM, Maciej Drobniuch wrote: > # dig soa 0.0.10.in-addr.arpa. > > ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;0.0.10.in-addr.arpa. IN SOA > > ;; ANSWER SECTION: > 0.0.10.in-addr.arpa. 86400 IN SOA freeipa1.cs.int. hostmaster.cs.int. > 1482653944 3600 900 1209600 3600 > > ;; AUTHORITY SECTION: > 0.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int. > 0.0.10.in-addr.arpa. 86400 IN NS freeipa2.cs.int. > 0.0.10.in-addr.arpa. 86400 IN NS krkfreeipa.cs.int. > > ;; ADDITIONAL SECTION: > freeipa1.cs.int. 1200 IN A 10.0.0.200 > freeipa2.cs.int. 1200 IN A 10.0.1.200 > krkfreeipa.cs.int. 1200 IN A 10.0.2.6 > > ;; Query time: 15 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: wto gru 27 07:33:41 EST 2016 > ;; MSG SIZE rcvd: 333 > > > On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti wrote: > >> I just noticed previously you sent wrong dig, I need >> >> dig 0.0.10.in-addr.arpa. SOA instead of the A rtype >> >> >> >> >> On 27.12.2016 13:21, Maciej Drobniuch wrote: >> >> # python -c 'from dns import resolver; a = resolver.query("0.0.10.in-addr.arpa.", >> "SOA", "IN"); print a.rrset.name' >> 0.0.10.in-addr.arpa. >> >> On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti wrote: >> >>> >>> >>> On 27.12.2016 13:04, Maciej Drobniuch wrote: >>> >>> $ dig 0.0.10.in-addr.arpa >>> >>> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232 >>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;0.0.10.in-addr.arpa. IN A >>> >>> ;; AUTHORITY SECTION: >>> 0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int. >>> 1482653944 3600 900 1209600 3600 >>> >>> ;; Query time: 197 msec >>> ;; SERVER: 10.0.0.200#53(10.0.0.200) >>> ;; WHEN: Tue Dec 27 13:02:24 CET 2016 >>> ;; MSG SIZE rcvd: 111 >>> >>> >>> Hmm, this query doesn't contain ANSWER section, that may be reason why >>> python-dns failed. >>> >>> could you check with: >>> >>> python -c 'from dns import resolver; a = resolver.query("0.0.10.in-addr.arpa.", >>> "SOA", "IN"); print a.rrset.name' >>> >>> >>> >>> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti >>> wrote: >>> >>>> >>>> >>>> On 27.12.2016 12:07, Maciej Drobniuch wrote: >>>> >>>> Hi Martin! >>>> >>>> Thank you for your time! >>>> >>>> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti >>>> wrote: >>>> >>>>> >>>>> >>>>> On 22.12.2016 10:57, Maciej Drobniuch wrote: >>>>> >>>>> Hi Martin >>>>> >>>>> Appreciate your help! >>>>> >>>>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 22.12.2016 09:37, Maciej Drobniuch wrote: >>>>>> >>>>>> Hi Martin >>>>>> >>>>>> Thank you for reply. >>>>>> >>>>>> 1. The dig is returning proper PTR record. I've added it manually to >>>>>> the zone and it's working. >>>>>> >>>>>> >>>>>> I was asking for SOA and zone name, IMO there is nothing secret about >>>>>> reverse zone name from private address space >>>>>> >>>>>> what returns this command on server? >>>>>> python -c 'import netaddr; from dns import resolver; ip = >>>>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; >>>>>> print resolver.zone_for_name(revn)' >>>>>> >>>>>> >>>>>> # python -c 'import netaddr; from dns import resolver; ip = >>>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; >>>>> print resolver.zone_for_name(revn)' >>>>> 165.0.0.10.in-addr.arpa. >>>>> in-addr.arpa. >>>>> >>>>> >>>>> It looks that python-dns failed to find proper zone, what is supposed >>>>> to be authoritative zone for that record in your system? >>>>> How do your reverse zones look? >>>>> >>>> I have the reverse zone added. >>>> 0.0.10.in-addr.arpa. >>>> >>>> Do you know maybe how python/ipa is determining what's the dns server >>>> for the internal zone? >>>> As far I understood this is not a "access rights issue". It's a DNS PTR >>>> resolution problem with python(ipa's using python) ? >>>> >>>> >>>> It doesn't care about resolver, python-dns is checking SOA records, it >>>> removes labels from left and tries to find best match zone >>>> >>>> what returns dig 0.0.10.in-addr.arpa. SOA ? >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> 2. The problem exists while adding host entries or A records with >>>>>> "create reverse" option. >>>>>> >>>>>> That's why I asked to run dig, the code uses DNS system to determine >>>>>> zone. >>>>>> >>>>>> 3. If I'll bind a host with ipa-client-install the PTR record gets >>>>>> created in the reverse zone and it works >>>>>> >>>>>> Ok >>>>>> >>>>> Manually creating the PTR record works fine as well. >>>>> >>>>>> >>>>>> >>>>>> 4. The resolv.conf file has only the IPA server IP addres/localhost >>>>>> added. >>>>>> >>>>>> >>>>>> Have you changed it recently? >>>>>> >>>>> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local >>>>> reverse zone. >>>>> Now it's pointing to localhost. And I get dig the PTRs. (I've manually >>>>> created the ptr) >>>>> >>>>> # dig -x 10.0.0.165 >>>>> >>>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165 >>>>> ;; global options: +cmd >>>>> ;; Got answer: >>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592 >>>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 >>>>> >>>>> ;; OPT PSEUDOSECTION: >>>>> ; E: version: 0, flags:; udp: 4096 >>>>> ;; QUESTION SECTION: >>>>> ;165.0.0.10.in-addr.arpa. IN PTR >>>>> >>>>> ;; ANSWER SECTION: >>>>> 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int. >>>>> >>>>> ;; AUTHORITY SECTION: >>>>> 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int. >>>>> >>>>> >>>>> This authority section looks suspicious, I would expect something like >>>>> 0.0.10.in-addr.arpa. >>>>> >>>>> Back to question about your reverse zones. >>>>> >>>> I've intentionally hid our internal ip space, sorry, good catch my >>>> finger has slipped :). >>>> >>>> >>>> So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig >>>> returned in authority section. >>>> >>>> >>>> >>>>> >>>>> ;; ADDITIONAL SECTION: >>>>> freeipa1.cs.int. 1200 IN A 10.0.0.200 >>>>> >>>>> ;; Query time: 3 msec >>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >>>>> ;; WHEN: czw gru 22 04:51:23 EST 2016 >>>>> ;; MSG SIZE rcvd: 124 >>>>> >>>>>> >>>>>> >>>>>> Martin >>>>>> >>>>>> >>>>>> >>>>>> Cheers! >>>>>> M. >>>>>> >>>>>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti >>>>>> wrote: >>>>>> >>>>>>> Hello all :) >>>>>>> >>>>>>> On 20.12.2016 01:33, Maciej Drobniuch wrote: >>>>>>> >>>>>>> Hi All! >>>>>>> >>>>>>> I get the following message while adding a new hostname. >>>>>>> >>>>>>> "The host was added but the DNS update failed with: DNS reverse zone >>>>>>> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server" >>>>>>> >>>>>>> >>>>>>> IPA failed to get correct reverse zone, can you try dig -x >>>>>>> 10.0.0.165 what will be in SOA answer? >>>>>>> >>>>>>> What is the name of reverse zone you have on IPA DNS server? >>>>>>> >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> >>>>>>> The reverse zone is configured and working. >>>>>>> When I am manually adding the PTR record to the reverse zone - all OK >>>>>>> >>>>>>> While adding a new host, the A record is being created but the PTR >>>>>>> fails with the message above. >>>>>>> >>>>>>> Reinstalling centos+IPA worked once but I had to reinstall again >>>>>>> because of problems with kerberos(probably dependencies). >>>>>>> >>>>>>> Not sure what is the root cause of the issue. >>>>>>> >>>>>>> VERSION: 4.4.0, API_VERSION: 2.213 >>>>>>> >>>>>>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 >>>>>>> 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>>> >>>>>>> Any help appreciated! >>>>>>> -- >>>>>>> Best regards >>>>>>> >>>>>>> Maciej Drobniuch >>>>>>> Network Security Engineer >>>>>>> Collective-sense LLC >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards >>>>>> >>>>>> Maciej Drobniuch >>>>>> Network Security Engineer >>>>>> Collective-sense LLC >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards >>>>> >>>>> Maciej Drobniuch >>>>> Network Security Engineer >>>>> 2410 Camino Ramon, Suite 129 >>>>> San Ramon, CA 94583 >>>>> >>>>> >>>>> >>>> Happy new year! >>>> >>>> -- >>>> Best regards >>>> >>>> Maciej Drobniuch >>>> Network Security Engineer >>>> Collective-Sense,LLC >>>> >>>> >>>> >>> >>> >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> Collective-Sense,LLC >>> >>> >>> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-Sense,LLC >> >> >> > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-Sense,LLC > -- Best regards Maciej Drobniuch Network Security Engineer Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Tue Dec 27 16:15:14 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 27 Dec 2016 17:15:14 +0100 Subject: [Freeipa-users] DNS reverse zone is not managed by this server In-Reply-To: References: <726cce75-7cd4-97d5-6c96-ddafdfff4835@redhat.com> <9e9c9e3c-aa42-3919-15d0-35d9951e4412@redhat.com> <8cd4ff33-7fc1-b786-ae63-a7b1a02f039b@redhat.com> Message-ID: Great, you are welcome :) On 27.12.2016 13:41, Maciej Drobniuch wrote: > Martin, > > Your troubleshooting style put me on the right track. > > The alternative DNS servers had Ipv6 AAAA records that did not resolv > properly. > > After deleting those records adding A records (with reverse PTR check) > and adding host works fine. The PTR record is created in the GUI and > works fine. > > Thank you very much for your time and help with this! > > Cheers! > M. > > On Tue, Dec 27, 2016 at 1:35 PM, Maciej Drobniuch > > wrote: > > # dig soa 0.0.10.in-addr.arpa. > > ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, > ADDITIONAL: 8 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;0.0.10.in-addr.arpa.INSOA > > ;; ANSWER SECTION: > 0.0.10.in-addr.arpa.86400INSOAfreeipa1.cs.int > . hostmaster.cs.int > . 1482653944 3600 900 1209600 3600 > > ;; AUTHORITY SECTION: > 0.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int . > 0.0.10.in-addr.arpa.86400INNSfreeipa2.cs.int . > 0.0.10.in-addr.arpa.86400INNSkrkfreeipa.cs.int > . > > ;; ADDITIONAL SECTION: > freeipa1.cs.int .1200INA10.0.0.200 > freeipa2.cs.int .1200INA10.0.1.200 > krkfreeipa.cs.int .1200INA10.0.2.6 > > ;; Query time: 15 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: wto gru 27 07:33:41 EST 2016 > ;; MSG SIZE rcvd: 333 > > > On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti > wrote: > > I just noticed previously you sent wrong dig, I need > > dig 0.0.10.in-addr.arpa. SOA instead of the A rtype > > > > > On 27.12.2016 13:21, Maciej Drobniuch wrote: >> # python -c 'from dns import resolver; a = >> resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print >> a.rrset.name ' >> 0.0.10.in-addr.arpa. >> >> On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti >> > wrote: >> >> >> >> On 27.12.2016 13:04, Maciej Drobniuch wrote: >>> $ dig 0.0.10.in-addr.arpa >>> >>> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232 >>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: >>> 1, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;0.0.10.in-addr.arpa.INA >>> >>> ;; AUTHORITY SECTION: >>> 0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int >>> . hostmaster.cs.int >>> . 1482653944 3600 900 1209600 3600 >>> >>> ;; Query time: 197 msec >>> ;; SERVER: 10.0.0.200#53(10.0.0.200) >>> ;; WHEN: Tue Dec 27 13:02:24 CET 2016 >>> ;; MSG SIZE rcvd: 111 >>> >>> >> Hmm, this query doesn't contain ANSWER section, that may >> be reason why python-dns failed. >> >> could you check with: >> >> python -c 'from dns import resolver; a = >> resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); >> print a.rrset.name ' >> >> >> >>> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti >>> > wrote: >>> >>> >>> >>> On 27.12.2016 12:07, Maciej Drobniuch wrote: >>>> Hi Martin! >>>> >>>> Thank you for your time! >>>> >>>> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti >>>> > wrote: >>>> >>>> >>>> >>>> On 22.12.2016 10:57, Maciej Drobniuch wrote: >>>>> Hi Martin >>>>> >>>>> Appreciate your help! >>>>> >>>>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti >>>>> > >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On 22.12.2016 09:37, Maciej Drobniuch wrote: >>>>>> Hi Martin >>>>>> >>>>>> Thank you for reply. >>>>>> >>>>>> 1. The dig is returning proper PTR >>>>>> record. I've added it manually to the >>>>>> zone and it's working. >>>>> >>>>> I was asking for SOA and zone name, IMO >>>>> there is nothing secret about reverse zone >>>>> name from private address space >>>>> >>>>> what returns this command on server? >>>>> python -c 'import netaddr; from dns import >>>>> resolver; ip = >>>>> netaddr.IPAddress("10.0.0.165"); revn = >>>>> ip.reverse_dns; print revn; print >>>>> resolver.zone_for_name(revn)' >>>>> >>>>> >>>>> # python -c 'import netaddr; from dns import >>>>> resolver; ip = >>>>> netaddr.IPAddress("10.0.0.165"); revn = >>>>> ip.reverse_dns; print revn; print >>>>> resolver.zone_for_name(revn)' >>>>> 165.0.0.10.in-addr.arpa. >>>>> in-addr.arpa. >>>> >>>> It looks that python-dns failed to find proper >>>> zone, what is supposed to be authoritative zone >>>> for that record in your system? >>>> How do your reverse zones look? >>>> >>>> I have the reverse zone added. >>>> 0.0.10.in-addr.arpa. >>>> >>>> Do you know maybe how python/ipa is determining >>>> what's the dns server for the internal zone? >>>> As far I understood this is not a "access rights >>>> issue". It's a DNS PTR resolution problem with >>>> python(ipa's using python) ? >>> >>> It doesn't care about resolver, python-dns is >>> checking SOA records, it removes labels from left >>> and tries to find best match zone >>> >>> what returns dig 0.0.10.in-addr.arpa. SOA ? >>> >>> >>>> >>>> >>>> >>>>> >>>>>> 2. The problem exists while adding host >>>>>> entries or A records with "create >>>>>> reverse" option. >>>>> That's why I asked to run dig, the code >>>>> uses DNS system to determine zone. >>>>> >>>>>> 3. If I'll bind a host with >>>>>> ipa-client-install the PTR record gets >>>>>> created in the reverse zone and it works >>>>> Ok >>>>> >>>>> Manually creating the PTR record works fine as >>>>> well. >>>>> >>>>> >>>>> >>>>>> 4. The resolv.conf file has only the IPA >>>>>> server IP addres/localhost added. >>>>> >>>>> Have you changed it recently? >>>>> >>>>> Yes, it pointed to outside 8.8.8.8, so the OS >>>>> did not see the local reverse zone. >>>>> Now it's pointing to localhost. And I get dig >>>>> the PTRs. (I've manually created the ptr) >>>>> >>>>> # dig -x 10.0.0.165 >>>>> >>>>> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x >>>>> 10.0.0.165 >>>>> ;; global options: +cmd >>>>> ;; Got answer: >>>>> ;; ->>HEADER<<- opcode: QUERY, status: >>>>> NOERROR, id: 35592 >>>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, >>>>> AUTHORITY: 1, ADDITIONAL: 2 >>>>> >>>>> ;; OPT PSEUDOSECTION: >>>>> ; E: version: 0, flags:; udp: 4096 >>>>> ;; QUESTION SECTION: >>>>> ;165.0.0.10.in-addr.arpa.INPTR >>>>> >>>>> ;; ANSWER SECTION: >>>>> 165.0.0.10.in-addr.arpa. >>>>> 1200INPTRprdfrmprb01.cs.int >>>>> . >>>>> >>>>> ;; AUTHORITY SECTION: >>>>> 1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int >>>>> . >>>>> >>>> >>>> This authority section looks suspicious, I >>>> would expect something like 0.0.10.in-addr.arpa. >>>> >>>> Back to question about your reverse zones. >>>> >>>> I've intentionally hid our internal ip space, >>>> sorry, good catch my finger has slipped :). >>> >>> So is the 0.0.10.in-addr.arpa. an authoritative >>> zone? Or what dig returned in authority section. >>> >>> >>>> >>>> >>>>> ;; ADDITIONAL SECTION: >>>>> freeipa1.cs.int >>>>> .1200INA10.0.0.200 >>>>> >>>>> ;; Query time: 3 msec >>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >>>>> ;; WHEN: czw gru 22 04:51:23 EST 2016 >>>>> ;; MSG SIZE rcvd: 124 >>>>> >>>>> >>>>> >>>>> Martin >>>>> >>>>> >>>>>> >>>>>> Cheers! >>>>>> M. >>>>>> >>>>>> On Wed, Dec 21, 2016 at 5:43 PM, Martin >>>>>> Basti >>>>> > wrote: >>>>>> >>>>>> Hello all :) >>>>>> >>>>>> >>>>>> On 20.12.2016 01:33, Maciej Drobniuch >>>>>> wrote: >>>>>>> Hi All! >>>>>>> >>>>>>> I get the following message while >>>>>>> adding a new hostname. >>>>>>> >>>>>>> "The host was added but the DNS >>>>>>> update failed with: DNS reverse zone >>>>>>> in-addr.arpa. for IP address >>>>>>> 10.0.0.165 is not managed by this >>>>>>> server" >>>>>> >>>>>> IPA failed to get correct reverse >>>>>> zone, can you try dig -x 10.0.0.165 >>>>>> what will be in SOA answer? >>>>>> >>>>>> What is the name of reverse zone you >>>>>> have on IPA DNS server? >>>>>> >>>>>> >>>>>> Martin >>>>>> >>>>>>> >>>>>>> The reverse zone is configured and >>>>>>> working. >>>>>>> When I am manually adding the PTR >>>>>>> record to the reverse zone - all OK >>>>>>> >>>>>>> While adding a new host, the A >>>>>>> record is being created but the PTR >>>>>>> fails with the message above. >>>>>>> >>>>>>> Reinstalling centos+IPA worked once >>>>>>> but I had to reinstall again because >>>>>>> of problems with kerberos(probably >>>>>>> dependencies). >>>>>>> >>>>>>> Not sure what is the root cause of >>>>>>> the issue. >>>>>>> >>>>>>> VERSION: 4.4.0, API_VERSION: 2.213 >>>>>>> >>>>>>> CENTOS7 Linux freeipa1 >>>>>>> 3.10.0-229.el7.x86_64 #1 SMP Fri Mar >>>>>>> 6 11:36:42 UTC 2015 x86_64 x86_64 >>>>>>> x86_64 GNU/Linux >>>>>>> >>>>>>> Any help appreciated! >>>>>>> -- >>>>>>> Best regards >>>>>>> >>>>>>> Maciej Drobniuch >>>>>>> Network Security Engineer >>>>>>> Collective-sense LLC >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards >>>>>> >>>>>> Maciej Drobniuch >>>>>> Network Security Engineer >>>>>> Collective-sense LLC >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards >>>>> >>>>> Maciej Drobniuch >>>>> Network Security Engineer >>>>> 2410 Camino Ramon, Suite 129 >>>>> San Ramon, CA 94583 >>>> >>>> >>>> Happy new year! >>>> >>>> -- >>>> Best regards >>>> >>>> Maciej Drobniuch >>>> Network Security Engineer >>>> Collective-Sense,LLC >>> >>> >>> >>> >>> -- >>> Best regards >>> >>> Maciej Drobniuch >>> Network Security Engineer >>> Collective-Sense,LLC >> >> >> >> >> -- >> Best regards >> >> Maciej Drobniuch >> Network Security Engineer >> Collective-Sense,LLC > > > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-Sense,LLC > > > > > -- > Best regards > > Maciej Drobniuch > Network Security Engineer > Collective-Sense,LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at instinctualsoftware.com Tue Dec 27 18:08:10 2016 From: alan at instinctualsoftware.com (Alan Latteri) Date: Tue, 27 Dec 2016 10:08:10 -0800 Subject: [Freeipa-users] Upgrade to 4.4.0 Breaks login. In-Reply-To: References: <20161223093134.zk25q7xaj7zhdq7b@redhat.com> Message-ID: <8E839F8C-DEF8-4974-96B0-0927B91226ED@instinctualsoftware.com> Can you provide an example of what file this entry should go into and what it look like in file? Do you have to do this on the client side/ server or both? Thanks, Alan > On Dec 23, 2016, at 4:43 AM, Dan Kemp wrote: > > That did it, thanks! I could have sworn I tried that, maybe I ended up putting it in in the wrong section. I wish whatever changed going from 4.2.0 to 4.4.0 that made SELinux required, took the selinux enforcement level into account and updated the file accordingly. > > > On Fri, Dec 23, 2016 at 4:31 AM, Alexander Bokovoy > wrote: > On to, 22 joulu 2016, Dan Kemp wrote: > Hello, > > I recently ran an upgrade of my freeipa servers, and most of the clients to > 4.4.0 (Current with CentOS 7 repos) from version 4.2.0. After the install > and server update, I can no longer log in to update clients via ssh. Login > to non-update clients works as before. > > The SSH connections fail with: > > Connection closed by UNKNOWN > > I ran sssd with debugging on a failing 4.4.0 client and got this error log: > > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit > ldb transaction (nesting: 2) > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit > ldb transaction (nesting: 1) > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [ldb] (0x4000): commit > ldb transaction (nesting: 0) > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] > [selinux_child_create_buffer] (0x4000): buffer size: 45 > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] > (0x2000): Setting up signal handler up for pid [437] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_handler_setup] > (0x2000): Signal handler set up for pid [437] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] > (0x2000): Trace: sh[0x560c04c37790], connected[1], ops[(nil)], > ldap[0x560c04c32d60] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [sdap_process_result] > (0x2000): Trace: end of ldap_result list > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [write_pipe_handler] > (0x0400): All data has been sent! > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): > selinux_child started. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): > Running with effective IDs: [0][0]. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x2000): > Running with real IDs [0][0]. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): > context initialized > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): seuser length: 12 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): seuser: unconfined_u > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): mls_range length: 14 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): mls_range: s0-s0:c0.c1023 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): username length: 7 > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [unpack_buffer] > (0x2000): username: ipauser > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0400): > performing selinux operations > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [sss_semanage_init] > (0x0020): SELinux policy not managed > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [get_seuser] > (0x0020): Cannot create SELinux handle > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] > [seuser_needs_update] (0x2000): get_seuser: ret: 5 seuser: unknown mls: > unknown > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [sss_semanage_init] > (0x0020): SELinux policy not managed > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [set_seuser] > (0x0020): Cannot init SELinux management > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): > Cannot set SELinux login context. > (Wed Dec 20 20:38:13 2016) [[sssd[selinux_child[437]]]] [main] (0x0020): > selinux_child failed! > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [read_pipe_handler] > (0x0400): EOF received, client finished > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [selinux_child_done] > (0x0020): selinux_child_parse_response failed: [22][Invalid argument] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_done] (0x0400): > DP Request [PAM SELinux #3]: Request handler finished [0]: Success > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [_dp_req_recv] > (0x0400): DP Request [PAM SELinux #3]: Receiving request data. > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] > (0x0400): DP Request [PAM SELinux #3]: Request removed. > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_req_destructor] > (0x0400): Number of active DP request: 0 > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [dp_pam_reply] > (0x1000): DP Request [PAM Account #2]: Sending result [4][domain.local] > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] > (0x1000): Waiting for child [437]. > (Wed Dec 20 20:38:13 2016) [sssd[be[domain.local]]] [child_sig_handler] > (0x0020): child [437] failed with status [1]. > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_remove_timeout] (0x2000): > 0x55f4be11f4c0 > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: > 0x55f4be1191b0 > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [sbus_dispatch] (0x4000): > Dispatching. > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_dp_process_reply] (0x0200): > received: [4 (System error)][domain.local] > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply > called with result [4]: System error. > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [pam_reply] (0x0200): blen: 39 > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x55f4be11f980][19] > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x55f4be11f980][19] > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_recv] (0x0200): Client > disconnected! > (Wed Dec 20 20:38:13 2016) [sssd[pam]] [client_close_fn] (0x2000): > Terminated client [0x55f4be11f980][19] > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x5604f5217c60][22] > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client > disconnected! > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): > Terminated client [0x5604f5217c60][22] > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [reset_idle_timer] (0x4000): Idle > timer re-set for client [0x5604f5216b20][21] > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_recv] (0x0200): Client > disconnected! > (Wed Dec 20 20:38:13 2016) [sssd[nss]] [client_close_fn] (0x2000): > Terminated client [0x5604f5216b20][21] > > > SeLinux is disabled, as I am running the clients in LXC containers on a > debian host. My setup is pretty simple, and was working before (and > connections to 4.2.0 clients are still functional!). Nothing looks amiss in > the ssh logs. > Add selinux_provider=none to the domain section if you are not using > SELinux at all. > > -- > / 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Tue Dec 27 18:21:58 2016 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 27 Dec 2016 19:21:58 +0100 Subject: [Freeipa-users] Upgrade to 4.4.0 Breaks login. In-Reply-To: <8E839F8C-DEF8-4974-96B0-0927B91226ED@instinctualsoftware.com> References: <20161223093134.zk25q7xaj7zhdq7b@redhat.com> <8E839F8C-DEF8-4974-96B0-0927B91226ED@instinctualsoftware.com> Message-ID: <20161227182157.GA25834@10.4.128.1> On (27/12/16 10:08), Alan Latteri wrote: >Can you provide an example of what file this entry should go into and what it look like in file? Do you have to do this on the client side/ server or both? > Do you have the same problem? Could you provide steps how do you run lxc container? >Thanks, >Alan > >> On Dec 23, 2016, at 4:43 AM, Dan Kemp wrote: >> >> That did it, thanks! I could have sworn I tried that, maybe I ended up putting it in in the wrong section. I wish whatever changed going from 4.2.0 to 4.4.0 that made SELinux required, took the selinux enforcement level into account and updated the file accordingly. >> BTW this bug is not related to ipa-client 4.2 or 4.4. It might be caused by changes in sssd or libsemanage. LS From jochen at jochen.org Wed Dec 28 13:04:16 2016 From: jochen at jochen.org (Jochen Hein) Date: Wed, 28 Dec 2016 14:04:16 +0100 Subject: [Freeipa-users] Using Privacyidea with FreeIPA - SSL certificates for PI In-Reply-To: <8360m4z012.fsf@echidna.jochen.org> (Jochen Hein's message of "Wed, 28 Dec 2016 13:54:49 +0100") References: <8360m4z012.fsf@echidna.jochen.org> Message-ID: <83zijgxl0v.fsf@echidna.jochen.org> Jochen Hein writes: > [ This mail sets the stage for more parts, which will get into technical > details. Comments or suggestions are welcome, possibly we should add > refined texts in the relevant wikis/documentations. - Jochen ] == Get SSL certificate from IPA == Maintaining a local CA is cumbersome, certificates need to be refreshed in regular intervals, and the CA certificate needs to be available on all systems. And you need to chosse ciphers and other parameters wisely (I didn't, so chrome complains about my local certificates). We need a couple of certificates anyway, so using some help is wise. We need: * SSL certificates for our local servers and services (letsencrypt might help, but I prefer my own CA. * Certificates for user authentification for OpenVPN or OpenConnect. Privacyidea has an option to connect to an external CA, but FreeIPA has a well integrated and usable CA. We can get certificates for each IPA-enrolled server, service, or user. The CA certificate is already on each enrolled client, and the best of all: certmonger will refresh certificates before they expire. So, let's get a certificate from IPA for privacyidea. First we need to add a service principal to IPA, which will own the certificate: ipa service-add HTTP/.example.org Next we add a scipt to the privacyidea host to enable restarts after the certificates have been refreshed (e.g. /root/refresh_apache_certificate.sh): #!/bin/bash chmod 600 /etc/ssl/certs/privacyideaserver.pem chown root:root /etc/ssl/certs/privacyideaserver.pem chmod 600 /etc/ssl/private/privacyideaserver.key chown root:root /etc/ssl/private/privacyideaserver.key systemctl restart apache2.service And now we are ready to request a certificate vom IPA: ipa-getcert request -f /etc/ssl/certs/privacyideaserver.pem \ -k /etc/ssl/private/privacyideaserver.key \ -N "CN=$(hostname --fqdn)" -D $(hostname) \ -K HTTP/$(hostname --fqdn) \ -U 1.3.6.1.5.5.7.3.1 \ -C "/root/refresh_apache_certificate.sh" Verify that the status is "MONITORING" with "ipa-getcert list". When accessing your privacyidea server from an enrolled client you should see a green lock and no certificate warnings. I find that pretty impressive, after having fought with a local CA. -- The only problem with troubleshooting is that the trouble shoots back. From jochen at jochen.org Wed Dec 28 13:09:14 2016 From: jochen at jochen.org (Jochen Hein) Date: Wed, 28 Dec 2016 14:09:14 +0100 Subject: [Freeipa-users] Using Privacyidea with FreeIPA - use IPA as userstore In-Reply-To: <8360m4z012.fsf@echidna.jochen.org> (Jochen Hein's message of "Wed, 28 Dec 2016 13:54:49 +0100") References: <8360m4z012.fsf@echidna.jochen.org> Message-ID: <83vau4xksl.fsf@echidna.jochen.org> Jochen Hein writes: > [ This mail sets the stage for more parts, which will get into technical > details. Comments or suggestions are welcome, possibly we should add > refined texts in the relevant wikis/documentations. - Jochen ] == Use IPA as our userstore in privacyidea == First we need an LDAP user to access the userstore. Store the following in the file privacyidea-fetch.ldif on you IPA server: dn: uid=privacyidea-fetch,cn=sysaccounts,cn=etc,dc=example,dc=org changetype: add objectclass: account objectclass: simplesecurityobject objectclass: top uid: privacyidea-fetch userPassword: passwordExpirationTime: 20380119031407Z nsIdleTimeout: 0 Add the user to FreeIPAs 389-dirsrv [TODO: verify command]: ldapadd -Y GSSAPI -f privacyidea-fetch.ldif Define your LDAP resolver in Privacyidea as follows: Server-URI: ldaps://.example.org Base-DN: cn=users,cn=accounts,dc=example,dc=org Bind-DN: uid=privacyidea-fetch,cn=sysaccounts,cn=etc,dc=example,dc=org Bind-Type: simple Loginname Attribute: uid Search Filter: (uid=*)(objectClass=inetorgperson) User Filter: (&(uid=%s)(objectClass=inetOrgPerson)) Attribute Mapping: { "username": "uid", "phone" : "telephoneNumber", "mobile" : "mobile", "email" : "mail", "surname" : "sn", "givenname" : "givenName", "description" : "gecos" } UID Type: ipaUniqueID TODO: Discuss options for UID Type. What should we recommend? DN seems to work. Changing is a bad idea, because it invalidates the token assignment to users. ipaUniqueID has: [2016-12-23 19:38:47,509][30665][140606770149120][WARNING][privacyidea.lib.resolvers.LDAPIdResolver:211] failed to check password for u'1c2ec066-648e-11e5-84ca-525400fe9f35'/u'uid=jochen,cn=users,cn=accounts,dc=jochen,dc=org': Exception('Wrong credentials',) TODO: when saving the resolver in privacyidea: [2016-12-23 21:07:18,437][30665][140606770149120][WARNING][privacyidea.lib.resolver:130] the passed key u'CACHE_TIMEOUT' is not a parameter for the resolver u'ldapresolver' Wishlist: Use SRV records from DNS to find the LDAP servers. -- The only problem with troubleshooting is that the trouble shoots back. From jochen at jochen.org Wed Dec 28 12:54:49 2016 From: jochen at jochen.org (Jochen Hein) Date: Wed, 28 Dec 2016 13:54:49 +0100 Subject: [Freeipa-users] Using Privacyidea with FreeIPA - part 1/n Message-ID: <8360m4z012.fsf@echidna.jochen.org> [ This mail sets the stage for more parts, which will get into technical details. Comments or suggestions are welcome, possibly we should add refined texts in the relevant wikis/documentations. - Jochen ] When I first looked at privacyidea I was quite unsure how it would integrate into my existing network and what tokens and applications I would use privacyidea for. After lots of thought and experiments I now think I have a useful scenario to work with. I run a family network with a local mail server (Kolab), webmail, ssh, and VPN access and think the structure might also work for small or medium offices too. Originally I had the userstore in Kolab's LDAP server which I wanted to use for more applications, e.g. Linux logins. pam_ldap and pam_ldapd could access the userstore in LDAP, but require that the server is available. How should that work for a roadwarrior setup? I've found sssd, but never had time to play with it. So that idea never got off the ground. Former tries with Kerberos/LDAP have not been successful, but once I found FreeIPA[1] I was kind of hooked. FreeIPA has: - LDAP as backend (e.g. userstore) - a versatile command line interface ("ipa") - a useful web interface - client software to join a Linux machine into the FreeIPA realm - sssd for clients by default - works "out of the box" If you need a central userstore with host based access control, SSO and lots of other features - I can really recommend it. I'll discuss later, what features I use with which software and why. The latest FreeIPA version has some OTP features included, for example Yubikeys or FreeOTP tokens. So, why would you want to use another OTP provider than FreeIPA? I use (and plan to extend the usage) Yubikey tokens. Since the Yubikeys only have two slots[2], we need to decide what we want to use the slots for. I want to have the following applications running with my Yubikeys: - Second Factor for my keepass file - Second Factor for login/ssh (later webmail access) - Second Factor for sudo authentication I've settled for the following usage of the slots: * Slot 1: This is a (reprogrammed) Yubico-AES token, which authenticates against Privacyides yubico mode instead of Yubicos cloud server. Why Yubico and not HOTP or TOTP? Here FreeIPA fails for me: Yubikey can't do TOTP, HOTP token can get out of sync, when we use them for local authentication, FreeIPA and Kolab (each application has a count, which needs to be "in near sync" with the counter in the Yubikey. I wouldn't trust such a setup.) But providing access to a Yubico Token via privacyidea works for all cases I have in mind. * Slot 2: Yubikey Challenge Response I use that as a second factor for my keepass file with keechallenge. The second application is my LUKS encrypted Laptop with privacyidea's privacyidea-luks-assign help. With pam_yubico I restrict access to Laptops with a second factor, without the need for a central authentication server[3]. For the laptops (local login) I skip entering a sudo password when a yubico is present and authenticated. Since there is no token count, the token will not get out of sync. For my local net u2f didn't seem useful, but I'll use it for remote services. I consider that design more secure than using only a password, but also more convenient. Let's see how far that will take us. [1] http://www.freeipa.org [2] How does that relate to PIV, U2F, and smart card features? [3] pam_python+privacyidea might help, but the packages are not in distro repositories and even more of a niche product than pam_yubico. The rest of this series expects that the PI host is enrolled in IPA. On Debian/Ubuntu systems, add the ca.crt to the local ca store: ln -s /etc/ipa/ca.crt /usr/local/share/ca-certificates update-ca-certificates -- The only problem with troubleshooting is that the trouble shoots back. From dag at sonsorol.org Wed Dec 28 13:52:41 2016 From: dag at sonsorol.org (Chris Dagdigian) Date: Wed, 28 Dec 2016 08:52:41 -0500 Subject: [Freeipa-users] Any good CLI methods for testing connectivity from IPA replica to remote AD servers? Message-ID: <5863C3A9.6030703@sonsorol.org> Hi folks, I may have network blocks between one of my IPA replicas and the *many* remote AD servers that need to be queried but I can only see evidence of this in the authentication failures and the debug level logging. Not sure how to test from the command line to verify connectivity or narrow down which ports may be getting blocked. Are there any common CLI techniques, ldaps:// search queries or other commands that could be run from an IPA replica to confirm basic communication with a remote AD controller? Thanks! Chris From lo73fr at gmail.com Wed Dec 28 14:47:45 2016 From: lo73fr at gmail.com (Laurent ARNAL) Date: Wed, 28 Dec 2016 15:47:45 +0100 Subject: [Freeipa-users] Error 500 on authentification from WebUI, Message-ID: Hello, I would apreciate some help to solve my issue on freeipa configuration. I've got two host in my configuration h1, and a replica h2. On host h2, everithing is working well. On host h1, at the start, everything was working well, but since a few day, I start received error when I login from Web UI interface. I I do a curl on the login_password uri, I've got a 500 error: curl -Lksi --data 'user=admin&password=mypass' https://h1.clae.net/ipa/ session/login_password HTTP/1.1 500 Internal Server Error Date: Wed, 28 Dec 2016 14:41:33 GMT Server: Apache/2.4.25 (Fedora) X-Frame-Options: DENY Content-Security-Policy: frame-ancestors 'none' Content-Length: 610 Connection: close Content-Type: text/html; charset=iso-8859-1 500 Internal Server Error

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at root at localhost to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

The same request on h2 return sucess curl -Lksi --data 'user=admin&password=mypass' https://h2.clae.net/ipa/ session/login_password HTTP/1.1 200 Success Date: Wed, 28 Dec 2016 14:43:13 GMT Server: Apache/2.4.25 (Fedora) X-Frame-Options: DENY Content-Security-Policy: frame-ancestors 'none' Set-Cookie: ipa_session=bdb87cfe758fd050dd69f6c0ca9988a3; Domain= kerclaei.clae.net; Path=/ipa; Expires=Wed, 28 Dec 2016 15:03:13 GMT; Secure; HttpOnly Vary: Accept-Encoding Transfer-Encoding: chunked Content-Type: text/plain; charset=UTF-8 Looking at the apache log, I can see the following error on h1: [Wed Dec 28 15:03:38.776075 2016] [wsgi:error] [pid 12804] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Wed Dec 28 15:03:38.776168 2016] [wsgi:error] [pid 12804] ipa: DEBUG: WSGI login_password.__call__: [Wed Dec 28 15:03:38.776348 2016] [wsgi:error] [pid 12804] ipa: DEBUG: Obtaining armor ccache: principal=HTTP/h1.clae.net at CLAE.NET keytab=/etc/httpd/conf/ipa.keytab ccache=/var/run/ipa_memcached/krbcc_A_admin [Wed Dec 28 15:03:38.776414 2016] [wsgi:error] [pid 12804] ipa: DEBUG: Initializing principal HTTP/h1.clae.net at CLAE.NET using keytab /etc/httpd/conf/ipa.keytab [Wed Dec 28 15:03:38.776470 2016] [wsgi:error] [pid 12804] ipa: DEBUG: using ccache /var/run/ipa_memcached/krbcc_A_admin [Wed Dec 28 15:03:39.395270 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] mod_wsgi (pid=12804): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. [Wed Dec 28 15:03:39.395330 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] Traceback (most recent call last): [Wed Dec 28 15:03:39.395358 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] File "/usr/share/ipa/wsgi.py", line 63, in application [Wed Dec 28 15:03:39.395397 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] return api.Backend.wsgi_dispatch(environ, start_response) [Wed Dec 28 15:03:39.395412 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 262, in __call__ [Wed Dec 28 15:03:39.395440 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] return self.route(environ, start_response) [Wed Dec 28 15:03:39.395453 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 274, in route [Wed Dec 28 15:03:39.395477 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] return app(environ, start_response) [Wed Dec 28 15:03:39.395491 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 978, in __call__ [Wed Dec 28 15:03:39.395514 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] self.kinit(user, self.api.env.realm, password, ipa_ccache_name) [Wed Dec 28 15:03:39.395527 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 1010, in kinit [Wed Dec 28 15:03:39.395564 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] raise CCacheError(message=unicode(e)) [Wed Dec 28 15:03:39.395589 2016] [wsgi:error] [pid 12804] [remote 192.168.254.1:61185] CCacheError: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529638936): Preauthentication failed I've also notice that running ipa command on h1, the command are running ok, but with strange message about password_callback ipa user-show admin exception in PK11 password callback TypeError: password_callback() takes exactly 4 arguments (3 given) exception in PK11 password callback TypeError: password_callback() takes exactly 4 arguments (3 given) exception in PK11 password callback TypeError: password_callback() takes exactly 4 arguments (3 given) Identifiant de connexion: admin Nom: Administrator R?pertoire personnel: /home/users/admin Interpr?teur de commande: /bin/bash Principal alias: admin at CLAE.NET UID: 5000 GID: 5000 Compte d?sactiv?: False Mot de passe: True Membre des groupes: admins, trust admins Cl?s Kerberos disponibles: True The same command on h2 don't show this messages. Can someone help me with this, I take a look on google, but don't find any reference on this, and don't know where to start. Regards, Laurent. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gparente at redhat.com Wed Dec 28 15:29:56 2016 From: gparente at redhat.com (German Parente) Date: Wed, 28 Dec 2016 16:29:56 +0100 Subject: [Freeipa-users] IPA Servers out of sync - DNS records In-Reply-To: References: <4b91efa8-7c41-b093-0978-be14414817c8@redhat.com> <67928c0b-9c50-0f6b-e7c0-6476446fc771@redhat.com> Message-ID: Hi, I think we can explain it. Is it possible that you were running 389-ds-base-1.3.4.0-33.el7_2.x86_64.rpm release ? >From the string: 389-Directory/1.3.4.0 B2016.215.1556 it seems to me that corresponds to rpm -qi -p 389-ds-base-1.3.4.0-33.el7_2.x86_64.rpm | grep -i ^signature Signature : RSA/SHA256, Tue 26 Jul 2016 04:49:26 AM CEST, Key ID 199e2f91fd431d51 This release includes a very harmful replication bug that manifests with this error message, that we can see in your logs: [20/Dec/2016:22:50:14 -0500] agmt="cn=meToipa2.optimcloud.com" (ipa2:389) - Can't locate CSN 58528dac000200040000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. And the replicas are out of sync + replication stopped. It's explained in this article: https://access.redhat.com/solutions/2690611 IdM/IPA LDAP and Red Hat Directory Server/RHDS replication halt, error Can't locate CSN number in the changelog (DB rc=-30988) You update to 7.3 has the fix for that bug included. regards, German. On Tue, Dec 27, 2016 at 1:21 PM, Outback Dingo wrote: > > According to log, it looks that replication has been restored a week ago > > > > can you use https://github.com/peterpakos/ipa_check_consistency to check > > what else is missing? > > > > If it finds missing entries, probably re-initialization will be needed > > > > Martin > > > really odd... i just did a yum update -y during our conversation on > both servers, now ipa2 is synced again... > > -- > Manage your subscription for 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 jrichard at placeiq.com Wed Dec 28 21:20:45 2016 From: jrichard at placeiq.com (Jim Richard) Date: Wed, 28 Dec 2016 16:20:45 -0500 Subject: [Freeipa-users] Can't create replica Message-ID: <4B2D52D4-6D5C-44D0-8D03-EC66F38DC57A@placeiq.com> This pretty much describes my issue: https://access.redhat.com/solutions/136993 ipa-server.x86_64 3.0.0-50.el6.centos.3 But it?s a little more complicated than that. My goal at this point is just to get to one master with no replication, no remnants of replication, no dangling this or that in either the the main LDAP or the CA instance. But, I think I?ve hosed it up pretty good, all things replication that is. So there is only one live server now, sso-109.nym1.placeiq.net But in going through the steps in that article I noticed something strange. Notice the ReplicaBindDN principalname in the first command, that server no longer exists And notice the the ID, 40. Then look at the output from the next command. ID 40 is actually sso-109, am I reading that right?? and of course CLEANRUV40 gives "error 53 unwilling to perform? - which is expected ?? I think, maybe I don?t know :( So uh, how do I un-F? myself here? Can I like manually delete that replication instance 40? If I?m saying, I just want one master, no replicas (will of course create a replica once I?m sure my one master is squared away), should I be able to get the db to a state with no nsDS5Replica entries? [root at sso-109:(NYM) slapd-PKI-IPA]$ ldapsearch -xLLL -D "cn=directory manager" -W -s sub -b cn=config objectclass=nsds5replica Enter LDAP Password: dn: cn=replica,cn=dc\3Dplaceiq\2Cdc\3Dnet,cn=mapping tree,cn=config cn: replica nsDS5Flags: 1 objectClass: top objectClass: nsds5replica objectClass: extensibleobject nsDS5ReplicaType: 3 nsDS5ReplicaRoot: dc=placeiq,dc=net nsds5ReplicaLegacyConsumer: off nsDS5ReplicaId: 40 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsDS5ReplicaBindDN: krbprincipalname=ldap/sso-110.nym1.placeiq.net at PLACEIQ.NET ,cn=services,cn=accounts,dc=placeiq,dc=net nsState:: KAAAAAAAAADkKWRYAAAAAAAAAAAAAAAADwAAAAAAAAASAAAAAAAAAA== nsDS5ReplicaName: 889b4308-86c311e6-95188dad-28da3cc2 nsds5ReplicaChangeCount: 13615 nsds5replicareapactive: 0 [root at sso-109:(NYM) slapd-PKI-IPA]$ ldapsearch -xLLL -D "cn=directory manager" -W -b dc=placeiq,dc=net \ > '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' Enter LDAP Password: ldap_bind: Invalid credentials (49) [root at sso-109:(NYM) slapd-PKI-IPA]$ ldapsearch -xLLL -D "cn=directory manager" -W -b dc=placeiq,dc=net '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' Enter LDAP Password: dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=placeiq,dc=net objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 52b07d23000000040000 nsds50ruv: {replica 40 ldap://sso-109.nym1.placeiq.net:389} 57ede5500007002800 00 58642aad000100280000 dc: placeiq nsruvReplicaLastModified: {replica 40 ldap://sso-109.nym1.placeiq.net:389} 586 42a9e Jim Richard SYSTEM ADMINISTRATOR III (646) 338-8905 -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Wed Dec 28 23:15:33 2016 From: william.muriithi at gmail.com (William Muriithi) Date: Wed, 28 Dec 2016 18:15:33 -0500 Subject: [Freeipa-users] Assistance with Samba share intergration with IPA Message-ID: Hello I am trying to setup a samba share - actually replace winbind on a current samba server and I am basing my change on these instructions. http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA The IPA servers is version ipa-server-4.4.0-14.el7 and I have trust established between AD and IPA. Samba server is on RHEL 6.8 Ideally, I would prefer to leave samba on RHEL 6 and it looks like RHEL 6 is currently using sssd-1.13.3-22.el6_8.4.x86_64. According to above link, you need sssd v1.12.2 and above. Would the version on RHEL 6 above be bundling sssd-libwbclient by any chance? If not, is it possible to install sssd-libwbclient on RHEL 6? Also, on smb.conf, its a bit ambiguous what REALM need to be used. Does one need to use IPA REALM or active directory REALM on these two lines below? workgroup = MY realm = MY.REALM Lastly, when I followed the above article to setup samba, I got the following errors when I attempted to connect to samba from Windows. What would be potential places to go check for misconfiguration? Dec 28 17:49:41 manganese smbd[30221]: [2016/12/28 17:49:41.503322, 0] libads/kerberos_verify.c:75(ads_dedicated_keytab_verify_ticket) Dec 28 17:49:41 manganese smbd[30221]: krb5_rd_req failed (Wrong principal in request) Dec 28 17:49:41 manganese smbd[30221]: [2016/12/28 17:49:41.507090, 0] libads/kerberos_verify.c:75(ads_dedicated_keytab_verify_ticket) Dec 28 17:49:41 manganese smbd[30221]: krb5_rd_req failed (Wrong principal in request) Regards, William From daniel at schimpfoessl.com Thu Dec 29 00:45:49 2016 From: daniel at schimpfoessl.com (Daniel Schimpfoessl) Date: Wed, 28 Dec 2016 18:45:49 -0600 Subject: [Freeipa-users] Asking for help with crashed freeIPA istance In-Reply-To: References: <729a8aed-4f22-ba26-3089-58c675bd64e0@redhat.com> <585A9F46.7080207@redhat.com> Message-ID: Rob/Florence, do you have any pointers on how to troubleshoot, reinstall/configure, update or fix the PKI server to function properly? Also if you know of any documentation or video that could be helpful. I researched the typical suspects youtube and freeipa.org without luck. Daniel 2016-12-22 18:08 GMT-06:00 Daniel Schimpfoessl : > I do not believe I changed the DM password. I know I had to update the > admin passwords regularly. > > Only during the startup using ipactl start --force I am able to connect to > the service using the password for DM and it returns: > > # extended LDIF > # > # LDAPv3 > # base <> with scope baseObject > # filter: (objectclass=*) > # requesting: ALL > # > > # > dn: > objectClass: top > namingContexts: cn=changelog > namingContexts: dc=myorg,dc=com > namingContexts: o=ipaca > defaultnamingcontext: dc=myorg,dc=com > supportedExtension: 2.16.840.1.113730.3.5.7 > supportedExtension: 2.16.840.1.113730.3.5.8 > supportedExtension: 2.16.840.1.113730.3.5.10 > supportedExtension: 2.16.840.1.113730.3.8.10.3 > supportedExtension: 2.16.840.1.113730.3.8.10.4 > supportedExtension: 2.16.840.1.113730.3.8.10.4.1 > supportedExtension: 1.3.6.1.4.1.4203.1.11.1 > supportedExtension: 2.16.840.1.113730.3.8.10.1 > supportedExtension: 2.16.840.1.113730.3.8.10.5 > supportedExtension: 2.16.840.1.113730.3.5.3 > supportedExtension: 2.16.840.1.113730.3.5.12 > supportedExtension: 2.16.840.1.113730.3.5.5 > supportedExtension: 2.16.840.1.113730.3.5.6 > supportedExtension: 2.16.840.1.113730.3.5.9 > supportedExtension: 2.16.840.1.113730.3.5.4 > supportedExtension: 2.16.840.1.113730.3.6.5 > supportedExtension: 2.16.840.1.113730.3.6.6 > supportedExtension: 2.16.840.1.113730.3.6.7 > supportedExtension: 2.16.840.1.113730.3.6.8 > supportedExtension: 1.3.6.1.4.1.1466.20037 > supportedControl: 2.16.840.1.113730.3.4.2 > supportedControl: 2.16.840.1.113730.3.4.3 > supportedControl: 2.16.840.1.113730.3.4.4 > supportedControl: 2.16.840.1.113730.3.4.5 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.16 > supportedControl: 2.16.840.1.113730.3.4.15 > supportedControl: 2.16.840.1.113730.3.4.17 > supportedControl: 2.16.840.1.113730.3.4.19 > supportedControl: 1.3.6.1.1.13.1 > supportedControl: 1.3.6.1.1.13.2 > supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 > supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 > supportedControl: 1.3.6.1.4.1.4203.666.5.16 > supportedControl: 2.16.840.1.113730.3.8.10.6 > supportedControl: 2.16.840.1.113730.3.4.14 > supportedControl: 2.16.840.1.113730.3.4.20 > supportedControl: 1.3.6.1.4.1.1466.29539.12 > supportedControl: 2.16.840.1.113730.3.4.12 > supportedControl: 2.16.840.1.113730.3.4.18 > supportedControl: 2.16.840.1.113730.3.4.13 > supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: DIGEST-MD5 > supportedSASLMechanisms: CRAM-MD5 > supportedSASLMechanisms: ANONYMOUS > supportedLDAPVersion: 2 > supportedLDAPVersion: 3 > vendorName: 389 Project > vendorVersion: 389-Directory/1.3.4.0 B2016.215.1556 > dataversion: 020161222235947020161222235947020161222235947 > netscapemdsuffix: cn=ldap://dc=wwgwho01,dc=myorg,dc=com:389 > lastusn: 8690425 > changeLog: cn=changelog > firstchangenumber: 2752153 > lastchangenumber: 2752346 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > 2016-12-21 9:27 GMT-06:00 Rob Crittenden : > >> Daniel Schimpfoessl wrote: >> > Thanks for getting back to me. >> > >> > getcert list | grep expires shows dates years in the future for all >> > certificates >> > Inline-Bild 1 >> > >> > ipactl start --force >> > >> > Eventually the system started with: >> > Forced start, ignoring pki-tomcatd Service, continuing normal >> > operations. >> > >> > systemctl status ipa shows: failed >> >> I don't think this is a certificate problem at all. I think the timing >> with your renewal is just coincidence. >> >> Did you change your Directory Manager password at some point? >> >> > >> > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w >> > password -b "" -s base >> > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w >> > *********** -b "" -s base >> > Inline-Bild 2 >> >> You need the -x flag to indicate simple bind. >> >> rob >> >> > The logs have thousands of lines like it, what am I looking for >> > specifically? >> > >> > Daniel >> > >> > >> > 2016-12-20 4:18 GMT-06:00 Florence Blanc-Renaud > > >: >> > >> > On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote: >> > >> > Good day and happy holidays, >> > >> > I have been running a freeIPA instance for a few years and been >> very >> > happy. Recently the certificate expired and I updated it using >> the >> > documented methods. At first all seemed fine. Added a Nagios >> > monitor for >> > the certificate expiration and restarted the server (single >> > server). I >> > have weekly snapshots, daily backups (using Amanda on the entire >> > disk). >> > >> > One day the services relying on IPA failed to authenticate. >> > Looking at >> > the server the ipa service had stopped. Restarting the service >> > fails. >> > Restoring a few weeks old snapshot does not start either. >> > Resetting the >> > date to a few month back does not work either as httpd fails to >> > start . >> > >> > I am at a loss. >> > >> > Here a few details: >> > # ipa --version >> > VERSION: 4.4.0, API_VERSION: 2.213 >> > >> > >> > # /usr/sbin/ipactl start >> > ... >> > out -> Failed to start pki-tomcatd Service >> > /var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP >> server >> > host ipa.myorg.com > > >> > port 636 Error >> > netscape.ldap.LDAPException: Authentication failed (48) >> > 2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted >> > due to >> > error: Retrieving CA status failed with status 500 >> > >> > Any help would be appreciated as all connected services are now >> > down. >> > >> > Thanks, >> > >> > Daniel >> > >> > >> > >> > >> > Hi Daniel, >> > >> > more information would be required to understand what is going on. >> > First of all, which certificate did you renew? Can you check with >> > $ getcert list >> > if other certificates also expired? >> > >> > PKI fails to start and the error seems linked to the SSL connection >> > with the LDAP server. You may want to check if the LDAP server is >> > listening on the LDAPs port: >> > - start the stack with >> > $ ipactl start --force >> > - check the LDAPs port with >> > $ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w >> > password -b "" -s base >> > >> > The communication between PKI and the LDAP server is authenticated >> > with the certificate 'subsystemCert cert-pki-ca' located in >> > /etc/pki/pki-tomcat/alias, so you may also want to check if it is >> > still valid. >> > The directory server access logs (in >> > /var/log/dirsrv/slapd-DOMAIN-COM/access) would also show the >> > connection with logs similar to: >> > >> > [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to >> > 10.34.58.150 >> > [...] conn=47 TLS1.2 128-bit AES; client CN=CA >> > Subsystem,O=DOMAIN.COM ; issuer CN=Certificate >> > Authority,O=DOMAIN.COM >> > [...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipac >> a >> > [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL >> > [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 >> > dn="uid=pkidbuser,ou=people,o=ipaca" >> > >> > >> > >> > HTH, >> > Flo >> > >> > >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gparente at redhat.com Thu Dec 29 09:55:12 2016 From: gparente at redhat.com (German Parente) Date: Thu, 29 Dec 2016 10:55:12 +0100 Subject: [Freeipa-users] Can't create replica In-Reply-To: <4B2D52D4-6D5C-44D0-8D03-EC66F38DC57A@placeiq.com> References: <4B2D52D4-6D5C-44D0-8D03-EC66F38DC57A@placeiq.com> Message-ID: HI Jim, it's normal to have an entry "cn=replica" under your mapping tree. That does not mean that you are replicating. It means the database is "enabled" for replication. And as it enabled, it needs a "replicaid" in the topology that in your case is 40. You cannot clean this id. In ipa, main database and certificate database (ipaca backend) are enabled for replication even if there's only one node in the topology. Regarding the binddn's, the ones under "cn=replica" should be a superset of the ones included in your future replication agreements if you add a new node to the topology. You could manually remove nsDS5ReplicaBindDN values if you consider they are leftovers. Thanks and regards, German. On Wed, Dec 28, 2016 at 10:20 PM, Jim Richard wrote: > This pretty much describes my issue: > > https://access.redhat.com/solutions/136993 > > ipa-server.x86_64 3.0.0-50.el6.centos.3 > > But it?s a little more complicated than that. > > My goal at this point is just to get to one master with no replication, no > remnants of replication, no dangling this or that in either the the main > LDAP or the CA instance. > > But, I think I?ve hosed it up pretty good, all things replication that is. > > So there is only one live server now, sso-109.nym1.placeiq.net > > But in going through the steps in that article I noticed something strange. > > Notice the ReplicaBindDN principalname in the first command, that server > no longer exists > And notice the the ID, 40. Then look at the output from the next command. > > ID 40 is actually sso-109, am I reading that right?? > > and of course CLEANRUV40 gives "error 53 unwilling to perform? - which is > expected ?? I think, maybe I don?t know :( > > So uh, how do I un-F? myself here? > > Can I like manually delete that replication instance 40? > > If I?m saying, I just want one master, no replicas (will of course create > a replica once I?m sure my one master is squared away), should I be able to > get the db to a state with no nsDS5Replica entries? > > [root at sso-109:(NYM) slapd-PKI-IPA]$ ldapsearch -xLLL -D "cn=directory > manager" -W -s sub -b cn=config objectclass=nsds5replica > Enter LDAP Password: > dn: cn=replica,cn=dc\3Dplaceiq\2Cdc\3Dnet,cn=mapping tree,cn=config > cn: replica > nsDS5Flags: 1 > objectClass: top > objectClass: nsds5replica > objectClass: extensibleobject > nsDS5ReplicaType: 3 > nsDS5ReplicaRoot: dc=placeiq,dc=net > nsds5ReplicaLegacyConsumer: off > nsDS5ReplicaId: 40 > nsDS5ReplicaBindDN: cn=replication manager,cn=config > nsDS5ReplicaBindDN: krbprincipalname=ldap/sso-110. > nym1.placeiq.net at PLACEIQ.NET > > ,cn=services,cn=accounts,dc=placeiq,dc=net > nsState:: KAAAAAAAAADkKWRYAAAAAAAAAAAAAAAADwAAAAAAAAASAAAAAAAAAA== > nsDS5ReplicaName: 889b4308-86c311e6-95188dad-28da3cc2 > nsds5ReplicaChangeCount: 13615 > nsds5replicareapactive: 0 > > > > [root at sso-109:(NYM) slapd-PKI-IPA]$ ldapsearch -xLLL -D "cn=directory > manager" -W -b dc=placeiq,dc=net \ > > '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)( > objectclass=nstombstone))' > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > [root at sso-109:(NYM) slapd-PKI-IPA]$ ldapsearch -xLLL -D "cn=directory > manager" -W -b dc=placeiq,dc=net '(&(nsuniqueid=ffffffff- > ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' > Enter LDAP Password: > dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=placeiq,dc=net > objectClass: top > objectClass: nsTombstone > objectClass: extensibleobject > nsds50ruv: {replicageneration} 52b07d23000000040000 > nsds50ruv: {replica 40 ldap://sso-109.nym1.placeiq.net:389} > 57ede5500007002800 > 00 58642aad000100280000 > dc: placeiq > nsruvReplicaLastModified: {replica 40 ldap://sso-109.nym1.placeiq.net:389} > 586 > 42a9e > > > > > > > > > > > Jim Richard > > > > > SYSTEM ADMINISTRATOR III > *(646) 338-8905 <%28646%29%20338-8905> * > [image: PlaceIQ:Alibaba] > > > > > > > -- > Manage your subscription for 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 mbasti at redhat.com Thu Dec 29 11:30:28 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 29 Dec 2016 12:30:28 +0100 Subject: [Freeipa-users] Using Privacyidea with FreeIPA - part 1/n In-Reply-To: <8360m4z012.fsf@echidna.jochen.org> References: <8360m4z012.fsf@echidna.jochen.org> Message-ID: <87787381-0c70-8792-47ae-1ba0ae4ded4f@redhat.com> Hello, I have a few comments/questions related to HOTP inline On 28.12.2016 13:54, Jochen Hein wrote: > [ This mail sets the stage for more parts, which will get into technical > details. Comments or suggestions are welcome, possibly we should add > refined texts in the relevant wikis/documentations. - Jochen ] > > When I first looked at privacyidea I was quite unsure how it would > integrate into my existing network and what tokens and applications I > would use privacyidea for. After lots of thought and experiments I now > think I have a useful scenario to work with. I run a family network with > a local mail server (Kolab), webmail, ssh, and VPN access and think the > structure might also work for small or medium offices too. > > Originally I had the userstore in Kolab's LDAP server which I wanted > to use for more applications, e.g. Linux logins. pam_ldap and > pam_ldapd could access the userstore in LDAP, but require that the > server is available. How should that work for a roadwarrior setup? > I've found sssd, but never had time to play with it. So that idea > never got off the ground. > > Former tries with Kerberos/LDAP have not been successful, but once I > found FreeIPA[1] I was kind of hooked. FreeIPA has: > > - LDAP as backend (e.g. userstore) > - a versatile command line interface ("ipa") > - a useful web interface > - client software to join a Linux machine into the FreeIPA realm > - sssd for clients by default > - works "out of the box" > > If you need a central userstore with host based access control, SSO > and lots of other features - I can really recommend it. > > I'll discuss later, what features I use with which software and why. > > The latest FreeIPA version has some OTP features included, for example > Yubikeys or FreeOTP tokens. So, why would you want to use another OTP > provider than FreeIPA? I use (and plan to extend the usage) Yubikey > tokens. Since the Yubikeys only have two slots[2], we need to decide > what we want to use the slots for. > > I want to have the following applications running with my Yubikeys: > > - Second Factor for my keepass file > - Second Factor for login/ssh (later webmail access) > - Second Factor for sudo authentication > > I've settled for the following usage of the slots: > > * Slot 1: This is a (reprogrammed) Yubico-AES token, which > authenticates against Privacyides yubico mode instead of Yubicos > cloud server. > > Why Yubico and not HOTP or TOTP? > > Here FreeIPA fails for me: Yubikey can't do TOTP, HOTP token can get > out of sync, when we use them for local authentication, FreeIPA and > Kolab (each application has a count, which needs to be "in near > sync" with the counter in the Yubikey. I wouldn't trust such a > setup.) AFAIK this is security feature to have "Window of allowed tokens" and counter is essential for HOTP, https://tools.ietf.org/html/rfc4226#section-7.2 > > But providing access to a Yubico Token via privacyidea works for all > cases I have in mind. How they are checking the valid tokes if they don't use its counter? > > * Slot 2: Yubikey Challenge Response > > I use that as a second factor for my keepass file with > keechallenge. The second application is my LUKS encrypted Laptop with > privacyidea's privacyidea-luks-assign help. With pam_yubico I restrict > access to Laptops with a second factor, without the need for a central > authentication server[3]. For the laptops (local login) I skip > entering a sudo password when a yubico is present and authenticated. > > Since there is no token count, the token will not get > out of sync. > > For my local net u2f didn't seem useful, but I'll use it for remote > services. > > I consider that design more secure than using only a password, but > also more convenient. Let's see how far that will take us. > > [1] http://www.freeipa.org > [2] How does that relate to PIV, U2F, and smart card features? > [3] pam_python+privacyidea might help, but the packages are not in > distro repositories and even more of a niche product than pam_yubico. > > The rest of this series expects that the PI host is enrolled in IPA. > On Debian/Ubuntu systems, add the ca.crt to the local ca store: > > ln -s /etc/ipa/ca.crt /usr/local/share/ca-certificates update-ca-certificates > > From peter at pakos.uk Thu Dec 29 12:52:55 2016 From: peter at pakos.uk (Peter Pakos) Date: Thu, 29 Dec 2016 12:52:55 +0000 Subject: [Freeipa-users] Broken dirsrv and SSL certificate in CA-less install of FreeIPA 4.4 on CentOS 7.3 Message-ID: Hi guys, I'm facing yet another problem with CA-less install of FreeIPA replica and 3rd party SSL certificate. Few days ago I deployed a new CA-less server (ipa02) by running the following command: ipa-server-install \ > -r PAKOS.UK \ > -n pakos.uk \ > -p 'password' \ > -a 'password' \ > --mkhomedir \ > --setup-dns \ > --no-forwarders \ > --no-dnssec-validation \ > --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \ > --dirsrv-pin='' \ > --http-cert-file=/root/ssl/star.pakos.uk.pfx \ > --http-pin='' \ > --http-cert-name=AlphaWildcardIPA \ > --idstart=1000 This server appears to be working OK. Then yesterday I deployed a client (ipa01): ipa-client-install \ > -p admin \ > -w 'password' \ > --mkhomedir Next, I promoted it to IPA server: ipa-replica-install \ > -w 'password' \ > --mkhomedir \ > --setup-dns \ > --no-forwarders \ > --no-dnssec-validation \ > --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \ > --dirsrv-pin='' \ > --dirsrv-cert-name=AlphaWildcardIPA \ > --http-cert-file=/root/ssl/star.pakos.uk.pfx \ > --http-pin='' \ > --http-cert-name=AlphaWildcardIPA After it finished, I've noticed that dirsrv wasn't running on port 636 on ipa01. Further investigation revealed that the SSL wildcard certificate (AlphaWildcardIPA) wasn't installed in dirsrv DB and CA certificates were named oddly (CA 1 and CA 2): [root at ipa01 ~]# certutil -L -d /etc/httpd/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI AlphaWildcardIPA u,u,u CA 1 ,, CA 2 C,, [root at ipa01 ~]# certutil -L -d /etc/dirsrv/slapd-PAKOS-UK/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI GlobalSign Root CA - GlobalSign nv-sa ,, AlphaSSL CA - SHA256 - G2 - GlobalSign nv-sa C,, This is what I found in the error log: [29/Dec/2016:01:43:58.852745536 +0000] 389-Directory/1.3.5.10 B2016.341.2222 starting up [29/Dec/2016:01:43:58.867642515 +0000] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match [29/Dec/2016:01:43:58.889866051 +0000] schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup! [29/Dec/2016:01:43:58.905267535 +0000] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.907051833 +0000] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.908396407 +0000] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.909758735 +0000] NSACLPlugin - The ACL target ou=sudoers,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.911133739 +0000] NSACLPlugin - The ACL target cn=users,cn=compat,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.912416230 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.913644794 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.914901802 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.916158004 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.917409810 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.918636743 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.919904210 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.921175543 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.922417264 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.923818252 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.925218237 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.928474915 +0000] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.943158867 +0000] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.944679679 +0000] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:59.060335708 +0000] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [29/Dec/2016:01:43:59.066618653 +0000] Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pakos,dc=uk--no CoS Templates found, which should be added before the CoS Definition. [29/Dec/2016:01:43:59.100168779 +0000] schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds! [29/Dec/2016:01:43:59.108366423 +0000] slapd started. Listening on All Interfaces port 389 for LDAP requests [29/Dec/2016:01:43:59.109788596 +0000] Listening on /var/run/slapd-PAKOS-UK.socket for LDAPI requests [29/Dec/2016:01:44:04.117095313 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=pakos,dc=uk [29/Dec/2016:01:44:04.142962437 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=pakos,dc=uk [29/Dec/2016:01:44:04.164958006 +0000] schema-compat-plugin - Finished plugin initialization. [29/Dec/2016:01:44:20.113621699 +0000] ipa-topology-plugin - ipa_topo_util_get_replica_conf: server configuration missing [29/Dec/2016:01:44:20.115517170 +0000] ipa-topology-plugin - ipa_topo_util_get_replica_conf: cannot create replica At this point I trashed ipa01 and tried to re-deploy it again using the same commands. The install failed with the following error message: Done configuring directory server (dirsrv). Configuring ipa-custodia [1/4]: Generating ipa-custodia config file [2/4]: Generating ipa-custodia keys [3/4]: starting ipa-custodia [4/4]: configuring ipa-custodia to start on boot Done configuring ipa-custodia. Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds [1/4]: configuring KDC [2/4]: adding the password extension to the directory [3/4]: starting the KDC [4/4]: configuring KDC to start on boot Done configuring Kerberos KDC (krb5kdc). Configuring kadmin [1/2]: starting kadmin [2/2]: configuring kadmin to start on boot Done configuring kadmin. Configuring ipa_memcached [1/2]: starting ipa_memcached [2/2]: configuring ipa_memcached to start on boot Done configuring ipa_memcached. Configuring the web interface (httpd). Estimated time: 1 minute [1/19]: setting mod_nss port to 443 [2/19]: setting mod_nss cipher suite [3/19]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2 [4/19]: setting mod_nss password file [5/19]: enabling mod_nss renegotiate [6/19]: adding URL rewriting rules [7/19]: configuring httpd [8/19]: setting up httpd keytab [9/19]: setting up ssl [error] NotFound: no such entry Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR no such entry ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information Here's the full install log: https://files.pakos.uk/ipareplica-install.log.txt I've raised this problem on #freeipa channel (many thanks to mbasti and ab for their help in investigating this issue with me) however we didn't get too far and some further input from dirsrv gurus is required here. [root at ipa01 ipa]# echo $SERVICE HTTP/ipa01.pakos.uk at PAKOS.UK [root at ipa01 ipa]# echo $DN krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=pakos,dc=uk [root at ipa01 ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN -s sub Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # HTTP/ipa01.pakos.uk at PAKOS.UK, services, accounts, pakos.uk dn: krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=p akos,dc=uk krbExtraData:: AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= krbLastPwdChange: 20161229103250Z krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP LwmAX3lYm objectClass: ipaobject objectClass: ipaservice objectClass: krbticketpolicyaux objectClass: ipakrbprincipal objectClass: krbprincipal objectClass: krbprincipalaux objectClass: pkiuser objectClass: top ipaKrbPrincipalAlias: HTTP/ipa01.pakos.uk at PAKOS.UK krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK managedBy: fqdn=ipa01.pakos.uk,cn=computers,cn=accounts,dc=pakos,dc=uk krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK ipaUniqueID: 25dc5432-cdb2-11e6-a20e-005056a2f7f5 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at ipa01 ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN -s sub "krbprincipalname=*" Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: krbprincipalname=* # requesting: ALL # # HTTP/ipa01.pakos.uk at PAKOS.UK, services, accounts, pakos.uk dn: krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=p akos,dc=uk krbExtraData:: AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= krbLastPwdChange: 20161229103250Z krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP LwmAX3lYm objectClass: ipaobject objectClass: ipaservice objectClass: krbticketpolicyaux objectClass: ipakrbprincipal objectClass: krbprincipal objectClass: krbprincipalaux objectClass: pkiuser objectClass: top ipaKrbPrincipalAlias: HTTP/ipa01.pakos.uk at PAKOS.UK krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK managedBy: fqdn=ipa01.pakos.uk,cn=computers,cn=accounts,dc=pakos,dc=uk krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK ipaUniqueID: 25dc5432-cdb2-11e6-a20e-005056a2f7f5 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at ipa01 ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN -s sub "(objectclass=*)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # HTTP/ipa01.pakos.uk at PAKOS.UK, services, accounts, pakos.uk dn: krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=p akos,dc=uk krbExtraData:: AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= krbLastPwdChange: 20161229103250Z krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP LwmAX3lYm objectClass: ipaobject objectClass: ipaservice objectClass: krbticketpolicyaux objectClass: ipakrbprincipal objectClass: krbprincipal objectClass: krbprincipalaux objectClass: pkiuser objectClass: top ipaKrbPrincipalAlias: HTTP/ipa01.pakos.uk at PAKOS.UK krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK managedBy: fqdn=ipa01.pakos.uk,cn=computers,cn=accounts,dc=pakos,dc=uk krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK ipaUniqueID: 25dc5432-cdb2-11e6-a20e-005056a2f7f5 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at ipa01 ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN -s base Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: ALL # # HTTP/ipa01.pakos.uk at PAKOS.UK, services, accounts, pakos.uk dn: krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=p akos,dc=uk krbExtraData:: AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= krbLastPwdChange: 20161229103250Z krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP LwmAX3lYm objectClass: ipaobject objectClass: ipaservice objectClass: krbticketpolicyaux objectClass: ipakrbprincipal objectClass: krbprincipal objectClass: krbprincipalaux objectClass: pkiuser objectClass: top ipaKrbPrincipalAlias: HTTP/ipa01.pakos.uk at PAKOS.UK krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK managedBy: fqdn=ipa01.pakos.uk,cn=computers,cn=accounts,dc=pakos,dc=uk krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK ipaUniqueID: 25dc5432-cdb2-11e6-a20e-005056a2f7f5 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 I must say that this a show stopper for us at WANdisco which is holding back the upgrade from FreeIPA 4.2 to FreeIPA 4.4. If there is anything else I can do to help with the investigation, please just let me know. Many thanks in advance. -- Kind regards, Peter Pakos -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at pakos.uk Thu Dec 29 18:13:10 2016 From: peter at pakos.uk (Peter Pakos) Date: Thu, 29 Dec 2016 18:13:10 +0000 Subject: [Freeipa-users] Broken dirsrv and SSL certificate in CA-less install of FreeIPA 4.4 on CentOS 7.3 In-Reply-To: References: Message-ID: Access log: https://files.pakos.uk/access.txt Error log: https://files.pakos.uk/ipareplica-install.log.txt I hope it helps. On 29 December 2016 at 12:52, Peter Pakos wrote: > Hi guys, > > I'm facing yet another problem with CA-less install of FreeIPA replica and > 3rd party SSL certificate. > > Few days ago I deployed a new CA-less server (ipa02) by running the > following command: > > ipa-server-install \ >> -r PAKOS.UK \ >> -n pakos.uk \ >> -p 'password' \ >> -a 'password' \ >> --mkhomedir \ >> --setup-dns \ >> --no-forwarders \ >> --no-dnssec-validation \ >> --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \ >> --dirsrv-pin='' \ >> --http-cert-file=/root/ssl/star.pakos.uk.pfx \ >> --http-pin='' \ >> --http-cert-name=AlphaWildcardIPA \ >> --idstart=1000 > > > This server appears to be working OK. > > Then yesterday I deployed a client (ipa01): > > ipa-client-install \ >> -p admin \ >> -w 'password' \ >> --mkhomedir > > > Next, I promoted it to IPA server: > > ipa-replica-install \ >> -w 'password' \ >> --mkhomedir \ >> --setup-dns \ >> --no-forwarders \ >> --no-dnssec-validation \ >> --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \ >> --dirsrv-pin='' \ >> --dirsrv-cert-name=AlphaWildcardIPA \ >> --http-cert-file=/root/ssl/star.pakos.uk.pfx \ >> --http-pin='' \ >> --http-cert-name=AlphaWildcardIPA > > > After it finished, I've noticed that dirsrv wasn't running on port 636 on > ipa01. > > Further investigation revealed that the SSL wildcard certificate > (AlphaWildcardIPA) wasn't installed in dirsrv DB and CA certificates were > named oddly (CA 1 and CA 2): > > [root at ipa01 ~]# certutil -L -d /etc/httpd/alias/ > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > AlphaWildcardIPA u,u,u > CA 1 ,, > CA 2 C,, > > > [root at ipa01 ~]# certutil -L -d /etc/dirsrv/slapd-PAKOS-UK/ > > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > > GlobalSign Root CA - GlobalSign nv-sa ,, > AlphaSSL CA - SHA256 - G2 - GlobalSign nv-sa C,, > > > This is what I found in the error log: > > [29/Dec/2016:01:43:58.852745536 +0000] 389-Directory/1.3.5.10 B2016.341.2222 starting up > [29/Dec/2016:01:43:58.867642515 +0000] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match > [29/Dec/2016:01:43:58.889866051 +0000] schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup! > [29/Dec/2016:01:43:58.905267535 +0000] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.907051833 +0000] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.908396407 +0000] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.909758735 +0000] NSACLPlugin - The ACL target ou=sudoers,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.911133739 +0000] NSACLPlugin - The ACL target cn=users,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.912416230 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.913644794 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.914901802 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.916158004 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.917409810 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.918636743 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.919904210 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.921175543 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.922417264 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.923818252 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.925218237 +0000] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.928474915 +0000] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.943158867 +0000] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.944679679 +0000] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:59.060335708 +0000] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist > [29/Dec/2016:01:43:59.066618653 +0000] Skipping CoS Definition cn=Password Policy,cn=accounts,dc=pakos,dc=uk--no CoS Templates found, which should be added before the CoS Definition. > [29/Dec/2016:01:43:59.100168779 +0000] schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds! > [29/Dec/2016:01:43:59.108366423 +0000] slapd started. Listening on All Interfaces port 389 for LDAP requests > [29/Dec/2016:01:43:59.109788596 +0000] Listening on /var/run/slapd-PAKOS-UK.socket for LDAPI requests > [29/Dec/2016:01:44:04.117095313 +0000] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=pakos,dc=uk > [29/Dec/2016:01:44:04.142962437 +0000] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=pakos,dc=uk > [29/Dec/2016:01:44:04.164958006 +0000] schema-compat-plugin - Finished plugin initialization. > [29/Dec/2016:01:44:20.113621699 +0000] ipa-topology-plugin - ipa_topo_util_get_replica_conf: server configuration missing > [29/Dec/2016:01:44:20.115517170 +0000] ipa-topology-plugin - ipa_topo_util_get_replica_conf: cannot create replica > > > At this point I trashed ipa01 and tried to re-deploy it again using the > same commands. The install failed with the following error message: > > Done configuring directory server (dirsrv). > Configuring ipa-custodia > [1/4]: Generating ipa-custodia config file > [2/4]: Generating ipa-custodia keys > [3/4]: starting ipa-custodia > [4/4]: configuring ipa-custodia to start on boot > Done configuring ipa-custodia. > Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds > [1/4]: configuring KDC > [2/4]: adding the password extension to the directory > [3/4]: starting the KDC > [4/4]: configuring KDC to start on boot > Done configuring Kerberos KDC (krb5kdc). > Configuring kadmin > [1/2]: starting kadmin > [2/2]: configuring kadmin to start on boot > Done configuring kadmin. > Configuring ipa_memcached > [1/2]: starting ipa_memcached > [2/2]: configuring ipa_memcached to start on boot > Done configuring ipa_memcached. > Configuring the web interface (httpd). Estimated time: 1 minute > [1/19]: setting mod_nss port to 443 > [2/19]: setting mod_nss cipher suite > [3/19]: setting mod_nss protocol list to TLSv1.0 - TLSv1.2 > [4/19]: setting mod_nss password file > [5/19]: enabling mod_nss renegotiate > [6/19]: adding URL rewriting rules > [7/19]: configuring httpd > [8/19]: setting up httpd keytab > [9/19]: setting up ssl > [error] NotFound: no such entry > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > ipa.ipapython.install.cli.install_tool(Replica): ERROR no such entry > ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information > > Here's the full install log: https://files.pakos.uk/ > ipareplica-install.log.txt > > I've raised this problem on #freeipa channel (many thanks to mbasti and ab > for their help in investigating this issue with me) however we didn't get > too far and some further input from dirsrv gurus is required here. > > [root at ipa01 ipa]# echo $SERVICE > HTTP/ipa01.pakos.uk at PAKOS.UK > > [root at ipa01 ipa]# echo $DN > krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=pakos,dc=uk > > [root at ipa01 ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN -s sub > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # HTTP/ipa01.pakos.uk at PAKOS.UK, services, accounts, pakos.uk > dn: krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=p > akos,dc=uk > krbExtraData:: AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= > krbLastPwdChange: 20161229103250Z > krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 > NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq > a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 > pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP > LwmAX3lYm > objectClass: ipaobject > objectClass: ipaservice > objectClass: krbticketpolicyaux > objectClass: ipakrbprincipal > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: pkiuser > objectClass: top > ipaKrbPrincipalAlias: HTTP/ipa01.pakos.uk at PAKOS.UK > krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK > managedBy: fqdn=ipa01.pakos.uk,cn=computers,cn=accounts,dc=pakos,dc=uk > krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK > ipaUniqueID: 25dc5432-cdb2-11e6-a20e-005056a2f7f5 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > [root at ipa01 ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN -s sub "krbprincipalname=*" > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: krbprincipalname=* > # requesting: ALL > # > > # HTTP/ipa01.pakos.uk at PAKOS.UK, services, accounts, pakos.uk > dn: krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=p > akos,dc=uk > krbExtraData:: AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= > krbLastPwdChange: 20161229103250Z > krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 > NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq > a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 > pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP > LwmAX3lYm > objectClass: ipaobject > objectClass: ipaservice > objectClass: krbticketpolicyaux > objectClass: ipakrbprincipal > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: pkiuser > objectClass: top > ipaKrbPrincipalAlias: HTTP/ipa01.pakos.uk at PAKOS.UK > krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK > managedBy: fqdn=ipa01.pakos.uk,cn=computers,cn=accounts,dc=pakos,dc=uk > krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK > ipaUniqueID: 25dc5432-cdb2-11e6-a20e-005056a2f7f5 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > [root at ipa01 ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN -s sub "(objectclass=*)" > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # HTTP/ipa01.pakos.uk at PAKOS.UK, services, accounts, pakos.uk > dn: krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=p > akos,dc=uk > krbExtraData:: AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= > krbLastPwdChange: 20161229103250Z > krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 > NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq > a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 > pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP > LwmAX3lYm > objectClass: ipaobject > objectClass: ipaservice > objectClass: krbticketpolicyaux > objectClass: ipakrbprincipal > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: pkiuser > objectClass: top > ipaKrbPrincipalAlias: HTTP/ipa01.pakos.uk at PAKOS.UK > krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK > managedBy: fqdn=ipa01.pakos.uk,cn=computers,cn=accounts,dc=pakos,dc=uk > krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK > ipaUniqueID: 25dc5432-cdb2-11e6-a20e-005056a2f7f5 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > [root at ipa01 ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN -s base > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope baseObject > # filter: (objectclass=*) > # requesting: ALL > # > > # HTTP/ipa01.pakos.uk at PAKOS.UK, services, accounts, pakos.uk > dn: krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=p > akos,dc=uk > krbExtraData:: AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= > krbLastPwdChange: 20161229103250Z > krbPrincipalKey:: MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 > NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq > a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 > pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP > LwmAX3lYm > objectClass: ipaobject > objectClass: ipaservice > objectClass: krbticketpolicyaux > objectClass: ipakrbprincipal > objectClass: krbprincipal > objectClass: krbprincipalaux > objectClass: pkiuser > objectClass: top > ipaKrbPrincipalAlias: HTTP/ipa01.pakos.uk at PAKOS.UK > krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK > managedBy: fqdn=ipa01.pakos.uk,cn=computers,cn=accounts,dc=pakos,dc=uk > krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK > ipaUniqueID: 25dc5432-cdb2-11e6-a20e-005056a2f7f5 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > I must say that this a show stopper for us at WANdisco which is holding > back the upgrade from FreeIPA 4.2 to FreeIPA 4.4. > > If there is anything else I can do to help with the investigation, please > just let me know. > > Many thanks in advance. > > -- > Kind regards, > Peter Pakos > -- Kind regards, Peter Pakos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen at jochen.org Thu Dec 29 19:44:33 2016 From: jochen at jochen.org (Jochen Hein) Date: Thu, 29 Dec 2016 20:44:33 +0100 Subject: [Freeipa-users] Valid Sender ? - Re: Using Privacyidea with FreeIPA - part 1/n In-Reply-To: <87787381-0c70-8792-47ae-1ba0ae4ded4f@redhat.com> (Martin Basti's message of "Thu, 29 Dec 2016 12:30:28 +0100") References: <8360m4z012.fsf@echidna.jochen.org> <87787381-0c70-8792-47ae-1ba0ae4ded4f@redhat.com> Message-ID: <83r34qy0ym.fsf@echidna.jochen.org> Martin Basti writes: > Hello, I have a few comments/questions related to HOTP inline Sure :-) > On 28.12.2016 13:54, Jochen Hein wrote: >> >> I've settled for the following usage of the slots: >> >> * Slot 1: This is a (reprogrammed) Yubico-AES token, which >> authenticates against Privacyides yubico mode instead of Yubicos >> cloud server. >> >> Why Yubico and not HOTP or TOTP? >> >> Here FreeIPA fails for me: Yubikey can't do TOTP, HOTP token can get >> out of sync, when we use them for local authentication, FreeIPA and >> Kolab (each application has a count, which needs to be "in near >> sync" with the counter in the Yubikey. I wouldn't trust such a >> setup.) > > AFAIK this is security feature to have "Window of allowed tokens" and > counter is essential for HOTP, > https://tools.ietf.org/html/rfc4226#section-7.2 Exactly. So it seems essential for me, that only one system can be the owner of the token (has the secret and counter to check the validity of an OTP). This is for both HOTP and Yubico-AES (cloud validation). So at first they look more or less identical, but why did I choose Yubico? Two usecases for me will work with yubico-AES, but not easily with HOTP (or maybe as well...). First is Kolab, my mailserver. With the current (development) release I can use 2FA with HOTP/TOTP and yubico-AES. Kolab wants to be the owner of the HOTP/TOTP token, so the Yubikey couldn't be used for other applications. Right now there is no external validation for TOTP/HOTP implemented. But we can ask a yubico validation server (e.g. privacyidea) which is the owner of my yubico AES token. Second is pam_yubico, which asks my privacyidea server for validation. For HOTP is might be possible to use something like pam_googleauthenticator, but with Kolab I didn't see a solution. So, one yubikey is enrolled privacyidea and can be used by multiple applications with pam_yubico, yubico validation protocol and RADIUS, but the secret and counter is only stored in privacyidea... >> But providing access to a Yubico Token via privacyidea works for all >> cases I have in mind. > > How they are checking the valid tokes if they don't use its counter? Privacyidea is the "owner" of the token and has the secret and the counter stored. Every other system (e.g. pam_yubico or FreeIPA) is checking the validation against privacyiadea, either with the yubico protocol, the privacyidey validation, or RADIUS. Does this clarify the architecture of my system? Jochen -- The only problem with troubleshooting is that the trouble shoots back. From michael.plemmons at crosschx.com Thu Dec 29 21:48:06 2016 From: michael.plemmons at crosschx.com (Michael Plemmons) Date: Thu, 29 Dec 2016 16:48:06 -0500 Subject: [Freeipa-users] LDAP - Load Balancer - SSL cert with SAN Message-ID: I am trying to get FreeIPA LDAP to work when behind a load balancer and using SSL and I do not understand how I am supposed to get the server to use a certificate I created that has a SAN created. FreeIPA 4.4.0 on CentOS 7 Here is what I have: ipa-master.dev.crosschx.com - master ipa-replica.dev.crosschx.com - replica ipa.dev.crosschx.com - load balancer DNS name which point to the master and replica servers Here is what I have done. ipa host-add ipa.dev.crosschx.com --random --force ipa service-add --force ldap/ipa.dev.crosschx.com ipa service-add-host ldap/ipa.dev.crosschx.com --hosts={ ipa-master.dev.crosschx.com,ipa-replica.dev.crosschx.com} ipa service-allow-retrieve-keytab ldap/ipa.dev.crosschx.com --users=admin ipa-getcert request -d /etc/crosschx -n ipa-load-balancer -N "CN= ipa-master.dev.crosschx.com,O=DEV.CROSSCHX.COM" -D ipa.dev.crosschx.com -K ldap/ipa-master.dev.crosschx.com I can see the certificate is being monitored by IPA when I run ipa-getcert list but I am lost at the step to have this cert put into the database so that IPA will properly respond when I try to connect over LDAPS. I was testing the connection with the following command and I see the the ipa-master.dev cert being served. openssl s_client -connect ipa-master.dev.crosschx.com:636 -servername ipa.dev.crosschx.com Can you point me to the documentation I need to follow? Thank you. *Mike Plemmons | Senior DevOps Engineer | CROSSCHX* 614-741-5475 mike.plemmons at crosschx.com www.crosschx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Dec 30 10:54:28 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 30 Dec 2016 11:54:28 +0100 Subject: [Freeipa-users] Broken dirsrv and SSL certificate in CA-less install of FreeIPA 4.4 on CentOS 7.3 In-Reply-To: References: Message-ID: <1df7900c-e8bd-2f56-dd0d-9bf5d9f5fbe7@redhat.com> Hello, The first half of the first issue is this bug: https://fedorahosted.org/freeipa/ticket/6226 you have to enable SSL on server manually after installation The second half of the first issue shouldn't be related to ticket above, but I don't know more details I'll leave this for IPA CA gurus The second issue is unrelated to certificates, I believe that something in dirsrv causes this unusual behavior. I saw this before with other users. * both no such entry for HTTP principal, or for topology plugin are the same issue * all users have this issue with CA-less installation, but not always reproducible, I'm not sure if there can be a step in CA-less install that can cause this * entries are in database (were added previously by installer) but during installation the search failed with no such entry, ldapsearch after installation works * in access log SRCH is before ADD operation, but this is against the steps in installer, entry is added first and even installer failed hard so there is no way how to add it after failure caused by not found error. [29/Dec/2016:10:33:02.775715491 +0000] conn=16 op=1 SRCH base="krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=pakos,dc=uk" scope=0 filter="(objectClass=*)" attrs=ALL [29/Dec/2016:10:33:02.775892719 +0000] conn=16 op=1 RESULT err=32 tag=101 nentries=0 etime=0 This caused installation failure (IMO - there is no more SRCH operation for HTTP principal in log) ^^^^^^ ...... [29/Dec/2016:10:33:05.487917960 +0000] conn=17 op=10 ADD dn="krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=pakos,dc=uk" [29/Dec/2016:10:33:05.492213776 +0000] conn=17 op=10 RESULT err=0 tag=105 nentries=0 etime=0 csn=5864e653000000040000 [29/Dec/2016:10:33:05.492372184 +0000] conn=17 op=11 MOD dn="krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=pakos,dc=uk" [29/Dec/2016:10:33:05.494649080 +0000] conn=17 op=11 RESULT err=0 tag=103 nentries=0 etime=0 csn=5864e653000100040000 [29/Dec/2016:10:33:05.494816357 +0000] conn=17 op=12 MOD dn="krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK,cn=services,cn=accounts,dc=pakos,dc=uk" These were added after failure ??? ^^^^^ I need a DS guru assistance to resolve this :) Martin^2 On 29.12.2016 19:13, Peter Pakos wrote: > Access log: https://files.pakos.uk/access.txt > Error log: https://files.pakos.uk/ipareplica-install.log.txt > I hope it helps. > On 29 December 2016 at 12:52, Peter Pakos > wrote: > > Hi guys, > I'm facing yet another problem with CA-less install of FreeIPA > replica and 3rd party SSL certificate. > Few days ago I deployed a new CA-less server (ipa02) by running > the following command: > > ipa-server-install \ -r PAKOS.UK \ -n > pakos.uk \ -p 'password' \ -a 'password' > \ --mkhomedir \ --setup-dns \ --no-forwarders \ > --no-dnssec-validation \ > --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \ > --dirsrv-pin='' \ > --http-cert-file=/root/ssl/star.pakos.uk.pfx \ --http-pin='' > \ --http-cert-name=AlphaWildcardIPA \ --idstart=1000 > > This server appears to be working OK. > Then yesterday I deployed a client (ipa01): > > ipa-client-install \ -p admin \ -w 'password' \ --mkhomedir > > Next, I promoted it to IPA server: > > ipa-replica-install \ -w 'password' \ --mkhomedir \ > --setup-dns \ --no-forwarders \ --no-dnssec-validation \ > --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \ > --dirsrv-pin='' \ --dirsrv-cert-name=AlphaWildcardIPA \ > --http-cert-file=/root/ssl/star.pakos.uk.pfx \ --http-pin='' > \ --http-cert-name=AlphaWildcardIPA > > After it finished, I've noticed that dirsrv wasn't running on port > 636 on ipa01. > Further investigation revealed that the SSL wildcard certificate > (AlphaWildcardIPA) wasn't installed in dirsrv DB and CA > certificates were named oddly (CA 1 and CA 2): > > [root at ipa01 ~]# certutil -L -d /etc/httpd/alias/ Certificate > Nickname Trust Attributes SSL,S/MIME,JAR/XPI AlphaWildcardIPA > u,u,u CA 1 ,, CA 2 C,, [root at ipa01 ~]# certutil -L -d > /etc/dirsrv/slapd-PAKOS-UK/ Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI GlobalSign Root CA - GlobalSign nv-sa ,, > AlphaSSL CA - SHA256 - G2 - GlobalSign nv-sa C,, > > This is what I found in the error log: > > [29/Dec/2016:01:43:58.852745536 +0000] 389-Directory/1.3.5.10 > B2016.341.2222 starting up > [29/Dec/2016:01:43:58.867642515 +0000] default_mr_indexer_create: > warning - plugin [caseIgnoreIA5Match] does not handle > caseExactIA5Match [29/Dec/2016:01:43:58.889866051 +0000] > schema-compat-plugin - scheduled schema-compat-plugin tree scan in > about 5 seconds after the server startup! > [29/Dec/2016:01:43:58.905267535 +0000] NSACLPlugin - The ACL > target cn=groups,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.907051833 +0000] NSACLPlugin - The ACL > target cn=computers,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.908396407 +0000] NSACLPlugin - The ACL > target cn=ng,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.909758735 +0000] NSACLPlugin - The ACL > target ou=sudoers,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.911133739 +0000] NSACLPlugin - The ACL > target cn=users,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.912416230 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.913644794 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.914901802 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.916158004 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.917409810 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.918636743 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.919904210 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.921175543 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.922417264 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.923818252 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.925218237 +0000] NSACLPlugin - The ACL > target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.928474915 +0000] NSACLPlugin - The ACL > target cn=ad,cn=etc,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.943158867 +0000] NSACLPlugin - The ACL > target cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pakos,dc=uk does not > exist [29/Dec/2016:01:43:58.944679679 +0000] NSACLPlugin - The ACL > target cn=casigningcert > cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pakos,dc=uk does not > exist [29/Dec/2016:01:43:59.060335708 +0000] NSACLPlugin - The ACL > target cn=automember rebuild membership,cn=tasks,cn=config does > not exist [29/Dec/2016:01:43:59.066618653 +0000] Skipping CoS > Definition cn=Password Policy,cn=accounts,dc=pakos,dc=uk--no CoS > Templates found, which should be added before the CoS Definition. > [29/Dec/2016:01:43:59.100168779 +0000] schema-compat-plugin - > schema-compat-plugin tree scan will start in about 5 seconds! > [29/Dec/2016:01:43:59.108366423 +0000] slapd started. Listening on > All Interfaces port 389 for LDAP requests > [29/Dec/2016:01:43:59.109788596 +0000] Listening on > /var/run/slapd-PAKOS-UK.socket for LDAPI requests > [29/Dec/2016:01:44:04.117095313 +0000] schema-compat-plugin - > warning: no entries set up under cn=ng, cn=compat,dc=pakos,dc=uk > [29/Dec/2016:01:44:04.142962437 +0000] schema-compat-plugin - > warning: no entries set up under cn=computers, > cn=compat,dc=pakos,dc=uk [29/Dec/2016:01:44:04.164958006 +0000] > schema-compat-plugin - Finished plugin initialization. > [29/Dec/2016:01:44:20.113621699 +0000] ipa-topology-plugin - > ipa_topo_util_get_replica_conf: server configuration missing > [29/Dec/2016:01:44:20.115517170 +0000] ipa-topology-plugin - > ipa_topo_util_get_replica_conf: cannot create replica > > At this point I trashed ipa01 and tried to re-deploy it again > using the same commands. The install failed with the following > error message: > > Done configuring directory server (dirsrv). Configuring > ipa-custodia [1/4]: Generating ipa-custodia config file [2/4]: > Generating ipa-custodia keys [3/4]: starting ipa-custodia [4/4]: > configuring ipa-custodia to start on boot Done configuring > ipa-custodia. Configuring Kerberos KDC (krb5kdc). Estimated time: > 30 seconds [1/4]: configuring KDC [2/4]: adding the password > extension to the directory [3/4]: starting the KDC [4/4]: > configuring KDC to start on boot Done configuring Kerberos KDC > (krb5kdc). Configuring kadmin [1/2]: starting kadmin [2/2]: > configuring kadmin to start on boot Done configuring kadmin. > Configuring ipa_memcached [1/2]: starting ipa_memcached [2/2]: > configuring ipa_memcached to start on boot Done configuring > ipa_memcached. Configuring the web interface (httpd). Estimated > time: 1 minute [1/19]: setting mod_nss port to 443 [2/19]: setting > mod_nss cipher suite [3/19]: setting mod_nss protocol list to > TLSv1.0 - TLSv1.2 [4/19]: setting mod_nss password file [5/19]: > enabling mod_nss renegotiate [6/19]: adding URL rewriting rules > [7/19]: configuring httpd [8/19]: setting up httpd keytab [9/19]: > setting up ssl [error] NotFound: no such entry Your system may be > partly configured. Run /usr/sbin/ipa-server-install --uninstall to > clean up. ipa.ipapython.install.cli.install_tool(Replica): ERROR > no such entry ipa.ipapython.install.cli.install_tool(Replica): > ERROR The ipa-replica-install command failed. See > /var/log/ipareplica-install.log for more information > > Here's the full install log: > https://files.pakos.uk/ipareplica-install.log.txt > > I've raised this problem on #freeipa channel (many thanks to > mbasti and ab for their help in investigating this issue with me) > however we didn't get too far and some further input from dirsrv > gurus is required here. > > [root at ipa01 ipa]# echo $SERVICE HTTP/ipa01.pakos.uk at PAKOS.UK > [root at ipa01 ipa]# echo $DN > krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK > ,cn=services,cn=accounts,dc=pakos,dc=uk > [root at ipa01 ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN > -s sub Enter LDAP Password: # extended LDIF # # LDAPv3 # base > ,cn=services,cn=accounts,dc=pakos,dc=uk> > with scope subtree # filter: (objectclass=*) # requesting: ALL # # > HTTP/ipa01.pakos.uk at PAKOS.UK , > services, accounts, pakos.uk dn: > krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK > ,cn=services,cn=accounts,dc=p > akos,dc=uk krbExtraData:: > AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= krbLastPwdChange: > 20161229103250Z krbPrincipalKey:: > MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 > NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq > a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 > pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP > LwmAX3lYm objectClass: ipaobject objectClass: ipaservice > objectClass: krbticketpolicyaux objectClass: ipakrbprincipal > objectClass: krbprincipal objectClass: krbprincipalaux > objectClass: pkiuser objectClass: top ipaKrbPrincipalAlias: > HTTP/ipa01.pakos.uk at PAKOS.UK > krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK > managedBy: fqdn=ipa01.pakos.uk > ,cn=computers,cn=accounts,dc=pakos,dc=uk > krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK > ipaUniqueID: > 25dc5432-cdb2-11e6-a20e-005056a2f7f5 # search result search: 2 > result: 0 Success # numResponses: 2 # numEntries: 1 [root at ipa01 > ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN -s sub > "krbprincipalname=*" Enter LDAP Password: # extended LDIF # # > LDAPv3 # base ,cn=services,cn=accounts,dc=pakos,dc=uk> > with scope subtree # filter: krbprincipalname=* # requesting: ALL > # # HTTP/ipa01.pakos.uk at PAKOS.UK , > services, accounts, pakos.uk dn: > krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK > ,cn=services,cn=accounts,dc=p > akos,dc=uk krbExtraData:: > AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= krbLastPwdChange: > 20161229103250Z krbPrincipalKey:: > MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 > NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq > a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 > pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP > LwmAX3lYm objectClass: ipaobject objectClass: ipaservice > objectClass: krbticketpolicyaux objectClass: ipakrbprincipal > objectClass: krbprincipal objectClass: krbprincipalaux > objectClass: pkiuser objectClass: top ipaKrbPrincipalAlias: > HTTP/ipa01.pakos.uk at PAKOS.UK > krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK > managedBy: fqdn=ipa01.pakos.uk > ,cn=computers,cn=accounts,dc=pakos,dc=uk > krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK > ipaUniqueID: > 25dc5432-cdb2-11e6-a20e-005056a2f7f5 # search result search: 2 > result: 0 Success # numResponses: 2 # numEntries: 1 [root at ipa01 > ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN -s sub > "(objectclass=*)" Enter LDAP Password: # extended LDIF # # LDAPv3 > # base ,cn=services,cn=accounts,dc=pakos,dc=uk> > with scope subtree # filter: (objectclass=*) # requesting: ALL # # > HTTP/ipa01.pakos.uk at PAKOS.UK , > services, accounts, pakos.uk dn: > krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK > ,cn=services,cn=accounts,dc=p > akos,dc=uk krbExtraData:: > AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= krbLastPwdChange: > 20161229103250Z krbPrincipalKey:: > MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 > NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq > a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 > pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP > LwmAX3lYm objectClass: ipaobject objectClass: ipaservice > objectClass: krbticketpolicyaux objectClass: ipakrbprincipal > objectClass: krbprincipal objectClass: krbprincipalaux > objectClass: pkiuser objectClass: top ipaKrbPrincipalAlias: > HTTP/ipa01.pakos.uk at PAKOS.UK > krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK > managedBy: fqdn=ipa01.pakos.uk > ,cn=computers,cn=accounts,dc=pakos,dc=uk > krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK > ipaUniqueID: > 25dc5432-cdb2-11e6-a20e-005056a2f7f5 # search result search: 2 > result: 0 Success # numResponses: 2 # numEntries: 1 > > [root at ipa01 ipa]# ldapsearch -D "cn=Directory Manager" -W -b $DN > -s base Enter LDAP Password: # extended LDIF # # LDAPv3 # base > ,cn=services,cn=accounts,dc=pakos,dc=uk> > with scope baseObject # filter: (objectclass=*) # requesting: ALL > # # HTTP/ipa01.pakos.uk at PAKOS.UK , > services, accounts, pakos.uk dn: > krbprincipalname=HTTP/ipa01.pakos.uk at PAKOS.UK > ,cn=services,cn=accounts,dc=p > akos,dc=uk krbExtraData:: > AAJS5mRYSFRUUC9pcGEwMS5wYWtvcy51a0BQQUtPUy5VSwA= krbLastPwdChange: > 20161229103250Z krbPrincipalKey:: > MIHeoAMCAQGhAwIBAaIDAgEBowMCAQGkgccwgcQwaKAbMBmgAwIBBKESBBB5 > NUQyJVZFPGYyMTZAUU0+oUkwR6ADAgESoUAEPiAA1r2NfOUD/7xph6tSb4hg/nTOwIVYhOusG/omq > a1qMz/ZVA/nn4pct9yNwFxKUGOFOz1suDz0l2Rur2vUMFigGzAZoAMCAQShEgQQOiQnZGE8Nk93V3 > pvJSRLVaE5MDegAwIBEaEwBC4QAJbWI/ipYCPMu9I/jUqL39P0a9WHq8BdW2kpY9kYqsoy7D+A3fP > LwmAX3lYm objectClass: ipaobject objectClass: ipaservice > objectClass: krbticketpolicyaux objectClass: ipakrbprincipal > objectClass: krbprincipal objectClass: krbprincipalaux > objectClass: pkiuser objectClass: top ipaKrbPrincipalAlias: > HTTP/ipa01.pakos.uk at PAKOS.UK > krbCanonicalName: HTTP/ipa01.pakos.uk at PAKOS.UK > managedBy: fqdn=ipa01.pakos.uk > ,cn=computers,cn=accounts,dc=pakos,dc=uk > krbPrincipalName: HTTP/ipa01.pakos.uk at PAKOS.UK > ipaUniqueID: > 25dc5432-cdb2-11e6-a20e-005056a2f7f5 # search result search: 2 > result: 0 Success # numResponses: 2 # numEntries: 1 > > I must say that this a show stopper for us at WANdisco which is > holding back the upgrade from FreeIPA 4.2 to FreeIPA 4.4. > If there is anything else I can do to help with the investigation, > please just let me know. > Many thanks in advance. > -- > Kind regards, > Peter Pakos > > -- > Kind regards, > Peter Pakos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apeddire at redhat.com Fri Dec 30 15:39:30 2016 From: apeddire at redhat.com (Abhinay Reddy Peddireddy) Date: Fri, 30 Dec 2016 21:09:30 +0530 Subject: [Freeipa-users] Authentication Pop-up appearing for IPA WebUI Message-ID: Hello Team, I have a customer testing IPA on RHEL 7. When he tries to access the WebUI, it prompts for the username and password as a pop-up as shown in the below attached image. This happens with Google Chrome and Internet Explorer only. But it appears normal in Firefox. Customer is expecting a normal authentication prompt. Is this something to be checked from IPA end. I hope this has to be corrected or modified from browser end. Any suggestions ? Thanks and Regards, Abhinay Reddy. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture.PNG Type: image/png Size: 293402 bytes Desc: not available URL: From brian at interlinx.bc.ca Fri Dec 30 14:30:15 2016 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Fri, 30 Dec 2016 09:30:15 -0500 Subject: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'} In-Reply-To: <7d7c9cfb-c580-deec-3845-f7c8e97986bf@redhat.com> References: <1481946787.11959.7.camel@interlinx.bc.ca> <1481999421.11959.23.camel@interlinx.bc.ca> <9efb76bf-524e-6f3f-64e3-27e1d12b83d1@redhat.com> <1482149965.28211.15.camel@interlinx.bc.ca> <1482179085.28211.36.camel@interlinx.bc.ca> <1482234065.28211.55.camel@interlinx.bc.ca> <89d5a584-ad8f-a022-65a9-0fff1e0d6ea5@redhat.com> <1482321907.28211.102.camel@interlinx.bc.ca> <1482332011.25536.2.camel@interlinx.bc.ca> <1482344567.7132.10.camel@interlinx.bc.ca> <7d7c9cfb-c580-deec-3845-f7c8e97986bf@redhat.com> Message-ID: <1483108215.24007.143.camel@interlinx.bc.ca> [ Sent just to the list. Hopefully Martin is on it. ] On Thu, 2016-12-22 at 10:06 +0100, Martin Babinsky wrote: > > Hi Brian, Hi Martin, > DS should use /etc/sysconfig/dirsrv to set its KRB5_KTNAME env > variable? > to /etc/dirsrv/ds.keytab. Ah-ha! This was the problem. When I upgraded from 4.2 to 4.4 as part of my CentOS upgrade I pulled up the config file changes (i.e. those usually in .rpmnew file) because I like to keep the config files up-to-date with the package. But when I did so, the KRB5_KTNAME setting got dropped. :-( > Can you please verify that /etc/sysconfig/dirsrv file exists and that > it? > contains the following lines?: > > KRB5_CCNAME=/tmp/krb5cc_389 This is actually KRB5CCNAME in my config file. > KRB5_KTNAME=/etc/dirsrv/ds.keytab > > > If not, please add this line to the file, restart dirsrv and try IPA? > commands again. That worked. Thanks so much! Cheers, b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part URL: From marc.boorshtein at tremolosecurity.com Fri Dec 30 16:35:18 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Fri, 30 Dec 2016 16:35:18 +0000 Subject: [Freeipa-users] Authentication Pop-up appearing for IPA WebUI In-Reply-To: References: Message-ID: it looks like you are using chrome? we have a customer with a similar issue. Chrome doesn't follow the specs around kerberos, if it receives a 401 it will generally prompt you even if you are not a member of a domain. My guess is if you try it with Firefox or IE you should be fine and not get the prompt. On Fri, Dec 30, 2016 at 10:52 AM Abhinay Reddy Peddireddy < apeddire at redhat.com> wrote: > Hello Team, > > I have a customer testing IPA on RHEL 7. > > When he tries to access the WebUI, it prompts for the username and > password as a pop-up as shown in the below attached image. > > This happens with Google Chrome and Internet Explorer only. But it appears > normal in Firefox. > > Customer is expecting a normal authentication prompt. Is this something to > be checked from IPA end. I hope this has to be corrected or modified from > browser end. > > Any suggestions ? > > Thanks and Regards, > Abhinay Reddy. > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 Twitter - @mlbiam / @tremolosecurity -------------- next part -------------- An HTML attachment was scrubbed... URL: From apeddire at redhat.com Fri Dec 30 16:49:30 2016 From: apeddire at redhat.com (Abhinay Reddy Peddireddy) Date: Fri, 30 Dec 2016 22:19:30 +0530 Subject: [Freeipa-users] Authentication Pop-up appearing for IPA WebUI In-Reply-To: References: Message-ID: Hi, Yes. It is fine with Firefox. But not with chrome. However customer is expecting the same on Chrome also. Ant modifications can be done to avoid the pop-up ? On Fri, Dec 30, 2016 at 10:05 PM, Marc Boorshtein < marc.boorshtein at tremolosecurity.com> wrote: > it looks like you are using chrome? we have a customer with a similar > issue. Chrome doesn't follow the specs around kerberos, if it receives a > 401 it will generally prompt you even if you are not a member of a domain. > My guess is if you try it with Firefox or IE you should be fine and not get > the prompt. > > On Fri, Dec 30, 2016 at 10:52 AM Abhinay Reddy Peddireddy < > apeddire at redhat.com> wrote: > >> Hello Team, >> >> I have a customer testing IPA on RHEL 7. >> >> When he tries to access the WebUI, it prompts for the username and >> password as a pop-up as shown in the below attached image. >> >> This happens with Google Chrome and Internet Explorer only. But it >> appears normal in Firefox. >> >> Customer is expecting a normal authentication prompt. Is this something >> to be checked from IPA end. I hope this has to be corrected or modified >> from browser end. >> >> Any suggestions ? >> >> Thanks and Regards, >> Abhinay Reddy. >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project > > -- > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 > Twitter - @mlbiam / @tremolosecurity > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.boorshtein at tremolosecurity.com Fri Dec 30 16:55:34 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Fri, 30 Dec 2016 16:55:34 +0000 Subject: [Freeipa-users] Authentication Pop-up appearing for IPA WebUI In-Reply-To: References: Message-ID: Not in chrome. If you don't want kerberos at all for the console you could try disabling it in Apache but that will break with every update to ipa On Fri, Dec 30, 2016, 11:49 AM Abhinay Reddy Peddireddy wrote: > Hi, > > Yes. It is fine with Firefox. But not with chrome. > > However customer is expecting the same on Chrome also. > > Ant modifications can be done to avoid the pop-up ? > > On Fri, Dec 30, 2016 at 10:05 PM, Marc Boorshtein < > marc.boorshtein at tremolosecurity.com> wrote: > > it looks like you are using chrome? we have a customer with a similar > issue. Chrome doesn't follow the specs around kerberos, if it receives a > 401 it will generally prompt you even if you are not a member of a domain. > My guess is if you try it with Firefox or IE you should be fine and not get > the prompt. > > On Fri, Dec 30, 2016 at 10:52 AM Abhinay Reddy Peddireddy < > apeddire at redhat.com> wrote: > > Hello Team, > > I have a customer testing IPA on RHEL 7. > > When he tries to access the WebUI, it prompts for the username and > password as a pop-up as shown in the below attached image. > > This happens with Google Chrome and Internet Explorer only. But it appears > normal in Firefox. > > Customer is expecting a normal authentication prompt. Is this something to > be checked from IPA end. I hope this has to be corrected or modified from > browser end. > > Any suggestions ? > > Thanks and Regards, > Abhinay Reddy. > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > > -- > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > (703) 828-4902 > Twitter - @mlbiam / @tremolosecurity > > > -- Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com (703) 828-4902 Twitter - @mlbiam / @tremolosecurity -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomek at pipebreaker.pl Fri Dec 30 17:06:19 2016 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Fri, 30 Dec 2016 18:06:19 +0100 Subject: [Freeipa-users] Authentication Pop-up appearing for IPA WebUI In-Reply-To: References: Message-ID: <20161230170619.GB150117@mother.pipebreaker.pl> On Fri, Dec 30, 2016 at 10:19:30PM +0530, Abhinay Reddy Peddireddy wrote: > Hi, > > Yes. It is fine with Firefox. But not with chrome. > > However customer is expecting the same on Chrome also. > > Ant modifications can be done to avoid the pop-up ? See https://fedorahosted.org/freeipa/ticket/5614 and https://github.com/modauthgssapi/mod_auth_gssapi/pull/65 , setting ?GssapiNegotiateOnce? looks relevant. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzichubg at chrome.pl -- Baron Vladimir Harkonnen From outbackdingo at gmail.com Sat Dec 31 03:08:44 2016 From: outbackdingo at gmail.com (Outback Dingo) Date: Fri, 30 Dec 2016 22:08:44 -0500 Subject: [Freeipa-users] DNS wildcards record for domain Message-ID: a bit at a loss here, whats the proper way to add a DNS wildcard for a domain name to resolve to www.acmewidgets.com if someone type just the domain acmewigets.com in a browser ? From pgb205 at yahoo.com Sat Dec 31 07:43:20 2016 From: pgb205 at yahoo.com (pgb205) Date: Sat, 31 Dec 2016 07:43:20 +0000 (UTC) Subject: [Freeipa-users] Unable to sudo with just one user on only a few servers References: <204372224.4103019.1483170200550.ref@mail.yahoo.com> Message-ID: <204372224.4103019.1483170200550@mail.yahoo.com> I have followed troubleshooting procedure outlined hereTroubleshooting - FreeIPA | | | | | | | | | | | Troubleshooting - FreeIPA | | | | Additionally I have done contrast and compare with a working server for the following files/etc/hosts/etc/resolv.conf/etc/sudo-ldap.conf/etc/krb5.conf/etc/sssd.conf/etc/nssswitch.conf all are identical other than host specific information. In addition I have also enabled debug_level in sssd.conf in all stanzas, but noticed that sudo log is not being generated.I can however provide other logs. I have also enabled sudo_debug=2 in /etc/sudo-ldap.confbut not sure where to look for that log file. A and PTR records exist for problematic servers in FreeIPA DNS. As mentioned above the user-id can ?ssh just fine but not sudo for any command even though that id should be able to do ANY ANY. I have checked the the user-id is in the correct sudo groups that are applied for the host-groups for broken servers. To add to the oddity we somehow managed to fix the problem on several servers but as it was a lot blind trial and error we are not surewhat the corrective steps actually were.? Please let me know what else I can/should take a look at. I can also provide logs if needed. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at schimpfoessl.com Sat Dec 31 18:51:25 2016 From: daniel at schimpfoessl.com (Daniel Schimpfoessl) Date: Sat, 31 Dec 2016 12:51:25 -0600 Subject: [Freeipa-users] Asking for help with crashed freeIPA istance In-Reply-To: References: <729a8aed-4f22-ba26-3089-58c675bd64e0@redhat.com> <585A9F46.7080207@redhat.com> Message-ID: Further attempts to fix the IPA server start has revealed that the ca admin getStatus is returning a server error (500). This has come up during restarts and ipa-server-upgrade. ipa: DEBUG: Waiting for CA to start... ipa: DEBUG: request POST http://wwgwho01.webwim.com: 8080/ca/admin/ca/getStatus ipa: DEBUG: request body '' ipa: DEBUG: response status 500 ipa: DEBUG: response headers {'content-length': '2133', 'content-language': 'en', 'server': 'Apache-Coyote/1.1', 'connection': 'close', 'date': 'Sat, 31 Dec 2016 18:44:55 GMT', 'content-type': 'text/html;charset=utf-8'} ipa: DEBUG: response body 'Apache Tomcat/7.0.69 - Error report

HTTP Status 500 - Subsystem unavailable

type Exception report

message Subsystem unavailable

description The server encountered an internal error that prevented it from fulfilling this request.

exception 

javax.ws.rs.ServiceUnavailableException:
Subsystem unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.
findSecurityConstraints(ProxyRealm.java:145)\n\torg.
apache.catalina.authenticator.AuthenticatorBase.invoke(
AuthenticatorBase.java:499)\n\torg.apache.catalina.valves.
ErrorReportValve.invoke(ErrorReportValve.java:103)\n\torg.apache.catalina.
connector.CoyoteAdapter.service(CoyoteAdapter.java:
436)\n\torg.apache.coyote.http11.AbstractHttp11Processor.process(
AbstractHttp11Processor.java:1078)\n\torg.apache.coyote.AbstractProtocol$
AbstractConnectionHandler.process(AbstractProtocol.java:
625)\n\torg.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(
JIoEndpoint.java:316)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(
ThreadPoolExecutor.java:1142)\n\tjava.util.concurrent.
ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\
n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(
TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:745)\n

note The full stack trace of the root cause is available in the Apache Tomcat/7.0.69 logs.

Apache Tomcat/7.0.69

' ipa: DEBUG: The CA status is: check interrupted due to error: Retrieving CA status failed with status 500 ipa: DEBUG: Waiting for CA to start... ipa: DEBUG: request POST http://wwgwho01.webwim.com:8080/ca/admin/ca/getStatus ipa: DEBUG: request body '' ipa: DEBUG: response status 500 ipa: DEBUG: response headers {'content-length': '2133', 'content-language': 'en', 'server': 'Apache-Coyote/1.1', 'connection': 'close', 'date': 'Sat, 31 Dec 2016 18:44:56 GMT', 'content-type': 'text/html;charset=utf-8'} ipa: DEBUG: response body 'Apache Tomcat/7.0.69 - Error report

HTTP Status 500 - Subsystem unavailable

type Exception report

message Subsystem unavailable

description The server encountered an internal error that prevented it from fulfilling this request.

exception 

javax.ws.rs.ServiceUnavailableException: Subsystem
unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:145)\n\torg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:499)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)\n\torg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)\n\torg.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)\n\torg.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:745)\n

note The full stack trace of the root cause is available in the Apache Tomcat/7.0.69 logs.

Apache Tomcat/7.0.69

' ipa: DEBUG: The CA status is: check interrupted due to error: Retrieving CA status failed with status 500 ipa: DEBUG: Waiting for CA to start... ipa.ipaserver.install.ipa_server_upgrade.ServerUpgrade: ERROR: IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. ipa.ipaserver.install.ipa_server_upgrade.ServerUpgrade: DEBUG: File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 48, in run raise admintool.ScriptError(str(e)) ipa.ipaserver.install.ipa_server_upgrade.ServerUpgrade: DEBUG: The ipa-server-upgrade command failed, exception: ScriptError: CA did not start in 300.0s ipa.ipaserver.install.ipa_server_upgrade.ServerUpgrade: ERROR: CA did not start in 300.0s ipa.ipaserver.install.ipa_server_upgrade.ServerUpgrade: ERROR: The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information with following in the syslog Dec 31, 2016 12:48:51 PM org.apache.catalina.core.ContainerBase backgroundProcess WARNING: Exception processing realm com.netscape.cms.tomcat. ProxyRealm at 38406d47 background process javax.ws.rs.ServiceUnavailableException: Subsystem unavailable at com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) at org.apache.catalina.core.ContainerBase.backgroundProcess( ContainerBase.java:1357) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor. processChildren(ContainerBase.java:1543) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor. processChildren(ContainerBase.java:1553) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor. processChildren(ContainerBase.java:1553) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor. run(ContainerBase.java:1521) at java.lang.Thread.run(Thread.java:745) 2016-12-28 18:45 GMT-06:00 Daniel Schimpfoessl : > Rob/Florence, > > do you have any pointers on how to troubleshoot, reinstall/configure, > update or fix the PKI server to function properly? > Also if you know of any documentation or video that could be helpful. > I researched the typical suspects youtube and freeipa.org without luck. > > Daniel > > 2016-12-22 18:08 GMT-06:00 Daniel Schimpfoessl : > >> I do not believe I changed the DM password. I know I had to update the >> admin passwords regularly. >> >> Only during the startup using ipactl start --force I am able to connect >> to the service using the password for DM and it returns: >> >> # extended LDIF >> # >> # LDAPv3 >> # base <> with scope baseObject >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # >> dn: >> objectClass: top >> namingContexts: cn=changelog >> namingContexts: dc=myorg,dc=com >> namingContexts: o=ipaca >> defaultnamingcontext: dc=myorg,dc=com >> supportedExtension: 2.16.840.1.113730.3.5.7 >> supportedExtension: 2.16.840.1.113730.3.5.8 >> supportedExtension: 2.16.840.1.113730.3.5.10 >> supportedExtension: 2.16.840.1.113730.3.8.10.3 >> supportedExtension: 2.16.840.1.113730.3.8.10.4 >> supportedExtension: 2.16.840.1.113730.3.8.10.4.1 >> supportedExtension: 1.3.6.1.4.1.4203.1.11.1 >> supportedExtension: 2.16.840.1.113730.3.8.10.1 >> supportedExtension: 2.16.840.1.113730.3.8.10.5 >> supportedExtension: 2.16.840.1.113730.3.5.3 >> supportedExtension: 2.16.840.1.113730.3.5.12 >> supportedExtension: 2.16.840.1.113730.3.5.5 >> supportedExtension: 2.16.840.1.113730.3.5.6 >> supportedExtension: 2.16.840.1.113730.3.5.9 >> supportedExtension: 2.16.840.1.113730.3.5.4 >> supportedExtension: 2.16.840.1.113730.3.6.5 >> supportedExtension: 2.16.840.1.113730.3.6.6 >> supportedExtension: 2.16.840.1.113730.3.6.7 >> supportedExtension: 2.16.840.1.113730.3.6.8 >> supportedExtension: 1.3.6.1.4.1.1466.20037 >> supportedControl: 2.16.840.1.113730.3.4.2 >> supportedControl: 2.16.840.1.113730.3.4.3 >> supportedControl: 2.16.840.1.113730.3.4.4 >> supportedControl: 2.16.840.1.113730.3.4.5 >> supportedControl: 1.2.840.113556.1.4.473 >> supportedControl: 2.16.840.1.113730.3.4.9 >> supportedControl: 2.16.840.1.113730.3.4.16 >> supportedControl: 2.16.840.1.113730.3.4.15 >> supportedControl: 2.16.840.1.113730.3.4.17 >> supportedControl: 2.16.840.1.113730.3.4.19 >> supportedControl: 1.3.6.1.1.13.1 >> supportedControl: 1.3.6.1.1.13.2 >> supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 >> supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 >> supportedControl: 1.2.840.113556.1.4.319 >> supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 >> supportedControl: 1.3.6.1.4.1.4203.666.5.16 >> supportedControl: 2.16.840.1.113730.3.8.10.6 >> supportedControl: 2.16.840.1.113730.3.4.14 >> supportedControl: 2.16.840.1.113730.3.4.20 >> supportedControl: 1.3.6.1.4.1.1466.29539.12 >> supportedControl: 2.16.840.1.113730.3.4.12 >> supportedControl: 2.16.840.1.113730.3.4.18 >> supportedControl: 2.16.840.1.113730.3.4.13 >> supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 >> supportedSASLMechanisms: EXTERNAL >> supportedSASLMechanisms: GSS-SPNEGO >> supportedSASLMechanisms: GSSAPI >> supportedSASLMechanisms: DIGEST-MD5 >> supportedSASLMechanisms: CRAM-MD5 >> supportedSASLMechanisms: ANONYMOUS >> supportedLDAPVersion: 2 >> supportedLDAPVersion: 3 >> vendorName: 389 Project >> vendorVersion: 389-Directory/1.3.4.0 B2016.215.1556 >> dataversion: 020161222235947020161222235947020161222235947 >> netscapemdsuffix: cn=ldap://dc=wwgwho01,dc=myorg,dc=com:389 >> lastusn: 8690425 >> changeLog: cn=changelog >> firstchangenumber: 2752153 >> lastchangenumber: 2752346 >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> >> >> 2016-12-21 9:27 GMT-06:00 Rob Crittenden : >> >>> Daniel Schimpfoessl wrote: >>> > Thanks for getting back to me. >>> > >>> > getcert list | grep expires shows dates years in the future for all >>> > certificates >>> > Inline-Bild 1 >>> > >>> > ipactl start --force >>> > >>> > Eventually the system started with: >>> > Forced start, ignoring pki-tomcatd Service, continuing normal >>> > operations. >>> > >>> > systemctl status ipa shows: failed >>> >>> I don't think this is a certificate problem at all. I think the timing >>> with your renewal is just coincidence. >>> >>> Did you change your Directory Manager password at some point? >>> >>> > >>> > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w >>> > password -b "" -s base >>> > ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w >>> > *********** -b "" -s base >>> > Inline-Bild 2 >>> >>> You need the -x flag to indicate simple bind. >>> >>> rob >>> >>> > The logs have thousands of lines like it, what am I looking for >>> > specifically? >>> > >>> > Daniel >>> > >>> > >>> > 2016-12-20 4:18 GMT-06:00 Florence Blanc-Renaud >> > >: >>> > >>> > On 12/19/2016 07:15 PM, Daniel Schimpfoessl wrote: >>> > >>> > Good day and happy holidays, >>> > >>> > I have been running a freeIPA instance for a few years and >>> been very >>> > happy. Recently the certificate expired and I updated it using >>> the >>> > documented methods. At first all seemed fine. Added a Nagios >>> > monitor for >>> > the certificate expiration and restarted the server (single >>> > server). I >>> > have weekly snapshots, daily backups (using Amanda on the >>> entire >>> > disk). >>> > >>> > One day the services relying on IPA failed to authenticate. >>> > Looking at >>> > the server the ipa service had stopped. Restarting the service >>> > fails. >>> > Restoring a few weeks old snapshot does not start either. >>> > Resetting the >>> > date to a few month back does not work either as httpd fails to >>> > start . >>> > >>> > I am at a loss. >>> > >>> > Here a few details: >>> > # ipa --version >>> > VERSION: 4.4.0, API_VERSION: 2.213 >>> > >>> > >>> > # /usr/sbin/ipactl start >>> > ... >>> > out -> Failed to start pki-tomcatd Service >>> > /var/log/pki/pki-tomcat/ca/debug -> Could not connect to LDAP >>> server >>> > host ipa.myorg.com < >>> http://ipa.myorg.com> >>> > port 636 Error >>> > netscape.ldap.LDAPException: Authentication failed (48) >>> > 2016-12-19T03:02:16Z DEBUG The CA status is: check interrupted >>> > due to >>> > error: Retrieving CA status failed with status 500 >>> > >>> > Any help would be appreciated as all connected services are now >>> > down. >>> > >>> > Thanks, >>> > >>> > Daniel >>> > >>> > >>> > >>> > >>> > Hi Daniel, >>> > >>> > more information would be required to understand what is going on. >>> > First of all, which certificate did you renew? Can you check with >>> > $ getcert list >>> > if other certificates also expired? >>> > >>> > PKI fails to start and the error seems linked to the SSL connection >>> > with the LDAP server. You may want to check if the LDAP server is >>> > listening on the LDAPs port: >>> > - start the stack with >>> > $ ipactl start --force >>> > - check the LDAPs port with >>> > $ ldapsearch -H ldaps://localhost:636 -D "cn=directory manager" -w >>> > password -b "" -s base >>> > >>> > The communication between PKI and the LDAP server is authenticated >>> > with the certificate 'subsystemCert cert-pki-ca' located in >>> > /etc/pki/pki-tomcat/alias, so you may also want to check if it is >>> > still valid. >>> > The directory server access logs (in >>> > /var/log/dirsrv/slapd-DOMAIN-COM/access) would also show the >>> > connection with logs similar to: >>> > >>> > [...] conn=47 fd=84 slot=84 SSL connection from 10.34.58.150 to >>> > 10.34.58.150 >>> > [...] conn=47 TLS1.2 128-bit AES; client CN=CA >>> > Subsystem,O=DOMAIN.COM ; issuer CN=Certificate >>> > Authority,O=DOMAIN.COM >>> > [...] conn=47 TLS1.2 client bound as uid=pkidbuser,ou=people,o=ipac >>> a >>> > [...] conn=47 op=0 BIND dn="" method=sasl version=3 mech=EXTERNAL >>> > [...] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 >>> > dn="uid=pkidbuser,ou=people,o=ipaca" >>> > >>> > >>> > >>> > HTH, >>> > Flo >>> > >>> > >>> > >>> > >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.candler at pobox.com Sat Dec 31 19:18:18 2016 From: b.candler at pobox.com (Brian Candler) Date: Sat, 31 Dec 2016 19:18:18 +0000 Subject: [Freeipa-users] DNS wildcards record for domain In-Reply-To: References: Message-ID: <44b2a198-772b-ac2d-c99a-3d5418697ca5@pobox.com> On 31/12/2016 03:08, Outback Dingo wrote: > a bit at a loss here, whats the proper way to add a DNS wildcard for a > domain name to resolve to www.acmewidgets.com if someone type just the > domain acmewigets.com in a browser ? > > That's not a wildcard. What you're asking for is two normal records: www.acmewidgets.com A 192.0.2.1 acmewidgets.com A 192.0.2.1 which you can create using: ipa dnsrecord-add acmewidgets.com www --a-ip-address=192.0.2.1 ipa dnsrecord-add acmewidgets.com @ --a-ip-address=192.0.2.1 From cornelius.koelbel at netknights.it Fri Dec 30 07:21:36 2016 From: cornelius.koelbel at netknights.it (=?UTF-8?Q?Cornelius_K=C3=B6lbel?=) Date: Thu, 29 Dec 2016 23:21:36 -0800 (PST) Subject: [Freeipa-users] Valid Sender ? - Re: Using Privacyidea with FreeIPA - part 1/n In-Reply-To: <83r34qy0ym.fsf@echidna.jochen.org> References: <8360m4z012.fsf@echidna.jochen.org> <87787381-0c70-8792-47ae-1ba0ae4ded4f@redhat.com> <83r34qy0ym.fsf@echidna.jochen.org> Message-ID: <817f4b03-5a71-49e6-ab32-37b7cbee14a8@googlegroups.com> Hi Jochen, this is a very important point. Every application is adopting two factor authentication with OTP. This is great - we always hoped for such a security awareness. But the important difference is: The common webapplication that finally will implement TOTP ("this cloudy algorithm which was invented by the Google Authenticator" ;-) ) manages the seeds/keys for these tokens. If the user uses a smartphone app the user will end up with an "OTP token" or "profile" in his App for every application. Or he has to share the seeds one seed between all applications. And then he runs into the troubles mentioned earlier. You perfectly pointed out, why you need a central authentication system for managing the second factors. >From a user experience point fo view the applications could also go for U2F. Then the user again will only have one device, which he needs tor register with each application... ...but there will be no "syncing" problem. Kind regards Cornelius Am Donnerstag, 29. Dezember 2016 20:45:34 UTC+1 schrieb Jochen Hein: > > Martin Basti > writes: > > > >> But providing access to a Yubico Token via privacyidea works for all > >> cases I have in mind. > > > > How they are checking the valid tokes if they don't use its counter? > > Privacyidea is the "owner" of the token and has the secret and the > counter stored. Every other system (e.g. pam_yubico or FreeIPA) is > checking the validation against privacyiadea, either with the yubico > protocol, the privacyidey validation, or RADIUS. > > Does this clarify the architecture of my system? > > Jochen > > -- > The only problem with troubleshooting is that the trouble shoots back. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornelius.koelbel at netknights.it Fri Dec 30 07:24:31 2016 From: cornelius.koelbel at netknights.it (=?UTF-8?Q?Cornelius_K=C3=B6lbel?=) Date: Thu, 29 Dec 2016 23:24:31 -0800 (PST) Subject: [Freeipa-users] Valid Sender ? - Re: Using Privacyidea with FreeIPA - part 1/n In-Reply-To: <817f4b03-5a71-49e6-ab32-37b7cbee14a8@googlegroups.com> References: <8360m4z012.fsf@echidna.jochen.org> <87787381-0c70-8792-47ae-1ba0ae4ded4f@redhat.com> <83r34qy0ym.fsf@echidna.jochen.org> <817f4b03-5a71-49e6-ab32-37b7cbee14a8@googlegroups.com> Message-ID: <0139c814-b963-4a1f-8e4f-a72e8dee2f31@googlegroups.com> ...by the way. This is probably the reason, why Red Hat uses the predecessor of privacyIDEA as central 2FA authentication system for the OTP authentication. Kind regards Cornelius Am Freitag, 30. Dezember 2016 08:21:36 UTC+1 schrieb Cornelius K?lbel: > > Hi Jochen, > > this is a very important point. > Every application is adopting two factor authentication with OTP. This is > great - we always hoped for such a security awareness. > But the important difference is: > The common webapplication that finally will implement TOTP ("this cloudy > algorithm which was invented by the Google Authenticator" ;-) ) manages the > seeds/keys for these tokens. If the user uses a smartphone app the user > will end up with an "OTP token" or "profile" in his App for every > application. > > Or he has to share the seeds one seed between all applications. And then > he runs into the troubles mentioned earlier. > > You perfectly pointed out, why you need a central authentication system > for managing the second factors. > From a user experience point fo view the applications could also go for > U2F. Then the user again will only have one device, which he needs tor > register with each application... > ...but there will be no "syncing" problem. > > Kind regards > Cornelius > > > Am Donnerstag, 29. Dezember 2016 20:45:34 UTC+1 schrieb Jochen Hein: >> >> Martin Basti > writes: >> >> >> >> But providing access to a Yubico Token via privacyidea works for >> all >> >> cases I have in mind. >> > >> > How they are checking the valid tokes if they don't use its counter? >> >> Privacyidea is the "owner" of the token and has the secret and the >> counter stored. Every other system (e.g. pam_yubico or FreeIPA) is >> checking the validation against privacyiadea, either with the yubico >> protocol, the privacyidey validation, or RADIUS. >> >> Does this clarify the architecture of my system? >> >> Jochen >> >> -- >> The only problem with troubleshooting is that the trouble shoots back. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: