subject:"\[Freeipa\-users\] Re\: AD Trust"

[Freeipa-users] Re: AD Trust with multiple replicas

2024-01-11 Thread Anil Rathod via FreeIPA-users

I have below Setup:
AD domain: abc.com
maste IPA: node1.idm.abc.com
Replica: node2.idm.com

Both nodes are Enabled server roles: AD trust agent, AD trust controller, CA 
server, IPA master

Now,
on client side, while client connected with node1, I am able to resolve the AD 
Users.
but when I connect the client with node2, then AD user not able to resolve.




  *   anil

This message, together with any attachments, is intended only for the use of 
the individual or entity to which it is addressed and may contain confidential 
and/or privileged information. If you are not the intended recipient(s), or the 
employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution or 
copying of this message, or any attachment, is strictly prohibited. If you have 
received this message in error, please immediately notify the sender and delete 
the message, together with any attachments, from your computer. Thank you for 
your cooperation.
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: AD Trust not authenticating users

2023-06-08 Thread Sumit Bose via FreeIPA-users

Am Thu, Jun 08, 2023 at 03:37:12PM - schrieb James Osbourn via 
FreeIPA-users:
> Thanks I will take a look at the link.
> 
> The krb5.conf file looks as follows
> includedir /etc/krb5.conf.d/
> includedir /var/lib/sss/pubconf/krb5.include.d/
> 
> [logging]
>  default = FILE:/var/log/krb5libs.log
>  kdc = FILE:/var/log/krb5kdc.log
>  admin_server = FILE:/var/log/kadmind.log
> 
> [libdefaults]
>  default_realm = IPA.AD1.COM
>  dns_lookup_realm = false
>  dns_lookup_kdc = true
>  rdns = false
>  ticket_lifetime = 24h
>  forwardable = true
>  udp_preference_limit = 0
>  default_ccache_name = KEYRING:persistent:%{uid}
> 
> [realms]
>  IPA.AD1.COM = {
>   kdc = ipa-3.ipa.ad1.com:88
>   master_kdc = ipa-3.ipa.ad1.com:88
>   kpasswd_server = ipa-3.ipa.ad1.com:464
>   admin_server = ipa-3.ipa.ad1.com:749
>   default_domain = ipa.ad1.com
>   pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
>   pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
> }
> 
> [domain_realm]
>  .ipa.ad1.com = IPA.AD1.COM
>  ipa.ad1.com = IPA.AD1.COM
>  ipa-3.ipa.ad1.com = IPA.AD1.COM

Hi,

assuming that auth.ssdis.loc is the domain with issues can you try if
adding 

   .auth.ssdis.loc = AUTH.SSDIS.LOC
   auth.ssdis.loc = AUTH.SSDIS.LOC

to the [domain_realm] of /etc/krb5.conf makes is more reliable?

bye,
Sumit

> 
> [dbmodules]
>   IPA.AD1.COM = {
> db_library = ipadb.so
>   }
> 
> [plugins]
>  certauth = {
>   module = ipakdb:kdb/ipadb.so
>   enable_only = ipakdb
>  }
> 
> Under the /var/lib/sss/pubconf/krb5.include.d/ directory the files and 
> contents are as follows
> ::
> /var/lib/sss/pubconf/krb5.include.d/domain_realm_auth_ssdis_loc
> ::
> [domain_realm]
> .ssdis.loc = SSDIS.LOC
> ssdis.loc = SSDIS.LOC
> .ROOT.TES = ROOT.TES
> ROOT.TES = ROOT.TES
> .INTERNAL.ROOT.TES = INTERNAL.ROOT.TES
> INTERNAL.ROOT.TES = INTERNAL.ROOT.TES
> [capaths]
> SSDIS.LOC = {
>   AUTH.SSDIS.LOC = SSDIS.LOC
> }
> ROOT.TES = {
>   AUTH.SSDIS.LOC = ROOT.TES
> }
> INTERNAL.ROOT.TES = {
>   AUTH.SSDIS.LOC = ROOT.TES
> }
> AUTH.SSDIS.LOC = {
>   SSDIS.LOC = SSDIS.LOC
>   ROOT.TES = ROOT.TES
>   INTERNAL.ROOT.TES = ROOT.TES
> }
> ::
> /var/lib/sss/pubconf/krb5.include.d/krb5_libdefaults
> ::
> [libdefaults]
>  canonicalize = true
> ::
> /var/lib/sss/pubconf/krb5.include.d/localauth_plugin
> ::
> [plugins]
>  localauth = {
>   module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so
>  }
> 
> I am still looking into my problem, a reboot of an IPA server seems to allow 
> authentication and AD group authorisation to work for a period of time and 
> then it stops.  Authentication will continue to work if the user is cached in 
> the SSSD cache, but trying to use sudo fails as it can no longer get the 
> membership details.
> ___
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: AD Trust not authenticating users

2023-06-08 Thread James Osbourn via FreeIPA-users

Thanks I will take a look at the link.

The krb5.conf file looks as follows
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = IPA.AD1.COM
 dns_lookup_realm = false
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
 IPA.AD1.COM = {
  kdc = ipa-3.ipa.ad1.com:88
  master_kdc = ipa-3.ipa.ad1.com:88
  kpasswd_server = ipa-3.ipa.ad1.com:464
  admin_server = ipa-3.ipa.ad1.com:749
  default_domain = ipa.ad1.com
  pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
  pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}

[domain_realm]
 .ipa.ad1.com = IPA.AD1.COM
 ipa.ad1.com = IPA.AD1.COM
 ipa-3.ipa.ad1.com = IPA.AD1.COM

[dbmodules]
  IPA.AD1.COM = {
db_library = ipadb.so
  }

[plugins]
 certauth = {
  module = ipakdb:kdb/ipadb.so
  enable_only = ipakdb
 }

Under the /var/lib/sss/pubconf/krb5.include.d/ directory the files and contents 
are as follows
::
/var/lib/sss/pubconf/krb5.include.d/domain_realm_auth_ssdis_loc
::
[domain_realm]
.ssdis.loc = SSDIS.LOC
ssdis.loc = SSDIS.LOC
.ROOT.TES = ROOT.TES
ROOT.TES = ROOT.TES
.INTERNAL.ROOT.TES = INTERNAL.ROOT.TES
INTERNAL.ROOT.TES = INTERNAL.ROOT.TES
[capaths]
SSDIS.LOC = {
  AUTH.SSDIS.LOC = SSDIS.LOC
}
ROOT.TES = {
  AUTH.SSDIS.LOC = ROOT.TES
}
INTERNAL.ROOT.TES = {
  AUTH.SSDIS.LOC = ROOT.TES
}
AUTH.SSDIS.LOC = {
  SSDIS.LOC = SSDIS.LOC
  ROOT.TES = ROOT.TES
  INTERNAL.ROOT.TES = ROOT.TES
}
::
/var/lib/sss/pubconf/krb5.include.d/krb5_libdefaults
::
[libdefaults]
 canonicalize = true
::
/var/lib/sss/pubconf/krb5.include.d/localauth_plugin
::
[plugins]
 localauth = {
  module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so
 }

I am still looking into my problem, a reboot of an IPA server seems to allow 
authentication and AD group authorisation to work for a period of time and then 
it stops.  Authentication will continue to work if the user is cached in the 
SSSD cache, but trying to use sudo fails as it can no longer get the membership 
details.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: AD Trust not authenticating users

2023-06-08 Thread Sumit Bose via FreeIPA-users

Am Thu, Jun 08, 2023 at 11:48:58AM - schrieb James Osbourn via 
FreeIPA-users:
> I have an inherited IPA domain that is a subdomain of an active directory 
> domain, e.g. ipa.ad1.com as a child of ad1.com.  The IPA domain has AD Trust 
> enabled and a one way domain trust to another AD sub domain, e.g. we want to 
> use user logins from the AD domain users.ad2.com which is a child domain of 
> ad2.com.  We are also using AD security group from the user.ad2.com domain to 
> apply group based access control.  e.g. we are using simple authentication on 
> SSSD to limit who can login and using AD groups to define sudo access.  This 
> users domain and AD servers is managed by another team.
> 
> Everything was working for some time and then we started seeing intermittent 
> problems with authentication, a quick restart of the IPA server would resolve 
> the problem temporarily, but then it would stop again.  Even if we could 
> login using SSH keys the sudo access would not work, it would appear to lose 
> group membership details.
> 
> I have recently updated all of the IPA nodes to RHEL9 and made sure that DNS 
> is updated correctly.

Hi,

this might be related to https://github.com/SSSD/sssd/issues/6600 but it
looks like not exactly the same issue.

Can you share /etc/krb5.conf and all files from /etc/krb5.conf.d/ and
/var/lib/sss/pubconf/krb5.include.d/

bye,
Sumit

> 
> The sssd.conf configuration on the IPA server looks as follows
> 
> [domain/ipa.ad1.com]
> debug_level = 6
> id_provider = ipa
> ipa_server = ipa-3.ipa.ad1.com
> ipa_domain = ipa.ad1.com
> ipa_hostname = ipa-3.ipa.ad1.com
> auth_provider = ipa
> chpass_provider = ipa
> access_provider = ipa
> cache_credentials = True
> ldap_tls_cacert = /etc/ipa/ca.crt
> krb5_store_password_if_offline = True
> sudo_provider = ipa
> autofs_provider = ipa
> subdomains_provider = ipa
> session_provider = ipa
> hostid_provider = ipa
> ipa_server_mode = True
> subdomain_homedir = /home/%u
> default_shell = /bin/bash
> override_shell = /bin/bash
> [sssd]
> services = nss, pam, sudo, ifp
> 
> domains = ipa.ad1.com
> domain_resolution_order = users.ad2.com
> [nss]
> homedir_substring = /home
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> allowed_uids = ipaapi, root
> 
> [session_recording]
> 
> I have debug level 6 enabled on SSSD and when I check the domain status I see 
> the following more often than not.  The ad2.com forest domains are offline.  
> They go online and then as soon as someone tries to login again then either 
> both or just the users.ad2.com domain go offline which causes the login to 
> fail.
> 
> ipa.ad1.com Online status: Online
> ad1.com Online status: Online
> ad2.com Online status: Offline
> users.ad2.com Online status: Offline
> 
> When I look at the SSSD domain logs I see the following (I have replaced 
> internal domain names or hostname)
> 
> *  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sbus_senders_lookup] (0x2000): 
> Looking for identity of sender [sssd.ifp]
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sss_domain_get_state] 
> (0x1000): Domain ipa.ad1.com is Active
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sss_domain_get_state] 
> (0x1000): Domain ad1.com is Active
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sss_domain_get_state] 
> (0x1000): Domain AD2.COM is Active
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sbus_issue_request_done] 
> (0x0400): sssd.DataProvider.Backend.IsOnline: Success
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sbus_dispatch] (0x4000): 
> Dispatching.
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [_read_pipe_handler] (0x0400): 
> [RID#1162] EOF received, client finished
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sdap_get_tgt_recv] (0x0400): 
> [RID#1162] Child responded: 0 [FILE:/var/lib/sss/db/ccache_AD2.COM], expired 
> on [1686187555]
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sdap_cli_auth_step] (0x0100): 
> [RID#1162] expire timeout is 900
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sdap_cli_auth_step] (0x1000): 
> [RID#1162] the connection will expire at 1686152455
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sasl_bind_send] (0x0100): 
> [RID#1162] Executing sasl bind mech: GSSAPI, user: AUTH$
>*  (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sasl_bind_send] (0x0020): 
> [RID#1162] ldap_sasl_interactive_bind_s failed (-2)[Local error]
> ** BACKTRACE DUMP ENDS HERE 
> *
> 
> (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sasl_bind_send] (0x0080): 
> [RID#1162] Extended failure message: [SASL(-1): generic failure: GSSAPI 
> Error: Unspecified GSS failure.  Minor code may provide more information 
> (Server not found in Kerberos database)]
> (2023-06-07 16:25:55): [be[ipa.ad1.com]] [child_sig_handler] (0x0100): 
> [RID#1162] child [9519] finished successfully.
> (2023-06-07 16:25:55): [be[ipa.ad1.com]] [sdap_cli_connect_recv] (0x0040): 
> [RID#1162] Unable to establish

[Freeipa-users] Re: AD Trust with multiple replicas

2022-04-26 Thread Cyrus via FreeIPA-users

El sáb, 23 abr 2022 a las 23:55, Alexander Bokovoy
() escribió:
>
> On la, 23 huhti 2022, Cyrus via FreeIPA-users wrote:
> >Hello!,
> >
> >I'm looking to deploy a multisite setup of FreeIPA, it would be 4
> >sites and 2 nodes per site. Alongside FreeIPA, there will also be:
> >- a pair of Samba4 controllers per site that I would like to setup trust with
> >- sites 5 & 6 from a third party running Windows 2019 AD (single
> >domain, DR setup), with which I also need to setup an AD trust.
> >
> >Is it required that my 8 replicas establish trust with all Samba4 and
> >Windows 2019 servers?
>
> You are using wrong terminology and mixing up preparation of the
> replicas with actual trust agreement. Please read
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/planning_identity_management/planning-a-cross-forest-trust-between-idm-and-ad_planning-identity-management#trust-controllers-and-trust-agents_planning-a-cross-forest-trust-between-idm-and-ad
>
> You do not need to establish trust again and again from different
> replicas.
>
> In short, trust between IPA and an Active Directory forest is
> established once, there is no need to re-establish it multiple times
> from different replicas. A replica that can establish trust is called
> 'Trust Controller'. A replica that can use trust to resolve users and
> groups is called 'Trust Agent'. If you need to ensure that users and
> groups from trusted forests can be resolved everywhere, then all those
> replicas need to be trust agents. You don't need to re-establish trust
> or to make all of those replicas trust controllers.
>
> So all you need to do is:
>
>   - make at least one Trust Controller
>   - use a Trust Controller to designate other replicas Trust Agents
>   - establish trust to the Active Directory forest(s)
>
> Then all clients connected to Trust Agents and Trust Controllers will be
> able to resolve users and groups from trusted forests.
>
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
Good night Alexander,

Thanks a lot for the clarification. After reading the documentation,
my understanding is that if my users reside on that trusted external
domain, I will need to have connectivity from all my FreeIPA nodes
(regardless of Trust Controller or Trust Agent role) in order to
authenticate those users with my FreeIPA managed machines..

Regards,
CI.-
___
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 with multiple replicas

2022-04-23 Thread Alexander Bokovoy via FreeIPA-users


On la, 23 huhti 2022, Cyrus via FreeIPA-users wrote:

Hello!,

I'm looking to deploy a multisite setup of FreeIPA, it would be 4
sites and 2 nodes per site. Alongside FreeIPA, there will also be:
- a pair of Samba4 controllers per site that I would like to setup trust with
- sites 5 & 6 from a third party running Windows 2019 AD (single
domain, DR setup), with which I also need to setup an AD trust.

Is it required that my 8 replicas establish trust with all Samba4 and
Windows 2019 servers?


You are using wrong terminology and mixing up preparation of the
replicas with actual trust agreement. Please read
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/planning_identity_management/planning-a-cross-forest-trust-between-idm-and-ad_planning-identity-management#trust-controllers-and-trust-agents_planning-a-cross-forest-trust-between-idm-and-ad

You do not need to establish trust again and again from different
replicas.

In short, trust between IPA and an Active Directory forest is
established once, there is no need to re-establish it multiple times
from different replicas. A replica that can establish trust is called
'Trust Controller'. A replica that can use trust to resolve users and
groups is called 'Trust Agent'. If you need to ensure that users and
groups from trusted forests can be resolved everywhere, then all those
replicas need to be trust agents. You don't need to re-establish trust
or to make all of those replicas trust controllers.

So all you need to do is:

 - make at least one Trust Controller
 - use a Trust Controller to designate other replicas Trust Agents
 - establish trust to the Active Directory forest(s)

Then all clients connected to Trust Agents and Trust Controllers will be
able to resolve users and groups from trusted forests.



--
/ 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 not working after IPA server reinstall

2021-08-24 Thread Vinícius Ferrão via FreeIPA-users

Florence, thank you. I'll adapt IDM's to have proper mapping when creating 
users.

Nothing still explains why AD Trust came back, but I'll just leave as it. It's 
working now, and I don't know what happened.

Thank you.

On 24 Aug 2021, at 05:47, Florence Renaud 
mailto:f...@redhat.com>> wrote:

Hi,

1/ The local ID range NIX.VERSATUSHPC.COM.BR_id_range shows that you can have 
posix ids created on IdM:
from 1,278,400,000 to 1,278,599,999.
These posix ids can be created either by idm1 or by idm2 server, but you need 
to make sure that they don't use the same value if simultaneous 
user-add/group-add operations are performed on both servers.
Currently, idm1 can pick any value in the 1,278,400,006-1,278,499,999 range 
(ids from 1,278,400,000 to 1,278,400,005 are probably already taken by existing 
users/groups). You need to find the list of posix ids already used, and adjust 
idm range starting from this max value +1. For the end of idm1 range, you can 
for instance cut the original range in 2, and have idm1 stop at 1,278,449,999, 
and idm2 start at 1,278,450,000 and stop at 1,278,499,999 (provided no value 
inside this range was already attributed).

2/ the ipa trust-fetch-domains output is normal, it returns 0 entry and if any 
additional domain is found it is displayed in ipa trustdomain-find.

HTH,
flo

On Fri, Aug 20, 2021 at 11:01 PM Vinícius Ferrão 
mailto:fer...@versatushpc.com.br>> wrote:
Hi Florence.

On 20 Aug 2021, at 05:29, Florence Renaud 
mailto:f...@redhat.com>> wrote:

Hi,

On Thu, Aug 19, 2021 at 7:09 PM Vinícius Ferrão via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:
Hello,

I had to reinstall our IPA server since we had Filesystem corruption beyond 
repair on it.

After the reinstall (with ipa-replica-install) AD Trust does not seems to be 
working anymore.

I tried to delete the trust and them re add it but there's no effect. Here's 
the outputs:

[root@idm1 ~]# ipa-adtrust-install --add-agents

The log file for this installation can be found in 
/var/log/ipaserver-adtrust-install.log
==
This program will setup components needed to establish trust to AD domains for
the IPA Server.

This includes:
  * Configure Samba
  * Add trust related objects to IPA LDAP server

To accept the default shown in brackets, press the Enter key.

Configuring cross-realm trusts for IPA server requires password for user 
'admin'.
This user is a regular system account used for IPA server administration.

admin password:

IPA generated smb.conf detected.
Overwrite smb.conf? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility 
plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work with 
trusted users.

Enable trusted domains support in slapi-nis? [no]: yes


The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring CIFS
  [1/24]: validate server hostname
  [2/24]: stopping smbd
  [3/24]: creating samba domain object
Samba domain object already exists
  [4/24]: retrieve local idmap range
  [5/24]: writing samba config file
  [6/24]: creating samba config registry
  [7/24]: adding cifs Kerberos principal
  [8/24]: adding cifs and host Kerberos principals to the adtrust agents group
  [9/24]: check for cifs services defined on other replicas
  [10/24]: adding cifs principal to S4U2Proxy targets
cifs principal already targeted, nothing to do.
  [11/24]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
  [12/24]: adding RID bases
RID bases already set, nothing to do
  [13/24]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [14/24]: activating CLDAP plugin
CLDAP plugin already configured, nothing to do
  [15/24]: activating sidgen task
Sidgen task plugin already configured, nothing to do
  [16/24]: map BUILTIN\Guests to nobody group
  [17/24]: configuring smbd to start on boot
  [18/24]: enabling trusted domains support for older clients via Schema 
Compatibility plugin
  [19/24]: restarting Directory Server to take MS PAC and LDAP plugins changes 
into account
  [20/24]: adding fallback group
Fallback group already set, nothing to do
  [21/24]: adding Default Trust View
Default Trust View already exists.
  [22/24]: setting SELinux booleans
  [23/24]: starting CIFS services
  [24/24]: restarting smbd
Done configuring CIFS.

=
Setup complete

You must make sure these network ports are open:
TCP Ports:
  * 135: epmap
  * 138: netbios-dgm
  * 139: netbios-ssn
  * 445: microsoft-ds
  * 1024..1300: epmap listener range
  * 3268: msft-gc
UDP Ports:
  * 138: netbios-dgm
  * 139: netbios-ssn
  * 389: (C)LDAP
  * 445: microsoft-ds

See the ipa-adtrust-install(1) man page for more details

[Freeipa-users] Re: AD Trust not working after IPA server reinstall

2021-08-24 Thread Florence Renaud via FreeIPA-users

Hi,

1/ The local ID range NIX.VERSATUSHPC.COM.BR_id_range shows that you can
have posix ids created on IdM:
from 1,278,400,000 to 1,278,599,999.
These posix ids can be created either by idm1 or by idm2 server, but you
need to make sure that they don't use the same value if simultaneous
user-add/group-add operations are performed on both servers.
Currently, idm1 can pick any value in the 1,278,400,006-1,278,499,999 range
(ids from 1,278,400,000 to 1,278,400,005 are probably already taken by
existing users/groups). You need to find the list of posix ids already
used, and adjust idm range starting from this max value +1. For the end of
idm1 range, you can for instance cut the original range in 2, and have idm1
stop at 1,278,449,999, and idm2 start at 1,278,450,000 and stop at
1,278,499,999 (provided no value inside this range was already attributed).

2/ the ipa trust-fetch-domains output is normal, it returns 0 entry and if
any additional domain is found it is displayed in ipa trustdomain-find.

HTH,
flo

On Fri, Aug 20, 2021 at 11:01 PM Vinícius Ferrão 
wrote:

> Hi Florence.
>
> On 20 Aug 2021, at 05:29, Florence Renaud  wrote:
>
> Hi,
>
> On Thu, Aug 19, 2021 at 7:09 PM Vinícius Ferrão via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> Hello,
>>
>> I had to reinstall our IPA server since we had Filesystem corruption
>> beyond repair on it.
>>
>> After the reinstall (with ipa-replica-install) AD Trust does not seems to
>> be working anymore.
>>
>> I tried to delete the trust and them re add it but there's no effect.
>> Here's the outputs:
>>
>> [root@idm1 ~]# ipa-adtrust-install --add-agents
>>
>> The log file for this installation can be found in
>> /var/log/ipaserver-adtrust-install.log
>>
>> ==
>> This program will setup components needed to establish trust to
>> AD domains for
>> the IPA Server.
>>
>> This includes:
>>   * Configure Samba
>>   * Add trust related objects to IPA LDAP server
>>
>> To accept the default shown in brackets, press the Enter key.
>>
>> Configuring cross-realm trusts for IPA server requires password for user
>> 'admin'.
>> This user is a regular system account used for IPA server administration.
>>
>> admin password:
>>
>> IPA generated smb.conf detected.
>> Overwrite smb.conf? [no]: yes
>> Do you want to enable support for trusted domains in Schema Compatibility
>> plugin?
>> This will allow clients older than SSSD 1.9 and non-Linux clients to work
>> with trusted users.
>>
>> Enable trusted domains support in slapi-nis? [no]: yes
>>
>>
>> The following operations may take some minutes to complete.
>> Please wait until the prompt is returned.
>>
>> Configuring CIFS
>>   [1/24]: validate server hostname
>>   [2/24]: stopping smbd
>>   [3/24]: creating samba domain object
>> Samba domain object already exists
>>   [4/24]: retrieve local idmap range
>>   [5/24]: writing samba config file
>>   [6/24]: creating samba config registry
>>   [7/24]: adding cifs Kerberos principal
>>   [8/24]: adding cifs and host Kerberos principals to the adtrust agents
>> group
>>   [9/24]: check for cifs services defined on other replicas
>>   [10/24]: adding cifs principal to S4U2Proxy targets
>> cifs principal already targeted, nothing to do.
>>   [11/24]: adding admin(group) SIDs
>> Admin SID already set, nothing to do
>> Admin group SID already set, nothing to do
>>   [12/24]: adding RID bases
>> RID bases already set, nothing to do
>>   [13/24]: updating Kerberos config
>> 'dns_lookup_kdc' already set to 'true', nothing to do.
>>   [14/24]: activating CLDAP plugin
>> CLDAP plugin already configured, nothing to do
>>   [15/24]: activating sidgen task
>> Sidgen task plugin already configured, nothing to do
>>   [16/24]: map BUILTIN\Guests to nobody group
>>   [17/24]: configuring smbd to start on boot
>>   [18/24]: enabling trusted domains support for older clients via Schema
>> Compatibility plugin
>>   [19/24]: restarting Directory Server to take MS PAC and LDAP
>> plugins changes into account
>>   [20/24]: adding fallback group
>> Fallback group already set, nothing to do
>>   [21/24]: adding Default Trust View
>> Default Trust View already exists.
>>   [22/24]: setting SELinux booleans
>>   [23/24]: starting CIFS services
>>   [24/24]: restarting smbd
>> Done configuring CIFS.
>>
>>
>> =
>> Setup complete
>>
>> You must make sure these network ports are open:
>> TCP Ports:
>>   * 135: epmap
>>   * 138: netbios-dgm
>>   * 139: netbios-ssn
>>   * 445: microsoft-ds
>>   * 1024..1300: epmap listener range
>>   * 3268: msft-gc
>> UDP Ports:
>>   * 138: netbios-dgm
>>   * 139: netbios-ssn
>>   * 389: (C)LDAP
>>   * 445: microsoft-ds
>>
>> See the ipa-adtrust-install(1) man page for more details
>>
>>
>> =
>>
>>
>> Doing the trust add since the last

[Freeipa-users] Re: AD Trust not working after IPA server reinstall

2021-08-20 Thread Vinícius Ferrão via FreeIPA-users

Hi Florence.

On 20 Aug 2021, at 05:29, Florence Renaud 
mailto:f...@redhat.com>> wrote:

Hi,

On Thu, Aug 19, 2021 at 7:09 PM Vinícius Ferrão via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:
Hello,

I had to reinstall our IPA server since we had Filesystem corruption beyond 
repair on it.

After the reinstall (with ipa-replica-install) AD Trust does not seems to be 
working anymore.

I tried to delete the trust and them re add it but there's no effect. Here's 
the outputs:

[root@idm1 ~]# ipa-adtrust-install --add-agents

The log file for this installation can be found in 
/var/log/ipaserver-adtrust-install.log
==
This program will setup components needed to establish trust to AD domains for
the IPA Server.

This includes:
  * Configure Samba
  * Add trust related objects to IPA LDAP server

To accept the default shown in brackets, press the Enter key.

Configuring cross-realm trusts for IPA server requires password for user 
'admin'.
This user is a regular system account used for IPA server administration.

admin password:

IPA generated smb.conf detected.
Overwrite smb.conf? [no]: yes
Do you want to enable support for trusted domains in Schema Compatibility 
plugin?
This will allow clients older than SSSD 1.9 and non-Linux clients to work with 
trusted users.

Enable trusted domains support in slapi-nis? [no]: yes


The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring CIFS
  [1/24]: validate server hostname
  [2/24]: stopping smbd
  [3/24]: creating samba domain object
Samba domain object already exists
  [4/24]: retrieve local idmap range
  [5/24]: writing samba config file
  [6/24]: creating samba config registry
  [7/24]: adding cifs Kerberos principal
  [8/24]: adding cifs and host Kerberos principals to the adtrust agents group
  [9/24]: check for cifs services defined on other replicas
  [10/24]: adding cifs principal to S4U2Proxy targets
cifs principal already targeted, nothing to do.
  [11/24]: adding admin(group) SIDs
Admin SID already set, nothing to do
Admin group SID already set, nothing to do
  [12/24]: adding RID bases
RID bases already set, nothing to do
  [13/24]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
  [14/24]: activating CLDAP plugin
CLDAP plugin already configured, nothing to do
  [15/24]: activating sidgen task
Sidgen task plugin already configured, nothing to do
  [16/24]: map BUILTIN\Guests to nobody group
  [17/24]: configuring smbd to start on boot
  [18/24]: enabling trusted domains support for older clients via Schema 
Compatibility plugin
  [19/24]: restarting Directory Server to take MS PAC and LDAP plugins changes 
into account
  [20/24]: adding fallback group
Fallback group already set, nothing to do
  [21/24]: adding Default Trust View
Default Trust View already exists.
  [22/24]: setting SELinux booleans
  [23/24]: starting CIFS services
  [24/24]: restarting smbd
Done configuring CIFS.

=
Setup complete

You must make sure these network ports are open:
TCP Ports:
  * 135: epmap
  * 138: netbios-dgm
  * 139: netbios-ssn
  * 445: microsoft-ds
  * 1024..1300: epmap listener range
  * 3268: msft-gc
UDP Ports:
  * 138: netbios-dgm
  * 139: netbios-ssn
  * 389: (C)LDAP
  * 445: microsoft-ds

See the ipa-adtrust-install(1) man page for more details

=


Doing the trust add since the last command didn't added it:

[root@idm1 ~]# ipa trust-add 
win.versatushpc.com.br
Active Directory domain administrator: Administrator
Active Directory domain administrator's password:
---
Added Active Directory trust for realm 
"win.versatushpc.com.br"
---
  Realm name: win.versatushpc.com.br
  Domain NetBIOS name: VersatusHPC
  Domain Security Identifier: S-1-5-21-3644117338-1171143469-618167831
  Trust direction: Trusting forest
  Trust type: Active Directory domain
  Trust status: Established and verified


Fetch domains return 0:

[root@idm1 ~]# ipa trust-fetch-domains 
win.versatushpc.com.br

List of trust domains successfully refreshed. Use trustdomain-find command to 
list them.


Number of entries returned 0



But trustdomain-find is able to find the domain:

[root@idm1 ~]# ipa trustdomain-find
Realm name: win.versatushpc.com.br

[Freeipa-users] Re: AD Trust not working after IPA server reinstall

2021-08-20 Thread Florence Renaud via FreeIPA-users

Hi,

On Thu, Aug 19, 2021 at 7:09 PM Vinícius Ferrão via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hello,
>
> I had to reinstall our IPA server since we had Filesystem corruption
> beyond repair on it.
>
> After the reinstall (with ipa-replica-install) AD Trust does not seems to
> be working anymore.
>
> I tried to delete the trust and them re add it but there's no effect.
> Here's the outputs:
>
> [root@idm1 ~]# ipa-adtrust-install --add-agents
>
> The log file for this installation can be found in
> /var/log/ipaserver-adtrust-install.log
>
> ==
> This program will setup components needed to establish trust to AD domains
> for
> the IPA Server.
>
> This includes:
>   * Configure Samba
>   * Add trust related objects to IPA LDAP server
>
> To accept the default shown in brackets, press the Enter key.
>
> Configuring cross-realm trusts for IPA server requires password for user
> 'admin'.
> This user is a regular system account used for IPA server administration.
>
> admin password:
>
> IPA generated smb.conf detected.
> Overwrite smb.conf? [no]: yes
> Do you want to enable support for trusted domains in Schema Compatibility
> plugin?
> This will allow clients older than SSSD 1.9 and non-Linux clients to work
> with trusted users.
>
> Enable trusted domains support in slapi-nis? [no]: yes
>
>
> The following operations may take some minutes to complete.
> Please wait until the prompt is returned.
>
> Configuring CIFS
>   [1/24]: validate server hostname
>   [2/24]: stopping smbd
>   [3/24]: creating samba domain object
> Samba domain object already exists
>   [4/24]: retrieve local idmap range
>   [5/24]: writing samba config file
>   [6/24]: creating samba config registry
>   [7/24]: adding cifs Kerberos principal
>   [8/24]: adding cifs and host Kerberos principals to the adtrust agents
> group
>   [9/24]: check for cifs services defined on other replicas
>   [10/24]: adding cifs principal to S4U2Proxy targets
> cifs principal already targeted, nothing to do.
>   [11/24]: adding admin(group) SIDs
> Admin SID already set, nothing to do
> Admin group SID already set, nothing to do
>   [12/24]: adding RID bases
> RID bases already set, nothing to do
>   [13/24]: updating Kerberos config
> 'dns_lookup_kdc' already set to 'true', nothing to do.
>   [14/24]: activating CLDAP plugin
> CLDAP plugin already configured, nothing to do
>   [15/24]: activating sidgen task
> Sidgen task plugin already configured, nothing to do
>   [16/24]: map BUILTIN\Guests to nobody group
>   [17/24]: configuring smbd to start on boot
>   [18/24]: enabling trusted domains support for older clients via Schema
> Compatibility plugin
>   [19/24]: restarting Directory Server to take MS PAC and LDAP
> plugins changes into account
>   [20/24]: adding fallback group
> Fallback group already set, nothing to do
>   [21/24]: adding Default Trust View
> Default Trust View already exists.
>   [22/24]: setting SELinux booleans
>   [23/24]: starting CIFS services
>   [24/24]: restarting smbd
> Done configuring CIFS.
>
>
> =
> Setup complete
>
> You must make sure these network ports are open:
> TCP Ports:
>   * 135: epmap
>   * 138: netbios-dgm
>   * 139: netbios-ssn
>   * 445: microsoft-ds
>   * 1024..1300: epmap listener range
>   * 3268: msft-gc
> UDP Ports:
>   * 138: netbios-dgm
>   * 139: netbios-ssn
>   * 389: (C)LDAP
>   * 445: microsoft-ds
>
> See the ipa-adtrust-install(1) man page for more details
>
>
> =
>
>
> Doing the trust add since the last command didn't added it:
>
> [root@idm1 ~]# ipa trust-add win.versatushpc.com.br
> Active Directory domain administrator: Administrator
> Active Directory domain administrator's password:
> ---
> Added Active Directory trust for realm "win.versatushpc.com.br"
> ---
>   Realm name: win.versatushpc.com.br
>   Domain NetBIOS name: VersatusHPC
>   Domain Security Identifier: S-1-5-21-3644117338-1171143469-618167831
>   Trust direction: Trusting forest
>   Trust type: Active Directory domain
>   Trust status: Established and verified
>
>
> Fetch domains return 0:
>
> [root@idm1 ~]# ipa trust-fetch-domains win.versatushpc.com.br
>
> 
> List of trust domains successfully refreshed. Use trustdomain-find command
> to list them.
>
> 
> 
> Number of entries returned 0
> 
>
>
> But trustdomain-find is able to find the domain:
>
> [root@idm1 ~]# ipa trustdomain-find
> Realm name: win.versatushpc.com.br
>   Domain

[Freeipa-users] Re: AD Trust Types

2021-06-15 Thread 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

2021-06-15 Thread 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

2021-06-15 Thread 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

2021-06-15 Thread 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?

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

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

[Freeipa-users] Re: AD Trust Types

2021-06-14 Thread Alexander Bokovoy via FreeIPA-users