> > I configured the following in krb5.conf and now at least get prompted
> > for a password and kinit works!:
> >   [libdefaults]
> > dns_lookup_kdc   = no
> > dns_lookup_realm = no
> >
> > klist
> > Ticket cache: API:krb5cc
> > Default principal: [email protected] <mailto:[email protected]>
> >
> > Valid starting     Expires            Service principal
> > 03/18/21 15:17:43  03/19/21 15:17:39  krbtgt/[email protected]
> > <mailto:[email protected]>
>
> I don't know why mac/Windows isn't working. It doesn't look like it is
> even trying GSSAPI.
>

Some progress. On Windows if I download and install MIT Kerberos and log in
with a user, I can use Putty for password-less login. Note Putty needs to
be a recent version, e.g.,  0.74.

I also got a Mac client to work. After adding the krb5.conf file into
/etc/krb5.conf, and running kinit I can run ssh -K and voila.

Using another Windows SSH client, e.g., MobaXterm (version 20 or later with
GSSAPI Kerberos checked in SSH settings), I also had to fill in the Domain:
field and use the "Native Windows" option:
[image: image.png]

However when testing, the various kinit attempts from a client generates
the below tickets that appear to be expired.
klist
Ticket cache: KCM:0:59081
Default principal: host/[email protected]

Valid starting     Expires            Service principal
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:
12/31/69 19:00:00  12/31/69 19:00:00  Encrypted/Credentials/v1@X-GSSPROXY:

We are on freeipa-server-4.9.2-4.fc33.x86_64 with kernel-5.11.11-200
ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

The logs that I see related to this user in krb5.conf, with debug enabled
are:
Apr 07 14:03:39 ourdomain.edu krb5kdc[1350528](info): AS_REQ (8 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23),
camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 150.108.68.55: ISSUE:
authtime 1617818619, etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
[email protected] for rbtgt/[email protected]

Apr 07 14:03:39 ourdomain.edu krb5kdc[1350528](info): closing down fd 11

Apr 07 14:03:44 ourdomain.edu krb5kdc[1350531](info): TGS_REQ (8 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23),
camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 150.108.68.55: ISSUE:
authtime 1617818619, etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
[email protected] for host/[email protected]

Apr 07 14:03:44 ourdomain.edu krb5kdc[1350531](info): closing down fd 11

Apr 07 14:03:44 ourdomain.edu krb5kdc[1350531](info): TGS_REQ (1 etypes
{aes256-cts-hmac-sha1-96(18)}) 150.108.68.55: ISSUE: authtime 1617818619,
etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
ses=aes256-cts-hmac-sha1-96(18)}, [email protected] for
krbtgt/[email protected]

So what causes those "expired" tickets? These "clients" I'm testing are a
Windows desktop and a Mac, so their hostnames aren't added a la a
freeipa-client.
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to