Qualche differenza tra DOMAIN \ username e username@domain.local?

Sto cercando di risolvere un oscuro errore di autenticazione e ho bisogno di alcune informazioni di base.

• C'è qualche differenza tra il modo in cui Windows (e programmi come Outlook) elaborano DOMAIN\usernamee username@domain.local?

• Quali sono i termini appropriati per questi due formati di nome utente?

• Modifica : in particolare, ci sono differenze nel modo in cui Windows autentica i due formati di nome utente?

Supponendo che tu abbia un ambiente Active Directory:

Credo che il formato barra rovesciata DOMAIN \ USERNAME cercherà nel dominio DOMAIN un oggetto utente il cui nome account SAM è USERNAME.

Il formato nome utente @ dominio UPN cercherà nella foresta un oggetto utente il cui nome del principio utente è nomeutente @ dominio.

Ora, normalmente un account utente con un nome account SAM di USERNAME ha un UPN di USERNAME @ DOMAIN, quindi entrambi i formati dovrebbero individuare lo stesso account, almeno a condizione che AD sia pienamente funzionante. Se si verificano problemi di replica o non è possibile raggiungere un catalogo globale, il formato barra rovesciata potrebbe funzionare nei casi in cui il formato UPN non riuscirà. Potrebbero esserci anche condizioni (anormali) in cui si applica il contrario - forse se per esempio non è possibile raggiungere controller di dominio per il dominio di destinazione.

Tuttavia: è anche possibile configurare esplicitamente un account utente in modo che abbia un UPN il cui componente nome utente è diverso dal nome account SAM e il cui componente dominio è diverso dal nome del dominio.

La scheda Account in Utenti e computer di Active Directory mostra l'UPN sotto l'intestazione "Nome accesso utente" e il Nome account SAM sotto l'intestazione "Nome accesso utente (precedente a Windows 2000)". Quindi, se hai problemi con determinati utenti, verificherei che non ci siano discrepanze tra questi due valori.

Nota: è possibile che vengano eseguite ulteriori ricerche se la ricerca che descrivo sopra non trova l'account utente. Ad esempio, forse il nome utente specificato viene convertito nell'altro formato (in modo ovvio) per vedere se produce una corrispondenza. Ci deve essere anche una procedura per trovare account in domini attendibili che non si trovano nella foresta. Non so dove / se sia documentato il comportamento esatto.

Solo per complicare ulteriormente la risoluzione dei problemi, i client Windows memorizzeranno per impostazione predefinita le informazioni sulla cache degli accessi interattivi riusciti, in modo da poter accedere allo stesso client anche se le informazioni dell'account utente in Active Directory sono inaccessibili.

Potrei essere corretto su questo, ma non c'è davvero molta differenza.

Dominio \ Utente è il "vecchio" formato di accesso, chiamato nome di accesso di livello inferiore . Conosciuto anche con i nomi SAMAccountName e il nome di accesso precedente a Windows 2000 .

User@Domain.com è un UPN - Nome principale utente . È il formato di accesso "preferito" e più recente. È un nome di accesso in stile Internet, che dovrebbe essere associato al nome e-mail dell'utente. ( Rif. Su MSDN )

Le ragioni per accedere con UPN credo siano principalmente estetiche: ipoteticamente danno ai tuoi utenti nella tua azienda un solo nome con il quale accedere alle loro stazioni di lavoro che possono anche fungere da indirizzo di posta elettronica aziendale.

modifica: più elaborazione - un altro vantaggio degli UPN è che puoi configurare più di un UPN valido per consentire agli utenti di accedere. Ancora una volta, in gran parte cosmetico. Ma la cosa importante è che non tutte le applicazioni sono compatibili con gli UPN e potrebbe essere quello che stai riscontrando.

modifica # 2: Mi piace la risposta di Harry Johnston qui sotto sui due formati di ricerca leggermente diversi eseguiti. Ha senso e, soprattutto, potrebbe effettivamente spiegare il tuo problema. :)

Il formato barrato ( DOMAIN\username) è in realtà l' NetBIOSequivalente del nome DNS del dominio ( domain.mycompany.local).
Il NetBIOSnome è limitato a 15 caratteri e non può contenere punti, trattini bassi, ecc.

Questa pagina spiega in modo più dettagliato:
* Jeff Schertz, 20-08-2012, Comprensione dei formati di denominazione di Active Directory (Archiviato qui .)

Come accennato da @ harry-johnston sopra, è davvero solo il vecchio formato compatibile con NT4 e Windows 2000 ma sembra essersi bloccato come un formato preferito (è meno da digitare!). Alla fine, il supporto per il formato legacy potrebbe passare da Windows.

Probabilmente è una buona idea abituare gli utenti a utilizzare il formato UPN poiché evita anche problemi in cui hanno problemi ad accedere a un PC con il loro nome utente e non si rendono conto che la casella di accesso di Windows è stata impostata automaticamente sul locale Dominio PC (ad es. pc01\fred) O quando si connettono a diversi host di desktop remoto e devono ricordare di includere il dominio e il loro nome utente poiché il client di Desktop remoto può memorizzare nella cache un altro nome di dominio precedentemente utilizzato. Attenersi al formato UPN ogni volta fa solo meno chiamate di supporto alla fine.

C'è sicuramente una differenza tra quei due, solo il 99% degli utenti non avrà problemi con esso. Proverò a spiegare la differenza e quando potrebbe verificarsi un problema del genere.

Se si utilizza domain \ username quando si tenta di accedere a una condivisione file, DNS risolverà prima il dominio e quindi controllerà il nome utente. Se si utilizza username @ domain, controllerà direttamente se l'utente si trova nella LCA (elenco controllo accessi) e ha accesso. Quindi, cosa importa, potresti pensare ... beh, immagina questo:

1 controller di dominio con nome DC01 e tutti i client ottengono dns e si trovano in questo dominio. Vuoi migrare e qualcuno ha aggiunto un altro server con lo stesso nome. Anche quest'ultimo server diventerà un controller di dominio, quindi il SAM locale non verrà più utilizzato e avrà anche una condivisione file.

Quando gli utenti si collegheranno al server, verranno loro richieste le credenziali. Se usi domain \ username, controllerà prima il dominio corrente invece di usare il nuovo dominio e abbiamo usato gli account del nuovo dominio nella condivisione file. Quindi una volta che ha trovato il DC corrente e controlla il nome utente non può essere trovato. (anche se il nome utente e la password sono identici e identici, non funzionerà poiché non utilizzerà il nome utente per verificare se è consentito nella LCA ma utilizzerà il SID. Il sid verrà creato nel tempo di creazione dell'utente in AD e hai un cambio di 1 su un trilione che è lo stesso, ottimo eh :-P).