dacsauth - En ligne dans le cloud

PROGRAMME:

Nom

dacsauth - vérification d'authentification

SYNOPSIS

dacsauth [-m spécification du module d'authentification] [...] [-r rôles-module-spec] [...] [-Ddirective=Plus-value]
[-aux]
[-fj nom de famille] [-fn nom-fédéral] [-h | -Aide] [-identifiant] [-ll niveau_log]
[-p Mot de passe]
[-pf filet] [-rapide] [-q] [{-u | -utilisateur} Nom d'utilisateur] [-v]
modules dacsauth

DESCRIPTION

Ce programme fait partie du DACS suite.

La dacsauth l'utilitaire teste si le matériel d'authentification donné satisfait à l'authentification
exigences et indique le résultat via le statut de sortie du processus. C'est similaire à
dacs_authentifier(8)[1] et dacscré(1)[2].

dacsauth fournit un moyen aux scripts et autres programmes d'exploiter le DACS authentification
Infrastructure. Ils peuvent utiliser une authentification réussie comme une forme grossière de
autorisation; seul un utilisateur fournissant un mot de passe correct peut être autorisé à exécuter le
programme, par exemple. Ou bien, ils peuvent renvoyer un certain type d'informations d'identification après avoir réussi
authentification, ou peut-être utiliser dacs_auth_agent(8)[3] pour revenir DACS lettres de créance.

dacsauth peut également être utilisé pour récupérer des informations de rôle associées à un utilisateur donné.

dacsauth ne lit rien DACS fichiers de configuration. Tout le nécessaire pour effectuer le test
doit être spécifié comme argument.

Conseil
If dacsauth utilise un module intégré pour effectuer l'authentification ou rechercher des rôles, aucune
serveur composant is conditions. Cela signifie que vous pouvez utiliser dacsauth sans avoir à
accéder ou même configurer un serveur web, notamment Apache.

OPTIONS

Les indicateurs de ligne de commande suivants sont reconnus. Au moins un -m drapeau (pour effectuer
tests d'authentification), ou au moins un -r flag doit être spécifié (pour former un rôle
chaîne de descripteur pour l'identité et imprimez-la sur la sortie standard). Une combinaison des deux drapeaux est
autorisé, auquel cas une chaîne de descripteur de rôle est générée uniquement si le test d'authentification
est réussi.

-Ddirective=Plus-value
Cela équivaut à définir directive, un général DACS directive de configuration, à
Plus-value. Voir dacs.conf(5)[4].

-aux
La chaîne suivante fournie par le -p, -pfou -rapide flag sera la valeur du
AUXILIAIRE argument d'authentification. Cela fournit un moyen sécurisé de transmettre des données sensibles
informations auxiliaires, telles qu'un code PIN, au programme. Un flag pour obtenir le mot de passe,
le cas échéant, doit précéder cet indicateur sur la ligne de commande.

-fj nom de famille
Utilisez nom de famille, qui doit être syntaxiquement valide, comme nom de juridiction. Si nécessaire
mais non fournie, une valeur dérivée du nom de domaine de l'hôte sera utilisée.

-fn nom-fédéral
Utilisez nom-fédéral, qui doit être syntaxiquement valide, comme le nom de la fédération. Si nécessaire
mais non fournie, une valeur dérivée du nom de domaine de l'hôte sera utilisée.

-h
-Aide
Affichez un message d'aide et quittez.

-identifiant
En cas de succès, imprimez le DACS identité à la sortie standard.

-ll niveau_log
Définissez le niveau de sortie de débogage sur niveau_log (voir dac(1)[5]). Le niveau par défaut est
avertir.

-m spécification du module d'authentification
Chaque type de test d'authentification requis est décrit par un spécification du module d'authentification
qui suit immédiatement le -m drapeau. Chaque spécification du module d'authentification est essentiellement un
représentation alternative d'un Auth qui les aurait exempté de leurs obligations si des circonstances hors de leur contrôle les empêchaient de produire le grain sous contrat. [6] et ses directives, qui sont utilisées par
dacs_authentifier(8)[1]. Tout comme l'ordre dans lequel les clauses Auth apparaissent dans un DACS
fichier de configuration, l'ordre dans lequel le -m les drapeaux qui apparaissent peuvent être significatifs,
en fonction de la des bactéries mots clés. Au cours du traitement, successifs -m les composants sont
noms attribués automatiquement, auth_module_1, auth_module_2, etc., principalement pour
à des fins de rapport d’erreurs.

An spécification du module d'authentification a la syntaxe suivante :

La module commence soit par le nom d'un module intégré, soit par une abréviation valide
celui-ci, ou l'URL (absolue) d'un module d'authentification externe (équivalent à
le URL[7] directive). Ensuite doit apparaître un mot-clé de style d'authentification reconnu
spécificateur (équivalent au STYLE[8] directive). Ensuite, le des bactéries le mot-clé suit,
qui est identique au CONTRÔLE[9] directive dans la clause Auth. Après le des bactéries
mot-clé, les indicateurs décrits ci-dessous peuvent suivre, dans n'importe quel ordre.

An spécification du module d'authentification se termine lorsque le premier flag invalide (ou la fin des flags) est
rencontré.

La -O le drapeau équivaut à un OPTION[10] directive.

La -De flag est suivi d'un argument qui est le nom d'un fichier à partir duquel lire
options, une par ligne, au format prénom=Plus-value. Lignes vides et lignes commençant par
un '#' est ignoré ; notez que ces lignes ne commencent pas par "-O" et les guillemets sont simplement
copié et non interprété. Le -De le drapeau peut être utilisé pour éviter de mettre des mots de passe
la ligne de commande et facilite l'écriture d'expressions qui autrement auraient
à éviter soigneusement pour empêcher l'interprétation par le shell, par exemple.

La -expr le drapeau est équivalent au EXPR[11] directive. Le -vfs le drapeau est utilisé pour
configurer VFS[12] directives requises par ce module.

-modules
Afficher une liste des modules d'authentification et des modules de rôles intégrés, un par ligne, et
puis sortez. Le nom canonique du module est imprimé, suivi de zéro ou plusieurs équivalents
abréviations. Pour les modules d'authentification, le style d'authentification est affiché. Lister
les modules disponibles, exécutez la commande :

% dacsauth-modules

L'ensemble des modules d'authentification et de rôles intégrés disponibles (activés) est déterminé
quand DACS est construit.

-p Mot de passe
Précisez le mot de passe à utiliser (équivalent au MOT DE PASSE argument
dacs_authentifier).

Sécurité
Un mot de passe donné sur la ligne de commande peut être visible par d'autres utilisateurs sur le même
système.

-pf filet
Lire le mot de passe à utiliser à partir de filet (équivalent au MOT DE PASSE argument
dacs_authentifier). Si filet est "-", alors le mot de passe est lu à partir de l'entrée standard
sans incitation.

-rapide
Demander le mot de passe et le lire depuis stdin (équivalent au MOT DE PASSE argument
dacs_authentifier). Le mot de passe n'est pas repris.

-q
Soyez plus silencieux en réduisant le niveau de sortie du débogage.

-r spécification du module de rôle
Rôles pour Nom d'utilisateur peut être déterminé en donnant ce drapeau, qui est immédiatement
suivie d'une rôles-module-specL’ -r le drapeau peut être répété, et les rôles résultants
sont combinés. Chaque rôles-module-spec est essentiellement une représentation alternative d'un
Clause de rôles utilisée par dacs_authentifier(8)[13]. Successif -r les composants sont
noms attribués, rôles_module_1, rôles_module_2, etc., principalement pour le rapport d'erreurs
fins pratiques.

A rôles-module-spec a la syntaxe suivante :

La module Le composant est équivalent au composant Roles de la clause URL[14] directive et est
soit le nom d'un module de rôles intégré disponible, une abréviation valide de celui-ci,
ou l'URL (absolue) d'un module de rôles externes.

Les drapeaux peuvent suivre le module composant, dans n’importe quel ordre. UN rôles-module-spec se termine quand
le premier indicateur invalide (ou la fin des indicateurs) est rencontré.

La -O le drapeau équivaut à un OPTION[10] directive.

La -De flag est suivi d'un argument qui est le nom d'un fichier à partir duquel lire
options, une par ligne, au format prénom=Plus-value. Lignes vides et lignes commençant par
un '#' est ignoré ; notez que ces lignes ne commencent pas par "-O" et les guillemets sont simplement
copié et non interprété. Le -De le drapeau peut être utilisé pour éviter de mettre des mots de passe
la ligne de commande et facilite l'écriture d'expressions qui autrement auraient
à éviter soigneusement pour empêcher l'interprétation par le shell, par exemple.

La -expr le drapeau est équivalent au EXPR[11] directive. Le -vfs le drapeau est utilisé pour
configurer VFS[12] directives exigées par module.

-u Nom d'utilisateur
-utilisateur Nom d'utilisateur
Le nom d'utilisateur avec lequel s'authentifier (équivalent au USERNAME argument
dacs_authentifier). Ce nom d'utilisateur est implicitement associé au nom d'utilisateur effectif
fédération et juridiction (voir le -fn[15] et -fj[16] drapeaux).

-v
La -v flag augmente le niveau de sortie de débogage pour déboguer ou (si répété) trace.

EXEMPLES

Sécurité
If dacsauth utilise un module intégré pour effectuer l'authentification, il doit exécuter setuid ou
setgid pour obtenir des privilèges suffisants pour accéder au fichier de mot de passe requis (le même
est vrai pour les modules de rôles intégrés). S'il utilise un module externe, ce module sera
besoin d'exécuter avec des privilèges suffisants pour accéder DACS clés cryptographiques,
spécifiquement Federation_keys et éventuellement DACS ou des fichiers de mots de passe système ; l'extérieur
Le module devra alors s'exécuter avec des privilèges suffisants pour accéder à tous les fichiers qu'il
a besoin.

Assurez-vous d'utiliser les Federation_keys qui sont corrects pour votre fédération. Référencement
les modules d'authentification dans deux fédérations ou plus ne fonctionneront probablement pas.

dacsauth ne devrait donc normalement pas s'exécuter en tant qu'UID de l'utilisateur qui l'invoque
(sauf si c'est root) car il ne pourra pas accéder aux informations
cela demande. Cela empêchera également un utilisateur de « tricher » (par exemple, en s'attachant au
module en cours d'exécution avec un débogueur).

Cet exemple authentifie l'utilisateur "bobo" avec le mot de passe "test" auprès du DACS fichier de mot de passe
/usr/local/dacs/conf/passwd :

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

Si l'état de sortie de la commande est zéro, le test d'authentification a réussi, sinon il
échoué.

L'exemple suivant tente d'authentifier "bobo" par rapport à son fichier de mots de passe Unix. Le
le programme demande le mot de passe.

% dacsauth -m mot de passe unix requis -u bobo -prompt

Dans l'exemple suivant, dacsauth tente d'authentifier "bobo" via NTLM sur
winders.exemple.com :

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

Cet exemple est similaire au précédent, sauf qu'un module d'authentification externe
est utilisé et le mot de passe est lu à partir d'un fichier. En raison du module externe, des
la configuration doit être fournie ; en particulier, l'emplacement de Federation_keys et le
Les noms des fédérations et des juridictions doivent être précisés.

% dacsauth -m https://example.example.com/cgi-bin/dacs/local_ntlm_authenticate \
mot de passe suffisant -OSAMBA_SERVER="winders.example.com" \
-fn EXEMPLE -fj FEDROOT -u bobo -pf monpass \
-DVFS="[federation_keys]dacs-fs:/usr/local/dacs/federations/example/federation_keys"

Pour s'authentifier auprès du Google[17] compte [email protected], on pourrait utiliser :

% dacsauth -m http mot de passe suff \
-OAUTH_URL="https://www.google.com/accounts/ClientLogin" \
-OUSERNAME_PARAMETER=Email -OPASSWORD_PARAMETER=Mot de passe \
-Oservice=xapi -Osource=DSS-DACS-1.4 -prompt -u [email protected]

Dans l'exemple suivant, une expression est évaluée pour déterminer si l'authentification
devrait réussir. L'utilisateur ("bobo") est invité à saisir un mot de passe. Seulement si la chaîne "foo" est
étant donné, l'authentification réussira. Un exemple plus réaliste pourrait appeler un autre programme pour
aider à prendre la décision, par exemple.

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

Authentification contre un Apache résumé le fichier de mot de passe est effectué dans ce qui suit
exemple, où le mot de passe est lu depuis stdin :

% écho "test" | dacsauth -m apache digest suffisant \
-OAUTH_MODULE=mod_auth_digest\
-OAUTH_FILE=/usr/local/apache2/conf/passwords.digest \
-OAUTH_REALM="Zone d'authentification DACS Digest" \
-u bobo -pf -

L'authentification via le module PAM fonctionne différemment des autres modules - et est plus
compliqué à utiliser - parce que dacsauth il faudra peut-être l'exécuter plusieurs fois, en fonction de ce qui
informations requises par PAM. Au lieu de renvoyer une décision oui/non, dacsauth peut imprimer
demande plus d'informations sur la sortie standard. Veuillez consulter les détails opérationnels présentés dans
dacs_authentifier(8)[18] et pamd(8)[19] avant d'essayer d'utiliser ce module.

L'exemple suivant montre l'utilisation du module à partir de la ligne de commande. Une fois la base
les idées sont comprises, il devrait être évident comment écrire un script pour exécuter le
itérations nécessaires. Les détails de l'exemple, tels que les chemins, devront peut-être être ajustés pour
votre environnement. Notez que dans cet exemple, le nom d'utilisateur n'est pas spécifié la première fois
dacsauth est exécuté, même si cela pourrait l'être s'il était connu.

% dacsauth -m pam demandé suffic \
-vfs "[federation_keys]dacs-fs:/usr/local/dacs/federations/dss/federation_keys" \
-OPAMD_HOST=localhost -OPAMD_PORT=dacs-pamd -fj EXEMPLE -fn TEST
AUTH_PROMPT_VAR1="Connexion :"
AUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"
% dacsauth -m pam demandé suffic \
-vfs "[federation_keys]dacs-fs:/usr/local/dacs/federations/dss/federation_keys" \
-OAUTH_PROMPT_VAR1="bobo" \
-OAUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"-fj EXAMPLE -fn TEST
AUTH_PROMPT_VAR2="Mot de passe :"
AUTH_TRANSID="10.0.0.124:52188:88417:5ffb0015f21ea546"
% dacsauth -m pam demandé suffic \
-vfs "[federation_keys]dacs-fs:/usr/local/dacs/federations/dss/federation_keys" \
-OAUTH_PROMPT_VAR2="un mot de passe" \
-OAUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"-fj EXAMPLE -fn TEST

La première fois dacsauth est exécuté dans l'exemple, il renvoie une invite pour le nom d'utilisateur
("Connexion :") associé à la variable de transaction AUTH_PROMPT_VAR1 et
identifiant de transaction (AUTH_TRANSID). Ce dernier doit être transmis au suivant
exécutions de dacsauth. La deuxième série de dacsauth passe le nom d'utilisateur ("bobo") et
renvoie une autre invite (« Mot de passe : ») associée à la variable de transaction
AUTH_PROMPT_VAR2. La troisième exécution transmet le mot de passe ("apassword") mais aucune invite n'est
renvoyé, indiquant que la session est terminée et que l'état de sortie du programme reflète
le résultat de l’authentification.

Conseil
Si dacsauth nécessite un mot de passe pour récupérer les rôles dépend des rôles particuliers
module utilisé. Par exemple, un mot de passe n'est pas requis par local_unix_roles[20] ou
rôles_locals[21] pour obtenir des rôles, mais local_ldap_roles[22] aura probablement besoin d'un
mot de passe pour se lier au répertoire et obtenir des rôles.

Cet exemple imprime la chaîne de rôle pour l'utilisateur "bobo" en appelant la fonction intégrée
local_unix_roles[20] modules :

% dacsauth -r unix -u bobo
bobo, roue, www, utilisateurs

L'exemple suivant est similaire au précédent, sauf qu'un module de rôles externes est utilisé :

% dacsauth -r https://example.example.com/cgi-bin/dacs/local_unix_roles \
-DVFS="[federation_keys]dacs-fs:/usr/local/dacs/federations/federation_keys" \
-fn EXEMPLE -u bobo
bobo, roue, www, utilisateurs

Le module de rôles externes peut être exécuté sur un hôte différent de celui qui exécute
dacsauth. Fourni dacsauth a été installé et un fichier Federation_keys correspondant est
disponible sur l'hôte local, l'hôte local n'a pas besoin d'être un DACS juridiction ou avoir tout
autre DACS configuration.

L'exemple suivant imprime le rôle de l' un magnifique[23] pour l'utilisateur "bobo", connu au sein du
répertoire sous le nom commun "Bobo Baggins", en utilisant le (externe) local_ldap_roles
module et la méthode de liaison "directe":

% dacsauth -r https://example.example.com/cgi-bin/dacs/local_ldap_roles \
-Of /usr/local/dacs/ldap_roles_options_direct -u "Bobo Baggins" \
-DVFS="[federation_keys]dacs-fs:/usr/local/dacs/federations/federation_keys" \
-fn EXEMPLE -fj FEDROOT -invite
Administrateurs DNS, opérateurs d'impression, administrateurs de domaine, administrateurs

Parce qu'il y a trop d'indicateurs pour les placer facilement et correctement sur la ligne de commande, le
les options nécessaires pour ce faire sont lues à partir d'un fichier spécifié par le -De drapeau.
Cela fournit également un moyen plus sécurisé de transmettre les mots de passe au programme ; garantir que l'accès
au fichier est restreint de manière appropriée. Le fichier
/usr/local/dacs/ldap_roles_options_direct peut contenir une configuration telle que celle-ci :

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

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

L'exemple suivant est comme le précédent, sauf qu'il utilise la liaison "indirecte"
méthode et n'a donc pas besoin de recevoir le nom commun de l'utilisateur :

% dacsauth -r https://example.example.com/cgi-bin/dacs/local_ldap_roles \
-Of /usr/local/dacs/ldap_roles_options_indirect -u bobo \
-DVFS="[federation_keys]dacs-fs:/usr/local/dacs/federations/federation_keys" \
-fn EXEMPLE -fj FEDROOT -p mot de passe bobos
Administrateurs DNS, opérateurs d'impression, administrateurs de domaine, administrateurs

Le fichier /usr/local/dacs/ldap_roles_options_indirect peut contenir une configuration telle que
ce:

LDAP_BIND_METHOD=indirect
LDAP_ADMIN_URL=ldap://winders.example.com/CN=Administrator,CN=Users,DC=example,DC=com

# Rechercher sous Utilisateurs...
LDAP_SEARCH_ROOT_DN=CN=Utilisateurs,DC=exemple,DC=com

LDAP_ADMIN_PASSWORD=le mot de passe administrateur secret
LDAP_SEARCH_FILTER*="(sAMAccountName=${Args::DACS_USERNAME})"
LDAP_ROLES_SELECTOR*="${LDAP::attrname}" eq "memberOf" ? strtr(ldap(rdn_attrvalue, \
ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""

Supposons que l'on veuille utiliser dacsauth pour authentifier un utilisateur via LDAP d'une manière analogue à
cette configuration dacs.conf :


URL "http://example.example.com/cgi-bin/dacs/local_ldap_authenticate"
STYLE "mot de passe, ajouter_rôles"
CONTROLE "obligatoire"
LDAP_BIND_METHOD "direct"
LDAP_USERNAME_URL* '"ldap://winders.example.com/cn=" . encode(url, ${Args::USERNAME}) . ",cn=Utilisateurs,dc=exemple,dc=local"'
LDAP_USERNAME_EXPR* '"${LDAP::sAMAccountName}"'
LDAP_ROLES_SELECTOR* '"${LDAP::attrname}" eq "memberOf" \
? strtr(ldap(rdn_attrvalue, ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""'


Un fichier comme celui-ci (par exemple, /usr/local/dacs/ldap_auth_options_direct) contiendrait le
directives suivantes :

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

L'authentification pourrait alors être effectuée à l'aide d'une commande comme celle-ci :

% dacsauth -fj FEDROOT -m http://example.example.com/cgi-bin/dacs/local_ldap_authenticate mot de passe suffisent \
-De /usr/local/dacs/ldap_auth_options_direct \
-DVFS="[federation_keys]dacs-fs:/usr/local/dacs/federations/federation_keys" \
-fn EXEMPLE -u bobo -prompt

DIAGNOSTIC

Le programme quitte 0 si l'authentification a réussi ou par 1 si l'authentification a échoué ou
une erreur s'est produite.

Utilisez dacsauth en ligne à l'aide des services onworks.net