dns discovery failed
by Andrew Meyer
So I decided to rebuild my setup at home. I am running this on CentOS 7 latest and have gotten the server working just fine. I am trying to setup a client server and getting the following:
[ameyer@jump01 vmware-tools-distrib]$ sudo ipa-client-install [sudo] password for ameyer: DNS discovery failed to determine your DNS domainProvide the domain name of your IPA server (ex: example.com): ^CThe ipa-client-install command failed. See /var/log/ipaclient-install.log for more information[ameyer@jump01 vmware-tools-distrib]$
My /etc/resolv.conf is pointed at the FreeIPA server and I am able to resolve DNS. I can telnet to port 53.
I'm seeing the fact that I can't connect to LDAP in my error logs. However I can get to the web ui.
5 years, 8 months
Global Catalog Support on FreeIPA 4.7 ?
by Zafer Syed
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 ?
5 years, 8 months
sambahomepath
by Jon Wright
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
5 years, 8 months
selinux issues
by Kat
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
5 years, 8 months
Authenticating RHEL 7 to IPA using the LDAP connector
by William Muriithi
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
5 years, 8 months
Certificates renewing with the wrong Subject
by Roderick Johnstone
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
5 years, 8 months
accessing the api
by Andrew Meyer
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><!--[if lt IE 7]> <html class="no-js ie6 oldie" lang="en-US"> <![endif]--><!--[if IE 7]> <html class="no-js ie7 oldie" lang="en-US"> <![endif]--><!--[if IE 8]> <html class="no-js ie8 oldie" lang="en-US"> <![endif]--><!--[if gt IE 8]><!--> <html class="no-js" lang="en-US"> <!--<![endif]--><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" /><!--[if lt IE 9]><link rel="stylesheet" id='cf_styles-ie-css' href="/cdn-cgi/styles/cf.errors.ie.css" type="text/css" media="screen,projection" /><![endif]--><style type="text/css">body{margin:0;padding:0}</style>
<!--[if gte IE 10]><!--><script type="text/javascript" src="/cdn-cgi/scripts/zepto.min.js"></script><!--<![endif]--><!--[if gte IE 10]><!--><script type="text/javascript" src="/cdn-cgi/scripts/cf.common.js"></script><!--<![endif]-->
</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><!-- /.header -->
<section></section><!-- spacer -->
<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><!-- /.section -->
<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><!-- /.error-footer -->
</div><!-- /#cf-error-details --> </div><!-- /#cf-wrapper -->
<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
5 years, 8 months
Re: Changing domain name
by Angus Clarke
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/
>
>
5 years, 8 months
Passync AD *and* trust?
by Pieter Baele
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
5 years, 8 months