Impossible de récupérer TGT malgré l'entrée de registre allowtgtsessionkey

Question

J'essaie de câbler notre application client Windows pour utiliser un mécanisme de connexion unique. Je suis les explications qui peuvent être trouvées here. J'ai déjà du mal à faire le premier pas, c'est-à-dire acquérir le Ticket-Granting-Ticket de l'Utilisateur Signé. Lors de l'exécution de mon test unitaire (code, voir ci-dessous), je reçois l'exception suivante:

javax.security.auth.login.LoginException: Unable to obtain Princpal Name for authentication 
at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:800) 
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:671) 
at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:584) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:606) 
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:784) 
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) 
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) 
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) 
at java.security.AccessController.doPrivileged(Native Method) 
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) 
at javax.security.auth.login.LoginContext.login(LoginContext.java:594) 
at org.myapp.test.cases.SSOTest.testSSO(SSOTest.java:28) 

Cela se produit lorsque je lance le test avec Java 7. Je pensais que cela signifie que le cache de billets est vide. Toutefois, lorsque j'exécute le test avec Java 6, la connexion est réussie et je peux récupérer un objet Subject entièrement rempli à partir du LoginContext. Comme je l'ai lu here, Java 7 respecte maintenant pleinement les politiques de Windows 7 qui autorisent/refusent l'exportation de TGT. J'ai donc mis la valeur allowtgtsessionkey dans mon registre, en espérant que cela réglerait mon problème. Mais malgré avoir relogué et redémarré, je ne peux toujours pas accéder à mon TGT avec Java 7. Avec Java 6, ça marche très bien. Quelqu'un pourrait-il indiquer ce que je manque?

SSOTest.java:

@Test 
    public void testSSO() { 
    System.setProperty("java.security.auth.login.config", "D:\\login.conf"); 

    LoginContext lc = null; 
    try { 
     lc = new LoginContext("TestLoginContext1"); 
    } catch (LoginException e1) { 
     e1.printStackTrace(); 
    } 

    try { 
     lc.login(); // Exception happens here 
    } catch (LoginException e) { 
     e.printStackTrace(); 
    } 

    Subject signedOnUserSubject = lc.getSubject(); 
    System.out.println(signedOnUserSubject); 
    } 

login.conf

TestLoginContext1 { 
    com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true doNotPrompt=true debug=true; 
}; 

krb5.conf

[libdefaults] 
default_realm = MY.DOMAIN.COM 
[realms] 
MY.DOMAIN.COM = { 
    kdc = domaincontroller.my.domain.com 
    admin_server = domaincontroller.my.domain.com 
    default_domain = MY.DOMAIN.COM 
} 

Answer 1

Il semble que ce soit une limitation de Windows en matière de comptes qui sont également dans le groupe de l'administration locale. Je lis ce qui suit here:

Problèmes connus

Si un compte AD est également ajouté dans le groupe d'administrateur local sur le PC client, Microsoft limite ce client d'obtenir la clé de session pour les billets (même si vous définissez la clé de Registre allowtgtsessionkey à 1). La solution de contournement est: N'oubliez pas que vous êtes un utilisateur enregistré, appelez kinit.exe. Ne dépend pas du cache des informations d'identification LSA.

Dans un correctif récent ([35] http://support.microsoft.com/kb/942219/en-us, devrait être inclus dans Vista SP1), cette restriction est levée pour la normale
billets de service. Cependant, il s'applique toujours à TGT. Puisque Java utilise TGT pour acquérir des tickets pour d'autres services (le processus Kerberos standard), cette mise à jour n'apporte aucun bénéfice à la programmation JGSS sous Windows.
En outre, même si l'implémentation de Java est modifiée pour lire
les tickets de service du cache LSA, elle ne peut toujours pas effectuer la délégation , car un TGT est toujours nécessaire dans ce cas.