dacsauth - Online nel cloud

PROGRAMMA:

NOME

dacsauth - controllo di autenticazione

SINOSSI

dacsauth [-m auth-modulo-spec] [...] [-r ruoli-modulo-spec] [...] [-DDirettive=APPREZZIAMO]
[-Agli]
[-fj cognome] [-fn nome di fede] [-h | -Aiuto] [-ID] [-LL log_level]
[-p parola d'ordine]
[-pf filetto] [-richiesta] [-q] [{-u | -utente} nome utente] [-v]
dacsauth-moduli

DESCRIZIONE

Questo programma fa parte di DACS on.

I dacsauth l'utilità verifica se il materiale di autenticazione fornito soddisfa l'autenticazione
requisiti e indica l'esito attraverso lo stato di uscita del processo. È simile a
dacs_autenticate(8)[1] e daccred(1)[2].

dacsauth fornisce un modo per gli script e altri programmi di sfruttare il DACS autenticazione
infrastruttura. Potrebbero usare l'autenticazione di successo come una forma grossolana di
autorizzazione; solo un utente che fornisce una password corretta potrebbe essere autorizzato a eseguire il
programma, per esempio. Oppure potrebbero restituire qualche tipo di credenziali dopo l'esito positivo
autenticazione, o forse uso dacs_auth_agent(8)[3] per tornare DACS credenziali.

dacsauth può essere utilizzato anche per recuperare informazioni sui ruoli associate a un determinato utente.

dacsauth non legge nessuno DACS file di configurazione. Tutto il necessario per eseguire il test
deve essere specificato come argomento.

Consiglio
If dacsauth utilizza un modulo integrato per eseguire l'autenticazione o cercare ruoli, no
server componente is necessario. Questo significa che puoi usare dacsauth senza dover
accedere o persino configurare un server Web, incluso Apache.

VERSIONI

Vengono riconosciuti i seguenti flag della riga di comando. Almeno uno -m bandiera (per eseguire
test di autenticazione), o almeno uno -r flag deve essere specificato (per formare un ruolo
stringa descrittiva per l'identità e stamparla su stdout). Una combinazione di entrambe le bandiere è
consentito, nel qual caso viene emessa una stringa di descrizione del ruolo solo se il test di autenticazione
ha successo

-DDirettive=APPREZZIAMO
Questo è equivalente a impostare Direttive, un generale DACS direttiva di configurazione, a
APPREZZIAMO. Vedere dacs.conf(5)[4].

-Agli
La stringa successiva fornita da -p, -pf, o -richiesta flag sarà il valore di
AUSILIARIO argomento di autenticazione. Questo fornisce un modo sicuro per passare sensibili
informazioni ausiliarie, come un PIN, al programma. Un flag per ottenere la password,
se presente, deve precedere questo flag sulla riga di comando.

-fj cognome
Usa il cognome, che deve essere sintatticamente valido, come nome della giurisdizione. Se richiesto
ma non fornito, verrà utilizzato un valore derivato dal nome di dominio dell'host.

-fn nome di fede
Usa il nome di fede, che deve essere sintatticamente valido, come nome della federazione. Se richiesto
ma non fornito, verrà utilizzato un valore derivato dal nome di dominio dell'host.

-h
-Aiuto
Visualizza un messaggio di aiuto ed esci.

-ID
In caso di successo, stampa l'autenticato DACS identità allo standard output.

-LL log_level
Imposta il livello di output del debug su log_level (Vedi dac(1)[5]). Il livello predefinito è
avvisare.

-m auth-modulo-spec
Ogni tipo di test di autenticazione richiesto è descritto da un auth-modulo-spec
che segue immediatamente il -m bandiera. Ogni auth-modulo-spec è essenzialmente un
rappresentazione alternativa di an auth clausola[6] e le sue direttive, utilizzate da
dacs_autenticate(8)[1]. Proprio come l'ordine in cui le clausole Auth appaiono in a DACS
file di configurazione, l'ordine in cui -m i flag visualizzati possono essere significativi,
dipende da di controllo parole chiave. Durante la lavorazione, successive -m i componenti sono
nomi assegnati automaticamente, auth_module_1, auth_module_2 e così via, principalmente per
finalità di segnalazione degli errori.

An auth-modulo-spec ha la seguente sintassi:

I modulo inizia con il nome di un modulo integrato o con un'abbreviazione valida
della stessa, o l'URL (assoluto) di un modulo di autenticazione esterno (equivalente a
, il URL[7] direttiva). Successivamente deve apparire una parola chiave di stile di autenticazione riconosciuta
specificatore (equivalente a STILE[8] direttiva). Successivamente, il di controllo segue la parola chiave,
che è identico a CONTROLLO[9] direttiva nella clausola Auth. Dopo il di controllo
parola chiave, i flag descritti di seguito possono seguire, in qualsiasi ordine.

An auth-modulo-spec termina quando il primo flag non valido (o la fine dei flag) è
incontrato.

I -O flag è equivalente ad an OPZIONE[10] direttiva.

I -Di flag è seguito da un argomento che è il nome di un file da cui leggere
opzioni, una per riga, nel formato Nome=APPREZZIAMO. Righe vuote e righe che iniziano con
un '#' viene ignorato; nota che queste righe non iniziano con "-O" e le virgolette sono semplicemente
copiato e non interpretato. Il -Di flag può essere utilizzato per evitare di inserire password
la riga di comando e rende più facile scrivere espressioni che altrimenti avrebbero
da sfuggire con attenzione per impedire l'interpretazione da parte della shell, ad esempio.

I -espr flag è equivalente a ESPR[11] direttiva. Il -vfs la bandiera è usata per
configure VFS[12] direttive richieste da questo modulo.

-moduli
Visualizza un elenco di moduli di autenticazione integrati e moduli di ruoli, uno per riga e
poi esci. Viene stampato il nome del modulo canonico, seguito da zero o più equivalenti
abbreviazioni. Per i moduli di autenticazione, viene mostrato lo stile di autenticazione. Elencare
i moduli disponibili, eseguire il comando:

% dacsauth -moduli

Viene determinato il set di moduli di autenticazione e ruoli integrati disponibili (abilitati)
quando DACS è costruito.

-p parola d'ordine
Specificare la password da utilizzare (equivalente al PASSWORD argomento a
dacs_autenticate).

Sicurezza
Una password fornita sulla riga di comando potrebbe essere visibile ad altri utenti sulla stessa
.

-pf filetto
Leggi la password da usare da filetto (equivalente a PASSWORD argomento a
dacs_autenticate). Se filetto è "-", quindi la password viene letta dall'input standard
senza chiedere.

-richiesta
Richiedi la password e leggila da stdin (equivalente a PASSWORD argomento a
dacs_autenticate). La password non viene ripetuta.

-q
Sii più silenzioso riducendo il livello di output del debug.

-r specifica del modulo di ruolo
Ruoli per nome utente può essere determinato dando questo flag, che è immediatamente
seguita da una ruoli-modulo-spec. -r flag può essere ripetuto, e i ruoli risultanti
sono combinati. Ogni ruoli-modulo-spec è essenzialmente una rappresentazione alternativa di a
Clausola dei ruoli utilizzata da dacs_autenticate(8)[13]. Successivo -r i componenti sono
nomi assegnati, role_module_1, role_module_2 e così via, principalmente per la segnalazione degli errori
scopi.

A ruoli-modulo-spec ha la seguente sintassi:

I modulo componente è equivalente alla clausola Roles URL[14] direttiva ed è
o il nome di un modulo di ruoli integrato disponibile, una sua abbreviazione valida,
o l'URL (assoluto) di un modulo dei ruoli esterni.

Le bandiere possono seguire il modulo componente, in qualsiasi ordine. UN ruoli-modulo-spec finisce quando
si incontra il primo flag non valido (o la fine dei flag).

I -O flag è equivalente ad an OPZIONE[10] direttiva.

I -Di flag è seguito da un argomento che è il nome di un file da cui leggere
opzioni, una per riga, nel formato Nome=APPREZZIAMO. Righe vuote e righe che iniziano con
un '#' viene ignorato; nota che queste righe non iniziano con "-O" e le virgolette sono semplicemente
copiato e non interpretato. Il -Di flag può essere utilizzato per evitare di inserire password
la riga di comando e rende più facile scrivere espressioni che altrimenti avrebbero
da sfuggire con attenzione per impedire l'interpretazione da parte della shell, ad esempio.

I -espr flag è equivalente a ESPR[11] direttiva. Il -vfs la bandiera è usata per
configure VFS[12] direttive richieste da modulo.

-u nome utente
-utente nome utente
Il nome utente su cui autenticarsi (equivalente a USERNAME argomento a
dacs_autenticate). Questo nome utente è implicitamente associato all'effettivo
federazione e giurisdizione (cfr -fn[15] e -fj[16] bandiere).

-v
I -v flag sposta il livello di output del debug per eseguire il debug o (se ripetuto) per tracciare.

ESEMPI

Sicurezza
If dacsauth utilizza un modulo integrato per eseguire l'autenticazione, deve eseguire setuid o
setgid per ottenere privilegi sufficienti per accedere al file di password richiesto (lo stesso
è vero per i moduli dei ruoli incorporati). Se utilizza un modulo esterno, quel modulo lo farà
necessità di eseguire con privilegi sufficienti per accedere DACS chiavi crittografiche,
in particolare federation_keys e possibilmente DACS o file di password di sistema; l'esterno
modulo dovrà quindi essere eseguito con privilegi sufficienti per accedere a qualsiasi file
richiede.

Assicurati di utilizzare le federation_keys corrette per la tua federazione. riferimento
i moduli di autenticazione in due o più federazioni probabilmente non funzioneranno.

dacsauth non dovrebbe quindi essere normalmente eseguito come UID dell'utente che lo invoca
(a meno che non sia root) perché non sarà in grado di accedere alle informazioni
richiede. Ciò impedirà anche a un utente di "barare" (ad esempio, collegandosi al
modulo in esecuzione con un debugger).

Questo esempio autentica l'utente "bobo" con la password "test" rispetto al DACS file di password
/usr/local/dacs/conf/passwd:

% dacsauth -m passwd passwd richiesto
-vfs "[passwds]dacs-kwv-fs:/usr/local/dacs/conf/passwd" -q -u bobo -p test

Se lo stato di uscita del comando è zero, il test di autenticazione è riuscito, altrimenti
fallito.

L'esempio seguente tenta di autenticare "bobo" con il suo file di password Unix. Il
programma richiede la password.

% dacsauth -m unix passwd richiesto -u bobo -prompt

Nel prossimo esempio, dacsauth tenta di autenticare "bobo" tramite NTLM su
winders.esempio.com:

% dacsauth -m ntlm passwd suff -OSAMBA_SERVER="winders.example.com" -prompt -u bobo

Questo esempio è simile al precedente, tranne per il modulo di autenticazione esterno
viene utilizzato e la password viene letta da un file. A causa del modulo esterno, aggiuntivo
deve essere fornita la configurazione; in particolare, la posizione di federation_keys e il
i nomi delle federazioni e delle giurisdizioni devono essere specificati.

% dacsauth -m https://example.example.com/cgi-bin/dacs/local_ntlm_authenticate \
passwd sufficiente -OSAMBA_SERVER="winders.example.com" \
-fn ESEMPIO -fj FEDROOT -u bobo -pf miopass \
-DVFS="[chiavi_federazione]dacs-fs:/usr/local/dacs/federations/example/chiavi_federazione"

Per autenticarsi contro il Google[17] conto [email protected], si potrebbe usare:

% dacsauth -m http passwd suff \
-OAUTH_URL="https://www.google.com/accounts/ClientLogin" \
-OUSERNAME_PARAMETER=E-mail -OPASSWORD_PARAMETER=Passwd \
-Oservice=xapi -Osource=DSS-DACS-1.4 -prompt -u [email protected]

Nell'esempio seguente, viene valutata un'espressione per determinare se l'autenticazione
dovrebbe riuscire. All'utente ("bobo") viene richiesta una password. Solo se la stringa "pippo" è
data l'autenticazione avrà esito positivo. Un esempio più realistico potrebbe chiamare un altro programma a
aiutare a prendere la decisione, per esempio.

% dacsauth -m espressione espressione suffi \
-expr '${Args::PASSWORD} eq "pippo" ? ${Args::USERNAME} : ""' -user bobo -prompt

Autenticazione contro un Apache htdigest il file della password viene eseguito nel modo seguente
esempio, dove la password viene letta da stdin:

% echo "test" | dacsauth -m apache digest sufficiente \
-OAUTH_MODULE=mod_auth_digest \
-OAUTH_FILE=/usr/local/apache2/conf/passwords.digest \
-OAUTH_REALM="Area di autenticazione digest DACS" \
-u bobo -pf-

L'autenticazione tramite il modulo PAM funziona in modo diverso rispetto agli altri moduli - ed è più
complicato da usare - perché dacsauth potrebbe essere necessario eseguire più volte, a seconda di cosa
informazioni richieste da PAM. Invece di restituire una decisione sì/no, dacsauth può stampare
richiede ulteriori informazioni a stdout. Si prega di rivedere i dettagli operativi presentati in
dacs_autenticate(8)[18] e pmd(8)[19] prima di tentare di utilizzare questo modulo.

L'esempio seguente mostra l'utilizzo del modulo dalla riga di comando. Una volta che la base
le idee sono comprese, dovrebbe essere evidente come scrivere uno script per eseguire il
iterazioni necessarie. Potrebbe essere necessario modificare i dettagli nell'esempio, ad esempio i percorsi
il tuo ambiente. Nota che in questo esempio il nome utente non è specificato la prima volta
dacsauth viene eseguito, anche se potrebbe esserlo se fosse noto.

% dacsauth -m pam richiesto suffic \
-vfs "[chiavi_federazione]dacs-fs:/usr/local/dacs/federations/dss/chiavi_federazione" \
-OPAMD_HOST=localhost -OPAMD_PORT=dacs-pamd -fj ESEMPIO -fn TEST
AUTH_PROMPT_VAR1="Accedi:"
AUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"
% dacsauth -m pam richiesto suffic \
-vfs "[chiavi_federazione]dacs-fs:/usr/local/dacs/federations/dss/chiavi_federazione" \
-OAUTH_PROMPT_VAR1="bobo" \
-OAUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"-fj EXAMPLE -fn TEST
AUTH_PROMPT_VAR2="Password:"
AUTH_TRANSID="10.0.0.124:52188:88417:5ffb0015f21ea546"
% dacsauth -m pam richiesto suffic \
-vfs "[chiavi_federazione]dacs-fs:/usr/local/dacs/federations/dss/chiavi_federazione" \
-OAUTH_PROMPT_VAR2="unapassword" \
-OAUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"-fj EXAMPLE -fn TEST

La prima volta dacsauth viene eseguito nell'esempio restituisce un prompt per il nome utente
("Login:") associato alla variabile di transazione AUTH_PROMPT_VAR1 e
identificatore della transazione (AUTH_TRANSID). Quest'ultimo deve essere passato al successivo
esecuzioni di dacsauth. La seconda corsa di dacsauth passa il nome utente ("bobo") e
restituisce un altro prompt ("Password:") associato alla variabile di transazione
AUTH_PROMPT_VAR2. La terza esecuzione passa la password ("apassword") ma non viene visualizzato alcun prompt
restituito, indicando che la sessione è completa e lo stato di uscita del programma riflette
l'esito dell'autenticazione.

Consiglio
Se dacsauth richiede una password per recuperare i ruoli dipende dai ruoli particolari
modulo in uso. Ad esempio, una password non è richiesta da ruoli_unix locali[20] o
ruoli_locali[21] per ottenere ruoli, ma ruoli_locali_ldap[22] probabilmente avrà bisogno di un
password da associare alla directory e ottenere i ruoli.

Questo esempio stampa la stringa del ruolo per l'utente "bobo" chiamando il built-in
ruoli_unix locali[20] modulo:

% dacsauth -r unix -u bobo
bobo,ruota,www,utenti

L'esempio successivo è simile al precedente, tranne per il fatto che viene utilizzato un modulo di ruoli esterni:

% dacsauth -r https://example.example.com/cgi-bin/dacs/local_unix_roles \
-DVFS="[chiavi_federazione]dacs-fs:/usr/local/dacs/federations/chiavi_federazione" \
-fn ESEMPIO -u bobo
bobo,ruota,www,utenti

Il modulo dei ruoli esterni potrebbe essere eseguito su un host diverso da quello in esecuzione
dacsauth. Fornito dacsauth è stato installato ed è presente un file federation_keys corrispondente
disponibile sull'host locale, non è necessario che l'host locale sia a DACS giurisdizione o avere qualsiasi
Altro DACS configurazione.

L'esempio seguente stampa il ruolo stringa[23] per l'utente "bobo", noto all'interno del
directory dal nome comune "Bobo Baggins", utilizzando il (esterno) ruoli_locali_ldap,
modulo e il metodo di associazione "diretto":

% dacsauth -r https://example.example.com/cgi-bin/dacs/local_ldap_roles \
-Of /usr/local/dacs/ldap_roles_options_direct -u "Bobo Baggins" \
-DVFS="[chiavi_federazione]dacs-fs:/usr/local/dacs/federations/chiavi_federazione" \
-fn ESEMPIO -fj FEDROOT -prompt
DnsAdmins,Print_Operators,Domain_Admins,Administrati

Poiché ci sono troppi flag da posizionare facilmente e correttamente sulla riga di comando, il
le opzioni necessarie per farlo vengono lette da un file specificato da -Di bandiera.
Ciò fornisce anche un modo più sicuro per passare le password al programma; garantire che l'accesso
al file è limitato in modo appropriato. Il file
/usr/local/dacs/ldap_roles_options_direct potrebbe contenere una configurazione come questa:

LDAP_BIND_METHOD=diretto
LDAP_ADMIN_URL*="ldap://winders.example.com/CN=" . encode(url,${Args::DACS_USERNAME}) . ",CN=Utenti,DC=esempio,DC=com"

LDAP_ROLES_SELECTOR*="${LDAP::attrname}" eq "memberOf" ? strtr(ldap(rdn_attrvalue, \
ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""

L'esempio seguente è come il precedente, tranne per il fatto che utilizza il legame "indiretto"
metodo e quindi non è necessario assegnare il nome comune dell'utente:

% dacsauth -r https://example.example.com/cgi-bin/dacs/local_ldap_roles \
-Di /usr/local/dacs/ldap_roles_options_indirect -u bobo \
-DVFS="[chiavi_federazione]dacs-fs:/usr/local/dacs/federations/chiavi_federazione" \
-fn ESEMPIO -fj FEDROOT -p bobospassword
DnsAdmins,Print_Operators,Domain_Admins,Administrati

Il file /usr/local/dacs/ldap_roles_options_indirect potrebbe contenere configurazioni come
Questo:

LDAP_BIND_METHOD=indiretto
LDAP_ADMIN_URL=ldap://winders.example.com/CN=Amministratore,CN=Utenti,DC=esempio,DC=com

# Cerca in Utenti...
LDAP_SEARCH_ROOT_DN=CN=Utenti,DC=esempio,DC=com

LDAP_ADMIN_PASSWORD=la password amministratore segreta
LDAP_SEARCH_FILTER*="(sAMAccountName=${Args::DACS_USERNAME})"
LDAP_ROLES_SELECTOR*="${LDAP::attrname}" eq "memberOf" ? strtr(ldap(rdn_attrvalue, \
ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""

Supponiamo che uno volesse usare dacsauth autenticare un utente tramite LDAP in modo analogo a
questa configurazione dacs.conf:


URL"http://example.example.com/cgi-bin/dacs/local_ldap_authenticate"
STILE "password,aggiungi_ruoli"
CONTROLLO "richiesto"
LDAP_BIND_METHOD "diretto"
LDAP_USERNAME_URL* '"ldap://winders.example.com/cn=" . encode(url, ${Args::USERNAME}) . ",cn=Utenti,dc=esempio,dc=locale"'
LDAP_USERNAME_EXPR* '"${LDAP::sAMAccountName}"'
LDAP_ROLES_SELECTOR* '"${LDAP::attrname}" eq "memberOf" \
? strtr(ldap(rdn_attrvalue, ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""'


Un file come questo (es. /usr/local/dacs/ldap_auth_options_direct) conterrebbe il
seguenti direttive:

LDAP_BIND_METHOD=diretto
LDAP_USERNAME_URL*="ldap://winders.example.com/cn=" . encode(url, ${Args::USERNAME}) . ",cn=Utenti,dc=esempio,dc=locale"
LDAP_USERNAME_EXPR*="${LDAP::sAMAccountName}"
LDAP_ROLES_SELECTOR*="${LDAP::attrname}" eq "memberOf" \
? strtr(ldap(rdn_attrvalue, ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""

L'autenticazione potrebbe quindi essere eseguita utilizzando un comando come questo:

% dacsauth -fj FEDROOT -m http://example.example.com/cgi-bin/dacs/local_ldap_authenticate passwd suff \
-Di /usr/local/dacs/ldap_auth_options_direct \
-DVFS="[chiavi_federazione]dacs-fs:/usr/local/dacs/federations/chiavi_federazione" \
-fn ESEMPIO -u bobo -prompt

DIAGNOSTICA

Il programma esce 0 se l'autenticazione ha avuto successo o con 1 se l'autenticazione non è riuscita o
si è verificato un errore.

Utilizzare dacsauth online utilizzando i servizi onworks.net