Heimdal upgrade from 0.7

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Heimdal upgrade from 0.7

Kostas Liakakis
Hello,

We have a really old realm based on Heimdal 0.7.2 we need to upgrade.

So I setup a new vm with Ubuntu 14.01 LTS, which installed heimdal-kdc
1.6~git20131207+dfsg-1ubuntu1 (kinit --version says 1.6.99), made it a
slave, pulled the database off the master and pointed some clients at it.

Unix clients and services have no problem authenticating. Windows XP,
unfortunately has :(

Our Windows AD realm is serviced by Windows2003 server and there is a
one-way trust with our Heimdal realm: Windows trust Heimdal. This setup
has been working for years now with Heimdal realm users mapped to
Windows users, so one could logon on Windows with their Heimdal
principal. This eliminated the need to keep a password updated in the AD
side.

When pointed to the upgraded 1.6.x KDC though, any WinXP client fails to
logon Heimdal users. On the Windows side there is the standard "The
system could not log you on. Make sure your User name and domain are
correct..." etc. etc. message. The audit log contains:

Logon Failure:
      Reason:        Unknown user name or bad password
      User Name:    kostas
      Domain:        PHYSICS.AUTH.GR
      Logon Type:    10
      Logon Process:    User32
      Authentication Package:    Negotiate
      Workstation Name:    PCLAB05

The heimdal-kdc logs:
2014-10-21T15:45:22 AS-REQ [hidden email] from
IPv4:10.207.123.14 for krbtgt/[hidden email]
2014-10-21T15:45:22 Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ
2014-10-21T15:45:22 sending 347 bytes to IPv4:10.207.123.14
2014-10-21T15:45:22 AS-REQ [hidden email] from
IPv4:10.207.123.14 for krbtgt/[hidden email]
2014-10-21T15:45:22 Client sent patypes: ENC-TS
2014-10-21T15:45:22 Looking for PK-INIT(ietf) pa-data --
[hidden email]
2014-10-21T15:45:22 Looking for PK-INIT(win2k) pa-data --
[hidden email]
2014-10-21T15:45:22 Looking for ENC-TS pa-data -- [hidden email]
2014-10-21T15:45:22 ENC-TS Pre-authentication succeeded --
[hidden email] using arcfour-hmac-md5
2014-10-21T15:45:22 ENC-TS pre-authentication succeeded --
[hidden email]
2014-10-21T15:45:22 AS-REQ authtime: 2014-10-21T15:45:22 starttime:
unset endtime: 2014-10-22T15:45:22 renew till: 2014-10-28T14:45:22
2014-10-21T15:45:22 Client supported enctypes: arcfour-hmac-md5, using
arcfour-hmac-md5/des3-cbc-sha1
2014-10-21T15:45:22 Requested flags: renewable-ok, renewable, forwardable
2014-10-21T15:45:22 sending 686 bytes to IPv4:10.207.123.14
2014-10-21T15:45:22 TGS-REQ [hidden email] from
IPv4:10.207.123.14 for krbtgt/[hidden email]
[renewable, forwardable]
2014-10-21T15:45:22 TGS-REQ authtime: 2014-10-21T15:45:22 starttime:
2014-10-21T15:45:22 endtime: 2014-10-22T15:45:22 renew till:
2014-10-28T14:45:22
2014-10-21T15:45:22 sending 616 bytes to IPv4:10.207.123.14

The only suspicious thing I am seeing is the des3-cbc-sha1 part in
client supported enctypes.
The principal I am trying to authenticate with is this:
kadmin> list -l kostas
             Principal: [hidden email]
                 [...]
         Last modified: 2014-10-21 09:51:43 UTC
              Modifier: kadmin/[hidden email]
            Attributes:
              Keytypes: des-cbc-md4(pw-salt()), des-cbc-crc(pw-salt()),
des-cbc-md4(pw-salt), des-cbc-crc(pw-salt),
aes256-cts-hmac-sha1-96(pw-salt), arcfour-hmac-md5(pw-salt)

Where I intentionally deleted all the des3 enctypes recalling that
neither WinXP nor Win2003 supported them, although authenticating
against 0.7.2 has no trouble even with these present.

The trust is using this key...
kadmin> list -l krbtgt/PCLAB2K3.PHYSICS.AUTH.GR
             Principal: krbtgt/[hidden email]
                [...]
         Last modified: 2007-02-16 10:07:15 UTC
              Modifier: admin/[hidden email]
            Attributes:
              Keytypes: des-cbc-md5(pw-salt()), des-cbc-md4(pw-salt()),
des-cbc-crc(pw-salt()), des3-cbc-sha1(pw-salt), des-cbc-md5(pw-salt),
des-cbc-md4(pw-salt), des-cbc-crc(pw-salt)

Network ID Manager which is installed on WinXP clients to support AFS,
if one logs in the AD realm instead, has no trouble getting tickets for
the above principal off the new 1.6.x KDC and using them to get AFS
tokens. Network Manager requests different enctypes though...


So, anybody has a hint on what am I missing with the new Heimdal? It has
been years since I had to deal with this kind of stuff and Google hasn't
been particularly helpful on the topic...

Thanks in advnace,

-Kostas





smime.p7s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal upgrade from 0.7

Harald Barth-2

> The trust is using this key...
> kadmin> list -l krbtgt/PCLAB2K3.PHYSICS.AUTH.GR
>             Principal: krbtgt/[hidden email]
>                [...]
>         Last modified: 2007-02-16 10:07:15 UTC
>              Modifier: admin/[hidden email]
>            Attributes:
>              Keytypes: des-cbc-md5(pw-salt()), des-cbc-md4(pw-salt()),
>              des-cbc-crc(pw-salt()), des3-cbc-sha1(pw-salt), des-cbc-md5(pw-salt),
>              des-cbc-md4(pw-salt), des-cbc-crc(pw-salt)

des-* and des3-* from 2007?

I think you want a newer key and newer enctypes (aes-* and arcfour-*).

Harald.
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal upgrade from 0.7

Kostas Liakakis
On 10/23/2014 11:32 AM, Harald Barth wrote:
> des-* and des3-* from 2007?
>
> I think you want a newer key and newer enctypes (aes-* and arcfour-*).
>

I said it is an old realm :) However, with this this key in place,
cross-realm authentication between our AD (Windows XP and Windows 2003
Server) and Heimdal realms (if the KDC is version 0.7.2) is working just
fine.

So you are suggesting that if I recreate the trust key to add newer
enctypes, cross-realm authentication on Windows XP clients will start
working against 1.6.x KDCs ?

Thank you for your help,

-Kostas


smime.p7s (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal upgrade from 0.7

Harald Barth-2

> So you are suggesting that if I recreate the trust key to add newer
> enctypes, cross-realm authentication on Windows XP clients will start
> working against 1.6.x KDCs ?

What is your setting of allow_weak_crypto? If the current trust uses one
of the weak cryptos and these are by default disabled in 1.6, that would
be the cause. You could test setting up a TEST.REALM and setting up a new
trust to that one from your AD (with new keys) and if that works then you
probably have found the cause.

Harald.
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal upgrade from 0.7

Kostas Liakakis-2

If 1.6 KDC disables weak cryptos, that would explain a lot...
allow_weak_crypto is 'yes' in [libdefaults] section of krb5.conf but that shouldn't affect the KDC itself right?

I believe we did use weak cryptos because Windows XP default login window (and probably 2003 AD) wouldn't handle anything else reliably at the time we put this scheme to work. I don't think this situation has ever changed till now.

How would one go to re-enable the KDC to send out keys containing week cryptos? Will it require recompilng?

-K.

On 10/23/2014 02:54 PM, Harald Barth wrote:
So you are suggesting that if I recreate the trust key to add newer
enctypes, cross-realm authentication on Windows XP clients will start
working against 1.6.x KDCs ?
What is your setting of allow_weak_crypto? If the current trust uses one
of the weak cryptos and these are by default disabled in 1.6, that would
be the cause. You could test setting up a TEST.REALM and setting up a new
trust to that one from your AD (with new keys) and if that works then you
probably have found the cause.

Harald.



Reply | Threaded
Open this post in threaded view
|

Re: Heimdal upgrade from 0.7

Jeffrey Altman-2
On 10/23/2014 8:16 AM, Kostas Liakakis wrote:
>
> If 1.6 KDC disables weak cryptos, that would explain a lot...

The 1.6 KDC disables weak crypto for all but AFS.

My understanding is that the release of Heimdal after 1.6 (like OSX
Yosemite which was released last week) is going to remove single DES
permanently.

Kerberos DES tickets are extremely vulnerable to brute force attacks on
public cloud services.   For approximately US$20 anyone with access to a
Kerberos service ticket that is encrypted with single DES can obtain the
service's long term key and forge tickets to that service.  If a
cross-realm TGT is encrypted with single DES, then a cross-realm TGT can
be forged permitting the attacker access as any identity to the trusting
realm.

Single DES tickets in Kerberos are no longer safe to use.  Please expend
your energy replacing your single DES keys.

Jeffrey Altman


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal upgrade from 0.7

Kostas Liakakis-2
In reply to this post by Kostas Liakakis

Harald, Jeffrey,

Thank you for your insight. I did as you suggested, but unfortunatelly,
this doesn't seem to be enough.

I setup a stand alone KDC, initialized TEST.COM and added a one-way
trust between the AD and TEST.COM. I also added a [hidden email]
principal and added a mapping to my AD account.

The generated keys have only rc4, des3 and aes256 enctypes. This is the
trust key for example:

              Principal: krbtgt/[hidden email]
      Principal expires: never
       Password expires: never
   Last password change: 2014-10-24 18:26:45 UTC
        Max ticket life: 1 day
     Max renewable life: 1 week
                   Kvno: 1
                  Mkvno: unknown
Last successful login: never
      Last failed login: never
     Failed login count: 0
          Last modified: 2014-10-24 18:26:45 UTC
               Modifier: kadmin/[hidden email]
             Attributes:
               Keytypes: aes256-cts-hmac-sha1-96(pw-salt)[1],
des3-cbc-sha1(pw-salt)[1], arcfour-hmac-md5(pw-salt)[1]
            PK-INIT ACL:

And this is the Heimdal log while the WinXP client is trying to
authenticate [hidden email] :

2014-10-24T21:27:32 AS-REQ [hidden email] from IPv4:10.207.123.14 for
krbtgt/[hidden email]
2014-10-24T21:27:32 Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ
2014-10-24T21:27:32 sending 316 bytes to IPv4:10.207.123.14
2014-10-24T21:27:32 AS-REQ [hidden email] from IPv4:10.207.123.14 for
krbtgt/[hidden email]
2014-10-24T21:27:32 Client sent patypes: ENC-TS
2014-10-24T21:27:32 Looking for PK-INIT(ietf) pa-data -- [hidden email]
2014-10-24T21:27:32 Looking for PK-INIT(win2k) pa-data -- [hidden email]
2014-10-24T21:27:32 Looking for ENC-TS pa-data -- [hidden email]
2014-10-24T21:27:32 ENC-TS Pre-authentication succeeded --
[hidden email] using arcfour-hmac-md5
2014-10-24T21:27:32 ENC-TS pre-authentication succeeded -- [hidden email]
2014-10-24T21:27:32 AS-REQ authtime: 2014-10-24T21:27:32 starttime:
unset endtime: 2014-10-25T21:27:32 renew till: 2014-10-31T20:27:32
2014-10-24T21:27:32 Client supported enctypes: arcfour-hmac-md5, using
arcfour-hmac-md5/aes256-cts-hmac-sha1-96
2014-10-24T21:27:32 Requested flags: renewable-ok, renewable, forwardable
2014-10-24T21:27:32 sending 634 bytes to IPv4:10.207.123.14
2014-10-24T21:27:32 TGS-REQ [hidden email] from IPv4:10.207.123.14 for
krbtgt/[hidden email] [renewable, forwardable]
2014-10-24T21:27:32 TGS-REQ authtime: 2014-10-24T21:27:32 starttime:
2014-10-24T21:27:32 endtime: 2014-10-25T21:27:32 renew till:
2014-10-31T20:27:32
2014-10-24T21:27:32 sending 606 bytes to IPv4:10.207.123.14


Same thing happens when trying to authenticate on the Win2003 AD server.
So this is not pertinent to XP...

2014-10-24T21:29:39 AS-REQ [hidden email] from IPv4:10.207.123.112 for
krbtgt/[hidden email]
2014-10-24T21:29:39 Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ
2014-10-24T21:29:39 sending 317 bytes to IPv4:10.207.123.112
2014-10-24T21:29:39 AS-REQ [hidden email] from IPv4:10.207.123.112 for
krbtgt/[hidden email]
2014-10-24T21:29:39 Client sent patypes: ENC-TS
2014-10-24T21:29:39 Looking for PK-INIT(ietf) pa-data -- [hidden email]
2014-10-24T21:29:39 Looking for PK-INIT(win2k) pa-data -- [hidden email]
2014-10-24T21:29:39 Looking for ENC-TS pa-data -- [hidden email]
2014-10-24T21:29:39 ENC-TS Pre-authentication succeeded --
[hidden email] using arcfour-hmac-md5
2014-10-24T21:29:39 ENC-TS pre-authentication succeeded -- [hidden email]
2014-10-24T21:29:39 AS-REQ authtime: 2014-10-24T21:29:39 starttime:
unset endtime: 2014-10-25T21:29:39 renew till: 2014-10-31T20:29:39
2014-10-24T21:29:39 Client supported enctypes: arcfour-hmac-md5, using
arcfour-hmac-md5/aes256-cts-hmac-sha1-96
2014-10-24T21:29:39 Requested flags: renewable-ok, renewable, forwardable
2014-10-24T21:29:39 sending 634 bytes to IPv4:10.207.123.112
2014-10-24T21:29:39 TGS-REQ [hidden email] from IPv4:10.207.123.112 for
krbtgt/[hidden email] [renewable, forwardable]
2014-10-24T21:29:39 TGS-REQ authtime: 2014-10-24T21:29:39 starttime:
2014-10-24T21:29:39 endtime: 2014-10-25T21:29:39 renew till:
2014-10-31T20:29:39
2014-10-24T21:29:39 sending 606 bytes to IPv4:10.207.123.112

I was also bold enough to recreate the trust key between AD and my
production realm. I did this on the master Heimdal 0.7.2 KDC, the change
propagated to a new slave KDC running version 1.6 and a WinXP client was
pointed to use that slave specifically. Again, the same behaviour:

2014-10-24T21:15:01 AS-REQ [hidden email] from
IPv4:10.207.123.14 for krbtgt/[hidden email]
2014-10-24T21:15:01 Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ
2014-10-24T21:15:01 sending 347 bytes to IPv4:10.207.123.14
2014-10-24T21:15:01 AS-REQ [hidden email] from
IPv4:10.207.123.14 for krbtgt/[hidden email]
2014-10-24T21:15:01 Client sent patypes: ENC-TS
2014-10-24T21:15:01 Looking for PK-INIT(ietf) pa-data --
[hidden email]
2014-10-24T21:15:01 Looking for PK-INIT(win2k) pa-data --
[hidden email]
2014-10-24T21:15:01 Looking for ENC-TS pa-data -- [hidden email]
2014-10-24T21:15:01 ENC-TS Pre-authentication succeeded --
[hidden email] using arcfour-hmac-md5
2014-10-24T21:15:01 ENC-TS pre-authentication succeeded --
[hidden email]
2014-10-24T21:15:01 AS-REQ authtime: 2014-10-24T21:15:01 starttime:
unset endtime: 2014-10-25T21:15:01 renew till: 2014-10-31T20:15:01
2014-10-24T21:15:01 Client supported enctypes: arcfour-hmac-md5, using
arcfour-hmac-md5/des3-cbc-sha1
2014-10-24T21:15:01 Requested flags: renewable-ok, renewable, forwardable
2014-10-24T21:15:01 sending 686 bytes to IPv4:10.207.123.14
2014-10-24T21:15:01 TGS-REQ [hidden email] from
IPv4:10.207.123.14 for krbtgt/[hidden email]
[renewable, forwardable]
2014-10-24T21:15:01 TGS-REQ authtime: 2014-10-24T21:15:01 starttime:
2014-10-24T21:15:01 endtime: 2014-10-25T21:15:01 renew till:
2014-10-31T20:15:01
2014-10-24T21:15:01 sending 626 bytes to IPv4:10.207.123.14

The message from the Windows side is like before, the standard "The
system could not log you on. Make sure your User name and domain are
correct..." etc. etc. message. Security log again contains the same
entry like before:

Logon Failure:
       Reason:        Unknown user name or bad password
       User Name:    kostas
       Domain:        PHYSICS.AUTH.GR
       Logon Type:    10
       Logon Process:    User32
       Authentication Package:    Negotiate
       Workstation Name:    PCLAB05


Point the same WinXP client to a 0.7 KDC and authentication works, the
user can login.

What else is there to do?

Thank you for taking the time to read all this,

-K.

On 10/23/2014 02:54 PM, Harald Barth wrote:

>> So you are suggesting that if I recreate the trust key to add newer
>> enctypes, cross-realm authentication on Windows XP clients will start
>> working against 1.6.x KDCs ?
> What is your setting of allow_weak_crypto? If the current trust uses one
> of the weak cryptos and these are by default disabled in 1.6, that would
> be the cause. You could test setting up a TEST.REALM and setting up a new
> trust to that one from your AD (with new keys) and if that works then you
> probably have found the cause.
>
> Harald.
>




Reply | Threaded
Open this post in threaded view
|

Re: Heimdal upgrade from 0.7

Kostas Liakakis-2

On 10/24/2014 10:03 PM, Kostas Liakakis wrote:
> What else is there to do?
>

Following up myself, the next thing to do was try MIT KDC for TEST.COM.
MIT (1.12-some letters) failed as well, much in the same manner.

And the next to deleted all the enctypes from the trust key (des, des3,
aes) BUT the rc4-hmac one.
And that did it! It worked!!! For both MIT and Heimdal KDCs, it was
required for the trust key to only contain a single enctype, the
rc4-hmac one in order to be accepted by Windows 2003 AD.

But... why should this be necessary?

Anyhow, I am happy with the result :)
If you people consider the above a quirk of Win2003 AD that should be
taken care of, I'd be happy to help you investigate further.

Thanks again for your time you devoted to look into my case,

-Kostas