Il WEB trasmette pura e semplice informazione. Grazie a ADO e RDS possiamo accedere alle informazioni di un database e manipolarle come vogliamo. Ma cosa succede quando vogliamo informazioni che riguardano la configurazione del nostro server. Come possiamo avere accesso a informazioni come:

Che file ci sono in una specifica directory?

Quali utenti appartengono a uno specifico gruppo?

Quali stampe sono in attesa nella coda di stampa?

Che servizi sono attivi su un particolare computer?

Sfortunatamente non siamo in grado di recuperare queste informazioni da un database. Eppure queste sono il tipo di domande che un amministratore di sistema si pone quotidianamente. In più l'amministratore potrebbe anche avere bisogno di apportare modifiche a questi aspetti del sistema ? magari quotidianamente ? in funzione della richieste del sistema.

Per rispondere a queste domande ed eseguire queste modifiche l'amministratore ha bisogno di accedere ai "directory services" del suo sistema e per far questo ha bisogno di essere a un terminale della sua rete, o almeno così era fino a qualche tempo fa. Adesso è possibile scrivere del codice ASP in grado di emulare ? a volte superandoli ? gli strumenti che comunemente sono associati all'amministrazione di sistema (gestione degli utenti ? gestione delle stampe e cose di questo tipo)

Il file system del server, Windows Explorer, possono essere emulati usando l'oggetto di scripting FileSystemObject. Per il resto abbiamo bisogno di ADSI (Active Directory Services Interface).

ADSI ci permette di gestire il ciclo di vita di oggetti directory astratti ? cose come computers, stampanti, utenti e gruppi. Inoltre possiamo usare ADSI per accedere a questi oggetti anche se si trovano su sistemi operativi diversi. Per esempio, prima di ADSI, condividere informazioni tra Windows NT e Novell Netware si limitava sostanzialmente a duplicare manualmente in entrambi i sistemi le informazioni sugli utenti. Con ADSI installato possiamo aggiornare le informazioni degli utenti da una pagina web e propagare automaticamente le modifiche all'interno di una rete con diversi sistemi operativi

Come funziona ADSI?

Configurare ADSI è abbastanza semplice. Per far funzionare pagine ADSI ASP bisogna semplicemente installare ADSI 2.0 (o 2.5 beta) sul server web. Ovviamente il server che useremo qui è IIS4.0, ma ADSI funziona bene anche con Personal Web Server. Tuttavia la mancanza di security sulla piattaforma Win9x ne sconsiglia l'uso. I file necessari all'installazione si possono trovare nella pagina di download del sito Backoffice della Microsoft.

Al momento dell'installazione ADSI sostanzialmente crea una super struttura (di directory) all'interno della quale si può accedere a qualsiasi "directory service" usando gli stessi comandi universali. Questa struttura contiene due tipi di oggetti base.

Un oggetto "container" cui appartengono una serie di oggetti sia di tipo "children" che di tipo "members"

UN oggetto leaf (foglia) che non contiene ne "children" ne "members"

Il perno dell'intera struttura è il container definito come "ADS://". Al suo interno troviamo una serie di "containers namespace". Ogni "namespace" espone una particolare sintassi grazie alla quale è possibile avere accesso al "directory service" in questione. Sfortunatamente un "directory service" non si troverà in un "namespace" a meno che non abbia installato un suo provider ADSI o che non se ne scriva uno attribuendogli un "namespace"

Attualmente, come mostrato più sotto, ci sono solo sei "directory services" che hanno anche un provider ADSI. Comunque ADSI è un' "open standard" ed è molto forte l'incentivo dei vari produttori di software a fornire un implementazione ADSI.

Nel frattempo ci sono tutta una serie di cose che possiamo fare con i sei provider che abbiamo a disposizione.

Sotto ogni "namespace" c'è una gerarchia di oggetti "container" e oggetti "leaf". Ogni container e così come ogni leaf ha le sue proprietà di base. Non possiamo analizzarle in questo contesto. Tuttavia, a titolo di esempio, possiamo iniziare a vedere la potenza e la scalbilità di ADSI dando un'occhiata alla struttura oggetti del "namespace" WinNT://:

Come si può vedere Windows NT ha una struttura abbastanza semplice. Probabilmente riconoscerete la gran parte (se non la totalità) dei nomi degli oggetti nel diagramma qui sopra. Da notare che c'è un unico oggetto schema per ogni "namespace provider" riconosciuto da ADSI ? si tratta dell'oggetto che contiene la lista di tutti gli oggetti del sistema e le loro proprietà

La vera potenza di ADSI emerge con la manipolazione dello schema WinNT, ciò diviene del tutto chiaro con il rilascio di Windows 2000 e la sua "Active Directory". E' possibile creare nuovi oggetti (con loro proprietà e metodi) in modo che ADSI li riconosca, oppure si può modificare l'insieme di proprietà di un oggetto esistente. Per esempio, cancellando una proprietà, si può togliere la necessità che un utente abbia la password.

Possiamo fare un passo in più. Lo schema definisce anche quali proprietà sono obbligatorie e quali facoltative (probabilmente George Orwell avrebbe intitolato il suo libro 1999 se avesse saputo che abbiamo la possibilità di costringere gli utenti a darci le informazioni che vogliamo negando l'accesso al terminale finché non viene attribuito un valore a una proprietà obbligatoria). ADSI ha qualche problema di sicurezza; per esempio, se si crea un sito di amministrazione remota della propria rete aumenta il rischio di attacchi o di accessi non autorizzati. Comunque ? a parte questo ? il sito in sé sarebbe incredibilmente facile da realizzare una volta capiti alcuni concetti base.

I concetti base

Ogni oggetto ADSI ha sei proprietà fondamentali: l'oggetto Parent, ADsPath, Name, Guid(identificativo unmerico univoco), lo schema (che lo governa) e l'oggetto class (al quale appartiene). Una volta identificato all'interno della "directory structure" l'item che si intende cambiare o monitorare è necessario collegare un oggetto a quell'item. Per esempio supponiamo di voler cambiare l'account di un utente:

Set objUser = GetObject("WinNT://DOMAIN/UserName")

Dove DOMAIN è il nome del dominio NT e UserName il nome dell'account.

Ora possiamo accedere a quelle sei proprietà fondamentali con la semplice sintassi oggetto.metodo e stamparle a schermo. Siccome ci siamo collegati a un oggetto User abbiamo accesso anche alle proprietà e ai metodi definiti dall'oggetto User ADSI. Il numero di proprietà varia da un "namespace provider" all'altro. In WinNT:// ci sono 48 proprietà e tre metodi; più parametri modificabili di quelli che si trovano nello User Manager.

Un altro aspetto chiave utile da conoscere è come enumerare gli oggetti all'interno di un "container" , ad esempio gli utenti all'interno di un gruppo o i computer all'interno di un dominio. In questo caso il codice cambia leggermente a seconda che gli oggetti "container" siano "members" o "children" del container. Per esempio gli utenti sono "members" di un gruppo mentre i gruppi sono "children" di un dominio.

Il codice per enumerare gli utenti del gruppo Administrators è il seguente:

<HTML>

<BODY>

<%

  Dim oGroup

  Dim oMember

  Set oGroup = GetObject("WinNT://DOMAIN/Administrators")

  For Each oMember in oGroup.Members

  Response.Write oMember.Name & "
"

  Next

%>

</BODY>

</HTML>

Se volessimo la lista dei "children" di un oggetto si tratterebbe di cambiare il ciclo For Each? Next in questa maniera:

Set oContainer = GetObject("WinNT://DOMAIN")

  For Each oChild in oContainer

  Response.Write oChild.Name & "
"

  Next 

Questi sono davvero le due tecniche da capire in una pagina ADSI. Con queste sotto controllo sarà semplicemente una questione di trovare quali proprietà e metodi supporta ogni classe di oggetti. Per far questo si può sia consultare l'help file di ADSI sia scrivere una semplice pagina ASP per enumerare i membri delle proprietà MandatoryProperties and OptionalProperties dello schema per quella classe di oggetto.

Applicazioni possibili

Sembrerebbe che ADSI si orientato all'amministrazione di sistema ? in effetti l'applicazione più ovvia di ADSI è sicuramente la creazione di un kit di amministrazione remota. Comunque integrando ADSI e ADO in ASP (magari mettendoci anche dell'altro) si possono usare tutte le risorse accessibili attraverso ADSI, in qualsiasi "namespace" per numerose applicazioni pratiche. Per esempio:

Intranet Personalizzata: Invece di creare un database utenti con ADO, si può estendere lo "user schema" con proprietà personalizzate e quindi riferirsi a queste informazioni per la personalizzazione dell'intranet ai gusti dell'utente.

Automazione di siti web: Accedendo al "namespace" IIS:// si può creare una pagina per gli utenti che vogliono creare la propria Home Page. Quindi si può usare ADSI o l'oggetto FileSystemObject per creare rispettivamente una nuova virtual directory o una directory fisica dove installare la home page; quindi restituire queste informazioni all'utente spiegando come accedere alla pagina.

Project management: Un sistema può essere configurato in modo che ogni progetto di un azienda venga rappresentato da un oggetto 'ADSI Project' definito nello schema con satus del progetto, report e facts definiti come proprietà dell'oggetto project. Un'altra proprietà potrebbe per esempio puntare a un piccolo database gestito da ADO contente tutte le comunicazioni inerenti quel progetto. Queste comunicazioni potrebbero presentarsi come numerosi e-mail copiati e inseriti nel database usando ADO e CDO.

ADSI a molte più applicazioni possibili di quelle che possono venire in mente. Inoltre - con l'affermarsi di WBEM (Web Based Enterprise Management) il completamento di ADSI per l'"enterprise management" diffuso con il rilascio del Service Pack 4 per NT ? ci si può aspettare una crescita del ruolo di ADSI.

Per saperne di più

ADSI 2.0 è scaricabile dal sito della Microsoft nella sezione Backoffice http://backoffice.microsoft.com/ . Di fatto ADSI si può avere in due distribuzioni ? le runtime libraries e l'SDK per scrivere "provider namespace" personalizzati. Per usare ADSI in ASP bastano le runtime libraries e i file di help che sono distribuiti con queste. Comunque è da notare che gli help file sono pensati per assistere gli sviluppatori che scrivono applicazioni client ADSI in Visual Basic o C++.

Al momento esiste un solo libro sulla programmazione di ADSI nel contesto di un sito web; si tratta di ADSI ASP Programmer's Reference di Steven Hahn (Wrox Press, 1998). Comunque esistono alcuni siti che forniscono documentazione ADSI per esempio 15seconds.com ospita una lista per chi ha problemi con ADSI, sul quale è possibile postare le proprie opinioni. Esiste anche un newsgroup ADSI news://microsoft.public.active.directory.interfaces/ con un flusso continuo di domande e risposte (anche se in realtà non è così pieno di attività come ci si potrebbe aspettare).