July 2017 - FreeIPA-users - Fedora mailing-lists

Can't create new CA replica
by john.bowman＠zayo.com 17 Nov '17

17 Nov '17

Since taking over our FreeIPA environment I've been unable to create a new CA replica. A bunch of failed attempts and upgrades over the last year and I keep running in to issues. After my latest attempt I noticed something that I had not seen before (likely a result of an recent upgrade) and I was wondering if this would cause a CA install to fail. Our env: 3 x ipa-server-3.0.0-51.el6.x86_64 3 x ipa-server-4.4.0-14.el7_3.7.x86_64 2 of the 3.x IPA servers are currently acting as CAs and I've been trying to create a new 4.x CA replica in order to start removing the 3.x IPA servers. I've been able to do a simple test with vanilla CentOS 6.9 and 7.3 and it seems to work fine as far as I can tell but when I try it in our environment it fails. I noticed this error in one of the logs and something jumped out at me that I had never seen before: [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: === Finalization === [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: Updating existing security domain [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: isSDHostDomainMaster(): Getting domain.xml from CA... [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: getting domain info [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: GET https://ipa-master.domain.tld:443/ca/admin/ca/getDomainXML [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: status: 0 [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: domain info: <?xml version="1.0" encoding="UTF-8" standalone="no"?><DomainInfo><Name>IPA</Name><CAList><CA ><Host>ipa-master.domain.tld</Host><SecurePort>443</SecurePort><SecureAgentPort>443</SecureAgentPort><SecureAdminPort>443</SecureAdminPort><UnSecurePort>80</UnSecurePort><Sec ureEEClientAuthPort>443</SecureEEClientAuthPort><DomainManager>TRUE</DomainManager><Clone>TRUE</Clone><SubsystemName>pki-cad</SubsystemName></CA><CA><Host>ipa-replica1.domain.tld </Host><SecurePort>443</SecurePort><SecureAgentPort>443</SecureAgentPort><SecureAdminPort>443</SecureAdminPort><UnSecurePort>80</UnSecurePort><SecureEEClientAuthPort>443</S ecureEEClientAuthPort><DomainManager>TRUE</DomainManager><Clone>TRUE</Clone><SubsystemName>pki-cad</SubsystemName></CA><CA><Host>ipa-replica2.domain.tld</Host><SecurePort>443</Se curePort><SecureAgentPort>443</SecureAgentPort><SecureAdminPort>443</SecureAdminPort><UnSecurePort>80</UnSecurePort><SecureEEClientAuthPort>443</SecureEEClientAuthPort><Dom ainManager>TRUE</DomainManager><Clone>TRUE</Clone><SubsystemName>pki-cad</SubsystemName></CA><SubsystemCount>3</SubsystemCount></CAList><OCSPList><SubsystemCount>0</Subsyst emCount></OCSPList><KRAList><SubsystemCount>0</SubsystemCount></KRAList><RAList><SubsystemCount>0</SubsystemCount></RAList><TKSList><SubsystemCount>0</SubsystemCount></TKSL ist><TPSList><SubsystemCount>0</SubsystemCount></TPSList></DomainInfo> [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: Cloning a domain master [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: Update security domain using admin interface [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: updateDomainXML start hostname=ipa-master.domain.tld port=443 [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: POST https://ipa-master.domain.tld:443/ca/admin/ca/updateDomainXML [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: Unable to access admin interface: javax.ws.rs.NotFoundException: HTTP 404 Not Found [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: Update security domain using agent interface [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: updateDomainXML start hostname=ipa-master.domain.tld port=443 [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: updateDomainXML() nickname=subsystemCert cert-pki-ca [14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: POST https://ipa-master.domain.tld:443/ca/agent/ca/updateDomainXML [14/Jun/2017:06:49:45][http-bio-8443-exec-3]: Server certificate: [14/Jun/2017:06:49:45][http-bio-8443-exec-3]: - subject: CN=ipa-master.domain.tld,O=DOMAIN.US [14/Jun/2017:06:49:45][http-bio-8443-exec-3]: - issuer: CN=Certificate Authority,O=DOMAIN.US [14/Jun/2017:06:49:45][http-bio-8443-exec-3]: ConfigurationUtils: updateDomainXML: status=1 [14/Jun/2017:06:49:45][http-bio-8443-exec-3]: Unable to update security domain: 2 java.io.IOException: Unable to update security domain: 2 The ipa-master.domain.tld is one of the current RHEL 6.9 FreeIPA 3.x servers but the other two listed in that domainxml file one does not exist (it may have at some point been renamed) and the other server is not a CA replica but it is a replica. Is it possible this bad info would cause a failure when trying to create a new CA replica? If so is it something I can try cleaning up? Any info would be appreciated. Thanks!

5 11

AD trust setup woes
by Jason Beck 28 Sep '17

28 Sep '17

I have been trying to reliably get an AD trust setup for a few weeks and no matter what I try, when I goto add AD users to an external group in FreeIPA, I get: "trusted domain object not found" Googling around tends to always yield the same suggestions: 1) Check time sync 2) Check DNS 3) Check firewall I have done all of this ad nauseam in several different environments with several different versions of FreeIPA and Windows servers. I have gotten a setup to work maybe 2% of the time out of hundreds of attempts. I am currently using FreeIPA 4.5.2 on Fedora 25 (out of the COPR repo). I am trying to establish trust with a mixed Windows 2012 & 2008 forest. I have tried both one and two way trusts. Everything seems to work fine up until I try to add AD users to FreeIPA. I have verified all of the requisite DNS records exist and return the proper information on both sides, there are no firewalls between any of the hosts, and the AD servers and FreeIPA servers are synchronized by the same NTP servers. What could I possibly be missing?

7 26

Re: Krb5.conf only sees first two kdc servers
by pgb205 01 Sep '17

01 Sep '17

Sumit, thank you very much for this. Very helpful, but I am still not seeing the problem So at first I will try with the following in krb5.confkdc=server1 <--shut off on the network#kdc=server2 <--shut off on the network and commented out in krb5.confkdc=server3 <--up and running KRB5_TRACE=/dev/stdout kinit user(a)test.domain [12583] 1501113245.556036: Getting initial credentials for user(a)test.domain [12583] 1501113245.556244: Sending request (181 bytes) to test.domain [12583] 1501113245.556282: Resolving hostname server1 [12583] 1501113245.557235: Sending initial UDP request to dgram ip_addr_server1:88 [12583] 1501113246.558328: Resolving hostname server3 [12583] 1501113246.558974: Sending initial UDP request to dgram ip_addr_server3:88 [12583] 1501113246.729059: Received answer (275 bytes) from dgram ip_addr_server3:88 [12583] 1501113246.729111: Response was from master KDC [12583] 1501113246.729155: Received error from KDC: -1765328359/Additional pre-authentication required [12583] 1501113246.729219: Processing preauth types: 136, 19, 2, 133 [12583] 1501113246.729245: Selected etype info: etype aes256-cts, salt "pY;=XB+5_*EjJC%S", params "" [12583] 1501113246.729254: Received cookie: MIT Password for user(a)test.domain <--get prompted for password Now with all three kdc uncommentedkdc=server1 <-shut off and uncommentedkdc=server2 <--shut off and uncommentedkdc=server3 <--up and running KRB5_TRACE=/dev/stdout kinit user(a)test.domain [12536] 1501112935.251721: Getting initial credentials for user(a)test.domain [12536] 1501112935.251917: Sending request (181 bytes) to test.domain [12536] 1501112935.251956: Resolving hostname server1 [12536] 1501112935.252875: Sending initial UDP request to dgram server1_ip:88 [12536] 1501112936.253962: Resolving hostname server2 [12536] 1501112936.255680: Retrying AS request with master KDC [12536] 1501112936.255699: Getting initial credentials for user(a)test.domain [12536] 1501112936.255763: Sending request (181 bytes) to test.domain (master) [12536] 1501112936.255779: Resolving hostname server1 [12536] 1501112936.256379: Sending initial UDP request to dgram server1_ip:88 [12536] 1501112937.257451: Resolving hostname server2 kinit: Invalid argument while getting initial credentials > So as you can see server3 is never even tried for authentication. One of my theories is that there might be maximum number of kdc's to tryor maximum total authentication timeout?! Just a wild guess as I'm reaching for straws. -------------------------------My other question with regards to how sssd and krb work together was prompted by sssd.confipa_server= _srv_ option which supposed to find available IPA servers from DNS records. We do indeed have this option set in sssd.confand are able to resolve server1,server2 server3 when querying for following records _ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp If the _srv_ is enabled then am i correct in assuming that we wouldn't even need kdc= records in krb5.conf ??I tried removing kdc= linesand was unable to authenticate.

5 10

Certificate renewals with external CA
by Rob Foehl 29 Aug '17

29 Aug '17

I've got a test instance of FreeIPA 4.4.4 running on F25 that was installed with --external-ca, and the resulting CSR signed with a validity period of 30 days to test behavior around expirations. Upon booting that instance today, certmonger decided to preemptively renew every IPA cert -- which is a good thing -- but did so without waiting for renewal of the IPA CA cert first, which is less good. Now that instance has a pile of certs that expire in two weeks, since they were signed with and thus tied to the expiration of the old IPA CA cert. While I'm guessing certmonger will figure this out and do the right thing within a couple weeks -- and with the expectation that this would only happen once per IPA CA renewal with a "real" deployment -- is this the intended behavior? Logs are a bit of a mess between this and a potentially-resolved SELinux issue with certmonger, but I'll wedge them all into a proper bug report if desired. -Rob

3 12

Free IPA/LDAP migration
by Ed Aiduc 23 Aug '17

23 Aug '17

Hi! I'am a newbie here.. I just have a question with regards to LDAP. I have two free ipa server, one with ldap and the other one has no ldap on it, I wanted to transfer/migrate the ldap config from one server to another server with no ldap, is it possible? I'm searching the internet but can't find any source I can use to as reference. Hoping for your kind response. Thank you!

4 5

Failed Upgrade?
by Ian Harding 16 Aug '17

16 Aug '17

I had an unexpected restart of an IPA server that had apparently had updates run but had not been restarted. ipactl says pki-tomcatd would not start. Strangely, the actual service appears to be running: [root@seattlenfs slapd-BPT-ROCKS]# systemctl status pki-tomcatd(a)pki-tomcat.service ● pki-tomcatd(a)pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2017-07-28 11:03:34 PDT; 36min ago Process: 14289 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited, status=0/SUCCESS) Main PID: 14406 (java) CGroup: /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd(a)pki-tomcat.service └─14406 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java -DRESTEASY_LIB=/usr/share/java/resteasy-base -Djava.library.path=/usr/lib64/nuxwdog-jni -classpath /usr/... Jul 28 11:39:50 seattlenfs.bpt.rocks server[14406]: Jul 28, 2017 11:39:50 AM org.apache.catalina.core.ContainerBase backgroundProcess Jul 28 11:39:50 seattlenfs.bpt.rocks server[14406]: WARNING: Exception processing realm com.netscape.cms.tomcat.ProxyRealm@67cf2df background process Jul 28 11:39:50 seattlenfs.bpt.rocks server[14406]: javax.ws.rs.ServiceUnavailableException: Subsystem unavailable Jul 28 11:39:50 seattlenfs.bpt.rocks server[14406]: at com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) Jul 28 11:39:50 seattlenfs.bpt.rocks server[14406]: at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1357) Jul 28 11:39:50 seattlenfs.bpt.rocks server[14406]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1543) Jul 28 11:39:50 seattlenfs.bpt.rocks server[14406]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1553) Jul 28 11:39:50 seattlenfs.bpt.rocks server[14406]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1553) Jul 28 11:39:50 seattlenfs.bpt.rocks server[14406]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1521) Jul 28 11:39:50 seattlenfs.bpt.rocks server[14406]: at java.lang.Thread.run(Thread.java:748) However, the /var/log/ipaupgrade.log is full of trouble. It ends with: 2017-07-28T17:01:19Z DEBUG The CA status is: check interrupted due to error: Retrieving CA status failed with status 500 2017-07-28T17:01:19Z DEBUG Waiting for CA to start... 2017-07-28T17:01:20Z DEBUG request POST http://seattlenfs.bpt.rocks:8080/ca/admin/ca/getStatus 2017-07-28T17:01:20Z DEBUG request body '' 2017-07-28T17:01:20Z DEBUG response status 500 2017-07-28T17:01:20Z DEBUG response headers {'content-length': '2208', 'content-language': 'en', 'server': 'Apache-Coyote/1.1', 'connection': 'close', 'date': 'Fri, 28 Jul 2017 17:01:20 GMT', 'content-type': 'text/html;charset=utf-8'} 2017-07-28T17:01:20Z DEBUG response body '<html><head><title>Apache Tomcat/7.0.69 - Error report</title><style></style> </head><body><h1>HTTP Status 500 - Subsystem unavailable</h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u>Subsystem unavailable</u></p><p><b>description</b> <u>The server encountered an internal error that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>javax.ws.rs.ServiceUnavailableException: Subsystem unavailable\n\tcom.netscape.cms.tomcat.ProxyRealm.findSecurityConstraints(ProxyRealm.java:145)\n\torg.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:499)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)\n\torg.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:436)\n\torg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)\n\torg.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)\n\torg.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:745)\n</pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the Apache Tomcat/7.0.69 logs.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.69</h3></body></html>' 2017-07-28T17:01:20Z DEBUG The CA status is: check interrupted due to error: Retrieving CA status failed with status 500 2017-07-28T17:01:20Z DEBUG Waiting for CA to start... 2017-07-28T17:01:21Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2017-07-28T17:01:21Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 48, in run raise admintool.ScriptError(str(e)) 2017-07-28T17:01:21Z DEBUG The ipa-server-upgrade command failed, exception: ScriptError: CA did not start in 300.0s 2017-07-28T17:01:21Z ERROR CA did not start in 300.0s 2017-07-28T17:01:21Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information Should I just blindly run ipa-server-upgrade again? Googling had me look at certificate expirations, they seem to be good. [root@seattlenfs slapd-BPT-ROCKS]# getcert list | grep expires expires: 2019-05-29 05:54:06 UTC expires: 2019-05-29 05:53:57 UTC expires: 2019-05-29 05:53:16 UTC expires: 2035-07-16 12:51:42 UTC expires: 2019-05-29 05:53:37 UTC expires: 2018-08-15 05:20:24 UTC expires: 2018-08-26 05:01:42 UTC expires: 2018-08-26 05:01:43 UTC [root@seattlenfs slapd-BPT-ROCKS]# yum list | grep ipa- ipa-admintools.noarch 4.4.0-14.el7.centos.7 @test-centos7-updates ipa-client.x86_64 4.4.0-14.el7.centos.7 @test-centos7-updates ipa-client-common.noarch 4.4.0-14.el7.centos.7 @test-centos7-updates ipa-common.noarch 4.4.0-14.el7.centos.7 @test-centos7-updates ipa-python-compat.noarch 4.4.0-14.el7.centos.7 @test-centos7-updates ipa-server.x86_64 4.4.0-14.el7.centos.7 @test-centos7-updates ipa-server-common.noarch 4.4.0-14.el7.centos.7 @test-centos7-updates ipa-server-dns.noarch 4.4.0-14.el7.centos.7 @test-centos7-updates [root@seattlenfs slapd-BPT-ROCKS]# yum list | grep pki- pki-base.noarch 10.3.3-19.el7_3 @updates pki-base-java.noarch 10.3.3-19.el7_3 @updates pki-ca.noarch 10.3.3-19.el7_3 @updates pki-kra.noarch 10.3.3-19.el7_3 @updates pki-server.noarch 10.3.3-19.el7_3 @updates pki-tools.x86_64 10.3.3-19.el7_3 @updates [root@seattlenfs slapd-BPT-ROCKS]# yum list | grep tomcat tomcat.noarch 7.0.69-12.el7_3 @updates tomcat-el-2.2-api.noarch 7.0.69-12.el7_3 @updates tomcat-jsp-2.2-api.noarch 7.0.69-12.el7_3 @updates tomcat-lib.noarch 7.0.69-12.el7_3 @updates tomcat-servlet-3.0-api.noarch 7.0.69-12.el7_3 @updates tomcatjss.noarch 7.1.2-3.el7 @base [root@seattlenfs slapd-BPT-ROCKS]# yum list | grep java java-1.7.0-openjdk.x86_64 1:1.7.0.141-2.6.10.1.el7_3 @test-centos7-updates java-1.7.0-openjdk-devel.x86_64 1:1.7.0.141-2.6.10.1.el7_3 @test-centos7-updates java-1.7.0-openjdk-headless.x86_64 1:1.7.0.141-2.6.10.1.el7_3 @test-centos7-updates java-1.8.0-openjdk.x86_64 1:1.8.0.141-1.b16.el7_3 @updates java-1.8.0-openjdk-headless.x86_64 1:1.8.0.141-1.b16.el7_3 @updates javamail.noarch 1.4.6-8.el7 @base javapackages-tools.noarch 3.4.1-11.el7 @base javassist.noarch 3.16.1-10.el7 @base nuxwdog-client-java.x86_64 1.0.3-5.el7 @base pki-base-java.noarch 10.3.3-19.el7_3 @updates python-javapackages.noarch 3.4.1-11.el7 @base tzdata-java.noarch 2017a-1.el7 @test-centos7-updates Any other useful information I can provide? -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com

5 25

Can’t SSH with AD user to freeipa joined Centos client
by Alexandre Pitre 16 Aug '17

16 Aug '17

I’ve been struggling to get SSH to work with an AD user for over 3 weeks now. I've scraped the bowels of the internet for answers, still no dice. The issue is pretty simple in itself, I can’t SSH to a freeipa joined Centos client 7.3 with an AD user. However, kinit with any AD users as well as su works just fine. I’m running two 4.4.0 IPA servers. I made sure the entire setup is resolving DNS properly, NTP(external to freeipa) is in sync. I’m using FQDN for hostnames. Here’s the output from journalctl -f: Jul 27 04:37:10 centos.ipa.ad.com sshd[2633]: pam_unix(sshd:session): session opened for user root by (uid=0) Jul 27 04:37:35 centos.ipa.ad.com su[2652]: (to admin(a)ad.com) root on pts/1 Jul 27 04:37:35 centos.ipa.ad.com su[2652]: pam_unix(su-l:session): session opened for user admin(a)ad.com by root(uid=0) Jul 27 04:37:42 centos.ipa.ad.com su[2652]: pam_unix(su-l:session): session closed for user admin(a)ad.com Jul 27 04:38:35 centos.ipa.ad.com sshd[2677]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruse r= rhost=localhost user=admin(a)ad.com Jul 27 04:38:35 centos.ipa.ad.com sshd[2677]: pam_sss(sshd:auth): received for user admin(a)ad.com: 6 (Permission denied) Jul 27 04:38:35 centos.ipa.ad.com sshd[2674]: error: PAM: Authentication failure for admin(a)ad.com from localhost Jul 27 04:38:38 centos.ipa.ad.com sshd[2674]: Connection closed by ::1 [preauth] Config files: /etc/krb5.conf #File modified by ipa-client-install includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [libdefaults] default_realm = IP.AD.COM dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] IP.AD.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt } /etc/sssd/sssd.conf [domain/ipa.ad.com] debug_level = 9 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = ipa.ad.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = centos.ipa.ad.com chpass_provider = ipa dyndns_update = True ipa_server = _srv_, ipaserver02.ipa.ad.com dyndns_iface = ens192 ldap_tls_cacert = /etc/ipa/ca.crt[sssd] services = nss, sudo, pam, ssh debug_level = 9 domains = ipa.ad.com [nss] homedir_substring = /home [pam] debug_level= 9 [sudo] [autofs] [ssh] debug_level=9 [pac] [ifp] /etc/ssh/sshd_config HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key SyslogFacility AUTHPRIV PermitRootLogin yes AuthorizedKeysFile .ssh/authorized_keys GSSAPICleanupCredentials no X11Forwarding yes UsePrivilegeSeparation sandbox # Default for new installations. AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS Subsystem sftp /usr/libexec/openssh/sftp-server KerberosAuthentication no PubkeyAuthentication yes UsePAM yes AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys GSSAPIAuthentication yes ChallengeResponseAuthentication yes AuthorizedKeysCommandUser nobody I uploaded krb5_child.log and ldap_child.log to https://1drv.ms/f/s!AlZwwyQE2ZZ5p2b5ROa15PBkAEQD I managed to ssh AD user login to works on both my freeipa servers. I had to modify the following files See changes in bold. /etc/krb5.conf includedir /etc/krb5.conf.d/ includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = IPA.AD.COM * dns_lookup_realm = true* * dns_lookup_kdc = true* rdns = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid} [realms] IPA.AD.COM = { kdc = ipaserver01.ipa.ad.com:88 master_kdc = ipaserver01.ipa.ad.com:88 admin_server = ipaserver01.ipa.ad.com:749 default_domain = ipa.ad.com pkinit_anchors = FILE:/etc/ipa/ca.crt * auth_to_local = RULE:[1:$1@$0](^.*@AD.COM <http://AD.COM>)s/@AD.COM/@ad.com/ <http://AD.COM/@ad.com/>* * auth_to_local = DEFAULT* } [domain_realm] .ipa.ad.com = IPA.AD.COM ipa.ad.com = IPA.AD.COM ipaserver02.ipa.ad.com = IPA.AD.COM [dbmodules] IPA.AD.COM = { db_library = ipadb.so } /etc/resolv.conf search ipa.ad.com ad.com nameserver 127.0.0.1 *nameserver 192.168.1.2 #Seconday IPA Server* In /etc/named.conf, I disabled dnssec-validation(dnssec-validation no;) Not sure those settings were at all necessary. Adding the following line sunder the [realms] for krb5.conf on my centos client machine did not make a difference. auth_to_local = RULE:[1:$1@$0](^.*@AD.COM)s/@AD.COM/@ad.com/ auth_to_local = DEFAULT IPv6 has been disabled in /etc/sysctl.conf net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 If anyone has an idea what may be the issue or where to look, please reply. Thanks Alex

3 17

Re: Trying To Connect FreeIPA with OKTA/OneLogin/Bitium
by Guillermo Fuentes 07 Aug '17

07 Aug '17

Hi Chris and all! Chris, thanks for putting together the guide on integrating FreeIPA with Okta. The integration works fine except for accounts with expired passwords. Okta will allow login for an account with an expired password. Although the guide says "This is all well documented and supported within OKTA.", Okta's support team said they haven't tested the integration with FreeIPA and for OKTA to recognize the password has expired, the user has to have the pwdReset attribute set to TRUE (for expired) or FALSE (https://support.okta.com/help/Documentation/Knowledge_Article/Configuring-Y…). I can't find the pwdReset attribute anywhere in the FreeIPA schema which will suggest me I'll have to extend it, unless Okta is willing to recognize and honor the krbPasswordExpiration attribute used in the guide. Did you or someone in the list have gotten this to work properly? Thanks so much in advance, Guillermo ------------ From: Chris Whittle <cwhittl gmail com> To: dpal redhat com Cc: freeipa-users <freeipa-users redhat com> Subject: Re: [Freeipa-users] Trying To Connect FreeIPA with OKTA/OneLogin/Bitium Date: Tue, 12 Aug 2014 08:46:26 -0500 http://www.freeipa.org/page/HowTo/Integrate_With_Okta On Sat, Aug 9, 2014 at 11:31 PM, Dmitri Pal <dpal redhat com> wrote: > > On 08/08/2014 04:26 PM, Chris Whittle wrote: ...

1 1

Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA
by Fraser Tweedale 05 Aug '17

05 Aug '17

On Mon, Jul 17, 2017 at 08:41:26AM -0400, Prasun Gera wrote: > Bumping this for help. I need to renew my replica's SSL certificate which > will expire in a month, but I can't find any instructions. It looks like > the replica's web-ui cert isn't tracked by the master or the replica. I'm > using a pretty stock installation with no external CAs or certs. So > ideally, all of this should have been handled automatically by ipa, but it > isn't. There have also been quite a few cert related posts of late which > makes me think if there are (were) some other issues with replica setup a > couple of years ago, which is when the certs were originally generated. > Hi Prasun, You can add a tracking request to Certmonger for the cert: % ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert \ -p /etc/httpd/alias/pwdfile.txt \ -K ldap/<hostname>@<realm> -D <hostname> The `-D <hostname>` option will ensure that the CSR contains the subject alt name for <hostname>, which will in turn be propagated to the issued certificiate. Once the tracking request is set up you can renew the cert via `ipa-getcert resubmit -i <request-id>`. Cheers, Fraser > On Sun, Apr 23, 2017 at 10:08 PM, Prasun Gera <prasun.gera(a)gmail.com> wrote: > > > I tried that, but the replica's "getcert list" doesn't seem to show any > > results. "Number of certificates and requests being tracked: 0." Is that > > expected ? > > > > On Sun, Apr 23, 2017 at 8:50 PM, Fraser Tweedale <ftweedal(a)redhat.com> > > wrote: > > > >> On Sun, Apr 23, 2017 at 03:32:19AM -0400, Prasun Gera wrote: > >> > Thank you. That worked for the master. How do I fix the replica's cert ? > >> > This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not using > >> > ipa's DNS at all. Did this happen because of that ? > >> > > >> This is not related to DNS. > >> > >> To fix the replica, log onto the host and perform the same steps > >> with Certmonger there. The tracking Request ID will be different > >> but otherwise the process is the same. > >> > >> Cheers, > >> Fraser > >> > >> > On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale <ftweedal(a)redhat.com> > >> > wrote: > >> > > >> > > On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote: > >> > > > I can confirm that I see this behaviour too. My ipa server install > >> is a > >> > > > pretty stock install with no 3rd party certificates. > >> > > > > >> > > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams < > >> > > > simon.williams(a)thehelpfulcat.com> wrote: > >> > > > > >> > > > > Yesterday, Chrome on both my Ubuntu and Windows machines updated > >> to > >> > > > > version 58.0.3029.81. It appears that this version of Chrome > >> will not > >> > > > > trust certificates based on Common Name. Looking at the Chrome > >> > > > > documentation and borne out by one of the messages, from Chrome > >> 58, > >> > > > > the subjectAltName is required to identify the DNS name of the > >> host > >> > > that > >> > > > > the certificate is issued for. I would be grateful if someone > >> could > >> > > point > >> > > > > me in the direction of how to recreate my SSL certificates so that > >> > > > > the subjectAltName is populated. > >> > > > > > >> > > > > Thanks in advance > >> > > > > > >> > > > > -- > >> > > > > Manage your subscription for the Freeipa-users mailing list: > >> > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > >> > > > > Go to http://freeipa.org for more info on the project > >> > > > > > >> > > Which version of IPA are you using? > >> > > > >> > > The first thing you should do, which I think should be sufficient in > >> > > most cases, is to tell certmonger to submit a new cert request for > >> > > each affected certificate, instructing to include the relevant > >> > > DNSName in the subjectAltName extension in the CSR. > >> > > > >> > > To list certmonger tracking requests and look for the HTTPS > >> > > certificate. For example: > >> > > > >> > > $ getcert list > >> > > Number of certificate and requests being tracked: 11 > >> > > ... > >> > > Request ID '20170418012901': > >> > > status: MONITORING > >> > > stuck: no > >> > > key pair storage: type=NSSDB,location='/etc/ > >> > > httpd/alias',nickname='Server-Cert',token='NSS Certificate > >> > > DB',pinfile='/etc/httpd/alias/pwdfile.txt' > >> > > certificate: type=NSSDB,location='/etc/ > >> > > httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > >> > > CA: IPA > >> > > issuer: CN=Certificate Authority,O=IPA.LOCAL 201703211317 > >> > > subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317 > >> > > expires: 2019-03-22 03:20:19 UTC > >> > > dns: f25-2.ipa.local > >> > > key usage: digitalSignature,nonRepudiatio > >> n,keyEncipherment, > >> > > dataEncipherment > >> > > eku: id-kp-serverAuth,id-kp-clientAuth > >> > > pre-save command: > >> > > post-save command: /usr/libexec/ipa/certmonger/re > >> start_httpd > >> > > track: yes > >> > > auto-renew: yes > >> > > ... > >> > > > >> > > Using the Request ID of the HTTPS certificate, resubmit the request > >> > > but use the ``-D <hostname>`` option to specify a DNSName to include > >> > > in the SAN extension: > >> > > > >> > > $ getcert resubmit -i <Request ID> -D <hostname> > >> > > > >> > > ``-D <hostname>`` can be specified multiple times, if necessary. > >> > > > >> > > This should request a new certificate that will have the server DNS > >> > > name in the SAN extension. > >> > > > >> > > HTH, > >> > > Fraser > >> > > > >> > > > >

4 13

OSX (El Capitan) - FreeIPA
by Luiz Garrido ALKEMY X 03 Aug '17

03 Aug '17

Hi, We have an environment with mixed OSX and CentOS computers and IPA is working great for almost everything. The only problem that we have (besides the known ones) is that the IPA user logged to an OSX computer is not getting group information. Logged to a CentOS, the `id` command shows all the groups assigned to the user but running the same command on an OSX under the same user, the groups are different, mainly Apple groups and not our IPA groups. Does anyone had this problem? So, because of this, ACL permissions on our NFS server is not working for OSX machines, but are working great for CentOS ones. Thanks! Luiz Garrido

4 9

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users July 2017