Quale campo utilizzare per l'autenticazione con Active Directory?


12

Gli oggetti utente di Active Directory includono un numero di campi che possono essere considerati un identificatore. Di seguito sono elencati alcuni di questi con la loro etichetta in ADUC e il loro nome di attributo:

  • Nome completo - cn
  • ? - nome
  • Accesso utente sAMAccountName - sAMAccountName
  • Accesso UPN utente: userPrincipalName
  • ? - nome distinto

Sto cercando di convincere i nostri sviluppatori a standardizzare l'utilizzo di uno solo di questi quando scrivono codice personalizzato che esegue l'autenticazione con AD: il problema è che non sono sicuro di quale sia quello "giusto" o se quelli diversi sono quelli giusti in differenti circostanze. Non sono nemmeno sicuro che nessuno dei campi sopra elencati debba essere usato!

Qualcun altro ne ha scelto uno da usare in modo coerente e cosa ti ha influenzato in quella decisione? Qualche documentazione che chiarisca il problema?


Ho incontrato alcune applicazioni (sia sviluppate internamente che altre cose) che eseguono l'autenticazione tramite LDAP utilizzando il campo cn. Questo campo ora viene aggiornato automaticamente in AD Admin Center (è etichettato Nome completo) se si modificano i campi nome o cognome, il che significa che non si può presumere che il campo cn possa essere considerato un campo nome utente. Questi sviluppatori hanno utilizzato il campo sbagliato o Microsoft ha rotto il cn?
Dunxd,

Risposte:


18

Un CN (nome comune) non è utile per l'accesso, poiché un CN da solo non identifica in modo univoco un utente. Potrei avere un

CN=Ryan Ries,OU=Dallas,DC=Domain,DC=com

e potrei anche avere un

CN=Ryan Ries,OU=New York,DC=Domain,DC=com

Anche la CN di un utente è un RDN (nome distinto relativo). Hanno la stessa CN, ma DN diversi. Potresti notare che si verificano problemi se nella tua organizzazione ci sono due persone di nome Ryan Ries, e dovrai creare SamAccountName per il secondo in qualche modo rries2.

Un DN (nome distinto) non è buono per accedere, perché chi vuole accedere a un sistema con un nome utente come CN=ryan,OU=Texas,DC=brazzers,DC=com? Mentre l'utilizzo di un DN identifica in modo univoco e definitivo un utente, è fastidioso dover digitare. È lo stesso tipo di concetto tra percorsi relativi e percorsi assoluti in un file system. Implica anche che tu sappia esattamente dove si trova l'oggetto nella struttura della directory senza doverlo cercare. Che spesso non lo fai.

Questo si chiama Ambiguous Name Resolution (ANR) - cerca nella directory un utente quando non si ha il suo nome distinto.

UPN (nome principale utente) è abbastanza buono perché sembrano indirizzi e-mail, possono essere gli stessi dell'indirizzo e-mail aziendale dell'utente, sono facili da ricordare e preferiscono accedere perché il nome verrà cercato nel dominio locale prima di cercarlo nella foresta.

Microsoft afferma: il punto dell'UPN è consolidare gli spazi dei nomi di posta elettronica e di accesso in modo che l'utente debba solo ricordare un solo nome. UPN è il nome di accesso preferito per gli utenti Windows. Gli utenti dovrebbero utilizzare i propri UPN per accedere al dominio. Al momento dell'accesso, un UPN viene convalidato prima cercando il dominio locale, quindi il catalogo globale. La mancata ricerca dell'UPN nel dominio locale o del GC comporta il rifiuto dell'UPN. L'UPN può essere assegnato, ma non è richiesto , quando viene creato l'account utente.

Tenere presente che alla fine la progettazione delle applicazioni non richiede "bit" obbligatori.

SamAccountName è anche utile perché SamAccountName deve essere univoco per tutti nel dominio (ma non per la foresta). Inoltre, SamAccountNames è breve. Molte persone accedono con SamAccountNames, anche se non ti identificano in modo univoco in una foresta AD, motivo per cui devi specificare un nome di dominio da associare a SamAccountName in modo che il sistema sappia a quale dominio stai tentando di accedere .

Ecco della grande documentazione sul problema per ulteriori letture:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx


4

Se ti riferisci al nome utente come qualcosa che qualcuno digiterebbe per accedere, ti consiglierei sAMAccountName, che sarebbe univoco in combinazione con un nome di dominio, o il userPrincipalName, che sarebbe univoco all'interno di una foresta.

Per quanto riguarda il nome utente come identificatore univoco, Windows utilizza il SID per tutte le voci di controllo dell'accesso e fornisce un set completo di metodi per la traduzione in SID dai nomi degli utenti. I SID corrispondono alla metafora dell'utente per la durata di un account, poiché la ridenominazione e gli spostamenti all'interno di un dominio non hanno alcun effetto, ma l'eliminazione e la ricostruzione dei risultati in un nuovo SID.

A tal fine, chiamerei LookupAccountName, che accetta una stringa che rappresenta il nome utente e restituisce sAMAccountName, il SIDe il nome di dominio del dominio in cui è stato trovato l'utente.

L'utente può quindi utilizzare qualsiasi sintassi supportata da Windows per accedere e non è richiesta alcuna formazione aggiuntiva.


LookupAccountName accetta UPN o sAMAccountName o DOMAIN \ sAMAccountName completo o tutto quanto sopra? Non è chiaro dalla documentazione a cui ti colleghi.
Dunxd,

Le liste di documentazione formati supportati: DOMAIN\Account, DOMAIN.COM\Account, Account, Account@DOMAIN.COM. Dice che i nomi completi sono più veloci, ma gli altri sono ancora disponibili.
Mitch,

0

Consiglio di consentire all'utente di scegliere il formato del nome che desidera utilizzare e di determinare l'input dell'utente sul lato dell'applicazione. ad esempio: se l'utente digita: nomeutente@dominio.com, consideralo come UPN e cerca UPN in AD. Se l'utente digita: username - consideralo come samAccountName per un dominio predefinito predefinito e ovviamente se l'utente digita domain \ username - consideralo come samAccountName dal dominio specificato. Recupera sempre il SID dell'utente e assegna tutte le autorizzazioni al SID perché le persone si sposano e il nome utente può cambiare.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.