Hello,
Suppose we have: Machine - with the full name ws16.ad16.loc - MS AD. Windows Server 2016 Machine - with the full name ipasrv-1.ipadomain.loc - IdM AD version 4.8.10. Linux Debian Machine - with the full name adclient-1.ad16.loc - AD Client. Linux Debian Bidirectional trust relationships between IPA and AD are configured. The third machine is joined to the AD domain using sssd 2.4.0.
Can I somehow authenticate on the AD client (third machine) using IdM users via the bidirectional trust relationships? That is, I don't mean the case where we make the AD client partially integrated into IdM by adding settings in sssd.conf for the second domain ([domain/ipadomain.loc]) and updating krb5.keytab. I mean, how can I make it so that the request goes specifically through AD (i.e., via the trust relationships) and not directly to IdM? And is this possible?
Thanks.
On Чцв, 28 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Hello,
Suppose we have: Machine - with the full name ws16.ad16.loc - MS AD. Windows Server 2016 Machine - with the full name ipasrv-1.ipadomain.loc - IdM AD version 4.8.10. Linux Debian Machine - with the full name adclient-1.ad16.loc - AD Client. Linux Debian Bidirectional trust relationships between IPA and AD are configured. The third machine is joined to the AD domain using sssd 2.4.0.
Can I somehow authenticate on the AD client (third machine) using IdM users via the bidirectional trust relationships?
No, it is not implemented at this point.
That is, I don't mean the case where we make the AD client partially integrated into IdM by adding settings in sssd.conf for the second domain ([domain/ipadomain.loc]) and updating krb5.keytab. I mean, how can I make it so that the request goes specifically through AD (i.e., via the trust relationships) and not directly to IdM? And is this possible?
You cannot.
On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Can you explain in more detail why? Thakns
What specifically? We do not support login to Windows machines as IPA users. This is not implemented. We have a work in progress to add that but it is incomplete yet.
Windows machines always talk to their own Active Directory domain controllers. If AD DC issued a referral to other realm, they'll follow it up, but the referral will contain cross-realm TGS, so Windows client always starts from their DC and then follows up to a trusted domain's DC.
In any case, Windows machines need more than just Kerberos to be able to login users and that part is not in FreeIPA releases yet.
I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct?
So the scheme is: Linux AD client -> AD <-> IPA
On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote:
I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct?
So the scheme is: Linux AD client -> AD <-> IPA
If that Linux client is enrolled into AD domain, it will be talking to AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs.
Alexander Bokovoy wrote:
On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote:
I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct? So the scheme is: Linux AD client -> AD <-> IPA If that Linux client is enrolled into AD domain, it will be talking to
AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs.
Sorry for spamming, but I would like to know. This is important information for me.
On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Alexander Bokovoy wrote:
On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote:
I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct? So the scheme is: Linux AD client -> AD <-> IPA If that Linux client is enrolled into AD domain, it will be talking to
AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs.
Sorry for spamming, but I would like to know. This is important information for me.
I answered your questions already. Sorry, I don't have time right now to respond more on this beyond what is already said.
Alexander Bokovoy wrote:
On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Alexander Bokovoy wrote: On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote: I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct? So the scheme is: Linux AD client -> AD <-> IPA If that Linux client is enrolled into AD domain, it will be talking to AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs. Sorry for spamming, but I would like to know. This is important information for me. I answered your questions already. Sorry, I don't have time right now to
respond more on this beyond what is already said.
How then does a Windows 10 client located in MS AD successfully obtain FreeIPA trusted domain information and successfully launch a user's IPA session?
On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Alexander Bokovoy wrote:
On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Alexander Bokovoy wrote: On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote: I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct? So the scheme is: Linux AD client -> AD <-> IPA If that Linux client is enrolled into AD domain, it will be talking to AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs. Sorry for spamming, but I would like to know. This is important information for me. I answered your questions already. Sorry, I don't have time right now to
respond more on this beyond what is already said.
How then does a Windows 10 client located in MS AD successfully obtain FreeIPA trusted domain information and successfully launch a user's IPA session?
https://www.freeipa.org/page/Windows_authentication_against_FreeIPA#id1: .... Note also that the described configuration is not supported by FreeIPA development team and also is not supported by Red Hat Enterprise Linux Identity Management product. A work on making possible to login to Windows machines already enrolled into a trusted Active Directory forest is ongoing and is not available yet in any released FreeIPA version. ....
This is not a supported setup and we have no time to look into it at the moment.
Alexander Bokovoy wrote:
On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Alexander Bokovoy wrote: On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote: I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct? So the scheme is: Linux AD client -> AD <-> IPA If that Linux client is enrolled into AD domain, it will be talking to AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs. Sorry for spamming, but I would like to know. This is important information for me. I answered your questions already. Sorry, I don't have time right now to respond more on this beyond what is already said. How then does a Windows 10 client located in MS AD successfully obtain FreeIPA trusted domain information and successfully launch a user's IPA session? https://www.freeipa.org/page/Windows_authentication_against_FreeIPA#id1:
.... Note also that the described configuration is not supported by FreeIPA development team and also is not supported by Red Hat Enterprise Linux Identity Management product. A work on making possible to login to Windows machines already enrolled into a trusted Active Directory forest is ongoing and is not available yet in any released FreeIPA version. .... This is not a supported setup and we have no time to look into it at the moment.
So Windows AD client also can't log in under IdM accounts via trust relationships? Sorry for my redundancy.
I mean IdM <-> AD <- Windows 10
Aleksandr Sabirov via FreeIPA-users wrote:
Alexander Bokovoy wrote:
On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Alexander Bokovoy wrote: On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote: I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct? So the scheme is: Linux AD client -> AD <-> IPA If that Linux client is enrolled into AD domain, it will be talking to AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs. Sorry for spamming, but I would like to know. This is important information for me. I answered your questions already. Sorry, I don't have time right now to respond more on this beyond what is already said. How then does a Windows 10 client located in MS AD successfully obtain FreeIPA trusted domain information and successfully launch a user's IPA session? https://www.freeipa.org/page/Windows_authentication_against_FreeIPA#id1:
.... Note also that the described configuration is not supported by FreeIPA development team and also is not supported by Red Hat Enterprise Linux Identity Management product. A work on making possible to login to Windows machines already enrolled into a trusted Active Directory forest is ongoing and is not available yet in any released FreeIPA version. .... This is not a supported setup and we have no time to look into it at the moment.
So Windows AD client also can't log in under IdM accounts via trust relationships? Sorry for my redundancy.
I mean IdM <-> AD <- Windows 10
Have you read the documentation?
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-sin...
rob
Rob Crittenden wrote:
Aleksandr Sabirov via FreeIPA-users wrote:
Alexander Bokovoy wrote: On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote: I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct? So the scheme is: Linux AD client -> AD <-> IPA If that Linux client is enrolled into AD domain, it will be talking to AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs. Sorry for spamming, but I would like to know. This is important information for me. I answered your questions already. Sorry, I don't have time right now to respond more on this beyond what is already said. How then does a Windows 10 client located in MS AD successfully obtain FreeIPA trusted domain information and successfully launch a user's IPA session? https://www.freeipa.org/page/Windows_authentication_against_FreeIPA#id1: .... Note also that the described configuration is not supported by FreeIPA development team and also is not supported by Red Hat Enterprise Linux Identity Management product. A work on making possible to login to Windows machines already enrolled into a trusted Active Directory forest is ongoing and is not available yet in any released FreeIPA version. .... This is not a supported setup and we have no time to look into it at the moment. So Windows AD client also can't log in under IdM accounts via trust relationships? Sorry for my redundancy. I mean IdM <-> AD <- Windows 10 Have you read the documentation?
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-sin... rob
Yes, I have read it. But everything there is described in "abstract terms." I want to know the specific names of the mechanisms that make it work that way.
What do Windows AD clients have that Linux clients don't, since Windows can obtain users through trust relationships, but Linux cannot.
On Срд, 04 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Rob Crittenden wrote:
Aleksandr Sabirov via FreeIPA-users wrote:
Alexander Bokovoy wrote: On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote: I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct? So the scheme is: Linux AD client -> AD <-> IPA If that Linux client is enrolled into AD domain, it will be talking to AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs. Sorry for spamming, but I would like to know. This is important information for me. I answered your questions already. Sorry, I don't have time right now to respond more on this beyond what is already said. How then does a Windows 10 client located in MS AD successfully obtain FreeIPA trusted domain information and successfully launch a user's IPA session? https://www.freeipa.org/page/Windows_authentication_against_FreeIPA#id1: .... Note also that the described configuration is not supported by FreeIPA development team and also is not supported by Red Hat Enterprise Linux Identity Management product. A work on making possible to login to Windows machines already enrolled into a trusted Active Directory forest is ongoing and is not available yet in any released FreeIPA version. .... This is not a supported setup and we have no time to look into it at the moment. So Windows AD client also can't log in under IdM accounts via trust relationships? Sorry for my redundancy. I mean IdM <-> AD <- Windows 10 Have you read the documentation?
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-sin... rob
Yes, I have read it. But everything there is described in "abstract terms." I want to know the specific names of the mechanisms that make it work that way.
What do Windows AD clients have that Linux clients don't, since Windows can obtain users through trust relationships, but Linux cannot. --
Windows clients talk to AD DCs using DCE RPC calls and delegate to AD DCs to talk to trusted domains' domain controllers. SSSD does not use DCE RPC calls like Windows does. It only talks over LDAP to AD DCs and uses Kerberos for authentication. In addition, SSSD AD provider does not support for an IPA domain being a subdomain of a AD domain. This means it cannot switch LDAP schema to IPA one when talking to IPA DC, even when it could reach IPA DC and could authenticate to it (over two-way trust).
If you need to know about Active Directory stuff, you can start with MS-ADOD[1] and MS-AUTHOD[2] overview documents.
[1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adod [2] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-authsod
Alexander Bokovoy wrote:
On Срд, 04 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Rob Crittenden wrote: Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote: I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct? So the scheme is: Linux AD client -> AD <-> IPA If that Linux client is enrolled into AD domain, it will be talking to AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs. Sorry for spamming, but I would like to know. This is important information for me. I answered your questions already. Sorry, I don't have time right now to respond more on this beyond what is already said. How then does a Windows 10 client located in MS AD successfully obtain FreeIPA trusted domain information and successfully launch a user's IPA session? https://www.freeipa.org/page/Windows_authentication_against_FreeIPA#id1: .... Note also that the described configuration is not supported by FreeIPA development team and also is not supported by Red Hat Enterprise Linux Identity Management product. A work on making possible to login to Windows machines already enrolled into a trusted Active Directory forest is ongoing and is not available yet in any released FreeIPA version. .... This is not a supported setup and we have no time to look into it at the moment. So Windows AD client also can't log in under IdM accounts via trust relationships? Sorry for my redundancy. I mean IdM <-> AD <- Windows 10 Have you read the documentation? https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-sin... rob Yes, I have read it. But everything there is described in "abstract terms." I want to know the specific names of the mechanisms that make it work that way. What do Windows AD clients have that Linux clients don't, since Windows can obtain users through trust relationships, but Linux cannot. -- Windows clients talk to AD DCs using DCE RPC calls and delegate to AD
DCs to talk to trusted domains' domain controllers. SSSD does not use DCE RPC calls like Windows does. It only talks over LDAP to AD DCs and uses Kerberos for authentication. In addition, SSSD AD provider does not support for an IPA domain being a subdomain of a AD domain. This means it cannot switch LDAP schema to IPA one when talking to IPA DC, even when it could reach IPA DC and could authenticate to it (over two-way trust). If you need to know about Active Directory stuff, you can start with MS-ADOD[1] and MS-AUTHOD[2] overview documents. [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adod [2] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-authsod
Is there any sort of roadmap for specific possible improvements (including the names of the technologies, etc.)? If not, could you perhaps find the time to provide a detailed description of what needs to be improved, where, and roughly how (with the names of the specific services, of course)? I want to assess the resources and possibilities for contributing this functionality later on.
Is there perhaps a connection scheme that needs to be implemented (similar to the ones in the official documentation)? They have diagrams for a Windows client with AD and a Linux client with IdM. Is there a diagram for a Linux client with AD?
thx.
On Срд, 25 сне 2024, Артемий Куликов via FreeIPA-users wrote:
Alexander Bokovoy wrote:
On Срд, 04 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote:
Rob Crittenden wrote: Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Аўт, 03 сне 2024, Aleksandr Sabirov via FreeIPA-users wrote: Alexander Bokovoy wrote: On Пят, 29 ліс 2024, Aleksandr Sabirov via FreeIPA-users wrote: I need a Linux client (using SSSD), joined to an AD domain, to be able to authenticate to IPA users through trust relationships. This is not possible, am I correct? So the scheme is: Linux AD client -> AD <-> IPA If that Linux client is enrolled into AD domain, it will be talking to AD DC, as I said, and then will be talking to IPA DC. This is only for authentication; identities will have to be fetched from AD DCs and they will not have that information because they couldn't retrieve it from IPA DCs. Sorry for spamming, but I would like to know. This is important information for me. I answered your questions already. Sorry, I don't have time right now to respond more on this beyond what is already said. How then does a Windows 10 client located in MS AD successfully obtain FreeIPA trusted domain information and successfully launch a user's IPA session? https://www.freeipa.org/page/Windows_authentication_against_FreeIPA#id1: .... Note also that the described configuration is not supported by FreeIPA development team and also is not supported by Red Hat Enterprise Linux Identity Management product. A work on making possible to login to Windows machines already enrolled into a trusted Active Directory forest is ongoing and is not available yet in any released FreeIPA version. .... This is not a supported setup and we have no time to look into it at the moment. So Windows AD client also can't log in under IdM accounts via trust relationships? Sorry for my redundancy. I mean IdM <-> AD <- Windows 10 Have you read the documentation? https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-sin... rob Yes, I have read it. But everything there is described in "abstract terms." I want to know the specific names of the mechanisms that make it work that way. What do Windows AD clients have that Linux clients don't, since Windows can obtain users through trust relationships, but Linux cannot. -- Windows clients talk to AD DCs using DCE RPC calls and delegate to AD
DCs to talk to trusted domains' domain controllers. SSSD does not use DCE RPC calls like Windows does. It only talks over LDAP to AD DCs and uses Kerberos for authentication. In addition, SSSD AD provider does not support for an IPA domain being a subdomain of a AD domain. This means it cannot switch LDAP schema to IPA one when talking to IPA DC, even when it could reach IPA DC and could authenticate to it (over two-way trust). If you need to know about Active Directory stuff, you can start with MS-ADOD[1] and MS-AUTHOD[2] overview documents. [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adod [2] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-authsod
Is there any sort of roadmap for specific possible improvements (including the names of the technologies, etc.)? If not, could you perhaps find the time to provide a detailed description of what needs to be improved, where, and roughly how (with the names of the specific services, of course)? I want to assess the resources and possibilities for contributing this functionality later on.
There are no plans to add support of IPA subdomains to AD identity provider in SSSD as far as I know. This is not on any roadmap.
Technologies involved to talk to AD DCs over DCE RPC are all covered in the documents I already linked. You can look at Samba source code for details of their implementation.
Is there perhaps a connection scheme that needs to be implemented (similar to the ones in the official documentation)? They have diagrams for a Windows client with AD and a Linux client with IdM. Is there a diagram for a Linux client with AD?
Look at the MS-ADOD/MS-AUTHSOD. Active Directory domain clients and domain controllers are supposed to implement that spec.
freeipa-users@lists.fedorahosted.org
-
Aleksandr Sabirov -
Alexander Bokovoy -
Rob Crittenden -
Артемий Куликов