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.htm...
> > > > > > > > > > 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$(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 :(
> > >
> >
> > > I hacked the localauth_login in ssd ad added
some trace. It turn out the
> > > plugin does a _nss_sss_getpwnam_r("jocke(a)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