dacsauth - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

dacsauth - Authentifizierungsprüfung

ZUSAMMENFASSUNG

dacsauth [-m Authentifizierungsmodul-Spezifikation] [...] [-r Rollen-Modul-Spezifikation] [...] [-DRichtlinien=Wert]
[-zu]
[-fj Jurname] [-fn Fedname] [-h | -Hilfe] [-id] [-NS log_level]
[-p Passwort]
[-pf Datei] [-prompt] [-q] [{-u | -Benutzer} Benutzername] [-v]
dacsauth-Module

BESCHREIBUNG

Dieses Programm ist Teil des DACS Suite.

Das dacsauth Utility testet, ob das angegebene Authentifizierungsmaterial die Authentifizierung erfüllt
Anforderungen und zeigt das Ergebnis durch den Exit-Status des Prozesses an. Es ist ähnlich wie
dacs_authenticate(8)[1] und dacscred(1)[2].

dacsauth bietet eine Möglichkeit für Skripte und andere Programme, die DACS Beglaubigung
Infrastruktur. Sie könnten eine erfolgreiche Authentifizierung als grobe Form von
Genehmigung; nur ein Benutzer, der ein korrektes Kennwort angibt, darf die
Programm zum Beispiel. Oder sie geben nach erfolgreichem Abschluss eine Art von Anmeldeinformationen zurück
Authentifizierung, oder vielleicht verwenden dacs_auth_agent(8)[3] zurückkehren DACS Referenzen.

dacsauth kann auch verwendet werden, um Rolleninformationen abzurufen, die einem bestimmten Benutzer zugeordnet sind.

dacsauth liest keine DACS Konfigurationsdateien. Alles was für die Durchführung des Tests benötigt wird
muss als Argument angegeben werden.

Tipp
If dacsauth verwendet ein integriertes Modul, um die Authentifizierung durchzuführen oder nach Rollen zu suchen, nicht
Server Komponente is falls angefordert. Dies bedeutet, dass Sie verwenden können dacsauth ohne zu müssen
auf einen Webserver, einschließlich Apache, zugreifen oder ihn sogar konfigurieren.

OPTIONAL

Die folgenden Befehlszeilen-Flags werden erkannt. Mindestens ein -m Flagge (durchführen
Authentifizierungstest) oder mindestens ein -r Flag muss angegeben werden (um eine Rolle zu bilden
Deskriptorzeichenfolge für die Identität und geben Sie sie auf stdout aus). Eine Kombination beider Flags ist
erlaubt, in diesem Fall wird ein Rollendeskriptor-String nur ausgegeben, wenn der Authentifizierungstest
ist erfolgreich.

-DRichtlinien=Wert
Dies entspricht der Einstellung Richtlinien, Ein General DACS Konfigurationsdirektive, zu
Wert. Sehen dacs.conf(5)[4].

-zu
Die nächste Zeichenfolge, die von bereitgestellt wird -p, -pf, oder -prompt Flag wird der Wert des sein
HILFS Authentifizierungsargument. Dies bietet eine sichere Möglichkeit, sensible
Zusatzinformationen, wie z. B. eine PIN, an das Programm. Ein Flag zum Abrufen des Passworts,
falls vorhanden, muss diesem Flag in der Befehlszeile vorangestellt werden.

-fj Jurname
Verwenden Sie die Jurname, die syntaktisch gültig sein muss, als Gerichtsstandsname. Falls erforderlich
jedoch nicht angegeben, wird ein vom Domänennamen des Hosts abgeleiteter Wert verwendet.

-fn Fedname
Verwenden Sie die Fedname, die syntaktisch gültig sein muss, als Föderationsname. Falls erforderlich
jedoch nicht angegeben, wird ein vom Domänennamen des Hosts abgeleiteter Wert verwendet.

-h
-Hilfe
Eine Hilfemeldung anzeigen und beenden.

-id
Wenn erfolgreich, drucken Sie die authentifizierte DACS Identität mit der Standardausgabe.

-NS log_level
Setzen Sie den Debugging-Ausgangspegel auf log_level (sehen dacs(1)[5]). Die Standardstufe ist
warnen.

-m Authentifizierungsmodul-Spezifikation
Jede erforderliche Art von Authentifizierungstest wird durch ein . beschrieben Authentifizierungsmodul-Spezifikation
das folgt sofort -m Flagge. Jeder Authentifizierungsmodul-Spezifikation ist im Wesentlichen ein
alternative Darstellung von an Auth Klausel[6] und deren Direktiven, die von
dacs_authenticate(8)[1]. Genauso wie die Reihenfolge, in der Auth-Klauseln in a DACS
Konfigurationsdatei, die Reihenfolge, in der die -m Flaggen erscheinen können von Bedeutung sein,
abhängig von Smartgeräte App Schlüsselwörter. Während der Verarbeitung sukzessive -m Komponenten sind
automatisch zugewiesene Namen, auth_module_1, auth_module_2 usw., hauptsächlich für
Fehlerberichtszwecke.

An Authentifizierungsmodul-Spezifikation hat die folgende Syntax:

Das Modulen beginnt entweder mit dem Namen eines eingebauten Moduls oder einer gültigen Abkürzung
davon oder die (absolute) URL eines externen Authentifizierungsmoduls (entspricht
URL[7] Richtlinie). Als nächstes muss ein anerkanntes Schlüsselwort für den Authentifizierungsstil erscheinen
Bezeichner (entspricht dem STYLE[8] Richtlinie). Als nächstes die Smartgeräte App Stichwort folgt,
das ist identisch mit dem STEUERN[9] Direktive in der Auth-Klausel. Nach dem Smartgeräte App
Schlüsselwort können die unten beschriebenen Flags in beliebiger Reihenfolge folgen.

An Authentifizierungsmodul-Spezifikation endet, wenn das erste ungültige Flag (oder das Ende von Flags) . ist
angetroffen.

Das -O Flag ist äquivalent zu an zur Auswahl[10] Richtlinie.

Das -Von Auf das Flag folgt ein Argument, das der Name einer Datei ist, aus der gelesen werden soll
Optionen, eine pro Zeile, im Format Name=Wert. Leerzeilen und Zeilen, die mit beginnen
ein '#' werden ignoriert; Beachten Sie, dass diese Zeilen nicht mit "-O" beginnen und Anführungszeichen einfach sind
kopiert und nicht interpretiert. Die -Von Flag kann verwendet werden, um das Setzen von Passwörtern zu vermeiden
die Befehlszeile und erleichtert das Schreiben von Ausdrücken, die sonst
sorgfältig maskiert werden, um beispielsweise eine Interpretation durch die Shell zu verhindern.

Das -ausdruck Flagge ist äquivalent zu dem EXPR[11] Richtlinie. Die -vfs Flagge wird verwendet, um
konfigurieren VFS[12] Anweisungen, die von diesem Modul benötigt werden.

-Module
Zeigen Sie eine Liste der integrierten Authentifizierungsmodule und Rollenmodule an, eines pro Zeile, und
dann aussteigen. Der kanonische Modulname wird gedruckt, gefolgt von null oder mehr Äquivalenten
Abkürzungen. Für Authentifizierungsmodule wird der Authentifizierungsstil angezeigt. Auflisten
die verfügbaren Module, führen Sie den Befehl aus:

% dacsauth-Module

Der Satz der verfügbaren (aktivierten) integrierten Authentifizierungs- und Rollenmodule wird bestimmt
wann DACS ist gebaut.

-p Passwort
Geben Sie das zu verwendende Passwort an (entspricht dem PASSWORD Argument zwei
dacs_authenticate).

Sicherheit
Ein in der Befehlszeile eingegebenes Passwort kann für andere Benutzer auf derselben sichtbar sein
System funktionieren.

-pf Datei
Lesen Sie das zu verwendende Passwort von Datei (entspricht dem PASSWORD Argument zwei
dacs_authenticate). Wenn Datei ist "-", dann wird das Passwort aus der Standardeingabe gelesen
ohne Aufforderung.

-prompt
Fordern Sie das Passwort an und lesen Sie es von stdin (entspricht dem PASSWORD Argument zwei
dacs_authenticate). Das Passwort wird nicht ausgegeben.

-q
Seien Sie leiser, indem Sie den Debugging-Ausgangspegel reduzieren.

-r Rollenmodul-Spezifikation
Rollen für Benutzername kann durch Angabe dieses Flags bestimmt werden, das sofort angezeigt wird
gefolgt von einem Rollen-Modul-Spezifikationdem „Vermischten Geschmack“. Seine -r Flag kann wiederholt werden, und die resultierenden Rollen
sind kombiniert. Jeder Rollen-Modul-Spezifikation ist im Wesentlichen eine alternative Darstellung von a
Rollenklausel, die von verwendet wird dacs_authenticate(8)[13]. Aufeinanderfolgend -r Komponenten sind
zugewiesene Namen, roles_module_1, roles_module_2 usw., hauptsächlich für die Fehlerberichterstattung
Zwecke.

A Rollen-Modul-Spezifikation hat die folgende Syntax:

Das Modulen Komponente entspricht der Rollenklausel URL[14] Richtlinie und ist
entweder der Name eines verfügbaren integrierten Rollenmoduls, eine gültige Abkürzung davon,
oder die (absolute) URL eines externen Rollenmoduls.

Flaggen können folgen Modulen Komponente in beliebiger Reihenfolge. EIN Rollen-Modul-Spezifikation endet wenn
das erste ungültige Flag (oder das Ende von Flags) wird angetroffen.

Das -O Flag ist äquivalent zu an zur Auswahl[10] Richtlinie.

Das -Von Auf das Flag folgt ein Argument, das der Name einer Datei ist, aus der gelesen werden soll
Optionen, eine pro Zeile, im Format Name=Wert. Leerzeilen und Zeilen, die mit beginnen
ein '#' werden ignoriert; Beachten Sie, dass diese Zeilen nicht mit "-O" beginnen und Anführungszeichen einfach sind
kopiert und nicht interpretiert. Die -Von Flag kann verwendet werden, um das Setzen von Passwörtern zu vermeiden
die Befehlszeile und erleichtert das Schreiben von Ausdrücken, die sonst
sorgfältig maskiert werden, um beispielsweise eine Interpretation durch die Shell zu verhindern.

Das -ausdruck Flagge ist äquivalent zu dem EXPR[11] Richtlinie. Die -vfs Flagge wird verwendet, um
konfigurieren VFS[12] Richtlinien erforderlich von Modulen.

-u Benutzername
-Benutzer Benutzername
Der Benutzername für die Authentifizierung (entspricht dem USERNAME Argument zwei
dacs_authenticate). Dieser Benutzername ist implizit mit dem effektiven
Föderation und Gerichtsbarkeit (siehe die -fn[15] und -fj[16] Flaggen).

-v
Das -v Flag erhöht den Debugging-Ausgangspegel auf Debug oder (bei Wiederholung) Trace.

Beispiele:

Sicherheit
If dacsauth verwendet ein eingebautes Modul, um die Authentifizierung durchzuführen, es muss setuid oder . ausführen
setgid, um ausreichende Berechtigungen für den Zugriff auf die erforderliche Passwortdatei zu erhalten (dasselbe
gilt für integrierte Rollenmodule). Wenn es ein externes Modul verwendet, wird dieses Modul
müssen mit ausreichenden Zugriffsrechten ausgeführt werden DACS kryptografische Schlüssel,
speziell Federation_keys und möglicherweise DACS oder Systemkennwortdateien; das Äußere
Das Modul muss dann mit ausreichenden Berechtigungen ausgeführt werden, um auf alle Dateien zugreifen zu können
erfordert.

Stellen Sie sicher, dass Sie die für Ihre Föderation korrekten Federation_keys verwenden. Referenzierung
Authentifizierungsmodule in zwei oder mehr Föderationen werden wahrscheinlich nicht funktionieren.

dacsauth sollte daher normalerweise nicht als UID des Benutzers ausgeführt werden, der sie aufruft
(es sei denn, es handelt sich um root), da es nicht auf die Informationen zugreifen kann
Es benötigt. Dadurch wird auch verhindert, dass ein Benutzer "schummelt" (z. B. durch Anhängen an die
laufendes Modul mit einem Debugger).

Dieses Beispiel authentifiziert den Benutzer "bobo" mit dem Passwort "test" gegen die DACS Passwortdatei
/usr/local/dacs/conf/passwd:

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

Wenn der Exit-Status des Befehls null ist, war der Authentifizierungstest erfolgreich, andernfalls ist er
gescheitert.

Im folgenden Beispiel wird versucht, "bobo" anhand ihrer Unix-Passwortdatei zu authentifizieren. Die
Programm fordert zur Eingabe des Passworts auf.

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

Im nächsten Beispiel, dacsauth versucht, "bobo" über NTLM zu authentifizieren
winders.example.com:

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

Dieses Beispiel ähnelt dem vorherigen, außer dass ein externes Authentifizierungsmodul
verwendet und das Passwort aus einer Datei gelesen. Durch das externe Modul zusätzlich
Konfiguration muss angegeben werden; insbesondere die Position von Federation_Keys und die
Föderations- und Jurisdiktionsnamen müssen angegeben werden.

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

Zur Authentifizierung gegen die Google[17] Konto [E-Mail geschützt] , könnte man verwenden:

% 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 [E-Mail geschützt]

Im folgenden Beispiel wird ein Ausdruck ausgewertet, um zu bestimmen, ob Authentifizierung
sollte gelingen. Der Benutzer ("bobo") wird nach einem Passwort gefragt. Nur wenn die Zeichenfolge "foo" ist
gegeben, wird die Authentifizierung erfolgreich sein. Ein realistischeres Beispiel könnte ein anderes Programm aufrufen, um
helfen bei der Bestimmung, zum Beispiel.

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

Authentifizierung gegen einen Apache htdigest Passwortdatei wird im Folgenden ausgeführt
Beispiel, wo das Passwort von stdin gelesen wird:

% echo "test" | dacsauth -m Apache Digest ausreichend \
-OAUTH_MODULE=mod_auth_digest \
-OAUTH_FILE=/usr/local/apache2/conf/passwords.digest \
-OAUTH_REALM="DACS-Digest-Authentifizierungsbereich" \
-u bobo -pf -

Die Authentifizierung über das PAM-Modul funktioniert anders als die anderen Module – und ist mehr
kompliziert zu bedienen - weil dacsauth muss möglicherweise mehrmals ausgeführt werden, je nachdem, was
Informationen, die PAM benötigt. Anstatt eine Ja/Nein-Entscheidung zurückzugeben, dacsauth darf drucken
fordert zur Eingabe weiterer Informationen in stdout auf. Bitte überprüfen Sie die Betriebsdetails in
dacs_authenticate(8)[18] und pamd(8)[19] bevor Sie versuchen, dieses Modul zu verwenden.

Das folgende Beispiel zeigt die Verwendung des Moduls über die Befehlszeile. Einmal die Basis
Ideen verstanden werden, sollte klar sein, wie man ein Skript schreibt, um die
notwendigen Iterationen. Details im Beispiel, wie Pfade, müssen eventuell angepasst werden
deine Umgebung. Beachten Sie, dass in diesem Beispiel der Benutzername nicht beim ersten Mal angegeben wird
dacsauth ausgeführt wird, obwohl es sein könnte, wenn es bekannt wäre.

% dacsauth -m pam fordert ausreichend \
-vfs "[federation_keys]dacs-fs:/usr/local/dacs/federations/dss/federation_keys" \
-OPAMD_HOST=localhost -OPAMD_PORT=dacs-pamd -fj BEISPIEL -fn TEST
AUTH_PROMPT_VAR1="Anmelden:"
AUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"
% dacsauth -m pam fordert ausreichend \
-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="Passwort:"
AUTH_TRANSID="10.0.0.124:52188:88417:5ffb0015f21ea546"
% dacsauth -m pam fordert ausreichend \
-vfs "[federation_keys]dacs-fs:/usr/local/dacs/federations/dss/federation_keys" \
-OAUTH_PROMPT_VAR2="einPasswort" \
-OAUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"-fj EXAMPLE -fn TEST

Das erste Mal dacsauth im Beispiel ausgeführt wird, gibt es eine Eingabeaufforderung für den Benutzernamen zurück
("Login:"), das der Transaktionsvariablen zugeordnet ist AUTH_PROMPT_VAR1 und einem
Transaktionskennung (AUTH_TRANSID). Letztere muss an die nachfolgenden weitergegeben werden
Hinrichtungen von dacsauth. Der zweite Lauf von dacsauth übergibt den Benutzernamen ("bobo") und
gibt eine weitere Eingabeaufforderung ("Password:") zurück, die der Transaktionsvariablen zugeordnet ist
AUTH_PROMPT_VAR2. Beim dritten Durchlauf wird das Passwort ("apassword") übergeben, aber es erfolgt keine Eingabeaufforderung
zurückgegeben, was anzeigt, dass die Sitzung abgeschlossen ist und der Beendigungsstatus des Programms widerspiegelt
das Ergebnis der Authentifizierung.

Tipp
Ob dacsauth erfordert ein Passwort, um Rollen abzurufen, hängt von den jeweiligen Rollen ab
Modul verwendet wird. Zum Beispiel ist kein Passwort erforderlich von local_unix_roles[20] oder
lokale_rollen[21] um Rollen zu erhalten, aber local_ldap_roles[22] wird wahrscheinlich einen brauchen
Kennwort, um sich an das Verzeichnis zu binden und Rollen zu erhalten.

In diesem Beispiel wird die Rollenzeichenfolge für den Benutzer "bobo" ausgegeben, indem das integrierte aufgerufen wird
local_unix_roles[20] Modul:

% dacsauth -r unix -u bobo
Bobo, Rad, www, Benutzer

Das nächste Beispiel ähnelt dem vorherigen, außer dass ein externes Rollenmodul verwendet wird:

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

Das externe Rollenmodul wird möglicherweise auf einem anderen Host als dem ausgeführten ausgeführt
dacsauth. Bereitgestellt dacsauth wurde installiert und eine passende federation_keys-Datei ist
auf dem lokalen Host verfügbar ist, muss der lokale Host kein DACS Gerichtsbarkeit oder haben
Sonstiges DACS Konfiguration.

Das folgende Beispiel druckt die Rolle Schnur[23] für Benutzer "bobo", bekannt innerhalb der
Verzeichnis mit dem Common Name "Bobo Beutlin", unter Verwendung der (externen) local_ldap_roles[22]
Modul und die "direkte" Bindungsmethode:

% dacsauth -r https://example.example.com/cgi-bin/dacs/local_ldap_roles \
-Of /usr/local/dacs/ldap_roles_options_direct -u "Bobo Beutlin" \
-DVFS="[federation_keys]dacs-fs:/usr/local/dacs/federations/federation_keys" \
-fn BEISPIEL -fj FEDROOT -prompt
DNS-Admins,Druck-Operatoren,Domain-Admins,Administratoren

Da es zu viele Flags gibt, um sie einfach und korrekt in der Befehlszeile zu platzieren,
die dazu benötigten Optionen werden aus einer Datei gelesen, die durch die -Von Flagge.
Dies bietet auch eine sicherere Möglichkeit, Kennwörter an das Programm zu übergeben; sicherstellen, dass der Zugang
auf die Datei wird entsprechend eingeschränkt. Die Datei
/usr/local/dacs/ldap_roles_options_direct kann eine Konfiguration wie diese enthalten:

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

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

Das folgende Beispiel ist wie das vorherige, außer dass es die "indirekte" Bindung verwendet
-Methode und muss daher nicht den Common Name des Benutzers erhalten:

% 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 BEISPIEL -fj FEDROOT -p bobospassword
DNS-Admins,Druck-Operatoren,Domain-Admins,Administratoren

Die Datei /usr/local/dacs/ldap_roles_options_indirect enthält möglicherweise Konfigurationen wie
Dies:

LDAP_BIND_METHOD=indirekt
LDAP_ADMIN_URL=ldap://winders.example.com/CN=Administrator,CN=Benutzer,DC=example,DC=com

# Suche unter Benutzer...
LDAP_SEARCH_ROOT_DN=CN=Benutzer,DC=Beispiel,DC=com

LDAP_ADMIN_PASSWORD=das geheime Admin-Passwort
LDAP_SEARCH_FILTER*="(sAMAccountName=${Args::DACS_USERNAME})"
LDAP_ROLES_SELECTOR*="${LDAP::attrname}" eq "memberOf" ? strtr(ldap(rdn_attrvalue, \
ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""

Angenommen, man wollte verwenden dacsauth einen Benutzer über LDAP analog zu authentifizieren
diese dacs.conf-Konfiguration:


URL"http://example.example.com/cgi-bin/dacs/local_ldap_authenticate"
STIL "password,add_roles"
STEUERUNG "erforderlich"
LDAP_BIND_METHOD "direkt"
LDAP_USERNAME_URL* '"ldap://winders.example.com/cn=" . encode(url, ${Args::USERNAME}) . ",cn=Benutzer,dc=Beispiel,dc=lokal"'
LDAP_USERNAME_EXPR* '"${LDAP::sAMAccountName}"'
LDAP_ROLES_SELECTOR* '"${LDAP::attrname}" eq "memberOf" \
? strtr(ldap(rdn_attrvalue, ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""'


Eine Datei wie diese (zB /usr/local/dacs/ldap_auth_options_direct) würde die
folgende Richtlinien:

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

Die Authentifizierung könnte dann mit einem Befehl wie diesem durchgeführt werden:

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

DIAGNOSE

Das Programm beendet 0, wenn die Authentifizierung erfolgreich war oder mit 1, wenn die Authentifizierung fehlgeschlagen ist oder
ein Fehler ist aufgetreten.

Verwenden Sie dacsauth online mit den onworks.net-Diensten