We are migrating to a new domain AD domain and I got cross domain trust problems(there is a bidirectional cross trust between the two ADs, how can I test this works from Linux?). All users in domain A has been copied to domain B(using the same UID/GID as in domain A).
I have managed to configure sssd for both domains(lets call the old domain A and the new B), joined to both domains and I can login using any of the 2 domains.
But here is the problem: If I use the new domain(B) as default login domain, I cannot ssh to another system still in domain A password less(without entering my password again) or access files on NFS mounted files exported from domain A.
I know very little about cross trust etc. so I want to ask: 1) Is this even possible? 2) I have no idea where to start looking for what went wrong, need som pointers.
We are using sssd 1.13.4 on the new domain B machines while servers in domain A uses an older sssd(1.12.5)
Jocke
On 27.7.2016 15:55, Joakim Tjernlund wrote:
We are migrating to a new domain AD domain and I got cross domain trust problems(there is a bidirectional cross trust between the two ADs, how can I test this works from Linux?). All users in domain A has been copied to domain B(using the same UID/GID as in domain A).
I have managed to configure sssd for both domains(lets call the old domain A and the new B), joined to both domains and I can login using any of the 2 domains.
But here is the problem: If I use the new domain(B) as default login domain, I cannot ssh to another system still in domain A password less(without entering my password again) or access files on NFS mounted files exported from domain A.
I know very little about cross trust etc. so I want to ask:
- Is this even possible?
- I have no idea where to start looking for what went wrong, need som pointers.
We are using sssd 1.13.4 on the new domain B machines while servers in domain A uses an older sssd(1.12.5)
The first step is to verify that system joined to domain B can get keys for domain A.
Log in to a system joined to domain B as some user from domain B. Then run this command: $ kvno host/<hostname of a system joined to a system in domain A>
It should print some number. If it prints an error use command $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> and see what went wrong. It would indicate a problem on Kerberos level.
If this works, looks at the target system (joined to domain A) and see its logs.
If you want to treat user1@domainA and user2@domainB as equal you might need to tweak Kerberos mapping from principals to local users, see https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... and edit krb5.conf to suit your needs.
I hope it helps.
On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote:
On 27.7.2016 15:55, Joakim Tjernlund wrote:
We are migrating to a new domain AD domain and I got cross domain trust problems(there is a bidirectional cross trust between the two ADs, how can I test this works from Linux?). All users in domain A has been copied to domain B(using the same UID/GID as in domain A).
I have managed to configure sssd for both domains(lets call the old domain A and the new B), joined to both domains and I can login using any of the 2 domains.
But here is the problem: If I use the new domain(B) as default login domain, I cannot ssh to another system still in domain A password less(without entering my password again) or access files on NFS mounted files exported from domain A.
I know very little about cross trust etc. so I want to ask:
- Is this even possible?
- I have no idea where to start looking for what went wrong, need som pointers.
We are using sssd 1.13.4 on the new domain B machines while servers in domain A uses an older sssd(1.12.5)
The first step is to verify that system joined to domain B can get keys for domain A.
Log in to a system joined to domain B as some user from domain B. Then run this command: $ kvno host/<hostname of a system joined to a system in domain A>
It should print some number. If it prints an error use command $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> and see what went wrong. It would indicate a problem on Kerberos level.
This works for both myhost@A and myhost@B so I guess all is good.
If this works, looks at the target system (joined to domain A) and see its logs.
If you want to treat user1@domainA and user2@domainB as equal you might need to tweak Kerberos mapping from principals to local users, see https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... and edit krb5.conf to suit your needs.
In server@A or newhost@B ?
One thing that works though is ssh from server@A to newhost@B (no passwd needed) but ssh newhost@B to server@A fail(asks for passwd). I guess this could be because newhost@B is joined to both domains and sssd is configured for both domains ?
Jocke
On Wed, Jul 27, 2016 at 03:12:47PM +0000, Joakim Tjernlund wrote:
On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote:
On 27.7.2016 15:55, Joakim Tjernlund wrote:
We are migrating to a new domain AD domain and I got cross domain trust problems(there is a bidirectional cross trust between the two ADs, how can I test this works from Linux?). All users in domain A has been copied to domain B(using the same UID/GID as in domain A).
I have managed to configure sssd for both domains(lets call the old domain A and the new B), joined to both domains and I can login using any of the 2 domains.
But here is the problem: If I use the new domain(B) as default login domain, I cannot ssh to another system still in domain A password less(without entering my password again) or access files on NFS mounted files exported from domain A.
I know very little about cross trust etc. so I want to ask:
- Is this even possible?
- I have no idea where to start looking for what went wrong, need som pointers.
We are using sssd 1.13.4 on the new domain B machines while servers in domain A uses an older sssd(1.12.5)
The first step is to verify that system joined to domain B can get keys for domain A.
Log in to a system joined to domain B as some user from domain B. Then run this command: $ kvno host/<hostname of a system joined to a system in domain A>
It should print some number. If it prints an error use command $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> and see what went wrong. It would indicate a problem on Kerberos level.
This works for both myhost@A and myhost@B so I guess all is good.
If this works, looks at the target system (joined to domain A) and see its logs.
If you want to treat user1@domainA and user2@domainB as equal you might need to tweak Kerberos mapping from principals to local users, see https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... and edit krb5.conf to suit your needs.
In server@A or newhost@B ?
One thing that works though is ssh from server@A to newhost@B (no passwd needed) but ssh newhost@B to server@A fail(asks for passwd). I guess this could be because newhost@B is joined to both domains and sssd is configured for both domains ?
I'm not great at debugging these failures either, but normally I start by increasing the SSHD (not SSSD) debug level and looking at what failures I get from SSHD.
Off-bat, I would also check if the domain-realm mappings in /etc/krb5.conf look like, maybe the system has them configured only for one domain since one domain works?
On Thu, 2016-07-28 at 09:57 +0200, Jakub Hrozek wrote:
On Wed, Jul 27, 2016 at 03:12:47PM +0000, Joakim Tjernlund wrote:
On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote:
On 27.7.2016 15:55, Joakim Tjernlund wrote:
We are migrating to a new domain AD domain and I got cross domain trust problems(there is a bidirectional cross trust between the two ADs, how can I test this works from Linux?). All users in domain A has been copied to domain B(using the same UID/GID as in domain A).
I have managed to configure sssd for both domains(lets call the old domain A and the new B), joined to both domains and I can login using any of the 2 domains.
But here is the problem: If I use the new domain(B) as default login domain, I cannot ssh to another system still in domain A password less(without entering my password again) or access files on NFS mounted files exported from domain A.
I know very little about cross trust etc. so I want to ask:
- Is this even possible?
- I have no idea where to start looking for what went wrong, need som pointers.
We are using sssd 1.13.4 on the new domain B machines while servers in domain A uses an older sssd(1.12.5)
The first step is to verify that system joined to domain B can get keys for domain A.
Log in to a system joined to domain B as some user from domain B. Then run this command: $ kvno host/<hostname of a system joined to a system in domain A>
It should print some number. If it prints an error use command $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> and see what went wrong. It would indicate a problem on Kerberos level.
This works for both myhost@A and myhost@B so I guess all is good.
If this works, looks at the target system (joined to domain A) and see its logs.
If you want to treat user1@domainA and user2@domainB as equal you might need to tweak Kerberos mapping from principals to local users, see https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... and edit krb5.conf to suit your needs.
In server@A or newhost@B ?
One thing that works though is ssh from server@A to newhost@B (no passwd needed) but ssh newhost@B to server@A fail(asks for passwd). I guess this could be because newhost@B is joined to both domains and sssd is configured for both domains ?
I'm not great at debugging these failures either, but normally I start by increasing the SSHD (not SSSD) debug level and looking at what failures I get from SSHD.
Off-bat, I would also check if the domain-realm mappings in /etc/krb5.conf look like, maybe the system has them configured only for one domain since one domain works?
Been a bit busy with other things but now a am back with full force again :)
It is starting to work but I need a /home/%user/.k5login for ssh to let me in without passwd :( How can I get rid of having a .k5login?
My krb5.conf looks like [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so }
[libdefaults] default_realm = A or B # A is the old domain and we are moving to B forwardable = yes allow_weak_crypto = true dns_lookup_realm = true dns_lookup_kdc = true
On Wed, Aug 03, 2016 at 05:07:31PM +0000, Joakim Tjernlund wrote:
On Thu, 2016-07-28 at 09:57 +0200, Jakub Hrozek wrote:
On Wed, Jul 27, 2016 at 03:12:47PM +0000, Joakim Tjernlund wrote:
On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote:
On 27.7.2016 15:55, Joakim Tjernlund wrote:
We are migrating to a new domain AD domain and I got cross domain trust problems(there is a bidirectional cross trust between the two ADs, how can I test this works from Linux?). All users in domain A has been copied to domain B(using the same UID/GID as in domain A).
I have managed to configure sssd for both domains(lets call the old domain A and the new B), joined to both domains and I can login using any of the 2 domains.
But here is the problem: If I use the new domain(B) as default login domain, I cannot ssh to another system still in domain A password less(without entering my password again) or access files on NFS mounted files exported from domain A.
I know very little about cross trust etc. so I want to ask:
- Is this even possible?
- I have no idea where to start looking for what went wrong, need som pointers.
We are using sssd 1.13.4 on the new domain B machines while servers in domain A uses an older sssd(1.12.5)
The first step is to verify that system joined to domain B can get keys for domain A.
Log in to a system joined to domain B as some user from domain B. Then run this command: $ kvno host/<hostname of a system joined to a system in domain A>
It should print some number. If it prints an error use command $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> and see what went wrong. It would indicate a problem on Kerberos level.
This works for both myhost@A and myhost@B so I guess all is good.
If this works, looks at the target system (joined to domain A) and see its logs.
If you want to treat user1@domainA and user2@domainB as equal you might need to tweak Kerberos mapping from principals to local users, see https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... and edit krb5.conf to suit your needs.
In server@A or newhost@B ?
One thing that works though is ssh from server@A to newhost@B (no passwd needed) but ssh newhost@B to server@A fail(asks for passwd). I guess this could be because newhost@B is joined to both domains and sssd is configured for both domains ?
I'm not great at debugging these failures either, but normally I start by increasing the SSHD (not SSSD) debug level and looking at what failures I get from SSHD.
Off-bat, I would also check if the domain-realm mappings in /etc/krb5.conf look like, maybe the system has them configured only for one domain since one domain works?
Been a bit busy with other things but now a am back with full force again :)
It is starting to work but I need a /home/%user/.k5login for ssh to let me in without passwd :( How can I get rid of having a .k5login?
My krb5.conf looks like [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so }
[libdefaults] default_realm = A or B # A is the old domain and we are moving to B forwardable = yes allow_weak_crypto = true dns_lookup_realm = true dns_lookup_kdc = true
I think this should work. Is there any activity in the SSSD logs indicating a principal-to-name-lookup? Are there any errors in the SSHD logs?
Alexander, do you see something wrong in the libdefaults section?
On Thu, 2016-08-04 at 10:41 +0200, Jakub Hrozek wrote:
On Wed, Aug 03, 2016 at 05:07:31PM +0000, Joakim Tjernlund wrote:
On Thu, 2016-07-28 at 09:57 +0200, Jakub Hrozek wrote:
On Wed, Jul 27, 2016 at 03:12:47PM +0000, Joakim Tjernlund wrote:
On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote:
On 27.7.2016 15:55, Joakim Tjernlund wrote:
We are migrating to a new domain AD domain and I got cross domain trust problems(there is a bidirectional cross trust between the two ADs, how can I test this works from Linux?). All users in domain A has been copied to domain B(using the same UID/GID as in domain A).
I have managed to configure sssd for both domains(lets call the old domain A and the new B), joined to both domains and I can login using any of the 2 domains.
But here is the problem: If I use the new domain(B) as default login domain, I cannot ssh to another system still in domain A password less(without entering my password again) or access files on NFS mounted files exported from domain A.
I know very little about cross trust etc. so I want to ask:
- Is this even possible?
- I have no idea where to start looking for what went wrong, need som pointers.
We are using sssd 1.13.4 on the new domain B machines while servers in domain A uses an older sssd(1.12.5)
The first step is to verify that system joined to domain B can get keys for domain A.
Log in to a system joined to domain B as some user from domain B. Then run this command: $ kvno host/<hostname of a system joined to a system in domain A>
It should print some number. If it prints an error use command $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> and see what went wrong. It would indicate a problem on Kerberos level.
This works for both myhost@A and myhost@B so I guess all is good.
If this works, looks at the target system (joined to domain A) and see its logs.
If you want to treat user1@domainA and user2@domainB as equal you might need to tweak Kerberos mapping from principals to local users, see https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... and edit krb5.conf to suit your needs.
In server@A or newhost@B ?
One thing that works though is ssh from server@A to newhost@B (no passwd needed) but ssh newhost@B to server@A fail(asks for passwd). I guess this could be because newhost@B is joined to both domains and sssd is configured for both domains ?
I'm not great at debugging these failures either, but normally I start by increasing the SSHD (not SSSD) debug level and looking at what failures I get from SSHD.
Off-bat, I would also check if the domain-realm mappings in /etc/krb5.conf look like, maybe the system has them configured only for one domain since one domain works?
Been a bit busy with other things but now a am back with full force again :)
It is starting to work but I need a /home/%user/.k5login for ssh to let me in without passwd :( How can I get rid of having a .k5login?
My krb5.conf looks like [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so }
[libdefaults] default_realm = A or B # A is the old domain and we are moving to B forwardable = yes allow_weak_crypto = true dns_lookup_realm = true dns_lookup_kdc = true
I think this should work. Is there any activity in the SSSD logs indicating a principal-to-name-lookup? Are there any errors in the SSHD logs?
Cannot find any obvious errors in SSSD logs, the best is the one from sshd: debug3: monitor_read: checking request 44 [5491] 1470316964.630401: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4-hmac/F186 [5491] 1470316964.630415: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4-hmac/1443 [5491] 1470316964.634375: Negotiated enctype based on authenticator: aes256-cts [5491] 1470316964.634385: Authenticator contains subkey: rc4-hmac/5816 [5491] 1470316964.634449: Resolving unique ccache of type MEMORY [5491] 1470316964.634462: Initializing MEMORY:DCuKq9v with default princ jocke@TRANSMODE.SE [5491] 1470316964.634468: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:DCuKq9v [5491] 1470316964.634506: Creating AP-REP, time 1470316964.627962, subkey aes256-cts/93B0, seqnum 394237360 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 [5491] 1470316964.646756: Destroying ccache MEMORY:DCuKq9v debug3: mm_answer_gss_userok: sending result 0 debug3: mm_request_send entering: type 47 Failed gssapi-with-mic for jocke from 172.20.4.10 port 50612 ssh2 debug3: mm_ssh_gssapi_userok: user not authenticated [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-with-mic,keyboard-interactive" [preauth]
Unless I have a .kr5login I get the above fail, could it be sssd_krb5_localauth_plugin.so not behaving?
Not sure what to do next? I was thinking to join all computer to both domains?
I also need to get NFS working over the cross realm, maybe some pointer where to start?
On Thu, 2016-08-04 at 15:31 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 10:41 +0200, Jakub Hrozek wrote:
On Wed, Aug 03, 2016 at 05:07:31PM +0000, Joakim Tjernlund wrote:
On Thu, 2016-07-28 at 09:57 +0200, Jakub Hrozek wrote:
On Wed, Jul 27, 2016 at 03:12:47PM +0000, Joakim Tjernlund wrote:
On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote:
On 27.7.2016 15:55, Joakim Tjernlund wrote: > > > > > We are migrating to a new domain AD domain and I got cross domain trust problems(there is a > bidirectional > cross trust between the two ADs, how can I test this works from Linux?). All users in domain A > has been copied to domain B(using the same UID/GID as in domain A). > > I have managed to configure sssd for both domains(lets call the old domain A and the new B), > joined to both domains and I can login using any of the 2 domains. > > But here is the problem: > If I use the new domain(B) as default login domain, I cannot ssh to another system still in > domain > A > password less(without entering my password again) or access files on NFS mounted files exported > from > domain A. > > I know very little about cross trust etc. so I want to ask: > 1) Is this even possible? > 2) I have no idea where to start looking for what went wrong, need som pointers. > > We are using sssd 1.13.4 on the new domain B machines while servers > in domain A uses an older sssd(1.12.5)
The first step is to verify that system joined to domain B can get keys for domain A.
Log in to a system joined to domain B as some user from domain B. Then run this command: $ kvno host/<hostname of a system joined to a system in domain A>
It should print some number. If it prints an error use command $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> and see what went wrong. It would indicate a problem on Kerberos level.
This works for both myhost@A and myhost@B so I guess all is good.
If this works, looks at the target system (joined to domain A) and see its logs.
If you want to treat user1@domainA and user2@domainB as equal you might need to tweak Kerberos mapping from principals to local users, see https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... and edit krb5.conf to suit your needs.
In server@A or newhost@B ?
One thing that works though is ssh from server@A to newhost@B (no passwd needed) but ssh newhost@B to server@A fail(asks for passwd). I guess this could be because newhost@B is joined to both domains and sssd is configured for both domains ?
I'm not great at debugging these failures either, but normally I start by increasing the SSHD (not SSSD) debug level and looking at what failures I get from SSHD.
Off-bat, I would also check if the domain-realm mappings in /etc/krb5.conf look like, maybe the system has them configured only for one domain since one domain works?
Been a bit busy with other things but now a am back with full force again :)
It is starting to work but I need a /home/%user/.k5login for ssh to let me in without passwd :( How can I get rid of having a .k5login?
My krb5.conf looks like [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so }
[libdefaults] default_realm = A or B # A is the old domain and we are moving to B forwardable = yes allow_weak_crypto = true dns_lookup_realm = true dns_lookup_kdc = true
I think this should work. Is there any activity in the SSSD logs indicating a principal-to-name-lookup? Are there any errors in the SSHD logs?
Cannot find any obvious errors in SSSD logs, the best is the one from sshd: debug3: monitor_read: checking request 44 [5491] 1470316964.630401: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4-hmac/F186 [5491] 1470316964.630415: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/1443 [5491] 1470316964.634375: Negotiated enctype based on authenticator: aes256-cts [5491] 1470316964.634385: Authenticator contains subkey: rc4-hmac/5816 [5491] 1470316964.634449: Resolving unique ccache of type MEMORY [5491] 1470316964.634462: Initializing MEMORY:DCuKq9v with default princ jocke@TRANSMODE.SE [5491] 1470316964.634468: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:DCuKq9v [5491] 1470316964.634506: Creating AP-REP, time 1470316964.627962, subkey aes256-cts/93B0, seqnum 394237360 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 [5491] 1470316964.646756: Destroying ccache MEMORY:DCuKq9v debug3: mm_answer_gss_userok: sending result 0 debug3: mm_request_send entering: type 47 Failed gssapi-with-mic for jocke from 172.20.4.10 port 50612 ssh2 debug3: mm_ssh_gssapi_userok: user not authenticated [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-with-mic,keyboard-interactive" [preauth]
if I change sssd.conf: domains = infinera.com to domains = infinera.com, transmode.se Then I can login without pw: [14695] 1470321279.525016: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4-hmac/F186 [14695] 1470321279.525032: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/E601 [14695] 1470321279.529550: Negotiated enctype based on authenticator: aes256-cts [14695] 1470321279.529581: Authenticator contains subkey: rc4-hmac/F46B [14695] 1470321279.529812: Resolving unique ccache of type MEMORY [14695] 1470321279.529864: Initializing MEMORY:oYIGWsB with default princ jocke@TRANSMODE.SE [14695] 1470321279.529893: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:oYIGWsB [14695] 1470321279.530022: Creating AP-REP, time 1470321279.523151, subkey aes256-cts/E60C, seqnum 895124245 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 Authorized to jocke, krb5 principal jocke@TRANSMODE.SE (krb5_kuserok) debug3: mm_answer_gss_userok: sending result 1
But this only works from old to new domain, ssh:ing from new to old domain does not work :(
Do I need something extra for cross realm to work in sssd.conf?: [sssd] config_file_version = 2 #domains = transmode.se,infinera.com domains = infinera.com, transmode.se #domains = infinera.com services = nss, pam debug_level=9 [nss] #filter_users = root fallback_homedir = /home/%u default_shell = /bin/bash debug_level=9
[pam] debug_level=9
[domain/transmode.se] debug_level=9 cache_credentials = true enumerate = true
id_provider = ldap auth_provider = krb5 chpass_provider = krb5 access_provider = ldap
case_sensitive = false
ldap_referrals = false ldap_sasl_mech = GSSAPI ldap_schema = rfc2307bis ldap_user_search_base = dc=transmode,dc=se ldap_user_object_class = user ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_group_search_base = dc=transmode,dc=se ldap_group_object_class = group ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true
krb5_realm = TRANSMODE.SE krb5_canonicalize = true krb5_store_password_if_offline = true krb5_use_kdcinfo = False
[domain/infinera.com] debug_level =0xffff cache_credentials = true #enumerate = true ldap_id_mapping = false
id_provider = ad auth_provider = krb5 chpass_provider = krb5 access_provider = ldap
case_sensitive = false
ldap_referrals = false ldap_sasl_mech = GSSAPI ldap_schema = rfc2307bis ldap_user_search_base = dc=infinera,dc=com ldap_user_object_class = user ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_user_name=sAMAccountName ldap_user_objectsid=objectSid ldap_user_fullname=displayName
ldap_group_search_base = dc=infinera,dc=com ldap_group_object_class = group ldap_group_name=name ldap_group_member=member
ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
krb5_realm = INFINERA.COM krb5_canonicalize = true krb5_store_password_if_offline = true krb5_use_kdcinfo = False
On Thu, 2016-08-04 at 16:50 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 15:31 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 10:41 +0200, Jakub Hrozek wrote:
On Wed, Aug 03, 2016 at 05:07:31PM +0000, Joakim Tjernlund wrote:
On Thu, 2016-07-28 at 09:57 +0200, Jakub Hrozek wrote:
On Wed, Jul 27, 2016 at 03:12:47PM +0000, Joakim Tjernlund wrote:
On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote: > > > > > On 27.7.2016 15:55, Joakim Tjernlund wrote: > > > > > > > > > > > > We are migrating to a new domain AD domain and I got cross domain trust problems(there is a > > bidirectional > > cross trust between the two ADs, how can I test this works from Linux?). All users in domain A > > has been copied to domain B(using the same UID/GID as in domain A). > > > > I have managed to configure sssd for both domains(lets call the old domain A and the new B), > > joined to both domains and I can login using any of the 2 domains. > > > > But here is the problem: > > If I use the new domain(B) as default login domain, I cannot ssh to another system still in > > domain > > A > > password less(without entering my password again) or access files on NFS mounted files > > exported > > from > > domain A. > > > > I know very little about cross trust etc. so I want to ask: > > 1) Is this even possible? > > 2) I have no idea where to start looking for what went wrong, need som pointers. > > > > We are using sssd 1.13.4 on the new domain B machines while servers > > in domain A uses an older sssd(1.12.5) > > The first step is to verify that system joined to domain B can get keys for > domain A. > > Log in to a system joined to domain B as some user from domain B. Then run > this command: > $ kvno host/<hostname of a system joined to a system in domain A> > > It should print some number. If it prints an error use command > $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> > and see what went wrong. It would indicate a problem on Kerberos level.
This works for both myhost@A and myhost@B so I guess all is good.
> > > > > > If this works, looks at the target system (joined to domain A) and see its logs. > > If you want to treat user1@domainA and user2@domainB as equal you might need > to tweak Kerberos mapping from principals to local users, see > https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... > and edit krb5.conf to suit your needs. >
In server@A or newhost@B ?
One thing that works though is ssh from server@A to newhost@B (no passwd needed) but ssh newhost@B to server@A fail(asks for passwd). I guess this could be because newhost@B is joined to both domains and sssd is configured for both domains ?
I'm not great at debugging these failures either, but normally I start by increasing the SSHD (not SSSD) debug level and looking at what failures I get from SSHD.
Off-bat, I would also check if the domain-realm mappings in /etc/krb5.conf look like, maybe the system has them configured only for one domain since one domain works?
Been a bit busy with other things but now a am back with full force again :)
It is starting to work but I need a /home/%user/.k5login for ssh to let me in without passwd :( How can I get rid of having a .k5login?
My krb5.conf looks like [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so }
[libdefaults] default_realm = A or B # A is the old domain and we are moving to B forwardable = yes allow_weak_crypto = true dns_lookup_realm = true dns_lookup_kdc = true
I think this should work. Is there any activity in the SSSD logs indicating a principal-to-name-lookup? Are there any errors in the SSHD logs?
Cannot find any obvious errors in SSSD logs, the best is the one from sshd: debug3: monitor_read: checking request 44 [5491] 1470316964.630401: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4- hmac/F186 [5491] 1470316964.630415: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/1443 [5491] 1470316964.634375: Negotiated enctype based on authenticator: aes256-cts [5491] 1470316964.634385: Authenticator contains subkey: rc4-hmac/5816 [5491] 1470316964.634449: Resolving unique ccache of type MEMORY [5491] 1470316964.634462: Initializing MEMORY:DCuKq9v with default princ jocke@TRANSMODE.SE [5491] 1470316964.634468: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:DCuKq9v [5491] 1470316964.634506: Creating AP-REP, time 1470316964.627962, subkey aes256-cts/93B0, seqnum 394237360 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 [5491] 1470316964.646756: Destroying ccache MEMORY:DCuKq9v debug3: mm_answer_gss_userok: sending result 0 debug3: mm_request_send entering: type 47 Failed gssapi-with-mic for jocke from 172.20.4.10 port 50612 ssh2 debug3: mm_ssh_gssapi_userok: user not authenticated [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-with-mic,keyboard-interactive" [preauth]
if I change sssd.conf: domains = infinera.com to domains = infinera.com, transmode.se Then I can login without pw: [14695] 1470321279.525016: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4-hmac/F186 [14695] 1470321279.525032: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/E601 [14695] 1470321279.529550: Negotiated enctype based on authenticator: aes256-cts [14695] 1470321279.529581: Authenticator contains subkey: rc4-hmac/F46B [14695] 1470321279.529812: Resolving unique ccache of type MEMORY [14695] 1470321279.529864: Initializing MEMORY:oYIGWsB with default princ jocke@TRANSMODE.SE [14695] 1470321279.529893: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:oYIGWsB [14695] 1470321279.530022: Creating AP-REP, time 1470321279.523151, subkey aes256-cts/E60C, seqnum 895124245 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 Authorized to jocke, krb5 principal jocke@TRANSMODE.SE (krb5_kuserok) debug3: mm_answer_gss_userok: sending result 1
But this only works from old to new domain, ssh:ing from new to old domain does not work :(
I hacked the localauth_login in ssd ad added some trace. It turn out the plugin does a _nss_sss_getpwnam_r("jocke@INFINERA.COM", ...) in a computer which is in TRANSMODE.SE this will come back with NSS_STATUS_NOTFOUND unless I have configured both domains in sssd.conf
Is TRANSMODE.SE supposed to pass on the lookup to INFINERA.COM automatically or not? Seems a little strange that we need to have both domains configure in every client
Jocke
On (04/08/16 17:04), Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 16:50 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 15:31 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 10:41 +0200, Jakub Hrozek wrote:
On Wed, Aug 03, 2016 at 05:07:31PM +0000, Joakim Tjernlund wrote:
On Thu, 2016-07-28 at 09:57 +0200, Jakub Hrozek wrote:
On Wed, Jul 27, 2016 at 03:12:47PM +0000, Joakim Tjernlund wrote: > > > > > On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote: > > > > > > > > > > On 27.7.2016 15:55, Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > We are migrating to a new domain AD domain and I got cross domain trust problems(there is a > > > bidirectional > > > cross trust between the two ADs, how can I test this works from Linux?). All users in domain A > > > has been copied to domain B(using the same UID/GID as in domain A). > > > > > > I have managed to configure sssd for both domains(lets call the old domain A and the new B), > > > joined to both domains and I can login using any of the 2 domains. > > > > > > But here is the problem: > > > If I use the new domain(B) as default login domain, I cannot ssh to another system still in > > > domain > > > A > > > password less(without entering my password again) or access files on NFS mounted files > > > exported > > > from > > > domain A. > > > > > > I know very little about cross trust etc. so I want to ask: > > > 1) Is this even possible? > > > 2) I have no idea where to start looking for what went wrong, need som pointers. > > > > > > We are using sssd 1.13.4 on the new domain B machines while servers > > > in domain A uses an older sssd(1.12.5) > > > > The first step is to verify that system joined to domain B can get keys for > > domain A. > > > > Log in to a system joined to domain B as some user from domain B. Then run > > this command: > > $ kvno host/<hostname of a system joined to a system in domain A> > > > > It should print some number. If it prints an error use command > > $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> > > and see what went wrong. It would indicate a problem on Kerberos level. > > This works for both myhost@A and myhost@B so I guess all is good. > > > > > > > > > > > > > If this works, looks at the target system (joined to domain A) and see its logs. > > > > If you want to treat user1@domainA and user2@domainB as equal you might need > > to tweak Kerberos mapping from principals to local users, see > > https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... > > and edit krb5.conf to suit your needs. > > > > In server@A or newhost@B ? > > One thing that works though is ssh from server@A to newhost@B (no passwd needed) but > ssh newhost@B to server@A fail(asks for passwd). > I guess this could be because newhost@B is joined to both domains and sssd is configured for both > domains ?
I'm not great at debugging these failures either, but normally I start by increasing the SSHD (not SSSD) debug level and looking at what failures I get from SSHD.
Off-bat, I would also check if the domain-realm mappings in /etc/krb5.conf look like, maybe the system has them configured only for one domain since one domain works?
Been a bit busy with other things but now a am back with full force again :)
It is starting to work but I need a /home/%user/.k5login for ssh to let me in without passwd :( How can I get rid of having a .k5login?
My krb5.conf looks like [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so }
[libdefaults] default_realm = A or B # A is the old domain and we are moving to B forwardable = yes allow_weak_crypto = true dns_lookup_realm = true dns_lookup_kdc = true
I think this should work. Is there any activity in the SSSD logs indicating a principal-to-name-lookup? Are there any errors in the SSHD logs?
Cannot find any obvious errors in SSSD logs, the best is the one from sshd: debug3: monitor_read: checking request 44 [5491] 1470316964.630401: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4- hmac/F186 [5491] 1470316964.630415: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/1443 [5491] 1470316964.634375: Negotiated enctype based on authenticator: aes256-cts [5491] 1470316964.634385: Authenticator contains subkey: rc4-hmac/5816 [5491] 1470316964.634449: Resolving unique ccache of type MEMORY [5491] 1470316964.634462: Initializing MEMORY:DCuKq9v with default princ jocke@TRANSMODE.SE [5491] 1470316964.634468: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:DCuKq9v [5491] 1470316964.634506: Creating AP-REP, time 1470316964.627962, subkey aes256-cts/93B0, seqnum 394237360 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 [5491] 1470316964.646756: Destroying ccache MEMORY:DCuKq9v debug3: mm_answer_gss_userok: sending result 0 debug3: mm_request_send entering: type 47 Failed gssapi-with-mic for jocke from 172.20.4.10 port 50612 ssh2 debug3: mm_ssh_gssapi_userok: user not authenticated [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-with-mic,keyboard-interactive" [preauth]
if I change sssd.conf: domains = infinera.com to domains = infinera.com, transmode.se Then I can login without pw: [14695] 1470321279.525016: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4-hmac/F186 [14695] 1470321279.525032: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/E601 [14695] 1470321279.529550: Negotiated enctype based on authenticator: aes256-cts [14695] 1470321279.529581: Authenticator contains subkey: rc4-hmac/F46B [14695] 1470321279.529812: Resolving unique ccache of type MEMORY [14695] 1470321279.529864: Initializing MEMORY:oYIGWsB with default princ jocke@TRANSMODE.SE [14695] 1470321279.529893: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:oYIGWsB [14695] 1470321279.530022: Creating AP-REP, time 1470321279.523151, subkey aes256-cts/E60C, seqnum 895124245 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 Authorized to jocke, krb5 principal jocke@TRANSMODE.SE (krb5_kuserok) debug3: mm_answer_gss_userok: sending result 1
But this only works from old to new domain, ssh:ing from new to old domain does not work :(
I hacked the localauth_login in ssd ad added some trace. It turn out the plugin does a _nss_sss_getpwnam_r("jocke@INFINERA.COM", ...) in a computer which is in TRANSMODE.SE this will come back with NSS_STATUS_NOTFOUND unless I have configured both domains in sssd.conf
Is TRANSMODE.SE supposed to pass on the lookup to INFINERA.COM automatically or not? Seems a little strange that we need to have both domains configure in every client
sssd cannot resolve users from trusted AD domain with id_provider = ldap and auth_provider = krb5.
Is there a reason why you cannot use id_provider ad?
LS
On Thu, 2016-08-04 at 19:51 +0200, Lukas Slebodnik wrote:
On (04/08/16 17:04), Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 16:50 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 15:31 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 10:41 +0200, Jakub Hrozek wrote:
On Wed, Aug 03, 2016 at 05:07:31PM +0000, Joakim Tjernlund wrote:
On Thu, 2016-07-28 at 09:57 +0200, Jakub Hrozek wrote: > > > > > On Wed, Jul 27, 2016 at 03:12:47PM +0000, Joakim Tjernlund wrote: > > > > > > > > > > > > On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote: > > > > > > > > > > > > > > > > > > On 27.7.2016 15:55, Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > We are migrating to a new domain AD domain and I got cross domain trust problems(there is > > > > a > > > > bidirectional > > > > cross trust between the two ADs, how can I test this works from Linux?). All users in > > > > domain A > > > > has been copied to domain B(using the same UID/GID as in domain A). > > > > > > > > I have managed to configure sssd for both domains(lets call the old domain A and the new > > > > B), > > > > joined to both domains and I can login using any of the 2 domains. > > > > > > > > But here is the problem: > > > > If I use the new domain(B) as default login domain, I cannot ssh to another system still > > > > in > > > > domain > > > > A > > > > password less(without entering my password again) or access files on NFS mounted files > > > > exported > > > > from > > > > domain A. > > > > > > > > I know very little about cross trust etc. so I want to ask: > > > > 1) Is this even possible? > > > > 2) I have no idea where to start looking for what went wrong, need som pointers. > > > > > > > > We are using sssd 1.13.4 on the new domain B machines while servers > > > > in domain A uses an older sssd(1.12.5) > > > > > > The first step is to verify that system joined to domain B can get keys for > > > domain A. > > > > > > Log in to a system joined to domain B as some user from domain B. Then run > > > this command: > > > $ kvno host/<hostname of a system joined to a system in domain A> > > > > > > It should print some number. If it prints an error use command > > > $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> > > > and see what went wrong. It would indicate a problem on Kerberos level. > > > > This works for both myhost@A and myhost@B so I guess all is good. > > > > > > > > > > > > > > > > > > > > > > > If this works, looks at the target system (joined to domain A) and see its logs. > > > > > > If you want to treat user1@domainA and user2@domainB as equal you might need > > > to tweak Kerberos mapping from principals to local users, see > > > https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... > > > ce > > > and edit krb5.conf to suit your needs. > > > > > > > In server@A or newhost@B ? > > > > One thing that works though is ssh from server@A to newhost@B (no passwd needed) but > > ssh newhost@B to server@A fail(asks for passwd). > > I guess this could be because newhost@B is joined to both domains and sssd is configured for > > both > > domains ? > > I'm not great at debugging these failures either, but normally I start > by increasing the SSHD (not SSSD) debug level and looking at what > failures I get from SSHD. > > Off-bat, I would also check if the domain-realm mappings in > /etc/krb5.conf look like, maybe the system has them configured only for > one domain since one domain works? >
Been a bit busy with other things but now a am back with full force again :)
It is starting to work but I need a /home/%user/.k5login for ssh to let me in without passwd :( How can I get rid of having a .k5login?
My krb5.conf looks like [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so }
[libdefaults] default_realm = A or B # A is the old domain and we are moving to B forwardable = yes allow_weak_crypto = true dns_lookup_realm = true dns_lookup_kdc = true
I think this should work. Is there any activity in the SSSD logs indicating a principal-to-name-lookup? Are there any errors in the SSHD logs?
Cannot find any obvious errors in SSSD logs, the best is the one from sshd: debug3: monitor_read: checking request 44 [5491] 1470316964.630401: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4- hmac/F186 [5491] 1470316964.630415: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/1443 [5491] 1470316964.634375: Negotiated enctype based on authenticator: aes256-cts [5491] 1470316964.634385: Authenticator contains subkey: rc4-hmac/5816 [5491] 1470316964.634449: Resolving unique ccache of type MEMORY [5491] 1470316964.634462: Initializing MEMORY:DCuKq9v with default princ jocke@TRANSMODE.SE [5491] 1470316964.634468: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:DCuKq9v [5491] 1470316964.634506: Creating AP-REP, time 1470316964.627962, subkey aes256-cts/93B0, seqnum 394237360 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 [5491] 1470316964.646756: Destroying ccache MEMORY:DCuKq9v debug3: mm_answer_gss_userok: sending result 0 debug3: mm_request_send entering: type 47 Failed gssapi-with-mic for jocke from 172.20.4.10 port 50612 ssh2 debug3: mm_ssh_gssapi_userok: user not authenticated [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-with-mic,keyboard- interactive" [preauth]
if I change sssd.conf: domains = infinera.com to domains = infinera.com, transmode.se Then I can login without pw: [14695] 1470321279.525016: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4- hmac/F186 [14695] 1470321279.525032: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/E601 [14695] 1470321279.529550: Negotiated enctype based on authenticator: aes256-cts [14695] 1470321279.529581: Authenticator contains subkey: rc4-hmac/F46B [14695] 1470321279.529812: Resolving unique ccache of type MEMORY [14695] 1470321279.529864: Initializing MEMORY:oYIGWsB with default princ jocke@TRANSMODE.SE [14695] 1470321279.529893: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:oYIGWsB [14695] 1470321279.530022: Creating AP-REP, time 1470321279.523151, subkey aes256-cts/E60C, seqnum 895124245 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 Authorized to jocke, krb5 principal jocke@TRANSMODE.SE (krb5_kuserok) debug3: mm_answer_gss_userok: sending result 1
But this only works from old to new domain, ssh:ing from new to old domain does not work :(
I hacked the localauth_login in ssd ad added some trace. It turn out the plugin does a _nss_sss_getpwnam_r("jocke@INFINERA.COM", ...) in a computer which is in TRANSMODE.SE this will come back with NSS_STATUS_NOTFOUND unless I have configured both domains in sssd.conf
Is TRANSMODE.SE supposed to pass on the lookup to INFINERA.COM automatically or not? Seems a little strange that we need to have both domains configure in every client
sssd cannot resolve users from trusted AD domain with id_provider = ldap and auth_provider = krb5.
Is there a reason why you cannot use id_provider ad?
That choise was made several years ago and I can't remember, I tried with id_provider = ad and sssd failed to start, don't know why ATM.
However INFINERA.COM has id_provider = ad already and it has the same problem, is there something more that needs to be adjusted?
On (04/08/16 19:02), Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 19:51 +0200, Lukas Slebodnik wrote:
On (04/08/16 17:04), Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 16:50 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 15:31 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 10:41 +0200, Jakub Hrozek wrote:
On Wed, Aug 03, 2016 at 05:07:31PM +0000, Joakim Tjernlund wrote: > > > > > On Thu, 2016-07-28 at 09:57 +0200, Jakub Hrozek wrote: > > > > > > > > > > On Wed, Jul 27, 2016 at 03:12:47PM +0000, Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 27.7.2016 15:55, Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We are migrating to a new domain AD domain and I got cross domain trust problems(there is > > > > > a > > > > > bidirectional > > > > > cross trust between the two ADs, how can I test this works from Linux?). All users in > > > > > domain A > > > > > has been copied to domain B(using the same UID/GID as in domain A). > > > > > > > > > > I have managed to configure sssd for both domains(lets call the old domain A and the new > > > > > B), > > > > > joined to both domains and I can login using any of the 2 domains. > > > > > > > > > > But here is the problem: > > > > > If I use the new domain(B) as default login domain, I cannot ssh to another system still > > > > > in > > > > > domain > > > > > A > > > > > password less(without entering my password again) or access files on NFS mounted files > > > > > exported > > > > > from > > > > > domain A. > > > > > > > > > > I know very little about cross trust etc. so I want to ask: > > > > > 1) Is this even possible? > > > > > 2) I have no idea where to start looking for what went wrong, need som pointers. > > > > > > > > > > We are using sssd 1.13.4 on the new domain B machines while servers > > > > > in domain A uses an older sssd(1.12.5) > > > > > > > > The first step is to verify that system joined to domain B can get keys for > > > > domain A. > > > > > > > > Log in to a system joined to domain B as some user from domain B. Then run > > > > this command: > > > > $ kvno host/<hostname of a system joined to a system in domain A> > > > > > > > > It should print some number. If it prints an error use command > > > > $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> > > > > and see what went wrong. It would indicate a problem on Kerberos level. > > > > > > This works for both myhost@A and myhost@B so I guess all is good. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If this works, looks at the target system (joined to domain A) and see its logs. > > > > > > > > If you want to treat user1@domainA and user2@domainB as equal you might need > > > > to tweak Kerberos mapping from principals to local users, see > > > > https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... > > > > ce > > > > and edit krb5.conf to suit your needs. > > > > > > > > > > In server@A or newhost@B ? > > > > > > One thing that works though is ssh from server@A to newhost@B (no passwd needed) but > > > ssh newhost@B to server@A fail(asks for passwd). > > > I guess this could be because newhost@B is joined to both domains and sssd is configured for > > > both > > > domains ? > > > > I'm not great at debugging these failures either, but normally I start > > by increasing the SSHD (not SSSD) debug level and looking at what > > failures I get from SSHD. > > > > Off-bat, I would also check if the domain-realm mappings in > > /etc/krb5.conf look like, maybe the system has them configured only for > > one domain since one domain works? > > > > Been a bit busy with other things but now a am back with full force again :) > > It is starting to work but I need a /home/%user/.k5login for ssh to let me in without passwd :( > How can I get rid of having a .k5login? > > My krb5.conf looks like > [plugins] > localauth = { > module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so > } > > [libdefaults] > default_realm = A or B # A is the old domain and we are moving to B > forwardable = yes > allow_weak_crypto = true > dns_lookup_realm = true > dns_lookup_kdc = true
I think this should work. Is there any activity in the SSSD logs indicating a principal-to-name-lookup? Are there any errors in the SSHD logs?
Cannot find any obvious errors in SSSD logs, the best is the one from sshd: debug3: monitor_read: checking request 44 [5491] 1470316964.630401: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4- hmac/F186 [5491] 1470316964.630415: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/1443 [5491] 1470316964.634375: Negotiated enctype based on authenticator: aes256-cts [5491] 1470316964.634385: Authenticator contains subkey: rc4-hmac/5816 [5491] 1470316964.634449: Resolving unique ccache of type MEMORY [5491] 1470316964.634462: Initializing MEMORY:DCuKq9v with default princ jocke@TRANSMODE.SE [5491] 1470316964.634468: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:DCuKq9v [5491] 1470316964.634506: Creating AP-REP, time 1470316964.627962, subkey aes256-cts/93B0, seqnum 394237360 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 [5491] 1470316964.646756: Destroying ccache MEMORY:DCuKq9v debug3: mm_answer_gss_userok: sending result 0 debug3: mm_request_send entering: type 47 Failed gssapi-with-mic for jocke from 172.20.4.10 port 50612 ssh2 debug3: mm_ssh_gssapi_userok: user not authenticated [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-with-mic,keyboard- interactive" [preauth]
if I change sssd.conf: domains = infinera.com to domains = infinera.com, transmode.se Then I can login without pw: [14695] 1470321279.525016: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4- hmac/F186 [14695] 1470321279.525032: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/E601 [14695] 1470321279.529550: Negotiated enctype based on authenticator: aes256-cts [14695] 1470321279.529581: Authenticator contains subkey: rc4-hmac/F46B [14695] 1470321279.529812: Resolving unique ccache of type MEMORY [14695] 1470321279.529864: Initializing MEMORY:oYIGWsB with default princ jocke@TRANSMODE.SE [14695] 1470321279.529893: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:oYIGWsB [14695] 1470321279.530022: Creating AP-REP, time 1470321279.523151, subkey aes256-cts/E60C, seqnum 895124245 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 Authorized to jocke, krb5 principal jocke@TRANSMODE.SE (krb5_kuserok) debug3: mm_answer_gss_userok: sending result 1
But this only works from old to new domain, ssh:ing from new to old domain does not work :(
I hacked the localauth_login in ssd ad added some trace. It turn out the plugin does a _nss_sss_getpwnam_r("jocke@INFINERA.COM", ...) in a computer which is in TRANSMODE.SE this will come back with NSS_STATUS_NOTFOUND unless I have configured both domains in sssd.conf
Is TRANSMODE.SE supposed to pass on the lookup to INFINERA.COM automatically or not? Seems a little strange that we need to have both domains configure in every client
sssd cannot resolve users from trusted AD domain with id_provider = ldap and auth_provider = krb5.
Is there a reason why you cannot use id_provider ad?
That choise was made several years ago and I can't remember, I tried with id_provider = ad and sssd failed to start, don't know why ATM.
However INFINERA.COM has id_provider = ad already and it has the same problem, is there something more that needs to be adjusted?
It's hard to say without more details. If you have right keytab + dnf is configured properly then it should be enough to use following configuration:
[domain/$AD_DOMAIN] id_provider = ad use_fully_qualified_names = True
Try to follow instructions on wiki https://fedorahosted.org/sssd/wiki/Troubleshooting
LS
That choise was made several years ago and I can't remember, I tried with id_provider = ad and sssd failed to start, don't know why ATM.
However INFINERA.COM has id_provider = ad already and it has the same problem, is there something more that needs to be adjusted?
It's hard to say without more details. If you have right keytab + dnf is configured properly then it should be enough to use following configuration:
[domain/$AD_DOMAIN] id_provider = ad use_fully_qualified_names = True
Any idea how do (cross) id lookups in Windows? I want to make sure the cross realm really works.
On Thu, 2016-08-04 at 21:27 +0200, Lukas Slebodnik wrote:
On (04/08/16 19:02), Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 19:51 +0200, Lukas Slebodnik wrote:
On (04/08/16 17:04), Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 16:50 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 15:31 +0200, Joakim Tjernlund wrote:
On Thu, 2016-08-04 at 10:41 +0200, Jakub Hrozek wrote: > > > > > On Wed, Aug 03, 2016 at 05:07:31PM +0000, Joakim Tjernlund wrote: > > > > > > > > > > > > On Thu, 2016-07-28 at 09:57 +0200, Jakub Hrozek wrote: > > > > > > > > > > > > > > > > > > On Wed, Jul 27, 2016 at 03:12:47PM +0000, Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2016-07-27 at 16:16 +0200, Petr Spacek wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 27.7.2016 15:55, Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We are migrating to a new domain AD domain and I got cross domain trust problems(there > > > > > > is > > > > > > a > > > > > > bidirectional > > > > > > cross trust between the two ADs, how can I test this works from Linux?). All users in > > > > > > domain A > > > > > > has been copied to domain B(using the same UID/GID as in domain A). > > > > > > > > > > > > I have managed to configure sssd for both domains(lets call the old domain A and the > > > > > > new > > > > > > B), > > > > > > joined to both domains and I can login using any of the 2 domains. > > > > > > > > > > > > But here is the problem: > > > > > > If I use the new domain(B) as default login domain, I cannot ssh to another system > > > > > > still > > > > > > in > > > > > > domain > > > > > > A > > > > > > password less(without entering my password again) or access files on NFS mounted files > > > > > > exported > > > > > > from > > > > > > domain A. > > > > > > > > > > > > I know very little about cross trust etc. so I want to ask: > > > > > > 1) Is this even possible? > > > > > > 2) I have no idea where to start looking for what went wrong, need som pointers. > > > > > > > > > > > > We are using sssd 1.13.4 on the new domain B machines while servers > > > > > > in domain A uses an older sssd(1.12.5) > > > > > > > > > > The first step is to verify that system joined to domain B can get keys for > > > > > domain A. > > > > > > > > > > Log in to a system joined to domain B as some user from domain B. Then run > > > > > this command: > > > > > $ kvno host/<hostname of a system joined to a system in domain A> > > > > > > > > > > It should print some number. If it prints an error use command > > > > > $ KRB5_TRACE=/dev/stdout kvno host/<the same hostname> > > > > > and see what went wrong. It would indicate a problem on Kerberos level. > > > > > > > > This works for both myhost@A and myhost@B so I guess all is good. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If this works, looks at the target system (joined to domain A) and see its logs. > > > > > > > > > > If you want to treat user1@domainA and user2@domainB as equal you might need > > > > > to tweak Kerberos mapping from principals to local users, see > > > > > https://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html#l... > > > > > erfa > > > > > ce > > > > > and edit krb5.conf to suit your needs. > > > > > > > > > > > > > In server@A or newhost@B ? > > > > > > > > One thing that works though is ssh from server@A to newhost@B (no passwd needed) but > > > > ssh newhost@B to server@A fail(asks for passwd). > > > > I guess this could be because newhost@B is joined to both domains and sssd is configured > > > > for > > > > both > > > > domains ? > > > > > > I'm not great at debugging these failures either, but normally I start > > > by increasing the SSHD (not SSSD) debug level and looking at what > > > failures I get from SSHD. > > > > > > Off-bat, I would also check if the domain-realm mappings in > > > /etc/krb5.conf look like, maybe the system has them configured only for > > > one domain since one domain works? > > > > > > > Been a bit busy with other things but now a am back with full force again :) > > > > It is starting to work but I need a /home/%user/.k5login for ssh to let me in without passwd > > :( > > How can I get rid of having a .k5login? > > > > My krb5.conf looks like > > [plugins] > > localauth = { > > module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so > > } > > > > [libdefaults] > > default_realm = A or B # A is the old domain and we are moving to B > > forwardable = yes > > allow_weak_crypto = true > > dns_lookup_realm = true > > dns_lookup_kdc = true > > I think this should work. Is there any activity in the SSSD logs > indicating a principal-to-name-lookup? Are there any errors in the SSHD > logs? >
Cannot find any obvious errors in SSSD logs, the best is the one from sshd: debug3: monitor_read: checking request 44 [5491] 1470316964.630401: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4- hmac/F186 [5491] 1470316964.630415: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/1443 [5491] 1470316964.634375: Negotiated enctype based on authenticator: aes256-cts [5491] 1470316964.634385: Authenticator contains subkey: rc4-hmac/5816 [5491] 1470316964.634449: Resolving unique ccache of type MEMORY [5491] 1470316964.634462: Initializing MEMORY:DCuKq9v with default princ jocke@TRANSMODE.SE [5491] 1470316964.634468: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:DCuKq9v [5491] 1470316964.634506: Creating AP-REP, time 1470316964.627962, subkey aes256-cts/93B0, seqnum 394237360 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 [5491] 1470316964.646756: Destroying ccache MEMORY:DCuKq9v debug3: mm_answer_gss_userok: sending result 0 debug3: mm_request_send entering: type 47 Failed gssapi-with-mic for jocke from 172.20.4.10 port 50612 ssh2 debug3: mm_ssh_gssapi_userok: user not authenticated [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-with-mic,keyboard- interactive" [preauth]
if I change sssd.conf: domains = infinera.com to domains = infinera.com, transmode.se Then I can login without pw: [14695] 1470321279.525016: Decrypted AP-REQ with server principal GENTOO-LABBBB$@INFINERA.COM: rc4- hmac/F186 [14695] 1470321279.525032: AP-REQ ticket: jocke@TRANSMODE.SE -> GENTOO-LABBBB$@INFINERA.COM, session key rc4- hmac/E601 [14695] 1470321279.529550: Negotiated enctype based on authenticator: aes256-cts [14695] 1470321279.529581: Authenticator contains subkey: rc4-hmac/F46B [14695] 1470321279.529812: Resolving unique ccache of type MEMORY [14695] 1470321279.529864: Initializing MEMORY:oYIGWsB with default princ jocke@TRANSMODE.SE [14695] 1470321279.529893: Storing jocke@TRANSMODE.SE -> krbtgt/TRANSMODE.SE@TRANSMODE.SE in MEMORY:oYIGWsB [14695] 1470321279.530022: Creating AP-REP, time 1470321279.523151, subkey aes256-cts/E60C, seqnum 895124245 debug1: Received some client credentials debug3: mm_request_send entering: type 45 debug3: send packet: type 61 [preauth] debug3: receive packet: type 66 [preauth] debug3: mm_request_send entering: type 48 [preauth] debug3: mm_request_receive_expect entering: type 49 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 48 debug3: mm_request_send entering: type 49 debug3: mm_request_send entering: type 46 [preauth] debug3: mm_request_receive_expect entering: type 47 [preauth] debug3: mm_request_receive entering [preauth] debug3: mm_request_receive entering debug3: monitor_read: checking request 46 Authorized to jocke, krb5 principal jocke@TRANSMODE.SE (krb5_kuserok) debug3: mm_answer_gss_userok: sending result 1
But this only works from old to new domain, ssh:ing from new to old domain does not work :(
I hacked the localauth_login in ssd ad added some trace. It turn out the plugin does a _nss_sss_getpwnam_r("jocke@INFINERA.COM", ...) in a computer which is in TRANSMODE.SE this will come back with NSS_STATUS_NOTFOUND unless I have configured both domains in sssd.conf
Is TRANSMODE.SE supposed to pass on the lookup to INFINERA.COM automatically or not? Seems a little strange that we need to have both domains configure in every client
sssd cannot resolve users from trusted AD domain with id_provider = ldap and auth_provider = krb5.
Is there a reason why you cannot use id_provider ad?
That choise was made several years ago and I can't remember, I tried with id_provider = ad and sssd failed to start, don't know why ATM.
However INFINERA.COM has id_provider = ad already and it has the same problem, is there something more that needs to be adjusted?
It's hard to say without more details. If you have right keytab + dnf is configured properly then it should be enough to use following configuration:
[domain/$AD_DOMAIN] id_provider = ad use_fully_qualified_names = True
Why the fully_qualified_names? It cause id and to report user@domain and also forces me to use the full domain name at login.
I managed to switch both domains to id_provider = ad but still I cannot do id lookup in the other domain. There is only one way I can do that and that this:
join the machine to both domains and configure both domains in sssd.conf
It is as if sssd does not understand that there is a cross trust and always tries to contact the other domain directly which will fail if I don't have both domains configured.
Jocke
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Joakim Tjernlund -
Lukas Slebodnik -
Petr Spacek