From erinn.looneytriggs at gmail.com Fri Aug 1 00:45:50 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 31 Jul 2014 17:45:50 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <1406755866.4784.5.camel@localhost.localdomain> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> Message-ID: <53DAE33E.1050503@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/30/2014 02:31 PM, Ade Lee wrote: > On Tue, 2014-07-29 at 17:49 -0700, Erinn Looney-Triggs wrote: >>>> >> >>>> Ok, well I tried deleting it using certutil it deletes both, >>>> I tried using keytool to see if it would work any better, no >>>> dice there. I'll try the rename, but at this point I am not >>>> holding my breath on that, it seems all operation are a bit >>>> too coarse. It seems the assumption was being made that there >>>> would only be one of each nickname. Which frankly makes me >>>> wonder how any of this kept running after the renewal. >>>> >>>> For now I'll see what I can do on a copy of the db using >>>> python. >>> >>> It is a little strange that there are multiple 'caSigningCert >>> cert-pki-ca' as this is the CA itself. It should be good for >>> 20 years and isn't something that the current renewal code >>> handles yet. >>> >>> You probably won't have much luck with python-nss. It can >>> handle reading PKCS#12 files but I don't believe it can write >>> them (access to key material). >>> >>> I'm not sure why certutil didn't do the trick. This should >>> work, if you want to give it another try. I'm assuming that >>> /root/cacert.p12 has the latest exported certs, adjust as >>> necessary: >>> >>> # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d >>> /tmp/test # certutil -D -d /tmp/test -n '' >>> >>> certutil should delete the oldest cert first, it always has >>> for me. >>> >>> rob >>> >> >> Ok folks I managed to clean up the certificate DB so there is >> only one valid certificate for each service. Installation >> continued pass that step and then failed shortly thereafter on >> configuring the ca. So here is my new error: >> >> >> pkispawn : ERROR ....... Exception from Java Configuration >> Servlet: Error while updating security domain: >> java.io.IOException: 2 pkispawn : DEBUG ....... Error Type: >> HTTPError pkispawn : DEBUG ....... Error Message: 500 >> Server Error: Internal Server Error pkispawn : DEBUG >> ....... File "/usr/sbin/pkispawn", line 374, in main rv = >> instance.spawn() File >> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", >> >> line 128, in spawn >> json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File >> "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", >> line 2998, in configure_pki_data response = >> client.configure(data) File >> "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in >> configure r = self.connection.post('/rest/installer/configure', >> data, headers) File >> "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in >> post r.raise_for_status() File >> "/usr/lib/python2.7/site-packages/requests/models.py", line 638, >> in raise_for_status raise http_error >> >> >> 2014-07-30T00:27:48Z CRITICAL failed to configure ca instance >> Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqX9SGx' returned >> non-zero exit status 1 2014-07-30T00:27:48Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> >> line 638, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-replica-install", line 667, in main CA = >> cainstance.install_replica_ca(config) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> line 1678, in install_replica_ca >> subject_base=config.subject_base) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> line 478, in configure_instance >> self.start_creation(runtime=210) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 364, in start_creation method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> line 604, in __spawn_instance >> raise RuntimeError('Configuration of CA failed') >> >> 2014-07-30T00:27:48Z DEBUG The ipa-replica-install command >> failed, exception: RuntimeError: Configuration of CA failed >> >> And from the pki-tomcat/ca debug log: isSDHostDomainMaster(): >> Getting domain.xml from CA... >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML start >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML: >> status=0 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: >> getDomainXML: domainInfo=> standalone="no"?>IPAipa.example.com44344344344380FALSEpki-cadTRUE100000 >> >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: Cloning a domain master >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML start hostname=ipa.example.com port=443 >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: >> updateSecurityDomain: failed to update security domain using >> admin port 443: org.xml.sax.SAXParseException; lineNumber: 1; >> columnNumber: 50; White spaces are required between publicId and >> systemId. [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: >> updateSecurityDomain: now trying agent port with client auth >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML start hostname=ipa.example.com port=443 >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: updateDomainXML() >> nickname=subsystemCert cert-pki-ca >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML: status=1 >> >> And from pki-tomcat/catalina.out: 00:26:53,450 INFO >> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) >> >> - - Deploying javax.ws.rs.core.Application: class >> com.netscape.ca.CertificateAuthorityApplication 00:26:53,472 >> INFO >> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) >> >> - - Adding singleton provider com.netscape.certsrv.acls.ACLInterceptor >> from Application javax.ws.rs.core.Application 00:26:53,473 INFO >> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) >> >> - - Adding singleton provider >> com.netscape.certsrv.authentication.AuthMethodInterceptor from >> Application javax.ws.rs.core.Application 00:26:53,772 DEBUG >> (org.jboss.resteasy.core.SynchronousDispatcher:60) - PathInfo: >> /installer/configure AuthInterceptor: >> SystemConfigResource.configure() AuthInterceptor: mapping name: >> default AuthInterceptor: required auth methods: [*] >> AuthInterceptor: anonymous access allowed [Fatal Error] :1:50: >> White spaces are required between publicId and systemId. [Fatal >> Error] :1:50: White spaces are required between publicId and >> systemId. [Fatal Error] :1:50: White spaces are required between >> publicId and systemId. [Fatal Error] :1:50: White spaces are >> required between publicId and systemId. java.io.IOException: 2 >> at >> com.netscape.cms.servlet.csadmin.ConfigurationUtils.updateDomainXML(ConfigurationUtils.java:3415) >> >> at >> com.netscape.cms.servlet.csadmin.ConfigurationUtils.updateSecurityDomain(ConfigurationUtils.java:3345) >> >> at >> com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:655) >> >> 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) >> >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) >> 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) >> >> at >> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) >> >> at >> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) >> >> at >> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) >> >> at java.security.AccessController.doPrivileged(Native Method) >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) >> >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) >> >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) >> >> at >> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) >> >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) >> >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) >> >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) >> >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) >> >> at >> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) >> >> at >> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) >> >> at >> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) >> >> 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) >> >> > > Is there any indication of what the error is on the master CA? This > would likely be in either the debug log or the catalina.out. Also, > you should see the access to update the security domain in the > httpd access log on the master. > > >> I fixed the db (in case anyone else runs into this issue) by >> doing the following: >> >> PKCS12Export of the NSS DB in order to get a .p12 file with all >> the certificates. >> >> use openssl to convert the pkcs12 file to a single file in PEM >> format with all of the certificates and the keys. >> >> From here unfortunately, you have to manually go in and find the >> valid key/cert pairs in the pem file and create new PEM files for >> each key pair you intend to import, ocsp, server cert, etc. >> Obviously only grab one key pair for each, and only the valid >> ones. Openssl does not support mass importing of key/certificate >> pairs into a PKCS12 file. >> >> Once you have a pem file for each service, you then need to >> convert these pem files back into PKCS12 format, one at a time, >> using the -name flag to give them friendly names. >> >> After this create a new NSS DB using certutil, and import each >> PKCS12 file for each service into the DB. >> >> I don't know if this is necessary, but I set the flags to be >> identical to the original DB for the certs. >> >> Now use PKCS12Export to export your newly created NSS DB into a >> cacert.p12 file. You now should have a nice new cacert.p12 file >> with only valid certificates. >> >> Most of the user space tools for handling NSS and PKCS12 files >> are not flexible enough to get what you want done. This could >> probably be coded up in a more efficient way. >> > > Thanks for the steps above. We'll be sure to keep them handy in > case this happens again, and I think we need to look at the > installation code to make sure that it handles cases where multiple > certs with the same nick are present. > >> Let me know if this stirs any thoughts, -Erinn > > This may or may not be pertinent. I noticed now on a restart of the IPA service on the RHEL 6.5 system the following are emitted: PKI-IPA...[01/Aug/2014:00:40:13 +0000] attr_syntax_create - Error: the EQUALITY matching rule [caseIgnoreIA5Match] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] [01/Aug/2014:00:40:13 +0000] attr_syntax_create - Error: the SUBSTR matching rule [caseIgnoreIA5SubstringsMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.15] for the attribute [dc] - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT2uM6AAoJEFg7BmJL2iPOkdUH/2eJ8SqGmYuTaOeOfG87iBdk hLnyMiT+VII2h2SXAJAxG9ROPlUx9jM6Zaask23X9yN1zraulyI23WFWB952DHu6 1NMGQtdEQ9esEu5GHJWacTHA7/9tz6IjHLE1wWbETizVew3fqfCf5g/u5gR6DsCG 2pArz10BfOotO5LedkYsI8G7pURYiDjy1G0hmF8kBv0JkG1c8QG03SiQrCXBr9HI HUGrlxghH7mj7qjr3THQcm31r5O8wcd2P6zLoKUaeYRj+CKyBhjfMu6KEdWKSeKS DzegpHia29ni+l4xPhrGe1khstjnJUYG6KdouVQ0ToNXF6SOihxu+eeFcr9FekA= =Rq0B -----END PGP SIGNATURE----- From barrykfl at gmail.com Fri Aug 1 06:23:47 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Fri, 1 Aug 2014 14:23:47 +0800 Subject: [Freeipa-users] Possible to extract password of ldap Message-ID: Hi : Is it possible to read clear text of password of ipa users by admin ? I m facing the issue of half rollout as half vol.of users changed password already. And if i deploy and reset all password then it may make issue for this half and we dont have records which user password sent . -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Aug 1 08:14:32 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 1 Aug 2014 10:14:32 +0200 Subject: [Freeipa-users] Users not inheriting groups In-Reply-To: <53DAC663.2050307@cenic.org> References: <53DAC663.2050307@cenic.org> Message-ID: <20140801081432.GA5182@hendrix.redhat.com> On Thu, Jul 31, 2014 at 03:42:43PM -0700, William Graboyes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi List, > > I am running into some odd issues with IPA and users not inheriting > all groups they are a member of. > > I spent a lot of time nesting groups so that when we add a user all of > the groups they need with one group setting (a boon for automation). > However I am finding a small percentage of users who are in the proper > groups in IPA but the server does not pick up all the groups involved, > until I add those specific users to the group in question. > > For clarity: > > 1) Most users inherit groups fine > 2) A small percentage (2-3% discovered so far) Do not inherit one or > more of the needed groups. > 3) Work around found by adding users directly to group instead of > nested in proper group (though less than ideal) Hi, let's find out if the group memberships propagated correctly on the server side, first, to isolate where the issues is. Can you run: ipa user-show $faulty_user --all --raw on the server, or directly ldapsearch the user so we can see if the user entry has all the memberof attributes you'd expect? From mkosek at redhat.com Fri Aug 1 08:26:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Aug 2014 10:26:25 +0200 Subject: [Freeipa-users] memberof plugin? In-Reply-To: <53DAC5E7.10408@gmail.com> References: <53DAC5E7.10408@gmail.com> Message-ID: <53DB4F31.5090404@redhat.com> On 08/01/2014 12:40 AM, Kat wrote: > Hi, > > I must be missing something obvious in getting memberof plugin to work.. Any > ideas? > > Thanks in advance... > ~K > > ---------------------------------- > > ./fixup-memberof.pl -D 'cn=Directory Manager' -b 'dc=red,dc=lemon,dc=com' -w - -v > ldap_initialize( ldap://localhost:7389 ) > add objectclass: > top > extensibleObject > add cn: > memberOf_fixup_2014_7_26_22_33_31 > add basedn: > dc=red,dc=lemon,dc=com > adding new entry "cn=memberOf_fixup_2014_7_26_22_33_31, cn=memberOf task, > cn=tasks, cn=config" > ldap_add: No such object (32) > Are you using FreeIPA or just standalone 389-ds-base instance? Does the memberOf task object exist? $ ldapsearch -x -D "cn=Directory Manager" -w Secret123 -b "cn=memberOf task, cn=tasks, cn=config" Is the MemberOf plugin enabled? (cn=MemberOf Plugin,cn=plugins,cn=config) Are there any /var/log/dirsrv/slapd-YOUR-REALM/errors? HTH, Martin From mkosek at redhat.com Fri Aug 1 08:32:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 01 Aug 2014 10:32:02 +0200 Subject: [Freeipa-users] Possible to extract password of ldap In-Reply-To: References: Message-ID: <53DB5082.8070403@redhat.com> On 08/01/2014 08:23 AM, barrykfl at gmail.com wrote: > Hi : > > Is it possible to read clear text of password of ipa users by admin ? No. Admin can't even read the hash # ldapsearch -Y GSSAPI -b uid=fbar,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid userPassword SASL/GSSAPI authentication started SASL username: admin at IDM.LAB.BOS.REDHAT.COM SASL SSF: 56 SASL data security layer installed. ... # fbar, users, accounts, idm.lab.bos.redhat.com dn: uid=fbar,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid: fbar ... Directory Manager can read the user password hash: # ldapsearch -D "cn=Directory Manager" -x -W -b uid=fbar,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid userPassword Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: uid userPassword # # fbar, users, accounts, idm.lab.bos.redhat.com dn: uid=fbar,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid: fbar userPassword:: e1NTSEF9Vnp6VDdBbDlQUVMrUHJTK1NsNnNlN1pNYU5oRnRxT2J2L3dtNUE9PQ= = # echo e1NTSEF9Vnp6VDdBbDlQUVMrUHJTK1NsNnNlN1pNYU5oRnRxT2J2L3dtNUE9PQ== | base64 --decode {SSHA}VzzT7Al9PQS+PrS+Sl6se7ZMaNhFtqObv/wm5A== That's all, no clear passwords - by design. > I m facing the issue of half rollout as half vol.of users changed > password already. > > And if i deploy and reset all password then it may make issue for this half > > and we dont have records which user password sent . I am not sure if I understand the question, but if your users have problems with their passwords, you can administratively reset them and send the new ones to them (they will be then forced to set their own (http://www.freeipa.org/page/New_Passwords_Expired)). Martin From barrykfl at gmail.com Fri Aug 1 09:42:21 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Fri, 1 Aug 2014 17:42:21 +0800 Subject: [Freeipa-users] Del private group fail even using command Message-ID: Hi: I follow command found from here and want to del priate group but fail any idea? It said line 5 attribute error , any synta xwrong? ldapsearch -LLL -Y GSSAPI cn=barry ldapmodify -Y GSSAPI < From davis.goodman at digital-district.ca Fri Aug 1 09:44:54 2014 From: davis.goodman at digital-district.ca (Davis Goodman) Date: Fri, 1 Aug 2014 05:44:54 -0400 Subject: [Freeipa-users] Del private group fail even using command In-Reply-To: References: Message-ID: On Aug 1, 2014, at 5:42 , wrote: > Hi: > > I follow command found from here and want to del priate group but fail any idea? > It said line 5 attribute error , any synta xwrong? > > ldapsearch -LLL -Y GSSAPI cn=barry > > ldapmodify -Y GSSAPI < dn: cn=barry,cn=groups,cn=accounts,dc=abc,dc=com > changetype: modify > delete: objectclass > objectclass: mepManagedEntry > delete: mepManagedBy > dn: cn=barry,cn=groups,cn=accounts,dc=abcdc=com > changetype: delete > EOF > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project You are missing a comma in : > dn: cn=barry,cn=groups,cn=accounts,dc=abcdc=com should be dn: cn=barry,cn=groups,cn=accounts,dc=abc,dc=com -- Davis Goodman Directeur Informatique | IT Manager 5605 Avenue de Gasp?, Suite 408 | Montr?al, QC H2T 2A4 T?l: +1 (514) 360-3253 x104 Cell: +1 (514) 994-7360 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_dd_small.png Type: image/png Size: 7313 bytes Desc: not available URL: From tbabej at redhat.com Fri Aug 1 09:56:36 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 01 Aug 2014 11:56:36 +0200 Subject: [Freeipa-users] Del private group fail even using command In-Reply-To: References: Message-ID: <53DB6454.3010508@redhat.com> On 08/01/2014 11:42 AM, barrykfl at gmail.com wrote: > Hi: > > I follow command found from here and want to del priate group but fail > any idea? > It said line 5 attribute error , any synta xwrong? > > ldapsearch -LLL -Y GSSAPI cn=barry > > ldapmodify -Y GSSAPI < dn: cn=barry,cn=groups,cn=accounts,dc=abc,dc=com > changetype: modify > delete: objectclass > objectclass: mepManagedEntry > delete: mepManagedBy > dn: cn=barry,cn=groups,cn=accounts,dc=abcdc=com > changetype: delete > EOF > > > You need to first delete the mepManagedBy attribute, since it is allowed by the mepManagedEntry objectclass, and then removing the objectclass itself. Performing the operations in reverse order leaves you with mepManagedBy in the entry, which is not allowed by any objectclass. #!RESULT OK #!DATE 2014-08-01T09:53:38.820 dn: cn=random,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com changetype: modify delete: mepManagedBy - #!RESULT OK #!DATE 2014-08-01T09:53:45.511 dn: cn=random,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com changetype: modify delete: objectClass objectClass: mepManagedEntry - -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkrispen at redhat.com Fri Aug 1 14:39:07 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 01 Aug 2014 16:39:07 +0200 Subject: [Freeipa-users] Del private group fail even using command In-Reply-To: <53DB6454.3010508@redhat.com> References: <53DB6454.3010508@redhat.com> Message-ID: <53DBA68B.3030309@redhat.com> On 08/01/2014 11:56 AM, Tomas Babej wrote: > > On 08/01/2014 11:42 AM, barrykfl at gmail.com wrote: >> Hi: >> >> I follow command found from here and want to del priate group but >> fail any idea? >> It said line 5 attribute error , any synta xwrong? >> >> ldapsearch -LLL -Y GSSAPI cn=barry >> >> ldapmodify -Y GSSAPI <> dn: cn=barry,cn=groups,cn=accounts,dc=abc,dc=com >> changetype: modify >> delete: objectclass >> objectclass: mepManagedEntry >> delete: mepManagedBy >> dn: cn=barry,cn=groups,cn=accounts,dc=abcdc=com >> changetype: delete >> EOF >> >> >> > > You need to first delete the mepManagedBy attribute, since it is > allowed by the mepManagedEntry objectclass, and then removing the > objectclass itself. you should be able to do this in one modify operation, if the attribute is a required attribute you even have to do it in one mod. Schema checking is done after all the mods of an operations are applied. In the original mod I think the separator of sub operations is missing, it should be: dn: cn=barry,cn=groups,cn=accounts,dc=abc,dc=com changetype: modify delete: objectclass objectclass: mepManagedEntry - delete: mepManagedBy > > Performing the operations in reverse order leaves you with > mepManagedBy in the entry, which is not allowed by any objectclass. > > #!RESULT OK > #!DATE 2014-08-01T09:53:38.820 > dn: > cn=random,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > changetype: modify > delete: mepManagedBy > - > > #!RESULT OK > #!DATE 2014-08-01T09:53:45.511 > dn: > cn=random,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > changetype: modify > delete: objectClass > objectClass: mepManagedEntry > - > > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wgraboyes at cenic.org Fri Aug 1 17:58:14 2014 From: wgraboyes at cenic.org (William Graboyes) Date: Fri, 01 Aug 2014 10:58:14 -0700 Subject: [Freeipa-users] Users not inheriting groups In-Reply-To: <20140801081432.GA5182@hendrix.redhat.com> References: <53DAC663.2050307@cenic.org> <20140801081432.GA5182@hendrix.redhat.com> Message-ID: <53DBD536.9040703@cenic.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Thanks for your help, The group memberships are propagated properly on the server side: dn: uid=user,cn=users,cn=accounts,dc=cenic,dc=org uid: user givenname: userfn sn: userln cn: userfn userln displayname: userfn userln initials: uu homedirectory: /home/user gecos: userfn userln loginshell: /bin/bash krbprincipalname: user at ORG.ORG mail: user at cenic.org uidnumber: 1080 gidnumber: 1080 nsaccountlock: False has_password: True has_keytab: True ipauniqueid: 2d01b68e-fb38-11e3-9d0d-525400e99b50 krbextradata: AALodNFTc3JpYXpAQ0VOSUMuT1JHAA== krblastfailedauth: 20140731220341Z krblastpwdchange: 20140724210440Z krblastsuccessfulauth: 20140731223953Z krbloginfailedcount: 0 krbpasswordexpiration: 20141022210440Z krbpwdpolicyreference: cn=global_policy,cn=ORG.ORG,cn=kerberos,dc=org,dc=org memberof: cn=ipausers,cn=groups,cn=accounts,dc=org,dc=org memberof: cn=games,cn=groups,cn=accounts,dc=org,dc=org memberof: cn=engineering_core_engineers,cn=groups,cn=accounts,dc=org,dc=org memberofindirect: cn=rancid_users,cn=groups,cn=accounts,dc=org,dc=org memberofindirect: ipauniqueid=696df694-e690-11e3-8fc8-525400e99b50,cn=sudorules,cn=sudo,dc=org,dc=org memberofindirect: ipauniqueid=a3eb8884-ecdc-11e3-a0df-525400e99b50,cn=ng,cn=alt,dc=org,dc=org memberofindirect: cn=rancid,cn=groups,cn=accounts,dc=org,dc=org memberofindirect: cn=engineering_core,cn=groups,cn=accounts,dc=org,dc=org memberofindirect: cn=engineering,cn=groups,cn=accounts,dc=org,dc=org memberofindirect: cn=staff,cn=groups,cn=accounts,dc=org,dc=org mepmanagedentry: cn=sriaz,cn=groups,cn=accounts,dc=org,dc=org objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetorgperson objectclass: inetuser objectclass: posixaccount objectclass: krbprincipalaux objectclass: krbticketpolicyaux objectclass: ipaobject objectclass: ipasshuser objectclass: ipaSshGroupOfPubKeys objectclass: mepOriginEntry This has been scrubbed, the group that is not being seen on the client side is the rancid group, which is showing up here. Thanks, Bill G. On Fri Aug 1 01:14:32 2014, Jakub Hrozek wrote: > On Thu, Jul 31, 2014 at 03:42:43PM -0700, William Graboyes wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hi List, >> >> I am running into some odd issues with IPA and users not inheriting >> all groups they are a member of. >> >> I spent a lot of time nesting groups so that when we add a user all of >> the groups they need with one group setting (a boon for automation). >> However I am finding a small percentage of users who are in the proper >> groups in IPA but the server does not pick up all the groups involved, >> until I add those specific users to the group in question. >> >> For clarity: >> >> 1) Most users inherit groups fine >> 2) A small percentage (2-3% discovered so far) Do not inherit one or >> more of the needed groups. >> 3) Work around found by adding users directly to group instead of >> nested in proper group (though less than ideal) > > Hi, > > let's find out if the group memberships propagated correctly on the > server side, first, to isolate where the issues is. > > Can you run: > ipa user-show $faulty_user --all --raw > > on the server, or directly ldapsearch the user so we can see if the user > entry has all the memberof attributes you'd expect? > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJT29U1AAoJEJFMz73A1+zr/NwQAJesAFdUa5CimrQr6XPqQzhC nk42rscNzf613IWA8QNd40Tns8rZ8PMlijdO5KjR4cnRxelvT9es85ik/kNBP+b1 jxqkCEWyhDJ4mu670NN0c1zALeGalpTjg0iezbtrBDulqH68a4BAYL8B4+QqN70v lBiXw/RznVKuZB/fSyu3KU93plser90kBsQi3xDG+ZZeO9Z3Dk9Fd10+MrxJBsqU GKd/mcL6KXTatj+WJ+IweM51Ple9ssKmVwLvI9NBbtImt2dxAowbHxzbWxi5zKaj H0r9ncRGJcGPo0B/FCEOy9N1+r1Dy940vPt/sfFTjuRoEFGdl7UnUu/j9CtVGITM +q6man2FSD2Vv3f//jYHzEXWZQVRpIhb4TVq9a8ah+TP6fyPeNsK96gSaMOGVos1 rHAx3y92lnqPta3+fO1pdMUaAAWtCaJXbf3m+vsziheID2/+k1ahLEzJUVoubI6S iMiArFtFUUwwwrM87naWH0pn92obuV3LQpFGm2w9nwvWbSQJCpmDQFwlHcw/vhpM OWZTmglPTFtlF+44KGBEWRwZp3bDKIV4/KOEUOaFYDAhtwCWDLepzbW1V5jaAAOX Xm/PK6xTTU07nX1YCsmPephEJxrikXOe4jD6vF4YI2pqzS2dO+hCQuH7HuQ4W4dX ZHXG7T8q9nlOT/kTJ5Pu =PEYa -----END PGP SIGNATURE----- From bnordgren at fs.fed.us Sun Aug 3 20:22:02 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sun, 3 Aug 2014 20:22:02 +0000 Subject: [Freeipa-users] Centos7, selinux, certmonger, and openldap Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E70F557@001FSN2MPN1-045.001f.mgd2.msft.net> Hey all, On CentOS 7 (presumably RHEL7 too), the tutorial on http://www.freeipa.org/page/PKI breaks (when applied to installing a certificate in /etc/openldap/certs). The offending line is "ipa-getcert request -d /etc/openldap/certs ...", and the failure message is "/etc/openldap/certs must be a directory". SELinux is enforcing, and there was an AVC. Audit2allow suggests that I enable the boolean "authlogin_nsswitch_use_ldap". Works like a champ after that. Thought I'd bring it up because the name of the boolean doesn't scream out "let certmonger manage openldap's certificates." Bryce 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 yamakasi.014 at gmail.com Sun Aug 3 20:55:34 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Sun, 3 Aug 2014 22:55:34 +0200 Subject: [Freeipa-users] IPA Replica does not start Bind but runs Manually Message-ID: Hi Guys, I have installed a replica with DNS which only starts manually and not togother with FreeIPA. It seems that it doesn't have it in it's list to start it, how can I solve this ? # /etc/init.d/ipa restart Restarting Directory Service Shutting down dirsrv: DOMAIN-LOCAL... [ OK ] Starting dirsrv: DOMAIN-LOCAL... [ 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 MEMCACHE Service Stopping ipa_memcached: [ OK ] Starting ipa_memcached: [ OK ] Restarting HTTP Service Stopping httpd: [ OK ] Starting httpd: [ OK ] I hope someone can help me out! Thanks, Matt From erinn.looneytriggs at gmail.com Sun Aug 3 23:04:52 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Sun, 03 Aug 2014 16:04:52 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <1406755866.4784.5.camel@localhost.localdomain> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> Message-ID: <53DEC014.1060604@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/30/2014 02:31 PM, Ade Lee wrote: > On Tue, 2014-07-29 at 17:49 -0700, Erinn Looney-Triggs wrote: >>>> >> >>>> Ok, well I tried deleting it using certutil it deletes both, >>>> I tried using keytool to see if it would work any better, no >>>> dice there. I'll try the rename, but at this point I am not >>>> holding my breath on that, it seems all operation are a bit >>>> too coarse. It seems the assumption was being made that there >>>> would only be one of each nickname. Which frankly makes me >>>> wonder how any of this kept running after the renewal. >>>> >>>> For now I'll see what I can do on a copy of the db using >>>> python. >>> >>> It is a little strange that there are multiple 'caSigningCert >>> cert-pki-ca' as this is the CA itself. It should be good for >>> 20 years and isn't something that the current renewal code >>> handles yet. >>> >>> You probably won't have much luck with python-nss. It can >>> handle reading PKCS#12 files but I don't believe it can write >>> them (access to key material). >>> >>> I'm not sure why certutil didn't do the trick. This should >>> work, if you want to give it another try. I'm assuming that >>> /root/cacert.p12 has the latest exported certs, adjust as >>> necessary: >>> >>> # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d >>> /tmp/test # certutil -D -d /tmp/test -n '' >>> >>> certutil should delete the oldest cert first, it always has >>> for me. >>> >>> rob >>> >> >> Ok folks I managed to clean up the certificate DB so there is >> only one valid certificate for each service. Installation >> continued pass that step and then failed shortly thereafter on >> configuring the ca. So here is my new error: >> >> >> pkispawn : ERROR ....... Exception from Java Configuration >> Servlet: Error while updating security domain: >> java.io.IOException: 2 pkispawn : DEBUG ....... Error Type: >> HTTPError pkispawn : DEBUG ....... Error Message: 500 >> Server Error: Internal Server Error pkispawn : DEBUG >> ....... File "/usr/sbin/pkispawn", line 374, in main rv = >> instance.spawn() File >> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", >> >> line 128, in spawn >> json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File >> "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", >> line 2998, in configure_pki_data response = >> client.configure(data) File >> "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in >> configure r = self.connection.post('/rest/installer/configure', >> data, headers) File >> "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in >> post r.raise_for_status() File >> "/usr/lib/python2.7/site-packages/requests/models.py", line 638, >> in raise_for_status raise http_error >> >> >> 2014-07-30T00:27:48Z CRITICAL failed to configure ca instance >> Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqX9SGx' returned >> non-zero exit status 1 2014-07-30T00:27:48Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> >> line 638, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-replica-install", line 667, in main CA = >> cainstance.install_replica_ca(config) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> line 1678, in install_replica_ca >> subject_base=config.subject_base) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> line 478, in configure_instance >> self.start_creation(runtime=210) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 364, in start_creation method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> line 604, in __spawn_instance >> raise RuntimeError('Configuration of CA failed') >> >> 2014-07-30T00:27:48Z DEBUG The ipa-replica-install command >> failed, exception: RuntimeError: Configuration of CA failed >> >> And from the pki-tomcat/ca debug log: isSDHostDomainMaster(): >> Getting domain.xml from CA... >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML start >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML: >> status=0 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: >> getDomainXML: domainInfo=> standalone="no"?>IPAipa.example.com44344344344380FALSEpki-cadTRUE100000 >> >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: Cloning a domain master >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML start hostname=ipa.example.com port=443 >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: >> updateSecurityDomain: failed to update security domain using >> admin port 443: org.xml.sax.SAXParseException; lineNumber: 1; >> columnNumber: 50; White spaces are required between publicId and >> systemId. [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: >> updateSecurityDomain: now trying agent port with client auth >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML start hostname=ipa.example.com port=443 >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: updateDomainXML() >> nickname=subsystemCert cert-pki-ca >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase >> updateDomainXML: status=1 >> >> And from pki-tomcat/catalina.out: 00:26:53,450 INFO >> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) >> >> - - Deploying javax.ws.rs.core.Application: class >> com.netscape.ca.CertificateAuthorityApplication 00:26:53,472 >> INFO >> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) >> >> - - Adding singleton provider com.netscape.certsrv.acls.ACLInterceptor >> from Application javax.ws.rs.core.Application 00:26:53,473 INFO >> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) >> >> - - Adding singleton provider >> com.netscape.certsrv.authentication.AuthMethodInterceptor from >> Application javax.ws.rs.core.Application 00:26:53,772 DEBUG >> (org.jboss.resteasy.core.SynchronousDispatcher:60) - PathInfo: >> /installer/configure AuthInterceptor: >> SystemConfigResource.configure() AuthInterceptor: mapping name: >> default AuthInterceptor: required auth methods: [*] >> AuthInterceptor: anonymous access allowed [Fatal Error] :1:50: >> White spaces are required between publicId and systemId. [Fatal >> Error] :1:50: White spaces are required between publicId and >> systemId. [Fatal Error] :1:50: White spaces are required between >> publicId and systemId. [Fatal Error] :1:50: White spaces are >> required between publicId and systemId. java.io.IOException: 2 >> at >> com.netscape.cms.servlet.csadmin.ConfigurationUtils.updateDomainXML(ConfigurationUtils.java:3415) >> >> at >> com.netscape.cms.servlet.csadmin.ConfigurationUtils.updateSecurityDomain(ConfigurationUtils.java:3345) >> >> at >> com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:655) >> >> 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) >> >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) >> 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) >> >> at >> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) >> >> at >> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) >> >> at >> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) >> >> at java.security.AccessController.doPrivileged(Native Method) >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) >> >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) >> >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) >> >> at >> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) >> >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) >> >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) >> >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) >> >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) >> >> at >> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) >> >> at >> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) >> >> at >> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) >> >> 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) >> >> > > Is there any indication of what the error is on the master CA? This > would likely be in either the debug log or the catalina.out. Also, > you should see the access to update the security domain in the > httpd access log on the master. > > >> I fixed the db (in case anyone else runs into this issue) by >> doing the following: >> >> PKCS12Export of the NSS DB in order to get a .p12 file with all >> the certificates. >> >> use openssl to convert the pkcs12 file to a single file in PEM >> format with all of the certificates and the keys. >> >> From here unfortunately, you have to manually go in and find the >> valid key/cert pairs in the pem file and create new PEM files for >> each key pair you intend to import, ocsp, server cert, etc. >> Obviously only grab one key pair for each, and only the valid >> ones. Openssl does not support mass importing of key/certificate >> pairs into a PKCS12 file. >> >> Once you have a pem file for each service, you then need to >> convert these pem files back into PKCS12 format, one at a time, >> using the -name flag to give them friendly names. >> >> After this create a new NSS DB using certutil, and import each >> PKCS12 file for each service into the DB. >> >> I don't know if this is necessary, but I set the flags to be >> identical to the original DB for the certs. >> >> Now use PKCS12Export to export your newly created NSS DB into a >> cacert.p12 file. You now should have a nice new cacert.p12 file >> with only valid certificates. >> >> Most of the user space tools for handling NSS and PKCS12 files >> are not flexible enough to get what you want done. This could >> probably be coded up in a more efficient way. >> > > Thanks for the steps above. We'll be sure to keep them handy in > case this happens again, and I think we need to look at the > installation code to make sure that it handles cases where multiple > certs with the same nick are present. > >> Let me know if this stirs any thoughts, -Erinn > > Whether related or not I am getting the following in my RHEL 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log: [26/Jul/2014:20:23:23 +0000] slapi_ldap_bind - Error: could not send startTLS re quest: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:23 +0000] NSMMReplicationPlugin - agmt="cn=masterAgreement1-i pa2.example.com-pki-ca" (ipa2:7389): Replication bind with SIMPLE auth failed: LD AP error -1 (Can't contact LDAP server) ((null)) [26/Jul/2014:20:23:37 +0000] slapi_ldap_bind - Error: could not send startTLS re quest: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:48 +0000] slapi_ldap_bind - Error: could not send startTLS re quest: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) And these errors just continue to be logged. When attempting to run ipa-ca-install -d on the RHEL 7 replica (all other services are on there running fine) I receive the following: ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned non-zero exit status 1 ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 638, in run_script return_value = main_function() File "/usr/sbin/ipa-ca-install", line 179, in main CA = cainstance.install_replica_ca(config, postinstall=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1678, in install_replica_ca subject_base=config.subject_base) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 364, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 604, in __spawn_instance raise RuntimeError('Configuration of CA failed') ipa : DEBUG The ipa-ca-install command failed, exception: RuntimeError: Configuration of CA failed Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed So this behavior changed after restarting the IPA service on the RHEL 6.5 system. So at this point I have a RHEL 6.5 system and a RHEL 7 replica of everything except the CA. The RHEL 6.5 system, when the IPA service is restarted throws an error, perhaps from schema change? Any ideas? - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT3sAPAAoJEFg7BmJL2iPOkOEIAK8Nusnjo12DqqPHNsSYcgkh ym/Cm/c33+94rdnSgrGOyaF5WOz4cRw2O8dR6Kpwy+v0Pj44b3SJvd6AfAPNnpOL zPy5PLtXr4Pr/Yb1WWhp6sL9Gg751Aru9QpKGdxG05K1kHXiuEr2JGrYbbNRGhdT DKh1NLJXN79pnpLDx+ZYvnKI3C4fwkKHClPaqPgDF1YiqorJ/j8bfKwqYcY4On0F IRlUwRwi0m7kIisWvLUut+ITud/kXDdKIOc1a/HzMKPzFdhVeJIaIZ+SfA58v5SE lD0qIc4F/gVSZKkR3majzlDr15B7arSAHsuKv6G8du8zEu48efQlU4TjNB4i97c= =WHnn -----END PGP SIGNATURE----- From bnordgren at fs.fed.us Sun Aug 3 23:36:36 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sun, 3 Aug 2014 23:36:36 +0000 Subject: [Freeipa-users] Centos7, selinux, certmonger, and openldap In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E70F557@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E70F557@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E70F594@001FSN2MPN1-045.001f.mgd2.msft.net> Spoke too soon. I needed the following "extra" selinux policy module to make all the AVCs go away. BTW: the instructions on http://www.freeipa.org/page/PKI really only work if you leave the password blank when you create a new database with certutil. Otherwise, the "ipa-getcert request" command creates tracking requests which get stuck. Databases with passwords cause certmonger to error with a "Cert storage slot still needs user PIN to be set.." This took me a couple of hours to track down. O, and don't use /etc/pki/nssdb as a "test" to see if you can make the instructions work there. It'll work, but your shiny new service certificate will clobber your host certificate because the subject is the same. Urgh. If that happens to you, you can "ipa-getcert list" to get the tracking ID of the clobbered certificate, then "ipa-getcert resubmit -i " to get it back. Ignorance really was bliss. Bryce SELinux module: ====================================================== module certmonger_openldap 1.0; require { type slapd_cert_t; type certmonger_t; class file write; } #============= certmonger_t ============== allow certmonger_t slapd_cert_t:file write; ======================================================== This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From simo at redhat.com Sun Aug 3 23:50:55 2014 From: simo at redhat.com (Simo Sorce) Date: Sun, 03 Aug 2014 19:50:55 -0400 Subject: [Freeipa-users] Centos7, selinux, certmonger, and openldap In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E70F594@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E70F557@001FSN2MPN1-045.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E70F594@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <1407109855.19681.35.camel@willson.usersys.redhat.com> On Sun, 2014-08-03 at 23:36 +0000, Nordgren, Bryce L -FS wrote: > Spoke too soon. I needed the following "extra" selinux policy module to make all the AVCs go away. > > BTW: the instructions on http://www.freeipa.org/page/PKI really only work if you leave the password blank when you create a new database with certutil. Otherwise, the "ipa-getcert request" command creates tracking requests which get stuck. Databases with passwords cause certmonger to error with a "Cert storage slot still needs user PIN to be set.." This took me a couple of hours to track down. > > O, and don't use /etc/pki/nssdb as a "test" to see if you can make the instructions work there. It'll work, but your shiny new service certificate will clobber your host certificate because the subject is the same. Urgh. If that happens to you, you can "ipa-getcert list" to get the tracking ID of the clobbered certificate, then "ipa-getcert resubmit -i " to get it back. > > Ignorance really was bliss. > > Bryce > > SELinux module: > ====================================================== > module certmonger_openldap 1.0; > > require { > type slapd_cert_t; > type certmonger_t; > class file write; > } > > #============= certmonger_t ============== > allow certmonger_t slapd_cert_t:file write; > ======================================================== Can you please open a selinux bug and attach info on how you fixed it ? Thank you. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Sun Aug 3 23:52:07 2014 From: simo at redhat.com (Simo Sorce) Date: Sun, 03 Aug 2014 19:52:07 -0400 Subject: [Freeipa-users] IPA Replica does not start Bind but runs Manually In-Reply-To: References: Message-ID: <1407109927.19681.36.camel@willson.usersys.redhat.com> On Sun, 2014-08-03 at 22:55 +0200, Matt . wrote: > Hi Guys, > > I have installed a replica with DNS which only starts manually and not > togother with FreeIPA. > > It seems that it doesn't have it in it's list to start it, how can I > solve this ? > > # /etc/init.d/ipa restart > Restarting Directory Service > Shutting down dirsrv: > DOMAIN-LOCAL... [ OK ] > Starting dirsrv: > DOMAIN-LOCAL... [ 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 MEMCACHE Service > Stopping ipa_memcached: [ OK ] > Starting ipa_memcached: [ OK ] > Restarting HTTP Service > Stopping httpd: [ OK ] > Starting httpd: [ OK ] > > I hope someone can help me out! Did you instalkl the replica wioth the --setup-dns switch ? If not you could tun ipa-dns-install on the replica I guess. Simo. -- Simo Sorce * Red Hat, Inc * New York From bnordgren at fs.fed.us Mon Aug 4 00:51:14 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Mon, 4 Aug 2014 00:51:14 +0000 Subject: [Freeipa-users] Centos7, selinux, certmonger, and openldap In-Reply-To: <1407109855.19681.35.camel@willson.usersys.redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E70F557@001FSN2MPN1-045.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E70F594@001FSN2MPN1-045.001f.mgd2.msft.net> <1407109855.19681.35.camel@willson.usersys.redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E70F5D3@001FSN2MPN1-045.001f.mgd2.msft.net> > Can you please open a selinux bug and attach info on how you fixed it ? http://bugs.centos.org/view.php?id=7458 Presumably a corresponding bug could be opened for Fedora 19 and/or RHEL 7, but I could be wrong. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From erinn.looneytriggs at gmail.com Mon Aug 4 02:45:34 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Sun, 03 Aug 2014 19:45:34 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53DEC014.1060604@gmail.com> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DEC014.1060604@gmail.com> Message-ID: <53DEF3CE.3010000@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > > > > Whether related or not I am getting the following in my RHEL 6.5 > IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log: > > [26/Jul/2014:20:23:23 +0000] slapi_ldap_bind - Error: could not > send startTLS re quest: error -1 (Can't contact LDAP server) errno > 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:23 > +0000] NSMMReplicationPlugin - agmt="cn=masterAgreement1-i > pa2.example.com-pki-ca" (ipa2:7389): Replication bind with SIMPLE > auth failed: LD AP error -1 (Can't contact LDAP server) ((null)) > [26/Jul/2014:20:23:37 +0000] slapi_ldap_bind - Error: could not > send startTLS re quest: error -1 (Can't contact LDAP server) errno > 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:48 > +0000] slapi_ldap_bind - Error: could not send startTLS re quest: > error -1 (Can't contact LDAP server) errno 107 (Transport endpoint > is not connected) > > And these errors just continue to be logged. > > When attempting to run ipa-ca-install -d on the RHEL 7 replica > (all other services are on there running fine) I receive the > following: > > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned non-zero > exit status 1 ipa : DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > > line 638, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-ca-install", line 179, in main CA = > cainstance.install_replica_ca(config, postinstall=True) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > > line 1678, in install_replica_ca > subject_base=config.subject_base) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > > line 478, in configure_instance > self.start_creation(runtime=210) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 364, in start_creation method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > > line 604, in __spawn_instance > raise RuntimeError('Configuration of CA failed') > > ipa : DEBUG The ipa-ca-install command failed, > exception: RuntimeError: Configuration of CA failed > > Your system may be partly configured. Run > /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > > > So this behavior changed after restarting the IPA service on the > RHEL 6.5 system. > > So at this point I have a RHEL 6.5 system and a RHEL 7 replica of > everything except the CA. The RHEL 6.5 system, when the IPA service > is restarted throws an error, perhaps from schema change? > > Any ideas? > > -Erinn > > I went in and debugged this a bit further by changing the verbosity for nsslapd-errorlog-level. It appears that the rhel 6.5 system is attempting to connect to the RHEL 7 system on port 7389 and since the RHEL 7 system does not have the CA installed this would obviously fail. This leads me to believe that there is cruft in the directory that is pointing to the wrong place. I don't think this will fix my second group of errors, but how does one view the replication agreements specifically for the ca? As well I omitted to lines from the ipa-ca-install error which are probably pertinent: ERROR: Unable to access directory server: Server is unwilling to perform ipa : DEBUG stderr= - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT3vPJAAoJEFg7BmJL2iPOv+MH/iRgdN+7R5q3BtQE9RcoZHss eMoUIEwAji/I1ddHklZc03p9fU5HTHlKKqRcfRGLA5nka5q3g4ZKlqh+N4BVoZrq 2wGxhD4Qh1Ye3TzwuB2Ex2oXQmRqrd96irdUnu/nf5LoFz0eBMPOcdAGRX6uMyoa lRF91cLX4HlA3neL0cSGsAp376WGMnU/EWdnriGmORkkoIqmYkR/38GYPCC3qoYG hYJK/YjInQxv1B5bXCJ/IQC3xgKkeXlzDiChp4rLNSJXWByxX3hcxTZ51YqTE49d t+yNIGkQk73yojW7WBluw2IidYXFEqqO/ORTMsd2mWUHDaGID+G3q9VCLdRHp/s= =Qv14 -----END PGP SIGNATURE----- From jhrozek at redhat.com Mon Aug 4 07:18:11 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 4 Aug 2014 09:18:11 +0200 Subject: [Freeipa-users] Users not inheriting groups In-Reply-To: <53DBD536.9040703@cenic.org> References: <53DAC663.2050307@cenic.org> <20140801081432.GA5182@hendrix.redhat.com> <53DBD536.9040703@cenic.org> Message-ID: <20140804071811.GA26329@hendrix.redhat.com> On Fri, Aug 01, 2014 at 10:58:14AM -0700, William Graboyes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Thanks for your help, > > The group memberships are propagated properly on the server side: > > dn: uid=user,cn=users,cn=accounts,dc=cenic,dc=org > uid: user > givenname: userfn > sn: userln > cn: userfn userln > displayname: userfn userln > initials: uu > homedirectory: /home/user > gecos: userfn userln > loginshell: /bin/bash > krbprincipalname: user at ORG.ORG > mail: user at cenic.org > uidnumber: 1080 > gidnumber: 1080 > nsaccountlock: False > has_password: True > has_keytab: True > ipauniqueid: 2d01b68e-fb38-11e3-9d0d-525400e99b50 > krbextradata: AALodNFTc3JpYXpAQ0VOSUMuT1JHAA== > krblastfailedauth: 20140731220341Z > krblastpwdchange: 20140724210440Z > krblastsuccessfulauth: 20140731223953Z > krbloginfailedcount: 0 > krbpasswordexpiration: 20141022210440Z > krbpwdpolicyreference: > cn=global_policy,cn=ORG.ORG,cn=kerberos,dc=org,dc=org > memberof: cn=ipausers,cn=groups,cn=accounts,dc=org,dc=org > memberof: cn=games,cn=groups,cn=accounts,dc=org,dc=org > memberof: > cn=engineering_core_engineers,cn=groups,cn=accounts,dc=org,dc=org > memberofindirect: cn=rancid_users,cn=groups,cn=accounts,dc=org,dc=org > memberofindirect: > ipauniqueid=696df694-e690-11e3-8fc8-525400e99b50,cn=sudorules,cn=sudo,dc=org,dc=org > memberofindirect: > ipauniqueid=a3eb8884-ecdc-11e3-a0df-525400e99b50,cn=ng,cn=alt,dc=org,dc=org > memberofindirect: cn=rancid,cn=groups,cn=accounts,dc=org,dc=org > memberofindirect: > cn=engineering_core,cn=groups,cn=accounts,dc=org,dc=org > memberofindirect: cn=engineering,cn=groups,cn=accounts,dc=org,dc=org > memberofindirect: cn=staff,cn=groups,cn=accounts,dc=org,dc=org > mepmanagedentry: cn=sriaz,cn=groups,cn=accounts,dc=org,dc=org > objectclass: top > objectclass: person > objectclass: organizationalperson > objectclass: inetorgperson > objectclass: inetuser > objectclass: posixaccount > objectclass: krbprincipalaux > objectclass: krbticketpolicyaux > objectclass: ipaobject > objectclass: ipasshuser > objectclass: ipaSshGroupOfPubKeys > objectclass: mepOriginEntry > > This has been scrubbed, the group that is not being seen on the client > side is the rancid group, which is showing up here. OK, then we know we're looking at a client side problem. Can you: 1) service sssd stop 2) edit /etc/sssd/sssd.conf and put debug_level=7 into both [nss] and [domain] sections 3) service sssd start 4) sss_cache -UG 5) id -G $username Then attach the logs found at /var/log/sssd/sssd_$domain.log If you feel the logs are too sensitive for a mailing list, you can send them directly to me and CC: pbrezina -at- redhat -dot- com From yamakasi.014 at gmail.com Mon Aug 4 07:40:56 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 4 Aug 2014 09:40:56 +0200 Subject: [Freeipa-users] IPA Replica does not start Bind but runs Manually In-Reply-To: <1407109927.19681.36.camel@willson.usersys.redhat.com> References: <1407109927.19681.36.camel@willson.usersys.redhat.com> Message-ID: Hi, Yes I did in the past. THe DNS tabs are there and named is installed. Can I run that "over" without any issue ? In any other case I just can reinstall the ipa software on the replica and create a new setup for it... Cheers, Matt 2014-08-04 1:52 GMT+02:00 Simo Sorce : > On Sun, 2014-08-03 at 22:55 +0200, Matt . wrote: >> Hi Guys, >> >> I have installed a replica with DNS which only starts manually and not >> togother with FreeIPA. >> >> It seems that it doesn't have it in it's list to start it, how can I >> solve this ? >> >> # /etc/init.d/ipa restart >> Restarting Directory Service >> Shutting down dirsrv: >> DOMAIN-LOCAL... [ OK ] >> Starting dirsrv: >> DOMAIN-LOCAL... [ 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 MEMCACHE Service >> Stopping ipa_memcached: [ OK ] >> Starting ipa_memcached: [ OK ] >> Restarting HTTP Service >> Stopping httpd: [ OK ] >> Starting httpd: [ OK ] >> >> I hope someone can help me out! > > Did you instalkl the replica wioth the --setup-dns switch ? > > If not you could tun ipa-dns-install on the replica I guess. > > Simo. > > > -- > Simo Sorce * Red Hat, Inc * New York > From jhrozek at redhat.com Mon Aug 4 07:57:18 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 4 Aug 2014 09:57:18 +0200 Subject: [Freeipa-users] Users not inheriting groups In-Reply-To: <20140804071811.GA26329@hendrix.redhat.com> References: <53DAC663.2050307@cenic.org> <20140801081432.GA5182@hendrix.redhat.com> <53DBD536.9040703@cenic.org> <20140804071811.GA26329@hendrix.redhat.com> Message-ID: <20140804075718.GC26329@hendrix.redhat.com> On Mon, Aug 04, 2014 at 09:18:11AM +0200, Jakub Hrozek wrote: > On Fri, Aug 01, 2014 at 10:58:14AM -0700, William Graboyes wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Thanks for your help, > > > > The group memberships are propagated properly on the server side: > > > > dn: uid=user,cn=users,cn=accounts,dc=cenic,dc=org > > uid: user > > givenname: userfn > > sn: userln > > cn: userfn userln > > displayname: userfn userln > > initials: uu > > homedirectory: /home/user > > gecos: userfn userln > > loginshell: /bin/bash > > krbprincipalname: user at ORG.ORG > > mail: user at cenic.org > > uidnumber: 1080 > > gidnumber: 1080 > > nsaccountlock: False > > has_password: True > > has_keytab: True > > ipauniqueid: 2d01b68e-fb38-11e3-9d0d-525400e99b50 > > krbextradata: AALodNFTc3JpYXpAQ0VOSUMuT1JHAA== > > krblastfailedauth: 20140731220341Z > > krblastpwdchange: 20140724210440Z > > krblastsuccessfulauth: 20140731223953Z > > krbloginfailedcount: 0 > > krbpasswordexpiration: 20141022210440Z > > krbpwdpolicyreference: > > cn=global_policy,cn=ORG.ORG,cn=kerberos,dc=org,dc=org > > memberof: cn=ipausers,cn=groups,cn=accounts,dc=org,dc=org > > memberof: cn=games,cn=groups,cn=accounts,dc=org,dc=org > > memberof: > > cn=engineering_core_engineers,cn=groups,cn=accounts,dc=org,dc=org > > memberofindirect: cn=rancid_users,cn=groups,cn=accounts,dc=org,dc=org > > memberofindirect: > > ipauniqueid=696df694-e690-11e3-8fc8-525400e99b50,cn=sudorules,cn=sudo,dc=org,dc=org > > memberofindirect: > > ipauniqueid=a3eb8884-ecdc-11e3-a0df-525400e99b50,cn=ng,cn=alt,dc=org,dc=org > > memberofindirect: cn=rancid,cn=groups,cn=accounts,dc=org,dc=org > > memberofindirect: > > cn=engineering_core,cn=groups,cn=accounts,dc=org,dc=org > > memberofindirect: cn=engineering,cn=groups,cn=accounts,dc=org,dc=org > > memberofindirect: cn=staff,cn=groups,cn=accounts,dc=org,dc=org > > mepmanagedentry: cn=sriaz,cn=groups,cn=accounts,dc=org,dc=org > > objectclass: top > > objectclass: person > > objectclass: organizationalperson > > objectclass: inetorgperson > > objectclass: inetuser > > objectclass: posixaccount > > objectclass: krbprincipalaux > > objectclass: krbticketpolicyaux > > objectclass: ipaobject > > objectclass: ipasshuser > > objectclass: ipaSshGroupOfPubKeys > > objectclass: mepOriginEntry > > > > This has been scrubbed, the group that is not being seen on the client > > side is the rancid group, which is showing up here. > > OK, then we know we're looking at a client side problem. > > Can you: > 1) service sssd stop > 2) edit /etc/sssd/sssd.conf and put debug_level=7 into both [nss] > and [domain] sections > 3) service sssd start > 4) sss_cache -UG > 5) id -G $username > > Then attach the logs found at /var/log/sssd/sssd_$domain.log > > If you feel the logs are too sensitive for a mailing list, you can > send them directly to me and CC: pbrezina -at- redhat -dot- com btw do all the groups have a POSIX ID ? We currently have a bug in SSSD where we don't resolve non-POSIX groups correctly. From mkosek at redhat.com Mon Aug 4 08:13:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 04 Aug 2014 10:13:47 +0200 Subject: [Freeipa-users] IPA Replica does not start Bind but runs Manually In-Reply-To: References: <1407109927.19681.36.camel@willson.usersys.redhat.com> Message-ID: <53DF40BB.3060502@redhat.com> On 08/04/2014 09:40 AM, Matt . wrote: > Hi, > > Yes I did in the past. THe DNS tabs are there and named is installed. You probably installed DNS service on another FreeIPA server. However, there is a configuration space telling which server has which services configured. It seems that it does not see your current server as the DNS server. > Can I run that "over" without any issue ? Yes, If it detects that DNS service was already installed there it will error out. Then we will do different route. > In any other case I just can reinstall the ipa software on the replica > and create a new setup for it... Let's not go this way (yet), simple DNS service installation should be work. Martin From mkosek at redhat.com Mon Aug 4 11:01:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 04 Aug 2014 13:01:47 +0200 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53DEF3CE.3010000@gmail.com> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DEC014.1060604@gmail.com> <53DEF3CE.3010000@gmail.com> Message-ID: <53DF681B.4000800@redhat.com> On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote: > > > > >> Whether related or not I am getting the following in my RHEL 6.5 >> IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log: > >> [26/Jul/2014:20:23:23 +0000] slapi_ldap_bind - Error: could not >> send startTLS re quest: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:23 >> +0000] NSMMReplicationPlugin - agmt="cn=masterAgreement1-i >> pa2.example.com-pki-ca" (ipa2:7389): Replication bind with SIMPLE >> auth failed: LD AP error -1 (Can't contact LDAP server) ((null)) >> [26/Jul/2014:20:23:37 +0000] slapi_ldap_bind - Error: could not >> send startTLS re quest: error -1 (Can't contact LDAP server) errno >> 107 (Transport endpoint is not connected) [26/Jul/2014:20:23:48 >> +0000] slapi_ldap_bind - Error: could not send startTLS re quest: >> error -1 (Can't contact LDAP server) errno 107 (Transport endpoint >> is not connected) > >> And these errors just continue to be logged. > >> When attempting to run ipa-ca-install -d on the RHEL 7 replica >> (all other services are on there running fine) I receive the >> following: > >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned non-zero >> exit status 1 ipa : DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > > > line 638, in run_script >> return_value = main_function() > >> File "/usr/sbin/ipa-ca-install", line 179, in main CA = >> cainstance.install_replica_ca(config, postinstall=True) > >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > > > line 1678, in install_replica_ca >> subject_base=config.subject_base) > >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > > > line 478, in configure_instance >> self.start_creation(runtime=210) > >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 364, in start_creation method() > >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > > > line 604, in __spawn_instance >> raise RuntimeError('Configuration of CA failed') > >> ipa : DEBUG The ipa-ca-install command failed, >> exception: RuntimeError: Configuration of CA failed > >> Your system may be partly configured. Run >> /usr/sbin/ipa-server-install --uninstall to clean up. > >> Configuration of CA failed > > >> So this behavior changed after restarting the IPA service on the >> RHEL 6.5 system. > >> So at this point I have a RHEL 6.5 system and a RHEL 7 replica of >> everything except the CA. The RHEL 6.5 system, when the IPA service >> is restarted throws an error, perhaps from schema change? > >> Any ideas? > >> -Erinn > > > > I went in and debugged this a bit further by changing the verbosity > for nsslapd-errorlog-level. It appears that the rhel 6.5 system is > attempting to connect to the RHEL 7 system on port 7389 and since the > RHEL 7 system does not have the CA installed this would obviously > fail. This leads me to believe that there is cruft in the directory > that is pointing to the wrong place. I don't think this will fix my > second group of errors, but how does one view the replication > agreements specifically for the ca? > > As well I omitted to lines from the ipa-ca-install error which are > probably pertinent: > > ERROR: Unable to access directory server: Server is unwilling to perform > > ipa : DEBUG stderr= > > -Erinn This is strange. ipa-ca-install/ipa-replica-install --setup-ca should create the replication agreement pointing at port 389 on RHEL-7.0, given that the 2 originally separated DS databases were merged. It looks like this is some replication agreement left over from previous tests. Anyway, to list all hosts with PKI, try: # ipa-csreplica-manage list Directory Manager password: vm-089.idm.lab.bos.redhat.com: master vm-086.idm.lab.bos.redhat.com: master "master" means that this server has PKI service installed. It will show different value if there is no PKI service. To check PKI replication agreements for specific hostname, run: # ipa-csreplica-manage list `hostname` Directory Manager password: vm-089.idm.lab.bos.redhat.com Check "man ipa-csreplica-manage" for advise how to delete or create the PKI agreements. HTH, Martin From mkosek at redhat.com Mon Aug 4 11:35:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 04 Aug 2014 13:35:54 +0200 Subject: [Freeipa-users] Centos7, selinux, certmonger, and openldap In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E70F594@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E70F557@001FSN2MPN1-045.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E70F594@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <53DF701A.1080304@redhat.com> On 08/04/2014 01:36 AM, Nordgren, Bryce L -FS wrote: > Spoke too soon. I needed the following "extra" selinux policy module to make all the AVCs go away. > > BTW: the instructions on http://www.freeipa.org/page/PKI really only work if you leave the password blank when you create a new database with certutil. Otherwise, the "ipa-getcert request" command creates tracking requests which get stuck. Databases with passwords cause certmonger to error with a "Cert storage slot still needs user PIN to be set.." This took me a couple of hours to track down. Hmm, sorry for incomplete instructions then. I updated the instructions to cope with that situation better (details in https://fedorahosted.org/freeipa/ticket/4466#comment:2). Please feel free to report more findings or even better help us enhance the page even further :-) HTH, Martin From alee at redhat.com Mon Aug 4 13:36:37 2014 From: alee at redhat.com (Ade Lee) Date: Mon, 04 Aug 2014 09:36:37 -0400 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53DA4437.2090001@gmail.com> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DA4437.2090001@gmail.com> Message-ID: <1407159397.11870.7.camel@aleeredhat.laptop> On Thu, 2014-07-31 at 06:27 -0700, Erinn Looney-Triggs wrote: > On 07/30/2014 02:31 PM, Ade Lee wrote: > > On Tue, 2014-07-29 at 17:49 -0700, Erinn Looney-Triggs wrote: > >>>> > >> > >>>> Ok, well I tried deleting it using certutil it deletes both, > >>>> I tried using keytool to see if it would work any better, no > >>>> dice there. I'll try the rename, but at this point I am not > >>>> holding my breath on that, it seems all operation are a bit > >>>> too coarse. It seems the assumption was being made that there > >>>> would only be one of each nickname. Which frankly makes me > >>>> wonder how any of this kept running after the renewal. > >>>> > >>>> For now I'll see what I can do on a copy of the db using > >>>> python. > >>> > >>> It is a little strange that there are multiple 'caSigningCert > >>> cert-pki-ca' as this is the CA itself. It should be good for > >>> 20 years and isn't something that the current renewal code > >>> handles yet. > >>> > >>> You probably won't have much luck with python-nss. It can > >>> handle reading PKCS#12 files but I don't believe it can write > >>> them (access to key material). > >>> > >>> I'm not sure why certutil didn't do the trick. This should > >>> work, if you want to give it another try. I'm assuming that > >>> /root/cacert.p12 has the latest exported certs, adjust as > >>> necessary: > >>> > >>> # certutil -N -d /tmp/test # pk12util -i /root/cacert.p12 -d > >>> /tmp/test # certutil -D -d /tmp/test -n '' > >>> > >>> certutil should delete the oldest cert first, it always has > >>> for me. > >>> > >>> rob > >>> > >> > >> Ok folks I managed to clean up the certificate DB so there is > >> only one valid certificate for each service. Installation > >> continued pass that step and then failed shortly thereafter on > >> configuring the ca. So here is my new error: > >> > >> > >> pkispawn : ERROR ....... Exception from Java Configuration > >> Servlet: Error while updating security domain: > >> java.io.IOException: 2 pkispawn : DEBUG ....... Error Type: > >> HTTPError pkispawn : DEBUG ....... Error Message: 500 > >> Server Error: Internal Server Error pkispawn : DEBUG > >> ....... File "/usr/sbin/pkispawn", line 374, in main rv = > >> instance.spawn() File > >> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", > >> > >> > line 128, in spawn > >> json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File > >> "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", > >> line 2998, in configure_pki_data response = > >> client.configure(data) File > >> "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in > >> configure r = self.connection.post('/rest/installer/configure', > >> data, headers) File > >> "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in > >> post r.raise_for_status() File > >> "/usr/lib/python2.7/site-packages/requests/models.py", line 638, > >> in raise_for_status raise http_error > >> > >> > >> 2014-07-30T00:27:48Z CRITICAL failed to configure ca instance > >> Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqX9SGx' returned > >> non-zero exit status 1 2014-07-30T00:27:48Z DEBUG File > >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > >> > >> > line 638, in run_script > >> return_value = main_function() > >> > >> File "/usr/sbin/ipa-replica-install", line 667, in main CA = > >> cainstance.install_replica_ca(config) > >> > >> File > >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > >> > >> > line 1678, in install_replica_ca > >> subject_base=config.subject_base) > >> > >> File > >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > >> > >> > line 478, in configure_instance > >> self.start_creation(runtime=210) > >> > >> File > >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > >> line 364, in start_creation method() > >> > >> File > >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > >> > >> > line 604, in __spawn_instance > >> raise RuntimeError('Configuration of CA failed') > >> > >> 2014-07-30T00:27:48Z DEBUG The ipa-replica-install command > >> failed, exception: RuntimeError: Configuration of CA failed > >> > >> And from the pki-tomcat/ca debug log: isSDHostDomainMaster(): > >> Getting domain.xml from CA... > >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML start > >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: getDomainXML: > >> status=0 [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: > >> getDomainXML: domainInfo= >> standalone="no"?>IPAipa.example.com44344344344380FALSEpki-cadTRUE100000 > >> > >> > [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: Cloning a domain master > >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase > >> updateDomainXML start hostname=ipa.example.com port=443 > >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: > >> updateSecurityDomain: failed to update security domain using > >> admin port 443: org.xml.sax.SAXParseException; lineNumber: 1; > >> columnNumber: 50; White spaces are required between publicId and > >> systemId. [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: > >> updateSecurityDomain: now trying agent port with client auth > >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase > >> updateDomainXML start hostname=ipa.example.com port=443 > >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: updateDomainXML() > >> nickname=subsystemCert cert-pki-ca > >> [30/Jul/2014:00:27:48][http-bio-8443-exec-3]: WizardPanelBase > >> updateDomainXML: status=1 > >> > >> And from pki-tomcat/catalina.out: 00:26:53,450 INFO > >> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) > >> > >> > - Deploying javax.ws.rs.core.Application: class > >> com.netscape.ca.CertificateAuthorityApplication 00:26:53,472 > >> INFO > >> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) > >> > >> > - Adding singleton provider com.netscape.certsrv.acls.ACLInterceptor > >> from Application javax.ws.rs.core.Application 00:26:53,473 INFO > >> (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) > >> > >> > - Adding singleton provider > >> com.netscape.certsrv.authentication.AuthMethodInterceptor from > >> Application javax.ws.rs.core.Application 00:26:53,772 DEBUG > >> (org.jboss.resteasy.core.SynchronousDispatcher:60) - PathInfo: > >> /installer/configure AuthInterceptor: > >> SystemConfigResource.configure() AuthInterceptor: mapping name: > >> default AuthInterceptor: required auth methods: [*] > >> AuthInterceptor: anonymous access allowed [Fatal Error] :1:50: > >> White spaces are required between publicId and systemId. [Fatal > >> Error] :1:50: White spaces are required between publicId and > >> systemId. [Fatal Error] :1:50: White spaces are required between > >> publicId and systemId. [Fatal Error] :1:50: White spaces are > >> required between publicId and systemId. java.io.IOException: 2 > >> at > >> com.netscape.cms.servlet.csadmin.ConfigurationUtils.updateDomainXML(ConfigurationUtils.java:3415) > >> > >> > at > >> com.netscape.cms.servlet.csadmin.ConfigurationUtils.updateSecurityDomain(ConfigurationUtils.java:3345) > >> > >> > at > >> com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:655) > >> > >> > 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) > >> > >> > at > >> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) > >> > >> > at > >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) > >> > >> > at > >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) > >> > >> > at > >> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) > >> > >> > at > >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) > >> > >> > at > >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) > >> > >> > at > >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) > >> > >> > at > >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) > >> > >> > at > >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) > >> > >> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > >> 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) > >> > >> > at > >> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) > >> > >> > at > >> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) > >> > >> > at > >> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) > >> > >> > at java.security.AccessController.doPrivileged(Native Method) > >> at > >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) > >> > >> > at > >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > >> > >> > at > >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > >> > >> > at > >> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) > >> > >> > at > >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > >> > >> > at > >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > >> > >> > at > >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > >> > >> > at > >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > >> > >> > at > >> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) > >> > >> > at > >> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > >> > >> > at > >> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) > >> > >> > 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) > >> > >> > > > > Is there any indication of what the error is on the master CA? This > > would likely be in either the debug log or the catalina.out. Also, > > you should see the access to update the security domain in the > > httpd access log on the master. > > > > > >> I fixed the db (in case anyone else runs into this issue) by > >> doing the following: > >> > >> PKCS12Export of the NSS DB in order to get a .p12 file with all > >> the certificates. > >> > >> use openssl to convert the pkcs12 file to a single file in PEM > >> format with all of the certificates and the keys. > >> > >> From here unfortunately, you have to manually go in and find the > >> valid key/cert pairs in the pem file and create new PEM files for > >> each key pair you intend to import, ocsp, server cert, etc. > >> Obviously only grab one key pair for each, and only the valid > >> ones. Openssl does not support mass importing of key/certificate > >> pairs into a PKCS12 file. > >> > >> Once you have a pem file for each service, you then need to > >> convert these pem files back into PKCS12 format, one at a time, > >> using the -name flag to give them friendly names. > >> > >> After this create a new NSS DB using certutil, and import each > >> PKCS12 file for each service into the DB. > >> > >> I don't know if this is necessary, but I set the flags to be > >> identical to the original DB for the certs. > >> > >> Now use PKCS12Export to export your newly created NSS DB into a > >> cacert.p12 file. You now should have a nice new cacert.p12 file > >> with only valid certificates. > >> > >> Most of the user space tools for handling NSS and PKCS12 files > >> are not flexible enough to get what you want done. This could > >> probably be coded up in a more efficient way. > >> > > > > Thanks for the steps above. We'll be sure to keep them handy in > > case this happens again, and I think we need to look at the > > installation code to make sure that it handles cases where multiple > > certs with the same nick are present. > > > >> Let me know if this stirs any thoughts, -Erinn > > > > > > Well here is probably the pertinent part of the debug log, though > there is a lot more when the clone is setting up: > [31/Jul/2014:13:23:53][TP-Processor3]: AuthMgrName: certUserDBAuthMgr > [31/Jul/2014:13:23:53][TP-Processor3]: CMSServlet: retrieving SSL > certificate > [31/Jul/2014:13:23:53][TP-Processor3]: CMSServlet: certUID=CN=CA > Subsystem,O=example.COM > [31/Jul/2014:13:23:53][TP-Processor3]: CertUserDBAuth: started > [31/Jul/2014:13:23:53][TP-Processor3]: CertUserDBAuth: Retrieving > client certificate > [31/Jul/2014:13:23:53][TP-Processor3]: CertUserDBAuth: Got client > certificate > [31/Jul/2014:13:23:53][TP-Processor3]: In LdapBoundConnFactory::getConn() > [31/Jul/2014:13:23:53][TP-Processor3]: masterConn is connected: true > [31/Jul/2014:13:23:53][TP-Processor3]: getConn: conn is connected true > [31/Jul/2014:13:23:53][TP-Processor3]: getConn: mNumConns now 2 > [31/Jul/2014:13:23:53][TP-Processor3]: returnConn: mNumConns now 3 > [31/Jul/2014:13:23:53][TP-Processor3]: Authentication: client > certificate found > [31/Jul/2014:13:23:53][TP-Processor3]: In LdapBoundConnFactory::getConn() > [31/Jul/2014:13:23:53][TP-Processor3]: masterConn is connected: true > [31/Jul/2014:13:23:53][TP-Processor3]: getConn: conn is connected true > [31/Jul/2014:13:23:53][TP-Processor3]: getConn: mNumConns now 2 > [31/Jul/2014:13:23:53][TP-Processor3]: returnConn: mNumConns now 3 > [31/Jul/2014:13:23:53][TP-Processor3]: SignedAuditEventFactory: > create() > message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=CA > Subsystem,O=example.COM] authentication failure > > [31/Jul/2014:13:23:53][TP-Processor3]: CMSServlet: curDate=Thu Jul 31 > 13:23:53 GMT 2014 id=caUpdateDomainXML time=11 > Lets focus on the above error. This says that the master was unable to map the certificate that was presented to a user under ou=users, o=ipaca. I would look at the database (for the master) and see what users are defined. Check which users have the subsystem certificate defined as their certificate, and check the description attribute. That attribute should contain a string that includes the certificate serial number, subject DN and issuer, delimited by semicolons. Check that string and confirm that the certificate for that user matches the description delimiter, and that the subsystem certificate is the same as the subsystem certificate in the replica certdb. It would also be useful to see what the DS access logs say at the time this authentication failure occurs. Ade > > -Erinn > From erinn.looneytriggs at gmail.com Mon Aug 4 14:40:37 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 04 Aug 2014 07:40:37 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <1407159397.11870.7.camel@aleeredhat.laptop> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DA4437.2090001@gmail.com> <1407159397.11870.7.camel@aleeredhat.laptop> Message-ID: <53DF9B65.2060007@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/04/2014 06:36 AM, Ade Lee wrote: >> >> Well here is probably the pertinent part of the debug log, >> though there is a lot more when the clone is setting up: >> [31/Jul/2014:13:23:53][TP-Processor3]: AuthMgrName: >> certUserDBAuthMgr [31/Jul/2014:13:23:53][TP-Processor3]: >> CMSServlet: retrieving SSL certificate >> [31/Jul/2014:13:23:53][TP-Processor3]: CMSServlet: certUID=CN=CA >> Subsystem,O=example.COM [31/Jul/2014:13:23:53][TP-Processor3]: >> CertUserDBAuth: started [31/Jul/2014:13:23:53][TP-Processor3]: >> CertUserDBAuth: Retrieving client certificate >> [31/Jul/2014:13:23:53][TP-Processor3]: CertUserDBAuth: Got >> client certificate [31/Jul/2014:13:23:53][TP-Processor3]: In >> LdapBoundConnFactory::getConn() >> [31/Jul/2014:13:23:53][TP-Processor3]: masterConn is connected: >> true [31/Jul/2014:13:23:53][TP-Processor3]: getConn: conn is >> connected true [31/Jul/2014:13:23:53][TP-Processor3]: getConn: >> mNumConns now 2 [31/Jul/2014:13:23:53][TP-Processor3]: >> returnConn: mNumConns now 3 >> [31/Jul/2014:13:23:53][TP-Processor3]: Authentication: client >> certificate found [31/Jul/2014:13:23:53][TP-Processor3]: In >> LdapBoundConnFactory::getConn() >> [31/Jul/2014:13:23:53][TP-Processor3]: masterConn is connected: >> true [31/Jul/2014:13:23:53][TP-Processor3]: getConn: conn is >> connected true [31/Jul/2014:13:23:53][TP-Processor3]: getConn: >> mNumConns now 2 [31/Jul/2014:13:23:53][TP-Processor3]: >> returnConn: mNumConns now 3 >> [31/Jul/2014:13:23:53][TP-Processor3]: SignedAuditEventFactory: >> create() >> message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=CA >> >> Subsystem,O=example.COM] authentication failure >> >> [31/Jul/2014:13:23:53][TP-Processor3]: CMSServlet: curDate=Thu >> Jul 31 13:23:53 GMT 2014 id=caUpdateDomainXML time=11 >> > Lets focus on the above error. This says that the master was > unable to map the certificate that was presented to a user under > ou=users, o=ipaca. > > I would look at the database (for the master) and see what users > are defined. Check which users have the subsystem certificate > defined as their certificate, and check the description attribute. > That attribute should contain a string that includes the > certificate serial number, subject DN and issuer, delimited by > semicolons. Check that string and confirm that the certificate for > that user matches the description delimiter, and that the subsystem > certificate is the same as the subsystem certificate in the replica > certdb. > > It would also be useful to see what the DS access logs say at the > time this authentication failure occurs. > > Ade >> >> -Erinn >> > > Well unfortunately, after restarting the IPA services on the RHEL 6.5 system I no longer receive this error at all. Using ipa-ca-install fails in the steps before this error was received. ipa : DEBUG Starting external process ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpvByIvk ipa : DEBUG Process finished, return code=1 ipa : DEBUG stdout=Loading deployment configuration from /tmp/tmpvByIvk. ERROR: Unable to access directory server: Server is unwilling to perform ipa : DEBUG stderr= ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpvByIvk' returned non-zero exit status 1 ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 638, in run_script return_value = main_function() File "/usr/sbin/ipa-ca-install", line 179, in main CA = cainstance.install_replica_ca(config, postinstall=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1678, in install_replica_ca subject_base=config.subject_base) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 364, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 604, in __spawn_instance raise RuntimeError('Configuration of CA failed') ipa : DEBUG The ipa-ca-install command failed, exception: RuntimeError: Configuration of CA failed Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed And the access log from /var/log/dirsrv/slapd-PKI-CA/access on the RHEL 6.5 master only shows this: [04/Aug/2014:14:16:25 +0000] conn=211 fd=74 slot=74 connection from 2001:4870:800e:301:862b:2bff:fe67:704d to 2001:4870:800e:301:f24d:a2ff:fe09:ae0 [04/Aug/2014:14:16:25 +0000] conn=211 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [04/Aug/2014:14:16:25 +0000] conn=211 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [04/Aug/2014:14:16:25 +0000] conn=211 SSL 128-bit AES [04/Aug/2014:14:16:25 +0000] conn=211 op=1 BIND dn="cn=Directory Manager" method=128 version=3 [04/Aug/2014:14:16:25 +0000] conn=211 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [04/Aug/2014:14:16:25 +0000] conn=211 op=2 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" [04/Aug/2014:14:16:25 +0000] conn=211 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [04/Aug/2014:14:16:26 +0000] conn=211 op=3 UNBIND [04/Aug/2014:14:16:26 +0000] conn=211 op=3 fd=74 closed - U1 However, did you mean ou=People instead of ou=Users? Because I have a People OU with admin and ipara objects, but no Users OU. Thanks, - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT35tgAAoJEFg7BmJL2iPOyNoIAIdkgTl8VILwQgfXgFNPN2jz T1jwdicLc/p08ZwacKufJ0IJVf4pko0UZrYE+ZaFEVGSuIPTzQc8oeGZoB3hKBTn WG5MchmU3ahlzoawh5gnU6VEFPVjcs5ev7nScU/yFl2WFXDrMACD3D21CSfUCBvF dCB7iz99xXGWqdQOf8lQPsd2/rHma0Vt6NYEN8pUyhaY7+KTapMLYMqkE/rFsV6A L815c+j0YdadB7DUpjXP855we9Fq6NWNUnTSabvq5D02uwdIeUNtWqq8Zbhps3Gv CY9HZhgKqAG4EOwhYJ9cmVFV40tbRS3gxgOs5gej0HHn6xUd2ySSJqczIFl8myA= =OjGC -----END PGP SIGNATURE----- From erinn.looneytriggs at gmail.com Mon Aug 4 14:48:55 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 04 Aug 2014 07:48:55 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53DF681B.4000800@redhat.com> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DEC014.1060604@gmail.com> <53DEF3CE.3010000@gmail.com> <53DF681B.4000800@redhat.com> Message-ID: <53DF9D57.8040105@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/04/2014 04:01 AM, Martin Kosek wrote: > On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote: >> >> >> >> >>> Whether related or not I am getting the following in my RHEL >>> 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log: >> >>> [26/Jul/2014:20:23:23 +0000] slapi_ldap_bind - Error: could >>> not send startTLS re quest: error -1 (Can't contact LDAP >>> server) errno 107 (Transport endpoint is not connected) >>> [26/Jul/2014:20:23:23 +0000] NSMMReplicationPlugin - >>> agmt="cn=masterAgreement1-i pa2.example.com-pki-ca" >>> (ipa2:7389): Replication bind with SIMPLE auth failed: LD AP >>> error -1 (Can't contact LDAP server) ((null)) >>> [26/Jul/2014:20:23:37 +0000] slapi_ldap_bind - Error: could >>> not send startTLS re quest: error -1 (Can't contact LDAP >>> server) errno 107 (Transport endpoint is not connected) >>> [26/Jul/2014:20:23:48 +0000] slapi_ldap_bind - Error: could not >>> send startTLS re quest: error -1 (Can't contact LDAP server) >>> errno 107 (Transport endpoint is not connected) >> >>> And these errors just continue to be logged. >> >>> When attempting to run ipa-ca-install -d on the RHEL 7 replica >>> (all other services are on there running fine) I receive the >>> following: >> >>> ipa : CRITICAL failed to configure ca instance Command >>> '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned >>> non-zero exit status 1 ipa : DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> >> >> >>> line 638, in run_script >>> return_value = main_function() >> >>> File "/usr/sbin/ipa-ca-install", line 179, in main CA = >>> cainstance.install_replica_ca(config, postinstall=True) >> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> >> >>> line 1678, in install_replica_ca >>> subject_base=config.subject_base) >> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> >> >>> line 478, in configure_instance >>> self.start_creation(runtime=210) >> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> >>> line 364, in start_creation method() >> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> >> >>> line 604, in __spawn_instance >>> raise RuntimeError('Configuration of CA failed') >> >>> ipa : DEBUG The ipa-ca-install command failed, >>> exception: RuntimeError: Configuration of CA failed >> >>> Your system may be partly configured. Run >>> /usr/sbin/ipa-server-install --uninstall to clean up. >> >>> Configuration of CA failed >> >> >>> So this behavior changed after restarting the IPA service on >>> the RHEL 6.5 system. >> >>> So at this point I have a RHEL 6.5 system and a RHEL 7 replica >>> of everything except the CA. The RHEL 6.5 system, when the IPA >>> service is restarted throws an error, perhaps from schema >>> change? >> >>> Any ideas? >> >>> -Erinn >> >> >> >> I went in and debugged this a bit further by changing the >> verbosity for nsslapd-errorlog-level. It appears that the rhel >> 6.5 system is attempting to connect to the RHEL 7 system on port >> 7389 and since the RHEL 7 system does not have the CA installed >> this would obviously fail. This leads me to believe that there is >> cruft in the directory that is pointing to the wrong place. I >> don't think this will fix my second group of errors, but how does >> one view the replication agreements specifically for the ca? >> >> As well I omitted to lines from the ipa-ca-install error which >> are probably pertinent: >> >> ERROR: Unable to access directory server: Server is unwilling to >> perform >> >> ipa : DEBUG stderr= >> >> -Erinn > > This is strange. ipa-ca-install/ipa-replica-install --setup-ca > should create the replication agreement pointing at port 389 on > RHEL-7.0, given that the 2 originally separated DS databases were > merged. > > It looks like this is some replication agreement left over from > previous tests. > > Anyway, to list all hosts with PKI, try: > > # ipa-csreplica-manage list Directory Manager password: > > vm-089.idm.lab.bos.redhat.com: master > vm-086.idm.lab.bos.redhat.com: master > > "master" means that this server has PKI service installed. It will > show different value if there is no PKI service. > > To check PKI replication agreements for specific hostname, run: > > # ipa-csreplica-manage list `hostname` Directory Manager password: > > vm-089.idm.lab.bos.redhat.com > > Check "man ipa-csreplica-manage" for advise how to delete or create > the PKI agreements. > > HTH, Martin > Yeah here is what I get: ipa-csreplica-manage list Directory Manager password: ipa2.example.com: CA not configured ipa.example.com: master ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance. ipa-csreplica-manage list ipa2.example.com Directory Manager password: Can't contact LDAP server Which I guess makes sense, however: ipa-csreplica-manage list -v ipa.example.com Directory Manager password: ipa2.example.com last init status: None last init ended: None last update status: -1 - LDAP error: Can't contact LDAP server last update ended: None ipa2.example.com last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-08-04 14:43:48+00:00 This seems odd to me, but I don't really know exactly what to expect. Why is ipa2 referenced twice? Why does on have replication succeeding and the other failing? It currently just feels like something is configured wrong, there is a wrong entry somewhere, but I can't figure it out just yet. Thanks for the help, - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT351QAAoJEFg7BmJL2iPOzKUIAKQe/QDZBAcUVtF9cx4ZqW7P 5iJOgkCJOKYTqn7qsbrccVySLsV1ZMf8wF4W/HuhypfNLqbLYXBfK2CkUt6qwA7Z zaJpRM29Foiz8yHkJUrFb2vG9A2M1O691gHxVnnJi7IKXQOAOF5d/k4jpdmSWPdL KeIBjf1y8OKi5zIEZZ/XnZJGjKmqOXZZWAdzVZdrfAaptLSNZxK+4cT+WNn/6dyC zaj5zEUbOzLbxXXPrbb0JgVcQVqcqnj3dMdX16BiRnfqY0/wvMStooqDpwRkycEl gIknQqBy3sgRYxs45THgis1jg1MXS7PCXo3GhEwiLrD1SHwMpniTzXs/wW96IlI= =bRll -----END PGP SIGNATURE----- From rcritten at redhat.com Mon Aug 4 15:46:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Aug 2014 11:46:49 -0400 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53DF9D57.8040105@gmail.com> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DEC014.1060604@gmail.com> <53DEF3CE.3010000@gmail.com> <53DF681B.4000800@redhat.com> <53DF9D57.8040105@gmail.com> Message-ID: <53DFAAE9.90803@redhat.com> Erinn Looney-Triggs wrote: > On 08/04/2014 04:01 AM, Martin Kosek wrote: >> On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote: >>> >>> >>> >>> >>>> Whether related or not I am getting the following in my RHEL >>>> 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug log: >>> >>>> [26/Jul/2014:20:23:23 +0000] slapi_ldap_bind - Error: could >>>> not send startTLS re quest: error -1 (Can't contact LDAP >>>> server) errno 107 (Transport endpoint is not connected) >>>> [26/Jul/2014:20:23:23 +0000] NSMMReplicationPlugin - >>>> agmt="cn=masterAgreement1-i pa2.example.com-pki-ca" >>>> (ipa2:7389): Replication bind with SIMPLE auth failed: LD AP >>>> error -1 (Can't contact LDAP server) ((null)) >>>> [26/Jul/2014:20:23:37 +0000] slapi_ldap_bind - Error: could >>>> not send startTLS re quest: error -1 (Can't contact LDAP >>>> server) errno 107 (Transport endpoint is not connected) >>>> [26/Jul/2014:20:23:48 +0000] slapi_ldap_bind - Error: could not >>>> send startTLS re quest: error -1 (Can't contact LDAP server) >>>> errno 107 (Transport endpoint is not connected) >>> >>>> And these errors just continue to be logged. >>> >>>> When attempting to run ipa-ca-install -d on the RHEL 7 replica >>>> (all other services are on there running fine) I receive the >>>> following: >>> >>>> ipa : CRITICAL failed to configure ca instance Command >>>> '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' returned >>>> non-zero exit status 1 ipa : DEBUG File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> >>> >>> >>>> > line 638, in run_script >>>> return_value = main_function() >>> >>>> File "/usr/sbin/ipa-ca-install", line 179, in main CA = >>>> cainstance.install_replica_ca(config, postinstall=True) >>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> >>> >>> >>>> > line 1678, in install_replica_ca >>>> subject_base=config.subject_base) >>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> >>> >>> >>>> > line 478, in configure_instance >>>> self.start_creation(runtime=210) >>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> >>>> > line 364, in start_creation method() >>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> >>> >>> >>>> > line 604, in __spawn_instance >>>> raise RuntimeError('Configuration of CA failed') >>> >>>> ipa : DEBUG The ipa-ca-install command failed, >>>> exception: RuntimeError: Configuration of CA failed >>> >>>> Your system may be partly configured. Run >>>> /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>>> Configuration of CA failed >>> >>> >>>> So this behavior changed after restarting the IPA service on >>>> the RHEL 6.5 system. >>> >>>> So at this point I have a RHEL 6.5 system and a RHEL 7 replica >>>> of everything except the CA. The RHEL 6.5 system, when the IPA >>>> service is restarted throws an error, perhaps from schema >>>> change? >>> >>>> Any ideas? >>> >>>> -Erinn >>> >>> >>> >>> I went in and debugged this a bit further by changing the >>> verbosity for nsslapd-errorlog-level. It appears that the rhel >>> 6.5 system is attempting to connect to the RHEL 7 system on port >>> 7389 and since the RHEL 7 system does not have the CA installed >>> this would obviously fail. This leads me to believe that there is >>> cruft in the directory that is pointing to the wrong place. I >>> don't think this will fix my second group of errors, but how does >>> one view the replication agreements specifically for the ca? >>> >>> As well I omitted to lines from the ipa-ca-install error which >>> are probably pertinent: >>> >>> ERROR: Unable to access directory server: Server is unwilling to >>> perform >>> >>> ipa : DEBUG stderr= >>> >>> -Erinn > >> This is strange. ipa-ca-install/ipa-replica-install --setup-ca >> should create the replication agreement pointing at port 389 on >> RHEL-7.0, given that the 2 originally separated DS databases were >> merged. > >> It looks like this is some replication agreement left over from >> previous tests. > >> Anyway, to list all hosts with PKI, try: > >> # ipa-csreplica-manage list Directory Manager password: > >> vm-089.idm.lab.bos.redhat.com: master >> vm-086.idm.lab.bos.redhat.com: master > >> "master" means that this server has PKI service installed. It will >> show different value if there is no PKI service. > >> To check PKI replication agreements for specific hostname, run: > >> # ipa-csreplica-manage list `hostname` Directory Manager password: > >> vm-089.idm.lab.bos.redhat.com > >> Check "man ipa-csreplica-manage" for advise how to delete or create >> the PKI agreements. > >> HTH, Martin > > > Yeah here is what I get: > ipa-csreplica-manage list > Directory Manager password: > > ipa2.example.com: CA not configured > ipa.example.com: master > > ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance. > > ipa-csreplica-manage list ipa2.example.com > Directory Manager password: > > Can't contact LDAP server > > Which I guess makes sense, however: > ipa-csreplica-manage list -v ipa.example.com > Directory Manager password: > > ipa2.example.com > last init status: None > last init ended: None > last update status: -1 - LDAP error: Can't contact LDAP server > last update ended: None > ipa2.example.com > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental > update succeeded > last update ended: 2014-08-04 14:43:48+00:00 > > This seems odd to me, but I don't really know exactly what to expect. > Why is ipa2 referenced twice? Why does on have replication succeeding > and the other failing? > > It currently just feels like something is configured wrong, there is a > wrong entry somewhere, but I can't figure it out just yet. As Directory Manager, look in cn=mapping tree,cn=config for the list of agreements. I'm guessing at least one of those has the wrong port. The IPA agreement CN takes the form of meTo and CA agreements CN uses masterAgreement1--* (or cloneAgreement, depending on the side you're on). rob From rmeggins at redhat.com Mon Aug 4 16:41:04 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 04 Aug 2014 10:41:04 -0600 Subject: [Freeipa-users] Possible to extract password of ldap In-Reply-To: References: Message-ID: <53DFB7A0.4000002@redhat.com> On 08/01/2014 12:23 AM, barrykfl at gmail.com wrote: > Hi : > > Is it possible to read clear text of password of ipa users by admin ? No. > > I m facing the issue of half rollout as half vol.of users changed > password already. > > And if i deploy and reset all password then it may make issue for this > half > > and we dont have records which user password sent . > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Mon Aug 4 17:06:44 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Mon, 4 Aug 2014 17:06:44 +0000 Subject: [Freeipa-users] Centos7, selinux, certmonger, and openldap In-Reply-To: <53DF701A.1080304@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E70F557@001FSN2MPN1-045.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E70F594@001FSN2MPN1-045.001f.mgd2.msft.net> <53DF701A.1080304@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E70F7BD@001FSN2MPN1-045.001f.mgd2.msft.net> > Hmm, sorry for incomplete instructions then. I updated the instructions to > cope with that situation better (details in > https://fedorahosted.org/freeipa/ticket/4466#comment:2). Please feel free > to report more findings or even better help us enhance the page even > further :-) Hmm, I thought it looked like your wiki, but when there was no login in the upper-right corner, I assumed it was an online version of your manual. That always gets me, even when I'm looking at a page I know I created myself. In this case, tho, I was definitely not qualified to provide a fix. New to both certmonger and that Mozilla certificate database thing. Made a comment on the talk page about the related OpenLDAP selinux issues (more than one cert_t defined). Dunno if you get notifications. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From erinn.looneytriggs at gmail.com Mon Aug 4 19:10:03 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 04 Aug 2014 12:10:03 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <1407178111.18236.5.camel@aleeredhat.laptop> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DA4437.2090001@gmail.com> <1407159397.11870.7.camel@aleeredhat.laptop> <53DF9B65.2060007@gmail.com> <1407173622.11870.19.camel@aleeredhat.laptop> <53DFD052.1050109@gmail.com> <1407178111.18236.5.camel@aleeredhat.laptop> Message-ID: <53DFDA8B.3080405@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/04/2014 11:48 AM, Ade Lee wrote: > OK - so its not really even getting started on the install. My > guess is there is some cruft from previous installs/uninstalls that > was not cleaned up. Is there anything in the directory server logs > on the RHEL7 machine? What operation is being attempted that the > server is refusing to perform? > > Ade > Ok I moved on past this issue. Problem was minssf was set to 56 on the RHEL 7 dirsrv instance, setting it to 0 resolved this issue. Thanks for having me check the dir on the RHEL 7 instance I was assuming it was hitting against the RHEL 6.5 instance and was finding basically nothing there. This run looks like it pulled a lot more information in but it still errored out. ipa : DEBUG stderr=pkispawn : WARNING ....... unable to validate security domain user/password through REST interface. Interface not available pkispawn : ERROR ....... Exception from Java Configuration Servlet: Error in confguring system certificatesjava.security.cert.CertificateException: Unable to initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, too big. ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero exit status 1 - From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 instance: [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with mininum 3 and maximum 15 connections to host ipa2.abaqis.com port 389, secure connection, false, authentication type 1 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new total available connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In LdapBoundConnFactory::getConn() [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: conn is connected true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: mNumConns now 2 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: param=preop.internaldb.post_ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file = /usr/share/pki/ca/conf/vlv.ldif [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): LDAP Errors in importing /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInvalidCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allInValidCertsNotBefore-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedCaCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedCertsNotAfter-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedOrRevokedExpiredCaCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allRevokedOrRevokedExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allValidCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allValidCertsNotAfter-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=allValidOrRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caAll-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caCanceled-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caCanceledEnrollment-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caCanceledRenewal-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caCanceledRevocation-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caComplete-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caCompleteEnrollment-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caCompleteRenewal-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caCompleteRevocation-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caEnrollment-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caPending-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caPendingEnrollment-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caPendingRenewal-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caPendingRevocation-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caRejected-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caRejectedEnrollment-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caRejectedRenewal-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caRejectedRevocation-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caRenewal-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: exception in adding entry cn=caRevocation-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): ldif file = /usr/share/pki/ca/conf/vlvtasks.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): ldif file copy to /var/lib/pki/pki-tomcat/ca/conf/vlvtasks.ldif [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: Checking wait_dn cn=index1160589769, cn=index, cn=tasks, cn=config [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: configCert: caType is local [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel: updateConfig() for certTag sslserver [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: updateConfig() done [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: Creating local certificate... certTag=sslserver [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: In LdapBoundConnFactory::getConn() [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: masterConn is connected: true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: getConn: conn is connected true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: getConn: mNumConns now 2 [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: Repository: getSerialNumber. [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: returnConn: mNumConns now 3 Record not found at com.netscape.cmscore.dbs.DBSSession.read(DBSSession.java:179) at com.netscape.cmscore.dbs.DBSSession.read(DBSSession.java:135) at com.netscape.cmscore.dbs.Repository.getSerialNumber(Repository.java:140) at com.netscape.cmscore.dbs.Repository.initCache(Repository.java:259) at com.netscape.cmscore.dbs.Repository.initCacheIfNeeded(Repository.java:331) at com.netscape.cmscore.dbs.CertificateRepository.getNextSerialNumber(CertificateRepository.java:261) at com.netscape.cms.servlet.csadmin.CertUtil.createLocalCert(CertUtil.java:391) at com.netscape.cms.servlet.csadmin.ConfigurationUtils.configCert(ConfigurationUtils.java:2323) at com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:517) 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) 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) [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel configCert() exception caught:Record not found [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel configCert: failed to add metainfo. Exception: java.lang.NullPointerException [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: In LdapBoundConnFactory::getConn() [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: masterConn is connected: true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: getConn: conn is connected true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: getConn: mNumConns now 2 [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: returnConn: mNumConns now 3 [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel configCert: failed to add certificate record. Exception: java.lang.NullPointerException [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel update: Exception: java.lang.NullPointerException [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: handleCertRequest: tag=sslserver [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: privKeyID=-45cf0bca8e8c04dc7904f4c273f6e3793185c997 [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: handleCertRequest: created cert request [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: handleCerts(): for cert tag sslserver And from catalina.out on the same system: java.security.cert.CertificateException: Unable to initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, too big. at netscape.security.x509.X509CertImpl.(X509CertImpl.java:186) at netscape.security.x509.X509CertImpl.(X509CertImpl.java:160) at com.netscape.cms.servlet.csadmin.ConfigurationUtils.handleCerts(ConfigurationUtils.java:2718) at com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:575) 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) 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) And the last bit from pkispawn: 2014-08-04 19:02:40 pkispawn : ERROR ....... Exception from Java Configuration Servlet: Error in confguring system certificatesjava.security.cert.CertificateException: Unable to initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, too big. 2014-08-04 19:02:40 pkispawn : DEBUG ....... Error Type: HTTPError 2014-08-04 19:02:40 pkispawn : DEBUG ....... Error Message: 500 Server Error: Internal Server Error 2014-08-04 19:02:40 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 374, in main rv = instance.spawn() File "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", line 128, in spawn json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", line 2998, in configure_pki_data response = client.configure(data) File "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in configure r = self.connection.post('/rest/installer/configure', data, headers) File "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in post r.raise_for_status() File "/usr/lib/python2.7/site-packages/requests/models.py", line 638, in raise_for_status raise http_error - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT39qHAAoJEFg7BmJL2iPOe4AH/AlenxG1XNorhGLDhkoyHAaP dvNAVvQHa3fPAHpPsVr6DydVbwJm3jsXQikK07nZ8bh7pH4Kgq7AbmHi/Dy024JE C37VZ8VT5MZs7VuKYF7x4TLiXaEw7uVrFbwGjBvrJ5Za/IAbk2TRcNi6F1Rh0fu7 6FT092WAlUzhKHE2VIBYTyLUbQxvFuGokuoxYr5qxE7wbQ14G8xMW5/iuyBP+fHS 4kzy2uRbhdU0b1xNwod8W7X8MPLU+IR3e7j7tQCC0txelsq5+dNXyKU3zujRycIO P4NIZO8vtJDRDVJUo9UjylnjehrLaLgl7g/M5vrhxi4BAnX8uEad4mVIp3c5F7o= =3oSm -----END PGP SIGNATURE----- From mheslin at redhat.com Mon Aug 4 20:21:30 2014 From: mheslin at redhat.com (Mark Heslin) Date: Mon, 04 Aug 2014 16:21:30 -0400 Subject: [Freeipa-users] AD Trusts: Should tcp/389/636 be excluded or not? Message-ID: <53DFEB4A.8060301@redhat.com> Folks, Does anyone know the current disposition of $subject? The FreeIPA documentation: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Firewall_configuration would seem to indicate this is no longer necessary. Is this "official" or should we block just the Win/AD server from these ports? Alexander Bokovoy and I were working together last Friday on a cross-realm Kerberos trust to an AD server (Win2012 R2) and noticed replication was not working because I had tcp/389 and tcp/636 REJECT configured on the IdM servers. After removing the rules everything is working again. Currently, I still have the rules removed but would like to know whether to keep them removed or add them back in but block only the packets from the Win/AD server. Thanks, =m -- Red Hat Reference Architectures Follow Us: https://twitter.com/RedHatRefArch Plus Us: https://plus.google.com/u/0/b/114152126783830728030/ Like Us: https://www.facebook.com/rhrefarch From abokovoy at redhat.com Mon Aug 4 20:37:44 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 4 Aug 2014 23:37:44 +0300 Subject: [Freeipa-users] AD Trusts: Should tcp/389/636 be excluded or not? In-Reply-To: <53DFEB4A.8060301@redhat.com> References: <53DFEB4A.8060301@redhat.com> Message-ID: <20140804203744.GP3492@redhat.com> On Mon, 04 Aug 2014, Mark Heslin wrote: >Folks, > >Does anyone know the current disposition of $subject? The FreeIPA >documentation: > >http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Firewall_configuration > >would seem to indicate this is no longer necessary. Is this "official" >or should we block >just the Win/AD server from these ports? > >Alexander Bokovoy and I were working together last Friday on a >cross-realm Kerberos trust >to an AD server (Win2012 R2) and noticed replication was not working >because I had >tcp/389 and tcp/636 REJECT configured on the IdM servers. After >removing the rules >everything is working again. > >Currently, I still have the rules removed but would like to know >whether to keep them removed >or add them back in but block only the packets from the Win/AD server. Never ever block tcp/389 and tcp/636 between IPA servers or your replication will not work at all. The instruction we show at the end of ipa-adtrust-install is related only to communication with AD DCs for the sake of their sanity as any attempt to use LDAP(S) over TCP against IPA servers will most likely confuse Windows machines due to completely different schema used. LDAP over UDP is required for trusts as connectionless LDAP (CLDAP) is part of discovery protocol that AD machines expect to work. Blocking TCP/389 and TCP/636 between AD DCs and IPA servers should not hurt. -- / Alexander Bokovoy From erinn.looneytriggs at gmail.com Mon Aug 4 20:41:56 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 04 Aug 2014 13:41:56 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53DFAAE9.90803@redhat.com> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DEC014.1060604@gmail.com> <53DEF3CE.3010000@gmail.com> <53DF681B.4000800@redhat.com> <53DF9D57.8040105@gmail.com> <53DFAAE9.90803@redhat.com> Message-ID: <53DFF014.6070808@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/04/2014 08:46 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> On 08/04/2014 04:01 AM, Martin Kosek wrote: >>> On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote: >>>> >>>> >>>> >>>> >>>>> Whether related or not I am getting the following in my >>>>> RHEL 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug >>>>> log: >>>> >>>>> [26/Jul/2014:20:23:23 +0000] slapi_ldap_bind - Error: >>>>> could not send startTLS re quest: error -1 (Can't contact >>>>> LDAP server) errno 107 (Transport endpoint is not >>>>> connected) [26/Jul/2014:20:23:23 +0000] >>>>> NSMMReplicationPlugin - agmt="cn=masterAgreement1-i >>>>> pa2.example.com-pki-ca" (ipa2:7389): Replication bind with >>>>> SIMPLE auth failed: LD AP error -1 (Can't contact LDAP >>>>> server) ((null)) [26/Jul/2014:20:23:37 +0000] >>>>> slapi_ldap_bind - Error: could not send startTLS re quest: >>>>> error -1 (Can't contact LDAP server) errno 107 (Transport >>>>> endpoint is not connected) [26/Jul/2014:20:23:48 +0000] >>>>> slapi_ldap_bind - Error: could not send startTLS re quest: >>>>> error -1 (Can't contact LDAP server) errno 107 (Transport >>>>> endpoint is not connected) >>>> >>>>> And these errors just continue to be logged. >>>> >>>>> When attempting to run ipa-ca-install -d on the RHEL 7 >>>>> replica (all other services are on there running fine) I >>>>> receive the following: >>>> >>>>> ipa : CRITICAL failed to configure ca instance >>>>> Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' >>>>> returned non-zero exit status 1 ipa : DEBUG >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>> >>>> >>>> >>>>> >> >>>>> line 638, in run_script >>>>> return_value = main_function() >>>> >>>>> File "/usr/sbin/ipa-ca-install", line 179, in main CA = >>>>> cainstance.install_replica_ca(config, postinstall=True) >>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> >>>> >>>> >>>>> >> >>>>> line 1678, in install_replica_ca >>>>> subject_base=config.subject_base) >>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> >>>> >>>> >>>>> >> >>>>> line 478, in configure_instance >>>>> self.start_creation(runtime=210) >>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>> >>>>> >> >>>>> line 364, in start_creation method() >>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> >>>> >>>> >>>>> >> >>>>> line 604, in __spawn_instance >>>>> raise RuntimeError('Configuration of CA failed') >>>> >>>>> ipa : DEBUG The ipa-ca-install command failed, >>>>> exception: RuntimeError: Configuration of CA failed >>>> >>>>> Your system may be partly configured. Run >>>>> /usr/sbin/ipa-server-install --uninstall to clean up. >>>> >>>>> Configuration of CA failed >>>> >>>> >>>>> So this behavior changed after restarting the IPA service >>>>> on the RHEL 6.5 system. >>>> >>>>> So at this point I have a RHEL 6.5 system and a RHEL 7 >>>>> replica of everything except the CA. The RHEL 6.5 system, >>>>> when the IPA service is restarted throws an error, perhaps >>>>> from schema change? >>>> >>>>> Any ideas? >>>> >>>>> -Erinn >>>> >>>> >>>> >>>> I went in and debugged this a bit further by changing the >>>> verbosity for nsslapd-errorlog-level. It appears that the >>>> rhel 6.5 system is attempting to connect to the RHEL 7 system >>>> on port 7389 and since the RHEL 7 system does not have the CA >>>> installed this would obviously fail. This leads me to believe >>>> that there is cruft in the directory that is pointing to the >>>> wrong place. I don't think this will fix my second group of >>>> errors, but how does one view the replication agreements >>>> specifically for the ca? >>>> >>>> As well I omitted to lines from the ipa-ca-install error >>>> which are probably pertinent: >>>> >>>> ERROR: Unable to access directory server: Server is >>>> unwilling to perform >>>> >>>> ipa : DEBUG stderr= >>>> >>>> -Erinn >> >>> This is strange. ipa-ca-install/ipa-replica-install --setup-ca >>> should create the replication agreement pointing at port 389 >>> on RHEL-7.0, given that the 2 originally separated DS databases >>> were merged. >> >>> It looks like this is some replication agreement left over >>> from previous tests. >> >>> Anyway, to list all hosts with PKI, try: >> >>> # ipa-csreplica-manage list Directory Manager password: >> >>> vm-089.idm.lab.bos.redhat.com: master >>> vm-086.idm.lab.bos.redhat.com: master >> >>> "master" means that this server has PKI service installed. It >>> will show different value if there is no PKI service. >> >>> To check PKI replication agreements for specific hostname, >>> run: >> >>> # ipa-csreplica-manage list `hostname` Directory Manager >>> password: >> >>> vm-089.idm.lab.bos.redhat.com >> >>> Check "man ipa-csreplica-manage" for advise how to delete or >>> create the PKI agreements. >> >>> HTH, Martin >> >> >> Yeah here is what I get: ipa-csreplica-manage list Directory >> Manager password: >> >> ipa2.example.com: CA not configured ipa.example.com: master >> >> ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance. >> >> ipa-csreplica-manage list ipa2.example.com Directory Manager >> password: >> >> Can't contact LDAP server >> >> Which I guess makes sense, however: ipa-csreplica-manage list -v >> ipa.example.com Directory Manager password: >> >> ipa2.example.com last init status: None last init ended: None >> last update status: -1 - LDAP error: Can't contact LDAP server >> last update ended: None ipa2.example.com last init status: None >> last init ended: None last update status: 0 Replica acquired >> successfully: Incremental update succeeded last update ended: >> 2014-08-04 14:43:48+00:00 >> >> This seems odd to me, but I don't really know exactly what to >> expect. Why is ipa2 referenced twice? Why does on have >> replication succeeding and the other failing? >> >> It currently just feels like something is configured wrong, there >> is a wrong entry somewhere, but I can't figure it out just yet. > > As Directory Manager, look in cn=mapping tree,cn=config for the > list of agreements. I'm guessing at least one of those has the > wrong port. > > The IPA agreement CN takes the form of meTo and CA > agreements CN uses masterAgreement1--* (or > cloneAgreement, depending on the side you're on). > > rob > Rob, Thanks, looking in there I see two entries for my ipa2 instance for CA replication. However, none should exist as far as I know because at this point there is no CA replica on ipa2. These safe to delete? - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT3/APAAoJEFg7BmJL2iPOJi0H/1fSZ2spdvzJtyvHxsNIOGAJ u8GgopYi7K3/sT/0tHl60zrwe5zfLroWbAN1wWO0MwDuR7HAf10rUpXmgz109tAS tPAgCpEbLYfJMJJ4DrqL6AbN2Uxy5PzWIdAdzgZcnt4sQeTqHKsmYnpLpHPlHEIW xuRokQo/qy+t0uuTGC4zHbZuT+FxDBgsIYMTPv0DUYx5e6M3xVIswSWn6NQchUtg 9HfaU2Qn0kk+0eDBhCbbsWoUuyf1NJAdh8Cp+bgCCL1ADmqGQJDyWeYEvqgYqt26 4Pf+q2dxVXDOZLdjx6fXy8zWjF3Cisf62dZ6HOYv4u6vuTK0HRwc78X9bQJjfhM= =JaA2 -----END PGP SIGNATURE----- From mheslin at redhat.com Mon Aug 4 21:09:20 2014 From: mheslin at redhat.com (Mark Heslin) Date: Mon, 04 Aug 2014 17:09:20 -0400 Subject: [Freeipa-users] AD Trusts: Should tcp/389/636 be excluded or not? In-Reply-To: <20140804203744.GP3492@redhat.com> References: <53DFEB4A.8060301@redhat.com> <20140804203744.GP3492@redhat.com> Message-ID: <53DFF680.1020201@redhat.com> On 08/04/2014 04:37 PM, Alexander Bokovoy wrote: > On Mon, 04 Aug 2014, Mark Heslin wrote: >> Folks, >> >> Does anyone know the current disposition of $subject? The FreeIPA >> documentation: >> >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Firewall_configuration >> >> >> would seem to indicate this is no longer necessary. Is this >> "official" or should we block >> just the Win/AD server from these ports? >> >> Alexander Bokovoy and I were working together last Friday on a >> cross-realm Kerberos trust >> to an AD server (Win2012 R2) and noticed replication was not working >> because I had >> tcp/389 and tcp/636 REJECT configured on the IdM servers. After >> removing the rules >> everything is working again. >> >> Currently, I still have the rules removed but would like to know >> whether to keep them removed >> or add them back in but block only the packets from the Win/AD server. > Never ever block tcp/389 and tcp/636 between IPA servers or your > replication will not work at all. The instruction we show at the end of > ipa-adtrust-install is related only to communication with AD DCs for > the sake of their sanity as any attempt to use LDAP(S) over TCP against > IPA servers will most likely confuse Windows machines due to completely > different schema used. LDAP over UDP is required for trusts as > connectionless LDAP (CLDAP) is part of discovery protocol that AD > machines expect to work. > > Blocking TCP/389 and TCP/636 between AD DCs and IPA servers should not > hurt. Good. I can modify the firewalld rules accordingly: ipv4 filter ipa-server-chain 0 --proto tcp --destination-port 389 ! --source {ad-server-ip} --jump ACCEPT ipv4 filter ipa-server-chain 0 --proto tcp --destination-port 636 ! --source {ad-server-ip} --jump ACCEPT Thanks Alexander :-) -m -- Red Hat Reference Architectures Follow Us: https://twitter.com/RedHatRefArch Plus Us: https://plus.google.com/u/0/b/114152126783830728030/ Like Us: https://www.facebook.com/rhrefarch From amessina at messinet.com Mon Aug 4 21:42:40 2014 From: amessina at messinet.com (Anthony Messina) Date: Mon, 04 Aug 2014 16:42:40 -0500 Subject: [Freeipa-users] attribute "dnaremotebindmethod" not allowed In-Reply-To: <8811150.x5i9GLEPuA@linux-ws1.messinet.com> References: <1533697.7NUeVVaGAa@linux-ws1.messinet.com> <53D28D15.10106@redhat.com> <8811150.x5i9GLEPuA@linux-ws1.messinet.com> Message-ID: <35182421.AL36lgdoXP@linux-ws1.messinet.com> On Friday, July 25, 2014 01:43:04 PM Anthony Messina wrote: > On Friday, July 25, 2014 11:00:05 AM Rich Megginson wrote: > > On 07/25/2014 10:43 AM, Anthony Messina wrote: > > On Friday, July 25, 2014 10:26:55 AM Rich Megginson wrote: > > On 07/25/2014 01:46 AM, Anthony Messina wrote: > > On Thursday, July 24, 2014 08:44:34 AM Martin Kosek wrote: > > On 07/23/2014 06:38 PM, Anthony Messina wrote: > > On Monday, July 21, 2014 01:09:43 PM Ludwig Krispenz wrote: > > Looks like the schema file was changed, but not added to the list of > > files to be replaced at upgrade, I will open a 389 ticket and have it in > > > > > > the next release. > > > > > > > > Could you try t copy file manually for now ? > > > > > > > > Manually copying the file from /etc/dirsrv/schema/10dna-plugin.ldif to > > /etc/dirsrv/slapd-EXAMPLE-COM/schema/10dna-plugin.ldif on both of my IPA > > masters and restarting seems to have eliminated the error. > > > > > > > > > > > > Is there anything else that needs to be done? > > > > > > > > > > That should be all. BTW, the schema upgrade error is now fixed in > > https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.20-1.fc20 > > With that update, my dirsrv error logs on both of my masters are flooded > > with the following errors. Issuing 'ipactl restart' several times seems > > to > > > > reduce the incidence: > > > > - Connection is NULL and hence cannot access SLAPI_CONN_ID > > > > > > Sorry about that - this will be fixed in 1.3.2.21. > > Thank you, Rich. > > > > > > > > > > Also, I'm not sure if it's related to the above error, but the following > > are what I find related to the originally reported dnaremotebindmethod > > issue after upgrading both of my masters. > > > > > > > > Should the dnaRemoteBindMethod and dnaRemoteConnProtocol have something > > other than (null) as a value? Should they be the same on each master? > > > > > > > > ~]# ldapsearch -Y GSSAPI -LLL -s sub -b cn=posix- > > ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com > > SASL/GSSAPI authentication started > > SASL username: admin at EXAMPLE.COM > > SASL SSF: 56 > > SASL data security layer installed. > > dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com > > objectClass: nsContainer > > objectClass: top > > cn: posix-ids > > > > > > > > dn: > > dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn > > =etc,dc=example,dc=com > > objectClass: dnaSharedConfig > > objectClass: top > > dnaHostname: ipa1.example.com > > dnaPortNum: 389 > > dnaSecurePortNum: 636 > > dnaRemainingValues: 199972 > > dnaRemoteBindMethod: (null) > > dnaRemoteConnProtocol: (null) > > > > > > > > This looks wrong. Please file a ticket. > > I'm having trouble understanding the problem in order to file a ticket... > > > > > > > > I first upgraded to 389-ds-base-1.3.2.19-1.fc20.x86_64 where I received > > the > > schema errors as well as > > > > > > > > dna-plugin - dna_update_shared_config: Unable to update shared config > > entry: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix- > > ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com [error 65] > > > > > > > > I then upgraded to 389-ds-base-1.3.2.20-1.fc20. Unfortunately, I cannot > > be > > sure what *should* be present for each of dnaRemoteBindMethod and > > dnaRemoteConnProtocol *or* if any original values were deleted when I > > first > > installed 389-ds-base-1.3.2.19-1.fc20.x86_64. If so, how would I know > > what > > the values were? > > > > > > > > I'm not sure. What I think is that these should not be present at all - > > I > > think they are just copied from the replication agreement configuration. > > > > > > > > Also, should the ticket be filed against 389, or against FreeIPA? > > > > > > > > 389 > > Ticket filed: https://fedorahosted.org/389/ticket/47866 > > > > > > > dn: > > dnaHostname=ipa2.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn > > =etc,dc=example,dc=com > > objectClass: dnaSharedConfig > > objectClass: top > > dnaHostname: ipa2.example.com > > dnaPortNum: 389 > > dnaSecurePortNum: 636 > > dnaRemainingValues: 0 > > > > Shouldn't the "second" master also have values for dnaRemoteBindMethod and > > dnaRemoteConnProtocol? For others who may be looking into this issue, I copied the values from the FreeIPA replication agreement: nsDS5ReplicaBindMethod: SASL/GSSAPI nsDS5ReplicaTransportInfo: LDAP and ldapmodify-d as follows: dn: dnaHostname=ipa1.example.com+dnaPortNum=389,cn=posix-ids,cn=dna,cn=ipa,cn =etc,dc=example,dc=com changetype: modify replace: dnaRemoteBindMethod dnaRemoteBindMethod: SASL/GSSAPI - replace: dnaRemoteConnProtocol dnaRemoteConnProtocol: LDAP -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From erinn.looneytriggs at gmail.com Mon Aug 4 22:03:29 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 04 Aug 2014 15:03:29 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <1407185490.18236.14.camel@aleeredhat.laptop> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DA4437.2090001@gmail.com> <1407159397.11870.7.camel@aleeredhat.laptop> <53DF9B65.2060007@gmail.com> <1407173622.11870.19.camel@aleeredhat.laptop> <53DFD052.1050109@gmail.com> <1407178111.18236.5.camel@aleeredhat.laptop> <53DFDA8B.3080405@gmail.com> <1407185490.18236.14.camel@aleeredhat.laptop> Message-ID: <53E00331.8070201@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/04/2014 01:51 PM, Ade Lee wrote: > OK - I suspect you may be running into an issue with serial number > generation. Each time we install a clone, we end up allocating a > new range of serial numbers for the clone. > > The idea is to keep separate ranges for each CA replica so that no > two replicas can issue certs with the same serial number. > > The problem is that you've probably retried the install a whole > bunch of times and now perhaps the serial number range is too > high. > > This is just a guess - but you can see what ranges have been > assigned by looking in : > > 1, ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg > for the master (look for the attributes dbs.* 3. The value of the > attribute nextRange on : ou=certificateRepository, o=ipaca and > ou=Requests, o=ipaca > > Please send me that info, and I'll explain how to clean that up. > > Ade > > On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote: >> On 08/04/2014 11:48 AM, Ade Lee wrote: >>> OK - so its not really even getting started on the install. >>> My guess is there is some cruft from previous >>> installs/uninstalls that was not cleaned up. Is there anything >>> in the directory server logs on the RHEL7 machine? What >>> operation is being attempted that the server is refusing to >>> perform? >>> >>> Ade >>> >> >> Ok I moved on past this issue. Problem was minssf was set to 56 >> on the RHEL 7 dirsrv instance, setting it to 0 resolved this >> issue. Thanks for having me check the dir on the RHEL 7 instance >> I was assuming it was hitting against the RHEL 6.5 instance and >> was finding basically nothing there. >> >> >> This run looks like it pulled a lot more information in but it >> still errored out. >> >> ipa : DEBUG stderr=pkispawn : WARNING ....... >> unable to validate security domain user/password through REST >> interface. Interface not available pkispawn : ERROR ....... >> Exception from Java Configuration Servlet: Error in confguring >> system certificatesjava.security.cert.CertificateException: >> Unable to initialize, java.io.IOException: DerInput.getLength(): >> lengthTag=127, too big. >> >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero >> exit status 1 >> >> From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 >> instance: >> >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with >> mininum 3 and maximum 15 connections to host ipa2.abaqis.com port >> 389, secure connection, false, authentication type 1 >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum >> connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: >> new total available connections 3 >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of >> connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In >> LdapBoundConnFactory::getConn() >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is >> connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: >> getConn: conn is connected true >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: mNumConns >> now 2 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: >> param=preop.internaldb.post_ldif >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif >> file = /usr/share/pki/ca/conf/vlv.ldif >> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif >> file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): >> LDAP Errors in importing >> /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, >> cn=config:netscape.ldap.LDAPException: error result (32); >> matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allInvalidCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allInValidCertsNotBefore-pki-tomcat, cn=ipaca, cn=ldbm >> database, cn=plugins, cn=config:netscape.ldap.LDAPException: >> error result (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allRevokedCaCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allRevokedCertsNotAfter-pki-tomcat, cn=ipaca, cn=ldbm >> database, cn=plugins, cn=config:netscape.ldap.LDAPException: >> error result (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allRevokedExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allRevokedOrRevokedExpiredCaCerts-pki-tomcat, cn=ipaca, >> cn=ldbm database, cn=plugins, >> cn=config:netscape.ldap.LDAPException: error result (32); >> matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allRevokedOrRevokedExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm >> database, cn=plugins, cn=config:netscape.ldap.LDAPException: >> error result (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allValidCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allValidCertsNotAfter-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=allValidOrRevokedCerts-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caAll-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, >> cn=config:netscape.ldap.LDAPException: error result (32); >> matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caCanceled-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, >> cn=config:netscape.ldap.LDAPException: error result (32); >> matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caCanceledEnrollment-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caCanceledRenewal-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caCanceledRevocation-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caComplete-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, >> cn=config:netscape.ldap.LDAPException: error result (32); >> matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caCompleteEnrollment-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caCompleteRenewal-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caCompleteRevocation-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caEnrollment-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caPending-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, >> cn=config:netscape.ldap.LDAPException: error result (32); >> matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caPendingEnrollment-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caPendingRenewal-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caPendingRevocation-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caRejected-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, >> cn=config:netscape.ldap.LDAPException: error result (32); >> matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caRejectedEnrollment-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caRejectedRenewal-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caRejectedRevocation-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caRenewal-pki-tomcat, cn=ipaca, cn=ldbm database, cn=plugins, >> cn=config:netscape.ldap.LDAPException: error result (32); >> matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: >> LDAPUtil:importLDIF: exception in adding entry >> cn=caRevocation-pki-tomcat, cn=ipaca, cn=ldbm database, >> cn=plugins, cn=config:netscape.ldap.LDAPException: error result >> (32); matchedDN = o=ipaca >> >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): ldif >> file = /usr/share/pki/ca/conf/vlvtasks.ldif >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): ldif >> file copy to /var/lib/pki/pki-tomcat/ca/conf/vlvtasks.ldif >> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: Checking wait_dn >> cn=index1160589769, cn=index, cn=tasks, cn=config >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: configCert: caType >> is local [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >> NamePanel: updateConfig() for certTag sslserver >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: updateConfig() >> done [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: Creating >> local certificate... certTag=sslserver >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: In >> LdapBoundConnFactory::getConn() >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: masterConn is >> connected: true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >> getConn: conn is connected true >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: getConn: mNumConns >> now 2 [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: Repository: >> getSerialNumber. [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >> returnConn: mNumConns now 3 Record not found at >> com.netscape.cmscore.dbs.DBSSession.read(DBSSession.java:179) at >> com.netscape.cmscore.dbs.DBSSession.read(DBSSession.java:135) at >> com.netscape.cmscore.dbs.Repository.getSerialNumber(Repository.java:140) >> >> at >> com.netscape.cmscore.dbs.Repository.initCache(Repository.java:259) >> >> at >> com.netscape.cmscore.dbs.Repository.initCacheIfNeeded(Repository.java:331) >> >> at >> com.netscape.cmscore.dbs.CertificateRepository.getNextSerialNumber(CertificateRepository.java:261) >> >> at >> com.netscape.cms.servlet.csadmin.CertUtil.createLocalCert(CertUtil.java:391) >> >> at >> com.netscape.cms.servlet.csadmin.ConfigurationUtils.configCert(ConfigurationUtils.java:2323) >> >> at >> com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:517) >> >> 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) >> >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) >> 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) >> >> at >> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) >> >> at >> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) >> >> at >> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) >> >> at java.security.AccessController.doPrivileged(Native Method) >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) >> >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) >> >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) >> >> at >> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) >> >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) >> >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) >> >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) >> >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) >> >> at >> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) >> >> at >> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) >> >> at >> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) >> >> 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) >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel >> configCert() exception caught:Record not found >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel >> configCert: failed to add metainfo. Exception: >> java.lang.NullPointerException >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: In >> LdapBoundConnFactory::getConn() >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: masterConn is >> connected: true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >> getConn: conn is connected true >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: getConn: mNumConns >> now 2 [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: returnConn: >> mNumConns now 3 [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >> NamePanel configCert: failed to add certificate record. >> Exception: java.lang.NullPointerException >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel update: >> Exception: java.lang.NullPointerException >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: handleCertRequest: >> tag=sslserver [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >> privKeyID=-45cf0bca8e8c04dc7904f4c273f6e3793185c997 >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: handleCertRequest: >> created cert request >> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: handleCerts(): for >> cert tag sslserver >> >> >> >> And from catalina.out on the same system: >> java.security.cert.CertificateException: Unable to initialize, >> java.io.IOException: DerInput.getLength(): lengthTag=127, too >> big. at >> netscape.security.x509.X509CertImpl.(X509CertImpl.java:186) >> >> at >> netscape.security.x509.X509CertImpl.(X509CertImpl.java:160) >> >> at >> com.netscape.cms.servlet.csadmin.ConfigurationUtils.handleCerts(ConfigurationUtils.java:2718) >> >> at >> com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:575) >> >> 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) >> >> at >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) >> >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) >> 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) >> >> at >> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) >> >> at >> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) >> >> at >> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) >> >> at java.security.AccessController.doPrivileged(Native Method) >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) >> >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) >> >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) >> >> at >> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) >> >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) >> >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) >> >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) >> >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) >> >> at >> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) >> >> at >> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) >> >> at >> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) >> >> 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) >> >> And the last bit from pkispawn: 2014-08-04 19:02:40 pkispawn : >> ERROR ....... Exception from Java Configuration Servlet: Error >> in confguring system >> certificatesjava.security.cert.CertificateException: Unable to >> initialize, java.io.IOException: DerInput.getLength(): >> lengthTag=127, too big. 2014-08-04 19:02:40 pkispawn : DEBUG >> ....... Error Type: HTTPError 2014-08-04 19:02:40 pkispawn : >> DEBUG ....... Error Message: 500 Server Error: Internal Server >> Error 2014-08-04 19:02:40 pkispawn : DEBUG ....... File >> "/usr/sbin/pkispawn", line 374, in main rv = instance.spawn() >> File >> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", >> >> line 128, in spawn >> json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File >> "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", >> line 2998, in configure_pki_data response = >> client.configure(data) File >> "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in >> configure r = self.connection.post('/rest/installer/configure', >> data, headers) File >> "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in >> post r.raise_for_status() File >> "/usr/lib/python2.7/site-packages/requests/models.py", line 638, >> in raise_for_status raise http_error >> >> >> -Erinn > > Here you go: dbs.beginReplicaNumber=1 dbs.beginRequestNumber=1 dbs.beginSerialNumber=1 dbs.enableSerialManagement=true dbs.endReplicaNumber=50 dbs.endRequestNumber=9900000 dbs.endSerialNumber=ff60000 dbs.ldap=internaldb dbs.newSchemaEntryAdded=true dbs.replicaCloneTransferNumber=5 dbs.replicaDN=ou=replica dbs.replicaIncrement=100 dbs.replicaLowWaterMark=20 dbs.replicaRangeDN=ou=replica, ou=ranges dbs.requestCloneTransferNumber=10000 dbs.requestDN=ou=ca, ou=requests dbs.requestIncrement=10000000 dbs.requestLowWaterMark=2000000 dbs.requestRangeDN=ou=requests, ou=ranges dbs.serialCloneTransferNumber=10000 dbs.serialDN=ou=certificateRepository, ou=ca dbs.serialIncrement=10000000 dbs.serialLowWaterMark=2000000 dbs.serialRangeDN=ou=certificateRepository, ou=ranges Unfortunately, things seem to have gone further south on the RHEL 6.5 CA instance now. This just seems to be my luck on this replica install. From the debug of the ipa-ca-install: ipa : DEBUG Starting external process ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmp1G6jOw ipa : DEBUG Process finished, return code=1 ipa : DEBUG stdout=Loading deployment configuration from /tmp/tmp1G6jOw. ERROR: Unable to access security domain: 404 Client Error: Not Found ipa : DEBUG stderr= ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmp1G6jOw' returned non-zero exit status 1 I can see in the apache logs on the RHEL 6.5 instance it errors out: [Mon Aug 04 21:06:02 2014] [error] [client 2001:4870:800e:301:862b:2bff:fe67:704d] File does not exist: /var/www/html/ca This is supposed to be mapped via ajp to localhost:9447 which does appear to be listening. Anyway, I am in the throws of that currently, but let me know if those ranges are out of control big. - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT4AMrAAoJEFg7BmJL2iPOzOcIAKTjuVyfVz8TBSkQ/3vyUrMT 3Ro+ybd5ihyiXRXEEIDrZSFJym0rUa6CYGB+xEAZgU2nL92W1XwdfXZg1xyL9usF U/wLxrJnBXUmNe+L+P111VM5PDBct6heAhA9IHpEdt/8w2OqXxoxAy4FdvrPeury as2L1+PPT5tic8BA8ei9SlflGrOMMhlI1tmjfVkn7VER+eT2XkLKwHckjLHMRxFp /lBUFA/FmOsBXc4Gab62ij+feGTZvcazcexBP7jnlQAuHCSo4wgKCN4GiGYmVvam OPKL+OLxOAtPfF9aqYr5UfTCQicj9LWK02V4cfPpO/Gjx7Zay2LJJzxHQ2aNS60= =pdRb -----END PGP SIGNATURE----- From mkosek at redhat.com Tue Aug 5 06:54:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Aug 2014 08:54:38 +0200 Subject: [Freeipa-users] Centos7, selinux, certmonger, and openldap In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E70F7BD@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E70F557@001FSN2MPN1-045.001f.mgd2.msft.net> <82E7C9A01FD0764CACDD35D10F5DFB6E70F594@001FSN2MPN1-045.001f.mgd2.msft.net> <53DF701A.1080304@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E70F7BD@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <53E07FAE.9030406@redhat.com> On 08/04/2014 07:06 PM, Nordgren, Bryce L -FS wrote: > >> Hmm, sorry for incomplete instructions then. I updated the instructions to >> cope with that situation better (details in >> https://fedorahosted.org/freeipa/ticket/4466#comment:2). Please feel free >> to report more findings or even better help us enhance the page even >> further :-) > > Hmm, I thought it looked like your wiki, but when there was no login in the upper-right corner, I assumed it was an online version of your manual. That always gets me, even when I'm looking at a page I know I created myself. Ah, that's a useful UXD feedback as it seems. BTW, to log in, check "Log in / create account with OpenID" in the LOWER right corner... > > In this case, tho, I was definitely not qualified to provide a fix. New to both certmonger and that Mozilla certificate database thing. Don't worry, you will get there. > Made a comment on the talk page about the related OpenLDAP selinux issues (more than one cert_t defined). Dunno if you get notifications. Ok. IMO this is a valid bug, system policy should allow certmonger to manage other cert types. Thanks for filing it. Martin From mkosek at redhat.com Tue Aug 5 07:08:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Aug 2014 09:08:04 +0200 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53E00331.8070201@gmail.com> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DA4437.2090001@gmail.com> <1407159397.11870.7.camel@aleeredhat.laptop> <53DF9B65.2060007@gmail.com> <1407173622.11870.19.camel@aleeredhat.laptop> <53DFD052.1050109@gmail.com> <1407178111.18236.5.camel@aleeredhat.laptop> <53DFDA8B.3080405@gmail.com> <1407185490.18236.14.camel@aleeredhat.laptop> <53E00331.8070201@gmail.com> Message-ID: <53E082D4.9040207@redhat.com> On 08/05/2014 12:03 AM, Erinn Looney-Triggs wrote: > On 08/04/2014 01:51 PM, Ade Lee wrote: >> OK - I suspect you may be running into an issue with serial number >> generation. Each time we install a clone, we end up allocating a new >> range of serial numbers for the clone. > >> The idea is to keep separate ranges for each CA replica so that no two >> replicas can issue certs with the same serial number. > >> The problem is that you've probably retried the install a whole bunch >> of times and now perhaps the serial number range is too high. > >> This is just a guess - but you can see what ranges have been assigned >> by looking in : > >> 1, ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg for >> the master (look for the attributes dbs.* 3. The value of the >> attribute nextRange on : ou=certificateRepository, o=ipaca and >> ou=Requests, o=ipaca > >> Please send me that info, and I'll explain how to clean that up. > >> Ade > >> On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote: >>> On 08/04/2014 11:48 AM, Ade Lee wrote: >>>> OK - so its not really even getting started on the install. My >>>> guess is there is some cruft from previous installs/uninstalls that >>>> was not cleaned up. Is there anything in the directory server logs >>>> on the RHEL7 machine? What operation is being attempted that the >>>> server is refusing to perform? >>>> >>>> Ade >>>> >>> >>> Ok I moved on past this issue. Problem was minssf was set to 56 on >>> the RHEL 7 dirsrv instance, setting it to 0 resolved this issue. >>> Thanks for having me check the dir on the RHEL 7 instance I was >>> assuming it was hitting against the RHEL 6.5 instance and was finding >>> basically nothing there. >>> >>> >>> This run looks like it pulled a lot more information in but it still >>> errored out. >>> >>> ipa : DEBUG stderr=pkispawn : WARNING ....... unable >>> to validate security domain user/password through REST interface. >>> Interface not available pkispawn : ERROR ....... Exception from >>> Java Configuration Servlet: Error in confguring system >>> certificatesjava.security.cert.CertificateException: Unable to >>> initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, >>> too big. >>> >>> ipa : CRITICAL failed to configure ca instance Command >>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero exit >>> status 1 >>> >>> From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 instance: >>> >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with >>> mininum 3 and maximum 15 connections to host ipa2.abaqis.com port >>> 389, secure connection, false, authentication type 1 >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum >>> connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new >>> total available connections 3 >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of >>> connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In >>> LdapBoundConnFactory::getConn() >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is >>> connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: >>> conn is connected true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: >>> getConn: mNumConns now 2 >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: >>> param=preop.internaldb.post_ldif >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif >>> file = /usr/share/pki/ca/conf/vlv.ldif >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif >>> file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): LDAP >>> Errors in importing /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error >>> result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allExpiredCerts-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allInvalidCerts-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allInValidCertsNotBefore-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allRevokedCaCerts-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allRevokedCerts-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allRevokedCertsNotAfter-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allRevokedExpiredCerts-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry >>> cn=allRevokedOrRevokedExpiredCaCerts-pki-tomcat, cn=ipaca, cn=ldbm >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error >>> result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry >>> cn=allRevokedOrRevokedExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error >>> result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allValidCerts-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allValidCertsNotAfter-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=allValidOrRevokedCerts-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caAll-pki-tomcat, cn=ipaca, cn=ldbm >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error >>> result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caCanceled-pki-tomcat, cn=ipaca, cn=ldbm >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error >>> result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caCanceledEnrollment-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caCanceledRenewal-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caCanceledRevocation-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caComplete-pki-tomcat, cn=ipaca, cn=ldbm >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error >>> result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caCompleteEnrollment-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caCompleteRenewal-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caCompleteRevocation-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caEnrollment-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caPending-pki-tomcat, cn=ipaca, cn=ldbm >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error >>> result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caPendingEnrollment-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caPendingRenewal-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caPendingRevocation-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caRejected-pki-tomcat, cn=ipaca, cn=ldbm >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error >>> result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caRejectedEnrollment-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caRejectedRenewal-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caRejectedRevocation-pki-tomcat, >>> cn=ipaca, cn=ldbm database, cn=plugins, >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = >>> o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caRenewal-pki-tomcat, cn=ipaca, cn=ldbm >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error >>> result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: >>> exception in adding entry cn=caRevocation-pki-tomcat, cn=ipaca, >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: >>> error result (32); matchedDN = o=ipaca >>> >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): ldif >>> file = /usr/share/pki/ca/conf/vlvtasks.ldif >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): ldif >>> file copy to /var/lib/pki/pki-tomcat/ca/conf/vlvtasks.ldif >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: Checking wait_dn >>> cn=index1160589769, cn=index, cn=tasks, cn=config >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: configCert: caType is >>> local [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel: >>> updateConfig() for certTag sslserver >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: updateConfig() done >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: Creating local >>> certificate... certTag=sslserver >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: In >>> LdapBoundConnFactory::getConn() >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: masterConn is >>> connected: true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: getConn: >>> conn is connected true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >>> getConn: mNumConns now 2 >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: Repository: >>> getSerialNumber. [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >>> returnConn: mNumConns now 3 Record not found at >>> com.netscape.cmscore.dbs.DBSSession.read(DBSSession.java:179) at >>> com.netscape.cmscore.dbs.DBSSession.read(DBSSession.java:135) at >>> com.netscape.cmscore.dbs.Repository.getSerialNumber(Repository.java:140) >>> >>> > >>> >>> at >>> com.netscape.cmscore.dbs.Repository.initCache(Repository.java:259) >>> >>> > at >>> com.netscape.cmscore.dbs.Repository.initCacheIfNeeded(Repository.java:331) >>> >>> > >>> >>> at >>> com.netscape.cmscore.dbs.CertificateRepository.getNextSerialNumber(CertificateRepository.java:261) >>> >>> > >>> >>> at >>> com.netscape.cms.servlet.csadmin.CertUtil.createLocalCert(CertUtil.java:391) >>> >>> > >>> >>> at >>> com.netscape.cms.servlet.csadmin.ConfigurationUtils.configCert(ConfigurationUtils.java:2323) >>> >>> > >>> >>> at >>> com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:517) >>> >>> > >>> >>> 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) >>> >>> > >>> >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) >>> >>> > >>> >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) >>> >>> > >>> >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) >>> >>> > >>> >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) >>> 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) >>> >>> > >>> >>> at >>> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) >>> >>> > >>> >>> at >>> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) >>> >>> > >>> >>> at >>> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) >>> >>> > >>> >>> at java.security.AccessController.doPrivileged(Native Method) >>> at >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) >>> >>> > >>> >>> at >>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) >>> >>> > >>> >>> at >>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) >>> >>> > >>> >>> at >>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) >>> >>> > >>> >>> at >>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) >>> >>> > >>> >>> at >>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) >>> >>> > >>> >>> at >>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) >>> >>> > >>> >>> at >>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) >>> >>> > >>> >>> at >>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) >>> >>> > >>> >>> at >>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) >>> >>> > >>> >>> at >>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) >>> >>> > >>> >>> 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) >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel configCert() >>> exception caught:Record not found >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel configCert: >>> failed to add metainfo. Exception: java.lang.NullPointerException >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: In >>> LdapBoundConnFactory::getConn() >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: masterConn is >>> connected: true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: getConn: >>> conn is connected true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >>> getConn: mNumConns now 2 >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: returnConn: mNumConns >>> now 3 [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel >>> configCert: failed to add certificate record. Exception: >>> java.lang.NullPointerException >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel update: >>> Exception: java.lang.NullPointerException >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: handleCertRequest: >>> tag=sslserver [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >>> privKeyID=-45cf0bca8e8c04dc7904f4c273f6e3793185c997 >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: handleCertRequest: >>> created cert request [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: >>> handleCerts(): for cert tag sslserver >>> >>> >>> >>> And from catalina.out on the same system: >>> java.security.cert.CertificateException: Unable to initialize, >>> java.io.IOException: DerInput.getLength(): lengthTag=127, too big. at >>> netscape.security.x509.X509CertImpl.(X509CertImpl.java:186) >>> >>> > at >>> netscape.security.x509.X509CertImpl.(X509CertImpl.java:160) >>> >>> > at >>> com.netscape.cms.servlet.csadmin.ConfigurationUtils.handleCerts(ConfigurationUtils.java:2718) >>> >>> > >>> >>> at >>> com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:575) >>> >>> > >>> >>> 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) >>> >>> > >>> >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) >>> >>> > >>> >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) >>> >>> > >>> >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) >>> >>> > >>> >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) >>> >>> > >>> >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) >>> 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) >>> >>> > >>> >>> at >>> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) >>> >>> > >>> >>> at >>> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) >>> >>> > >>> >>> at >>> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) >>> >>> > >>> >>> at java.security.AccessController.doPrivileged(Native Method) >>> at >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) >>> >>> > >>> >>> at >>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) >>> >>> > >>> >>> at >>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) >>> >>> > >>> >>> at >>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) >>> >>> > >>> >>> at >>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) >>> >>> > >>> >>> at >>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) >>> >>> > >>> >>> at >>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) >>> >>> > >>> >>> at >>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) >>> >>> > >>> >>> at >>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) >>> >>> > >>> >>> at >>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) >>> >>> > >>> >>> at >>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) >>> >>> > >>> >>> 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) >>> >>> And the last bit from pkispawn: 2014-08-04 19:02:40 pkispawn : >>> ERROR ....... Exception from Java Configuration Servlet: Error in >>> confguring system >>> certificatesjava.security.cert.CertificateException: Unable to >>> initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, >>> too big. 2014-08-04 19:02:40 pkispawn : DEBUG ....... Error Type: >>> HTTPError 2014-08-04 19:02:40 pkispawn : DEBUG ....... Error >>> Message: 500 Server Error: Internal Server Error 2014-08-04 19:02:40 >>> pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 374, >>> in main rv = instance.spawn() File >>> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", >>> >>> > line 128, in spawn >>> json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File >>> "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", line >>> 2998, in configure_pki_data response = client.configure(data) File >>> "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in >>> configure r = self.connection.post('/rest/installer/configure', data, >>> headers) File "/usr/lib/python2.7/site-packages/pki/client.py", line >>> 64, in post r.raise_for_status() File >>> "/usr/lib/python2.7/site-packages/requests/models.py", line 638, in >>> raise_for_status raise http_error >>> >>> >>> -Erinn > > > > Here you go: dbs.beginReplicaNumber=1 dbs.beginRequestNumber=1 > dbs.beginSerialNumber=1 dbs.enableSerialManagement=true > dbs.endReplicaNumber=50 dbs.endRequestNumber=9900000 > dbs.endSerialNumber=ff60000 dbs.ldap=internaldb > dbs.newSchemaEntryAdded=true dbs.replicaCloneTransferNumber=5 > dbs.replicaDN=ou=replica dbs.replicaIncrement=100 > dbs.replicaLowWaterMark=20 dbs.replicaRangeDN=ou=replica, ou=ranges > dbs.requestCloneTransferNumber=10000 dbs.requestDN=ou=ca, ou=requests > dbs.requestIncrement=10000000 dbs.requestLowWaterMark=2000000 > dbs.requestRangeDN=ou=requests, ou=ranges > dbs.serialCloneTransferNumber=10000 > dbs.serialDN=ou=certificateRepository, ou=ca dbs.serialIncrement=10000000 > dbs.serialLowWaterMark=2000000 dbs.serialRangeDN=ou=certificateRepository, > ou=ranges > > Unfortunately, things seem to have gone further south on the RHEL 6.5 CA > instance now. This just seems to be my luck on this replica install. From > the debug of the ipa-ca-install: ipa : DEBUG Starting external > process ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f > /tmp/tmp1G6jOw ipa : DEBUG Process finished, return code=1 ipa > : DEBUG stdout=Loading deployment configuration from /tmp/tmp1G6jOw. > ERROR: Unable to access security domain: 404 Client Error: Not Found > > ipa : DEBUG stderr= ipa : CRITICAL failed to configure > ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmp1G6jOw' returned > non-zero exit status 1 > > I can see in the apache logs on the RHEL 6.5 instance it errors out: [Mon > Aug 04 21:06:02 2014] [error] [client > 2001:4870:800e:301:862b:2bff:fe67:704d] File does not exist: > /var/www/html/ca > > This is supposed to be mapped via ajp to localhost:9447 which does appear > to be listening. Anyway, I am in the throws of that currently, but let me > know if those ranges are out of control big. > > -Erinn Could this be caused by https://bugzilla.redhat.com/show_bug.cgi?id=1083878? You could check access log to see what calls are being made by 7.0 replica. This will be fixed in 6.6, I am afraid that for 6.5 you will have to do the update (adding "|^/ca/ee/ca/profileSubmit") yourself. Martin From mkosek at redhat.com Tue Aug 5 07:45:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Aug 2014 09:45:29 +0200 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53DFF014.6070808@gmail.com> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DEC014.1060604@gmail.com> <53DEF3CE.3010000@gmail.com> <53DF681B.4000800@redhat.com> <53DF9D57.8040105@gmail.com> <53DFAAE9.90803@redhat.com> <53DFF014.6070808@gmail.com> Message-ID: <53E08B99.3020909@redhat.com> On 08/04/2014 10:41 PM, Erinn Looney-Triggs wrote: > On 08/04/2014 08:46 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> On 08/04/2014 04:01 AM, Martin Kosek wrote: >>>> On 08/04/2014 04:45 AM, Erinn Looney-Triggs wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Whether related or not I am getting the following in my >>>>>> RHEL 6.5 IPA instance /var/log/dirsrv/slapd-PKI-CA/debug >>>>>> log: >>>>> >>>>>> [26/Jul/2014:20:23:23 +0000] slapi_ldap_bind - Error: >>>>>> could not send startTLS re quest: error -1 (Can't contact >>>>>> LDAP server) errno 107 (Transport endpoint is not >>>>>> connected) [26/Jul/2014:20:23:23 +0000] >>>>>> NSMMReplicationPlugin - agmt="cn=masterAgreement1-i >>>>>> pa2.example.com-pki-ca" (ipa2:7389): Replication bind with >>>>>> SIMPLE auth failed: LD AP error -1 (Can't contact LDAP >>>>>> server) ((null)) [26/Jul/2014:20:23:37 +0000] >>>>>> slapi_ldap_bind - Error: could not send startTLS re quest: >>>>>> error -1 (Can't contact LDAP server) errno 107 (Transport >>>>>> endpoint is not connected) [26/Jul/2014:20:23:48 +0000] >>>>>> slapi_ldap_bind - Error: could not send startTLS re quest: >>>>>> error -1 (Can't contact LDAP server) errno 107 (Transport >>>>>> endpoint is not connected) >>>>> >>>>>> And these errors just continue to be logged. >>>>> >>>>>> When attempting to run ipa-ca-install -d on the RHEL 7 >>>>>> replica (all other services are on there running fine) I >>>>>> receive the following: >>>>> >>>>>> ipa : CRITICAL failed to configure ca instance >>>>>> Command '/usr/sbin/pkispawn -vv -s CA -f /tmp/tmpqd0WwF' >>>>>> returned non-zero exit status 1 ipa : DEBUG >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>> >>>>> >>>>> >>>>>> >>> >>>>>> > line 638, in run_script >>>>>> return_value = main_function() >>>>> >>>>>> File "/usr/sbin/ipa-ca-install", line 179, in main CA = >>>>>> cainstance.install_replica_ca(config, postinstall=True) >>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> >>>>> >>>>> >>>>>> >>> >>>>>> > line 1678, in install_replica_ca >>>>>> subject_base=config.subject_base) >>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> >>>>> >>>>> >>>>>> >>> >>>>>> > line 478, in configure_instance >>>>>> self.start_creation(runtime=210) >>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>>> >>>>>> >>> >>>>>> > line 364, in start_creation method() >>>>> >>>>>> File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> >>>>> >>>>> >>>>>> >>> >>>>>> > line 604, in __spawn_instance >>>>>> raise RuntimeError('Configuration of CA failed') >>>>> >>>>>> ipa : DEBUG The ipa-ca-install command failed, >>>>>> exception: RuntimeError: Configuration of CA failed >>>>> >>>>>> Your system may be partly configured. Run >>>>>> /usr/sbin/ipa-server-install --uninstall to clean up. >>>>> >>>>>> Configuration of CA failed >>>>> >>>>> >>>>>> So this behavior changed after restarting the IPA service >>>>>> on the RHEL 6.5 system. >>>>> >>>>>> So at this point I have a RHEL 6.5 system and a RHEL 7 >>>>>> replica of everything except the CA. The RHEL 6.5 system, >>>>>> when the IPA service is restarted throws an error, perhaps >>>>>> from schema change? >>>>> >>>>>> Any ideas? >>>>> >>>>>> -Erinn >>>>> >>>>> >>>>> >>>>> I went in and debugged this a bit further by changing the >>>>> verbosity for nsslapd-errorlog-level. It appears that the >>>>> rhel 6.5 system is attempting to connect to the RHEL 7 system >>>>> on port 7389 and since the RHEL 7 system does not have the CA >>>>> installed this would obviously fail. This leads me to believe >>>>> that there is cruft in the directory that is pointing to the >>>>> wrong place. I don't think this will fix my second group of >>>>> errors, but how does one view the replication agreements >>>>> specifically for the ca? >>>>> >>>>> As well I omitted to lines from the ipa-ca-install error >>>>> which are probably pertinent: >>>>> >>>>> ERROR: Unable to access directory server: Server is >>>>> unwilling to perform >>>>> >>>>> ipa : DEBUG stderr= >>>>> >>>>> -Erinn >>> >>>> This is strange. ipa-ca-install/ipa-replica-install --setup-ca >>>> should create the replication agreement pointing at port 389 >>>> on RHEL-7.0, given that the 2 originally separated DS databases >>>> were merged. >>> >>>> It looks like this is some replication agreement left over >>>> from previous tests. >>> >>>> Anyway, to list all hosts with PKI, try: >>> >>>> # ipa-csreplica-manage list Directory Manager password: >>> >>>> vm-089.idm.lab.bos.redhat.com: master >>>> vm-086.idm.lab.bos.redhat.com: master >>> >>>> "master" means that this server has PKI service installed. It >>>> will show different value if there is no PKI service. >>> >>>> To check PKI replication agreements for specific hostname, >>>> run: >>> >>>> # ipa-csreplica-manage list `hostname` Directory Manager >>>> password: >>> >>>> vm-089.idm.lab.bos.redhat.com >>> >>>> Check "man ipa-csreplica-manage" for advise how to delete or >>>> create the PKI agreements. >>> >>>> HTH, Martin >>> >>> >>> Yeah here is what I get: ipa-csreplica-manage list Directory >>> Manager password: >>> >>> ipa2.example.com: CA not configured ipa.example.com: master >>> >>> ipa2 is my rhel7 instance, ipa is the rhel 6.5 instance. >>> >>> ipa-csreplica-manage list ipa2.example.com Directory Manager >>> password: >>> >>> Can't contact LDAP server >>> >>> Which I guess makes sense, however: ipa-csreplica-manage list -v >>> ipa.example.com Directory Manager password: >>> >>> ipa2.example.com last init status: None last init ended: None >>> last update status: -1 - LDAP error: Can't contact LDAP server >>> last update ended: None ipa2.example.com last init status: None >>> last init ended: None last update status: 0 Replica acquired >>> successfully: Incremental update succeeded last update ended: >>> 2014-08-04 14:43:48+00:00 >>> >>> This seems odd to me, but I don't really know exactly what to >>> expect. Why is ipa2 referenced twice? Why does on have >>> replication succeeding and the other failing? >>> >>> It currently just feels like something is configured wrong, there >>> is a wrong entry somewhere, but I can't figure it out just yet. > >> As Directory Manager, look in cn=mapping tree,cn=config for the >> list of agreements. I'm guessing at least one of those has the >> wrong port. > >> The IPA agreement CN takes the form of meTo and CA >> agreements CN uses masterAgreement1--* (or >> cloneAgreement, depending on the side you're on). > >> rob > > > Rob, > Thanks, looking in there I see two entries for my ipa2 instance for CA > replication. However, none should exist as far as I know because at > this point there is no CA replica on ipa2. These safe to delete? > > -Erinn > Yes, it should be able to delete them. They are possibly left-overs from some of your earlier testing. Some confusion may appear from the fact, that on RHEL-6.5, there are 2 DS instances. One running on 389 serving the main suffix, one running on 7389 serving the PKI database. Normally, when CA is not configured, RHEL-6.5 server should have just one replication agreement with RHEL-7.0 DS for the main suffix. When CA is configured, RHEL-6.5 DS on port 389 will still have one replication agreement with RHEL-7.0 DS (main suffix), but there will be also second replication agreement in RHEL-6.5 DS on port 7389 with RHEL-7.0 DS. As you can guess, RHEL-7.0 will have two replication agreements in this case, one with IPA DS and one with PKI DS. ipa-cs-replica-manage from my RHEL-6.5: # ipa-csreplica-manage list Directory Manager password: rhel7.example.com: master rhel6.example.com: master # ipa-csreplica-manage list `hostname` Directory Manager password: rhel7.example.com ipa-cs-replica-manage from my RHEL-7.0: # ipa-csreplica-manage list Directory Manager password: rhel6.example.com: master rhel7.example.com: master # ipa-csreplica-manage list `hostname` Directory Manager password: rhel6.example.com HTH, Martin From yamakasi.014 at gmail.com Tue Aug 5 09:24:00 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 5 Aug 2014 11:24:00 +0200 Subject: [Freeipa-users] IPA Replica does not start Bind but runs Manually In-Reply-To: <53DF40BB.3060502@redhat.com> References: <1407109927.19681.36.camel@willson.usersys.redhat.com> <53DF40BB.3060502@redhat.com> Message-ID: Hi, I got this solved but the replica doesn't do it's forwards on the zone's it need to foreward for, the master with the same settings does. I have done a new install but the same happens. WHat could be wrong here ? Cheers, Matt 2014-08-04 10:13 GMT+02:00 Martin Kosek : > On 08/04/2014 09:40 AM, Matt . wrote: >> Hi, >> >> Yes I did in the past. THe DNS tabs are there and named is installed. > > You probably installed DNS service on another FreeIPA server. However, there is > a configuration space telling which server has which services configured. It > seems that it does not see your current server as the DNS server. > >> Can I run that "over" without any issue ? > > Yes, If it detects that DNS service was already installed there it will error > out. Then we will do different route. > >> In any other case I just can reinstall the ipa software on the replica >> and create a new setup for it... > > Let's not go this way (yet), simple DNS service installation should be work. > > Martin From knighcl at gmail.com Tue Aug 5 10:05:38 2014 From: knighcl at gmail.com (Curtis L. Knight) Date: Tue, 5 Aug 2014 06:05:38 -0400 Subject: [Freeipa-users] Building previous release rpms are failing Message-ID: Hey, I have been trying to build rpms from different releases without much success. I can build 4.0+ rpms but I have not tested them. Going backward like with release-3-3-5, it fails on lint/pylint routine. I comment out the lint call in the Makefile and further along it cannot find some ui files. I got this setup to use docker to generate the rpms. Included below are the sequences and commands. for current release that does build without intervention: # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 release-4-0-1 or for master # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 for previous release # docker run -ti --name freeipa-devel-rpms-container knighcl/freeipa-devel-rpms:fedora-20 release-3-3-5 Once dropped into the terminal upon finishing, I edit the Makefile to comment out the make-lint line within the lint stanza #./make-lint $(LINT_OPTIONS) run 'make rpms' again to get beyond lint errors shown below cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi ./make-lint Traceback (most recent call last): File "./make-lint", line 272, in sys.exit(main()) File "./make-lint", line 243, in main linter.check(files) File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 626, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 712, in check_astroid_module walker.walk(astroid) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 715, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 715, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 712, in walk cb(astroid) File "/usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py", line 135, in visit_function args=(call.args[0].name, )) AttributeError: 'Getattr' object has no attribute 'name' make: *** [lint] Error 1 The final errors from the build are below. I tried to find the jdennis building/ci script to see if there is something I am missing but I am guessing it is on the build system. This was an exercise on building rpms and learning docker to possibly help the developers out with a new process. I do not need to do this successfully but thought you might want to know that something might not be proper. Regards, Curtis rpm 3.3.5 log /usr/bin/mkdir -p '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/dojo' /usr/bin/install -c -m 644 -p dojo.js '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/dojo' make[6]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/dojo' make[5]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/dojo' Making install in freeipa make[5]: Entering directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' ../../util/make-ui.sh Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/compile.sh: line 114: pushd: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa: No such file or directory Invalid build dir: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa make[6]: Entering directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' make[6]: Nothing to be done for `install-exec-am'. ../../util/make-ui.sh Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/compile.sh: line 114: pushd: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa: No such file or directory Invalid build dir: /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa /usr/bin/mkdir -p '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' /usr/bin/install -c -m 644 -p ./app.js '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' /usr/bin/install: cannot stat './app.js': No such file or directory make[6]: *** [install-appDATA] Error 1 make[6]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' make[5]: *** [install-am] Error 2 make[5]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' make[4]: *** [install-recursive] Error 1 make[4]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install' make[1]: *** [install] Error 1 make[1]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595' error: Bad exit status from /var/tmp/rpm-tmp.4ZvCpe (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.4ZvCpe (%install) make: *** [rpms] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Aug 5 10:32:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Aug 2014 12:32:17 +0200 Subject: [Freeipa-users] Building previous release rpms are failing In-Reply-To: References: Message-ID: <53E0B2B1.2040002@redhat.com> On 08/05/2014 12:05 PM, Curtis L. Knight wrote: > Hey, > > I have been trying to build rpms from different releases without much > success. I can build 4.0+ rpms but I have not tested them. Going backward > like with release-3-3-5, it fails on lint/pylint routine. I comment out the > lint call in the Makefile and further along it cannot find some ui files. You could also run $ make rpms DEVELOPER_MODE=1 to have the lint run, but ignored it's results (though fixing the bug it is better of course). > > I got this setup to use docker to generate the rpms. Included below are the > sequences and commands. > > for current release that does build without intervention: > # docker run -ti --name freeipa-devel-rpms-container > knighcl/freeipa-devel-rpms:fedora-20 release-4-0-1 > > or for master > > # docker run -ti --name freeipa-devel-rpms-container > knighcl/freeipa-devel-rpms:fedora-20 > > for previous release > # docker run -ti --name freeipa-devel-rpms-container > knighcl/freeipa-devel-rpms:fedora-20 release-3-3-5 > > Once dropped into the terminal upon finishing, I edit the Makefile to > comment out the make-lint line within the lint stanza > > #./make-lint $(LINT_OPTIONS) > > run 'make rpms' again to get beyond lint errors shown below > > > cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr > --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi > ./make-lint > Traceback (most recent call last): > File "./make-lint", line 272, in > sys.exit(main()) > File "./make-lint", line 243, in main > linter.check(files) > File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 626, in check > self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) > File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 712, in > check_astroid_module > walker.walk(astroid) > File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 715, in walk > self.walk(child) > File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 715, in walk > self.walk(child) > File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 712, in walk > cb(astroid) > File "/usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py", > line 135, in visit_function > args=(call.args[0].name, )) > AttributeError: 'Getattr' object has no attribute 'name' > make: *** [lint] Error 1 This is new, I created upstream ticket to timely fix it: https://fedorahosted.org/freeipa/ticket/4475 > The final errors from the build are below. I tried to find the jdennis > building/ci script to see if there is something I am missing but I am > guessing it is on the build system. This was an exercise on building rpms > and learning docker to possibly help the developers out with a new process. > I do not need to do this successfully but thought you might want to know > that something might not be proper. > > Regards, > Curtis > > rpm 3.3.5 log > /usr/bin/mkdir -p > '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/dojo' > /usr/bin/install -c -m 644 -p dojo.js > '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/dojo' > make[6]: Leaving directory > `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/dojo' > make[5]: Leaving directory > `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/dojo' > Making install in freeipa > make[5]: Entering directory > `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' > ../../util/make-ui.sh > Error: Could not find or load main class > org.mozilla.javascript.tools.shell.Main > Error: Could not find or load main class > org.mozilla.javascript.tools.shell.Main > Error: Could not find or load main class > org.mozilla.javascript.tools.shell.Main > /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/compile.sh: > line 114: pushd: > /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa: > No such file or directory > Invalid build dir: > /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa > make[6]: Entering directory > `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' > make[6]: Nothing to be done for `install-exec-am'. > ../../util/make-ui.sh > Error: Could not find or load main class > org.mozilla.javascript.tools.shell.Main > Error: Could not find or load main class > org.mozilla.javascript.tools.shell.Main > Error: Could not find or load main class > org.mozilla.javascript.tools.shell.Main > /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/compile.sh: > line 114: pushd: > /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa: > No such file or directory > Invalid build dir: > /freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/util/../release/lib/freeipa > /usr/bin/mkdir -p > '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' > /usr/bin/install -c -m 644 -p ./app.js > '/freeipa/rpmbuild/BUILDROOT/freeipa-3.3.5GITd366595-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' > /usr/bin/install: cannot stat './app.js': No such file or directory > make[6]: *** [install-appDATA] Error 1 > make[6]: Leaving directory > `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' > make[5]: *** [install-am] Error 2 > make[5]: Leaving directory > `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build/freeipa' > make[4]: *** [install-recursive] Error 1 > make[4]: Leaving directory > `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui/build' > make[3]: *** [install-recursive] Error 1 > make[3]: Leaving directory > `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install/ui' > make[2]: *** [install-recursive] Error 1 > make[2]: Leaving directory > `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595/install' > make[1]: *** [install] Error 1 > make[1]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.3.5GITd366595' > error: Bad exit status from /var/tmp/rpm-tmp.4ZvCpe (%install) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.4ZvCpe (%install) > make: *** [rpms] Error 1 This is caused by missing build dependency on rhino. I cherry-picked the patch fixing this error and pushed to ipa-3-3 branch. With that patch available + DEVELOPER_MODE workaround, you should be able to have your build running. HTH, Martin From mkosek at redhat.com Tue Aug 5 11:21:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 05 Aug 2014 13:21:10 +0200 Subject: [Freeipa-users] Building previous release rpms are failing In-Reply-To: <53E0B2B1.2040002@redhat.com> References: <53E0B2B1.2040002@redhat.com> Message-ID: <53E0BE26.4070204@redhat.com> On 08/05/2014 12:32 PM, Martin Kosek wrote: > On 08/05/2014 12:05 PM, Curtis L. Knight wrote: ... >> #./make-lint $(LINT_OPTIONS) >> >> run 'make rpms' again to get beyond lint errors shown below >> >> >> cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr >> --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi >> ./make-lint >> Traceback (most recent call last): >> File "./make-lint", line 272, in >> sys.exit(main()) >> File "./make-lint", line 243, in main >> linter.check(files) >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 626, in check >> self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 712, in >> check_astroid_module >> walker.walk(astroid) >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 715, in walk >> self.walk(child) >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 715, in walk >> self.walk(child) >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 712, in walk >> cb(astroid) >> File "/usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py", >> line 135, in visit_function >> args=(call.args[0].name, )) >> AttributeError: 'Getattr' object has no attribute 'name' >> make: *** [lint] Error 1 > > This is new, I created upstream ticket to timely fix it: > https://fedorahosted.org/freeipa/ticket/4475 Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch should now build OK again. Martin From alee at redhat.com Tue Aug 5 13:25:22 2014 From: alee at redhat.com (Ade Lee) Date: Tue, 05 Aug 2014 09:25:22 -0400 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53E082D4.9040207@redhat.com> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DA4437.2090001@gmail.com> <1407159397.11870.7.camel@aleeredhat.laptop> <53DF9B65.2060007@gmail.com> <1407173622.11870.19.camel@aleeredhat.laptop> <53DFD052.1050109@gmail.com> <1407178111.18236.5.camel@aleeredhat.laptop> <53DFDA8B.3080405@gmail.com> <1407185490.18236.14.camel@aleeredhat.laptop> <53E00331.8070201@gmail.com> <53E082D4.9040207@redhat.com> Message-ID: <1407245122.2579.3.camel@aleeredhat.laptop> On Tue, 2014-08-05 at 09:08 +0200, Martin Kosek wrote: > On 08/05/2014 12:03 AM, Erinn Looney-Triggs wrote: > > On 08/04/2014 01:51 PM, Ade Lee wrote: > >> OK - I suspect you may be running into an issue with serial number > >> generation. Each time we install a clone, we end up allocating a new > >> range of serial numbers for the clone. > > > >> The idea is to keep separate ranges for each CA replica so that no two > >> replicas can issue certs with the same serial number. > > > >> The problem is that you've probably retried the install a whole bunch > >> of times and now perhaps the serial number range is too high. > > > >> This is just a guess - but you can see what ranges have been assigned > >> by looking in : > > > >> 1, ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg for > >> the master (look for the attributes dbs.* 3. The value of the > >> attribute nextRange on : ou=certificateRepository, o=ipaca and > >> ou=Requests, o=ipaca > > > >> Please send me that info, and I'll explain how to clean that up. > > > >> Ade > > > >> On Mon, 2014-08-04 at 12:10 -0700, Erinn Looney-Triggs wrote: > >>> On 08/04/2014 11:48 AM, Ade Lee wrote: > >>>> OK - so its not really even getting started on the install. My > >>>> guess is there is some cruft from previous installs/uninstalls that > >>>> was not cleaned up. Is there anything in the directory server logs > >>>> on the RHEL7 machine? What operation is being attempted that the > >>>> server is refusing to perform? > >>>> > >>>> Ade > >>>> > >>> > >>> Ok I moved on past this issue. Problem was minssf was set to 56 on > >>> the RHEL 7 dirsrv instance, setting it to 0 resolved this issue. > >>> Thanks for having me check the dir on the RHEL 7 instance I was > >>> assuming it was hitting against the RHEL 6.5 instance and was finding > >>> basically nothing there. > >>> > >>> > >>> This run looks like it pulled a lot more information in but it still > >>> errored out. > >>> > >>> ipa : DEBUG stderr=pkispawn : WARNING ....... unable > >>> to validate security domain user/password through REST interface. > >>> Interface not available pkispawn : ERROR ....... Exception from > >>> Java Configuration Servlet: Error in confguring system > >>> certificatesjava.security.cert.CertificateException: Unable to > >>> initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, > >>> too big. > >>> > >>> ipa : CRITICAL failed to configure ca instance Command > >>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpbTnSRM' returned non-zero exit > >>> status 1 > >>> > >>> From the /var/log/pki/pki-tomcat/ca/debug log on the RHEL 7 instance: > >>> > >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: initializing with > >>> mininum 3 and maximum 15 connections to host ipa2.abaqis.com port > >>> 389, secure connection, false, authentication type 1 > >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: increasing minimum > >>> connections by 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new > >>> total available connections 3 > >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: new number of > >>> connections 3 [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: In > >>> LdapBoundConnFactory::getConn() > >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: masterConn is > >>> connected: true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: getConn: > >>> conn is connected true [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: > >>> getConn: mNumConns now 2 > >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS: > >>> param=preop.internaldb.post_ldif > >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif > >>> file = /usr/share/pki/ca/conf/vlv.ldif > >>> [04/Aug/2014:19:02:36][http-bio-8443-exec-3]: importLDIFS(): ldif > >>> file copy to /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): LDAP > >>> Errors in importing /var/lib/pki/pki-tomcat/ca/conf/vlv.ldif > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allCerts-pki-tomcat, cn=ipaca, cn=ldbm > >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error > >>> result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allExpiredCerts-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allInvalidCerts-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allInValidCertsNotBefore-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allNonRevokedCerts-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allRevokedCaCerts-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allRevokedCerts-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allRevokedCertsNotAfter-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allRevokedExpiredCerts-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry > >>> cn=allRevokedOrRevokedExpiredCaCerts-pki-tomcat, cn=ipaca, cn=ldbm > >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error > >>> result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry > >>> cn=allRevokedOrRevokedExpiredCerts-pki-tomcat, cn=ipaca, cn=ldbm > >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error > >>> result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allValidCerts-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allValidCertsNotAfter-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=allValidOrRevokedCerts-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caAll-pki-tomcat, cn=ipaca, cn=ldbm > >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error > >>> result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caCanceled-pki-tomcat, cn=ipaca, cn=ldbm > >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error > >>> result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caCanceledEnrollment-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caCanceledRenewal-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caCanceledRevocation-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caComplete-pki-tomcat, cn=ipaca, cn=ldbm > >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error > >>> result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caCompleteEnrollment-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caCompleteRenewal-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caCompleteRevocation-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caEnrollment-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caPending-pki-tomcat, cn=ipaca, cn=ldbm > >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error > >>> result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caPendingEnrollment-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caPendingRenewal-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caPendingRevocation-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caRejected-pki-tomcat, cn=ipaca, cn=ldbm > >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error > >>> result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caRejectedEnrollment-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caRejectedRenewal-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caRejectedRevocation-pki-tomcat, > >>> cn=ipaca, cn=ldbm database, cn=plugins, > >>> cn=config:netscape.ldap.LDAPException: error result (32); matchedDN = > >>> o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caRenewal-pki-tomcat, cn=ipaca, cn=ldbm > >>> database, cn=plugins, cn=config:netscape.ldap.LDAPException: error > >>> result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: LDAPUtil:importLDIF: > >>> exception in adding entry cn=caRevocation-pki-tomcat, cn=ipaca, > >>> cn=ldbm database, cn=plugins, cn=config:netscape.ldap.LDAPException: > >>> error result (32); matchedDN = o=ipaca > >>> > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): ldif > >>> file = /usr/share/pki/ca/conf/vlvtasks.ldif > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: importLDIFS(): ldif > >>> file copy to /var/lib/pki/pki-tomcat/ca/conf/vlvtasks.ldif > >>> [04/Aug/2014:19:02:37][http-bio-8443-exec-3]: Checking wait_dn > >>> cn=index1160589769, cn=index, cn=tasks, cn=config > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: configCert: caType is > >>> local [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel: > >>> updateConfig() for certTag sslserver > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: updateConfig() done > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: Creating local > >>> certificate... certTag=sslserver > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: In > >>> LdapBoundConnFactory::getConn() > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: masterConn is > >>> connected: true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: getConn: > >>> conn is connected true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: > >>> getConn: mNumConns now 2 > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: Repository: > >>> getSerialNumber. [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: > >>> returnConn: mNumConns now 3 Record not found at > >>> com.netscape.cmscore.dbs.DBSSession.read(DBSSession.java:179) at > >>> com.netscape.cmscore.dbs.DBSSession.read(DBSSession.java:135) at > >>> com.netscape.cmscore.dbs.Repository.getSerialNumber(Repository.java:140) > >>> > >>> > > > >>> > >>> > at > >>> com.netscape.cmscore.dbs.Repository.initCache(Repository.java:259) > >>> > >>> > > at > >>> com.netscape.cmscore.dbs.Repository.initCacheIfNeeded(Repository.java:331) > >>> > >>> > > > >>> > >>> > at > >>> com.netscape.cmscore.dbs.CertificateRepository.getNextSerialNumber(CertificateRepository.java:261) > >>> > >>> > > > >>> > >>> > at > >>> com.netscape.cms.servlet.csadmin.CertUtil.createLocalCert(CertUtil.java:391) > >>> > >>> > > > >>> > >>> > at > >>> com.netscape.cms.servlet.csadmin.ConfigurationUtils.configCert(ConfigurationUtils.java:2323) > >>> > >>> > > > >>> > >>> > at > >>> com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:517) > >>> > >>> > > > >>> > >>> > 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) > >>> > >>> > > > >>> > >>> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > >>> 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) > >>> > >>> > > > >>> > >>> > at java.security.AccessController.doPrivileged(Native Method) > >>> at > >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) > >>> > >>> > > > >>> > >>> > 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) > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel configCert() > >>> exception caught:Record not found > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel configCert: > >>> failed to add metainfo. Exception: java.lang.NullPointerException > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: In > >>> LdapBoundConnFactory::getConn() > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: masterConn is > >>> connected: true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: getConn: > >>> conn is connected true [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: > >>> getConn: mNumConns now 2 > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: returnConn: mNumConns > >>> now 3 [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel > >>> configCert: failed to add certificate record. Exception: > >>> java.lang.NullPointerException > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: NamePanel update: > >>> Exception: java.lang.NullPointerException > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: handleCertRequest: > >>> tag=sslserver [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: > >>> privKeyID=-45cf0bca8e8c04dc7904f4c273f6e3793185c997 > >>> [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: handleCertRequest: > >>> created cert request [04/Aug/2014:19:02:40][http-bio-8443-exec-3]: > >>> handleCerts(): for cert tag sslserver > >>> > >>> > >>> > >>> And from catalina.out on the same system: > >>> java.security.cert.CertificateException: Unable to initialize, > >>> java.io.IOException: DerInput.getLength(): lengthTag=127, too big. at > >>> netscape.security.x509.X509CertImpl.(X509CertImpl.java:186) > >>> > >>> > > at > >>> netscape.security.x509.X509CertImpl.(X509CertImpl.java:160) > >>> > >>> > > at > >>> com.netscape.cms.servlet.csadmin.ConfigurationUtils.handleCerts(ConfigurationUtils.java:2718) > >>> > >>> > > > >>> > >>> > at > >>> com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:575) > >>> > >>> > > > >>> > >>> > 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) > >>> > >>> > > > >>> > >>> > at > >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) > >>> > >>> > > > >>> > >>> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > >>> 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) > >>> > >>> > > > >>> > >>> > at java.security.AccessController.doPrivileged(Native Method) > >>> at > >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > >>> > >>> > > > >>> > >>> > at > >>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) > >>> > >>> > > > >>> > >>> > 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) > >>> > >>> And the last bit from pkispawn: 2014-08-04 19:02:40 pkispawn : > >>> ERROR ....... Exception from Java Configuration Servlet: Error in > >>> confguring system > >>> certificatesjava.security.cert.CertificateException: Unable to > >>> initialize, java.io.IOException: DerInput.getLength(): lengthTag=127, > >>> too big. 2014-08-04 19:02:40 pkispawn : DEBUG ....... Error Type: > >>> HTTPError 2014-08-04 19:02:40 pkispawn : DEBUG ....... Error > >>> Message: 500 Server Error: Internal Server Error 2014-08-04 19:02:40 > >>> pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 374, > >>> in main rv = instance.spawn() File > >>> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", > >>> > >>> > > line 128, in spawn > >>> json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File > >>> "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", line > >>> 2998, in configure_pki_data response = client.configure(data) File > >>> "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in > >>> configure r = self.connection.post('/rest/installer/configure', data, > >>> headers) File "/usr/lib/python2.7/site-packages/pki/client.py", line > >>> 64, in post r.raise_for_status() File > >>> "/usr/lib/python2.7/site-packages/requests/models.py", line 638, in > >>> raise_for_status raise http_error > >>> > >>> > >>> -Erinn > > > > > > > > Here you go: dbs.beginReplicaNumber=1 dbs.beginRequestNumber=1 > > dbs.beginSerialNumber=1 dbs.enableSerialManagement=true > > dbs.endReplicaNumber=50 dbs.endRequestNumber=9900000 > > dbs.endSerialNumber=ff60000 dbs.ldap=internaldb > > dbs.newSchemaEntryAdded=true dbs.replicaCloneTransferNumber=5 > > dbs.replicaDN=ou=replica dbs.replicaIncrement=100 > > dbs.replicaLowWaterMark=20 dbs.replicaRangeDN=ou=replica, ou=ranges > > dbs.requestCloneTransferNumber=10000 dbs.requestDN=ou=ca, ou=requests > > dbs.requestIncrement=10000000 dbs.requestLowWaterMark=2000000 > > dbs.requestRangeDN=ou=requests, ou=ranges > > dbs.serialCloneTransferNumber=10000 > > dbs.serialDN=ou=certificateRepository, ou=ca dbs.serialIncrement=10000000 > > dbs.serialLowWaterMark=2000000 dbs.serialRangeDN=ou=certificateRepository, > > ou=ranges > > Erinn, I still need to see the ldap entries I mentioned above. Those are actually the ones that will need to be changed. > > Unfortunately, things seem to have gone further south on the RHEL 6.5 CA > > instance now. This just seems to be my luck on this replica install. From > > the debug of the ipa-ca-install: ipa : DEBUG Starting external > > process ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f > > /tmp/tmp1G6jOw ipa : DEBUG Process finished, return code=1 ipa > > : DEBUG stdout=Loading deployment configuration from /tmp/tmp1G6jOw. > > ERROR: Unable to access security domain: 404 Client Error: Not Found > > > > ipa : DEBUG stderr= ipa : CRITICAL failed to configure > > ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmp1G6jOw' returned > > non-zero exit status 1 > > > > I can see in the apache logs on the RHEL 6.5 instance it errors out: [Mon > > Aug 04 21:06:02 2014] [error] [client > > 2001:4870:800e:301:862b:2bff:fe67:704d] File does not exist: > > /var/www/html/ca > > > > This is supposed to be mapped via ajp to localhost:9447 which does appear > > to be listening. Anyway, I am in the throws of that currently, but let me > > know if those ranges are out of control big. > > > > -Erinn > Erinn, I'm a little confused. Perhaps at this point, it would make sense for you to test out your 6.5 instance and confirm that its working/ can issue certs etc. Maybe a restart of IPA on that server could help right things. > Could this be caused by https://bugzilla.redhat.com/show_bug.cgi?id=1083878? > You could check access log to see what calls are being made by 7.0 replica. > > This will be fixed in 6.6, I am afraid that for 6.5 you will have to do the > update (adding "|^/ca/ee/ca/profileSubmit") yourself. > > Martin From erinn.looneytriggs at gmail.com Tue Aug 5 15:42:44 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 05 Aug 2014 08:42:44 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <1407245122.2579.3.camel@aleeredhat.laptop> References: <53D446E4.6030100@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DA4437.2090001@gmail.com> <1407159397.11870.7.camel@aleeredhat.laptop> <53DF9B65.2060007@gmail.com> <1407173622.11870.19.camel@aleeredhat.laptop> <53DFD052.1050109@gmail.com> <1407178111.18236.5.camel@aleeredhat.laptop> <53DFDA8B.3080405@gmail.com> <1407185490.18236.14.camel@aleeredhat.laptop> <53E00331.8070201@gmail.com> <53E082D4.9040207@redhat.com> <1407245122.2579.3.camel@aleeredhat.laptop> Message-ID: <53E0FB74.8030308@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> >>> Here you go: dbs.beginReplicaNumber=1 dbs.beginRequestNumber=1 >>> dbs.beginSerialNumber=1 dbs.enableSerialManagement=true >>> dbs.endReplicaNumber=50 dbs.endRequestNumber=9900000 >>> dbs.endSerialNumber=ff60000 dbs.ldap=internaldb >>> dbs.newSchemaEntryAdded=true dbs.replicaCloneTransferNumber=5 >>> dbs.replicaDN=ou=replica dbs.replicaIncrement=100 >>> dbs.replicaLowWaterMark=20 dbs.replicaRangeDN=ou=replica, >>> ou=ranges dbs.requestCloneTransferNumber=10000 >>> dbs.requestDN=ou=ca, ou=requests dbs.requestIncrement=10000000 >>> dbs.requestLowWaterMark=2000000 dbs.requestRangeDN=ou=requests, >>> ou=ranges dbs.serialCloneTransferNumber=10000 >>> dbs.serialDN=ou=certificateRepository, ou=ca >>> dbs.serialIncrement=10000000 dbs.serialLowWaterMark=2000000 >>> dbs.serialRangeDN=ou=certificateRepository, ou=ranges >>> > > Erinn, I still need to see the ldap entries I mentioned above. > Those are actually the ones that will need to be changed. > >>> Unfortunately, things seem to have gone further south on the >>> RHEL 6.5 CA instance now. This just seems to be my luck on this >>> replica install. From the debug of the ipa-ca-install: ipa >>> : DEBUG Starting external process ipa : DEBUG >>> args=/usr/sbin/pkispawn -s CA -f /tmp/tmp1G6jOw ipa : >>> DEBUG Process finished, return code=1 ipa : DEBUG >>> stdout=Loading deployment configuration from /tmp/tmp1G6jOw. >>> ERROR: Unable to access security domain: 404 Client Error: Not >>> Found >>> >>> ipa : DEBUG stderr= ipa : CRITICAL failed to >>> configure ca instance Command '/usr/sbin/pkispawn -s CA -f >>> /tmp/tmp1G6jOw' returned non-zero exit status 1 >>> >>> I can see in the apache logs on the RHEL 6.5 instance it errors >>> out: [Mon Aug 04 21:06:02 2014] [error] [client >>> 2001:4870:800e:301:862b:2bff:fe67:704d] File does not exist: >>> /var/www/html/ca >>> >>> This is supposed to be mapped via ajp to localhost:9447 which >>> does appear to be listening. Anyway, I am in the throws of that >>> currently, but let me know if those ranges are out of control >>> big. >>> >>> -Erinn >> > Erinn, I'm a little confused. > > Perhaps at this point, it would make sense for you to test out your > 6.5 instance and confirm that its working/ can issue certs etc. > Maybe a restart of IPA on that server could help right things. > >> Could this be caused by >> https://bugzilla.redhat.com/show_bug.cgi?id=1083878? You could >> check access log to see what calls are being made by 7.0 >> replica. >> >> This will be fixed in 6.6, I am afraid that for 6.5 you will have >> to do the update (adding "|^/ca/ee/ca/profileSubmit") yourself. >> >> Martin > > You and me both my friend, confusion seems to be par for the course on this particular migration, but hey I am learning a lot and y'all are great help. Actually I think I have figured out why everything went a bit further south, well at least I have a theory I would like to run by you folks. I did a run on the RHEL 7 system of ipa-ca-install that failed probably because of Ade's theory. However, I think at that point the replication agreement was in place and functioning possibly because of the old entries on the RHEL 6.5 system. I then ran a pkidestroy on the RHEL 7 instance to clean things up. I reckon this might have replicated on over because at this point it appears I have no ipaca entries, nor anything functioning in that area on the RHEL 6.5 system. Either that or I have some serious corruption or HW problems. So I am working on a restore from a backup of the directory server info for the CA on the RHEL 6.5 system. All in all, pretty damn funny if that is how it worked out. One way or another the cert info is gone on the RHEL 6.5 system though the cn=config info remains intact. - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT4PtuAAoJEFg7BmJL2iPOsr8IAIgS7qnfbXYqJ5bnc2/zXafH w4Y5/zs9JtD19MeA+vFou9D0RlJA4KZ0CDk9gyMnbaM0Yb4H+9rLSF8HIK/B7IzO Cv67gbhDC7ut1L2rBRGMDUzwOlgm3mfukZLRsuWU1age49WayxzLrGLCcBM/8xqf /67etQoNYX4wHYQRPsdnm/8D3RkYPZ3LtxZqkvbxl3LERXhzjsJV5F4Jl7LKK6OE gag0qHIyfzlw7Si/kOzkNusdETRE/ZF4H7/xI/0IbrSIuG8gVovkdVxeBPOCrZ90 w1xlQyArEbIAADhQ5meez4e+MhMGHK+HlKtUHod2iXyWF2GAIR+6v1CMOljSBxs= =13KE -----END PGP SIGNATURE----- From ltartarini90 at gmail.com Tue Aug 5 15:47:57 2014 From: ltartarini90 at gmail.com (Luca Tartarini) Date: Tue, 5 Aug 2014 17:47:57 +0200 Subject: [Freeipa-users] FreeIPA + Ipsilon In-Reply-To: <1406805084.30289.25.camel@willson.usersys.redhat.com> References: <1406805084.30289.25.camel@willson.usersys.redhat.com> Message-ID: Hi, thanks for the replies. I am finally managed to install lasso correctly (without lasso-python) but after the installation of ipsilon-server (ipsilon-server-install --ipa=yes --secure=no) when I try to connet via browser to: https://myidp.example.com/idp I had this error: [error] mod_wsgi (pid=22357): Target WSGI script '/usr/sbin/ipsilon' cannot be loaded as Python module. [error] mod_wsgi (pid=22357): Exception occurred processing WSGI script '/usr/sbin/ipsilon'. [error] Traceback (most recent call last): [error] File "/usr/sbin/ipsilon", line 28, in [error] from ipsilon.root import Root [error] File "/usr/lib/python2.6/site-packages/ipsilon/root.py", line 26, in [error] from ipsilon.admin.login import LoginPlugins [error] File "/usr/lib/python2.6/site-packages/ipsilon/admin/login.py", line 48 [error] plugins_by_name = {p.name: p for p in self._site[FACILITY]['enabled']} [error] ^ [error] SyntaxError: invalid syntax with HTTP 500 Internal Server Error ("GET /idp HTTP/1.1" 500 619) The line is this one (in /usr/lib/python2.6/site-packages/ipsilon/admin/login.py): plugins_by_name = {p.name: p for p in self._site[FACILITY]['enabled']} The same thing if I try: ipsilon-client-install --saml-idp-metadata https://myidp.example.org/idp/saml2/metadata --debug Thanks in advance. Luca Tartarini 2014-07-31 13:11 GMT+02:00 Simo Sorce : > On Thu, 2014-07-31 at 09:53 +0200, Luca Tartarini wrote: > > Hi, > > > > Thanks for the reply, unfortunately I can not find the package on > > Scientific Linux, is there a workaround? > > I saw from the lasso mailing list that you built the lasso package > yourself, make sure you built the python bindings, they are part of the > same source tree. > > Attached find a .spec file you can use top build lasso on EL6 platforms, > until it will become available "officially". > > This will build and install the python binding correctly. > > Simo. > > > Thanks. > > > > Luca Tartarini > > > > > > 2014-07-30 15:00 GMT+02:00 Simo Sorce : > > > > > On Tue, 2014-07-29 at 15:58 +0200, Martin Kosek wrote: > > > > On 07/29/2014 03:47 PM, Luca Tartarini wrote: > > > > > Hi everyone, > > > > > > > > > > I am new in FreeIPA, I am trying to configure FreeIPA with > Ipsilon. The > > > > > configuration is the following: Service Provider (host with > Scientific > > > > > Linux 6) with ipsilon-client and Identity Provider (another host > with > > > > > Scientific Linux 6) with FreeIPA and ipsilon-server, is the > > > configuration > > > > > feasible and/or correct? > > > > > If it is, then I am stuck in the installation of ipsilon-client > because > > > > > after I installed lasso-2.3.6 and all the ipsilon-client > prerequisites, > > > > > when I finally run: > > > > > > > > > > ipsilon-client-install --saml-idp-metadata > > > > > https://myidp.example.org/idp/saml2/metadata --saml-auth /wiki > > > > > > > > > > I get this error about lasso: > > > > > > > > > > Traceback (most recent call last): > > > > > File "/usr/bin/ipsilon-client-install", line 20, in > > > > > from ipsilon.tools.saml2metadata import Metadata > > > > > File > > > "/usr/lib/python2.6/site-packages/ipsilon/tools/saml2metadata.py", > > > > > line 22, in > > > > > import lasso > > > > > File "/usr/lib/python2.6/site-packages/lasso.py", line 3, in > > > > > > import _lasso > > > > > ImportError: No module named _lasso > > > > > > > > > > Does anyone know if it's a problem about lasso's configuration or I > > > forgot > > > > > something about ipsilon-client? > > > > > > > > > > Thanks in advance. > > > > > > > > > > Luca Tartarini > > > > > > > > Not sure, _lasso.so should be provided by lasso-python package: > > > > > > > > # rpm -qf /usr/lib64/python2.6/site-packages/_lasso.so > > > > lasso-python-2.4.0-4.el6.x86_64 > > > > > > > > CCing Simo to advise. > > > > > > Sounds like lasso-python is missing indeed. > > > > > > Simo. > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Tue Aug 5 17:48:23 2014 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 05 Aug 2014 13:48:23 -0400 Subject: [Freeipa-users] FreeIPA + Ipsilon In-Reply-To: References: <1406805084.30289.25.camel@willson.usersys.redhat.com> Message-ID: <1407260903.4573.9.camel@willson.usersys.redhat.com> On Tue, 2014-08-05 at 17:47 +0200, Luca Tartarini wrote: > Hi, thanks for the replies. > > I am finally managed to install lasso correctly (without lasso-python) but > after the installation of ipsilon-server (ipsilon-server-install --ipa=yes > --secure=no) when I try to connet via browser to: > > https://myidp.example.com/idp > > I had this error: > > [error] mod_wsgi (pid=22357): Target WSGI script '/usr/sbin/ipsilon' cannot > be loaded as Python module. > [error] mod_wsgi (pid=22357): Exception occurred processing WSGI script > '/usr/sbin/ipsilon'. > [error] Traceback (most recent call last): > [error] File "/usr/sbin/ipsilon", line 28, in > [error] from ipsilon.root import Root > [error] File "/usr/lib/python2.6/site-packages/ipsilon/root.py", line 26, > in > [error] from ipsilon.admin.login import LoginPlugins > [error] File "/usr/lib/python2.6/site-packages/ipsilon/admin/login.py", > line 48 > [error] plugins_by_name = {p.name: p for p in > self._site[FACILITY]['enabled']} > [error] ^ > [error] SyntaxError: invalid syntax > > with HTTP 500 Internal Server Error ("GET /idp HTTP/1.1" 500 619) > > The line is this one (in > /usr/lib/python2.6/site-packages/ipsilon/admin/login.py): > > plugins_by_name = {p.name: p for p in self._site[FACILITY]['enabled']} Uhmm python 2.6, I think it does not support dict comprehension. You can replace this line with: dict([p.name, p for p in self._site[FACILITY]['enabled']]) Let me know if that helps. Simo. > The same thing if I try: > > ipsilon-client-install --saml-idp-metadata > https://myidp.example.org/idp/saml2/metadata --debug > > Thanks in advance. > > Luca Tartarini > > > > 2014-07-31 13:11 GMT+02:00 Simo Sorce : > > > On Thu, 2014-07-31 at 09:53 +0200, Luca Tartarini wrote: > > > Hi, > > > > > > Thanks for the reply, unfortunately I can not find the package on > > > Scientific Linux, is there a workaround? > > > > I saw from the lasso mailing list that you built the lasso package > > yourself, make sure you built the python bindings, they are part of the > > same source tree. > > > > Attached find a .spec file you can use top build lasso on EL6 platforms, > > until it will become available "officially". > > > > This will build and install the python binding correctly. > > > > Simo. > > > > > Thanks. > > > > > > Luca Tartarini > > > > > > > > > 2014-07-30 15:00 GMT+02:00 Simo Sorce : > > > > > > > On Tue, 2014-07-29 at 15:58 +0200, Martin Kosek wrote: > > > > > On 07/29/2014 03:47 PM, Luca Tartarini wrote: > > > > > > Hi everyone, > > > > > > > > > > > > I am new in FreeIPA, I am trying to configure FreeIPA with > > Ipsilon. The > > > > > > configuration is the following: Service Provider (host with > > Scientific > > > > > > Linux 6) with ipsilon-client and Identity Provider (another host > > with > > > > > > Scientific Linux 6) with FreeIPA and ipsilon-server, is the > > > > configuration > > > > > > feasible and/or correct? > > > > > > If it is, then I am stuck in the installation of ipsilon-client > > because > > > > > > after I installed lasso-2.3.6 and all the ipsilon-client > > prerequisites, > > > > > > when I finally run: > > > > > > > > > > > > ipsilon-client-install --saml-idp-metadata > > > > > > https://myidp.example.org/idp/saml2/metadata --saml-auth /wiki > > > > > > > > > > > > I get this error about lasso: > > > > > > > > > > > > Traceback (most recent call last): > > > > > > File "/usr/bin/ipsilon-client-install", line 20, in > > > > > > from ipsilon.tools.saml2metadata import Metadata > > > > > > File > > > > "/usr/lib/python2.6/site-packages/ipsilon/tools/saml2metadata.py", > > > > > > line 22, in > > > > > > import lasso > > > > > > File "/usr/lib/python2.6/site-packages/lasso.py", line 3, in > > > > > > > > import _lasso > > > > > > ImportError: No module named _lasso > > > > > > > > > > > > Does anyone know if it's a problem about lasso's configuration or I > > > > forgot > > > > > > something about ipsilon-client? > > > > > > > > > > > > Thanks in advance. > > > > > > > > > > > > Luca Tartarini > > > > > > > > > > Not sure, _lasso.so should be provided by lasso-python package: > > > > > > > > > > # rpm -qf /usr/lib64/python2.6/site-packages/_lasso.so > > > > > lasso-python-2.4.0-4.el6.x86_64 > > > > > > > > > > CCing Simo to advise. > > > > > > > > Sounds like lasso-python is missing indeed. > > > > > > > > Simo. > > > > > > > > > > > > > > > > > > From erinn.looneytriggs at gmail.com Tue Aug 5 18:29:59 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 05 Aug 2014 11:29:59 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <1407185490.18236.14.camel@aleeredhat.laptop> References: <53D446E4.6030100@gmail.com> <53D46028.3090105@gmail.com> <53D4A412.9050900@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DA4437.2090001@gmail.com> <1407159397.11870.7.camel@aleeredhat.laptop> <53DF9B65.2060007@gmail.com> <1407173622.11870.19.camel@aleeredhat.laptop> <53DFD052.1050109@gmail.com> <1407178111.18236.5.camel@aleeredhat.laptop> <53DFDA8B.3080405@gmail.com> <1407185490.18236.14.camel@aleeredhat.laptop> Message-ID: <53E122A7.1010600@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/04/2014 01:51 PM, Ade Lee wrote: > OK - I suspect you may be running into an issue with serial number > generation. Each time we install a clone, we end up allocating a > new range of serial numbers for the clone. > > The idea is to keep separate ranges for each CA replica so that no > two replicas can issue certs with the same serial number. > > The problem is that you've probably retried the install a whole > bunch of times and now perhaps the serial number range is too > high. > > This is just a guess - but you can see what ranges have been > assigned by looking in : > > 1, ou-ranges, o=ipaca (on the master directory server) 2. CS.cfg > for the master (look for the attributes dbs.* 3. The value of the > attribute nextRange on : ou=certificateRepository, o=ipaca and > ou=Requests, o=ipaca > > Please send me that info, and I'll explain how to clean that up. > > Ade > Ok, after that brief little side trip down deleting my CA lane, here is what I have for the ranges info: 1. Hmm ok, I'll do the best I can here, LDAP is not yet my forte: dn: ou=ranges,o=ipaca objectClass: organizationalUnit objectClass: top ou: ranges dn: ou=replica,ou=ranges,o=ipaca objectClass: organizationalUnit objectClass: top ou: replica dn: ou=requests,ou=ranges,o=ipaca objectClass: organizationalUnit objectClass: top ou: requests dn: ou=certificateRepository,ou=ranges,o=ipaca objectClass: organizationalUnit objectClass: top ou: certificateRepository dn: cn=10000001,ou=requests,ou=ranges,o=ipaca objectClass: pkiRange objectClass: top beginRange: 10000001 cn: 10000001 endRange: 20000000 host: ipa2.example.com SecurePort: 443 dn: cn=10000001,ou=certificateRepository,ou=ranges,o=ipaca objectClass: pkiRange objectClass: top beginRange: 10000001 cn: 10000001 endRange: 20000000 host: ipa2.example.com SecurePort: 443 2. dbs.beginReplicaNumber=1 dbs.beginRequestNumber=1 dbs.beginSerialNumber=1 dbs.enableSerialManagement=true dbs.endReplicaNumber=50 dbs.endRequestNumber=9900000 dbs.endSerialNumber=ff60000 dbs.ldap=internaldb dbs.newSchemaEntryAdded=true dbs.replicaCloneTransferNumber=5 dbs.replicaDN=ou=replica dbs.replicaIncrement=100 dbs.replicaLowWaterMark=20 dbs.replicaRangeDN=ou=replica, ou=ranges dbs.requestCloneTransferNumber=10000 dbs.requestDN=ou=ca, ou=requests dbs.requestIncrement=10000000 dbs.requestLowWaterMark=2000000 dbs.requestRangeDN=ou=requests, ou=ranges dbs.serialCloneTransferNumber=10000 dbs.serialDN=ou=certificateRepository, ou=ca dbs.serialIncrement=10000000 dbs.serialLowWaterMark=2000000 dbs.serialRangeDN=ou=certificateRepository, ou=ranges 3. In ou=ca,ou=ranges,o=ipaca nextRange: 20000001 Ditto for ou=certificateRepository,ou=ca,o=ipaca Thanks, - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT4SKhAAoJEFg7BmJL2iPOBmUIAKoiE7IOW3ld9ja03L9oOvdc geI56IWSXV2i5p5vln+BWQMvBko724smohWFxCJ88LY4NIXKYIV877+oDUBYX0BO pygaDZp43qTll4mo+0akYk8Ooy/4qpP2a9uslxUH6/KfhmGmo/aF1WPbfmw5t5p3 nfktyOfHp0iaD5nGjfjTlF8jhJ0UQRZxkX49u2zXKMNVZ3Oay7sItziBUtnvXcaD eIeOKjgY3dUuGulqXGqkhSev7ZV5w7WUA8snyDyG/Ls0LZdgYc3+RvdA9DuNxXFL PE36+1tfVIDnVwvwSPz/dKTMs/ThHPBbNQh/7UYVUEe5dVnUIvhVJEHJupFj9xk= =u2/z -----END PGP SIGNATURE----- From pviktori at redhat.com Tue Aug 5 18:33:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 05 Aug 2014 20:33:12 +0200 Subject: [Freeipa-users] FreeIPA + Ipsilon In-Reply-To: <1407260903.4573.9.camel@willson.usersys.redhat.com> References: <1406805084.30289.25.camel@willson.usersys.redhat.com> <1407260903.4573.9.camel@willson.usersys.redhat.com> Message-ID: <53E12368.9070308@redhat.com> On 08/05/2014 07:48 PM, Simo Sorce wrote: > On Tue, 2014-08-05 at 17:47 +0200, Luca Tartarini wrote: [...] >> with HTTP 500 Internal Server Error ("GET /idp HTTP/1.1" 500 619) >> >> The line is this one (in >> /usr/lib/python2.6/site-packages/ipsilon/admin/login.py): >> >> plugins_by_name = {p.name: p for p in self._site[FACILITY]['enabled']} > > Uhmm python 2.6, I think it does not support dict comprehension. > You can replace this line with: > dict([p.name, p for p in self._site[FACILITY]['enabled']]) dict((p.name, p) for p in self._site[FACILITY]['enabled']) (You need the parens around (p.name, p)) -- Petr? From matthew.bryant at melbourneit.com.au Tue Aug 5 22:16:14 2014 From: matthew.bryant at melbourneit.com.au (Matt Bryant) Date: Wed, 06 Aug 2014 08:16:14 +1000 Subject: [Freeipa-users] Replica Cert failed to renew ... In-Reply-To: <53D9FC8B.3010101@redhat.com> References: <53D9D8D9.5060608@melbourneit.com.au> <53D9F152.9080904@redhat.com> <53D9F5ED.8000204@melbourneit.com.au> <53D9FC8B.3010101@redhat.com> Message-ID: <53E157AE.6030206@melbourneit.com.au> Hmmm so question here .. our domain was originally installed as a 2.x and upgraded to 3.x .. I installed the replicas using the ipa-replica-prepare etc but the CA dirsrv instance was never copied over or started on the replicas (ie no slapd-PKI-* around) .. yet /etc/ipa/defaults.conf points to the replica itself for certmonger - so not sure how that will work given there is no CA copy running on the replica .. In the end the process followed was to change the xmlrpc_uri to the original master and delete and resubit the cert request for Server-Cert for slapd & httpd/alias we get an up to date cert ... not sure if anything else broken by doing that though ... I assume maybe the replcia install/mgmt under 2.x was slightly or perhaps majorly different ... rgds Matt On 31/07/2014 6:21 pm, Martin Kosek wrote: > (Adding back the users list as this may be interesting for everyone) > > Ok, the steps suggested below should help. If the DS does not want to start at > all because of the expired certificate, you can also edit > /etc/dirsrv/slapd-YOUR-REALM/dse.ldif and edit it manually (only when dirsrv > service is stopped). > > Martin > > On 07/31/2014 09:53 AM, Matt Bryant wrote: >> Martin, >> >> Correct in that the replica does not have a CA and the version being run is >> >> $ rpm -qa ipa-server >> ipa-server-3.0.0-25.el6.x86_64 >> >> restarted the services and get >> >> Starting dirsrv: >> SERVER-IPA...[31/Jul/2014:18:00:15 +1000] - SSL alert: >> CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of >> family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - >> Peer's Certificate has expired.) >> >> so I think it is just dealing with an expired cert ... so will try the other >> steps suggested .. >> >> rgds >> >> Matt Bryant >> >> On 31/07/14 17:33, Martin Kosek wrote: >>> On 07/31/2014 07:49 AM, Matt Bryant wrote: >>>> All, >>>> >>>> Got an issue with an IPA replica in that the certs in /etc/httpd/alias & >>>> /etc/dirsrv/slapd-IPA-REALM have expired. >>> I assume that this replica does not have a CA and we are only dealing with >>> service HTTPD and DIRSRV service certificates. >>> >>>> Have tried setting date back before expiry on the replica and doing an >>>> 'ipa-getcert resubmit -i ' but that hasn't worked it looks like the CA >>>> master is actually rejecting it since the havent set the date back on that >>>> server. >>>> >>>> Error am getting on replica is ... >>>> >>>> Request ID '20120719044839': >>>> status: CA_UNREACHABLE >>>> ca-error: Server failed request, will retry: -504 (libcurl failed to >>>> execute the HTTP POST transaction. Peer certificate cannot be authenticated >>>> with known CA certificates). >>> Isn't this rather a problem that the replica does not trust the master server >>> HTTPD certificate because it's certificates are not valid from replica POV? >>> >>>> is there any way of forcing a re-newel or manual process for updating these >>>> certs .. ??? >>> If this is just a replica without PKI, I would suggest synchronizing the time >>> back with the master CA server and restarting all the services. >>> >>> If the HTTPD service does not want to start, follow chapter "?25.2.2. Starting >>> IdM with Expired Certificates" in >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/cas.html >>> >>> and then try to resubmit the certificates so that they can be renewed on the >>> master. Do not forget to revert the above configuration changes when you are >>> done. >>> >>> Also, what version of FreeIPA are you running? >>> >>> HTH, >>> Martin -- Matt Bryant Manager - SMB Services | Melbourne IT | Brisbane | Tel +617 3230 7422 | Mob +61431 496663 From knighcl at gmail.com Wed Aug 6 02:56:50 2014 From: knighcl at gmail.com (Curtis L. Knight) Date: Tue, 5 Aug 2014 22:56:50 -0400 Subject: [Freeipa-users] Building previous release rpms are failing In-Reply-To: <53E0BE26.4070204@redhat.com> References: <53E0B2B1.2040002@redhat.com> <53E0BE26.4070204@redhat.com> Message-ID: On Tue, Aug 5, 2014 at 7:21 AM, Martin Kosek wrote: > On 08/05/2014 12:32 PM, Martin Kosek wrote: > > On 08/05/2014 12:05 PM, Curtis L. Knight wrote: > ... > >> #./make-lint $(LINT_OPTIONS) > >> > >> run 'make rpms' again to get beyond lint errors shown below > >> > >> > >> cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr > >> --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi > >> ./make-lint > >> Traceback (most recent call last): > >> File "./make-lint", line 272, in > >> sys.exit(main()) > >> File "./make-lint", line 243, in main > >> linter.check(files) > >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 626, in > check > >> self.check_astroid_module(astroid, walker, rawcheckers, > tokencheckers) > >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 712, in > >> check_astroid_module > >> walker.walk(astroid) > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 715, in > walk > >> self.walk(child) > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 715, in > walk > >> self.walk(child) > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 712, in > walk > >> cb(astroid) > >> File "/usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py", > >> line 135, in visit_function > >> args=(call.args[0].name, )) > >> AttributeError: 'Getattr' object has no attribute 'name' > >> make: *** [lint] Error 1 > > > > This is new, I created upstream ticket to timely fix it: > > https://fedorahosted.org/freeipa/ticket/4475 > > Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch should now > build OK again. > > Martin > Hey Martin, Tested ipa-3-3 and generated rpms from that branch. Many thanks for the resolution. Just a note, but I verified that ipa-3-2 and ipa-3-1 are in need of the same ipa-3-3 dependency patch. Both also complained that make-lint needed pylint installed which it already was. With the lint failure and rhino patch, ipa-3-2 did generate rpms. With the lint failure and rhino patch, ipa-3-1 did not generate rpms and gave the following logs. Regards, Curtis Report written to /freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/release/lib/build-report.txt Process finished normally. errors: 0 warnings: 0 build time: 4.62 seconds Invalid option "-main" Usage: java org.mozilla.javascript.tools.shell.Main [options...] [files] Valid options are: -?, -help Displays help messages. -w Enable warnings. -version 100|110|120|130|140|150|160|170|180 Set a specific language version. -opt [-1|0-9] Set optimization level. -f script-filename Execute script file, or "-" for interactive. -e script-source Evaluate inline script. -modules [uri] Add a single path or URL element to the CommonJS module search path. (implies -require) -require Enable CommonJS module support. -sandbox Enable CommonJS sandbox mode. (implies -require) -debug Generate debug code. -strict Enable strict mode warnings. -fatal-warnings Treat warnings as errors. -encoding charset Use specified character encoding as default when reading scripts. /freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/release/lib/freeipa /freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/build/freeipa /freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/build/freeipa /usr/bin/mkdir -p '/freeipa/rpmbuild/BUILDROOT/freeipa-3.1.5GIT98f5abe-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' /usr/bin/install -c -m 644 ./app.js '/freeipa/rpmbuild/BUILDROOT/freeipa-3.1.5GIT98f5abe-0.fc20.x86_64/usr/share/ipa/ui/js/freeipa' /usr/bin/install: cannot stat './app.js': No such file or directory make[6]: *** [install-appDATA] Error 1 make[6]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/build/freeipa' make[5]: *** [install-am] Error 2 make[5]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/build/freeipa' make[4]: *** [install-recursive] Error 1 make[4]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui/build' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install/ui' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe/install' make[1]: *** [install] Error 1 make[1]: Leaving directory `/freeipa/rpmbuild/BUILD/freeipa-3.1.5GIT98f5abe' error: Bad exit status from /var/tmp/rpm-tmp.Ex5L4m (%install) RPM build errors: bogus date in %changelog: Thu Aug 17 2012 Martin Kosek < mkosek at redhat.com> - 2.99.0-41 bogus date in %changelog: Fri Jun 21 2012 Sumit Bose - 2.99.0-36 bogus date in %changelog: Fri Jun 21 2012 Rob Crittenden < rcritten at redhat.com> - 2.99.0-35 bogus date in %changelog: Fri Jun 21 2012 Petr Vobornik < pvoborni at redhat.com> - 2.99.0-34 bogus date in %changelog: Wed Mar 26 2012 Rob Crittenden < rcritten at redhat.com> - 2.99.0-25 bogus date in %changelog: Wed Mar 19 2012 Martin Kosek < mkosek at redhat.com> - 2.99.0-23 bogus date in %changelog: Wed Nov 17 2011 Simo Sorce - 2.99.0-12 bogus date in %changelog: Wed Nov 14 2011 Endi S. Dewata < edewata at redhat.com> - 2.99.0-11 bogus date in %changelog: Wed Aug 25 2011 Simo Sorce - 2.99.0-1 bogus date in %changelog: Tue Jul 29 2011 Alexander Bokovoy < abokovoy at redhat.com> - 2.0.90-9 bogus date in %changelog: Thu Feb 2 2011 Rob Crittenden < rcritten at redhat.com> - 1.99-43 bogus date in %changelog: Thu Jan 19 2011 Adam Young - 1.99-40 bogus date in %changelog: Thu May 6 2009 Rob Crittenden < rcritten at redhat.com> - 1.99-5 bogus date in %changelog: Thu Feb 29 2008 Rob Crittenden < rcritten at redhat.com> 0.99-11 bogus date in %changelog: Mon Aug 5 2007 Rob Crittenden < rcritten at redhat.com> - 0.1.0-3 Bad exit status from /var/tmp/rpm-tmp.Ex5L4m (%install) make: *** [rpms] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 6 03:26:06 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Aug 2014 23:26:06 -0400 Subject: [Freeipa-users] Building previous release rpms are failing In-Reply-To: References: <53E0B2B1.2040002@redhat.com> <53E0BE26.4070204@redhat.com> Message-ID: <53E1A04E.2050403@redhat.com> Curtis L. Knight wrote: > On Tue, Aug 5, 2014 at 7:21 AM, Martin Kosek > wrote: > > On 08/05/2014 12:32 PM, Martin Kosek wrote: > > On 08/05/2014 12:05 PM, Curtis L. Knight wrote: > ... > >> #./make-lint $(LINT_OPTIONS) > >> > >> run 'make rpms' again to get beyond lint errors shown below > >> > >> > >> cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr > >> --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi > >> ./make-lint > >> Traceback (most recent call last): > >> File "./make-lint", line 272, in > >> sys.exit(main()) > >> File "./make-lint", line 243, in main > >> linter.check(files) > >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line > 626, in check > >> self.check_astroid_module(astroid, walker, rawcheckers, > tokencheckers) > >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line > 712, in > >> check_astroid_module > >> walker.walk(astroid) > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line > 715, in walk > >> self.walk(child) > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line > 715, in walk > >> self.walk(child) > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line > 712, in walk > >> cb(astroid) > >> File > "/usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py", > >> line 135, in visit_function > >> args=(call.args[0].name, )) > >> AttributeError: 'Getattr' object has no attribute 'name' > >> make: *** [lint] Error 1 > > > > This is new, I created upstream ticket to timely fix it: > > https://fedorahosted.org/freeipa/ticket/4475 > > Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch > should now > build OK again. > > Martin > > > Hey Martin, > > Tested ipa-3-3 and generated rpms from that branch. Many thanks for the > resolution. > > Just a note, but I verified that ipa-3-2 and ipa-3-1 are in need of the > same ipa-3-3 dependency patch. Both also complained that make-lint > needed pylint installed which it already was. With the lint failure and > rhino patch, ipa-3-2 did generate rpms. With the lint failure and rhino > patch, ipa-3-1 did not generate rpms and gave the following logs. I guess it becomes a bit fuzzy, especially with these versions. We don't usually offer any guarantees that older releases will build against more modern distros, but both 3.1.5 and 3.2.0 crossed that line, with Fedora builds in two releases (F18/19 and F19/20 respectively). Do you have a requirement to use these older releases or are you just offering this data point in case anyone else runs into this? regards rob From erinn.looneytriggs at gmail.com Wed Aug 6 04:30:51 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 05 Aug 2014 21:30:51 -0700 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <1407245122.2579.3.camel@aleeredhat.laptop> References: <53D446E4.6030100@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DA4437.2090001@gmail.com> <1407159397.11870.7.camel@aleeredhat.laptop> <53DF9B65.2060007@gmail.com> <1407173622.11870.19.camel@aleeredhat.laptop> <53DFD052.1050109@gmail.com> <1407178111.18236.5.camel@aleeredhat.laptop> <53DFDA8B.3080405@gmail.com> <1407185490.18236.14.camel@aleeredhat.laptop> <53E00331.8070201@gmail.com> <53E082D4.9040207@redhat.com> <1407245122.2579.3.camel@aleeredhat.laptop> Message-ID: <53E1AF7B.2010703@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Ok I am throwing up the white flag on this one and starting anew. Clearly there are several things broken down there in the murky depths, and well I just don't trust my install all that much at this point. Thanks for all the help I really appreciate it. Please remember to take a look at the multiple certs issue for creating a clone in dogtag, as that is a bug for sure. - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT4a91AAoJEFg7BmJL2iPOxk8IAIvLoQdw4mkL6CGpzlU8H2go C1OXaS52pd9cX7LLZkNgVYUcaAizyND2cNp7vjwhESRwDcPSBzDWl1jXGhrv/Dp9 TOpP7YvR8WueifgQkqcEVCUf6TEH07v4MXNwkrX6h6eX092583jfXLuzmp3hjO+J cLbWAwuQR5E0xntkfrnWjdjDddWVzUKVUGNO2Da5nIjancGZLaRAgMYIpY3tz0FD F6OVEUQA4eP/xoZlN8bFBLbtLH4n+/pFOF66A0e+9NtXUEtW3Sd+OupTerpDcid9 7YMmJ2kXsyhT3X9Rykm8irMRx6zGNZhf/TUfVg5tLFRzoZ+LvqxY+52SnSL5jwo= =mt1j -----END PGP SIGNATURE----- From ketanmehta.in at gmail.com Wed Aug 6 08:40:54 2014 From: ketanmehta.in at gmail.com (ketan mehta) Date: Wed, 6 Aug 2014 09:40:54 +0100 Subject: [Freeipa-users] FreeIPA HTTP Server-Cert expired. Message-ID: Hi All, I'm facing a strange problem, my IPA master server's HTTP Server-Cert got expired and i'm not able to renew it. would you please help me in resolve it. [root at ipa01 ~]# getcert list Number of certificates and requests being tracked: 9. Request ID '20120731123222': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. couldn't connect to host). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-BIGDATA-BSKYB-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-BIGDATA-BSKYB-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-BIGDATA-BSKYB-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa01.EXAMPLE.COM,O=EXAMPLE.COM expires: 2014-08-01 12:32:21 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv BIGDATA-BSKYB-COM track: yes auto-renew: yes Request ID '20120731123240': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. couldn't connect to host). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa01.EXAMPLE.COM,O=EXAMPLE.COM expires: 2014-08-01 12:32:40 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20120731123255': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. couldn't connect to host). stuck: yes key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa01.EXAMPLE.COM,O=EXAMPLE.COM expires: 2014-08-01 12:32:55 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes Request ID '20130315142330': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='625466584922' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Audit,O=EXAMPLE.COM expires: 2016-06-12 15:06:33 UTC pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130315142331': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='625466584922' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=OCSP Subsystem,O=EXAMPLE.COM expires: 2016-06-12 15:05:33 UTC eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130315142332': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='625466584922' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Subsystem,O=EXAMPLE.COM expires: 2016-06-12 15:05:33 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130315142333': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=IPA RA,O=EXAMPLE.COM expires: 2016-06-12 15:05:33 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20130315142334': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='625466584922' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa01.EXAMPLE.COM,O=EXAMPLE.COM expires: 2016-06-12 15:05:33 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140805110726': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction. couldn't connect to host). stuck: yes key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes [root at ipa01 ~]# ipactl start Starting Directory Service Starting dirsrv: EXAMPLE-COM...[06/Aug/2014:09:39:50 +0100] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) [ OK ] PKI-IPA...[06/Aug/2014:09:39:52 +0100] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting DNS Service Starting named: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [FAILED] Failed to start HTTP Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping named: . [ OK ] Stopping ipa_memcached: [ OK ] Stopping httpd: [FAILED] Stopping pki-ca: [ OK ] Shutting down dirsrv: EXAMPLE-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl I'm running ipa-server-3.0.0-26.el6_4.2.x86_64 Let me know if you need any further information. Thanks, Ketan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 6 12:54:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Aug 2014 08:54:36 -0400 Subject: [Freeipa-users] FreeIPA HTTP Server-Cert expired. In-Reply-To: References: Message-ID: <53E2258C.1020609@redhat.com> ketan mehta wrote: > Hi All, > > I'm facing a strange problem, my IPA master server's HTTP Server-Cert > got expired and i'm not able to renew it. would you please help me in > resolve it. > > [root at ipa01 ~]# getcert list > Number of certificates and requests being tracked: 9. > Request ID '20120731123222': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl > failed to execute the HTTP POST transaction. couldn't connect to host). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-BIGDATA-BSKYB-COM',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-BIGDATA-BSKYB-COM/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-BIGDATA-BSKYB-COM',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa01.EXAMPLE.COM > ,O=EXAMPLE.COM > expires: 2014-08-01 12:32:21 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv > BIGDATA-BSKYB-COM > track: yes > auto-renew: yes > Request ID '20120731123240': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl > failed to execute the HTTP POST transaction. couldn't connect to host). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa01.EXAMPLE.COM > ,O=EXAMPLE.COM > expires: 2014-08-01 12:32:40 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > Request ID '20120731123255': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl > failed to execute the HTTP POST transaction. couldn't connect to host). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa01.EXAMPLE.COM > ,O=EXAMPLE.COM > expires: 2014-08-01 12:32:55 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > Request ID '20130315142330': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin='625466584922' > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=CA Audit,O=EXAMPLE.COM > expires: 2016-06-12 15:06:33 UTC > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20130315142331': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB',pin='625466584922' > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=OCSP Subsystem,O=EXAMPLE.COM > expires: 2016-06-12 15:05:33 UTC > eku: id-kp-OCSPSigning > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20130315142332': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin='625466584922' > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=CA Subsystem,O=EXAMPLE.COM > expires: 2016-06-12 15:05:33 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20130315142333': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=IPA RA,O=EXAMPLE.COM > expires: 2016-06-12 15:05:33 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > track: yes > auto-renew: yes > Request ID '20130315142334': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB',pin='625466584922' > certificate: > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-renew-agent > issuer: CN=Certificate Authority,O=EXAMPLE.COM > subject: CN=ipa01.EXAMPLE.COM > ,O=EXAMPLE.COM > expires: 2016-06-12 15:05:33 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > Request ID '20140805110726': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (libcurl > failed to execute the HTTP POST transaction. couldn't connect to host). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS > Certificate DB' > certificate: > type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > [root at ipa01 ~]# ipactl start > Starting Directory Service > Starting dirsrv: > EXAMPLE-COM...[06/Aug/2014:09:39:50 +0100] - SSL alert: > CERT_VerifyCertificateNow: verify certificate failed for cert > Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable > Runtime error -8181 - Peer's Certificate has expired.) > [ OK ] > PKI-IPA...[06/Aug/2014:09:39:52 +0100] - SSL alert: > CERT_VerifyCertificateNow: verify certificate failed for cert > Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable > Runtime error -8181 - Peer's Certificate has expired.) > [ OK ] > Starting KDC Service > Starting Kerberos 5 KDC: [ OK ] > Starting KPASSWD Service > Starting Kerberos 5 Admin Server: [ OK ] > Starting DNS Service > Starting named: [ OK ] > Starting MEMCACHE Service > Starting ipa_memcached: [ OK ] > Starting HTTP Service > Starting httpd: [FAILED] > Failed to start HTTP Service > Shutting down > Stopping Kerberos 5 KDC: [ OK ] > Stopping Kerberos 5 Admin Server: [ OK ] > Stopping named: . [ OK ] > Stopping ipa_memcached: [ OK ] > Stopping httpd: [FAILED] > Stopping pki-ca: [ OK ] > Shutting down dirsrv: > EXAMPLE-COM... [ OK ] > PKI-IPA... [ OK ] > Aborting ipactl > > I'm running ipa-server-3.0.0-26.el6_4.2.x86_64 > > Let me know if you need any further information. The easiest thing to do would be to roll back time to 7/31 and restart certmonger. It's hard to say why they didn't renew already as the CA subsystem certificates appear to have renewed ok. rob From ketanmehta.in at gmail.com Wed Aug 6 13:11:50 2014 From: ketanmehta.in at gmail.com (ketan mehta) Date: Wed, 6 Aug 2014 14:11:50 +0100 Subject: [Freeipa-users] FreeIPA HTTP Server-Cert expired. In-Reply-To: <53E2258C.1020609@redhat.com> References: <53E2258C.1020609@redhat.com> Message-ID: Hi Rob, I tried doing that earlier but it fails because of named error output of /var/log/messages Jul 31 14:06:04 ipa01 named[22866]: Failed to init credentials (Clock skew too great) Jul 31 14:06:04 ipa01 named[22866]: loading configuration: failure Jul 31 14:06:04 ipa01 named[22866]: exiting (due to fatal error) Jul 31 14:06:05 ipa01 ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_494' not found) ------------------ [root at ipa01 ~]# service ntpd status ntpd is stopped [root at ipa01 ~]# ipactl start Starting Directory Service Starting dirsrv: EXAMPLE-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting DNS Service Starting named: [FAILED] Failed to start DNS Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping named: [ OK ] Stopping httpd: [FAILED] Stopping pki-ca: [ OK ] Shutting down dirsrv: EXAMPLE-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl Thanks, Ketan On Wed, Aug 6, 2014 at 1:54 PM, Rob Crittenden wrote: > ketan mehta wrote: > > Hi All, > > > > I'm facing a strange problem, my IPA master server's HTTP Server-Cert > > got expired and i'm not able to renew it. would you please help me in > > resolve it. > > > > [root at ipa01 ~]# getcert list > > Number of certificates and requests being tracked: 9. > > Request ID '20120731123222': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl > > failed to execute the HTTP POST transaction. couldn't connect to host). > > stuck: yes > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-BIGDATA-BSKYB-COM',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-BIGDATA-BSKYB-COM/pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-BIGDATA-BSKYB-COM',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=EXAMPLE.COM < > http://EXAMPLE.COM> > > subject: CN=ipa01.EXAMPLE.COM > > ,O=EXAMPLE.COM > > expires: 2014-08-01 12:32:21 UTC > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv > > BIGDATA-BSKYB-COM > > track: yes > > auto-renew: yes > > Request ID '20120731123240': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl > > failed to execute the HTTP POST transaction. couldn't connect to host). > > stuck: yes > > key pair storage: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' > > certificate: > > > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=EXAMPLE.COM < > http://EXAMPLE.COM> > > subject: CN=ipa01.EXAMPLE.COM > > ,O=EXAMPLE.COM > > expires: 2014-08-01 12:32:40 UTC > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > Request ID '20120731123255': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl > > failed to execute the HTTP POST transaction. couldn't connect to host). > > stuck: yes > > key pair storage: > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS > > Certificate DB' > > CA: IPA > > issuer: CN=Certificate Authority,O=EXAMPLE.COM < > http://EXAMPLE.COM> > > subject: CN=ipa01.EXAMPLE.COM > > ,O=EXAMPLE.COM > > expires: 2014-08-01 12:32:55 UTC > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > > track: yes > > auto-renew: yes > > Request ID '20130315142330': > > status: MONITORING > > stuck: no > > key pair storage: > > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert > > cert-pki-ca',token='NSS Certificate DB',pin='625466584922' > > certificate: > > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert > > cert-pki-ca',token='NSS Certificate DB' > > CA: dogtag-ipa-renew-agent > > issuer: CN=Certificate Authority,O=EXAMPLE.COM < > http://EXAMPLE.COM> > > subject: CN=CA Audit,O=EXAMPLE.COM > > expires: 2016-06-12 15:06:33 UTC > > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > > "auditSigningCert cert-pki-ca" > > track: yes > > auto-renew: yes > > Request ID '20130315142331': > > status: MONITORING > > stuck: no > > key pair storage: > > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert > > cert-pki-ca',token='NSS Certificate DB',pin='625466584922' > > certificate: > > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert > > cert-pki-ca',token='NSS Certificate DB' > > CA: dogtag-ipa-renew-agent > > issuer: CN=Certificate Authority,O=EXAMPLE.COM < > http://EXAMPLE.COM> > > subject: CN=OCSP Subsystem,O=EXAMPLE.COM > > expires: 2016-06-12 15:05:33 UTC > > eku: id-kp-OCSPSigning > > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > > "ocspSigningCert cert-pki-ca" > > track: yes > > auto-renew: yes > > Request ID '20130315142332': > > status: MONITORING > > stuck: no > > key pair storage: > > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert > > cert-pki-ca',token='NSS Certificate DB',pin='625466584922' > > certificate: > > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert > > cert-pki-ca',token='NSS Certificate DB' > > CA: dogtag-ipa-renew-agent > > issuer: CN=Certificate Authority,O=EXAMPLE.COM < > http://EXAMPLE.COM> > > subject: CN=CA Subsystem,O=EXAMPLE.COM > > expires: 2016-06-12 15:05:33 UTC > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad > > post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert > > "subsystemCert cert-pki-ca" > > track: yes > > auto-renew: yes > > Request ID '20130315142333': > > status: MONITORING > > stuck: no > > key pair storage: > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > > certificate: > > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > > Certificate DB' > > CA: dogtag-ipa-renew-agent > > issuer: CN=Certificate Authority,O=EXAMPLE.COM < > http://EXAMPLE.COM> > > subject: CN=IPA RA,O=EXAMPLE.COM > > expires: 2016-06-12 15:05:33 UTC > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert > > track: yes > > auto-renew: yes > > Request ID '20130315142334': > > status: MONITORING > > stuck: no > > key pair storage: > > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > > cert-pki-ca',token='NSS Certificate DB',pin='625466584922' > > certificate: > > type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert > > cert-pki-ca',token='NSS Certificate DB' > > CA: dogtag-ipa-renew-agent > > issuer: CN=Certificate Authority,O=EXAMPLE.COM < > http://EXAMPLE.COM> > > subject: CN=ipa01.EXAMPLE.COM > > ,O=EXAMPLE.COM > > expires: 2016-06-12 15:05:33 UTC > > eku: id-kp-serverAuth,id-kp-clientAuth > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > Request ID '20140805110726': > > status: CA_UNREACHABLE > > ca-error: Server failed request, will retry: -504 (libcurl > > failed to execute the HTTP POST transaction. couldn't connect to host). > > stuck: yes > > key pair storage: > > type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS > > Certificate DB' > > certificate: > > type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert' > > CA: IPA > > issuer: > > subject: > > expires: unknown > > pre-save command: > > post-save command: > > track: yes > > auto-renew: yes > > > > [root at ipa01 ~]# ipactl start > > Starting Directory Service > > Starting dirsrv: > > EXAMPLE-COM...[06/Aug/2014:09:39:50 +0100] - SSL alert: > > CERT_VerifyCertificateNow: verify certificate failed for cert > > Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable > > Runtime error -8181 - Peer's Certificate has expired.) > > [ OK ] > > PKI-IPA...[06/Aug/2014:09:39:52 +0100] - SSL alert: > > CERT_VerifyCertificateNow: verify certificate failed for cert > > Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable > > Runtime error -8181 - Peer's Certificate has expired.) > > [ OK ] > > Starting KDC Service > > Starting Kerberos 5 KDC: [ OK ] > > Starting KPASSWD Service > > Starting Kerberos 5 Admin Server: [ OK ] > > Starting DNS Service > > Starting named: [ OK ] > > Starting MEMCACHE Service > > Starting ipa_memcached: [ OK ] > > Starting HTTP Service > > Starting httpd: [FAILED] > > Failed to start HTTP Service > > Shutting down > > Stopping Kerberos 5 KDC: [ OK ] > > Stopping Kerberos 5 Admin Server: [ OK ] > > Stopping named: . [ OK ] > > Stopping ipa_memcached: [ OK ] > > Stopping httpd: [FAILED] > > Stopping pki-ca: [ OK ] > > Shutting down dirsrv: > > EXAMPLE-COM... [ OK ] > > PKI-IPA... [ OK ] > > Aborting ipactl > > > > I'm running ipa-server-3.0.0-26.el6_4.2.x86_64 > > > > Let me know if you need any further information. > > The easiest thing to do would be to roll back time to 7/31 and restart > certmonger. It's hard to say why they didn't renew already as the CA > subsystem certificates appear to have renewed ok. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Wed Aug 6 14:02:52 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 06 Aug 2014 10:02:52 -0400 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far In-Reply-To: <53E1AF7B.2010703@gmail.com> References: <53D446E4.6030100@gmail.com> <53D52968.4080205@gmail.com> <53D6567F.7020309@redhat.com> <53D65B82.7050902@redhat.com> <53D660FC.6030409@gmail.com> <1406559847.14582.5.camel@aleeredhat.laptop> <53D66BC0.6050309@gmail.com> <1406570879.14582.28.camel@aleeredhat.laptop> <53D6A123.3030709@gmail.com> <1406575224.14582.38.camel@aleeredhat.laptop> <53D6A63B.9050608@gmail.com> <53D6AAFE.6090305@redhat.com> <53D840FE.9060405@gmail.com> <1406755866.4784.5.camel@localhost.localdomain> <53DA4437.2090001@gmail.com> <1407159397.11870.7.camel@aleeredhat.laptop> <53DF9B65.2060007@gmail.com> <1407173622.11870.19.camel@aleeredhat.laptop> <53DFD052.1050109@gmail.com> <1407178111.18236.5.camel@aleeredhat.laptop> <53DFDA8B.3080405@gmail.com> <1407185490.18236.14.camel@aleeredhat.laptop> <53E00331.8070201@gmail.com> <53E082D4.9040207@redhat.com> <1407245122.2579.3.camel@aleeredhat.laptop> <53E1AF7B.2010703@gmail.com> Message-ID: <1407333772.14215.1.camel@aleeredhat.laptop> Thanks for sticking in there with the debugging. Let us know if you run into any issues with the re-install. I will open a Dogtag ticket to look into the multiple certs issue for Dogtag. Ade On Tue, 2014-08-05 at 21:30 -0700, Erinn Looney-Triggs wrote: > Ok I am throwing up the white flag on this one and starting anew. > Clearly there are several things broken down there in the murky > depths, and well I just don't trust my install all that much at this > point. > > Thanks for all the help I really appreciate it. > > Please remember to take a look at the multiple certs issue for > creating a clone in dogtag, as that is a bug for sure. > > -Erinn > From mkosek at redhat.com Wed Aug 6 14:07:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 06 Aug 2014 16:07:35 +0200 Subject: [Freeipa-users] Replica Cert failed to renew ... In-Reply-To: <53E157AE.6030206@melbourneit.com.au> References: <53D9D8D9.5060608@melbourneit.com.au> <53D9F152.9080904@redhat.com> <53D9F5ED.8000204@melbourneit.com.au> <53D9FC8B.3010101@redhat.com> <53E157AE.6030206@melbourneit.com.au> Message-ID: <53E236A7.9080309@redhat.com> Right, the processing route may not seem obvious. certmonger uses the server from /etc/ipa/default.conf. This server does not necessarily need to also run CA, we count with that option. When certmonger wants to renew or request a certificate, it calls cert-request API call on that server. The API call calls Dogtag backend which checks if the server is a CA powered IPA. If it is not, it picks any other master where CA *is* installed and connects that for the certificate operation. Check _select_any_master in ipaserver/plugins/dogtag.py if you are interested about the code. Does that help? Martin On 08/06/2014 12:16 AM, Matt Bryant wrote: > Hmmm so question here .. our domain was originally installed as a 2.x and > upgraded to 3.x .. I installed the replicas using the ipa-replica-prepare etc > but the CA dirsrv instance was never copied over or started on the replicas (ie > no slapd-PKI-* around) .. yet /etc/ipa/defaults.conf points to the replica > itself for certmonger - so not sure how that will work given there is no CA > copy running on the replica .. > > In the end the process followed was to change the xmlrpc_uri to the original > master and delete and resubit the cert request for Server-Cert for slapd & > httpd/alias we get an up to date cert ... not sure if anything else broken by > doing that though ... > > I assume maybe the replcia install/mgmt under 2.x was slightly or perhaps > majorly different ... > > rgds > > Matt > > On 31/07/2014 6:21 pm, Martin Kosek wrote: >> (Adding back the users list as this may be interesting for everyone) >> >> Ok, the steps suggested below should help. If the DS does not want to start at >> all because of the expired certificate, you can also edit >> /etc/dirsrv/slapd-YOUR-REALM/dse.ldif and edit it manually (only when dirsrv >> service is stopped). >> >> Martin >> >> On 07/31/2014 09:53 AM, Matt Bryant wrote: >>> Martin, >>> >>> Correct in that the replica does not have a CA and the version being run is >>> >>> $ rpm -qa ipa-server >>> ipa-server-3.0.0-25.el6.x86_64 >>> >>> restarted the services and get >>> >>> Starting dirsrv: >>> SERVER-IPA...[31/Jul/2014:18:00:15 +1000] - SSL alert: >>> CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of >>> family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - >>> Peer's Certificate has expired.) >>> >>> so I think it is just dealing with an expired cert ... so will try the other >>> steps suggested .. >>> >>> rgds >>> >>> Matt Bryant >>> >>> On 31/07/14 17:33, Martin Kosek wrote: >>>> On 07/31/2014 07:49 AM, Matt Bryant wrote: >>>>> All, >>>>> >>>>> Got an issue with an IPA replica in that the certs in /etc/httpd/alias & >>>>> /etc/dirsrv/slapd-IPA-REALM have expired. >>>> I assume that this replica does not have a CA and we are only dealing with >>>> service HTTPD and DIRSRV service certificates. >>>> >>>>> Have tried setting date back before expiry on the replica and doing an >>>>> 'ipa-getcert resubmit -i ' but that hasn't worked it looks like the CA >>>>> master is actually rejecting it since the havent set the date back on that >>>>> server. >>>>> >>>>> Error am getting on replica is ... >>>>> >>>>> Request ID '20120719044839': >>>>> status: CA_UNREACHABLE >>>>> ca-error: Server failed request, will retry: -504 (libcurl failed to >>>>> execute the HTTP POST transaction. Peer certificate cannot be authenticated >>>>> with known CA certificates). >>>> Isn't this rather a problem that the replica does not trust the master server >>>> HTTPD certificate because it's certificates are not valid from replica POV? >>>> >>>>> is there any way of forcing a re-newel or manual process for updating these >>>>> certs .. ??? >>>> If this is just a replica without PKI, I would suggest synchronizing the time >>>> back with the master CA server and restarting all the services. >>>> >>>> If the HTTPD service does not want to start, follow chapter "?25.2.2. Starting >>>> IdM with Expired Certificates" in >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/cas.html >>>> >>>> >>>> and then try to resubmit the certificates so that they can be renewed on the >>>> master. Do not forget to revert the above configuration changes when you are >>>> done. >>>> >>>> Also, what version of FreeIPA are you running? >>>> >>>> HTH, >>>> Martin > From ltartarini90 at gmail.com Wed Aug 6 15:20:39 2014 From: ltartarini90 at gmail.com (Luca Tartarini) Date: Wed, 6 Aug 2014 17:20:39 +0200 Subject: [Freeipa-users] FreeIPA + Ipsilon In-Reply-To: <53E12368.9070308@redhat.com> References: <1406805084.30289.25.camel@willson.usersys.redhat.com> <1407260903.4573.9.camel@willson.usersys.redhat.com> <53E12368.9070308@redhat.com> Message-ID: Hi, Thanks for the replies. I updated the line with: plugins_by_name = dict((p.name, p) for p in self._site[FACILITY]['enabled']) and it works (the installation is completed succesfully). But now when I try to connect to: https://myidp.example.com/idp or I try to configure ipsilon-client (ipsilon-client-install ...) I got HTTP 500 Internal Error (with ipsilon background). I put "debug = True" in /etc/ipsilon/idp/ipsilon.conf and I got this (in /var/log/httpd/error_log): [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Available providers: ['saml2'] [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp storage path: /var/lib/ipsilon/idp/saml2 [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp metadata file: metadata.xml [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp storage path: /var/lib/ipsilon/idp/saml2 [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp key file: /var/lib/ipsilon/idp/saml2/idp.key [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp storage path: /var/lib/ipsilon/idp/saml2 [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp certificate file: /var/lib/ipsilon/idp/saml2/idp.pem [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] IdP Provider registered: saml2 [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] enabled: 1 [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] IdP Provider enabled: saml2 [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login plugin: krb [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login plugin: pam [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] username text: Username [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] password text: Password [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] service name: remote [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] help text: Insert your Username and Password and then submit. [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login plugin: testauth [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] username text: Username [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] password text: Password [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] help text: Insert your Username and Password and then submit. [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin provider plugin: saml2 [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] default allowed nameids: ['persistent', 'transient', 'email', 'kerberos', 'x509'] [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp metadata file: metadata.xml [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] default email domain: example.com [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp certificate file: /var/lib/ipsilon/idp/saml2/idp.pem [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] allow self registration: True [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp key file: /var/lib/ipsilon/idp/saml2/idp.key [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp storage path: /var/lib/ipsilon/idp/saml2 [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] default nameid: persistent [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Traceback (most recent call last): [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", line 104, in run [Wed Aug 06 16:22:09 2014] [error] hook() [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", line 63, in __call__ [Wed Aug 06 16:22:09 2014] [error] return self.callback(**self.kwargs) [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/ipsilon/util/page.py", line 37, in protect [Wed Aug 06 16:22:09 2014] [error] UserSession().remote_login() [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/ipsilon/util/user.py", line 103, in __init__ [Wed Aug 06 16:22:09 2014] [error] self.user = self.get_data('user', 'name') [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/ipsilon/util/user.py", line 147, in get_data [Wed Aug 06 16:22:09 2014] [error] if facility not in cherrypy.session: [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/__init__.py", line 258, in __contains__ [Wed Aug 06 16:22:09 2014] [error] return key in child [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", line 335, in __contains__ [Wed Aug 06 16:22:09 2014] [error] self.load() [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", line 268, in load [Wed Aug 06 16:22:09 2014] [error] data = self._load() [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", line 497, in _load [Wed Aug 06 16:22:09 2014] [error] assert self.locked, ("The session load without being locked. " [Wed Aug 06 16:22:09 2014] [error] AssertionError: The session load without being locked. Check your tools' priority levels. [Wed Aug 06 16:22:09 2014] [error] [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] HTTP [Wed Aug 06 16:22:09 2014] [error] Request Headers: [Wed Aug 06 16:22:09 2014] [error] COOKIE: __utma=203412483.1716219377.1393273532.1393273532.1398882487.2; __utmz=203412483.1398882487.2.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); _ga=GA1.2.1716219377.1393273532; session_id=0942ebacef3fbcf8f9b21605013b5dfa1454bc93 [Wed Aug 06 16:22:09 2014] [error] ACCEPT-LANGUAGE: it-IT,it;q=0.8,en-US;q=0.6,en;q=0.4,fr;q=0.2 [Wed Aug 06 16:22:09 2014] [error] USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.132 Safari/537.36 [Wed Aug 06 16:22:09 2014] [error] CONNECTION: keep-alive [Wed Aug 06 16:22:09 2014] [error] Remote-Addr: 128.141.28.32 [Wed Aug 06 16:22:09 2014] [error] HOST: ltartari3.cern.ch [Wed Aug 06 16:22:09 2014] [error] CACHE-CONTROL: max-age=0 [Wed Aug 06 16:22:09 2014] [error] ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 [Wed Aug 06 16:22:09 2014] [error] ACCEPT-ENCODING: gzip,deflate,sdch [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] HTTP Traceback (most recent call last): [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", line 667, in respond [Wed Aug 06 16:22:09 2014] [error] self.hooks.run('before_handler') [Wed Aug 06 16:22:09 2014] [error] File "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", line 114, in run [Wed Aug 06 16:22:09 2014] [error] raise exc [Wed Aug 06 16:22:09 2014] [error] AssertionError: The session load without being locked. Check your tools' priority levels. [Wed Aug 06 16:22:09 2014] [error] [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] ['500 Internal Server Error', 'The server encountered an unexpected condition which prevented it from fulfilling the request.', 'Traceback (most recent call last):\\n File "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", line 667, in respond\\n self.hooks.run(\\'before_handler\\')\\n File "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", line 114, in run\\n raise exc\\nAssertionError: The session load without being locked. Check your tools\\' priority levels.\\n', '3.5.0'] and obviously "GET /idp/ HTTP/1.1" 500 1054 in /var/log/httpd/access_log Cherrypy bug? Thanks. Luca Tartarini 2014-08-05 20:33 GMT+02:00 Petr Viktorin : > On 08/05/2014 07:48 PM, Simo Sorce wrote: > >> On Tue, 2014-08-05 at 17:47 +0200, Luca Tartarini wrote: >> > [...] > > with HTTP 500 Internal Server Error ("GET /idp HTTP/1.1" 500 619) >>> >>> The line is this one (in >>> /usr/lib/python2.6/site-packages/ipsilon/admin/login.py): >>> >>> plugins_by_name = {p.name: p for p in self._site[FACILITY]['enabled']} >>> >> >> Uhmm python 2.6, I think it does not support dict comprehension. >> You can replace this line with: >> dict([p.name, p for p in self._site[FACILITY]['enabled']]) >> > > > dict((p.name, p) for p in self._site[FACILITY]['enabled']) > > > (You need the parens around (p.name, p)) > > -- > Petr? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Wed Aug 6 15:37:00 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 06 Aug 2014 11:37:00 -0400 Subject: [Freeipa-users] FreeIPA + Ipsilon In-Reply-To: References: <1406805084.30289.25.camel@willson.usersys.redhat.com> <1407260903.4573.9.camel@willson.usersys.redhat.com> <53E12368.9070308@redhat.com> Message-ID: <1407339420.4573.21.camel@willson.usersys.redhat.com> On Wed, 2014-08-06 at 17:20 +0200, Luca Tartarini wrote: > Hi, > > Thanks for the replies. I updated the line with: > > plugins_by_name = dict((p.name, p) for p in self._site[FACILITY]['enabled']) > > and it works (the installation is completed succesfully). > > But now when I try to connect to: > > https://myidp.example.com/idp > > or I try to configure ipsilon-client (ipsilon-client-install ...) I got > HTTP 500 Internal Error (with ipsilon background). I put "debug = True" > in /etc/ipsilon/idp/ipsilon.conf and I got this (in > /var/log/httpd/error_log): > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Available > providers: ['saml2'] > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > storage path: /var/lib/ipsilon/idp/saml2 > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > metadata file: metadata.xml > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > storage path: /var/lib/ipsilon/idp/saml2 > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp key > file: /var/lib/ipsilon/idp/saml2/idp.key > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > storage path: /var/lib/ipsilon/idp/saml2 > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > certificate file: /var/lib/ipsilon/idp/saml2/idp.pem > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] IdP Provider > registered: saml2 > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] enabled: > 1 > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] IdP Provider > enabled: saml2 > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login > plugin: krb > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login > plugin: pam > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] username > text: Username > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] password > text: Password > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] service > name: remote > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] help text: > Insert your Username and Password and then submit. > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login > plugin: testauth > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] > username text: Username > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] > password text: Password > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] help > text: Insert your Username and Password and then submit. > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin provider > plugin: saml2 > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] default > allowed nameids: ['persistent', 'transient', 'email', 'kerberos', 'x509'] > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > metadata file: metadata.xml > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] default > email domain: example.com > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > certificate file: /var/lib/ipsilon/idp/saml2/idp.pem > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] allow > self registration: True > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp key > file: /var/lib/ipsilon/idp/saml2/idp.key > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > storage path: /var/lib/ipsilon/idp/saml2 > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] default > nameid: persistent > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Traceback (most > recent call last): > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > line 104, in run > [Wed Aug 06 16:22:09 2014] [error] hook() > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > line 63, in __call__ > [Wed Aug 06 16:22:09 2014] [error] return self.callback(**self.kwargs) > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/ipsilon/util/page.py", line 37, in protect > [Wed Aug 06 16:22:09 2014] [error] UserSession().remote_login() > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/ipsilon/util/user.py", line 103, in > __init__ > [Wed Aug 06 16:22:09 2014] [error] self.user = self.get_data('user', > 'name') > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/ipsilon/util/user.py", line 147, in > get_data > [Wed Aug 06 16:22:09 2014] [error] if facility not in cherrypy.session: > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/__init__.py", > line 258, in __contains__ > [Wed Aug 06 16:22:09 2014] [error] return key in child > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", > line 335, in __contains__ > [Wed Aug 06 16:22:09 2014] [error] self.load() > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", > line 268, in load > [Wed Aug 06 16:22:09 2014] [error] data = self._load() > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", > line 497, in _load > [Wed Aug 06 16:22:09 2014] [error] assert self.locked, ("The session > load without being locked. " > [Wed Aug 06 16:22:09 2014] [error] AssertionError: The session load without > being locked. Check your tools' priority levels. > [Wed Aug 06 16:22:09 2014] [error] > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] HTTP > [Wed Aug 06 16:22:09 2014] [error] Request Headers: > [Wed Aug 06 16:22:09 2014] [error] COOKIE: > __utma=203412483.1716219377.1393273532.1393273532.1398882487.2; > __utmz=203412483.1398882487.2.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); > _ga=GA1.2.1716219377.1393273532; > session_id=0942ebacef3fbcf8f9b21605013b5dfa1454bc93 > [Wed Aug 06 16:22:09 2014] [error] ACCEPT-LANGUAGE: > it-IT,it;q=0.8,en-US;q=0.6,en;q=0.4,fr;q=0.2 > [Wed Aug 06 16:22:09 2014] [error] USER-AGENT: Mozilla/5.0 (X11; Linux > x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.132 > Safari/537.36 > [Wed Aug 06 16:22:09 2014] [error] CONNECTION: keep-alive > [Wed Aug 06 16:22:09 2014] [error] Remote-Addr: 128.141.28.32 > [Wed Aug 06 16:22:09 2014] [error] HOST: ltartari3.cern.ch > [Wed Aug 06 16:22:09 2014] [error] CACHE-CONTROL: max-age=0 > [Wed Aug 06 16:22:09 2014] [error] ACCEPT: > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > [Wed Aug 06 16:22:09 2014] [error] ACCEPT-ENCODING: gzip,deflate,sdch > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] HTTP Traceback > (most recent call last): > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > line 667, in respond > [Wed Aug 06 16:22:09 2014] [error] self.hooks.run('before_handler') > [Wed Aug 06 16:22:09 2014] [error] File > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > line 114, in run > [Wed Aug 06 16:22:09 2014] [error] raise exc > [Wed Aug 06 16:22:09 2014] [error] AssertionError: The session load without > being locked. Check your tools' priority levels. > [Wed Aug 06 16:22:09 2014] [error] > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] ['500 Internal > Server Error', 'The server encountered an unexpected condition which > prevented it from fulfilling the request.', 'Traceback (most recent call > last):\\n File > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > line 667, in respond\\n self.hooks.run(\\'before_handler\\')\\n File > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > line 114, in run\\n raise exc\\nAssertionError: The session load without > being locked. Check your tools\\' priority levels.\\n', '3.5.0'] > > and obviously "GET /idp/ HTTP/1.1" 500 1054 in /var/log/httpd/access_log > > Cherrypy bug? > > Thanks. I've never seen this but I am using Cherrypy 3.2.2 on F20. Simo. From knighcl at gmail.com Thu Aug 7 11:39:18 2014 From: knighcl at gmail.com (Curtis L. Knight) Date: Thu, 7 Aug 2014 07:39:18 -0400 Subject: [Freeipa-users] Building previous release rpms are failing In-Reply-To: <53E1A04E.2050403@redhat.com> References: <53E0B2B1.2040002@redhat.com> <53E0BE26.4070204@redhat.com> <53E1A04E.2050403@redhat.com> Message-ID: On Tue, Aug 5, 2014 at 11:26 PM, Rob Crittenden wrote: > Curtis L. Knight wrote: > > On Tue, Aug 5, 2014 at 7:21 AM, Martin Kosek > > wrote: > > > > On 08/05/2014 12:32 PM, Martin Kosek wrote: > > > On 08/05/2014 12:05 PM, Curtis L. Knight wrote: > > ... > > >> #./make-lint $(LINT_OPTIONS) > > >> > > >> run 'make rpms' again to get beyond lint errors shown below > > >> > > >> > > >> cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr > > >> --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi > > >> ./make-lint > > >> Traceback (most recent call last): > > >> File "./make-lint", line 272, in > > >> sys.exit(main()) > > >> File "./make-lint", line 243, in main > > >> linter.check(files) > > >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line > > 626, in check > > >> self.check_astroid_module(astroid, walker, rawcheckers, > > tokencheckers) > > >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line > > 712, in > > >> check_astroid_module > > >> walker.walk(astroid) > > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line > > 715, in walk > > >> self.walk(child) > > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line > > 715, in walk > > >> self.walk(child) > > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line > > 712, in walk > > >> cb(astroid) > > >> File > > "/usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py", > > >> line 135, in visit_function > > >> args=(call.args[0].name, )) > > >> AttributeError: 'Getattr' object has no attribute 'name' > > >> make: *** [lint] Error 1 > > > > > > This is new, I created upstream ticket to timely fix it: > > > https://fedorahosted.org/freeipa/ticket/4475 > > > > Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch > > should now > > build OK again. > > > > Martin > > > > > > Hey Martin, > > > > Tested ipa-3-3 and generated rpms from that branch. Many thanks for the > > resolution. > > > > Just a note, but I verified that ipa-3-2 and ipa-3-1 are in need of the > > same ipa-3-3 dependency patch. Both also complained that make-lint > > needed pylint installed which it already was. With the lint failure and > > rhino patch, ipa-3-2 did generate rpms. With the lint failure and rhino > > patch, ipa-3-1 did not generate rpms and gave the following logs. > > I guess it becomes a bit fuzzy, especially with these versions. We don't > usually offer any guarantees that older releases will build against more > modern distros, but both 3.1.5 and 3.2.0 crossed that line, with Fedora > builds in two releases (F18/19 and F19/20 respectively). > > Do you have a requirement to use these older releases or are you just > offering this data point in case anyone else runs into this? > > regards > > rob > Hello Rob, Yes this is additional information and is not any requirement for me. I was not sure which branches were being maintained for F20. My interest was to see if I could help the freeipa developers build rpms easily from git with Docker images/containers. That is just about finished. My next thought was about using a Docker containers to test code from a git working directory quickly. That workflow could be a) to build rpms from a git commit, install the generated rpms or b) push changed code into an existing freeipa installation (probably not recommended but maybe necessary for testing). I did read a couple of places that it seems to take less time and or RAM to build code within Docker then other methods. Overall there does not seem to be enough people that are doing it yet for a lot of data points. Does any of that sound beneficial to the team? Regards, Curtis -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Aug 7 12:53:19 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 07 Aug 2014 14:53:19 +0200 Subject: [Freeipa-users] IPA Replica does not start Bind but runs Manually In-Reply-To: References: <1407109927.19681.36.camel@willson.usersys.redhat.com> <53DF40BB.3060502@redhat.com> Message-ID: <53E376BF.8040700@redhat.com> On 5.8.2014 11:24, Matt . wrote: > Hi, > > I got this solved but the replica doesn't do it's forwards on the > zone's it need to foreward for, the master with the same settings > does. > > I have done a new install but the same happens. > > WHat could be wrong here ? Please provide us with installation logs /var/log/ipaserver-install.log so we can investigate it. Petr^2 Spacek > > Cheers, > > Matt > > 2014-08-04 10:13 GMT+02:00 Martin Kosek : >> On 08/04/2014 09:40 AM, Matt . wrote: >>> Hi, >>> >>> Yes I did in the past. THe DNS tabs are there and named is installed. >> >> You probably installed DNS service on another FreeIPA server. However, there is >> a configuration space telling which server has which services configured. It >> seems that it does not see your current server as the DNS server. >> >>> Can I run that "over" without any issue ? >> >> Yes, If it detects that DNS service was already installed there it will error >> out. Then we will do different route. >> >>> In any other case I just can reinstall the ipa software on the replica >>> and create a new setup for it... >> >> Let's not go this way (yet), simple DNS service installation should be work. >> >> Martin > -- Petr^2 Spacek From tjaalton at ubuntu.com Thu Aug 7 13:24:42 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 07 Aug 2014 16:24:42 +0300 Subject: [Freeipa-users] Ubuntu updates, client backport for 12.04 Message-ID: <53E37E1A.8010005@ubuntu.com> Hi So the archive version of freeipa-client on Ubuntu 12.04 has been in a limbo state until now, because the package got reworked too much for newer releases that trying to push updates would have taken a lot of paperwork and other effort.. But 14.10/utopic finally has a smoothly installing client based on 3.3.4, and I've also pushed the updates fixing ntp/chronyd issues to 14.04 (not accepted to trusty-proposed yet) and backported this version to 12.04 too. You can install it for 12.04 from the freeipa ppa: apt-add-repository ppa:freeipa https://launchpad.net/~freeipa/+archive/ubuntu/ppa/+packages and for this you also need the sssd ppa: apt-add-repository ppa:sssd/updates https://launchpad.net/~sssd/+archive/ubuntu/updates I've verified that install/uninstall works fine, certmonger stop/start fails on uninstall but it should be harmless. Only thing missing from it that I know of is that --mkhomedir does not work because of https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1336869 Also, beware that the version of nss on the ppa gets obsolete when a new security release is published, which means that new installs should create nssdb's by hand, or forcefully install the ppa version once and then upgrade.. the db's shouldn't vanish on upgrade. ps. server is still WIP, currently blocked on getting Dogtag deps accepted in the Debian archive, but the goal is still to have everything in by November before 'jessie' freezes.. we'll see -- t From mkosek at redhat.com Thu Aug 7 13:45:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 07 Aug 2014 15:45:05 +0200 Subject: [Freeipa-users] Building previous release rpms are failing In-Reply-To: References: <53E0B2B1.2040002@redhat.com> <53E0BE26.4070204@redhat.com> <53E1A04E.2050403@redhat.com> Message-ID: <53E382E1.8090507@redhat.com> On 08/07/2014 01:39 PM, Curtis L. Knight wrote: > On Tue, Aug 5, 2014 at 11:26 PM, Rob Crittenden wrote: > >> Curtis L. Knight wrote: >>> On Tue, Aug 5, 2014 at 7:21 AM, Martin Kosek >> > wrote: >>> >>> On 08/05/2014 12:32 PM, Martin Kosek wrote: >>> > On 08/05/2014 12:05 PM, Curtis L. Knight wrote: >>> ... >>> >> #./make-lint $(LINT_OPTIONS) >>> >> >>> >> run 'make rpms' again to get beyond lint errors shown below >>> >> >>> >> >>> >> cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr >>> >> --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi >>> >> ./make-lint >>> >> Traceback (most recent call last): >>> >> File "./make-lint", line 272, in >>> >> sys.exit(main()) >>> >> File "./make-lint", line 243, in main >>> >> linter.check(files) >>> >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line >>> 626, in check >>> >> self.check_astroid_module(astroid, walker, rawcheckers, >>> tokencheckers) >>> >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line >>> 712, in >>> >> check_astroid_module >>> >> walker.walk(astroid) >>> >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line >>> 715, in walk >>> >> self.walk(child) >>> >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line >>> 715, in walk >>> >> self.walk(child) >>> >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line >>> 712, in walk >>> >> cb(astroid) >>> >> File >>> "/usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py", >>> >> line 135, in visit_function >>> >> args=(call.args[0].name, )) >>> >> AttributeError: 'Getattr' object has no attribute 'name' >>> >> make: *** [lint] Error 1 >>> > >>> > This is new, I created upstream ticket to timely fix it: >>> > https://fedorahosted.org/freeipa/ticket/4475 >>> >>> Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch >>> should now >>> build OK again. >>> >>> Martin >>> >>> >>> Hey Martin, >>> >>> Tested ipa-3-3 and generated rpms from that branch. Many thanks for the >>> resolution. >>> >>> Just a note, but I verified that ipa-3-2 and ipa-3-1 are in need of the >>> same ipa-3-3 dependency patch. Both also complained that make-lint >>> needed pylint installed which it already was. With the lint failure and >>> rhino patch, ipa-3-2 did generate rpms. With the lint failure and rhino >>> patch, ipa-3-1 did not generate rpms and gave the following logs. >> >> I guess it becomes a bit fuzzy, especially with these versions. We don't >> usually offer any guarantees that older releases will build against more >> modern distros, but both 3.1.5 and 3.2.0 crossed that line, with Fedora >> builds in two releases (F18/19 and F19/20 respectively). >> >> Do you have a requirement to use these older releases or are you just >> offering this data point in case anyone else runs into this? >> >> regards >> >> rob >> > > Hello Rob, > > Yes this is additional information and is not any requirement for me. I was > not sure which branches were being maintained for F20. My interest was to > see if I could help the freeipa developers build rpms easily from git with > Docker images/containers. That is just about finished. My next thought was > about using a Docker containers to test code from a git working directory > quickly. That workflow could be a) to build rpms from a git commit, install > the generated rpms or b) push changed code into an existing freeipa > installation (probably not recommended but maybe necessary for testing). I > did read a couple of places that it seems to take less time and or RAM to > build code within Docker then other methods. Overall there does not seem to > be enough people that are doing it yet for a lot of data points. Does any > of that sound beneficial to the team? > > Regards, > Curtis Your efforts do sound interesting for the development team. I would like to encourage you to send your results to the freeipa-devel list, so that developers can give you proper feedback. I was already pondering whether containers could be utilized for our integration tests: http://www.freeipa.org/page/Testing#Integration_tests Currently, we use full VMs and that is obviously not so fast. If containers could be utilized, things could get much faster (I hope). Martin From lslebodn at redhat.com Thu Aug 7 15:06:10 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 7 Aug 2014 17:06:10 +0200 Subject: [Freeipa-users] Building previous release rpms are failing In-Reply-To: References: <53E0B2B1.2040002@redhat.com> <53E0BE26.4070204@redhat.com> <53E1A04E.2050403@redhat.com> Message-ID: <20140807150609.GA9907@mail.corp.redhat.com> On (07/08/14 07:39), Curtis L. Knight wrote: >On Tue, Aug 5, 2014 at 11:26 PM, Rob Crittenden wrote: > >> Curtis L. Knight wrote: >> > On Tue, Aug 5, 2014 at 7:21 AM, Martin Kosek > > > wrote: >> > >> > On 08/05/2014 12:32 PM, Martin Kosek wrote: >> > > On 08/05/2014 12:05 PM, Curtis L. Knight wrote: >> > ... >> > >> #./make-lint $(LINT_OPTIONS) >> > >> >> > >> run 'make rpms' again to get beyond lint errors shown below >> > >> >> > >> >> > >> cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr >> > >> --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib; fi >> > >> ./make-lint >> > >> Traceback (most recent call last): >> > >> File "./make-lint", line 272, in >> > >> sys.exit(main()) >> > >> File "./make-lint", line 243, in main >> > >> linter.check(files) >> > >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line >> > 626, in check >> > >> self.check_astroid_module(astroid, walker, rawcheckers, >> > tokencheckers) >> > >> File "/usr/lib/python2.7/site-packages/pylint/lint.py", line >> > 712, in >> > >> check_astroid_module >> > >> walker.walk(astroid) >> > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line >> > 715, in walk >> > >> self.walk(child) >> > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line >> > 715, in walk >> > >> self.walk(child) >> > >> File "/usr/lib/python2.7/site-packages/pylint/utils.py", line >> > 712, in walk >> > >> cb(astroid) >> > >> File >> > "/usr/lib/python2.7/site-packages/pylint/checkers/newstyle.py", >> > >> line 135, in visit_function >> > >> args=(call.args[0].name, )) >> > >> AttributeError: 'Getattr' object has no attribute 'name' >> > >> make: *** [lint] Error 1 >> > > >> > > This is new, I created upstream ticket to timely fix it: >> > > https://fedorahosted.org/freeipa/ticket/4475 >> > >> > Ticket 4475 is now fixed, thanks to Jan Cholasta. ipa-3-3 branch >> > should now >> > build OK again. >> > >> > Martin >> > >> > >> > Hey Martin, >> > >> > Tested ipa-3-3 and generated rpms from that branch. Many thanks for the >> > resolution. >> > >> > Just a note, but I verified that ipa-3-2 and ipa-3-1 are in need of the >> > same ipa-3-3 dependency patch. Both also complained that make-lint >> > needed pylint installed which it already was. With the lint failure and >> > rhino patch, ipa-3-2 did generate rpms. With the lint failure and rhino >> > patch, ipa-3-1 did not generate rpms and gave the following logs. >> >> I guess it becomes a bit fuzzy, especially with these versions. We don't >> usually offer any guarantees that older releases will build against more >> modern distros, but both 3.1.5 and 3.2.0 crossed that line, with Fedora >> builds in two releases (F18/19 and F19/20 respectively). >> >> Do you have a requirement to use these older releases or are you just >> offering this data point in case anyone else runs into this? >> >> regards >> >> rob >> > >Hello Rob, > >Yes this is additional information and is not any requirement for me. I was >not sure which branches were being maintained for F20. My interest was to >see if I could help the freeipa developers build rpms easily from git with >Docker images/containers. That is just about finished. My next thought was >about using a Docker containers to test code from a git working directory >quickly. That workflow could be a) to build rpms from a git commit, install >the generated rpms or b) push changed code into an existing freeipa >installation (probably not recommended but maybe necessary for testing). I >did read a couple of places that it seems to take less time and or RAM to >build code within Docker then other methods. Overall there does not seem to What kind of other methods did you try? I doubt it is more efficient then mock [1] >be enough people that are doing it yet for a lot of data points. Does any >of that sound beneficial to the team? > LS [1] http://fedoraproject.org/wiki/Projects/Mock From ltartarini90 at gmail.com Thu Aug 7 15:49:51 2014 From: ltartarini90 at gmail.com (Luca Tartarini) Date: Thu, 7 Aug 2014 17:49:51 +0200 Subject: [Freeipa-users] FreeIPA + Ipsilon In-Reply-To: <1407339420.4573.21.camel@willson.usersys.redhat.com> References: <1406805084.30289.25.camel@willson.usersys.redhat.com> <1407260903.4573.9.camel@willson.usersys.redhat.com> <53E12368.9070308@redhat.com> <1407339420.4573.21.camel@willson.usersys.redhat.com> Message-ID: Hi, thanks for the reply, with Cherrypy 3.2.2 it works. Unfortunately now when I try to login with 'admin' account ('admin' user created previously during the installation of ipa-server) I can't see the Administration tab. Basically this condition (in /usr/share/ipsilon/templates/index.html) is not satisfied: {% if user.is_admin %} Administration | {% endif %} For ipsilon-server installation I run: ipsilon-server-install --secure=no --ipa=yes --krb=yes because I read that 'admin' is default. When I login with 'admin' in IPA Identity Management it is all ok (I login as administrator), with IPSILON I can login but not as administrator. I used the last version of jinja2 (jinja2 2.7.2). Log of ipsilon-server-install: [2014-08-07 17:48:11,242] Intallation arguments: [2014-08-07 17:48:11,242] admin_user: admin [2014-08-07 17:48:11,242] config_profile: None [2014-08-07 17:48:11,242] hostname: ltartari3.cern.ch [2014-08-07 17:48:11,242] instance: idp [2014-08-07 17:48:11,242] ipa: yes [2014-08-07 17:48:11,243] krb: yes [2014-08-07 17:48:11,243] krb_httpd_keytab: /etc/httpd/conf/http.keytab [2014-08-07 17:48:11,243] krb_realms: None [2014-08-07 17:48:11,243] lm_order: ['krb'] [2014-08-07 17:48:11,243] pam: no [2014-08-07 17:48:11,243] pam_service: remote [2014-08-07 17:48:11,243] saml2: yes [2014-08-07 17:48:11,243] secure: no [2014-08-07 17:48:11,243] server_debugging: False [2014-08-07 17:48:11,244] system_user: ipsilon [2014-08-07 17:48:11,244] testauth: no [2014-08-07 17:48:11,244] uninstall: False [2014-08-07 17:48:11,244] Installation initiated [2014-08-07 17:48:11,244] Installing default config files [2014-08-07 17:48:11,461] Configuring environment helpers Searching for keytab in: /etc/httpd/conf/http.keytab ... Found! Searching for keytab in: /etc/httpd/conf/ipa.keytab ... Found! [2014-08-07 17:48:11,486] Configuring login managers Cannot set persistent booleans without managed policy. [2014-08-07 17:48:12,126] Configuring Authentication Providers Generating a 2048 bit RSA private key .............+++ ..............+++ writing new private key to '/var/lib/ipsilon/idp/saml2/idp.key' ----- Installation complete. Please restart HTTPD to enable the IdP instance. Thanks in advance. Luca Tartarini 2014-08-06 17:37 GMT+02:00 Simo Sorce : > On Wed, 2014-08-06 at 17:20 +0200, Luca Tartarini wrote: > > Hi, > > > > Thanks for the replies. I updated the line with: > > > > plugins_by_name = dict((p.name, p) for p in > self._site[FACILITY]['enabled']) > > > > and it works (the installation is completed succesfully). > > > > But now when I try to connect to: > > > > https://myidp.example.com/idp > > > > or I try to configure ipsilon-client (ipsilon-client-install ...) I got > > HTTP 500 Internal Error (with ipsilon background). I put "debug = True" > > in /etc/ipsilon/idp/ipsilon.conf and I got this (in > > /var/log/httpd/error_log): > > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Available > > providers: ['saml2'] > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > storage path: /var/lib/ipsilon/idp/saml2 > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > metadata file: metadata.xml > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > storage path: /var/lib/ipsilon/idp/saml2 > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > key > > file: /var/lib/ipsilon/idp/saml2/idp.key > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > storage path: /var/lib/ipsilon/idp/saml2 > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > certificate file: /var/lib/ipsilon/idp/saml2/idp.pem > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] IdP Provider > > registered: saml2 > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] > enabled: > > 1 > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] IdP Provider > > enabled: saml2 > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login > > plugin: krb > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login > > plugin: pam > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] username > > text: Username > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] password > > text: Password > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] service > > name: remote > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] help > text: > > Insert your Username and Password and then submit. > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login > > plugin: testauth > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] > > username text: Username > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] > > password text: Password > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] > help > > text: Insert your Username and Password and then submit. > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin provider > > plugin: saml2 > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] > default > > allowed nameids: ['persistent', 'transient', 'email', 'kerberos', 'x509'] > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > metadata file: metadata.xml > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] > default > > email domain: example.com > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > certificate file: /var/lib/ipsilon/idp/saml2/idp.pem > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] allow > > self registration: True > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > key > > file: /var/lib/ipsilon/idp/saml2/idp.key > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > storage path: /var/lib/ipsilon/idp/saml2 > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] > default > > nameid: persistent > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Traceback > (most > > recent call last): > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > line 104, in run > > [Wed Aug 06 16:22:09 2014] [error] hook() > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > line 63, in __call__ > > [Wed Aug 06 16:22:09 2014] [error] return > self.callback(**self.kwargs) > > [Wed Aug 06 16:22:09 2014] [error] File > > "/usr/lib/python2.6/site-packages/ipsilon/util/page.py", line 37, in > protect > > [Wed Aug 06 16:22:09 2014] [error] UserSession().remote_login() > > [Wed Aug 06 16:22:09 2014] [error] File > > "/usr/lib/python2.6/site-packages/ipsilon/util/user.py", line 103, in > > __init__ > > [Wed Aug 06 16:22:09 2014] [error] self.user = self.get_data('user', > > 'name') > > [Wed Aug 06 16:22:09 2014] [error] File > > "/usr/lib/python2.6/site-packages/ipsilon/util/user.py", line 147, in > > get_data > > [Wed Aug 06 16:22:09 2014] [error] if facility not in > cherrypy.session: > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/__init__.py", > > line 258, in __contains__ > > [Wed Aug 06 16:22:09 2014] [error] return key in child > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", > > line 335, in __contains__ > > [Wed Aug 06 16:22:09 2014] [error] self.load() > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", > > line 268, in load > > [Wed Aug 06 16:22:09 2014] [error] data = self._load() > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", > > line 497, in _load > > [Wed Aug 06 16:22:09 2014] [error] assert self.locked, ("The session > > load without being locked. " > > [Wed Aug 06 16:22:09 2014] [error] AssertionError: The session load > without > > being locked. Check your tools' priority levels. > > [Wed Aug 06 16:22:09 2014] [error] > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] HTTP > > [Wed Aug 06 16:22:09 2014] [error] Request Headers: > > [Wed Aug 06 16:22:09 2014] [error] COOKIE: > > __utma=203412483.1716219377.1393273532.1393273532.1398882487.2; > > > __utmz=203412483.1398882487.2.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); > > _ga=GA1.2.1716219377.1393273532; > > session_id=0942ebacef3fbcf8f9b21605013b5dfa1454bc93 > > [Wed Aug 06 16:22:09 2014] [error] ACCEPT-LANGUAGE: > > it-IT,it;q=0.8,en-US;q=0.6,en;q=0.4,fr;q=0.2 > > [Wed Aug 06 16:22:09 2014] [error] USER-AGENT: Mozilla/5.0 (X11; Linux > > x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.132 > > Safari/537.36 > > [Wed Aug 06 16:22:09 2014] [error] CONNECTION: keep-alive > > [Wed Aug 06 16:22:09 2014] [error] Remote-Addr: 128.141.28.32 > > [Wed Aug 06 16:22:09 2014] [error] HOST: ltartari3.cern.ch > > [Wed Aug 06 16:22:09 2014] [error] CACHE-CONTROL: max-age=0 > > [Wed Aug 06 16:22:09 2014] [error] ACCEPT: > > > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > > [Wed Aug 06 16:22:09 2014] [error] ACCEPT-ENCODING: gzip,deflate,sdch > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] HTTP Traceback > > (most recent call last): > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > line 667, in respond > > [Wed Aug 06 16:22:09 2014] [error] self.hooks.run('before_handler') > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > line 114, in run > > [Wed Aug 06 16:22:09 2014] [error] raise exc > > [Wed Aug 06 16:22:09 2014] [error] AssertionError: The session load > without > > being locked. Check your tools' priority levels. > > [Wed Aug 06 16:22:09 2014] [error] > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] ['500 Internal > > Server Error', 'The server encountered an unexpected condition which > > prevented it from fulfilling the request.', 'Traceback (most recent call > > last):\\n File > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > line 667, in respond\\n self.hooks.run(\\'before_handler\\')\\n File > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > line 114, in run\\n raise exc\\nAssertionError: The session load > without > > being locked. Check your tools\\' priority levels.\\n', '3.5.0'] > > > > and obviously "GET /idp/ HTTP/1.1" 500 1054 in /var/log/httpd/access_log > > > > Cherrypy bug? > > > > Thanks. > > I've never seen this but I am using Cherrypy 3.2.2 on F20. > > Simo. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyamanishi at sesda3.com Thu Aug 7 16:14:08 2014 From: lyamanishi at sesda3.com (Lucas Yamanishi) Date: Thu, 07 Aug 2014 12:14:08 -0400 Subject: [Freeipa-users] Certificate system unavailable Message-ID: <53E3A5D0.7010509@sesda3.com> Hello, I'm a bit of a pickle with the PKI system. I have three replicas, but only one contains the CA. I realize how poor a decision it was to do that. I plan to create more complete replicas, but right now I can't even create a replica file, much less a full replica. The problem started when the CA subsystem certificates expired. I read several threads explaining how to roll back time and renew them, but I then discovered that the host and HTTP certificates for the server were missing. I checked for backups, but we erroneously did not cover those files. Because they are missing I was unable to rewnew any certificates. Is there a way to manually create host and service certificates? When I search for this, the "manual" procedure listed in the documentation requires `ipa cert-request` which does not work. I did try installing a self-signed cert for HTTP with `ipa-server-certinstall`. That changed the errors, but the commands still fail. The pki-ca services is running OK, as far as I can tell. I also tried adding a CA instance to one of the other replicas with `ipa-ca-install`, but it failed during the configuration phase. -- ----- *question everything*learn something*answer nothing* ------------ Lucas Yamanishi ------------------ Systems Administrator, ADNET Systems, Inc. NASA Space and Earth Science Data Analysis (606.9) 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Thu Aug 7 16:18:57 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Thu, 7 Aug 2014 11:18:57 -0500 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium Message-ID: I'm currently working on a trial with OKTA and have installed their server agent with no issues. Now I'm trying to map FreeIPA attributes with OKTA's I'm getting no entries found, which leads me to think I'm missing something [image: Inline image 1] [image: Inline image 2] [image: Inline image 3] Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 103249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 88448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 89508 bytes Desc: not available URL: From rcritten at redhat.com Thu Aug 7 17:15:09 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Aug 2014 13:15:09 -0400 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: References: Message-ID: <53E3B41D.5050805@redhat.com> Chris Whittle wrote: > I'm currently working on a trial with OKTA and have installed their > server agent with no issues. Now I'm trying to map FreeIPA attributes > with OKTA's > > I'm getting no entries found, which leads me to think I'm missing something > Inline image 1 > Inline image 2 > Inline image 3 > Thanks! > > Try these changes: User Unique Identifier Attribute: ipaUniqueID Object Class: posixAccount Password Attribute: userPassword Group Object Class: posixGroup I don't think their Role maps directly with our Role, not sure you should try. You may need to define a new area in the DIT for this. Otherwise the settings look correct to me. Once you get something working it would be great if you could write something on on our Wiki about it under http://www.freeipa.org/page/HowTos rob From lyamanishi at sesda3.com Thu Aug 7 17:22:16 2014 From: lyamanishi at sesda3.com (Lucas Yamanishi) Date: Thu, 07 Aug 2014 13:22:16 -0400 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: References: Message-ID: <53E3B5C8.6090208@sesda3.com> On 08/07/2014 12:18 PM, Chris Whittle wrote: > I'm currently working on a trial with OKTA and have installed their > server agent with no issues. Now I'm trying to map FreeIPA attributes > with OKTA's > > I'm getting no entries found, which leads me to think I'm missing > something > Inline image 1 > Inline image 2 > Inline image 3 > Thanks! > > The objectClass values look incorrect. Try |posixAccount| and |posixGroup| for users and groups. Roles are |groupOfNames|, but that?s a little less specific and will match non-role entries without a search base. You can easily look up raw entries to check your mappings with commands like these (the ?all and ?raw options are available for all *-show commands, afaik): |ipa user-show --all --raw $USER_NAME ipa group-show --all --raw $GROUP ipa role-show --all --raw $ROLE | Or pure ldaputils: | ldapsearch -LLL -YGSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' 'uid=$USER_NAME' | ? -- ----- *question everything*learn something*answer nothing* ------------ Lucas Yamanishi ------------------ Systems Administrator, ADNET Systems, Inc. NASA Space and Earth Science Data Analysis (606.9) 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 89508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 88448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 103249 bytes Desc: not available URL: From rcritten at redhat.com Thu Aug 7 17:25:20 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Aug 2014 13:25:20 -0400 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53E3A5D0.7010509@sesda3.com> References: <53E3A5D0.7010509@sesda3.com> Message-ID: <53E3B680.2080901@redhat.com> Lucas Yamanishi wrote: > Hello, I'm a bit of a pickle with the PKI system. I have three > replicas, but only one contains the CA. I realize how poor a decision > it was to do that. I plan to create more complete replicas, but right > now I can't even create a replica file, much less a full replica. > > The problem started when the CA subsystem certificates expired. I read > several threads explaining how to roll back time and renew them, but I > then discovered that the host and HTTP certificates for the server were > missing. I checked for backups, but we erroneously did not cover those > files. Because they are missing I was unable to rewnew any certificates. > > Is there a way to manually create host and service certificates? When I > search for this, the "manual" procedure listed in the documentation > requires `ipa cert-request` which does not work. I did try installing a > self-signed cert for HTTP with `ipa-server-certinstall`. That changed > the errors, but the commands still fail. The pki-ca services is running > OK, as far as I can tell. > > I also tried adding a CA instance to one of the other replicas with > `ipa-ca-install`, but it failed during the configuration phase. The subsystem certificate renewal should be independent of the web (and host) certificates. I'd focus on getting the CA back up, then we can see about getting a new web server certificate. Can you share the output of: getcert list You'll probably want to obfuscate the output as it contains the PIN to the private key database of the CA. rob From cwhittl at gmail.com Thu Aug 7 18:21:49 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Thu, 7 Aug 2014 13:21:49 -0500 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: <53E3B5C8.6090208@sesda3.com> References: <53E3B5C8.6090208@sesda3.com> Message-ID: Thanks guys that works! On Thu, Aug 7, 2014 at 12:22 PM, Lucas Yamanishi wrote: > On 08/07/2014 12:18 PM, Chris Whittle wrote: > > I'm currently working on a trial with OKTA and have installed their > server agent with no issues. Now I'm trying to map FreeIPA attributes with > OKTA's > > I'm getting no entries found, which leads me to think I'm missing > something > [image: Inline image 1] > [image: Inline image 2] > [image: Inline image 3] > Thanks! > > > The objectClass values look incorrect. Try posixAccount and posixGroup > for users and groups. Roles are groupOfNames, but that?s a little less > specific and will match non-role entries without a search base. > > You can easily look up raw entries to check your mappings with commands > like these (the ?all and ?raw options are available for all *-show > commands, afaik): > > ipa user-show --all --raw $USER_NAME > ipa group-show --all --raw $GROUP > ipa role-show --all --raw $ROLE > > Or pure ldaputils: > > ldapsearch -LLL -YGSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' 'uid=$USER_NAME' > > ? > > -- > ----- > *question everything*learn something*answer nothing* > ------------ > Lucas Yamanishi > ------------------ > Systems Administrator, ADNET Systems, Inc. > NASA Space and Earth Science Data Analysis (606.9) > 7515 Mission Drive, Suite A100 > Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB > > > -- > Manage your subscription for 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: not available Type: image/png Size: 88448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 103249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 89508 bytes Desc: not available URL: From lyamanishi at sesda3.com Thu Aug 7 18:41:56 2014 From: lyamanishi at sesda3.com (Lucas Yamanishi) Date: Thu, 07 Aug 2014 14:41:56 -0400 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53E3B680.2080901@redhat.com> References: <53E3A5D0.7010509@sesda3.com> <53E3B680.2080901@redhat.com> Message-ID: <53E3C874.60904@sesda3.com> On 08/07/2014 01:25 PM, Rob Crittenden wrote: > Lucas Yamanishi wrote: >> Hello, I'm a bit of a pickle with the PKI system. I have three >> replicas, but only one contains the CA. I realize how poor a decision >> it was to do that. I plan to create more complete replicas, but right >> now I can't even create a replica file, much less a full replica. >> >> The problem started when the CA subsystem certificates expired. I read >> several threads explaining how to roll back time and renew them, but I >> then discovered that the host and HTTP certificates for the server were >> missing. I checked for backups, but we erroneously did not cover those >> files. Because they are missing I was unable to rewnew any certificates. >> >> Is there a way to manually create host and service certificates? When I >> search for this, the "manual" procedure listed in the documentation >> requires `ipa cert-request` which does not work. I did try installing a >> self-signed cert for HTTP with `ipa-server-certinstall`. That changed >> the errors, but the commands still fail. The pki-ca services is running >> OK, as far as I can tell. >> >> I also tried adding a CA instance to one of the other replicas with >> `ipa-ca-install`, but it failed during the configuration phase. > The subsystem certificate renewal should be independent of the web (and > host) certificates. I'd focus on getting the CA back up, then we can see > about getting a new web server certificate. > > Can you share the output of: getcert list > > You'll probably want to obfuscate the output as it contains the PIN to > the private key database of the CA. > > rob Here you go. I've also included `certutil -L` outputs. The *auditSigningCert* I tried resubmitting with the time rolled back. The post-save command was also updated, because it wasn't done a year or two back when it replaced our old CRL-signer. `getcert list`: ``` Number of certificates and requests being tracked: 7. Request ID '20130321103859': status: CA_UNREACHABLE ca-error: Error 35 connecting to https://badca.example.com:9443/ca/agent/ca/profileReview: SSL connect error. stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='XXXXXXXXXXXX' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Audit,O=EXAMPLE.COM expires: 2014-07-31 21:29:35 UTC pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130321103900': status: NEED_GUIDANCE stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='XXXXXXXXXXXX' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=OCSP Subsystem,O=EXAMPLE.COM expires: 2014-07-31 21:29:33 UTC eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/restart_pkicad "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130321103901': status: NEED_GUIDANCE stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='XXXXXXXXXXXX' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Subsystem,O=EXAMPLE.COM expires: 2014-07-31 21:29:34 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/restart_pkicad "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130321103902': status: NEED_GUIDANCE stuck: yes key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=IPA RA,O=EXAMPLE.COM expires: 2014-07-31 21:30:34 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes Request ID '20130321103903': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='XXXXXXXXXXXX' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=badca.example.com,O=EXAMPLE.COM expires: 2016-07-03 23:53:02 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20140724160403': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=badca.example.com,O=EXAMPLE.COM expires: 2016-07-28 18:28:51 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE-COM track: yes auto-renew: yes Request ID '20140807180016': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=badca.example.com,O=EXAMPLE.COM expires: 2016-07-25 23:53:04 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA track: yes auto-renew: yes ``` `certutil -L -d /var/lib/pki-ca/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,u,u auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u ``` `certutil -L -d /etc/httpd/alias` (most of these were re-added after `ipa-server-certinstall` removed them): ``` Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI badca.example.com - self-signed CTu,Cu,u EXAMPLE.COM IPA CA CT,C, ipaCert u,u,u Server-Cert ,, ``` `certutil -L -d /etc/pki/nssdb`: ``` Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI badca.example.com - self-signed CT,C,C IPA CA CT,C,C ``` -- ----- *question everything*learn something*answer nothing* ------------ Lucas Yamanishi ------------------ Systems Administrator, ADNET Systems, Inc. NASA Space and Earth Science Data Analysis (606.9) 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB -------------- next part -------------- An HTML attachment was scrubbed... URL: From aalam at paperlesspost.com Thu Aug 7 20:32:37 2014 From: aalam at paperlesspost.com (Ash Alam) Date: Thu, 7 Aug 2014 16:32:37 -0400 Subject: [Freeipa-users] FreeIPA + Chef In-Reply-To: References: Message-ID: Thank You for the link. We are a chef shop so ill be working on this in chef. Ill see what i can use from Sean's repo and from the one you provided. If anyone have any recommendations/suggestions feel free to post them. Thank You ash On Thu, Jul 31, 2014 at 2:55 PM, James wrote: > On Thu, Jul 31, 2014 at 11:55 AM, Ash Alam wrote: > > Hi > > > > I am currently deploying CentOS and FreeIPA and i am looking for some > > recommendation on chef cookbooks. I have googled around but haven't found > > anything that is current. I found a git repo from "Sean OMeara" but last > > contribution was 3 years ago. > > > > If anyone can point me in the right direction i would very grateful. > > > > Thank You > > > I've got a puppet module that I'm actively working on... > https://github.com/purpleidea/puppet-ipa > > If you don't find a ready chef module, you can consider using puppet > instead, or start porting it to chef. A lot of the code can be > re-used, since my module contains a good amount of puppet. > > HTH, > James > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Aug 7 20:48:04 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Aug 2014 16:48:04 -0400 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53E3C874.60904@sesda3.com> References: <53E3A5D0.7010509@sesda3.com> <53E3B680.2080901@redhat.com> <53E3C874.60904@sesda3.com> Message-ID: <53E3E604.7080203@redhat.com> Lucas Yamanishi wrote: > On 08/07/2014 01:25 PM, Rob Crittenden wrote: >> Lucas Yamanishi wrote: >>> Hello, I'm a bit of a pickle with the PKI system. I have three >>> replicas, but only one contains the CA. I realize how poor a decision >>> it was to do that. I plan to create more complete replicas, but right >>> now I can't even create a replica file, much less a full replica. >>> >>> The problem started when the CA subsystem certificates expired. I read >>> several threads explaining how to roll back time and renew them, but I >>> then discovered that the host and HTTP certificates for the server were >>> missing. I checked for backups, but we erroneously did not cover those >>> files. Because they are missing I was unable to rewnew any certificates. >>> >>> Is there a way to manually create host and service certificates? When I >>> search for this, the "manual" procedure listed in the documentation >>> requires `ipa cert-request` which does not work. I did try installing a >>> self-signed cert for HTTP with `ipa-server-certinstall`. That changed >>> the errors, but the commands still fail. The pki-ca services is running >>> OK, as far as I can tell. >>> >>> I also tried adding a CA instance to one of the other replicas with >>> `ipa-ca-install`, but it failed during the configuration phase. >> The subsystem certificate renewal should be independent of the web (and >> host) certificates. I'd focus on getting the CA back up, then we can see >> about getting a new web server certificate. >> >> Can you share the output of: getcert list >> >> You'll probably want to obfuscate the output as it contains the PIN to >> the private key database of the CA. >> >> rob > Here you go. I've also included `certutil -L` outputs. > > The *auditSigningCert* I tried resubmitting with the time rolled back. > The post-save command was also updated, because it wasn't done a year or > two back when it replaced our old CRL-signer. > > `getcert list`: > > ``` > Number of certificates and requests being tracked: 7. [ snip ] What version of IPA is this? You need to modify a few more of these. Take a look at http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master When you roll back time are you restarting the pki-cad service? rob From lyamanishi at sesda3.com Thu Aug 7 21:27:25 2014 From: lyamanishi at sesda3.com (Lucas Yamanishi) Date: Thu, 07 Aug 2014 17:27:25 -0400 Subject: [Freeipa-users] Certificate system unavailable In-Reply-To: <53E3E604.7080203@redhat.com> References: <53E3A5D0.7010509@sesda3.com> <53E3B680.2080901@redhat.com> <53E3C874.60904@sesda3.com> <53E3E604.7080203@redhat.com> Message-ID: <53E3EF3D.1030802@sesda3.com> On 08/07/2014 04:48 PM, Rob Crittenden wrote: > Lucas Yamanishi wrote: >> On 08/07/2014 01:25 PM, Rob Crittenden wrote: >>> Lucas Yamanishi wrote: >>>> Hello, I'm a bit of a pickle with the PKI system. I have three >>>> replicas, but only one contains the CA. I realize how poor a decision >>>> it was to do that. I plan to create more complete replicas, but right >>>> now I can't even create a replica file, much less a full replica. >>>> >>>> The problem started when the CA subsystem certificates expired. I read >>>> several threads explaining how to roll back time and renew them, but I >>>> then discovered that the host and HTTP certificates for the server were >>>> missing. I checked for backups, but we erroneously did not cover those >>>> files. Because they are missing I was unable to rewnew any certificates. >>>> >>>> Is there a way to manually create host and service certificates? When I >>>> search for this, the "manual" procedure listed in the documentation >>>> requires `ipa cert-request` which does not work. I did try installing a >>>> self-signed cert for HTTP with `ipa-server-certinstall`. That changed >>>> the errors, but the commands still fail. The pki-ca services is running >>>> OK, as far as I can tell. >>>> >>>> I also tried adding a CA instance to one of the other replicas with >>>> `ipa-ca-install`, but it failed during the configuration phase. >>> The subsystem certificate renewal should be independent of the web (and >>> host) certificates. I'd focus on getting the CA back up, then we can see >>> about getting a new web server certificate. >>> >>> Can you share the output of: getcert list >>> >>> You'll probably want to obfuscate the output as it contains the PIN to >>> the private key database of the CA. >>> >>> rob >> Here you go. I've also included `certutil -L` outputs. >> >> The *auditSigningCert* I tried resubmitting with the time rolled back. >> The post-save command was also updated, because it wasn't done a year or >> two back when it replaced our old CRL-signer. >> >> `getcert list`: >> >> ``` >> Number of certificates and requests being tracked: 7. > [ snip ] > > What version of IPA is this? Sorry. It's 3.0.0-37.el6 on Scientific Linux 6x. 389ds is 1.2.11.15-32.el6_5 and Dogtag is 9.0.3-32.el6. > > You need to modify a few more of these. Take a look at > http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master Thanks. That was in my notes to do for the resubmits. The CS.cfg changes were made a long while back, before the guide. I think the ipa-pki-proxy.conf change was inherited with an upgrade. Those are awesome, BTW, the rpm automated upgrades! The renew_ra_cert script, too. > > When you roll back time are you restarting the pki-cad service? I think I did, but I can't recall. I will be sure to do it this weekend when I try again. > > rob > Since you pointed out that the certificates and ipa commands should not be dependent on each other I discovered that the host ticket needed renewing. The version was out of sync. Running `kinit -kt /etc/krb5.keytab host/badca.example.com at EXAMPLE.COM` fixed the ipa commands and I now get the expected SSL_ERROR_EXPIRED_CERT_ALERT code when doing a cert-request. Is there anything else I should look at? -- ----- *question everything*learn something*answer nothing* ------------ Lucas Yamanishi ------------------ Systems Administrator, ADNET Systems, Inc. NASA Space and Earth Science Data Analysis (606.9) 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Fri Aug 8 12:28:40 2014 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 8 Aug 2014 14:28:40 +0200 Subject: [Freeipa-users] IPA Replica does not start Bind but runs Manually In-Reply-To: <53E376BF.8040700@redhat.com> References: <1407109927.19681.36.camel@willson.usersys.redhat.com> <53DF40BB.3060502@redhat.com> <53E376BF.8040700@redhat.com> Message-ID: Hi, Sorry, my fault, there was a FW fule in between. Thanks for the heads up. Matt 2014-08-07 14:53 GMT+02:00 Petr Spacek : > On 5.8.2014 11:24, Matt . wrote: >> >> Hi, >> >> I got this solved but the replica doesn't do it's forwards on the >> zone's it need to foreward for, the master with the same settings >> does. >> >> I have done a new install but the same happens. >> >> WHat could be wrong here ? > > > Please provide us with installation logs /var/log/ipaserver-install.log so > we can investigate it. > > Petr^2 Spacek > > >> >> Cheers, >> >> Matt >> >> 2014-08-04 10:13 GMT+02:00 Martin Kosek : >>> >>> On 08/04/2014 09:40 AM, Matt . wrote: >>>> >>>> Hi, >>>> >>>> Yes I did in the past. THe DNS tabs are there and named is installed. >>> >>> >>> You probably installed DNS service on another FreeIPA server. However, >>> there is >>> a configuration space telling which server has which services configured. >>> It >>> seems that it does not see your current server as the DNS server. >>> >>>> Can I run that "over" without any issue ? >>> >>> >>> Yes, If it detects that DNS service was already installed there it will >>> error >>> out. Then we will do different route. >>> >>>> In any other case I just can reinstall the ipa software on the replica >>>> and create a new setup for it... >>> >>> >>> Let's not go this way (yet), simple DNS service installation should be >>> work. >>> >>> Martin >> >> > > > -- > Petr^2 Spacek > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From nicklas.bjork at skalarit.se Fri Aug 8 12:46:02 2014 From: nicklas.bjork at skalarit.se (=?UTF-8?B?Tmlja2xhcyBCasO2cms=?=) Date: Fri, 08 Aug 2014 14:46:02 +0200 Subject: [Freeipa-users] ca.crt contains more than one certificate Message-ID: <53E4C68A.7040909@skalarit.se> Trying to upgrade from FreeIPA 3.0 running on CentOS 6 to 3.3 on CentOS 7 using migration. I seem to have run into some certificate problems and the replica installation halts half-way through. We have a simple CA-structure, where FreeIPA has been installed as a sub-ca directly under ca root ca. A replica bundle was created on the master using: ipa-replica-prepare replica.example.net --ip-address 192.168.100.2 the gpg-file was copied to replica:/var/lib/ipa and the following command was executed: ipa-replica-install --mkhomedir -d --setup-ca --setup-dns --no-forwarders /var/lib/ipa/replica-info-replica.example.net.gpg During the first attempt, I was instructed to also run copy-schema-to-ca.py on the master server, which has been done. The replica installation halts complainig that ca.crt contains more than one certificate. Both the FreeIPA CA and the Root CA certificates are in that file. Debug output in /var/log/ipareplica-install.log tells the following: 2014-08-08T12:22:08Z DEBUG [17/34]: configuring ssl for ds instance 2014-08-08T12:22:08Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2014-08-08T12:22:08Z DEBUG Starting external process 2014-08-08T12:22:08Z DEBUG args=/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-NET/ -N -f /etc/dirsrv/slapd-EXAMPLE-NET//pwdfile.txt 2014-08-08T12:22:08Z DEBUG Process finished, return code=0 2014-08-08T12:22:08Z DEBUG stdout= 2014-08-08T12:22:08Z DEBUG stderr= 2014-08-08T12:22:08Z DEBUG Starting external process 2014-08-08T12:22:08Z DEBUG args=/usr/bin/pk12util -d /etc/dirsrv/slapd-EXAMPLE-NET/ -i /tmp/tmpNOzZ3cipa/realm_info/dscert.p12 -k /etc/dirsrv/slapd-EXAMPLE-NET//pwdfile.txt -v -w /dev/stdin 2014-08-08T12:22:08Z DEBUG Process finished, return code=0 2014-08-08T12:22:08Z DEBUG stdout=pk12util: PKCS12 IMPORT SUCCESSFUL 2014-08-08T12:22:08Z DEBUG stderr= 2014-08-08T12:22:08Z DEBUG Starting external process 2014-08-08T12:22:08Z DEBUG args=/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-NET/ -L 2014-08-08T12:22:08Z DEBUG Process finished, return code=0 2014-08-08T12:22:08Z DEBUG stdout= Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u CN=Example Root CA,O=Example AB ,, EXAMPLE.NET IPA CA ,, 2014-08-08T12:22:08Z DEBUG stderr= 2014-08-08T12:22:08Z DEBUG Starting external process 2014-08-08T12:22:08Z DEBUG args=/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-NET/ -A -n CA -t CT,CT, -a 2014-08-08T12:22:08Z DEBUG Process finished, return code=0 2014-08-08T12:22:08Z DEBUG stdout= 2014-08-08T12:22:08Z DEBUG stderr= 2014-08-08T12:22:08Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 638, in run_script return_value = main_function() File "/usr/sbin/ipa-replica-install", line 664, in main ds = install_replica_ds(config) File "/usr/sbin/ipa-replica-install", line 189, in install_replica_ds ca_file=config.dir + "/ca.crt", File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 360, in create_replica self.start_creation(runtime=60) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 364, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 606, in enable_ssl ca_file=self.ca_file) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 841, in create_from_pkcs12 self.nssdb.import_pem_cert('CA', 'CT,CT,', ca_file) File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", line 240, in import_pem_cert location) 2014-08-08T12:22:08Z DEBUG The ipa-replica-install command failed, exception: ValueError: /tmp/tmpNOzZ3cipa/realm_info/ca.crt contains more than one certificate Is there anything obvious that is wrong or odd with this setup or process? Best regards Nicklas Bj?rk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: From bruno-barbosa at prodesan.com.br Fri Aug 8 12:51:55 2014 From: bruno-barbosa at prodesan.com.br (Bruno Henrique Barbosa) Date: Fri, 8 Aug 2014 09:51:55 -0300 (BRT) Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> Message-ID: <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> Hello everyone, I'm running through an issue where an application needs its server's hostname to be in short name format, such as "server" and not "server.example.com". When I started deploying FreeIPA in the very beginning of this year, I remember I couldn't install freeipa-client with a bare "ipa-client install", because of this: ____________ [root at server ~] # hostname server [root at server ~]# hostname -f server.example.com [root at server ~]# ipa-client-install Discovery was successful! Hostname: server.example.com Realm: EXAMPLE.COM DNS Domain: example.com IPA Server: ipa01.example.com Base DN: dc=example,dc=com Continue to configure the system with these values? [no] yes User authorized to enroll computers: admin Synchronizing time with KDC... Unable to sync time with IPA NTP Server, assuming the time is in sync. Please check that port 123 UDP is opened. Password for admin at EXAMPLE.COM: Joining realm failed: The hostname must be fully-qualified: server Installation failed. Rolling back changes. IPA client is not configured on this system. ________________ So, using the short name as hostname didn't work for install, I then make it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", and it installs and works like a charm, BUT it updates the machine's hostname to FQDN. What I tested and, at first, worked: after deploying and ipa-client installation with those parameters which work, renaming the machine back to a short name AT FIRST is not causing any problems. I can login with my ssh rules perfectly, but I don't find any IPA technical docs saying it will/won't work if I change the hostname back to short name and not FQDN. Searching for it, I found on RedHat guide: "The hostname of a system is critical for the correct operation of Kerberos and SSL. Both of these security mechanisms rely on the hostname to ensure that communication is occurring between the specified hosts." I've also found this message http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems to be related to my case, but what I need to know is: where does it state FQDN is a mandatory requirement in order to FreeIPA to work and/or is there anything else (a patch, update, whatever) to solve this issue, so I don't need to change my applications? Thank you and sorry for the wall of a text. PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not the same server as IPA (it forwards to a Windows DC). RPMs: libipa_hbac-1.9.2-129.el6_5.4.x86_64 libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-3.0.0-37.el6.x86_64 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-server-3.0.0-37.el6.x86_64 ipa-python-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Aug 8 13:16:02 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 8 Aug 2014 16:16:02 +0300 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> Message-ID: <20140808131602.GL3496@redhat.com> On Fri, 08 Aug 2014, Bruno Henrique Barbosa wrote: >Hello everyone, > >I'm running through an issue where an application needs its server's >hostname to be in short name format, such as "server" and not >"server.example.com". When I started deploying FreeIPA in the very >beginning of this year, I remember I couldn't install freeipa-client >with a bare "ipa-client install", because of this: > >____________ > >[root at server ~] # hostname >server >[root at server ~]# hostname -f >server.example.com >[root at server ~]# ipa-client-install >Discovery was successful! >Hostname: server.example.com >Realm: EXAMPLE.COM >DNS Domain: example.com >IPA Server: ipa01.example.com >Base DN: dc=example,dc=com > >Continue to configure the system with these values? [no] yes >User authorized to enroll computers: admin >Synchronizing time with KDC... >Unable to sync time with IPA NTP Server, assuming the time is in sync. Please check that port 123 UDP is opened. >Password for admin at EXAMPLE.COM: >Joining realm failed: The hostname must be fully-qualified: server >Installation failed. Rolling back changes. >IPA client is not configured on this system. > >________________ > >So, using the short name as hostname didn't work for install, I then >make it like "ipa-client install --hostname=`hostname -f` --mkhomedir >-N", and it installs and works like a charm, BUT it updates the >machine's hostname to FQDN. > >What I tested and, at first, worked: after deploying and ipa-client >installation with those parameters which work, renaming the machine >back to a short name AT FIRST is not causing any problems. I can login >with my ssh rules perfectly, but I don't find any IPA technical docs >saying it will/won't work if I change the hostname back to short name >and not FQDN. > >Searching for it, I found on RedHat guide: "The hostname of a system is >critical for the correct operation of Kerberos and SSL. Both of these >security mechanisms rely on the hostname to ensure that communication >is occurring between the specified hosts." >I've also found this message >http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems to >be related to my case, but what I need to know is: where does it state >FQDN is a mandatory requirement in order to FreeIPA to work and/or is >there anything else (a patch, update, whatever) to solve this issue, so >I don't need to change my applications? The requirement comes from Kerberos where a principal for a host-based service has two components, a service name and a hostname. FreeIPA does not have user-friendly means to associate additional hostname components with the same service principal which means ldap/server at EXAMPLE.COM and ldap/server.example.com at EXAMPLE.COM will be two different kerberos principals, corresponding to two different services, each with its own set of keys. Many applications are not prepared into trying multiple keys from a keytab and only look for the name that is "canonical" for the host, via getaddrinfo() call. http://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html -- / Alexander Bokovoy From bpk678 at gmail.com Fri Aug 8 14:57:20 2014 From: bpk678 at gmail.com (brendan kearney) Date: Fri, 8 Aug 2014 10:57:20 -0400 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> Message-ID: Kerberos is dependent on A records in dns. The instance (as in principal/instance at REALM) should match the A record in dns. There is absolutely no Kerberos dependency on hostnames being fully qualified. I have all my devices named with short names and I have no issues with Kerberos ticketing. This seems to be an artificial requirement in FreeIPA that is wrong. On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < bruno-barbosa at prodesan.com.br> wrote: > Hello everyone, > > I'm running through an issue where an application needs its server's > hostname to be in short name format, such as "server" and not " > server.example.com". When I started deploying FreeIPA in the very > beginning of this year, I remember I couldn't install freeipa-client with a > bare "ipa-client install", because of this: > > ____________ > > [root at server ~]# hostname > server > [root at server ~]# hostname -f > server.example.com > [root at server ~]# ipa-client-install > Discovery was successful! > Hostname: server.example.com > Realm: EXAMPLE.COM > DNS Domain: example.com > IPA Server: ipa01.example.com > Base DN: dc=example,dc=com > > Continue to configure the system with these values? [no] yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Unable to sync time with IPA NTP Server, assuming the time is in sync. > Please check that port 123 UDP is opened. > Password for admin at EXAMPLE.COM: > Joining realm failed: The hostname must be fully-qualified: server > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > ________________ > > So, using the short name as hostname didn't work for install, I then make > it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", and > it installs and works like a charm, BUT it updates the machine's hostname > to FQDN. > > What I tested and, at first, worked: after deploying and ipa-client > installation with those parameters which work, renaming the machine back to > a short name AT FIRST is not causing any problems. I can login with my ssh > rules perfectly, but I don't find any IPA technical docs saying it > will/won't work if I change the hostname back to short name and not FQDN. > > Searching for it, I found on RedHat guide: "The hostname of a system is > critical for the correct operation of Kerberos and SSL. Both of these > security mechanisms rely on the hostname to ensure that communication is > occurring between the specified hosts." > I've also found this message > http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems to be > related to my case, but what I need to know is: where does it state FQDN is > a mandatory requirement in order to FreeIPA to work and/or is there > anything else (a patch, update, whatever) to solve this issue, so I don't > need to change my applications? > > Thank you and sorry for the wall of a text. > > PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not > the same server as IPA (it forwards to a Windows DC). > > RPMs: > libipa_hbac-1.9.2-129.el6_5.4.x86_64 > libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-admintools-3.0.0-37.el6.x86_64 > ipa-server-selinux-3.0.0-37.el6.x86_64 > ipa-server-3.0.0-37.el6.x86_64 > ipa-python-3.0.0-37.el6.x86_64 > ipa-client-3.0.0-37.el6.x86_64 > > > > -- > Manage your subscription for 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 bpk678 at gmail.com Fri Aug 8 15:50:27 2014 From: bpk678 at gmail.com (brendan kearney) Date: Fri, 8 Aug 2014 11:50:27 -0400 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> Message-ID: Correction, its primary/instance at REALM On Aug 8, 2014 10:57 AM, "brendan kearney" wrote: > Kerberos is dependent on A records in dns. The instance (as in > principal/instance at REALM) should match the A record in dns. > > There is absolutely no Kerberos dependency on hostnames being fully > qualified. I have all my devices named with short names and I have no > issues with Kerberos ticketing. > > This seems to be an artificial requirement in FreeIPA that is wrong. > On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < > bruno-barbosa at prodesan.com.br> wrote: > >> Hello everyone, >> >> I'm running through an issue where an application needs its server's >> hostname to be in short name format, such as "server" and not " >> server.example.com". When I started deploying FreeIPA in the very >> beginning of this year, I remember I couldn't install freeipa-client with a >> bare "ipa-client install", because of this: >> >> ____________ >> >> [root at server ~]# hostname >> server >> [root at server ~]# hostname -f >> server.example.com >> [root at server ~]# ipa-client-install >> Discovery was successful! >> Hostname: server.example.com >> Realm: EXAMPLE.COM >> DNS Domain: example.com >> IPA Server: ipa01.example.com >> Base DN: dc=example,dc=com >> >> Continue to configure the system with these values? [no] yes >> User authorized to enroll computers: admin >> Synchronizing time with KDC... >> Unable to sync time with IPA NTP Server, assuming the time is in sync. >> Please check that port 123 UDP is opened. >> Password for admin at EXAMPLE.COM: >> Joining realm failed: The hostname must be fully-qualified: server >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> ________________ >> >> So, using the short name as hostname didn't work for install, I then make >> it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", and >> it installs and works like a charm, BUT it updates the machine's hostname >> to FQDN. >> >> What I tested and, at first, worked: after deploying and ipa-client >> installation with those parameters which work, renaming the machine back to >> a short name AT FIRST is not causing any problems. I can login with my ssh >> rules perfectly, but I don't find any IPA technical docs saying it >> will/won't work if I change the hostname back to short name and not FQDN. >> >> Searching for it, I found on RedHat guide: "The hostname of a system is >> critical for the correct operation of Kerberos and SSL. Both of these >> security mechanisms rely on the hostname to ensure that communication is >> occurring between the specified hosts." >> I've also found this message >> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems to >> be related to my case, but what I need to know is: where does it state FQDN >> is a mandatory requirement in order to FreeIPA to work and/or is there >> anything else (a patch, update, whatever) to solve this issue, so I don't >> need to change my applications? >> >> Thank you and sorry for the wall of a text. >> >> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not >> the same server as IPA (it forwards to a Windows DC). >> >> RPMs: >> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >> python-iniparse-0.3.1-2.1.el6.noarch >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> ipa-admintools-3.0.0-37.el6.x86_64 >> ipa-server-selinux-3.0.0-37.el6.x86_64 >> ipa-server-3.0.0-37.el6.x86_64 >> ipa-python-3.0.0-37.el6.x86_64 >> ipa-client-3.0.0-37.el6.x86_64 >> >> >> >> -- >> Manage your subscription for 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 rmeggins at redhat.com Fri Aug 8 16:09:27 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 08 Aug 2014 10:09:27 -0600 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> Message-ID: <53E4F637.3020709@redhat.com> On 08/08/2014 08:57 AM, brendan kearney wrote: > > Kerberos is dependent on A records in dns. The instance (as in > principal/instance at REALM) should match the A record in dns. > > There is absolutely no Kerberos dependency on hostnames being fully > qualified. I have all my devices named with short names and I have no > issues with Kerberos ticketing. > > This seems to be an artificial requirement in FreeIPA that is wrong. > The other hostname requirement is for TLS/SSL, for MITM checking. By default, when an SSL server cert is issued, the subject DN contains cn=fqdn as the leftmost component. clients use this fqdn to verify the server. That is, client knows the IP address of the server - client does a reverse lookup (i.e. PTR) to see if the server returned by that lookup matches the cn=fqdn in the server cert. This requires reverse lookups are configured and that the fqdn is the first name/alias returned. > On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" > > > wrote: > > Hello everyone, > > I'm running through an issue where an application needs its > server's hostname to be in short name format, such as "server" and > not "server.example.com ". When I > started deploying FreeIPA in the very beginning of this year, I > remember I couldn't install freeipa-client with a bare "ipa-client > install", because of this: > > ____________ > > [root at server ~]# hostname > server > [root at server ~]# hostname -f > server.example.com > [root at server ~]# ipa-client-install > Discovery was successful! > Hostname: server.example.com > Realm: EXAMPLE.COM > DNS Domain: example.com > IPA Server: ipa01.example.com > Base DN: dc=example,dc=com > > Continue to configure the system with these values? [no] yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Unable to sync time with IPA NTP Server, assuming the time is in > sync. Please check that port 123 UDP is opened. > Password for admin at EXAMPLE.COM : > Joining realm failed: The hostname must be fully-qualified: server > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > ________________ > > So, using the short name as hostname didn't work for install, I > then make it like "ipa-client install --hostname=`hostname -f` > --mkhomedir -N", and it installs and works like a charm, BUT it > updates the machine's hostname to FQDN. > > What I tested and, at first, worked: after deploying and > ipa-client installation with those parameters which work, renaming > the machine back to a short name AT FIRST is not causing any > problems. I can login with my ssh rules perfectly, but I don't > find any IPA technical docs saying it will/won't work if I change > the hostname back to short name and not FQDN. > > Searching for it, I found on RedHat guide: "The hostname of a > system is critical for the correct operation of Kerberos and SSL. > Both of these security mechanisms rely on the hostname to ensure > that communication is occurring between the specified hosts." > I've also found this message > http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which > seems to be related to my case, but what I need to know is: where > does it state FQDN is a mandatory requirement in order to FreeIPA > to work and/or is there anything else (a patch, update, whatever) > to solve this issue, so I don't need to change my applications? > > Thank you and sorry for the wall of a text. > > PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS > is not the same server as IPA (it forwards to a Windows DC). > > RPMs: > libipa_hbac-1.9.2-129.el6_5.4.x86_64 > libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-admintools-3.0.0-37.el6.x86_64 > ipa-server-selinux-3.0.0-37.el6.x86_64 > ipa-server-3.0.0-37.el6.x86_64 > ipa-python-3.0.0-37.el6.x86_64 > ipa-client-3.0.0-37.el6.x86_64 > > > > -- > Manage your subscription for 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 bpk678 at gmail.com Fri Aug 8 16:56:27 2014 From: bpk678 at gmail.com (brendan kearney) Date: Fri, 8 Aug 2014 12:56:27 -0400 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <53E4F637.3020709@redhat.com> References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> Message-ID: Arent all of those lookups done in dns? Wouldnt that mean hostnames being fqdn's is irrelevant? On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: > On 08/08/2014 08:57 AM, brendan kearney wrote: > > Kerberos is dependent on A records in dns. The instance (as in > principal/instance at REALM) should match the A record in dns. > > There is absolutely no Kerberos dependency on hostnames being fully > qualified. I have all my devices named with short names and I have no > issues with Kerberos ticketing. > > This seems to be an artificial requirement in FreeIPA that is wrong. > > > The other hostname requirement is for TLS/SSL, for MITM checking. By > default, when an SSL server cert is issued, the subject DN contains cn=fqdn > as the leftmost component. clients use this fqdn to verify the server. > That is, client knows the IP address of the server - client does a reverse > lookup (i.e. PTR) to see if the server returned by that lookup matches the > cn=fqdn in the server cert. This requires reverse lookups are configured > and that the fqdn is the first name/alias returned. > > On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < > bruno-barbosa at prodesan.com.br> wrote: > >> Hello everyone, >> >> I'm running through an issue where an application needs its server's >> hostname to be in short name format, such as "server" and not " >> server.example.com". When I started deploying FreeIPA in the very >> beginning of this year, I remember I couldn't install freeipa-client with a >> bare "ipa-client install", because of this: >> >> ____________ >> >> [root at server ~]# hostname >> server >> [root at server ~]# hostname -f >> server.example.com >> [root at server ~]# ipa-client-install >> Discovery was successful! >> Hostname: server.example.com >> Realm: EXAMPLE.COM >> DNS Domain: example.com >> IPA Server: ipa01.example.com >> Base DN: dc=example,dc=com >> >> Continue to configure the system with these values? [no] yes >> User authorized to enroll computers: admin >> Synchronizing time with KDC... >> Unable to sync time with IPA NTP Server, assuming the time is in sync. >> Please check that port 123 UDP is opened. >> Password for admin at EXAMPLE.COM: >> Joining realm failed: The hostname must be fully-qualified: server >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> ________________ >> >> So, using the short name as hostname didn't work for install, I then make >> it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", and >> it installs and works like a charm, BUT it updates the machine's hostname >> to FQDN. >> >> What I tested and, at first, worked: after deploying and ipa-client >> installation with those parameters which work, renaming the machine back to >> a short name AT FIRST is not causing any problems. I can login with my ssh >> rules perfectly, but I don't find any IPA technical docs saying it >> will/won't work if I change the hostname back to short name and not FQDN. >> >> Searching for it, I found on RedHat guide: "The hostname of a system is >> critical for the correct operation of Kerberos and SSL. Both of these >> security mechanisms rely on the hostname to ensure that communication is >> occurring between the specified hosts." >> I've also found this message >> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems to >> be related to my case, but what I need to know is: where does it state FQDN >> is a mandatory requirement in order to FreeIPA to work and/or is there >> anything else (a patch, update, whatever) to solve this issue, so I don't >> need to change my applications? >> >> Thank you and sorry for the wall of a text. >> >> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not >> the same server as IPA (it forwards to a Windows DC). >> >> RPMs: >> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >> python-iniparse-0.3.1-2.1.el6.noarch >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> ipa-admintools-3.0.0-37.el6.x86_64 >> ipa-server-selinux-3.0.0-37.el6.x86_64 >> ipa-server-3.0.0-37.el6.x86_64 >> ipa-python-3.0.0-37.el6.x86_64 >> ipa-client-3.0.0-37.el6.x86_64 >> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Aug 8 17:03:06 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 08 Aug 2014 11:03:06 -0600 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> Message-ID: <53E502CA.8040307@redhat.com> On 08/08/2014 10:56 AM, brendan kearney wrote: > > Arent all of those lookups done in dns? > Yes. > Wouldnt that mean hostnames being fqdn's is irrelevant? > Not sure what you mean. I guess if you issued your server certs with a subject DN of "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR lookups configured so that w.x.y.z returned "hostname" instead of "hostname.domain.tld", then TLS/SSL would work. > On Aug 8, 2014 12:11 PM, "Rich Megginson" > wrote: > > On 08/08/2014 08:57 AM, brendan kearney wrote: >> >> Kerberos is dependent on A records in dns. The instance (as in >> principal/instance at REALM) should match the A record in dns. >> >> There is absolutely no Kerberos dependency on hostnames being >> fully qualified. I have all my devices named with short names >> and I have no issues with Kerberos ticketing. >> >> This seems to be an artificial requirement in FreeIPA that is wrong. >> > > The other hostname requirement is for TLS/SSL, for MITM checking. > By default, when an SSL server cert is issued, the subject DN > contains cn=fqdn as the leftmost component. clients use this fqdn > to verify the server. That is, client knows the IP address of the > server - client does a reverse lookup (i.e. PTR) to see if the > server returned by that lookup matches the cn=fqdn in the server > cert. This requires reverse lookups are configured and that the > fqdn is the first name/alias returned. > >> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" >> > > wrote: >> >> Hello everyone, >> >> I'm running through an issue where an application needs its >> server's hostname to be in short name format, such as >> "server" and not "server.example.com >> ". When I started deploying >> FreeIPA in the very beginning of this year, I remember I >> couldn't install freeipa-client with a bare "ipa-client >> install", because of this: >> >> ____________ >> >> [root at server ~]# hostname >> server >> [root at server ~]# hostname -f >> server.example.com >> [root at server ~]# ipa-client-install >> Discovery was successful! >> Hostname: server.example.com >> Realm: EXAMPLE.COM >> DNS Domain: example.com >> IPA Server: ipa01.example.com >> Base DN: dc=example,dc=com >> >> Continue to configure the system with these values? [no] yes >> User authorized to enroll computers: admin >> Synchronizing time with KDC... >> Unable to sync time with IPA NTP Server, assuming the time is >> in sync. Please check that port 123 UDP is opened. >> Password for admin at EXAMPLE.COM : >> Joining realm failed: The hostname must be fully-qualified: >> server >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> ________________ >> >> So, using the short name as hostname didn't work for install, >> I then make it like "ipa-client install --hostname=`hostname >> -f` --mkhomedir -N", and it installs and works like a charm, >> BUT it updates the machine's hostname to FQDN. >> >> What I tested and, at first, worked: after deploying and >> ipa-client installation with those parameters which work, >> renaming the machine back to a short name AT FIRST is not >> causing any problems. I can login with my ssh rules >> perfectly, but I don't find any IPA technical docs saying it >> will/won't work if I change the hostname back to short name >> and not FQDN. >> >> Searching for it, I found on RedHat guide: "The hostname of a >> system is critical for the correct operation of Kerberos and >> SSL. Both of these security mechanisms rely on the hostname >> to ensure that communication is occurring between the >> specified hosts." >> I've also found this message >> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which >> seems to be related to my case, but what I need to know is: >> where does it state FQDN is a mandatory requirement in order >> to FreeIPA to work and/or is there anything else (a patch, >> update, whatever) to solve this issue, so I don't need to >> change my applications? >> >> Thank you and sorry for the wall of a text. >> >> PS: Enviroment is CentOS 6.5, in both IPA server and client. >> DNS is not the same server as IPA (it forwards to a Windows DC). >> >> RPMs: >> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >> python-iniparse-0.3.1-2.1.el6.noarch >> ipa-pki-common-theme-9.0.3-7.el6.noarch >> ipa-pki-ca-theme-9.0.3-7.el6.noarch >> ipa-admintools-3.0.0-37.el6.x86_64 >> ipa-server-selinux-3.0.0-37.el6.x86_64 >> ipa-server-3.0.0-37.el6.x86_64 >> ipa-python-3.0.0-37.el6.x86_64 >> ipa-client-3.0.0-37.el6.x86_64 >> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> >> >> > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpk678 at gmail.com Fri Aug 8 17:17:08 2014 From: bpk678 at gmail.com (brendan kearney) Date: Fri, 8 Aug 2014 13:17:08 -0400 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <53E502CA.8040307@redhat.com> References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <53E502CA.8040307@redhat.com> Message-ID: The cert should have the fqdn, just like the kerberos instance, but the hostname is not required to be fq'd. The lookup of a short name, as well as and more specifically the IP, in dns will result in the fqdn being returned by dns (the short name resolution being affected by domain and search directives in resolv.conf and the origin directive in dns if either of those are absent). Back to the point, dns lookup for cert matching is not dependent on hostnames. PTR lookups will always return fqdns, so a dependency on fqdns as hostnames is artificial, no? On Aug 8, 2014 1:03 PM, "Rich Megginson" wrote: > On 08/08/2014 10:56 AM, brendan kearney wrote: > > Arent all of those lookups done in dns? > > > Yes. > > Wouldnt that mean hostnames being fqdn's is irrelevant? > > > Not sure what you mean. > > I guess if you issued your server certs with a subject DN of > "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR > lookups configured so that w.x.y.z returned "hostname" instead of > "hostname.domain.tld", then TLS/SSL would work. > > On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: > >> On 08/08/2014 08:57 AM, brendan kearney wrote: >> >> Kerberos is dependent on A records in dns. The instance (as in >> principal/instance at REALM) should match the A record in dns. >> >> There is absolutely no Kerberos dependency on hostnames being fully >> qualified. I have all my devices named with short names and I have no >> issues with Kerberos ticketing. >> >> This seems to be an artificial requirement in FreeIPA that is wrong. >> >> >> The other hostname requirement is for TLS/SSL, for MITM checking. By >> default, when an SSL server cert is issued, the subject DN contains cn=fqdn >> as the leftmost component. clients use this fqdn to verify the server. >> That is, client knows the IP address of the server - client does a reverse >> lookup (i.e. PTR) to see if the server returned by that lookup matches the >> cn=fqdn in the server cert. This requires reverse lookups are configured >> and that the fqdn is the first name/alias returned. >> >> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < >> bruno-barbosa at prodesan.com.br> wrote: >> >>> Hello everyone, >>> >>> I'm running through an issue where an application needs its server's >>> hostname to be in short name format, such as "server" and not " >>> server.example.com". When I started deploying FreeIPA in the very >>> beginning of this year, I remember I couldn't install freeipa-client with a >>> bare "ipa-client install", because of this: >>> >>> ____________ >>> >>> [root at server ~]# hostname >>> server >>> [root at server ~]# hostname -f >>> server.example.com >>> [root at server ~]# ipa-client-install >>> Discovery was successful! >>> Hostname: server.example.com >>> Realm: EXAMPLE.COM >>> DNS Domain: example.com >>> IPA Server: ipa01.example.com >>> Base DN: dc=example,dc=com >>> >>> Continue to configure the system with these values? [no] yes >>> User authorized to enroll computers: admin >>> Synchronizing time with KDC... >>> Unable to sync time with IPA NTP Server, assuming the time is in sync. >>> Please check that port 123 UDP is opened. >>> Password for admin at EXAMPLE.COM: >>> Joining realm failed: The hostname must be fully-qualified: server >>> Installation failed. Rolling back changes. >>> IPA client is not configured on this system. >>> >>> ________________ >>> >>> So, using the short name as hostname didn't work for install, I then >>> make it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", >>> and it installs and works like a charm, BUT it updates the machine's >>> hostname to FQDN. >>> >>> What I tested and, at first, worked: after deploying and ipa-client >>> installation with those parameters which work, renaming the machine back to >>> a short name AT FIRST is not causing any problems. I can login with my ssh >>> rules perfectly, but I don't find any IPA technical docs saying it >>> will/won't work if I change the hostname back to short name and not FQDN. >>> >>> Searching for it, I found on RedHat guide: "The hostname of a system is >>> critical for the correct operation of Kerberos and SSL. Both of these >>> security mechanisms rely on the hostname to ensure that communication is >>> occurring between the specified hosts." >>> I've also found this message >>> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems to >>> be related to my case, but what I need to know is: where does it state FQDN >>> is a mandatory requirement in order to FreeIPA to work and/or is there >>> anything else (a patch, update, whatever) to solve this issue, so I don't >>> need to change my applications? >>> >>> Thank you and sorry for the wall of a text. >>> >>> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not >>> the same server as IPA (it forwards to a Windows DC). >>> >>> RPMs: >>> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >>> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >>> python-iniparse-0.3.1-2.1.el6.noarch >>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>> ipa-admintools-3.0.0-37.el6.x86_64 >>> ipa-server-selinux-3.0.0-37.el6.x86_64 >>> ipa-server-3.0.0-37.el6.x86_64 >>> ipa-python-3.0.0-37.el6.x86_64 >>> ipa-client-3.0.0-37.el6.x86_64 >>> >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> >> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Aug 8 17:43:11 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 08 Aug 2014 11:43:11 -0600 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <53E502CA.8040307@redhat.com> Message-ID: <53E50C2F.80803@redhat.com> On 08/08/2014 11:17 AM, brendan kearney wrote: > > The cert should have the fqdn, just like the kerberos instance, but > the hostname is not required to be fq'd. The lookup of a short name, > as well as and more specifically the IP, in dns will result in the > fqdn being returned by dns (the short name resolution being affected > by domain and search directives in resolv.conf and the origin > directive in dns if either of those are absent). > > Back to the point, dns lookup for cert matching is not dependent on > hostnames. PTR lookups will always return fqdns, so a dependency on > fqdns as hostnames is artificial, no? > Most clients will also do the additional step of matching the hostname in the cert against the originally given hostname. For example, with ldapsearch: ldapsearch -xLLLZZ -h hostname ... This will fail if the server cert for hostname has "cn=hostname.domain.tld" > On Aug 8, 2014 1:03 PM, "Rich Megginson" > wrote: > > On 08/08/2014 10:56 AM, brendan kearney wrote: >> >> Arent all of those lookups done in dns? >> > > Yes. > >> Wouldnt that mean hostnames being fqdn's is irrelevant? >> > > Not sure what you mean. > > I guess if you issued your server certs with a subject DN of > "cn=hostname", instead of "cn=hostname.domain.tld", and you had > the DNS PTR lookups configured so that w.x.y.z returned "hostname" > instead of "hostname.domain.tld", then TLS/SSL would work. > >> On Aug 8, 2014 12:11 PM, "Rich Megginson" > > wrote: >> >> On 08/08/2014 08:57 AM, brendan kearney wrote: >>> >>> Kerberos is dependent on A records in dns. The instance (as >>> in principal/instance at REALM) should match the A record in dns. >>> >>> There is absolutely no Kerberos dependency on hostnames >>> being fully qualified. I have all my devices named with >>> short names and I have no issues with Kerberos ticketing. >>> >>> This seems to be an artificial requirement in FreeIPA that >>> is wrong. >>> >> >> The other hostname requirement is for TLS/SSL, for MITM >> checking. By default, when an SSL server cert is issued, the >> subject DN contains cn=fqdn as the leftmost component. >> clients use this fqdn to verify the server. That is, client >> knows the IP address of the server - client does a reverse >> lookup (i.e. PTR) to see if the server returned by that >> lookup matches the cn=fqdn in the server cert. This requires >> reverse lookups are configured and that the fqdn is the first >> name/alias returned. >> >>> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" >>> >> > wrote: >>> >>> Hello everyone, >>> >>> I'm running through an issue where an application needs >>> its server's hostname to be in short name format, such >>> as "server" and not "server.example.com >>> ". When I started deploying >>> FreeIPA in the very beginning of this year, I remember I >>> couldn't install freeipa-client with a bare "ipa-client >>> install", because of this: >>> >>> ____________ >>> >>> [root at server ~]# hostname >>> server >>> [root at server ~]# hostname -f >>> server.example.com >>> [root at server ~]# ipa-client-install >>> Discovery was successful! >>> Hostname: server.example.com >>> Realm: EXAMPLE.COM >>> DNS Domain: example.com >>> IPA Server: ipa01.example.com >>> Base DN: dc=example,dc=com >>> >>> Continue to configure the system with these values? [no] yes >>> User authorized to enroll computers: admin >>> Synchronizing time with KDC... >>> Unable to sync time with IPA NTP Server, assuming the >>> time is in sync. Please check that port 123 UDP is opened. >>> Password for admin at EXAMPLE.COM : >>> Joining realm failed: The hostname must be >>> fully-qualified: server >>> Installation failed. Rolling back changes. >>> IPA client is not configured on this system. >>> >>> ________________ >>> >>> So, using the short name as hostname didn't work for >>> install, I then make it like "ipa-client install >>> --hostname=`hostname -f` --mkhomedir -N", and it >>> installs and works like a charm, BUT it updates the >>> machine's hostname to FQDN. >>> >>> What I tested and, at first, worked: after deploying and >>> ipa-client installation with those parameters which >>> work, renaming the machine back to a short name AT FIRST >>> is not causing any problems. I can login with my ssh >>> rules perfectly, but I don't find any IPA technical docs >>> saying it will/won't work if I change the hostname back >>> to short name and not FQDN. >>> >>> Searching for it, I found on RedHat guide: "The hostname >>> of a system is critical for the correct operation of >>> Kerberos and SSL. Both of these security mechanisms rely >>> on the hostname to ensure that communication is >>> occurring between the specified hosts." >>> I've also found this message >>> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html >>> which seems to be related to my case, but what I need to >>> know is: where does it state FQDN is a mandatory >>> requirement in order to FreeIPA to work and/or is there >>> anything else (a patch, update, whatever) to solve this >>> issue, so I don't need to change my applications? >>> >>> Thank you and sorry for the wall of a text. >>> >>> PS: Enviroment is CentOS 6.5, in both IPA server and >>> client. DNS is not the same server as IPA (it forwards >>> to a Windows DC). >>> >>> RPMs: >>> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >>> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >>> python-iniparse-0.3.1-2.1.el6.noarch >>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>> ipa-admintools-3.0.0-37.el6.x86_64 >>> ipa-server-selinux-3.0.0-37.el6.x86_64 >>> ipa-server-3.0.0-37.el6.x86_64 >>> ipa-python-3.0.0-37.el6.x86_64 >>> ipa-client-3.0.0-37.el6.x86_64 >>> >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >>> >>> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpk678 at gmail.com Fri Aug 8 18:21:20 2014 From: bpk678 at gmail.com (brendan kearney) Date: Fri, 8 Aug 2014 14:21:20 -0400 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <53E50C2F.80803@redhat.com> References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <53E502CA.8040307@redhat.com> <53E50C2F.80803@redhat.com> Message-ID: Double check your example. -h means the hostname of the ldap server to connect to and issue your query to. Man page calls it ldaphost. I have not run across a client that does cert validation using ldap. Is that IPA specific? It seems that a lot of effort is being spent to justify a dependency on fully qualified hostnames, when there is no reason to require it. In fact, it may even break somethings or even violate some rfc. On Aug 8, 2014 1:43 PM, "Rich Megginson" wrote: > On 08/08/2014 11:17 AM, brendan kearney wrote: > > The cert should have the fqdn, just like the kerberos instance, but the > hostname is not required to be fq'd. The lookup of a short name, as well > as and more specifically the IP, in dns will result in the fqdn being > returned by dns (the short name resolution being affected by domain and > search directives in resolv.conf and the origin directive in dns if either > of those are absent). > > Back to the point, dns lookup for cert matching is not dependent on > hostnames. PTR lookups will always return fqdns, so a dependency on fqdns > as hostnames is artificial, no? > > > Most clients will also do the additional step of matching the hostname in > the cert against the originally given hostname. For example, with > ldapsearch: > > ldapsearch -xLLLZZ -h hostname ... > > This will fail if the server cert for hostname has "cn=hostname.domain.tld" > > On Aug 8, 2014 1:03 PM, "Rich Megginson" wrote: > >> On 08/08/2014 10:56 AM, brendan kearney wrote: >> >> Arent all of those lookups done in dns? >> >> >> Yes. >> >> Wouldnt that mean hostnames being fqdn's is irrelevant? >> >> >> Not sure what you mean. >> >> I guess if you issued your server certs with a subject DN of >> "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR >> lookups configured so that w.x.y.z returned "hostname" instead of >> "hostname.domain.tld", then TLS/SSL would work. >> >> On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: >> >>> On 08/08/2014 08:57 AM, brendan kearney wrote: >>> >>> Kerberos is dependent on A records in dns. The instance (as in >>> principal/instance at REALM) should match the A record in dns. >>> >>> There is absolutely no Kerberos dependency on hostnames being fully >>> qualified. I have all my devices named with short names and I have no >>> issues with Kerberos ticketing. >>> >>> This seems to be an artificial requirement in FreeIPA that is wrong. >>> >>> >>> The other hostname requirement is for TLS/SSL, for MITM checking. By >>> default, when an SSL server cert is issued, the subject DN contains cn=fqdn >>> as the leftmost component. clients use this fqdn to verify the server. >>> That is, client knows the IP address of the server - client does a reverse >>> lookup (i.e. PTR) to see if the server returned by that lookup matches the >>> cn=fqdn in the server cert. This requires reverse lookups are configured >>> and that the fqdn is the first name/alias returned. >>> >>> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < >>> bruno-barbosa at prodesan.com.br> wrote: >>> >>>> Hello everyone, >>>> >>>> I'm running through an issue where an application needs its server's >>>> hostname to be in short name format, such as "server" and not " >>>> server.example.com". When I started deploying FreeIPA in the very >>>> beginning of this year, I remember I couldn't install freeipa-client with a >>>> bare "ipa-client install", because of this: >>>> >>>> ____________ >>>> >>>> [root at server ~]# hostname >>>> server >>>> [root at server ~]# hostname -f >>>> server.example.com >>>> [root at server ~]# ipa-client-install >>>> Discovery was successful! >>>> Hostname: server.example.com >>>> Realm: EXAMPLE.COM >>>> DNS Domain: example.com >>>> IPA Server: ipa01.example.com >>>> Base DN: dc=example,dc=com >>>> >>>> Continue to configure the system with these values? [no] yes >>>> User authorized to enroll computers: admin >>>> Synchronizing time with KDC... >>>> Unable to sync time with IPA NTP Server, assuming the time is in sync. >>>> Please check that port 123 UDP is opened. >>>> Password for admin at EXAMPLE.COM: >>>> Joining realm failed: The hostname must be fully-qualified: server >>>> Installation failed. Rolling back changes. >>>> IPA client is not configured on this system. >>>> >>>> ________________ >>>> >>>> So, using the short name as hostname didn't work for install, I then >>>> make it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", >>>> and it installs and works like a charm, BUT it updates the machine's >>>> hostname to FQDN. >>>> >>>> What I tested and, at first, worked: after deploying and ipa-client >>>> installation with those parameters which work, renaming the machine back to >>>> a short name AT FIRST is not causing any problems. I can login with my ssh >>>> rules perfectly, but I don't find any IPA technical docs saying it >>>> will/won't work if I change the hostname back to short name and not FQDN. >>>> >>>> Searching for it, I found on RedHat guide: "The hostname of a system is >>>> critical for the correct operation of Kerberos and SSL. Both of these >>>> security mechanisms rely on the hostname to ensure that communication is >>>> occurring between the specified hosts." >>>> I've also found this message >>>> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems to >>>> be related to my case, but what I need to know is: where does it state FQDN >>>> is a mandatory requirement in order to FreeIPA to work and/or is there >>>> anything else (a patch, update, whatever) to solve this issue, so I don't >>>> need to change my applications? >>>> >>>> Thank you and sorry for the wall of a text. >>>> >>>> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is not >>>> the same server as IPA (it forwards to a Windows DC). >>>> >>>> RPMs: >>>> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >>>> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >>>> python-iniparse-0.3.1-2.1.el6.noarch >>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>> ipa-admintools-3.0.0-37.el6.x86_64 >>>> ipa-server-selinux-3.0.0-37.el6.x86_64 >>>> ipa-server-3.0.0-37.el6.x86_64 >>>> ipa-python-3.0.0-37.el6.x86_64 >>>> ipa-client-3.0.0-37.el6.x86_64 >>>> >>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >>>> >>> >>> >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Aug 8 18:37:33 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 08 Aug 2014 12:37:33 -0600 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <53E502CA.8040307@redhat.com> <53E50C2F.80803@redhat.com> Message-ID: <53E518ED.3020709@redhat.com> On 08/08/2014 12:21 PM, brendan kearney wrote: > > Double check your example. -h means the hostname of the ldap server > to connect to and issue your query to. Man page calls it ldaphost. > Yes. > I have not run across a client that does cert validation using ldap. > Is that IPA specific? > I'm not talking about cert validation using ldap. I'm talking about the fact that, by default, the ldapsearch client will expect the hostname you pass in to match the hostname in the ssl server cert subject DN. > It seems that a lot of effort is being spent to justify a dependency > on fully qualified hostnames, when there is no reason to require it. > In fact, it may even break somethings or even violate some rfc. > If requiring fully qualified hostnames violates RFCs or other standards, I'd like to hear about it. > On Aug 8, 2014 1:43 PM, "Rich Megginson" > wrote: > > On 08/08/2014 11:17 AM, brendan kearney wrote: >> >> The cert should have the fqdn, just like the kerberos instance, >> but the hostname is not required to be fq'd. The lookup of a >> short name, as well as and more specifically the IP, in dns will >> result in the fqdn being returned by dns (the short name >> resolution being affected by domain and search directives in >> resolv.conf and the origin directive in dns if either of those >> are absent). >> >> Back to the point, dns lookup for cert matching is not dependent >> on hostnames. PTR lookups will always return fqdns, so a >> dependency on fqdns as hostnames is artificial, no? >> > > Most clients will also do the additional step of matching the > hostname in the cert against the originally given hostname. For > example, with ldapsearch: > > ldapsearch -xLLLZZ -h hostname ... > > This will fail if the server cert for hostname has > "cn=hostname.domain.tld" > >> On Aug 8, 2014 1:03 PM, "Rich Megginson" > > wrote: >> >> On 08/08/2014 10:56 AM, brendan kearney wrote: >>> >>> Arent all of those lookups done in dns? >>> >> >> Yes. >> >>> Wouldnt that mean hostnames being fqdn's is irrelevant? >>> >> >> Not sure what you mean. >> >> I guess if you issued your server certs with a subject DN of >> "cn=hostname", instead of "cn=hostname.domain.tld", and you >> had the DNS PTR lookups configured so that w.x.y.z returned >> "hostname" instead of "hostname.domain.tld", then TLS/SSL >> would work. >> >>> On Aug 8, 2014 12:11 PM, "Rich Megginson" >>> > wrote: >>> >>> On 08/08/2014 08:57 AM, brendan kearney wrote: >>>> >>>> Kerberos is dependent on A records in dns. The >>>> instance (as in principal/instance at REALM) should match >>>> the A record in dns. >>>> >>>> There is absolutely no Kerberos dependency on hostnames >>>> being fully qualified. I have all my devices named >>>> with short names and I have no issues with Kerberos >>>> ticketing. >>>> >>>> This seems to be an artificial requirement in FreeIPA >>>> that is wrong. >>>> >>> >>> The other hostname requirement is for TLS/SSL, for MITM >>> checking. By default, when an SSL server cert is >>> issued, the subject DN contains cn=fqdn as the leftmost >>> component. clients use this fqdn to verify the server. >>> That is, client knows the IP address of the server - >>> client does a reverse lookup (i.e. PTR) to see if the >>> server returned by that lookup matches the cn=fqdn in >>> the server cert. This requires reverse lookups are >>> configured and that the fqdn is the first name/alias >>> returned. >>> >>>> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" >>>> >>> > wrote: >>>> >>>> Hello everyone, >>>> >>>> I'm running through an issue where an application >>>> needs its server's hostname to be in short name >>>> format, such as "server" and not >>>> "server.example.com ". >>>> When I started deploying FreeIPA in the very >>>> beginning of this year, I remember I couldn't >>>> install freeipa-client with a bare "ipa-client >>>> install", because of this: >>>> >>>> ____________ >>>> >>>> [root at server ~]# hostname >>>> server >>>> [root at server ~]# hostname -f >>>> server.example.com >>>> [root at server ~]# ipa-client-install >>>> Discovery was successful! >>>> Hostname: server.example.com >>>> >>>> Realm: EXAMPLE.COM >>>> DNS Domain: example.com >>>> IPA Server: ipa01.example.com >>>> >>>> Base DN: dc=example,dc=com >>>> >>>> Continue to configure the system with these values? >>>> [no] yes >>>> User authorized to enroll computers: admin >>>> Synchronizing time with KDC... >>>> Unable to sync time with IPA NTP Server, assuming >>>> the time is in sync. Please check that port 123 UDP >>>> is opened. >>>> Password for admin at EXAMPLE.COM >>>> : >>>> Joining realm failed: The hostname must be >>>> fully-qualified: server >>>> Installation failed. Rolling back changes. >>>> IPA client is not configured on this system. >>>> >>>> ________________ >>>> >>>> So, using the short name as hostname didn't work >>>> for install, I then make it like "ipa-client >>>> install --hostname=`hostname -f` --mkhomedir -N", >>>> and it installs and works like a charm, BUT it >>>> updates the machine's hostname to FQDN. >>>> >>>> What I tested and, at first, worked: after >>>> deploying and ipa-client installation with those >>>> parameters which work, renaming the machine back to >>>> a short name AT FIRST is not causing any problems. >>>> I can login with my ssh rules perfectly, but I >>>> don't find any IPA technical docs saying it >>>> will/won't work if I change the hostname back to >>>> short name and not FQDN. >>>> >>>> Searching for it, I found on RedHat guide: "The >>>> hostname of a system is critical for the correct >>>> operation of Kerberos and SSL. Both of these >>>> security mechanisms rely on the hostname to ensure >>>> that communication is occurring between the >>>> specified hosts." >>>> I've also found this message >>>> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html >>>> which seems to be related to my case, but what I >>>> need to know is: where does it state FQDN is a >>>> mandatory requirement in order to FreeIPA to work >>>> and/or is there anything else (a patch, update, >>>> whatever) to solve this issue, so I don't need to >>>> change my applications? >>>> >>>> Thank you and sorry for the wall of a text. >>>> >>>> PS: Enviroment is CentOS 6.5, in both IPA server >>>> and client. DNS is not the same server as IPA (it >>>> forwards to a Windows DC). >>>> >>>> RPMs: >>>> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >>>> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >>>> python-iniparse-0.3.1-2.1.el6.noarch >>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>> ipa-admintools-3.0.0-37.el6.x86_64 >>>> ipa-server-selinux-3.0.0-37.el6.x86_64 >>>> ipa-server-3.0.0-37.el6.x86_64 >>>> ipa-python-3.0.0-37.el6.x86_64 >>>> ipa-client-3.0.0-37.el6.x86_64 >>>> >>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users >>>> mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >>>> >>>> >>>> >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpk678 at gmail.com Fri Aug 8 19:16:50 2014 From: bpk678 at gmail.com (brendan kearney) Date: Fri, 8 Aug 2014 15:16:50 -0400 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <53E518ED.3020709@redhat.com> References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <53E502CA.8040307@redhat.com> <53E50C2F.80803@redhat.com> <53E518ED.3020709@redhat.com> Message-ID: Maybe I am reading too far into rfc 1178, but I hardly think making hostnames required to be fqdns is in anybodys interest. It is not a requirement now in any other technology anywhere, so what is the impetus to push it? I dont see any value in it On Aug 8, 2014 2:37 PM, "Rich Megginson" wrote: > On 08/08/2014 12:21 PM, brendan kearney wrote: > > Double check your example. -h means the hostname of the ldap server to > connect to and issue your query to. Man page calls it ldaphost. > > > Yes. > > I have not run across a client that does cert validation using ldap. Is > that IPA specific? > > > I'm not talking about cert validation using ldap. I'm talking about the > fact that, by default, the ldapsearch client will expect the hostname you > pass in to match the hostname in the ssl server cert subject DN. > > It seems that a lot of effort is being spent to justify a dependency on > fully qualified hostnames, when there is no reason to require it. In fact, > it may even break somethings or even violate some rfc. > > > If requiring fully qualified hostnames violates RFCs or other standards, > I'd like to hear about it. > > On Aug 8, 2014 1:43 PM, "Rich Megginson" wrote: > >> On 08/08/2014 11:17 AM, brendan kearney wrote: >> >> The cert should have the fqdn, just like the kerberos instance, but the >> hostname is not required to be fq'd. The lookup of a short name, as well >> as and more specifically the IP, in dns will result in the fqdn being >> returned by dns (the short name resolution being affected by domain and >> search directives in resolv.conf and the origin directive in dns if either >> of those are absent). >> >> Back to the point, dns lookup for cert matching is not dependent on >> hostnames. PTR lookups will always return fqdns, so a dependency on fqdns >> as hostnames is artificial, no? >> >> >> Most clients will also do the additional step of matching the hostname in >> the cert against the originally given hostname. For example, with >> ldapsearch: >> >> ldapsearch -xLLLZZ -h hostname ... >> >> This will fail if the server cert for hostname has >> "cn=hostname.domain.tld" >> >> On Aug 8, 2014 1:03 PM, "Rich Megginson" wrote: >> >>> On 08/08/2014 10:56 AM, brendan kearney wrote: >>> >>> Arent all of those lookups done in dns? >>> >>> >>> Yes. >>> >>> Wouldnt that mean hostnames being fqdn's is irrelevant? >>> >>> >>> Not sure what you mean. >>> >>> I guess if you issued your server certs with a subject DN of >>> "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR >>> lookups configured so that w.x.y.z returned "hostname" instead of >>> "hostname.domain.tld", then TLS/SSL would work. >>> >>> On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: >>> >>>> On 08/08/2014 08:57 AM, brendan kearney wrote: >>>> >>>> Kerberos is dependent on A records in dns. The instance (as in >>>> principal/instance at REALM) should match the A record in dns. >>>> >>>> There is absolutely no Kerberos dependency on hostnames being fully >>>> qualified. I have all my devices named with short names and I have no >>>> issues with Kerberos ticketing. >>>> >>>> This seems to be an artificial requirement in FreeIPA that is wrong. >>>> >>>> >>>> The other hostname requirement is for TLS/SSL, for MITM checking. By >>>> default, when an SSL server cert is issued, the subject DN contains cn=fqdn >>>> as the leftmost component. clients use this fqdn to verify the server. >>>> That is, client knows the IP address of the server - client does a reverse >>>> lookup (i.e. PTR) to see if the server returned by that lookup matches the >>>> cn=fqdn in the server cert. This requires reverse lookups are configured >>>> and that the fqdn is the first name/alias returned. >>>> >>>> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < >>>> bruno-barbosa at prodesan.com.br> wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> I'm running through an issue where an application needs its server's >>>>> hostname to be in short name format, such as "server" and not " >>>>> server.example.com". When I started deploying FreeIPA in the very >>>>> beginning of this year, I remember I couldn't install freeipa-client with a >>>>> bare "ipa-client install", because of this: >>>>> >>>>> ____________ >>>>> >>>>> [root at server ~]# hostname >>>>> server >>>>> [root at server ~]# hostname -f >>>>> server.example.com >>>>> [root at server ~]# ipa-client-install >>>>> Discovery was successful! >>>>> Hostname: server.example.com >>>>> Realm: EXAMPLE.COM >>>>> DNS Domain: example.com >>>>> IPA Server: ipa01.example.com >>>>> Base DN: dc=example,dc=com >>>>> >>>>> Continue to configure the system with these values? [no] yes >>>>> User authorized to enroll computers: admin >>>>> Synchronizing time with KDC... >>>>> Unable to sync time with IPA NTP Server, assuming the time is in sync. >>>>> Please check that port 123 UDP is opened. >>>>> Password for admin at EXAMPLE.COM: >>>>> Joining realm failed: The hostname must be fully-qualified: server >>>>> Installation failed. Rolling back changes. >>>>> IPA client is not configured on this system. >>>>> >>>>> ________________ >>>>> >>>>> So, using the short name as hostname didn't work for install, I then >>>>> make it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", >>>>> and it installs and works like a charm, BUT it updates the machine's >>>>> hostname to FQDN. >>>>> >>>>> What I tested and, at first, worked: after deploying and ipa-client >>>>> installation with those parameters which work, renaming the machine back to >>>>> a short name AT FIRST is not causing any problems. I can login with my ssh >>>>> rules perfectly, but I don't find any IPA technical docs saying it >>>>> will/won't work if I change the hostname back to short name and not FQDN. >>>>> >>>>> Searching for it, I found on RedHat guide: "The hostname of a system >>>>> is critical for the correct operation of Kerberos and SSL. Both of these >>>>> security mechanisms rely on the hostname to ensure that communication is >>>>> occurring between the specified hosts." >>>>> I've also found this message >>>>> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems >>>>> to be related to my case, but what I need to know is: where does it state >>>>> FQDN is a mandatory requirement in order to FreeIPA to work and/or is there >>>>> anything else (a patch, update, whatever) to solve this issue, so I don't >>>>> need to change my applications? >>>>> >>>>> Thank you and sorry for the wall of a text. >>>>> >>>>> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is >>>>> not the same server as IPA (it forwards to a Windows DC). >>>>> >>>>> RPMs: >>>>> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >>>>> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>> ipa-admintools-3.0.0-37.el6.x86_64 >>>>> ipa-server-selinux-3.0.0-37.el6.x86_64 >>>>> ipa-server-3.0.0-37.el6.x86_64 >>>>> ipa-python-3.0.0-37.el6.x86_64 >>>>> ipa-client-3.0.0-37.el6.x86_64 >>>>> >>>>> >>>>> >>>>> -- >>>>> Manage your subscription for the Freeipa-users mailing list: >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> Go To http://freeipa.org for more info on the project >>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Aug 8 19:29:57 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 08 Aug 2014 13:29:57 -0600 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <53E502CA.8040307@redhat.com> <53E50C2F.80803@redhat.com> <53E518ED.3020709@redhat.com> Message-ID: <53E52535.5000703@redhat.com> On 08/08/2014 01:16 PM, brendan kearney wrote: > > Maybe I am reading too far into rfc 1178, > http://tools.ietf.org/html/rfc1178 "This memo provides information for the Internet community. It does not specify any standard." I guess the upshot is - if you think that FreeIPA is being too restrictive with its default policies about fqdn requirements for hostnames, please file ticket(s) accordingly. > but I hardly think making hostnames required to be fqdns is in > anybodys interest. It is not a requirement now in any other > technology anywhere, so what is the impetus to push it? I dont see > any value in it > > On Aug 8, 2014 2:37 PM, "Rich Megginson" > wrote: > > On 08/08/2014 12:21 PM, brendan kearney wrote: >> >> Double check your example. -h means the hostname of the ldap >> server to connect to and issue your query to. Man page calls it >> ldaphost. >> > > Yes. > >> I have not run across a client that does cert validation using >> ldap. Is that IPA specific? >> > > I'm not talking about cert validation using ldap. I'm talking > about the fact that, by default, the ldapsearch client will expect > the hostname you pass in to match the hostname in the ssl server > cert subject DN. > >> It seems that a lot of effort is being spent to justify a >> dependency on fully qualified hostnames, when there is no reason >> to require it. In fact, it may even break somethings or even >> violate some rfc. >> > > If requiring fully qualified hostnames violates RFCs or other > standards, I'd like to hear about it. > >> On Aug 8, 2014 1:43 PM, "Rich Megginson" > > wrote: >> >> On 08/08/2014 11:17 AM, brendan kearney wrote: >>> >>> The cert should have the fqdn, just like the kerberos >>> instance, but the hostname is not required to be fq'd. The >>> lookup of a short name, as well as and more specifically the >>> IP, in dns will result in the fqdn being returned by dns >>> (the short name resolution being affected by domain and >>> search directives in resolv.conf and the origin directive in >>> dns if either of those are absent). >>> >>> Back to the point, dns lookup for cert matching is not >>> dependent on hostnames. PTR lookups will always return >>> fqdns, so a dependency on fqdns as hostnames is artificial, no? >>> >> >> Most clients will also do the additional step of matching the >> hostname in the cert against the originally given hostname. >> For example, with ldapsearch: >> >> ldapsearch -xLLLZZ -h hostname ... >> >> This will fail if the server cert for hostname has >> "cn=hostname.domain.tld" >> >>> On Aug 8, 2014 1:03 PM, "Rich Megginson" >>> > wrote: >>> >>> On 08/08/2014 10:56 AM, brendan kearney wrote: >>>> >>>> Arent all of those lookups done in dns? >>>> >>> >>> Yes. >>> >>>> Wouldnt that mean hostnames being fqdn's is irrelevant? >>>> >>> >>> Not sure what you mean. >>> >>> I guess if you issued your server certs with a subject >>> DN of "cn=hostname", instead of >>> "cn=hostname.domain.tld", and you had the DNS PTR >>> lookups configured so that w.x.y.z returned "hostname" >>> instead of "hostname.domain.tld", then TLS/SSL would work. >>> >>>> On Aug 8, 2014 12:11 PM, "Rich Megginson" >>>> > wrote: >>>> >>>> On 08/08/2014 08:57 AM, brendan kearney wrote: >>>>> >>>>> Kerberos is dependent on A records in dns. The >>>>> instance (as in principal/instance at REALM) should >>>>> match the A record in dns. >>>>> >>>>> There is absolutely no Kerberos dependency on >>>>> hostnames being fully qualified. I have all my >>>>> devices named with short names and I have no >>>>> issues with Kerberos ticketing. >>>>> >>>>> This seems to be an artificial requirement in >>>>> FreeIPA that is wrong. >>>>> >>>> >>>> The other hostname requirement is for TLS/SSL, for >>>> MITM checking. By default, when an SSL server cert >>>> is issued, the subject DN contains cn=fqdn as the >>>> leftmost component. clients use this fqdn to verify >>>> the server. That is, client knows the IP address >>>> of the server - client does a reverse lookup (i.e. >>>> PTR) to see if the server returned by that lookup >>>> matches the cn=fqdn in the server cert. This >>>> requires reverse lookups are configured and that >>>> the fqdn is the first name/alias returned. >>>> >>>>> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" >>>>> >>>> > wrote: >>>>> >>>>> Hello everyone, >>>>> >>>>> I'm running through an issue where an >>>>> application needs its server's hostname to be >>>>> in short name format, such as "server" and not >>>>> "server.example.com >>>>> ". When I started >>>>> deploying FreeIPA in the very beginning of >>>>> this year, I remember I couldn't install >>>>> freeipa-client with a bare "ipa-client >>>>> install", because of this: >>>>> >>>>> ____________ >>>>> >>>>> [root at server ~]# hostname >>>>> server >>>>> [root at server ~]# hostname -f >>>>> server.example.com >>>>> [root at server ~]# ipa-client-install >>>>> Discovery was successful! >>>>> Hostname: server.example.com >>>>> >>>>> Realm: EXAMPLE.COM >>>>> DNS Domain: example.com >>>>> IPA Server: ipa01.example.com >>>>> >>>>> Base DN: dc=example,dc=com >>>>> >>>>> Continue to configure the system with these >>>>> values? [no] yes >>>>> User authorized to enroll computers: admin >>>>> Synchronizing time with KDC... >>>>> Unable to sync time with IPA NTP Server, >>>>> assuming the time is in sync. Please check >>>>> that port 123 UDP is opened. >>>>> Password for admin at EXAMPLE.COM >>>>> : >>>>> Joining realm failed: The hostname must be >>>>> fully-qualified: server >>>>> Installation failed. Rolling back changes. >>>>> IPA client is not configured on this system. >>>>> >>>>> ________________ >>>>> >>>>> So, using the short name as hostname didn't >>>>> work for install, I then make it like >>>>> "ipa-client install --hostname=`hostname -f` >>>>> --mkhomedir -N", and it installs and works >>>>> like a charm, BUT it updates the machine's >>>>> hostname to FQDN. >>>>> >>>>> What I tested and, at first, worked: after >>>>> deploying and ipa-client installation with >>>>> those parameters which work, renaming the >>>>> machine back to a short name AT FIRST is not >>>>> causing any problems. I can login with my ssh >>>>> rules perfectly, but I don't find any IPA >>>>> technical docs saying it will/won't work if I >>>>> change the hostname back to short name and not >>>>> FQDN. >>>>> >>>>> Searching for it, I found on RedHat guide: >>>>> "The hostname of a system is critical for the >>>>> correct operation of Kerberos and SSL. Both of >>>>> these security mechanisms rely on the hostname >>>>> to ensure that communication is occurring >>>>> between the specified hosts." >>>>> I've also found this message >>>>> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html >>>>> which seems to be related to my case, but what >>>>> I need to know is: where does it state FQDN is >>>>> a mandatory requirement in order to FreeIPA to >>>>> work and/or is there anything else (a patch, >>>>> update, whatever) to solve this issue, so I >>>>> don't need to change my applications? >>>>> >>>>> Thank you and sorry for the wall of a text. >>>>> >>>>> PS: Enviroment is CentOS 6.5, in both IPA >>>>> server and client. DNS is not the same server >>>>> as IPA (it forwards to a Windows DC). >>>>> >>>>> RPMs: >>>>> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >>>>> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>> ipa-admintools-3.0.0-37.el6.x86_64 >>>>> ipa-server-selinux-3.0.0-37.el6.x86_64 >>>>> ipa-server-3.0.0-37.el6.x86_64 >>>>> ipa-python-3.0.0-37.el6.x86_64 >>>>> ipa-client-3.0.0-37.el6.x86_64 >>>>> >>>>> >>>>> >>>>> -- >>>>> Manage your subscription for the Freeipa-users >>>>> mailing list: >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> Go To http://freeipa.org for more info on the >>>>> project >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users >>>> mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Aug 8 19:46:08 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 08 Aug 2014 21:46:08 +0200 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <53E502CA.8040307@redhat.com> <53E50C2F.80803@redhat.com> <53E518ED.3020709@redhat.com> Message-ID: <53E52900.2020200@redhat.com> Hello, On 8.8.2014 21:16, brendan kearney wrote: > Maybe I am reading too far into rfc 1178, but I hardly think making > hostnames required to be fqdns is in anybodys interest. It is not a > requirement now in any other technology anywhere, so what is the impetus to > push it? I dont see any value in it First of all, feel free to experiment with FreeIPA and let us know what we did wrong. Messages like 'I have removed all the checks and it still passes all test even with short name!' are welcome :-) As you said, Kerberos technically does not require FQDN but it is important to note that the machine name have to be stable and unique inside given Kerberos realm because the name is used as lookup key in keytab file and KDC database. Assume that FQDN is constructed as static hostname.domainname from DHCP or via reverse DNS lookup. What happens if the machine (laptop) moves from one network to another? What if the machine have multiple interfaces? As a result, any change in FQDN will break your Kerberos setup. See $ man 1 domainname " THE FQDN [...] If a machine has multiple network interfaces/addresses or is used in a mobile environment, then it may either have multiple FQDNs/domain names or none at all. Therefore avoid using hostname --fqdn, hostname --domain and dnsdomainname. hostname --ip-address is subject to the same limitations so it should be avoided as well. " Ideas and patches solving this problem are welcome. Have a nice day! Petr^2 Spacek > On Aug 8, 2014 2:37 PM, "Rich Megginson" wrote: > >> On 08/08/2014 12:21 PM, brendan kearney wrote: >> >> Double check your example. -h means the hostname of the ldap server to >> connect to and issue your query to. Man page calls it ldaphost. >> >> >> Yes. >> >> I have not run across a client that does cert validation using ldap. Is >> that IPA specific? >> >> >> I'm not talking about cert validation using ldap. I'm talking about the >> fact that, by default, the ldapsearch client will expect the hostname you >> pass in to match the hostname in the ssl server cert subject DN. >> >> It seems that a lot of effort is being spent to justify a dependency on >> fully qualified hostnames, when there is no reason to require it. In fact, >> it may even break somethings or even violate some rfc. >> >> >> If requiring fully qualified hostnames violates RFCs or other standards, >> I'd like to hear about it. >> >> On Aug 8, 2014 1:43 PM, "Rich Megginson" wrote: >> >>> On 08/08/2014 11:17 AM, brendan kearney wrote: >>> >>> The cert should have the fqdn, just like the kerberos instance, but the >>> hostname is not required to be fq'd. The lookup of a short name, as well >>> as and more specifically the IP, in dns will result in the fqdn being >>> returned by dns (the short name resolution being affected by domain and >>> search directives in resolv.conf and the origin directive in dns if either >>> of those are absent). >>> >>> Back to the point, dns lookup for cert matching is not dependent on >>> hostnames. PTR lookups will always return fqdns, so a dependency on fqdns >>> as hostnames is artificial, no? >>> >>> >>> Most clients will also do the additional step of matching the hostname in >>> the cert against the originally given hostname. For example, with >>> ldapsearch: >>> >>> ldapsearch -xLLLZZ -h hostname ... >>> >>> This will fail if the server cert for hostname has >>> "cn=hostname.domain.tld" >>> >>> On Aug 8, 2014 1:03 PM, "Rich Megginson" wrote: >>> >>>> On 08/08/2014 10:56 AM, brendan kearney wrote: >>>> >>>> Arent all of those lookups done in dns? >>>> >>>> >>>> Yes. >>>> >>>> Wouldnt that mean hostnames being fqdn's is irrelevant? >>>> >>>> >>>> Not sure what you mean. >>>> >>>> I guess if you issued your server certs with a subject DN of >>>> "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR >>>> lookups configured so that w.x.y.z returned "hostname" instead of >>>> "hostname.domain.tld", then TLS/SSL would work. >>>> >>>> On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: >>>> >>>>> On 08/08/2014 08:57 AM, brendan kearney wrote: >>>>> >>>>> Kerberos is dependent on A records in dns. The instance (as in >>>>> principal/instance at REALM) should match the A record in dns. >>>>> >>>>> There is absolutely no Kerberos dependency on hostnames being fully >>>>> qualified. I have all my devices named with short names and I have no >>>>> issues with Kerberos ticketing. >>>>> >>>>> This seems to be an artificial requirement in FreeIPA that is wrong. >>>>> >>>>> >>>>> The other hostname requirement is for TLS/SSL, for MITM checking. By >>>>> default, when an SSL server cert is issued, the subject DN contains cn=fqdn >>>>> as the leftmost component. clients use this fqdn to verify the server. >>>>> That is, client knows the IP address of the server - client does a reverse >>>>> lookup (i.e. PTR) to see if the server returned by that lookup matches the >>>>> cn=fqdn in the server cert. This requires reverse lookups are configured >>>>> and that the fqdn is the first name/alias returned. >>>>> >>>>> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < >>>>> bruno-barbosa at prodesan.com.br> wrote: >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> I'm running through an issue where an application needs its server's >>>>>> hostname to be in short name format, such as "server" and not " >>>>>> server.example.com". When I started deploying FreeIPA in the very >>>>>> beginning of this year, I remember I couldn't install freeipa-client with a >>>>>> bare "ipa-client install", because of this: >>>>>> >>>>>> ____________ >>>>>> >>>>>> [root at server ~]# hostname >>>>>> server >>>>>> [root at server ~]# hostname -f >>>>>> server.example.com >>>>>> [root at server ~]# ipa-client-install >>>>>> Discovery was successful! >>>>>> Hostname: server.example.com >>>>>> Realm: EXAMPLE.COM >>>>>> DNS Domain: example.com >>>>>> IPA Server: ipa01.example.com >>>>>> Base DN: dc=example,dc=com >>>>>> >>>>>> Continue to configure the system with these values? [no] yes >>>>>> User authorized to enroll computers: admin >>>>>> Synchronizing time with KDC... >>>>>> Unable to sync time with IPA NTP Server, assuming the time is in sync. >>>>>> Please check that port 123 UDP is opened. >>>>>> Password for admin at EXAMPLE.COM: >>>>>> Joining realm failed: The hostname must be fully-qualified: server >>>>>> Installation failed. Rolling back changes. >>>>>> IPA client is not configured on this system. >>>>>> >>>>>> ________________ >>>>>> >>>>>> So, using the short name as hostname didn't work for install, I then >>>>>> make it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", >>>>>> and it installs and works like a charm, BUT it updates the machine's >>>>>> hostname to FQDN. >>>>>> >>>>>> What I tested and, at first, worked: after deploying and ipa-client >>>>>> installation with those parameters which work, renaming the machine back to >>>>>> a short name AT FIRST is not causing any problems. I can login with my ssh >>>>>> rules perfectly, but I don't find any IPA technical docs saying it >>>>>> will/won't work if I change the hostname back to short name and not FQDN. >>>>>> >>>>>> Searching for it, I found on RedHat guide: "The hostname of a system >>>>>> is critical for the correct operation of Kerberos and SSL. Both of these >>>>>> security mechanisms rely on the hostname to ensure that communication is >>>>>> occurring between the specified hosts." >>>>>> I've also found this message >>>>>> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems >>>>>> to be related to my case, but what I need to know is: where does it state >>>>>> FQDN is a mandatory requirement in order to FreeIPA to work and/or is there >>>>>> anything else (a patch, update, whatever) to solve this issue, so I don't >>>>>> need to change my applications? >>>>>> >>>>>> Thank you and sorry for the wall of a text. >>>>>> >>>>>> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is >>>>>> not the same server as IPA (it forwards to a Windows DC). >>>>>> >>>>>> RPMs: >>>>>> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >>>>>> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >>>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>>> ipa-admintools-3.0.0-37.el6.x86_64 >>>>>> ipa-server-selinux-3.0.0-37.el6.x86_64 >>>>>> ipa-server-3.0.0-37.el6.x86_64 >>>>>> ipa-python-3.0.0-37.el6.x86_64 >>>>>> ipa-client-3.0.0-37.el6.x86_64 From bnordgren at fs.fed.us Fri Aug 8 20:02:06 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 8 Aug 2014 20:02:06 +0000 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <53E52900.2020200@redhat.com> References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <53E502CA.8040307@redhat.com> <53E50C2F.80803@redhat.com> <53E518ED.3020709@redhat.com> <53E52900.2020200@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E712B2A@001FSN2MPN1-045.001f.mgd2.msft.net> > Assume that FQDN is constructed as static hostname.domainname from > DHCP or via reverse DNS lookup. What happens if the machine (laptop) > moves from one network to another? What if the machine have multiple > interfaces? > > As a result, any change in FQDN will break your Kerberos setup. The machine's host keytab (/etc/krb5.keytab) retains a reference to whatever principal was used when the host was added to ipa. The Kerberos setup shouldn't break unless: A] You can't contact your KDC because a firewall's in the way. B] The KDC moved and DNS has not caught up. This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From bruno-barbosa at prodesan.com.br Fri Aug 8 20:03:32 2014 From: bruno-barbosa at prodesan.com.br (Bruno Henrique Barbosa) Date: Fri, 8 Aug 2014 17:03:32 -0300 (BRT) Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <53E52900.2020200@redhat.com> Message-ID: <1825955097.528628.1407528212256.JavaMail.root@prodesan.com.br> Hi everyone, I know this is such a rich debate, and I mean no offense to you guys, but can you focus answering my main question about FreeIPA and why can't I install/use it without FQDN and/or even after install it with FQDN, will I have trouble going back to the short name? Thank you and sorry! ----- Mensagem original ----- De: "Petr Spacek" Para: freeipa-users at redhat.com Enviadas: Sexta-feira, 8 de agosto de 2014 16:46:08 Assunto: Re: [Freeipa-users] FreeIPA and FQDN requirements Hello, On 8.8.2014 21:16, brendan kearney wrote: > Maybe I am reading too far into rfc 1178, but I hardly think making > hostnames required to be fqdns is in anybodys interest. It is not a > requirement now in any other technology anywhere, so what is the impetus to > push it? I dont see any value in it First of all, feel free to experiment with FreeIPA and let us know what we did wrong. Messages like 'I have removed all the checks and it still passes all test even with short name!' are welcome :-) As you said, Kerberos technically does not require FQDN but it is important to note that the machine name have to be stable and unique inside given Kerberos realm because the name is used as lookup key in keytab file and KDC database. Assume that FQDN is constructed as static hostname.domainname from DHCP or via reverse DNS lookup. What happens if the machine (laptop) moves from one network to another? What if the machine have multiple interfaces? As a result, any change in FQDN will break your Kerberos setup. See $ man 1 domainname " THE FQDN [...] If a machine has multiple network interfaces/addresses or is used in a mobile environment, then it may either have multiple FQDNs/domain names or none at all. Therefore avoid using hostname --fqdn, hostname --domain and dnsdomainname. hostname --ip-address is subject to the same limitations so it should be avoided as well. " Ideas and patches solving this problem are welcome. Have a nice day! Petr^2 Spacek > On Aug 8, 2014 2:37 PM, "Rich Megginson" wrote: > >> On 08/08/2014 12:21 PM, brendan kearney wrote: >> >> Double check your example. -h means the hostname of the ldap server to >> connect to and issue your query to. Man page calls it ldaphost. >> >> >> Yes. >> >> I have not run across a client that does cert validation using ldap. Is >> that IPA specific? >> >> >> I'm not talking about cert validation using ldap. I'm talking about the >> fact that, by default, the ldapsearch client will expect the hostname you >> pass in to match the hostname in the ssl server cert subject DN. >> >> It seems that a lot of effort is being spent to justify a dependency on >> fully qualified hostnames, when there is no reason to require it. In fact, >> it may even break somethings or even violate some rfc. >> >> >> If requiring fully qualified hostnames violates RFCs or other standards, >> I'd like to hear about it. >> >> On Aug 8, 2014 1:43 PM, "Rich Megginson" wrote: >> >>> On 08/08/2014 11:17 AM, brendan kearney wrote: >>> >>> The cert should have the fqdn, just like the kerberos instance, but the >>> hostname is not required to be fq'd. The lookup of a short name, as well >>> as and more specifically the IP, in dns will result in the fqdn being >>> returned by dns (the short name resolution being affected by domain and >>> search directives in resolv.conf and the origin directive in dns if either >>> of those are absent). >>> >>> Back to the point, dns lookup for cert matching is not dependent on >>> hostnames. PTR lookups will always return fqdns, so a dependency on fqdns >>> as hostnames is artificial, no? >>> >>> >>> Most clients will also do the additional step of matching the hostname in >>> the cert against the originally given hostname. For example, with >>> ldapsearch: >>> >>> ldapsearch -xLLLZZ -h hostname ... >>> >>> This will fail if the server cert for hostname has >>> "cn=hostname.domain.tld" >>> >>> On Aug 8, 2014 1:03 PM, "Rich Megginson" wrote: >>> >>>> On 08/08/2014 10:56 AM, brendan kearney wrote: >>>> >>>> Arent all of those lookups done in dns? >>>> >>>> >>>> Yes. >>>> >>>> Wouldnt that mean hostnames being fqdn's is irrelevant? >>>> >>>> >>>> Not sure what you mean. >>>> >>>> I guess if you issued your server certs with a subject DN of >>>> "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR >>>> lookups configured so that w.x.y.z returned "hostname" instead of >>>> "hostname.domain.tld", then TLS/SSL would work. >>>> >>>> On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: >>>> >>>>> On 08/08/2014 08:57 AM, brendan kearney wrote: >>>>> >>>>> Kerberos is dependent on A records in dns. The instance (as in >>>>> principal/instance at REALM) should match the A record in dns. >>>>> >>>>> There is absolutely no Kerberos dependency on hostnames being fully >>>>> qualified. I have all my devices named with short names and I have no >>>>> issues with Kerberos ticketing. >>>>> >>>>> This seems to be an artificial requirement in FreeIPA that is wrong. >>>>> >>>>> >>>>> The other hostname requirement is for TLS/SSL, for MITM checking. By >>>>> default, when an SSL server cert is issued, the subject DN contains cn=fqdn >>>>> as the leftmost component. clients use this fqdn to verify the server. >>>>> That is, client knows the IP address of the server - client does a reverse >>>>> lookup (i.e. PTR) to see if the server returned by that lookup matches the >>>>> cn=fqdn in the server cert. This requires reverse lookups are configured >>>>> and that the fqdn is the first name/alias returned. >>>>> >>>>> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < >>>>> bruno-barbosa at prodesan.com.br> wrote: >>>>> >>>>>> Hello everyone, >>>>>> >>>>>> I'm running through an issue where an application needs its server's >>>>>> hostname to be in short name format, such as "server" and not " >>>>>> server.example.com". When I started deploying FreeIPA in the very >>>>>> beginning of this year, I remember I couldn't install freeipa-client with a >>>>>> bare "ipa-client install", because of this: >>>>>> >>>>>> ____________ >>>>>> >>>>>> [root at server ~]# hostname >>>>>> server >>>>>> [root at server ~]# hostname -f >>>>>> server.example.com >>>>>> [root at server ~]# ipa-client-install >>>>>> Discovery was successful! >>>>>> Hostname: server.example.com >>>>>> Realm: EXAMPLE.COM >>>>>> DNS Domain: example.com >>>>>> IPA Server: ipa01.example.com >>>>>> Base DN: dc=example,dc=com >>>>>> >>>>>> Continue to configure the system with these values? [no] yes >>>>>> User authorized to enroll computers: admin >>>>>> Synchronizing time with KDC... >>>>>> Unable to sync time with IPA NTP Server, assuming the time is in sync. >>>>>> Please check that port 123 UDP is opened. >>>>>> Password for admin at EXAMPLE.COM: >>>>>> Joining realm failed: The hostname must be fully-qualified: server >>>>>> Installation failed. Rolling back changes. >>>>>> IPA client is not configured on this system. >>>>>> >>>>>> ________________ >>>>>> >>>>>> So, using the short name as hostname didn't work for install, I then >>>>>> make it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", >>>>>> and it installs and works like a charm, BUT it updates the machine's >>>>>> hostname to FQDN. >>>>>> >>>>>> What I tested and, at first, worked: after deploying and ipa-client >>>>>> installation with those parameters which work, renaming the machine back to >>>>>> a short name AT FIRST is not causing any problems. I can login with my ssh >>>>>> rules perfectly, but I don't find any IPA technical docs saying it >>>>>> will/won't work if I change the hostname back to short name and not FQDN. >>>>>> >>>>>> Searching for it, I found on RedHat guide: "The hostname of a system >>>>>> is critical for the correct operation of Kerberos and SSL. Both of these >>>>>> security mechanisms rely on the hostname to ensure that communication is >>>>>> occurring between the specified hosts." >>>>>> I've also found this message >>>>>> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems >>>>>> to be related to my case, but what I need to know is: where does it state >>>>>> FQDN is a mandatory requirement in order to FreeIPA to work and/or is there >>>>>> anything else (a patch, update, whatever) to solve this issue, so I don't >>>>>> need to change my applications? >>>>>> >>>>>> Thank you and sorry for the wall of a text. >>>>>> >>>>>> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is >>>>>> not the same server as IPA (it forwards to a Windows DC). >>>>>> >>>>>> RPMs: >>>>>> libipa_hbac-1.9.2-129.el6_5.4.x86_64 >>>>>> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 >>>>>> python-iniparse-0.3.1-2.1.el6.noarch >>>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch >>>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch >>>>>> ipa-admintools-3.0.0-37.el6.x86_64 >>>>>> ipa-server-selinux-3.0.0-37.el6.x86_64 >>>>>> ipa-server-3.0.0-37.el6.x86_64 >>>>>> ipa-python-3.0.0-37.el6.x86_64 >>>>>> ipa-client-3.0.0-37.el6.x86_64 -- Manage your subscription for 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 dpal at redhat.com Fri Aug 8 20:09:48 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Aug 2014 16:09:48 -0400 Subject: [Freeipa-users] feature request In-Reply-To: <53CC44BB.1090104@redhat.com> References: <53CC44BB.1090104@redhat.com> Message-ID: <53E52E8C.3040506@redhat.com> On 07/20/2014 06:37 PM, Rob Crittenden wrote: > sergey ivanov wrote: >> Dear IPA developers, I'd like to describe what we are doing and ask >> about existing ways to do it easier, or if there is no such ways - to >> propose creating some tools to ease such way of migration. >> >> We are preparing for migration to IPA. In our organization we were >> using kerberos servers for authentication together with /etc/passwd >> files for managing user access to hosts. In our organization we also >> are using kerberos together with .htacces files for web >> authentication. And kerberos with pam for mail services, - both IMAP >> and SMTP via dovecot. >> >> I asked some time ago and got reply here in this mailing list, that >> there is no way to use kdb_util to dump kerberos database and get from >> the dump values for inserting into IPA's ldap kerberos principle >> fields for user entries. So, we ended up using special web page, which >> authenticate our users against existing kerberos servers and after >> successful authentication reset password for this user in IPA. >> >> We did not want password in IPA to be in "expired" state, so that >> users must change once more at first login. As a workaround we are >> using 2 different kerberos connection caches for each session: one for >> administrator for setting up user password to something unique, and >> second - for authenticating with this unique password as a user, just >> to reset it to the value he requested by user though web form. >> >> I think there would be pretty many similar cases. May be having >> customizable web form on IPA server itself, authenticating for user >> against some old external authentication system from which the >> migration is being performed would be the best. >> >> If not, than at least some standard way to drop privileges from >> administrator to user, for setting up password or maybe even other >> fields, would be great. >> > I take it that the LDAP connection used by your migration page isn't > using the credentials provided by the user, but binding using some > service account? Binding as the user would be ideal, but if you can't > you can add the dn for that service account dn to the > passSyncManagersDNs list to have it not cause a reset. > > % ldapmodify -x -D "cn=Directory Manager" -W > Enter LDAP Password: ******* > dn: cn=ipa_pwd_extop,cn=plugins,cn=config > changetype: modify > add: passSyncManagersDNs > passSyncManagersDNs: uid=webadmin,cn=users,cn=accounts,dc=example,dc=com > > rob > Should we turn it into HOWTO? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri Aug 8 20:11:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Aug 2014 16:11:20 -0400 Subject: [Freeipa-users] Adding cross realm trust principals In-Reply-To: <20140721081053.GB13866@redhat.com> References: <53CCC096.6080200@kit.edu> <20140721073037.GA13866@redhat.com> <53CCC822.2050309@redhat.com> <20140721081053.GB13866@redhat.com> Message-ID: <53E52EE8.30103@redhat.com> On 07/21/2014 04:10 AM, Alexander Bokovoy wrote: > On Mon, 21 Jul 2014, Petr Spacek wrote: >> On 21.7.2014 09:30, Alexander Bokovoy wrote: >>> On Mon, 21 Jul 2014, Andreas Ladanyi wrote: >>>> Hello, >>>> >>>> i want to migrate an existing MIT Kerberos Realm to IPA and want to >>>> setup a >>>> cross realm trust relationship. I exactly have the problem >>>> discussed on this >>>> Mailinglist >>>> https://www.redhat.com/archives/freeipa-users/2013-November/msg00213.html >>>> >>>> and want to ask if there is now a new way to create trust >>>> principals without >>>> using "kadmin.local -x ipa-setup-override-restrictions". >>> No changes yet. >> >> Let me elaborate. We haven't had time to work on this but it would be >> really valuable if you could experiment with it a little bit. >> >> Simo, Alexander, could you propose some dirty tricks to try? > The thread mentioned above has all needed information already. Should we turn it into a HOWTO page then? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From bnordgren at fs.fed.us Fri Aug 8 20:13:19 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Fri, 8 Aug 2014 20:13:19 +0000 Subject: [Freeipa-users] Adding cross realm trust principals In-Reply-To: <53E52EE8.30103@redhat.com> References: <53CCC096.6080200@kit.edu> <20140721073037.GA13866@redhat.com> <53CCC822.2050309@redhat.com> <20140721081053.GB13866@redhat.com> <53E52EE8.30103@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E712B4F@001FSN2MPN1-045.001f.mgd2.msft.net> > >> Let me elaborate. We haven't had time to work on this but it would be > >> really valuable if you could experiment with it a little bit. > >> > >> Simo, Alexander, could you propose some dirty tricks to try? > > The thread mentioned above has all needed information already. > Should we turn it into a HOWTO page then? Yes, I would appreciate that. This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From dpal at redhat.com Fri Aug 8 20:16:43 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Aug 2014 16:16:43 -0400 Subject: [Freeipa-users] Mass update IP addresses In-Reply-To: References: Message-ID: <53E5302B.5010401@redhat.com> On 07/22/2014 11:04 AM, KodaK wrote: > For various reasons, I need to move a lot of my IPA clients to a > different subnet. > > I'd like to automate this as much as possible. My initial thought is > to use a combination > of puppet and ipa commands, but I wanted to see if anyone had any > advice. Anything I > should watch out for in IPA? I know that's vague, but I'm just > seeking general advice. > > Thanks, > > --Jason > > > > I do not see any replies. How did it go? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Aug 8 20:23:12 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Aug 2014 16:23:12 -0400 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: References: <53E3B5C8.6090208@sesda3.com> Message-ID: <53E531B0.8030300@redhat.com> On 08/07/2014 02:21 PM, Chris Whittle wrote: > Thanks guys that works! And what about HOWTO? ;-) > > > On Thu, Aug 7, 2014 at 12:22 PM, Lucas Yamanishi > > wrote: > > On 08/07/2014 12:18 PM, Chris Whittle wrote: > >> I'm currently working on a trial with OKTA and have installed >> their server agent with no issues. Now I'm trying to map FreeIPA >> attributes with OKTA's >> >> I'm getting no entries found, which leads me to think I'm missing >> something >> Inline image 1 >> Inline image 2 >> Inline image 3 >> Thanks! >> >> > The objectClass values look incorrect. Try |posixAccount| and > |posixGroup| for users and groups. Roles are |groupOfNames|, but > that's a little less specific and will match non-role entries > without a search base. > > You can easily look up raw entries to check your mappings with > commands like these (the ---all and ---raw options are available > for all *-show commands, afaik): > > |ipa user-show --all --raw $USER_NAME > ipa group-show --all --raw $GROUP > ipa role-show --all --raw $ROLE > | > > Or pure ldaputils: > > | ldapsearch -LLL -YGSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' 'uid=$USER_NAME' > | > > -- > ----- > *question everything*learn something*answer nothing* > ------------ > Lucas Yamanishi > ------------------ > Systems Administrator, ADNET Systems, Inc. > NASA Space and Earth Science Data Analysis (606.9) > 7515 Mission Drive, Suite A100 > Lanham, MD 20706 *301-352-4646 * 0xD354B2CB > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 89508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 88448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 103249 bytes Desc: not available URL: From cwhittl at gmail.com Fri Aug 8 20:26:58 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Fri, 8 Aug 2014 15:26:58 -0500 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: <53E531B0.8030300@redhat.com> References: <53E3B5C8.6090208@sesda3.com> <53E531B0.8030300@redhat.com> Message-ID: Hey Dimitri, What do you mean? Both of them gave me the same answer and it worked. On Aug 8, 2014 3:25 PM, "Dmitri Pal" wrote: > On 08/07/2014 02:21 PM, Chris Whittle wrote: > > Thanks guys that works! > > > > And what about HOWTO? ;-) > > > > > On Thu, Aug 7, 2014 at 12:22 PM, Lucas Yamanishi > wrote: > >> On 08/07/2014 12:18 PM, Chris Whittle wrote: >> >> I'm currently working on a trial with OKTA and have installed their >> server agent with no issues. Now I'm trying to map FreeIPA attributes with >> OKTA's >> >> I'm getting no entries found, which leads me to think I'm missing >> something >> [image: Inline image 1] >> [image: Inline image 2] >> [image: Inline image 3] >> Thanks! >> >> >> The objectClass values look incorrect. Try posixAccount and posixGroup >> for users and groups. Roles are groupOfNames, but that?s a little less >> specific and will match non-role entries without a search base. >> >> You can easily look up raw entries to check your mappings with commands >> like these (the ?all and ?raw options are available for all *-show >> commands, afaik): >> >> ipa user-show --all --raw $USER_NAME >> ipa group-show --all --raw $GROUP >> ipa role-show --all --raw $ROLE >> >> Or pure ldaputils: >> >> ldapsearch -LLL -YGSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' 'uid=$USER_NAME' >> >> ? >> >> -- >> ----- >> *question everything*learn something*answer nothing* >> ------------ >> Lucas Yamanishi >> ------------------ >> Systems Administrator, ADNET Systems, Inc. >> NASA Space and Earth Science Data Analysis (606.9) >> 7515 Mission Drive, Suite A100 >> Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for 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: not available Type: image/png Size: 89508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 103249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 88448 bytes Desc: not available URL: From ssorce at redhat.com Fri Aug 8 20:31:40 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2014 16:31:40 -0400 Subject: [Freeipa-users] FreeIPA + Ipsilon In-Reply-To: References: <1406805084.30289.25.camel@willson.usersys.redhat.com> <1407260903.4573.9.camel@willson.usersys.redhat.com> <53E12368.9070308@redhat.com> <1407339420.4573.21.camel@willson.usersys.redhat.com> Message-ID: <1407529900.28399.28.camel@willson.usersys.redhat.com> On Thu, 2014-08-07 at 17:49 +0200, Luca Tartarini wrote: > Hi, > > thanks for the reply, with Cherrypy 3.2.2 it works. Unfortunately now when > I try to login with 'admin' account ('admin' user created previously during > the installation of ipa-server) I can't see the Administration tab. > Basically this condition (in /usr/share/ipsilon/templates/index.html) is > not satisfied: > > {% if user.is_admin %} > Administration | > {% endif %} > > For ipsilon-server installation I run: > > ipsilon-server-install --secure=no --ipa=yes --krb=yes > > because I read that 'admin' is default. > When I login with 'admin' in IPA Identity Management it is all ok (I login > as administrator), with IPSILON I can login but not as administrator. Is this using kerberos authentication ? Or username/password ? If Kerberos SSO then do you have KrbLocalUserMapping On in the section in the file /etc/httpd/conf.g/ipsilon-idp.conf ? If not then the user will be seen as admin at REALM and not considered the same as the user "admin" by ipsilon. Simo. > I used the last version of jinja2 (jinja2 2.7.2). > > Log of ipsilon-server-install: > > [2014-08-07 17:48:11,242] Intallation arguments: > [2014-08-07 17:48:11,242] admin_user: admin > [2014-08-07 17:48:11,242] config_profile: None > [2014-08-07 17:48:11,242] hostname: ltartari3.cern.ch > [2014-08-07 17:48:11,242] instance: idp > [2014-08-07 17:48:11,242] ipa: yes > [2014-08-07 17:48:11,243] krb: yes > [2014-08-07 17:48:11,243] krb_httpd_keytab: /etc/httpd/conf/http.keytab > [2014-08-07 17:48:11,243] krb_realms: None > [2014-08-07 17:48:11,243] lm_order: ['krb'] > [2014-08-07 17:48:11,243] pam: no > [2014-08-07 17:48:11,243] pam_service: remote > [2014-08-07 17:48:11,243] saml2: yes > [2014-08-07 17:48:11,243] secure: no > [2014-08-07 17:48:11,243] server_debugging: False > [2014-08-07 17:48:11,244] system_user: ipsilon > [2014-08-07 17:48:11,244] testauth: no > [2014-08-07 17:48:11,244] uninstall: False > [2014-08-07 17:48:11,244] Installation initiated > [2014-08-07 17:48:11,244] Installing default config files > [2014-08-07 17:48:11,461] Configuring environment helpers > Searching for keytab in: /etc/httpd/conf/http.keytab ... Found! > Searching for keytab in: /etc/httpd/conf/ipa.keytab ... Found! > [2014-08-07 17:48:11,486] Configuring login managers > Cannot set persistent booleans without managed policy. > [2014-08-07 17:48:12,126] Configuring Authentication Providers > Generating a 2048 bit RSA private key > .............+++ > ..............+++ > writing new private key to '/var/lib/ipsilon/idp/saml2/idp.key' > ----- > Installation complete. > Please restart HTTPD to enable the IdP instance. > > > Thanks in advance. > > Luca Tartarini > > > 2014-08-06 17:37 GMT+02:00 Simo Sorce : > > > On Wed, 2014-08-06 at 17:20 +0200, Luca Tartarini wrote: > > > Hi, > > > > > > Thanks for the replies. I updated the line with: > > > > > > plugins_by_name = dict((p.name, p) for p in > > self._site[FACILITY]['enabled']) > > > > > > and it works (the installation is completed succesfully). > > > > > > But now when I try to connect to: > > > > > > https://myidp.example.com/idp > > > > > > or I try to configure ipsilon-client (ipsilon-client-install ...) I got > > > HTTP 500 Internal Error (with ipsilon background). I put "debug = True" > > > in /etc/ipsilon/idp/ipsilon.conf and I got this (in > > > /var/log/httpd/error_log): > > > > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Available > > > providers: ['saml2'] > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > > storage path: /var/lib/ipsilon/idp/saml2 > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > > metadata file: metadata.xml > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > > storage path: /var/lib/ipsilon/idp/saml2 > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > key > > > file: /var/lib/ipsilon/idp/saml2/idp.key > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > > storage path: /var/lib/ipsilon/idp/saml2 > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > > certificate file: /var/lib/ipsilon/idp/saml2/idp.pem > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] IdP Provider > > > registered: saml2 > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] > > enabled: > > > 1 > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] IdP Provider > > > enabled: saml2 > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login > > > plugin: krb > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login > > > plugin: pam > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] username > > > text: Username > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] password > > > text: Password > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] service > > > name: remote > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [pam] help > > text: > > > Insert your Username and Password and then submit. > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin login > > > plugin: testauth > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] > > > username text: Username > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] > > > password text: Password > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [testauth] > > help > > > text: Insert your Username and Password and then submit. > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Admin provider > > > plugin: saml2 > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] > > default > > > allowed nameids: ['persistent', 'transient', 'email', 'kerberos', 'x509'] > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > > metadata file: metadata.xml > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] > > default > > > email domain: example.com > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > > certificate file: /var/lib/ipsilon/idp/saml2/idp.pem > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] allow > > > self registration: True > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > key > > > file: /var/lib/ipsilon/idp/saml2/idp.key > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] idp > > > storage path: /var/lib/ipsilon/idp/saml2 > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] [saml2] > > default > > > nameid: persistent > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] Traceback > > (most > > > recent call last): > > > [Wed Aug 06 16:22:09 2014] [error] File > > > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > > line 104, in run > > > [Wed Aug 06 16:22:09 2014] [error] hook() > > > [Wed Aug 06 16:22:09 2014] [error] File > > > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > > line 63, in __call__ > > > [Wed Aug 06 16:22:09 2014] [error] return > > self.callback(**self.kwargs) > > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/ipsilon/util/page.py", line 37, in > > protect > > > [Wed Aug 06 16:22:09 2014] [error] UserSession().remote_login() > > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/ipsilon/util/user.py", line 103, in > > > __init__ > > > [Wed Aug 06 16:22:09 2014] [error] self.user = self.get_data('user', > > > 'name') > > > [Wed Aug 06 16:22:09 2014] [error] File > > > "/usr/lib/python2.6/site-packages/ipsilon/util/user.py", line 147, in > > > get_data > > > [Wed Aug 06 16:22:09 2014] [error] if facility not in > > cherrypy.session: > > > [Wed Aug 06 16:22:09 2014] [error] File > > > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/__init__.py", > > > line 258, in __contains__ > > > [Wed Aug 06 16:22:09 2014] [error] return key in child > > > [Wed Aug 06 16:22:09 2014] [error] File > > > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", > > > line 335, in __contains__ > > > [Wed Aug 06 16:22:09 2014] [error] self.load() > > > [Wed Aug 06 16:22:09 2014] [error] File > > > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", > > > line 268, in load > > > [Wed Aug 06 16:22:09 2014] [error] data = self._load() > > > [Wed Aug 06 16:22:09 2014] [error] File > > > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/lib/sessions.py", > > > line 497, in _load > > > [Wed Aug 06 16:22:09 2014] [error] assert self.locked, ("The session > > > load without being locked. " > > > [Wed Aug 06 16:22:09 2014] [error] AssertionError: The session load > > without > > > being locked. Check your tools' priority levels. > > > [Wed Aug 06 16:22:09 2014] [error] > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] HTTP > > > [Wed Aug 06 16:22:09 2014] [error] Request Headers: > > > [Wed Aug 06 16:22:09 2014] [error] COOKIE: > > > __utma=203412483.1716219377.1393273532.1393273532.1398882487.2; > > > > > __utmz=203412483.1398882487.2.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); > > > _ga=GA1.2.1716219377.1393273532; > > > session_id=0942ebacef3fbcf8f9b21605013b5dfa1454bc93 > > > [Wed Aug 06 16:22:09 2014] [error] ACCEPT-LANGUAGE: > > > it-IT,it;q=0.8,en-US;q=0.6,en;q=0.4,fr;q=0.2 > > > [Wed Aug 06 16:22:09 2014] [error] USER-AGENT: Mozilla/5.0 (X11; Linux > > > x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.132 > > > Safari/537.36 > > > [Wed Aug 06 16:22:09 2014] [error] CONNECTION: keep-alive > > > [Wed Aug 06 16:22:09 2014] [error] Remote-Addr: 128.141.28.32 > > > [Wed Aug 06 16:22:09 2014] [error] HOST: ltartari3.cern.ch > > > [Wed Aug 06 16:22:09 2014] [error] CACHE-CONTROL: max-age=0 > > > [Wed Aug 06 16:22:09 2014] [error] ACCEPT: > > > > > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > > > [Wed Aug 06 16:22:09 2014] [error] ACCEPT-ENCODING: gzip,deflate,sdch > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] HTTP Traceback > > > (most recent call last): > > > [Wed Aug 06 16:22:09 2014] [error] File > > > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > > line 667, in respond > > > [Wed Aug 06 16:22:09 2014] [error] self.hooks.run('before_handler') > > > [Wed Aug 06 16:22:09 2014] [error] File > > > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > > line 114, in run > > > [Wed Aug 06 16:22:09 2014] [error] raise exc > > > [Wed Aug 06 16:22:09 2014] [error] AssertionError: The session load > > without > > > being locked. Check your tools' priority levels. > > > [Wed Aug 06 16:22:09 2014] [error] > > > [Wed Aug 06 16:22:09 2014] [error] [06/Aug/2014:16:22:09] ['500 Internal > > > Server Error', 'The server encountered an unexpected condition which > > > prevented it from fulfilling the request.', 'Traceback (most recent call > > > last):\\n File > > > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > > line 667, in respond\\n self.hooks.run(\\'before_handler\\')\\n File > > > > > "/usr/lib/python2.6/site-packages/CherryPy-3.5.0-py2.6.egg/cherrypy/_cprequest.py", > > > line 114, in run\\n raise exc\\nAssertionError: The session load > > without > > > being locked. Check your tools\\' priority levels.\\n', '3.5.0'] > > > > > > and obviously "GET /idp/ HTTP/1.1" 500 1054 in /var/log/httpd/access_log > > > > > > Cherrypy bug? > > > > > > Thanks. > > > > I've never seen this but I am using Cherrypy 3.2.2 on F20. > > > > Simo. > > > > > > From simo at redhat.com Fri Aug 8 20:35:31 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2014 16:35:31 -0400 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <53E4F637.3020709@redhat.com> References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> Message-ID: <1407530131.28399.30.camel@willson.usersys.redhat.com> On Fri, 2014-08-08 at 10:09 -0600, Rich Megginson wrote: > On 08/08/2014 08:57 AM, brendan kearney wrote: > > > > Kerberos is dependent on A records in dns. The instance (as in > > principal/instance at REALM) should match the A record in dns. > > > > There is absolutely no Kerberos dependency on hostnames being fully > > qualified. I have all my devices named with short names and I have no > > issues with Kerberos ticketing. > > > > This seems to be an artificial requirement in FreeIPA that is wrong. > > > > The other hostname requirement is for TLS/SSL, for MITM checking. By > default, when an SSL server cert is issued, the subject DN contains > cn=fqdn as the leftmost component. clients use this fqdn to verify the > server. That is, client knows the IP address of the server - client > does a reverse lookup (i.e. PTR) to see if the server returned by that > lookup matches the cn=fqdn in the server cert. This requires reverse > lookups are configured and that the fqdn is the first name/alias returned. This is incorrect, clients check that the name they've been told to use matches what the certificate says is the name of the server. PTR records are never and *should never* be used to check certificate names or it would be absolutely trivial to MITM clients by redirecting them to a different IP address or spoofing the PTR reply from DNS to a certificate that is completely unrelated to the server you wanted to connect to. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Fri Aug 8 20:39:54 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 08 Aug 2014 14:39:54 -0600 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <1407530131.28399.30.camel@willson.usersys.redhat.com> References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <1407530131.28399.30.camel@willson.usersys.redhat.com> Message-ID: <53E5359A.1050602@redhat.com> On 08/08/2014 02:35 PM, Simo Sorce wrote: > On Fri, 2014-08-08 at 10:09 -0600, Rich Megginson wrote: >> On 08/08/2014 08:57 AM, brendan kearney wrote: >>> Kerberos is dependent on A records in dns. The instance (as in >>> principal/instance at REALM) should match the A record in dns. >>> >>> There is absolutely no Kerberos dependency on hostnames being fully >>> qualified. I have all my devices named with short names and I have no >>> issues with Kerberos ticketing. >>> >>> This seems to be an artificial requirement in FreeIPA that is wrong. >>> >> The other hostname requirement is for TLS/SSL, for MITM checking. By >> default, when an SSL server cert is issued, the subject DN contains >> cn=fqdn as the leftmost component. clients use this fqdn to verify the >> server. That is, client knows the IP address of the server - client >> does a reverse lookup (i.e. PTR) to see if the server returned by that >> lookup matches the cn=fqdn in the server cert. This requires reverse >> lookups are configured and that the fqdn is the first name/alias returned. > This is incorrect, clients check that the name they've been told to use > matches what the certificate says is the name of the server. > > PTR records are never and *should never* be used to check certificate > names or it would be absolutely trivial to MITM clients by redirecting > them to a different IP address or spoofing the PTR reply from DNS to a > certificate that is completely unrelated to the server you wanted to > connect to. Sorry. Yes, you are correct. The TLS/SSL client does not do a PTR lookup, it does an A/AAAA lookup of the host specified in the server cert subject DN, then sees if that IP address matches the IP address of the server from the network connection. > > Simo. > From simo at redhat.com Fri Aug 8 20:44:58 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2014 16:44:58 -0400 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <1825955097.528628.1407528212256.JavaMail.root@prodesan.com.br> References: <1825955097.528628.1407528212256.JavaMail.root@prodesan.com.br> Message-ID: <1407530698.28399.32.camel@willson.usersys.redhat.com> On Fri, 2014-08-08 at 17:03 -0300, Bruno Henrique Barbosa wrote: > Hi everyone, > > I know this is such a rich debate, and I mean no offense to you guys, > but can you focus answering my main question about FreeIPA and why > can't I install/use it without FQDN and/or even after install it with > FQDN, will I have trouble going back to the short name? > > Thank you and sorry! You should be able to set back a short hostname provided you check that in /etc/sssd/sssd.conf you set ipa_hostname to the fully qualified name in the appropriate domain section. This will insure sssd (and therefor login) works. SSHD may not like GSSAPI authentication unless you fool it by a hack in libkrb5 setting ignore_acceptor_hostname true in krb5.conf in the [libdefaults] section. Most stuff should work this way, but cannot vouch for all kerberized servers you may deploy on such a machine. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Aug 8 20:51:05 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2014 16:51:05 -0400 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <53E502CA.8040307@redhat.com> <53E50C2F.80803@redhat.com> <53E518ED.3020709@redhat.com> Message-ID: <1407531065.28399.34.camel@willson.usersys.redhat.com> On Fri, 2014-08-08 at 15:16 -0400, brendan kearney wrote: > Maybe I am reading too far into rfc 1178, but I hardly think making > hostnames required to be fqdns is in anybodys interest. It is not a > requirement now in any other technology anywhere, so what is the impetus to > push it? I dont see any value in it A number of kerberized services used to use gethostname() and then troll /etc/krb5.keytab to find a suitable key. This obviously fail if your hostname is not a fqdn. Now in time we are trying to avoid application from using direct kerberos calls and for GSSAPI applications that still insist using gethostname() to construct the local server name and the pass it to the acceptor (for example openssh) we have the little hack of setting ignore_acceptor_hostname top true ion krb5.conf I think we are getting close to be able to work without forcing the hostname to be a fqdn on the client, provided you have a way to tell what is the fqdn at freeipa-client-install time. We did not want to force all machines to belong to the same DNS domain as the kerberos realm so we cannot do like windows and force the fqdn to be lower(hostname.REALM) like windows does. Perhaps we could use hostname -f and hope we get something sensible on join or simply force users to always pass --hostname Please open a RFE to consider dropping the requirement on the client. Simo. > On Aug 8, 2014 2:37 PM, "Rich Megginson" wrote: > > > On 08/08/2014 12:21 PM, brendan kearney wrote: > > > > Double check your example. -h means the hostname of the ldap server to > > connect to and issue your query to. Man page calls it ldaphost. > > > > > > Yes. > > > > I have not run across a client that does cert validation using ldap. Is > > that IPA specific? > > > > > > I'm not talking about cert validation using ldap. I'm talking about the > > fact that, by default, the ldapsearch client will expect the hostname you > > pass in to match the hostname in the ssl server cert subject DN. > > > > It seems that a lot of effort is being spent to justify a dependency on > > fully qualified hostnames, when there is no reason to require it. In fact, > > it may even break somethings or even violate some rfc. > > > > > > If requiring fully qualified hostnames violates RFCs or other standards, > > I'd like to hear about it. > > > > On Aug 8, 2014 1:43 PM, "Rich Megginson" wrote: > > > >> On 08/08/2014 11:17 AM, brendan kearney wrote: > >> > >> The cert should have the fqdn, just like the kerberos instance, but the > >> hostname is not required to be fq'd. The lookup of a short name, as well > >> as and more specifically the IP, in dns will result in the fqdn being > >> returned by dns (the short name resolution being affected by domain and > >> search directives in resolv.conf and the origin directive in dns if either > >> of those are absent). > >> > >> Back to the point, dns lookup for cert matching is not dependent on > >> hostnames. PTR lookups will always return fqdns, so a dependency on fqdns > >> as hostnames is artificial, no? > >> > >> > >> Most clients will also do the additional step of matching the hostname in > >> the cert against the originally given hostname. For example, with > >> ldapsearch: > >> > >> ldapsearch -xLLLZZ -h hostname ... > >> > >> This will fail if the server cert for hostname has > >> "cn=hostname.domain.tld" > >> > >> On Aug 8, 2014 1:03 PM, "Rich Megginson" wrote: > >> > >>> On 08/08/2014 10:56 AM, brendan kearney wrote: > >>> > >>> Arent all of those lookups done in dns? > >>> > >>> > >>> Yes. > >>> > >>> Wouldnt that mean hostnames being fqdn's is irrelevant? > >>> > >>> > >>> Not sure what you mean. > >>> > >>> I guess if you issued your server certs with a subject DN of > >>> "cn=hostname", instead of "cn=hostname.domain.tld", and you had the DNS PTR > >>> lookups configured so that w.x.y.z returned "hostname" instead of > >>> "hostname.domain.tld", then TLS/SSL would work. > >>> > >>> On Aug 8, 2014 12:11 PM, "Rich Megginson" wrote: > >>> > >>>> On 08/08/2014 08:57 AM, brendan kearney wrote: > >>>> > >>>> Kerberos is dependent on A records in dns. The instance (as in > >>>> principal/instance at REALM) should match the A record in dns. > >>>> > >>>> There is absolutely no Kerberos dependency on hostnames being fully > >>>> qualified. I have all my devices named with short names and I have no > >>>> issues with Kerberos ticketing. > >>>> > >>>> This seems to be an artificial requirement in FreeIPA that is wrong. > >>>> > >>>> > >>>> The other hostname requirement is for TLS/SSL, for MITM checking. By > >>>> default, when an SSL server cert is issued, the subject DN contains cn=fqdn > >>>> as the leftmost component. clients use this fqdn to verify the server. > >>>> That is, client knows the IP address of the server - client does a reverse > >>>> lookup (i.e. PTR) to see if the server returned by that lookup matches the > >>>> cn=fqdn in the server cert. This requires reverse lookups are configured > >>>> and that the fqdn is the first name/alias returned. > >>>> > >>>> On Aug 8, 2014 8:54 AM, "Bruno Henrique Barbosa" < > >>>> bruno-barbosa at prodesan.com.br> wrote: > >>>> > >>>>> Hello everyone, > >>>>> > >>>>> I'm running through an issue where an application needs its server's > >>>>> hostname to be in short name format, such as "server" and not " > >>>>> server.example.com". When I started deploying FreeIPA in the very > >>>>> beginning of this year, I remember I couldn't install freeipa-client with a > >>>>> bare "ipa-client install", because of this: > >>>>> > >>>>> ____________ > >>>>> > >>>>> [root at server ~]# hostname > >>>>> server > >>>>> [root at server ~]# hostname -f > >>>>> server.example.com > >>>>> [root at server ~]# ipa-client-install > >>>>> Discovery was successful! > >>>>> Hostname: server.example.com > >>>>> Realm: EXAMPLE.COM > >>>>> DNS Domain: example.com > >>>>> IPA Server: ipa01.example.com > >>>>> Base DN: dc=example,dc=com > >>>>> > >>>>> Continue to configure the system with these values? [no] yes > >>>>> User authorized to enroll computers: admin > >>>>> Synchronizing time with KDC... > >>>>> Unable to sync time with IPA NTP Server, assuming the time is in sync. > >>>>> Please check that port 123 UDP is opened. > >>>>> Password for admin at EXAMPLE.COM: > >>>>> Joining realm failed: The hostname must be fully-qualified: server > >>>>> Installation failed. Rolling back changes. > >>>>> IPA client is not configured on this system. > >>>>> > >>>>> ________________ > >>>>> > >>>>> So, using the short name as hostname didn't work for install, I then > >>>>> make it like "ipa-client install --hostname=`hostname -f` --mkhomedir -N", > >>>>> and it installs and works like a charm, BUT it updates the machine's > >>>>> hostname to FQDN. > >>>>> > >>>>> What I tested and, at first, worked: after deploying and ipa-client > >>>>> installation with those parameters which work, renaming the machine back to > >>>>> a short name AT FIRST is not causing any problems. I can login with my ssh > >>>>> rules perfectly, but I don't find any IPA technical docs saying it > >>>>> will/won't work if I change the hostname back to short name and not FQDN. > >>>>> > >>>>> Searching for it, I found on RedHat guide: "The hostname of a system > >>>>> is critical for the correct operation of Kerberos and SSL. Both of these > >>>>> security mechanisms rely on the hostname to ensure that communication is > >>>>> occurring between the specified hosts." > >>>>> I've also found this message > >>>>> http://osdir.com/ml/freeipa-users/2012-03/msg00006.html which seems > >>>>> to be related to my case, but what I need to know is: where does it state > >>>>> FQDN is a mandatory requirement in order to FreeIPA to work and/or is there > >>>>> anything else (a patch, update, whatever) to solve this issue, so I don't > >>>>> need to change my applications? > >>>>> > >>>>> Thank you and sorry for the wall of a text. > >>>>> > >>>>> PS: Enviroment is CentOS 6.5, in both IPA server and client. DNS is > >>>>> not the same server as IPA (it forwards to a Windows DC). > >>>>> > >>>>> RPMs: > >>>>> libipa_hbac-1.9.2-129.el6_5.4.x86_64 > >>>>> libipa_hbac-python-1.9.2-129.el6_5.4.x86_64 > >>>>> python-iniparse-0.3.1-2.1.el6.noarch > >>>>> ipa-pki-common-theme-9.0.3-7.el6.noarch > >>>>> ipa-pki-ca-theme-9.0.3-7.el6.noarch > >>>>> ipa-admintools-3.0.0-37.el6.x86_64 > >>>>> ipa-server-selinux-3.0.0-37.el6.x86_64 > >>>>> ipa-server-3.0.0-37.el6.x86_64 > >>>>> ipa-python-3.0.0-37.el6.x86_64 > >>>>> ipa-client-3.0.0-37.el6.x86_64 > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Manage your subscription for 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 > >>>> > >>> > >>> > >> > > -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Aug 8 20:56:09 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2014 16:56:09 -0400 Subject: [Freeipa-users] FreeIPA and FQDN requirements In-Reply-To: <53E5359A.1050602@redhat.com> References: <363819447.518756.1407500191140.JavaMail.root@prodesan.com.br> <1710276640.519712.1407502315242.JavaMail.root@prodesan.com.br> <53E4F637.3020709@redhat.com> <1407530131.28399.30.camel@willson.usersys.redhat.com> <53E5359A.1050602@redhat.com> Message-ID: <1407531369.28399.36.camel@willson.usersys.redhat.com> On Fri, 2014-08-08 at 14:39 -0600, Rich Megginson wrote: > On 08/08/2014 02:35 PM, Simo Sorce wrote: > > On Fri, 2014-08-08 at 10:09 -0600, Rich Megginson wrote: > >> On 08/08/2014 08:57 AM, brendan kearney wrote: > >>> Kerberos is dependent on A records in dns. The instance (as in > >>> principal/instance at REALM) should match the A record in dns. > >>> > >>> There is absolutely no Kerberos dependency on hostnames being fully > >>> qualified. I have all my devices named with short names and I have no > >>> issues with Kerberos ticketing. > >>> > >>> This seems to be an artificial requirement in FreeIPA that is wrong. > >>> > >> The other hostname requirement is for TLS/SSL, for MITM checking. By > >> default, when an SSL server cert is issued, the subject DN contains > >> cn=fqdn as the leftmost component. clients use this fqdn to verify the > >> server. That is, client knows the IP address of the server - client > >> does a reverse lookup (i.e. PTR) to see if the server returned by that > >> lookup matches the cn=fqdn in the server cert. This requires reverse > >> lookups are configured and that the fqdn is the first name/alias returned. > > This is incorrect, clients check that the name they've been told to use > > matches what the certificate says is the name of the server. > > > > PTR records are never and *should never* be used to check certificate > > names or it would be absolutely trivial to MITM clients by redirecting > > them to a different IP address or spoofing the PTR reply from DNS to a > > certificate that is completely unrelated to the server you wanted to > > connect to. > > Sorry. Yes, you are correct. The TLS/SSL client does not do a PTR > lookup, it does an A/AAAA lookup of the host specified in the server > cert subject DN, then sees if that IP address matches the IP address of > the server from the network connection. Nope, it doesn't do this either. The application may do a DNS A/AAAA request to find out what is the server IP (although that may also be set in /etc/hosts locally) *before* it even tries to connect to the server (and therefore before seeing the certificate). Once it has connected though it just does a straight comparison of the name requested by the user with the name in the cert. If it did a DNS lookup of the name found in the cert it would be subject to the same MITM attack by presenting a randomly named cert and then spoofing the A/AAAA DNS request. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Fri Aug 8 21:04:40 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 08 Aug 2014 23:04:40 +0200 Subject: [Freeipa-users] Mass update IP addresses In-Reply-To: <53E5302B.5010401@redhat.com> References: <53E5302B.5010401@redhat.com> Message-ID: <53E53B68.5050304@redhat.com> On 8.8.2014 22:16, Dmitri Pal wrote: > On 07/22/2014 11:04 AM, KodaK wrote: >> For various reasons, I need to move a lot of my IPA clients to a different >> subnet. >> >> I'd like to automate this as much as possible. My initial thought is to use >> a combination >> of puppet and ipa commands, but I wanted to see if anyone had any advice. >> Anything I >> should watch out for in IPA? I know that's vague, but I'm just seeking >> general advice. I'm sorry, the original question was almost forgotten... SSSD should handle IP address change if: - hostname stays the same - dynamic DNS updates are enabled on IPA server - SSSD/nsupdate can automatically update PTR records if they are hosted on the same IPA server and PTR synchronization is enabled - see: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/SyncPTR The other option is to use ipa command dnsrecord-mod with own script. Simply use "ipa dnsrecord-mod ...", no magic is required. > I do not see any replies. > How did it go? -- Petr^2 Spacek From rcritten at redhat.com Sun Aug 10 02:43:13 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 09 Aug 2014 22:43:13 -0400 Subject: [Freeipa-users] feature request In-Reply-To: <53E52E8C.3040506@redhat.com> References: <53CC44BB.1090104@redhat.com> <53E52E8C.3040506@redhat.com> Message-ID: <53E6DC41.5090505@redhat.com> Dmitri Pal wrote: > On 07/20/2014 06:37 PM, Rob Crittenden wrote: >> sergey ivanov wrote: >>> Dear IPA developers, I'd like to describe what we are doing and ask >>> about existing ways to do it easier, or if there is no such ways - to >>> propose creating some tools to ease such way of migration. >>> >>> We are preparing for migration to IPA. In our organization we were >>> using kerberos servers for authentication together with /etc/passwd >>> files for managing user access to hosts. In our organization we also >>> are using kerberos together with .htacces files for web >>> authentication. And kerberos with pam for mail services, - both IMAP >>> and SMTP via dovecot. >>> >>> I asked some time ago and got reply here in this mailing list, that >>> there is no way to use kdb_util to dump kerberos database and get from >>> the dump values for inserting into IPA's ldap kerberos principle >>> fields for user entries. So, we ended up using special web page, which >>> authenticate our users against existing kerberos servers and after >>> successful authentication reset password for this user in IPA. >>> >>> We did not want password in IPA to be in "expired" state, so that >>> users must change once more at first login. As a workaround we are >>> using 2 different kerberos connection caches for each session: one for >>> administrator for setting up user password to something unique, and >>> second - for authenticating with this unique password as a user, just >>> to reset it to the value he requested by user though web form. >>> >>> I think there would be pretty many similar cases. May be having >>> customizable web form on IPA server itself, authenticating for user >>> against some old external authentication system from which the >>> migration is being performed would be the best. >>> >>> If not, than at least some standard way to drop privileges from >>> administrator to user, for setting up password or maybe even other >>> fields, would be great. >>> >> I take it that the LDAP connection used by your migration page isn't >> using the credentials provided by the user, but binding using some >> service account? Binding as the user would be ideal, but if you can't >> you can add the dn for that service account dn to the >> passSyncManagersDNs list to have it not cause a reset. >> >> % ldapmodify -x -D "cn=Directory Manager" -W >> Enter LDAP Password: ******* >> dn: cn=ipa_pwd_extop,cn=plugins,cn=config >> changetype: modify >> add: passSyncManagersDNs >> passSyncManagersDNs: uid=webadmin,cn=users,cn=accounts,dc=example,dc=com >> >> rob >> > Should we turn it into HOWTO? I believe this is already in the documentation. rob From erinn.looneytriggs at gmail.com Sun Aug 10 02:50:20 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Sat, 09 Aug 2014 20:50:20 -0600 Subject: [Freeipa-users] MinSSF suggestions? Message-ID: <53E6DDEC.10105@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 It would seem to be prudent to set the minssf setting for 389 to 56, however I am wondering why this isn't done by default, and if there is any reason why I shouldn't do it? Thanks, - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT5t3nAAoJEFg7BmJL2iPOMuEIAK2pqwpn8bxmZhj4NwKDifV7 B3oNIFGfSlabQzV4bdQHiYTVknqjQK4V0K6fX2ZcfP/nMqEC9sSCQ6zkbXiu3u4w ZHBCMcHgW1olRFHXZOxipJDR836JSsLSrsRCRLRbo6Prygr6GSsr9pKUEEsNzu8U R5SO6V1K7Cf43EPBdNJBT94TYywgQTDeWTCdX3eAWKjPDLD0RODABMwQTHvF55yc JrWcJtqRr7vyorKe/5NyYxWbpmOJhLp9kCPfvA7Mr34H8PiNeisY3QkEbB8bqCXm snc2X4XAPbcjhykZXi4303tBsRzGl4vhsPW/znFlSUejwcA0/PjQnCW9HOf/Icg= =/maD -----END PGP SIGNATURE----- From dpal at redhat.com Sun Aug 10 04:31:09 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 10 Aug 2014 00:31:09 -0400 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: References: <53E3B5C8.6090208@sesda3.com> <53E531B0.8030300@redhat.com> Message-ID: <53E6F58D.5090700@redhat.com> On 08/08/2014 04:26 PM, Chris Whittle wrote: > > Hey Dimitri, What do you mean? Both of them gave me the same answer > and it worked. > Right, now you have the knowledge which is burred in a mail thread and would be hard to find for others that might want to follow your steps. I was hoping you would find some time to summarize your setup and experience and share with others via a HOWTO page on the FreeIPA site [1]. [1] http://www.freeipa.org/page/HowTos Thanks Dmitri > On Aug 8, 2014 3:25 PM, "Dmitri Pal" > wrote: > > On 08/07/2014 02:21 PM, Chris Whittle wrote: >> Thanks guys that works! > > > And what about HOWTO? ;-) > > >> >> >> On Thu, Aug 7, 2014 at 12:22 PM, Lucas Yamanishi >> > wrote: >> >> On 08/07/2014 12:18 PM, Chris Whittle wrote: >> >>> I'm currently working on a trial with OKTA and have >>> installed their server agent with no issues. Now I'm trying >>> to map FreeIPA attributes with OKTA's >>> >>> I'm getting no entries found, which leads me to think I'm >>> missing something >>> Inline image 1 >>> Inline image 2 >>> Inline image 3 >>> Thanks! >>> >>> >> The objectClass values look incorrect. Try |posixAccount| and >> |posixGroup| for users and groups. Roles are |groupOfNames|, >> but that?s a little less specific and will match non-role >> entries without a search base. >> >> You can easily look up raw entries to check your mappings >> with commands like these (the ?all and ?raw options are >> available for all *-show commands, afaik): >> >> |ipa user-show --all --raw $USER_NAME >> ipa group-show --all --raw $GROUP >> ipa role-show --all --raw $ROLE >> | >> >> Or pure ldaputils: >> >> | ldapsearch -LLL -YGSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' 'uid=$USER_NAME' >> | >> >> ? >> >> -- >> ----- >> *question everything*learn something*answer nothing* >> ------------ >> Lucas Yamanishi >> ------------------ >> Systems Administrator, ADNET Systems, Inc. >> NASA Space and Earth Science Data Analysis (606.9) >> 7515 Mission Drive, Suite A100 >> Lanham, MD 20706 *301-352-4646 * 0xD354B2CB >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 89508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 88448 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 103249 bytes Desc: not available URL: From dpal at redhat.com Sun Aug 10 04:32:32 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 10 Aug 2014 00:32:32 -0400 Subject: [Freeipa-users] Adding cross realm trust principals In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E712B4F@001FSN2MPN1-045.001f.mgd2.msft.net> References: <53CCC096.6080200@kit.edu> <20140721073037.GA13866@redhat.com> <53CCC822.2050309@redhat.com> <20140721081053.GB13866@redhat.com> <53E52EE8.30103@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E712B4F@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <53E6F5E0.8080600@redhat.com> On 08/08/2014 04:13 PM, Nordgren, Bryce L -FS wrote: >>>> Let me elaborate. We haven't had time to work on this but it would be >>>> really valuable if you could experiment with it a little bit. >>>> >>>> Simo, Alexander, could you propose some dirty tricks to try? >>> The thread mentioned above has all needed information already. >> Should we turn it into a HOWTO page then? > Yes, I would appreciate that. > > > > Any volunteers? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Sun Aug 10 04:36:23 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 10 Aug 2014 00:36:23 -0400 Subject: [Freeipa-users] FreeIPA 4.0.0 and CentOS release 6.5 In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E6FB68E@001FSN2MPN1-044.001f.mgd2.msft.net> References: <53D1330B.60007@redhat.com> <82E7C9A01FD0764CACDD35D10F5DFB6E6FB68E@001FSN2MPN1-044.001f.mgd2.msft.net> Message-ID: <53E6F6C7.8050808@redhat.com> On 07/24/2014 01:04 PM, Nordgren, Bryce L -FS wrote: > One of our larger users was in a similar situation a few years ago and > ended up running Fedora until RHEL caught up and then migrating the servers. > > I'm running it on F20 because it seemed like the dependencies would make running it on CentOS 7 a pile of pain I didn't need. I do think "RHEL catching up" will probably be a 3-4 year proposition (i.e., RHEL 8), so the ability to run FreeIPA 4.0.0 is likely to be a moot point by then. Or are you thinking that it might be part of 7.1? We are indeed working into this direction so expectations that it will be in RHEL in 3-4 years are negatively exaggerated. > > Bryce > > > > > > 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. > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Sun Aug 10 04:40:49 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 10 Aug 2014 00:40:49 -0400 Subject: [Freeipa-users] Adding user created in IPA to end machine group In-Reply-To: References: Message-ID: <53E6F7D1.70902@redhat.com> On 07/25/2014 12:45 AM, Sanju A wrote: > Dear All, > > Centralized authentication is working fine and we have a requirement > to give privilege to users for configuring printer in their machines. > For local users, they will get the privilege by adding them to the > local printer group (lp or lpadmin group). > > Is there any way to add the user to the end machine printer group. You can't add central users to local groups. I am not familiar with printer configuration policies. Which systems are the clients? RHEL? Fedora? CentOS? In all these cases I suspect this would be done via policy kit policies so may be the way to go is to update policy to point to user's private group. I smell RFE here but probably for SSSD rather than IPA. > > Regards > Sanju Abraham > > =====-----=====-----===== > Notice: The information contained in this e-mail > message and/or attachments to it may contain > confidential or privileged information. If you are > not the intended recipient, any dissemination, use, > review, distribution, printing or copying of the > information contained in this e-mail message > and/or attachments to it are strictly prohibited. If > you have received this communication in error, > please notify us by reply e-mail or telephone and > immediately and permanently delete the message > and any attachments. Thank you > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Aug 10 05:09:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 10 Aug 2014 01:09:53 -0400 Subject: [Freeipa-users] User auth for Samba 3 file server against IPA 3.0.0 In-Reply-To: References: <53C6FE58.6000503@redhat.com> Message-ID: <53E6FEA1.60107@redhat.com> On 07/21/2014 10:15 AM, dbischof at hrz.uni-kassel.de wrote: > Dmitri, > > thanks for your answer. > > On Wed, 16 Jul 2014, Dmitri Pal wrote: > >> On 07/16/2014 07:16 AM, dbischof at hrz.uni-kassel.de wrote: >>> I have IPA running on a CentOS 6 server. This server also acts as >>> NFS- and Samba server. My Linux clients (openSUSE 13.1) work fine >>> (NFS, automount, user auth for ssh and display manager). >>> >>> Since I also have some Windows users, I want them to be able to >>> mount their homes via Samba using their IPA password. Just that, no >>> AD or other fancy stuff. >> >> Support of Windows users is still where it was. Code might have >> changed so the solution might not apply any more cleanly. Our general >> vision is that windows users belong to Windows and have to be either >> in AD or in Samba4. As soon as Samba 4 supports cross forest trusts >> we will make it supported. Then we will be able to support cases like >> you describe. >> >> Also right now Samba FS as a member of IPA domain does not work well. >> It should work better with SSSD 1.12.1 and IPA 4.1 when we make sure >> that all parts are in place but that would still have some problems >> when one has to come from windows client as there is no SSSD >> equivalent for windows clients. >> >> Bottom line: no, there is no better info, sorry. > > Bummer. Just to make sure: I don't want my Windows users to be able to > log on to their systems using IPA auth, they all have local accounts. > I just want them to be able to manually mount their home shares. Sorry for a delayed response, I am slowly catching up on these threads. Mounting a share requires authentication with the account that Samba FS server knows about. Samba FS server until now could have been joined to AD only. Samba 4 DC can be used as an alternative of AD. But in both cases Samba FS yet can't be a member of the IPA domain. We are working on it. So once it is done you might be able to manually mount shares using the accounts managed by IPA. It is a question of couple months really so may be you can wait for this functionality to emerge and try it? Thanks Dmitri > > Since I'm still more or less testing stuff, I wonder where to go from > here. Before biting the bullet having separate Samba accounts: Would > it help to switch to Samba 4? This post > > https://www.redhat.com/archives/freeipa-users/2013-April/msg00248.html > > suggests that it's possible. Somebody out there did it successfully? > >>> [1] http://techslaves.org/2011/08/24/freeipa-and-samba-3-integration/ > > > Mit freundlichen Gruessen/With best regards, > > --Daniel. > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jreg2k at gmail.com Sun Aug 10 11:58:51 2014 From: jreg2k at gmail.com (James James) Date: Sun, 10 Aug 2014 13:58:51 +0200 Subject: [Freeipa-users] WebUI krbprincipal expiration calendar widegt Message-ID: Hello, Is there a way to patch my ipa .3.0.0 with this patch: https://www.mail-archive.com/freeipa-devel at redhat.com/msg20528.html ? The DateTime data type will be very useful ! Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Sun Aug 10 13:03:07 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Sun, 10 Aug 2014 08:03:07 -0500 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: <53E6F58D.5090700@redhat.com> References: <53E3B5C8.6090208@sesda3.com> <53E531B0.8030300@redhat.com> <53E6F58D.5090700@redhat.com> Message-ID: Sure! I will try to get it out there tonight. On Aug 9, 2014 11:31 PM, "Dmitri Pal" wrote: > On 08/08/2014 04:26 PM, Chris Whittle wrote: > > Hey Dimitri, What do you mean? Both of them gave me the same answer and > it worked. > > > Right, now you have the knowledge which is burred in a mail thread and > would be hard to find for others that might want to follow your steps. > I was hoping you would find some time to summarize your setup and > experience and share with others via a HOWTO page on the FreeIPA site [1]. > > [1] http://www.freeipa.org/page/HowTos > > Thanks > Dmitri > > On Aug 8, 2014 3:25 PM, "Dmitri Pal" wrote: > >> On 08/07/2014 02:21 PM, Chris Whittle wrote: >> >> Thanks guys that works! >> >> >> >> And what about HOWTO? ;-) >> >> >> >> >> On Thu, Aug 7, 2014 at 12:22 PM, Lucas Yamanishi >> wrote: >> >>> On 08/07/2014 12:18 PM, Chris Whittle wrote: >>> >>> I'm currently working on a trial with OKTA and have installed their >>> server agent with no issues. Now I'm trying to map FreeIPA attributes with >>> OKTA's >>> >>> I'm getting no entries found, which leads me to think I'm missing >>> something >>> [image: Inline image 1] >>> [image: Inline image 2] >>> [image: Inline image 3] >>> Thanks! >>> >>> >>> The objectClass values look incorrect. Try posixAccount and posixGroup >>> for users and groups. Roles are groupOfNames, but that?s a little less >>> specific and will match non-role entries without a search base. >>> >>> You can easily look up raw entries to check your mappings with commands >>> like these (the ?all and ?raw options are available for all *-show >>> commands, afaik): >>> >>> ipa user-show --all --raw $USER_NAME >>> ipa group-show --all --raw $GROUP >>> ipa role-show --all --raw $ROLE >>> >>> Or pure ldaputils: >>> >>> ldapsearch -LLL -YGSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' 'uid=$USER_NAME' >>> >>> ? >>> >>> -- >>> ----- >>> *question everything*learn something*answer nothing* >>> ------------ >>> Lucas Yamanishi >>> ------------------ >>> Systems Administrator, ADNET Systems, Inc. >>> NASA Space and Earth Science Data Analysis (606.9) >>> 7515 Mission Drive, Suite A100 >>> Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 103249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 89508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 88448 bytes Desc: not available URL: From jhrozek at redhat.com Sun Aug 10 15:33:03 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 10 Aug 2014 17:33:03 +0200 Subject: [Freeipa-users] Adding user created in IPA to end machine group In-Reply-To: <53E6F7D1.70902@redhat.com> References: <53E6F7D1.70902@redhat.com> Message-ID: <20140810153303.GL4845@hendrix.redhat.com> On Sun, Aug 10, 2014 at 12:40:49AM -0400, Dmitri Pal wrote: > On 07/25/2014 12:45 AM, Sanju A wrote: > >Dear All, > > > >Centralized authentication is working fine and we have a requirement to > >give privilege to users for configuring printer in their machines. For > >local users, they will get the privilege by adding them to the local > >printer group (lp or lpadmin group). > > > >Is there any way to add the user to the end machine printer group. > You can't add central users to local groups. > I am not familiar with printer configuration policies. > Which systems are the clients? RHEL? Fedora? CentOS? > In all these cases I suspect this would be done via policy kit policies so > may be the way to go is to update policy to point to user's private group. > > I smell RFE here but probably for SSSD rather than IPA. I suspect this should work already. My LDAP user (fetched via SSSD) is a happy member of several local groups such as mock. Just add him with the usual shadow-utils tools: usermod -a -G $groupname $username What is problematic is the other way around, that is, add a local user to an LDAP group. Currently we can only do this for the RFC2307 schema, not for RFC2307bis or its variants. From abokovoy at redhat.com Mon Aug 11 14:18:03 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 Aug 2014 17:18:03 +0300 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <53E6DDEC.10105@gmail.com> References: <53E6DDEC.10105@gmail.com> Message-ID: <20140811141803.GA19977@redhat.com> On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >It would seem to be prudent to set the minssf setting for 389 to 56, >however I am wondering why this isn't done by default, and if there is >any reason why I shouldn't do it? Anonymous connection to LDAP wouldn't work. I think we use it for rootdse access when enrolling IPA clients where we don't yet have a CA certificate. I may be wrong, though. -- / Alexander Bokovoy From jhrozek at redhat.com Mon Aug 11 14:24:34 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 11 Aug 2014 16:24:34 +0200 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <20140811141803.GA19977@redhat.com> References: <53E6DDEC.10105@gmail.com> <20140811141803.GA19977@redhat.com> Message-ID: <20140811142434.GB9920@hendrix.redhat.com> On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy wrote: > On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA256 > > > >It would seem to be prudent to set the minssf setting for 389 to 56, > >however I am wondering why this isn't done by default, and if there is > >any reason why I shouldn't do it? > Anonymous connection to LDAP wouldn't work. I think we use it for > rootdse access when enrolling IPA clients where we don't yet have a CA > certificate. > > I may be wrong, though. Also old (RHEL-5) SSSD versions rely on anonymous access to be able to retrieve rootDSE. Newer (RHEL-6.3+) clients are able to re-try fetching rootDSE once the authenticated connection is established. From mkosek at redhat.com Mon Aug 11 15:05:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Aug 2014 17:05:01 +0200 Subject: [Freeipa-users] WebUI krbprincipal expiration calendar widegt In-Reply-To: References: Message-ID: <53E8DB9D.7000903@redhat.com> On 08/10/2014 01:58 PM, James James wrote: > Hello, > > > Is there a way to patch my ipa .3.0.0 with this patch: > https://www.mail-archive.com/freeipa-devel at redhat.com/msg20528.html ? > > The DateTime data type will be very useful ! > > Regards It would be quite difficult, if not only because of the API versioning problem we have with parallel branches of FreeIPA, like RHEL-6.x/CentOS-6.x is (judging based on your version). There is an upstream ticket filed: https://fedorahosted.org/freeipa/ticket/4427 But I do not think it would help in your case. Especially as this is just a convenience fix, the best advise I can give is either to a) Hack this around in your IPA codebase, making sure that the capability API version is correct b) Live with old string variant c) Upgrade to newer IPA, like 3.3 in RHEL-7.0 or 4.0 in Fedora 20! :-) Martin From mkosek at redhat.com Mon Aug 11 15:08:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Aug 2014 17:08:42 +0200 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <20140811142434.GB9920@hendrix.redhat.com> References: <53E6DDEC.10105@gmail.com> <20140811141803.GA19977@redhat.com> <20140811142434.GB9920@hendrix.redhat.com> Message-ID: <53E8DC7A.6090102@redhat.com> On 08/11/2014 04:24 PM, Jakub Hrozek wrote: > On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy wrote: >> On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> It would seem to be prudent to set the minssf setting for 389 to 56, >>> however I am wondering why this isn't done by default, and if there is >>> any reason why I shouldn't do it? >> Anonymous connection to LDAP wouldn't work. I think we use it for >> rootdse access when enrolling IPA clients where we don't yet have a CA >> certificate. >> >> I may be wrong, though. > > Also old (RHEL-5) SSSD versions rely on anonymous access to be able to > retrieve rootDSE. Newer (RHEL-6.3+) clients are able to re-try fetching > rootDSE once the authenticated connection is established. > Also, older FreeIPA clients were not able to join those severs due to bug in ipa-client-install: https://fedorahosted.org/freeipa/ticket/4459 This will be fixed in FreeIPA 4.0.2. Note that this only affects if you are changing MinSSF for whole DS by nsslapd-minssf. Martin From mlasevich at gmail.com Mon Aug 11 18:35:58 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Mon, 11 Aug 2014 11:35:58 -0700 Subject: [Freeipa-users] Using Native OTP for auth from specific hosts Message-ID: Ok, I am trying to figure out how to use native OTP capabilities in FreeIPA4 to authenticate users but I am not finding enough docs on how to USE OTP. Specifically I would like to force OTP authentication on specific servers while allowing password auth in other cases. As I understand authentication, you can either select OTP or password or both authentications, but if you select both, the user can use password instead of otp from ANY server. Is there any way to block password auth based on source (HBAC rules?) So far the only way I can figure out is to create a second account, which is less than optimal. Thanks, -M -------------- next part -------------- An HTML attachment was scrubbed... URL: From shownde at slu.edu Mon Aug 11 18:43:07 2014 From: shownde at slu.edu (Daniel Shown) Date: Mon, 11 Aug 2014 13:43:07 -0500 Subject: [Freeipa-users] mapping AD trust users to FreeIPA users for access to NFS w/ ACLs Message-ID: I?m trying to get a client to respect an NFS4 ACL for a directory. I?ve got users in FreeIPA that match a subset of users in AD. The NFS server is a FreeBSD box that I?ve got config?ed to use FreeIPA as an LDAP service in nsswitch for providing uids. I use setfacl there with just the uid. The FreeIPA client with the NFS mount (not kerberized) is an Ubuntu 14.04 bound to a FreeIPA 3.0 server (running on CentOS 6.5). I?ve got the FreeIPA 3.0 server configured with a trust with an AD domain. My krb5.conf has dns_lookup_kdc = true and auth_to_local = RULE:[1:$1@ $0](^.*@AD.DOMAIN$)s/@AD.DOMAIN/@ad.domain/ and my sssd.conf has the standard subdomains_provider = ipa and services = ..., pac along with a full_name_format = %1$s to strip the realm name off when displaying the username. From what I understand about NFS ACLs, they should respect the uid reported, which matches, and ignore uidnumbers (which don?t match). From the FreeIPA client I can authenticate as an AD user, but I still don?t have access to the NFS directory with ACLs that should allow me to read. When I do an getfacl on the NFS server I get just the uid, but when I do nfs4_getfacl on the FreeIPA/NFS client I get uid at ipa.realm (and no access to the directory). Am I missing something? Best! =================================== Daniel Shown, Linux Systems Administrator Advanced Technology Group Information Technology Services at Saint Louis University . 314-977-2583 =================================== ?The aim of education is the knowledge, not of facts, but of values.? ? William S. Burroughs ?I?m supposed to be a scientific person but I use intuition more than logic in making basic decisions.? ? Seymour R. Cray ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Aug 11 18:49:23 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 Aug 2014 21:49:23 +0300 Subject: [Freeipa-users] Using Native OTP for auth from specific hosts In-Reply-To: References: Message-ID: <20140811184923.GB4748@redhat.com> On Mon, 11 Aug 2014, Michael Lasevich wrote: >Ok, I am trying to figure out how to use native OTP capabilities in >FreeIPA4 to authenticate users but I am not finding enough docs on how to >USE OTP. > >Specifically I would like to force OTP authentication on specific servers >while allowing password auth in other cases. As I understand >authentication, you can either select OTP or password or both >authentications, but if you select both, the user can use password instead >of otp from ANY server. That is correct. >Is there any way to block password auth based on source (HBAC rules?) So >far the only way I can figure out is to create a second account, which is >less than optimal. No, this functionality is not supported. One particular issue is that we'll need to authenticate before applying HBAC rules, not after, so some other means to validate the request chain are needed. Additionally, Kerberos authentication requires to enter your credentials only when obtaining a ticket granting ticket (TGT) which happens before a client will ask for a ticket to a specific service. Also, renewing the ticket might be possible without original credentials. Perhaps we could add a flag into TGT that would tell how strong were credentials (how many factors were in use) when TGT was obtained and then use it in a policy to see if a ticket to the target service principal could be granted. It worth to file an RFE, anyway. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Aug 11 18:51:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 Aug 2014 21:51:13 +0300 Subject: [Freeipa-users] mapping AD trust users to FreeIPA users for access to NFS w/ ACLs In-Reply-To: References: Message-ID: <20140811185113.GC4748@redhat.com> On Mon, 11 Aug 2014, Daniel Shown wrote: >I?m trying to get a client to respect an NFS4 ACL for a directory. I?ve got >users in FreeIPA that match a subset of users in AD. The NFS server is a >FreeBSD box that I?ve got config?ed to use FreeIPA as an LDAP service in >nsswitch for providing uids. I use setfacl there with just the uid. The >FreeIPA client with the NFS mount (not kerberized) is an Ubuntu 14.04 bound >to a FreeIPA 3.0 server (running on CentOS 6.5). I?ve got the FreeIPA 3.0 >server configured with a trust with an AD domain. My krb5.conf has >dns_lookup_kdc >= true and auth_to_local = RULE:[1:$1@ >$0](^.*@AD.DOMAIN$)s/@AD.DOMAIN/@ad.domain/ and my sssd.conf has the >standard subdomains_provider = ipa and services = ..., pac along with >a full_name_format >= %1$s to strip the realm name off when displaying the username. From what >I understand about NFS ACLs, they should respect the uid reported, which >matches, and ignore uidnumbers (which don?t match). From the FreeIPA client >I can authenticate as an AD user, but I still don?t have access to the NFS >directory with ACLs that should allow me to read. When I do an getfacl on >the NFS server I get just the uid, but when I do nfs4_getfacl on the >FreeIPA/NFS client I get uid at ipa.realm (and no access to the directory). > >Am I missing something? There is a bug in NFS ID mapping code that prevents this use case from working. It should be fixed in recent libnsfidmap releases but I'm not sure it is already available in CentOS 6.5. -- / Alexander Bokovoy From shownde at slu.edu Mon Aug 11 18:54:39 2014 From: shownde at slu.edu (Daniel Shown) Date: Mon, 11 Aug 2014 13:54:39 -0500 Subject: [Freeipa-users] mapping AD trust users to FreeIPA users for access to NFS w/ ACLs In-Reply-To: <20140811185113.GC4748@redhat.com> References: <20140811185113.GC4748@redhat.com> Message-ID: grumble grumble. Do you know a bug ID or something similar i can search on? FWIW, FreeIPA server is CentOS 6.5, but the client is Ubuntu 14. Hopefully that makes a fix easier. :/ d:s =================================== *Daniel Shown,* Linux Systems Administrator Advanced Technology Group Information Technology Services at Saint Louis University . 314-977-2583 =================================== "The aim of education is the knowledge, not of facts, but of values." ? William S. Burroughs "I?m supposed to be a scientific person but I use intuition more than logic in making basic decisions." ? Seymour R. Cray On Mon, Aug 11, 2014 at 1:51 PM, Alexander Bokovoy wrote: > On Mon, 11 Aug 2014, Daniel Shown wrote: > >> I?m trying to get a client to respect an NFS4 ACL for a directory. I?ve >> got >> users in FreeIPA that match a subset of users in AD. The NFS server is a >> FreeBSD box that I?ve got config?ed to use FreeIPA as an LDAP service in >> nsswitch for providing uids. I use setfacl there with just the uid. The >> FreeIPA client with the NFS mount (not kerberized) is an Ubuntu 14.04 >> bound >> to a FreeIPA 3.0 server (running on CentOS 6.5). I?ve got the FreeIPA 3.0 >> server configured with a trust with an AD domain. My krb5.conf has >> dns_lookup_kdc >> = true and auth_to_local = RULE:[1:$1@ >> $0](^.*@AD.DOMAIN$)s/@AD.DOMAIN/@ad.domain/ and my sssd.conf has the >> standard subdomains_provider = ipa and services = ..., pac along with >> a full_name_format >> = %1$s to strip the realm name off when displaying the username. From what >> I understand about NFS ACLs, they should respect the uid reported, which >> matches, and ignore uidnumbers (which don?t match). From the FreeIPA >> client >> I can authenticate as an AD user, but I still don?t have access to the NFS >> directory with ACLs that should allow me to read. When I do an getfacl on >> the NFS server I get just the uid, but when I do nfs4_getfacl on the >> FreeIPA/NFS client I get uid at ipa.realm (and no access to the directory). >> >> Am I missing something? >> > There is a bug in NFS ID mapping code that prevents this use case from > working. It should be fixed in recent libnsfidmap releases but I'm not > sure it is already available in CentOS 6.5. > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Aug 11 19:04:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 Aug 2014 22:04:37 +0300 Subject: [Freeipa-users] mapping AD trust users to FreeIPA users for access to NFS w/ ACLs In-Reply-To: References: <20140811185113.GC4748@redhat.com> Message-ID: <20140811190437.GD4748@redhat.com> On Mon, 11 Aug 2014, Daniel Shown wrote: >grumble grumble. > >Do you know a bug ID or something similar i can search on? FWIW, FreeIPA >server is CentOS 6.5, but the client is Ubuntu 14. Hopefully that makes a >fix easier. :/ Here is the thread upstream, including the patch: http://thread.gmane.org/gmane.linux.nfs/62014 I cannot find the bug on bugzilla.redhat.com, though, perhaps it is closed already. -- / Alexander Bokovoy From mlasevich at gmail.com Mon Aug 11 19:17:25 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Mon, 11 Aug 2014 12:17:25 -0700 Subject: [Freeipa-users] Using Native OTP for auth from specific hosts In-Reply-To: <20140811184923.GB4748@redhat.com> References: <20140811184923.GB4748@redhat.com> Message-ID: Thanks for quick response, further questions inline. On Mon, Aug 11, 2014 at 11:49 AM, Alexander Bokovoy wrote: > On Mon, 11 Aug 2014, Michael Lasevich wrote: > >> Ok, I am trying to figure out how to use native OTP capabilities in >> FreeIPA4 to authenticate users but I am not finding enough docs on how to >> USE OTP. >> >> Specifically I would like to force OTP authentication on specific servers >> while allowing password auth in other cases. As I understand >> authentication, you can either select OTP or password or both >> authentications, but if you select both, the user can use password instead >> of otp from ANY server. >> > That is correct. > > So, it is NOT intended to use for border-style 2FA authentication (i.e. VPN) - which seems may be a common use case for 2FA? > > Is there any way to block password auth based on source (HBAC rules?) So >> far the only way I can figure out is to create a second account, which is >> less than optimal. >> > No, this functionality is not supported. One particular issue is that > we'll need to authenticate before applying HBAC rules, not after, so > some other means to validate the request chain are needed. > > Additionally, Kerberos authentication requires to enter your credentials > only when obtaining a ticket granting ticket (TGT) which happens before > a client will ask for a ticket to a specific service. Also, renewing the > ticket might be possible without original credentials. Perhaps we could > add a flag into TGT that would tell how strong were credentials (how > many factors were in use) when TGT was obtained and then use it in a > policy to see if a ticket to the target service principal could be > granted. > > I think I understand - HBAC has no way to know how you authenticated - so you cannot make rules based on that? Is there a way to test OTP token auth while bypassing kerberos? For example, you can validate user's password via a LDAP login, - can you do a similar validation of OTP token directly? Thanks, -M -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbischof at hrz.uni-kassel.de Mon Aug 11 19:29:01 2014 From: dbischof at hrz.uni-kassel.de (dbischof at hrz.uni-kassel.de) Date: Mon, 11 Aug 2014 21:29:01 +0200 (CEST) Subject: [Freeipa-users] User auth for Samba 3 file server against IPA 3.0.0 In-Reply-To: <53E6FEA1.60107@redhat.com> References: <53C6FE58.6000503@redhat.com> <53E6FEA1.60107@redhat.com> Message-ID: Hi, On Sun, 10 Aug 2014, Dmitri Pal wrote: > On 07/21/2014 10:15 AM, dbischof at hrz.uni-kassel.de wrote: >> On Wed, 16 Jul 2014, Dmitri Pal wrote: >>> On 07/16/2014 07:16 AM, dbischof at hrz.uni-kassel.de wrote: >>>> I have IPA running on a CentOS 6 server. This server also acts as >>>> NFS- and Samba server. My Linux clients (openSUSE 13.1) work fine >>>> (NFS, automount, user auth for ssh and display manager). >>>> >>>> Since I also have some Windows users, I want them to be able to mount >>>> their homes via Samba using their IPA password. Just that, no AD or >>>> other fancy stuff. >>> >>> Support of Windows users is still where it was. Code might have >>> changed so the solution might not apply any more cleanly. Our general >>> vision is that windows users belong to Windows and have to be either >>> in AD or in Samba4. As soon as Samba 4 supports cross forest trusts we >>> will make it supported. Then we will be able to support cases like you >>> describe. >>> >>> Also right now Samba FS as a member of IPA domain does not work well. >>> It should work better with SSSD 1.12.1 and IPA 4.1 when we make sure >>> that all parts are in place but that would still have some problems >>> when one has to come from windows client as there is no SSSD >>> equivalent for windows clients. >>> >>> Bottom line: no, there is no better info, sorry. >> >> Bummer. Just to make sure: I don't want my Windows users to be able to >> log on to their systems using IPA auth, they all have local accounts. I >> just want them to be able to manually mount their home shares. > > Sorry for a delayed response, I am slowly catching up on these threads. > Mounting a share requires authentication with the account that Samba FS > server knows about. Samba FS server until now could have been joined to > AD only. Samba 4 DC can be used as an alternative of AD. But in both > cases Samba FS yet can't be a member of the IPA domain. We are working > on it. So once it is done you might be able to manually mount shares > using the accounts managed by IPA. It is a question of couple months > really so may be you can wait for this functionality to emerge and try > it? will that feature (Samba shares w/ IPA accounts) be available for IPA 3.0 as in RHEL/CentOS6 or for IPA4 only? Waiting another couple of months would be perfectly ok for me, if I could then just update the IPA package and do some additional configuration to make it work. I'd happily take part in testing the feature in advance, too. Mit freundlichen Gruessen/With best regards, --Daniel. From abokovoy at redhat.com Mon Aug 11 19:30:17 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 Aug 2014 22:30:17 +0300 Subject: [Freeipa-users] Using Native OTP for auth from specific hosts In-Reply-To: References: <20140811184923.GB4748@redhat.com> Message-ID: <20140811193017.GE4748@redhat.com> On Mon, 11 Aug 2014, Michael Lasevich wrote: >So, it is NOT intended to use for border-style 2FA authentication (i.e. >VPN) - which seems may be a common use case for 2FA? You can always supplement authentication check with some host-specific information at the VPN concentrator. We don't have ready to use solution here but it is definitely possible to use such scheme against FreeIPA 2FA. >> Is there any way to block password auth based on source (HBAC rules?) So >>> far the only way I can figure out is to create a second account, which is >>> less than optimal. >>> >> No, this functionality is not supported. One particular issue is that >> we'll need to authenticate before applying HBAC rules, not after, so >> some other means to validate the request chain are needed. >> > >> Additionally, Kerberos authentication requires to enter your credentials >> only when obtaining a ticket granting ticket (TGT) which happens before >> a client will ask for a ticket to a specific service. Also, renewing the >> ticket might be possible without original credentials. Perhaps we could >> add a flag into TGT that would tell how strong were credentials (how >> many factors were in use) when TGT was obtained and then use it in a >> policy to see if a ticket to the target service principal could be >> granted. >> >> >I think I understand - HBAC has no way to know how you authenticated - so >you cannot make rules based on that? Yes, these are different stages in the PAM stack and unless all modules are cooperating you have no means to get them in accord. >Is there a way to test OTP token auth while bypassing kerberos? For >example, you can validate user's password via a LDAP login, - can you do a >similar validation of OTP token directly? Just try to bind to LDAP, it will work the same way regardless whether you are using a password or 2FA -- if only 2FA is enabled, only 2FA login will be accepted over LDAP bind. -- / Alexander Bokovoy From shownde at slu.edu Mon Aug 11 19:39:22 2014 From: shownde at slu.edu (Daniel Shown) Date: Mon, 11 Aug 2014 14:39:22 -0500 Subject: [Freeipa-users] mapping AD trust users to FreeIPA users for access to NFS w/ ACLs In-Reply-To: <20140811190437.GD4748@redhat.com> References: <20140811185113.GC4748@redhat.com> <20140811190437.GD4748@redhat.com> Message-ID: Hmm... yeah, I've mucked with idmap.conf and still no happiness. d:s =================================== *Daniel Shown,* Linux Systems Administrator Advanced Technology Group Information Technology Services at Saint Louis University . 314-977-2583 =================================== "The aim of education is the knowledge, not of facts, but of values." ? William S. Burroughs "I?m supposed to be a scientific person but I use intuition more than logic in making basic decisions." ? Seymour R. Cray On Mon, Aug 11, 2014 at 2:04 PM, Alexander Bokovoy wrote: > On Mon, 11 Aug 2014, Daniel Shown wrote: > >> grumble grumble. >> >> Do you know a bug ID or something similar i can search on? FWIW, FreeIPA >> server is CentOS 6.5, but the client is Ubuntu 14. Hopefully that makes a >> fix easier. :/ >> > Here is the thread upstream, including the patch: > http://thread.gmane.org/gmane.linux.nfs/62014 > > I cannot find the bug on bugzilla.redhat.com, though, perhaps it is > closed already. > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Aug 11 19:42:39 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 11 Aug 2014 21:42:39 +0200 Subject: [Freeipa-users] mapping AD trust users to FreeIPA users for access to NFS w/ ACLs In-Reply-To: <20140811190437.GD4748@redhat.com> References: <20140811185113.GC4748@redhat.com> <20140811190437.GD4748@redhat.com> Message-ID: <20140811194239.GI9920@hendrix.redhat.com> On Mon, Aug 11, 2014 at 10:04:37PM +0300, Alexander Bokovoy wrote: > On Mon, 11 Aug 2014, Daniel Shown wrote: > >grumble grumble. > > > >Do you know a bug ID or something similar i can search on? FWIW, FreeIPA > >server is CentOS 6.5, but the client is Ubuntu 14. Hopefully that makes a > >fix easier. :/ > Here is the thread upstream, including the patch: > http://thread.gmane.org/gmane.linux.nfs/62014 > > I cannot find the bug on bugzilla.redhat.com, though, perhaps it is > closed already. I think you meant this one: https://bugzilla.redhat.com/show_bug.cgi?id=1066153 However, the bugzilla is marked as private, so it's not accessible outside redhat.com What I think is very safe to say is the fix is planned for 6.6 and appears to be on track. From shownde at slu.edu Mon Aug 11 19:45:00 2014 From: shownde at slu.edu (Daniel Shown) Date: Mon, 11 Aug 2014 14:45:00 -0500 Subject: [Freeipa-users] about AD trusts and passthrough authentication Message-ID: I'm fairly new to FreeIPA, so can someone give me a sanity check? Should I be able to map AD users in an AD trust to to corresponding FreeIPA users? i.e. Users can auth with their AD credentials and get a FreeIPA uidnumber, gidnumber, home, etc.? Also, if that's not possible, has anyone tried using pass through authentication from FreeIPA to an AD domain? http://directory.fedoraproject.org/wiki/Howto:PAM_Pass_Through Best! =================================== *Daniel Shown,* Linux Systems Administrator Advanced Technology Group Information Technology Services at Saint Louis University . 314-977-2583 =================================== "The aim of education is the knowledge, not of facts, but of values." ? William S. Burroughs "I?m supposed to be a scientific person but I use intuition more than logic in making basic decisions." ? Seymour R. Cray -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at gmail.com Mon Aug 11 19:49:04 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Mon, 11 Aug 2014 12:49:04 -0700 Subject: [Freeipa-users] Using Native OTP for auth from specific hosts In-Reply-To: <20140811193017.GE4748@redhat.com> References: <20140811184923.GB4748@redhat.com> <20140811193017.GE4748@redhat.com> Message-ID: On Mon, Aug 11, 2014 at 12:30 PM, Alexander Bokovoy wrote: > On Mon, 11 Aug 2014, Michael Lasevich wrote: > >> So, it is NOT intended to use for border-style 2FA authentication (i.e. >> VPN) - which seems may be a common use case for 2FA? >> > You can always supplement authentication check with some host-specific > information at the VPN concentrator. We don't have ready to use solution > here but it is definitely possible to use such scheme against FreeIPA > 2FA. > > Sorry, I am not following. What do you mean by "host-specific information"? If system has no way to detect how many factors were involved in authentication, how would I be able to guarantee that only 2FA is allowed via this box? I suppose this can work: I can write code that will: 1 - detects if there are OTP numbers at the end of the password 2 - authenticates using full 2FA 3 - authenticates using just password without 2FA And then authenticate only if all 3 conditions are satisfied. Seems a bit hacky, but that is the only way I can think that may work. Alternative is to set up 2 users for each actual user, one for border and one for internal auth. Force 2fa on border user. Only allow border users on border boxes. Am I missing anything? -M > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreg2k at gmail.com Mon Aug 11 19:59:20 2014 From: jreg2k at gmail.com (James James) Date: Mon, 11 Aug 2014 21:59:20 +0200 Subject: [Freeipa-users] WebUI krbprincipal expiration calendar widegt In-Reply-To: <53E8DB9D.7000903@redhat.com> References: <53E8DB9D.7000903@redhat.com> Message-ID: Thanks a lot for your answer. I will switch to RHEL 7 to use 3.3 .. Best regards. James 2014-08-11 17:05 GMT+02:00 Martin Kosek : > On 08/10/2014 01:58 PM, James James wrote: > > Hello, > > > > > > Is there a way to patch my ipa .3.0.0 with this patch: > > https://www.mail-archive.com/freeipa-devel at redhat.com/msg20528.html ? > > > > The DateTime data type will be very useful ! > > > > Regards > > It would be quite difficult, if not only because of the API versioning > problem > we have with parallel branches of FreeIPA, like RHEL-6.x/CentOS-6.x is > (judging > based on your version). > > There is an upstream ticket filed: > https://fedorahosted.org/freeipa/ticket/4427 > > But I do not think it would help in your case. Especially as this is just a > convenience fix, the best advise I can give is either to > a) Hack this around in your IPA codebase, making sure that the capability > API > version is correct > b) Live with old string variant > c) Upgrade to newer IPA, like 3.3 in RHEL-7.0 or 4.0 in Fedora 20! :-) > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Aug 11 20:04:15 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 Aug 2014 23:04:15 +0300 Subject: [Freeipa-users] Using Native OTP for auth from specific hosts In-Reply-To: References: <20140811184923.GB4748@redhat.com> <20140811193017.GE4748@redhat.com> Message-ID: <20140811200415.GF4748@redhat.com> On Mon, 11 Aug 2014, Michael Lasevich wrote: >On Mon, Aug 11, 2014 at 12:30 PM, Alexander Bokovoy >wrote: > >> On Mon, 11 Aug 2014, Michael Lasevich wrote: >> >>> So, it is NOT intended to use for border-style 2FA authentication (i.e. >>> VPN) - which seems may be a common use case for 2FA? >>> >> You can always supplement authentication check with some host-specific >> information at the VPN concentrator. We don't have ready to use solution >> here but it is definitely possible to use such scheme against FreeIPA >> 2FA. >> >> >Sorry, I am not following. What do you mean by "host-specific >information"? If system has no way to detect how many factors were involved >in authentication, how would I be able to guarantee that only 2FA is >allowed via this box? > >I suppose this can work: I can write code that will: > >1 - detects if there are OTP numbers at the end of the password >2 - authenticates using full 2FA >3 - authenticates using just password without 2FA > >And then authenticate only if all 3 conditions are satisfied. Seems a bit >hacky, but that is the only way I can think that may work. 2 and 3 are the same from IPA point of view, just an LDAP bind. Ideally SSSD could handle this as part of a PAM stack by providing PAM feedback that could be used by other modules. There was no request for this functionality before. However, I was mostly thinking that you may have an authentication sequence where past successful auth you would check tokens associated with the user to see if there is a recent update within the same time period on one of tokens. This would work right now, though it is a bit a hack -- a better one than the 2-accounts-per-user. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Aug 11 20:08:11 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 11 Aug 2014 23:08:11 +0300 Subject: [Freeipa-users] about AD trusts and passthrough authentication In-Reply-To: References: Message-ID: <20140811200811.GG4748@redhat.com> On Mon, 11 Aug 2014, Daniel Shown wrote: >I'm fairly new to FreeIPA, so can someone give me a sanity check? Should I >be able to map AD users in an AD trust to to corresponding FreeIPA users? >i.e. Users can auth with their AD credentials and get a FreeIPA uidnumber, >gidnumber, home, etc.? Users from a trusted forest are treated as separate users. They have their own identities and get IDs from either Active Directory (if POSIX compatibility is enabled at AD) or from special ID range allocated for them in IPA. You can include these users (and groups, it doesn't matter what is what) into special type of groups in IPA, called "external" groups. These groups, in turn, can be members of existing POSIX groups from IPA. If done so, your AD users will become members of appropriate POSIX groups from IPA by means of nested membership. These POSIX groups then can be used to apply SUDO or HBAC rules against AD users. -- / Alexander Bokovoy From dpal at redhat.com Mon Aug 11 20:15:49 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Aug 2014 22:15:49 +0200 Subject: [Freeipa-users] Using Native OTP for auth from specific hosts In-Reply-To: <20140811184923.GB4748@redhat.com> References: <20140811184923.GB4748@redhat.com> Message-ID: <53E92475.6020007@redhat.com> On 08/11/2014 08:49 PM, Alexander Bokovoy wrote: > On Mon, 11 Aug 2014, Michael Lasevich wrote: >> Ok, I am trying to figure out how to use native OTP capabilities in >> FreeIPA4 to authenticate users but I am not finding enough docs on >> how to >> USE OTP. >> >> Specifically I would like to force OTP authentication on specific >> servers >> while allowing password auth in other cases. As I understand >> authentication, you can either select OTP or password or both >> authentications, but if you select both, the user can use password >> instead >> of otp from ANY server. > That is correct. > >> Is there any way to block password auth based on source (HBAC rules?) So >> far the only way I can figure out is to create a second account, >> which is >> less than optimal. > No, this functionality is not supported. One particular issue is that > we'll need to authenticate before applying HBAC rules, not after, so > some other means to validate the request chain are needed. > > Additionally, Kerberos authentication requires to enter your credentials > only when obtaining a ticket granting ticket (TGT) which happens before > a client will ask for a ticket to a specific service. Also, renewing the > ticket might be possible without original credentials. Perhaps we could > add a flag into TGT that would tell how strong were credentials (how > many factors were in use) when TGT was obtained and then use it in a > policy to see if a ticket to the target service principal could be > granted. > > It worth to file an RFE, anyway. > We already have these RFEs and they are in plans. They have not been implemented because it required a lot of the upstream Kerberos standards work. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Aug 11 20:33:26 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Aug 2014 22:33:26 +0200 Subject: [Freeipa-users] Using Native OTP for auth from specific hosts In-Reply-To: <20140811200415.GF4748@redhat.com> References: <20140811184923.GB4748@redhat.com> <20140811193017.GE4748@redhat.com> <20140811200415.GF4748@redhat.com> Message-ID: <53E92896.70106@redhat.com> On 08/11/2014 10:04 PM, Alexander Bokovoy wrote: > On Mon, 11 Aug 2014, Michael Lasevich wrote: >> On Mon, Aug 11, 2014 at 12:30 PM, Alexander Bokovoy >> >> wrote: >> >>> On Mon, 11 Aug 2014, Michael Lasevich wrote: >>> >>>> So, it is NOT intended to use for border-style 2FA authentication >>>> (i.e. >>>> VPN) - which seems may be a common use case for 2FA? >>>> >>> You can always supplement authentication check with some host-specific >>> information at the VPN concentrator. We don't have ready to use >>> solution >>> here but it is definitely possible to use such scheme against FreeIPA >>> 2FA. >>> >>> >> Sorry, I am not following. What do you mean by "host-specific >> information"? If system has no way to detect how many factors were >> involved >> in authentication, how would I be able to guarantee that only 2FA is >> allowed via this box? >> >> I suppose this can work: I can write code that will: >> >> 1 - detects if there are OTP numbers at the end of the password >> 2 - authenticates using full 2FA >> 3 - authenticates using just password without 2FA >> >> And then authenticate only if all 3 conditions are satisfied. Seems a >> bit >> hacky, but that is the only way I can think that may work. > 2 and 3 are the same from IPA point of view, just an LDAP bind. > Ideally SSSD could handle this as part of a PAM stack by providing PAM > feedback that could be used by other modules. There was no request for > this functionality before. > > However, I was mostly thinking that you may have an authentication > sequence where past successful auth you would check tokens associated > with the user to see if there is a recent update within the same time > period on one of tokens. This would work right now, though it is a bit a > hack -- a better one than the 2-accounts-per-user. > Here is more info: 1) Right now there is no way to scope the 2FA to different hosts. It is all or nothing. 2) There are plans to be able to differentiate which services would require 2FA and which would allow just a single factor. We might not have filed specific RFEs in IPA because most of the work needs to happen in Kerberos. There are two approaches: a) Allow users authenticate using 2FA or single factor at their discretion but centrally control which services can be accessed with ticket that is acquired with single factor. That would prevent users from accessing the services that require 2FA. b) For smarter services (which do not exist yet and would have be implemented) they would be able to look into the ticket themselves and see the information how ticket was acquired and then make a decision based on that. The place where the information of how the authentication was performed is called CAMMAC - http://k5wiki.kerberos.org/wiki/Projects/Authentication_indicator HTH -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mlasevich at gmail.com Mon Aug 11 20:59:48 2014 From: mlasevich at gmail.com (Michael Lasevich) Date: Mon, 11 Aug 2014 13:59:48 -0700 Subject: [Freeipa-users] Using Native OTP for auth from specific hosts In-Reply-To: <20140811200415.GF4748@redhat.com> References: <20140811184923.GB4748@redhat.com> <20140811193017.GE4748@redhat.com> <20140811200415.GF4748@redhat.com> Message-ID: My thought is that while 2 and 3 are same from IPA point of view, since I am guaranteed to be sending a different credentials in those cases I am guaranteed to be checking both password and otp. Prevents a case where user's password ends in a string of digits similar to OTP. I will look into checking the tokens for changes, but that seems a bit more complicated and error-prone. -M On Mon, Aug 11, 2014 at 1:04 PM, Alexander Bokovoy wrote: > On Mon, 11 Aug 2014, Michael Lasevich wrote: > >> On Mon, Aug 11, 2014 at 12:30 PM, Alexander Bokovoy >> wrote: >> >> On Mon, 11 Aug 2014, Michael Lasevich wrote: >>> >>> So, it is NOT intended to use for border-style 2FA authentication (i.e. >>>> VPN) - which seems may be a common use case for 2FA? >>>> >>>> You can always supplement authentication check with some host-specific >>> information at the VPN concentrator. We don't have ready to use solution >>> here but it is definitely possible to use such scheme against FreeIPA >>> 2FA. >>> >>> >>> Sorry, I am not following. What do you mean by "host-specific >> information"? If system has no way to detect how many factors were >> involved >> in authentication, how would I be able to guarantee that only 2FA is >> allowed via this box? >> >> I suppose this can work: I can write code that will: >> >> 1 - detects if there are OTP numbers at the end of the password >> 2 - authenticates using full 2FA >> 3 - authenticates using just password without 2FA >> >> And then authenticate only if all 3 conditions are satisfied. Seems a bit >> hacky, but that is the only way I can think that may work. >> > 2 and 3 are the same from IPA point of view, just an LDAP bind. Ideally > SSSD could handle this as part of a PAM stack by providing PAM > feedback that could be used by other modules. There was no request for > this functionality before. > > However, I was mostly thinking that you may have an authentication > sequence where past successful auth you would check tokens associated > with the user to see if there is a recent update within the same time > period on one of tokens. This would work right now, though it is a bit a > hack -- a better one than the 2-accounts-per-user. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shownde at slu.edu Mon Aug 11 21:03:43 2014 From: shownde at slu.edu (Daniel Shown) Date: Mon, 11 Aug 2014 16:03:43 -0500 Subject: [Freeipa-users] about AD trusts and passthrough authentication In-Reply-To: <20140811200811.GG4748@redhat.com> References: <20140811200811.GG4748@redhat.com> Message-ID: Right, that's what I've got at this point. I just wanted to make sure I wasn't missing something. Unfortunately, that architecture won't work for me (mostly for political reasons instead of technical ones). I guess I'll be digging into pass through auth to see if I can get that working. thx. =================================== *Daniel Shown,* Linux Systems Administrator Advanced Technology Group Information Technology Services at Saint Louis University . 314-977-2583 =================================== "The aim of education is the knowledge, not of facts, but of values." ? William S. Burroughs "I?m supposed to be a scientific person but I use intuition more than logic in making basic decisions." ? Seymour R. Cray On Mon, Aug 11, 2014 at 3:08 PM, Alexander Bokovoy wrote: > On Mon, 11 Aug 2014, Daniel Shown wrote: > >> I'm fairly new to FreeIPA, so can someone give me a sanity check? Should I >> be able to map AD users in an AD trust to to corresponding FreeIPA users? >> i.e. Users can auth with their AD credentials and get a FreeIPA uidnumber, >> gidnumber, home, etc.? >> > Users from a trusted forest are treated as separate users. They have > their own identities and get IDs from either Active Directory (if POSIX > compatibility is enabled at AD) or from special ID range allocated for > them in IPA. > > You can include these users (and groups, it doesn't matter what is what) > into special type of groups in IPA, called "external" groups. These > groups, in turn, can be members of existing POSIX groups from IPA. If > done so, your AD users will become members of appropriate POSIX groups > from IPA by means of nested membership. > > These POSIX groups then can be used to apply SUDO or HBAC rules against > AD users. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Mon Aug 11 21:46:14 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Mon, 11 Aug 2014 21:46:14 +0000 Subject: [Freeipa-users] about AD trusts and passthrough authentication In-Reply-To: References: <20140811200811.GG4748@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7132C7@001FSN2MPN1-045.001f.mgd2.msft.net> I?ve got a prototype setup for cross-realm operations. I don?t know if that?s useful for you or not. I don?t have control over ?my? AD, and I?m managing this during our CIO?s migration from one AD realm to another (so duplicate users having distinct DNs and Kerberos principals are the norm, rather than the exception). I have three upstreams: FreeIPA, and Corporate AD A and B. My non-FreeIPA users setup is in two stages, meaning two separate OpenLDAP servers. I couldn?t squash them down onto one server, but you might be smarter than me: 1] A ?remapping? metadirectory server, which combines all of the foreign users from all three upstreams into one DIT (although each upstream gets its own OU). This server?s job is to make sure that a single LDAP query can return results from any of the upstream servers. It stores nothing locally and masks out most of the upstream info. LDAP binds are passed thru to upstream. 2] A ?translucent proxy? server, which does no remapping, but lets me add/override attributes. Also have RFC2307 group stored here. FWIW, I don?t have a trust between any AD and FreeIPA. The metadirectory server binds as me against AD (via a keytab and k5start). You can get pretty far without a trust, and without the ability to create groups on the AD side. My goal is to set myself up to take advantage of ?views? when they make it into FreeIPA. The real objective, though, is to propagate the cross realm functionality enjoyed for the last four years with my ldap/padl setup into a freeipa/sssd environment. Long term, I want FreeIPA to internalize my sketchy prototype setup and manage uid/uidNumber/gidNumber/loginShell/homeDirectory overrides for my linux domain in some sensible and convenient way. I?m trying to implement the ?umich_schema? (man idmapd.conf) to enable cross realm NFS, eventually, if I ever get a trust. Ideally, this could also be used by sssd to map GSSAuthName to username, particularly if a person has more than one GSSAuthName. Dumb and persistent sometimes trumps smart. ? Bryce From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Daniel Shown Sent: Monday, August 11, 2014 3:04 PM To: Alexander Bokovoy Cc: freeipa-users Subject: Re: [Freeipa-users] about AD trusts and passthrough authentication Right, that's what I've got at this point. I just wanted to make sure I wasn't missing something. Unfortunately, that architecture won't work for me (mostly for political reasons instead of technical ones). I guess I'll be digging into pass through auth to see if I can get that working. thx. =================================== Daniel Shown, Linux Systems Administrator Advanced Technology Group Information Technology Services at Saint Louis University. 314-977-2583 =================================== "The aim of education is the knowledge, not of facts, but of values." ? William S. Burroughs "I?m supposed to be a scientific person but I use intuition more than logic in making basic decisions." ? Seymour R. Cray [Image removed by sender.] On Mon, Aug 11, 2014 at 3:08 PM, Alexander Bokovoy > wrote: On Mon, 11 Aug 2014, Daniel Shown wrote: I'm fairly new to FreeIPA, so can someone give me a sanity check? Should I be able to map AD users in an AD trust to to corresponding FreeIPA users? i.e. Users can auth with their AD credentials and get a FreeIPA uidnumber, gidnumber, home, etc.? Users from a trusted forest are treated as separate users. They have their own identities and get IDs from either Active Directory (if POSIX compatibility is enabled at AD) or from special ID range allocated for them in IPA. You can include these users (and groups, it doesn't matter what is what) into special type of groups in IPA, called "external" groups. These groups, in turn, can be members of existing POSIX groups from IPA. If done so, your AD users will become members of appropriate POSIX groups from IPA by means of nested membership. These POSIX groups then can be used to apply SUDO or HBAC rules against AD users. -- / Alexander Bokovoy 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 451 bytes Desc: image001.jpg URL: From william at firstyear.id.au Mon Aug 11 23:55:17 2014 From: william at firstyear.id.au (William) Date: Tue, 12 Aug 2014 09:25:17 +0930 Subject: [Freeipa-users] Adding permissions to a service account. Message-ID: <1407801317.20500.2.camel@ammy.its.adelaide.edu.au> Hi, I am trying to allow a radius service account the ability to read ipaNTHash. I carried out the following steps: ipa permission-add 'ipaNTHash service read' --attrs=ipaNTHash --type=user --permissions=read ----------------------------------------- Added permission "ipaNTHash service read" ----------------------------------------- Permission name: ipaNTHash service read Permissions: read Attributes: ipanthash Type: user ipa privilege-add 'Radius services' --desc='Privileges needed to allow radiusd servers to operate' ipa privilege-add-permission 'Radius services' --permissions='ipaNTHash service read' Privilege name: Radius services Description: Privileges needed to allow radiusd servers to operate Permissions: ipaNTHash service read ----------------------------- Number of permissions added 1 ----------------------------- ipa role-add 'Radius server' --desc="Radius server role" -------------------------- Added role "Radius server" -------------------------- Role name: Radius server Description: Radius server role ipa service-add 'radius/lorna.dev.blackhats.net.au' ---------------------------------------------------------------------- Added service "radius/lorna.dev.blackhats.net.au at DEV.BLACKHATS.NET.AU" ---------------------------------------------------------------------- Principal: radius/lorna.dev.blackhats.net.au at DEV.BLACKHATS.NET.AU Managed by: lorna.dev.blackhats.net.au ipa role-add-member 'Radius server' --hosts='lorna.dev.blackhats.net.au' Role name: Radius server Description: Radius server role Member hosts: lorna.dev.blackhats.net.au Privileges: Radius services ------------------------- Number of members added 1 ------------------------- ipa-getkeytab -p 'radius/lorna.dev.blackhats.net.au' -s lorna.dev.blackhats.net.au -k /root/radiusd.keytab kinit -t /root/radiusd.keytab -k radius/lorna.dev.blackhats.net.au After these steps I did an ldapwhoami and attempted to get the ipaNTHast from an account: It didn't work. I believe this is because the whoami shows the account binds as a different DN than the host account, thus the permission isn't applied. But there is no way to in the ui or cli add permissions to a service account. How should I proceed? From cwhittl at gmail.com Tue Aug 12 13:46:26 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 12 Aug 2014 08:46:26 -0500 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: <53E6F58D.5090700@redhat.com> References: <53E3B5C8.6090208@sesda3.com> <53E531B0.8030300@redhat.com> <53E6F58D.5090700@redhat.com> Message-ID: http://www.freeipa.org/page/HowTo/Integrate_With_Okta On Sat, Aug 9, 2014 at 11:31 PM, Dmitri Pal wrote: > On 08/08/2014 04:26 PM, Chris Whittle wrote: > > Hey Dimitri, What do you mean? Both of them gave me the same answer and > it worked. > > > Right, now you have the knowledge which is burred in a mail thread and > would be hard to find for others that might want to follow your steps. > I was hoping you would find some time to summarize your setup and > experience and share with others via a HOWTO page on the FreeIPA site [1]. > > [1] http://www.freeipa.org/page/HowTos > > Thanks > Dmitri > > > On Aug 8, 2014 3:25 PM, "Dmitri Pal" wrote: > >> On 08/07/2014 02:21 PM, Chris Whittle wrote: >> >> Thanks guys that works! >> >> >> >> And what about HOWTO? ;-) >> >> >> >> >> On Thu, Aug 7, 2014 at 12:22 PM, Lucas Yamanishi >> wrote: >> >>> On 08/07/2014 12:18 PM, Chris Whittle wrote: >>> >>> I'm currently working on a trial with OKTA and have installed their >>> server agent with no issues. Now I'm trying to map FreeIPA attributes with >>> OKTA's >>> >>> I'm getting no entries found, which leads me to think I'm missing >>> something >>> [image: Inline image 1] >>> [image: Inline image 2] >>> [image: Inline image 3] >>> Thanks! >>> >>> >>> The objectClass values look incorrect. Try posixAccount and posixGroup >>> for users and groups. Roles are groupOfNames, but that?s a little less >>> specific and will match non-role entries without a search base. >>> >>> You can easily look up raw entries to check your mappings with commands >>> like these (the ?all and ?raw options are available for all *-show >>> commands, afaik): >>> >>> ipa user-show --all --raw $USER_NAME >>> ipa group-show --all --raw $GROUP >>> ipa role-show --all --raw $ROLE >>> >>> Or pure ldaputils: >>> >>> ldapsearch -LLL -YGSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' 'uid=$USER_NAME' >>> >>> ? >>> >>> -- >>> ----- >>> *question everything*learn something*answer nothing* >>> ------------ >>> Lucas Yamanishi >>> ------------------ >>> Systems Administrator, ADNET Systems, Inc. >>> NASA Space and Earth Science Data Analysis (606.9) >>> 7515 Mission Drive, Suite A100 >>> Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 103249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 89508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 88448 bytes Desc: not available URL: From mkosek at redhat.com Tue Aug 12 14:50:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 12 Aug 2014 16:50:21 +0200 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: References: <53E3B5C8.6090208@sesda3.com> <53E531B0.8030300@redhat.com> <53E6F58D.5090700@redhat.com> Message-ID: <53EA29AD.8040703@redhat.com> Thank you! I liked this page to http://www.freeipa.org/page/HowTos#Authentication and also improved formatting of the page. I am not sure about the "role" section though, we do not use "role" objectclass, so Okta's search probably returns no results anyway. It may be better to keep that blank IMO. Martin On 08/12/2014 03:46 PM, Chris Whittle wrote: > http://www.freeipa.org/page/HowTo/Integrate_With_Okta > > > On Sat, Aug 9, 2014 at 11:31 PM, Dmitri Pal wrote: > >> On 08/08/2014 04:26 PM, Chris Whittle wrote: >> >> Hey Dimitri, What do you mean? Both of them gave me the same answer and >> it worked. >> >> >> Right, now you have the knowledge which is burred in a mail thread and >> would be hard to find for others that might want to follow your steps. >> I was hoping you would find some time to summarize your setup and >> experience and share with others via a HOWTO page on the FreeIPA site [1]. >> >> [1] http://www.freeipa.org/page/HowTos >> >> Thanks >> Dmitri >> >> >> On Aug 8, 2014 3:25 PM, "Dmitri Pal" wrote: >> >>> On 08/07/2014 02:21 PM, Chris Whittle wrote: >>> >>> Thanks guys that works! >>> >>> >>> >>> And what about HOWTO? ;-) >>> >>> >>> >>> >>> On Thu, Aug 7, 2014 at 12:22 PM, Lucas Yamanishi >>> wrote: >>> >>>> On 08/07/2014 12:18 PM, Chris Whittle wrote: >>>> >>>> I'm currently working on a trial with OKTA and have installed their >>>> server agent with no issues. Now I'm trying to map FreeIPA attributes with >>>> OKTA's >>>> >>>> I'm getting no entries found, which leads me to think I'm missing >>>> something >>>> [image: Inline image 1] >>>> [image: Inline image 2] >>>> [image: Inline image 3] >>>> Thanks! >>>> >>>> >>>> The objectClass values look incorrect. Try posixAccount and posixGroup >>>> for users and groups. Roles are groupOfNames, but that?s a little less >>>> specific and will match non-role entries without a search base. >>>> >>>> You can easily look up raw entries to check your mappings with commands >>>> like these (the ?all and ?raw options are available for all *-show >>>> commands, afaik): >>>> >>>> ipa user-show --all --raw $USER_NAME >>>> ipa group-show --all --raw $GROUP >>>> ipa role-show --all --raw $ROLE >>>> >>>> Or pure ldaputils: >>>> >>>> ldapsearch -LLL -YGSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' 'uid=$USER_NAME' >>>> >>>> ? >>>> >>>> -- >>>> ----- >>>> *question everything*learn something*answer nothing* >>>> ------------ >>>> Lucas Yamanishi >>>> ------------------ >>>> Systems Administrator, ADNET Systems, Inc. >>>> NASA Space and Earth Science Data Analysis (606.9) >>>> 7515 Mission Drive, Suite A100 >>>> Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB >>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >>>> >>> >>> >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> > > > From erinn.looneytriggs at gmail.com Tue Aug 12 15:13:21 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 12 Aug 2014 09:13:21 -0600 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <53E8DC7A.6090102@redhat.com> References: <53E6DDEC.10105@gmail.com> <20140811141803.GA19977@redhat.com> <20140811142434.GB9920@hendrix.redhat.com> <53E8DC7A.6090102@redhat.com> Message-ID: <53EA2F11.3040606@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/11/2014 09:08 AM, Martin Kosek wrote: > On 08/11/2014 04:24 PM, Jakub Hrozek wrote: >> On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy >> wrote: >>> On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>> >>>> It would seem to be prudent to set the minssf setting for 389 >>>> to 56, however I am wondering why this isn't done by default, >>>> and if there is any reason why I shouldn't do it? >>> Anonymous connection to LDAP wouldn't work. I think we use it >>> for rootdse access when enrolling IPA clients where we don't >>> yet have a CA certificate. >>> >>> I may be wrong, though. >> >> Also old (RHEL-5) SSSD versions rely on anonymous access to be >> able to retrieve rootDSE. Newer (RHEL-6.3+) clients are able to >> re-try fetching rootDSE once the authenticated connection is >> established. >> > > Also, older FreeIPA clients were not able to join those severs due > to bug in ipa-client-install: > > https://fedorahosted.org/freeipa/ticket/4459 > > This will be fixed in FreeIPA 4.0.2. Note that this only affects if > you are changing MinSSF for whole DS by nsslapd-minssf. > > Martin > I guess the part I don't get here, is that this setting does not disable anonymous access to rootdse it just requires, as far as I understand, that TLS or some security be used for the connection. I currently have minssf set to 56 and am able to anonymously bind and obtain the rootdse. I understand there may be troubles along the way but wouldn't setting this as a default be a "good" thing to aim for? - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT6i8MAAoJEFg7BmJL2iPO6IkIALotkQHu8XRNRbxIl+NlXNn+ TgfjCHyu37jn+xGYjRkciH/wDaPgq3VJxoac1LZ5InU7iNqk3tBwXboeOmtw24yx sgS7QnFmH7la/+OIRqy7anOcj0eSC6YCVEpAp2/Igx/Fi1XE5aYf+4xvnudLaTRH MtVSDo7+RO6Aixn9nVKEvyz4gOky0BHnWlLWye/+vPVidwu5lWAU7HMy8h/lzsXB 2PEcOdyiQu5QSXHLjU4IN1mwOHjGZZGEmw5y8hYPU5z3RWhGakBpEQB9BrgR2rUO xZ/eJrCuWjhBvzQbkU7guIajZvT37pzDdAir/v3exreRIWZVI3Cf3TB3cKrUcxc= =0RQg -----END PGP SIGNATURE----- From erinn.looneytriggs at gmail.com Tue Aug 12 15:18:10 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 12 Aug 2014 09:18:10 -0600 Subject: [Freeipa-users] Replicating o=ipaca Message-ID: <53EA3032.20206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The documentation seems to be a little fuzzy on setting up two CAs, some parts indicate this is a bad idea because the CRLs can clobber each other, other parts, such as the migration guide from RHEL 6.5 to 7 seem to indicate that it is ok, albeit maybe that is just for a short time. What I am wondering, because I get a little nervous when all my data for the CA is on one host (backups aside), is whether there is a value, assuming that having two concurrent dogtag instances is a bad thing, to replicating the ipaca data in ldap. Just the data I mean, would it be possible, having just the LDAP data and whatever certs are in the replica file to basically reconstruct a CA? - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT6jAyAAoJEFg7BmJL2iPOnM4IAKLtywgP5hvAtNRdd71rBilm EaYTbOuWf/47BigLKL/0OjfWhEF0dFGcKn27EeeZL3CCznH92liSfgpSVYzAa7cW X+INDSs2ctn9//LJdGIjhfSvHt3xQIB8KXR/DcSlu3gjHizEXpVLg0oj+w6GzbRG pw7p2A50MNGRar//wsbcZLV5VDdW84f/L+3iWUL9onn7hgNe3vlSBKmkD7cFXq5C +jwGS9t/ElYsB0tE3vchdF03h8u+1pYfc8u6y59zUnyFKIfw5iYYHd9HyuCx7Z3k jcby8/gmpxm+wqUmhmXOTDX+zTS32WnzKwjeqVGPVrGv1bOfjkXyovrGJwlEetA= =7cXD -----END PGP SIGNATURE----- From abokovoy at redhat.com Tue Aug 12 15:21:31 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 Aug 2014 18:21:31 +0300 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <53EA2F11.3040606@gmail.com> References: <53E6DDEC.10105@gmail.com> <20140811141803.GA19977@redhat.com> <20140811142434.GB9920@hendrix.redhat.com> <53E8DC7A.6090102@redhat.com> <53EA2F11.3040606@gmail.com> Message-ID: <20140812152131.GK4748@redhat.com> On Tue, 12 Aug 2014, Erinn Looney-Triggs wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >On 08/11/2014 09:08 AM, Martin Kosek wrote: >> On 08/11/2014 04:24 PM, Jakub Hrozek wrote: >>> On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy >>> wrote: >>>> On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>> >>>>> It would seem to be prudent to set the minssf setting for 389 >>>>> to 56, however I am wondering why this isn't done by default, >>>>> and if there is any reason why I shouldn't do it? >>>> Anonymous connection to LDAP wouldn't work. I think we use it >>>> for rootdse access when enrolling IPA clients where we don't >>>> yet have a CA certificate. >>>> >>>> I may be wrong, though. >>> >>> Also old (RHEL-5) SSSD versions rely on anonymous access to be >>> able to retrieve rootDSE. Newer (RHEL-6.3+) clients are able to >>> re-try fetching rootDSE once the authenticated connection is >>> established. >>> >> >> Also, older FreeIPA clients were not able to join those severs due >> to bug in ipa-client-install: >> >> https://fedorahosted.org/freeipa/ticket/4459 >> >> This will be fixed in FreeIPA 4.0.2. Note that this only affects if >> you are changing MinSSF for whole DS by nsslapd-minssf. >> >> Martin >> > >I guess the part I don't get here, is that this setting does not >disable anonymous access to rootdse it just requires, as far as I >understand, that TLS or some security be used for the connection. > >I currently have minssf set to 56 and am able to anonymously bind and >obtain the rootdse. This assumes you have CA certificate available so that you can successfully verify TLS handshake. When you are enrolling a client, you don't have the certificate yet. -- / Alexander Bokovoy From erinn.looneytriggs at gmail.com Tue Aug 12 15:23:23 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 12 Aug 2014 09:23:23 -0600 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <20140812152131.GK4748@redhat.com> References: <53E6DDEC.10105@gmail.com> <20140811141803.GA19977@redhat.com> <20140811142434.GB9920@hendrix.redhat.com> <53E8DC7A.6090102@redhat.com> <53EA2F11.3040606@gmail.com> <20140812152131.GK4748@redhat.com> Message-ID: <53EA316B.3000008@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/12/2014 09:21 AM, Alexander Bokovoy wrote: > On Tue, 12 Aug 2014, Erinn Looney-Triggs wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 08/11/2014 09:08 AM, Martin Kosek wrote: >>> On 08/11/2014 04:24 PM, Jakub Hrozek wrote: >>>> On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy >>>> wrote: >>>>> On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>>> >>>>>> It would seem to be prudent to set the minssf setting for >>>>>> 389 to 56, however I am wondering why this isn't done by >>>>>> default, and if there is any reason why I shouldn't do >>>>>> it? >>>>> Anonymous connection to LDAP wouldn't work. I think we use >>>>> it for rootdse access when enrolling IPA clients where we >>>>> don't yet have a CA certificate. >>>>> >>>>> I may be wrong, though. >>>> >>>> Also old (RHEL-5) SSSD versions rely on anonymous access to >>>> be able to retrieve rootDSE. Newer (RHEL-6.3+) clients are >>>> able to re-try fetching rootDSE once the authenticated >>>> connection is established. >>>> >>> >>> Also, older FreeIPA clients were not able to join those severs >>> due to bug in ipa-client-install: >>> >>> https://fedorahosted.org/freeipa/ticket/4459 >>> >>> This will be fixed in FreeIPA 4.0.2. Note that this only >>> affects if you are changing MinSSF for whole DS by >>> nsslapd-minssf. >>> >>> Martin >>> >> >> I guess the part I don't get here, is that this setting does not >> disable anonymous access to rootdse it just requires, as far as >> I understand, that TLS or some security be used for the >> connection. >> >> I currently have minssf set to 56 and am able to anonymously bind >> and obtain the rootdse. > This assumes you have CA certificate available so that you can > successfully verify TLS handshake. When you are enrolling a client, > you don't have the certificate yet. > Gotcha, that makes sense, didn't think that through. - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT6jFmAAoJEFg7BmJL2iPOsz8H/1q+dj83Sr7PLLuNxKXp9HGD Gy40XEMu2u/qpNMULikPCmUBEa09fJNZDcLfpFrgG2SrH1q+yDerp7Udwt3lV6nx tUObM+F8/PoKING9YhHY9DlB7ZyRvqyiiG6VTfRFNfRnPzkvWhNUfDM6WpeuyOqN M9gSxDt0ol2PAyApuW0phD8S0GT7uiCaYNdL2Dzkt98QULB30Znn4UBHGDx+VK1l oMiZAVYPpkFJel0WjKsEpFvAMpBIQKJ8zEXjNMVcokyei8KGKRomKDr9T08JypHz Q22ZoljPhXcFVRc80MzWaKVA/sPiNf3gpYRFd+0VEvSyMYS3aItrQW4U+LK6cnk= =CGuF -----END PGP SIGNATURE----- From cwhittl at gmail.com Tue Aug 12 15:26:44 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 12 Aug 2014 10:26:44 -0500 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: <53EA29AD.8040703@redhat.com> References: <53E3B5C8.6090208@sesda3.com> <53E531B0.8030300@redhat.com> <53E6F58D.5090700@redhat.com> <53EA29AD.8040703@redhat.com> Message-ID: Thanks Martin! On Tue, Aug 12, 2014 at 9:50 AM, Martin Kosek wrote: > Thank you! I liked this page to > http://www.freeipa.org/page/HowTos#Authentication > and also improved formatting of the page. I am not sure about the "role" > section though, we do not use "role" objectclass, so Okta's search probably > returns no results anyway. It may be better to keep that blank IMO. > > Martin > > On 08/12/2014 03:46 PM, Chris Whittle wrote: > > http://www.freeipa.org/page/HowTo/Integrate_With_Okta > > > > > > On Sat, Aug 9, 2014 at 11:31 PM, Dmitri Pal wrote: > > > >> On 08/08/2014 04:26 PM, Chris Whittle wrote: > >> > >> Hey Dimitri, What do you mean? Both of them gave me the same answer and > >> it worked. > >> > >> > >> Right, now you have the knowledge which is burred in a mail thread and > >> would be hard to find for others that might want to follow your steps. > >> I was hoping you would find some time to summarize your setup and > >> experience and share with others via a HOWTO page on the FreeIPA site > [1]. > >> > >> [1] http://www.freeipa.org/page/HowTos > >> > >> Thanks > >> Dmitri > >> > >> > >> On Aug 8, 2014 3:25 PM, "Dmitri Pal" wrote: > >> > >>> On 08/07/2014 02:21 PM, Chris Whittle wrote: > >>> > >>> Thanks guys that works! > >>> > >>> > >>> > >>> And what about HOWTO? ;-) > >>> > >>> > >>> > >>> > >>> On Thu, Aug 7, 2014 at 12:22 PM, Lucas Yamanishi < > lyamanishi at sesda3.com> > >>> wrote: > >>> > >>>> On 08/07/2014 12:18 PM, Chris Whittle wrote: > >>>> > >>>> I'm currently working on a trial with OKTA and have installed their > >>>> server agent with no issues. Now I'm trying to map FreeIPA > attributes with > >>>> OKTA's > >>>> > >>>> I'm getting no entries found, which leads me to think I'm missing > >>>> something > >>>> [image: Inline image 1] > >>>> [image: Inline image 2] > >>>> [image: Inline image 3] > >>>> Thanks! > >>>> > >>>> > >>>> The objectClass values look incorrect. Try posixAccount and > posixGroup > >>>> for users and groups. Roles are groupOfNames, but that?s a little less > >>>> specific and will match non-role entries without a search base. > >>>> > >>>> You can easily look up raw entries to check your mappings with > commands > >>>> like these (the ?all and ?raw options are available for all *-show > >>>> commands, afaik): > >>>> > >>>> ipa user-show --all --raw $USER_NAME > >>>> ipa group-show --all --raw $GROUP > >>>> ipa role-show --all --raw $ROLE > >>>> > >>>> Or pure ldaputils: > >>>> > >>>> ldapsearch -LLL -YGSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' > 'uid=$USER_NAME' > >>>> > >>>> ? > >>>> > >>>> -- > >>>> ----- > >>>> *question everything*learn something*answer nothing* > >>>> ------------ > >>>> Lucas Yamanishi > >>>> ------------------ > >>>> Systems Administrator, ADNET Systems, Inc. > >>>> NASA Space and Earth Science Data Analysis (606.9) > >>>> 7515 Mission Drive, Suite A100 > >>>> Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB > >>>> > >>>> > >>>> -- > >>>> Manage your subscription for the Freeipa-users mailing list: > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>> Go To http://freeipa.org for more info on the project > >>>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Thank you, > >>> Dmitri Pal > >>> > >>> Sr. Engineering Manager IdM portfolio > >>> Red Hat, Inc. > >>> > >>> > >>> -- > >>> Manage your subscription for the Freeipa-users mailing list: > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>> Go To http://freeipa.org for more info on the project > >>> > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager IdM portfolio > >> Red Hat, Inc. > >> > >> > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Tue Aug 12 15:29:51 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 12 Aug 2014 09:29:51 -0600 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <20140812152131.GK4748@redhat.com> References: <53E6DDEC.10105@gmail.com> <20140811141803.GA19977@redhat.com> <20140811142434.GB9920@hendrix.redhat.com> <53E8DC7A.6090102@redhat.com> <53EA2F11.3040606@gmail.com> <20140812152131.GK4748@redhat.com> Message-ID: <53EA32EF.9070606@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/12/2014 09:21 AM, Alexander Bokovoy wrote: > On Tue, 12 Aug 2014, Erinn Looney-Triggs wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >> >> On 08/11/2014 09:08 AM, Martin Kosek wrote: >>> On 08/11/2014 04:24 PM, Jakub Hrozek wrote: >>>> On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy >>>> wrote: >>>>> On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>>> >>>>>> It would seem to be prudent to set the minssf setting for >>>>>> 389 to 56, however I am wondering why this isn't done by >>>>>> default, and if there is any reason why I shouldn't do >>>>>> it? >>>>> Anonymous connection to LDAP wouldn't work. I think we use >>>>> it for rootdse access when enrolling IPA clients where we >>>>> don't yet have a CA certificate. >>>>> >>>>> I may be wrong, though. >>>> >>>> Also old (RHEL-5) SSSD versions rely on anonymous access to >>>> be able to retrieve rootDSE. Newer (RHEL-6.3+) clients are >>>> able to re-try fetching rootDSE once the authenticated >>>> connection is established. >>>> >>> >>> Also, older FreeIPA clients were not able to join those severs >>> due to bug in ipa-client-install: >>> >>> https://fedorahosted.org/freeipa/ticket/4459 >>> >>> This will be fixed in FreeIPA 4.0.2. Note that this only >>> affects if you are changing MinSSF for whole DS by >>> nsslapd-minssf. >>> >>> Martin >>> >> >> I guess the part I don't get here, is that this setting does not >> disable anonymous access to rootdse it just requires, as far as >> I understand, that TLS or some security be used for the >> connection. >> >> I currently have minssf set to 56 and am able to anonymously bind >> and obtain the rootdse. > This assumes you have CA certificate available so that you can > successfully verify TLS handshake. When you are enrolling a client, > you don't have the certificate yet. > However, this does bring up one more question in mind, why would the initial installer care? I mean that if the intial connection for ipa-client-install is going to be cleartext to what is basically an untrusted source at that point why not just ignore CA issues and use a TLS connection anyway? Kind of in the vein of the first ssh connection to a new host, the host presents its keys and you can choose whether to trust them or not. In the installers case trusting them for an anonymous bind would be just as safe as doing an anonymous bind without tls. Does that make sense? - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT6jLrAAoJEFg7BmJL2iPOxRgIAL2KlWRjPmwMbgzIOL+HNhW9 Ogf2SRNAYlHOCNAiwtLkHRtm2vxAtZbyBaVhIoOvgchejLT0Esj9OZSEA81z3Qkm FCk41R8xNFjPkDt39lU7r6F+LLECQw2933sSFnCFap3wHfIo2sb4fLGAlHe9SWYE t/PppCa+ToYuYVRGev6QtO9oAXzBfYbh8naZm2kz4QQil+N40UfhKkrDfwha2abn iEfIp5Eut+FPh3F2aVugv8Zb5pnqzC4/KR0RBLR7BTc4dLf9CC4DtCKk7S+FBpjV XOd3A3HDI7psFQy2qijq5Z1mgMNGnIUxB2Q1EhYoCsrTVaTnYCYUxcNvm0zSHvA= =uifU -----END PGP SIGNATURE----- From rcritten at redhat.com Tue Aug 12 17:49:02 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Aug 2014 13:49:02 -0400 Subject: [Freeipa-users] Replicating o=ipaca In-Reply-To: <53EA3032.20206@gmail.com> References: <53EA3032.20206@gmail.com> Message-ID: <53EA538E.2010501@redhat.com> Erinn Looney-Triggs wrote: > The documentation seems to be a little fuzzy on setting up two CAs, > some parts indicate this is a bad idea because the CRLs can clobber > each other, other parts, such as the migration guide from RHEL 6.5 to > 7 seem to indicate that it is ok, albeit maybe that is just for a > short time. It isn't a bad idea to stand up clones, you just need to understand that this is one of the rare places where all masters are not equal. One has to be designated as the CRL generator and one as the CA renewal master. These don't have to be the same but it makes sense to keep them together IMHO. The reason to limit CRL generation to one master is the small chance that you could end up with two CRLs with the same serial number but containing different certificates. Remember that a CRL is just a signed snapshot in time of revoked certificates. Similarly for renewal it is vastly easier to do it on one host than try to manage the race condition of them trying to renew at the same time. > What I am wondering, because I get a little nervous when all my data > for the CA is on one host (backups aside), is whether there is a > value, assuming that having two concurrent dogtag instances is a bad > thing, to replicating the ipaca data in ldap. Just the data I mean, > would it be possible, having just the LDAP data and whatever certs are > in the replica file to basically reconstruct a CA? Right, you want at least two CAs for redundancy. Some dogtag guru could probably stand up a new CA using just the LDAP data and the certs but I can't imagine it would be easy, even for them. rob From rcritten at redhat.com Tue Aug 12 17:51:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Aug 2014 13:51:24 -0400 Subject: [Freeipa-users] Adding permissions to a service account. In-Reply-To: <1407801317.20500.2.camel@ammy.its.adelaide.edu.au> References: <1407801317.20500.2.camel@ammy.its.adelaide.edu.au> Message-ID: <53EA541C.4090302@redhat.com> William wrote: > Hi, > > I am trying to allow a radius service account the ability to read > ipaNTHash. I carried out the following steps: > > > > ipa permission-add 'ipaNTHash service read' --attrs=ipaNTHash > --type=user --permissions=read > ----------------------------------------- > Added permission "ipaNTHash service read" > ----------------------------------------- > Permission name: ipaNTHash service read > Permissions: read > Attributes: ipanthash > Type: user > > ipa privilege-add 'Radius services' --desc='Privileges needed to allow > radiusd servers to operate' > > ipa privilege-add-permission 'Radius services' --permissions='ipaNTHash > service read' > Privilege name: Radius services > Description: Privileges needed to allow radiusd servers to operate > Permissions: ipaNTHash service read > ----------------------------- > Number of permissions added 1 > ----------------------------- > > > ipa role-add 'Radius server' --desc="Radius server role" > -------------------------- > Added role "Radius server" > -------------------------- > Role name: Radius server > Description: Radius server role > > > ipa service-add 'radius/lorna.dev.blackhats.net.au' > ---------------------------------------------------------------------- > Added service "radius/lorna.dev.blackhats.net.au at DEV.BLACKHATS.NET.AU" > ---------------------------------------------------------------------- > Principal: radius/lorna.dev.blackhats.net.au at DEV.BLACKHATS.NET.AU > Managed by: lorna.dev.blackhats.net.au > > > ipa role-add-member 'Radius server' --hosts='lorna.dev.blackhats.net.au' > Role name: Radius server > Description: Radius server role > Member hosts: lorna.dev.blackhats.net.au > Privileges: Radius services > ------------------------- > Number of members added 1 > ------------------------- > > ipa-getkeytab -p 'radius/lorna.dev.blackhats.net.au' -s > lorna.dev.blackhats.net.au -k /root/radiusd.keytab > kinit -t /root/radiusd.keytab -k radius/lorna.dev.blackhats.net.au > > > After these steps I did an ldapwhoami and attempted to get the ipaNTHast > from an account: It didn't work. I believe this is because the whoami > shows the account binds as a different DN than the host account, thus > the permission isn't applied. But there is no way to in the ui or cli > add permissions to a service account. How should I proceed? > You can't delegate permissions to a service. See https://fedorahosted.org/freeipa/ticket/3644 rob From abokovoy at redhat.com Tue Aug 12 18:33:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 12 Aug 2014 21:33:13 +0300 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <53EA32EF.9070606@gmail.com> References: <53E6DDEC.10105@gmail.com> <20140811141803.GA19977@redhat.com> <20140811142434.GB9920@hendrix.redhat.com> <53E8DC7A.6090102@redhat.com> <53EA2F11.3040606@gmail.com> <20140812152131.GK4748@redhat.com> <53EA32EF.9070606@gmail.com> Message-ID: <20140812183313.GM4748@redhat.com> On Tue, 12 Aug 2014, Erinn Looney-Triggs wrote: >>> I guess the part I don't get here, is that this setting does not >>> disable anonymous access to rootdse it just requires, as far as >>> I understand, that TLS or some security be used for the >>> connection. >>> >>> I currently have minssf set to 56 and am able to anonymously bind >>> and obtain the rootdse. >> This assumes you have CA certificate available so that you can >> successfully verify TLS handshake. When you are enrolling a client, >> you don't have the certificate yet. >> > >However, this does bring up one more question in mind, why would the >initial installer care? > >I mean that if the intial connection for ipa-client-install is going >to be cleartext to what is basically an untrusted source at that point >why not just ignore CA issues and use a TLS connection anyway? Kind of >in the vein of the first ssh connection to a new host, the host >presents its keys and you can choose whether to trust them or not. In >the installers case trusting them for an anonymous bind would be just >as safe as doing an anonymous bind without tls. > >Does that make sense? We need to support old clients which don't have chance to get updated to support this logic. I think we pretty much stuck with existing approach, given that now we have ability to serve the certificate through LDAP connection already (it is stored at cn=CACert,cn=ipa,cn=etc,$SUFFIX) and then the client does use it after downloading to perform actual join operation against LDAP over TLS. -- / Alexander Bokovoy From erinn.looneytriggs at gmail.com Tue Aug 12 18:40:39 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 12 Aug 2014 12:40:39 -0600 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <20140812183313.GM4748@redhat.com> References: <53E6DDEC.10105@gmail.com> <20140811141803.GA19977@redhat.com> <20140811142434.GB9920@hendrix.redhat.com> <53E8DC7A.6090102@redhat.com> <53EA2F11.3040606@gmail.com> <20140812152131.GK4748@redhat.com> <53EA32EF.9070606@gmail.com> <20140812183313.GM4748@redhat.com> Message-ID: <53EA5FA7.7060900@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/12/2014 12:33 PM, Alexander Bokovoy wrote: > On Tue, 12 Aug 2014, Erinn Looney-Triggs wrote: >>>> I guess the part I don't get here, is that this setting does >>>> not disable anonymous access to rootdse it just requires, as >>>> far as I understand, that TLS or some security be used for >>>> the connection. >>>> >>>> I currently have minssf set to 56 and am able to anonymously >>>> bind and obtain the rootdse. >>> This assumes you have CA certificate available so that you can >>> successfully verify TLS handshake. When you are enrolling a >>> client, you don't have the certificate yet. >>> >> >> However, this does bring up one more question in mind, why would >> the initial installer care? >> >> I mean that if the intial connection for ipa-client-install is >> going to be cleartext to what is basically an untrusted source at >> that point why not just ignore CA issues and use a TLS connection >> anyway? Kind of in the vein of the first ssh connection to a new >> host, the host presents its keys and you can choose whether to >> trust them or not. In the installers case trusting them for an >> anonymous bind would be just as safe as doing an anonymous bind >> without tls. >> >> Does that make sense? > We need to support old clients which don't have chance to get > updated to support this logic. I think we pretty much stuck with > existing approach, given that now we have ability to serve the > certificate through LDAP connection already (it is stored at > cn=CACert,cn=ipa,cn=etc,$SUFFIX) and then the client does use it > after downloading to perform actual join operation against LDAP > over TLS. > Makes sense, I reckoned there was probably good reasons, but I just wanted to bring it up as an option to see if it was possible. Thanks, - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT6l+jAAoJEFg7BmJL2iPOz/cIAItTGO9Kwouu8871ByEMd83D rLxVjg0eWgipuEg4K9Je5JI9nKZIKi+g9B7M/9LWXzIGH7meN6srG+9Wk/GkqkEu Q518n06iGT+8B/PqfgkTJBdXqRPH/oXJcypXq1Mfkyr0mO+h5rqb3/iM79cJATdJ r++h70TdZ8ELN51OETcTmhV7eg7IqKfNwuMTvLvR9Q/XjzZHWACgiF1lX80ODSNC QHTo7y7U8M6SLLj8UjERVvGAcznzTlrw4UA5oIDUtgzlf7s+qXdkfXwivrqVBdVy PV5bP3xRcP8jPVwojr6fb6FjFFemGyoAsHOgRkcjmJsVlk+TqXYUGl+ENVO/3DU= =rTN/ -----END PGP SIGNATURE----- From erinn.looneytriggs at gmail.com Tue Aug 12 19:53:05 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 12 Aug 2014 13:53:05 -0600 Subject: [Freeipa-users] Replicating o=ipaca In-Reply-To: <53EA538E.2010501@redhat.com> References: <53EA3032.20206@gmail.com> <53EA538E.2010501@redhat.com> Message-ID: <53EA70A1.1080102@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/12/2014 11:49 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> The documentation seems to be a little fuzzy on setting up two >> CAs, some parts indicate this is a bad idea because the CRLs can >> clobber each other, other parts, such as the migration guide from >> RHEL 6.5 to 7 seem to indicate that it is ok, albeit maybe that >> is just for a short time. > > It isn't a bad idea to stand up clones, you just need to understand > that this is one of the rare places where all masters are not > equal. One has to be designated as the CRL generator and one as the > CA renewal master. These don't have to be the same but it makes > sense to keep them together IMHO. > > The reason to limit CRL generation to one master is the small > chance that you could end up with two CRLs with the same serial > number but containing different certificates. Remember that a CRL > is just a signed snapshot in time of revoked certificates. > > Similarly for renewal it is vastly easier to do it on one host than > try to manage the race condition of them trying to renew at the > same time. > >> What I am wondering, because I get a little nervous when all my >> data for the CA is on one host (backups aside), is whether there >> is a value, assuming that having two concurrent dogtag instances >> is a bad thing, to replicating the ipaca data in ldap. Just the >> data I mean, would it be possible, having just the LDAP data and >> whatever certs are in the replica file to basically reconstruct a >> CA? > > Right, you want at least two CAs for redundancy. Some dogtag guru > could probably stand up a new CA using just the LDAP data and the > certs but I can't imagine it would be easy, even for them. > > rob > Ok, are there manual steps involved in that or does the --setup-ca on the replica just take care of everything. I certainly hope I am not looking in the wrong place, I just can't seem to find anything definitive in the docs. Thanks, - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJT6nChAAoJEFg7BmJL2iPOxjoH/i3fOKoJX1jFyMyP8L7KQZIA c+H94PnvGrsNXUtA7nlfFAvkLj0k1H9lib5vxPwTAF+XGAY4EsxlxFU8e//aIKOw yjDNqIVOoTa0OAVWNDDOFXyCZrmuvgpTLawk0iGSorWljPYWoQBaZvRmJo6l9MAO QyKtBIrrhrese9iNTvg3qbR6teIHRTnoQ5QftE0dxvDlrSqc1sj2GppRoVGVqwqv jETT6sq1IJaiFF3wBBso58vC5vLFqu8xkdF7g8nhRXnMX2oG50WHRtFoYvaGRlNf pHfojyuZn9XhVmLvqAIi0da6T6iwtR1UvwwkVndLqso59iB6KgSx6GA/pfqJd8k= =V5A3 -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Aug 13 00:15:55 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Aug 2014 20:15:55 -0400 Subject: [Freeipa-users] Replicating o=ipaca In-Reply-To: <53EA70A1.1080102@gmail.com> References: <53EA3032.20206@gmail.com> <53EA538E.2010501@redhat.com> <53EA70A1.1080102@gmail.com> Message-ID: <53EAAE3B.6090805@redhat.com> Erinn Looney-Triggs wrote: > On 08/12/2014 11:49 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> The documentation seems to be a little fuzzy on setting up two >>> CAs, some parts indicate this is a bad idea because the CRLs can >>> clobber each other, other parts, such as the migration guide from >>> RHEL 6.5 to 7 seem to indicate that it is ok, albeit maybe that >>> is just for a short time. > >> It isn't a bad idea to stand up clones, you just need to understand >> that this is one of the rare places where all masters are not >> equal. One has to be designated as the CRL generator and one as the >> CA renewal master. These don't have to be the same but it makes >> sense to keep them together IMHO. > >> The reason to limit CRL generation to one master is the small >> chance that you could end up with two CRLs with the same serial >> number but containing different certificates. Remember that a CRL >> is just a signed snapshot in time of revoked certificates. > >> Similarly for renewal it is vastly easier to do it on one host than >> try to manage the race condition of them trying to renew at the >> same time. > >>> What I am wondering, because I get a little nervous when all my >>> data for the CA is on one host (backups aside), is whether there >>> is a value, assuming that having two concurrent dogtag instances >>> is a bad thing, to replicating the ipaca data in ldap. Just the >>> data I mean, would it be possible, having just the LDAP data and >>> whatever certs are in the replica file to basically reconstruct a >>> CA? > >> Right, you want at least two CAs for redundancy. Some dogtag guru >> could probably stand up a new CA using just the LDAP data and the >> certs but I can't imagine it would be easy, even for them. > >> rob > > > Ok, are there manual steps involved in that or does the --setup-ca on > the replica just take care of everything. > > I certainly hope I am not looking in the wrong place, I just can't > seem to find anything definitive in the docs. --setup-ca does it all for you. Dogtag actually handles the creation of the replication agreement so we don't do a lot other than to tell it the remote server and provide the initial certs/keys. You can use ipa-csreplica-manage to view/manage CA replication agreements. rob From william at firstyear.id.au Wed Aug 13 00:27:50 2014 From: william at firstyear.id.au (William) Date: Wed, 13 Aug 2014 09:57:50 +0930 Subject: [Freeipa-users] Adding permissions to a service account. In-Reply-To: <53EA541C.4090302@redhat.com> References: <1407801317.20500.2.camel@ammy.its.adelaide.edu.au> <53EA541C.4090302@redhat.com> Message-ID: <1407889670.20500.13.camel@ammy.its.adelaide.edu.au> On Tue, 2014-08-12 at 13:51 -0400, Rob Crittenden wrote: > William wrote: > > Hi, > > > > I am trying to allow a radius service account the ability to read > > ipaNTHash. I carried out the following steps: > > > > You can't delegate permissions to a service. See > https://fedorahosted.org/freeipa/ticket/3644 > > rob For now, should I just add the service DN as a member of the role to enable this? -- William From barrykfl at gmail.com Wed Aug 13 05:56:37 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 13 Aug 2014 13:56:37 +0800 Subject: [Freeipa-users] check access log of when a user login integrated system Message-ID: Hi all: I have a buzilla intgrated with ldap ,,,is it poosible to check when the user login through the access log of ldap free ipa server .. What sentence should it look like ? thks barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Aug 13 06:32:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Aug 2014 08:32:17 +0200 Subject: [Freeipa-users] Replicating o=ipaca In-Reply-To: <53EAAE3B.6090805@redhat.com> References: <53EA3032.20206@gmail.com> <53EA538E.2010501@redhat.com> <53EA70A1.1080102@gmail.com> <53EAAE3B.6090805@redhat.com> Message-ID: <53EB0671.9050902@redhat.com> On 08/13/2014 02:15 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> On 08/12/2014 11:49 AM, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> The documentation seems to be a little fuzzy on setting up two >>>> CAs, some parts indicate this is a bad idea because the CRLs can >>>> clobber each other, other parts, such as the migration guide from >>>> RHEL 6.5 to 7 seem to indicate that it is ok, albeit maybe that >>>> is just for a short time. >> >>> It isn't a bad idea to stand up clones, you just need to understand >>> that this is one of the rare places where all masters are not >>> equal. One has to be designated as the CRL generator and one as the >>> CA renewal master. These don't have to be the same but it makes >>> sense to keep them together IMHO. >> >>> The reason to limit CRL generation to one master is the small >>> chance that you could end up with two CRLs with the same serial >>> number but containing different certificates. Remember that a CRL >>> is just a signed snapshot in time of revoked certificates. >> >>> Similarly for renewal it is vastly easier to do it on one host than >>> try to manage the race condition of them trying to renew at the >>> same time. >> >>>> What I am wondering, because I get a little nervous when all my >>>> data for the CA is on one host (backups aside), is whether there >>>> is a value, assuming that having two concurrent dogtag instances >>>> is a bad thing, to replicating the ipaca data in ldap. Just the >>>> data I mean, would it be possible, having just the LDAP data and >>>> whatever certs are in the replica file to basically reconstruct a >>>> CA? >> >>> Right, you want at least two CAs for redundancy. Some dogtag guru >>> could probably stand up a new CA using just the LDAP data and the >>> certs but I can't imagine it would be easy, even for them. >> >>> rob >> >> >> Ok, are there manual steps involved in that or does the --setup-ca on >> the replica just take care of everything. >> >> I certainly hope I am not looking in the wrong place, I just can't >> seem to find anything definitive in the docs. > > --setup-ca does it all for you. Dogtag actually handles the creation of > the replication agreement so we don't do a lot other than to tell it the > remote server and provide the initial certs/keys. > > You can use ipa-csreplica-manage to view/manage CA replication agreements. > > rob > Also, in case you choose to for example decommission your current CRL generator, you can switch that role to other machine using this HOWTO: http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master Martin From abokovoy at redhat.com Wed Aug 13 06:36:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 13 Aug 2014 09:36:50 +0300 Subject: [Freeipa-users] check access log of when a user login integrated system In-Reply-To: References: Message-ID: <20140813063650.GP4748@redhat.com> On Wed, 13 Aug 2014, barrykfl at gmail.com wrote: >Hi all: > >I have a buzilla intgrated with ldap ,,,is it poosible to check >when the user login through the access log of ldap free ipa server .. > >What sentence should it look like ? For example, following will return you date and uid of the user login. # cat /var/log/dirsrv/slapd-EXAMPLE-COM/access|awk '/RESULT.*dn="uid=/ { split($10, a, /[=,]/); print $1,$2,a[3] }' [12/Aug/2014:20:27:57 +0200] abbra [12/Aug/2014:20:28:23 +0200] abbra [12/Aug/2014:20:30:33 +0200] abbra [13/Aug/2014:08:06:48 +0200] admin -- / Alexander Bokovoy From mkosek at redhat.com Wed Aug 13 06:44:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Aug 2014 08:44:27 +0200 Subject: [Freeipa-users] Adding permissions to a service account. In-Reply-To: <1407889670.20500.13.camel@ammy.its.adelaide.edu.au> References: <1407801317.20500.2.camel@ammy.its.adelaide.edu.au> <53EA541C.4090302@redhat.com> <1407889670.20500.13.camel@ammy.its.adelaide.edu.au> Message-ID: <53EB094B.2050300@redhat.com> On 08/13/2014 02:27 AM, William wrote: > On Tue, 2014-08-12 at 13:51 -0400, Rob Crittenden wrote: >> William wrote: >>> Hi, >>> >>> I am trying to allow a radius service account the ability to read >>> ipaNTHash. I carried out the following steps: >>> > >> >> You can't delegate permissions to a service. See >> https://fedorahosted.org/freeipa/ticket/3644 >> >> rob > > > For now, should I just add the service DN as a member of the role to > enable this? Rob used a wrong ticket, this is the one: https://fedorahosted.org/freeipa/ticket/3164 It is currently planned for FreeIPA 4.1. If you are interested in contributing a patch, please feel free to do so, this would be a simple one :-) Anyway, to fix your permission delegation problem, check this: # ipa service-show foo/`hostname` --all --raw | grep "dn:" dn: krbprincipalname=foo/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test # ipa role-show test_role --all --raw | grep "dn:" dn: cn=test_role,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test # kinit admin Password for admin at MKOSEK-FEDORA20.TEST: # ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: admin at MKOSEK-FEDORA20.TEST SASL SSF: 56 SASL data security layer installed. dn: cn=test_role,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test changetype: modify add: member member: krbprincipalname=foo/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test modifying entry "cn=test_role,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test" # ipa role-show test_role --all --raw ... member: krbprincipalname=foo/ipa.mkosek-fedora20.test at MKOSEK-FEDORA20.TEST,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test ... Then, the role and assigned privileges/permissions should work for this service. Martin From kliu at alumni.warwick.ac.uk Wed Aug 13 07:51:32 2014 From: kliu at alumni.warwick.ac.uk (Barry) Date: Wed, 13 Aug 2014 15:51:32 +0800 Subject: [Freeipa-users] check access log of when a user login integrated system In-Reply-To: <20140813063650.GP4748@redhat.com> References: <20140813063650.GP4748@redhat.com> Message-ID: Hi: Yes there are some log show user but seem it log the user who directly login ldap using their uid. i integrate the buzilla using an uid=ldap ..then otther user can login freely ...it seem it logged ldap not inside users using the buzilla. 2014-08-13 14:36 GMT+08:00 Alexander Bokovoy : > On Wed, 13 Aug 2014, barrykfl at gmail.com wrote: > >> Hi all: >> >> I have a buzilla intgrated with ldap ,,,is it poosible to check >> when the user login through the access log of ldap free ipa server .. >> >> What sentence should it look like ? >> > For example, following will return you date and uid of the user login. > > # cat /var/log/dirsrv/slapd-EXAMPLE-COM/access|awk '/RESULT.*dn="uid=/ { > split($10, a, /[=,]/); print $1,$2,a[3] }' > [12/Aug/2014:20:27:57 +0200] abbra > [12/Aug/2014:20:28:23 +0200] abbra > [12/Aug/2014:20:30:33 +0200] abbra > [13/Aug/2014:08:06:48 +0200] admin > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uncommonkat at gmail.com Wed Aug 13 14:23:43 2014 From: uncommonkat at gmail.com (Kat) Date: Wed, 13 Aug 2014 07:23:43 -0700 Subject: [Freeipa-users] getting auth to work with just IPA LDAP Message-ID: <53EB74EF.6050201@gmail.com> Hello fellow IPAers... Just wondering what I might be doing wrong. I have servers that just need to auth to the LDAP username/PW portion of IPA since they can't do Kerberos right now. What could I be missing -- I run the authconfig to setup and verify sssd.conf, but I continue to get: sshd[7010]: pam_sss(sshd:auth): received for user testuser: 9 (Authentication service cannot retrieve authentication info) The ports are open to the LDAP/IPA server, I can run ldapsearch commands, but it just won't authenticate. Any ideas? From jhrozek at redhat.com Wed Aug 13 16:28:35 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 13 Aug 2014 18:28:35 +0200 Subject: [Freeipa-users] getting auth to work with just IPA LDAP In-Reply-To: <53EB74EF.6050201@gmail.com> References: <53EB74EF.6050201@gmail.com> Message-ID: <20140813162835.GD29931@hendrix.redhat.com> On Wed, Aug 13, 2014 at 07:23:43AM -0700, Kat wrote: > Hello fellow IPAers... > > Just wondering what I might be doing wrong. I have servers that just need to > auth to the LDAP username/PW portion of IPA since they can't do Kerberos > right now. > > What could I be missing -- I run the authconfig to setup and verify > sssd.conf, but I continue to get: > > sshd[7010]: pam_sss(sshd:auth): received for user testuser: 9 > (Authentication service cannot retrieve authentication info) > > The ports are open to the LDAP/IPA server, I can run ldapsearch commands, > but it just won't authenticate. > > Any ideas? Can you post SSSD logs? The error code makes it sound like sssd can't reach the servers, but it's very hard to tell from just that one line. From cwhittl at gmail.com Wed Aug 13 17:55:28 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Wed, 13 Aug 2014 12:55:28 -0500 Subject: [Freeipa-users] Does FreeIPA support SHA or SSHA for password encryption Message-ID: We are looking at ONELogin as well as OKTA for our SSO to work with FreeIPA. The way they integrate with LDAP is a little different. The question I have is how does FreeIPA support SHA or SSHA for password encryption? *From One Login's help doc on LDAP* *--password-crypt: *Defines the cryptographic method used to store new passwords to your Ldap Server when a user changes his password on the OneLogin Web UI. Currently only SHA an SSHA are supported, SHA is the default value -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 13 20:05:41 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Aug 2014 16:05:41 -0400 Subject: [Freeipa-users] Adding permissions to a service account. In-Reply-To: <1407889670.20500.13.camel@ammy.its.adelaide.edu.au> References: <1407801317.20500.2.camel@ammy.its.adelaide.edu.au> <53EA541C.4090302@redhat.com> <1407889670.20500.13.camel@ammy.its.adelaide.edu.au> Message-ID: <53EBC515.5030709@redhat.com> William wrote: > On Tue, 2014-08-12 at 13:51 -0400, Rob Crittenden wrote: >> William wrote: >>> Hi, >>> >>> I am trying to allow a radius service account the ability to read >>> ipaNTHash. I carried out the following steps: >>> > >> >> You can't delegate permissions to a service. See >> https://fedorahosted.org/freeipa/ticket/3644 >> >> rob > > > For now, should I just add the service DN as a member of the role to > enable this? > Theoretically if you add the service as a member in the role using ldapmodify then yes, it should work functionally. What the IPA framework would do with this is another matter. Worst case it would blow up whenever trying to retrieve this role/privilege/permission/service (or a combination). rob From rcritten at redhat.com Wed Aug 13 20:10:01 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Aug 2014 16:10:01 -0400 Subject: [Freeipa-users] Does FreeIPA support SHA or SSHA for password encryption In-Reply-To: References: Message-ID: <53EBC619.3010104@redhat.com> Chris Whittle wrote: > We are looking at ONELogin as well as OKTA for our SSO to work with > FreeIPA. > > The way they integrate with LDAP is a little different. > > The question I have is how does FreeIPA support SHA or SSHA for password > encryption? > > *From One Login's help doc on LDAP* > > *--password-crypt: *Defines the cryptographic method used to store new > passwords to your Ldap Server when a user changes his password on the > OneLogin Web UI. Currently only SHA an SSHA are supported, SHA is the > default value This sounds rather strange to me. It sounds like it is going to pre-encrypt the password and send the hash. For IPA to work it would need to send the password in the clear (over GSSAPI or TLS of course) so that we can generate the Kerberos keys as well. 389-ds only accepts pre-encrypted hashes in certain cases anyway (it differs by version). You can look in cn=Password Storage Schemes,cn=plugins,cn=config for the list of available password hashes. Both SSHA and SHA are included by default. rob From rcritten at redhat.com Thu Aug 14 00:57:19 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Aug 2014 20:57:19 -0400 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <53EA32EF.9070606@gmail.com> References: <53E6DDEC.10105@gmail.com> <20140811141803.GA19977@redhat.com> <20140811142434.GB9920@hendrix.redhat.com> <53E8DC7A.6090102@redhat.com> <53EA2F11.3040606@gmail.com> <20140812152131.GK4748@redhat.com> <53EA32EF.9070606@gmail.com> Message-ID: <53EC096F.9050609@redhat.com> Erinn Looney-Triggs wrote: > On 08/12/2014 09:21 AM, Alexander Bokovoy wrote: >> On Tue, 12 Aug 2014, Erinn Looney-Triggs wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> On 08/11/2014 09:08 AM, Martin Kosek wrote: >>>> On 08/11/2014 04:24 PM, Jakub Hrozek wrote: >>>>> On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy >>>>> wrote: >>>>>> On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>>>> >>>>>>> It would seem to be prudent to set the minssf setting for >>>>>>> 389 to 56, however I am wondering why this isn't done by >>>>>>> default, and if there is any reason why I shouldn't do >>>>>>> it? >>>>>> Anonymous connection to LDAP wouldn't work. I think we use >>>>>> it for rootdse access when enrolling IPA clients where we >>>>>> don't yet have a CA certificate. >>>>>> >>>>>> I may be wrong, though. >>>>> >>>>> Also old (RHEL-5) SSSD versions rely on anonymous access to >>>>> be able to retrieve rootDSE. Newer (RHEL-6.3+) clients are >>>>> able to re-try fetching rootDSE once the authenticated >>>>> connection is established. >>>>> >>>> >>>> Also, older FreeIPA clients were not able to join those severs >>>> due to bug in ipa-client-install: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4459 >>>> >>>> This will be fixed in FreeIPA 4.0.2. Note that this only >>>> affects if you are changing MinSSF for whole DS by >>>> nsslapd-minssf. >>>> >>>> Martin >>>> >>> >>> I guess the part I don't get here, is that this setting does not >>> disable anonymous access to rootdse it just requires, as far as >>> I understand, that TLS or some security be used for the >>> connection. >>> >>> I currently have minssf set to 56 and am able to anonymously bind >>> and obtain the rootdse. >> This assumes you have CA certificate available so that you can >> successfully verify TLS handshake. When you are enrolling a client, >> you don't have the certificate yet. > > > However, this does bring up one more question in mind, why would the > initial installer care? > > I mean that if the intial connection for ipa-client-install is going > to be cleartext to what is basically an untrusted source at that point > why not just ignore CA issues and use a TLS connection anyway? Kind of > in the vein of the first ssh connection to a new host, the host > presents its keys and you can choose whether to trust them or not. In > the installers case trusting them for an anonymous bind would be just > as safe as doing an anonymous bind without tls. > > Does that make sense? Yeah, but the stuff we're doing isn't all that critical anyway and should be seemlessly skipped. What doesn't happen is the validation that the remote LDAP server is an IPA server. This would only be an issue for manual enrollments or if DNS returns the wrong records. rob From dpal at redhat.com Thu Aug 14 10:35:47 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 14 Aug 2014 12:35:47 +0200 Subject: [Freeipa-users] Local users/groups to IPA Transition In-Reply-To: References: <82E7C9A01FD0764CACDD35D10F5DFB6E701F11@001FSN2MPN1-044.001f.mgd2.msft.net> <53DA4FD2.8000108@redhat.com> Message-ID: <53EC9103.9070207@redhat.com> On 07/31/2014 04:45 PM, Baird, Josh wrote: >> I wouldn't recommend duplicating your users, pick one and use that. If you >> want to be able to manage your users, groups, HBAC, sudo, etc. >> centrally then you'll want the users in IPA. But if you leave them locally you >> may end up with corner case problems. >> >> If you *do* end up adding your local users to IPA then yeah, you've got a >> decision to make. Either your use the existing UID/GID which is probably fine >> (though you may want to look adding a local range) or you let IPA assign a >> new UID from its own range, then you have to quickly change file ownership >> on all enrolled systems. >> > Well, the users are definitely going to be in IPA (or AD via IPA). However, they *will* exist in both IPA and locally during the migration period. If they have the same UID/GIDs in both places (local and IPA), then I will need to prefer IPA to 'files' in nsswitch.conf. The main reason I want to duplicate the local UID/GID's in IPA is to retain file permissions. > > Josh > I want to add that IPA is working on the concept of views. This means that once it is implemented you would be able to have UID/GID in IPA and users in AD. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Aug 14 15:02:22 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 14 Aug 2014 17:02:22 +0200 Subject: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium In-Reply-To: References: <53E3B5C8.6090208@sesda3.com> <53E531B0.8030300@redhat.com> <53E6F58D.5090700@redhat.com> <53EA29AD.8040703@redhat.com> Message-ID: <53ECCF7E.3010503@redhat.com> On 08/12/2014 05:26 PM, Chris Whittle wrote: > Thanks Martin! Thank you for the contribution! Really appreciated. > > > On Tue, Aug 12, 2014 at 9:50 AM, Martin Kosek > wrote: > > Thank you! I liked this page to > http://www.freeipa.org/page/HowTos#Authentication > and also improved formatting of the page. I am not sure about the > "role" > section though, we do not use "role" objectclass, so Okta's search > probably > returns no results anyway. It may be better to keep that blank IMO. > > Martin > > On 08/12/2014 03:46 PM, Chris Whittle wrote: > > http://www.freeipa.org/page/HowTo/Integrate_With_Okta > > > > > > On Sat, Aug 9, 2014 at 11:31 PM, Dmitri Pal > wrote: > > > >> On 08/08/2014 04:26 PM, Chris Whittle wrote: > >> > >> Hey Dimitri, What do you mean? Both of them gave me the same > answer and > >> it worked. > >> > >> > >> Right, now you have the knowledge which is burred in a mail > thread and > >> would be hard to find for others that might want to follow your > steps. > >> I was hoping you would find some time to summarize your setup and > >> experience and share with others via a HOWTO page on the > FreeIPA site [1]. > >> > >> [1] http://www.freeipa.org/page/HowTos > >> > >> Thanks > >> Dmitri > >> > >> > >> On Aug 8, 2014 3:25 PM, "Dmitri Pal" > wrote: > >> > >>> On 08/07/2014 02:21 PM, Chris Whittle wrote: > >>> > >>> Thanks guys that works! > >>> > >>> > >>> > >>> And what about HOWTO? ;-) > >>> > >>> > >>> > >>> > >>> On Thu, Aug 7, 2014 at 12:22 PM, Lucas Yamanishi > > > >>> wrote: > >>> > >>>> On 08/07/2014 12:18 PM, Chris Whittle wrote: > >>>> > >>>> I'm currently working on a trial with OKTA and have installed > their > >>>> server agent with no issues. Now I'm trying to map FreeIPA > attributes with > >>>> OKTA's > >>>> > >>>> I'm getting no entries found, which leads me to think I'm > missing > >>>> something > >>>> [image: Inline image 1] > >>>> [image: Inline image 2] > >>>> [image: Inline image 3] > >>>> Thanks! > >>>> > >>>> > >>>> The objectClass values look incorrect. Try posixAccount and > posixGroup > >>>> for users and groups. Roles are groupOfNames, but that?s a > little less > >>>> specific and will match non-role entries without a search base. > >>>> > >>>> You can easily look up raw entries to check your mappings > with commands > >>>> like these (the ?all and ?raw options are available for all > *-show > >>>> commands, afaik): > >>>> > >>>> ipa user-show --all --raw $USER_NAME > >>>> ipa group-show --all --raw $GROUP > >>>> ipa role-show --all --raw $ROLE > >>>> > >>>> Or pure ldaputils: > >>>> > >>>> ldapsearch -LLL -YGSSAPI -b > 'cn=users,cn=accounts,dc=example,dc=com' 'uid=$USER_NAME' > >>>> > >>>> ? > >>>> > >>>> -- > >>>> ----- > >>>> *question everything*learn something*answer nothing* > >>>> ------------ > >>>> Lucas Yamanishi > >>>> ------------------ > >>>> Systems Administrator, ADNET Systems, Inc. > >>>> NASA Space and Earth Science Data Analysis (606.9) > >>>> 7515 Mission Drive, Suite A100 > >>>> Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB > >>>> > >>>> > >>>> -- > >>>> Manage your subscription for the Freeipa-users mailing list: > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>> Go To http://freeipa.org for more info on the project > >>>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Thank you, > >>> Dmitri Pal > >>> > >>> Sr. Engineering Manager IdM portfolio > >>> Red Hat, Inc. > >>> > >>> > >>> -- > >>> Manage your subscription for the Freeipa-users mailing list: > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>> Go To http://freeipa.org for more info on the project > >>> > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager IdM portfolio > >> Red Hat, Inc. > >> > >> > > > > > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyamanishi at sesda3.com Thu Aug 14 15:53:14 2014 From: lyamanishi at sesda3.com (Lucas Yamanishi) Date: Thu, 14 Aug 2014 11:53:14 -0400 Subject: [Freeipa-users] Certificate system unavailable [solved] In-Reply-To: <53E3EF3D.1030802@sesda3.com> References: <53E3A5D0.7010509@sesda3.com> <53E3B680.2080901@redhat.com> <53E3C874.60904@sesda3.com> <53E3E604.7080203@redhat.com> <53E3EF3D.1030802@sesda3.com> Message-ID: <53ECDB6A.9010004@sesda3.com> On 08/07/2014 05:27 PM, Lucas Yamanishi wrote: > On 08/07/2014 04:48 PM, Rob Crittenden wrote: >> Lucas Yamanishi wrote: >>> On 08/07/2014 01:25 PM, Rob Crittenden wrote: >>>> Lucas Yamanishi wrote: >>>>> Hello, I'm a bit of a pickle with the PKI system. I have three >>>>> replicas, but only one contains the CA. I realize how poor a decision >>>>> it was to do that. I plan to create more complete replicas, but right >>>>> now I can't even create a replica file, much less a full replica. >>>>> >>>>> The problem started when the CA subsystem certificates expired. I read >>>>> several threads explaining how to roll back time and renew them, but I >>>>> then discovered that the host and HTTP certificates for the server were >>>>> missing. I checked for backups, but we erroneously did not cover those >>>>> files. Because they are missing I was unable to rewnew any certificates. >>>>> >>>>> Is there a way to manually create host and service certificates? When I >>>>> search for this, the "manual" procedure listed in the documentation >>>>> requires `ipa cert-request` which does not work. I did try installing a >>>>> self-signed cert for HTTP with `ipa-server-certinstall`. That changed >>>>> the errors, but the commands still fail. The pki-ca services is running >>>>> OK, as far as I can tell. >>>>> >>>>> I also tried adding a CA instance to one of the other replicas with >>>>> `ipa-ca-install`, but it failed during the configuration phase. >>>> The subsystem certificate renewal should be independent of the web (and >>>> host) certificates. I'd focus on getting the CA back up, then we can see >>>> about getting a new web server certificate. >>>> >>>> Can you share the output of: getcert list >>>> >>>> You'll probably want to obfuscate the output as it contains the PIN to >>>> the private key database of the CA. >>>> >>>> rob >>> Here you go. I've also included `certutil -L` outputs. >>> >>> The *auditSigningCert* I tried resubmitting with the time rolled back. >>> The post-save command was also updated, because it wasn't done a year or >>> two back when it replaced our old CRL-signer. >>> >>> `getcert list`: >>> >>> ``` >>> Number of certificates and requests being tracked: 7. >> [ snip ] >> >> What version of IPA is this? > Sorry. It's 3.0.0-37.el6 on Scientific Linux 6x. 389ds is > 1.2.11.15-32.el6_5 and Dogtag is 9.0.3-32.el6. >> You need to modify a few more of these. Take a look at >> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master > Thanks. That was in my notes to do for the resubmits. The CS.cfg > changes were made a long while back, before the guide. I think the > ipa-pki-proxy.conf change was inherited with an upgrade. Those are > awesome, BTW, the rpm automated upgrades! The renew_ra_cert script, too. >> When you roll back time are you restarting the pki-cad service? > I think I did, but I can't recall. I will be sure to do it this > weekend when I try again. >> rob >> > Since you pointed out that the certificates and ipa commands should > not be dependent on each other I discovered that the host ticket > needed renewing. The version was out of sync. Running `kinit -kt > /etc/krb5.keytab host/badca.example.com at EXAMPLE.COM` fixed the ipa > commands and I now get the expected SSL_ERROR_EXPIRED_CERT_ALERT code > when doing a cert-request. Is there anything else I should look at? > > -- > ----- > *question everything*learn something*answer nothing* > ------------ > Lucas Yamanishi > ------------------ > Systems Administrator, ADNET Systems, Inc. > NASA Space and Earth Science Data Analysis (606.9) > 7515 Mission Drive, Suite A100 > Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB To follow up, the second try went well and everything is again running smoothly. I followed the `getcert stop-tracking`, `getcert start-tracking` procedure described in the *HOWTO Promote a CA* page for all certificates but the *auditSigningCert* on which I previously ran `getcert resubmit`. I'm not sure if it was related to the resubmit or some other side-effect, but the *auditSigningCert* saved into a new index of the NSS DB leaving two identically named indexes, whereas the others saved into their existing indexes on top of their old certificates. I don't know what effect the separate indexes might have had, if any, but I was worried a process selecting it by name would select the wrong cert. It was easy enough to fix by exporting them both in ASCII format, deleting them both, then importing them as a single file. certutil -L -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -a > /root/auditSigningCert.crt certutil -D -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' certutil -D -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' certutil -A -d /var/lib/pki-ca/alias -n 'auditSigningCert cert-pki-ca' -i /root/auditSigningCert.crt -t ',,P' Also, for some reason the RA certificate didn't properly publish. Manually running the post-save script was all it took to fix it. /usr/lib64/ipa/certmonger/renew_ra_cert -- ----- *question everything*learn something*answer nothing* ------------ Lucas Yamanishi ------------------ Systems Administrator, ADNET Systems, Inc. NASA Space and Earth Science Data Analysis (606.9) 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Aug 14 18:25:19 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 14 Aug 2014 20:25:19 +0200 Subject: [Freeipa-users] User auth for Samba 3 file server against IPA 3.0.0 In-Reply-To: References: <53C6FE58.6000503@redhat.com> <53E6FEA1.60107@redhat.com> Message-ID: <53ECFF0F.1090109@redhat.com> On 08/11/2014 09:29 PM, dbischof at hrz.uni-kassel.de wrote: > Hi, > > On Sun, 10 Aug 2014, Dmitri Pal wrote: >> On 07/21/2014 10:15 AM, dbischof at hrz.uni-kassel.de wrote: >>> On Wed, 16 Jul 2014, Dmitri Pal wrote: >>>> On 07/16/2014 07:16 AM, dbischof at hrz.uni-kassel.de wrote: >>>>> I have IPA running on a CentOS 6 server. This server also acts as >>>>> NFS- and Samba server. My Linux clients (openSUSE 13.1) work fine >>>>> (NFS, automount, user auth for ssh and display manager). >>>>> >>>>> Since I also have some Windows users, I want them to be able to >>>>> mount their homes via Samba using their IPA password. Just that, >>>>> no AD or other fancy stuff. >>>> >>>> Support of Windows users is still where it was. Code might have >>>> changed so the solution might not apply any more cleanly. Our >>>> general vision is that windows users belong to Windows and have to >>>> be either in AD or in Samba4. As soon as Samba 4 supports cross >>>> forest trusts we will make it supported. Then we will be able to >>>> support cases like you describe. >>>> >>>> Also right now Samba FS as a member of IPA domain does not work >>>> well. It should work better with SSSD 1.12.1 and IPA 4.1 when we >>>> make sure that all parts are in place but that would still have >>>> some problems when one has to come from windows client as there is >>>> no SSSD equivalent for windows clients. >>>> >>>> Bottom line: no, there is no better info, sorry. >>> >>> Bummer. Just to make sure: I don't want my Windows users to be able >>> to log on to their systems using IPA auth, they all have local >>> accounts. I just want them to be able to manually mount their home >>> shares. >> >> Sorry for a delayed response, I am slowly catching up on these >> threads. Mounting a share requires authentication with the account >> that Samba FS server knows about. Samba FS server until now could >> have been joined to AD only. Samba 4 DC can be used as an alternative >> of AD. But in both cases Samba FS yet can't be a member of the IPA >> domain. We are working on it. So once it is done you might be able to >> manually mount shares using the accounts managed by IPA. It is a >> question of couple months really so may be you can wait for this >> functionality to emerge and try it? > > will that feature (Samba shares w/ IPA accounts) be available for IPA > 3.0 as in RHEL/CentOS6 or for IPA4 only? Waiting another couple of > months would be perfectly ok for me, if I could then just update the > IPA package and do some additional configuration to make it work. I'd > happily take part in testing the feature in advance, too. > > > Mit freundlichen Gruessen/With best regards, > > --Daniel. > You would need SSSD 1.12.1 for this to work. CC to https://fedorahosted.org/sssd/ticket/1588 and you will get notifications on the status changes of the ticket. Once you see it closed you can grab a build and try it out. See help on the SSSD users list or on IRC. Thanks for offering testing, really appreciated. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From erinn.looneytriggs at gmail.com Thu Aug 14 19:32:26 2014 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 14 Aug 2014 13:32:26 -0600 Subject: [Freeipa-users] MinSSF suggestions? In-Reply-To: <53EC096F.9050609@redhat.com> References: <53E6DDEC.10105@gmail.com> <53EA32EF.9070606@gmail.com> <53EC096F.9050609@redhat.com> Message-ID: <2460326.52Ie0cX8pN@thin-mint2.abaqis.com> On Wednesday, August 13, 2014 08:57:19 PM Rob Crittenden wrote: > Erinn Looney-Triggs wrote: > > On 08/12/2014 09:21 AM, Alexander Bokovoy wrote: > >> On Tue, 12 Aug 2014, Erinn Looney-Triggs wrote: > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >>> > >>> On 08/11/2014 09:08 AM, Martin Kosek wrote: > >>>> On 08/11/2014 04:24 PM, Jakub Hrozek wrote: > >>>>> On Mon, Aug 11, 2014 at 05:18:03PM +0300, Alexander Bokovoy > >>>>> > >>>>> wrote: > >>>>>> On Sat, 09 Aug 2014, Erinn Looney-Triggs wrote: > >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >>>>>>> > >>>>>>> It would seem to be prudent to set the minssf setting for > >>>>>>> 389 to 56, however I am wondering why this isn't done by > >>>>>>> default, and if there is any reason why I shouldn't do > >>>>>>> it? > >>>>>> > >>>>>> Anonymous connection to LDAP wouldn't work. I think we use > >>>>>> it for rootdse access when enrolling IPA clients where we > >>>>>> don't yet have a CA certificate. > >>>>>> > >>>>>> I may be wrong, though. > >>>>> > >>>>> Also old (RHEL-5) SSSD versions rely on anonymous access to > >>>>> be able to retrieve rootDSE. Newer (RHEL-6.3+) clients are > >>>>> able to re-try fetching rootDSE once the authenticated > >>>>> connection is established. > >>>> > >>>> Also, older FreeIPA clients were not able to join those severs > >>>> due to bug in ipa-client-install: > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/4459 > >>>> > >>>> This will be fixed in FreeIPA 4.0.2. Note that this only > >>>> affects if you are changing MinSSF for whole DS by > >>>> nsslapd-minssf. > >>>> > >>>> Martin > >>> > >>> I guess the part I don't get here, is that this setting does not > >>> disable anonymous access to rootdse it just requires, as far as > >>> I understand, that TLS or some security be used for the > >>> connection. > >>> > >>> I currently have minssf set to 56 and am able to anonymously bind > >>> and obtain the rootdse. > >> > >> This assumes you have CA certificate available so that you can > >> successfully verify TLS handshake. When you are enrolling a client, > >> you don't have the certificate yet. > > > > However, this does bring up one more question in mind, why would the > > initial installer care? > > > > I mean that if the intial connection for ipa-client-install is going > > to be cleartext to what is basically an untrusted source at that point > > why not just ignore CA issues and use a TLS connection anyway? Kind of > > in the vein of the first ssh connection to a new host, the host > > presents its keys and you can choose whether to trust them or not. In > > the installers case trusting them for an anonymous bind would be just > > as safe as doing an anonymous bind without tls. > > > > Does that make sense? > > Yeah, but the stuff we're doing isn't all that critical anyway and > should be seemlessly skipped. What doesn't happen is the validation that > the remote LDAP server is an IPA server. This would only be an issue for > manual enrollments or if DNS returns the wrong records. > > rob Yeah I understand that, the stuff that you folks are doing I was not too concerned about. This whole thought process started because I was looking at the IDM manual and under the disabling anonymous bind section it had an ldapmodify command using the directory manager's credentials that were being sent in the clear. I filed a bug, it'll be fixed, but it got me thinking about how to protect folks from themselves and thus minssf. Anyway, there seem to be good reasons that things are as they are, maybe in you know, five years, when RHEL 5 goes away, this can be revisited. -Erinn -------------- 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 jhrozek at redhat.com Thu Aug 14 19:52:55 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 14 Aug 2014 21:52:55 +0200 Subject: [Freeipa-users] [SOLVED] getting auth to work with just IPA LDAP In-Reply-To: <20140813162835.GD29931@hendrix.redhat.com> References: <53EB74EF.6050201@gmail.com> <20140813162835.GD29931@hendrix.redhat.com> Message-ID: <20140814195255.GL3684@hendrix.redhat.com> On Wed, Aug 13, 2014 at 06:28:35PM +0200, Jakub Hrozek wrote: > On Wed, Aug 13, 2014 at 07:23:43AM -0700, Kat wrote: > > Hello fellow IPAers... > > > > Just wondering what I might be doing wrong. I have servers that just need to > > auth to the LDAP username/PW portion of IPA since they can't do Kerberos > > right now. > > > > What could I be missing -- I run the authconfig to setup and verify > > sssd.conf, but I continue to get: > > > > sshd[7010]: pam_sss(sshd:auth): received for user testuser: 9 > > (Authentication service cannot retrieve authentication info) > > > > The ports are open to the LDAP/IPA server, I can run ldapsearch commands, > > but it just won't authenticate. > > > > Any ideas? > > Can you post SSSD logs? > > The error code makes it sound like sssd can't reach the servers, but > it's very hard to tell from just that one line. This turned out to be a certificate problem. From mlasevich at lasevich.net Thu Aug 14 20:19:58 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Thu, 14 Aug 2014 13:19:58 -0700 Subject: [Freeipa-users] FreeIPA4 OTP vs PAM Message-ID: I am testing a simple setup with FreeIPA 4.0.1 server and a centos6.5 stock "ipa-client" package and I can get the regular password to work, but not otp login (otp login works in web ui). As I understood this, kinit is not expected to work (requires FAST) but PAM (which uses sssd, which supposed to supports/configure FAST by default) Indeed the kinit fails with "Generic preauthentication failure while getting initial credentials" but PAM/SSSD does not seem to work either. This is a brand new test domain with allow-all HBAC intact, so I do not think that is the issue I did not dive into this yet, but before I waste too much time I wanted to ask if centos 6.5 default ipa client expected to work with 2FA or not. Thanks -M -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at lasevich.net Thu Aug 14 20:23:13 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Thu, 14 Aug 2014 13:23:13 -0700 Subject: [Freeipa-users] Minimal permissions for "joiner" account? Message-ID: Is there somewhere a documented minimum set of permissions required to create a special role/account/principal to auto-join machines to the domain? I am not all too comfortable to run this as admin user and not quite ready to set up the orchestration needed to pre-join the host. Thanks, -M -------------- next part -------------- An HTML attachment was scrubbed... URL: From purpleidea at gmail.com Thu Aug 14 21:07:36 2014 From: purpleidea at gmail.com (James) Date: Thu, 14 Aug 2014 17:07:36 -0400 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: On Thu, Aug 14, 2014 at 4:23 PM, Michael Lasevich wrote: > I am not all too comfortable to run this as admin user and not quite ready > to set up the orchestration needed to pre-join the host. Re: orchestration, https://github.com/purpleidea/puppet-ipa Does this help? From mlasevich at lasevich.net Thu Aug 14 23:29:39 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Thu, 14 Aug 2014 16:29:39 -0700 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: Not that much. For one, I am using Salt instead if Puppet, but more importantly, if I am reading this correctly it seems to be just using full admin account. I can already do that. By orchestration I meant setting up the OTP for client join on the server, then passing that OTP to the client to join it. It is not that hard to throw together, but timing in this process can be problematic. I prefer to avoid it for the moment if I can and just create a non-admin account for this. On Thu, Aug 14, 2014 at 2:07 PM, James wrote: > On Thu, Aug 14, 2014 at 4:23 PM, Michael Lasevich > wrote: > > I am not all too comfortable to run this as admin user and not quite > ready > > to set up the orchestration needed to pre-join the host. > > Re: orchestration, > > https://github.com/purpleidea/puppet-ipa > > Does this help? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From purpleidea at gmail.com Fri Aug 15 00:00:43 2014 From: purpleidea at gmail.com (James) Date: Thu, 14 Aug 2014 20:00:43 -0400 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: On Thu, Aug 14, 2014 at 7:29 PM, Michael Lasevich wrote: > Not that much. For one, I am using Salt instead if Puppet, but more > importantly, if I am reading this correctly it seems to be just using full > admin account. I can already do that. By orchestration I meant setting up > the OTP for client join on the server, then passing that OTP to the client > to join it. It is not that hard to throw together, but timing in this > process can be problematic. I prefer to avoid it for the moment if I can and > just create a non-admin account for this. The point I was trying to make is that the puppet module I linked you to does all of this automatically for you. HTH, James From mlasevich at lasevich.net Fri Aug 15 00:29:08 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Thu, 14 Aug 2014 17:29:08 -0700 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: I appreciate it. Maybe I did not read it close enough, but it seemed to send the admin password to every client, which is what I am trying to avoid. I will take a closer look, maybe I can bite the bullet and implement the few lines of code that are required to make this work in Salt (it would take way too much work and be generally counterproductive to switch to Puppet). -M On Thu, Aug 14, 2014 at 2:07 PM, James wrote: > > On Thu, Aug 14, 2014 at 4:23 PM, Michael Lasevich > wrote: > > I am not all too comfortable to run this as admin user and not quite ready > > to set up the orchestration needed to pre-join the host. > > Re: orchestration, > > https://github.com/purpleidea/puppet-ipa > > Does this help? -------------- next part -------------- An HTML attachment was scrubbed... URL: From purpleidea at gmail.com Fri Aug 15 01:50:03 2014 From: purpleidea at gmail.com (James) Date: Thu, 14 Aug 2014 21:50:03 -0400 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: On Thu, Aug 14, 2014 at 8:29 PM, Michael Lasevich wrote: > I appreciate it. Maybe I did not read it close enough, but it seemed to send > the admin password to every client, which is what I am trying to avoid. Oh no!! Definitely not :) I went to great pains to specifically avoid this actually. If you're interested in how the DM and admin passwords are managed, read: https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ If you're interested in how the clients auth, they do so via getkeytab, and in order for that to work, puppet passes a temporary one-time password to the client, uses it, and verifies that _that_ client auth-ed. If the password isn't used by that client, then a new OTP is generated, and the original is discarded (as it was probably used by the wrong client, or maliciously in that rare scenario). All of this to say, that this was quite complex to write, so I would consider using the module as is (and even extending it as needed!). Secondly, I'd like to point out that I'm not doing any orchestration, only config management. Which means this can actually scale! > > I will take a closer look, maybe I can bite the bullet and implement the few > lines of code that are required to make this work in Salt (it would take way > too much work and be generally counterproductive to switch to Puppet). Of course I can only help with the puppet case, but if you don't switch (this module is a winning module, in the same way that rails saved ruby, so I would take a closer look) you can at least use it as a reference architecture when writing a salt module. That;s the beauty of Free Software! Good luck! HTH, James From PGrant at westfield.com Fri Aug 15 01:52:12 2014 From: PGrant at westfield.com (Peter Grant) Date: Fri, 15 Aug 2014 01:52:12 +0000 Subject: [Freeipa-users] IPA Master Issue - Not starting Message-ID: <96A72336A6B7174C9F0D4ADDB784B50E417D119A@AUPDC00-MBX01P.au.ad.westfield.com> Hi All, Have been thrown in the deep end with a Master Instance not starting. Not very familiar with IPA so hoping someone here is able to steer me in the right direction. Below is output from restarting and /var/log/messages [root at host~]# sudo ipactl restart Restarting Directory Service Shutting down dirsrv: DOMAIN-COM... server already stopped [FAILED] PKI-IPA... server already stopped [FAILED] *** Error: 2 instance(s) unsuccessfully stopped [FAILED] Starting dirsrv: DOMAIN-COM... [ OK ] PKI-IPA... [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [FAILED] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [FAILED] Starting Kerberos 5 Admin Server: [ OK ] Restarting DNS Service Stopping named: [ OK ] Starting named: [FAILED] Failed to restart DNS Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping named: [ OK ] Stopping httpd: [FAILED] Stopping pki-ca: [ OK ] Shutting down dirsrv: DOMAIN-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl [root at host ~]# 2014-08-15T11:43:44.010180+10:00 hostname ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_493' not found) 2014-08-15T11:43:46.323908+10:00 hostname named[6470]: starting BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 -u named 2014-08-15T11:43:46.324391+10:00 hostname named[6470]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' 2014-08-15T11:43:46.324459+10:00 host named[6470]: ---------------------------------------------------- 2014-08-15T11:43:46.324513+10:00 host named[6470]: BIND 9 is maintained by Internet Systems Consortium, 2014-08-15T11:43:46.324568+10:00 host named[6470]: Inc. (ISC), a non-profit 501(c)(3) public-benefit 2014-08-15T11:43:46.324621+10:00 host named[6470]: corporation. Support and training for BIND 9 are 2014-08-15T11:43:46.324673+10:00 host named[6470]: available at https://www.isc.org/support 2014-08-15T11:43:46.324719+10:00 host named[6470]: ---------------------------------------------------- 2014-08-15T11:43:46.324788+10:00 host named[6470]: adjusted limit on open files from 62000 to 1048576 2014-08-15T11:43:46.324852+10:00 host named[6470]: found 1 CPU, using 1 worker thread 2014-08-15T11:43:46.325227+10:00 host named[6470]: using up to 4096 sockets 2014-08-15T11:43:46.328360+10:00 host named[6470]: loading configuration from '/etc/named.conf' 2014-08-15T11:43:46.329001+10:00 host named[6470]: using default UDP/IPv4 port range: [1024, 65535] 2014-08-15T11:43:46.329275+10:00 host named[6470]: using default UDP/IPv6 port range: [1024, 65535] 2014-08-15T11:43:46.330699+10:00 host named[6470]: listening on IPv6 interfaces, port 53 2014-08-15T11:43:46.332657+10:00 host named[6470]: listening on IPv4 interface lo, 127.0.0.1#53 2014-08-15T11:43:46.333038+10:00 host named[6470]: listening on IPv4 interface eth0, 10.3.11.16#53 2014-08-15T11:43:46.333960+10:00 host named[6470]: generating session key for dynamic DNS 2014-08-15T11:43:46.334216+10:00 host named[6470]: sizing zone task pool based on 9 zones 2014-08-15T11:43:46.336307+10:00 host named[6470]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' 2014-08-15T11:43:46.434383+10:00 host named[6470]: Failed to init credentials (Decrypt integrity check failed) 2014-08-15T11:43:46.434884+10:00 host named[6470]: loading configuration: failure 2014-08-15T11:43:46.434991+10:00 host named[6470]: exiting (due to fatal error) 2014-08-15T11:43:47.435187+10:00 host ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm ?DOMAIN.COM') Thanks for any help anyone is able to provide. Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Aug 15 07:10:29 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 15 Aug 2014 09:10:29 +0200 Subject: [Freeipa-users] IPA Master Issue - Not starting In-Reply-To: <96A72336A6B7174C9F0D4ADDB784B50E417D119A@AUPDC00-MBX01P.au.ad.westfield.com> References: <96A72336A6B7174C9F0D4ADDB784B50E417D119A@AUPDC00-MBX01P.au.ad.westfield.com> Message-ID: <53EDB265.9020103@redhat.com> Hello, On 15.8.2014 03:52, Peter Grant wrote: > 2014-08-15T11:43:46.434383+10:00 host named[6470]: Failed to init credentials (Decrypt integrity check failed) > > 2014-08-15T11:43:46.434884+10:00 host named[6470]: loading configuration: failure > > 2014-08-15T11:43:46.434991+10:00 host named[6470]: exiting (due to fatal error) > > 2014-08-15T11:43:47.435187+10:00 host ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm ?DOMAIN.COM') For named issue please follow instructions on https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a3.FailedtoinitcredentialsorFailedtogetinitialcredentialsDecryptintegritycheckfailedorClientscredentialshavebeenrevoked It seems that /etc/named.keytab is somehow corrupted or obsolete. Also, KDC logs in /var/log/krb5kdc.log can tell you more. I hope that others will add ideas about other errors. -- Petr^2 Spacek From jhrozek at redhat.com Fri Aug 15 08:07:36 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 15 Aug 2014 10:07:36 +0200 Subject: [Freeipa-users] FreeIPA4 OTP vs PAM In-Reply-To: References: Message-ID: <20140815080736.GO3684@hendrix.redhat.com> On Thu, Aug 14, 2014 at 01:19:58PM -0700, Michael Lasevich wrote: > I did not dive into this yet, but before I waste too much time I wanted to > ask if centos 6.5 default ipa client expected to work with 2FA or not. No it's not, sorry. The 6.5 client is SSSD 1.9.x and there's a couple of fixes that landed during the 1.11 development such as: https://fedorahosted.org/sssd/ticket/2186 or: https://fedorahosted.org/sssd/ticket/2271 plus some other commits I see in git log which don't reference any ticket. I'd suggest to test using a centos 7.0 client. From mkosek at redhat.com Fri Aug 15 08:18:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 Aug 2014 10:18:18 +0200 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: <53EDC24A.6040705@redhat.com> On 08/14/2014 10:23 PM, Michael Lasevich wrote: > Is there somewhere a documented minimum set of permissions required to > create a special role/account/principal to auto-join machines to the domain? > > I am not all too comfortable to run this as admin user and not quite ready > to set up the orchestration needed to pre-join the host. > > Thanks, > > -M > > > You can simply create a system user or a joiner service and assign it a "Host Administrators" privilege: # ipa privilege-show "Host Administrators" Privilege name: Host Administrators Description: Host Administrators Permissions: add hosts, remove hosts, modify hosts, manage host ssh public keys, manage host keytab, enroll a host, retrieve certificates from the ca, revoke certificate, add krbprincipalname to a host Granting privilege to roles: IT Specialist HTH, Martin From mlasevich at lasevich.net Fri Aug 15 09:25:41 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Fri, 15 Aug 2014 02:25:41 -0700 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: Sorry, I did not intend to belittle your efforts - just misread the code (saw you pass in $admin and $password and made wrong assumption that $admin was admin username) as well as trying to avoid puppet as I find Salt much quicker and much simpler (and already established in my setup) I sat down tonight and threw together a quick salt reactor that does same thing as your module - creates the host account in IPA with a generated OTP password and joins the host to the domain using that generated OTP (and while at it, validates the host against AWS and populates the metadata into IPA) Ended up having to join the salt master to the domain, which I was avoiding doing for security reasons, but I can just disable IPA logins in PAM and call it a day. The nice bit is that it is using the host's keytab for authentication, so I do not need any extra credentials sitting around. Seems to be working just fine. :-). I ended up granting the salt-master host the "Host Administrators" privilege. It seems that "Host Enrollment" privilege is not sufficient to enroll hosts - go figure. The only thing that bugs me is that I am calling IPA python code from my salt reactor python code via subprocess - there has got to be a better, more direct way - but I found documentation too confusing to follow at 1 am - will be a project for another day. Thanks for your help. -M On Thu, Aug 14, 2014 at 6:50 PM, James wrote: > On Thu, Aug 14, 2014 at 8:29 PM, Michael Lasevich > wrote: > > I appreciate it. Maybe I did not read it close enough, but it seemed to > send > > the admin password to every client, which is what I am trying to avoid. > Oh no!! Definitely not :) I went to great pains to specifically avoid > this actually. If you're interested in how the DM and admin passwords > are managed, read: > > https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ > > If you're interested in how the clients auth, they do so via > getkeytab, and in order for that to work, puppet passes a temporary > one-time password to the client, uses it, and verifies that _that_ > client auth-ed. If the password isn't used by that client, then a new > OTP is generated, and the original is discarded (as it was probably > used by the wrong client, or maliciously in that rare scenario). > > All of this to say, that this was quite complex to write, so I would > consider using the module as is (and even extending it as needed!). > Secondly, I'd like to point out that I'm not doing any orchestration, > only config management. Which means this can actually scale! > > > > > > I will take a closer look, maybe I can bite the bullet and implement the > few > > lines of code that are required to make this work in Salt (it would take > way > > too much work and be generally counterproductive to switch to Puppet). > > Of course I can only help with the puppet case, but if you don't > switch (this module is a winning module, in the same way that rails > saved ruby, so I would take a closer look) you can at least use it as > a reference architecture when writing a salt module. That;s the beauty > of Free Software! > > Good luck! HTH, > James > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at lasevich.net Fri Aug 15 09:27:30 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Fri, 15 Aug 2014 02:27:30 -0700 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: <53EDC24A.6040705@redhat.com> References: <53EDC24A.6040705@redhat.com> Message-ID: Thanks, that was actually very helpful. "Host Enrollment" privilege does not actually allow you to enroll hosts, not sure what that is about. But "Host Administrators" worked just fine. -M On Fri, Aug 15, 2014 at 1:18 AM, Martin Kosek wrote: > On 08/14/2014 10:23 PM, Michael Lasevich wrote: > > Is there somewhere a documented minimum set of permissions required to > > create a special role/account/principal to auto-join machines to the > domain? > > > > I am not all too comfortable to run this as admin user and not quite > ready > > to set up the orchestration needed to pre-join the host. > > > > Thanks, > > > > -M > > > > > > > > You can simply create a system user or a joiner service and assign it a > "Host > Administrators" privilege: > > # ipa privilege-show "Host Administrators" > Privilege name: Host Administrators > Description: Host Administrators > Permissions: add hosts, remove hosts, modify hosts, manage host ssh > public keys, > manage host keytab, enroll a host, retrieve certificates > from > the ca, > revoke certificate, add krbprincipalname to a host > Granting privilege to roles: IT Specialist > > HTH, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlasevich at lasevich.net Fri Aug 15 09:29:11 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Fri, 15 Aug 2014 02:29:11 -0700 Subject: [Freeipa-users] FreeIPA4 OTP vs PAM In-Reply-To: <20140815080736.GO3684@hendrix.redhat.com> References: <20140815080736.GO3684@hendrix.redhat.com> Message-ID: Thanks, glad I asked before wasting time. On Fri, Aug 15, 2014 at 1:07 AM, Jakub Hrozek wrote: > On Thu, Aug 14, 2014 at 01:19:58PM -0700, Michael Lasevich wrote: > > I did not dive into this yet, but before I waste too much time I wanted > to > > ask if centos 6.5 default ipa client expected to work with 2FA or not. > > No it's not, sorry. The 6.5 client is SSSD 1.9.x and there's a couple of > fixes that landed during the 1.11 development such as: > https://fedorahosted.org/sssd/ticket/2186 > or: > https://fedorahosted.org/sssd/ticket/2271 > plus some other commits I see in git log which don't reference any ticket. > > I'd suggest to test using a centos 7.0 client. > > -- > Manage your subscription for 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 mkosek at redhat.com Fri Aug 15 10:26:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 Aug 2014 12:26:21 +0200 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: <53EDC24A.6040705@redhat.com> Message-ID: <53EDE04D.1000306@redhat.com> This may also be a bug. Host Enrollment privilege should be enough to join FreeIPA. We did many access control related fixes in FreeIPA 4.0 (like https://fedorahosted.org/freeipa/ticket/4252), it may got fixed there. If "Host Enrollment" permission is still failing for you in 4.0+, we would be interested to see the actual error so that we can fix it. Martin On 08/15/2014 11:27 AM, Michael Lasevich wrote: > Thanks, that was actually very helpful. > > "Host Enrollment" privilege does not actually allow you to enroll hosts, > not sure what that is about. But "Host Administrators" worked just fine. > > -M > > > On Fri, Aug 15, 2014 at 1:18 AM, Martin Kosek wrote: > >> On 08/14/2014 10:23 PM, Michael Lasevich wrote: >>> Is there somewhere a documented minimum set of permissions required to >>> create a special role/account/principal to auto-join machines to the >> domain? >>> >>> I am not all too comfortable to run this as admin user and not quite >> ready >>> to set up the orchestration needed to pre-join the host. >>> >>> Thanks, >>> >>> -M >>> >>> >>> >> >> You can simply create a system user or a joiner service and assign it a >> "Host >> Administrators" privilege: >> >> # ipa privilege-show "Host Administrators" >> Privilege name: Host Administrators >> Description: Host Administrators >> Permissions: add hosts, remove hosts, modify hosts, manage host ssh >> public keys, >> manage host keytab, enroll a host, retrieve certificates >> from >> the ca, >> revoke certificate, add krbprincipalname to a host >> Granting privilege to roles: IT Specialist >> >> HTH, >> Martin >> > From dpal at redhat.com Fri Aug 15 10:35:52 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 15 Aug 2014 12:35:52 +0200 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: <53EDE288.7080707@redhat.com> On 08/15/2014 11:25 AM, Michael Lasevich wrote: > Sorry, I did not intend to belittle your efforts - just misread the > code (saw you pass in $admin and $password and made wrong assumption > that $admin was admin username) as well as trying to avoid puppet as I > find Salt much quicker and much simpler (and already established in my > setup) > > I sat down tonight and threw together a quick salt reactor that does > same thing as your module - creates the host account in IPA with a > generated OTP password and joins the host to the domain using that > generated OTP (and while at it, validates the host against AWS and > populates the metadata into IPA) Ended up having to join the salt > master to the domain, which I was avoiding doing for security reasons, > but I can just disable IPA logins in PAM and call it a day. The nice > bit is that it is using the host's keytab for authentication, so I do > not need any extra credentials sitting around. Seems to be working > just fine. :-). I ended up granting the salt-master host the "Host > Administrators" privilege. It seems that "Host Enrollment" privilege > is not sufficient to enroll hosts - go figure. > > The only thing that bugs me is that I am calling IPA python code from > my salt reactor python code via subprocess - there has got to be a > better, more direct way - but I found documentation too confusing to > follow at 1 am - will be a project for another day. > > Thanks for your help. > Great that it is working for you! Would you mind may be putting together a howto page based on your setup for others to benefit from your sleepless night? http://www.freeipa.org/page/HowTos Thanks Dmitri > -M > > > On Thu, Aug 14, 2014 at 6:50 PM, James > wrote: > > On Thu, Aug 14, 2014 at 8:29 PM, Michael Lasevich > > wrote: > > I appreciate it. Maybe I did not read it close enough, but it > seemed to send > > the admin password to every client, which is what I am trying to > avoid. > Oh no!! Definitely not :) I went to great pains to specifically avoid > this actually. If you're interested in how the DM and admin passwords > are managed, read: > https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ > > If you're interested in how the clients auth, they do so via > getkeytab, and in order for that to work, puppet passes a temporary > one-time password to the client, uses it, and verifies that _that_ > client auth-ed. If the password isn't used by that client, then a new > OTP is generated, and the original is discarded (as it was probably > used by the wrong client, or maliciously in that rare scenario). > > All of this to say, that this was quite complex to write, so I would > consider using the module as is (and even extending it as needed!). > Secondly, I'd like to point out that I'm not doing any orchestration, > only config management. Which means this can actually scale! > > > > > > I will take a closer look, maybe I can bite the bullet and > implement the few > > lines of code that are required to make this work in Salt (it > would take way > > too much work and be generally counterproductive to switch to > Puppet). > > Of course I can only help with the puppet case, but if you don't > switch (this module is a winning module, in the same way that rails > saved ruby, so I would take a closer look) you can at least use it as > a reference architecture when writing a salt module. That;s the beauty > of Free Software! > > Good luck! HTH, > James > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Aug 15 10:51:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 15 Aug 2014 12:51:14 +0200 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: <53EDE622.8000407@redhat.com> On 08/15/2014 11:25 AM, Michael Lasevich wrote: ... > The only thing that bugs me is that I am calling IPA python code from my > salt reactor python code via subprocess - there has got to be a better, > more direct way - but I found documentation too confusing to follow at 1 > am - will be a project for another day. Would the example below help? # kinit admin Password for admin at MKOSEK-FEDORA20.TEST: [root at ipa ~]# python Python 2.7.5 (default, Jun 25 2014, 10:19:55) [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from ipalib import api >>> api.bootstrap(context='exporter', debug=False) >>> api.finalize() >>> api.Backend.rpcclient.connect() ipa: INFO: trying https://ipa.mkosek-fedora20.test/ipa/json >>> >>> hosts = api.Command['host_find']()['result'] ipa: INFO: Forwarding 'host_find' to json server 'https://ipa.mkosek-fedora20.test/ipa/json' >>> >>> for host in hosts: ... print host['fqdn'][0] ... ipa.mkosek-fedora20.test >>> This works with FreeIPA 4.0. For older FreeIPA, you would need to switch rpcclient attribute for xmlclient. I admit we do not have the best developer documentation on how to do that. We plan to do that in the future, so far we were focusing on other things. Martin From pspacek at redhat.com Fri Aug 15 11:46:08 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 15 Aug 2014 13:46:08 +0200 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: <53EDE622.8000407@redhat.com> References: <53EDE622.8000407@redhat.com> Message-ID: <53EDF300.3020206@redhat.com> On 15.8.2014 12:51, Martin Kosek wrote: > On 08/15/2014 11:25 AM, Michael Lasevich wrote: > ... >> The only thing that bugs me is that I am calling IPA python code from my >> salt reactor python code via subprocess - there has got to be a better, >> more direct way - but I found documentation too confusing to follow at 1 >> am - will be a project for another day. > > Would the example below help? > > # kinit admin > Password for admin at MKOSEK-FEDORA20.TEST: > [root at ipa ~]# python > Python 2.7.5 (default, Jun 25 2014, 10:19:55) > [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> from ipalib import api >>>> api.bootstrap(context='exporter', debug=False) >>>> api.finalize() >>>> api.Backend.rpcclient.connect() > ipa: INFO: trying https://ipa.mkosek-fedora20.test/ipa/json >>>> >>>> hosts = api.Command['host_find']()['result'] > ipa: INFO: Forwarding 'host_find' to json server > 'https://ipa.mkosek-fedora20.test/ipa/json' >>>> >>>> for host in hosts: > ... print host['fqdn'][0] > ... > ipa.mkosek-fedora20.test >>>> > > This works with FreeIPA 4.0. For older FreeIPA, you would need to switch > rpcclient attribute for xmlclient. > > I admit we do not have the best developer documentation on how to do that. We > plan to do that in the future, so far we were focusing on other things. Anyway, blog posts and how-tos are more than welcome! :-) Please let others know about your experiments with FreeIPA API! -- Petr^2 Spacek From stacy.redmond at blueshieldca.com Fri Aug 15 14:33:40 2014 From: stacy.redmond at blueshieldca.com (Redmond, Stacy) Date: Fri, 15 Aug 2014 07:33:40 -0700 Subject: [Freeipa-users] Enabling ntp if not done during ipa-server-install Message-ID: <77D4DA314ADF354BBE2686CBBAB9DD790EB729EC@EDHC01WEX02.bsc.bscal.com> I installed my ipa server with -no-ntp but find that I want to enable it on my server, and all my replicas. Is it possible to do post install? Stacy Redmond | Unix/Linux System Administrator Build Engineering | Bluedof California 4203 Town Center Boulevard | El Dorado Hills, CA 95762 Desk: 916.350.7912 | FAX: 916.350.8943 Email: Stacy Redmond at blueshieldca.com "This message (including any attachments) contains business proprietary/confidentialinformation intended for a specific individual and purpose and is protected by law. If you are not the intended recipient, you should delete this message and all attachments from your computer or email server. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, without the express permission of the originator, is strictly prohibited." -------------- next part -------------- An HTML attachment was scrubbed... URL: From purpleidea at gmail.com Fri Aug 15 16:02:36 2014 From: purpleidea at gmail.com (James) Date: Fri, 15 Aug 2014 12:02:36 -0400 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: On Fri, Aug 15, 2014 at 5:25 AM, Michael Lasevich wrote: > Sorry, I did not intend to belittle your efforts - just misread the code Didn't take it that way, no worries :) > (saw you pass in $admin and $password and made wrong assumption that $admin > was admin username) as well as trying to avoid puppet as I find Salt much > quicker and much simpler (and already established in my setup) > > I sat down tonight and threw together a quick salt reactor that does same > thing as your module - creates the host account in IPA with a generated OTP > password and joins the host to the domain using that generated OTP (and > while at it, validates the host against AWS and populates the metadata into > IPA) Ended up having to join the salt master to the domain, which I was > avoiding doing for security reasons, but I can just disable IPA logins in > PAM and call it a day. The nice bit is that it is using the host's keytab > for authentication, so I do not need any extra credentials sitting around. > Seems to be working just fine. :-). I ended up granting the salt-master host > the "Host Administrators" privilege. It seems that "Host Enrollment" > privilege is not sufficient to enroll hosts - go figure. Great! > > The only thing that bugs me is that I am calling IPA python code from my > salt reactor python code via subprocess - there has got to be a better, more > direct way - but I found documentation too confusing to follow at 1 am - > will be a project for another day. There is the python ipa API, not sure how stable or official it is, but if you look in my code I use it occasionally. > > Thanks for your help. Cheers, James From pviktori at redhat.com Fri Aug 15 16:26:36 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 15 Aug 2014 18:26:36 +0200 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: Message-ID: <53EE34BC.30805@redhat.com> On 08/15/2014 06:02 PM, James wrote: > On Fri, Aug 15, 2014 at 5:25 AM, Michael Lasevich > wrote: >> Sorry, I did not intend to belittle your efforts - just misread the code > Didn't take it that way, no worries :) > >> (saw you pass in $admin and $password and made wrong assumption that $admin >> was admin username) as well as trying to avoid puppet as I find Salt much >> quicker and much simpler (and already established in my setup) >> >> I sat down tonight and threw together a quick salt reactor that does same >> thing as your module - creates the host account in IPA with a generated OTP >> password and joins the host to the domain using that generated OTP (and >> while at it, validates the host against AWS and populates the metadata into >> IPA) Ended up having to join the salt master to the domain, which I was >> avoiding doing for security reasons, but I can just disable IPA logins in >> PAM and call it a day. The nice bit is that it is using the host's keytab >> for authentication, so I do not need any extra credentials sitting around. >> Seems to be working just fine. :-). I ended up granting the salt-master host >> the "Host Administrators" privilege. It seems that "Host Enrollment" >> privilege is not sufficient to enroll hosts - go figure. > Great! > >> >> The only thing that bugs me is that I am calling IPA python code from my >> salt reactor python code via subprocess - there has got to be a better, more >> direct way - but I found documentation too confusing to follow at 1 am - >> will be a project for another day. > There is the python ipa API, not sure how stable or official it is, > but if you look in my code I use it occasionally. The RPC API is not official (i.e. documented), but since IPA needs to keep backwards compatibility with its own client, it's very stable. Just be sure to send the API version with each call. (The server will send a warning if you don't.) -- Petr? From lyamanishi at sesda3.com Fri Aug 15 18:11:14 2014 From: lyamanishi at sesda3.com (Lucas Yamanishi) Date: Fri, 15 Aug 2014 14:11:14 -0400 Subject: [Freeipa-users] Enabling ntp if not done during ipa-server-install In-Reply-To: <77D4DA314ADF354BBE2686CBBAB9DD790EB729EC@EDHC01WEX02.bsc.bscal.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790EB729EC@EDHC01WEX02.bsc.bscal.com> Message-ID: <53EE4D42.1000304@sesda3.com> On 08/15/2014 10:33 AM, Redmond, Stacy wrote: > I installed my ipa server with ?no-ntp but find that I want to enable > it on my server, and all my replicas. Is it possible to do post install? > > > > *Stacy Redmond | *Unix/Linux System Administrator > > Build Engineering | Bluedof California > > 4203 Town Center Boulevard | El Dorado Hills, CA 95762 > > *Desk:*916.350.7912 | *FAX:* 916.350.8943 > > *Email:*Stacy Redmond at blueshieldca.com > > > > > > ?This message (including any attachments) contains business > proprietary/confidentialinformation intended for a specific individual > and purpose and is protected by law. If you are not the intended > recipient, you should delete this message and all attachments from > your computer or email server. Any disclosure, copying, or > distribution of this message, or the taking of any action based on it, > without the express permission of the originator, is strictly prohibited.? > > > > > Yes, you can do that. There?s no |ipa-ntp-install| command, because /NTP isn?t integrated with FreeIPA as much as it?s a good idea to run it along side FreeIPA/; Kerberos and other crypto operations depend on good time-sync. All you need to do to replicate the default |ipa-server-install| behavior (without ?no-ntp) is enable inbound connections to /ntpd/, add the other servers to its server list, and for extra credit add an /SRV/ resource record for each server. (Does anything actually uses the SRV records?) /ntpd(8)/ should be installed, but make sure? it?s usually just called /ntp/. You?ll then need to open UDP port 123 and configure the daemon appropriately. Here?s an example |/etc/ntp.conf| file (it assumes there are two other servers in the cluster, ipa2 and ipa3; edit as you see fit): |# ntp.conf # # Keep ntpd from panicking in the event of a large clock skew # when a VM guest is suspended and resumed. # (disable this if running on a physical machine with a battery-backed RTC) tinker panic 0 # Permit time synchronization with our time source, but do not' # permit the source to query or modify the service on this system.' restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 # Servers server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server 3.pool.ntp.org server ipa2.example.com server ipa3.example.com # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. # (disable this if running on a virtual machine) server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 # Driftfile. driftfile /var/lib/ntp/drift | Run this command to add an SRV RR for /ipa1.example.com/ (don?t forget the trailing dot): |ipa dnsrecord-add example.com _ntp._udp --srv-priority=0 --srv-weight=100 --srv-port=123 --srv-target=ipa1.example.com. | ? -- ----- *question everything*learn something*answer nothing* ------------ Lucas Yamanishi ------------------ Systems Administrator, ADNET Systems, Inc. NASA Space and Earth Science Data Analysis (606.9) 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri Aug 15 18:46:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 15 Aug 2014 20:46:09 +0200 Subject: [Freeipa-users] Enabling ntp if not done during ipa-server-install In-Reply-To: <53EE4D42.1000304@sesda3.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790EB729EC@EDHC01WEX02.bsc.bscal.com> <53EE4D42.1000304@sesda3.com> Message-ID: <53EE5571.2030902@redhat.com> On 08/15/2014 08:11 PM, Lucas Yamanishi wrote: > On 08/15/2014 10:33 AM, Redmond, Stacy wrote: > >> I installed my ipa server with ?no-ntp but find that I want to enable >> it on my server, and all my replicas. Is it possible to do post install? > Yes, you can do that. There?s no |ipa-ntp-install| command, because /NTP > isn?t integrated with FreeIPA as much as it?s a good idea to run it > along side FreeIPA/; Kerberos and other crypto operations depend on good > time-sync. All you need to do to [...] Thanks for the instructions, Lucas. Adding it may be easy, but users don't necessarily know that, so it would make sense to provide an ipa-ntp-install command to take care of all the details. I filed a RFE for ipa-ntp-install: https://fedorahosted.org/freeipa/ticket/4497 -- Petr? From simo at redhat.com Fri Aug 15 19:51:25 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 15 Aug 2014 15:51:25 -0400 Subject: [Freeipa-users] Enabling ntp if not done during ipa-server-install In-Reply-To: <53EE5571.2030902@redhat.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790EB729EC@EDHC01WEX02.bsc.bscal.com> <53EE4D42.1000304@sesda3.com> <53EE5571.2030902@redhat.com> Message-ID: <1408132285.15168.47.camel@willson.usersys.redhat.com> On Fri, 2014-08-15 at 20:46 +0200, Petr Viktorin wrote: > On 08/15/2014 08:11 PM, Lucas Yamanishi wrote: > > On 08/15/2014 10:33 AM, Redmond, Stacy wrote: > > > >> I installed my ipa server with ?no-ntp but find that I want to enable > >> it on my server, and all my replicas. Is it possible to do post install? > > > Yes, you can do that. There?s no |ipa-ntp-install| command, because /NTP > > isn?t integrated with FreeIPA as much as it?s a good idea to run it > > along side FreeIPA/; Kerberos and other crypto operations depend on good > > time-sync. All you need to do to [...] > > Thanks for the instructions, Lucas. > > > Adding it may be easy, but users don't necessarily know that, so it > would make sense to provide an ipa-ntp-install command to take care of > all the details. > I filed a RFE for ipa-ntp-install: > https://fedorahosted.org/freeipa/ticket/4497 IIRC Ntpd also supports an interface (may require patching) to allow signing packets (I remember vaguely samba AD has an interface for this). Maybe we should open a ticket to make use of that too and really formally integrate and configure ntpd to sign outgoing packets. Simo. -- Simo Sorce * Red Hat, Inc * New York From mheslin at redhat.com Fri Aug 15 20:58:36 2014 From: mheslin at redhat.com (Mark Heslin) Date: Fri, 15 Aug 2014 16:58:36 -0400 Subject: [Freeipa-users] Enabling ntp if not done during ipa-server-install In-Reply-To: <1408132285.15168.47.camel@willson.usersys.redhat.com> References: <77D4DA314ADF354BBE2686CBBAB9DD790EB729EC@EDHC01WEX02.bsc.bscal.com> <53EE4D42.1000304@sesda3.com> <53EE5571.2030902@redhat.com> <1408132285.15168.47.camel@willson.usersys.redhat.com> Message-ID: <53EE747C.3010600@redhat.com> On 08/15/2014 03:51 PM, Simo Sorce wrote: > On Fri, 2014-08-15 at 20:46 +0200, Petr Viktorin wrote: >> On 08/15/2014 08:11 PM, Lucas Yamanishi wrote: >>> On 08/15/2014 10:33 AM, Redmond, Stacy wrote: >>> >>>> I installed my ipa server with ?no-ntp but find that I want to enable >>>> it on my server, and all my replicas. Is it possible to do post install? >>> Yes, you can do that. There?s no |ipa-ntp-install| command, because /NTP >>> isn?t integrated with FreeIPA as much as it?s a good idea to run it >>> along side FreeIPA/; Kerberos and other crypto operations depend on good >>> time-sync. All you need to do to [...] >> Thanks for the instructions, Lucas. >> >> >> Adding it may be easy, but users don't necessarily know that, so it >> would make sense to provide an ipa-ntp-install command to take care of >> all the details. >> I filed a RFE for ipa-ntp-install: >> https://fedorahosted.org/freeipa/ticket/4497 > IIRC Ntpd also supports an interface (may require patching) to allow > signing packets (I remember vaguely samba AD has an interface for this). > > Maybe we should open a ticket to make use of that too and really > formally integrate and configure ntpd to sign outgoing packets. > > Simo. > I just wanted to add 2 points that may or may not apply to you: 1. The RHEL7 IdM guide recommends *not* running NTP on an IdM server that is on a VM: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prerequisites.html#prereq-ntp It's not entirely clear to me whether this still holds true today or if it's an old documentation artifact. 2. For RHEL 7, the default time service is chronyd, not ntpd. From my readings it appears that chronyd is primarily for "mobile" devices like laptops. If you're running IdM on a RHEL 7 server then I'd suggest masking the chronyd service (systemctl mask chronyd) and enabling ntpd just as outlined in the OSE-IdM reference architecture: https://access.redhat.com/articles/1155603 See sections 2.2.5 Time Services (ntpd, chronyd) and 4.5 Configure Time Service (NTP). -m From purpleidea at gmail.com Mon Aug 18 04:05:47 2014 From: purpleidea at gmail.com (James) Date: Mon, 18 Aug 2014 00:05:47 -0400 Subject: [Freeipa-users] Multi-OS FreeIPA in puppet-ipa Message-ID: <1408334747.10563.6.camel@freed> I've just pushed out a WIP feature branch for multi-os puppet-ipa. This is an elegant way to create a multi-os compatible puppet module. It can be useful for managing differences between RHEL and Debian, but also between CentOS and RHEL, and even RHEL 6.x and RHEL 7, etc... Some background on the technique when I did this for puppet-gluster: https://ttboj.wordpress.com/2014/06/04/hiera-data-in-modules-and-os-independent-puppet/ Since I'm only currently testing CentOS/RHEL 6.x, please report any issues with other versions or OS's, and I'll patch them ASAP. WIP branch: https://github.com/purpleidea/puppet-ipa/tree/feat/yamldata I'll rebase this branch as new patches are added, and I'll usually keep it current against git master. Once someone ACK's that it is working against another OS or version, then I'll maintain it in git master. Thank you, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From Duncan.Innes at virginmoney.com Mon Aug 18 07:49:28 2014 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Mon, 18 Aug 2014 08:49:28 +0100 Subject: [Freeipa-users] PatternFly questions In-Reply-To: <56343345B145C043AE990701E3D193950478DFF8@EXVS2.nrplc.localnet> References: <56343345B145C043AE990701E3D193950478DFA8@EXVS2.nrplc.localnet> <53C04561.2000400@redhat.com> <53C7DF1E.3040909@redhat.com> <56343345B145C043AE990701E3D193950478DFEF@EXVS2.nrplc.localnet> <53C8F5A7.2020005@redhat.com> <56343345B145C043AE990701E3D193950478DFF6@EXVS2.nrplc.localnet><53C91D26.2010203@redhat.com><53C91FB9.9010409@redhat.com> <53C93878.9050304@redhat.com> <56343345B145C043AE990701E3D193950478DFF8@EXVS2.nrplc.localnet> Message-ID: <56343345B145C043AE990701E3D193950478E02B@EXVS2.nrplc.localnet> Bump Back to work now - do you want RFE's written up for this stuff, or do you have it in hand? D -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Innes, Duncan Sent: 31 July 2014 21:47 To: dpal at redhat.com; Martin Kosek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] PatternFly questions Hi, Sorry for delay - paternity leave took me away from work rather abruptly. Do you still want RFE's written up for these? My brain might have been fried when I thought about this, but is there any mileage in creating an elasticsearch (or similar) database of the useful fields and using that for searching? If LDAP searches are the limiting factor that is. Keeping the databases in sync might be an issue, but the elasticsearch database would be read-only for users and would allow a potentially richer method of searching. Back at work on Monday, so should be able to write up some RFE's then if they're still needed. Cheers D -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: 18 July 2014 16:09 To: Martin Kosek; freeipa-users at redhat.com Subject: Re: [Freeipa-users] PatternFly questions On 07/18/2014 09:23 AM, Martin Kosek wrote: > On 07/18/2014 03:12 PM, Dmitri Pal wrote: >> On 07/18/2014 08:17 AM, Innes, Duncan wrote: >>> Hi Petr, >>> >>> On 18/07/2014 11:24, Petr Vobornik wrote: >>>> Hello Duncan, >>>> >>>> thank you for the input. If you or somebody else have any Web UI >>> ideas/RFEs, feel free to write them down. I would like to >>>> know what people don't like or would like to have. >>>> >>>> On 18.7.2014 10:21, Innes, Duncan wrote: >>>>> Just poking around the new 4.0 demo page and very much liking what >>>>> I >>> see. This will make a >>>>> big difference in use on large estates. >>>>> >>>>> A couple PatternFly related questions though: >>>>> >>>>> 1. The tables don't sort by column if I click on a column header. >>> Is this not available in PatternFly yet, >>>>> or have FreeIPA decided against implementing it? >>>> First just a note about PatternFly. It's not really a widget >>>> library, >>> it is(or should be) more of a set of patterns and >>>> styles. But the referential implementation is built on Bootstrap 3, >>>> so >>> it is very easy to adopt. PatternFly doesn't have an >>>> official pattern for table sorting yet, but it has styles for >>> DataTables (jQuery table plugin) which can do it. >>>> I don't remember any decision against it -> could be implemented if >>> there is enough will and user demand. >>>> Sorting can be done on client side and on server side. Client side >>>> is >>> limited to issue #2 - only 20 items, so it is not really >>>> helpful. >>>> >>>> And server side (IPA API) doesn't support specifying a sort >>>> attribute >>> atm. >>>> You would like the server-side sorting, right? >>>> >>> Hadn't considered there to be an option. When I looked at the >>> PatternFly demos I hadn't thought about it, but the speed that >>> FreeIPA pulls data out for rendering, I suppose it would have to be. >>> Even our modest estate (at a few hundred users and hosts) would slow >>> down far too much if the full dataset was sent. >>> >>> The other possibilities thrown up by PatternFly are also >>> interesting; add/remove columns, resize columns etc. I know some of >>> these are still on the drawing board, but there are demo pages >>> available already. >>> >>>>> 2. Browsing the screen on a large monitor still leaves the user >>>>> page >>> (at least) limited to around 22 rows. >>>>> This leaves the bottom third of my browser empty. The table >>>>> uses >>> the full width of the browser, can it >>>>> not use the full height too? >>>> I have and idea/plan to make it configurable - to specify the >>>> number >>> of items and also to allow disabling of paging. >>>> The more rows the slower the UI is. Also paging has its own issues >>> which are not straightforward to solve: >>>> - >>> http://www.redhat.com/archives/freeipa-devel/2012-August/msg00295.ht >>> ml True. What's the biggest time factor in loading large tables? >>> >>> When admining estates with tens of thousands of entries, however, >>> much emphasis needs to be placed on the table filters. No admin in >>> their right mind is going to be performing actions on all entries >>> simultaneously. Similar to Foreman's filters, could FreeIPA allow >>> (example) in the hosts screen a filter of "hostgroup = groupX" to >>> show only hosts belonging to that group? Or filtering users with >>> "manager = 'Duncan Innes'"? >> Please open RFEs. This is really a valuable feedback. > I think we are somewhat talking about this RFE: > > https://fedorahosted.org/freeipa/ticket/2388 > > Maybe it is time to resurrect it from Ticket Deferred milestone given > it would bring big value for large user deployments. > > The API and the mighty LDAP search engine is already there: > > ipa user-add --first=Test --last=User manager ipa user-add > --first=Test --last=User employee --manager manager ipa user-add > --first=Test --last=User employee2 --manager manager ipa group-add > testgroup --desc test ipa group-add-member testgroup --users employee2 > > > # ipa user-find --manager manager --pkey-only > --------------- > 2 users matched > --------------- > User login: employee > > User login: employee2 > ---------------------------- > Number of entries returned 2 > ---------------------------- > > # ipa user-find --manager manager --in-group testgroup --pkey-only > -------------- > 1 user matched > -------------- > User login: employee2 > ---------------------------- > Number of entries returned 1 > > > So we would just need to utilize it in our Web UI. I personally really > like the simple search tags like below > > > > that can be seen in some web apps or eshops and which are pretty easy to control. > > Martin Moved to needs triage. It will be a nice UI feature for 4.2. Taking a note. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.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 This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From mkosek at redhat.com Mon Aug 18 10:29:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 Aug 2014 12:29:30 +0200 Subject: [Freeipa-users] PatternFly questions In-Reply-To: <56343345B145C043AE990701E3D193950478E02B@EXVS2.nrplc.localnet> References: <56343345B145C043AE990701E3D193950478DFA8@EXVS2.nrplc.localnet> <53C04561.2000400@redhat.com> <53C7DF1E.3040909@redhat.com> <56343345B145C043AE990701E3D193950478DFEF@EXVS2.nrplc.localnet> <53C8F5A7.2020005@redhat.com> <56343345B145C043AE990701E3D193950478DFF6@EXVS2.nrplc.localnet><53C91D26.2010203@redhat.com><53C91FB9.9010409@redhat.com> <53C93878.9050304@redhat.com> <56343345B145C043AE990701E3D193950478DFF8@EXVS2.nrplc.localnet> <56343345B145C043AE990701E3D193950478E02B@EXVS2.nrplc.localnet> Message-ID: <53F1D58A.9050008@redhat.com> Hello Duncan, I think we are all set. As written below, I revisited the RFE that was filed previously: https://fedorahosted.org/freeipa/ticket/2388 And added information from this thread. It is currently planned for FreeIPA 4.2 as our Web UI could indeed benefit from this functionality. If we missed anything, please feel free to update the ticket. THanks, Martin On 08/18/2014 09:49 AM, Innes, Duncan wrote: > Bump > > Back to work now - do you want RFE's written up for this stuff, or do > you have it in hand? > > D > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Innes, Duncan > Sent: 31 July 2014 21:47 > To: dpal at redhat.com; Martin Kosek; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] PatternFly questions > > Hi, > > Sorry for delay - paternity leave took me away from work rather > abruptly. > > Do you still want RFE's written up for these? > > My brain might have been fried when I thought about this, but is there > any mileage in creating an elasticsearch (or similar) database of the > useful fields and using that for searching? If LDAP searches are the > limiting factor that is. Keeping the databases in sync might be an > issue, but the elasticsearch database would be read-only for users and > would allow a potentially richer method of searching. > > Back at work on Monday, so should be able to write up some RFE's then if > they're still needed. > > Cheers > > D > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal > Sent: 18 July 2014 16:09 > To: Martin Kosek; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] PatternFly questions > > On 07/18/2014 09:23 AM, Martin Kosek wrote: >> On 07/18/2014 03:12 PM, Dmitri Pal wrote: >>> On 07/18/2014 08:17 AM, Innes, Duncan wrote: >>>> Hi Petr, >>>> >>>> On 18/07/2014 11:24, Petr Vobornik wrote: >>>>> Hello Duncan, >>>>> >>>>> thank you for the input. If you or somebody else have any Web UI >>>> ideas/RFEs, feel free to write them down. I would like to >>>>> know what people don't like or would like to have. >>>>> >>>>> On 18.7.2014 10:21, Innes, Duncan wrote: >>>>>> Just poking around the new 4.0 demo page and very much liking what > >>>>>> I >>>> see. This will make a >>>>>> big difference in use on large estates. >>>>>> >>>>>> A couple PatternFly related questions though: >>>>>> >>>>>> 1. The tables don't sort by column if I click on a column header. >>>> Is this not available in PatternFly yet, >>>>>> or have FreeIPA decided against implementing it? >>>>> First just a note about PatternFly. It's not really a widget >>>>> library, >>>> it is(or should be) more of a set of patterns and >>>>> styles. But the referential implementation is built on Bootstrap 3, > >>>>> so >>>> it is very easy to adopt. PatternFly doesn't have an >>>>> official pattern for table sorting yet, but it has styles for >>>> DataTables (jQuery table plugin) which can do it. >>>>> I don't remember any decision against it -> could be implemented if >>>> there is enough will and user demand. >>>>> Sorting can be done on client side and on server side. Client side >>>>> is >>>> limited to issue #2 - only 20 items, so it is not really >>>>> helpful. >>>>> >>>>> And server side (IPA API) doesn't support specifying a sort >>>>> attribute >>>> atm. >>>>> You would like the server-side sorting, right? >>>>> >>>> Hadn't considered there to be an option. When I looked at the >>>> PatternFly demos I hadn't thought about it, but the speed that >>>> FreeIPA pulls data out for rendering, I suppose it would have to be. >>>> Even our modest estate (at a few hundred users and hosts) would slow > >>>> down far too much if the full dataset was sent. >>>> >>>> The other possibilities thrown up by PatternFly are also >>>> interesting; add/remove columns, resize columns etc. I know some of > >>>> these are still on the drawing board, but there are demo pages >>>> available already. >>>> >>>>>> 2. Browsing the screen on a large monitor still leaves the user >>>>>> page >>>> (at least) limited to around 22 rows. >>>>>> This leaves the bottom third of my browser empty. The table >>>>>> uses >>>> the full width of the browser, can it >>>>>> not use the full height too? >>>>> I have and idea/plan to make it configurable - to specify the >>>>> number >>>> of items and also to allow disabling of paging. >>>>> The more rows the slower the UI is. Also paging has its own issues >>>> which are not straightforward to solve: >>>>> - >>>> http://www.redhat.com/archives/freeipa-devel/2012-August/msg00295.ht >>>> ml True. What's the biggest time factor in loading large tables? >>>> >>>> When admining estates with tens of thousands of entries, however, >>>> much emphasis needs to be placed on the table filters. No admin in >>>> their right mind is going to be performing actions on all entries >>>> simultaneously. Similar to Foreman's filters, could FreeIPA allow >>>> (example) in the hosts screen a filter of "hostgroup = groupX" to >>>> show only hosts belonging to that group? Or filtering users with >>>> "manager = 'Duncan Innes'"? >>> Please open RFEs. This is really a valuable feedback. >> I think we are somewhat talking about this RFE: >> >> https://fedorahosted.org/freeipa/ticket/2388 >> >> Maybe it is time to resurrect it from Ticket Deferred milestone given >> it would bring big value for large user deployments. >> >> The API and the mighty LDAP search engine is already there: >> >> ipa user-add --first=Test --last=User manager ipa user-add >> --first=Test --last=User employee --manager manager ipa user-add >> --first=Test --last=User employee2 --manager manager ipa group-add >> testgroup --desc test ipa group-add-member testgroup --users employee2 >> >> >> # ipa user-find --manager manager --pkey-only >> --------------- >> 2 users matched >> --------------- >> User login: employee >> >> User login: employee2 >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> # ipa user-find --manager manager --in-group testgroup --pkey-only >> -------------- >> 1 user matched >> -------------- >> User login: employee2 >> ---------------------------- >> Number of entries returned 1 >> >> >> So we would just need to utilize it in our Web UI. I personally really > >> like the simple search tags like below >> >> >> >> that can be seen in some web apps or eshops and which are pretty easy > to control. >> >> Martin > Moved to needs triage. > It will be a nice UI feature for 4.2. > Taking a note. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > This e-mail is intended to be confidential to the recipient. If you > receive a copy in error, please inform the sender and then delete this > message. > > Virgin Money plc - Registered in England and Wales (Company no. > 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon > Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential > Regulation Authority and regulated by the Financial Conduct Authority > and the Prudential Regulation Authority. > > The following companies also trade as Virgin Money. They are both > authorised and regulated by the Financial Conduct Authority, are > registered in England and Wales and have their registered office at > Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money > Personal Financial Service Limited (Company no. 3072766) and Virgin > Money Unit Trust Managers Limited (Company no. 3000482). > > For further details of Virgin Money group companies please visit our > website at virginmoney.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 > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. > > This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. > > The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). > > For further details of Virgin Money group companies please visit our website at virginmoney.com > From rcritten at redhat.com Mon Aug 18 18:33:14 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 Aug 2014 14:33:14 -0400 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: <53EDC24A.6040705@redhat.com> Message-ID: <53F246EA.9090909@redhat.com> Michael Lasevich wrote: > Thanks, that was actually very helpful. > > "Host Enrollment" privilege does not actually allow you to enroll hosts, > not sure what that is about. But "Host Administrators" worked just fine. I'd be curious to know how it was failing. It should be enough to do just an enrollment (not add a missing host, etc). Host Administrator also grants a slew of privileges beyond what you need. rob > > -M > > > On Fri, Aug 15, 2014 at 1:18 AM, Martin Kosek > wrote: > > On 08/14/2014 10:23 PM, Michael Lasevich wrote: > > Is there somewhere a documented minimum set of permissions required to > > create a special role/account/principal to auto-join machines to > the domain? > > > > I am not all too comfortable to run this as admin user and not > quite ready > > to set up the orchestration needed to pre-join the host. > > > > Thanks, > > > > -M > > > > > > > > You can simply create a system user or a joiner service and assign > it a "Host > Administrators" privilege: > > # ipa privilege-show "Host Administrators" > Privilege name: Host Administrators > Description: Host Administrators > Permissions: add hosts, remove hosts, modify hosts, manage host > ssh public keys, > manage host keytab, enroll a host, retrieve > certificates from > the ca, > revoke certificate, add krbprincipalname to a host > Granting privilege to roles: IT Specialist > > HTH, > Martin > > > > From mlasevich at lasevich.net Mon Aug 18 19:35:05 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Mon, 18 Aug 2014 12:35:05 -0700 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: <53EE34BC.30805@redhat.com> References: <53EE34BC.30805@redhat.com> Message-ID: I wanted to use the python ipalib directly, but like you mentioned, I found very little documentation and what I found indicated I was going to just pass cli arguments to it, it seemed to be not much better than calling the wrapper directly :-( I will clean up my salt reactor of things specific to my install (mostly just validating host against AWS and pulling AWS info to be added to the host description fields) and try to add it to the salt-forumulas - then we can link to it from the how-tos, etc. If someone is interested sooner, I can post it here for time being. As far as Host-Enrollment vs Host-Administrators privileges - it may be that I am mixing up 2 ways to enroll hosts. My original attempt was to try to have an "enroller" account that would add client directly from the client - but I have relented and switched to a more proper method of adding a host entrue with a generated OTP for the client followed by joining of that client from the client itself with the OTP password. This works, but when I try to add host entry with OTP password using account with only "Host Enrollment" privilege I get: ipa: ERROR: Insufficient access: Insufficient 'add' privilege to the 'userPassword' attribute I really would like to have minimal privileges for my "adder" account, but at least this account is only available on a much more restricted server (salt-master) where only limited admins have access to it. For now I am granting it the "Host Administrators" privilege, as it is what works. -M On Fri, Aug 15, 2014 at 9:26 AM, Petr Viktorin wrote: > On 08/15/2014 06:02 PM, James wrote: > >> On Fri, Aug 15, 2014 at 5:25 AM, Michael Lasevich >> wrote: >> >>> Sorry, I did not intend to belittle your efforts - just misread the code >>> >> Didn't take it that way, no worries :) >> >> (saw you pass in $admin and $password and made wrong assumption that >>> $admin >>> was admin username) as well as trying to avoid puppet as I find Salt much >>> quicker and much simpler (and already established in my setup) >>> >>> I sat down tonight and threw together a quick salt reactor that does same >>> thing as your module - creates the host account in IPA with a generated >>> OTP >>> password and joins the host to the domain using that generated OTP (and >>> while at it, validates the host against AWS and populates the metadata >>> into >>> IPA) Ended up having to join the salt master to the domain, which I was >>> avoiding doing for security reasons, but I can just disable IPA logins in >>> PAM and call it a day. The nice bit is that it is using the host's keytab >>> for authentication, so I do not need any extra credentials sitting >>> around. >>> Seems to be working just fine. :-). I ended up granting the salt-master >>> host >>> the "Host Administrators" privilege. It seems that "Host Enrollment" >>> privilege is not sufficient to enroll hosts - go figure. >>> >> Great! >> >> >>> The only thing that bugs me is that I am calling IPA python code from my >>> salt reactor python code via subprocess - there has got to be a better, >>> more >>> direct way - but I found documentation too confusing to follow at 1 am - >>> will be a project for another day. >>> >> There is the python ipa API, not sure how stable or official it is, >> but if you look in my code I use it occasionally. >> > > The RPC API is not official (i.e. documented), but since IPA needs to keep > backwards compatibility with its own client, it's very stable. > > Just be sure to send the API version with each call. (The server will send > a warning if you don't.) > > > -- > Petr? > > > -- > Manage your subscription for 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 joshua at azariah.com Tue Aug 19 01:12:14 2014 From: joshua at azariah.com (Joshua J. Kugler) Date: Mon, 18 Aug 2014 17:12:14 -0800 Subject: [Freeipa-users] Need for some pull-style replication, or an alternate solution Message-ID: <6049577.AbIWlARZBF@hosanna> So, we have a need for replication, but the existing push-only methodology doesn't work for us. I suppose our problems could be attributed to over- zealous network rules, but it is what it is. :) I'd love to change our network policy, but we aren't in charge of network policy, and there is no way I'm swaying the person that is. Topology: 1) DMZ environments 1,...,n 2) An Internal network 3) A remote rack in a data center. Rules (by "talk" I mean initiate connections to): 1) DMZs can talk to each other, somewhat. 2) The Internal network can talk to the DMZs 3) The DMZ *cannot* connect to the Internal network 4) The remote rack of course cannot contact the Internal network, but can contact the DMZs. Scenario A, Master in a DMZ: - Slave in the Internal network could contact the DMZ master for replica setup, but the Master could not contact the slave to push updates - Slave in the remote rack could contact master in DMZ, but incoming to remote rack is very restrictive, so it is possible that master couldn't push. Scenario B: Master in the Internal network. - Slaves in DMZ and remote rack couldn't contact master for setup, although the master could contact the slaves to push updates. Scenario C: Master in remote rack - Not acceptable as remote rack is a testing rack, and may go down at any time. So, the best solution, from my current understanding is being able to somehow do pull-updates for replicas, because then we could have this: - Master in DMZs - Slaves in Internal network can contact Master in DMZ for replica setup and updates - Slaves in remote rack can contact Master in DMZ for replica setup and updates Any feedback is appreciated, especially if I'm missing something...obvious or minor. j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design joshua at azariah.com - Jabber: pedahzur at gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A From lkrispen at redhat.com Tue Aug 19 07:26:11 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 19 Aug 2014 09:26:11 +0200 Subject: [Freeipa-users] Need for some pull-style replication, or an alternate solution In-Reply-To: <6049577.AbIWlARZBF@hosanna> References: <6049577.AbIWlARZBF@hosanna> Message-ID: <53F2FC13.7090809@redhat.com> What's wrong with your scenario B: master(s) in internal network, they can contact consumers in DMZ and remote rack and replicate to them. What do you mean by "to contact for setup" ? Ludwig On 08/19/2014 03:12 AM, Joshua J. Kugler wrote: > So, we have a need for replication, but the existing push-only methodology > doesn't work for us. I suppose our problems could be attributed to over- > zealous network rules, but it is what it is. :) I'd love to change our network > policy, but we aren't in charge of network policy, and there is no way I'm > swaying the person that is. > > Topology: > 1) DMZ environments 1,...,n > 2) An Internal network > 3) A remote rack in a data center. > > Rules (by "talk" I mean initiate connections to): > 1) DMZs can talk to each other, somewhat. > 2) The Internal network can talk to the DMZs > 3) The DMZ *cannot* connect to the Internal network > 4) The remote rack of course cannot contact the Internal network, but can > contact the DMZs. > > Scenario A, Master in a DMZ: > - Slave in the Internal network could contact the DMZ master for replica > setup, but the Master could not contact the slave to push updates > - Slave in the remote rack could contact master in DMZ, but incoming to > remote rack is very restrictive, so it is possible that master couldn't push. > > Scenario B: Master in the Internal network. > - Slaves in DMZ and remote rack couldn't contact master for setup, although > the master could contact the slaves to push updates. > > Scenario C: Master in remote rack > - Not acceptable as remote rack is a testing rack, and may go down at any > time. > > So, the best solution, from my current understanding is being able to somehow > do pull-updates for replicas, because then we could have this: > > - Master in DMZs > - Slaves in Internal network can contact Master in DMZ for replica setup and > updates > - Slaves in remote rack can contact Master in DMZ for replica setup and > updates > > Any feedback is appreciated, especially if I'm missing something...obvious or > minor. > > j > From mkosek at redhat.com Tue Aug 19 08:14:03 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 19 Aug 2014 10:14:03 +0200 Subject: [Freeipa-users] Minimal permissions for "joiner" account? In-Reply-To: References: <53EE34BC.30805@redhat.com> Message-ID: <53F3074B.5060805@redhat.com> On 08/18/2014 09:35 PM, Michael Lasevich wrote: > I wanted to use the python ipalib directly, but like you mentioned, I found > very little documentation and what I found indicated I was going to just > pass cli arguments to it, it seemed to be not much better than calling the > wrapper directly :-( I disagree. It *is* vastly better that calling "ipa" command tool from a subprocess. If not only because you receive proper Python exceptions and results in Python data types instead of having to parse it from the CLI. AFAIK, the "only" missing piece is the documentation for this API. For now, you need to read the plugins code (takes_options section) or deduce the call option names from CLI option names. ... > As far as Host-Enrollment vs Host-Administrators privileges - it may be > that I am mixing up 2 ways to enroll hosts. My original attempt was to try > to have an "enroller" account that would add client directly from the > client - but I have relented and switched to a more proper method of adding > a host entrue with a generated OTP for the client followed by joining of > that client from the client itself with the OTP password. This works, but > when I try to add host entry with OTP password using account with only > "Host Enrollment" privilege I get: > > ipa: ERROR: Insufficient access: Insufficient 'add' privilege to the > 'userPassword' attribute Ah, so this is the error. What FreeIPA version do you use? This bug was fixed in FreeIPA 4.0: https://fedorahosted.org/freeipa/ticket/4252 Current permissions would still not allow you to add new Hosts with Host Enrollment privilege, one would also need to add "System: Add hosts" permission, IIUC. Martin From pspacek at redhat.com Tue Aug 19 15:13:15 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 19 Aug 2014 17:13:15 +0200 Subject: [Freeipa-users] Improving FreeIPA.org Message-ID: <53F3698B.4050500@redhat.com> Hello community, Do you have an idea how to improve Freeipa.org web site? Share it! I will start: The main page currently contains three links placed right above "Main features" section header: "Learn more about FreeIPA ? What FreeIPA means for me? ? Try FreeIPA in a public demo" It seems to me that two links "Learn more about FreeIPA" [http://www.freeipa.org/page/About] and "What FreeIPA means for me?" [http://www.freeipa.org/page/Leaflet] are somehow too much for the main page. I propose to either merge "About" and "Leaflet" or to hide Leaflet from main page. It would be better to replace Leaftlet with Quick Start Guide: "Learn more about FreeIPA ? Quick Start Guide ? Try FreeIPA in a public demo" -- Petr^2 Spacek From Suhail.Choudhury at bskyb.com Tue Aug 19 16:33:49 2014 From: Suhail.Choudhury at bskyb.com (Choudhury, Suhail) Date: Tue, 19 Aug 2014 16:33:49 +0000 Subject: [Freeipa-users] Improving FreeIPA.org In-Reply-To: <53F3698B.4050500@redhat.com> References: <53F3698B.4050500@redhat.com> Message-ID: <9769CCE57C8E5A44B968BAB661851133D294FA@WPMBX060.bskyb.com> Hi, I think a small screenshot in the middle or on the side of the main webpage will serve to increase the "coolness" of the website and may possibly even result in many more people trying it out and visiting the demo. Regards, Suhail Choudhury. DevOps | Recommendations Team | BSkyB Regards, Suhail Choudhury. DevOps | Recommendations Team | BSkyB ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Petr Spacek [pspacek at redhat.com] Sent: 19 August 2014 16:13 To: freeipa-users at redhat.com Subject: [Freeipa-users] Improving FreeIPA.org Hello community, Do you have an idea how to improve Freeipa.org web site? Share it! I will start: The main page currently contains three links placed right above "Main features" section header: "Learn more about FreeIPA ? What FreeIPA means for me? ? Try FreeIPA in a public demo" It seems to me that two links "Learn more about FreeIPA" [http://www.freeipa.org/page/About] and "What FreeIPA means for me?" [http://www.freeipa.org/page/Leaflet] are somehow too much for the main page. I propose to either merge "About" and "Leaflet" or to hide Leaflet from main page. It would be better to replace Leaftlet with Quick Start Guide: "Learn more about FreeIPA ? Quick Start Guide ? Try FreeIPA in a public demo" -- 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 Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From joshua at azariah.com Tue Aug 19 17:55:00 2014 From: joshua at azariah.com (Joshua J. Kugler) Date: Tue, 19 Aug 2014 09:55 -0800 Subject: [Freeipa-users] Need for some pull-style replication, or an alternate solution In-Reply-To: <53F2FC13.7090809@redhat.com> References: <6049577.AbIWlARZBF@hosanna> <53F2FC13.7090809@redhat.com> Message-ID: <4861692.8zCsvlK8bH@hosanna> A replica must connect to the master for initial setup; after that, the master pushes to the replica. j On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote: > What's wrong with your scenario B: master(s) in internal network, they > can contact consumers in DMZ and remote rack and replicate to them. > What do you mean by "to contact for setup" ? > > Ludwig > > On 08/19/2014 03:12 AM, Joshua J. Kugler wrote: > > So, we have a need for replication, but the existing push-only methodology > > doesn't work for us. I suppose our problems could be attributed to over- > > zealous network rules, but it is what it is. :) I'd love to change our > > network policy, but we aren't in charge of network policy, and there is > > no way I'm swaying the person that is. > > > > Topology: > > 1) DMZ environments 1,...,n > > 2) An Internal network > > 3) A remote rack in a data center. > > > > Rules (by "talk" I mean initiate connections to): > > 1) DMZs can talk to each other, somewhat. > > 2) The Internal network can talk to the DMZs > > 3) The DMZ *cannot* connect to the Internal network > > 4) The remote rack of course cannot contact the Internal network, but can > > contact the DMZs. > > > > Scenario A, Master in a DMZ: > > - Slave in the Internal network could contact the DMZ master for replica > > > > setup, but the Master could not contact the slave to push updates > > > > - Slave in the remote rack could contact master in DMZ, but incoming to > > > > remote rack is very restrictive, so it is possible that master couldn't > > push. > > > > Scenario B: Master in the Internal network. > > > > - Slaves in DMZ and remote rack couldn't contact master for setup, > > although > > > > the master could contact the slaves to push updates. > > > > Scenario C: Master in remote rack > > > > - Not acceptable as remote rack is a testing rack, and may go down at > > any > > > > time. > > > > So, the best solution, from my current understanding is being able to > > somehow> > > do pull-updates for replicas, because then we could have this: > > - Master in DMZs > > - Slaves in Internal network can contact Master in DMZ for replica setup > > and> > > updates > > > > - Slaves in remote rack can contact Master in DMZ for replica setup and > > > > updates > > > > Any feedback is appreciated, especially if I'm missing something...obvious > > or minor. > > > > j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design joshua at azariah.com - Jabber: pedahzur at gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A From cwhittl at gmail.com Tue Aug 19 21:08:59 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 19 Aug 2014 16:08:59 -0500 Subject: [Freeipa-users] FreeIP just stopped starting Message-ID: Here is what I get if I try to start it manually... Any ideas? [root at itservices /]# /usr/sbin/ipactl start Starting Directory Service Starting dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [ OK ] Starting CA Service Starting pki-ca: [ OK ] Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Failed to start CA Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached: [ OK ] Stopping httpd: [ OK ] Stopping pki-ca: [FAILED] Shutting down dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl -------------- next part -------------- An HTML attachment was scrubbed... URL: From barrykfl at gmail.com Wed Aug 20 04:23:54 2014 From: barrykfl at gmail.com (barrykfl at gmail.com) Date: Wed, 20 Aug 2014 12:23:54 +0800 Subject: [Freeipa-users] dirsrv access log redirect Message-ID: Dear all: I got 2 servers as cluster ... how can i redirect all logs server2 's /var/log/dirsrv/slapd-abc.com/access to server 1 's /var/log/dirsrv/ slapd-abc.com/access so i can view once ?what config should consider ? Or should i use syslog to collect server2 and redirect all to server 1 ? thks -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Aug 20 07:29:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 Aug 2014 09:29:37 +0200 Subject: [Freeipa-users] FreeIP just stopped starting In-Reply-To: References: Message-ID: <53F44E61.9060607@redhat.com> On 08/19/2014 11:08 PM, Chris Whittle wrote: > Here is what I get if I try to start it manually... Any ideas? > > > [root at itservices /]# /usr/sbin/ipactl start > > Starting Directory Service > > Starting dirsrv: > > COLLECTIVEBIAS-COM... [ OK ] > > PKI-IPA... [ OK ] > > Starting KDC Service > > Starting Kerberos 5 KDC: [ OK ] > > Starting KPASSWD Service > > Starting Kerberos 5 Admin Server: [ OK ] > > Starting MEMCACHE Service > > Starting ipa_memcached: [ OK ] > > Starting HTTP Service > > Starting httpd: [ OK ] > > Starting CA Service > > Starting pki-ca: [ OK ] > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Usage: grep [OPTION]... PATTERN [FILE]... > > Try `grep --help' for more information. > > Failed to start CA Service > > Shutting down > > Stopping Kerberos 5 KDC: [ OK ] > > Stopping Kerberos 5 Admin Server: [ OK ] > > Stopping ipa_memcached: [ OK ] > > Stopping httpd: [ OK ] > > Stopping pki-ca: [FAILED] > > Shutting down dirsrv: > > COLLECTIVEBIAS-COM... [ OK ] > > PKI-IPA... [ OK ] > > Aborting ipactl This error is new to me. PKI service start script apparently calls grep function with wrong arguments. CCing Ade and Endi from PKI team to help. What version of PKI&IPA are we talking about? Martin From PGrant at westfield.com Wed Aug 20 08:02:30 2014 From: PGrant at westfield.com (Peter Grant) Date: Wed, 20 Aug 2014 08:02:30 +0000 Subject: [Freeipa-users] IPA Master Issue - Not starting In-Reply-To: <53EDB265.9020103@redhat.com> References: <96A72336A6B7174C9F0D4ADDB784B50E417D119A@AUPDC00-MBX01P.au.ad.westfield.com> <53EDB265.9020103@redhat.com> Message-ID: <96A72336A6B7174C9F0D4ADDB784B50E417DC3A8@AUPDC00-MBX01P.au.ad.westfield.com> Hi Petr, Thanks for your help the other day. Something is bringing down my master instance. i am seeing mismatch on master [root at master init.d]# kvno DNS/master.domain.com at domain.COM DNS/master.domain.com at domain.COM: kvno = 8 [root at master init.d]# klist -kt /etc/named.keytab Keytab name: FILE:/etc/named.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM 49 08/20/14 17:43:43 DNS/master.domain.com at domain.COM 49 08/20/14 17:43:44 DNS/master.domain.com at domain.COM 49 08/20/14 17:43:44 DNS/master.domain.com at domain.COM 49 08/20/14 17:43:44 DNS/master.domain.com at domain.COM [root at master init.d]# also here is output from /var/log/messages whilst trying to ipactl start [root at master init.d]# sudo ipactl start Starting Directory Service Starting dirsrv: domain-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting DNS Service Starting named: 2014-08-20T18:00:22.098747+10:00 master named[20827]: starting BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 -u named 2014-08-20T18:00:22.099552+10:00 master named[20827]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' 2014-08-20T18:00:22.099633+10:00 master named[20827]: ---------------------------------------------------- 2014-08-20T18:00:22.099688+10:00 master named[20827]: BIND 9 is maintained by Internet Systems Consortium, 2014-08-20T18:00:22.099750+10:00 master named[20827]: Inc. (ISC), a non-profit 501(c)(3) public-benefit 2014-08-20T18:00:22.099803+10:00 master named[20827]: corporation. Support and training for BIND 9 are 2014-08-20T18:00:22.099864+10:00 master named[20827]: available at https://www.isc.org/support 2014-08-20T18:00:22.099925+10:00 master named[20827]: ---------------------------------------------------- 2014-08-20T18:00:22.099998+10:00 master named[20827]: adjusted limit on open files from 62000 to 1048576 2014-08-20T18:00:22.100207+10:00 master named[20827]: found 1 CPU, using 1 worker thread 2014-08-20T18:00:22.100484+10:00 master named[20827]: using up to 4096 sockets 2014-08-20T18:00:22.103796+10:00 master named[20827]: loading configuration from '/etc/named.conf' 2014-08-20T18:00:22.104495+10:00 master named[20827]: using default UDP/IPv4 port range: [1024, 65535] 2014-08-20T18:00:22.104728+10:00 master named[20827]: using default UDP/IPv6 port range: [1024, 65535] 2014-08-20T18:00:22.106090+10:00 master named[20827]: listening on IPv6 interfaces, port 53 2014-08-20T18:00:22.108167+10:00 master named[20827]: listening on IPv4 interface lo, 127.0.0.1#53 2014-08-20T18:00:22.108571+10:00 master named[20827]: listening on IPv4 interface eth0, 10.3.11.16#53 2014-08-20T18:00:22.109760+10:00 master named[20827]: generating session key for dynamic DNS 2014-08-20T18:00:22.109997+10:00 master named[20827]: sizing zone task pool based on 5 zones 2014-08-20T18:00:22.112660+10:00 master named[20827]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' 2014-08-20T18:00:22.129607+10:00 master named[20827]: Failed to init credentials (Generic preauthentication failure) 2014-08-20T18:00:22.130031+10:00 master named[20827]: loading configuration: failure 2014-08-20T18:00:22.130285+10:00 master named[20827]: exiting (due to fatal error) [FAILED] Failed to start DNS Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: 2014-08-20T18:00:23.833115+10:00 master ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/LOCALDOMAIN at domain.COM not found in Kerberos database) [ OK ] Stopping named: [ OK ] Stopping httpd: [FAILED] Stopping pki-ca: [ OK ] Shutting down dirsrv: domain-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl [root at master init.d]# however there is still a mismatch when i try to get key tab from secondary using command ipa-getkeytab -s secondary.domain.com -p DNS/master.domain.com at domain.COM -k /etc/named.keytab i am unable to regenerate the key tab on the master as ldap is not running. Any ideas? Thankyou, Peter. > On 15 Aug 2014, at 5:10 pm, Petr Spacek wrote: > > Hello, > > On 15.8.2014 03:52, Peter Grant wrote: >> 2014-08-15T11:43:46.434383+10:00 host named[6470]: Failed to init credentials (Decrypt integrity check failed) >> >> 2014-08-15T11:43:46.434884+10:00 host named[6470]: loading configuration: failure >> >> 2014-08-15T11:43:46.434991+10:00 host named[6470]: exiting (due to fatal error) >> >> 2014-08-15T11:43:47.435187+10:00 host ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm ?DOMAIN.COM') > > For named issue please follow instructions on > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a3.FailedtoinitcredentialsorFailedtogetinitialcredentialsDecryptintegritycheckfailedorClientscredentialshavebeenrevoked > > It seems that /etc/named.keytab is somehow corrupted or obsolete. > > Also, KDC logs in /var/log/krb5kdc.log can tell you more. > > I hope that others will add ideas about other errors. > > -- > Petr^2 Spacek > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From pspacek at redhat.com Wed Aug 20 08:13:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 20 Aug 2014 10:13:00 +0200 Subject: [Freeipa-users] IPA Master Issue - Not starting In-Reply-To: <96A72336A6B7174C9F0D4ADDB784B50E417DC3A8@AUPDC00-MBX01P.au.ad.westfield.com> References: <96A72336A6B7174C9F0D4ADDB784B50E417D119A@AUPDC00-MBX01P.au.ad.westfield.com> <53EDB265.9020103@redhat.com> <96A72336A6B7174C9F0D4ADDB784B50E417DC3A8@AUPDC00-MBX01P.au.ad.westfield.com> Message-ID: <53F4588C.7040301@redhat.com> On 20.8.2014 10:02, Peter Grant wrote: > Hi Petr, > > Thanks for your help the other day. > > Something is bringing down my master instance. > > i am seeing mismatch on master > > [root at master init.d]# kvno DNS/master.domain.com at domain.COM > DNS/master.domain.com at domain.COM: kvno = 8 > [root at master init.d]# klist -kt /etc/named.keytab > Keytab name: FILE:/etc/named.keytab > KVNO Timestamp Principal > ---- ----------------- -------------------------------------------------------- > 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM > 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM > 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM > 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM > 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM > 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM > 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM > 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM > 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM > 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM > 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM > 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM > 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM > 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM > 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM > 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM > 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM > 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM > 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM > 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM > 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM > 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM > 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM > 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM > 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM > 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM > 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM > 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM > 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM > 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM > 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM > 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM > 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM > 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM > 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM > 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM > 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM > 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM > 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM > 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM > 49 08/20/14 17:43:43 DNS/master.domain.com at domain.COM > 49 08/20/14 17:43:44 DNS/master.domain.com at domain.COM > 49 08/20/14 17:43:44 DNS/master.domain.com at domain.COM > 49 08/20/14 17:43:44 DNS/master.domain.com at domain.COM > [root at master init.d]# > > > also here is output from /var/log/messages whilst trying to ipactl start > > > > [root at master init.d]# sudo ipactl start > Starting Directory Service > Starting dirsrv: > domain-COM... [ OK ] > PKI-IPA... [ OK ] > Starting KDC Service > Starting Kerberos 5 KDC: [ OK ] > Starting KPASSWD Service > Starting Kerberos 5 Admin Server: [ OK ] > Starting DNS Service > Starting named: 2014-08-20T18:00:22.098747+10:00 master named[20827]: starting BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 -u named > 2014-08-20T18:00:22.099552+10:00 master named[20827]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FO! RTIFY_SOUR CE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' > 2014-08-20T18:00:22.099633+10:00 master named[20827]: ---------------------------------------------------- > 2014-08-20T18:00:22.099688+10:00 master named[20827]: BIND 9 is maintained by Internet Systems Consortium, > 2014-08-20T18:00:22.099750+10:00 master named[20827]: Inc. (ISC), a non-profit 501(c)(3) public-benefit > 2014-08-20T18:00:22.099803+10:00 master named[20827]: corporation. Support and training for BIND 9 are > 2014-08-20T18:00:22.099864+10:00 master named[20827]: available at https://www.isc.org/support > 2014-08-20T18:00:22.099925+10:00 master named[20827]: ---------------------------------------------------- > 2014-08-20T18:00:22.099998+10:00 master named[20827]: adjusted limit on open files from 62000 to 1048576 > 2014-08-20T18:00:22.100207+10:00 master named[20827]: found 1 CPU, using 1 worker thread > 2014-08-20T18:00:22.100484+10:00 master named[20827]: using up to 4096 sockets > 2014-08-20T18:00:22.103796+10:00 master named[20827]: loading configuration from '/etc/named.conf' > 2014-08-20T18:00:22.104495+10:00 master named[20827]: using default UDP/IPv4 port range: [1024, 65535] > 2014-08-20T18:00:22.104728+10:00 master named[20827]: using default UDP/IPv6 port range: [1024, 65535] > 2014-08-20T18:00:22.106090+10:00 master named[20827]: listening on IPv6 interfaces, port 53 > 2014-08-20T18:00:22.108167+10:00 master named[20827]: listening on IPv4 interface lo, 127.0.0.1#53 > 2014-08-20T18:00:22.108571+10:00 master named[20827]: listening on IPv4 interface eth0, 10.3.11.16#53 > 2014-08-20T18:00:22.109760+10:00 master named[20827]: generating session key for dynamic DNS > 2014-08-20T18:00:22.109997+10:00 master named[20827]: sizing zone task pool based on 5 zones > 2014-08-20T18:00:22.112660+10:00 master named[20827]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' > 2014-08-20T18:00:22.129607+10:00 master named[20827]: Failed to init credentials (Generic preauthentication failure) > 2014-08-20T18:00:22.130031+10:00 master named[20827]: loading configuration: failure > 2014-08-20T18:00:22.130285+10:00 master named[20827]: exiting (due to fatal error) > [FAILED] > Failed to start DNS Service > Shutting down > Stopping Kerberos 5 KDC: [ OK ] > Stopping Kerberos 5 Admin Server: 2014-08-20T18:00:23.833115+10:00 master ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/LOCALDOMAIN at domain.COM not found in Kerberos database) This seems to be more serious - I suspect that replication between replicas doesn't work because replica is not able to authenticate. The error message is suspicious but I'm not sure that it is not result of obfuscation. Please try to apply this article to ns-slapd on your broken master: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a2.Serverldapsrv01EXAMPLE.COMnotfoundinKerberosdatabase Maybe /etc/hosts is somehow misconfigured. > [ OK ] > Stopping named: [ OK ] > Stopping httpd: [FAILED] > Stopping pki-ca: [ OK ] > Shutting down dirsrv: > domain-COM... [ OK ] > PKI-IPA... [ OK ] > Aborting ipactl > [root at master init.d]# > > however there is still a mismatch when i try to get key tab from secondary using command > ipa-getkeytab -s secondary.domain.com -p DNS/master.domain.com at domain.COM -k /etc/named.keytab Maybe it is caused by broken replication (one KDC have different keys than the other KDC). I would start with replication problems and focus on named later. Petr^2 Spacek > > i am unable to regenerate the key tab on the master as ldap is not running. > > > Any ideas? > > > Thankyou, > > Peter. > > >> On 15 Aug 2014, at 5:10 pm, Petr Spacek wrote: >> >> Hello, >> >> On 15.8.2014 03:52, Peter Grant wrote: >>> 2014-08-15T11:43:46.434383+10:00 host named[6470]: Failed to init credentials (Decrypt integrity check failed) >>> >>> 2014-08-15T11:43:46.434884+10:00 host named[6470]: loading configuration: failure >>> >>> 2014-08-15T11:43:46.434991+10:00 host named[6470]: exiting (due to fatal error) >>> >>> 2014-08-15T11:43:47.435187+10:00 host ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm ?DOMAIN.COM') >> >> For named issue please follow instructions on >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a3.FailedtoinitcredentialsorFailedtogetinitialcredentialsDecryptintegritycheckfailedorClientscredentialshavebeenrevoked >> >> It seems that /etc/named.keytab is somehow corrupted or obsolete. >> >> Also, KDC logs in /var/log/krb5kdc.log can tell you more. >> >> I hope that others will add ideas about other errors. From dpal at redhat.com Wed Aug 20 08:58:34 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 20 Aug 2014 10:58:34 +0200 Subject: [Freeipa-users] Need for some pull-style replication, or an alternate solution In-Reply-To: <4861692.8zCsvlK8bH@hosanna> References: <6049577.AbIWlARZBF@hosanna> <53F2FC13.7090809@redhat.com> <4861692.8zCsvlK8bH@hosanna> Message-ID: <53F4633A.8090708@redhat.com> On 08/19/2014 07:55 PM, Joshua J. Kugler wrote: > A replica must connect to the master for initial setup; after that, the master > pushes to the replica. > > j > > On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote: >> What's wrong with your scenario B: master(s) in internal network, they >> can contact consumers in DMZ and remote rack and replicate to them. >> What do you mean by "to contact for setup" ? >> >> Ludwig >> >> On 08/19/2014 03:12 AM, Joshua J. Kugler wrote: >>> So, we have a need for replication, but the existing push-only methodology >>> doesn't work for us. I suppose our problems could be attributed to over- >>> zealous network rules, but it is what it is. :) I'd love to change our >>> network policy, but we aren't in charge of network policy, and there is >>> no way I'm swaying the person that is. >>> >>> Topology: >>> 1) DMZ environments 1,...,n >>> 2) An Internal network >>> 3) A remote rack in a data center. >>> >>> Rules (by "talk" I mean initiate connections to): >>> 1) DMZs can talk to each other, somewhat. >>> 2) The Internal network can talk to the DMZs >>> 3) The DMZ *cannot* connect to the Internal network >>> 4) The remote rack of course cannot contact the Internal network, but can >>> contact the DMZs. >>> >>> Scenario A, Master in a DMZ: >>> - Slave in the Internal network could contact the DMZ master for replica >>> >>> setup, but the Master could not contact the slave to push updates >>> >>> - Slave in the remote rack could contact master in DMZ, but incoming to >>> >>> remote rack is very restrictive, so it is possible that master couldn't >>> push. >>> >>> Scenario B: Master in the Internal network. >>> >>> - Slaves in DMZ and remote rack couldn't contact master for setup, >>> although >>> >>> the master could contact the slaves to push updates. >>> >>> Scenario C: Master in remote rack >>> >>> - Not acceptable as remote rack is a testing rack, and may go down at >>> any >>> >>> time. >>> >>> So, the best solution, from my current understanding is being able to >>> somehow> >>> do pull-updates for replicas, because then we could have this: >>> - Master in DMZs >>> - Slaves in Internal network can contact Master in DMZ for replica setup >>> and> >>> updates >>> >>> - Slaves in remote rack can contact Master in DMZ for replica setup and >>> >>> updates >>> >>> Any feedback is appreciated, especially if I'm missing something...obvious >>> or minor. >>> >>> j I think you capture the problem correctly. There is unfortunately no solution for this at the moment. We considered looking into read only replicas but this is not exactly what would help here either since changes to RO replicas would be rerouted to the real masters and thos need to be accessible from DMZ or remote req in your case - so it will be inbound connection here. I am not sure there is a way to help you here with the current software. The only option I see is a two different domains - internal and external with some manually set trust in between. You bight be able to sync people in some way with some scripts but still that would be quite fragile. Are the users operating inside the FW and in DMZ/remote are really same users? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Wed Aug 20 09:00:48 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 20 Aug 2014 11:00:48 +0200 Subject: [Freeipa-users] dirsrv access log redirect In-Reply-To: References: Message-ID: <53F463C0.5080300@redhat.com> On 08/20/2014 06:23 AM, barrykfl at gmail.com wrote: > Dear all: > > I got 2 servers as cluster ... how can i redirect all logs server2 's > /var/log/dirsrv/slapd-abc.com/access to > server 1 's /var/log/dirsrv/slapd-abc.com/access > > > so i can view once ?what config should consider ? Or should i use > syslog to collect server2 > and redirect all to server 1 ? > > thks > > > You should use log collection tools of your choice to collect and process the logs. You can send logs to syslog and then use rsyslog to collect it. After that you can use different tools to process it: logstash, splunk, etc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baghery.jone at gmail.com Wed Aug 20 11:45:14 2014 From: baghery.jone at gmail.com (alireza baghery) Date: Wed, 20 Aug 2014 16:15:14 +0430 Subject: [Freeipa-users] i inetgrated ipa server with AD but users AD can not loggin on server linux? Message-ID: hi Having a particularly weird problem. We have moved from AD(windows 2008 R2) to ipa server(centos 6.5). and i integrated ipa with AD machine linux joined with ipa and machine windowse joined with AD. users AD can loggin in cli mode in system linux (centos 6.5) but can not in GUI mod loggin error message in file /var/log/security ---------------------------------------------------------------------------------- pam: gdm-password[2685]: pam_unix(gdm-password:auth): authentication failure: logname= uid=0 euid=0 tty=:0 ruser= rhost= rhost= user=sallea at AD pam: gdm-password[2685]: pam_sss(gdm-password:auth): user info message: your password will expire in 40 day pam: gdm-password[2685]:pam_sss( gdm-password:auth): authenticate success: logname= uid=0 euid=0 tty=:0 ruser= rhost= rhost= user=sallea at AD pam: gdm-password[2685]:pam_unix (gdm-password:session): session opened for user sallea at AD by (uid=0) polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus name :1.116 , object path /org/gnome/PolcyKit1/AuthenticationAgent, - Ignored: local en_US) (disconnected from bus) pam: gdm-password[2685]: pam_unix (gdm-password:session): session closed for user sallea at AD ------------------------------------------------------ and context file /etc/pam.d/password-auth ----------------------------------- auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session require pam_sss.so -------------------------------------- how to solve this problem? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Wed Aug 20 12:54:27 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Wed, 20 Aug 2014 07:54:27 -0500 Subject: [Freeipa-users] FreeIP just stopped starting In-Reply-To: <53F44E61.9060607@redhat.com> References: <53F44E61.9060607@redhat.com> Message-ID: How is the best way to determine the version? On Wed, Aug 20, 2014 at 2:29 AM, Martin Kosek wrote: > On 08/19/2014 11:08 PM, Chris Whittle wrote: > > Here is what I get if I try to start it manually... Any ideas? > > > > > > [root at itservices /]# /usr/sbin/ipactl start > > > > Starting Directory Service > > > > Starting dirsrv: > > > > COLLECTIVEBIAS-COM... [ OK ] > > > > PKI-IPA... [ OK ] > > > > Starting KDC Service > > > > Starting Kerberos 5 KDC: [ OK ] > > > > Starting KPASSWD Service > > > > Starting Kerberos 5 Admin Server: [ OK ] > > > > Starting MEMCACHE Service > > > > Starting ipa_memcached: [ OK ] > > > > Starting HTTP Service > > > > Starting httpd: [ OK ] > > > > Starting CA Service > > > > Starting pki-ca: [ OK ] > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Usage: grep [OPTION]... PATTERN [FILE]... > > > > Try `grep --help' for more information. > > > > Failed to start CA Service > > > > Shutting down > > > > Stopping Kerberos 5 KDC: [ OK ] > > > > Stopping Kerberos 5 Admin Server: [ OK ] > > > > Stopping ipa_memcached: [ OK ] > > > > Stopping httpd: [ OK ] > > > > Stopping pki-ca: [FAILED] > > > > Shutting down dirsrv: > > > > COLLECTIVEBIAS-COM... [ OK ] > > > > PKI-IPA... [ OK ] > > > > Aborting ipactl > > > This error is new to me. PKI service start script apparently calls grep > function with wrong arguments. CCing Ade and Endi from PKI team to help. > > What version of PKI&IPA are we talking about? > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Aug 20 12:55:13 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 20 Aug 2014 14:55:13 +0200 Subject: [Freeipa-users] Need for some pull-style replication, or an alternate solution In-Reply-To: <53F4633A.8090708@redhat.com> References: <6049577.AbIWlARZBF@hosanna> <53F2FC13.7090809@redhat.com> <4861692.8zCsvlK8bH@hosanna> <53F4633A.8090708@redhat.com> Message-ID: <53F49AB1.8010105@redhat.com> On 20.8.2014 10:58, Dmitri Pal wrote: > On 08/19/2014 07:55 PM, Joshua J. Kugler wrote: >> A replica must connect to the master for initial setup; after that, the master >> pushes to the replica. >> >> j >> >> On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote: >>> What's wrong with your scenario B: master(s) in internal network, they >>> can contact consumers in DMZ and remote rack and replicate to them. >>> What do you mean by "to contact for setup" ? >>> >>> Ludwig >>> >>> On 08/19/2014 03:12 AM, Joshua J. Kugler wrote: >>>> So, we have a need for replication, but the existing push-only methodology >>>> doesn't work for us. I suppose our problems could be attributed to over- >>>> zealous network rules, but it is what it is. :) I'd love to change our >>>> network policy, but we aren't in charge of network policy, and there is >>>> no way I'm swaying the person that is. >>>> >>>> Topology: >>>> 1) DMZ environments 1,...,n >>>> 2) An Internal network >>>> 3) A remote rack in a data center. >>>> >>>> Rules (by "talk" I mean initiate connections to): >>>> 1) DMZs can talk to each other, somewhat. >>>> 2) The Internal network can talk to the DMZs >>>> 3) The DMZ *cannot* connect to the Internal network >>>> 4) The remote rack of course cannot contact the Internal network, but can >>>> contact the DMZs. >>>> >>>> Scenario A, Master in a DMZ: >>>> - Slave in the Internal network could contact the DMZ master for replica >>>> >>>> setup, but the Master could not contact the slave to push updates >>>> >>>> - Slave in the remote rack could contact master in DMZ, but incoming to >>>> >>>> remote rack is very restrictive, so it is possible that master couldn't >>>> push. >>>> >>>> Scenario B: Master in the Internal network. >>>> >>>> - Slaves in DMZ and remote rack couldn't contact master for setup, >>>> although >>>> >>>> the master could contact the slaves to push updates. >>>> >>>> Scenario C: Master in remote rack >>>> >>>> - Not acceptable as remote rack is a testing rack, and may go down at >>>> any >>>> >>>> time. >>>> >>>> So, the best solution, from my current understanding is being able to >>>> somehow> >>>> do pull-updates for replicas, because then we could have this: >>>> - Master in DMZs >>>> - Slaves in Internal network can contact Master in DMZ for replica setup >>>> and> >>>> updates >>>> >>>> - Slaves in remote rack can contact Master in DMZ for replica setup and >>>> >>>> updates >>>> >>>> Any feedback is appreciated, especially if I'm missing something...obvious >>>> or minor. >>>> >>>> j > I think you capture the problem correctly. There is unfortunately no solution > for this at the moment. > We considered looking into read only replicas but this is not exactly what > would help here either since changes to RO replicas would be rerouted to the > real masters and thos need to be accessible from DMZ or remote req in your > case - so it will be inbound connection here. > I am not sure there is a way to help you here with the current software. The > only option I see is a two different domains - internal and external with some > manually set trust in between. You bight be able to sync people in some way > with some scripts but still that would be quite fragile. > Are the users operating inside the FW and in DMZ/remote are really same users? Or IPA-to-IPA trust? :-) Joshua, if you want to experiment: Ludwig said earlier in this thread that 389 replication will work fine if master is inside internal network (and thus able to contact other replicas in DMZ or external network). It seems to me that main *technical* problem is "replica setup" phase where replica contacts the original master and not the other way around. You can use e.g. SSH from master to replica and do some tricks with port forwarding and iptables/routing table so the replica will be able to contact the master inside internal network. (That will breach all policies you have, of course.) If you want to experiment even more, you can try to use port forwarding for replica setup and then close the hole. 389 replication should work because master will connect to replica and not the other way around. I'm not sure what else will break... -- Petr^2 Spacek From dpal at redhat.com Wed Aug 20 12:57:40 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 20 Aug 2014 14:57:40 +0200 Subject: [Freeipa-users] i inetgrated ipa server with AD but users AD can not loggin on server linux? In-Reply-To: References: Message-ID: <53F49B44.5040703@redhat.com> On 08/20/2014 01:45 PM, alireza baghery wrote: > hi > Having a particularly weird problem. We have moved from AD(windows > 2008 R2) > to ipa server(centos 6.5). and i integrated ipa with AD > machine linux joined with ipa and machine windowse joined with AD. > users AD can loggin in cli mode in system linux (centos 6.5) > but can not in GUI mod loggin Do I get it right: User from AD walks to a desktop console of the Linux system joined into IPA that is in trust relations with AD and the GDE produces the following log? > error message in file /var/log/security > ---------------------------------------------------------------------------------- > pam: gdm-password[2685]: pam_unix(gdm-password:auth): > authentication failure: logname= uid=0 euid=0 tty=:0 ruser= rhost= > rhost= user=sallea at AD > pam: gdm-password[2685]: pam_sss(gdm-password:auth): > user info message: your password will expire in 40 day > pam: gdm-password[2685]:pam_sss( > gdm-password:auth): > authenticate success: logname= uid=0 euid=0 tty=:0 ruser= rhost= > rhost= user=sallea at AD > pam: gdm-password[2685]:pam_unix (gdm-password:session): > session opened for user sallea at AD by (uid=0) > polkitd(authority=local): Unregistered Authentication > Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus > name :1.116 , object path /org/gnome/PolcyKit1/AuthenticationAgent, > > - Ignored: > local en_US) (disconnected from bus) > > pam: gdm-password[2685]: pam_unix (gdm-password:session): > session closed for user sallea at AD > ------------------------------------------------------ > > and context file /etc/pam.d/password-auth > ----------------------------------- > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_sss.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > password requisite pam_cracklib.so try_first_pass retry=3 type= > password sufficient pam_unix.so sha512 shadow nullok > try_first_pass use_authtok > password sufficient pam_sss.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > session [success=1 default=ignore] pam_succeed_if.so service in > crond quiet use_uid > session required pam_unix.so > > session require pam_sss.so > -------------------------------------- > how to solve this problem? > thanks > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Aug 20 13:04:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 20 Aug 2014 15:04:06 +0200 Subject: [Freeipa-users] FreeIP just stopped starting In-Reply-To: References: <53F44E61.9060607@redhat.com> Message-ID: <53F49CC6.7000508@redhat.com> $ rpm -q freeipa-server if you are running on Fedora. $ rpm -q ipa-server if you are running on RHEL/CentOS. FreeIPA 4.0 later also show version with $ ipa --version or in Web UI. Martin On 08/20/2014 02:54 PM, Chris Whittle wrote: > How is the best way to determine the version? > > > On Wed, Aug 20, 2014 at 2:29 AM, Martin Kosek wrote: > >> On 08/19/2014 11:08 PM, Chris Whittle wrote: >>> Here is what I get if I try to start it manually... Any ideas? >>> >>> >>> [root at itservices /]# /usr/sbin/ipactl start >>> >>> Starting Directory Service >>> >>> Starting dirsrv: >>> >>> COLLECTIVEBIAS-COM... [ OK ] >>> >>> PKI-IPA... [ OK ] >>> >>> Starting KDC Service >>> >>> Starting Kerberos 5 KDC: [ OK ] >>> >>> Starting KPASSWD Service >>> >>> Starting Kerberos 5 Admin Server: [ OK ] >>> >>> Starting MEMCACHE Service >>> >>> Starting ipa_memcached: [ OK ] >>> >>> Starting HTTP Service >>> >>> Starting httpd: [ OK ] >>> >>> Starting CA Service >>> >>> Starting pki-ca: [ OK ] >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Usage: grep [OPTION]... PATTERN [FILE]... >>> >>> Try `grep --help' for more information. >>> >>> Failed to start CA Service >>> >>> Shutting down >>> >>> Stopping Kerberos 5 KDC: [ OK ] >>> >>> Stopping Kerberos 5 Admin Server: [ OK ] >>> >>> Stopping ipa_memcached: [ OK ] >>> >>> Stopping httpd: [ OK ] >>> >>> Stopping pki-ca: [FAILED] >>> >>> Shutting down dirsrv: >>> >>> COLLECTIVEBIAS-COM... [ OK ] >>> >>> PKI-IPA... [ OK ] >>> >>> Aborting ipactl >> >> >> This error is new to me. PKI service start script apparently calls grep >> function with wrong arguments. CCing Ade and Endi from PKI team to help. >> >> What version of PKI&IPA are we talking about? >> >> Martin >> > From cwhittl at gmail.com Wed Aug 20 13:10:40 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Wed, 20 Aug 2014 08:10:40 -0500 Subject: [Freeipa-users] FreeIP just stopped starting In-Reply-To: <53F49CC6.7000508@redhat.com> References: <53F44E61.9060607@redhat.com> <53F49CC6.7000508@redhat.com> Message-ID: ipa-server-3.0.0-37.el6.x86_64 I also found this with no solution https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html On Wed, Aug 20, 2014 at 8:04 AM, Martin Kosek wrote: > $ rpm -q freeipa-server > > if you are running on Fedora. > > $ rpm -q ipa-server > > if you are running on RHEL/CentOS. > > FreeIPA 4.0 later also show version with > $ ipa --version > or in Web UI. > > Martin > > On 08/20/2014 02:54 PM, Chris Whittle wrote: > > How is the best way to determine the version? > > > > > > On Wed, Aug 20, 2014 at 2:29 AM, Martin Kosek wrote: > > > >> On 08/19/2014 11:08 PM, Chris Whittle wrote: > >>> Here is what I get if I try to start it manually... Any ideas? > >>> > >>> > >>> [root at itservices /]# /usr/sbin/ipactl start > >>> > >>> Starting Directory Service > >>> > >>> Starting dirsrv: > >>> > >>> COLLECTIVEBIAS-COM... [ OK ] > >>> > >>> PKI-IPA... [ OK ] > >>> > >>> Starting KDC Service > >>> > >>> Starting Kerberos 5 KDC: [ OK ] > >>> > >>> Starting KPASSWD Service > >>> > >>> Starting Kerberos 5 Admin Server: [ OK ] > >>> > >>> Starting MEMCACHE Service > >>> > >>> Starting ipa_memcached: [ OK ] > >>> > >>> Starting HTTP Service > >>> > >>> Starting httpd: [ OK ] > >>> > >>> Starting CA Service > >>> > >>> Starting pki-ca: [ OK ] > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Usage: grep [OPTION]... PATTERN [FILE]... > >>> > >>> Try `grep --help' for more information. > >>> > >>> Failed to start CA Service > >>> > >>> Shutting down > >>> > >>> Stopping Kerberos 5 KDC: [ OK ] > >>> > >>> Stopping Kerberos 5 Admin Server: [ OK ] > >>> > >>> Stopping ipa_memcached: [ OK ] > >>> > >>> Stopping httpd: [ OK ] > >>> > >>> Stopping pki-ca: [FAILED] > >>> > >>> Shutting down dirsrv: > >>> > >>> COLLECTIVEBIAS-COM... [ OK ] > >>> > >>> PKI-IPA... [ OK ] > >>> > >>> Aborting ipactl > >> > >> > >> This error is new to me. PKI service start script apparently calls grep > >> function with wrong arguments. CCing Ade and Endi from PKI team to help. > >> > >> What version of PKI&IPA are we talking about? > >> > >> Martin > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 20 13:15:48 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Aug 2014 09:15:48 -0400 Subject: [Freeipa-users] dirsrv access log redirect In-Reply-To: <53F463C0.5080300@redhat.com> References: <53F463C0.5080300@redhat.com> Message-ID: <53F49F84.4010208@redhat.com> Dmitri Pal wrote: > On 08/20/2014 06:23 AM, barrykfl at gmail.com wrote: >> Dear all: >> >> I got 2 servers as cluster ... how can i redirect all logs server2 's >> /var/log/dirsrv/slapd-abc.com/access to >> server 1 's /var/log/dirsrv/slapd-abc.com/access >> >> >> so i can view once ?what config should consider ? Or should i use >> syslog to collect server2 >> and redirect all to server 1 ? >> >> thks >> >> >> > You should use log collection tools of your choice to collect and > process the logs. > You can send logs to syslog and then use rsyslog to collect it. After > that you can use different tools to process it: logstash, splunk, etc. Take a look at this page for instructions on redirecting logging in 389-ds: http://www.port389.org/wiki/Named_Pipe_Log_Script rob From lkrispen at redhat.com Wed Aug 20 13:16:51 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 20 Aug 2014 15:16:51 +0200 Subject: [Freeipa-users] Need for some pull-style replication, or an alternate solution In-Reply-To: <53F49AB1.8010105@redhat.com> References: <6049577.AbIWlARZBF@hosanna> <53F2FC13.7090809@redhat.com> <4861692.8zCsvlK8bH@hosanna> <53F4633A.8090708@redhat.com> <53F49AB1.8010105@redhat.com> Message-ID: <53F49FC3.6050906@redhat.com> On 08/20/2014 02:55 PM, Petr Spacek wrote: > On 20.8.2014 10:58, Dmitri Pal wrote: >> On 08/19/2014 07:55 PM, Joshua J. Kugler wrote: >>> A replica must connect to the master for initial setup; after that, >>> the master >>> pushes to the replica. >>> >>> j >>> >>> On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote: >>>> What's wrong with your scenario B: master(s) in internal network, they >>>> can contact consumers in DMZ and remote rack and replicate to them. >>>> What do you mean by "to contact for setup" ? >>>> >>>> Ludwig >>>> >>>> On 08/19/2014 03:12 AM, Joshua J. Kugler wrote: >>>>> So, we have a need for replication, but the existing push-only >>>>> methodology >>>>> doesn't work for us. I suppose our problems could be attributed to >>>>> over- >>>>> zealous network rules, but it is what it is. :) I'd love to change >>>>> our >>>>> network policy, but we aren't in charge of network policy, and >>>>> there is >>>>> no way I'm swaying the person that is. >>>>> >>>>> Topology: >>>>> 1) DMZ environments 1,...,n >>>>> 2) An Internal network >>>>> 3) A remote rack in a data center. >>>>> >>>>> Rules (by "talk" I mean initiate connections to): >>>>> 1) DMZs can talk to each other, somewhat. >>>>> 2) The Internal network can talk to the DMZs >>>>> 3) The DMZ *cannot* connect to the Internal network >>>>> 4) The remote rack of course cannot contact the Internal network, >>>>> but can >>>>> contact the DMZs. >>>>> >>>>> Scenario A, Master in a DMZ: >>>>> - Slave in the Internal network could contact the DMZ master >>>>> for replica >>>>> >>>>> setup, but the Master could not contact the slave to push updates >>>>> >>>>> - Slave in the remote rack could contact master in DMZ, but >>>>> incoming to >>>>> >>>>> remote rack is very restrictive, so it is possible that master >>>>> couldn't >>>>> push. >>>>> >>>>> Scenario B: Master in the Internal network. >>>>> >>>>> - Slaves in DMZ and remote rack couldn't contact master for setup, >>>>> although >>>>> >>>>> the master could contact the slaves to push updates. >>>>> >>>>> Scenario C: Master in remote rack >>>>> >>>>> - Not acceptable as remote rack is a testing rack, and may go >>>>> down at >>>>> any >>>>> >>>>> time. >>>>> >>>>> So, the best solution, from my current understanding is being able to >>>>> somehow> >>>>> do pull-updates for replicas, because then we could have this: >>>>> - Master in DMZs >>>>> - Slaves in Internal network can contact Master in DMZ for >>>>> replica setup >>>>> and> >>>>> updates >>>>> >>>>> - Slaves in remote rack can contact Master in DMZ for replica >>>>> setup and >>>>> >>>>> updates >>>>> >>>>> Any feedback is appreciated, especially if I'm missing >>>>> something...obvious >>>>> or minor. >>>>> >>>>> j >> I think you capture the problem correctly. There is unfortunately no >> solution >> for this at the moment. >> We considered looking into read only replicas but this is not exactly >> what >> would help here either since changes to RO replicas would be rerouted >> to the >> real masters and thos need to be accessible from DMZ or remote req in >> your >> case - so it will be inbound connection here. >> I am not sure there is a way to help you here with the current >> software. The >> only option I see is a two different domains - internal and external >> with some >> manually set trust in between. You bight be able to sync people in >> some way >> with some scripts but still that would be quite fragile. >> Are the users operating inside the FW and in DMZ/remote are really >> same users? > > Or IPA-to-IPA trust? :-) > > Joshua, if you want to experiment: > > Ludwig said earlier in this thread that 389 replication will work fine > if master is inside internal network (and thus able to contact other > replicas in DMZ or external network). > > It seems to me that main *technical* problem is "replica setup" phase > where replica contacts the original master and not the other way around. yes, and you make it a read only consumer, otherwise it would try to establish a replication connection. So it ends all up in setting this up 'manually'. > > You can use e.g. SSH from master to replica and do some tricks with > port forwarding and iptables/routing table so the replica will be able > to contact the master inside internal network. (That will breach all > policies you have, of course.) > > If you want to experiment even more, you can try to use port > forwarding for replica setup and then close the hole. 389 replication > should work because master will connect to replica and not the other > way around. I'm not sure what else will break... > From rcritten at redhat.com Wed Aug 20 13:21:14 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Aug 2014 09:21:14 -0400 Subject: [Freeipa-users] IPA Master Issue - Not starting In-Reply-To: <53F4588C.7040301@redhat.com> References: <96A72336A6B7174C9F0D4ADDB784B50E417D119A@AUPDC00-MBX01P.au.ad.westfield.com> <53EDB265.9020103@redhat.com> <96A72336A6B7174C9F0D4ADDB784B50E417DC3A8@AUPDC00-MBX01P.au.ad.westfield.com> <53F4588C.7040301@redhat.com> Message-ID: <53F4A0CA.1090505@redhat.com> Petr Spacek wrote: > On 20.8.2014 10:02, Peter Grant wrote: >> Hi Petr, >> >> Thanks for your help the other day. >> >> Something is bringing down my master instance. >> >> i am seeing mismatch on master >> >> [root at master init.d]# kvno DNS/master.domain.com at domain.COM >> DNS/master.domain.com at domain.COM: kvno = 8 >> [root at master init.d]# klist -kt /etc/named.keytab >> Keytab name: FILE:/etc/named.keytab >> KVNO Timestamp Principal >> ---- ----------------- >> -------------------------------------------------------- >> 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM >> 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM >> 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM >> 33 08/20/14 16:41:42 DNS/master.domain.com at domain.COM >> 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM >> 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM >> 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM >> 34 08/20/14 16:53:29 DNS/master.domain.com at domain.COM >> 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM >> 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM >> 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM >> 35 08/20/14 16:59:37 DNS/master.domain.com at domain.COM >> 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM >> 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM >> 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM >> 38 08/20/14 17:02:30 DNS/master.domain.com at domain.COM >> 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM >> 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM >> 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM >> 41 08/20/14 17:07:45 DNS/master.domain.com at domain.COM >> 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM >> 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM >> 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM >> 42 08/20/14 17:13:17 DNS/master.domain.com at domain.COM >> 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM >> 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM >> 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM >> 45 08/20/14 17:20:34 DNS/master.domain.com at domain.COM >> 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM >> 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM >> 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM >> 46 08/20/14 17:35:00 DNS/master.domain.com at domain.COM >> 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM >> 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM >> 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM >> 47 08/20/14 17:37:43 DNS/master.domain.com at domain.COM >> 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM >> 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM >> 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM >> 48 08/20/14 17:41:42 DNS/master.domain.com at domain.COM >> 49 08/20/14 17:43:43 DNS/master.domain.com at domain.COM >> 49 08/20/14 17:43:44 DNS/master.domain.com at domain.COM >> 49 08/20/14 17:43:44 DNS/master.domain.com at domain.COM >> 49 08/20/14 17:43:44 DNS/master.domain.com at domain.COM >> [root at master init.d]# >> >> >> also here is output from /var/log/messages whilst trying to ipactl start >> >> >> >> [root at master init.d]# sudo ipactl start >> Starting Directory Service >> Starting dirsrv: >> domain-COM... [ OK ] >> PKI-IPA... [ OK ] >> Starting KDC Service >> Starting Kerberos 5 KDC: [ OK ] >> Starting KPASSWD Service >> Starting Kerberos 5 Admin Server: [ OK ] >> Starting DNS Service >> Starting named: 2014-08-20T18:00:22.098747+10:00 master named[20827]: >> starting BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 -u named >> 2014-08-20T18:00:22.099552+10:00 master named[20827]: built with >> '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' >> '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' >> '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' >> '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' >> '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' >> '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' >> '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' >> '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' >> '--disable-openssl-version-check' '--with-dlz-ldap=yes' >> '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' >> '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' >> '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' >> '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' >> 'host_alias=x86_64-redhat-linux-gnu' >> 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall >> -Wp,-D_FO! > RTIFY_SOUR > CE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 > -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' >> 2014-08-20T18:00:22.099633+10:00 master named[20827]: >> ---------------------------------------------------- >> 2014-08-20T18:00:22.099688+10:00 master named[20827]: BIND 9 is >> maintained by Internet Systems Consortium, >> 2014-08-20T18:00:22.099750+10:00 master named[20827]: Inc. (ISC), a >> non-profit 501(c)(3) public-benefit >> 2014-08-20T18:00:22.099803+10:00 master named[20827]: corporation. >> Support and training for BIND 9 are >> 2014-08-20T18:00:22.099864+10:00 master named[20827]: available at >> https://www.isc.org/support >> 2014-08-20T18:00:22.099925+10:00 master named[20827]: >> ---------------------------------------------------- >> 2014-08-20T18:00:22.099998+10:00 master named[20827]: adjusted limit >> on open files from 62000 to 1048576 >> 2014-08-20T18:00:22.100207+10:00 master named[20827]: found 1 CPU, >> using 1 worker thread >> 2014-08-20T18:00:22.100484+10:00 master named[20827]: using up to 4096 >> sockets >> 2014-08-20T18:00:22.103796+10:00 master named[20827]: loading >> configuration from '/etc/named.conf' >> 2014-08-20T18:00:22.104495+10:00 master named[20827]: using default >> UDP/IPv4 port range: [1024, 65535] >> 2014-08-20T18:00:22.104728+10:00 master named[20827]: using default >> UDP/IPv6 port range: [1024, 65535] >> 2014-08-20T18:00:22.106090+10:00 master named[20827]: listening on >> IPv6 interfaces, port 53 >> 2014-08-20T18:00:22.108167+10:00 master named[20827]: listening on >> IPv4 interface lo, 127.0.0.1#53 >> 2014-08-20T18:00:22.108571+10:00 master named[20827]: listening on >> IPv4 interface eth0, 10.3.11.16#53 >> 2014-08-20T18:00:22.109760+10:00 master named[20827]: generating >> session key for dynamic DNS >> 2014-08-20T18:00:22.109997+10:00 master named[20827]: sizing zone task >> pool based on 5 zones >> 2014-08-20T18:00:22.112660+10:00 master named[20827]: set up managed >> keys zone for view _default, file 'dynamic/managed-keys.bind' >> 2014-08-20T18:00:22.129607+10:00 master named[20827]: Failed to init >> credentials (Generic preauthentication failure) >> 2014-08-20T18:00:22.130031+10:00 master named[20827]: loading >> configuration: failure >> 2014-08-20T18:00:22.130285+10:00 master named[20827]: exiting (due to >> fatal error) >> [FAILED] >> Failed to start DNS Service >> Shutting down >> Stopping Kerberos 5 KDC: [ OK ] >> Stopping Kerberos 5 Admin Server: 2014-08-20T18:00:23.833115+10:00 >> master ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code >> may provide more information (Server krbtgt/LOCALDOMAIN at domain.COM not >> found in Kerberos database) > > This seems to be more serious - I suspect that replication between > replicas doesn't work because replica is not able to authenticate. > > The error message is suspicious but I'm not sure that it is not result > of obfuscation. Please try to apply this article to ns-slapd on your > broken master: > > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a2.Serverldapsrv01EXAMPLE.COMnotfoundinKerberosdatabase > > > Maybe /etc/hosts is somehow misconfigured. > >> [ OK ] >> Stopping named: [ OK ] >> Stopping httpd: [FAILED] >> Stopping pki-ca: [ OK ] >> Shutting down dirsrv: >> domain-COM... [ OK ] >> PKI-IPA... [ OK ] >> Aborting ipactl >> [root at master init.d]# >> >> however there is still a mismatch when i try to get key tab from >> secondary using command >> ipa-getkeytab -s secondary.domain.com -p >> DNS/master.domain.com at domain.COM -k /etc/named.keytab > > Maybe it is caused by broken replication (one KDC have different keys > than the other KDC). I would start with replication problems and focus > on named later. > I think Petr is right. Consider this. You got a new keytab from the other master and because this master is down it hasn't been replicated yet. So this master starts and named tries to use a keytab that the local master doesn't know about, so things stop. What I'd do is this: - Set /etc/resolv.conf to point to working master # service dirsrv start # service krb5kdc start # service httpd start Wait a bit for replication to take place. You can probably watch the dirsrv access log for all the gory details. Once things settle down check on replication status: # ipa-replica-manage list -v `hostname` You can check on the kvno per the local KDC using: # kinit admin # kvno DNS/`hostname` The kvno should match the highest one in the keytab. If it doesn't then that suggests an issue with replication. If it does match, try to start named. If that comes up ok, I'd manually shut these all off an then use ipactl to start everything up. rob From walid.shaari at gmail.com Wed Aug 20 13:30:02 2014 From: walid.shaari at gmail.com (Walid) Date: Wed, 20 Aug 2014 16:30:02 +0300 Subject: [Freeipa-users] ipa 2 client connecting to ipa 3 server Message-ID: Hello All, What is the recommendation on having ipa2 clients connecting to IPA 3 server, we have some RHEL5.3 clients (I know they are EOL, however end user still wants as it is) that we would like to connect them to IPA 3.x server running RHEL6.5. Any one running free-ipa on RHEL instead of the Red Hat packages on RHEL5, and RHEL6? regards Walid -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Aug 20 13:43:22 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 20 Aug 2014 15:43:22 +0200 Subject: [Freeipa-users] ipa 2 client connecting to ipa 3 server In-Reply-To: References: Message-ID: <53F4A5FA.5000803@redhat.com> On 08/20/2014 03:30 PM, Walid wrote: > Hello All, > > What is the recommendation on having ipa2 clients connecting to IPA 3 > server, we have some RHEL5.3 clients (I know they are EOL, however end > user still wants as it is) that we would like to connect them to IPA > 3.x server running RHEL6.5. > > Any one running free-ipa on RHEL instead of the Red Hat packages on > RHEL5, and RHEL6? > > regards > > Walid > > > > > 5.3 clean can be connected to IPA using pam_krb5 or pam_ldap for authentication and nss_ldap for identity. Perfectly reasonable and supported configuration. No need to run unsupported packages on RHEL. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kybaker at redhat.com Wed Aug 20 13:45:56 2014 From: kybaker at redhat.com (Kyle Baker) Date: Wed, 20 Aug 2014 09:45:56 -0400 (EDT) Subject: [Freeipa-users] Improving FreeIPA.org In-Reply-To: <53F460D8.1080307@redhat.com> References: <9769CCE57C8E5A44B968BAB661851133D294FA@WPMBX060.bskyb.com> <53F460D8.1080307@redhat.com> Message-ID: <2066613071.41843000.1408542356070.JavaMail.zimbra@redhat.com> > -------- Original Message -------- > Subject: Re: [Freeipa-users] Improving FreeIPA.org > Date: Tue, 19 Aug 2014 16:33:49 +0000 > From: Choudhury, Suhail > To: freeipa-users at redhat.com > > > > Hi, > > I think a small screenshot in the middle or on the side of the main webpage > will serve to increase the "coolness" of the website and may possibly even > result in many more people trying it out and visiting the demo. I agree, I think images would help break up some of the content on the homepage. Also I would consider how much content appears on the homepage. In the current state there is so much information which makes it is hard to parse. The information is very dense as well. It might be useful to think about presenting the information on the homepage in the same way you would tell someone verbally about FreeIPA. I think the Bootstrap project does a nice job of presenting an overview of information at a high level - http://getbootstrap.com/ > > Regards, > Suhail Choudhury. > DevOps | Recommendations Team | BSkyB > Regards, > Suhail Choudhury. > DevOps | Recommendations Team | BSkyB > > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on > behalf of Petr Spacek [pspacek at redhat.com] > Sent: 19 August 2014 16:13 > To: freeipa-users at redhat.com > Subject: [Freeipa-users] Improving FreeIPA.org > > Hello community, > > Do you have an idea how to improve Freeipa.org web site? Share it! > > I will start: > > The main page currently contains three links placed right above "Main > features" section header: > > "Learn more about FreeIPA ? What FreeIPA means for me? ? Try FreeIPA in a > public demo" > > It seems to me that two links > "Learn more about FreeIPA" [http://www.freeipa.org/page/About] > and > "What FreeIPA means for me?" [http://www.freeipa.org/page/Leaflet] > are somehow too much for the main page. > > I propose to either merge "About" and "Leaflet" or to hide Leaflet from main > page. > > It would be better to replace Leaftlet with Quick Start Guide: > "Learn more about FreeIPA ? Quick Start Guide ? Try FreeIPA in a public demo" > > From rcritten at redhat.com Wed Aug 20 13:55:47 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Aug 2014 09:55:47 -0400 Subject: [Freeipa-users] ipa 2 client connecting to ipa 3 server In-Reply-To: References: Message-ID: <53F4A8E3.4070004@redhat.com> Walid wrote: > Hello All, > > What is the recommendation on having ipa2 clients connecting to IPA 3 > server, we have some RHEL5.3 clients (I know they are EOL, however end > user still wants as it is) that we would like to connect them to IPA > 3.x server running RHEL6.5. Should work fine with no problems. > Any one running free-ipa on RHEL instead of the Red Hat packages on > RHEL5, and RHEL6? Depending on the versions of IPA and RHEL it can be difficult but not impossible. The biggest obstacle is missing or older dependencies, some of which are extremely non-trivial to backport. RHEL 5 still has Python 2.4 which makes the backport that much more difficult. rob From jkinney at emory.edu Wed Aug 20 14:10:04 2014 From: jkinney at emory.edu (Jim Kinney) Date: Wed, 20 Aug 2014 10:10:04 -0400 Subject: [Freeipa-users] "admin" user ssh required for replication? Message-ID: <1408543804.3466.18.camel@serenity.cci.emory.edu> All, I'm setting up a new replicated master (CentOS7) from a CentOS 6.5 original master. I added the patch (to the freeIPA 3.3 on CentOS 7) from https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=8c98561c209d0ccaa692a335e3e9a10aec23ee0e to handle the 2 replication IDs bug. The replication fails to complete. If I exclude the connection check, it fails. If I leave the connection check in place, it asks for an ssh password for the admin@. There is no admin user on that machine. The admin user is only in freeIPA. Should there be an admin user account exposed? Did I find a config change between 3.0 and 3.3 releases? -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkinney at emory.edu 404.712.0300 bmi.emory.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From baghery.jone at gmail.com Wed Aug 20 14:29:21 2014 From: baghery.jone at gmail.com (alireza baghery) Date: Wed, 20 Aug 2014 18:59:21 +0430 Subject: [Freeipa-users] i inetgrated ipa server with AD but users AD can not loggin on server linux? In-Reply-To: <53F49B44.5040703@redhat.com> References: <53F49B44.5040703@redhat.com> Message-ID: yes right. ipa trust relation with AD and subdomain AD. yes gde produce log On Wed, Aug 20, 2014 at 5:27 PM, Dmitri Pal wrote: > On 08/20/2014 01:45 PM, alireza baghery wrote: > > hi > Having a particularly weird problem. We have moved from AD(windows > 2008 R2) > to ipa server(centos 6.5). and i integrated ipa with AD > machine linux joined with ipa and machine windowse joined with AD. > users AD can loggin in cli mode in system linux (centos 6.5) > but can not in GUI mod loggin > > > > Do I get it right: > > User from AD walks to a desktop console of the Linux system joined into > IPA that is in trust relations with AD and the GDE produces the following > log? > > > error message in file /var/log/security > > ---------------------------------------------------------------------------------- > pam: gdm-password[2685]: pam_unix(gdm-password:auth): > authentication failure: logname= uid=0 euid=0 tty=:0 ruser= rhost= > rhost= user=sallea at AD > pam: gdm-password[2685]: pam_sss(gdm-password:auth): > user info message: your password will expire in 40 day > pam: gdm-password[2685]:pam_sss( > gdm-password:auth): > authenticate success: logname= uid=0 euid=0 tty=:0 ruser= rhost= > rhost= user=sallea at AD > pam: gdm-password[2685]:pam_unix (gdm-password:session): > session opened for user sallea at AD by (uid=0) > polkitd(authority=local): Unregistered Authentication > Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus > name :1.116 , object path /org/gnome/PolcyKit1/AuthenticationAgent, > > - Ignored: > local en_US) (disconnected from bus) > > pam: gdm-password[2685]: pam_unix (gdm-password:session): > session closed for user sallea at AD > ------------------------------------------------------ > > and context file /etc/pam.d/password-auth > ----------------------------------- > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_sss.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > password requisite pam_cracklib.so try_first_pass retry=3 type= > password sufficient pam_unix.so sha512 shadow nullok > try_first_pass use_authtok > password sufficient pam_sss.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > session [success=1 default=ignore] pam_succeed_if.so service in > crond quiet use_uid > session required pam_unix.so > > session require pam_sss.so > -------------------------------------- > how to solve this problem? > thanks > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 20 14:37:20 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Aug 2014 10:37:20 -0400 Subject: [Freeipa-users] "admin" user ssh required for replication? In-Reply-To: <1408543804.3466.18.camel@serenity.cci.emory.edu> References: <1408543804.3466.18.camel@serenity.cci.emory.edu> Message-ID: <53F4B2A0.4070103@redhat.com> Jim Kinney wrote: > All, > > I'm setting up a new replicated master (CentOS7) from a CentOS 6.5 > original master. I added the patch (to the freeIPA 3.3 on CentOS 7) from > https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=8c98561c209d0ccaa692a335e3e9a10aec23ee0e > to handle the 2 replication IDs bug. > > The replication fails to complete. If I exclude the connection check, it > fails. If I leave the connection check in place, it asks for an ssh > password for the admin@. There is no admin user on > that machine. The admin user is only in freeIPA. > > Should there be an admin user account exposed? Did I find a config > change between 3.0 and 3.3 releases? The admin user is in freeIPA so therefore the user IS on that original master. The connection check is there to confirm that the required ports are available in both directions. If replication is failing it may be due to that, but without details it's hard to say. rob From dpal at redhat.com Wed Aug 20 15:00:14 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 20 Aug 2014 17:00:14 +0200 Subject: [Freeipa-users] i inetgrated ipa server with AD but users AD can not loggin on server linux? In-Reply-To: References: <53F49B44.5040703@redhat.com> Message-ID: <53F4B7FE.5050802@redhat.com> On 08/20/2014 04:29 PM, alireza baghery wrote: > yes right. ipa trust relation with AD and subdomain AD. yes gde > produce log It seems that you have some custom polkit policy that fails to load. Did you play with some polkit policies? > > > On Wed, Aug 20, 2014 at 5:27 PM, Dmitri Pal > wrote: > > On 08/20/2014 01:45 PM, alireza baghery wrote: >> hi >> Having a particularly weird problem. We have moved from >> AD(windows 2008 R2) >> to ipa server(centos 6.5). and i integrated ipa with AD >> machine linux joined with ipa and machine windowse joined >> with AD. >> users AD can loggin in cli mode in system linux (centos 6.5) >> but can not in GUI mod loggin > > > Do I get it right: > > User from AD walks to a desktop console of the Linux system joined > into IPA that is in trust relations with AD and the GDE produces > the following log? > > >> error message in file /var/log/security >> ---------------------------------------------------------------------------------- >> pam: gdm-password[2685]: pam_unix(gdm-password:auth): >> authentication failure: logname= uid=0 euid=0 tty=:0 ruser= >> rhost= >> rhost= user=sallea at AD >> pam: gdm-password[2685]: pam_sss(gdm-password:auth): >> user info message: your password will expire in 40 day >> pam: gdm-password[2685]:pam_sss( >> gdm-password:auth): >> authenticate success: logname= uid=0 euid=0 tty=:0 ruser= rhost= >> rhost= user=sallea at AD >> pam: gdm-password[2685]:pam_unix (gdm-password:session): >> session opened for user sallea at AD by (uid=0) >> polkitd(authority=local): Unregistered Authentication >> Agent for session /org/freedesktop/ConsoleKit/Session4 >> (system bus >> name :1.116 , object path >> /org/gnome/PolcyKit1/AuthenticationAgent, >> >> - Ignored: >> local en_US) (disconnected from bus) >> >> pam: gdm-password[2685]: pam_unix (gdm-password:session): >> session closed for user sallea at AD >> ------------------------------------------------------ >> >> and context file /etc/pam.d/password-auth >> ----------------------------------- >> auth required pam_env.so >> auth sufficient pam_unix.so nullok try_first_pass >> auth requisite pam_succeed_if.so uid >= 500 quiet >> auth sufficient pam_sss.so use_first_pass >> auth required pam_deny.so >> >> account required pam_unix.so >> account sufficient pam_localuser.so >> account sufficient pam_succeed_if.so uid < 500 quiet >> account [default=bad success=ok user_unknown=ignore] >> pam_sss.so >> account required pam_permit.so >> >> password requisite pam_cracklib.so try_first_pass >> retry=3 type= >> password sufficient pam_unix.so sha512 shadow nullok >> try_first_pass use_authtok >> password sufficient pam_sss.so use_authtok >> password required pam_deny.so >> >> session optional pam_keyinit.so revoke >> session required pam_limits.so >> session [success=1 default=ignore] pam_succeed_if.so >> service in >> crond quiet use_uid >> session required pam_unix.so >> >> session require pam_sss.so >> -------------------------------------- >> how to solve this problem? >> thanks >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbaird at follett.com Wed Aug 20 15:18:16 2014 From: jbaird at follett.com (Baird, Josh) Date: Wed, 20 Aug 2014 15:18:16 +0000 Subject: [Freeipa-users] ipa-client-install via Kickstart in RHEL7 Message-ID: Hi, We are attempting to run ipa-client-install in the %post section of a Kickstart in order to join the host to an IPA domain (3.3/RHEL7 IdM). We are using something like: /usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U --no-ssh --no-sshd --no-ntp --domain=realm.com The machine does indeed join the domain correctly, but the certmonger request fails. Looking at the logs, we can see this: 2014-08-19T15:02:45Z DEBUG Starting external process 2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service 2014-08-19T15:02:45Z DEBUG Process finished, return code=0 2014-08-19T15:02:45Z DEBUG stdout= 2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request. The error is occurring because the certmonger service fails to start. This is because systemd is not able to manipulate services in a chrooted environment (ala the anaconda installation environment). Prior to systemd, this would work fine as services could start normally via init in a chroot/%post. Additionally, we see the error: Unable to find 'admin' user with 'getent passwd admin at domain.com' Again, this is because systemd is unable to start sssd in the chrooted installation environment. I'm wondering if anyone else has experienced these issues with systemd unable to start these required services during installation and what you did to work around them. One option would be to move the ipa-client-install out of Kickstart and have Puppet join the host to the domain post-installation (after firstboot), but this isn't really ideal. Any advice or suggestions would be appreciated. Thanks, Josh From rmeggins at redhat.com Wed Aug 20 15:24:52 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 20 Aug 2014 09:24:52 -0600 Subject: [Freeipa-users] ipa-client-install via Kickstart in RHEL7 In-Reply-To: References: Message-ID: <53F4BDC4.7090309@redhat.com> On 08/20/2014 09:18 AM, Baird, Josh wrote: > Hi, > > We are attempting to run ipa-client-install in the %post section of a Kickstart in order to join the host to an IPA domain (3.3/RHEL7 IdM). We are using something like: > > /usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U --no-ssh --no-sshd --no-ntp --domain=realm.com > > The machine does indeed join the domain correctly, but the certmonger request fails. Looking at the logs, we can see this: > > 2014-08-19T15:02:45Z DEBUG Starting external process > 2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service > 2014-08-19T15:02:45Z DEBUG Process finished, return code=0 > 2014-08-19T15:02:45Z DEBUG stdout= > 2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request. > > The error is occurring because the certmonger service fails to start. This is because systemd is not able to manipulate services in a chrooted environment (ala the anaconda installation environment). Prior to systemd, this would work fine as services could start normally via init in a chroot/%post. > > Additionally, we see the error: > > Unable to find 'admin' user with 'getent passwd admin at domain.com' > > Again, this is because systemd is unable to start sssd in the chrooted installation environment. I'm wondering if anyone else has experienced these issues with systemd unable to start these required services during installation and what you did to work around them. One option would be to move the ipa-client-install out of Kickstart and have Puppet join the host to the domain post-installation (after firstboot), but this isn't really ideal. > > Any advice or suggestions would be appreciated. Create a file that is run at boot, presumably after networking and certmonger are started. > > Thanks, > > Josh > From jkinney at emory.edu Wed Aug 20 16:03:37 2014 From: jkinney at emory.edu (Jim Kinney) Date: Wed, 20 Aug 2014 12:03:37 -0400 Subject: [Freeipa-users] "admin" user ssh required for replication? In-Reply-To: <1408543804.3466.18.camel@serenity.cci.emory.edu> References: <1408543804.3466.18.camel@serenity.cci.emory.edu> Message-ID: <1408550617.3466.35.camel@serenity.cci.emory.edu> Found a solution: The first replica I built did not have the CA replication setup. So I ran the ipa-ca-install with it's original replica file on the first replica. Now that system is able to generate a replica.gpg file for the new centos7 box. The new box replicated just fine and all is well with it. Now I can resync the ldap on the original master and fix it. Of course the weirdness is the web gui shows data for users but the system itself can't use that data. Maybe I should dig into the pam modules. On Wed, 2014-08-20 at 10:10 -0400, Jim Kinney wrote: > All, > > I'm setting up a new replicated master (CentOS7) from a CentOS 6.5 > original master. I added the patch (to the freeIPA 3.3 on CentOS 7) > from > https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=8c98561c209d0ccaa692a335e3e9a10aec23ee0e > to handle the 2 replication IDs bug. > > The replication fails to complete. If I exclude the connection check, > it fails. If I leave the connection check in place, it asks for an ssh > password for the admin@. There is no admin user > on that machine. The admin user is only in freeIPA. > > Should there be an admin user account exposed? Did I find a config > change between 3.0 and 3.3 releases? > -- > > Jim Kinney > Senior System Administrator > Department of BioMedical Informatics > Emory University > jimkinney at emory.edu > 404.712.0300 > bmi.emory.edu > plain text document attachment (ATT00001) > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkinney at emory.edu 404.712.0300 bmi.emory.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbaird at follett.com Wed Aug 20 16:12:08 2014 From: jbaird at follett.com (Baird, Josh) Date: Wed, 20 Aug 2014 16:12:08 +0000 Subject: [Freeipa-users] Problems establishing a trust with AD Message-ID: Hi, I'm attempting to establish a trust between FreeIPA 3.3 and AD 2008 R2. My IPA domain consists of two servers (one master and one replica). I have verified that DNS is configured properly as the IPA domain can resolve AD and the AD domain can resolve IPA hosts. On each IPA server, I performed the following: $ yum install ipa-server-trust-ad samba-client $ ipa-adtrust-install On the main IPA server, I executed the following: $ ipa trust-add --admin administrator --password The output of this command suggests that establishing the trust was successful: ------------------------------------------------- Added Active Directory trust for realm "test.lan" ------------------------------------------------- Realm name: test.lan Domain NetBIOS name: TEST Domain Security Identifier: S-1-5-21-2234298371-4032204425-1996979893 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified Additionally, I can also see the IPA domain in Active Directory Domains and Trusts on the Windows side. Next, I successfully requested a service ticket for the AD domain: $ kvno cifs/vmxxenttest01.test.lan at TEST.LAN cifs/vmxxenttest01.test.lan at TEST.LAN: kvno = 4 $ klist | grep TEST 08/20/2014 11:03:47 08/20/2014 21:03:47 cifs/vmxxenttest01.test.lan at TEST.LAN 08/20/2014 11:03:47 08/21/2014 11:00:30 krbtgt/TEST.LAN at QA-UNIX.DOMAIN.COM Next, I modified /etc/krb5.conf on both IDM servers (master and replica) and added the following to the [realms] section and restarted krb5kdc: auth_to_local = RULE:[1:$1@$0](^.*@TEST.LAN$)s/@TEST.LAN/@TEST.LAN/ auth_to_local = DEFAULT I also modified /etc/sssd/sssd.conf and added "pac" to services and "subdomains_provider = ipa." Next, I tried to validate the trust from the AD side using the "Validate" button in AD Domains and Trusts. Once I click the 'Vaildate' button, I choose "Yes, validate the incoming trust" and specify the IPA admin account and password and get notified that the trust cannot be validated due to "There are currently no logon servers available to service the logon requests." It suggests that I reset the trust password, and I accept, but again it fails due to no logon servers. I don't really see anything in the krb5kdc.log logs on the IPA servers. Any ideas how to further troubleshoot this? Thanks, Josh From walid.shaari at gmail.com Wed Aug 20 19:32:32 2014 From: walid.shaari at gmail.com (Walid) Date: Wed, 20 Aug 2014 22:32:32 +0300 Subject: [Freeipa-users] ipa 2 client connecting to ipa 3 server In-Reply-To: <53F4A5FA.5000803@redhat.com> References: <53F4A5FA.5000803@redhat.com> Message-ID: Thanks Dmitri, so sssd is out of the picture in this case? On 20 August 2014 16:43, Dmitri Pal wrote: > On 08/20/2014 03:30 PM, Walid wrote: > > Hello All, > > What is the recommendation on having ipa2 clients connecting to IPA 3 > server, we have some RHEL5.3 clients (I know they are EOL, however end user > still wants as it is) that we would like to connect them to IPA 3.x server > running RHEL6.5. > > Any one running free-ipa on RHEL instead of the Red Hat packages on > RHEL5, and RHEL6? > > regards > > Walid > > > > > > 5.3 clean can be connected to IPA using pam_krb5 or pam_ldap for > authentication and nss_ldap for identity. > Perfectly reasonable and supported configuration. No need to run > unsupported packages on RHEL. > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for 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 walid.shaari at gmail.com Wed Aug 20 19:35:16 2014 From: walid.shaari at gmail.com (Walid) Date: Wed, 20 Aug 2014 22:35:16 +0300 Subject: [Freeipa-users] ipa 2 client connecting to ipa 3 server In-Reply-To: <53F4A8E3.4070004@redhat.com> References: <53F4A8E3.4070004@redhat.com> Message-ID: Thanks Rob, we have native python2.4, and anaconda python 2.7, so i guess if anything needs python 2.6 or greater it would not be an issue. I am just wondering if there are people using the upstream project in such a legacy system ;-) On 20 August 2014 16:55, Rob Crittenden wrote: > Walid wrote: > > Hello All, > > > > What is the recommendation on having ipa2 clients connecting to IPA 3 > > server, we have some RHEL5.3 clients (I know they are EOL, however end > > user still wants as it is) that we would like to connect them to IPA > > 3.x server running RHEL6.5. > > Should work fine with no problems. > > > Any one running free-ipa on RHEL instead of the Red Hat packages on > > RHEL5, and RHEL6? > > Depending on the versions of IPA and RHEL it can be difficult but not > impossible. The biggest obstacle is missing or older dependencies, some > of which are extremely non-trivial to backport. > > RHEL 5 still has Python 2.4 which makes the backport that much more > difficult. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 20 19:43:16 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Aug 2014 15:43:16 -0400 Subject: [Freeipa-users] ipa 2 client connecting to ipa 3 server In-Reply-To: References: <53F4A8E3.4070004@redhat.com> Message-ID: <53F4FA54.6070600@redhat.com> Walid wrote: > Thanks Rob, we have native python2.4, and anaconda python 2.7, so i > guess if anything needs python 2.6 or greater it would not be an issue. > I am just wondering if there are people using the upstream project in > such a legacy system ;-) It's not just python, it's all the modules as well. In the end the issue isn't so much ipa-client as all the related dependencies. The ipa-client package just helps configure things, sssd does all the heavy lifting. If you wanted to backport anything I'd start there, and it is likely extremely non-trivial. I know that people still use RHEL-5 and the current 2.2-based client. It, and its related packages, generally works fine you just miss out on some of the newer features, particularly in sssd (like sudo and autofs). rob > > > On 20 August 2014 16:55, Rob Crittenden > wrote: > > Walid wrote: > > Hello All, > > > > What is the recommendation on having ipa2 clients connecting to IPA 3 > > server, we have some RHEL5.3 clients (I know they are EOL, however end > > user still wants as it is) that we would like to connect them to IPA > > 3.x server running RHEL6.5. > > Should work fine with no problems. > > > Any one running free-ipa on RHEL instead of the Red Hat packages on > > RHEL5, and RHEL6? > > Depending on the versions of IPA and RHEL it can be difficult but not > impossible. The biggest obstacle is missing or older dependencies, some > of which are extremely non-trivial to backport. > > RHEL 5 still has Python 2.4 which makes the backport that much more > difficult. > > rob > > From dpal at redhat.com Wed Aug 20 19:49:01 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 20 Aug 2014 21:49:01 +0200 Subject: [Freeipa-users] ipa 2 client connecting to ipa 3 server In-Reply-To: <53F4FA54.6070600@redhat.com> References: <53F4A8E3.4070004@redhat.com> <53F4FA54.6070600@redhat.com> Message-ID: <53F4FBAD.5060006@redhat.com> On 08/20/2014 09:43 PM, Rob Crittenden wrote: > Walid wrote: >> Thanks Rob, we have native python2.4, and anaconda python 2.7, so i >> guess if anything needs python 2.6 or greater it would not be an issue. >> I am just wondering if there are people using the upstream project in >> such a legacy system ;-) > It's not just python, it's all the modules as well. > > In the end the issue isn't so much ipa-client as all the related > dependencies. The ipa-client package just helps configure things, sssd > does all the heavy lifting. If you wanted to backport anything I'd start > there, and it is likely extremely non-trivial. > > I know that people still use RHEL-5 and the current 2.2-based client. > It, and its related packages, generally works fine you just miss out on > some of the newer features, particularly in sssd (like sudo and autofs). You can try to build sssd on 5.3 but I suspect it will require so many dependencies that you system would look more like a 5.10. You can try but this will be an adventurous effort. For old systems like that we recommend using what they had then and not SSSD. Users will be able to authenticate and posix data will be the same as on the more modern systems which should be sufficient for the needs of those old systems anyways. > > rob > >> >> On 20 August 2014 16:55, Rob Crittenden > > wrote: >> >> Walid wrote: >> > Hello All, >> > >> > What is the recommendation on having ipa2 clients connecting to IPA 3 >> > server, we have some RHEL5.3 clients (I know they are EOL, however end >> > user still wants as it is) that we would like to connect them to IPA >> > 3.x server running RHEL6.5. >> >> Should work fine with no problems. >> >> > Any one running free-ipa on RHEL instead of the Red Hat packages on >> > RHEL5, and RHEL6? >> >> Depending on the versions of IPA and RHEL it can be difficult but not >> impossible. The biggest obstacle is missing or older dependencies, some >> of which are extremely non-trivial to backport. >> >> RHEL 5 still has Python 2.4 which makes the backport that much more >> difficult. >> >> rob >> >> -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From abokovoy at redhat.com Wed Aug 20 21:19:58 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 21 Aug 2014 00:19:58 +0300 Subject: [Freeipa-users] Problems establishing a trust with AD In-Reply-To: References: Message-ID: <20140820211958.GU4748@redhat.com> On Wed, 20 Aug 2014, Baird, Josh wrote: >Hi, > >I'm attempting to establish a trust between FreeIPA 3.3 and AD 2008 R2. >My IPA domain consists of two servers (one master and one replica). I >have verified that DNS is configured properly as the IPA domain can >resolve AD and the AD domain can resolve IPA hosts. > >On each IPA server, I performed the following: > >$ yum install ipa-server-trust-ad samba-client >$ ipa-adtrust-install > >On the main IPA server, I executed the following: > >$ ipa trust-add --admin administrator --password > >The output of this command suggests that establishing the trust was successful: > >------------------------------------------------- >Added Active Directory trust for realm "test.lan" >------------------------------------------------- > Realm name: test.lan > Domain NetBIOS name: TEST > Domain Security Identifier: S-1-5-21-2234298371-4032204425-1996979893 > SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, > S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 > SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, > S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 > Trust direction: Two-way trust > Trust type: Active Directory domain > Trust status: Established and verified > >Additionally, I can also see the IPA domain in Active Directory Domains >and Trusts on the Windows side. Next, I successfully requested a >service ticket for the AD domain: > >$ kvno cifs/vmxxenttest01.test.lan at TEST.LAN >cifs/vmxxenttest01.test.lan at TEST.LAN: kvno = 4 >$ klist | grep TEST >08/20/2014 11:03:47 08/20/2014 21:03:47 cifs/vmxxenttest01.test.lan at TEST.LAN >08/20/2014 11:03:47 08/21/2014 11:00:30 krbtgt/TEST.LAN at QA-UNIX.DOMAIN.COM All is good. At this point, if kvno as IPA user works against AD DC, you don't need to perform validation from AD side. >Next, I modified /etc/krb5.conf on both IDM servers (master and >replica) and added the following to the [realms] section and restarted >krb5kdc: > >auth_to_local = RULE:[1:$1@$0](^.*@TEST.LAN$)s/@TEST.LAN/@TEST.LAN/ >auth_to_local = DEFAULT The AD domain rule is a bit wrong, the last part (replacement) should be low-cased. auth_to_local = RULE:[1:$1@$0](^.*@TEST.LAN$)s/@TEST.LAN/@test.lan/ >I also modified /etc/sssd/sssd.conf and added "pac" to services and "subdomains_provider = ipa." Did you restart sssd at this point? Did you try getent passwd administrator at test.lan or id administrator at test.lan ? > >Next, I tried to validate the trust from the AD side using the >"Validate" button in AD Domains and Trusts. Once I click the >'Vaildate' button, I choose "Yes, validate the incoming trust" and >specify the IPA admin account and password and get notified that the >trust cannot be validated due to "There are currently no logon servers >available to service the logon requests." It suggests that I reset the >trust password, and I accept, but again it fails due to no logon >servers. > >I don't really see anything in the krb5kdc.log logs on the IPA servers. >Any ideas how to further troubleshoot this? As I said, if kvno succeeds as IPA user against AD services, no additional validation from AD side is needed. Since you did establish trust using AD admin credentials, IPA did issue request to validate trust automatically. You may re-establish trust if you think your actions on AD side broke something in the trust objects in AD. -- / Alexander Bokovoy From william at firstyear.id.au Wed Aug 20 23:01:10 2014 From: william at firstyear.id.au (William) Date: Thu, 21 Aug 2014 08:31:10 +0930 Subject: [Freeipa-users] Ldapsearch with a trailing space Message-ID: <1408575670.24664.3.camel@ammy.its.adelaide.edu.au> Hi, Semi offtopic, how does one search with ldap for an attribute instance with a trailing space. Consider: "cn=foo " How do you distinguish this from "cn=foo" in an ldapsearch? I have tried: ldapsearch (cn=foo) ldapsearch (cn='foo ') ldapsearch (&(cn=foo*)(!(cn=foo))) ldapsearch (cn=foo\20) Any other ideas? -- William From rmeggins at redhat.com Wed Aug 20 23:12:53 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 20 Aug 2014 17:12:53 -0600 Subject: [Freeipa-users] Ldapsearch with a trailing space In-Reply-To: <1408575670.24664.3.camel@ammy.its.adelaide.edu.au> References: <1408575670.24664.3.camel@ammy.its.adelaide.edu.au> Message-ID: <53F52B75.2040708@redhat.com> On 08/20/2014 05:01 PM, William wrote: > Hi, > > Semi offtopic, how does one search with ldap for an attribute instance > with a trailing space. Consider: > > "cn=foo" > > How do you distinguish this from "cn=foo" in an ldapsearch? I have > tried: > > ldapsearch (cn=foo) > ldapsearch (cn='foo ') > ldapsearch (&(cn=foo*)(!(cn=foo))) > ldapsearch (cn=foo\20) > > Any other ideas? > How did you manage to add an attribute value with a trailing space? From william at firstyear.id.au Wed Aug 20 23:28:16 2014 From: william at firstyear.id.au (William) Date: Thu, 21 Aug 2014 08:58:16 +0930 Subject: [Freeipa-users] Ldapsearch with a trailing space In-Reply-To: <53F52B75.2040708@redhat.com> References: <1408575670.24664.3.camel@ammy.its.adelaide.edu.au> <53F52B75.2040708@redhat.com> Message-ID: <1408577296.24664.4.camel@ammy.its.adelaide.edu.au> > > > How did you manage to add an attribute value with a trailing space? > Excellent question: Someone else in my workplace managed to stuff this one up, so that a users objectClass has a trailing space, thus is returning is base64 on search now. -- William From rmeggins at redhat.com Thu Aug 21 00:32:26 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 20 Aug 2014 18:32:26 -0600 Subject: [Freeipa-users] Ldapsearch with a trailing space In-Reply-To: <1408577296.24664.4.camel@ammy.its.adelaide.edu.au> References: <1408575670.24664.3.camel@ammy.its.adelaide.edu.au> <53F52B75.2040708@redhat.com> <1408577296.24664.4.camel@ammy.its.adelaide.edu.au> Message-ID: <53F53E1A.2080204@redhat.com> On 08/20/2014 05:28 PM, William wrote: >> How did you manage to add an attribute value with a trailing space? >> > Excellent question: Someone else in my workplace managed to stuff this > one up, so that a users objectClass has a trailing space, thus is > returning is base64 on search now. Ok. As to how to fix it: ldapsearch -xLLL -D "cn=directory manager" -W -s base -b "the dn with the broken objectclass" 'objectclass=*' objectclass > junk.ldif then edit junk.ldif to look like this: dn: the dn with the broken objectclass changetype: modify replace: objectclass objectclass: .... objectclass: .... Basically, all of the objectclasses from ldapsearch, but fixing the one with the trailing space Then use ldapmodify ldapmodify -x -D "cn=directory manager" -W -f junk.ldif As to your original question - I'm not sure - I would have thought the correct way to do it would have been to use the ldap escape sequence for space in the ldap search filter. From cwhittl at gmail.com Thu Aug 21 01:27:53 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Wed, 20 Aug 2014 20:27:53 -0500 Subject: [Freeipa-users] Install FreeIPA 4 on ubuntu Message-ID: Is there instructions anywhere? My FreeIPA 3 on CentOS died so I'm starting over -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Thu Aug 21 04:17:12 2014 From: Less at imagine-sw.com (Les Stott) Date: Thu, 21 Aug 2014 04:17:12 +0000 Subject: [Freeipa-users] ntp and srv records Message-ID: <4ED173A868981548967B4FCA2707222627FC38EC@AACMBXP04.exchserver.com> Hi All, Am about to start rolling out clinet installs on rhel6 hosts with dns autodiscovery. Enviroment: rhel6, ipa-3.0.0-37.el6. I already have setup SRV records for Kerberos and ldap etc. Are the following ntp records as SRV records necessary also? ;ntp server _ntp._udp IN SRV 0 100 123 ntp1.mydomain.com. _ntp._udp IN SRV 0 100 123 ntp2.mydomain.com. I've seen some guides that don't reference them, others that do. I don't see any adverse effects on the two freeipa servers (master + replica) that are currently running without the ntp srv records. Thanks in advance, Regards, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Thu Aug 21 04:55:34 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 21 Aug 2014 07:55:34 +0300 Subject: [Freeipa-users] Install FreeIPA 4 on ubuntu In-Reply-To: References: Message-ID: <53F57BC6.1070404@ubuntu.com> On 21.08.2014 04:27, Chris Whittle wrote: > Is there instructions anywhere? My FreeIPA 3 on CentOS died so I'm > starting over there is no server for ubuntu/debian yet -- t From lslebodn at redhat.com Thu Aug 21 06:40:57 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 21 Aug 2014 08:40:57 +0200 Subject: [Freeipa-users] Install FreeIPA 4 on ubuntu In-Reply-To: References: Message-ID: <20140821064057.GB5435@mail.corp.redhat.com> On (20/08/14 20:27), Chris Whittle wrote: >Is there instructions anywhere? My FreeIPA 3 on CentOS died so I'm >starting over You can try FreeIPA 3.3. on CentOS 7 bash-4.2# yum info ipa-server Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.raystedman.net * extras: mirror.solarvps.com * updates: centos.mirror.constant.com Available Packages Name : ipa-server Arch : x86_64 Version : 3.3.3 Release : 28.el7.centos Size : 1.2 M Repo : base/7/x86_64 Summary : The IPA authentication server URL : http://www.freeipa.org/ License : GPLv3+ Description : IPA is an integrated solution to provide centrally managed : Identity (machine, user, virtual machines, groups, authentication : credentials), Policy (configuration settings, access control : information) and Audit (events, logs, analysis thereof). If you : are installing an IPA server you need to install this package (in : other words, most people should NOT install this package). LS From pspacek at redhat.com Thu Aug 21 06:51:45 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 21 Aug 2014 08:51:45 +0200 Subject: [Freeipa-users] ntp and srv records In-Reply-To: <4ED173A868981548967B4FCA2707222627FC38EC@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222627FC38EC@AACMBXP04.exchserver.com> Message-ID: <53F59701.4060707@redhat.com> On 21.8.2014 06:17, Les Stott wrote: > Hi All, > > Am about to start rolling out clinet installs on rhel6 hosts with dns autodiscovery. > > Enviroment: rhel6, ipa-3.0.0-37.el6. > > I already have setup SRV records for Kerberos and ldap etc. > > Are the following ntp records as SRV records necessary also? Technically not but they are highly recommended (assuming that your IPA servers are running a NTP server). > ;ntp server > _ntp._udp IN SRV 0 100 123 ntp1.mydomain.com. > _ntp._udp IN SRV 0 100 123 ntp2.mydomain.com. > > I've seen some guides that don't reference them, others that do. I don't see any adverse effects on the two freeipa servers (master + replica) that are currently running without the ntp srv records. The adverse effect will probably manifest on client side. Things (Kerberos :-) will break if time on client is too far away from time on server. -- Petr^2 Spacek From Less at imagine-sw.com Thu Aug 21 07:01:46 2014 From: Less at imagine-sw.com (Les Stott) Date: Thu, 21 Aug 2014 07:01:46 +0000 Subject: [Freeipa-users] ntp and srv records In-Reply-To: <53F59701.4060707@redhat.com> References: <4ED173A868981548967B4FCA2707222627FC38EC@AACMBXP04.exchserver.com> <53F59701.4060707@redhat.com> Message-ID: <4ED173A868981548967B4FCA2707222627FC3AFA@AACMBXP04.exchserver.com> We have ntp setup on two servers and configured normally via /etc/ntp* etc. All clients and servers reference the same ntp servers, and all would be on the same time. This doesn't require ntp SRV records. So I personally don't thing ntp srv records are necessary and can't see an issue. But wanted to check to be sure.... Les -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Petr Spacek Sent: Thursday, 21 August 2014 4:52 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] ntp and srv records On 21.8.2014 06:17, Les Stott wrote: > Hi All, > > Am about to start rolling out clinet installs on rhel6 hosts with dns autodiscovery. > > Enviroment: rhel6, ipa-3.0.0-37.el6. > > I already have setup SRV records for Kerberos and ldap etc. > > Are the following ntp records as SRV records necessary also? Technically not but they are highly recommended (assuming that your IPA servers are running a NTP server). > ;ntp server > _ntp._udp IN SRV 0 100 123 ntp1.mydomain.com. > _ntp._udp IN SRV 0 100 123 ntp2.mydomain.com. > > I've seen some guides that don't reference them, others that do. I don't see any adverse effects on the two freeipa servers (master + replica) that are currently running without the ntp srv records. The adverse effect will probably manifest on client side. Things (Kerberos :-) will break if time on client is too far away from time on server. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project From lkrispen at redhat.com Thu Aug 21 08:29:48 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 21 Aug 2014 10:29:48 +0200 Subject: [Freeipa-users] Ldapsearch with a trailing space In-Reply-To: <53F53E1A.2080204@redhat.com> References: <1408575670.24664.3.camel@ammy.its.adelaide.edu.au> <53F52B75.2040708@redhat.com> <1408577296.24664.4.camel@ammy.its.adelaide.edu.au> <53F53E1A.2080204@redhat.com> Message-ID: <53F5ADFC.5090306@redhat.com> On 08/21/2014 02:32 AM, Rich Megginson wrote: > On 08/20/2014 05:28 PM, William wrote: >>> How did you manage to add an attribute value with a trailing space? >>> >> Excellent question: Someone else in my workplace managed to stuff this >> one up, so that a users objectClass has a trailing space, thus is >> returning is base64 on search now. > > Ok. As to how to fix it: > ldapsearch -xLLL -D "cn=directory manager" -W -s base -b "the dn with > the broken objectclass" 'objectclass=*' objectclass > junk.ldif > > then edit junk.ldif to look like this: > > dn: the dn with the broken objectclass > changetype: modify > replace: objectclass > objectclass: .... > objectclass: .... > > > Basically, all of the objectclasses from ldapsearch, but fixing the > one with the trailing space > > Then use ldapmodify > > ldapmodify -x -D "cn=directory manager" -W -f junk.ldif > > As to your original question - I'm not sure - I would have thought the > correct way to do it would have been to use the ldap escape sequence > for space in the ldap search filter. I think the behaviour is correct, in caseIgnore match leading and trailing spaces are insignificant and any clever way to pass the space will be normalized away From mkosek at redhat.com Thu Aug 21 11:55:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Aug 2014 13:55:34 +0200 Subject: [Freeipa-users] ipa-client-install via Kickstart in RHEL7 In-Reply-To: <53F4BDC4.7090309@redhat.com> References: <53F4BDC4.7090309@redhat.com> Message-ID: <53F5DE36.20106@redhat.com> On 08/20/2014 05:24 PM, Rich Megginson wrote: > On 08/20/2014 09:18 AM, Baird, Josh wrote: >> Hi, >> >> We are attempting to run ipa-client-install in the %post section of a >> Kickstart in order to join the host to an IPA domain (3.3/RHEL7 IdM). We are >> using something like: >> >> /usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U >> --no-ssh --no-sshd --no-ntp --domain=realm.com >> >> The machine does indeed join the domain correctly, but the certmonger request >> fails. Looking at the logs, we can see this: >> >> 2014-08-19T15:02:45Z DEBUG Starting external process >> 2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service >> 2014-08-19T15:02:45Z DEBUG Process finished, return code=0 >> 2014-08-19T15:02:45Z DEBUG stdout= >> 2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request. >> >> The error is occurring because the certmonger service fails to start. This >> is because systemd is not able to manipulate services in a chrooted >> environment (ala the anaconda installation environment). Prior to systemd, >> this would work fine as services could start normally via init in a >> chroot/%post. >> >> Additionally, we see the error: >> >> Unable to find 'admin' user with 'getent passwd admin at domain.com' >> >> Again, this is because systemd is unable to start sssd in the chrooted >> installation environment. I'm wondering if anyone else has experienced these >> issues with systemd unable to start these required services during >> installation and what you did to work around them. One option would be to >> move the ipa-client-install out of Kickstart and have Puppet join the host to >> the domain post-installation (after firstboot), but this isn't really ideal. >> >> Any advice or suggestions would be appreciated. > > Create a file that is run at boot, presumably after networking and certmonger > are started. What I saw as the common approach in OpenStack or other projects are scripts and configurations for Cloud-init [1]. Are there people using it for this purpose or are there other (better) approaches? [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/End_User_Guide/user-data.html Martin From mkosek at redhat.com Thu Aug 21 11:59:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 21 Aug 2014 13:59:43 +0200 Subject: [Freeipa-users] ipa 2 client connecting to ipa 3 server In-Reply-To: <53F4FBAD.5060006@redhat.com> References: <53F4A8E3.4070004@redhat.com> <53F4FA54.6070600@redhat.com> <53F4FBAD.5060006@redhat.com> Message-ID: <53F5DF2F.1020309@redhat.com> On 08/20/2014 09:49 PM, Dmitri Pal wrote: > On 08/20/2014 09:43 PM, Rob Crittenden wrote: >> Walid wrote: >>> Thanks Rob, we have native python2.4, and anaconda python 2.7, so i >>> guess if anything needs python 2.6 or greater it would not be an issue. >>> I am just wondering if there are people using the upstream project in >>> such a legacy system ;-) >> It's not just python, it's all the modules as well. >> >> In the end the issue isn't so much ipa-client as all the related >> dependencies. The ipa-client package just helps configure things, sssd >> does all the heavy lifting. If you wanted to backport anything I'd start >> there, and it is likely extremely non-trivial. >> >> I know that people still use RHEL-5 and the current 2.2-based client. >> It, and its related packages, generally works fine you just miss out on >> some of the newer features, particularly in sssd (like sudo and autofs). > You can try to build sssd on 5.3 but I suspect it will require so many > dependencies that you system would look more like a 5.10. > You can try but this will be an adventurous effort. > For old systems like that we recommend using what they had then and not SSSD. > Users will be able to authenticate and posix data will be the same as on the > more modern systems which should be sufficient for the needs of those old > systems anyways. JFTR, note that you can also authenticate with users from potentially trusted AD domains by using: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts Preso here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf Martin From rcritten at redhat.com Thu Aug 21 12:59:30 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Aug 2014 08:59:30 -0400 Subject: [Freeipa-users] dirsrv access log redirect In-Reply-To: References: <53F463C0.5080300@redhat.com> <53F49F84.4010208@redhat.com> Message-ID: <53F5ED32.8040809@redhat.com> barrykfl at gmail.com wrote: > Hi: > > I m not avaibable to test the pipe setting as the servers are live now > and need restrt..can i simply config rsyslog server using > /var/log/dirsrv/slapf-abc.com/access > to redirect ot another rsyslog server ? Please keep responses on the list. I don't know, perhaps someone else does. rob > > > > 2014-08-20 21:15 GMT+08:00 Rob Crittenden >: > > Dmitri Pal wrote: > > On 08/20/2014 06:23 AM, barrykfl at gmail.com > wrote: > >> Dear all: > >> > >> I got 2 servers as cluster ... how can i redirect all logs server2 's > >> /var/log/dirsrv/slapd-abc.com/access > to > >> server 1 's /var/log/dirsrv/slapd-abc.com/access > > >> > >> > >> so i can view once ?what config should consider ? Or should i use > >> syslog to collect server2 > >> and redirect all to server 1 ? > >> > >> thks > >> > >> > >> > > You should use log collection tools of your choice to collect and > > process the logs. > > You can send logs to syslog and then use rsyslog to collect it. After > > that you can use different tools to process it: logstash, splunk, etc. > > Take a look at this page for instructions on redirecting logging in > 389-ds: http://www.port389.org/wiki/Named_Pipe_Log_Script > > rob > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > From rmeggins at redhat.com Thu Aug 21 13:30:29 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 21 Aug 2014 07:30:29 -0600 Subject: [Freeipa-users] ipa-client-install via Kickstart in RHEL7 In-Reply-To: <53F5DE36.20106@redhat.com> References: <53F4BDC4.7090309@redhat.com> <53F5DE36.20106@redhat.com> Message-ID: <53F5F475.5000401@redhat.com> On 08/21/2014 05:55 AM, Martin Kosek wrote: > On 08/20/2014 05:24 PM, Rich Megginson wrote: >> On 08/20/2014 09:18 AM, Baird, Josh wrote: >>> Hi, >>> >>> We are attempting to run ipa-client-install in the %post section of a >>> Kickstart in order to join the host to an IPA domain (3.3/RHEL7 IdM). We are >>> using something like: >>> >>> /usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U >>> --no-ssh --no-sshd --no-ntp --domain=realm.com >>> >>> The machine does indeed join the domain correctly, but the certmonger request >>> fails. Looking at the logs, we can see this: >>> >>> 2014-08-19T15:02:45Z DEBUG Starting external process >>> 2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service >>> 2014-08-19T15:02:45Z DEBUG Process finished, return code=0 >>> 2014-08-19T15:02:45Z DEBUG stdout= >>> 2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request. >>> >>> The error is occurring because the certmonger service fails to start. This >>> is because systemd is not able to manipulate services in a chrooted >>> environment (ala the anaconda installation environment). Prior to systemd, >>> this would work fine as services could start normally via init in a >>> chroot/%post. >>> >>> Additionally, we see the error: >>> >>> Unable to find 'admin' user with 'getent passwd admin at domain.com' >>> >>> Again, this is because systemd is unable to start sssd in the chrooted >>> installation environment. I'm wondering if anyone else has experienced these >>> issues with systemd unable to start these required services during >>> installation and what you did to work around them. One option would be to >>> move the ipa-client-install out of Kickstart and have Puppet join the host to >>> the domain post-installation (after firstboot), but this isn't really ideal. >>> >>> Any advice or suggestions would be appreciated. >> Create a file that is run at boot, presumably after networking and certmonger >> are started. > What I saw as the common approach in OpenStack or other projects are scripts > and configurations for Cloud-init [1]. > > Are there people using it for this purpose or are there other (better) approaches? Yes, you can do ipa-server-install/ipa-client-install from a cloud-init user-data runcmd script. However, there are selinux issues - some of the transitions from the cloud-init contexts are not handled correctly. What you can do is to first run with selinux in Permissive mode, audit2allow -M cloudinit < /var/log/audit/audit.log , then in subsequent runs do semodule -i cloudinit.pp with selinux Enforcing. However, cloud-init and kickstart do not mix afaik. > > [1] > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/End_User_Guide/user-data.html > > Martin From rmeggins at redhat.com Thu Aug 21 13:54:39 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 21 Aug 2014 07:54:39 -0600 Subject: [Freeipa-users] dirsrv access log redirect In-Reply-To: <53F5ED32.8040809@redhat.com> References: <53F463C0.5080300@redhat.com> <53F49F84.4010208@redhat.com> <53F5ED32.8040809@redhat.com> Message-ID: <53F5FA1F.2010200@redhat.com> On 08/21/2014 06:59 AM, Rob Crittenden wrote: > barrykfl at gmail.com wrote: >> Hi: >> >> I m not avaibable to test the pipe setting as the servers are live now >> and need restrt..can i simply config rsyslog server using >> /var/log/dirsrv/slapf-abc.com/access >> to redirect ot another rsyslog server ? > Please keep responses on the list. > > I don't know, perhaps someone else does. I don't understand the question. dirsrv does not use syslog. You would have to use the Named Pipe thing and write your own script to send the contents of the access log to syslog/rsyslog. > > rob > >> >> >> 2014-08-20 21:15 GMT+08:00 Rob Crittenden > >: >> >> Dmitri Pal wrote: >> > On 08/20/2014 06:23 AM, barrykfl at gmail.com >> wrote: >> >> Dear all: >> >> >> >> I got 2 servers as cluster ... how can i redirect all logs server2 's >> >> /var/log/dirsrv/slapd-abc.com/access >> to >> >> server 1 's /var/log/dirsrv/slapd-abc.com/access >> >> >> >> >> >> >> so i can view once ?what config should consider ? Or should i use >> >> syslog to collect server2 >> >> and redirect all to server 1 ? >> >> >> >> thks >> >> >> >> >> >> >> > You should use log collection tools of your choice to collect and >> > process the logs. >> > You can send logs to syslog and then use rsyslog to collect it. After >> > that you can use different tools to process it: logstash, splunk, etc. >> >> Take a look at this page for instructions on redirecting logging in >> 389-ds: http://www.port389.org/wiki/Named_Pipe_Log_Script >> >> rob >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> >> From mlosapio at palantir.com Thu Aug 21 14:05:27 2014 From: mlosapio at palantir.com (Mike LoSapio) Date: Thu, 21 Aug 2014 14:05:27 +0000 Subject: [Freeipa-users] dirsrv access log redirect In-Reply-To: <53F5FA1F.2010200@redhat.com> References: <53F463C0.5080300@redhat.com> <53F49F84.4010208@redhat.com> <53F5ED32.8040809@redhat.com> <53F5FA1F.2010200@redhat.com> Message-ID: You can use this. http://www.rsyslog.com/doc/imfile.html On 8/21/14, 9:54 AM, "Rich Megginson" wrote: >On 08/21/2014 06:59 AM, Rob Crittenden wrote: >> barrykfl at gmail.com wrote: >>> Hi: >>> >>> I m not avaibable to test the pipe setting as the servers are live now >>> and need restrt..can i simply config rsyslog server using >>> /var/log/dirsrv/slapf-abc.com/access >>>>>k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=8E1gsOSt%2FCtC2n%2BOWoKLZBLdyvsujbjT >>>a%2Bu0JdpPSEU%3D%0A&m=xi7h2Vatp0VcMsq6kgqvowQ4cvc3TETggnxgkKN%2BOCs%3D%0 >>>A&s=0697d19c286f8960436806a08c1db329b315eda30cb1251762522b95d3a4419a> >>> to redirect ot another rsyslog server ? >> Please keep responses on the list. >> >> I don't know, perhaps someone else does. > >I don't understand the question. dirsrv does not use syslog. You would >have to use the Named Pipe thing and write your own script to send the >contents of the access log to syslog/rsyslog. > >> >> rob >> >>> >>> >>> 2014-08-20 21:15 GMT+08:00 Rob Crittenden >> >: >>> >>> Dmitri Pal wrote: >>> > On 08/20/2014 06:23 AM, barrykfl at gmail.com >>> wrote: >>> >> Dear all: >>> >> >>> >> I got 2 servers as cluster ... how can i redirect all logs >>>server2 's >>> >> /var/log/dirsrv/slapd-abc.com/access >>> >>>>>k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=8E1gsOSt%2FCtC2n%2BOWoKLZBLdyvsujbjT >>>a%2Bu0JdpPSEU%3D%0A&m=xi7h2Vatp0VcMsq6kgqvowQ4cvc3TETggnxgkKN%2BOCs%3D%0 >>>A&s=e9bd6622c394ecea1514bb0a5a9c658d36d92287bc0687c694839969237c574f> >>>>>k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=8E1gsOSt%2FCtC2n%2BOWoKLZBLdyvsujbjT >>>a%2Bu0JdpPSEU%3D%0A&m=xi7h2Vatp0VcMsq6kgqvowQ4cvc3TETggnxgkKN%2BOCs%3D%0 >>>A&s=e9bd6622c394ecea1514bb0a5a9c658d36d92287bc0687c694839969237c574f> to >>> >> server 1 's /var/log/dirsrv/slapd-abc.com/access >>> >>>>>k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=8E1gsOSt%2FCtC2n%2BOWoKLZBLdyvsujbjT >>>a%2Bu0JdpPSEU%3D%0A&m=xi7h2Vatp0VcMsq6kgqvowQ4cvc3TETggnxgkKN%2BOCs%3D%0 >>>A&s=e9bd6622c394ecea1514bb0a5a9c658d36d92287bc0687c694839969237c574f> >>> >> >>>>>k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=8E1gsOSt%2FCtC2n%2BOWoKLZBLdyvsujbjT >>>a%2Bu0JdpPSEU%3D%0A&m=xi7h2Vatp0VcMsq6kgqvowQ4cvc3TETggnxgkKN%2BOCs%3D%0 >>>A&s=e9bd6622c394ecea1514bb0a5a9c658d36d92287bc0687c694839969237c574f> >>> >> >>> >> so i can view once ?what config should consider ? Or should i >>>use >>> >> syslog to collect server2 >>> >> and redirect all to server 1 ? >>> >> >>> >> thks >>> >> >>> >> >>> >> >>> > You should use log collection tools of your choice to collect >>>and >>> > process the logs. >>> > You can send logs to syslog and then use rsyslog to collect it. >>>After >>> > that you can use different tools to process it: logstash, >>>splunk, etc. >>> >>> Take a look at this page for instructions on redirecting logging >>>in >>> 389-ds: >>>https://urldefense.proofpoint.com/v1/url?u=http://www.port389.org/wiki/N >>>amed_Pipe_Log_Script&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=8E1gsOSt%2FCtC2 >>>n%2BOWoKLZBLdyvsujbjTa%2Bu0JdpPSEU%3D%0A&m=xi7h2Vatp0VcMsq6kgqvowQ4cvc3T >>>ETggnxgkKN%2BOCs%3D%0A&s=8c04f5678b42c1447199d8156d262952ed4699d479f77a8 >>>54c6d062843c55251 >>> >>> rob >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> >>>https://urldefense.proofpoint.com/v1/url?u=https://www.redhat.com/mailma >>>n/listinfo/freeipa-users&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=8E1gsOSt%2F >>>CtC2n%2BOWoKLZBLdyvsujbjTa%2Bu0JdpPSEU%3D%0A&m=xi7h2Vatp0VcMsq6kgqvowQ4c >>>vc3TETggnxgkKN%2BOCs%3D%0A&s=2d47703b2e0fe0f7e7e0483a60087064ead7232f809 >>>26069c422618d09f3b89b >>> Go To >>>https://urldefense.proofpoint.com/v1/url?u=http://freeipa.org/&k=fDZpZZQ >>>MmYwf27OU23GmAQ%3D%3D%0A&r=8E1gsOSt%2FCtC2n%2BOWoKLZBLdyvsujbjTa%2Bu0Jdp >>>PSEU%3D%0A&m=xi7h2Vatp0VcMsq6kgqvowQ4cvc3TETggnxgkKN%2BOCs%3D%0A&s=46c88 >>>503d24246c7333d66185f382446351d3a3719f20e3dfdc9c5a2921cf615 for more >>>info on the project >>> >>> > >-- >Manage your subscription for the Freeipa-users mailing list: >https://urldefense.proofpoint.com/v1/url?u=https://www.redhat.com/mailman/ >listinfo/freeipa-users&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=8E1gsOSt%2FCtC2 >n%2BOWoKLZBLdyvsujbjTa%2Bu0JdpPSEU%3D%0A&m=xi7h2Vatp0VcMsq6kgqvowQ4cvc3TET >ggnxgkKN%2BOCs%3D%0A&s=2d47703b2e0fe0f7e7e0483a60087064ead7232f80926069c42 >2618d09f3b89b >Go To >https://urldefense.proofpoint.com/v1/url?u=http://freeipa.org/&k=fDZpZZQMm >Ywf27OU23GmAQ%3D%3D%0A&r=8E1gsOSt%2FCtC2n%2BOWoKLZBLdyvsujbjTa%2Bu0JdpPSEU >%3D%0A&m=xi7h2Vatp0VcMsq6kgqvowQ4cvc3TETggnxgkKN%2BOCs%3D%0A&s=46c88503d24 >246c7333d66185f382446351d3a3719f20e3dfdc9c5a2921cf615 for more info on >the project -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5043 bytes Desc: not available URL: From lyamanishi at sesda3.com Thu Aug 21 16:13:17 2014 From: lyamanishi at sesda3.com (Lucas Yamanishi) Date: Thu, 21 Aug 2014 12:13:17 -0400 Subject: [Freeipa-users] ntp and srv records In-Reply-To: <4ED173A868981548967B4FCA2707222627FC38EC@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222627FC38EC@AACMBXP04.exchserver.com> Message-ID: <53F61A9D.6050008@sesda3.com> On 08/21/2014 12:17 AM, Les Stott wrote: > > Hi All, > > > > Am about to start rolling out clinet installs on rhel6 hosts with dns > autodiscovery. > > > > Enviroment: rhel6, ipa-3.0.0-37.el6. > > > > I already have setup SRV records for Kerberos and ldap etc. > > > > Are the following ntp records as SRV records necessary also? > > > > ;ntp server > > _ntp._udp IN SRV 0 100 123 ntp1.mydomain.com. > > _ntp._udp IN SRV 0 100 123 ntp2.mydomain.com. > > > > I?ve seen some guides that don?t reference them, others that do. I > don?t see any adverse effects on the two freeipa servers (master + > replica) that are currently running without the ntp srv records. > > > > Thanks in advance, > > > > Regards, > > > > Les > > > > > *ipa-client-install* and *ipa-server-install* use them to sync time before they proceed to crypto operations, but they're not strictly required, especially if time is already in sync. If the records are not available they attempt to sync directly with the IPA server, failing that they will throw a warning and continue. Microsoft has also been adding support for them to a lot of their AD-connected mobile software, but I think they too use it as a convenience, not a requirement. -- ----- *question everything*learn something*answer nothing* ------------ Lucas Yamanishi ------------------ Systems Administrator, ADNET Systems, Inc. NASA Space and Earth Science Data Analysis (606.9) 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xD354B2CB -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.muriithi at gmail.com Thu Aug 21 23:44:18 2014 From: william.muriithi at gmail.com (William Muriithi) Date: Thu, 21 Aug 2014 19:44:18 -0400 Subject: [Freeipa-users] Permission for root running cron task as a different user Message-ID: Evening, Came across a problem where a cron job I had setup last night seemed not to run. On further investigation, I noticed FreeIPA must be pushing a policy that block cron task that adopt a different user than the one its set under. I am certain its FreeIPA related as I have a system that's not enrolled and the task run fine there. Now, this is curiosity sake as I solved the problem using groups, but how would one allow root to schedule a job that run as non root? * 4 * * * williamm /usr/local/bin/some-script.sh Aug 21 14:06:02 muriithi crond[6621]: (williamm) FAILED to authorize user with PAM (Permission denied) Aug 21 14:07:01 wmuriithi crond[6625]: (williamm) FAILED to authorize user with PAM (Permission denied) Aug 21 14:08:01 wmuriithi crond[6628]: (williamm) FAILED to authorize user with PAM (Permission denied) Regards, William -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Aug 22 01:33:52 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Aug 2014 21:33:52 -0400 Subject: [Freeipa-users] Permission for root running cron task as a different user In-Reply-To: References: Message-ID: <53F69E00.6080208@redhat.com> William Muriithi wrote: > Evening, > > Came across a problem where a cron job I had setup last night seemed not > to run. On further investigation, I noticed FreeIPA must be pushing a > policy that block cron task that adopt a different user than the one its > set under. > > I am certain its FreeIPA related as I have a system that's not enrolled > and the task run fine there. > > Now, this is curiosity sake as I solved the problem using groups, but > how would one allow root to schedule a job that run as non root? > > * 4 * * * williamm /usr/local/bin/some-script.sh > > Aug 21 14:06:02 muriithi crond[6621]: (williamm) FAILED to authorize > user with PAM (Permission denied) Aug 21 14:07:01 wmuriithi crond[6625]: > (williamm) FAILED to authorize user with PAM (Permission denied) Aug 21 > 14:08:01 wmuriithi crond[6628]: (williamm) FAILED to authorize user with > PAM (Permission denied) You probably need to grant access via HBAC rules. rob From arthur at deus.pro Fri Aug 22 10:10:22 2014 From: arthur at deus.pro (Arthur Fayzullin) Date: Fri, 22 Aug 2014 16:10:22 +0600 Subject: [Freeipa-users] Install FreeIPA 4 on ubuntu In-Reply-To: <20140821064057.GB5435@mail.corp.redhat.com> References: <20140821064057.GB5435@mail.corp.redhat.com> Message-ID: <53F7170E.8050006@deus.pro> Can confirm that does work :) 21.08.2014 12:40, Lukas Slebodnik ?????: > On (20/08/14 20:27), Chris Whittle wrote: >> Is there instructions anywhere? My FreeIPA 3 on CentOS died so I'm >> starting over > You can try FreeIPA 3.3. on CentOS 7 > > bash-4.2# yum info ipa-server > Loaded plugins: fastestmirror > Loading mirror speeds from cached hostfile > * base: mirror.raystedman.net > * extras: mirror.solarvps.com > * updates: centos.mirror.constant.com > Available Packages > Name : ipa-server > Arch : x86_64 > Version : 3.3.3 > Release : 28.el7.centos > Size : 1.2 M > Repo : base/7/x86_64 > Summary : The IPA authentication server > URL : http://www.freeipa.org/ > License : GPLv3+ > Description : IPA is an integrated solution to provide centrally managed > : Identity (machine, user, virtual machines, groups, authentication > : credentials), Policy (configuration settings, access control > : information) and Audit (events, logs, analysis thereof). If you > : are installing an IPA server you need to install this package (in > : other words, most people should NOT install this package). > > LS > -- ? ?????????, ????? ????????? From cwhittl at gmail.com Fri Aug 22 15:16:01 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Fri, 22 Aug 2014 10:16:01 -0500 Subject: [Freeipa-users] Install FreeIPA 4 on ubuntu In-Reply-To: <53F57BC6.1070404@ubuntu.com> References: <53F57BC6.1070404@ubuntu.com> Message-ID: Thanks Timo so Fedora is really the only one it's supported on for now? On Wed, Aug 20, 2014 at 11:55 PM, Timo Aaltonen wrote: > On 21.08.2014 04:27, Chris Whittle wrote: > > Is there instructions anywhere? My FreeIPA 3 on CentOS died so I'm > > starting over > > there is no server for ubuntu/debian yet > > > -- > t > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Fri Aug 22 15:19:30 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Fri, 22 Aug 2014 18:19:30 +0300 Subject: [Freeipa-users] Install FreeIPA 4 on ubuntu In-Reply-To: References: <53F57BC6.1070404@ubuntu.com> Message-ID: <53F75F82.50500@ubuntu.com> On 22.08.2014 18:16, Chris Whittle wrote: > Thanks Timo so Fedora is really the only one it's supported on for now? Fedora/RHEL/Centos etc, yes. Maybe by x-mas we'll have something in Debian unstable working. -- t From cwhittl at gmail.com Fri Aug 22 15:38:13 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Fri, 22 Aug 2014 10:38:13 -0500 Subject: [Freeipa-users] Install FreeIPA 4 on ubuntu In-Reply-To: <53F75F82.50500@ubuntu.com> References: <53F57BC6.1070404@ubuntu.com> <53F75F82.50500@ubuntu.com> Message-ID: But just Centos 7 right? On Fri, Aug 22, 2014 at 10:19 AM, Timo Aaltonen wrote: > On 22.08.2014 18:16, Chris Whittle wrote: > > Thanks Timo so Fedora is really the only one it's supported on for now? > > Fedora/RHEL/Centos etc, yes. Maybe by x-mas we'll have something in > Debian unstable working. > > > > -- > t > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Fri Aug 22 15:41:58 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Fri, 22 Aug 2014 18:41:58 +0300 Subject: [Freeipa-users] Install FreeIPA 4 on ubuntu In-Reply-To: References: <53F57BC6.1070404@ubuntu.com> <53F75F82.50500@ubuntu.com> Message-ID: <53F764C6.1070202@ubuntu.com> On 22.08.2014 18:38, Chris Whittle wrote: > But just Centos 7 right? right, if you need v4 -- t From mlasevich at lasevich.net Fri Aug 22 20:41:41 2014 From: mlasevich at lasevich.net (Michael Lasevich) Date: Fri, 22 Aug 2014 13:41:41 -0700 Subject: [Freeipa-users] Ubuntu 3.3.x client vs. 3.0.0 server Message-ID: Trying to use ipa command line admin tools from Ubuntu 14.04 box against 3.0.0 CentOS 6 server and running into trouble. Seems like upgrading server is not an option without upgrading the server, and 3.3.0 client is not compatible with 3.0.0 server (seems to be sending invalid fields to the server in api) I cannot seem to easily find a way to get 3.0 client on ubuntu not do I see any pre-made 3.0 deb packages. Any suggestions? Thanks, -M -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Sat Aug 23 04:13:05 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Fri, 22 Aug 2014 23:13:05 -0500 Subject: [Freeipa-users] Centos 7 and 4.0 Message-ID: I'm trying to install the repo from https://copr.fedoraproject.org/coprs/pviktori/freeipa/ and when I go to install I get yum install freeipa-server > > Loaded plugins: fastestmirror, langpacks > > Repository pviktori-freeipa is listed more than once in the configuration > > > http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml: > [Errno 14] HTTP Error 404 - Not Found > > Trying other mirror. > > Loading mirror speeds from cached hostfile > > * base: mirror-centos.hostingswift.com > > * extras: centos.host-engine.com > > * updates: centos.arvixe.com > > No package *freeipa-server* available. > >> Error: Nothing to do > > Am I missing something? I remember that there was a thread about Centos 7 and FreeIPA 4 but for the life of me I can't find it. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From purpleidea at gmail.com Sat Aug 23 04:18:11 2014 From: purpleidea at gmail.com (James) Date: Sat, 23 Aug 2014 00:18:11 -0400 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: References: Message-ID: On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle wrote: > I'm trying to install the repo from > https://copr.fedoraproject.org/coprs/pviktori/freeipa/ and when I go to > install I get > >> yum install freeipa-server >> >> Loaded plugins: fastestmirror, langpacks >> >> Repository pviktori-freeipa is listed more than once in the configuration >> >> >> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml: >> [Errno 14] HTTP Error 404 - Not Found >> >> Trying other mirror. >> >> Loading mirror speeds from cached hostfile >> >> * base: mirror-centos.hostingswift.com >> >> * extras: centos.host-engine.com >> >> * updates: centos.arvixe.com >> >> No package freeipa-server available. >>> >>> Error: Nothing to do > > > Am I missing something? I remember that there was a thread about Centos 7 > and FreeIPA 4 but for the life of me I can't find it. > > Thanks Just a guess but it's probably called ipa-server. You can use yum search too. Eg: 'yum search freeipa' to find it. Cheers, James > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From cwhittl at gmail.com Sat Aug 23 12:16:07 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Sat, 23 Aug 2014 07:16:07 -0500 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: References: Message-ID: Thanks, i was following the instructions On Aug 22, 2014 11:18 PM, "James" wrote: > On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle wrote: > > I'm trying to install the repo from > > https://copr.fedoraproject.org/coprs/pviktori/freeipa/ and when I go to > > install I get > > > >> yum install freeipa-server > >> > >> Loaded plugins: fastestmirror, langpacks > >> > >> Repository pviktori-freeipa is listed more than once in the > configuration > >> > >> > >> > http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml > : > >> [Errno 14] HTTP Error 404 - Not Found > >> > >> Trying other mirror. > >> > >> Loading mirror speeds from cached hostfile > >> > >> * base: mirror-centos.hostingswift.com > >> > >> * extras: centos.host-engine.com > >> > >> * updates: centos.arvixe.com > >> > >> No package freeipa-server available. > >>> > >>> Error: Nothing to do > > > > > > Am I missing something? I remember that there was a thread about Centos > 7 > > and FreeIPA 4 but for the life of me I can't find it. > > > > Thanks > Just a guess but it's probably called ipa-server. > You can use yum search too. > Eg: 'yum search freeipa' to find it. > > Cheers, > James > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Sat Aug 23 12:22:21 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Sat, 23 Aug 2014 07:22:21 -0500 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: References: Message-ID: ipa-server does work but only for 3.3.3 I'm wanting 4 On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle wrote: > Thanks, i was following the instructions > On Aug 22, 2014 11:18 PM, "James" wrote: > >> On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle >> wrote: >> > I'm trying to install the repo from >> > https://copr.fedoraproject.org/coprs/pviktori/freeipa/ and when I go to >> > install I get >> > >> >> yum install freeipa-server >> >> >> >> Loaded plugins: fastestmirror, langpacks >> >> >> >> Repository pviktori-freeipa is listed more than once in the >> configuration >> >> >> >> >> >> >> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml >> : >> >> [Errno 14] HTTP Error 404 - Not Found >> >> >> >> Trying other mirror. >> >> >> >> Loading mirror speeds from cached hostfile >> >> >> >> * base: mirror-centos.hostingswift.com >> >> >> >> * extras: centos.host-engine.com >> >> >> >> * updates: centos.arvixe.com >> >> >> >> No package freeipa-server available. >> >>> >> >>> Error: Nothing to do >> > >> > >> > Am I missing something? I remember that there was a thread about >> Centos 7 >> > and FreeIPA 4 but for the life of me I can't find it. >> > >> > Thanks >> Just a guess but it's probably called ipa-server. >> You can use yum search too. >> Eg: 'yum search freeipa' to find it. >> >> Cheers, >> James >> >> > >> > -- >> > Manage your subscription for the Freeipa-users mailing list: >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > Go To http://freeipa.org for more info on the project >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Aug 23 13:23:34 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 23 Aug 2014 15:23:34 +0200 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: References: Message-ID: <53F895D6.9090502@redhat.com> On 08/23/2014 02:22 PM, Chris Whittle wrote: > ipa-server does work but only for 3.3.3 I'm wanting 4 Try the epel repo http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ > > > On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle > wrote: > > Thanks, i was following the instructions > > On Aug 22, 2014 11:18 PM, "James" > wrote: > > On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle > > wrote: > > I'm trying to install the repo from > > https://copr.fedoraproject.org/coprs/pviktori/freeipa/ and > when I go to > > install I get > > > >> yum install freeipa-server > >> > >> Loaded plugins: fastestmirror, langpacks > >> > >> Repository pviktori-freeipa is listed more than once in the > configuration > >> > >> > >> > http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml: > >> [Errno 14] HTTP Error 404 - Not Found > >> > >> Trying other mirror. > >> > >> Loading mirror speeds from cached hostfile > >> > >> * base: mirror-centos.hostingswift.com > > >> > >> * extras: centos.host-engine.com > > >> > >> * updates: centos.arvixe.com > >> > >> No package freeipa-server available. > >>> > >>> Error: Nothing to do > > > > > > Am I missing something? I remember that there was a thread > about Centos 7 > > and FreeIPA 4 but for the life of me I can't find it. > > > > Thanks > Just a guess but it's probably called ipa-server. > You can use yum search too. > Eg: 'yum search freeipa' to find it. > > Cheers, > James > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Sat Aug 23 16:46:16 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 23 Aug 2014 18:46:16 +0200 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: References: Message-ID: <20140823164615.GA16746@mail.corp.redhat.com> On (22/08/14 23:13), Chris Whittle wrote: >I'm trying to install the repo from >https://copr.fedoraproject.org/coprs/pviktori/freeipa/ and when I go to >install I get > > yum install freeipa-server You will not be able to install freeipa-server on CentOS from this repo, because freeipa-4.0 is not build for epel7. It is built just for next distros: Release Architecture Yum Repo Fedora 20 i386 pviktori-freeipa-fedora-20.repo x86_64 Fedora rawhide i386 pviktori-freeipa-fedora-rawhide.repo x86_64 LS From uncommonkat at gmail.com Sat Aug 23 18:03:28 2014 From: uncommonkat at gmail.com (Kat) Date: Sat, 23 Aug 2014 11:03:28 -0700 Subject: [Freeipa-users] IPA 3 client and IPA 4 server Message-ID: <53F8D770.4060304@gmail.com> Hi, Wondering about mixed configs and using features from the server such as OTP. Has anyone done this with a v3 client? I know it is mostly sssd, but wondering if there might be any gotchas. Thanks From cwhittl at gmail.com Sat Aug 23 18:33:46 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Sat, 23 Aug 2014 13:33:46 -0500 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: <53F895D6.9090502@redhat.com> References: <53F895D6.9090502@redhat.com> Message-ID: Thanks Dmitri, I'm going to sound like a noob for a second but how do I add that repo? I added a repo call pviktori-epel-7 to /etc/yum.repos.d with the following info [pviktori-epel-7] > name=pviktori for RHEL/ CentOS $releasever - $basearch > baseurl= > http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ > enabled=1 And then ran > [root at xavier yum.repos.d]# yum install freeipa-server > Loaded plugins: fastestmirror, langpacks > base | 3.6 kB > 00:00 > extras | 3.3 kB > 00:00 > pviktori-epel-7 | 3.0 kB > 00:00 > updates | 3.4 kB > 00:00 > pviktori-epel-7/primary_db | 1.4 kB > 00:00 > Loading mirror speeds from cached hostfile > * base: mirror-centos.hostingswift.com > * extras: centos.host-engine.com > * updates: centos.arvixe.com > No package *freeipa-server* available. > Error: Nothing to do I then tried > [root at xavier yum.repos.d]# yum install ipa-server and just got the 3.3 stuff... I'm so close, I can taste it.... Thanks for all your help On Sat, Aug 23, 2014 at 8:23 AM, Dmitri Pal wrote: > On 08/23/2014 02:22 PM, Chris Whittle wrote: > > ipa-server does work but only for 3.3.3 I'm wanting 4 > > > Try the epel repo > http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ > > > > On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle wrote: > >> Thanks, i was following the instructions >> On Aug 22, 2014 11:18 PM, "James" wrote: >> >>> On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle >>> wrote: >>> > I'm trying to install the repo from >>> > https://copr.fedoraproject.org/coprs/pviktori/freeipa/ and when I go >>> to >>> > install I get >>> > >>> >> yum install freeipa-server >>> >> >>> >> Loaded plugins: fastestmirror, langpacks >>> >> >>> >> Repository pviktori-freeipa is listed more than once in the >>> configuration >>> >> >>> >> >>> >> >>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml >>> : >>> >> [Errno 14] HTTP Error 404 - Not Found >>> >> >>> >> Trying other mirror. >>> >> >>> >> Loading mirror speeds from cached hostfile >>> >> >>> >> * base: mirror-centos.hostingswift.com >>> >> >>> >> * extras: centos.host-engine.com >>> >> >>> >> * updates: centos.arvixe.com >>> >> >>> >> No package freeipa-server available. >>> >>> >>> >>> Error: Nothing to do >>> > >>> > >>> > Am I missing something? I remember that there was a thread about >>> Centos 7 >>> > and FreeIPA 4 but for the life of me I can't find it. >>> > >>> > Thanks >>> Just a guess but it's probably called ipa-server. >>> You can use yum search too. >>> Eg: 'yum search freeipa' to find it. >>> >>> Cheers, >>> James >>> >>> > >>> > -- >>> > Manage your subscription for the Freeipa-users mailing list: >>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>> > Go To http://freeipa.org for more info on the project >>> >> > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for 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 dpal at redhat.com Sat Aug 23 19:26:19 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 23 Aug 2014 21:26:19 +0200 Subject: [Freeipa-users] IPA 3 client and IPA 4 server In-Reply-To: <53F8D770.4060304@gmail.com> References: <53F8D770.4060304@gmail.com> Message-ID: <53F8EADB.10608@redhat.com> On 08/23/2014 08:03 PM, Kat wrote: > Hi, > > Wondering about mixed configs and using features from the server such > as OTP. Has anyone done this with a v3 client? I know it is mostly > sssd, but wondering if there might be any gotchas. > > Thanks > It depends how you want to use it. If your client is LDAP any clients should work but be sure to use SSL when you bind. SSSD will try to use kerberos. There have been some glitches reported with SSSD in kerberos mode trying to do OTP. So far I recall some failures if UDP is configured for kerberos so the it should be turned off in the krb5.conf on the client. And then there are issues with the password change if you use OTPs managed by IPA (but not external ones). But other than that 1.11 SSSD on top of F20+ and RHEL/CentOS 7 should work. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Sat Aug 23 19:29:26 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 23 Aug 2014 21:29:26 +0200 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: References: <53F895D6.9090502@redhat.com> Message-ID: <53F8EB96.2040703@redhat.com> On 08/23/2014 08:33 PM, Chris Whittle wrote: > Thanks Dmitri, > I'm going to sound like a noob for a second but how do I add that repo? > I added a repo call pviktori-epel-7 to /etc/yum.repos.d with the > following info Sorry this is beyond my skill set. I would leave it for some more experienced people to answer. Lukas mentioned in other mail that epel might not work. May be best would be to wait till Monday and ping people on #freeipa on freenode.net > > [pviktori-epel-7] > name=pviktori for RHEL/ CentOS $releasever - $basearch > baseurl=http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ > enabled=1 > > > And then ran > > [root at xavier yum.repos.d]# yum install freeipa-server > Loaded plugins: fastestmirror, langpacks > base | 3.6 kB > 00:00 > extras | 3.3 kB > 00:00 > pviktori-epel-7 | 3.0 kB > 00:00 > updates | 3.4 kB > 00:00 > pviktori-epel-7/primary_db | 1.4 kB 00:00 > Loading mirror speeds from cached hostfile > * base: mirror-centos.hostingswift.com > > * extras: centos.host-engine.com > * updates: centos.arvixe.com > No package *freeipa-server* available. > Error: Nothing to do > > > I then tried > > [root at xavier yum.repos.d]# yum install ipa-server > > > and just got the 3.3 stuff... > I'm so close, I can taste it.... > Thanks for all your help > > > On Sat, Aug 23, 2014 at 8:23 AM, Dmitri Pal > wrote: > > On 08/23/2014 02:22 PM, Chris Whittle wrote: >> ipa-server does work but only for 3.3.3 I'm wanting 4 > > Try the epel repo > http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ > > >> >> >> On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle > > wrote: >> >> Thanks, i was following the instructions >> >> On Aug 22, 2014 11:18 PM, "James" > > wrote: >> >> On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle >> > wrote: >> > I'm trying to install the repo from >> > https://copr.fedoraproject.org/coprs/pviktori/freeipa/ >> and when I go to >> > install I get >> > >> >> yum install freeipa-server >> >> >> >> Loaded plugins: fastestmirror, langpacks >> >> >> >> Repository pviktori-freeipa is listed more than once >> in the configuration >> >> >> >> >> >> >> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml: >> >> [Errno 14] HTTP Error 404 - Not Found >> >> >> >> Trying other mirror. >> >> >> >> Loading mirror speeds from cached hostfile >> >> >> >> * base: mirror-centos.hostingswift.com >> >> >> >> >> * extras: centos.host-engine.com >> >> >> >> >> * updates: centos.arvixe.com >> >> >> >> No package freeipa-server available. >> >>> >> >>> Error: Nothing to do >> > >> > >> > Am I missing something? I remember that there was a >> thread about Centos 7 >> > and FreeIPA 4 but for the life of me I can't find it. >> > >> > Thanks >> Just a guess but it's probably called ipa-server. >> You can use yum search too. >> Eg: 'yum search freeipa' to find it. >> >> Cheers, >> James >> >> > >> > -- >> > Manage your subscription for the Freeipa-users mailing >> list: >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > Go To http://freeipa.org for more info on the project >> >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uncommonkat at gmail.com Sat Aug 23 19:42:42 2014 From: uncommonkat at gmail.com (Kat) Date: Sat, 23 Aug 2014 12:42:42 -0700 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: <53F8EB96.2040703@redhat.com> References: <53F895D6.9090502@redhat.com> <53F8EB96.2040703@redhat.com> Message-ID: <53F8EEB2.6050707@gmail.com> If you look closely, the "epel-7" repo is actually empty. There are no packages there. So there are no packages to actually install. Only the "fedora" repos in that same tree have packages. ~K On 8/23/14 12:29 PM, Dmitri Pal wrote: > On 08/23/2014 08:33 PM, Chris Whittle wrote: >> Thanks Dmitri, >> I'm going to sound like a noob for a second but how do I add that repo? >> I added a repo call pviktori-epel-7 to /etc/yum.repos.d with the >> following info > > Sorry this is beyond my skill set. > I would leave it for some more experienced people to answer. > Lukas mentioned in other mail that epel might not work. > May be best would be to wait till Monday and ping people on #freeipa > on freenode.net > >> >> [pviktori-epel-7] >> name=pviktori for RHEL/ CentOS $releasever - $basearch >> baseurl=http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >> enabled=1 >> >> >> And then ran >> >> [root at xavier yum.repos.d]# yum install freeipa-server >> Loaded plugins: fastestmirror, langpacks >> base | 3.6 kB 00:00 >> extras | 3.3 kB 00:00 >> pviktori-epel-7 | 3.0 kB 00:00 >> updates | 3.4 kB 00:00 >> pviktori-epel-7/primary_db | 1.4 kB 00:00 >> Loading mirror speeds from cached hostfile >> * base: mirror-centos.hostingswift.com >> >> * extras: centos.host-engine.com >> * updates: centos.arvixe.com >> No package *freeipa-server* available. >> Error: Nothing to do >> >> >> I then tried >> >> [root at xavier yum.repos.d]# yum install ipa-server >> >> >> and just got the 3.3 stuff... >> I'm so close, I can taste it.... >> Thanks for all your help >> >> >> On Sat, Aug 23, 2014 at 8:23 AM, Dmitri Pal > > wrote: >> >> On 08/23/2014 02:22 PM, Chris Whittle wrote: >>> ipa-server does work but only for 3.3.3 I'm wanting 4 >> >> Try the epel repo >> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >> >> >>> >>> >>> On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle >>> > wrote: >>> >>> Thanks, i was following the instructions >>> >>> On Aug 22, 2014 11:18 PM, "James" >> > wrote: >>> >>> On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle >>> > wrote: >>> > I'm trying to install the repo from >>> > https://copr.fedoraproject.org/coprs/pviktori/freeipa/ >>> and when I go to >>> > install I get >>> > >>> >> yum install freeipa-server >>> >> >>> >> Loaded plugins: fastestmirror, langpacks >>> >> >>> >> Repository pviktori-freeipa is listed more than once >>> in the configuration >>> >> >>> >> >>> >> >>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml: >>> >> [Errno 14] HTTP Error 404 - Not Found >>> >> >>> >> Trying other mirror. >>> >> >>> >> Loading mirror speeds from cached hostfile >>> >> >>> >> * base: mirror-centos.hostingswift.com >>> >>> >> >>> >> * extras: centos.host-engine.com >>> >>> >> >>> >> * updates: centos.arvixe.com >>> >> >>> >> No package freeipa-server available. >>> >>> >>> >>> Error: Nothing to do >>> > >>> > >>> > Am I missing something? I remember that there was a >>> thread about Centos 7 >>> > and FreeIPA 4 but for the life of me I can't find it. >>> > >>> > Thanks >>> Just a guess but it's probably called ipa-server. >>> You can use yum search too. >>> Eg: 'yum search freeipa' to find it. >>> >>> Cheers, >>> James >>> >>> > >>> > -- >>> > Manage your subscription for the Freeipa-users mailing >>> list: >>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>> > Go To http://freeipa.org for more info on the project >>> >>> >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Sat Aug 23 19:46:41 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Sat, 23 Aug 2014 14:46:41 -0500 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: <53F8EEB2.6050707@gmail.com> References: <53F895D6.9090502@redhat.com> <53F8EB96.2040703@redhat.com> <53F8EEB2.6050707@gmail.com> Message-ID: Thanks Kat, so what do I need to do? I have a brand new Centos 7 Server and I am itchy to install FreeIPA 4... Thanks! On Aug 23, 2014 2:44 PM, "Kat" wrote: > If you look closely, the "epel-7" repo is actually empty. There are no > packages there. > > So there are no packages to actually install. Only the "fedora" repos in > that same tree have packages. > > ~K > > On 8/23/14 12:29 PM, Dmitri Pal wrote: > > On 08/23/2014 08:33 PM, Chris Whittle wrote: > > Thanks Dmitri, > I'm going to sound like a noob for a second but how do I add that repo? > I added a repo call pviktori-epel-7 to /etc/yum.repos.d with the following > info > > > Sorry this is beyond my skill set. > I would leave it for some more experienced people to answer. > Lukas mentioned in other mail that epel might not work. > May be best would be to wait till Monday and ping people on #freeipa on > freenode.net > > > [pviktori-epel-7] >> name=pviktori for RHEL/ CentOS $releasever - $basearch >> baseurl= >> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >> enabled=1 > > > And then ran > >> [root at xavier yum.repos.d]# yum install freeipa-server >> Loaded plugins: fastestmirror, langpacks >> base | 3.6 kB >> 00:00 >> extras | 3.3 kB >> 00:00 >> pviktori-epel-7 | 3.0 kB >> 00:00 >> updates | 3.4 kB >> 00:00 >> pviktori-epel-7/primary_db | 1.4 kB >> 00:00 >> Loading mirror speeds from cached hostfile >> * base: mirror-centos.hostingswift.com >> * extras: centos.host-engine.com >> * updates: centos.arvixe.com >> No package *freeipa-server* available. >> Error: Nothing to do > > > I then tried > >> [root at xavier yum.repos.d]# yum install ipa-server > > > and just got the 3.3 stuff... > I'm so close, I can taste it.... > Thanks for all your help > > > On Sat, Aug 23, 2014 at 8:23 AM, Dmitri Pal wrote: > >> On 08/23/2014 02:22 PM, Chris Whittle wrote: >> >> ipa-server does work but only for 3.3.3 I'm wanting 4 >> >> >> Try the epel repo >> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >> >> >> >> On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle wrote: >> >>> Thanks, i was following the instructions >>> On Aug 22, 2014 11:18 PM, "James" wrote: >>> >>>> On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle >>>> wrote: >>>> > I'm trying to install the repo from >>>> > https://copr.fedoraproject.org/coprs/pviktori/freeipa/ and when I go >>>> to >>>> > install I get >>>> > >>>> >> yum install freeipa-server >>>> >> >>>> >> Loaded plugins: fastestmirror, langpacks >>>> >> >>>> >> Repository pviktori-freeipa is listed more than once in the >>>> configuration >>>> >> >>>> >> >>>> >> >>>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml >>>> : >>>> >> [Errno 14] HTTP Error 404 - Not Found >>>> >> >>>> >> Trying other mirror. >>>> >> >>>> >> Loading mirror speeds from cached hostfile >>>> >> >>>> >> * base: mirror-centos.hostingswift.com >>>> >> >>>> >> * extras: centos.host-engine.com >>>> >> >>>> >> * updates: centos.arvixe.com >>>> >> >>>> >> No package freeipa-server available. >>>> >>> >>>> >>> Error: Nothing to do >>>> > >>>> > >>>> > Am I missing something? I remember that there was a thread about >>>> Centos 7 >>>> > and FreeIPA 4 but for the life of me I can't find it. >>>> > >>>> > Thanks >>>> Just a guess but it's probably called ipa-server. >>>> You can use yum search too. >>>> Eg: 'yum search freeipa' to find it. >>>> >>>> Cheers, >>>> James >>>> >>>> > >>>> > -- >>>> > Manage your subscription for the Freeipa-users mailing list: >>>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>>> > Go To http://freeipa.org for more info on the project >>>> >>> >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > > > > -- > Manage your subscription for 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 dpal at redhat.com Sat Aug 23 19:51:19 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 23 Aug 2014 21:51:19 +0200 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: References: <53F895D6.9090502@redhat.com> <53F8EB96.2040703@redhat.com> <53F8EEB2.6050707@gmail.com> Message-ID: <53F8F0B7.5070702@redhat.com> On 08/23/2014 09:46 PM, Chris Whittle wrote: > > Thanks Kat, so what do I need to do? I have a brand new Centos 7 > Server and I am itchy to install FreeIPA 4... > I suspect there are only two options: 1. Wait for project developers to produce a build for CentOS 7 2. Try to do it yourself by building all packages needed. That would include a lot of dependencies that would need to be built. We will see what can we do on 1) on Monday but it would not be instantaneous. > Thanks! > > On Aug 23, 2014 2:44 PM, "Kat" > wrote: > > If you look closely, the "epel-7" repo is actually empty. There > are no packages there. > > So there are no packages to actually install. Only the "fedora" > repos in that same tree have packages. > > ~K > > On 8/23/14 12:29 PM, Dmitri Pal wrote: >> On 08/23/2014 08:33 PM, Chris Whittle wrote: >>> Thanks Dmitri, >>> I'm going to sound like a noob for a second but how do I add >>> that repo? >>> I added a repo call pviktori-epel-7 to /etc/yum.repos.d with the >>> following info >> >> Sorry this is beyond my skill set. >> I would leave it for some more experienced people to answer. >> Lukas mentioned in other mail that epel might not work. >> May be best would be to wait till Monday and ping people on >> #freeipa on freenode.net >> >>> >>> [pviktori-epel-7] >>> name=pviktori for RHEL/ CentOS $releasever - $basearch >>> baseurl=http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>> enabled=1 >>> >>> >>> And then ran >>> >>> [root at xavier yum.repos.d]# yum install freeipa-server >>> Loaded plugins: fastestmirror, langpacks >>> base | 3.6 kB 00:00 >>> extras | 3.3 kB 00:00 >>> pviktori-epel-7 | 3.0 kB 00:00 >>> updates | 3.4 kB 00:00 >>> pviktori-epel-7/primary_db | 1.4 kB 00:00 >>> Loading mirror speeds from cached hostfile >>> * base: mirror-centos.hostingswift.com >>> >>> * extras: centos.host-engine.com >>> >>> * updates: centos.arvixe.com >>> No package *freeipa-server* available. >>> Error: Nothing to do >>> >>> >>> I then tried >>> >>> [root at xavier yum.repos.d]# yum install ipa-server >>> >>> >>> and just got the 3.3 stuff... >>> I'm so close, I can taste it.... >>> Thanks for all your help >>> >>> >>> On Sat, Aug 23, 2014 at 8:23 AM, Dmitri Pal >> > wrote: >>> >>> On 08/23/2014 02:22 PM, Chris Whittle wrote: >>>> ipa-server does work but only for 3.3.3 I'm wanting 4 >>> >>> Try the epel repo >>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>> >>> >>>> >>>> >>>> On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle >>>> > wrote: >>>> >>>> Thanks, i was following the instructions >>>> >>>> On Aug 22, 2014 11:18 PM, "James" >>> > wrote: >>>> >>>> On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle >>>> > wrote: >>>> > I'm trying to install the repo from >>>> > >>>> https://copr.fedoraproject.org/coprs/pviktori/freeipa/ >>>> and when I go to >>>> > install I get >>>> > >>>> >> yum install freeipa-server >>>> >> >>>> >> Loaded plugins: fastestmirror, langpacks >>>> >> >>>> >> Repository pviktori-freeipa is listed more than >>>> once in the configuration >>>> >> >>>> >> >>>> >> >>>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml: >>>> >> [Errno 14] HTTP Error 404 - Not Found >>>> >> >>>> >> Trying other mirror. >>>> >> >>>> >> Loading mirror speeds from cached hostfile >>>> >> >>>> >> * base: mirror-centos.hostingswift.com >>>> >>>> >> >>>> >> * extras: centos.host-engine.com >>>> >>>> >> >>>> >> * updates: centos.arvixe.com >>>> >>>> >> >>>> >> No package freeipa-server available. >>>> >>> >>>> >>> Error: Nothing to do >>>> > >>>> > >>>> > Am I missing something? I remember that there >>>> was a thread about Centos 7 >>>> > and FreeIPA 4 but for the life of me I can't find it. >>>> > >>>> > Thanks >>>> Just a guess but it's probably called ipa-server. >>>> You can use yum search too. >>>> Eg: 'yum search freeipa' to find it. >>>> >>>> Cheers, >>>> James >>>> >>>> > >>>> > -- >>>> > Manage your subscription for the Freeipa-users >>>> mailing list: >>>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>>> > Go To http://freeipa.org for more info on the project >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uncommonkat at gmail.com Sat Aug 23 20:32:42 2014 From: uncommonkat at gmail.com (Kat) Date: Sat, 23 Aug 2014 13:32:42 -0700 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: <53F8F0B7.5070702@redhat.com> References: <53F895D6.9090502@redhat.com> <53F8EB96.2040703@redhat.com> <53F8EEB2.6050707@gmail.com> <53F8F0B7.5070702@redhat.com> Message-ID: <53F8FA6A.6070508@gmail.com> I am working on the same thing - specifically I have found the libnl dependencies to be the biggest headache. If I get anywhere over the weekend, I will let you all know. ~K On 8/23/14 12:51 PM, Dmitri Pal wrote: > On 08/23/2014 09:46 PM, Chris Whittle wrote: >> >> Thanks Kat, so what do I need to do? I have a brand new Centos 7 >> Server and I am itchy to install FreeIPA 4... >> > > I suspect there are only two options: > 1. Wait for project developers to produce a build for CentOS 7 > 2. Try to do it yourself by building all packages needed. That would > include a lot of dependencies that would need to be built. > > We will see what can we do on 1) on Monday but it would not be > instantaneous. > >> Thanks! >> >> On Aug 23, 2014 2:44 PM, "Kat" > > wrote: >> >> If you look closely, the "epel-7" repo is actually empty. There >> are no packages there. >> >> So there are no packages to actually install. Only the "fedora" >> repos in that same tree have packages. >> >> ~K >> >> On 8/23/14 12:29 PM, Dmitri Pal wrote: >>> On 08/23/2014 08:33 PM, Chris Whittle wrote: >>>> Thanks Dmitri, >>>> I'm going to sound like a noob for a second but how do I add >>>> that repo? >>>> I added a repo call pviktori-epel-7 to /etc/yum.repos.d with >>>> the following info >>> >>> Sorry this is beyond my skill set. >>> I would leave it for some more experienced people to answer. >>> Lukas mentioned in other mail that epel might not work. >>> May be best would be to wait till Monday and ping people on >>> #freeipa on freenode.net >>> >>>> >>>> [pviktori-epel-7] >>>> name=pviktori for RHEL/ CentOS $releasever - $basearch >>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>>> enabled=1 >>>> >>>> >>>> And then ran >>>> >>>> [root at xavier yum.repos.d]# yum install freeipa-server >>>> Loaded plugins: fastestmirror, langpacks >>>> base | 3.6 kB 00:00 >>>> extras | 3.3 kB 00:00 >>>> pviktori-epel-7 | 3.0 kB 00:00 >>>> updates | 3.4 kB 00:00 >>>> pviktori-epel-7/primary_db | 1.4 kB 00:00 >>>> Loading mirror speeds from cached hostfile >>>> * base: mirror-centos.hostingswift.com >>>> >>>> * extras: centos.host-engine.com >>>> >>>> * updates: centos.arvixe.com >>>> No package *freeipa-server* available. >>>> Error: Nothing to do >>>> >>>> >>>> I then tried >>>> >>>> [root at xavier yum.repos.d]# yum install ipa-server >>>> >>>> >>>> and just got the 3.3 stuff... >>>> I'm so close, I can taste it.... >>>> Thanks for all your help >>>> >>>> >>>> On Sat, Aug 23, 2014 at 8:23 AM, Dmitri Pal >>> > wrote: >>>> >>>> On 08/23/2014 02:22 PM, Chris Whittle wrote: >>>>> ipa-server does work but only for 3.3.3 I'm wanting 4 >>>> >>>> Try the epel repo >>>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>>> >>>> >>>>> >>>>> >>>>> On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle >>>>> > wrote: >>>>> >>>>> Thanks, i was following the instructions >>>>> >>>>> On Aug 22, 2014 11:18 PM, "James" >>>>> > >>>>> wrote: >>>>> >>>>> On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle >>>>> > wrote: >>>>> > I'm trying to install the repo from >>>>> > >>>>> https://copr.fedoraproject.org/coprs/pviktori/freeipa/ >>>>> and when I go to >>>>> > install I get >>>>> > >>>>> >> yum install freeipa-server >>>>> >> >>>>> >> Loaded plugins: fastestmirror, langpacks >>>>> >> >>>>> >> Repository pviktori-freeipa is listed more than >>>>> once in the configuration >>>>> >> >>>>> >> >>>>> >> >>>>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml: >>>>> >> [Errno 14] HTTP Error 404 - Not Found >>>>> >> >>>>> >> Trying other mirror. >>>>> >> >>>>> >> Loading mirror speeds from cached hostfile >>>>> >> >>>>> >> * base: mirror-centos.hostingswift.com >>>>> >>>>> >> >>>>> >> * extras: centos.host-engine.com >>>>> >>>>> >> >>>>> >> * updates: centos.arvixe.com >>>>> >>>>> >> >>>>> >> No package freeipa-server available. >>>>> >>> >>>>> >>> Error: Nothing to do >>>>> > >>>>> > >>>>> > Am I missing something? I remember that there >>>>> was a thread about Centos 7 >>>>> > and FreeIPA 4 but for the life of me I can't >>>>> find it. >>>>> > >>>>> > Thanks >>>>> Just a guess but it's probably called ipa-server. >>>>> You can use yum search too. >>>>> Eg: 'yum search freeipa' to find it. >>>>> >>>>> Cheers, >>>>> James >>>>> >>>>> > >>>>> > -- >>>>> > Manage your subscription for the Freeipa-users >>>>> mailing list: >>>>> > >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> > Go To http://freeipa.org for more info on the >>>>> project >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >>>> >>>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Sat Aug 23 20:42:40 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Sat, 23 Aug 2014 15:42:40 -0500 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: <53F8FA6A.6070508@gmail.com> References: <53F895D6.9090502@redhat.com> <53F8EB96.2040703@redhat.com> <53F8EEB2.6050707@gmail.com> <53F8F0B7.5070702@redhat.com> <53F8FA6A.6070508@gmail.com> Message-ID: Thanks Kat On Aug 23, 2014 3:36 PM, "Kat" wrote: > I am working on the same thing - specifically I have found the libnl > dependencies to be the biggest headache. If I get anywhere over the > weekend, I will let you all know. > > ~K > > On 8/23/14 12:51 PM, Dmitri Pal wrote: > > On 08/23/2014 09:46 PM, Chris Whittle wrote: > > Thanks Kat, so what do I need to do? I have a brand new Centos 7 Server > and I am itchy to install FreeIPA 4... > > > I suspect there are only two options: > 1. Wait for project developers to produce a build for CentOS 7 > 2. Try to do it yourself by building all packages needed. That would > include a lot of dependencies that would need to be built. > > We will see what can we do on 1) on Monday but it would not be > instantaneous. > > Thanks! > On Aug 23, 2014 2:44 PM, "Kat" wrote: > >> If you look closely, the "epel-7" repo is actually empty. There are no >> packages there. >> >> So there are no packages to actually install. Only the "fedora" repos in >> that same tree have packages. >> >> ~K >> >> On 8/23/14 12:29 PM, Dmitri Pal wrote: >> >> On 08/23/2014 08:33 PM, Chris Whittle wrote: >> >> Thanks Dmitri, >> I'm going to sound like a noob for a second but how do I add that repo? >> I added a repo call pviktori-epel-7 to /etc/yum.repos.d with the >> following info >> >> >> Sorry this is beyond my skill set. >> I would leave it for some more experienced people to answer. >> Lukas mentioned in other mail that epel might not work. >> May be best would be to wait till Monday and ping people on #freeipa on >> freenode.net >> >> >> [pviktori-epel-7] >>> name=pviktori for RHEL/ CentOS $releasever - $basearch >>> baseurl= >>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>> enabled=1 >> >> >> And then ran >> >>> [root at xavier yum.repos.d]# yum install freeipa-server >>> Loaded plugins: fastestmirror, langpacks >>> base | 3.6 kB >>> 00:00 >>> extras | 3.3 kB >>> 00:00 >>> pviktori-epel-7 | 3.0 kB >>> 00:00 >>> updates | 3.4 kB >>> 00:00 >>> pviktori-epel-7/primary_db | 1.4 kB >>> 00:00 >>> Loading mirror speeds from cached hostfile >>> * base: mirror-centos.hostingswift.com >>> * extras: centos.host-engine.com >>> * updates: centos.arvixe.com >>> No package *freeipa-server* available. >>> Error: Nothing to do >> >> >> I then tried >> >>> [root at xavier yum.repos.d]# yum install ipa-server >> >> >> and just got the 3.3 stuff... >> I'm so close, I can taste it.... >> Thanks for all your help >> >> >> On Sat, Aug 23, 2014 at 8:23 AM, Dmitri Pal wrote: >> >>> On 08/23/2014 02:22 PM, Chris Whittle wrote: >>> >>> ipa-server does work but only for 3.3.3 I'm wanting 4 >>> >>> >>> Try the epel repo >>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>> >>> >>> >>> On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle >>> wrote: >>> >>>> Thanks, i was following the instructions >>>> On Aug 22, 2014 11:18 PM, "James" wrote: >>>> >>>>> On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle >>>>> wrote: >>>>> > I'm trying to install the repo from >>>>> > https://copr.fedoraproject.org/coprs/pviktori/freeipa/ and when I >>>>> go to >>>>> > install I get >>>>> > >>>>> >> yum install freeipa-server >>>>> >> >>>>> >> Loaded plugins: fastestmirror, langpacks >>>>> >> >>>>> >> Repository pviktori-freeipa is listed more than once in the >>>>> configuration >>>>> >> >>>>> >> >>>>> >> >>>>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml >>>>> : >>>>> >> [Errno 14] HTTP Error 404 - Not Found >>>>> >> >>>>> >> Trying other mirror. >>>>> >> >>>>> >> Loading mirror speeds from cached hostfile >>>>> >> >>>>> >> * base: mirror-centos.hostingswift.com >>>>> >> >>>>> >> * extras: centos.host-engine.com >>>>> >> >>>>> >> * updates: centos.arvixe.com >>>>> >> >>>>> >> No package freeipa-server available. >>>>> >>> >>>>> >>> Error: Nothing to do >>>>> > >>>>> > >>>>> > Am I missing something? I remember that there was a thread about >>>>> Centos 7 >>>>> > and FreeIPA 4 but for the life of me I can't find it. >>>>> > >>>>> > Thanks >>>>> Just a guess but it's probably called ipa-server. >>>>> You can use yum search too. >>>>> Eg: 'yum search freeipa' to find it. >>>>> >>>>> Cheers, >>>>> James >>>>> >>>>> > >>>>> > -- >>>>> > Manage your subscription for the Freeipa-users mailing list: >>>>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> > Go To http://freeipa.org for more info on the project >>>>> >>>> >>> >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > > > > -- > Manage your subscription for 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 dpal at redhat.com Sat Aug 23 20:48:55 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 23 Aug 2014 22:48:55 +0200 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: <53F8FA6A.6070508@gmail.com> References: <53F895D6.9090502@redhat.com> <53F8EB96.2040703@redhat.com> <53F8EEB2.6050707@gmail.com> <53F8F0B7.5070702@redhat.com> <53F8FA6A.6070508@gmail.com> Message-ID: <53F8FE37.2010208@redhat.com> On 08/23/2014 10:32 PM, Kat wrote: > I am working on the same thing - specifically I have found the libnl > dependencies to be the biggest headache. If I get anywhere over the > weekend, I will let you all know. do not forget about sssd, samba, certmonger, ging-libs; not all dependencies are yet polished in all distros. > > ~K > > On 8/23/14 12:51 PM, Dmitri Pal wrote: >> On 08/23/2014 09:46 PM, Chris Whittle wrote: >>> >>> Thanks Kat, so what do I need to do? I have a brand new Centos 7 >>> Server and I am itchy to install FreeIPA 4... >>> >> >> I suspect there are only two options: >> 1. Wait for project developers to produce a build for CentOS 7 >> 2. Try to do it yourself by building all packages needed. That would >> include a lot of dependencies that would need to be built. >> >> We will see what can we do on 1) on Monday but it would not be >> instantaneous. >> >>> Thanks! >>> >>> On Aug 23, 2014 2:44 PM, "Kat" >> > wrote: >>> >>> If you look closely, the "epel-7" repo is actually empty. There >>> are no packages there. >>> >>> So there are no packages to actually install. Only the "fedora" >>> repos in that same tree have packages. >>> >>> ~K >>> >>> On 8/23/14 12:29 PM, Dmitri Pal wrote: >>>> On 08/23/2014 08:33 PM, Chris Whittle wrote: >>>>> Thanks Dmitri, >>>>> I'm going to sound like a noob for a second but how do I add >>>>> that repo? >>>>> I added a repo call pviktori-epel-7 to /etc/yum.repos.d with >>>>> the following info >>>> >>>> Sorry this is beyond my skill set. >>>> I would leave it for some more experienced people to answer. >>>> Lukas mentioned in other mail that epel might not work. >>>> May be best would be to wait till Monday and ping people on >>>> #freeipa on freenode.net >>>> >>>>> >>>>> [pviktori-epel-7] >>>>> name=pviktori for RHEL/ CentOS $releasever - $basearch >>>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>>>> enabled=1 >>>>> >>>>> >>>>> And then ran >>>>> >>>>> [root at xavier yum.repos.d]# yum install freeipa-server >>>>> Loaded plugins: fastestmirror, langpacks >>>>> base | 3.6 kB 00:00 >>>>> extras | 3.3 kB 00:00 >>>>> pviktori-epel-7 | 3.0 kB 00:00 >>>>> updates | 3.4 kB 00:00 >>>>> pviktori-epel-7/primary_db | 1.4 kB 00:00 >>>>> Loading mirror speeds from cached hostfile >>>>> * base: mirror-centos.hostingswift.com >>>>> >>>>> * extras: centos.host-engine.com >>>>> >>>>> * updates: centos.arvixe.com >>>>> No package *freeipa-server* available. >>>>> Error: Nothing to do >>>>> >>>>> >>>>> I then tried >>>>> >>>>> [root at xavier yum.repos.d]# yum install ipa-server >>>>> >>>>> >>>>> and just got the 3.3 stuff... >>>>> I'm so close, I can taste it.... >>>>> Thanks for all your help >>>>> >>>>> >>>>> On Sat, Aug 23, 2014 at 8:23 AM, Dmitri Pal >>>> > wrote: >>>>> >>>>> On 08/23/2014 02:22 PM, Chris Whittle wrote: >>>>>> ipa-server does work but only for 3.3.3 I'm wanting 4 >>>>> >>>>> Try the epel repo >>>>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle >>>>>> > wrote: >>>>>> >>>>>> Thanks, i was following the instructions >>>>>> >>>>>> On Aug 22, 2014 11:18 PM, "James" >>>>>> > >>>>>> wrote: >>>>>> >>>>>> On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle >>>>>> > wrote: >>>>>> > I'm trying to install the repo from >>>>>> > >>>>>> https://copr.fedoraproject.org/coprs/pviktori/freeipa/ >>>>>> and when I go to >>>>>> > install I get >>>>>> > >>>>>> >> yum install freeipa-server >>>>>> >> >>>>>> >> Loaded plugins: fastestmirror, langpacks >>>>>> >> >>>>>> >> Repository pviktori-freeipa is listed more >>>>>> than once in the configuration >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml: >>>>>> >> [Errno 14] HTTP Error 404 - Not Found >>>>>> >> >>>>>> >> Trying other mirror. >>>>>> >> >>>>>> >> Loading mirror speeds from cached hostfile >>>>>> >> >>>>>> >> * base: mirror-centos.hostingswift.com >>>>>> >>>>>> >> >>>>>> >> * extras: centos.host-engine.com >>>>>> >>>>>> >> >>>>>> >> * updates: centos.arvixe.com >>>>>> >>>>>> >> >>>>>> >> No package freeipa-server available. >>>>>> >>> >>>>>> >>> Error: Nothing to do >>>>>> > >>>>>> > >>>>>> > Am I missing something? I remember that there >>>>>> was a thread about Centos 7 >>>>>> > and FreeIPA 4 but for the life of me I can't >>>>>> find it. >>>>>> > >>>>>> > Thanks >>>>>> Just a guess but it's probably called ipa-server. >>>>>> You can use yum search too. >>>>>> Eg: 'yum search freeipa' to find it. >>>>>> >>>>>> Cheers, >>>>>> James >>>>>> >>>>>> > >>>>>> > -- >>>>>> > Manage your subscription for the Freeipa-users >>>>>> mailing list: >>>>>> > >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> > Go To http://freeipa.org for more info on the >>>>>> project >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thank you, >>>>> Dmitri Pal >>>>> >>>>> Sr. Engineering Manager IdM portfolio >>>>> Red Hat, Inc. >>>>> >>>>> >>>>> -- >>>>> Manage your subscription for the Freeipa-users mailing list: >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> Go To http://freeipa.org for more info on the project >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager IdM portfolio >>>> Red Hat, Inc. >>>> >>>> >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >>> >>> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Sun Aug 24 00:04:58 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Sun, 24 Aug 2014 00:04:58 +0000 Subject: [Freeipa-users] A prototype of merged domains ("views") Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E71869F@001FSN2MPN1-045.001f.mgd2.msft.net> Over the past month, I rearranged my local systems for our collaboration environment. The essence of the work is to combine employee identities (defined in AD) with identities for external users (defined in FreeIPA), massage them so that they look the same, and export them to every posix desktop and web application I support. Defining cross-domain posix groups is included, and was successfully performed, but sssd doesn't have a vocabulary to describe a merged domain (one identity provider, multiple auth providers). Still trying to figure out if I can force this to work somehow. The activity may shine a light on some of the things "views" might be required to do. http://www.freeipa.org/page/V4/Use_Case_for_Views:_Collaboration Enjoy, Bryce 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 cwhittl at gmail.com Sun Aug 24 05:12:23 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Sun, 24 Aug 2014 00:12:23 -0500 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: <53F8FE37.2010208@redhat.com> References: <53F895D6.9090502@redhat.com> <53F8EB96.2040703@redhat.com> <53F8EEB2.6050707@gmail.com> <53F8F0B7.5070702@redhat.com> <53F8FA6A.6070508@gmail.com> <53F8FE37.2010208@redhat.com> Message-ID: I gave up and just installed Fedora... Looks like once my provider opens my ports I'm going to be good... One last question is the UI url the same from 3.3 to 4? On Sat, Aug 23, 2014 at 3:48 PM, Dmitri Pal wrote: > On 08/23/2014 10:32 PM, Kat wrote: > > I am working on the same thing - specifically I have found the libnl > dependencies to be the biggest headache. If I get anywhere over the > weekend, I will let you all know. > > > do not forget about sssd, samba, certmonger, ging-libs; not all > dependencies are yet polished in all distros. > > > ~K > > On 8/23/14 12:51 PM, Dmitri Pal wrote: > > On 08/23/2014 09:46 PM, Chris Whittle wrote: > > Thanks Kat, so what do I need to do? I have a brand new Centos 7 Server > and I am itchy to install FreeIPA 4... > > > I suspect there are only two options: > 1. Wait for project developers to produce a build for CentOS 7 > 2. Try to do it yourself by building all packages needed. That would > include a lot of dependencies that would need to be built. > > We will see what can we do on 1) on Monday but it would not be > instantaneous. > > Thanks! > On Aug 23, 2014 2:44 PM, "Kat" wrote: > >> If you look closely, the "epel-7" repo is actually empty. There are no >> packages there. >> >> So there are no packages to actually install. Only the "fedora" repos in >> that same tree have packages. >> >> ~K >> >> On 8/23/14 12:29 PM, Dmitri Pal wrote: >> >> On 08/23/2014 08:33 PM, Chris Whittle wrote: >> >> Thanks Dmitri, >> I'm going to sound like a noob for a second but how do I add that repo? >> I added a repo call pviktori-epel-7 to /etc/yum.repos.d with the >> following info >> >> >> Sorry this is beyond my skill set. >> I would leave it for some more experienced people to answer. >> Lukas mentioned in other mail that epel might not work. >> May be best would be to wait till Monday and ping people on #freeipa on >> freenode.net >> >> >> [pviktori-epel-7] >>> name=pviktori for RHEL/ CentOS $releasever - $basearch >>> baseurl= >>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>> enabled=1 >> >> >> And then ran >> >>> [root at xavier yum.repos.d]# yum install freeipa-server >>> Loaded plugins: fastestmirror, langpacks >>> base | 3.6 kB >>> 00:00 >>> extras | 3.3 kB >>> 00:00 >>> pviktori-epel-7 | 3.0 kB >>> 00:00 >>> updates | 3.4 kB >>> 00:00 >>> pviktori-epel-7/primary_db | 1.4 kB >>> 00:00 >>> Loading mirror speeds from cached hostfile >>> * base: mirror-centos.hostingswift.com >>> * extras: centos.host-engine.com >>> * updates: centos.arvixe.com >>> No package *freeipa-server* available. >>> Error: Nothing to do >> >> >> I then tried >> >>> [root at xavier yum.repos.d]# yum install ipa-server >> >> >> and just got the 3.3 stuff... >> I'm so close, I can taste it.... >> Thanks for all your help >> >> >> On Sat, Aug 23, 2014 at 8:23 AM, Dmitri Pal wrote: >> >>> On 08/23/2014 02:22 PM, Chris Whittle wrote: >>> >>> ipa-server does work but only for 3.3.3 I'm wanting 4 >>> >>> >>> Try the epel repo >>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>> >>> >>> >>> On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle >>> wrote: >>> >>>> Thanks, i was following the instructions >>>> On Aug 22, 2014 11:18 PM, "James" wrote: >>>> >>>>> On Sat, Aug 23, 2014 at 12:13 AM, Chris Whittle >>>>> wrote: >>>>> > I'm trying to install the repo from >>>>> > https://copr.fedoraproject.org/coprs/pviktori/freeipa/ and when I >>>>> go to >>>>> > install I get >>>>> > >>>>> >> yum install freeipa-server >>>>> >> >>>>> >> Loaded plugins: fastestmirror, langpacks >>>>> >> >>>>> >> Repository pviktori-freeipa is listed more than once in the >>>>> configuration >>>>> >> >>>>> >> >>>>> >> >>>>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml >>>>> : >>>>> >> [Errno 14] HTTP Error 404 - Not Found >>>>> >> >>>>> >> Trying other mirror. >>>>> >> >>>>> >> Loading mirror speeds from cached hostfile >>>>> >> >>>>> >> * base: mirror-centos.hostingswift.com >>>>> >> >>>>> >> * extras: centos.host-engine.com >>>>> >> >>>>> >> * updates: centos.arvixe.com >>>>> >> >>>>> >> No package freeipa-server available. >>>>> >>> >>>>> >>> Error: Nothing to do >>>>> > >>>>> > >>>>> > Am I missing something? I remember that there was a thread about >>>>> Centos 7 >>>>> > and FreeIPA 4 but for the life of me I can't find it. >>>>> > >>>>> > Thanks >>>>> Just a guess but it's probably called ipa-server. >>>>> You can use yum search too. >>>>> Eg: 'yum search freeipa' to find it. >>>>> >>>>> Cheers, >>>>> James >>>>> >>>>> > >>>>> > -- >>>>> > Manage your subscription for the Freeipa-users mailing list: >>>>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> > Go To http://freeipa.org for more info on the project >>>>> >>>> >>> >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go To http://freeipa.org for more info on the project >>> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> >> >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project >> > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for 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 dpal at redhat.com Sun Aug 24 08:02:09 2014 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 24 Aug 2014 10:02:09 +0200 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: References: <53F895D6.9090502@redhat.com> <53F8EB96.2040703@redhat.com> <53F8EEB2.6050707@gmail.com> <53F8F0B7.5070702@redhat.com> <53F8FA6A.6070508@gmail.com> <53F8FE37.2010208@redhat.com> Message-ID: <53F99C01.9040204@redhat.com> On 08/24/2014 07:12 AM, Chris Whittle wrote: > I gave up and just installed Fedora... Looks like once my provider > opens my ports I'm going to be good... One last question is the UI url > the same from 3.3 to 4? Yes. You can see for yourself http://www.freeipa.org/page/Demo > > > On Sat, Aug 23, 2014 at 3:48 PM, Dmitri Pal > wrote: > > On 08/23/2014 10:32 PM, Kat wrote: >> I am working on the same thing - specifically I have found the >> libnl dependencies to be the biggest headache. If I get anywhere >> over the weekend, I will let you all know. > > do not forget about sssd, samba, certmonger, ging-libs; not all > dependencies are yet polished in all distros. > >> >> ~K >> >> On 8/23/14 12:51 PM, Dmitri Pal wrote: >>> On 08/23/2014 09:46 PM, Chris Whittle wrote: >>>> >>>> Thanks Kat, so what do I need to do? I have a brand new >>>> Centos 7 Server and I am itchy to install FreeIPA 4... >>>> >>> >>> I suspect there are only two options: >>> 1. Wait for project developers to produce a build for CentOS 7 >>> 2. Try to do it yourself by building all packages needed. That >>> would include a lot of dependencies that would need to be built. >>> >>> We will see what can we do on 1) on Monday but it would not be >>> instantaneous. >>> >>>> Thanks! >>>> >>>> On Aug 23, 2014 2:44 PM, "Kat" >>> > wrote: >>>> >>>> If you look closely, the "epel-7" repo is actually empty. >>>> There are no packages there. >>>> >>>> So there are no packages to actually install. Only the >>>> "fedora" repos in that same tree have packages. >>>> >>>> ~K >>>> >>>> On 8/23/14 12:29 PM, Dmitri Pal wrote: >>>>> On 08/23/2014 08:33 PM, Chris Whittle wrote: >>>>>> Thanks Dmitri, >>>>>> I'm going to sound like a noob for a second but how do I >>>>>> add that repo? >>>>>> I added a repo call pviktori-epel-7 to /etc/yum.repos.d >>>>>> with the following info >>>>> >>>>> Sorry this is beyond my skill set. >>>>> I would leave it for some more experienced people to answer. >>>>> Lukas mentioned in other mail that epel might not work. >>>>> May be best would be to wait till Monday and ping people >>>>> on #freeipa on freenode.net >>>>> >>>>>> >>>>>> [pviktori-epel-7] >>>>>> name=pviktori for RHEL/ CentOS $releasever - $basearch >>>>>> baseurl=http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>>>>> enabled=1 >>>>>> >>>>>> >>>>>> And then ran >>>>>> >>>>>> [root at xavier yum.repos.d]# yum install freeipa-server >>>>>> Loaded plugins: fastestmirror, langpacks >>>>>> base | 3.6 kB 00:00 >>>>>> extras | 3.3 kB 00:00 >>>>>> pviktori-epel-7 | 3.0 kB >>>>>> 00:00 >>>>>> updates | 3.4 kB 00:00 >>>>>> pviktori-epel-7/primary_db >>>>>> | 1.4 kB 00:00 >>>>>> Loading mirror speeds from cached hostfile >>>>>> * base: mirror-centos.hostingswift.com >>>>>> >>>>>> * extras: centos.host-engine.com >>>>>> >>>>>> * updates: centos.arvixe.com >>>>>> No package *freeipa-server* available. >>>>>> Error: Nothing to do >>>>>> >>>>>> >>>>>> I then tried >>>>>> >>>>>> [root at xavier yum.repos.d]# yum install ipa-server >>>>>> >>>>>> >>>>>> and just got the 3.3 stuff... >>>>>> I'm so close, I can taste it.... >>>>>> Thanks for all your help >>>>>> >>>>>> >>>>>> On Sat, Aug 23, 2014 at 8:23 AM, Dmitri Pal >>>>>> > wrote: >>>>>> >>>>>> On 08/23/2014 02:22 PM, Chris Whittle wrote: >>>>>>> ipa-server does work but only for 3.3.3 I'm wanting 4 >>>>>> >>>>>> Try the epel repo >>>>>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/epel-7-x86_64/ >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Aug 23, 2014 at 7:16 AM, Chris Whittle >>>>>>> > wrote: >>>>>>> >>>>>>> Thanks, i was following the instructions >>>>>>> >>>>>>> On Aug 22, 2014 11:18 PM, "James" >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> On Sat, Aug 23, 2014 at 12:13 AM, Chris >>>>>>> Whittle >>>>>> > wrote: >>>>>>> > I'm trying to install the repo from >>>>>>> > >>>>>>> https://copr.fedoraproject.org/coprs/pviktori/freeipa/ >>>>>>> and when I go to >>>>>>> > install I get >>>>>>> > >>>>>>> >> yum install freeipa-server >>>>>>> >> >>>>>>> >> Loaded plugins: fastestmirror, langpacks >>>>>>> >> >>>>>>> >> Repository pviktori-freeipa is listed >>>>>>> more than once in the configuration >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> http://copr-be.cloud.fedoraproject.org/results/pviktori/freeipa/fedora-7-x86_64/repodata/repomd.xml: >>>>>>> >> [Errno 14] HTTP Error 404 - Not Found >>>>>>> >> >>>>>>> >> Trying other mirror. >>>>>>> >> >>>>>>> >> Loading mirror speeds from cached hostfile >>>>>>> >> >>>>>>> >> * base: mirror-centos.hostingswift.com >>>>>>> >>>>>>> >> >>>>>>> >> * extras: centos.host-engine.com >>>>>>> >>>>>>> >> >>>>>>> >> * updates: centos.arvixe.com >>>>>>> >>>>>>> >> >>>>>>> >> No package freeipa-server available. >>>>>>> >>> >>>>>>> >>> Error: Nothing to do >>>>>>> > >>>>>>> > >>>>>>> > Am I missing something? I remember that >>>>>>> there was a thread about Centos 7 >>>>>>> > and FreeIPA 4 but for the life of me I >>>>>>> can't find it. >>>>>>> > >>>>>>> > Thanks >>>>>>> Just a guess but it's probably called >>>>>>> ipa-server. >>>>>>> You can use yum search too. >>>>>>> Eg: 'yum search freeipa' to find it. >>>>>>> >>>>>>> Cheers, >>>>>>> James >>>>>>> >>>>>>> > >>>>>>> > -- >>>>>>> > Manage your subscription for the >>>>>>> Freeipa-users mailing list: >>>>>>> > >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>> > Go To http://freeipa.org for more info on >>>>>>> the project >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thank you, >>>>>> Dmitri Pal >>>>>> >>>>>> Sr. Engineering Manager IdM portfolio >>>>>> Red Hat, Inc. >>>>>> >>>>>> >>>>>> -- >>>>>> Manage your subscription for the Freeipa-users >>>>>> mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> Go To http://freeipa.org for more info on the project >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thank you, >>>>> Dmitri Pal >>>>> >>>>> Sr. Engineering Manager IdM portfolio >>>>> Red Hat, Inc. >>>>> >>>>> >>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go To http://freeipa.org for more info on the project >>>> >>>> >>>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >> >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Mon Aug 25 01:04:23 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Sun, 24 Aug 2014 20:04:23 -0500 Subject: [Freeipa-users] Installing a new Cert Message-ID: Trying to do this http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP And I keep getting "Error unable to get local issuer certificate getting chain." I'm wondering if it's because of this from the doc "The certificate in mysite.crt must be signed by the CA used when installing FreeIPA." but it might not either... Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Mon Aug 25 06:42:27 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 25 Aug 2014 08:42:27 +0200 Subject: [Freeipa-users] Centos 7 and 4.0 In-Reply-To: <53F8FE37.2010208@redhat.com> References: <53F895D6.9090502@redhat.com> <53F8EB96.2040703@redhat.com> <53F8EEB2.6050707@gmail.com> <53F8F0B7.5070702@redhat.com> <53F8FA6A.6070508@gmail.com> <53F8FE37.2010208@redhat.com> Message-ID: <20140825064226.GA8940@mail.corp.redhat.com> On (23/08/14 22:48), Dmitri Pal wrote: >On 08/23/2014 10:32 PM, Kat wrote: >>I am working on the same thing - specifically I have found the libnl >>dependencies to be the biggest headache. If I get anywhere over the >>weekend, I will let you all know. > >do not forget about sssd, samba, certmonger, ging-libs; not all dependencies >are yet polished in all distros. I rebuild lot of dependencies[1], but the most problematic is dogtag. Error: Package: freeipa-server-4.0.1-1.el7.x86_64 (lslebodn-ding-libs) Requires: pki-ca >= 10.1.1 Available: pki-ca-10.0.5-3.el7.noarch (base) pki-ca = 10.0.5-3.el7 Available: pki-ca-10.0.6-1.el7.noarch (lslebodn-ding-libs) pki-ca = 10.0.6-1.el7 It requires resteasy >= 3.0.1-3 I tried to rebuild new resteasy (resteasy-3.0.6-2.fc20.src.rpm), but there are lots of missing dependensies. So I gave up. I am not expert in java packaging. Error: No Package found for apache-james-project Error: No Package found for apache-mime4j >= 0.7.2-2 Error: No Package found for bean-validation-api Error: No Package found for classmate Error: No Package found for hibernate-validator Error: No Package found for infinispan Error: No Package found for jackson-annotations Error: No Package found for jackson-core Error: No Package found for jackson-databind Error: No Package found for jackson-jaxrs-json-provider Error: No Package found for jackson-module-jaxb-annotations Error: No Package found for jcip-annotations Error: No Package found for jsonp Error: No Package found for maven-jaxb2-plugin Error: No Package found for maven-plugin-cobertura Error: No Package found for maven-pmd-plugin Error: No Package found for netty Error: No Package found for picketbox Error: No Package found for springframework-webmvc Error: No Package found for undertow just for record here is a list of successfully rebuild src.rpms and needed rpms [1] list of rebuilt packages 389-ds-base-1.3.2.22-1.fc20.src.rpm ctdb-2.4-1.fc20.src.rpm dogtag-pki-theme-10.1.1-1.fc20.src.rpm fontawesome-fonts-4.0.3-1.fc20.src.rpm krb5-1.11.5-12.fc20.src.rpm open-sans-fonts-1.10-1.fc20.src.rpm python-kerberos-1.1-14.fc20.src.rpm python-nss-0.15.0-1.fc20.src.rpm python-polib-1.0.3-3.fc20.src.rpm python-qrcode-2.4.1-5.fc20.src.rpm python-yubico-1.2.1-3.fc20.src.rpm pyusb-1.0.0-0.7.a3.fc20.src.rpm samba-4.1.9-4.fc20.src.rpm ttembed-1.1-1.fc20.src.rpm [2] list of missing dependecies pki-core-10.1.1-1.fc20.src.rpm and probably nevwe version of selinux-policy (for testing purposes, it could be removed from freeipa spec file and user can create their own rules.) LS From mkosek at redhat.com Mon Aug 25 07:58:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 Aug 2014 09:58:15 +0200 Subject: [Freeipa-users] Ubuntu 3.3.x client vs. 3.0.0 server In-Reply-To: References: Message-ID: <53FAEC97.1060003@redhat.com> On 08/22/2014 10:41 PM, Michael Lasevich wrote: > Trying to use ipa command line admin tools from Ubuntu 14.04 box against > 3.0.0 CentOS 6 server and running into trouble. > > Seems like upgrading server is not an option without upgrading the server, > and 3.3.0 client is not compatible with 3.0.0 server (seems to be sending > invalid fields to the server in api) > > I cannot seem to easily find a way to get 3.0 client on ubuntu not do I see > any pre-made 3.0 deb packages. > > Any suggestions? > > Thanks, > > -M Please see http://www.freeipa.org/page/Client#Compatibility which describes our current compatibility constrains for "ipa" tool. TLDR; your 3.3 clients should work just fine regarding to FreeIPA services (identity, authentication, authorization, sudo, ...). But when you want to use the "ipa" tool, you would either need to use the one on the FreeIPA server or use one from other CentOS 6 FreeIPA client (or use the Web UI). Martin From jcholast at redhat.com Mon Aug 25 08:52:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Aug 2014 10:52:06 +0200 Subject: [Freeipa-users] Installing a new Cert In-Reply-To: References: Message-ID: <53FAF936.9000506@redhat.com> Hi, Dne 25.8.2014 v 03:04 Chris Whittle napsal(a): > Trying to do this > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > > And I keep getting "Error unable to get local issuer certificate getting > chain." Where are you getting this error? ipa-server-certinstall, or httpd, or somewhere else? What version of ipa do you have installed? > > I'm wondering if it's because of this from the doc > "The certificate in mysite.crt must be signed by the CA used when > installing FreeIPA." > but it might not either... In this case you should get a "file.p12 is not signed by /etc/ipa/ca.crt, or the full certificate chain is not present in the PKCS#12 file" error in ipa-server-certinstall. > > Any ideas? > > Honza -- Jan Cholasta From jcholast at redhat.com Mon Aug 25 08:55:22 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 25 Aug 2014 10:55:22 +0200 Subject: [Freeipa-users] ca.crt contains more than one certificate In-Reply-To: <53E4C68A.7040909@skalarit.se> References: <53E4C68A.7040909@skalarit.se> Message-ID: <53FAF9FA.4010709@redhat.com> Hi, Dne 8.8.2014 v 14:46 Nicklas Bj?rk napsal(a): > Trying to upgrade from FreeIPA 3.0 running on CentOS 6 to 3.3 on CentOS > 7 using migration. I seem to have run into some certificate problems and > the replica installation halts half-way through. We have a simple > CA-structure, where FreeIPA has been installed as a sub-ca directly > under ca root ca. > > A replica bundle was created on the master using: > ipa-replica-prepare replica.example.net --ip-address 192.168.100.2 > the gpg-file was copied to replica:/var/lib/ipa and the following > command was executed: > ipa-replica-install --mkhomedir -d --setup-ca --setup-dns > --no-forwarders /var/lib/ipa/replica-info-replica.example.net.gpg > > During the first attempt, I was instructed to also run > copy-schema-to-ca.py on the master server, which has been done. The > replica installation halts complainig that ca.crt contains more than one > certificate. Both the FreeIPA CA and the Root CA certificates are in > that file. > > > Debug output in /var/log/ipareplica-install.log tells the following: > > 2014-08-08T12:22:08Z DEBUG [17/34]: configuring ssl for ds instance > 2014-08-08T12:22:08Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2014-08-08T12:22:08Z DEBUG Starting external process > 2014-08-08T12:22:08Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-EXAMPLE-NET/ -N -f > /etc/dirsrv/slapd-EXAMPLE-NET//pwdfile.txt > 2014-08-08T12:22:08Z DEBUG Process finished, return code=0 > 2014-08-08T12:22:08Z DEBUG stdout= > 2014-08-08T12:22:08Z DEBUG stderr= > 2014-08-08T12:22:08Z DEBUG Starting external process > 2014-08-08T12:22:08Z DEBUG args=/usr/bin/pk12util -d > /etc/dirsrv/slapd-EXAMPLE-NET/ -i > /tmp/tmpNOzZ3cipa/realm_info/dscert.p12 -k > /etc/dirsrv/slapd-EXAMPLE-NET//pwdfile.txt -v -w /dev/stdin > 2014-08-08T12:22:08Z DEBUG Process finished, return code=0 > 2014-08-08T12:22:08Z DEBUG stdout=pk12util: PKCS12 IMPORT SUCCESSFUL > > 2014-08-08T12:22:08Z DEBUG stderr= > 2014-08-08T12:22:08Z DEBUG Starting external process > 2014-08-08T12:22:08Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-EXAMPLE-NET/ -L > 2014-08-08T12:22:08Z DEBUG Process finished, return code=0 > 2014-08-08T12:22:08Z DEBUG stdout= > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > Server-Cert u,u,u > CN=Example Root CA,O=Example AB ,, > EXAMPLE.NET IPA CA ,, > > 2014-08-08T12:22:08Z DEBUG stderr= > 2014-08-08T12:22:08Z DEBUG Starting external process > 2014-08-08T12:22:08Z DEBUG args=/usr/bin/certutil -d > /etc/dirsrv/slapd-EXAMPLE-NET/ -A -n CA -t CT,CT, -a > 2014-08-08T12:22:08Z DEBUG Process finished, return code=0 > 2014-08-08T12:22:08Z DEBUG stdout= > 2014-08-08T12:22:08Z DEBUG stderr= > 2014-08-08T12:22:08Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 638, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-replica-install", line 664, in main > ds = install_replica_ds(config) > > File "/usr/sbin/ipa-replica-install", line 189, in install_replica_ds > ca_file=config.dir + "/ca.crt", > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line > 360, in create_replica > self.start_creation(runtime=60) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 364, in start_creation > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line > 606, in enable_ssl > ca_file=self.ca_file) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", > line 841, in create_from_pkcs12 > self.nssdb.import_pem_cert('CA', 'CT,CT,', ca_file) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py", > line 240, in import_pem_cert > location) > > 2014-08-08T12:22:08Z DEBUG The ipa-replica-install command failed, > exception: ValueError: /tmp/tmpNOzZ3cipa/realm_info/ca.crt contains more > than one certificate > > > > Is there anything obvious that is wrong or odd with this setup or process? It seems you somehow ended up with more than one certificate in /etc/ipa/ca.crt on the master. It should contain only the IPA CA certificate, if you delete all other certificates from it and re-run ipa-replica-prepare, you should be able to successfully install the replica using ipa-replica-install. > > > Best regards > Nicklas Bj?rk > > > Honza -- Jan Cholasta From abokovoy at redhat.com Mon Aug 25 09:04:20 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 Aug 2014 12:04:20 +0300 Subject: [Freeipa-users] A prototype of merged domains ("views") In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E71869F@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E71869F@001FSN2MPN1-045.001f.mgd2.msft.net> Message-ID: <20140825090420.GH4748@redhat.com> On Sun, 24 Aug 2014, Nordgren, Bryce L -FS wrote: >Over the past month, I rearranged my local systems for our >collaboration environment. The essence of the work is to combine >employee identities (defined in AD) with identities for external users >(defined in FreeIPA), massage them so that they look the same, and >export them to every posix desktop and web application I support. > >Defining cross-domain posix groups is included, and was successfully >performed, but sssd doesn't have a vocabulary to describe a merged >domain (one identity provider, multiple auth providers). Still trying >to figure out if I can force this to work somehow. > >The activity may shine a light on some of the things "views" might be >required to do. > >http://www.freeipa.org/page/V4/Use_Case_for_Views:_Collaboration After reading the page I think you are over-complicating your own deployment for no real benefit. What essentially you want is to arbitrate access control to certain services regardless the source users or groups are coming from. This is already possible to achieve with HBAC rules because we already can make external SIDs members of a non-POSIX group that is included into a POSIX group which is referenced by an HBAC rule. This works already and doesn't need any views because HBAC rules already can be subjected to a specific host and specific service on the host. We need to extend concept of external members of non-POSIX groups to have the same resolving features as we are planning with ID view overrides (SID:S-..., IPA:, etc) so that external non-POSIX groups can be used more widely. Note that ID view overrides per host will then affect HBAC rule content automatically as SSSD would perform group/user resolution prior to evaluating the rule. Your other problem is that you seem to unable to establish two-way trust with AD as currently IPA requires. I have plans to get one-way trust back working but it needs additional changes on our side to properly protect trust account credentials when distributing them to a group of IPA masters participating in the trust. -- / Alexander Bokovoy From baghery.jone at gmail.com Mon Aug 25 10:01:52 2014 From: baghery.jone at gmail.com (alireza baghery) Date: Mon, 25 Aug 2014 14:31:52 +0430 Subject: [Freeipa-users] users AD can not sudo in centos 6.5 Message-ID: hi i integrated AD windows 208 R2 with IPA server (centos 6.5) i write a sudo policy and access for specified user and host with allow any command. user can execute sudo in centos 7 but when user loggin on centos 6.5 can not execute sudo and get error below user at AD is not in sudoers file. i configure /etc/nsswitch.conf --sudoers: file sss /etc/sss/sss.conf----service nss, pam,ssh,sudo /etc/sysconfig/network ----- NISDOMAIN=ad.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Aug 25 10:12:26 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 25 Aug 2014 12:12:26 +0200 Subject: [Freeipa-users] users AD can not sudo in centos 6.5 In-Reply-To: References: Message-ID: <53FB0C0A.3010009@redhat.com> On 08/25/2014 12:01 PM, alireza baghery wrote: > hi > i integrated AD windows 208 R2 with IPA server (centos 6.5) > i write a sudo policy and access for specified user and host with > allow any command. > user can execute sudo in centos 7 but when user loggin on centos 6.5 > can not execute sudo and get error below > user at AD is not in sudoers file. > i configure /etc/nsswitch.conf --sudoers: file sss > /etc/sss/sss.conf----service nss, pam,ssh,sudo > /etc/sysconfig/network ----- NISDOMAIN=ad.com > > > AFAIR there was a bug in 6.5 around sudo and AD users, it has been fixed in fedora but I am not sure it made its way into all distros yet. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagemnna at gmail.com Mon Aug 25 10:51:27 2014 From: nagemnna at gmail.com (Megan .) Date: Mon, 25 Aug 2014 06:51:27 -0400 Subject: [Freeipa-users] sudo with freeIPA Message-ID: Good Morning, I'm very new to freeIPA. I'm running centOS 6.5 with freeIPA v3 I have the freeIPA server up but i'm working on getting SUDO configured. Currently i'm having problems getting sudo commands to work on the client. I'm a bit unclear if i have everything configured correctly. The only thing that I can figure out might be an issue, is when i try the sudo command i see a filter search with objectclass=sudoRule but when i check the ldap server it has objectclass=sudoRole, so there are no results. Any ideas? Thank you in advance for any advice. [tuser2 at map1 ~]$ sudo /sbin/iptables -L Enter RSA PIN+token: tuser2 is not allowed to run sudo on map1. This incident will be reported. CLIENT: yum installed libsss_sudo I added "nisdomainname dir1.server.example.com" to /etc/rc.d/rc.local **still not sure what this is for ** Created a sudo user on ldap server ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D "cn=Directory Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com ** [root at map1 sssd]# cat /etc/nsswitch.conf # passwd: files sss shadow: files sss group: files sss sudoers: files sss sudoers_debug: 1 #sudoers: files hosts: files dns bootparams: files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: files automount: files ldap aliases: files [root at map1 sssd]# [root at map1 sssd]# cat sssd.conf [domain/server.example.com] debug_level = 5 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = server.example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = map1.server.example.com chpass_provider = ipa ipa_server = _srv_, dir1.server.example.com ldap_netgroup_search_base = cn=ng,cn=compat,dc=server,dc=example,dc=com ldap_tls_cacert = /etc/ipa/ca.crt sudo_provider = ldap ldap_uri = ldap://dir1.server.example.com ldap_sudo_search_base = ou=sudoers,dc=server,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/dir1.server.example.com ldap_sasl_realm = server.example.com krb5_server = dir1.server.example.com [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = server.example.com [nss] [pam] [sudo] debug_level=5 [autofs] [ssh] [pac] from the sssd_sudo.log (Mon Aug 25 10:36:31 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*))(&(dataExpireTimestamp<=1408962991)))] (Mon Aug 25 10:36:31 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*)))] (Mon Aug 25 10:36:33 2014) [sssd[sudo]] [client_recv] (0x0200): Client disconnected! [root at dir1 ~]# !ldaps ldapsearch -h dir1.server.example.com -x -D "cn=Directory Manager" -W -b "dc=server,dc=example,dc=com" 'objectclass=sudoRole' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: objectclass=sudoRole # requesting: ALL # # test, sudoers, server.example.com dn: cn=test,ou=sudoers,dc=server,dc=example,dc=com objectClass: sudoRole sudoUser: megan2 sudoUser: tuser2 sudoHost: map1.server.example.com sudoCommand: /sbin/iptables -L sudoCommand: /home/tuser1/test.sh sudoCommand: test2.sh cn: test # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root at dir1 ~]# ldapsearch -h dir1.server.example.com -x -D "cn=Directory Manager" -W -b "dc=server,dc=example,dc=com" 'objectclass=sudoRule' Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: objectclass=sudoRule # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 From mkosek at redhat.com Mon Aug 25 11:03:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 25 Aug 2014 13:03:28 +0200 Subject: [Freeipa-users] sudo with freeIPA In-Reply-To: References: Message-ID: <53FB1800.2020904@redhat.com> On 08/25/2014 12:51 PM, Megan . wrote: > Good Morning, > > I'm very new to freeIPA. Welcome on board! > I'm running centOS 6.5 with freeIPA v3 > > I have the freeIPA server up but i'm working on getting SUDO > configured. Currently i'm having problems getting sudo commands to > work on the client. I'm a bit unclear if i have everything configured > correctly. The only thing that I can figure out might be an issue, is > when i try the sudo command i see a filter search with > objectclass=sudoRule but when i check the ldap server it has > objectclass=sudoRole, so there are no results. According to http://www.sudo.ws/sudoers.ldap.man.html the objectclass in the schema should really read "sudoRole" (I know, may be confusing). > Any ideas? Thank you in advance for any advice. Where do you see the filter? > > [tuser2 at map1 ~]$ sudo /sbin/iptables -L > Enter RSA PIN+token: > tuser2 is not allowed to run sudo on map1. This incident will be reported. > > > CLIENT: > > yum installed libsss_sudo > > I added "nisdomainname dir1.server.example.com" to /etc/rc.d/rc.local > > **still not sure what this is for ** This is for setting the NIS domain permanently. sudo uses NIS domains when it uses sudo rules with host groups instead of individual host names. > Created a sudo user on ldap server > ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D "cn=Directory > Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com > ** > > > [root at map1 sssd]# cat /etc/nsswitch.conf > # > passwd: files sss > shadow: files sss > group: files sss > sudoers: files sss > sudoers_debug: 1 > #sudoers: files > hosts: files dns > bootparams: files > ethers: files > netmasks: files > networks: files > protocols: files > rpc: files > services: files sss > netgroup: files sss > publickey: files > automount: files ldap > aliases: files > [root at map1 sssd]# > > > > > > [root at map1 sssd]# cat sssd.conf > [domain/server.example.com] > > debug_level = 5 > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = server.example.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = map1.server.example.com > chpass_provider = ipa > ipa_server = _srv_, dir1.server.example.com > ldap_netgroup_search_base = cn=ng,cn=compat,dc=server,dc=example,dc=com > ldap_tls_cacert = /etc/ipa/ca.crt > > sudo_provider = ldap > ldap_uri = ldap://dir1.server.example.com > ldap_sudo_search_base = ou=sudoers,dc=server,dc=example,dc=com > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/dir1.server.example.com > ldap_sasl_realm = server.example.com > krb5_server = dir1.server.example.com > > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > > domains = server.example.com > [nss] > > [pam] > > [sudo] > debug_level=5 > > [autofs] > > [ssh] > > [pac] > > > > > from the sssd_sudo.log > > (Mon Aug 25 10:36:31 2014) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*))(&(dataExpireTimestamp<=1408962991)))] > (Mon Aug 25 10:36:31 2014) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*)))] > (Mon Aug 25 10:36:33 2014) [sssd[sudo]] [client_recv] (0x0200): Client > disconnected! I do not understand why it searches with "sudorule" objectclass. According to sssd-ldap man page, ldap_sudorule_object_class should default to "sudoRole". Jakub or Pavel, any idea? > [root at dir1 ~]# !ldaps > ldapsearch -h dir1.server.example.com -x -D "cn=Directory Manager" -W > -b "dc=server,dc=example,dc=com" 'objectclass=sudoRole' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: objectclass=sudoRole > # requesting: ALL > # > > # test, sudoers, server.example.com > dn: cn=test,ou=sudoers,dc=server,dc=example,dc=com > objectClass: sudoRole > sudoUser: megan2 > sudoUser: tuser2 > sudoHost: map1.server.example.com > sudoCommand: /sbin/iptables -L > sudoCommand: /home/tuser1/test.sh > sudoCommand: test2.sh > cn: test > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > [root at dir1 ~]# ldapsearch -h dir1.server.example.com -x -D > "cn=Directory Manager" -W -b "dc=server,dc=example,dc=com" > 'objectclass=sudoRule' > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: objectclass=sudoRule > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > I do not know the root cause, but Pavel or Jakub will be able to provide help. BTW, FreeIPA 4.0+ enable SUDO via SSSD's sudo provider automatically (https://fedorahosted.org/freeipa/ticket/3358). This functionality will be also available in RHEL-6.6. Martin From abokovoy at redhat.com Mon Aug 25 11:08:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 25 Aug 2014 14:08:51 +0300 Subject: [Freeipa-users] sudo with freeIPA In-Reply-To: <53FB1800.2020904@redhat.com> References: <53FB1800.2020904@redhat.com> Message-ID: <20140825110851.GJ4748@redhat.com> On Mon, 25 Aug 2014, Martin Kosek wrote: >On 08/25/2014 12:51 PM, Megan . wrote: >> Good Morning, >> >> I'm very new to freeIPA. > >Welcome on board! > >> I'm running centOS 6.5 with freeIPA v3 >> >> I have the freeIPA server up but i'm working on getting SUDO >> configured. Currently i'm having problems getting sudo commands to >> work on the client. I'm a bit unclear if i have everything configured >> correctly. The only thing that I can figure out might be an issue, is >> when i try the sudo command i see a filter search with >> objectclass=sudoRule but when i check the ldap server it has >> objectclass=sudoRole, so there are no results. > >According to >http://www.sudo.ws/sudoers.ldap.man.html > >the objectclass in the schema should really read "sudoRole" (I know, may be >confusing). > >> Any ideas? Thank you in advance for any advice. > >Where do you see the filter? > >> >> [tuser2 at map1 ~]$ sudo /sbin/iptables -L >> Enter RSA PIN+token: >> tuser2 is not allowed to run sudo on map1. This incident will be reported. >> >> >> CLIENT: >> >> yum installed libsss_sudo >> >> I added "nisdomainname dir1.server.example.com" to /etc/rc.d/rc.local >> >> **still not sure what this is for ** > >This is for setting the NIS domain permanently. sudo uses NIS domains when it >uses sudo rules with host groups instead of individual host names. > >> Created a sudo user on ldap server >> ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D "cn=Directory >> Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com >> ** >> >> >> [root at map1 sssd]# cat /etc/nsswitch.conf >> # >> passwd: files sss >> shadow: files sss >> group: files sss >> sudoers: files sss >> sudoers_debug: 1 >> #sudoers: files >> hosts: files dns >> bootparams: files >> ethers: files >> netmasks: files >> networks: files >> protocols: files >> rpc: files >> services: files sss >> netgroup: files sss >> publickey: files >> automount: files ldap >> aliases: files >> [root at map1 sssd]# >> >> >> >> >> >> [root at map1 sssd]# cat sssd.conf >> [domain/server.example.com] >> >> debug_level = 5 >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = server.example.com >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = map1.server.example.com >> chpass_provider = ipa >> ipa_server = _srv_, dir1.server.example.com >> ldap_netgroup_search_base = cn=ng,cn=compat,dc=server,dc=example,dc=com >> ldap_tls_cacert = /etc/ipa/ca.crt >> >> sudo_provider = ldap >> ldap_uri = ldap://dir1.server.example.com >> ldap_sudo_search_base = ou=sudoers,dc=server,dc=example,dc=com >> ldap_sasl_mech = GSSAPI >> ldap_sasl_authid = host/dir1.server.example.com >> ldap_sasl_realm = server.example.com >> krb5_server = dir1.server.example.com >> >> [sssd] >> services = nss, pam, ssh, sudo >> config_file_version = 2 >> >> domains = server.example.com >> [nss] >> >> [pam] >> >> [sudo] >> debug_level=5 >> >> [autofs] >> >> [ssh] >> >> [pac] >> >> >> >> >> from the sssd_sudo.log >> >> (Mon Aug 25 10:36:31 2014) [sssd[sudo]] >> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*))(&(dataExpireTimestamp<=1408962991)))] >> (Mon Aug 25 10:36:31 2014) [sssd[sudo]] >> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with >> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*)))] >> (Mon Aug 25 10:36:33 2014) [sssd[sudo]] [client_recv] (0x0200): Client >> disconnected! > >I do not understand why it searches with "sudorule" objectclass. According to >sssd-ldap man page, ldap_sudorule_object_class should default to "sudoRole". >Jakub or Pavel, any idea? It is a search against SSSD's local cache where the object class is sudoRule. A correct entry for searching against LDAP server should be in the sss_.log -- / Alexander Bokovoy From cwhittl at gmail.com Mon Aug 25 11:24:30 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Mon, 25 Aug 2014 06:24:30 -0500 Subject: [Freeipa-users] Installing a new Cert In-Reply-To: <53FAF936.9000506@redhat.com> References: <53FAF936.9000506@redhat.com> Message-ID: I have 4 installed and I get it when I try to generate the pk12 On Aug 25, 2014 3:50 AM, "Jan Cholasta" wrote: > Hi, > > Dne 25.8.2014 v 03:04 Chris Whittle napsal(a): > >> Trying to do this >> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >> >> And I keep getting "Error unable to get local issuer certificate getting >> chain." >> > > Where are you getting this error? ipa-server-certinstall, or httpd, or > somewhere else? > > What version of ipa do you have installed? > > >> I'm wondering if it's because of this from the doc >> "The certificate in mysite.crt must be signed by the CA used when >> installing FreeIPA." >> but it might not either... >> > > In this case you should get a "file.p12 is not signed by /etc/ipa/ca.crt, > or the full certificate chain is not present in the PKCS#12 file" error in > ipa-server-certinstall. > > >> Any ideas? >> >> >> > Honza > > -- > Jan Cholasta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Aug 25 11:58:41 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 Aug 2014 13:58:41 +0200 Subject: [Freeipa-users] users AD can not sudo in centos 6.5 In-Reply-To: <53FB0C0A.3010009@redhat.com> References: <53FB0C0A.3010009@redhat.com> Message-ID: <20140825115841.GD31972@hendrix.brq.redhat.com> On Mon, Aug 25, 2014 at 12:12:26PM +0200, Dmitri Pal wrote: > On 08/25/2014 12:01 PM, alireza baghery wrote: > >hi > >i integrated AD windows 208 R2 with IPA server (centos 6.5) > >i write a sudo policy and access for specified user and host with allow > >any command. > >user can execute sudo in centos 7 but when user loggin on centos 6.5 can > >not execute sudo and get error below > >user at AD is not in sudoers file. > >i configure /etc/nsswitch.conf --sudoers: file sss > >/etc/sss/sss.conf----service nss, pam,ssh,sudo > >/etc/sysconfig/network ----- NISDOMAIN=ad.com > > > > > > > > AFAIR there was a bug in 6.5 around sudo and AD users, it has been fixed in > fedora but I am not sure it made its way into all distros yet. Yes, it would be best if you could run both sudo and with more debugging enabled. For sudo logs, something like: Debug sudo /tmp/sudo_debug all at debug Should produce pretty verbose logs SSSD debug_level should be enabled in [sudo] and [domain] sections. From lslebodn at redhat.com Mon Aug 25 12:00:44 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 25 Aug 2014 14:00:44 +0200 Subject: [Freeipa-users] users AD can not sudo in centos 6.5 In-Reply-To: References: Message-ID: <20140825120044.GC8940@mail.corp.redhat.com> On (25/08/14 14:31), alireza baghery wrote: >hi >i integrated AD windows 208 R2 with IPA server (centos 6.5) >i write a sudo policy and access for specified user and host with allow any >command. >user can execute sudo in centos 7 but when user loggin on centos 6.5 can >not execute sudo and get error below >user at AD is not in sudoers file. >i configure /etc/nsswitch.conf --sudoers: file sss >/etc/sss/sss.conf----service nss, pam,ssh,sudo >/etc/sysconfig/network ----- NISDOMAIN=ad.com I would like to see your sssd.conf files. Log files wuld be helpful as well. @see slides 18-19 http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf LS From nagemnna at gmail.com Mon Aug 25 12:02:02 2014 From: nagemnna at gmail.com (Megan .) Date: Mon, 25 Aug 2014 08:02:02 -0400 Subject: [Freeipa-users] sudo with freeIPA In-Reply-To: <20140825110851.GJ4748@redhat.com> References: <53FB1800.2020904@redhat.com> <20140825110851.GJ4748@redhat.com> Message-ID: Below is the output from the sss_.log when i ran the sudo command as the user. I see things about offline replies and LDAP not working. Is this my problem or is this part of a normal series of items that are tried? (Mon Aug 25 11:53:23 2014) [sssd[be[server.example.com]]] [be_get_account_info] (0x0100): Got request for [4098][1][idnumber=1079600005] (Mon Aug 25 11:53:23 2014) [sssd[be[server.example.com]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_get_account_info] (0x0100): Got request for [3][1][name=tuser2] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): domain: server.example.com (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): user: tuser2 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): service: sudo (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): tty: /dev/pts/1 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): ruser: tuser2 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): rhost: (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): authtok type: 1 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): authtok size: 23 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): priv: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): cli_pid: 17822 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [check_for_valid_tgt] (0x0080): TGT is valid. (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [resolve_srv_send] (0x0200): The status of SRV lookup is neutral (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [resolve_srv_cont] (0x0100): Searching for servers via SRV query '_ldap._tcp.server.example.com' (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.server.example.com' (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'not working' (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'not resolved' (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup meta-server), resolver returned (5) (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_resolve_server_process] (0x0200): Found address for server dir1.server.example.com: [10.10.26.148] TTL 7200 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [krb5_find_ccache_step] (0x0080): Saved ccache FILE:/tmp/krb5cc_1079600005_Hfzpn4 if of different type than ccache in configuration file, reusing the old ccache (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [sysdb_cache_auth] (0x0100): Hashes do match! (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (1, 9, ) [Provider is Offline (Authentication service cannot retrieve authentication info)] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Sending result [9][server.example.com] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Sent result [9][server.example.com] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): domain: server.example.com (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): user: tuser2 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): service: sudo (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): tty: /dev/pts/1 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): ruser: tuser2 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): rhost: (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): priv: 0 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [pam_print_data] (0x0100): cli_pid: 17822 (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Sending result [0][server.example.com] (Mon Aug 25 11:53:24 2014) [sssd[be[server.example.com]]] [be_pam_handler_callback] (0x0100): Sent result [0][server.example.com] (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [get_port_status] (0x0100): Reseting the status of port 389 for server 'dir1.server.example.com' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [be_resolve_server_process] (0x0200): Found address for server dir1.server.example.com: [10.10.26.148] TTL 7200 (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'KERBEROS' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [be_resolve_server_process] (0x0200): Found address for server dir1.server.example.com: [10.10.26.148] TTL 7200 (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [child_sig_handler] (0x0100): child [17823] finished successfully. (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'dir1.server.example.com' as 'not working' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP' (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [sdap_sudo_periodical_first_refresh_done] (0x0040): Periodical full refresh of sudo rules failed [dp_error: 1] ([11]: Resource temporarily unavailable) (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.server.example.com], [2][No such file or directory] (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kdcinfo.server.example.com], [2][No such file or directory] (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.server.example.com], [2][No such file or directory] On Mon, Aug 25, 2014 at 7:08 AM, Alexander Bokovoy wrote: > On Mon, 25 Aug 2014, Martin Kosek wrote: >> >> On 08/25/2014 12:51 PM, Megan . wrote: >>> >>> Good Morning, >>> >>> I'm very new to freeIPA. >> >> >> Welcome on board! >> >>> I'm running centOS 6.5 with freeIPA v3 >>> >>> I have the freeIPA server up but i'm working on getting SUDO >>> configured. Currently i'm having problems getting sudo commands to >>> work on the client. I'm a bit unclear if i have everything configured >>> correctly. The only thing that I can figure out might be an issue, is >>> when i try the sudo command i see a filter search with >>> objectclass=sudoRule but when i check the ldap server it has >>> objectclass=sudoRole, so there are no results. >> >> >> According to >> http://www.sudo.ws/sudoers.ldap.man.html >> >> the objectclass in the schema should really read "sudoRole" (I know, may >> be >> confusing). >> >>> Any ideas? Thank you in advance for any advice. >> >> >> Where do you see the filter? >> >>> >>> [tuser2 at map1 ~]$ sudo /sbin/iptables -L >>> Enter RSA PIN+token: >>> tuser2 is not allowed to run sudo on map1. This incident will be >>> reported. >>> >>> >>> CLIENT: >>> >>> yum installed libsss_sudo >>> >>> I added "nisdomainname dir1.server.example.com" to /etc/rc.d/rc.local >>> >>> **still not sure what this is for ** >> >> >> This is for setting the NIS domain permanently. sudo uses NIS domains when >> it >> uses sudo rules with host groups instead of individual host names. >> >>> Created a sudo user on ldap server >>> ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D "cn=Directory >>> Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com >>> ** >>> >>> >>> [root at map1 sssd]# cat /etc/nsswitch.conf >>> # >>> passwd: files sss >>> shadow: files sss >>> group: files sss >>> sudoers: files sss >>> sudoers_debug: 1 >>> #sudoers: files >>> hosts: files dns >>> bootparams: files >>> ethers: files >>> netmasks: files >>> networks: files >>> protocols: files >>> rpc: files >>> services: files sss >>> netgroup: files sss >>> publickey: files >>> automount: files ldap >>> aliases: files >>> [root at map1 sssd]# >>> >>> >>> >>> >>> >>> [root at map1 sssd]# cat sssd.conf >>> [domain/server.example.com] >>> >>> debug_level = 5 >>> cache_credentials = True >>> krb5_store_password_if_offline = True >>> ipa_domain = server.example.com >>> id_provider = ipa >>> auth_provider = ipa >>> access_provider = ipa >>> ipa_hostname = map1.server.example.com >>> chpass_provider = ipa >>> ipa_server = _srv_, dir1.server.example.com >>> ldap_netgroup_search_base = cn=ng,cn=compat,dc=server,dc=example,dc=com >>> ldap_tls_cacert = /etc/ipa/ca.crt >>> >>> sudo_provider = ldap >>> ldap_uri = ldap://dir1.server.example.com >>> ldap_sudo_search_base = ou=sudoers,dc=server,dc=example,dc=com >>> ldap_sasl_mech = GSSAPI >>> ldap_sasl_authid = host/dir1.server.example.com >>> ldap_sasl_realm = server.example.com >>> krb5_server = dir1.server.example.com >>> >>> [sssd] >>> services = nss, pam, ssh, sudo >>> config_file_version = 2 >>> >>> domains = server.example.com >>> [nss] >>> >>> [pam] >>> >>> [sudo] >>> debug_level=5 >>> >>> [autofs] >>> >>> [ssh] >>> >>> [pac] >>> >>> >>> >>> >>> from the sssd_sudo.log >>> >>> (Mon Aug 25 10:36:31 2014) [sssd[sudo]] >>> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with >>> >>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*))(&(dataExpireTimestamp<=1408962991)))] >>> (Mon Aug 25 10:36:31 2014) [sssd[sudo]] >>> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with >>> >>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*)))] >>> (Mon Aug 25 10:36:33 2014) [sssd[sudo]] [client_recv] (0x0200): Client >>> disconnected! >> >> >> I do not understand why it searches with "sudorule" objectclass. According >> to >> sssd-ldap man page, ldap_sudorule_object_class should default to >> "sudoRole". >> Jakub or Pavel, any idea? > > It is a search against SSSD's local cache where the object class is > sudoRule. A correct entry for searching against LDAP server should be in the > sss_.log > > -- > / Alexander Bokovoy From jhrozek at redhat.com Mon Aug 25 12:11:09 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 Aug 2014 14:11:09 +0200 Subject: [Freeipa-users] sudo with freeIPA In-Reply-To: References: Message-ID: <20140825121109.GA10132@hendrix.redhat.com> On Mon, Aug 25, 2014 at 06:51:27AM -0400, Megan . wrote: > Good Morning, > > I'm very new to freeIPA. I'm running centOS 6.5 with freeIPA v3 > > I have the freeIPA server up but i'm working on getting SUDO > configured. Currently i'm having problems getting sudo commands to > work on the client. I'm a bit unclear if i have everything configured > correctly. The only thing that I can figure out might be an issue, is > when i try the sudo command i see a filter search with > objectclass=sudoRule but when i check the ldap server it has These two searches are unrelated. The sudoRule objectlass is what we use internally in sssd cache. On the LDAP side, sudoRole is used. In general, only the [domain] process works with LDAP data, all others (nss, pam, sudo, ...) work with cached data that might look totally different. > objectclass=sudoRole, so there are no results. > > Any ideas? Thank you in advance for any advice. > Can you put debug_level into the domain section as well and increase the debug_level of both to 7? > > > [tuser2 at map1 ~]$ sudo /sbin/iptables -L > Enter RSA PIN+token: > tuser2 is not allowed to run sudo on map1. This incident will be reported. > > > CLIENT: > > yum installed libsss_sudo > > I added "nisdomainname dir1.server.example.com" to /etc/rc.d/rc.local > > **still not sure what this is for ** > Created a sudo user on ldap server > ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D "cn=Directory > Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com > ** The config file looks good to me. From jhrozek at redhat.com Mon Aug 25 12:19:00 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 Aug 2014 14:19:00 +0200 Subject: [Freeipa-users] users AD can not sudo in centos 6.5 In-Reply-To: <20140825115841.GD31972@hendrix.brq.redhat.com> References: <53FB0C0A.3010009@redhat.com> <20140825115841.GD31972@hendrix.brq.redhat.com> Message-ID: <20140825121900.GD10132@hendrix.redhat.com> On Mon, Aug 25, 2014 at 01:58:41PM +0200, Jakub Hrozek wrote: > For sudo logs, something like: > Debug sudo /tmp/sudo_debug all at debug > Should produce pretty verbose logs Sorry, I should have said the Debug directive belongs to /etc/sudo.conf From jhrozek at redhat.com Mon Aug 25 12:26:49 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 Aug 2014 14:26:49 +0200 Subject: [Freeipa-users] sudo with freeIPA In-Reply-To: References: <53FB1800.2020904@redhat.com> <20140825110851.GJ4748@redhat.com> Message-ID: <20140825122649.GE10132@hendrix.redhat.com> On Mon, Aug 25, 2014 at 08:02:02AM -0400, Megan . wrote: > Below is the output from the sss_.log when i ran the sudo > command as the user. I see things about offline replies and LDAP not > working. Is this my problem or is this part of a normal series of > items that are tried? > > > (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] > [be_resolve_server_process] (0x0200): Found address for server > dir1.server.example.com: [10.10.26.148] TTL 7200 > > (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] > [child_sig_handler] (0x0100): child [17823] finished successfully. > > (Mon Aug 25 11:54:46 2014) [sssd[be[server.example.com]]] > [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] It appears your keytab is wrong. Can you run: kinit -k as root on that machine? If you prepend KRB5_TRACE you will see a lot of debugging info. From nagemnna at gmail.com Mon Aug 25 12:33:51 2014 From: nagemnna at gmail.com (Megan .) Date: Mon, 25 Aug 2014 08:33:51 -0400 Subject: [Freeipa-users] sudo with freeIPA In-Reply-To: <20140825121109.GA10132@hendrix.redhat.com> References: <20140825121109.GA10132@hendrix.redhat.com> Message-ID: ok. Changed debug_level to 7. I already it in the domain section (first line). Not sure if this makes a difference [root at map1 pam.d]# cat system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_tally2.so deny=5 auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so from sssd_sudo.log (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [accept_fd_handler] (0x0400): Client connected! (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'tuser2' matched without domain, user is tuser2 (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'tuser2' matched without domain, user is tuser2 (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting default options for [tuser2] from [] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [tuser2 at server.domain.com] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [tuser2 at server.domain.com] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving default options for [tuser2] from [server.domain.com] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*))(&(dataExpireTimestamp<=1408969900)))] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [@server.domain.com] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'tuser2' matched without domain, user is tuser2 (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'tuser2' matched without domain, user is tuser2 (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [tuser2] from [] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [tuser2 at server.domain.com] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [tuser2 at server.domain.com] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [tuser2] from [server.domain.com] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*))(&(dataExpireTimestamp<=1408969900)))] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*)))] (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [tuser2 at server.domain.com] (Mon Aug 25 12:31:42 2014) [sssd[sudo]] [client_recv] (0x0200): Client disconnected! from sssd_server.log (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_get_subdomains] (0x0400): Got get subdomains [not forced][] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_get_subdomains] (0x0400): Cannot proceed, provider is offline. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_get_subdomains] (0x1000): Request processed. Returned 1,11,Provider is offline (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_get_account_info] (0x0100): Got request for [4098][1][idnumber=1079600005] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_port_status] (0x1000): Port status of port 0 for server '(no name)' is 'neutral' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [resolve_srv_send] (0x0200): The status of SRV lookup is neutral (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [resolve_srv_send] (0x0400): SRV resolution of service 'IPA'. Will use DNS discovery domain 'server.domain.com' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [resolve_srv_cont] (0x0100): Searching for servers via SRV query '_ldap._tcp.server.domain.com' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.server.domain.com' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [request_watch_destructor] (0x0400): Deleting request watch (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'not working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as 'not resolved' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup meta-server), resolver returned (5) (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x1000): Trying with the next one! (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'name resolved' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'dir1.server.domain.com' is 'neutral' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'name resolved' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x0200): Found address for server dir1.server.domain.com: [10.10.26.148] TTL 7200 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://dir1.server.domain.com' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://dir1.server.domain.com:389/??base] with fd [25]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/map1.server.domain.com, server.domain.com, 86400) (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'name resolved' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'name resolved' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x0200): Found address for server dir1.server.domain.com: [10.10.26.148] TTL 7200 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [create_tgt_req_send_buffer] (0x1000): buffer size: 72 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_server.domain.com], expired on [1409056143] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1408970643 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/map1.server.domain.com (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [child_sig_handler] (0x1000): Waiting for child [17983]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [child_sig_handler] (0x0100): child [17983] finished successfully. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'dir1.server.domain.com' as 'working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [set_server_common_status] (0x0100): Marking server 'dir1.server.domain.com' as 'working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [cn=accounts,dc=server,dc=domain,dc=com] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(gidNumber=1079600005)(objectclass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=server,dc=domain,dc=com]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 1 results. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_save_group] (0x0400): Processing group tuser2 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_save_group] (0x1000): Original USN value is not available for [tuser2]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_process_ghost_members] (0x0400): The group has 0 members (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_process_ghost_members] (0x0400): Group has 0 members (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_save_group] (0x0400): Storing info for group tuser2 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_save_grpmem] (0x1000): No members for group [tuser2] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_save_grpmem] (0x0400): Storing members for group tuser2 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1408969743 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo rules (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_port_status] (0x1000): Port status of port 389 for server 'dir1.server.domain.com' is 'not working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_port_status] (0x0100): Reseting the status of port 389 for server 'dir1.server.domain.com' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x0200): Found address for server dir1.server.domain.com: [10.10.26.148] TTL 7200 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_uri_callback] (0x0400): Constructed uri 'ldap://dir1.server.domain.com' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://dir1.server.domain.com:389/??base] with fd [26]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/dir1.server.domain.com, server.domain.com, 86400) (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service KERBEROS (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'KERBEROS' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x0200): Found address for server dir1.server.domain.com: [10.10.26.148] TTL 7200 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [create_tgt_req_send_buffer] (0x1000): buffer size: 72 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Error writing to key table], expired on [0] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [5] result [4] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'dir1.server.domain.com' as 'not working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [get_port_status] (0x1000): Port status of port 389 for server 'dir1.server.domain.com' is 'not working' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [fo_resolve_service_send] (0x0020): No available servers for service 'LDAP' (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [child_sig_handler] (0x1000): Waiting for child [17984]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [child_sig_handler] (0x0100): child [17984] finished successfully. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_resolve_server_done] (0x1000): Server resolution failed: 5 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_sudo_periodical_first_refresh_done] (0x0040): Periodical full refresh of sudo rules failed [dp_error: 1] ([11]: Resource temporarily unavailable) (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_sudo_periodical_first_refresh_done] (0x0400): Data provider is offline. Scheduling another full refresh in 6 minutes. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1408970103 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1408969743 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo rules (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_sudo_periodical_first_refresh_done] (0x0040): Periodical full refresh of sudo rules failed [dp_error: 1] ([11]: Resource temporarily unavailable) (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_sudo_periodical_first_refresh_done] (0x0400): Data provider is offline. Scheduling another full refresh in 8 minutes. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1408970223 (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaNTTrustedDomain][cn=trusts,dc=server,dc=domain,dc=com]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTFlatName] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [objectclass=ipaIDRange][cn=ranges,cn=etc,dc=server,dc=domain,dc=com]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseID] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseRID] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSecondaryBaseRID] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaIDRangeSize] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaNTTrustedDomainSID] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sysdb_update_ranges] (0x0400): Adding range [server.domain.com_id_range]. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sysdb_range_create] (0x0040): Invalid range, expected that either the secondary base rid or the SID of the trusted domain is set, but not both or none of them. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sysdb_range_create] (0x0400): Error: 22 (Invalid argument) (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [sysdb_update_ranges] (0x0040): sysdb_range_create failed. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [ipa_subdomains_handler_ranges_done] (0x0040): sysdb_update_ranges failed. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication. (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.server.domain.com], [2][No such file or directory] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kdcinfo.server.domain.com], [2][No such file or directory] (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.server.domain.com], [2][No such file or directory] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_get_account_info] (0x0100): Got request for [3][1][name=tuser2] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): domain: server.domain.com (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): user: tuser2 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): service: sudo (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): tty: /dev/pts/1 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): ruser: tuser2 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): rhost: (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): authtok type: 1 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): authtok size: 23 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): priv: 0 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): cli_pid: 17982 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [cc_residual_is_used] (0x1000): User [1079600005] is still active, reusing ccache [/tmp/krb5cc_1079600005_Hfzpn4]. (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [check_for_valid_tgt] (0x1000): TGT end time [1409049392]. (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [check_for_valid_tgt] (0x0080): TGT is valid. (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'working' (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'dir1.server.domain.com' is 'working' (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [get_server_status] (0x1000): Status of server 'dir1.server.domain.com' is 'working' (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_resolve_server_process] (0x0200): Found address for server dir1.server.domain.com: [10.10.26.148] TTL 7200 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://dir1.server.domain.com' (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [krb5_find_ccache_step] (0x0080): Saved ccache FILE:/tmp/krb5cc_1079600005_Hfzpn4 if of different type than ccache in configuration file, reusing the old ccache (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [sysdb_cache_auth] (0x0100): Hashes do match! (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (1, 9, ) [Provider is Offline (Authentication service cannot retrieve authentication info)] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [9][server.domain.com] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [9][server.domain.com] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler] (0x0100): Got request with the following data (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): domain: server.domain.com (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): user: tuser2 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): service: sudo (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): tty: /dev/pts/1 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): ruser: tuser2 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): rhost: (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): authtok type: 0 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): authtok size: 0 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): newauthtok type: 0 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): newauthtok size: 0 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): priv: 0 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [pam_print_data] (0x0100): cli_pid: 17982 (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [sdap_access_send] (0x0400): Performing access check for user [tuser2] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user [tuser2] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [hbac_attrs_to_rule] (0x1000): Processing rule [allow_all] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [hbac_user_attrs_to_rule] (0x1000): Processing users for rule [allow_all] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule [allow_all] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [allow_all] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_all] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [hbac_eval_user_element] (0x1000): [2] groups for [tuser2] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [hbac_eval_user_element] (0x1000): Added group [ipausers] for user [tuser2] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [ipa_get_selinux_send] (0x0400): Retrieving SELinux user mapping (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [0][server.domain.com] (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [0][server.domain.com] On Mon, Aug 25, 2014 at 8:11 AM, Jakub Hrozek wrote: > On Mon, Aug 25, 2014 at 06:51:27AM -0400, Megan . wrote: >> Good Morning, >> >> I'm very new to freeIPA. I'm running centOS 6.5 with freeIPA v3 >> >> I have the freeIPA server up but i'm working on getting SUDO >> configured. Currently i'm having problems getting sudo commands to >> work on the client. I'm a bit unclear if i have everything configured >> correctly. The only thing that I can figure out might be an issue, is >> when i try the sudo command i see a filter search with >> objectclass=sudoRule but when i check the ldap server it has > > These two searches are unrelated. The sudoRule objectlass is what we use > internally in sssd cache. On the LDAP side, sudoRole is used. > > In general, only the [domain] process works with LDAP data, all others > (nss, pam, sudo, ...) work with cached data that might look totally > different. > >> objectclass=sudoRole, so there are no results. >> >> Any ideas? Thank you in advance for any advice. >> > > Can you put debug_level into the domain section as well and increase the > debug_level of both to 7? > >> >> >> [tuser2 at map1 ~]$ sudo /sbin/iptables -L >> Enter RSA PIN+token: >> tuser2 is not allowed to run sudo on map1. This incident will be reported. >> >> >> CLIENT: >> >> yum installed libsss_sudo >> >> I added "nisdomainname dir1.server.example.com" to /etc/rc.d/rc.local >> >> **still not sure what this is for ** >> Created a sudo user on ldap server >> ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D "cn=Directory >> Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com >> ** > > The config file looks good to me. > > -- > Manage your subscription for 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 yagofp8 at gmail.com Mon Aug 25 12:43:00 2014 From: yagofp8 at gmail.com (=?ISO-8859-1?Q?Yago_Fern=E1ndez_Pinilla?=) Date: Mon, 25 Aug 2014 14:43:00 +0200 Subject: [Freeipa-users] Custom kinit Message-ID: Hi, I would like to create a script in python that does the same that kinit, I don?t where to start. I have checked many examples and I guess I need to do some HTTP requests against the server, is that possible to do it using freeipa? What is the url? Thanks in advance Yago -- Yago Fern?ndez Pinilla e-mail: yagofp8 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Aug 25 13:08:24 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 Aug 2014 15:08:24 +0200 Subject: [Freeipa-users] Custom kinit In-Reply-To: References: Message-ID: <20140825130824.GI10132@hendrix.redhat.com> On Mon, Aug 25, 2014 at 02:43:00PM +0200, Yago Fern?ndez Pinilla wrote: > Hi, > > I would like to create a script in python that does the same that kinit, I > don?t where to start. Why do you need this? From yagofp8 at gmail.com Mon Aug 25 13:31:47 2014 From: yagofp8 at gmail.com (=?ISO-8859-1?Q?Yago_Fern=E1ndez_Pinilla?=) Date: Mon, 25 Aug 2014 15:31:47 +0200 Subject: [Freeipa-users] Custom kinit In-Reply-To: <20140825130824.GI10132@hendrix.redhat.com> References: <20140825130824.GI10132@hendrix.redhat.com> Message-ID: I want to integrate it in other service. Is there any good documentation about the APIs? Thanks in advance On Mon, Aug 25, 2014 at 3:08 PM, Jakub Hrozek wrote: > On Mon, Aug 25, 2014 at 02:43:00PM +0200, Yago Fern?ndez Pinilla wrote: > > Hi, > > > > I would like to create a script in python that does the same that kinit, > I > > don?t where to start. > > Why do you need this? > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -- Yago Fern?ndez Pinilla e-mail: yagofp8 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Mon Aug 25 13:45:13 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Mon, 25 Aug 2014 08:45:13 -0500 Subject: [Freeipa-users] Installing a new Cert In-Reply-To: References: <53FAF936.9000506@redhat.com> Message-ID: I found this but I think it's just IPA certs? http://www.freeipa.org/page/V4/CA_certificate_renewal Basically I want to use my existing wildcard cert for https and ldaps... I did this on my 3.3 install on CentOS but now I'm on a 4 install on Fedora Core. Any help would be more than appreciated! Thanks! On Mon, Aug 25, 2014 at 6:24 AM, Chris Whittle wrote: > I have 4 installed and I get it when I try to generate the pk12 > On Aug 25, 2014 3:50 AM, "Jan Cholasta" wrote: > >> Hi, >> >> Dne 25.8.2014 v 03:04 Chris Whittle napsal(a): >> >>> Trying to do this >>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >>> >>> And I keep getting "Error unable to get local issuer certificate getting >>> chain." >>> >> >> Where are you getting this error? ipa-server-certinstall, or httpd, or >> somewhere else? >> >> What version of ipa do you have installed? >> >> >>> I'm wondering if it's because of this from the doc >>> "The certificate in mysite.crt must be signed by the CA used when >>> installing FreeIPA." >>> but it might not either... >>> >> >> In this case you should get a "file.p12 is not signed by /etc/ipa/ca.crt, >> or the full certificate chain is not present in the PKCS#12 file" error in >> ipa-server-certinstall. >> >> >>> Any ideas? >>> >>> >>> >> Honza >> >> -- >> Jan Cholasta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Aug 25 13:49:10 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Aug 2014 09:49:10 -0400 Subject: [Freeipa-users] Custom kinit In-Reply-To: References: <20140825130824.GI10132@hendrix.redhat.com> Message-ID: <53FB3ED6.1050209@redhat.com> Yago Fern?ndez Pinilla wrote: > I want to integrate it in other service. Is there any good documentation > about the APIs? We really need more details in order to help you. The API for IPA is not documented though once you get the patterns down it is fairly straightforward. This of course is a completely separate issue of kinit in python. What release of IPA on which distro(s) are you looking at? rob > > Thanks in advance > > > On Mon, Aug 25, 2014 at 3:08 PM, Jakub Hrozek > wrote: > > On Mon, Aug 25, 2014 at 02:43:00PM +0200, Yago Fern?ndez Pinilla wrote: > > Hi, > > > > I would like to create a script in python that does the same that > kinit, I > > don?t where to start. > > Why do you need this? > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > > > > > -- > Yago Fern?ndez Pinilla > e-mail: yagofp8 at gmail.com > > > From rcritten at redhat.com Mon Aug 25 15:48:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Aug 2014 11:48:36 -0400 Subject: [Freeipa-users] Custom kinit In-Reply-To: References: <20140825130824.GI10132@hendrix.redhat.com> <53FB3ED6.1050209@redhat.com> Message-ID: <53FB5AD4.5020500@redhat.com> Yago Fern?ndez Pinilla wrote: > I'm using FreeIpa 3.3.5. And according to what I saw, using the API, > seems to be the best option. > > For the time being I just want to request tickets and check tickets. > > Is that possible? > . I'm still not sure what it is you're trying to do. It's important to remember that IPA isn't a server itself, it is a collection of services configured to work together towards a common goal (centralized identity). What we add is a management framework on top to (hopefully) make things easier. This is what our API does, helps you manage users, groups, etc. A ticket is a Kerberos concept and you would obtain it directly from the KDC. The IPA API is not involved in that case. If that is what you want to do then it involves the python-krbV package which is difficult at best to use and doesn't implement the entire Kerberos stack. You can though do the equivalent of a kinit using a keytab doing something like: import krbV from ipalib import api api.bootstrap(context='test') api.finalize() ccache_file = 'FILE:/tmp/host_ccache' krbcontext = krbV.default_context() principal = str('host/%s@%s' % (api.env.host, api.env.realm)) keytab = krbV.Keytab(name='/etc/krb5.keytab', context=krbcontext) principal = krbV.Principal(name=principal, context=krbcontext) os.environ['KRB5CCNAME'] = ccache_file ccache = krbV.CCache(name=ccache_file, context=krbcontext, primary_principal=principal) ccache.init(principal) cache.init_creds_keytab(keytab=keytab, principal=principal) You'll definitely want to do something differently with the ccache file than I'm showing here. I threw in IPA client initialization here so you could use this to prepare to do IPA API calls. rob > > > On Mon, Aug 25, 2014 at 3:49 PM, Rob Crittenden > wrote: > > Yago Fern?ndez Pinilla wrote: > > I want to integrate it in other service. Is there any good > documentation > > about the APIs? > > We really need more details in order to help you. > > The API for IPA is not documented though once you get the patterns down > it is fairly straightforward. > > This of course is a completely separate issue of kinit in python. What > release of IPA on which distro(s) are you looking at? > > rob > > > > > Thanks in advance > > > > > > On Mon, Aug 25, 2014 at 3:08 PM, Jakub Hrozek > > >> wrote: > > > > On Mon, Aug 25, 2014 at 02:43:00PM +0200, Yago Fern?ndez > Pinilla wrote: > > > Hi, > > > > > > I would like to create a script in python that does the same > that > > kinit, I > > > don?t where to start. > > > > Why do you need this? > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > > > > > > > > > -- > > Yago Fern?ndez Pinilla > > e-mail: yagofp8 at gmail.com > > > > > > > > > > > > > -- > Yago Fern?ndez Pinilla > e-mail: yagofp8 at gmail.com > From cwhittl at gmail.com Mon Aug 25 18:34:06 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Mon, 25 Aug 2014 13:34:06 -0500 Subject: [Freeipa-users] Installing a new Cert In-Reply-To: References: <53FAF936.9000506@redhat.com> Message-ID: ok I think I got it again... If anyone is looking for this here is the answer that worked for me.... 1. Here are the steps 1. http://stackoverflow.com/questions/23374894/mod-nss-with-apache-public-certificate-issue?noredirect=1#comment36504881_23374894 -- start at Convert crt file in PEM format and do that whole section completely 2. Then with the p12 from above you get do this (skip the line about generating a new one) http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP 1. If you run across the error "/etc/ipa/ca.crt contains more than one certificate" you will need to go into /etc/ipa/ca.crt, back it up and then try removing one of the certs and try ipa-server-certinstall from above again (if it doesn't work revert ca.crt to the original and then remove the other) 3. Then restart the both instances (bottom of the freeipa link) and you should be good to go. On Mon, Aug 25, 2014 at 8:45 AM, Chris Whittle wrote: > I found this but I think it's just IPA certs? > http://www.freeipa.org/page/V4/CA_certificate_renewal > > Basically I want to use my existing wildcard cert for https and ldaps... > I did this on my 3.3 install on CentOS but now I'm on a 4 install on > Fedora Core. > > Any help would be more than appreciated! > Thanks! > > > On Mon, Aug 25, 2014 at 6:24 AM, Chris Whittle wrote: > >> I have 4 installed and I get it when I try to generate the pk12 >> On Aug 25, 2014 3:50 AM, "Jan Cholasta" wrote: >> >>> Hi, >>> >>> Dne 25.8.2014 v 03:04 Chris Whittle napsal(a): >>> >>>> Trying to do this >>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >>>> >>>> And I keep getting "Error unable to get local issuer certificate getting >>>> chain." >>>> >>> >>> Where are you getting this error? ipa-server-certinstall, or httpd, or >>> somewhere else? >>> >>> What version of ipa do you have installed? >>> >>> >>>> I'm wondering if it's because of this from the doc >>>> "The certificate in mysite.crt must be signed by the CA used when >>>> installing FreeIPA." >>>> but it might not either... >>>> >>> >>> In this case you should get a "file.p12 is not signed by >>> /etc/ipa/ca.crt, or the full certificate chain is not present in the >>> PKCS#12 file" error in ipa-server-certinstall. >>> >>> >>>> Any ideas? >>>> >>>> >>>> >>> Honza >>> >>> -- >>> Jan Cholasta >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Mon Aug 25 19:02:49 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Mon, 25 Aug 2014 14:02:49 -0500 Subject: [Freeipa-users] Installing a new Cert In-Reply-To: References: <53FAF936.9000506@redhat.com> Message-ID: I spoke a little too soon... It's working fine (browser is using new cert and also ldaps is using the new cert) except when you go to the certs page on the ui. https://DOMAIN/ipa/ui/#/e/cert/search An error has occurred (IPA Error 4301: CertificateOperationError) Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error) On Mon, Aug 25, 2014 at 1:34 PM, Chris Whittle wrote: > ok I think I got it again... If anyone is looking for this here is the > answer that worked for me.... > > > 1. Here are the steps > 1. > http://stackoverflow.com/questions/23374894/mod-nss-with-apache-public-certificate-issue?noredirect=1#comment36504881_23374894 > -- start at Convert crt file in PEM format and do that whole > section completely > 2. Then with the p12 from above you get do this (skip the line > about generating a new one) > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > 1. If you run across the error "/etc/ipa/ca.crt contains more > than one certificate" you will need to go into /etc/ipa/ca.crt, back it up > and then try removing one of the certs and try ipa-server-certinstall > from above again (if it doesn't work revert ca.crt to the original and then > remove the other) > 3. Then restart the both instances (bottom of the freeipa link) and > you should be good to go. > > > On Mon, Aug 25, 2014 at 8:45 AM, Chris Whittle wrote: > >> I found this but I think it's just IPA certs? >> http://www.freeipa.org/page/V4/CA_certificate_renewal >> >> Basically I want to use my existing wildcard cert for https and ldaps... >> I did this on my 3.3 install on CentOS but now I'm on a 4 install on >> Fedora Core. >> >> Any help would be more than appreciated! >> Thanks! >> >> >> On Mon, Aug 25, 2014 at 6:24 AM, Chris Whittle wrote: >> >>> I have 4 installed and I get it when I try to generate the pk12 >>> On Aug 25, 2014 3:50 AM, "Jan Cholasta" wrote: >>> >>>> Hi, >>>> >>>> Dne 25.8.2014 v 03:04 Chris Whittle napsal(a): >>>> >>>>> Trying to do this >>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >>>>> >>>>> And I keep getting "Error unable to get local issuer certificate >>>>> getting >>>>> chain." >>>>> >>>> >>>> Where are you getting this error? ipa-server-certinstall, or httpd, or >>>> somewhere else? >>>> >>>> What version of ipa do you have installed? >>>> >>>> >>>>> I'm wondering if it's because of this from the doc >>>>> "The certificate in mysite.crt must be signed by the CA used when >>>>> installing FreeIPA." >>>>> but it might not either... >>>>> >>>> >>>> In this case you should get a "file.p12 is not signed by >>>> /etc/ipa/ca.crt, or the full certificate chain is not present in the >>>> PKCS#12 file" error in ipa-server-certinstall. >>>> >>>> >>>>> Any ideas? >>>>> >>>>> >>>>> >>>> Honza >>>> >>>> -- >>>> Jan Cholasta >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wgraboyes at cenic.org Mon Aug 25 21:54:24 2014 From: wgraboyes at cenic.org (William Graboyes) Date: Mon, 25 Aug 2014 14:54:24 -0700 Subject: [Freeipa-users] sudo with freeIPA In-Reply-To: References: <20140825121109.GA10132@hendrix.redhat.com> Message-ID: <53FBB090.6040609@cenic.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Megan, I had the same problem with CENTOS 6.5 and free-ipa. I did a ton of searching, and IIRC the conclusion was a bug in that version of sssd, I don't remember all of the details, however I do remember the work around. Create a system account (in this case I called it sudo). Create or edit the following file. /etc/sudo-ldap.conf ## BINDDN DN ## The BINDDN parameter specifies the identity, in the form of a Dis‐ ## tinguished Name (DN), to use when performing LDAP operations. If ## not specified, LDAP operations are performed with an anonymous ## identity. By default, most LDAP servers will allow anonymous ## access. ## binddn uid=sudo,cn=sysaccounts,cn=etc,dc=domain,dc=com ## BINDPW secret ## The BINDPW parameter specifies the password to use when performing ## LDAP operations. This is typically used in conjunction with the ## BINDDN parameter. ## bindpw ${obfusticated} ## SSL start_tls ## If the SSL parameter is set to start_tls, the LDAP server connec‐ ## tion is initiated normally and TLS encryption is begun before the ## bind credentials are sent. This has the advantage of not requiring ## a dedicated port for encrypted communications. This parameter is ## only supported by LDAP servers that honor the start_tls extension, ## such as the OpenLDAP and Tivoli Directory servers. ## ssl start_tls ## TLS_CACERTFILE file name ## The path to a certificate authority bundle which contains the cer‐ ## tificates for all the Certificate Authorities the client knows to ## be valid, e.g. /etc/ssl/ca-bundle.pem. This option is only sup‐ ## ported by the OpenLDAP libraries. Netscape-derived LDAP libraries ## use the same certificate database for CA and client certificates ## (see TLS_CERT). ## tls_cacertfile /etc/ipa/ca.crt ## TLS_CHECKPEER on/true/yes/off/false/no ## If enabled, TLS_CHECKPEER will cause the LDAP server's TLS certifi‐ ## cated to be verified. If the server's TLS certificate cannot be ## verified (usually because it is signed by an unknown certificate ## authority), sudo will be unable to connect to it. If TLS_CHECKPEER ## is disabled, no check is made. Note that disabling the check cre‐ ## ates an opportunity for man-in-the-middle attacks since the ## server's identity will not be authenticated. If possible, the CA's ## certificate should be installed locally so it can be verified. ## This option is not supported by the Tivoli Directory Server LDAP ## libraries. tls_checkpeer yes ## ## URI ldap[s]://[hostname[:port]] ... ## Specifies a whitespace-delimited list of one or more ## URIs describing the LDAP server(s) to connect to. ## uri ldap://freeipaserver1 ldap://freeipaserver2 ## ## SUDOERS_BASE base ## The base DN to use when performing sudo LDAP queries. ## Multiple SUDOERS_BASE lines may be specified, in which ## case they are queried in the order specified. ## sudoers_base ou=sudoers,dc=domain,dc=com ## ## BIND_TIMELIMIT seconds ## The BIND_TIMELIMIT parameter specifies the amount of ## time to wait while trying to connect to an LDAP server. ## #bind_timelimit 30 ## ## TIMELIMIT seconds ## The TIMELIMIT parameter specifies the amount of time ## to wait for a response to an LDAP query. ## #timelimit 30 ## ## SUDOERS_DEBUG debug_level ## This sets the debug level for sudo LDAP queries. Debugging ## information is printed to the standard error. A value of 1 ## results in a moderate amount of debugging information. ## A value of 2 shows the results of the matches themselves. ## sudoers_debug 0 And your nsswitch.conf change the sudoers line to: sudoers: files ldap sss On a side note the setting the nisdomain parameter in rc.local is a hack at best. This should be set, on a Red Hat based system (RHEL, CENTOS, etc), in /etc/sysconfig/network. And should look like NISDOMAIN=your.domain.here. The professionals may say otherwise on switching to ldap based auth/sudo access, and I will learn something. At least this gets you up and running until an actual solution is found. As I stated earlier, I believe I had found a bug report on this, I am just having a hard time finding it again. Thanks, Bill On Mon Aug 25 05:33:51 2014, Megan . wrote: > ok. Changed debug_level to 7. I already it in the domain section (first line). > > > > Not sure if this makes a difference > > [root at map1 pam.d]# cat system-auth > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required pam_env.so > auth required pam_tally2.so deny=5 > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_sss.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so broken_shadow > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > password requisite pam_cracklib.so try_first_pass retry=3 > minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 > password sufficient pam_unix.so sha512 shadow nullok > try_first_pass use_authtok > password sufficient pam_sss.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > session optional pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0077 > session [success=1 default=ignore] pam_succeed_if.so service in > crond quiet use_uid > session required pam_unix.so > session optional pam_sss.so > > > > > > from sssd_sudo.log > > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [accept_fd_handler] (0x0400): > Client connected! > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_cmd_get_version] > (0x0200): Received client version [1]. > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_cmd_get_version] > (0x0200): Offered version [1]. > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] > (0x0200): name 'tuser2' matched without domain, user is tuser2 > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] > (0x0200): using default domain [(null)] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] > (0x0200): name 'tuser2' matched without domain, user is tuser2 > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] > (0x0200): using default domain [(null)] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] > (0x0200): Requesting default options for [tuser2] from [] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): > Requesting info about [tuser2 at server.domain.com] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): > Returning info for user [tuser2 at server.domain.com] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): > Retrieving default options for [tuser2] from [server.domain.com] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*))(&(dataExpireTimestamp<=1408969900)))] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(name=defaults)))] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] > [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for > [@server.domain.com] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] > (0x0200): name 'tuser2' matched without domain, user is tuser2 > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] > (0x0200): using default domain [(null)] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] > (0x0200): name 'tuser2' matched without domain, user is tuser2 > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sss_parse_name_for_domains] > (0x0200): using default domain [(null)] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] > (0x0200): Requesting rules for [tuser2] from [] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): > Requesting info about [tuser2 at server.domain.com] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): > Returning info for user [tuser2 at server.domain.com] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): > Retrieving rules for [tuser2] from [server.domain.com] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*))(&(dataExpireTimestamp<=1408969900)))] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] > [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with > [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=tuser2)(sudoUser=#1079600005)(sudoUser=%tuser2)(sudoUser=+*)))] > (Mon Aug 25 12:31:40 2014) [sssd[sudo]] > [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for > [tuser2 at server.domain.com] > (Mon Aug 25 12:31:42 2014) [sssd[sudo]] [client_recv] (0x0200): Client > disconnected! > > > > > > > > > from sssd_server.log > > > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_get_subdomains] (0x0400): Got get subdomains [not forced][] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_get_subdomains] (0x0400): Cannot proceed, provider is offline. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_get_subdomains] (0x1000): Request processed. Returned > 1,11,Provider is offline > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_get_account_info] (0x0100): Got request for > [4098][1][idnumber=1079600005] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast > reply - offline > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_port_status] (0x1000): Port status of port 0 for server '(no > name)' is 'neutral' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [resolve_srv_send] (0x0200): The status of SRV lookup is neutral > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [resolve_srv_send] (0x0400): SRV resolution of service 'IPA'. Will use > DNS discovery domain 'server.domain.com' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [resolve_srv_cont] (0x0100): Searching for servers via SRV query > '_ldap._tcp.server.domain.com' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of > '_ldap._tcp.server.domain.com' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [request_watch_destructor] (0x0400): Deleting request watch > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as > 'not working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [set_srv_data_status] (0x0100): Marking SRV lookup of service 'IPA' as > 'not resolved' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x0080): Couldn't resolve server (SRV > lookup meta-server), resolver returned (5) > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x1000): Trying with the next one! > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'name resolved' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_port_status] (0x1000): Port status of port 0 for server > 'dir1.server.domain.com' is 'neutral' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'name resolved' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x1000): Saving the first resolved server > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x0200): Found address for server > dir1.server.domain.com: [10.10.26.148] TTL 7200 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [ipa_resolve_callback] (0x0400): Constructed uri > 'ldap://dir1.server.domain.com' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for > connecting > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to > [ldap://dir1.server.domain.com:389/??base] with fd [25]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [(objectclass=*)][]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [namingContexts] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedControl] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedExtension] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedFeatures] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedLDAPVersion] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedSASLMechanisms] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [domainControllerFunctionality] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [defaultNamingContext] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [highestCommittedUSN] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no > errmsg set > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_kinit_send] (0x0400): Attempting kinit (default, > host/map1.server.domain.com, server.domain.com, 86400) > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'name resolved' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'name resolved' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x1000): Saving the first resolved server > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x0200): Found address for server > dir1.server.domain.com: [10.10.26.148] TTL 7200 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get > TGT... > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [create_tgt_req_send_buffer] (0x1000): buffer size: 72 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt > child > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [write_pipe_handler] (0x0400): All data has been sent! > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [read_pipe_handler] (0x0400): EOF received, client finished > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_tgt_recv] (0x0400): Child responded: 0 > [FILE:/var/lib/sss/db/ccache_server.domain.com], expired on > [1409056143] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_cli_auth_step] (0x0100): expire timeout is 900 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_cli_auth_step] (0x1000): the connection will expire at > 1408970643 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: > host/map1.server.domain.com > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [child_sig_handler] (0x1000): Waiting for child [17983]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [child_sig_handler] (0x0100): child [17983] finished successfully. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [fo_set_port_status] (0x0100): Marking port 0 of server > 'dir1.server.domain.com' as 'working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [set_server_common_status] (0x0100): Marking server > 'dir1.server.domain.com' as 'working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_groups_next_base] (0x0400): Searching for groups with base > [cn=accounts,dc=server,dc=domain,dc=com] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [(&(gidNumber=1079600005)(objectclass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=server,dc=domain,dc=com]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [modifyTimestamp] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_run_online_cb] (0x0080): Going online. Running callbacks. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no > errmsg set > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_groups_process] (0x0400): Search for groups, returned 1 > results. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_has_deref_support] (0x0400): The server supports deref method > OpenLDAP > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_save_group] (0x0400): Processing group tuser2 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_save_group] (0x1000): Original USN value is not available for > [tuser2]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_process_ghost_members] (0x0400): The group has 0 members > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_process_ghost_members] (0x0400): Group has 0 members > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_save_group] (0x0400): Storing info for group tuser2 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_save_grpmem] (0x1000): No members for group [tuser2] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_save_grpmem] (0x0400): Storing members for group tuser2 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: > 1408969743 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo > rules > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_port_status] (0x1000): Port status of port 389 for server > 'dir1.server.domain.com' is 'not working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_port_status] (0x0100): Reseting the status of port 389 for server > 'dir1.server.domain.com' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x1000): Saving the first resolved server > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x0200): Found address for server > dir1.server.domain.com: [10.10.26.148] TTL 7200 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_uri_callback] (0x0400): Constructed uri > 'ldap://dir1.server.domain.com' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for > connecting > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to > [ldap://dir1.server.domain.com:389/??base] with fd [26]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [(objectclass=*)][]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [namingContexts] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedControl] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedExtension] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedFeatures] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedLDAPVersion] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedSASLMechanisms] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [domainControllerFunctionality] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [defaultNamingContext] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [highestCommittedUSN] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no > errmsg set > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_kinit_send] (0x0400): Attempting kinit (default, > host/dir1.server.domain.com, server.domain.com, 86400) > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service > KERBEROS > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service > 'KERBEROS' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x1000): Saving the first resolved server > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x0200): Found address for server > dir1.server.domain.com: [10.10.26.148] TTL 7200 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get > TGT... > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [create_tgt_req_send_buffer] (0x1000): buffer size: 72 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt > child > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [write_pipe_handler] (0x0400): All data has been sent! > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [read_pipe_handler] (0x0400): EOF received, client finished > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Error writing to > key table], expired on [0] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [5] result [4] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [fo_set_port_status] (0x0100): Marking port 389 of server > 'dir1.server.domain.com' as 'not working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [get_port_status] (0x1000): Port status of port 389 for server > 'dir1.server.domain.com' is 'not working' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [fo_resolve_service_send] (0x0020): No available servers for service > 'LDAP' > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [child_sig_handler] (0x1000): Waiting for child [17984]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [child_sig_handler] (0x0100): child [17984] finished successfully. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_done] (0x1000): Server resolution failed: 5 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline > (5 [Input/output error]) > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [be_run_offline_cb] (0x0080): Going offline. Running callbacks. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_sudo_periodical_first_refresh_done] (0x0040): Periodical full > refresh of sudo rules failed [dp_error: 1] ([11]: Resource temporarily > unavailable) > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_sudo_periodical_first_refresh_done] (0x0400): Data provider is > offline. Scheduling another full refresh in 6 minutes. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: > 1408970103 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: > 1408969743 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo > rules > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_sudo_periodical_first_refresh_done] (0x0040): Periodical full > refresh of sudo rules failed [dp_error: 1] ([11]: Resource temporarily > unavailable) > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_sudo_periodical_first_refresh_done] (0x0400): Data provider is > offline. Scheduling another full refresh in 8 minutes. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: > 1408970223 > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [objectclass=ipaNTTrustedDomain][cn=trusts,dc=server,dc=domain,dc=com]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [ipaNTFlatName] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [ipaNTTrustedDomainSID] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no > errmsg set > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [objectclass=ipaIDRange][cn=ranges,cn=etc,dc=server,dc=domain,dc=com]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseID] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaBaseRID] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [ipaSecondaryBaseRID] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [ipaIDRangeSize] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [ipaNTTrustedDomainSID] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no > errmsg set > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sysdb_update_ranges] (0x0400): Adding range > [server.domain.com_id_range]. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sysdb_range_create] (0x0040): Invalid range, expected that either the > secondary base rid or the SID of the trusted domain is set, but not > both or none of them. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sysdb_range_create] (0x0400): Error: 22 (Invalid argument) > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [sysdb_update_ranges] (0x0040): sysdb_range_create failed. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [ipa_subdomains_handler_ranges_done] (0x0040): sysdb_update_ranges > failed. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [delayed_online_authentication_callback] (0x0200): Backend is online, > starting delayed online authentication. > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [remove_krb5_info_files] (0x0200): Could not remove > [/var/lib/sss/pubconf/kpasswdinfo.server.domain.com], [2][No such file > or directory] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [remove_krb5_info_files] (0x0200): Could not remove > [/var/lib/sss/pubconf/kdcinfo.server.domain.com], [2][No such file or > directory] > > (Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] > [remove_krb5_info_files] (0x0200): Could not remove > [/var/lib/sss/pubconf/kpasswdinfo.server.domain.com], [2][No such file > or directory] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_get_account_info] (0x0100): Got request for [3][1][name=tuser2] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_pam_handler] (0x0100): Got request with the following data > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): command: PAM_AUTHENTICATE > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): domain: server.domain.com > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): user: tuser2 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): service: sudo > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): tty: /dev/pts/1 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): ruser: tuser2 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): rhost: > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): authtok type: 1 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): authtok size: 23 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): newauthtok type: 0 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): newauthtok size: 0 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): priv: 0 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): cli_pid: 17982 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [cc_residual_is_used] (0x1000): User [1079600005] is still active, > reusing ccache [/tmp/krb5cc_1079600005_Hfzpn4]. > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [check_for_valid_tgt] (0x1000): TGT end time [1409049392]. > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [check_for_valid_tgt] (0x0080): TGT is valid. > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'working' > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [get_port_status] (0x1000): Port status of port 0 for server > 'dir1.server.domain.com' is 'working' > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [get_server_status] (0x1000): Status of server > 'dir1.server.domain.com' is 'working' > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x1000): Saving the first resolved server > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_resolve_server_process] (0x0200): Found address for server > dir1.server.domain.com: [10.10.26.148] TTL 7200 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [ipa_resolve_callback] (0x0400): Constructed uri > 'ldap://dir1.server.domain.com' > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [krb5_find_ccache_step] (0x0080): Saved ccache > FILE:/tmp/krb5cc_1079600005_Hfzpn4 if of different type than ccache in > configuration file, reusing the old ccache > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [sysdb_cache_auth] (0x0100): Hashes do match! > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_pam_handler_callback] (0x0100): Backend returned: (1, 9, ) > [Provider is Offline (Authentication service cannot retrieve > authentication info)] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_pam_handler_callback] (0x0100): Sending result > [9][server.domain.com] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_pam_handler_callback] (0x0100): Sent result [9][server.domain.com] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_pam_handler] (0x0100): Got request with the following data > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): command: PAM_ACCT_MGMT > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): domain: server.domain.com > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): user: tuser2 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): service: sudo > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): tty: /dev/pts/1 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): ruser: tuser2 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): rhost: > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): authtok type: 0 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): authtok size: 0 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): newauthtok type: 0 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): newauthtok size: 0 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): priv: 0 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [pam_print_data] (0x0100): cli_pid: 17982 > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [sdap_access_send] (0x0400): Performing access check for user [tuser2] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for > user [tuser2] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [hbac_attrs_to_rule] (0x1000): Processing rule [allow_all] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [hbac_user_attrs_to_rule] (0x1000): Processing users for rule > [allow_all] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [hbac_get_category] (0x0200): Category is set to 'all'. > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [hbac_service_attrs_to_rule] (0x1000): Processing PAM services for > rule [allow_all] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [hbac_get_category] (0x0200): Category is set to 'all'. > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule > [allow_all] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [hbac_get_category] (0x0200): Category is set to 'all'. > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule > [allow_all] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [hbac_eval_user_element] (0x1000): [2] groups for [tuser2] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [hbac_eval_user_element] (0x1000): Added group [ipausers] for user > [tuser2] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule > [allow_all] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) > [Success] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [ipa_get_selinux_send] (0x0400): Retrieving SELinux user mapping > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) > [Success] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_pam_handler_callback] (0x0100): Sending result > [0][server.domain.com] > > (Mon Aug 25 12:29:10 2014) [sssd[be[server.domain.com]]] > [be_pam_handler_callback] (0x0100): Sent result [0][server.domain.com] > > On Mon, Aug 25, 2014 at 8:11 AM, Jakub Hrozek wrote: >> On Mon, Aug 25, 2014 at 06:51:27AM -0400, Megan . wrote: >>> Good Morning, >>> >>> I'm very new to freeIPA. I'm running centOS 6.5 with freeIPA v3 >>> >>> I have the freeIPA server up but i'm working on getting SUDO >>> configured. Currently i'm having problems getting sudo commands to >>> work on the client. I'm a bit unclear if i have everything configured >>> correctly. The only thing that I can figure out might be an issue, is >>> when i try the sudo command i see a filter search with >>> objectclass=sudoRule but when i check the ldap server it has >> >> These two searches are unrelated. The sudoRule objectlass is what we use >> internally in sssd cache. On the LDAP side, sudoRole is used. >> >> In general, only the [domain] process works with LDAP data, all others >> (nss, pam, sudo, ...) work with cached data that might look totally >> different. >> >>> objectclass=sudoRole, so there are no results. >>> >>> Any ideas? Thank you in advance for any advice. >>> >> >> Can you put debug_level into the domain section as well and increase the >> debug_level of both to 7? >> >>> >>> >>> [tuser2 at map1 ~]$ sudo /sbin/iptables -L >>> Enter RSA PIN+token: >>> tuser2 is not allowed to run sudo on map1. This incident will be reported. >>> >>> >>> CLIENT: >>> >>> yum installed libsss_sudo >>> >>> I added "nisdomainname dir1.server.example.com" to /etc/rc.d/rc.local >>> >>> **still not sure what this is for ** >>> Created a sudo user on ldap server >>> ldappasswd -x -S -W -h dir1.server.example.com -ZZ -D "cn=Directory >>> Manager" uid=sudo,cn=sysaccounts,cn=etc,dc=server,dc=example,dc=com >>> ** >> >> The config file looks good to me. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go To http://freeipa.org for more info on the project > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJT+7CQAAoJEJFMz73A1+zrdHkP/Rn9S3Wl3pfqFQ94EvrXgoVd v3zEgJvlcQJIV2cqByLYIJjGhk9rIco6qalr1CjE2YRFgbCuOCKZ9p/tQ91sNiIh jI3NX1Co2lxUVPuIWXjXT2Q0TzrU0Dw0nz+NWgr3Ucb5J5O42Jp15itctoyC585e REmbzkxKKgMb8Db38+xTWBGLs96uC6TkAcd1gqS03227dCxWSoNkdxAzwk1AM0ug KE2g+drPGxTCQbHHhbXfGtMMR/rM35H/l7J0sIu9IU/zPeKpJ0kIgp6z4X/sFMEm ZMce/zSpo67zHs5PLjtjAb5GUCNlM5r80faVcTW0A/s4Vm9ILNFszjvX4BKxdPU0 vqk5AU+m3SfY08h7cLZVV+i1hwmhJJ3yZf/Jzm1X6Ia6UjzQLQjQtbJ1tpKz/hAn EBipEEuoJpupYzOb/YnpXvIuOLCh7ovPzQ0t8e3WOKDMY0v8MFfiB9SsU4rC66Z1 WkoOUKLL+XLWKTPwAxe0SZs+4rLSSZRvoGpe7R63I/YjjYNVeB7KpHuNEdwmRZpi Z58Xv5Foj1niggr+cqPp6cf5nBo+vM0AnWkGW/7pgaEU0slHPMDc6VPSesqPVGOk KxiCeXwyaP2DTEEpadwA+dZW8VGoGaDoEq3mSLAlx3F9wRZvosaoL6d4vzO+Ezs+ nQURME5XMxJ8nuxr4jwX =dZHC -----END PGP SIGNATURE----- From Dennis.Ott at mckesson.com Mon Aug 25 22:26:18 2014 From: Dennis.Ott at mckesson.com (Ott, Dennis) Date: Mon, 25 Aug 2014 22:26:18 +0000 Subject: [Freeipa-users] Cert Renewal Message-ID: I have an IPA setup, one master, one replica; originally installed as v 2.x and later updated to v 3.0. For whatever reasons, the certs did not automatically renew and the services would no longer start. I updated the certs manually on the master using the procedure shown at: http://www.freeipa.org/page/IPA_2x_Certificate_Renewal The master is now functioning properly. At this point, the IPA service is still stopped on the replica. I hesitate to start it for concern it could interfere with the now-working master. What would be the recommended method for returning the replica to service? Thanks for your help. Dennis -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Aug 25 22:36:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 25 Aug 2014 18:36:36 -0400 Subject: [Freeipa-users] Cert Renewal In-Reply-To: References: Message-ID: <53FBBA74.2040807@redhat.com> Ott, Dennis wrote: > I have an IPA setup, one master, one replica; originally installed as v > 2.x and later updated to v 3.0. For whatever reasons, the certs did not > automatically renew and the services would no longer start. I updated > the certs manually on the master using the procedure shown at: > > > > http://www.freeipa.org/page/IPA_2x_Certificate_Renewal > > > > The master is now functioning properly. > > > > > > At this point, the IPA service is still stopped on the replica. I > hesitate to start it for concern it could interfere with the now-working > master. > > > > What would be the recommended method for returning the replica to service? It depends on whether the replica. Does it also run a CA? If not then you can try restarting the certmonger service. This should cause it to fetch new certificates for the other IPA servers. ipa-getcert list will show you the status, wait until they are all MONITORING. Once that works then you can safely restart the world. Any changes on the master will be replicated out, and vice versa. rob From cwhittl at gmail.com Tue Aug 26 02:22:41 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Mon, 25 Aug 2014 21:22:41 -0500 Subject: [Freeipa-users] Fedora Core IPTables or FirewallID? Message-ID: I've got my server up and running great with one exception every time I reboot I have to login and flush the iptables or nothing can connect. I've found a ton of fixes and none seem to work, I'm on FC20 does anyone have experience with it and wouldn't mind helping? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Tue Aug 26 06:34:51 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 26 Aug 2014 08:34:51 +0200 Subject: [Freeipa-users] sudo with freeIPA In-Reply-To: References: <20140825121109.GA10132@hendrix.redhat.com> Message-ID: <20140826063450.GA18786@mail.corp.redhat.com> On (25/08/14 08:33), Megan . wrote: >ok. Changed debug_level to 7. I already it in the domain section (first line). > > > >Not sure if this makes a difference > >[root at map1 pam.d]# cat system-auth >#%PAM-1.0 ># This file is auto-generated. ># User changes will be destroyed the next time authconfig is run. >auth required pam_env.so >auth required pam_tally2.so deny=5 >auth sufficient pam_unix.so nullok try_first_pass >auth requisite pam_succeed_if.so uid >= 500 quiet >auth sufficient pam_sss.so use_first_pass >auth required pam_deny.so > >account required pam_unix.so broken_shadow >account sufficient pam_succeed_if.so uid < 500 quiet >account [default=bad success=ok user_unknown=ignore] pam_sss.so >account required pam_permit.so > >password requisite pam_cracklib.so try_first_pass retry=3 >minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 >password sufficient pam_unix.so sha512 shadow nullok >try_first_pass use_authtok >password sufficient pam_sss.so use_authtok >password required pam_deny.so > >session optional pam_keyinit.so revoke >session required pam_limits.so >session optional pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0077 >session [success=1 default=ignore] pam_succeed_if.so service in >crond quiet use_uid >session required pam_unix.so >session optional pam_sss.so > > >from sssd_server.log > > > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[be_get_subdomains] (0x0400): Got get subdomains [not forced][] > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[be_get_subdomains] (0x0400): Cannot proceed, provider is offline. > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[be_get_subdomains] (0x1000): Request processed. Returned >1,11,Provider is offline > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[be_get_account_info] (0x0100): Got request for >[4098][1][idnumber=1079600005] > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast >reply - offline SSSD was in offline mode, sudo rules were not downloaded yet. This is a reason why sudo doesn't work for you. > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[get_port_status] (0x1000): Port status of port 0 for server '(no >name)' is 'neutral' > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[resolve_srv_send] (0x0200): The status of SRV lookup is neutral > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[resolve_srv_send] (0x0400): SRV resolution of service 'IPA'. Will use >DNS discovery domain 'server.domain.com' > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[resolve_srv_cont] (0x0100): Searching for servers via SRV query >'_ldap._tcp.server.domain.com' > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[resolv_getsrv_send] (0x0100): Trying to resolve SRV record of >'_ldap._tcp.server.domain.com' > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[request_watch_destructor] (0x0400): Deleting request watch > >(Mon Aug 25 12:29:03 2014) [sssd[be[server.domain.com]]] >[resolve_srv_done] (0x0020): SRV query failed: [Domain name not found] > SSSD was not able reo resolv SRV records. There are two explanations: a) you did not install ipa server wit dns (ipaserver-install --setup-dns) b) you don't have ip addres of IPA server in /etc/resolv.conf If you fix this problem, sudo should work. You can test resolving SRV records from command line dig SRV _ldap._tcp.server.domain.com LS From lslebodn at redhat.com Tue Aug 26 06:37:35 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 26 Aug 2014 08:37:35 +0200 Subject: [Freeipa-users] sudo with freeIPA In-Reply-To: <53FBB090.6040609@cenic.org> References: <20140825121109.GA10132@hendrix.redhat.com> <53FBB090.6040609@cenic.org> Message-ID: <20140826063735.GB18786@mail.corp.redhat.com> On (25/08/14 14:54), William Graboyes wrote: >Hi Megan, > >I had the same problem with CENTOS 6.5 and free-ipa. I did a ton of >searching, and IIRC the conclusion was a bug in that version of sssd, I >don't remember all of the details, however I do remember the work >around. > >Create a system account (in this case I called it sudo). > >Create or edit the following file. > >/etc/sudo-ldap.conf > You are using different program for downloading sudo rules from LDAP server. I don't want to say that configuring sudo with with IPA server on CentOS 6.5 is easy, but it is possible. LS From jhrozek at redhat.com Tue Aug 26 06:42:09 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 26 Aug 2014 08:42:09 +0200 Subject: [Freeipa-users] sudo with freeIPA In-Reply-To: <53FBB090.6040609@cenic.org> References: <20140825121109.GA10132@hendrix.redhat.com> <53FBB090.6040609@cenic.org> Message-ID: <81548790-AEB0-49C5-AC1A-3307D3CABAC2@redhat.com> On 25 Aug 2014, at 23:54, William Graboyes wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Megan, > > I had the same problem with CENTOS 6.5 and free-ipa. Megan had a different problem. We were able to get to the root cause in an off-list discussion, the ldap_sasl_authid parameter was set up wrongly. From yagofp8 at gmail.com Tue Aug 26 07:37:52 2014 From: yagofp8 at gmail.com (=?ISO-8859-1?Q?Yago_Fern=E1ndez_Pinilla?=) Date: Tue, 26 Aug 2014 09:37:52 +0200 Subject: [Freeipa-users] Custom kinit In-Reply-To: <53FB5AD4.5020500@redhat.com> References: <20140825130824.GI10132@hendrix.redhat.com> <53FB3ED6.1050209@redhat.com> <53FB5AD4.5020500@redhat.com> Message-ID: Thanks for the info! I will work more on this and comment my progress On Mon, Aug 25, 2014 at 5:48 PM, Rob Crittenden wrote: > Yago Fern?ndez Pinilla wrote: > > I'm using FreeIpa 3.3.5. And according to what I saw, using the API, > > seems to be the best option. > > > > For the time being I just want to request tickets and check tickets. > > > > Is that possible? > > . > > I'm still not sure what it is you're trying to do. > > It's important to remember that IPA isn't a server itself, it is a > collection of services configured to work together towards a common goal > (centralized identity). What we add is a management framework on top to > (hopefully) make things easier. This is what our API does, helps you > manage users, groups, etc. > > A ticket is a Kerberos concept and you would obtain it directly from the > KDC. The IPA API is not involved in that case. > > If that is what you want to do then it involves the python-krbV package > which is difficult at best to use and doesn't implement the entire > Kerberos stack. You can though do the equivalent of a kinit using a > keytab doing something like: > > import krbV > from ipalib import api > > api.bootstrap(context='test') > api.finalize() > > ccache_file = 'FILE:/tmp/host_ccache' > krbcontext = krbV.default_context() > principal = str('host/%s@%s' % (api.env.host, api.env.realm)) > keytab = krbV.Keytab(name='/etc/krb5.keytab', context=krbcontext) > principal = krbV.Principal(name=principal, context=krbcontext) > os.environ['KRB5CCNAME'] = ccache_file > ccache = krbV.CCache(name=ccache_file, context=krbcontext, > primary_principal=principal) > ccache.init(principal) > cache.init_creds_keytab(keytab=keytab, principal=principal) > > You'll definitely want to do something differently with the ccache file > than I'm showing here. > > I threw in IPA client initialization here so you could use this to > prepare to do IPA API calls. > > rob > > > > > > > On Mon, Aug 25, 2014 at 3:49 PM, Rob Crittenden > > wrote: > > > > Yago Fern?ndez Pinilla wrote: > > > I want to integrate it in other service. Is there any good > > documentation > > > about the APIs? > > > > We really need more details in order to help you. > > > > The API for IPA is not documented though once you get the patterns > down > > it is fairly straightforward. > > > > This of course is a completely separate issue of kinit in python. > What > > release of IPA on which distro(s) are you looking at? > > > > rob > > > > > > > > Thanks in advance > > > > > > > > > On Mon, Aug 25, 2014 at 3:08 PM, Jakub Hrozek > > > > >> wrote: > > > > > > On Mon, Aug 25, 2014 at 02:43:00PM +0200, Yago Fern?ndez > > Pinilla wrote: > > > > Hi, > > > > > > > > I would like to create a script in python that does the same > > that > > > kinit, I > > > > don?t where to start. > > > > > > Why do you need this? > > > > > > -- > > > Manage your subscription for the Freeipa-users mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go To http://freeipa.org for more info on the project > > > > > > > > > > > > > > > -- > > > Yago Fern?ndez Pinilla > > > e-mail: yagofp8 at gmail.com > > > > > > > > > > > > > > > > > > > > > > -- > > Yago Fern?ndez Pinilla > > e-mail: yagofp8 at gmail.com > > > > -- Yago Fern?ndez Pinilla e-mail: yagofp8 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From yagofp8 at gmail.com Tue Aug 26 09:43:20 2014 From: yagofp8 at gmail.com (=?ISO-8859-1?Q?Yago_Fern=E1ndez_Pinilla?=) Date: Tue, 26 Aug 2014 11:43:20 +0200 Subject: [Freeipa-users] Custom kinit In-Reply-To: References: <20140825130824.GI10132@hendrix.redhat.com> <53FB3ED6.1050209@redhat.com> <53FB5AD4.5020500@redhat.com> Message-ID: I have checked what you told me. What I would like to do is: having a user and a password, authenticate against the kerberos server using a python script (not using kinit) and then be able to access to the ticket that is returned back by kerberos. User -----> Service ------> Kerberos The user sends user and password the first time to authenticate and then the ticket. I know that this can look a bit weird but in the environment that I'm working on i need this. Any idea how can I do this? I have checked many libraries in Python but they don't seem like having what i need. Thanks in advance Yago On Tue, Aug 26, 2014 at 9:37 AM, Yago Fern?ndez Pinilla wrote: > Thanks for the info! > > I will work more on this and comment my progress > > > > On Mon, Aug 25, 2014 at 5:48 PM, Rob Crittenden > wrote: > >> Yago Fern?ndez Pinilla wrote: >> > I'm using FreeIpa 3.3.5. And according to what I saw, using the API, >> > seems to be the best option. >> > >> > For the time being I just want to request tickets and check tickets. >> > >> > Is that possible? >> > . >> >> I'm still not sure what it is you're trying to do. >> >> It's important to remember that IPA isn't a server itself, it is a >> collection of services configured to work together towards a common goal >> (centralized identity). What we add is a management framework on top to >> (hopefully) make things easier. This is what our API does, helps you >> manage users, groups, etc. >> >> A ticket is a Kerberos concept and you would obtain it directly from the >> KDC. The IPA API is not involved in that case. >> >> If that is what you want to do then it involves the python-krbV package >> which is difficult at best to use and doesn't implement the entire >> Kerberos stack. You can though do the equivalent of a kinit using a >> keytab doing something like: >> >> import krbV >> from ipalib import api >> >> api.bootstrap(context='test') >> api.finalize() >> >> ccache_file = 'FILE:/tmp/host_ccache' >> krbcontext = krbV.default_context() >> principal = str('host/%s@%s' % (api.env.host, api.env.realm)) >> keytab = krbV.Keytab(name='/etc/krb5.keytab', context=krbcontext) >> principal = krbV.Principal(name=principal, context=krbcontext) >> os.environ['KRB5CCNAME'] = ccache_file >> ccache = krbV.CCache(name=ccache_file, context=krbcontext, >> primary_principal=principal) >> ccache.init(principal) >> cache.init_creds_keytab(keytab=keytab, principal=principal) >> >> You'll definitely want to do something differently with the ccache file >> than I'm showing here. >> >> I threw in IPA client initialization here so you could use this to >> prepare to do IPA API calls. >> >> rob >> >> > >> > >> > On Mon, Aug 25, 2014 at 3:49 PM, Rob Crittenden > > > wrote: >> > >> > Yago Fern?ndez Pinilla wrote: >> > > I want to integrate it in other service. Is there any good >> > documentation >> > > about the APIs? >> > >> > We really need more details in order to help you. >> > >> > The API for IPA is not documented though once you get the patterns >> down >> > it is fairly straightforward. >> > >> > This of course is a completely separate issue of kinit in python. >> What >> > release of IPA on which distro(s) are you looking at? >> > >> > rob >> > >> > > >> > > Thanks in advance >> > > >> > > >> > > On Mon, Aug 25, 2014 at 3:08 PM, Jakub Hrozek > > >> > > >> wrote: >> > > >> > > On Mon, Aug 25, 2014 at 02:43:00PM +0200, Yago Fern?ndez >> > Pinilla wrote: >> > > > Hi, >> > > > >> > > > I would like to create a script in python that does the same >> > that >> > > kinit, I >> > > > don?t where to start. >> > > >> > > Why do you need this? >> > > >> > > -- >> > > Manage your subscription for the Freeipa-users mailing list: >> > > https://www.redhat.com/mailman/listinfo/freeipa-users >> > > Go To http://freeipa.org for more info on the project >> > > >> > > >> > > >> > > >> > > -- >> > > Yago Fern?ndez Pinilla >> > > e-mail: yagofp8 at gmail.com >> > > >> > > >> > > >> > > >> > >> > >> > >> > >> > -- >> > Yago Fern?ndez Pinilla >> > e-mail: yagofp8 at gmail.com >> > >> >> > > > -- > Yago Fern?ndez Pinilla > e-mail: yagofp8 at gmail.com > > -- Yago Fern?ndez Pinilla e-mail: yagofp8 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From baghery.jone at gmail.com Tue Aug 26 12:20:19 2014 From: baghery.jone at gmail.com (alireza baghery) Date: Tue, 26 Aug 2014 16:50:19 +0430 Subject: [Freeipa-users] users AD can not sudo in centos 6.5 In-Reply-To: <20140825121900.GD10132@hendrix.redhat.com> References: <53FB0C0A.3010009@redhat.com> <20140825115841.GD31972@hendrix.brq.redhat.com> <20140825121900.GD10132@hendrix.redhat.com> Message-ID: sorry for delay file sssd.conf: ============== domain/example.com] debug_level = 6 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = l.example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client1.l.example.com chpass_provider = ipa ipa_server = ipaserver.l.example.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] config_file_version = 2 services = nss, pam,ssh,sudo domains = l.example.com [nss] [pam] [ssh] On Mon, Aug 25, 2014 at 4:49 PM, Jakub Hrozek wrote: > On Mon, Aug 25, 2014 at 01:58:41PM +0200, Jakub Hrozek wrote: > > For sudo logs, something like: > > Debug sudo /tmp/sudo_debug all at debug > > Should produce pretty verbose logs > > Sorry, I should have said the Debug directive belongs to /etc/sudo.conf > > -- > Manage your subscription for 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 Aug 26 12:43:54 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 26 Aug 2014 14:43:54 +0200 Subject: [Freeipa-users] users AD can not sudo in centos 6.5 In-Reply-To: References: <53FB0C0A.3010009@redhat.com> <20140825115841.GD31972@hendrix.brq.redhat.com> <20140825121900.GD10132@hendrix.redhat.com> Message-ID: <20140826124354.GE18786@mail.corp.redhat.com> On (26/08/14 16:50), alireza baghery wrote: >sorry for delay >file sssd.conf: >============== > >domain/example.com] >debug_level = 6 >cache_credentials = True >krb5_store_password_if_offline = True >ipa_domain = l.example.com >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = client1.l.example.com >chpass_provider = ipa >ipa_server = ipaserver.l.example.com >ldap_tls_cacert = /etc/ipa/ca.crt > >[sssd] >config_file_version = 2 >services = nss, pam,ssh,sudo > You wrote that AD user cannot use sudo. The problem is that even ipa users cannot use sudo with this configuration. SSSD on CentoOS 6.5 does not have sudo_provider = ipa and thus configuration is little bit complicated. The configuration is described in manual page sssd-sudo man sssd-sudo -> CONFIGURING SUDO TO COOPERATE WITH SSSD -> CONFIGURING SSSD TO FETCH SUDO RULES LS From bpk678 at gmail.com Tue Aug 26 13:51:19 2014 From: bpk678 at gmail.com (brendan kearney) Date: Tue, 26 Aug 2014 09:51:19 -0400 Subject: [Freeipa-users] Fedora Core IPTables or FirewallID? In-Reply-To: References: Message-ID: systemctl stop firewalld systemctl disable firewalld systemctl stop iptables systemctl disable iptables sudo iptables -nvL This is not a recommended config, as a firewall will save your bacon without you realizing it. Fwbuilder is a great package in the fedora repos that will write excellent firewall policies. Maybe take a look at that. On Aug 25, 2014 10:24 PM, "Chris Whittle" wrote: > I've got my server up and running great with one exception every time I > reboot I have to login and flush the iptables or nothing can connect. > > I've found a ton of fixes and none seem to work, I'm on FC20 does anyone > have experience with it and wouldn't mind helping? > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Aug 26 14:00:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Aug 2014 10:00:24 -0400 Subject: [Freeipa-users] Fedora Core IPTables or FirewallID? In-Reply-To: References: Message-ID: <53FC92F8.2080405@redhat.com> brendan kearney wrote: > systemctl stop firewalld > systemctl disable firewalld > > systemctl stop iptables > systemctl disable iptables > > sudo iptables -nvL > > This is not a recommended config, as a firewall will save your bacon > without you realizing it. Fwbuilder is a great package in the fedora > repos that will write excellent firewall policies. Maybe take a look at > that. Yeah, I would definitely not recommend complete disabling the firewall. Fedora 20 uses firewalld as its default firewall service. Use firewall-cmd to open ports as needed. Add the --permanent flag to make it persistent across reboots, but you need to reload the rules when using this flag (see the man page for details). rob > > On Aug 25, 2014 10:24 PM, "Chris Whittle" > wrote: > > I've got my server up and running great with one exception every > time I reboot I have to login and flush the iptables or nothing can > connect. > > I've found a ton of fixes and none seem to work, I'm on FC20 does > anyone have experience with it and wouldn't mind helping? > > -- > Manage your subscription for 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 mheslin at redhat.com Tue Aug 26 14:22:44 2014 From: mheslin at redhat.com (Mark Heslin) Date: Tue, 26 Aug 2014 10:22:44 -0400 Subject: [Freeipa-users] Fedora Core IPTables or FirewallID? In-Reply-To: References: Message-ID: <53FC9834.9040401@redhat.com> Hi Chris, Take a look at the attached snippet - it will walk you through configuring firewalld with named chains on RHEL 7. You don't have to use named chains but makes managing multiple chains cleaner. Do make sure you 'mask' iptables - only using 'disable' can still cause conflicts in some circumstances. This is extracted from the recently published reference architecture "Integrating OpenShift Enterprise with IdM in RHEL 7": https://access.redhat.com/articles/1155603 (The redhat.com links are not yet in place). The context here was for an IdM server but I also used the same approach for the IdM replica and RHEL 7 clients. hth, -m On 08/25/2014 10:22 PM, Chris Whittle wrote: > I've got my server up and running great with one exception every time > I reboot I have to login and flush the iptables or nothing can connect. > > I've found a ton of fixes and none seem to work, I'm on FC20 does > anyone have experience with it and wouldn't mind helping? > > -- Red Hat Reference Architectures Follow Us: https://twitter.com/RedHatRefArch Plus Us: https://plus.google.com/u/0/b/114152126783830728030/ Like Us: https://www.facebook.com/rhrefarch -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firewalld-rhel7-idm-server Type: application/pdf Size: 143381 bytes Desc: not available URL: From cwhittl at gmail.com Tue Aug 26 14:26:15 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 26 Aug 2014 09:26:15 -0500 Subject: [Freeipa-users] Fedora Core IPTables or FirewallID? In-Reply-To: <53FC9834.9040401@redhat.com> References: <53FC9834.9040401@redhat.com> Message-ID: Here is what I found that seems to work from http://adam.younglogic.com/2013/04/firewall-d-for-freeipa/ It only has to be ran once... cat >/etc/firewalld/services/kerberos.xml < kerberos Kerberos EOD cat >/etc/firewalld/services/kpasswd.xml < kpasswd kpasswd EOD cat >/etc/firewalld/services/ldap.xml < ldap Lightweight Directory Access Protocol EOD cat >/etc/firewalld/services/ldaps.xml < ldaps Lightweight Directory Access Protocol over SSL EOD firewall-cmd --permanent --zone=public --add-service=dns firewall-cmd --permanent --zone=public --add-service=http firewall-cmd --permanent --zone=public --add-service=https firewall-cmd --permanent --zone=public --add-service=kerberos firewall-cmd --permanent --zone=public --add-service=kpasswd firewall-cmd --permanent --zone=public --add-service=ldap firewall-cmd --permanent --zone=public --add-service=ldaps firewall-cmd --permanent --zone=public --add-service=ntp firewall-cmd --reload On Tue, Aug 26, 2014 at 9:22 AM, Mark Heslin wrote: > Hi Chris, > > Take a look at the attached snippet - it will walk you through configuring > firewalld > with named chains on RHEL 7. You don't have to use named chains but makes > managing > multiple chains cleaner. Do make sure you 'mask' iptables - only using > 'disable' can still cause > conflicts in some circumstances. > > This is extracted from the recently published reference architecture > "Integrating OpenShift Enterprise > with IdM in RHEL 7": > > https://access.redhat.com/articles/1155603 (The redhat.com links > are not yet in place). > > The context here was for an IdM server but I also used the same approach > for the IdM replica > and RHEL 7 clients. > > hth, > > -m > > > > On 08/25/2014 10:22 PM, Chris Whittle wrote: > > I've got my server up and running great with one exception every time I > reboot I have to login and flush the iptables or nothing can connect. > > I've found a ton of fixes and none seem to work, I'm on FC20 does anyone > have experience with it and wouldn't mind helping? > > > > > -- > > Red Hat Reference Architectures > > Follow Us: https://twitter.com/RedHatRefArch > Plus Us: https://plus.google.com/u/0/b/114152126783830728030/ > Like Us: https://www.facebook.com/rhrefarch > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Tue Aug 26 14:37:14 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 26 Aug 2014 09:37:14 -0500 Subject: [Freeipa-users] Create a non-user Message-ID: So I have a user called mac_slave that is used to verify a that a user is active or not and also used to bind a mac laptop to freeipa's ldap. What I want to do is limit what that used can do and see, for example I wwant to keep them from logging in to my macs (i think i can do that by moving them outside the users group but don't know how to do that in freeipa) I also want to limit what they can see... basically I want them to see is the uid and the nsaccountlock attribute. Any ideas on these? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mheslin at redhat.com Tue Aug 26 14:37:35 2014 From: mheslin at redhat.com (Mark Heslin) Date: Tue, 26 Aug 2014 10:37:35 -0400 Subject: [Freeipa-users] Fedora Core IPTables or FirewallID? In-Reply-To: References: <53FC9834.9040401@redhat.com> Message-ID: <53FC9BAF.8060108@redhat.com> Chris, My understanding is that firewalld "services" are where we're heading but I'm not entirely sure how much or how little of these are fully supported/available yet. I've copied Thomas - he'll know :-) -m On 08/26/2014 10:26 AM, Chris Whittle wrote: > Here is what I found that seems to work from > http://adam.younglogic.com/2013/04/firewall-d-for-freeipa/ > > It only has to be ran once... > > cat >/etc/firewalld/services/kerberos.xml < > > kerberos > Kerberos > > > > EOD > > cat >/etc/firewalld/services/kpasswd.xml < > > kpasswd > kpasswd > > > > EOD > > cat >/etc/firewalld/services/ldap.xml < > > ldap > Lightweight Directory Access Protocol > > > EOD > > cat >/etc/firewalld/services/ldaps.xml < > > ldaps > Lightweight Directory Access Protocol over > SSL > > > EOD > > firewall-cmd --permanent --zone=public --add-service=dns > firewall-cmd --permanent --zone=public --add-service=http > firewall-cmd --permanent --zone=public --add-service=https > firewall-cmd --permanent --zone=public --add-service=kerberos > firewall-cmd --permanent --zone=public --add-service=kpasswd > firewall-cmd --permanent --zone=public --add-service=ldap > firewall-cmd --permanent --zone=public --add-service=ldaps > firewall-cmd --permanent --zone=public --add-service=ntp > firewall-cmd --reload > > > > On Tue, Aug 26, 2014 at 9:22 AM, Mark Heslin > wrote: > > Hi Chris, > > Take a look at the attached snippet - it will walk you through > configuring firewalld > with named chains on RHEL 7. You don't have to use named chains > but makes managing > multiple chains cleaner. Do make sure you 'mask' iptables - only > using 'disable' can still cause > conflicts in some circumstances. > > This is extracted from the recently published reference > architecture "Integrating OpenShift Enterprise > with IdM in RHEL 7": > > https://access.redhat.com/articles/1155603 (The redhat.com > links are not yet in place). > > The context here was for an IdM server but I also used the same > approach for the IdM replica > and RHEL 7 clients. > > hth, > > -m > > > > On 08/25/2014 10:22 PM, Chris Whittle wrote: >> I've got my server up and running great with one exception every >> time I reboot I have to login and flush the iptables or nothing >> can connect. >> >> I've found a ton of fixes and none seem to work, I'm on FC20 does >> anyone have experience with it and wouldn't mind helping? >> >> > > > -- > > Red Hat Reference Architectures > > Follow Us:https://twitter.com/RedHatRefArch > Plus Us:https://plus.google.com/u/0/b/114152126783830728030/ > Like Us:https://www.facebook.com/rhrefarch > > -- Red Hat Reference Architectures Follow Us: https://twitter.com/RedHatRefArch Plus Us: https://plus.google.com/u/0/b/114152126783830728030/ Like Us: https://www.facebook.com/rhrefarch -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwhittl at gmail.com Tue Aug 26 15:19:23 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Tue, 26 Aug 2014 10:19:23 -0500 Subject: [Freeipa-users] Installing a new Cert In-Reply-To: References: <53FAF936.9000506@redhat.com> Message-ID: This actually died after restart so I ended up starting over... So here is the process I did that looks like it works and also survives restart Step 1 - Before install http://stackoverflow.com/questions/23374894/mod-nss-with-apache-public-certificate-issue?noredirect=1#comment36504881_23374894 -- start at Convert crt file in PEM format and do that whole section completely Step 2 - Install IPA server using the p12 file from before and also the intermediate.crt from your provider (I'm not sure why this isn't documented anywhere but I found it in my searches) ipa-server-install --http_pkcs12 DOMAIN.COM.p12 --dirsrv_pkcs12 collectivebias.com.p12 --root-ca-file intermediate.crt Step 3 - re add certs (for some reason I don't know but it's needed) (from http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP) ipa-server-certinstall -w --http_pin=PKPASSWORD DOMAIN.COM.p12 ipa-server-certinstall -d --dirsrv_pin=PKPASSWORD DOMAIN.COM.p12 Step 4 reboot Step 5 You can dance if you wanna... On Mon, Aug 25, 2014 at 2:02 PM, Chris Whittle wrote: > I spoke a little too soon... It's working fine (browser is using new cert > and also ldaps is using the new cert) except when you go to the certs page > on the ui. > https://DOMAIN/ipa/ui/#/e/cert/search > > An error has occurred (IPA Error 4301: CertificateOperationError) > > Certificate operation cannot be completed: Unable to communicate with CMS > (Internal Server Error) > > > On Mon, Aug 25, 2014 at 1:34 PM, Chris Whittle wrote: > >> ok I think I got it again... If anyone is looking for this here is the >> answer that worked for me.... >> >> >> 1. Here are the steps >> 1. >> http://stackoverflow.com/questions/23374894/mod-nss-with-apache-public-certificate-issue?noredirect=1#comment36504881_23374894 >> -- start at Convert crt file in PEM format and do that whole >> section completely >> 2. Then with the p12 from above you get do this (skip the line >> about generating a new one) >> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >> 1. If you run across the error "/etc/ipa/ca.crt contains more >> than one certificate" you will need to go into /etc/ipa/ca.crt, back it up >> and then try removing one of the certs and try ipa-server-certinstall >> from above again (if it doesn't work revert ca.crt to the original and then >> remove the other) >> 3. Then restart the both instances (bottom of the freeipa link) >> and you should be good to go. >> >> >> On Mon, Aug 25, 2014 at 8:45 AM, Chris Whittle wrote: >> >>> I found this but I think it's just IPA certs? >>> http://www.freeipa.org/page/V4/CA_certificate_renewal >>> >>> Basically I want to use my existing wildcard cert for https and ldaps... >>> I did this on my 3.3 install on CentOS but now I'm on a 4 install on >>> Fedora Core. >>> >>> Any help would be more than appreciated! >>> Thanks! >>> >>> >>> On Mon, Aug 25, 2014 at 6:24 AM, Chris Whittle >>> wrote: >>> >>>> I have 4 installed and I get it when I try to generate the pk12 >>>> On Aug 25, 2014 3:50 AM, "Jan Cholasta" wrote: >>>> >>>>> Hi, >>>>> >>>>> Dne 25.8.2014 v 03:04 Chris Whittle napsal(a): >>>>> >>>>>> Trying to do this >>>>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >>>>>> >>>>>> And I keep getting "Error unable to get local issuer certificate >>>>>> getting >>>>>> chain." >>>>>> >>>>> >>>>> Where are you getting this error? ipa-server-certinstall, or httpd, or >>>>> somewhere else? >>>>> >>>>> What version of ipa do you have installed? >>>>> >>>>> >>>>>> I'm wondering if it's because of this from the doc >>>>>> "The certificate in mysite.crt must be signed by the CA used when >>>>>> installing FreeIPA." >>>>>> but it might not either... >>>>>> >>>>> >>>>> In this case you should get a "file.p12 is not signed by >>>>> /etc/ipa/ca.crt, or the full certificate chain is not present in the >>>>> PKCS#12 file" error in ipa-server-certinstall. >>>>> >>>>> >>>>>> Any ideas? >>>>>> >>>>>> >>>>>> >>>>> Honza >>>>> >>>>> -- >>>>> Jan Cholasta >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitkany at gmail.com Tue Aug 26 16:43:27 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Tue, 26 Aug 2014 12:43:27 -0400 Subject: [Freeipa-users] Monitoring FreeIPA with SNMP Message-ID: I have successfully enabled SNMP monitoring of FreeIPA server following the instructions available at RedHat's portal: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Monitoring_DS_Using_SNMP.html The problem is I cannot retrieve any metrics from the monitored server: Examples: Try to walk the whole rhds sub-tree > snmpwalk -v 2c -c public -mALL localhost rhds > RHDS-MIB::rhds = No more variables left in this MIB View (It is past the > end of the MIB tree) I was expecting the redhat sub-tree would be instantiated under private/enterprises(2312) Judging from the snmpwalk output the RHDS sub-tree is missing in the MIB view. My understanding is that beside configuring the SNMP agents for monitoring I don't need to configure the LDAP/FreeIPA server for monitoring, Is there anything else I need to configure, that is maybe not mentioned in the documentation? We are using - FreeIPA -3.0.0 - CentOS release 6.5 x86_64 - NET-SNMP version 5.5 dirsrv-snmp agent configuration /etc/dirsrv/config/ldap-agent.conf > agentx-master /var/agentx/master > agent-logdir /var/log/dirsrv > server slapd-EXAMPLE-COM and log output > 2014-08-26 10:58:48 Starting ldap-agent... > 2014-08-26 10:58:48 Started ldap-agent as pid 27008 snmpd AgentX log output > Aug 26 10:43:48 106 snmpd[26607]: Turning on AgentX master support. > Aug 26 10:43:48 106 snmpd[26609]: NET-SNMP version 5.5 Thanks Dimitar -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitkany at gmail.com Tue Aug 26 19:28:47 2014 From: mitkany at gmail.com (Dimitar Georgievski) Date: Tue, 26 Aug 2014 15:28:47 -0400 Subject: [Freeipa-users] Monitoring FreeIPA with SNMP In-Reply-To: References: Message-ID: Problem resolved. I completely forgot to check the access privileges in /etc/snmp/snmpd.conf. By default NET-SNMP configures the agent to provide access to .iso.org.dod.internet.mgmt. sub-tree only. The redhat sub-tree is under .iso.org.dod.internet.private.enterprises. I had to add a view on this three and the appropriate security privileges to access the new community. The sub-tree could be traversed now with: *snmpwalk -v 2c -c mycommunity -mALL localhost rhds* > RHDS-MIB::dsAnonymousBinds.389 = Counter64: 1187 > RHDS-MIB::dsUnAuthBinds.389 = Counter64: 1187 > RHDS-MIB::dsSimpleAuthBinds.389 = Counter64: 1213 > RHDS-MIB::dsStrongAuthBinds.389 = Counter64: 227103 > RHDS-MIB::dsBindSecurityErrors.389 = Counter64: 5 > RHDS-MIB::dsInOps.389 = Counter64: 6590347 > RHDS-MIB::dsReadOps.389 = Counter64: 0 > RHDS-MIB::dsCompareOps.389 = Counter64: 6 > RHDS-MIB::dsAddEntryOps.389 = Counter64: 17 > RHDS-MIB::dsRemoveEntryOps.389 = Counter64: 203 > RHDS-MIB::dsModifyEntryOps.389 = Counter64: 70101 > RHDS-MIB::dsModifyRDNOps.389 = Counter64: 0 > RHDS-MIB::dsListOps.389 = Counter64: 0 > RHDS-MIB::dsSearchOps.389 = Counter64: 5959375 > RHDS-MIB::dsOneLevelSearchOps.389 = Counter64: 39 > RHDS-MIB::dsWholeSubtreeSearchOps.389 = Counter64: 5342418 > RHDS-MIB::dsReferrals.389 = Counter64: 0 > RHDS-MIB::dsChainings.389 = Counter64: 0 > RHDS-MIB::dsSecurityErrors.389 = Counter64: 7 > RHDS-MIB::dsErrors.389 = Counter64: 240831 > RHDS-MIB::dsMasterEntries.389 = Counter64: 0 > RHDS-MIB::dsCopyEntries.389 = Counter64: 0 > RHDS-MIB::dsCacheEntries.389 = Counter64: 0 > RHDS-MIB::dsCacheHits.389 = Counter64: 0 > RHDS-MIB::dsSlaveHits.389 = Counter64: 0 > RHDS-MIB::dsEntityDescr.389 = STRING: > RHDS-MIB::dsEntityVers.389 = STRING: 389-Directory/1.2.11.15 > RHDS-MIB::dsEntityOrg.389 = STRING: > RHDS-MIB::dsEntityLocation.389 = STRING: > RHDS-MIB::dsEntityContact.389 = STRING: > RHDS-MIB::dsEntityName.389 = STRING: On Tue, Aug 26, 2014 at 12:43 PM, Dimitar Georgievski wrote: > > I have successfully enabled SNMP monitoring of FreeIPA server following > the instructions available at RedHat's portal: > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Monitoring_DS_Using_SNMP.html > > The problem is I cannot retrieve any metrics from the monitored server: > > Examples: > Try to walk the whole rhds sub-tree > >> snmpwalk -v 2c -c public -mALL localhost rhds >> RHDS-MIB::rhds = No more variables left in this MIB View (It is past the >> end of the MIB tree) > > > I was expecting the redhat sub-tree would be instantiated under > private/enterprises(2312) > > > Judging from the snmpwalk output the RHDS sub-tree is missing in the MIB > view. My understanding is that beside configuring the SNMP agents for > monitoring I don't need to configure the LDAP/FreeIPA server for > monitoring, > Is there anything else I need to configure, that is maybe not mentioned in > the documentation? > > We are using > - FreeIPA -3.0.0 > - CentOS release 6.5 x86_64 > - NET-SNMP version 5.5 > > dirsrv-snmp agent configuration > /etc/dirsrv/config/ldap-agent.conf > >> agentx-master /var/agentx/master >> agent-logdir /var/log/dirsrv >> server slapd-EXAMPLE-COM > > > and log output > >> 2014-08-26 10:58:48 Starting ldap-agent... >> 2014-08-26 10:58:48 Started ldap-agent as pid 27008 > > > snmpd AgentX log output > >> Aug 26 10:43:48 106 snmpd[26607]: Turning on AgentX master support. >> Aug 26 10:43:48 106 snmpd[26609]: NET-SNMP version 5.5 > > > Thanks > > Dimitar > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Aug 26 19:52:52 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 26 Aug 2014 15:52:52 -0400 Subject: [Freeipa-users] Cert Renewal In-Reply-To: References: <53FBBA74.2040807@redhat.com> Message-ID: <53FCE594.5040106@redhat.com> Ott, Dennis wrote: > No services are currently running on the replica (and I am hesitant to start them) but, my recollection is that I did the replica server installation with the --setup-ca option. Also, there are /var/lib/dirsrv/slapd-PKI-IPA/ and /etc/pki-ca/ directories in place on the replica. > > ipa-getcert list shows all certs with a status of: CA_UNREACHABLE (but then, the service is down. The master also gave this status, even with the service running, until I followed the cert renewal procedure.) > > So, with the replica running a CA, should I follow the same procedure that I used on the master? Anything else to look out for? No, the procedure is slightly different on the replica. You need to start by ensuring that certmonger has a CA type for renewal: # getcert list-cas Look for ca_renewal Check the CA subsystem certs to see how they are configured. The CA should be dogtag-ipa-retrieve-agent-submit for "auditSigningCert cert-pki-ca", "ocspSigningCert cert-pki-ca" and "subsystemCert cert-pki-ca" and a pre-save command of stop_pkicad and a post-save a restart_pkicad PKI-IPA The agent cert, ipaCert, should be using "dogtag-ipa-retrieve-agent-submit", a blank pre-save command and a post-save command of restart_httpd. rob > > Thanks. > > Dennis > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, August 25, 2014 6:37 PM > To: Ott, Dennis; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cert Renewal > > Ott, Dennis wrote: >> I have an IPA setup, one master, one replica; originally installed as >> v 2.x and later updated to v 3.0. For whatever reasons, the certs did >> not automatically renew and the services would no longer start. I >> updated the certs manually on the master using the procedure shown at: >> >> >> >> http://www.freeipa.org/page/IPA_2x_Certificate_Renewal >> >> >> >> The master is now functioning properly. >> >> >> >> >> >> At this point, the IPA service is still stopped on the replica. I >> hesitate to start it for concern it could interfere with the >> now-working master. >> >> >> >> What would be the recommended method for returning the replica to service? > > It depends on whether the replica. Does it also run a CA? If not then you can try restarting the certmonger service. This should cause it to fetch new certificates for the other IPA servers. ipa-getcert list will show you the status, wait until they are all MONITORING. > > Once that works then you can safely restart the world. Any changes on the master will be replicated out, and vice versa. > > rob > From mkosek at redhat.com Tue Aug 26 20:12:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Aug 2014 22:12:55 +0200 Subject: [Freeipa-users] Installing a new Cert In-Reply-To: References: <53FAF936.9000506@redhat.com> Message-ID: <53FCEA47.6060502@redhat.com> Thanks for sharing your (rather painful) experience, I am glad you made it working in the end. Just note that we are currently (read FreeIPA 4.0.x and FreeIPA 4.1) working making the cert operations in the installers smoother so that after so that people like you would have much easier job. Martin On 08/26/2014 05:19 PM, Chris Whittle wrote: > This actually died after restart so I ended up starting over... > > So here is the process I did that looks like it works and also survives restart > > Step 1 - Before install > http://stackoverflow.com/questions/23374894/mod-nss-with-apache-public-certificate-issue?noredirect=1#comment36504881_23374894-- > start at Convert crt file in PEM format and do that whole section completely > > Step 2 - Install IPA server using the p12 file from before and also the > intermediate.crt from your provider (I'm not sure why this isn't documented > anywhere but I found it in my searches) > > ipa-server-install --http_pkcs12 DOMAIN.COM.p12 --dirsrv_pkcs12 > collectivebias.com.p12 --root-ca-file intermediate.crt > > Step 3 - re add certs (for some reason I don't know but it's needed) (from > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP) > > ipa-server-certinstall -w --http_pin=PKPASSWORD DOMAIN.COM.p12 > ipa-server-certinstall -d --dirsrv_pin=PKPASSWORD DOMAIN.COM.p12 > > Step 4 reboot > Step 5 You can dance if you wanna... > > > > On Mon, Aug 25, 2014 at 2:02 PM, Chris Whittle > wrote: > > I spoke a little too soon... It's working fine (browser is using new cert > and also ldaps is using the new cert) except when you go to the certs page > on the ui. > https://DOMAIN/ipa/ui/#/e/cert/search > > > An error has occurred (IPA Error 4301: CertificateOperationError) > > Certificate operation cannot be completed: Unable to communicate with CMS > (Internal Server Error) > > > > On Mon, Aug 25, 2014 at 1:34 PM, Chris Whittle > wrote: > > ok I think I got it again... If anyone is looking for this here is the > answer that worked for me.... > > 1. Here are the steps > 1. http://stackoverflow.com/questions/23374894/mod-nss-with-apache-public-certificate-issue?noredirect=1#comment36504881_23374894 > -- start at Convert crt file in PEM format and do that whole > section completely > 2. Then with the p12 from above you get do this (skip the line > about generating a new one) > http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP > 1. If you run across the error "/etc/ipa/ca.crt contains more > than one certificate" you will need to go into > /etc/ipa/ca.crt, back it up and then try removing one of > the certs and try ipa-server-certinstall from above again > (if it doesn't work revert ca.crt to the original and then > remove the other) > 3. Then restart the both instances (bottom of the freeipa link) > and you should be good to go. > > > On Mon, Aug 25, 2014 at 8:45 AM, Chris Whittle > wrote: > > I found this but I think it's just IPA certs? > http://www.freeipa.org/page/V4/CA_certificate_renewal > > Basically I want to use my existing wildcard cert for https and > ldaps... > I did this on my 3.3 install on CentOS but now I'm on a 4 install > on Fedora Core. > > Any help would be more than appreciated! > Thanks! > > > On Mon, Aug 25, 2014 at 6:24 AM, Chris Whittle > wrote: > > I have 4 installed and I get it when I try to generate the pk12 > > On Aug 25, 2014 3:50 AM, "Jan Cholasta" > wrote: > > Hi, > > Dne 25.8.2014 v 03:04 Chris Whittle napsal(a): > > Trying to do this > http://www.freeipa.org/page/__Using_3rd_part_certificates___for_HTTP/LDAP > > > And I keep getting "Error unable to get local issuer > certificate getting > chain." > > > Where are you getting this error? ipa-server-certinstall, > or httpd, or somewhere else? > > What version of ipa do you have installed? > > > I'm wondering if it's because of this from the doc > "The certificate in mysite.crt must be signed by the CA > used when > installing FreeIPA." > but it might not either... > > > In this case you should get a "file.p12 is not signed by > /etc/ipa/ca.crt, or the full certificate chain is not > present in the PKCS#12 file" error in ipa-server-certinstall. > > > Any ideas? > > > > Honza > > -- > Jan Cholasta > > > > > > > From dpal at redhat.com Tue Aug 26 22:47:28 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 27 Aug 2014 00:47:28 +0200 Subject: [Freeipa-users] Custom kinit In-Reply-To: References: <20140825130824.GI10132@hendrix.redhat.com> <53FB3ED6.1050209@redhat.com> <53FB5AD4.5020500@redhat.com> Message-ID: <53FD0E80.60900@redhat.com> On 08/26/2014 11:43 AM, Yago Fern?ndez Pinilla wrote: > I have checked what you told me. > > What I would like to do is: having a user and a password, authenticate > against the kerberos server using a python script (not using kinit) > and then be able to access to the ticket that is returned back by > kerberos. Access by what? Can you please describe a full flow as you see it? > > User -----> Service ------> Kerberos > > The user sends user and password the first time to authenticate and > then the ticket. > I know that this can look a bit weird but in the environment that I'm > working on i need this. > > Any idea how can I do this? I have checked many libraries in Python > but they don't seem like having what i need. > > Thanks in advance > > Yago > > > > On Tue, Aug 26, 2014 at 9:37 AM, Yago Fern?ndez Pinilla > > wrote: > > Thanks for the info! > > I will work more on this and comment my progress > > > > On Mon, Aug 25, 2014 at 5:48 PM, Rob Crittenden > > wrote: > > Yago Fern?ndez Pinilla wrote: > > I'm using FreeIpa 3.3.5. And according to what I saw, using > the API, > > seems to be the best option. > > > > For the time being I just want to request tickets and check > tickets. > > > > Is that possible? > > . > > I'm still not sure what it is you're trying to do. > > It's important to remember that IPA isn't a server itself, it is a > collection of services configured to work together towards a > common goal > (centralized identity). What we add is a management framework > on top to > (hopefully) make things easier. This is what our API does, > helps you > manage users, groups, etc. > > A ticket is a Kerberos concept and you would obtain it > directly from the > KDC. The IPA API is not involved in that case. > > If that is what you want to do then it involves the > python-krbV package > which is difficult at best to use and doesn't implement the entire > Kerberos stack. You can though do the equivalent of a kinit > using a > keytab doing something like: > > import krbV > from ipalib import api > > api.bootstrap(context='test') > api.finalize() > > ccache_file = 'FILE:/tmp/host_ccache' > krbcontext = krbV.default_context() > principal = str('host/%s@%s' % (api.env.host, api.env.realm)) > keytab = krbV.Keytab(name='/etc/krb5.keytab', context=krbcontext) > principal = krbV.Principal(name=principal, context=krbcontext) > os.environ['KRB5CCNAME'] = ccache_file > ccache = krbV.CCache(name=ccache_file, context=krbcontext, > primary_principal=principal) > ccache.init(principal) > cache.init_creds_keytab(keytab=keytab, principal=principal) > > You'll definitely want to do something differently with the > ccache file > than I'm showing here. > > I threw in IPA client initialization here so you could use this to > prepare to do IPA API calls. > > rob > > > > > > > On Mon, Aug 25, 2014 at 3:49 PM, Rob Crittenden > > > >> > wrote: > > > > Yago Fern?ndez Pinilla wrote: > > > I want to integrate it in other service. Is there any good > > documentation > > > about the APIs? > > > > We really need more details in order to help you. > > > > The API for IPA is not documented though once you get > the patterns down > > it is fairly straightforward. > > > > This of course is a completely separate issue of kinit > in python. What > > release of IPA on which distro(s) are you looking at? > > > > rob > > > > > > > > Thanks in advance > > > > > > > > > On Mon, Aug 25, 2014 at 3:08 PM, Jakub Hrozek > > > > > > > > >>> wrote: > > > > > > On Mon, Aug 25, 2014 at 02:43:00PM +0200, Yago > Fern?ndez > > Pinilla wrote: > > > > Hi, > > > > > > > > I would like to create a script in python that > does the same > > that > > > kinit, I > > > > don?t where to start. > > > > > > Why do you need this? > > > > > > -- > > > Manage your subscription for the Freeipa-users > mailing list: > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Go To http://freeipa.org for more info on the project > > > > > > > > > > > > > > > -- > > > Yago Fern?ndez Pinilla > > > e-mail: yagofp8 at gmail.com > > > > > >> > > > > > > > > > > > > > > > > > > > -- > > Yago Fern?ndez Pinilla > > e-mail: yagofp8 at gmail.com > > > > > > > > > -- > Yago Fern?ndez Pinilla > e-mail: yagofp8 at gmail.com > > > > > -- > Yago Fern?ndez Pinilla > e-mail: yagofp8 at gmail.com > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uncommonkat at gmail.com Wed Aug 27 05:47:06 2014 From: uncommonkat at gmail.com (Kat) Date: Tue, 26 Aug 2014 22:47:06 -0700 Subject: [Freeipa-users] Migration works on 3 but not 4? Message-ID: <53FD70DA.6070105@gmail.com> Hi all... Migrating from Open LDAP and it works fine to FreeIPA to 3.x but 4.x I get migration errors? /Constraint violation: invalid password syntax - passwords with storage scheme are not allowed/ I did find one reference to this in the archives, but it references 389-ds 1.3.2.20 and i am running 1.3.2.22, so am I missing something? ~K -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Aug 27 07:14:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 Aug 2014 09:14:58 +0200 Subject: [Freeipa-users] Migration works on 3 but not 4? In-Reply-To: <53FD70DA.6070105@gmail.com> References: <53FD70DA.6070105@gmail.com> Message-ID: <53FD8572.10006@redhat.com> On 08/27/2014 07:47 AM, Kat wrote: > Hi all... > > Migrating from Open LDAP and it works fine to FreeIPA to 3.x but 4.x I get > migration errors? > > /Constraint violation: invalid password syntax - passwords with storage scheme > are not allowed/ > > I did find one reference to this in the archives, but it references 389-ds > 1.3.2.20 and i am running 1.3.2.22, so am I missing something? > > ~K Hello Kat, You are exactly on spot. This problem is caused by 389-ds-base not allowing hashed password, you can find details in https://fedorahosted.org/freeipa/ticket/4450 This *was* fixed with DS 1.3.2.20. Unfortunately, there was a security update in the DS and it had to be based on 1.3.2.19 again and versioned 1.3.2.22 (i.e. without the fix for 4450). Noriko, what are the time plans regarding a release of the DS based on 1.3.2.20 + the security update? Thanks, Martin From lkrispen at redhat.com Wed Aug 27 09:09:21 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 27 Aug 2014 11:09:21 +0200 Subject: [Freeipa-users] Migration works on 3 but not 4? In-Reply-To: <53FD8572.10006@redhat.com> References: <53FD70DA.6070105@gmail.com> <53FD8572.10006@redhat.com> Message-ID: <53FDA041.9060708@redhat.com> On 08/27/2014 09:14 AM, Martin Kosek wrote: > On 08/27/2014 07:47 AM, Kat wrote: >> Hi all... >> >> Migrating from Open LDAP and it works fine to FreeIPA to 3.x but 4.x >> I get >> migration errors? >> >> /Constraint violation: invalid password syntax - passwords with >> storage scheme >> are not allowed/ >> >> I did find one reference to this in the archives, but it references >> 389-ds >> 1.3.2.20 and i am running 1.3.2.22, so am I missing something? >> >> ~K > > Hello Kat, > > You are exactly on spot. This problem is caused by 389-ds-base not > allowing hashed password, you can find details in > > https://fedorahosted.org/freeipa/ticket/4450 > > This *was* fixed with DS 1.3.2.20. Unfortunately, there was a security > update in the DS and it had to be based on 1.3.2.19 again and > versioned 1.3.2.22 (i.e. without the fix for 4450). > > Noriko, what are the time plans regarding a release of the DS based on > 1.3.2.20 + the security update? There are two outstanding tickets for 1.3.2.23: 47871: the crash you reported, Thierry has a fix and I think it is good to commit 47866: invalid (null) values for dna config entries, I'll look into this. > > Thanks, > Martin > From arthur at deus.pro Wed Aug 27 10:55:03 2014 From: arthur at deus.pro (Arthur Fayzullin) Date: Wed, 27 Aug 2014 16:55:03 +0600 Subject: [Freeipa-users] Fedora Core IPTables or FirewallID? In-Reply-To: <53FC9BAF.8060108@redhat.com> References: <53FC9834.9040401@redhat.com> <53FC9BAF.8060108@redhat.com> Message-ID: <53FDB907.5080402@deus.pro> I've got something like this: $ sudo firewall-cmd --permanent --list-all [sudo] password for afayzullin: public (default) interfaces: sources: services: dhcpv6-client dns http https kerberos kpasswd ldap ldaps ntp ssh ports: 7389/tcp masquerade: no forward-ports: icmp-blocks: rich rules: 26.08.2014 20:37, Mark Heslin ?????: > Chris, > > My understanding is that firewalld "services" are where we're heading > but I'm not entirely > sure how much or how little of these are fully supported/available yet. > > I've copied Thomas - he'll know :-) > > -m > > > > On 08/26/2014 10:26 AM, Chris Whittle wrote: >> Here is what I found that seems to work from >> http://adam.younglogic.com/2013/04/firewall-d-for-freeipa/ >> >> It only has to be ran once... >> >> cat >/etc/firewalld/services/kerberos.xml <> >> >> kerberos >> Kerberos >> >> >> >> EOD >> >> cat >/etc/firewalld/services/kpasswd.xml <> >> >> kpasswd >> kpasswd >> >> >> >> EOD >> >> cat >/etc/firewalld/services/ldap.xml <> >> >> ldap >> Lightweight Directory Access Protocol >> >> >> EOD >> >> cat >/etc/firewalld/services/ldaps.xml <> >> >> ldaps >> Lightweight Directory Access Protocol over >> SSL >> >> >> EOD >> >> firewall-cmd --permanent --zone=public --add-service=dns >> firewall-cmd --permanent --zone=public --add-service=http >> firewall-cmd --permanent --zone=public --add-service=https >> firewall-cmd --permanent --zone=public --add-service=kerberos >> firewall-cmd --permanent --zone=public --add-service=kpasswd >> firewall-cmd --permanent --zone=public --add-service=ldap >> firewall-cmd --permanent --zone=public --add-service=ldaps >> firewall-cmd --permanent --zone=public --add-service=ntp >> firewall-cmd --reload >> >> >> >> On Tue, Aug 26, 2014 at 9:22 AM, Mark Heslin > > wrote: >> >> Hi Chris, >> >> Take a look at the attached snippet - it will walk you through >> configuring firewalld >> with named chains on RHEL 7. You don't have to use named chains >> but makes managing >> multiple chains cleaner. Do make sure you 'mask' iptables - only >> using 'disable' can still cause >> conflicts in some circumstances. >> >> This is extracted from the recently published reference >> architecture "Integrating OpenShift Enterprise >> with IdM in RHEL 7": >> >> https://access.redhat.com/articles/1155603 (The redhat.com >> links are not yet in place). >> >> The context here was for an IdM server but I also used the same >> approach for the IdM replica >> and RHEL 7 clients. >> >> hth, >> >> -m >> >> >> >> On 08/25/2014 10:22 PM, Chris Whittle wrote: >>> I've got my server up and running great with one exception every >>> time I reboot I have to login and flush the iptables or nothing >>> can connect. >>> >>> I've found a ton of fixes and none seem to work, I'm on FC20 >>> does anyone have experience with it and wouldn't mind helping? >>> >>> >> >> >> -- >> >> Red Hat Reference Architectures >> >> Follow Us: https://twitter.com/RedHatRefArch >> Plus Us: https://plus.google.com/u/0/b/114152126783830728030/ >> Like Us: https://www.facebook.com/rhrefarch >> >> > > > -- > > Red Hat Reference Architectures > > Follow Us: https://twitter.com/RedHatRefArch > Plus Us: https://plus.google.com/u/0/b/114152126783830728030/ > Like Us: https://www.facebook.com/rhrefarch > > -- ? ?????????, ????? ????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnordgren at fs.fed.us Wed Aug 27 22:43:04 2014 From: bnordgren at fs.fed.us (Nordgren, Bryce L -FS) Date: Wed, 27 Aug 2014 22:43:04 +0000 Subject: [Freeipa-users] A prototype of merged domains ("views") In-Reply-To: <20140825090420.GH4748@redhat.com> References: <82E7C9A01FD0764CACDD35D10F5DFB6E71869F@001FSN2MPN1-045.001f.mgd2.msft.net> <20140825090420.GH4748@redhat.com> Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E71910F@001FSN2MPN1-045.001f.mgd2.msft.net> > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: Monday, August 25, 2014 3:04 AM > To: Nordgren, Bryce L -FS > Cc: 'freeipa-users at redhat.com'; 'sssd-users at lists.fedorahosted.org' > Subject: Re: [Freeipa-users] A prototype of merged domains ("views") > > What essentially you want is to arbitrate access control to certain services > regardless the source users or groups are coming from. This is already > possible to achieve with HBAC rules because we already can make external > SIDs members of a non-POSIX group that is included into a POSIX group > which is referenced by an HBAC rule. This works already and doesn't need > any views because HBAC rules already can be subjected to a specific host and > specific service on the host. Ah. My system is intended to work when there is no upstream SID (e.g., the source could be something other than active directory). This is necessary to provide a loose one-way coupling from the more-truested intranet to the less-trusted collaboration network. Getting this established as a foundation is also a critical prerequisite to experimenting with a web sso/kerberos gateway. > We need to extend concept of external members of non-POSIX groups to > have the same resolving features as we are planning with ID view overrides > (SID:S-..., IPA:, etc) so that external non-POSIX groups can be used > more widely. Nonlocal groups are not interesting to me. They are defined in the internal corporate environment which is not at all similar to an external collaboration domain. Locally defined groups, containing members drawn from any of the contributing identity sources, are interesting. > Your other problem is that you seem to unable to establish two-way trust > with AD as currently IPA requires. I have plans to get one-way trust back > working but it needs additional changes on our side to properly protect trust > account credentials when distributing them to a group of IPA masters > participating in the trust. One way trust was requested in April and is still pending. Chances of getting a two-way trust are zero. I'll be using the documented workaround to add the Kerberos cross-realm principal to the KDC if and when I get it. Chances of getting a "trust" go up if you eliminate all the crap MS overloads that word with. A simple Kerberos trust ("realm trust") should be easier to get than a domain/forest/etc. trust because it exposes the intranet to less vulnerability. Much of my problem so far has been that people assume I want a domain or forest trust when I'm really asking for a realm trust. If it helps, you can think of this as a prototype of what FreeIPA's going to need views to do in order to implement a vanilla Kerberos trust. I want them (CIO) to authenticate users for me and provide a handful of well controlled and harmless user attributes. Port 88, port 389, and port 636. Nothing else. In other words, I want a very loose, one-way coupling between the collaboration domain and the intranet. Not two way. Not tight coupling. Understand that the point of the collaboration domain is to delegate root access to people who are not part of the CIO and may not even be employees. Tight, two-way coupling of the intranet to this environment amounts to unnecessary exposure to risk. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. From nicklas.bjork at skalarit.se Thu Aug 28 08:58:51 2014 From: nicklas.bjork at skalarit.se (=?UTF-8?B?Tmlja2xhcyBCasO2cms=?=) Date: Thu, 28 Aug 2014 10:58:51 +0200 Subject: [Freeipa-users] RHEL 7 Upgrade experience so far Message-ID: <53FEEF4B.2070307@skalarit.se> I have been following this thread with great interest, as I have encountered similar problems with our migration from 3.0.0-37 on CentOS 6.5 to 3.3.3-28 on CentOS 7. I have been able to solve a few of them with manual patching, but there is still something going on that will make the CA replication to fail. The following changes have been made to the environments: - On the replica, /usr/lib/python2.7/site-packages/ipaserver/install/replication.py has been patched to handle multiple values of nsDS5ReplicaId on the master. - /usr/share/ipa/html/ca.crt used to contain our local root certificate as well as the IPA CA-certificate, which caused the replica installation to fail. The root certificate was removed from this file, the replica gpg-bundle recreated, and the installation would happily continue. - /etc/httpd/conf.d/ipa-pki-proxy.conf has been patched to contain the profileSubmit-patch to the ee port-line and have also tried with and without the additions to the admin port and installer-line Checking the log files on the 3.3.3 replica, there are a few error messages, which I am not sure how to resolve. /var/log/ipareplica-install.log ends with the following lines: 2014-08-27T14:44:15Z DEBUG Starting external process 2014-08-27T14:44:15Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpxkixl8 2014-08-27T14:45:19Z DEBUG Process finished, return code=1 2014-08-27T14:45:19Z DEBUG stdout=Loading deployment configuration from /tmp/tmpxkixl8. Installing CA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. Installation failed. 2014-08-27T14:45:19Z DEBUG stderr=pkispawn : WARNING ....... unable to validate security domain user/password through REST interface. Interface not available pkispawn : ERROR ....... Exception from Java Configuration Servlet: Error while updating security domain: java.io.IOException: 2 2014-08-27T14:45:19Z CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpxkixl8' returned non-zero exit status 1 2014-08-27T14:45:19Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 638, in run_script return_value = main_function() File "/usr/sbin/ipa-replica-install", line 667, in main CA = cainstance.install_replica_ca(config) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1678, in install_replica_ca subject_base=config.subject_base) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 364, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 604, in __spawn_instance raise RuntimeError('Configuration of CA failed') 2014-08-27T14:45:19Z DEBUG The ipa-replica-install command failed, exception: RuntimeError: Configuration of CA failed /var/log/pki/pki-ca-spawn.20140827164415.log reveals these error messages: 2014-08-27 16:44:16 pkispawn : INFO ....... executing 'systemctl start pki-tomcatd at pki-tomcat.service' 2014-08-27 16:44:18 pkispawn : DEBUG ........... No connection - server may still be down 2014-08-27 16:44:18 pkispawn : DEBUG ........... No connection - exception thrown: [Errno 111] Connection refused 2014-08-27 16:44:26 pkispawn : DEBUG ........... 0CArunning10.0.5-3.el7 2014-08-27 16:44:27 pkispawn : INFO ....... constructing PKI configuration data. 2014-08-27 16:44:27 pkispawn : INFO ....... configuring PKI configuration data. 2014-08-27 16:45:19 pkispawn : ERROR ....... Exception from Java Configuration Servlet: Error while updating security domain: java.io.IOException: 2 2014-08-27 16:45:19 pkispawn : DEBUG ....... Error Type: HTTPError 2014-08-27 16:45:19 pkispawn : DEBUG ....... Error Message: 500 Server Error: Internal Server Error 2014-08-27 16:45:19 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 374, in main rv = instance.spawn() File "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", line 128, in spawn json.dumps(data, cls=pki.encoder.CustomTypeEncoder)) File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", line 2998, in configure_pki_data response = client.configure(data) File "/usr/lib/python2.7/site-packages/pki/system.py", line 80, in configure r = self.connection.post('/rest/installer/configure', data, headers) File "/usr/lib/python2.7/site-packages/pki/client.py", line 64, in post r.raise_for_status() File "/usr/lib/python2.7/site-packages/requests/models.py", line 638, in raise_for_status raise http_error In /var/log/pki/pki-tomcat/catalina.out one can read: Aug 27, 2014 4:44:22 PM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /var/lib/pki/pki-tomcat/webapps/ca SSLAuthenticatorWithFallback: Creating SSL authenticator with fallback SSLAuthenticatorWithFallback: Setting container SSLAuthenticatorWithFallback: Initializing authenticators SSLAuthenticatorWithFallback: Starting authenticators CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initializa tion failed and skipped, error=Property internaldb.ldapconn.port missing value| Server is started. Aug 27, 2014 4:44:26 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-bio-8080"] Aug 27, 2014 4:44:26 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-bio-8443"] Aug 27, 2014 4:44:26 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["ajp-bio-127.0.0.1-8009"] Aug 27, 2014 4:44:26 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 7872 ms 16:44:27,950 INFO (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) - Deploying javax.ws.rs.core.Application: class com.netscape.ca.CertificateAuthorityApplication 16:44:27,967 INFO (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) - Adding singleton provider com.netscape.certsrv.acls.ACLInterceptor from Application javax.ws.rs.core.Application 16:44:27,968 INFO (org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher:82) - Adding singleton provider com.netscape.certsrv.authentication.AuthMethodInterceptor from Application javax.ws.rs.core.Application 16:44:28,433 DEBUG (org.jboss.resteasy.core.SynchronousDispatcher:60) - PathInfo: /installer/configure AuthInterceptor: SystemConfigResource.configure() AuthInterceptor: mapping name: default AuthInterceptor: required auth methods: [*] AuthInterceptor: anonymous access allowed java.io.IOException: 2 at com.netscape.cms.servlet.csadmin.ConfigurationUtils.updateDomainXML(ConfigurationUtils.java:3415) at com.netscape.cms.servlet.csadmin.ConfigurationUtils.updateSecurityDomain(ConfigurationUtils.java:3345) at com.netscape.cms.servlet.csadmin.SystemConfigService.configure(SystemConfigService.java:655) 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.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) 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.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:299) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:57) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1024) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) 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:744) /var/log/pki/pki-tomcat/ca/debug may give a clue aswell: [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: isSDHostDomainMaster(): Getting domain.xml from CA... [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: getDomainXML start [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: getDomainXML: status=0 [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: getDomainXML: domainInfo=IPAipa.skalarit.net44344344344380FALSEpki-cadTRUE100000 [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: Cloning a domain master [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: WizardPanelBase updateDomainXML start hostname=ipa.skalarit.net port=443 [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: updateSecurityDomain: failed to update security domain using admin port 443: java.io.IOException: Failed to get response when updating security domain [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: updateSecurityDomain: now trying agent port with client auth [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: WizardPanelBase updateDomainXML start hostname=ipa.skalarit.net port=443 [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: updateDomainXML() nickname=subsystemCert cert-pki-ca [27/Aug/2014:16:45:19][http-bio-8443-exec-3]: WizardPanelBase updateDomainXML: status=1 /Nicklas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: From asl.gerardo at gmail.com Thu Aug 28 10:08:27 2014 From: asl.gerardo at gmail.com (Gerardo Padierna) Date: Thu, 28 Aug 2014 12:08:27 +0200 Subject: [Freeipa-users] ipa-server (v3.3.3) with sssd (v1.11.2) config Message-ID: <53FEFF9B.80209@gmail.com> Hi, In a setup where FreeIPA + sssd act as an authentication for AD users (taking advantage of sssd's ability to act as an authentication client for AD users), why do we need to establish a (two-way) trust relationship? Ins't there a workaround for this, given that sssd is already able to authenticate users without having to do nothing on the DA-side (just need a read-only user to carry out the initial bind)? In a bit more detail: We'd like to use AD-based authentication on some Unix hosts (mostly Solaris 10) for which there's no sssd available (we're already using sssd on RHEL hosts); we were thinking of setting up a server with FreeIPA + sssd to act as sort of a proxy to the actual AD for authentication, for those hosts for which there's no sssd client available (based on this doc: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts). There reasons why we're doing this are basically: ? there's no unix-compatibiliy available on the AD sever (and most likely there won't ever be) ? we'd like to keep the same UID/GIDs for all users that already authenticate on the RHEL boxes (to be able to work on the same home directories, maintain homogenous file ownership accross shared ressources, etc.) So, we've set up: ? a CentOS 7.0 host with ipa-server v3.3.3 and sssd v1.11.2 and configured (with domain: ipa-dom.com) ? checked that sssd-based authenticacion to the AD server works on this box (AD-users in domain da-dom.com) ? checked that the IPA server works for users created on the IPA server (domain e.g. user at ipa-dom.com) Now, to set up what we really wanted, which is basically, on a Unix-box with no sssd client, be able to authentica a user1 at da-dom.com via the FreeIPA-server, through sssd. But, the final step of the configuration process (cmd: ipa trust-add ...) requires to establish a two-way trust relationship between the IPA server and the AD DC, which requires AD administrator privileges (which we don't have, and I don't see why we should have them). The AD admins of the company are not willing to consider this trust relationship to be established because the regard this as a secury risk. My question is basically, isn't there a workaround for this situation? If sssd is already able to authenticate, and based on the explanations of the doc mentioned above, I can't see why for plaiin user authentication there must be a trust relationship established. We don't need that for any of our sssd-based hosts (and they haven't been added to the domain da-dom.com, no need to). Any suggestions? Maybe there are different setups and/or tool combinations for a this kind of scenario? Thanks a lot, -- *Gerardo Padierna* -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Aug 28 10:32:40 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 28 Aug 2014 12:32:40 +0200 Subject: [Freeipa-users] ipa-server (v3.3.3) with sssd (v1.11.2) config In-Reply-To: <53FEFF9B.80209@gmail.com> References: <53FEFF9B.80209@gmail.com> Message-ID: <53FF0548.6080203@redhat.com> On 08/28/2014 12:08 PM, Gerardo Padierna wrote: > Hi, > > In a setup where FreeIPA + sssd act as an authentication for AD users > (taking advantage of sssd's ability to act as an authentication client > for AD users), why do we need to establish a (two-way) trust > relationship? Ins't there a workaround for this, given that sssd is > already able to authenticate users without having to do nothing on the > DA-side (just need a read-only user to carry out the initial bind)? > > In a bit more detail: We'd like to use AD-based authentication on some > Unix hosts (mostly Solaris 10) for which there's no sssd available > (we're already using sssd on RHEL hosts); we were thinking of setting > up a server with FreeIPA + sssd to act as sort of a proxy to the > actual AD for authentication, for those hosts for which there's no > sssd client available (based on this doc: > http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts). > There reasons why we're doing this are basically: > ? there's no unix-compatibiliy available on the AD sever (and most > likely there won't ever be) > ? we'd like to keep the same UID/GIDs for all users that already > authenticate on the RHEL boxes (to be able to work on the same home > directories, maintain homogenous file ownership accross shared > ressources, etc.) > > So, we've set up: > ? a CentOS 7.0 host with ipa-server v3.3.3 and sssd v1.11.2 and > configured (with domain: ipa-dom.com) > ? checked that sssd-based authenticacion to the AD server works on > this box (AD-users in domain da-dom.com) > ? checked that the IPA server works for users created on the IPA > server (domain e.g. user at ipa-dom.com) > > Now, to set up what we really wanted, which is basically, on a > Unix-box with no sssd client, be able to authentica a user1 at da-dom.com > via the FreeIPA-server, through sssd. But, the final step of the > configuration process (cmd: ipa trust-add ...) requires to establish a > two-way trust relationship between the IPA server and the AD DC, which > requires AD administrator privileges (which we don't have, and I don't > see why we should have them). > The AD admins of the company are not willing to consider this trust > relationship to be established because the regard this as a secury risk. > > My question is basically, isn't there a workaround for this situation? > If sssd is already able to authenticate, and based on the explanations > of the doc mentioned above, I can't see why for plaiin user > authentication there must be a trust relationship established. We > don't need that for any of our sssd-based hosts (and they haven't been > added to the domain da-dom.com, no need to). > > Any suggestions? Maybe there are different setups and/or tool > combinations for a this kind of scenario? > > Thanks a lot, > > -- > > *Gerardo Padierna* > > > Will one way trust be acceptable by AD admins? Is there more prejudice to IdM connecting to AD in general or one way trust when IPA trusts AD but not the other way around is OK? It will still require admin privileges to establish the trust. There is already work going on to make the trust be one way by default since there is some confusion about it. Trusts are needed for Kerberos to be able to forward tickets and do SSO. Without trusts you can do only basic proxy setup which can be done with a DS server and PAM proxy plugin - a non goal for IPA. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Thu Aug 28 11:15:43 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Thu, 28 Aug 2014 14:15:43 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu Message-ID: <53FF0F5F.5000904@astron.yasar.com.tr> Hi, I try to apply sudo policies on ubuntu client. Is there any examples how to apply it? Regards... --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. From jhrozek at redhat.com Thu Aug 28 11:20:34 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 28 Aug 2014 13:20:34 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <53FF0F5F.5000904@astron.yasar.com.tr> References: <53FF0F5F.5000904@astron.yasar.com.tr> Message-ID: <20140828112034.GA3139@hendrix.brq.redhat.com> On Thu, Aug 28, 2014 at 02:15:43PM +0300, Tevfik Ceydeliler wrote: > > Hi, > I try to apply sudo policies on ubuntu client. > Is there any examples how to apply it? > Regards... Depends on your sssd and sudo versions but in general I don't think there are any Ubuntu-specific issues. As long as you have sssd 1.9+ and sudo 1.8+ you should be good. From ziplyx at gmail.com Thu Aug 28 14:18:47 2014 From: ziplyx at gmail.com (Zip Ly) Date: Thu, 28 Aug 2014 16:18:47 +0200 Subject: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin Message-ID: Hi, I'm trying to change a user password without reset. If I use the (primary) admin to change the password then it doesn't need a password reset, because the expire lifetime is 90 days. But if I create a second admin, then every password change made by the second admin needs a password reset, because the password is expired immediately. 1a) Does anyone knows how I can change the policy/privilege of the second admin so every password change doesn't require a reset? 1b) and is it possible to set a different expire lifetime like zero for unlimited lifetime? It's almost the same bugreport as https://fedorahosted.org/freeipa/ticket/2795 but the difference is there should be 2 policies: one for changing your own password and another for resetting other users password. 2) Are there more differences in policies between the first (primary) admin and the second admin you just created? Kind regards, Zip -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Aug 28 14:44:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 28 Aug 2014 16:44:07 +0200 Subject: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin In-Reply-To: References: Message-ID: <53FF4037.3040804@redhat.com> On 08/28/2014 04:18 PM, Zip Ly wrote: > Hi, > > > I'm trying to change a user password without reset. > If I use the (primary) admin to change the password then it doesn't need a > password reset, because the expire lifetime is 90 days. This is strange. Did you by any chance added this admin's account DN to passSyncManagersDNs setting in ipa_pwd_extop plugin? http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/pass-sync.html#password-sync > But if I create a second admin, then every password change made by the > second admin needs a password reset, because the password is expired > immediately. Right, this is done on purpose: http://www.freeipa.org/page/New_Passwords_Expired > 1a) Does anyone knows how I can change the policy/privilege of the second > admin so every password change doesn't require a reset? See docs link above. But note it is a hack and we discourage it for reasons written in the wiki link above. > 1b) and is it > possible to set a different expire lifetime like zero for unlimited > lifetime? No (for security reasons). > > It's almost the same bugreport as > https://fedorahosted.org/freeipa/ticket/2795 but the difference is there > should be 2 policies: one for changing your own password and another for > resetting other users password. Administrative password change is only subject to max password life time part of the password policy AFAIR. Thus it already uses 2 different standards for these password changes (e.g. password length is not enforced for administrative password change). > 2) Are there more differences in policies between the first (primary) admin > and the second admin you just created? There should not be. All members of admins groups should be equal in rights. Martin From mail at willsheldon.com Thu Aug 28 14:45:54 2014 From: mail at willsheldon.com (Will Sheldon) Date: Thu, 28 Aug 2014 07:45:54 -0700 Subject: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin In-Reply-To: References: Message-ID: 1a) has come up before: https://www.redhat.com/archives/freeipa-users/2014-February/msg00313.html 1b) We handled this by setting the expire lifetime to a very large value (20 years) for members of a certain group. 2) I?m not sure. Kind regards, Will Sheldon +1.778-689-1244 On August 28, 2014 at 7:26:03 AM, Zip Ly (ziplyx at gmail.com) wrote: Hi, ? ? I'm trying to change a user password without reset. If I use the (primary) admin to change the password then it doesn't need a password reset, because the expire?lifetime is 90 days. ? But if I create a second admin, then every password change made by the second admin needs a password reset, because the password is expired immediately. ? 1a) Does anyone knows how I can change the policy/privilege of the second admin so every password change doesn't require a reset? 1b)?and?is it possible?to?set a different expire?lifetime like zero for?unlimited lifetime? ? It's almost the same bugreport as https://fedorahosted.org/freeipa/ticket/2795 but the difference is there should be 2 policies: one for changing your own password and another for resetting other users password. ? ? 2) Are there more?differences in policies between the first?(primary) admin and the second admin you just created? ? ? Kind regards, ? Zip ? ? -- Manage your subscription for 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 cwhittl at gmail.com Thu Aug 28 14:56:31 2014 From: cwhittl at gmail.com (Chris Whittle) Date: Thu, 28 Aug 2014 09:56:31 -0500 Subject: [Freeipa-users] Disable Password Policy? Message-ID: We are going to use a SSO provider like OneLogin to enforce a password policy how can we disable FreeIPA from doing it also? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Aug 28 16:16:12 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 28 Aug 2014 18:16:12 +0200 Subject: [Freeipa-users] Disable Password Policy? In-Reply-To: References: Message-ID: <53FF55CC.6020803@redhat.com> On 08/28/2014 04:56 PM, Chris Whittle wrote: > We are going to use a SSO provider like OneLogin to enforce a password > policy how can we disable FreeIPA from doing it also? > > I do not think you can. You can make IPA policy less restrictive then it would just not apply. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Aug 28 16:18:45 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 28 Aug 2014 18:18:45 +0200 Subject: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin In-Reply-To: References: Message-ID: <53FF5665.9010403@redhat.com> On 08/28/2014 04:18 PM, Zip Ly wrote: > Hi, > I'm trying to change a user password without reset. > If I use the (primary) admin to change the password then it doesn't > need a password reset, because the expire lifetime is 90 days. > But if I create a second admin, then every password change made by the > second admin needs a password reset, because the password is expired > immediately. > 1a) Does anyone knows how I can change the policy/privilege of the > second admin so every password change doesn't require a reset? > 1b) and is it possible to set a different expire lifetime like zero > for unlimited lifetime? You are probably changing password for the admin himself. Isn't there a different flow when admin changes his own password? > It's almost the same bugreport as > https://fedorahosted.org/freeipa/ticket/2795 but the difference is > there should be 2 policies: one for changing your own password and > another for resetting other users password. > 2) Are there more differences in policies between the first (primary) > admin and the second admin you just created? > Kind regards, > Zip > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ziplyx at gmail.com Fri Aug 29 08:21:10 2014 From: ziplyx at gmail.com (Zip Ly) Date: Fri, 29 Aug 2014 10:21:10 +0200 Subject: [Freeipa-users] Password expiration dates are different when being resetted by the (primary) admin and a different admin In-Reply-To: <53FF5665.9010403@redhat.com> References: <53FF5665.9010403@redhat.com> Message-ID: @Martin 1) Yes, I did executed 8.5.3 from the wiki. Is this is reason for the systems behaviour? if so why doesnt't it applies for both admins? And it doesn't explain the 90 days, because it is not set in the tutorial. Unless some params are left out of the wiki for some reason. I'm using windows LDAP admin tool to browse the LDAP tree, but couln't find this param/value so I wasn't sure if the new setting is being used. I did get a confirmation while executing the change. @Dimitri 1) Yes, there are no problems with changing your own password. There is only something strange with the expiration lifetime when you are changing other users (admin or non-admin) password. The expiration lifetime of a password reset should be equal to BOTH admins like expired immediately, 90 days or the value that is set in the password policy. I prefer the value in a password policy, because this way I have it more under control. @Martin & @Will 1b) Ok, I'm afraid you may say that. Most free clients like gmail, hotmail, ebay, paypal doesn't require a password reset from time to time (yes they may have set a very high value). So I was wondering why it isn't possible. I know it's bad for security, but still. On Thu, Aug 28, 2014 at 6:18 PM, Dmitri Pal wrote: > On 08/28/2014 04:18 PM, Zip Ly wrote: > > Hi, > > > I'm trying to change a user password without reset. > If I use the (primary) admin to change the password then it doesn't need a > password reset, because the expire lifetime is 90 days. > > But if I create a second admin, then every password change made by the > second admin needs a password reset, because the password is expired > immediately. > > 1a) Does anyone knows how I can change the policy/privilege of the > second admin so every password change doesn't require a reset? 1b) and is > it possible to set a different expire lifetime like zero for unlimited > lifetime? > > > You are probably changing password for the admin himself. > Isn't there a different flow when admin changes his own password? > > > > It's almost the same bugreport as > https://fedorahosted.org/freeipa/ticket/2795 but the difference is there > should be 2 policies: one for changing your own password and another for > resetting other users password. > > > 2) Are there more differences in policies between the first (primary) > admin and the second admin you just created? > > > Kind regards, > > Zip > > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Aug 29 08:27:19 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 29 Aug 2014 10:27:19 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <54001E1F.1090304@astron.yasar.com.tr> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140828112034.GA3139@hendrix.brq.redhat.com> <53FF183F.9050801@astron.yasar.com.tr> <20140828142103.GD3139@hendrix.brq.redhat.com> <54001E1F.1090304@astron.yasar.com.tr> Message-ID: <20140829082719.GS3139@hendrix.brq.redhat.com> On Fri, Aug 29, 2014 at 09:30:55AM +0300, Tevfik Ceydeliler wrote: > > Here is my configuration adn client output. I dont know what is wrong Please keep the freeipa-users list in the CC list; other users might run into the same problem. > ======================================================= > Server Side: > [root at srv ~]# ipa sudorule-find > ------------------- > 1 Sudo Rule matched > ------------------- > Rule name: log-reading > Enabled: TRUE > Users: kduser1, user1 > Hosts: clnt2.ipa.grp, clnt.ipa.grp > Sudo Allow Commands: /usr/bin/less, /usr/bin/vi, /usr/bin/yum, > /usr/bin/apt- > get > Sudo Option: !authenticate > ---------------------------- > Number of entries returned 1 > ---------------------------- > > > And client side: > 1. nsswitch.con: > > # /etc/nsswitch.conf > # > # Example configuration of GNU Name Service Switch functionality. > # If you have the `glibc-doc-reference' and `info' packages installed, try: > # `info libc "Name Service Switch"' for information about this file. > > passwd: compat sss > group: compat sss > shadow: compat > > hosts: files mdns4_minimal [NOTFOUND=return] dns > networks: files > > protocols: sss files > services: sss files > ethers: sss files > rpc: sss files > > netgroup: nis sss > sudoers: files sss > sudoers_debug: 1 > > 2. sssd.conf: > > [domain/ipa.grp] > krb5_realm = IPA.GRP > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = ipa.grp > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = clnt.ipa.grp > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, srv.ipa.grp > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > domains = ipa.grp > [nss] > homedir_substring = /home > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > ldap_sudo_search_base = ou=sudoers,ou=ipa,dc=grp > ldap_sasl_mech = GSSAPI > ldap=sasl_authid = host/cnlt2.ipa.grp > ldap_sasl_realm = IPA.GRP > ldap_netgroup_search_base = ou=SUDOers,dc=ipa,dc=grp > sudo_provider = ldap > ldap_uri = ldap://srv.ipa.grp > krb5_server = srv.ipa.grp These options belong to the [domain] section, you put them into the [pac] section. > > When I try to use sudo: > > user1 at clnt:~$ sudo -i user1 vi apt-get update > [sudo] password for user1: > Sorry, user user1 is not allowed to execute '/bin/bash -c user1 vi apt-get > update' as root on clnt.ipa.grp. > user1 at clnt:~$ > > ======================================================= > On 28-08-2014 17:21, Jakub Hrozek wrote: > >On Thu, Aug 28, 2014 at 02:53:35PM +0300, Tevfik Ceydeliler wrote: > >>After configuration, for example, I try to create policiy about sudo > >>command, let's say I want to run "apt-get" command bu sudoas client > >> > >>How can I use it in client side? > >>Any example? > >I still don't understand what you mean, did you check out the 'ipa > >sudorule-add-runasuser' command? > > -- > > >
> >

> Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. From tevfik.ceydeliler at astron.yasar.com.tr Fri Aug 29 08:54:42 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Fri, 29 Aug 2014 11:54:42 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140829082719.GS3139@hendrix.brq.redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140828112034.GA3139@hendrix.brq.redhat.com> <53FF183F.9050801@astron.yasar.com.tr> <20140828142103.GD3139@hendrix.brq.redhat.com> <54001E1F.1090304@astron.yasar.com.tr> <20140829082719.GS3139@hendrix.brq.redhat.com> Message-ID: <54003FD2.5020106@astron.yasar.com.tr> ok sorry. On 29-08-2014 11:27, Jakub Hrozek wrote: > On Fri, Aug 29, 2014 at 09:30:55AM +0300, Tevfik Ceydeliler wrote: >> Here is my configuration adn client output. I dont know what is wrong > Please keep the freeipa-users list in the CC list; other users might run > into the same problem. > >> ======================================================= >> Server Side: >> [root at srv ~]# ipa sudorule-find >> ------------------- >> 1 Sudo Rule matched >> ------------------- >> Rule name: log-reading >> Enabled: TRUE >> Users: kduser1, user1 >> Hosts: clnt2.ipa.grp, clnt.ipa.grp >> Sudo Allow Commands: /usr/bin/less, /usr/bin/vi, /usr/bin/yum, >> /usr/bin/apt- >> get >> Sudo Option: !authenticate >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> >> And client side: >> 1. nsswitch.con: >> >> # /etc/nsswitch.conf >> # >> # Example configuration of GNU Name Service Switch functionality. >> # If you have the `glibc-doc-reference' and `info' packages installed, try: >> # `info libc "Name Service Switch"' for information about this file. >> >> passwd: compat sss >> group: compat sss >> shadow: compat >> >> hosts: files mdns4_minimal [NOTFOUND=return] dns >> networks: files >> >> protocols: sss files >> services: sss files >> ethers: sss files >> rpc: sss files >> >> netgroup: nis sss >> sudoers: files sss >> sudoers_debug: 1 >> >> 2. sssd.conf: >> >> [domain/ipa.grp] >> krb5_realm = IPA.GRP >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = ipa.grp >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = clnt.ipa.grp >> chpass_provider = ipa >> ipa_dyndns_update = True >> ipa_server = _srv_, srv.ipa.grp >> ldap_tls_cacert = /etc/ipa/ca.crt >> [sssd] >> services = nss, pam, ssh, sudo >> config_file_version = 2 >> domains = ipa.grp >> [nss] >> homedir_substring = /home >> [pam] >> >> [sudo] >> >> [autofs] >> >> [ssh] >> >> [pac] >> >> ldap_sudo_search_base = ou=sudoers,ou=ipa,dc=grp >> ldap_sasl_mech = GSSAPI >> ldap=sasl_authid = host/cnlt2.ipa.grp >> ldap_sasl_realm = IPA.GRP >> ldap_netgroup_search_base = ou=SUDOers,dc=ipa,dc=grp >> sudo_provider = ldap >> ldap_uri = ldap://srv.ipa.grp >> krb5_server = srv.ipa.grp > These options belong to the [domain] section, you put them into the > [pac] section. > >> When I try to use sudo: >> >> user1 at clnt:~$ sudo -i user1 vi apt-get update >> [sudo] password for user1: >> Sorry, user user1 is not allowed to execute '/bin/bash -c user1 vi apt-get >> update' as root on clnt.ipa.grp. >> user1 at clnt:~$ >> >> ======================================================= >> On 28-08-2014 17:21, Jakub Hrozek wrote: >>> On Thu, Aug 28, 2014 at 02:53:35PM +0300, Tevfik Ceydeliler wrote: >>>> After configuration, for example, I try to create policiy about sudo >>>> command, let's say I want to run "apt-get" command bu sudoas client >>>> >>>> How can I use it in client side? >>>> Any example? >>> I still don't understand what you mean, did you check out the 'ipa >>> sudorule-add-runasuser' command? >> -- >> >> >>
>> >>

>> Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From tevfik.ceydeliler at astron.yasar.com.tr Fri Aug 29 10:15:28 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Fri, 29 Aug 2014 13:15:28 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140829082719.GS3139@hendrix.brq.redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140828112034.GA3139@hendrix.brq.redhat.com> <53FF183F.9050801@astron.yasar.com.tr> <20140828142103.GD3139@hendrix.brq.redhat.com> <54001E1F.1090304@astron.yasar.com.tr> <20140829082719.GS3139@hendrix.brq.redhat.com> Message-ID: <540052C0.2000202@astron.yasar.com.tr> I moved these configuration lines under [domain] section. Then reboot the client. But same result.. On 29-08-2014 11:27, Jakub Hrozek wrote: > On Fri, Aug 29, 2014 at 09:30:55AM +0300, Tevfik Ceydeliler wrote: >> Here is my configuration adn client output. I dont know what is wrong > Please keep the freeipa-users list in the CC list; other users might run > into the same problem. > >> ======================================================= >> Server Side: >> [root at srv ~]# ipa sudorule-find >> ------------------- >> 1 Sudo Rule matched >> ------------------- >> Rule name: log-reading >> Enabled: TRUE >> Users: kduser1, user1 >> Hosts: clnt2.ipa.grp, clnt.ipa.grp >> Sudo Allow Commands: /usr/bin/less, /usr/bin/vi, /usr/bin/yum, >> /usr/bin/apt- >> get >> Sudo Option: !authenticate >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> >> And client side: >> 1. nsswitch.con: >> >> # /etc/nsswitch.conf >> # >> # Example configuration of GNU Name Service Switch functionality. >> # If you have the `glibc-doc-reference' and `info' packages installed, try: >> # `info libc "Name Service Switch"' for information about this file. >> >> passwd: compat sss >> group: compat sss >> shadow: compat >> >> hosts: files mdns4_minimal [NOTFOUND=return] dns >> networks: files >> >> protocols: sss files >> services: sss files >> ethers: sss files >> rpc: sss files >> >> netgroup: nis sss >> sudoers: files sss >> sudoers_debug: 1 >> >> 2. sssd.conf: >> >> [domain/ipa.grp] >> krb5_realm = IPA.GRP >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = ipa.grp >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = clnt.ipa.grp >> chpass_provider = ipa >> ipa_dyndns_update = True >> ipa_server = _srv_, srv.ipa.grp >> ldap_tls_cacert = /etc/ipa/ca.crt >> [sssd] >> services = nss, pam, ssh, sudo >> config_file_version = 2 >> domains = ipa.grp >> [nss] >> homedir_substring = /home >> [pam] >> >> [sudo] >> >> [autofs] >> >> [ssh] >> >> [pac] >> >> ldap_sudo_search_base = ou=sudoers,ou=ipa,dc=grp >> ldap_sasl_mech = GSSAPI >> ldap=sasl_authid = host/cnlt2.ipa.grp >> ldap_sasl_realm = IPA.GRP >> ldap_netgroup_search_base = ou=SUDOers,dc=ipa,dc=grp >> sudo_provider = ldap >> ldap_uri = ldap://srv.ipa.grp >> krb5_server = srv.ipa.grp > These options belong to the [domain] section, you put them into the > [pac] section. > >> When I try to use sudo: >> >> user1 at clnt:~$ sudo -i user1 vi apt-get update >> [sudo] password for user1: >> Sorry, user user1 is not allowed to execute '/bin/bash -c user1 vi apt-get >> update' as root on clnt.ipa.grp. >> user1 at clnt:~$ >> >> ======================================================= >> On 28-08-2014 17:21, Jakub Hrozek wrote: >>> On Thu, Aug 28, 2014 at 02:53:35PM +0300, Tevfik Ceydeliler wrote: >>>> After configuration, for example, I try to create policiy about sudo >>>> command, let's say I want to run "apt-get" command bu sudoas client >>>> >>>> How can I use it in client side? >>>> Any example? >>> I still don't understand what you mean, did you check out the 'ipa >>> sudorule-add-runasuser' command? >> -- >> >> >>
>> >>

>> Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From jhrozek at redhat.com Fri Aug 29 11:23:30 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 29 Aug 2014 13:23:30 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <540052C0.2000202@astron.yasar.com.tr> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140828112034.GA3139@hendrix.brq.redhat.com> <53FF183F.9050801@astron.yasar.com.tr> <20140828142103.GD3139@hendrix.brq.redhat.com> <54001E1F.1090304@astron.yasar.com.tr> <20140829082719.GS3139@hendrix.brq.redhat.com> <540052C0.2000202@astron.yasar.com.tr> Message-ID: <20140829112330.GA3139@hendrix.brq.redhat.com> On Fri, Aug 29, 2014 at 01:15:28PM +0300, Tevfik Ceydeliler wrote: > > I moved these configuration lines under [domain] section. Then reboot the > client. But same result.. Please make sure libsss_sudo is installed. If it is, then we need to see the logs from the [sudo] and [domain] sections of sssd.conf From bret.wortman at damascusgrp.com Fri Aug 29 12:31:02 2014 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 29 Aug 2014 08:31:02 -0400 Subject: [Freeipa-users] GSSAPIAuthentication setting in /etc/sshd_config? Message-ID: <54007286.3040406@damascusgrp.com> Does this really need to be set to "yes" in /etc/sshd_config? I've looked through the documentation and it only seems to say this for HP-UX and AIX. We're running freeipa 3.3.5-1 and are seeing some slow logins via ssh that some users have reported speed up markedly when this setting is toggled to "no". Before I make any wholesale change recommendations, I wanted to check on this. Thanks! -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 51f7de33e4b08d2bdb8b4860 Type: image/png Size: 28526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From simo at redhat.com Fri Aug 29 12:39:18 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 29 Aug 2014 08:39:18 -0400 Subject: [Freeipa-users] GSSAPIAuthentication setting in /etc/sshd_config? In-Reply-To: <54007286.3040406@damascusgrp.com> References: <54007286.3040406@damascusgrp.com> Message-ID: <1409315958.6483.47.camel@willson.usersys.redhat.com> On Fri, 2014-08-29 at 08:31 -0400, Bret Wortman wrote: > Does this really need to be set to "yes" in /etc/sshd_config? I've > looked through the documentation and it only seems to say this for HP-UX > and AIX. If you want to do SSO login (ie passwordless) you need that on. > We're running freeipa 3.3.5-1 and are seeing some slow logins via ssh > that some users have reported speed up markedly when this setting is > toggled to "no". Before I make any wholesale change recommendations, I > wanted to check on this. Users may fail to name the server properly, or servers may not have keytabs, what I suggest is for users to add exceptions in their .ssh/config so that their client skips trying SSO auth for hosts that are known to fail to provide it. Something like: Host fails.example.com User root GSSAPIAuthentication no HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From tevfik.ceydeliler at astron.yasar.com.tr Fri Aug 29 12:45:38 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Fri, 29 Aug 2014 15:45:38 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140829112330.GA3139@hendrix.brq.redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140828112034.GA3139@hendrix.brq.redhat.com> <53FF183F.9050801@astron.yasar.com.tr> <20140828142103.GD3139@hendrix.brq.redhat.com> <54001E1F.1090304@astron.yasar.com.tr> <20140829082719.GS3139@hendrix.brq.redhat.com> <540052C0.2000202@astron.yasar.com.tr> <20140829112330.GA3139@hendrix.brq.redhat.com> Message-ID: <540075F2.8010906@astron.yasar.com.tr> this package is installed root at clnt:/home/awtadm# apt-get install libsss-sudo Reading package lists... Done Building dependency tree Reading state information... Done libsss-sudo is already the newest version. libsss-sudo set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded. sssd_sudo and sssd_domain logs are empty under /var/log/sssd On 29-08-2014 14:23, Jakub Hrozek wrote: > On Fri, Aug 29, 2014 at 01:15:28PM +0300, Tevfik Ceydeliler wrote: >> I moved these configuration lines under [domain] section. Then reboot the >> client. But same result.. > Please make sure libsss_sudo is installed. If it is, then we need to see > the logs from the [sudo] and [domain] sections of sssd.conf --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 15216 bytes Desc: not available URL: From jhrozek at redhat.com Fri Aug 29 13:07:08 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 29 Aug 2014 15:07:08 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <540075F2.8010906@astron.yasar.com.tr> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140828112034.GA3139@hendrix.brq.redhat.com> <53FF183F.9050801@astron.yasar.com.tr> <20140828142103.GD3139@hendrix.brq.redhat.com> <54001E1F.1090304@astron.yasar.com.tr> <20140829082719.GS3139@hendrix.brq.redhat.com> <540052C0.2000202@astron.yasar.com.tr> <20140829112330.GA3139@hendrix.brq.redhat.com> <540075F2.8010906@astron.yasar.com.tr> Message-ID: <20140829130708.GC3139@hendrix.brq.redhat.com> On Fri, Aug 29, 2014 at 03:45:38PM +0300, Tevfik Ceydeliler wrote: > > this package is installed > > root at clnt:/home/awtadm# apt-get install libsss-sudo > Reading package lists... Done > Building dependency tree > Reading state information... Done > libsss-sudo is already the newest version. > libsss-sudo set to manually installed. > 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded. > > sssd_sudo and sssd_domain logs are empty under /var/log/sssd You need to put debug_level=N into the [sssd] and [domain] sections, restart sssd, then you'll have some logs. We only log critical failures by default. 6 is a good start for the log level usually. > > On 29-08-2014 14:23, Jakub Hrozek wrote: > >On Fri, Aug 29, 2014 at 01:15:28PM +0300, Tevfik Ceydeliler wrote: > >>I moved these configuration lines under [domain] section. Then reboot the > >>client. But same result.. > >Please make sure libsss_sudo is installed. If it is, then we need to see > >the logs from the [sudo] and [domain] sections of sssd.conf > > -- > > >
> >

> Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. From jhrozek at redhat.com Fri Aug 29 13:14:45 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 29 Aug 2014 15:14:45 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140829130708.GC3139@hendrix.brq.redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140828112034.GA3139@hendrix.brq.redhat.com> <53FF183F.9050801@astron.yasar.com.tr> <20140828142103.GD3139@hendrix.brq.redhat.com> <54001E1F.1090304@astron.yasar.com.tr> <20140829082719.GS3139@hendrix.brq.redhat.com> <540052C0.2000202@astron.yasar.com.tr> <20140829112330.GA3139@hendrix.brq.redhat.com> <540075F2.8010906@astron.yasar.com.tr> <20140829130708.GC3139@hendrix.brq.redhat.com> Message-ID: <20140829131445.GD3139@hendrix.brq.redhat.com> On Fri, Aug 29, 2014 at 03:07:08PM +0200, Jakub Hrozek wrote: > On Fri, Aug 29, 2014 at 03:45:38PM +0300, Tevfik Ceydeliler wrote: > > > > this package is installed > > > > root at clnt:/home/awtadm# apt-get install libsss-sudo > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > libsss-sudo is already the newest version. > > libsss-sudo set to manually installed. > > 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded. > > > > sssd_sudo and sssd_domain logs are empty under /var/log/sssd > > You need to put debug_level=N into the [sssd] and [domain] sections, Sorry I meant to say [sudo] and [domain] sections. > restart sssd, then you'll have some logs. We only log critical failures > by default. > > 6 is a good start for the log level usually. > > > > > On 29-08-2014 14:23, Jakub Hrozek wrote: > > >On Fri, Aug 29, 2014 at 01:15:28PM +0300, Tevfik Ceydeliler wrote: > > >>I moved these configuration lines under [domain] section. Then reboot the > > >>client. But same result.. > > >Please make sure libsss_sudo is installed. If it is, then we need to see > > >the logs from the [sudo] and [domain] sections of sssd.conf > > > > -- > > > > > >
> > > >

> > Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From lslebodn at redhat.com Fri Aug 29 13:44:43 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 29 Aug 2014 15:44:43 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <53FF0F5F.5000904@astron.yasar.com.tr> References: <53FF0F5F.5000904@astron.yasar.com.tr> Message-ID: <20140829134442.GA11446@mail.corp.redhat.com> On (28/08/14 14:15), Tevfik Ceydeliler wrote: > >Hi, >I try to apply sudo policies on ubuntu client. >Is there any examples how to apply it? >Regards... You may be interested in this presentation. http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf LS From tevfik.ceydeliler at astron.yasar.com.tr Fri Aug 29 14:37:06 2014 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Fri, 29 Aug 2014 17:37:06 +0300 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <20140829134442.GA11446@mail.corp.redhat.com> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> Message-ID: <54009012.10903@astron.yasar.com.tr> Thnx for document. I know this. I think there is no problem abot configuration generally. Maybe some nish details. Problem is why dont work in my test env. On 29-08-2014 16:44, Lukas Slebodnik wrote: > On (28/08/14 14:15), Tevfik Ceydeliler wrote: >> Hi, >> I try to apply sudo policies on ubuntu client. >> Is there any examples how to apply it? >> Regards... > You may be interested in this presentation. > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > > LS --


Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.png Type: image/png Size: 15216 bytes Desc: not available URL: From lslebodn at redhat.com Fri Aug 29 14:53:54 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 29 Aug 2014 16:53:54 +0200 Subject: [Freeipa-users] How to use sudo rules on ubuntu In-Reply-To: <54009012.10903@astron.yasar.com.tr> References: <53FF0F5F.5000904@astron.yasar.com.tr> <20140829134442.GA11446@mail.corp.redhat.com> <54009012.10903@astron.yasar.com.tr> Message-ID: <20140829145354.GB11446@mail.corp.redhat.com> On (29/08/14 17:37), Tevfik Ceydeliler wrote: > >Thnx for document. I know this. >I think there is no problem abot configuration generally. Maybe some nish >details. >Problem is why dont work in my test env. > Could you write more details about version of sssd, sudo? Which ubuntu release do you use? ... LS From kyle.flavin at gmail.com Fri Aug 29 16:33:53 2014 From: kyle.flavin at gmail.com (Kyle Flavin) Date: Fri, 29 Aug 2014 09:33:53 -0700 Subject: [Freeipa-users] IPA, Multiple Backends Message-ID: I'm doing some testing to integrate FreeIPA into my environment. I need to setup two domains in sssd.conf; One is my fresh install of IPA, and the other is our legacy LDAP environment. I want to use IPA for ssh logins to servers. I want to be able to grant/deny SSH access through IPA. However, I still need the legacy LDAP connected to ensure our servers still see the same file level permissions in their content directories. I added two domains to SSSD (config below), and it works fine as far as seeing all accounts and groups. My problem is, SSSD is now allowing SSH access from both IPA and from LDAP. I don't want users in our legacy LDAP environment to be able to login to servers. Is there a way to say "allow SSH from this domain", and "disallow SSH from this other domain"? Sanitized version of my sssd.conf: [domain/newipa.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = newipa.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client.newipa.com chpass_provider = ipa ipa_server = _srv_, ipaserver.newipa.com ldap_tls_cacert = /etc/ipa/ca.crt [domain/oldldap.com] #legacy LDAP ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=oldldap,dc=com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://ldapserver.oldldap.com #ldap_tls_cacertdir = /etc/openldap/cacerts ldap_tls_reqcert = never [sssd] services = nss, pam, ssh config_file_version = 2 domains = newipa.com, oldldap.com Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Aug 29 16:43:41 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 29 Aug 2014 18:43:41 +0200 Subject: [Freeipa-users] IPA, Multiple Backends In-Reply-To: References: Message-ID: <4F28DF70-F106-4A12-95CD-464EEC8F972B@redhat.com> On 29 Aug 2014, at 18:33, Kyle Flavin wrote: > I'm doing some testing to integrate FreeIPA into my environment. I need to setup two domains in sssd.conf; One is my fresh install of IPA, and the other is our legacy LDAP environment. > > I want to use IPA for ssh logins to servers. I want to be able to grant/deny SSH access through IPA. However, I still need the legacy LDAP connected to ensure our servers still see the same file level permissions in their content directories. > > I added two domains to SSSD (config below), and it works fine as far as seeing all accounts and groups. My problem is, SSSD is now allowing SSH access from both IPA and from LDAP. I don't want users in our legacy LDAP environment to be able to login to servers. Is there a way to say "allow SSH from this domain", and "disallow SSH from this other domain?? Can you try auth_provider=none in the domain that is not supposed to authenticate? > > Sanitized version of my sssd.conf: > > [domain/newipa.com] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = newipa.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = client.newipa.com > chpass_provider = ipa > ipa_server = _srv_, ipaserver.newipa.com > ldap_tls_cacert = /etc/ipa/ca.crt > > [domain/oldldap.com] > #legacy LDAP > ldap_id_use_start_tls = True > cache_credentials = True > ldap_search_base = dc=oldldap,dc=com > id_provider = ldap > auth_provider = ldap > chpass_provider = ldap > ldap_uri = ldap://ldapserver.oldldap.com > #ldap_tls_cacertdir = /etc/openldap/cacerts > ldap_tls_reqcert = never > > > [sssd] > services = nss, pam, ssh > config_file_version = 2 > domains = newipa.com, oldldap.com > > > Thanks. > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go To http://freeipa.org for more info on the project From mohammadsereshki at yahoo.com Fri Aug 29 16:06:48 2014 From: mohammadsereshki at yahoo.com (mohammad sereshki) Date: Fri, 29 Aug 2014 09:06:48 -0700 Subject: [Freeipa-users] IPuser can't authenticated with sssd In-Reply-To: <1406493413.17348.YahooMailNeo@web161504.mail.bf1.yahoo.com> References: <1406493413.17348.YahooMailNeo@web161504.mail.bf1.yahoo.com> Message-ID: <1409328408.25274.YahooMailNeo@web161505.mail.bf1.yahoo.com> Hi I have configured IPA(ipa-client-2.1.3-7.el5) but the problem is that Ican connect with kerberos from another client but I can't login to client directly and I chet below error ?pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.211.166 user= Please help me if you can ,I'm under pressure to fix it :( my os is centos 5.8 and kernel is ?2.6.18-348.16.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.flavin at gmail.com Fri Aug 29 16:57:12 2014 From: kyle.flavin at gmail.com (Kyle Flavin) Date: Fri, 29 Aug 2014 09:57:12 -0700 Subject: [Freeipa-users] IPA, Multiple Backends In-Reply-To: <4F28DF70-F106-4A12-95CD-464EEC8F972B@redhat.com> References: <4F28DF70-F106-4A12-95CD-464EEC8F972B@redhat.com> Message-ID: Hi Jacob, I'll give that a try shortly, and update with the result. On Fri, Aug 29, 2014 at 9:43 AM, Jakub Hrozek wrote: > > On 29 Aug 2014, at 18:33, Kyle Flavin wrote: > > > I'm doing some testing to integrate FreeIPA into my environment. I need > to setup two domains in sssd.conf; One is my fresh install of IPA, and the > other is our legacy LDAP environment. > > > > I want to use IPA for ssh logins to servers. I want to be able to > grant/deny SSH access through IPA. However, I still need the legacy LDAP > connected to ensure our servers still see the same file level permissions > in their content directories. > > > > I added two domains to SSSD (config below), and it works fine as far as > seeing all accounts and groups. My problem is, SSSD is now allowing SSH > access from both IPA and from LDAP. I don't want users in our legacy LDAP > environment to be able to login to servers. Is there a way to say "allow > SSH from this domain", and "disallow SSH from this other domain?? > > Can you try auth_provider=none in the domain that is not supposed to > authenticate? > > > > > > > Sanitized version of my sssd.conf: > > > > [domain/newipa.com] > > cache_credentials = True > > krb5_store_password_if_offline = True > > ipa_domain = newipa.com > > id_provider = ipa > > auth_provider = ipa > > access_provider = ipa > > ipa_hostname = client.newipa.com > > chpass_provider = ipa > > ipa_server = _srv_, ipaserver.newipa.com > > ldap_tls_cacert = /etc/ipa/ca.crt > > > > [domain/oldldap.com] > > #legacy LDAP > > ldap_id_use_start_tls = True > > cache_credentials = True > > ldap_search_base = dc=oldldap,dc=com > > id_provider = ldap > > auth_provider = ldap > > chpass_provider = ldap > > ldap_uri = ldap://ldapserver.oldldap.com > > #ldap_tls_cacertdir = /etc/openldap/cacerts > > ldap_tls_reqcert = never > > > > > > [sssd] > > services = nss, pam, ssh > > config_file_version = 2 > > domains = newipa.com, oldldap.com > > > > > > Thanks. > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go To http://freeipa.org for more info on the project > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.flavin at gmail.com Fri Aug 29 17:44:22 2014 From: kyle.flavin at gmail.com (Kyle Flavin) Date: Fri, 29 Aug 2014 10:44:22 -0700 Subject: [Freeipa-users] IPA, Multiple Backends In-Reply-To: References: <4F28DF70-F106-4A12-95CD-464EEC8F972B@redhat.com> Message-ID: That's doing what I need! Thank you. On Fri, Aug 29, 2014 at 9:57 AM, Kyle Flavin wrote: > Hi Jacob, > I'll give that a try shortly, and update with the result. > > > On Fri, Aug 29, 2014 at 9:43 AM, Jakub Hrozek wrote: > >> >> On 29 Aug 2014, at 18:33, Kyle Flavin wrote: >> >> > I'm doing some testing to integrate FreeIPA into my environment. I >> need to setup two domains in sssd.conf; One is my fresh install of IPA, and >> the other is our legacy LDAP environment. >> > >> > I want to use IPA for ssh logins to servers. I want to be able to >> grant/deny SSH access through IPA. However, I still need the legacy LDAP >> connected to ensure our servers still see the same file level permissions >> in their content directories. >> > >> > I added two domains to SSSD (config below), and it works fine as far as >> seeing all accounts and groups. My problem is, SSSD is now allowing SSH >> access from both IPA and from LDAP. I don't want users in our legacy LDAP >> environment to be able to login to servers. Is there a way to say "allow >> SSH from this domain", and "disallow SSH from this other domain?? >> >> Can you try auth_provider=none in the domain that is not supposed to >> authenticate? >> >> >> > >> >> > Sanitized version of my sssd.conf: >> > >> > [domain/newipa.com] >> > cache_credentials = True >> > krb5_store_password_if_offline = True >> > ipa_domain = newipa.com >> > id_provider = ipa >> > auth_provider = ipa >> > access_provider = ipa >> > ipa_hostname = client.newipa.com >> > chpass_provider = ipa >> > ipa_server = _srv_, ipaserver.newipa.com >> > ldap_tls_cacert = /etc/ipa/ca.crt >> > >> > [domain/oldldap.com] >> > #legacy LDAP >> > ldap_id_use_start_tls = True >> > cache_credentials = True >> > ldap_search_base = dc=oldldap,dc=com >> > id_provider = ldap >> > auth_provider = ldap >> > chpass_provider = ldap >> > ldap_uri = ldap://ldapserver.oldldap.com >> > #ldap_tls_cacertdir = /etc/openldap/cacerts >> > ldap_tls_reqcert = never >> > >> > >> > [sssd] >> > services = nss, pam, ssh >> > config_file_version = 2 >> > domains = newipa.com, oldldap.com >> > >> > >> > Thanks. >> > -- >> > Manage your subscription for the Freeipa-users mailing list: >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> > Go To http://freeipa.org for more info on the project >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Aug 29 18:05:16 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 29 Aug 2014 20:05:16 +0200 Subject: [Freeipa-users] IPuser can't authenticated with sssd In-Reply-To: <1409328408.25274.YahooMailNeo@web161505.mail.bf1.yahoo.com> References: <1406493413.17348.YahooMailNeo@web161504.mail.bf1.yahoo.com> <1409328408.25274.YahooMailNeo@web161505.mail.bf1.yahoo.com> Message-ID: <5400C0DC.5050306@redhat.com> On 08/29/2014 06:06 PM, mohammad sereshki wrote: > Hi > I have configured IPA(ipa-client-2.1.3-7.el5) but the problem is that > Ican connect with kerberos from another client but I can't login to > client directly and I chet below error > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 > tty=ssh ruser= rhost=192.168.211.166 user= > > Please help me if you can ,I'm under pressure to fix it :( > > > my os is centos 5.8 and kernel is > 2.6.18-348.16.1 > > Put debug_level=6 or higher into sssd.conf into your pam, nss and domain sections, restart sssd and send us the sanitized logs of your login try. Also sssd.conf and pam.conf as well as ssh configuration would be helpful. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at indigo.nu Fri Aug 29 19:32:39 2014 From: matt at indigo.nu (Matthew Sellers) Date: Fri, 29 Aug 2014 14:32:39 -0500 Subject: [Freeipa-users] FreeIPA bind also-notify behavior. Message-ID: Hi Everyone! I am using FreeIPA 3.3.5 on Fedora 20 and attempting to configure FreeIPA to send notifies to non-IPA slaves, but it seems broken on IPA ( notify packets are never sent to to slaves ). I have configured also-notify { nameserverip; }; in named.conf on my FreeIPA test host in the options section and watched for notify traffic with tcpdump. This document suggests that this is supported, and this is something I have used in non-IPA bind servers with no issues. https://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_zone_transfer I wanted to ask the list before I file a bug with more details. Is anyone using this bind feature on IPA with any success? Thanks! Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: