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.htm...
> > > > > 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$(a)INFINERA.COM: rc4-hmac/F186
[5491] 1470316964.630415: AP-REQ ticket: jocke(a)TRANSMODE.SE ->
GENTOO-LABBBB$(a)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(a)TRANSMODE.SE
[5491] 1470316964.634468: Storing jocke(a)TRANSMODE.SE ->
krbtgt/TRANSMODE.SE(a)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$(a)INFINERA.COM: rc4-hmac/F186
[14695] 1470321279.525032: AP-REQ ticket: jocke(a)TRANSMODE.SE ->
GENTOO-LABBBB$(a)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(a)TRANSMODE.SE
[14695] 1470321279.529893: Storing jocke(a)TRANSMODE.SE ->
krbtgt/TRANSMODE.SE(a)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(a)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