INFORMAZIONI: Come utilizzare ADSI per eseguire query un server LDAP di terze parti

Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell’utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell’utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.

Clicca qui per visualizzare la versione originale in inglese dell’articolo: 251195
Dichiarazione di non responsabilità per articoli della Microsoft Knowledge Base su prodotti non più supportati
Questo articolo è stato scritto sui prodotti per cui Microsoft non offre più supporto. L’articolo, quindi, viene offerto ‘così come è’ e non verrà più aggiornato.
Sommario
Il provider LDAP (Lightweight Directory Access Protocol) per ADSI (Active Directory Service INTERFACES) è utilizzato per recuperare informazioni dai server LDAP di terze parti. In questo articolo viene descritto alcuni problemi che possono verificarsi e come risolvere tali.
Informazioni
Quando si utilizza ADSI per recuperare informazioni da un server LDAP di terze parti, è necessario:
  • Verificare la disponibilità di informazioni sullo schema.
  • Consente di ottenere l'autenticazione corretta.
  • Impedire un ricerca in un contenitore inesistente.

Determinare la disponibilità di informazioni sullo schema

In conformità con Request for Comments (RFC) 2251 LDAP versione 3 server devono esporre un attributo subSchemaSubEntry directory principale dell'organizzazione del servizio directory (il rootDSE). ADSI questo attributo viene utilizzato per individuare le informazioni subschema, che quindi tenta di convalidare e memorizzare nella cache.

Per ulteriori informazioni su come ADSI memorizza nella cache il subschema, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
251189INFORMAZIONI: Individuazione uno schema del server LDAP memorizzato nella cache da ADSI
ADSI utilizza le informazioni di subschema per esporre le interfacce appropriate per una determinata classe e recuperare gli attributi della sintassi corretta dalla cache delle proprietà.

Se ADSI non individuare o convalidare correttamente le informazioni di subschema, viene utilizzato lo schema versione 2 di LDAP predefinito. Poiché LDAP versione 2 server non espongono un subschema, ADSI mantiene informazioni di schema internamente sulle molte classi e attributi standard. Se ADSI utilizza lo schema della versione 2 predefinito, non dispone di accesso alle informazioni dello schema non standard, incluse le classi personalizzate o gli attributi che sono stati creati sul server.

Se informazioni sullo schema sulla sintassi dell'attributo non sono disponibile, ADSI è Impossibile recuperare l'attributo dalla cache delle proprietà. In questo caso, è possibile utilizzare il metodo IADsPropertyList.GetPropertyItem per specificare una sintassi dell'attributo della proprietà richiesta. Quando si specifica un valore ADsTYPE, è possibile evitare la necessità di informazioni di sintassi di tale attributo.

Se si utilizza Microsoft ActiveX Data Objects (ADO), e non si dispone di disponibili informazioni sullo schema, è necessario recuperare la stringa ADsPath dell'oggetto, l'associazione all'oggetto nella directory e quindi utilizzare il metodo IADsPropertyList.GetPropertyItem . Non è disponibile alcuna soluzione per l'utilizzo di ADO direttamente senza informazioni sullo schema.

Ottenere l'autenticazione corretta

Esistono diversi modi per autenticare un client LDAP a un server LDAP con ADSI. Tra questi metodi, il solo un'associazione semplice è supportata in modo nativo da LDAP per comunicare credenziali al server. In altri casi, il client e il server devono essere conformi al metodo, in genere con l'utilizzo di un'altra autorità di protezione o un protocollo proprietario.

Ad esempio, il metodo GetObject (o la funzione di ADsGetObject in C) utilizza il flag ADS_SECURE_AUTHENTICATION, che potrebbe causare un binding LDAP che utilizza Microsoft Windows NT Challenge/Response (NTLM). Questa associazione è probabilmente esito negativo poiché molti server di terzi non accettano il NTLM. Se l'autenticazione non riesce, l'associazione di protezione è stato modificato per un binding anonimo; ad esempio, un semplice associare senza le credenziali dell'utente. È possibile che a questo punto, che l'applicazione disponga di accesso solo a un sottoinsieme di informazioni (o anche a Nessuna informazione) a seconda della configurazione server.

Per evitare questa situazione, è necessario eseguire un'associazione semplice utilizzando il metodo OpenDSObject (o la funzione di ADsOpenObject in C) e specificare zero (Nessun flag) o ADS_FAST_BIND (descritto di seguito) per il parametro lnReserved . Con l'associazione semplice, passare un nome utente con attributo valido (cn = UserName, cn =...) e una password per il server LDAP per la verifica. Per ottenere un'associazione semplice con ADO, impostare la proprietà Password di crittografia dell'oggetto ADODB.Connection su FALSE e assegnare rispettivamente il nome utente con attributi e la password alle proprietà ID utente e password .

Evitare di una ricerca in un contenitore inesistente

Per impostazione predefinita, ADSI esegue una ricerca di objectClass dell'oggetto base specificato in una query o l'associazione. La ricerca non riesce se il nome distinto è specificato non esiste nella directory.

Ad esempio, si supponga che che una ricerca sia impostata a partire da "o = corp, c = IT" per tutti gli utenti nella directory. La struttura della directory è ad esempio che non esiste nessun contenitore "Org" effettivo, ma invece di due oggetti nella directory principale della directory con i nomi distinti di "ou = Europa, o = corp, c = IT"e"ou = Europa, o = corp, c = IT". ADSI emette un cercare objectClass "o = corp, c = IT" che non riesce, interruzione della ricerca per gli utenti prima che venga avviato.

La soluzione più semplice a questo problema consiste nello specificare un oggetto di base che effettivamente esiste nella directory. Se non è possibile, a causa dell'implementazione di directory, eseguire la ricerca desiderata con un oggetto di base valido, è necessario impedire ADSI di eseguire una ricerca objectClass iniziale.

Per evitare che una ricerca objectClass dell'oggetto, passare il flag ADS_FAST_BIND nel parametro lnReserved del metodo OpenDSObject (oppure la funzione di ADsOpenObject in C). Poiché questo flag determina le azioni di ADSI, dopo l'associazione, non influenza l'autenticazione corretta. Si noti che questo flag non è disponibile prima ADSI versione 2.5.

Il provider di ADO per Microsoft Windows 2000 espone le proprietà ADSI Flag dell'oggetto ADODB.Connection . È possibile impostare il flag ADS_FAST_BIND per questa proprietà impedire l'esecuzione di una ricerca objectClass di query ADO. La proprietà ADSI Flag non è presente in ADSI versione 2.5 per Microsoft Windows NT versione 4.0 o Microsoft Windows 9 x. Per una possibile soluzione, vedere il seguente articolo:

223049HOWTO: Query di Exchange 5.x Anonymously tramite ADSI
Riferimenti
Per ulteriori informazioni su ADSI, vedere i seguenti articoli della Microsoft Knowledge Base riportato di seguito:
233023HOWTO: Trova tutti i provider ADSI in un sistema
187529HOWTO: Utilizzo di ADO per oggetti tramite un provider LDAP ADSI
251189INFORMAZIONI: Individuazione uno schema del server LDAP memorizzato nella cache da ADSI
223049HOWTO: Query di Exchange 5.x Anonymously tramite ADSI

Per informazioni generali su ADSI, vedere il seguente sito Web:
adsi LDAP

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 251195 - Ultima revisione: 09/28/2007 05:40:21 - Revisione: 1.3

Microsoft Active Directory Service Interfaces 2.5

  • kbmt kbinfo kbmsg KB251195 KbMtit
Feedback