Solaris 10 & Windows 2008R2 KDC's

Douglas E. Engert deengert at
Wed Nov 14 11:42:38 EST 2012

On 11/14/2012 9:26 AM, Anders Holm wrote:
> Hi.
> I am facing issues with kerberos authentication after the Windows team
> here have upgraded to Win 2k8r2 AD's. There's still Win 2k3 AD's,
> running KDC's as well.  We're running a mix of RedHat, Oracle Enterprise
> Linux (OEL) and Solaris. All Linux hosts authenticate happily against
> either of the Windows Platforms. Solaris however I am facing some
> problems with.
> What I see is that, on both Linux and Solaris, TXT SRV records are
> preferred over hard coded configuration done in krb5.conf. As such, that
> means a client can hit *either* a 2k3 or 2k8 Windows KDC.To make
> matters slightly more interesting, Win 2k8 KDC's have defaulted to not
> use the DES encryption we have used for some time here. In itself, not a
> major issue.
> However, responses back from the Windows KDC's are now having the
> Solaris clients running into problems.
> First off, there's seemingly KDC's that simply do not like the
> encryption types we have defined:

The main difference is AES support was added in 2k8.
Both support RC4-hmac. (There may be a hot fix to w2k3 too.)

Some Oracle/Solaris/Java systems may support AES-128 but not
AES-256 for export reasons. You will need to install the domestic
versions that do support AES-256.
  "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7"
> default_tkt_enctypes = rc4-hmac aes256-cts-hmac-sha1-96
> aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5
> default_tgs_enctypes = rc4-hmac aes256-cts-hmac-sha1-96
> aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5

The defaults should work.
> rc4-hmac is supposedly supported and available on all KDC's
> (nevertheless seemingly not always used, as I'm seeing enctypes errors
> and failures)

rc4-hmac is supported on all.

> Leading to the client retrying the request with $random_kdc_for_domain
> which may be the same KDC again, depending on what is returned in the
> TXT SRV record as $next_KDC ..

Have a look at the krb5.conf options:
   dns_lookup_kdc and dns_lookup_realm

> I am facing that same headache when a Windows KDC also responds with
> "hey, I have an auth response for you, but it's too big for UDP, please
> change to TCP to come and grab it!" ....

Add the krb5.conf option
udp_preference_limit = 1

This will force TCP all the time.

> *sigh* I may see the client
> then conneting again to $random_kdc_for_domain which might give me a
> success, or might simply go "Nope, that enctype isn't supported here" ..
> (Could I ask to add a feature, or change behaviour to connect to the
> *same* KDC when switching to TCP, please? :) )
> Yep, I know, all of the above appear to be Windows related issues.
> However, those are managed by another team, and for those, if anyone
> here has recommendations I would be more than happy to take those
> onboard and forward on to the Windows team.
> Does anyone here have a similar setup, know of one, or has any
> recommendations I can look at and use when talking to the Windows team?

How do you add the service principals to AD?

The AD attribute msDs-supportedEncryptionTypes:
defines what encryption types the services can support, i.e. what
enctypes are in the keytab on the server.

msktutil   can be used to create keytabs and add serveros accounts in AD.
One version can be found here:
I believe RedHat also has a version. Msktutil has a --enctype n
option where n is the decimal value used to set the

Samba may also have a way to create keytabs.

Solaris has a script as well, but we don't use it.

> Yep, we are using the exact same krb5.conf on both Linux and Solaris.
> Yep, distributed out via config management system. We've got Kerberos
> 1.6.3 and testing 1.10.3 on a couple of Solaris hosts. RedHat/OEL are
> using what was supplied by the vendor. We've had zero luck in getting
> the Sun supplied libraries working, at all.

We use the Solaris 10 Kerberos, and ssh windows 2008r2 as the KDCs
with great success. (There is a Mac Mountain Lion ssh with delegation
problem to Solaris that has popped up recently.)

> I also have tcpdumps available so I can provide a lot more details if
> needed, though I suspect this may have been surfaced previously and I
> have simply not been able to find anything about it. :)
> Thanks in advance folks!
> //anders


  Douglas E. Engert  <DEEngert at>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

More information about the Kerberos mailing list