[Freeipa-users] Re: FreeIPA w. letsencrypt for HTTPS/LDAP failing to communicate with itself

[Chris Moody via FreeIPA-users]

Just found some additional possible clues in the apache error.log

=
[Tue Jun 15 17:11:34.636290 2021] [:warn] [pid 31831:tid 
139703600768768] [client 2001:470:8af9:255::10:47920] failed to set 
perms (3140) on file (/run/ipa/ccaches/ch...@ipa.node-nine.com)!, 
referer: https://REDACTED-1.ipa.REDACTED.com/ipa/ui/
[Tue Jun 15 17:11:34.674975 2021] [ssl:error] [pid 31830:tid 
139703550412544] [client 2604:a880:2:d1::36:4001:58500] AH02039: 
Certificate Verification: Error (19): self signed certificate in 
certificate chain
[Tue Jun 15 17:11:34.675088 2021] [ssl:error] [pid 31830:tid 
139703550412544] [client 2604:a880:2:d1::36:4001:58500] AH02261: 
Re-negotiation handshake failed
[Tue Jun 15 17:11:34.675111 2021] [ssl:error] [pid 31830:tid 
139703550412544] SSL Library Error: error:1417C086:SSL 
routines:tls_process_client_certificate:certificate verify failed
[Tue Jun 15 17:11:34.675884 2021] [wsgi:error] [pid 31828:tid 
139703722125056] [remote 2001:470:8af9:255::10:47920] ipa: INFO: 
[jsonserver_session] ch...@ipa.redacted.com: cert_request('-BEGIN 
NEW CERTIFICATE 
REQUEST-\\nMIIEcTCCAlkCAQAwLDEaMBgGA1UEChMRSVBBLk5PREUtTklORS5DT00xDjAMBgNV\\nBAMTBWNocmlzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA8QR2JbFR\\nE7S7/XAk9V1bNEvvXxB65MpLnIu6gLnfXr8yz0xcTjvEDmKAukS7u+GhwnVfQvwS\\nRjlexS5leIZfMFU59R5K6ubzM5e3Qy07xQU40+8jLS2o3SUo7CvY+TcgTmfJWiK4\\nlWlG70LcMy6VbBVf+nQNoenryPDK2Y94kG3ydcKjGLZsaJ69s1OaSXxZY4esEhk/\\nFJs+odjMQRguS5sbUmfpSy3FTJsvuy4Sge2X5HsHOCKM2bWMcDqkRGI428toET0i\\n+FIXlvroqJQ7OL/RmwVcYOFMwMWN5Ne3g0ECZUrOWRNGt+TfMmcUxfDaw1kl/QqA\\nIYtv0xBszOC9ECSAak9pUuhabn616jI0teZE1+4trXc1ZLwBKiF+Ev2F7wFLdoPK\\nTyikms8lzQ/GLj9c61NieXsDRJLU3ZMjhQkcfbKKp5R4fp6UPUuJ8MdDzNDiLyuB\\nkgyRLRmF7NBFGvdEV9javdvAuSQz/Wa2ReGRWhI4hj8OgYZaFrNdWbgIRSZUDy3f\\ngDt8NoS7ouoD8vGQ93OvvaUfqgMhs57qZbSZNTgoLKcDFwGyT4oqfA25wzQhzlXU\\nV+q6JLpyz2J+d2CI4B/7/Udh44YT9LiLn9y84QNBaD3qJWrLuYrZYk9hb5HIuJf7\\nXDSh7zHmSed1BrMn/BnzKpxwl201P/Oy/5cCAwEAAaAAMA0GCSqGSIb3DQEBCwUA\\nA4ICAQBhFLpWtZXDhpnmfRu1tkfVQEuGMhG0MdIC1NXAUMs0EoBXKA0/Ak3xCN9c\\nbbvZtBBOktqIV5bxV+d4X0RHLGYh2NGezWHS5gkA92xzmw9gyUKHRQpDmIV9IicH\\nUCSFwL5xO5DFUC2XXshHFgHqpi3kYxCvfcX+wvrmJwjxsbv7raMVsZlN/6w2Z4/p\\nS1VYakUZnXXBl8x3TbK4yZ+mvRX6RjQOU8oCvZMAGns/IgjTL++4O59XThV7VaAa\\nIromeDGnS9klR/hx7BBy7UureQT/aIBpFczjaU5qPBJxkrFi7K+f3vdms9PZOfKv\\n4eowQhanJwoxhkSE11sVmrQQ9+pmrTXHLgO8IFRWAonnM0La31WQ+uBD9vF8iAGS\\neMk+CvEGV6u2UwZph4P6t/KCCGT89BMnJHTRYmyMulx3Ko4jJDMV9v3nm/Ls75ti\\abcdefghijklmnophPfch6I7wJEp+t7egdgrd5jbj4m4lDOT9v9msknlOXoUu\\nibGzaylvac6xhtggDVdz/OIQS7l0jNZE0t0w5ZgEP2fkUlCP6ZpBBL7hloBIzv28...REDACTED\\n-END 
NEW CERTIFICATE REQUEST-', cacn='ipa', principal='chris', 
version='2.233'): NetworkError

=

-Chris



On 6/15/21 5:09 PM, Chris Moody via FreeIPA-users wrote:
Apologies for the belated response - took me a bit to verify across 
all clients.


When I installed the LE certs on each replica/server, I performed the 
following:

=(the privkey & fullchain files provided by LE)=
ipa-server-certinstall -w -d privkey.pem fullchain.pem
&
/usr/sbin/ipa-certupdate
=

I have verified via 'openssl s_client -connect' that both https & 
ldaps are serving the proper LE certificates across all IPA servers.


I have also now iterated across every ipa-client installation and run 
'ipa-certupdate' as well.  All the /etc/ssl/certs/ca-certificates.crt 
files on each and every system have the LE certs and are current.


Unfortunately, the 'Actions->New Certificate' process I mentioned is 
still giving me identical behavior.


I followed the exact steps in the NewCert dialogue from one of the 
validated-current ipa-clients:

=
# Create a certificate database or use an existing one. To create a new 



database:
|# certutil -N -d |
# Create a CSR with subject /CN=,O=/, for example:
|# certutil -R -d  -a -g  -s 
'CN=chris,O=IPA.REDACTED.COM'|



=
IPA Error 907: NetworkError
cannot connect to 
'https://REDACTED-1.ipa.REDACTED.com:443/ca/rest/account/login': [SSL: 
TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:2508)

=

-Chris


On 6/12/21 3:55 AM, Florence Renaud wrote:

Hi,

when the let's encrypt certificates were installed, did you run 
ipa-cacert-manage install on one of the nodes + ipa-certupdate on 
_all the IPA machines_? It's important to run ipa-certupdate on all 
the server/replicas/clients in order to install the CA everywhere.


flo

On Sat, Jun 12, 2021 at 2:19 AM Chris Moody via FreeIPA-users 
> wrote:


Hello folks.

Hopefully I'm just missing something face-palm level obvious, but
I am running into some trouble when interfacing with my CA
functionality on an IPA server cluster.  My attempts at scouring
all my saved prior-comms from the mailing-list as well as several
search-engines are not enchanting me with much clue.

It appears that my need for the LetsEncrypt certs for the
user-facing Web-UI and LDAPs components are causing IPA to
dis-trust 

[Freeipa-users] Re: FreeIPA w. letsencrypt for HTTPS/LDAP failing to communicate with itself

[Chris Moody via FreeIPA-users]

Apologies for the belated response - took me a bit to verify across all 
clients.


When I installed the LE certs on each replica/server, I performed the 
following:

=(the privkey & fullchain files provided by LE)=
ipa-server-certinstall -w -d privkey.pem fullchain.pem
&
/usr/sbin/ipa-certupdate
=

I have verified via 'openssl s_client -connect' that both https & ldaps 
are serving the proper LE certificates across all IPA servers.


I have also now iterated across every ipa-client installation and run 
'ipa-certupdate' as well.  All the /etc/ssl/certs/ca-certificates.crt 
files on each and every system have the LE certs and are current.


Unfortunately, the 'Actions->New Certificate' process I mentioned is 
still giving me identical behavior.


I followed the exact steps in the NewCert dialogue from one of the 
validated-current ipa-clients:

=
# Create a certificate database or use an existing one. To create a new 
database:

|# certutil -N -d |
# Create a CSR with subject /CN=,O=/, for example:
|# certutil -R -d  -a -g  -s 
'CN=chris,O=IPA.REDACTED.COM'|



=
IPA Error 907: NetworkError
cannot connect to 
'https://REDACTED-1.ipa.REDACTED.com:443/ca/rest/account/login': [SSL: 
TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:2508)

=

-Chris


On 6/12/21 3:55 AM, Florence Renaud wrote:

Hi,

when the let's encrypt certificates were installed, did you run 
ipa-cacert-manage install on one of the nodes + ipa-certupdate on _all 
the IPA machines_? It's important to run ipa-certupdate on all the 
server/replicas/clients in order to install the CA everywhere.


flo

On Sat, Jun 12, 2021 at 2:19 AM Chris Moody via FreeIPA-users 
> wrote:


Hello folks.

Hopefully I'm just missing something face-palm level obvious, but
I am running into some trouble when interfacing with my CA
functionality on an IPA server cluster.  My attempts at scouring
all my saved prior-comms from the mailing-list as well as several
search-engines are not enchanting me with much clue.

It appears that my need for the LetsEncrypt certs for the
user-facing Web-UI and LDAPs components are causing IPA to
dis-trust itself.

===
4-node cluster - Ubuntu19.10
(all nodes currently fully updated/patched via the official Ubuntu
repos)
===
ipa --version
VERSION: 4.8.1, API_VERSION: 2.233
===
running letsencrypt certificates successfully for HTTPs & LDAPs
connectivity
===

These 4-nodes are all happily running and replicating betwixt each
other.  LDAPs is functioning great and many linux systems are able
to all join as freeipa-clients. Users and groups are replicating
and being used elegantly for many LDAP-based
authentication/authorization needs.

Overall, for these nodes, life is good.


Where I'm running into trouble is in finally wanting to leverage
certificate issuance on a per-user basis.  End goal is integrating
things like yubikeys, user-cert auth, and so on.


In the UI, when I enter a user's account and select Actions->New
Certificate, I am able to successfully issue the couple prompted
'certutil' commands to generate the user's CSR.  I then paste in
the contents of the CSR and hit 'Issue' and run into the following
error:
==
IPA Error 907: NetworkError
cannot connect to
'https://REDACTED-1.ipa.REDACTED.com:443/ca/rest/account/login
':
[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:2508)
==

As I then start digging into cli-mode to attempt to understand
where things are unhappy, I run into similar troubles with the
server attempting to talk to itself and not being very happy about it.

==
chris@REDACTED-1:~$ ipa ca-find

1 CA matched

  Name: ipa
  Description: IPA CA
  Authority ID: 8acca54b-64d7-44bf-b8f7-59316213cfb6
  Subject DN: CN=Certificate Authority,O=IPA.REDACTED.COM

  Issuer DN: CN=Certificate Authority,O=IPA.REDACTED.COM


Number of entries returned 1

chris@REDACTED-1:~$ ipa ca-show
Name: ipa
ipa: ERROR: cannot connect to
'https://REDACTED-1.ipa.REDACTED.com:443/ca/rest/account/login
':
[SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:2508)
==

Verifying with 'openssl s_client' returns the valid and
non-expired LE cert-chain.

==
chris@REDACTED-1:~$ openssl s_client
REDACTED-1.ipa.REDACTED.com:443

CONNECTED(0003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1

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

[Rob Crittenden via FreeIPA-users]

Alfred Victor wrote:
> I don't see a directive equivalent of SECURE_NFS to add to nfs.conf (all
> documentation seems to still refer to the sysconfig path), or is it the
> same? Can I just disable rpcgssd? We have no nfs mounts which are
> kerberized yet, and disabling rpcgssd seems to solve our problem, and I
> can kinit after disabling rpcgssd. It also does not seem that disabling
> rpcgssd hurts running tasks or node, but would like to confirm it's
> limited to nfs in function. I still have to wonder if there's a better way.

I suspect that SECURE_NFS is a no-op these days. It was necessary in
RHEL 5/6 for sure.

Yes, I think you can safely disable the service. In some versions of
RHEL/Fedora IIRC this is symlinked to nfs-secure-server so mask that as
well.

rob

> 
> Alfred
> 
> On Tue, Jun 15, 2021 at 10:31 AM Alexander Bokovoy  > wrote:
> 
> On ti, 15 kesä 2021, Alfred Victor via FreeIPA-users wrote:
> >Hi Rob,
> >
> >We attempted setting sec=sys on the mount, however to our surprise
> found
> >this didn't work. We then figured out that IPA install is adding
> this to
> >/etc/sysconfig/nfs:
> >
> >SECURE_NFS=yes
> >
> >
> >We tried removing this to no avail and restarting all the related
> sytstemd
> >units (rpcgssd, nfs, etc). Any idea why sec=sys is being ignored?
> Should we
> >need to set SECURE_NFS=no? On non-IPA nodes this directive does not
> exist
> >at all. For now, I have also totally disabled rpcgssd as I think
> this unit
> >may be responsible ( it seems that it does the upcall in
> >https://access.redhat.com/solutions/225783 ) so I will hope that this
> >solves it, I don't believe anything else depends on rpcgssd but
> will soon
> >find out. Any suggestions please? :)
> 
> Depends on nfs-utils version? I remember there had been a change in
> configuration in upstream nfs-utils in 2019:
> 
> commit c69875c8afdd877baf7139c0cd5241f70105cbd4
> Author: François Cami mailto:fc...@redhat.com>>
> Date:   Tue Feb 26 13:59:06 2019 +0100
> 
>      ipa-client-automount: handle NFS configuration file changes
> 
>      nfs-utils in Fedora 30 and later switched its configuration
>      file from /etc/sysconfig/nfs to /etc/nfs.conf, providing a
>      conversion service (nfs-convert.service) for upgrades.
>      However, for new installs the original configuration file
>      is missing. This change:
>      * adds a tuple-based osinfo.version_number method to handle
>        more kinds of OS versioning schemes
>      * detects RHEL and Fedora versions with the the new nfs-utils
>        behavior
>      * avoids backing up the new NFS configuration file as we do
>        not have to modify it.
> 
>      See: https://bugzilla.redhat.com/show_bug.cgi?id=1676981
> 
>      Fixes: https://pagure.io/freeipa/issue/7868
> 
> 
> >
> >Alfred
> >
> >On Thu, Jun 10, 2021 at 2:17 PM Rob Crittenden  > wrote:
> >
> >> Alfred Victor wrote:
> >> > Thanks very much Rob et al! I believe we have found our root
> cause and
> >> > the fix. If you like I'll provide some more details after we're
> done
> >> > with everything.
> >>
> >> Yes, knowing the cause would be great and could be helpful to others!
> >>
> >> cheers
> >>
> >> rob
> >>
> >> >
> >> > Alfred
> >> >
> >> > On Thu, Jun 10, 2021 at 11:02 AM Rob Crittenden
> mailto:rcrit...@redhat.com>
> >> > >> wrote:
> >> >
> >> >     Alfred Victor wrote:
> >> >     > Hi all,
> >> >     >
> >> >     > Just curious if anyone has suggestions about that please
> before I
> >> get
> >> >     > going in a couple of hours with conversions to IPA again?
> I did
> >> >     the math
> >> >     > and 1,097,471 log messages in 5 hours is about 60 times per
> >> second, so
> >> >     > I'm gradually becoming more certain this is why we can
> only boot
> >> 20-30
> >> >     > nodes at a time when we used to boot hundreds. However,
> this is
> >> still
> >> >     > just a guess as I don't know the mechanism behind why this
> >> interferes
> >> >     > with IPA joins, some bottleneck with the KDC?
> >> >
> >> >     It sure seems like this is a kerberized NFS request for a
> host that
> >> >     doesn't provide it, or doesn't have an nfs principal. I
> think you'd
> >> need
> >> >     to monitor the offending client to see what it is doing.
> >> >
> >> >     If the KDC is being dramatically slowed down by this then
> yes, you
> >> could
> >> >     see slower Apache performance because it needs to obtain
> tickets on
> >> >     behalf of the user doing the join. Whether that 

[Freeipa-users] Doc suggestion: explicitly advise 'non-desktop' spins for freeipa-server*

[Harry G. Coin via FreeIPA-users]

Might the 'edition' (server, desktop, iot, whatnot) of the distribution
used in testing freeipa-server* be explicitly stated in the 'getting
started' docs as being 'approved' for freeipa-server use?   The better
to avoid interactions with un-interaction-tested packages / security
libraries generally seen only in user/special-purpose distros.  (re:
dnssec  / bind9 / smart-card interaction)

HC



___
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]

I don't see a directive equivalent of SECURE_NFS to add to nfs.conf (all
documentation seems to still refer to the sysconfig path), or is it the
same? Can I just disable rpcgssd? We have no nfs mounts which are
kerberized yet, and disabling rpcgssd seems to solve our problem, and I can
kinit after disabling rpcgssd. It also does not seem that disabling
rpcgssd hurts running tasks or node, but would like to confirm it's limited
to nfs in function. I still have to wonder if there's a better way.

Alfred

On Tue, Jun 15, 2021 at 10:31 AM Alexander Bokovoy 
wrote:

> On ti, 15 kesä 2021, Alfred Victor via FreeIPA-users wrote:
> >Hi Rob,
> >
> >We attempted setting sec=sys on the mount, however to our surprise found
> >this didn't work. We then figured out that IPA install is adding this to
> >/etc/sysconfig/nfs:
> >
> >SECURE_NFS=yes
> >
> >
> >We tried removing this to no avail and restarting all the related sytstemd
> >units (rpcgssd, nfs, etc). Any idea why sec=sys is being ignored? Should
> we
> >need to set SECURE_NFS=no? On non-IPA nodes this directive does not exist
> >at all. For now, I have also totally disabled rpcgssd as I think this unit
> >may be responsible ( it seems that it does the upcall in
> >https://access.redhat.com/solutions/225783 ) so I will hope that this
> >solves it, I don't believe anything else depends on rpcgssd but will soon
> >find out. Any suggestions please? :)
>
> Depends on nfs-utils version? I remember there had been a change in
> configuration in upstream nfs-utils in 2019:
>
> commit c69875c8afdd877baf7139c0cd5241f70105cbd4
> Author: François Cami 
> Date:   Tue Feb 26 13:59:06 2019 +0100
>
>  ipa-client-automount: handle NFS configuration file changes
>
>  nfs-utils in Fedora 30 and later switched its configuration
>  file from /etc/sysconfig/nfs to /etc/nfs.conf, providing a
>  conversion service (nfs-convert.service) for upgrades.
>  However, for new installs the original configuration file
>  is missing. This change:
>  * adds a tuple-based osinfo.version_number method to handle
>more kinds of OS versioning schemes
>  * detects RHEL and Fedora versions with the the new nfs-utils
>behavior
>  * avoids backing up the new NFS configuration file as we do
>not have to modify it.
>
>  See: https://bugzilla.redhat.com/show_bug.cgi?id=1676981
>
>  Fixes: https://pagure.io/freeipa/issue/7868
>
>
> >
> >Alfred
> >
> >On Thu, Jun 10, 2021 at 2:17 PM Rob Crittenden 
> wrote:
> >
> >> Alfred Victor wrote:
> >> > Thanks very much Rob et al! I believe we have found our root cause and
> >> > the fix. If you like I'll provide some more details after we're done
> >> > with everything.
> >>
> >> Yes, knowing the cause would be great and could be helpful to others!
> >>
> >> cheers
> >>
> >> rob
> >>
> >> >
> >> > Alfred
> >> >
> >> > On Thu, Jun 10, 2021 at 11:02 AM Rob Crittenden  >> > > wrote:
> >> >
> >> > Alfred Victor wrote:
> >> > > Hi all,
> >> > >
> >> > > Just curious if anyone has suggestions about that please before
> I
> >> get
> >> > > going in a couple of hours with conversions to IPA again? I did
> >> > the math
> >> > > and 1,097,471 log messages in 5 hours is about 60 times per
> >> second, so
> >> > > I'm gradually becoming more certain this is why we can only boot
> >> 20-30
> >> > > nodes at a time when we used to boot hundreds. However, this is
> >> still
> >> > > just a guess as I don't know the mechanism behind why this
> >> interferes
> >> > > with IPA joins, some bottleneck with the KDC?
> >> >
> >> > It sure seems like this is a kerberized NFS request for a host
> that
> >> > doesn't provide it, or doesn't have an nfs principal. I think
> you'd
> >> need
> >> > to monitor the offending client to see what it is doing.
> >> >
> >> > If the KDC is being dramatically slowed down by this then yes, you
> >> could
> >> > see slower Apache performance because it needs to obtain tickets
> on
> >> > behalf of the user doing the join. Whether that would represent
> >> itself
> >> > as a read timeout I don't know.
> >> >
> >> > rob
> >> >
> >> > >
> >> > > Alfred
> >> > >
> >> > > On Wed, Jun 9, 2021 at 3:49 PM Alfred Victor <
> alvic...@gmail.com
> >> > 
> >> > > >> wrote:
> >> > >
> >> > > 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
> >> > > 

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

[Alexander Bokovoy via FreeIPA-users]

On ti, 15 kesä 2021, Alfred Victor via FreeIPA-users wrote:

Hi Rob,

We attempted setting sec=sys on the mount, however to our surprise found
this didn't work. We then figured out that IPA install is adding this to
/etc/sysconfig/nfs:

SECURE_NFS=yes


We tried removing this to no avail and restarting all the related sytstemd
units (rpcgssd, nfs, etc). Any idea why sec=sys is being ignored? Should we
need to set SECURE_NFS=no? On non-IPA nodes this directive does not exist
at all. For now, I have also totally disabled rpcgssd as I think this unit
may be responsible ( it seems that it does the upcall in
https://access.redhat.com/solutions/225783 ) so I will hope that this
solves it, I don't believe anything else depends on rpcgssd but will soon
find out. Any suggestions please? :)


Depends on nfs-utils version? I remember there had been a change in
configuration in upstream nfs-utils in 2019:

commit c69875c8afdd877baf7139c0cd5241f70105cbd4
Author: François Cami 
Date:   Tue Feb 26 13:59:06 2019 +0100

ipa-client-automount: handle NFS configuration file changes

nfs-utils in Fedora 30 and later switched its configuration
file from /etc/sysconfig/nfs to /etc/nfs.conf, providing a
conversion service (nfs-convert.service) for upgrades.
However, for new installs the original configuration file
is missing. This change:
* adds a tuple-based osinfo.version_number method to handle
  more kinds of OS versioning schemes
* detects RHEL and Fedora versions with the the new nfs-utils
  behavior
* avoids backing up the new NFS configuration file as we do
  not have to modify it.

See: https://bugzilla.redhat.com/show_bug.cgi?id=1676981

Fixes: https://pagure.io/freeipa/issue/7868




Alfred

On Thu, Jun 10, 2021 at 2:17 PM Rob Crittenden  wrote:


Alfred Victor wrote:
> Thanks very much Rob et al! I believe we have found our root cause and
> the fix. If you like I'll provide some more details after we're done
> with everything.

Yes, knowing the cause would be great and could be helpful to others!

cheers

rob

>
> Alfred
>
> On Thu, Jun 10, 2021 at 11:02 AM Rob Crittenden  > wrote:
>
> Alfred Victor wrote:
> > Hi all,
> >
> > Just curious if anyone has suggestions about that please before I
get
> > going in a couple of hours with conversions to IPA again? I did
> the math
> > and 1,097,471 log messages in 5 hours is about 60 times per
second, so
> > I'm gradually becoming more certain this is why we can only boot
20-30
> > nodes at a time when we used to boot hundreds. However, this is
still
> > just a guess as I don't know the mechanism behind why this
interferes
> > with IPA joins, some bottleneck with the KDC?
>
> It sure seems like this is a kerberized NFS request for a host that
> doesn't provide it, or doesn't have an nfs principal. I think you'd
need
> to monitor the offending client to see what it is doing.
>
> If the KDC is being dramatically slowed down by this then yes, you
could
> see slower Apache performance because it needs to obtain tickets on
> behalf of the user doing the join. Whether that would represent
itself
> as a read timeout I don't know.
>
> rob
>
> >
> > Alfred
> >
> > On Wed, Jun 9, 2021 at 3:49 PM Alfred Victor  
> > >> wrote:
> >
> > 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 

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

[Alfred Victor via FreeIPA-users]

Hi Rob,

We attempted setting sec=sys on the mount, however to our surprise found
this didn't work. We then figured out that IPA install is adding this to
/etc/sysconfig/nfs:

SECURE_NFS=yes


We tried removing this to no avail and restarting all the related sytstemd
units (rpcgssd, nfs, etc). Any idea why sec=sys is being ignored? Should we
need to set SECURE_NFS=no? On non-IPA nodes this directive does not exist
at all. For now, I have also totally disabled rpcgssd as I think this unit
may be responsible ( it seems that it does the upcall in
https://access.redhat.com/solutions/225783 ) so I will hope that this
solves it, I don't believe anything else depends on rpcgssd but will soon
find out. Any suggestions please? :)

Alfred

On Thu, Jun 10, 2021 at 2:17 PM Rob Crittenden  wrote:

> Alfred Victor wrote:
> > Thanks very much Rob et al! I believe we have found our root cause and
> > the fix. If you like I'll provide some more details after we're done
> > with everything.
>
> Yes, knowing the cause would be great and could be helpful to others!
>
> cheers
>
> rob
>
> >
> > Alfred
> >
> > On Thu, Jun 10, 2021 at 11:02 AM Rob Crittenden  > > wrote:
> >
> > Alfred Victor wrote:
> > > Hi all,
> > >
> > > Just curious if anyone has suggestions about that please before I
> get
> > > going in a couple of hours with conversions to IPA again? I did
> > the math
> > > and 1,097,471 log messages in 5 hours is about 60 times per
> second, so
> > > I'm gradually becoming more certain this is why we can only boot
> 20-30
> > > nodes at a time when we used to boot hundreds. However, this is
> still
> > > just a guess as I don't know the mechanism behind why this
> interferes
> > > with IPA joins, some bottleneck with the KDC?
> >
> > It sure seems like this is a kerberized NFS request for a host that
> > doesn't provide it, or doesn't have an nfs principal. I think you'd
> need
> > to monitor the offending client to see what it is doing.
> >
> > If the KDC is being dramatically slowed down by this then yes, you
> could
> > see slower Apache performance because it needs to obtain tickets on
> > behalf of the user doing the join. Whether that would represent
> itself
> > as a read timeout I don't know.
> >
> > rob
> >
> > >
> > > Alfred
> > >
> > > On Wed, Jun 9, 2021 at 3:49 PM Alfred Victor  > 
> > > >> wrote:
> > >
> > > 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
> > mailto:rcrit...@redhat.com>
> > > >>
> 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 

[Freeipa-users] Re: sssd version 2.2.3 issues with AD Trust View

[iulian roman via FreeIPA-users]

I have attached some sssd logs snippets  with debug_level activated in 
sssd.conf  (some lines have been truncated) :

(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [dp_get_account_info_send] 
(0x0200): Got request for [0x1][BE_REQ_USER][name=test_u...@example.com]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [dp_attach_req] (0x0400): DP 
Request [Account #1]: New request. Flags [0x0001].
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [dp_attach_req] (0x0400): 
Number of active DP request: 1
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sss_domain_get_state] 
(0x1000): Domain ipa.example.com is Active
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sss_domain_get_state] 
(0x1000): Domain EXAMPLE.com is Active
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sss_domain_get_state] 
(0x1000): Domain ipa.example.com is Active
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sss_domain_get_state] 
(0x1000): Domain EXAMPLE.com is Active
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_id_op_connect_step] 
(0x4000): reusing cached connection
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_id_op_connect_step] 
(0x4000): reusing cached connection
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] 
[ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view 
[Default Trust View] with filter 
[(&(objectClass=ipaUserOverride)(uid=test_user))].
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_print_server] (0x2000): 
Searching 10.10.100.121:389
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_get_generic_ext_step] 
(0x0400): calling ldap_search_ext with 
[(&(objectClass=ipaUserOverride)(uid=test_user))][cn=Default Trust 
View,cn=views,cn=accounts,dc=
ipa,dc=example,dc=com].
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_get_generic_ext_step] 
(0x2000): ldap_search_ext called, msgid = 16
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_op_add] (0x2000): New 
operation 16 timeout 6
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_process_result] 
(0x2000): Trace: sh[0x55756a96b460], connected[1], ops[0x55756a964f90], 
ldap[0x55756a9618f0]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_process_message] 
(0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_parse_entry] (0x1000): 
OriginalDN: 
[ipaanchoruuid=:SID:S-1-5-21-1695049048-159329179-1862793928-25318,cn=Default 
Trust View,cn=views,cn=accounts,dc=ipa,d
c=example,dc=com].
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_parse_range] (0x2000): 
No sub-attributes for [ipaSshPubKey]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_parse_range] (0x2000): 
No sub-attributes for [ipaAnchorUUID]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_parse_range] (0x2000): 
No sub-attributes for [uid]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_parse_range] (0x2000): 
No sub-attributes for [uidNumber]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_parse_range] (0x2000): 
No sub-attributes for [objectClass]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_parse_range] (0x2000): 
No sub-attributes for [ipaOriginalUid]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_process_result] 
(0x2000): Trace: sh[0x55756a96b460], connected[1], ops[0x55756a964f90], 
ldap[0x55756a9618f0]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_process_message] 
(0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_get_generic_op_finished] 
(0x0400): Search result: Success(0), no errmsg set
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_op_destructor] (0x2000): 
Operation 16 finished
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [ipa_get_ad_override_done] 
(0x4000): Found override for object with filter 
[(&(objectClass=ipaUserOverride)(uid=test_user))].
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_id_op_destroy] (0x4000): 
releasing operation connection
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] 
[ipa_subdomain_account_got_override] (0x4000): Processing override.
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sss_domain_get_state] 
(0x1000): Domain ipa.example.com is Active
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sss_domain_get_state] 
(0x1000): Domain EXAMPLE.com is Active
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_id_op_connect_step] 
(0x4000): reusing cached connection
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [ipa_s2n_get_acct_info_send] 
(0x0400): Sending request_type: [REQ_FULL_WITH_MEMBERS] for trust user 
[S-1-5-21-1695049048-159329179-1862793928-25318] to IPA ser
ver
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [ipa_s2n_exop_send] (0x0400): 
Executing extended operation
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [ipa_s2n_exop_send] (0x2000): 
ldap_extended_operation sent, msgid = 17
(Tue Jun 15 16:09:02 2021) [be[ipa.example.com]] [sdap_op_add] (0x2000): New 
operation 17 timeout 6
(Tue 

[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]

On Mon, Jun 14, 2021, at 3:47 PM, Rob Crittenden wrote:
> Bret Wortman via FreeIPA-users wrote:
> > This appears to be the error, or at least it's the only "fatal" I could 
> > find in the stream and it's near enough to the end of traffic that it seems 
> > likely. I'm no expert on Wireshark so I'm hoping someone is willing to take 
> > a peek and let me know if there's something obvious here.
> > 
> > https://gist.github.com/wortmanb/d3b1cb38e894d1fb0578ab05e459b178
> > 
> > 
> 
> Are you sure you aren't seeing a connect error on the F21 Apache server?
> This looks to me like an untrusted CA or something like it.

Not that I'm aware of. We haven't touched those servers in ages (hence the 
F21). Where would we be most likely to see the connect error on the server? I 
may have missed a log file.

> Have you replaced any of your IPA certs on the F21 server? Signed the
> IPA CA with an external?

I'll double-check today but not that I'm aware of.
___
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: AD Trust Types

[Alexander Bokovoy via FreeIPA-users]

On ti, 15 kesä 2021, Ronald Wimmer via FreeIPA-users wrote:

On 15.06.21 08:42, Alexander Bokovoy via FreeIPA-users wrote:

[...]
Check the first link I gave. Only 'domain local' groups can include
members from "Accounts, Global groups, and Universal groups from other
forests and from external domains". Domain local groups, on the other
hand, can only be used inside the domain they defined.

Thus, such groups cannot be used over a trust to IPA.


I was not aware that only 'domain local' groups allow members from 
other forests and/or domains. I know that 'domain local' groups cannot 
be used in IPA.


The group my colleague created is a 'domain local' group although I 
told them many times not to create local groups because they cannot be 
used in IPA...


Thanks a lot for clarification. I think I do have a better picture now.

Is it true that the main use case for creating an 'external' trust is 
to establish a trust to just one domain of a forest?


On Active Directory side external trust is often used to perform a
shortcut in an authentication request processing. This is often needed
if you have a deep hierarchy of child domains in a forest and you only
want to have a trust to a specific child domain. This allows to avoid
going through parent domains' domain controllers for each Kerberos or
identity resolution request.

Another reason is that people often use external trust in a situation
where they have organizational barriers to set up a proper forest trust.

Both of these could apply to IPA to AD trust as well. As always, one
needs to carefully plan the deployment in advance, as external trust has
clear limitations.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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: AD Trust Types

[Ronald Wimmer via FreeIPA-users]

On 15.06.21 08:42, Alexander Bokovoy via FreeIPA-users wrote:

[...]
Check the first link I gave. Only 'domain local' groups can include
members from "Accounts, Global groups, and Universal groups from other
forests and from external domains". Domain local groups, on the other
hand, can only be used inside the domain they defined.

Thus, such groups cannot be used over a trust to IPA.


I was not aware that only 'domain local' groups allow members from other 
forests and/or domains. I know that 'domain local' groups cannot be used 
in IPA.


The group my colleague created is a 'domain local' group although I told 
them many times not to create local groups because they cannot be used 
in IPA...


Thanks a lot for clarification. I think I do have a better picture now.

Is it true that the main use case for creating an 'external' trust is to 
establish a trust to just one domain of a forest?


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: AD Trust Types

[Alexander Bokovoy via FreeIPA-users]

On ti, 15 kesä 2021, Ronald Wimmer via FreeIPA-users wrote:

On 15.06.21 07:39, Alexander Bokovoy via FreeIPA-users wrote:

On ma, 14 kesä 2021, Ronald Wimmer wrote:

On 14.06.21 13:37, Alexander Bokovoy wrote:

On ma, 14 kesä 2021, Ronald Wimmer via FreeIPA-users wrote:

On 12.06.21 13:08, Florence Renaud via FreeIPA-users wrote:

Hi,

please refer to External Trusts to Active Directory [1] from 
WIndows Integration guide, it nicely explains the difference 
between external trust and forest trust.

flo

[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/active-directory-trust#ext-trust-to-ad
 





Sorry for my unspecific initial question. I did read the 
documentation. As I understood it the external trust somehow 
isolates the view on that particular domain.


If DomA_Trust is a normal one and DomB_Trust an external one I 
cannot use DomB users in a DomA group for example, right? If 
DomB trust was not external I could do that?


I think you need to start with Active Directory design and
documentation. In particular, group types in AD define who can be
included into them and how they can be consumed:
https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups



Type of trust between domains influences the use of groups but group
scopes are ultimate ones here.

When applying that to a trust between IPA and AD, remember that we only
have two trust types:

 - forest trust: IPA domain is in a separate forest than any AD domain

 - external trust: only immediately trusted AD domain users and groups
   can be seen and used for authentication across the trust, there is no
   transitivity into any other trust that this AD domain may have
   anywhere else

In addition to that, while forest trust in itself is transitive to
domains in the trusting forest, there is no transitivity across all
trusting forests. If forest A trusts forest B and forest B trusts forest
C, there is no trust from forest A to any domain in forest C.

The same applies to groups from those forests as well, complicated by
the group scopes.


In our case IPA hast a trust to the forest root of domain A which 
itself has a trust to domain B. IPA has an external trust to 
domain B. With the AD management tool we are using I can put users 
of domain B into a group of domain A.


What matters is where domain B is located. Is it part of the same forest
as domain A? Is it outside of forest A?


It is outside of forest A but forest A has a trust to it.


As I already said, forest trust is not transitive to other forest
trusts. So it does not count, a trust to B has to be explicitly created.

When I try to use that particular group (POSIX group that has the 
AD group as its member) in a HBAC scenario I do get a permission 
denied error.


It can be anything. This information does not give any chance to
understand why there is a problem.


At the moment I do have users of domain B in a group of domain A. I 
cannot use that particular group in IPA. I think this could be because 
I setup the IPA trust to domain B as external.


Check the first link I gave. Only 'domain local' groups can include
members from "Accounts, Global groups, and Universal groups from other
forests and from external domains". Domain local groups, on the other
hand, can only be used inside the domain they defined.

Thus, such groups cannot be used over a trust to IPA.

External trust to domain B was setup years ago when we were still 
experimenting with IPA. So my first question is if the separate 
trust to domain B is needed at all? (because there is a trust from 
domain A to domain B on the AD side.) If yes I probably would not 
want domain B trust to be an external one in my scenario, would I?


You need to decide what you want. ;) If A and B are in the same forest,
then you don't need an external trust to B from IPA side.


If I want to use users of domain B in a domain A group I will probably 
have to set up a 'normal' trust to domain B and not an 'external' one. 
Do you agree?


No. It does not matter. What matters is a group type. If you have group
members from outside your own forest, you can only use them in domain
local groups but these groups then cannot be used in other forests or
even within your own forests but in other domains. This is Active
Directory's design limitation.

What you could do is to have a trust in IPA to both forest A and a
domain B, then have IPA external groups that include individually
users/groups from A and B, then use IPA POSIX groups to include IPA
external groups. Those IPA POSIX groups then can be used to apply
permissions on IPA side. 



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Freeipa-users] Re: AD Trust Types

[Ronald Wimmer via FreeIPA-users]

On 15.06.21 07:39, Alexander Bokovoy via FreeIPA-users wrote:

On ma, 14 kesä 2021, Ronald Wimmer wrote:

On 14.06.21 13:37, Alexander Bokovoy wrote:

On ma, 14 kesä 2021, Ronald Wimmer via FreeIPA-users wrote:

On 12.06.21 13:08, Florence Renaud via FreeIPA-users wrote:

Hi,

please refer to External Trusts to Active Directory [1] from 
WIndows Integration guide, it nicely explains the difference 
between external trust and forest trust.

flo

[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/active-directory-trust#ext-trust-to-ad 
 





Sorry for my unspecific initial question. I did read the 
documentation. As I understood it the external trust somehow 
isolates the view on that particular domain.


If DomA_Trust is a normal one and DomB_Trust an external one I 
cannot use DomB users in a DomA group for example, right? If DomB 
trust was not external I could do that?


I think you need to start with Active Directory design and
documentation. In particular, group types in AD define who can be
included into them and how they can be consumed:
https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups 




Type of trust between domains influences the use of groups but group
scopes are ultimate ones here.

When applying that to a trust between IPA and AD, remember that we only
have two trust types:

 - forest trust: IPA domain is in a separate forest than any AD domain

 - external trust: only immediately trusted AD domain users and groups
   can be seen and used for authentication across the trust, there is no
   transitivity into any other trust that this AD domain may have
   anywhere else

In addition to that, while forest trust in itself is transitive to
domains in the trusting forest, there is no transitivity across all
trusting forests. If forest A trusts forest B and forest B trusts forest
C, there is no trust from forest A to any domain in forest C.

The same applies to groups from those forests as well, complicated by
the group scopes.


In our case IPA hast a trust to the forest root of domain A which 
itself has a trust to domain B. IPA has an external trust to domain B. 
With the AD management tool we are using I can put users of domain B 
into a group of domain A.


What matters is where domain B is located. Is it part of the same forest
as domain A? Is it outside of forest A?


It is outside of forest A but forest A has a trust to it.

When I try to use that particular group (POSIX group that has the AD 
group as its member) in a HBAC scenario I do get a permission denied 
error.


It can be anything. This information does not give any chance to
understand why there is a problem.


At the moment I do have users of domain B in a group of domain A. I 
cannot use that particular group in IPA. I think this could be because I 
setup the IPA trust to domain B as external.






External trust to domain B was setup years ago when we were still 
experimenting with IPA. So my first question is if the separate trust 
to domain B is needed at all? (because there is a trust from domain A 
to domain B on the AD side.) If yes I probably would not want domain B 
trust to be an external one in my scenario, would I?


You need to decide what you want. ;) If A and B are in the same forest,
then you don't need an external trust to B from IPA side.


If I want to use users of domain B in a domain A group I will probably 
have to set up a 'normal' trust to domain B and not an 'external' one. 
Do you agree?


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