utenti in domini trusted

Question

La mia applicazione definisce utenti autorizzati tramite LDAP (solitamente Active Directory):

1. Il cliente definisce un server LDAP (TreeA) e un gruppo (GroupA). Qualsiasi utente nel GruppoA può utilizzare l'applicazione.
2. al momento del login, un utente invia il proprio nome utente e password - se un binding a LDAP TreeA con le loro credenziali di opere e il loro account utente è in un GroupA, sono buoni per andare

I' Ci si imbatte in una situazione in cui due Active Directory si fidano l'un l'altro e il GroupA specificato in TreeA contiene utenti di TreeB. Quindi il passo 2 fallisce perché sto cercando di autenticare l'Utente B (da TreeB) contro TreeA.

L'applicazione ha accesso a TreeA, quindi suppongo che potrebbe apparire nel GruppoA e vedere UtenteB lì. Ma come potrebbe sapere che ha bisogno di inviare richieste di binding a TreeB per autenticare il nome utente e la password?

C'è un modo migliore per avvicinarsi a questo?
Se tali richieste di binding a TreeA vengono inoltrate automagicamente a TreeB poiché esiste una relazione di trust ??

Answer 1

È possibile che si sia verificato un problema di configurazione sul server LDAP (TreeA). Hai scritto che ci sono fiducia tra TreeA e TreeB, così puoi aggiungere UserB (da TreeB) come membro del GroupA in TreeA. Se riesci a farlo, allora hai stabilito con successo la fiducia nella direzione corretta tra TreeA e TreeB. È necessario comprendere che tale attendibilità significa solo che Active Directory B verifica solo la password dell'utente, ma UtenteB per impostazione predefinita non avrà accesso a nessuna risorsa da Active Directory A. L'UtenteB non può disporre dell'autorizzazione per associare LDAP al server A. Nel caso in cui il problema venga risolto concedendo all'utente B l'autorizzazione di accesso remoto sul server A e l'accesso in lettura a GroupA e probabilmente legge l'autorizzazione all'OU dove esiste il Gruppo A. Puoi provare Insight for Active Directory per monitorare l'accesso AD per localizzare i problemi di autorizzazione.

Altro possibile motivo del problema potrebbe essere l'utilizzo dell'API che si utilizza per l'accesso LDAP. Nella tua domanda non hai scritto alcuna informazione sull'API. Utilizzi API Win32 come ldap_bind_s o utilizza DirectoryEntry in .NET? In entrambi i casi potrebbe essere importante utilizzare esplicitamente il nome del dominio insieme al nome dell'account (per UtenteB) durante l'associazione o utilizzare null per il nome e la password per le credenziali dell'utente corrente dell'utente.

L'utilizzo di account fissi da TreeA per tutti gli accessi a TreeA (anche per test su UtenteB) potrebbe anche risolvere il problema, ma potrebbe essere possibile solo un qualche tipo di utilizzo dell'applicazione.

In qualsiasi modo maggiori informazioni nella tua domanda potrebbero limitare il problema e le modalità per risolvere il problema.

Answer 2

Forse dovresti usare la replica ldap in modo tale che gli oggetti siano sempre presenti in entrambi i server?

Answer 3

L'applicazione ha accesso a TreeA, quindi suppongo che poteva guardare in GroupA e vedere UserB lì. Ma come sarebbe sapere che ha bisogno di inviare le richieste di collegamento a TreeB per autenticare il nome utente e la password ?

L'attributo member in GroupA darà il nome completo distinto (DN) di ogni membro, che potrebbe essere simile:

member: CN=User1,OU=People,DC=TreeA,DC=foobar,DC=com 
member: CN=User2,OU=People,DC=TreeB,DC=foobar,DC=com 

Così, quando i tentativi 'user2' per l'autenticazione, è possibile abbinare il CN e sappi che dovresti autenticarti contro "TreeB" invece di "TreeA". (Presumibilmente si potrebbe avere una sorta di tabella che associa il DN al nome host del server AD.) Oppure, basta forzarlo e provare "TreeB" se si ottiene un "tale utente" da "TreeA".

Dovresti prendere una decisione su come gestire il caso di nomi utente duplicati nei due alberi: uno ha priorità sull'altro?

Un altro approccio sarebbe richiedere agli utenti di specificare a quale albero si sta autenticando, ad esempio accedendo con un nome di accesso come "utente1@treea.foobar.com".

Answer 4

Diciamo che avete il dominio A e il dominio B che fiducia l'un l'altro, e se si desidera autenticare l'utente B da Dominio B contro il dominio di A sul server di un dominio A in modo che cosa dovete fare sono:

1. Impersonare l'utente B sul dominio A utilizzando le API Win32.

2. Autenticare l'utente B rispetto al dominio A tramite DirectoryEntry, quindi è possibile accedere all'AD del dominio A per altre informazioni utente come gruppi assegnati.

L'ho implementato in un'applicazione ASP.NET che utilizza l'autenticazione di Windows.

Spero che sia d'aiuto,