August 2018 - FreeIPA-users - Fedora mailing-lists

Global Catalog Support on FreeIPA 4.7 ?
by Zafer Syed 26 Aug '18

26 Aug '18

Good Day, I've configured a Two-way Forest trust between AD (windows-2016) and FreeIPA 4.7(Centos 7). I'm able to log into the Linux Box, using the Windows AD username. However, when i browse on the Windows AD to add the FreeIPA user to a group for Logging locally, i get a message "Object not found" Do we have Global Catalog service supported on FreeIPA 4.7 ? or is there any workaround for getting this to work ? Please advise ?

2 1

sambahomepath
by Jon Wright 25 Aug '18

25 Aug '18

Hi, We're investigating replacing our Centos openldap system with FreeIPA to authenticate users on our Apple desktops. So far so good, we have migrated from openldap to FreeIPA, we can login users into desktops using kerberos etc etc They get a local home directory as e.g. /Users/fred and in the past we have then run a simple script which checks the contents of the LDAP attribute sambaHomePath for the server hostname and username e.g. sambaHomePath: samba1/fred This script then mounts samba1:/fred as a network drive and users can then find their network server files on /Volumes/fred This has worked well for the last few years and I see from using slapcat sambaHomePath is set for each user with freeipa but the standard ldapseach -x ... tool does not see it. Is there a simple way of unhiding this attribute so when a user runs ldapsearch -x -h ipa1 uid=`whoami` we get the answer? It's taken a few days to get IPA setup so the Mac's can authenticate but I think if we 'solve' this last issue then we're done. Thanks

1 1

selinux issues
by Kat 24 Aug '18

24 Aug '18

Hi all - So this is something I found and wanted to post it to the team - this is for RHEL and/or CentOS 7.3 thru 5 so far. It has to do with selinux_provider and having to explicitly disable it in sssd or things will randomly fail. On heavily loaded clients, (and a fair load on IPA cluster) you find that even if a client has selinux disabled (sometimes because of application requirements) that ssh access is still randomly denied because of selinux failures. You need to explicitly add selinux_provider=none to sssd.conf to avoid seeing these: sshd[58319]: fatal: Access denied for user xxxxxxxx by PAM account configuration [preauth] sshd[58319]: pam_sss(sshd:account): Access denied for user xxxxxxxx: 4 (System error) If you look in detail you find that the authentication actually works but when it is sent back to the client, there are random failures for the same username from time to time. It all seems to be load related, as I have been unable to find a root cause. An example is that I have a looping ssh job to just login, create a folder and exit - all via ssh keys. If you run that for a few hours with a few seconds interval, you find that out of 1000+ successes, you might see 20-30 random "Access Denied". This was confusing at first because sshd only returns that the authentication failed without any details (return code is 255) but looking in detailed logs finds the random errors as show above. This all connects back with the errors I reported last week regarding the same thing and that I felt it was related to DNS and other settings - it was not. Hope this helps someone else.. -K

2 1

Authenticating RHEL 7 to IPA using the LDAP connector
by William Muriithi 22 Aug '18

22 Aug '18

Hello, As there isn't currently a way to cleanly setup a samba share on a IPA enrolled system, I am attempting to get around this by hopefully getting the system retrieving the ID from IPA by mean of LDAP protocol That way, I can point the samba service directly to the AD. Because of this requirement, I can't use realmd or the ipa-client to enrol the system. So I am setting it manually. This is what I had done to get the system authenticating the user from IPA using LDAP - Changed /etc/nsswitch.conf and added SSS passwd: files sss shadow: files sss group: files sss - Added sssd on the pam files [root@sambapoc4 ~]# cat /etc/pam.d/password-auth-ac | grep sss auth sufficient pam_sss.so forward_pass account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok session optional pam_sss.so [root@sambapoc4 ~]# cat /etc/pam.d/system-auth | grep sss auth sufficient pam_sss.so forward_pass account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok session optional pam_sss.so [root@sambapoc4 ~]# - This is the SSSD configurations [domain/default] autofs_provider = ldap cache_credentials = True ldap_search_base = dc=eng,dc=example,dc=com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://hydrogen.eng.example.com:389,ldap://lithium.eng.example.com:389 ldap_id_use_start_tls = True ldap_tls_cacertdir = /etc/openldap/cacerts [sssd] services = nss, pam, autofs domains = default [nss] homedir_substring = /home [pam] [sudo] I don't think though this is correct or enough since I am seeing this on the logs. Aug 22 17:42:21 localhost sshd[20724]: Failed password for invalid user william from 192.168.20.221 port 49598 ssh2 Aug 22 17:42:25 localhost sshd[20724]: Failed password for invalid user william from 192.168.20.221 port 49598 ssh2 Aug 22 17:42:27 localhost sshd[20724]: Connection closed by 192.168.20.221 [preauth] What other changes would I be overlooking to get the system authenticating using LDAP? Regards, William

1 0

Certificates renewing with the wrong Subject
by Roderick Johnstone 21 Aug '18

21 Aug '18

Hi Our freeipa certificates need to be renewed due to passing their expiry dates. While some certificates have renewed ok, the ipaCert and auditSigningCert are renewing but the new certificates have the wrong Subject. Environment is: serverA (CRL, first, master) RHEL 7.3, ipa 4.4 serverB (replica) RHEL 7.3, ipa 4.4 serverC (replica) RHEL 7.4, ipa 4.5 Once there are renewed certificates with the wrong Subject present, there are various problems with renewing the remaining certificates, which I think might be related to the bad Subject: 1) When just ipaCert has the wrong subject no further renewals happen 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd service will not start and no further renewals happen. I've been round the following loop many times on ServerA, our first master: 1) Restore good certificates from backup 2) Put the clock back to a time when certificates are all valid 3) Resubmit certificates for renewal Each time the ipaCert renews it has the same wrong Subject. The wrong Subject includes the host name of one of our ipa client systems. Each time the auditSigningCert renews it has the same wrong Subject but a different subject to the ipaCert. The wrong Subject in this case includes the host name of a system which has never been an ipa client, but might have been added and removed with ipa host-add and ipa host-del for testing something, a while ago. As far as I can see, the "cert_subject" is set correctly in the file /var/lib/certmonger/<request id> until the point at which the certificate is actually renewed. I'd be very grateful for some pointers as to which configuration options and logs to check through to resolve this problem on our production system. If its of any relevance we did change which server is the first master some time ago. Thanks Roderick Johnstone

3 21

[BLOG] Issuing subordinate CA certificates from FreeIPA
by Fraser Tweedale 21 Aug '18

21 Aug '18

Hi all, There was recently discussion about how to issue sub-CA certificates to external entities in FreeIPA (i.e. not lightweight CAs which are internal to an IPA deployment). So I blogged a comprehensive HOWTO, with a discussion of the caveats/limitations. https://frasertweedale.github.io/blog-redhat/posts/2018-08-21-ipa-subordina… As always, feedback/errata/follow-up questions are welcome. Cheers, Fraser

1 0

accessing the api
by Andrew Meyer 20 Aug '18

20 Aug '18

Hello,I'm having some difficulty accessing the API. Following the directions shown here: Far away to be identical | | | Far away to be identical Identity management chaos or a development of a fun | | | I am trying to use the following curl commands:curl -kv -H Referer:https://$IPASERVER1/ipa -c $COOKIEJAR -b $COOKIEJAR --negotiate -u : -X POST https://$IPASERVER1/ipa/ui I get the following output: Andrews-MacBook-Pro :) > curl -kv -H Referer:https://$IPASERVER1/ipa -c $COOKIEJAR -b $COOKIEJAR --negotiate -u : -X POST https://$IPASERVER1/ipa/ui* Trying 10.1.6.250...* TCP_NODELAY set* Connected to $IPASERVER1 (10.1.6.250) port 443 (#0)* ALPN, offering h2* ALPN, offering http/1.1* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH* successfully set certificate verify locations:* CAfile: /etc/ssl/cert.pem CApath: none* TLSv1.2 (OUT), TLS handshake, Client hello (1):* TLSv1.2 (IN), TLS handshake, Server hello (2):* TLSv1.2 (IN), TLS handshake, Certificate (11):* TLSv1.2 (IN), TLS handshake, Server key exchange (12):* TLSv1.2 (IN), TLS handshake, Server finished (14):* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):* TLSv1.2 (OUT), TLS change cipher, Client hello (1):* TLSv1.2 (OUT), TLS handshake, Finished (20):* TLSv1.2 (IN), TLS change cipher, Client hello (1):* TLSv1.2 (IN), TLS handshake, Finished (20):* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384* ALPN, server did not agree to a protocol* Server certificate:* subject: O=EXAMPLE.NET; CN=$IPASERVER1* start date: Mar 6 21:52:54 2018 GMT* expire date: Mar 6 21:52:54 2020 GMT* issuer: O=EXAMPLE.NET; CN=Certificate Authority* SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.> POST /ipa/ui HTTP/1.1> Host: $IPASERVER1> User-Agent: curl/7.54.0> Accept: */*> Referer:https://$IPASERVER1/ipa>< HTTP/1.1 301 Moved Permanently< Date: Mon, 20 Aug 2018 19:50:50 GMT< Server: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.5.1 mod_nss/1.0.14 NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5* Added cookie ipa_session="" for domain $IPASERVER1, path /ipa, expire 1534794650< Set-Cookie: ipa_session=;Max-Age=0;path=/ipa;httponly;secure;< X-Frame-Options: DENY< Content-Security-Policy: frame-ancestors 'none'< Location: https://$IPASERVER1/ipa/ui/< Cache-Control: max-age=31536000< Expires: Tue, 20 Aug 2019 19:50:50 GMT< Cache-Control: no-cache* Replaced cookie ipa_session="" for domain $IPASERVER1, path /ipa, expire 1534794650< Set-Cookie: ipa_session=;Max-Age=0;path=/ipa;httponly;secure;< Content-Length: 255< Content-Type: text/html; charset=iso-8859-1<<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>301 Moved Permanently</title></head><body><h1>Moved Permanently</h1><p>The document has moved <a href="https://$IPASERVER1/ipa/ui/">here</a>.</p></body></html>* Connection #0 to host $IPASERVER1 left intactAndrews-MacBook-Pro :) > Then I run this:Andrews-MacBook-Pro :) > curl -kv -H referer:https://$IPASERVER1/ipa -H "Content-Type:application/json" -H "Accept:applicaton/json" -c $COOKIEJAR -b $COOKIEJAR -d $JSON_PAYLOAD -X POST https://$IPASERVER1/ipa/session/json* Rebuilt URL to: POST/* Trying 104.16.143.73...* TCP_NODELAY set* Connected to POST (104.16.143.73) port 80 (#0)> POST / HTTP/1.1> Host: POST> User-Agent: curl/7.54.0> referer:https://$IPASERVER1/ipa> Content-Type:application/json> Accept:applicaton/json> Content-Length: 2>* upload completely sent off: 2 out of 2 bytes< HTTP/1.1 403 Forbidden< Date: Mon, 20 Aug 2018 19:53:36 GMT< Content-Type: text/html; charset=UTF-8< Transfer-Encoding: chunked< Connection: close* skipped cookie with bad tailmatch domain: post< Set-Cookie: __cfduid=d805f1a1676001cf1532cc7c25208107f1534794816; expires=Tue, 20-Aug-19 19:53:36 GMT; path=/; domain=.post; HttpOnly< Cache-Control: max-age=15< Expires: Mon, 20 Aug 2018 19:53:51 GMT< X-Frame-Options: SAMEORIGIN< Server: cloudflare-nginx< CF-RAY: 44d76832d2d654e6-ORD<<!DOCTYPE html> <html class="no-js" lang="en-US"> <head><title>Direct IP access not allowed | Cloudflare</title><meta charset="UTF-8" /><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1" /><meta name="robots" content="noindex, nofollow" /><meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1" /><link rel="stylesheet" id="cf_styles-css" href="/cdn-cgi/styles/cf.errors.css" type="text/css" media="screen,projection" /><style type="text/css">body{margin:0;padding:0}</style> <script type="text/javascript" src="/cdn-cgi/scripts/zepto.min.js"></script><script type="text/javascript" src="/cdn-cgi/scripts/cf.common.js"></script> </head><body> <div id="cf-wrapper"> <div class="cf-alert cf-alert-error cf-cookie-error" id="cookie-alert" data-translate="enable_cookies">Please enable cookies.</div> <div id="cf-error-details" class="cf-error-details-wrapper"> <div class="cf-wrapper cf-header cf-error-overview"> <h1> <span class="cf-error-type" data-translate="error">Error</span> <span class="cf-error-code">1003</span> <small class="heading-ray-id">Ray ID: 44d76832d2d654e6 • 2018-08-20 19:53:36 UTC</small> </h1> <h2 class="cf-subheadline">Direct IP access not allowed</h2> </div> <section></section> <div class="cf-section cf-wrapper"> <div class="cf-columns two"> <div class="cf-column"> <h2 data-translate="what_happened">What happened?</h2> <p>You've requested an IP address that is part of the <a data-orig-proto="https" data-orig-ref="www.cloudflare.com/5xx-error-landing?utm_source=error_100x" target="_blank">Cloudflare</a> network. A valid Host header must be supplied to reach the desired website.</p> </div> <div class="cf-column"> <h2 data-translate="what_can_i_do">What can I do?</h2> <p>If you are interested in learning more about Cloudflare, please <a data-orig-proto="https" data-orig-ref="www.cloudflare.com/5xx-error-landing?utm_source=error_100x" target="_blank">visit our website</a>.</p> </div> </div> </div> <div class="cf-error-footer cf-wrapper"> <p> <span class="cf-footer-item">Cloudflare Ray ID: <strong>44d76832d2d654e6</strong></span> <span class="cf-footer-separator">•</span> <span class="cf-footer-item"><span>Your IP</span>: 209.116.32.50</span> <span class="cf-footer-separator">•</span> <span class="cf-footer-item"><span>Performance & security by</span> <a href="https://www.cloudflare.com/5xx-error-landing?utm_source=error_footer" id="brand_link" target="_blank">Cloudflare</a></span> </p></div> </div> </div> <script type="text/javascript"> window._cf_translation = {}; </script> </body></html>* Closing connection 0* Trying 10.1.6.250...* TCP_NODELAY set* Connected to $IPASERVER1 (10.1.6.250) port 443 (#1)* ALPN, offering h2* ALPN, offering http/1.1* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH* successfully set certificate verify locations:* CAfile: /etc/ssl/cert.pem CApath: none* TLSv1.2 (OUT), TLS handshake, Client hello (1):* TLSv1.2 (IN), TLS handshake, Server hello (2):* TLSv1.2 (IN), TLS handshake, Certificate (11):* TLSv1.2 (IN), TLS handshake, Server key exchange (12):* TLSv1.2 (IN), TLS handshake, Server finished (14):* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):* TLSv1.2 (OUT), TLS change cipher, Client hello (1):* TLSv1.2 (OUT), TLS handshake, Finished (20):* TLSv1.2 (IN), TLS change cipher, Client hello (1):* TLSv1.2 (IN), TLS handshake, Finished (20):* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384* ALPN, server did not agree to a protocol* Server certificate:* subject: O=EXAMPLE.NET; CN=$IPASERVER* start date: Mar 6 21:52:54 2018 GMT* expire date: Mar 6 21:52:54 2020 GMT* issuer: O=EXAMPLE.NET; CN=Certificate Authority* SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.> POST /ipa/session/json HTTP/1.1> Host: $IPASERVER1> User-Agent: curl/7.54.0> referer:https://$IPASERVER1/ipa> Content-Type:application/json> Accept:applicaton/json> Content-Length: 2>* upload completely sent off: 2 out of 2 bytes< HTTP/1.1 401 Unauthorized< Date: Mon, 20 Aug 2018 19:53:36 GMT< Server: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.5.1 mod_nss/1.0.14 NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5< WWW-Authenticate: Negotiate* Added cookie ipa_session="" for domain $IPASERVER1, path /ipa, expire 1534794816< Set-Cookie: ipa_session=;Max-Age=0;path=/ipa;httponly;secure;< X-Frame-Options: DENY< Content-Security-Policy: frame-ancestors 'none'< Last-Modified: Thu, 30 Nov 2017 20:03:14 GMT< Accept-Ranges: bytes< Content-Length: 1474< Cache-Control: no-cache< Content-Type: text/html; charset=UTF-8<<!DOCTYPE html><html><head> <meta charset="utf-8"> <title>Identity Management</title> <script type="text/javascript" src="../ui/js/libs/loader.js"></script> <script type="text/javascript"> (function() { var styles = [ '../ui/css/patternfly.css', '../ui/css/ipa.css' ]; ipa_loader.styles(styles); })(); </script></head> <body class="info-page"> <nav class="navbar navbar-default navbar-pf" role="navigation"> <div class="navbar-header"> <a class="brand" href="../ui/index.html"><img src="../ui/images/header-logo.png" alt="Identity Management"></a> </div> </nav> <div class="container-fluid"> <div class="row"> <div class="col-sm-12"> <h1>Unable to verify your Kerberos credentials</h1> <p> Please make sure that you have valid Kerberos tickets (obtainable via <strong>kinit</strong>), and that you have configured your browser correctly. </p> <h2>Browser configuration</h2> <div id="first-time"> <p> If this is your first time, please <strong>configure your browser</strong>. Use <a href="browserconfig.html">Firefox configuration page</a> for Firefox or <a href="ssbrowser.html">manual configuration page</a> for other browsers. </p> </div> </div> </div> </div> </body> </html>* Connection #1 to host $IPASERVER1 left intact I was able to export/extract my kerberos key for this user. I found something on stackexchange or another website like it that said I could use the variables KRB5_CLIENT_KTNAME & KRB5CCNAME. Which I have defined and I think curl should pick up on those. However its still not authenticating me. Is there something else I need to be doing? Maybe something I did wrong? Regards,Andrew Meyer

2 4

Re: Changing domain name
by Angus Clarke 19 Aug '18

19 Aug '18

You might find some useful tips here: https://www.redhat.com/archives/freeipa-users/2014-May/msg00158.html Not sure if they did drop their other scripts into github (as suggested two thirds down) Regards Angus On 17 August 2018 at 10:09, Alfredo De Luca via FreeIPA-users < freeipa-users(a)lists.fedorahosted.org> wrote: > Hi Rob. It worked. Thanks. > It was confusing for me the name *migrated *thinking was the new host > rather than the *"old"* . > Now users/groups are there and whoever has the password needs to connect > to the new server in order to recreate their password with kerberos. I > guess who has the ssh keys don't need to to that...right? > > Now I need to migrate manually the hbac,sudo etc.... > > Thanks > > > On Thu, Aug 16, 2018 at 4:00 PM Alfredo De Luca <alfredo.deluca(a)gmail.com> > wrote: > >> Thanks Rob. I ll give a try. >> CHeers >> >> On Thu, Aug 16, 2018 at 2:31 PM Rob Crittenden <rcritten(a)redhat.com> >> wrote: >> >>> Alfredo De Luca via FreeIPA-users wrote: >>> > Hi Florence. >>> > But the example says ldap://*migrated*.freeipa.server.test >>> > >>> > so I ran the command from the actual server where I want migrate the >>> > users from and pointing to the migrated (so the new which I will >>> migrate >>> > to) server... >>> > So is it wrong? >>> > So should I run the command instead fron the new ipa server pointing to >>> > the old server? >>> >>> The old server. You have been trying to migrate the server to itself. >>> >>> rob >>> >>> > >>> > >>> > >>> > On Thu, Aug 16, 2018 at 1:02 PM Florence Blanc-Renaud <flo(a)redhat.com >>> > <mailto:flo@redhat.com>> wrote: >>> > >>> > On 08/16/2018 12:37 PM, Alfredo De Luca via FreeIPA-users wrote: >>> > > The IP is the new server where I'd like to migrate all the >>> > user/groups >>> > > to and it should be ok. >>> > > The migrate-ds is the default I copy from the freeipa.org >>> > <http://freeipa.org> >>> > > <http://freeipa.org> migration section.. >>> > > >>> > Hi, >>> > >>> > the ldap URI should point to the server where the users are >>> currently >>> > defined (=the FROM server). >>> > >>> > Hope this clarifies, >>> > flo >>> > > >>> > > >>> > > >>> > > On Tue, Aug 14, 2018 at 7:00 PM Rob Crittenden >>> > <rcritten(a)redhat.com <mailto:rcritten@redhat.com> >>> > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> >>> wrote: >>> > > >>> > > Alfredo De Luca via FreeIPA-users wrote: >>> > > > Hi Rob. >>> > > > Yes. I am following the link you sent. So now I can >>> understand >>> > > they need >>> > > > to create the new Kerberos but given the command I should >>> have >>> > > seen all >>> > > > the users in the new freeipa server... which are not >>> there. >>> > > > Maybe I put a wrong command? (below) >>> > > > >>> > > > ipa migrate-ds --bind-dn="cn=Directory Manager" >>> > > > --user-container=cn=users,cn=accounts >>> --group-overwrite-gid >>> > > > --group-container=cn=groups,cn=accounts >>> > > --group-objectclass=posixgroup >>> > > > >>> > > >>> > --user-ignore-attribute={krbPrincipalName,krbextradata, >>> krblastfailedauth,krblastpwdchange,krblastsuccessfulauth, >>> krbloginfailedcount,krbpasswordexpiration,krbticketflags, >>> krbpwdpolicyreference,mepManagedEntry} >>> > > > --user-ignore-objectclass=mepOriginEntry --with-compat >>> > > > ldap://192.168.20.177:389 <http://192.168.20.177:389> >>> > <http://192.168.20.177:389> >>> > > <http://192.168.20.177:389> >>> > > > >>> > > > Password: >>> > > > ----------- >>> > > > migrate-ds: >>> > > > ----------- >>> > > > Migrated: >>> > > > group: admins, editors >>> > > > Failed user: >>> > > > admin: This entry already exists >>> > > > Failed group: >>> > > > ---------- >>> > > > Passwords have been migrated in pre-hashed format. >>> > > > IPA is unable to generate Kerberos keys unless provided >>> > > > with clear text passwords. All migrated users need to >>> > > > login at https://your.domain/ipa/migration/ before they >>> > > > can use their Kerberos accounts. >>> > > >>> > > It isn't finding any of your users. Are you sure that IP >>> > address points >>> > > to your existing IPA instance? >>> > > >>> > > rob >>> > > >>> > > >>> > > >>> > > -- >>> > > /Alfredo/ >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > FreeIPA-users mailing list -- freeipa-users@lists. >>> fedorahosted.org >>> > <mailto:freeipa-users@lists.fedorahosted.org> >>> > > To unsubscribe send an email to >>> > freeipa-users-leave(a)lists.fedorahosted.org >>> > <mailto:freeipa-users-leave@lists.fedorahosted.org> >>> > > Fedora Code of Conduct: https://getfedora.org/code-of- >>> conduct.html >>> > > List Guidelines: >>> > https://fedoraproject.org/wiki/Mailing_list_guidelines >>> > > List Archives: >>> > https://lists.fedoraproject.org/archives/list/freeipa- >>> users(a)lists.fedorahosted.org/message/N3LK45PLAZOV3SA2TRNI6SYQKTNQQPF3/ >>> > > >>> > >>> > >>> > >>> > -- >>> > /Alfredo/ >>> > >>> > >>> > >>> > _______________________________________________ >>> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org >>> > To unsubscribe send an email to freeipa-users-leave@lists. >>> fedorahosted.org >>> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>> > List Guidelines: https://fedoraproject.org/ >>> wiki/Mailing_list_guidelines >>> > List Archives: https://lists.fedoraproject.org/archives/list/freeipa- >>> users(a)lists.fedorahosted.org/message/VPSB6HPG4J3ZGJHOPA3IQTRJ56GGS4ZR/ >>> > >>> >>> >> >> -- >> *Alfredo* >> >> > > -- > *Alfredo* > > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/freeipa- > users(a)lists.fedorahosted.org/message/KI32QFU4SCN3CKBP6ZODISPLPLFYW3S2/ > >

2 1

Passync AD *and* trust?
by Pieter Baele 17 Aug '18

17 Aug '18

Hi, Would it somehow be possible to - partially - sync AD users (max 200) with IPA while still using a trust with the same domain? Logically this sounds like a bad idea, but my colleagues would really really like to use IPA also for AIX. The biggest limitation is that the AIX client doesn't work well with <user>@<AD Domain> in IPA compat. What would possible work-arounds be to make use of IPA on AIX...? A custom virtual LDAP which strips the @<AD domain> part, but keeps all other LDAP data the same? Using some commercial offering? Sincerely Pieter

2 1

Problems after IPA upgrade: ipa-server-upgrade doesn't complete, pki-tomcatd won't start
by Jokinen Eemeli 17 Aug '18

17 Aug '18

Hello all! I have very similiar problem as this one: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… ipa-server-upgrade fails as below -- Update complete Upgrading IPA services Upgrading the configuration of the IPA services [Verifying that root certificate is published] [Migrate CRL publish directory] CRL tree already moved [Verifying that CA proxy configuration is correct] IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. CA did not start in 300.0s The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information -- And the log tells me that CA returns status 500 -- DEBUG Waiting for CA to start... DEBUG request POST http://<<ipa1.fqdn>>:8080/ca/admin/ca/getStatus<http://%3c%3cipa1.fqdn%3e%3e:8080/ca/admin/ca/getStatus> DEBUG request body '' DEBUG response status 500 DEBUG response headers Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Language: en Content-Length: 2208 Date: Fri, 15 Jun 2018 10:05:29 GMT Connection: close DEBUG response body '<html><head><title>Apache Tomcat/7.0.76 - 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:500)\n\torg.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)\n\torg.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:962)\n\torg.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)\n\torg.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1087)\n\torg.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)\n\torg.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)\n\tjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\torg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n\tjava.lang.Thread.run(Thread.java:748)\n</pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the Apache Tomcat/7.0.76 logs.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.76</h3></body></html>' DEBUG The CA status is: check interrupted due to error: Retrieving CA status failed with status 500 DEBUG Waiting for CA to start... ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 48, in run raise admintool.ScriptError(str(e)) The ipa-server-upgrade command failed, exception: ScriptError: CA did not start in 300.0s ERROR CA did not start in 300.0s -- With command "ipactl start --ignore-service-failures" I can start all the services but pki-tomcatd. -- Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: STOPPED smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful -- Suggested resolution to above problem doesn't help me since the LDAP and NSS DB seem to have same certificates (some difference in wrapping but the string is same if I take out the line breaks) and even the serial number matches. -- certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a -----BEGIN CERTIFICATE----- MIIDjD... ...Prh2G -----END CERTIFICATE----- certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' |grep Serial Serial Number: 4 (0x4) ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso Enter LDAP Password: dn: uid=pkidbuser,ou=people,o=ipaca userCertificate:: MIIDjD... ...Prh2 G description: 2;4;CN=Certificate Authority,O=<<REALM>>;CN=CA Subsystem, O=<<REALM>> seeAlso: CN=CA Subsystem,O=<<REALM>> -- And here's where my actual knowledge of things end. I've been trying to figure out all kind of logs (tomcat, Kerberos, directory server, ...) but haven't found a solid reason for it. I'm starting to believe this is a certificate issue, because although "getcert list" tells me that the certificate status is "Monitoring" on all certificates the expiry date is already in the past (current date 20.6.2018, certificate expiry 21.03.2018) on 4 certificates and it won't update even if I resubmit it or delete certificate and manually redo it (it got the same date as the "old ones"). The "main certs" ("caSigningCert cert-pki-ca", "Server-Cert cert-pki-ca" and two directory server certs) are valid for years (until 2020+). -- Request ID '20160331084234': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=<<REALM>> subject: CN=OCSP Subsystem,O=<<REALM>> expires: 2018-03-21 09:42:04 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign eku: id-kp-OCSPSigning pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20160331085008': 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=<<REALM>> subject: CN=<<ipasrv1.fqdn>>,O=<<REALM>> expires: 2020-03-04 09:58:23 UTC principal name: HTTP/<<ipasrv1.fqdn>>@<<REALM>> key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes -- Has anyone else bumped into same kind of issues? Any ideas where I should continue looking? I'm starting to run out of ideas... Eemeli Jokinen

3 23

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users August 2018