erreur GSS-API contexte accepter: clé Service non disponible - Code Solaris, Windows KDC

Question

Je tente d'obtenir une paire client Kerberos test / serveur de travail sur Active Directory. J'ai créé trois utilisateurs dans un domaine libre dans notre réseau d'entreprise, « richardc », « Serveur1 » et « Server2 ». Mes utilisateurs du serveur ont été mis en correspondance avec différents noms principaux de service, une avec KRB5_NT_PRINCIPAL, l'autre avec KRB5_NT_SRV_HOST.

ktpass -out server2.keytab 
          -princ server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
          -mapuser ServerUser2@BENCHMARKING.RDDEV.LOCAL
          -pass ThePassword
          -crypto All
          -pType KRB5_NT_SRV_HOST
          -kvno 2

Je n'ai pas utilisé l'option + desonly cette fois-ci, dans l'espoir que dans les systèmes d'aujourd'hui, je ne ai pas besoin DES. J'ai remplacé le vrai nom de domaine avec mondomaine dans cette question afin d'éviter problème de gestion.

Cela me donne un keytab. Je peux KLIST il:

KVNO Principal
---- --------------------------------------------------------------------------
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (DES cbc mode with CRC-32)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (DES cbc mode with RSA-MD5)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (ArcFour with HMAC/md5)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (AES-128 CTS mode with 96-bit SHA-1 HMAC)

Je peux même utiliser kinit -k pour se connecter avec la clé de la keytab -. Il semble fonctionner

Je possède mon propre programme de test, et à défaut le programme de test http://download.oracle.com/docs/cd/E19683-01/816-1331/sampleprogs-1/index.html . Dans ce programme, sur le serveur, je l'ai changé GSS_C_NT_HOSTBASED_SERVICE à GSS_C_NT_USER_NAME avec les deux keytabs pour le faire reconnaître le nom. Je cours le serveur Oracle Demo comme

./gss-server -mech 1.2.840.113554.1.2.2 server2/serbia.mydomain.com    

et le client

./gss-client -mech 1.2.840.113554.1.2.2 serbia.mydomain.com server2 "Hello"

Le résultat:

GSS-API error accepting context: Invalid credential was supplied
GSS-API error accepting context: Service key not available

Dans ce cas et à la fois avec mon propre code de test, l'erreur se produit après que le client a envoyé son premier jeton, alors que le serveur tente de le décoder.

montre klist la clé accordée pour le client. Il utilise arcfour, qui est dans le keytab

Default principal: RichardC@BENCHMARKING.RDDEV.LOCAL

Valid starting                Expires                Service principal
07/25/11 17:36:49  07/26/11 03:35:18  krbtgt/BENCHMARKING.RDDEV.LOCAL@BENCHMARKING.RDDEV.LOCAL
    renew until 08/01/11 17:36:49
07/25/11 17:36:03  07/26/11 03:35:18  server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
    renew until 08/01/11 17:36:03

La machine UNIX (Serbie) pourrait éventuellement appartenir à un autre domaine (celui que je l'ai appelé mydomain.com ici), mais il ne semble pas avoir la configuration Kerberos. J'utilise un fichier krb5.conf locale que je l'ai signalé au domaine BENCHMARKING.RDDEV.LOCAL, mais si la machine tente d'utiliser le DNS avec son nom d'hôte, il peut obtenir la mauvaise réponse. Mon krb5.conf a

[libdefaults]
    default_keytab_name = /users/dev/core/richardc/server1.keytab
    default_realm = BENCHMARKING.RDDEV.LOCAL
    dns_lookup_kdc = false
    default_tkt_types = DES-CBC-MD5

[realms]
BENCHMARKING.RDDEV.LOCAL = {
    kdc = gbha-dcbench01p.benchmarking.rddev.local
    admin_server = gbha-dcbench01p.benchmarking.rddev.local
}

[domain_realm]
benchmarking.rddev.local = BENCHMARKING.RDDEV.LOCAL
.benchmarking.rddev.local = BENCHMARKING.RDDEV.LOCAL
mydomain.com = BENCHMARKING.RDDEV.LOCAL
.mydomain.com = BENCHMARKING.RDDEV.LOCAL

Il ressemble à des options telles que default_tkt_types ont été inefficaces.

La question est - comment puis-je réparer mon erreur

Merci - Richard

Answer 1

Le problème était dans le

ktpass -out server2.keytab 
      -princ server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
      -mapuser ServerUser2@BENCHMARKING.RDDEV.LOCAL
      -pass ThePassword
      -crypto All
      -pType KRB5_NT_SRV_HOST
      -kvno 2

Cela provoque Windows pour augmenter le numéro de version clé. La clé résultante est pas un problème pour la connexion « kinit -k » pour une raison quelconque, mais ne cause le code du serveur GSS-API pour échouer avec la touche « Service non disponible » inutile sur les systèmes Solaris.

Le système de Windows était 2008R2. Je comprends que le comportement de cette commande varie entre les différentes versions de Windows.

Je l'ai testé avec succès avec desonly. Je dois retourner au service informatique pauvres aux abois pour tout autre test :-)

La solution est de manquer l'argument -kvno.

 ktpass -out server4.keytab 
      -princ server4/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
      -mapuser ServerUser4@BENCHMARKING.RDDEV.LOCAL
      -pass ThePassword
      -crypto DES-CBC-MD5
      -pType KRB5_NT_USER_PRINCIPAL

Cela donne la sortie

Targeting domain controller: GBHA-DCBENCH01P.benchmarking.rddev.local
Using legacy password setting method
Successfully mapped server4/serbia.mydomain.com to Server4.
Key created.
Output keytab to server4.keytab:
Keytab version: 0x502
keysize 79 server4/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL ptype 1
     (KRB5_NT_PRINCIPAL) vno 5 etype 0x3 (DES-CBC-MD5) keylength 8 (0xd1532a6d0f2a8631)
Account Server4 has been set for DES-only encryption.

Notez que le "5 OVN" dans la sortie.

Je l'ai testé avec les deux valeurs pour -pType. Les deux travaux.

Code Mon ESG utilise GSS_C_NT_HOSTBASED_SERVICE, mais tout cela semble modifier le format requis pour saisir le nom.

(j'ai changé la clé ci-dessus)

Addendum

Ma solution finale utilise -pType KRB5_NT_USER_PRINCIPAL

Code Mon ESG utilise GSS_C_NT_USER_NAME pour rechercher le nom, et je spécifier le nom complet server4/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL . J'ai trouvé que toutes les plates-formes que je travaillais accepté le GSS_C_NT_HOSTBASED_SERVICE, mais ils acceptent tous GSS_C_NT_USER_NAME.

La personne qui installe notre application serveur définit le nom du serveur principal comme une option de configuration. Cela semblait le moyen le plus fiable. La personne qui met en place la clé, donc sait ce qu'elle est, dit l'application directement ce qui touche à l'utilisation.