[Freeipa-users] Re: Redhat Idm/IPA cross domain trust problems

[Sumit Bose via FreeIPA-users]

Am Wed, Jun 09, 2021 at 07:32:49PM - schrieb thing.thing--- via 
FreeIPA-users:
> Hi,
> 
> I have RH's version of freeipa
> (ipa-server-4.9.2-3.module+el8.4.0+10412+5ecb5b37.x86_64) working fine. 
> RHEL8, RHEL7,
> Debian10.9, Ubuntu20LTS and Centos7 clients work perfectly OK to IPA OK for 
> users in
> IPA..
> 
> For the cross domain trust however only RHEL8 and RHEL7 work. Debian10.9, 
> Ubuntu20LTS and
> Centos7 fail for the AD user who cannot ssh in.
> 
> Is there any config I need to do to get 3rd party Linux to work with a trust? 
> Just
> wondering if I have missed a package? config? steps?
> 
> or does it just not work?
> 
> rhel7 secure log showing success,
> 
> 8><
> Jun 9 16:40:55 rhel7a sshd[9339]: pam_sss(sshd:auth): authentication success; 
> logname=
> uid=0 euid=0 tty=ssh ruser= rhost=v1.ods.vuw.ac.nz 
> user=linuxuser2(a)vuwtest.ac.nz
> Jun 9 16:41:04 rhel7a sshd[9336]: Accepted keyboard-interactive/pam for
> linuxuser2(a)vuwtest.ac.nz from 10.100.32.67 port 48
> Jun 9 16:41:04 rhel7a sshd[9336]: pam_unix(sshd:session): session opened for 
> user
> linuxuser2(a)vuwtest.ac.nz by (uid=0)
> [root@rhel7a ~]#
> 8><---
> 
> 
> centos7 secure log,
> 
> 8><---
> [root@centos7a ~]# tail -50f /var/log/secure
> Jun 9 17:15:24 centos7a sshd[1812]: Invalid user linuxuser2(a)vuwtest.ac.nz 
> from
> 10.100.32.67 port 53880

Hi,

it looks like the user cannot be resolved on this system. Does

getent passwd linuxuser2(a)vuwtest.ac.nz

work on this system?

bye,
Sumit

> Jun 9 17:15:24 centos7a sshd[1812]: input_userauth_request: invalid user
> linuxuser2(a)vuwtest.ac.nz [preauth]
> Jun 9 17:15:24 centos7a sshd[1812]: Postponed keyboard-interactive for 
> invalid user
> linuxuser2(a)vuwtest.ac.nz from 10.100.32.67 port 53880 ssh2 [preauth]
> Jun 9 17:15:35 centos7a sshd[1814]: pam_unix(sshd:auth): check pass; user 
> unknown
> Jun 9 17:15:35 centos7a sshd[1814]: pam_unix(sshd:auth): authentication 
> failure; logname=
> uid=0 euid=0 tty=ssh ruser= rhost=10.100.32.67
> Jun 9 17:15:37 centos7a sshd[1812]: error: PAM: User not known to the 
> underlying
> authentication module for illegal user linuxuser2(a)vuwtest.ac.nz from 
> 10.100.32.67
> Jun 9 17:15:37 centos7a sshd[1812]: Failed keyboard-interactive/pam for 
> invalid user
> linuxuser2(a)vuwtest.ac.nz from 10.100.32.67 port 53880 ssh2
> Jun 9 17:15:37 centos7a sshd[1812]: Postponed keyboard-interactive for 
> invalid user
> linuxuser2(a)vuwtest.ac.nz from 10.100.32.67 port 53880 ssh2 [preauth]
> 8><---
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Join command 500 errors, timeouts

[Alfred Victor via FreeIPA-users]

Hi Rob,

I have reduced that timeout and will tune it further. Regarding ISE errors,
I think we can make the assumption that this is entirely an issue of the
web timeouts, I haven't seen any evidence otherwise and will have another
attempt at converting nodes tomorrow, and with a keener eye of what to look
for I can make a better determination then. I am most concerned over what
the underlying cause might be causing it to take too long and hit the
timeout, and don't want to engineer around this by changing Apache timeouts
if we can instead address the root cause. I am suspicious of krb log
messages flooding our IPA systems about a service principal like so, but
not sure if this is gumming up the works (or even why this message has
started appearing since the rebuild):

./krb5kdc.log:Jun 09 10:38:51 redacted.redacted.com
krb5kdc[31187](info): TGS_REQ (4 etypes {18 17 16 23}) 10.1.1.27:
LOOKING_UP_SERVER: authtime 0,
host/redacted.redacted@redacted.com for
nfs/nfsserver.redacted@redacted.com, Server not found in Kerberos
database


Just in the last 5 hours alone, this log message and others like it
(main difference is just the nodename it references) has appeared
1,097,471 times. Conceivably there is also some log write locking or
something going on that could be slowing IPA down and leading to our
symptom here?

Alfred


On Wed, Jun 9, 2021 at 9:19 AM Rob Crittenden  wrote:

> Alfred Victor wrote:
> > Hi Rob,
> >
> > We did revert to 60s - I seem to remember some ldapsearch timing out
> > previously but maybe we could still greatly reduce this with no ill
> > effect. However, we saw no change in join success either way and I have
> > not changed anything in Apache as I would need to find the exact values
> > in question and I think these directive changes may get lost with an
> > update? The timeout/ISE issues are new - we previously booted many nodes
> > concurrently (400+) without problems but now it happens even booting as
> > few as 50 results in 10-20 timeouts or ISE. This has been the case at
> > least since we rebuilt and re-replicated the environment by swapping IPA
> > members out of the old one, but maybe this is unrelated. Is it possible
> > we landed on a newer version with different timeout values? Is it
> > possible that IPA is under slightly more load from the higher number of
> > nodes and has some bottleneck since we last did conversions? We have not
> > been able to substantiate the latter by looking at CPU/memory/io trends.
> > What might we investigate next to see if we may have missed some ongoing
> > issue that could for instance cause locking problems or something else
> > internally in IPA to explain our symptoms? Also, I have observed some
> > nodes which report a successful installation of IPA client, but have in
> > fact a lot of failures, for instance with mounts not working from
> > automount setup. We will need to try to reproduce this to understand
> > what happened I think as we have already sorted those nodes elsewhere
> > and they have got going outside of IPA.
> >
> > I am interested that you suggested "at least some of the clients aren't
> > connecting at all and increasing the timeout could make this worse" -
> > this might indicate some sort of network problem at play, but as far as
> > I am aware, everything is working absent IPA so I do not suspect it
> > presently.
>
> A 60 second LDAP timeout is still way too big. The default is 2. Unless
>  you are seeing timeouts I'd suggest lowering it.
>
> I'm only seeing hints to what you're seeing and the scope so it's hard
> to make further suggestions. Are all the internal errors the same, for
> example? Are some failing due to LDAP timeouts or are they all wsgi read
> timeouts?
>
> The Apache request timeout can be configured in httpd.conf which is
> independent of the config files that IPA currently writes so it should
> survive upgrades.
>
> rob
> >
> > Alfred
> >
> > On Mon, Jun 7, 2021 at 4:42 PM Rob Crittenden  > > wrote:
> >
> > Alfred Victor wrote:
> > > Actually, no change happened from 300-> 600 timeout, the web portal
> > > itself gave me an ISE I hadn't noticed when I tried clicking save!
> >
> > I wasn't clear which log to look in. You'll see details about where
> the
> >  error is caught in IPA in the Apache log. To see LDAP timeouts you
> look
> > for err=3 in the 389-ds access log.
> >
> > But since you posted a traceback this time it's clear that this is
> just
> > Apache waiting for client data to read so any tuning you do needs to
> be
> > in Apache. You could try tuning Timeout which defaults to 60 but this
> > doesn't seem likely to help since at least some of the clients aren't
> > connecting at all and increasing the timeout could make this worse.
> >
> > Please revert the searchtimeout. 300 seconds is orders of magnitude
> > too big.
> >
> > rob
> >
> > >
> > > Alfred
> > >
> > > On Mon, Jun 7, 

[Freeipa-users] Re: CentOS 6 Client installation stuck and don't complete

[thing.thing--- via FreeIPA-users]

If no one else has any ideas, RHEL6 / Centos 6 is well obsolete so it maybe its 
to old for a sssd client to work with new?  I suggest do a trail run on a 
"modern" Linux client version Centos 8.3 by the look of it to prove that 
everything works OK.   Then if no one suggests anything you might have to build 
your own rpm of sssd.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Redhat Idm/IPA cross domain trust problems

[thing.thing--- via FreeIPA-users]

Hi,

I have RH's version of freeipa
(ipa-server-4.9.2-3.module+el8.4.0+10412+5ecb5b37.x86_64) working fine. RHEL8, 
RHEL7,
Debian10.9, Ubuntu20LTS and Centos7 clients work perfectly OK to IPA OK for 
users in
IPA..

For the cross domain trust however only RHEL8 and RHEL7 work. Debian10.9, 
Ubuntu20LTS and
Centos7 fail for the AD user who cannot ssh in.

Is there any config I need to do to get 3rd party Linux to work with a trust? 
Just
wondering if I have missed a package? config? steps?

or does it just not work?

rhel7 secure log showing success,

8><
Jun 9 16:40:55 rhel7a sshd[9339]: pam_sss(sshd:auth): authentication success; 
logname=
uid=0 euid=0 tty=ssh ruser= rhost=v1.ods.vuw.ac.nz 
user=linuxuser2(a)vuwtest.ac.nz
Jun 9 16:41:04 rhel7a sshd[9336]: Accepted keyboard-interactive/pam for
linuxuser2(a)vuwtest.ac.nz from 10.100.32.67 port 48
Jun 9 16:41:04 rhel7a sshd[9336]: pam_unix(sshd:session): session opened for 
user
linuxuser2(a)vuwtest.ac.nz by (uid=0)
[root@rhel7a ~]#
8><---


centos7 secure log,

8><---
[root@centos7a ~]# tail -50f /var/log/secure
Jun 9 17:15:24 centos7a sshd[1812]: Invalid user linuxuser2(a)vuwtest.ac.nz from
10.100.32.67 port 53880
Jun 9 17:15:24 centos7a sshd[1812]: input_userauth_request: invalid user
linuxuser2(a)vuwtest.ac.nz [preauth]
Jun 9 17:15:24 centos7a sshd[1812]: Postponed keyboard-interactive for invalid 
user
linuxuser2(a)vuwtest.ac.nz from 10.100.32.67 port 53880 ssh2 [preauth]
Jun 9 17:15:35 centos7a sshd[1814]: pam_unix(sshd:auth): check pass; user 
unknown
Jun 9 17:15:35 centos7a sshd[1814]: pam_unix(sshd:auth): authentication 
failure; logname=
uid=0 euid=0 tty=ssh ruser= rhost=10.100.32.67
Jun 9 17:15:37 centos7a sshd[1812]: error: PAM: User not known to the underlying
authentication module for illegal user linuxuser2(a)vuwtest.ac.nz from 
10.100.32.67
Jun 9 17:15:37 centos7a sshd[1812]: Failed keyboard-interactive/pam for invalid 
user
linuxuser2(a)vuwtest.ac.nz from 10.100.32.67 port 53880 ssh2
Jun 9 17:15:37 centos7a sshd[1812]: Postponed keyboard-interactive for invalid 
user
linuxuser2(a)vuwtest.ac.nz from 10.100.32.67 port 53880 ssh2 [preauth]
8><---


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Invalid CA chain after ca chain renewal

[Philipp Leusmann via FreeIPA-users]

Rob,

thanks, that helped a lot. 

Would be great if removing the old cert automatically was an option in 
ipa-cacert-manage!

Best,
 Philipp
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: How to blend IPA server 4.1.4 on F21 with server 4.6.8 on C7?

[Rob Crittenden via FreeIPA-users]

Bret Wortman via FreeIPA-users wrote:
> Looks like we're missing an LDAP connection port?
> 
> [09/Jun/2021:10:02:54][localhost-startStop-1]: LdapBoundConnFactory: init
> Property internaldb.ldapconn.port missing value
> 
> Full debug log is at 
> https://gist.github.com/wortmanb/7782c5c0c4318c2aec17f2eea589b567
> 
> 

That error is expected (and ignored).

It looks like the failure is here:

[09/Jun/2021:10:02:56][http-bio-8443-exec-3]: ConfigurationUtils: GET
https://ipa1.our.net:443/ca/admin/ca/getCertChain
javax.ws.rs.ProcessingException: Unable to invoke request
...
Caused by: java.io.IOException: SocketException cannot write on socket

So I suppose make sure that communication works but given this is the
standard https port it seems like it should just work. Look on
ipa1.our.net to see if it got a connection at all, or if it logged some
error.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Join command 500 errors, timeouts

[Rob Crittenden via FreeIPA-users]

Alfred Victor wrote:
> Hi Rob,
> 
> We did revert to 60s - I seem to remember some ldapsearch timing out
> previously but maybe we could still greatly reduce this with no ill
> effect. However, we saw no change in join success either way and I have
> not changed anything in Apache as I would need to find the exact values
> in question and I think these directive changes may get lost with an
> update? The timeout/ISE issues are new - we previously booted many nodes
> concurrently (400+) without problems but now it happens even booting as
> few as 50 results in 10-20 timeouts or ISE. This has been the case at
> least since we rebuilt and re-replicated the environment by swapping IPA
> members out of the old one, but maybe this is unrelated. Is it possible
> we landed on a newer version with different timeout values? Is it
> possible that IPA is under slightly more load from the higher number of
> nodes and has some bottleneck since we last did conversions? We have not
> been able to substantiate the latter by looking at CPU/memory/io trends.
> What might we investigate next to see if we may have missed some ongoing
> issue that could for instance cause locking problems or something else
> internally in IPA to explain our symptoms? Also, I have observed some
> nodes which report a successful installation of IPA client, but have in
> fact a lot of failures, for instance with mounts not working from
> automount setup. We will need to try to reproduce this to understand
> what happened I think as we have already sorted those nodes elsewhere
> and they have got going outside of IPA. 
> 
> I am interested that you suggested "at least some of the clients aren't
> connecting at all and increasing the timeout could make this worse" -
> this might indicate some sort of network problem at play, but as far as
> I am aware, everything is working absent IPA so I do not suspect it
> presently.

A 60 second LDAP timeout is still way too big. The default is 2. Unless
 you are seeing timeouts I'd suggest lowering it.

I'm only seeing hints to what you're seeing and the scope so it's hard
to make further suggestions. Are all the internal errors the same, for
example? Are some failing due to LDAP timeouts or are they all wsgi read
timeouts?

The Apache request timeout can be configured in httpd.conf which is
independent of the config files that IPA currently writes so it should
survive upgrades.

rob
> 
> Alfred
> 
> On Mon, Jun 7, 2021 at 4:42 PM Rob Crittenden  > wrote:
> 
> Alfred Victor wrote:
> > Actually, no change happened from 300-> 600 timeout, the web portal
> > itself gave me an ISE I hadn't noticed when I tried clicking save!
> 
> I wasn't clear which log to look in. You'll see details about where the
>  error is caught in IPA in the Apache log. To see LDAP timeouts you look
> for err=3 in the 389-ds access log.
> 
> But since you posted a traceback this time it's clear that this is just
> Apache waiting for client data to read so any tuning you do needs to be
> in Apache. You could try tuning Timeout which defaults to 60 but this
> doesn't seem likely to help since at least some of the clients aren't
> connecting at all and increasing the timeout could make this worse.
> 
> Please revert the searchtimeout. 300 seconds is orders of magnitude
> too big.
> 
> rob
> 
> >
> > Alfred
> >
> > On Mon, Jun 7, 2021 at 3:57 PM Alfred Victor  
> > >> wrote:
> >
> >     Hi FreeIPA list,
> >
> >     I don't see any in error log that match `grep -i "err=3"
> >     /var/log/httpd/error_log`. We have tried raising
> searchtimelimit as
> >     high as 120, then 300 (now are trying 600) but observed no
> >     difference in the rate at which nodes succeeded or failed in IPA
> >     joins. We are somewhat puzzled by this, as none of the other
> values
> >     we are aware of might have changed, though it is possible that the
> >     IPA systems are under a little higher demand from client
> systems, we
> >     have tried to mitigate this by shutting down some workflows and
> >     aren't sure whether we've seen any improvement. Short of adjusting
> >     apache/resource/process timeouts it is difficult to say what might
> >     be wrong. To give an example, out of 250 nodes rebooted, only 112
> >     joined IPA successfully. Here is some output from the error log,
> >     following what this looks like in the ipa client install log
> (error
> >     log output will match the node attempt):
> >
> >
> >     2021-06-07T18:25:30Z DEBUG The ipa-client-install command
> failed, exception: NetworkError: cannot connect to
> 'https://redactednode.com/ipa/json
> ': Internal Server Error
> >
> >     [Mon Jun 07 

[Freeipa-users] Re: How to blend IPA server 4.1.4 on F21 with server 4.6.8 on C7?

[Bret Wortman via FreeIPA-users]

Looks like we're missing an LDAP connection port?

[09/Jun/2021:10:02:54][localhost-startStop-1]: LdapBoundConnFactory: init
Property internaldb.ldapconn.port missing value

Full debug log is at 
https://gist.github.com/wortmanb/7782c5c0c4318c2aec17f2eea589b567


-- 
  Bret Wortman
  bret.wort...@damascusgrp.com

On Wed, Jun 9, 2021, at 4:59 AM, Bret Wortman via FreeIPA-users wrote:
> My misunderstanding, sorry. This is from the existing CA since that's 
> where I thought the problem would be. Okay, going back and looking at 
> the debug log on the new server to see if it's more revealing.
> 
> 
> -- 
>   Bret Wortman
>   bret.wort...@damascusgrp.com
> 
> On Tue, Jun 8, 2021, at 2:27 PM, Rob Crittenden wrote:
> > Bret Wortman via FreeIPA-users wrote:
> > > I was tailing several logs in /var/log/pki/pki-tomcat/ca/ (debug, system, 
> > > and transactions) and though the replica installation failed again at the 
> > > same point, this is what I got from the logs throughout the installation 
> > > process:
> > 
> > This doesn't seem to show any errors. Reading the pki logs can be
> > problematic as it often charges on after an error is encountered so
> > subsequent errors are basically red herrings but I don't see anything
> > wrong here at all, or I'm missing something.
> > 
> > The IPA installer calls pki-spawn  so not much comes
> > back to us. It's a black box. Can you provide the whole debug log,
> > out-of-band is fine too. I'd also suggest looking at the debug log on
> > the existing CA as it may be part of the communication as well.
> > 
> > rob
> > 
> > > 
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > > AuthMethodInterceptor: SecurityDomainResource.getDomainInfo()
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > > AuthMethodInterceptor: mapping: default
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > > AuthMethodInterceptor: required auth methods: [*]
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > > AuthMethodInterceptor: anonymous access allowed
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: ACLInterceptor: 
> > > SecurityDomainResource.getDomainInfo()
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: ACLInterceptor: No 
> > > ACL mapping.
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > > MessageFormatInterceptor: SecurityDomainResource.getDomainInfo()
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > > MessageFormatInterceptor: content-type: null
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > > MessageFormatInterceptor: accept: [application/json]
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > > MessageFormatInterceptor: response format: application/json
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: according to 
> > > ccMode, authorization for servlet: securitydomain is LDAP based, not XML 
> > > {1}, use default authz mgr: {2}.
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > > LdapBoundConnFactory: init 
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > > LdapBoundConnFactory:doCloning true
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: LdapAuthInfo: 
> > > init()
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: LdapAuthInfo: init 
> > > begins
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: LdapAuthInfo: init 
> > > ends
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: init: before 
> > > makeConnection errorIfDown is false
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: makeConnection: 
> > > errorIfDown false
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: LdapJssSSLSocket 
> > > set client auth cert nicknamesubsystemCert cert-pki-ca
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: SSL handshake 
> > > happened
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: Established LDAP 
> > > connection with SSL client auth to ipa1.our.net:636
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: initializing with 
> > > mininum 3 and maximum 15 connections to host ipa1.our.net port 636, 
> > > secure connection, true, authentication type 2
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: increasing minimum 
> > > connections by 3
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: new total 
> > > available connections 3
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: new number of 
> > > connections 3
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: In 
> > > LdapBoundConnFactory::getConn()
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: masterConn is 
> > > connected: true
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: getConn: conn is 
> > > connected true
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: getConn: mNumConns 
> > > now 2
> > > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 

[Freeipa-users] AD Trust Types

[Ronald Wimmer via FreeIPA-users]

Quite some time ago I added a trust to another AD domain. IIRC I added 
an "external trust" for a reason I do not remember.


What is the "Non-transitive external trust to a domain in another Active 
Directory forest" trust type for? Could I not just have added another 
"Active Directory domain" trust?


Any clarification on this matter would be highly appreciated!

Cheers,
Ronald
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: How to blend IPA server 4.1.4 on F21 with server 4.6.8 on C7?

[Bret Wortman via FreeIPA-users]

My misunderstanding, sorry. This is from the existing CA since that's where I 
thought the problem would be. Okay, going back and looking at the debug log on 
the new server to see if it's more revealing.


-- 
  Bret Wortman
  bret.wort...@damascusgrp.com

On Tue, Jun 8, 2021, at 2:27 PM, Rob Crittenden wrote:
> Bret Wortman via FreeIPA-users wrote:
> > I was tailing several logs in /var/log/pki/pki-tomcat/ca/ (debug, system, 
> > and transactions) and though the replica installation failed again at the 
> > same point, this is what I got from the logs throughout the installation 
> > process:
> 
> This doesn't seem to show any errors. Reading the pki logs can be
> problematic as it often charges on after an error is encountered so
> subsequent errors are basically red herrings but I don't see anything
> wrong here at all, or I'm missing something.
> 
> The IPA installer calls pki-spawn  so not much comes
> back to us. It's a black box. Can you provide the whole debug log,
> out-of-band is fine too. I'd also suggest looking at the debug log on
> the existing CA as it may be part of the communication as well.
> 
> rob
> 
> > 
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > AuthMethodInterceptor: SecurityDomainResource.getDomainInfo()
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > AuthMethodInterceptor: mapping: default
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > AuthMethodInterceptor: required auth methods: [*]
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > AuthMethodInterceptor: anonymous access allowed
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: ACLInterceptor: 
> > SecurityDomainResource.getDomainInfo()
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: ACLInterceptor: No 
> > ACL mapping.
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > MessageFormatInterceptor: SecurityDomainResource.getDomainInfo()
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > MessageFormatInterceptor: content-type: null
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > MessageFormatInterceptor: accept: [application/json]
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > MessageFormatInterceptor: response format: application/json
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: according to ccMode, 
> > authorization for servlet: securitydomain is LDAP based, not XML {1}, use 
> > default authz mgr: {2}.
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > LdapBoundConnFactory: init 
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > LdapBoundConnFactory:doCloning true
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: LdapAuthInfo: init()
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: LdapAuthInfo: init 
> > begins
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: LdapAuthInfo: init 
> > ends
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: init: before 
> > makeConnection errorIfDown is false
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: makeConnection: 
> > errorIfDown false
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: LdapJssSSLSocket set 
> > client auth cert nicknamesubsystemCert cert-pki-ca
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: SSL handshake 
> > happened
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: Established LDAP 
> > connection with SSL client auth to ipa1.our.net:636
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: initializing with 
> > mininum 3 and maximum 15 connections to host ipa1.our.net port 636, secure 
> > connection, true, authentication type 2
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: increasing minimum 
> > connections by 3
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: new total available 
> > connections 3
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: new number of 
> > connections 3
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: In 
> > LdapBoundConnFactory::getConn()
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: masterConn is 
> > connected: true
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: getConn: conn is 
> > connected true
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: getConn: mNumConns 
> > now 2
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > SecurityDomainProcessor: name: IPA
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > SecurityDomainProcessor: subtype: CA
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > SecurityDomainProcessor:  - cn=ipa1.our.net:443,cn=CAList,ou=Security 
> > Domain,o=ipaca
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > SecurityDomainProcessor:- objectClass: top
> > [08/Jun/2021:06:35:45][ajp-bio-127.0.0.1-8009-exec-2]: 
> > SecurityDomainProcessor:- host: ipa1.our.net
> >