Perché kerberos si imposta automaticamente su NTLM in WCF?

Question

Hai ottenuto una semplice app per la demo di WCF con due progetti di console: host e client. Entrambi sono in esecuzione sulla mia macchina (vinci 7 box). Sto usando netTcpBinding, che usa l'autenticazione di Windows.

Il problema è che l'autenticazione sta eseguendo il downgrade a NTLM da Kerberos e non riesco a capire perché.

Se uso

<clientCredentials> 
    <windows allowNtlm="true" /> 
</clientCredentials> 

sul lato client, tutto è fresco. Ma se cambio che a false, ottengo la seguente eccezione:

SecurityNegotiationException: il server remoto non soddisfaceva il requisito di autenticazione reciproca .

Ciò suggerisce che kerberos non funziona e poiché il client non consente a NTLM la chiamata genera un'eccezione generata.

Si tratta di un problema con il progetto o si tratta di un problema esterno causato dalla configurazione della mia macchina di sviluppo?

---

Soluzione:

A quanto pare, devo specificare l'identità del server all'interno della configurazione del client. Nel mio caso, il server è in esecuzione con la mia identità, in modo da modificare il client così:

<client> 
    <endpoint address="net.tcp://dev7.HurrDurr.com:12345/MyService" 
      binding="netTcpBinding" 
      bindingConfiguration="MyBindingConfigurationLol" 
      behaviorConfiguration="HurrDurrServiceEndpoint" 
      contract="ShaolinCore.ICommunicationService"> 
    <!-- start changes here --> 
    <identity> 
     <userPrincipalName value="myusername@mydomain"/> 
    </identity> 
    <!-- end changes here --> 
    </endpoint> 
</client> 

Io non sono sicuro perché questo risolve il problema. Ok, ora sul lato client mi fido del server (hey, lo conosco!). Ma dal momento che NTLM è meno sicuro di Kerberos, perché non è il contrario? Se non mi fido del server, uso kerberos, altrimenti ntlm va bene.

Oppure, OTOH, se non mi fido del server perché funziona? "SecurityException: identità dell'endpoint non impostata, WCF non può fidarsi dell'identità del server e non trasmetterà l'identità del client."

Answer 1

Quando ho lavorato ai team di sviluppo IIS4, 5 e 6, ci siamo imbattuti in questo!Per Curb al lavoro, sono necessari i seguenti condizioni per essere vero:

1) Entrambe le parti sostengono marciapiede (tutte le versioni supportate di Curb il supporto di Windows oggi)

2) Macchine autenticazione ad Active Directory

3) Nomi principali del servizio (SPN) registrati per l'endpoint del server. Nei "bei vecchi tempi" dovevi farlo manualmente usando SetSPN.exe. Un SPN è solo un punto finale a cui Curb si connetterà; ha bisogno di questi dati per supportare l'authn reciproco. La maggior parte delle applicazioni saranno chiamano l'API approp a questo lavoro per voi (DsWriteAccountSpn)

Se uno dei passaggi di cui sopra non sono vere, Windows solito predefinito NTLM, pagherei ti dà solo l'autenticazione del client.

Spero che questo aiuti! - Michael

Answer 2

Come è configurato il server? Avete il <authentication mode="Windows"/> e <identity impersonate="true"/> nel file di configurazione?

si imposta la modalità di autenticazione tramite il tag di autenticazione nel file di configurazione:

<configuration> 
    <system.web> 
    <authentication mode="Windows" /> 
    </system.web> 
</configuration> 

Answer 3

Forse questa pagina su MSDN - Debugging Windows Authentication Errors - aiuta a capire cosa sta succedendo - sembra essere abbastanza difficile da quando NTLM vs Kerberos è in uso.

Answer 4

Fyi tramite MSDN: netTcpBinding: l'associazione predefinita utilizza la sicurezza del trasporto con autenticazione negoziata. Questa negoziazione tenta di utilizzare Kerberos, ma se non funziona, ricadrà e utilizzerà il precedente protocollo NTLM. Kerberos è un'ottima scelta se ti trovi in ​​un ambiente di dominio; per poterlo utilizzare, è necessario che sia il servizio che i client siano in esecuzione con gli account di dominio. Dovrai anche configurare un nome principale del servizio (SPN) per il tuo servizio.