AD trust user logins where their userPrincipalName does not match AD's DNS domain name
by Sam Morris
I have a FreeIPA setup that trusts an Active Directory domain. I have users who exist in the AD domain, but who are unable to log into Linux systems.
The domains are:
ad.domain.examaple: the Active Directory domain
ipa.ad.domain.example: the FreeIPA domain
The user has a SAM-Account-Name of 'user.name' and a userPrincipalName of
'user.name(a)thirdparty.com'.
Here are the log messages I see when one of them tries to log in:
==> krb5_child.log <==
(Thu Jul 23 11:08:58 2020) [[sssd[krb5_child[2481132]]]] [get_and_save_tgt] (0x0020): 1704: [-1765328378][Client 'user.name\@THIRDPARTY.COM(a)IPA.AD.DOMAIN.EXAMPLE' not found in Kerberos database]
(Thu Jul 23 11:08:58 2020) [[sssd[krb5_child[2481132]]]] [map_krb5_error] (0x0020): 1833: [-1765328378][Client 'user.name\@THIRDPARTY.COM(a)IPA.AD.DOMAIN.EXAMPLE' not found in Kerberos database]
==> sssd_ipa.ad.domain.example.log <==
(Thu Jul 23 11:08:58 2020) [sssd[be[ipa.ad.domain.example]]] [krb5_auth_done] (0x0040): The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information
A bit of research brings me to
<https://docs.microsoft.com/en-us/windows/win32/ad/naming-properties> which
states:
A UPN suffix has the following restrictions:
It must be the DNS name of a domain, but does not need to be the name of
the domain that contains the user.
It must be the name of a domain in the current domain forest, or an
alternate name listed in the upnSuffixes attribute of the Partitions container
within the Configuration container.
I believe the user account violates the second of these restrictions, in that
its suffix (thirdparty.com) is neither in the AD forest, nor is it found in the
upnSuffixes attribute of
CN=Partitions,CN=Configuration,DC=ad,DC=domain,DC=example in AD.
Now the ugly part. I suspect this is just How Things Are Done around here and
getting the user's userPrincipalName changed to ad.domain.example will not be
particularly easy.
So in the meantime, is there any configuration I can do, either on the FreeIPA
servers or on the machine where the user needs to log in, to work around the
UPN suffix mismatch?
I am able to get a TGT for the user with 'kinit user.name(a)AD.DOMAIN.EXAMPLE',
so I guess I'm looking for a hypothetical way to tell sssd to map the UPN
suffix in the user's domain (thirdparty.com) to ad.domain.example when it tries
to get a ticket during user login...
I can also ask to get thirdparty.com added to the AD domain's list of UPN
suffixes. Can anyone confirm whether this would be sufficient to get sssd to be
able to authenticate the user?
Thanks!
--
Sam Morris <https://robots.org.uk/>
1 year, 9 months
Centos 8.2.2004 (Core) not pulling FreeIPA 4.8
by Damjan Kumin
Hello guys,
regardless what officially I do, my Centos is not pulling latest FreeiPA binaries to install, it sticks with 4.7
Since everything is working, it is not a deal-breaker, but still, now that everything is stable and config is absolutely correct, it would be time to upgrade and stay up to date with all fixes.
Any help on this topic please? Thanks in advance!
rgD
1 year, 9 months
autofs Troubles
by Ronald Wimmer
Hi,
all over sudden automounting home shares has stopped working on one of
our most important servers. The configuration has not changed at all.
Automounting on servers with identical configuration works.
What i tried so far:
1) stopping rpcidmapd, rpcgssd, autofs, sssd and restarting the services
2) rebooting the system
3) doing ipa-client-automount --uninstall and reconfiguring it again
4) checking /etc/sysconfig/nfs and /etc/idmapd.conf as well as sssd.conf
5) automount -fv tells me that it attemts to mount /home but nothing happens
No matter what I tried I could not get homeshares mounted again.
I would highly appreciate any input that brings me one step further.
Cheers,
Ronald
1 year, 10 months
ssh session timeout on freeipa clients
by Saurabh Garg
Hi,
Can someone please help me find an option if IdM server allows to control the ssh session timeout for user logins on freeipa clients?
thanks,
sgarg
1 year, 10 months
FreeIPA CA failing to login with new admin user
by Stasiek Michalski
Hello,
I installed FreeIPA replica on 4.8.4 on CentOS 8 from 4.4.4 from Fedora
25 with `ipa-replica-install --setup-dns --auto-forwarders`, without
`--setup-ca` due to errors, which went fine. I do want to install CA
though, which failed when I did `--setup-ca` and then later
`ipa-ca-install` with the following error:
```
[4/29]: creating installation admin user
Unable to log in as uid=admin-freeipa2.infra.opensuse.org,ou=people,o=ipaca on ldap://freeipa.infra.opensuse.org:389
[hint] tune with replication_wait_timeout
[error] NotFound: uid=admin-freeipa2.infra.opensuse.org,ou=people,o=ipaca did not replicate to ldap://freeipa.infra.opensuse.org:389
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
```
Obviously I did try try extending the timeout based on that, but I don't
think that was helpful in the end, considering the logs produced by the
old server:
httpd access_log
```
192.168.47.90 - - [23/Jul/2020:00:25:36 +0000] "GET /ca/rest/account/login HTTP/1.1" 401 994
```
server process in journal
```
SSLAuthenticatorWithFallback: Authenticating with BASIC authentication
Invalid Credential.
at com.netscape.cmscore.authentication.PasswdUserDBAuthentication.authenticate(PasswdUserDBAuthentication.java:167)
at com.netscape.cms.realm.PKIRealm.authenticate(PKIRealm.java:63)
at com.netscape.cms.tomcat.ProxyRealm.authenticate(ProxyRealm.java:78)
at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:94)
at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.doSubAuthenticate(SSLAuthenticatorWithFallback.java:37)
at com.netscape.cms.tomcat.AbstractPKIAuthenticator.doAuthenticate(AbstractPKIAuthenticator.java:98)
at com.netscape.cms.tomcat.SSLAuthenticatorWithFallback.authenticate(SSLAuthenticatorWithFallback.java:47)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:579)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:502)
at org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java:877)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1539)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1495)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
SSLAuthenticatorWithFallback: Fallback auth header: WWW-Authenticate=Basic realm="Certificate Authority"
SSLAuthenticatorWithFallback: Fallback auth return code: 401
SSLAuthenticatorWithFallback: Result: false
```
and from pki logs
```
Failed to authenticate as admin UID=admin-freeipa2.infra.opensuse.org. Error: netscape.ldap.LDAPException: error result (49)
```
I don't particularly know how to proceed from here, since those errors
don't mean much to me. I see however it's not just me having issues with
`ipa-ca-install` at least similar to this one (although by the looks of
it, the reason is already different ;)
Thanks in advance for trying,
LCP [Stasiek]
https://lcp.world/
1 year, 10 months
getting authentication token is no longer valid new one required error
by Kannappan M
Hi Team,
we have cloned one of the linux server which is having ipa user ac lets say
1. server a
2.server b
3. server c
4.server a.1 (clone server)
one user has been created in server a.1 , b and c
i was able to login to from b to c and c to b
but when i tried to login to server b to server a.1 or from c to server a.1
getting error as authentication failed error when i dig deep with the cat /var/log/secure getting message as
authentication token is no longer valid; new one required (log messages in server c and server b)
when i checked the logs in server a.1 (cat /var/log/secure)
pam_sss(sshd:auth): authentication success ; logname= uid = 0 euid=0 tty=ssh ruser= rhost= server c user
error:pam: user account has expired for USER from server c
please help me to fix it
Regards
Kanna
1 year, 10 months
PKI for Windows
by Vinícius Ferrão
Hello,
I need to issue some certificates for the AD Environment and I don’t have ADCS in place. So my FreeIPA deployment was with a self signed CA and the common AD Trust enabled.
Now with this issue I’m looking on the IPA’s documentation and there’s some recommendations to deploy IPA as as subCA from ADCS, but as as I said, I don’t have it. So I was thinking if it’s possible to issue certificates for Windows machines directly form FreeIPA, and if this is recommended or not.
If it’s possible but it will be a hassle, there’s a way to make FreeIPA talk with ADCS after the deployment? I can setup an ADCS instance to keep Windows certificates in a separate location.
I saw this post: https://frasertweedale.github.io/blog-redhat/posts/2019-09-23-direct-inte... but I don’t think it’s the same issue here; the valuable info that I found on this site is about trusting the FreeIPA CA certificate on Windows environment: "Operationally there is one additional step when the IPA CA is not subordinate to the AD CA: the IPA CA certificate has to be explicitly trusted.”; but the use case does not seems to be on a Windows system.
Thanks for any guidance.
1 year, 10 months
Re: ipa-ca-install fails
by Roberto Cornacchia
Hi,
I just wanted thank Rob for the help and give a conclusion to this thread,
in case anyone else needs to replicate from some old version like 4.2
I first wanted to replicate from 4.2.4 to 4.8.4 (provided by CentOS 8).
Just not possible (4.8 doesn't support replication from level 0).
So I decided to first replicate from 4.2 to 4.6.6 (provided by CentOS 7). I
got almost at the end, but I found too many incompatibilities. Not worth
the effort.
My next attempt was from 4.2.4 to 4.4.4 (provided by FC25). This succeeded,
but had to upgrade nss to get past https://pagure.io/freeipa/issue/4676
Lesson learned: don't try to skip too many releases.
On Fri, 24 Jul 2020 at 15:33, Roberto Cornacchia <
roberto.cornacchia(a)gmail.com> wrote:
> I actually went further - I'm really close now.
>
> Hinted by https://bugzilla.redhat.com/show_bug.cgi?id=1158410, I adjusted
> /usr/share/pki/server/conf/ciphers.info
> /usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py
> to use the same ciphers as ipa01.
>
> This worked, and it got almost to the end (with one step in between - I
> needed to open port 8443 on ipa01):
>
> [root@ipa02 ~]# ipa-ca-install replica-info-ipa02.hq.spinque.com.gpg
> Password for admin(a)HQ.SPINQUE.COM:
> Directory Manager (existing master) password:
>
> Run connection check to master
> Connection check OK
> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
> [1/27]: configuring certificate server instance
> [2/27]: reindex attributes
> [3/27]: exporting Dogtag certificate store pin
> [4/27]: stopping certificate server instance to update CS.cfg
> [5/27]: backing up CS.cfg
> [6/27]: disabling nonces
> [7/27]: set up CRL publishing
> [8/27]: enable PKIX certificate path discovery and validation
> [9/27]: starting certificate server instance
> [10/27]: setting audit signing renewal to 2 years
> [11/27]: restarting certificate server
> [12/27]: authorizing RA to modify profiles
> [13/27]: authorizing RA to manage lightweight CAs
> [14/27]: Ensure lightweight CAs container exists
> [15/27]: Ensuring backward compatibility
> [16/27]: configure certificate renewals
> [17/27]: configure Server-Cert certificate renewal
> [18/27]: Configure HTTP to proxy connections
> [19/27]: restarting certificate server
> [20/27]: updating IPA configuration
> [21/27]: enabling CA instance
> [22/27]: exposing CA instance on LDAP
> [23/27]: migrating certificate profiles to LDAP
> [24/27]: importing IPA certificate profiles
> [25/27]: adding default CA ACL
> [26/27]: adding 'ipa' CA entry
> [error] HTTPRequestError: Request failed with status 404: Non-2xx
> response from CA REST API: 404.
>
> The failing call was
> https://ipa01.hq.spinque.com:8443/ca/rest/authorities/host-authority.
> This comes after a successful POST
> https://ipa01.hq.spinque.com:8443/ca/rest/profiles/KDCs_PKINIT_Certs?acti...
>
> The subpath /authorities doesn't seem to exist on ipa01 - probably it
> changed.
>
> Is there a workaround here?
>
> If not: it was almost at the end. Is it missing crucial steps or can I get
> away with it?
>
> The CA is up, I'm just not sure if it is safe to use.
> Can I check its health further than the following?
>
> [root@ipa02 ~]# ipa server-role-find --role "CA server"
> ----------------------
> 2 server roles matched
> ----------------------
> Server name: ipa02.hq.spinque.com
> Role name: CA server
> Role status: enabled
>
> Server name: ipa01.hq.spinque.com
> Role name: CA server
> Role status: enabled
> ----------------------------
> Number of entries returned 2
> ----------------------------
>
>
>
> On Fri, 24 Jul 2020 at 13:20, Roberto Cornacchia <
> roberto.cornacchia(a)gmail.com> wrote:
>
>> Thanks Rob.
>>
>> Skipping the key checks got me past that error. So the connection test
>> passes!
>>
>> Unfortunately now I have a cipher issue.
>>
>> [root@ipa02 ~]# ipa-ca-install replica-info-ipa02.hq.spinque.com.gpg
>> Directory Manager (existing master) password:
>>
>> Run connection check to master
>> Connection check OK
>> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
>> [1/27]: configuring certificate server instance
>> ipaserver.install.dogtaginstance: CRITICAL Failed to configure CA
>> instance: Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpkUNbPC' returned
>> non-zero exit status 1
>> ipaserver.install.dogtaginstance: CRITICAL See the installation logs and
>> the following files/directories for more information:
>> ipaserver.install.dogtaginstance: CRITICAL /var/log/pki/pki-tomcat
>>
>> /var/log/pki/pki-tomcat/ca/debug
>>
>> [http-bio-8443-exec-3]: ConfigurationUtils: GET
>> https://ipa01.hq.spinque.com:443/ca/admin/ca/getCertChain
>> javax.ws.rs.ProcessingException: Unable to invoke request
>> at
>> org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:287)
>> ...
>> Caused by: java.io.IOException: SocketException cannot write on socket
>> at org.mozilla.jss.ssl.SSLSocket.write(SSLSocket.java:1503)
>>
>> ipa01:/var/log/httpd/error_log says:
>> [:error] [pid 18129] SSL Library Error: -12286 No common encryption
>> algorithm(s) with client
>>
>> I guess it makes sense, old ciphers have been disabled in the newer
>> release.
>>
>> Testing with openssl from ipa02 against ipa01, I found only these being
>> accepted:
>> AES128-SHA
>> DES-CBC3-SHA
>> RC4-SHA
>> RC4-MD5
>>
>> How can I temporarily make ipa-ca-install accept old ciphers?
>> Before running ipa-ca-install there is even no pki-tomcat configured on
>> ipa02, but running it fails.
>>
>> Any idea?
>>
>> On Fri, 24 Jul 2020 at 00:46, Rob Crittenden <rcritten(a)redhat.com> wrote:
>>
>>> Roberto Cornacchia via FreeIPA-users wrote:
>>> > Hi Rob,
>>> >
>>> > Thanks for the tip.
>>> >
>>> > I don't see errors that I've found before, but quite some errors.
>>> >
>>> > In attachment is the result of
>>> > grep -v SUCCESS /var/log/httpd/error_log
>>> > for today.
>>>
>>> IPA stopped using memcached in I think version 4.5.0. I guess the key
>>> size in the session grew since then.
>>>
>>> I'm not sure what the best workaround is. On the 4.2 servers you could
>>> try to modify /usr/lib/python*/site-packages/ipaserver/session.py and
>>> find:
>>>
>>> self.mc = memcache.Client(self.servers, debug=0)
>>>
>>> Add check_keys=False to that initialization to not check sizing. That
>>> could have other unintended consequences that I'm not aware of.
>>>
>>> Restart httpd after making this change.
>>>
>>> > I've also tried to replicate the error that I got with
>>> > ipa-replica-install, during the server upgrade step.
>>> > I ran ipa-server-upgrade -v on ipa02, and got the same error
>>> > "ipaserver.install.ldapupdate: ERROR Add failure attribute "cn" not
>>> > allowed".
>>>
>>> /var/log/ipaserver-upgrade.log should have more context.
>>>
>>> >
>>> > I also see something else that is strane in the output
>>> > of ipa-server-upgrade -v:
>>> >
>>> > Failed to check CA status: cannot connect to
>>> > 'http://ipa01.hq.spinque.com:8080/ca/admin/ca/getStatus': [Errno 113]
>>> No
>>> > route to host
>>> >
>>> > I wonder why 8080. Shouldn't this be on 80?
>>>
>>> Try opening port 8080. It tries to contact the CA directly and not
>>> through the Apache proxy.
>>>
>>> >
>>> > [root@ipa02 ~]# curl
>>> > 'http://ipa01.hq.spinque.com:8080/ca/admin/ca/getStatus'
>>> > curl: (7) Failed connect to ipa01.hq.spinque.com:8080
>>> > <http://ipa01.hq.spinque.com:8080>; No route to host
>>> >
>>> > [root@ipa02 ~]# curl '
>>> http://ipa01.hq.spinque.com/ca/admin/ca/getStatus'
>>> > <?xml version="1.0" encoding="UTF-8"
>>> >
>>> standalone="no"?><XMLResponse><State>1</State><Type>CA</Type><Status>running</Status><Version>10.2.6-20.fc23</Version></XMLResponse>
>>> >
>>> > Roberto
>>> >
>>> > On Thu, 23 Jul 2020 at 19:08, Rob Crittenden <rcritten(a)redhat.com
>>> > <mailto:rcritten@redhat.com>> wrote:
>>> >
>>> > Roberto Cornacchia via FreeIPA-users wrote:
>>> > > ipa-replica-conncheck fails with --auto-master-check (used by
>>> > > ipa-ca-install), but not without:
>>> > >
>>> > >
>>> > > [root@ipa02 ~]# /usr/sbin/ipa-replica-conncheck --master
>>> > > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>
>>> > <http://ipa01.hq.spinque.com> --auto-master-check
>>> > > --realm HQ.SPINQUE.COM <http://HQ.SPINQUE.COM>
>>> > <http://HQ.SPINQUE.COM> --hostname
>>> > > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>
>>> > <http://ipa02.hq.spinque.com>
>>> > > Check connection from replica to remote master
>>> > 'ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>
>>> > > <http://ipa01.hq.spinque.com>':
>>> > > Directory Service: Unsecure port (389): OK
>>> > > Directory Service: Secure port (636): OK
>>> > > Kerberos KDC: TCP (88): OK
>>> > > Kerberos Kpasswd: TCP (464): OK
>>> > > HTTP Server: Unsecure port (80): OK
>>> > > HTTP Server: Secure port (443): OK
>>> > >
>>> > > The following list of ports use UDP protocoland would need to be
>>> > > checked manually:
>>> > > Kerberos KDC: UDP (88): SKIPPED
>>> > > Kerberos Kpasswd: UDP (464): SKIPPED
>>> > >
>>> > > Connection from replica to master is OK.
>>> > > Start listening on required ports for remote master check
>>> > > 389 tcp: Failed to bind
>>> > > 636 tcp: Failed to bind
>>> > > 88 tcp: Failed to bind
>>> > > 88 udp: Failed to bind
>>> > > 464 tcp: Failed to bind
>>> > > 464 udp: Failed to bind
>>> > > 80 tcp: Failed to bind
>>> > > 443 tcp: Failed to bind
>>> > > Get credentials to log in to remote master
>>> > > Check RPC connection to remote master
>>> > > trying https://ipa01.hq.spinque.com/ipa/session/json
>>> > > *Connection to https://ipa01.hq.spinque.com/ipa/session/json
>>> > failed with
>>> > > <ProtocolError for ipa01.hq.spinque.com/ipa/session/json
>>> > <http://ipa01.hq.spinque.com/ipa/session/json>
>>> > > <http://ipa01.hq.spinque.com/ipa/session/json>: 500 Internal
>>> > Server Error>*
>>> > > trying https://ipa02.hq.spinque.com/ipa/session/json
>>> > > [try 1]: Forwarding 'schema' to json server
>>> > > 'https://ipa02.hq.spinque.com/ipa/session/json'
>>> > > trying https://ipa01.hq.spinque.com/ipa/session/json
>>> > > Connection to https://ipa01.hq.spinque.com/ipa/session/json
>>> failed
>>> > with
>>> > > <ProtocolError for ipa01.hq.spinque.com/ipa/session/json
>>> > <http://ipa01.hq.spinque.com/ipa/session/json>
>>> > > <http://ipa01.hq.spinque.com/ipa/session/json>: 500 Internal
>>> > Server Error>
>>> > > trying https://ipa02.hq.spinque.com/ipa/session/json
>>> > > [try 1]: Forwarding 'ping/1' to json server
>>> > > 'https://ipa02.hq.spinque.com/ipa/session/json'
>>> > > Execute check on remote master
>>> > > [try 1]: Forwarding 'server_conncheck' to json server
>>> > > 'https://ipa02.hq.spinque.com/ipa/session/json'
>>> > > *ERROR: Remote master check failed with following error
>>> message(s):
>>> > > invalid 'cn': must be "ipa02.hq.spinque.com
>>> > <http://ipa02.hq.spinque.com> <http://ipa02.hq.spinque.com>"*
>>> > >
>>> > >
>>> > > Now, without --auto-master-check:
>>> > >
>>> > > On ipa02 (I suppose the many "Failed to bind" below are
>>> expected?):
>>> > > [root@ipa02 ~]# /usr/sbin/ipa-replica-conncheck --master
>>> > > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>
>>> > <http://ipa01.hq.spinque.com> --realm
>>> > > HQ.SPINQUE.COM <http://HQ.SPINQUE.COM> <http://HQ.SPINQUE.COM>
>>> > --hostname ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>
>>> > > <http://ipa02.hq.spinque.com>
>>> > > Check connection from replica to remote master
>>> > 'ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>
>>> > > <http://ipa01.hq.spinque.com>':
>>> > > Directory Service: Unsecure port (389): OK
>>> > > Directory Service: Secure port (636): OK
>>> > > Kerberos KDC: TCP (88): OK
>>> > > Kerberos Kpasswd: TCP (464): OK
>>> > > HTTP Server: Unsecure port (80): OK
>>> > > HTTP Server: Secure port (443): OK
>>> > >
>>> > > The following list of ports use UDP protocoland would need to be
>>> > > checked manually:
>>> > > Kerberos KDC: UDP (88): SKIPPED
>>> > > Kerberos Kpasswd: UDP (464): SKIPPED
>>> > >
>>> > > Connection from replica to master is OK.
>>> > > Start listening on required ports for remote master check
>>> > > 389 tcp: Failed to bind
>>> > > 636 tcp: Failed to bind
>>> > > 88 tcp: Failed to bind
>>> > > 88 udp: Failed to bind
>>> > > 464 tcp: Failed to bind
>>> > > 464 udp: Failed to bind
>>> > > 80 tcp: Failed to bind
>>> > > 443 tcp: Failed to bind
>>> > > Listeners are started. Use CTRL+C to terminate the listening part
>>> > after
>>> > > the test.
>>> > >
>>> > > Please run the following command on remote master:
>>> > > /usr/sbin/ipa-replica-conncheck --replica ipa02.hq.spinque.com
>>> > <http://ipa02.hq.spinque.com>
>>> > > <http://ipa02.hq.spinque.com>
>>> > > ^C
>>> > > Cleaning up...
>>> > >
>>> > > On ipa01:
>>> > > [root@ipa01 ~]# /usr/sbin/ipa-replica-conncheck --replica
>>> > > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>
>>> > <http://ipa02.hq.spinque.com>
>>> > > Check connection from master to remote replica
>>> > 'ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>
>>> > > <http://ipa02.hq.spinque.com>':
>>> > > Directory Service: Unsecure port (389): OK
>>> > > Directory Service: Secure port (636): OK
>>> > > Kerberos KDC: TCP (88): OK
>>> > > Kerberos KDC: UDP (88): WARNING
>>> > > Kerberos Kpasswd: TCP (464): OK
>>> > > Kerberos Kpasswd: UDP (464): WARNING
>>> > > HTTP Server: Unsecure port (80): OK
>>> > > HTTP Server: Secure port (443): OK
>>> > > The following UDP ports could not be verified as open: 88, 464
>>> > > This can happen if they are already bound to an application
>>> > > and ipa-replica-conncheck cannot attach own UDP responder.
>>> > >
>>> > > Connection from master to replica is OK.
>>> > >
>>> > >
>>> > >
>>> > > On Thu, 23 Jul 2020 at 15:15, Roberto Cornacchia
>>> > > <roberto.cornacchia(a)gmail.com
>>> > <mailto:roberto.cornacchia@gmail.com>
>>> > <mailto:roberto.cornacchia@gmail.com
>>> > <mailto:roberto.cornacchia@gmail.com>>> wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > I have successfully created a replica from a 4.2.4 master
>>> (ipa01)
>>> > > into a new 4.6.6 master (ipa02).
>>> > >
>>> > > I did it without --setup-ca option (because it had failed),
>>> so the
>>> > > only CA is still on the 4.2.4 server (ipa01).
>>> > >
>>> > > When I try to setup theCA on ipa02 (the same replica file
>>> was used
>>> > > with ipa-replica-install), this fails:
>>> > >
>>> > > $ ipa-ca-install replica-info-ipa02.hq.spinque.com.gpg
>>> > > Directory Manager (existing master) password:
>>> > >
>>> > > Run connection check to master
>>> > >
>>> > > Your system may be partly configured.
>>> > > Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>> > >
>>> > > Connection check failed!
>>> > > See /var/log/ipareplica-conncheck.log for more information.
>>> > > If the check results are not valid it can be skipped with
>>> > > --skip-conncheck parameter.
>>> > >
>>> > > The log of conncheck (generated by ipa-ca-install) is in
>>> > attachment.
>>> > > In there, I can see a couple of things going wrong:
>>> > >
>>> > > ProtocolError: <ProtocolError for
>>> > > ipa01.hq.spinque.com/ipa/session/json
>>> > <http://ipa01.hq.spinque.com/ipa/session/json>
>>> > > <http://ipa01.hq.spinque.com/ipa/session/json>: 500 Internal
>>> > Server
>>> > > Error>
>>> > > ...
>>> > > 2020-07-23T12:20:50Z ERROR ERROR: Remote master check failed
>>> with
>>> > > following error message(s):
>>> > > invalid 'cn': must be "ipa02.hq.spinque.com
>>> > <http://ipa02.hq.spinque.com>
>>> > > <http://ipa02.hq.spinque.com>"
>>> > >
>>> > > Not sure if relevant, but also ipa-replica-install, though it
>>> > > completed successfully, gave this error:
>>> > >
>>> > > Upgrading IPA:. Estimated time: 1 minute 30 seconds
>>> > > [1/10]: stopping directory server
>>> > > [2/10]: saving configuration
>>> > > [3/10]: disabling listeners
>>> > > [4/10]: enabling DS global lock
>>> > > [5/10]: disabling Schema Compat
>>> > > [6/10]: starting directory server
>>> > > [7/10]: upgrading server
>>> > > ipaserver.install.ldapupdate: ERROR Add failure attribute
>>> "cn"
>>> > > not allowed
>>> > > [8/10]: stopping directory server
>>> > > [9/10]: restoring configuration
>>> > > [10/10]: starting directory server
>>> > >
>>> > >
>>> > > Could you please help me find the issue?
>>> >
>>> > Look on ipa01.hq.spinque.com <http://ipa01.hq.spinque.com> in
>>> > /var/log/httpd/error_log for those
>>> > internal errors.
>>> >
>>> > rob
>>> >
>>> >
>>> > _______________________________________________
>>> > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> > List Guidelines:
>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> > List Archives:
>>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>> >
>>>
>>>
1 year, 10 months
[SSSD-users] Announcing SSSD 2.3.1
by Pavel Březina
# SSSD 2.3.1
The SSSD team is proud to announce the release of version 2.3.1 of the
System Security Services Daemon. The tarball can be downloaded from:
https://github.com/SSSD/sssd/releases/tag/sssd-2_3_1
See the full release notes at:
https://sssd.io/docs/users/relnotes/notes_2_3_1
RPM packages will be made available for Fedora shortly.
## Feedback
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
## Highlights
### New features
- Domains can be now explicitly enabled or disabled using `enable` option in
domain section. This can be especially used in configuration snippets.
- New configuration options `memcache_size_passwd`, `memcache_size_group`,
`memcache_size_initgroups` that can be used to control memory cache size.
### Notable bug fixes
- Fixed several regressions in GPO processing introduced in sssd-2.3.0
- Fixed regression in PAM responder: failures in cache only lookups are
no longer considered fatal
- Fixed regression in proxy provider: `pwfield=x` is now default value
only for `sssd-shadowutils` target
### Packaging changes
- `libwbclient` is now deprecated and is not being built by default (use
`--with-libwibclient` to build it)
### Documentation Changes
- Added option `memcache_size_passwd`
- Added option `memcache_size_group`
- Added option `memcache_size_initgroups`
- Added option `enable` in domain sections
- Minor text improvements
1 year, 10 months
