hi guys
I've have AD trust work fine (gssapi), ssh & samba are password-less when the trust is establish with 'admin' credentials.
But the strory is very different with 'shared secret'. Kerberos does not work, passwords are asked for and with Windows cifs - asks for username and no authentication even with passwords!
And this weird bit, I do:
$ ipa trust-add --all --two-way=0 --type=ad bec.private.mac.ac.uk --trust-secret --server=win8-vm.bec.private.mac.ac.uk
Shared secret for the trust:
...
Here, for the 'secret' I can punch in anything and IPA will say that the trust was added successfully - this surely must not be right, right?
So, should 'secret' work for one-way incoming trust in IPA? To me, it does not seem like.
many thanks, L.
On to, 14 marras 2019, lejeczek via FreeIPA-users wrote:
hi guys
I've have AD trust work fine (gssapi), ssh & samba are password-less when the trust is establish with 'admin' credentials.
But the strory is very different with 'shared secret'. Kerberos does not work, passwords are asked for and with Windows cifs - asks for username and no authentication even with passwords!
And this weird bit, I do:
$ ipa trust-add --all --two-way=0 --type=ad bec.private.mac.ac.uk --trust-secret --server=win8-vm.bec.private.mac.ac.uk
Shared secret for the trust:
...
Here, for the 'secret' I can punch in anything and IPA will say that the trust was added successfully - this surely must not be right, right?
So, should 'secret' work for one-way incoming trust in IPA? To me, it does not seem like.
It very much depends what RHEL/CentOS version do you use. What ipa-server package version? You need RHEL 7.7 as a base.
See https://bugzilla.redhat.com/show_bug.cgi?id=1757507
However, there is a catch. If you have more than one domain in your IPA deployment that is not subdomain of the primary IPA domain (e.g. example.test and anotherdomain.test where example.test is primary IPA domain), then GSSAPI authentication to anotherdomain.test would not work from Windows machines. This is because we don't yet have implementation of the APIs expected by Active Directory domain controllers to retrieve the forest topology from IPA side and we cannot update it on AD DC side from IPA without admin credentials.
On 14/11/2019 11:44, Alexander Bokovoy wrote:
On to, 14 marras 2019, lejeczek via FreeIPA-users wrote:
hi guys
I've have AD trust work fine (gssapi), ssh & samba are password-less when the trust is establish with 'admin' credentials.
But the strory is very different with 'shared secret'. Kerberos does not work, passwords are asked for and with Windows cifs - asks for username and no authentication even with passwords!
And this weird bit, I do:
$ ipa trust-add --all --two-way=0 --type=ad bec.private.mac.ac.uk --trust-secret --server=win8-vm.bec.private.mac.ac.uk
Shared secret for the trust:
...
Here, for the 'secret' I can punch in anything and IPA will say that the trust was added successfully - this surely must not be right, right?
So, should 'secret' work for one-way incoming trust in IPA? To me, it does not seem like.
It very much depends what RHEL/CentOS version do you use. What ipa-server package version? You need RHEL 7.7 as a base.
IPA version in the subject. I'm on Centos 7.7.1908.
thanks, L.
See https://bugzilla.redhat.com/show_bug.cgi?id=1757507
However, there is a catch. If you have more than one domain in your IPA deployment that is not subdomain of the primary IPA domain (e.g. example.test and anotherdomain.test where example.test is primary IPA domain), then GSSAPI authentication to anotherdomain.test would not work from Windows machines. This is because we don't yet have implementation of the APIs expected by Active Directory domain controllers to retrieve the forest topology from IPA side and we cannot update it on AD DC side from IPA without admin credentials.
On 14/11/2019 11:44, Alexander Bokovoy wrote:
On to, 14 marras 2019, lejeczek via FreeIPA-users wrote:
hi guys
I've have AD trust work fine (gssapi), ssh & samba are password-less when the trust is establish with 'admin' credentials.
But the strory is very different with 'shared secret'. Kerberos does not work, passwords are asked for and with Windows cifs - asks for username and no authentication even with passwords!
And this weird bit, I do:
$ ipa trust-add --all --two-way=0 --type=ad bec.private.mac.ac.uk --trust-secret --server=win8-vm.bec.private.mac.ac.uk
Shared secret for the trust:
...
Here, for the 'secret' I can punch in anything and IPA will say that the trust was added successfully - this surely must not be right, right?
So, should 'secret' work for one-way incoming trust in IPA? To me, it does not seem like.
It very much depends what RHEL/CentOS version do you use. What ipa-server package version? You need RHEL 7.7 as a base.
I do not think this works. I've been now trying 4.7.1 on Centos 8 and I get the same results which are - no kerberos for user authentication.
Which is even more disappointing when you check rpm changelogs for both versions because there it says that it's been implemented.
many thanks, L.
See https://bugzilla.redhat.com/show_bug.cgi?id=1757507
However, there is a catch. If you have more than one domain in your IPA deployment that is not subdomain of the primary IPA domain (e.g. example.test and anotherdomain.test where example.test is primary IPA domain), then GSSAPI authentication to anotherdomain.test would not work from Windows machines. This is because we don't yet have implementation of the APIs expected by Active Directory domain controllers to retrieve the forest topology from IPA side and we cannot update it on AD DC side from IPA without admin credentials.
On su, 17 marras 2019, lejeczek via FreeIPA-users wrote:
On 14/11/2019 11:44, Alexander Bokovoy wrote:
On to, 14 marras 2019, lejeczek via FreeIPA-users wrote:
hi guys
I've have AD trust work fine (gssapi), ssh & samba are password-less when the trust is establish with 'admin' credentials.
But the strory is very different with 'shared secret'. Kerberos does not work, passwords are asked for and with Windows cifs - asks for username and no authentication even with passwords!
And this weird bit, I do:
$ ipa trust-add --all --two-way=0 --type=ad bec.private.mac.ac.uk --trust-secret --server=win8-vm.bec.private.mac.ac.uk
Shared secret for the trust:
...
Here, for the 'secret' I can punch in anything and IPA will say that the trust was added successfully - this surely must not be right, right?
So, should 'secret' work for one-way incoming trust in IPA? To me, it does not seem like.
It very much depends what RHEL/CentOS version do you use. What ipa-server package version? You need RHEL 7.7 as a base.
I do not think this works. I've been now trying 4.7.1 on Centos 8 and I get the same results which are - no kerberos for user authentication.
Which is even more disappointing when you check rpm changelogs for both versions because there it says that it's been implemented.
It works and we have tests for it, all commits are in https://pagure.io/freeipa/issue/6077
If it doesn't work for you, you need to follow https://access.redhat.com/solutions/3346421 to gather logs and provide them off-list.
I'm on vacation until November 26th and most likely will have no access to my work email.
On 17/11/2019 17:00, Alexander Bokovoy wrote:
On su, 17 marras 2019, lejeczek via FreeIPA-users wrote:
On 14/11/2019 11:44, Alexander Bokovoy wrote:
On to, 14 marras 2019, lejeczek via FreeIPA-users wrote:
hi guys
I've have AD trust work fine (gssapi), ssh & samba are password-less when the trust is establish with 'admin' credentials.
But the strory is very different with 'shared secret'. Kerberos does not work, passwords are asked for and with Windows cifs - asks for username and no authentication even with passwords!
And this weird bit, I do:
$ ipa trust-add --all --two-way=0 --type=ad bec.private.mac.ac.uk --trust-secret --server=win8-vm.bec.private.mac.ac.uk
Shared secret for the trust:
...
Here, for the 'secret' I can punch in anything and IPA will say that the trust was added successfully - this surely must not be right, right?
So, should 'secret' work for one-way incoming trust in IPA? To me, it does not seem like.
It very much depends what RHEL/CentOS version do you use. What ipa-server package version? You need RHEL 7.7 as a base.
I do not think this works. I've been now trying 4.7.1 on Centos 8 and I get the same results which are - no kerberos for user authentication.
Which is even more disappointing when you check rpm changelogs for both versions because there it says that it's been implemented.
It works and we have tests for it, all commits are in https://pagure.io/freeipa/issue/6077
If it doesn't work for you, you need to follow https://access.redhat.com/solutions/3346421 to gather logs and provide them off-list.
I'm on vacation until November 26th and most likely will have no access to my work email.
One other thing I noticed is that setting up such one-way-trust-secret trust does not end up in AD having any 'name suffix routing' added/created.
When I try to refresh that routing and AD asks for credentials then I get from AD:
"Unable to read forest trust information from the other domain. Th error is: Access is denied."
many thanks, L.
On 14/11/2019 10:56, lejeczek via FreeIPA-users wrote:
hi guys
I've have AD trust work fine (gssapi), ssh & samba are password-less when the trust is establish with 'admin' credentials.
But the strory is very different with 'shared secret'. Kerberos does not work, passwords are asked for and with Windows cifs - asks for username and no authentication even with passwords!
And this weird bit, I do:
$ ipa trust-add --all --two-way=0 --type=ad bec.private.mac.ac.uk --trust-secret --server=win8-vm.bec.private.mac.ac.uk
Shared secret for the trust:
...
Here, for the 'secret' I can punch in anything and IPA will say that the trust was added successfully - this surely must not be right, right?
So, should 'secret' work for one-way incoming trust in IPA? To me, it does not seem like.
many thanks, L.
I think it's okey (and the highest time) to say that IPA does not give a working one-way-trust-secret trust with AD. (so folks would not waste time trying)
Maybe in labs for @devel it does work but what's rpm packaged in common distros for 'regular' folk world, that is broken.
Anybody not 'devel' got such trust work?
many thanks, L.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
lejeczek