dacsauth — Online w chmurze

PROGRAM:

IMIĘ

dacsauth – sprawdzenie uwierzytelnienia

STRESZCZENIE

daksauth [-m specyfikacja modułu uwierzytelniania] [...] [-r specyfikacja modułu ról] [...] [-DDyrektywy=wartość]
[-pomocniczy]
[-fj nazwisko] [-fn nazwa_użytkownika] [-h | -Pomoc] [-ID] [-NS poziom_logowania]
[-p password]
[-pf filet] [-podpowiedź] [-q] [{-u | -użytkownik} nazwa użytkownika] [-v]
moduły dacsauth

OPIS

Ten program jest częścią DAC na.

Połączenia daksauth Narzędzie testuje, czy dany materiał uwierzytelniający spełnia kryteria uwierzytelnienia
wymagań i wskazuje wynik poprzez status zakończenia procesu. To jest podobne do
dacs_authenticate(8)[1] i daskred(1)[2].

daksauth umożliwia skryptom i innym programom wykorzystanie DAC Uwierzytelnianie
infrastruktura. Mogą używać udanego uwierzytelnienia jako uproszczonej formy
upoważnienie; tylko użytkownik, który poda prawidłowe hasło, będzie mógł uruchomić program
programu np. Lub mogą zwrócić jakiś rodzaj poświadczeń po pomyślnym zakończeniu
uwierzytelnianie, a może użycie dacs_auth_agent(8)[3], aby wrócić DAC kwalifikacje.

daksauth można również wykorzystać do pobrania informacji o roli powiązanej z danym użytkownikiem.

daksauth nie czyta żadnego DAC pliki konfiguracyjne. Wszystko co potrzebne do wykonania testu
należy podać jako argument.

Wskazówka
If daksauth wykorzystuje wbudowany moduł do przeprowadzania uwierzytelniania, czyli wyszukiwania ról, Nie
serwer składnik is wymagany. Oznacza to, że możesz używać daksauth bez konieczności
uzyskać dostęp lub nawet skonfigurować serwer WWW, w tym Apache.

OPCJE

Rozpoznawane są następujące flagi wiersza poleceń. Przynajmniej jeden -m flaga (do wykonania
testy uwierzytelniające) lub co najmniej jeden -r należy określić flagę (aby utworzyć rolę
ciąg deskryptora tożsamości i wypisz go na standardowe wyjście). Jest to kombinacja obu flag
dozwolone, w takim przypadku ciąg deskryptora roli jest wyprowadzany tylko w przypadku testu uwierzytelniania
zakończony powodzeniem.

-DDyrektywy=wartość
Jest to równoznaczne z ustawieniem Dyrektywy, generał DAC dyrektywa konfiguracyjna, do
wartość. Zobaczyć dacs.conf(5)[4].

-pomocniczy
Następny ciąg dostarczony przez -p, -pflub -podpowiedź flaga będzie wartością
POMOCNICZY argument uwierzytelniający. Zapewnia to bezpieczny sposób przekazywania danych wrażliwych
informacje pomocnicze, takie jak PIN, do programu. Flaga uzyskania hasła,
jeśli istnieje, musi poprzedzać tę flagę w wierszu poleceń.

-fj nazwisko
Zastosowanie nazwisko, które musi być poprawne składniowo, jako nazwa jurysdykcji. Jeśli wymagane
ale nie została podana, zostanie użyta wartość pochodząca z nazwy domeny hosta.

-fn nazwa_użytkownika
Zastosowanie nazwa_użytkownika, która musi być poprawna składniowo, jako nazwa federacji. Jeśli wymagane
ale nie została podana, zostanie użyta wartość pochodząca z nazwy domeny hosta.

-h
-Pomoc
Wyświetl komunikat pomocy i wyjdź.

-ID
Jeśli się powiedzie, wydrukuj uwierzytelniony plik DAC tożsamość na standardowe wyjście.

-NS poziom_logowania
Ustaw poziom wyjściowy debugowania na poziom_logowania (Patrz daków(1)[5]). Domyślny poziom to
ostrzec.

-m specyfikacja modułu uwierzytelniania
Każdy rodzaj wymaganego testu uwierzytelnienia jest opisany przez specyfikacja modułu uwierzytelniania
który natychmiast następuje po -m flaga. Każdy specyfikacja modułu uwierzytelniania jest zasadniczo
alternatywna reprezentacja Auth klauzula[6] i jego dyrektywy, z których korzystają
dacs_authenticate(8)[1]. Podobnie jak kolejność, w jakiej klauzule Auth pojawiają się w pliku a DAC
plik konfiguracyjny, kolejność, w jakiej -m pojawiające się flagi mogą być znaczące,
w zależności od kontrola słowa kluczowe. Podczas przetwarzania, sukcesywnie -m składniki są
automatycznie przypisane nazwy, auth_module_1, auth_module_2 itd., głównie dla
celów zgłaszania błędów.

An specyfikacja modułu uwierzytelniania ma następującą składnię:

Połączenia moduł zaczyna się od nazwy wbudowanego modułu lub prawidłowego skrótu
jego lub (bezwzględny) adres URL zewnętrznego modułu uwierzytelniającego (odpowiednik
dotychczasowy URL[7] dyrektywa). Następnie musi pojawić się słowo kluczowe rozpoznanego stylu uwierzytelniania
specyfikator (odpowiednik STYL[8] dyrektywa). Następny, kontrola następuje słowo kluczowe,
który jest identyczny z CONTROL[9] dyrektywa w klauzuli Auth. Po kontrola
po słowie kluczowym mogą następować opisane poniżej flagi w dowolnej kolejności.

An specyfikacja modułu uwierzytelniania kończy się, gdy pojawi się pierwsza nieprawidłowa flaga (lub koniec flag).
napotkany.

Połączenia -O flaga jest równoznaczna z OPCJA[10] dyrektywy.

Połączenia -Z po flagi następuje argument będący nazwą pliku, z którego należy czytać
opcje, po jednej w linii, w formacie Nazwa=wartość. Puste linie i linie zaczynające się od
znak „#” jest ignorowany; zwróć uwagę, że te linie nie zaczynają się od „-O”, a cudzysłowy są po prostu
skopiowane i nie zinterpretowane. The -Z flagę można wykorzystać do uniknięcia umieszczania haseł
wiersza poleceń i ułatwia pisanie wyrażeń, które w przeciwnym razie miałyby miejsce
należy ostrożnie uciec, aby na przykład zapobiec interpretacji przez powłokę.

Połączenia -wyr flaga jest równoważna WYRAŻ[11] dyrektywa. The -vfs flaga jest używana do
skonfigurować VFS[12] dyrektyw wymaganych przez ten moduł.

-moduły
Wyświetl listę wbudowanych modułów uwierzytelniania i modułów ról, po jednym w wierszu, i
następnie wyjdź. Drukowana jest kanoniczna nazwa modułu, po której następuje zero lub jego odpowiednik
skróty. W przypadku modułów uwierzytelniających pokazany jest styl uwierzytelniania. Notować
dostępne moduły, uruchom komendę:

% dacsauth -moduły

Określany jest zestaw dostępnych (włączonych) wbudowanych modułów uwierzytelniania i ról
jeśli chodzi o komunikację i motywację DAC jest zbudowany.

-p password
Określ hasło, którego chcesz używać (odpowiednik hasła HASŁO argument drugi
dacs_authenticate).

Bezpieczeństwo
Hasło podane w wierszu poleceń może być widoczne dla innych użytkowników tego samego
pomimo napiętego harmonogramu

-pf filet
Przeczytaj hasło, z którego chcesz korzystać filet (odpowiednik HASŁO argument drugi
dacs_authenticate). Jeśli filet ma wartość „-”, wówczas hasło jest odczytywane ze standardowego wejścia
bez pytania.

-podpowiedź
Zapytaj o hasło i odczytaj je ze standardowego wejścia (odpowiednik HASŁO argument drugi
dacs_authenticate). Hasło nie jest powtarzane.

-q
Bądź cichszy, zmniejszając poziom wyjściowy debugowania.

-r specyfikacja modułu roli
Role dla nazwa użytkownika można określić podając tę ​​flagę, która jest natychmiastowa
następnie specyfikacja modułu ról, -r flaga może się powtarzać i wynikające z tego role
są połączone. Każdy specyfikacja modułu ról jest zasadniczo alternatywną reprezentacją a
Klauzula ról używana przez dacs_authenticate(8)[13]. Kolejny -r składniki są
przypisane nazwy, role_module_1, role_module_2 itd., głównie w celu raportowania błędów
celów.

A specyfikacja modułu ról ma następującą składnię:

Połączenia moduł komponent jest odpowiednikiem klauzuli Roles URL[14] dyrektywa i jest
albo nazwę dostępnego wbudowanego modułu ról, albo jego prawidłowy skrót,
lub (bezwzględny) adres URL zewnętrznego modułu ról.

Flagi mogą podążać za moduł komponent w dowolnej kolejności. A specyfikacja modułu ról kończy się, kiedy
napotkano pierwszą nieprawidłową flagę (lub koniec flag).

Połączenia -O flaga jest równoznaczna z OPCJA[10] dyrektywy.

Połączenia -Z po flagi następuje argument będący nazwą pliku, z którego należy czytać
opcje, po jednej w linii, w formacie Nazwa=wartość. Puste linie i linie zaczynające się od
znak „#” jest ignorowany; zwróć uwagę, że te linie nie zaczynają się od „-O”, a cudzysłowy są po prostu
skopiowane i nie zinterpretowane. The -Z flagę można wykorzystać do uniknięcia umieszczania haseł
wiersza poleceń i ułatwia pisanie wyrażeń, które w przeciwnym razie miałyby miejsce
należy ostrożnie uciec, aby na przykład zapobiec interpretacji przez powłokę.

Połączenia -wyr flaga jest równoważna WYRAŻ[11] dyrektywa. The -vfs flaga jest używana do
skonfigurować VFS[12] dyrektywy wymagane przez moduł.

-u nazwa użytkownika
-użytkownik nazwa użytkownika
Nazwa użytkownika, względem której ma nastąpić uwierzytelnienie (odpowiednik nazwy USERNAME argument drugi
dacs_authenticate). Ta nazwa użytkownika jest pośrednio powiązana z efektem
federacja i jurysdykcja (zob -fn[15] i -fj[16] flag).

-v
Połączenia -v flaga podbija poziom wyjściowy debugowania w celu debugowania lub (jeśli powtarzane) śledzenia.

PRZYKŁADY

Bezpieczeństwo
If daksauth używa wbudowanego modułu do przeprowadzania uwierzytelniania, musi uruchomić setuid lub
setgid, aby uzyskać wystarczające uprawnienia dostępu do wymaganego pliku haseł (to samo
dotyczy wbudowanych modułów ról). Jeśli korzysta z modułu zewnętrznego, ten moduł to zrobi
należy wykonać z wystarczającymi uprawnieniami dostępu DAC klucze kryptograficzne,
konkretnie federation_keys i ewentualnie DAC lub systemowe pliki haseł; zewnętrzne
moduł będzie musiał zostać uruchomiony z wystarczającymi uprawnieniami, aby uzyskać dostęp do dowolnych plików
wymaga.

Pamiętaj, aby użyć kluczy_federacji odpowiednich dla Twojej federacji. Odwoływanie się
moduły uwierzytelniające w dwóch lub więcej federacjach prawdopodobnie nie będą działać.

daksauth dlatego nie powinien zwykle działać jako identyfikator UID użytkownika, który go wywołuje
(chyba że jest to root), ponieważ nie będzie mógł uzyskać dostępu do informacji
to wymaga. Zapobiegnie to również „oszukiwaniu” użytkownika (np. poprzez dołączenie do pliku
działający moduł z debugerem).

Ten przykład uwierzytelnia użytkownika „bobo” za pomocą hasła „test” względem DAC plik hasła
/usr/local/dacs/conf/passwd:

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

Jeśli status zakończenia polecenia wynosi zero, test uwierzytelnienia powiódł się, w przeciwnym razie
nie udało się.

Poniższy przykład próbuje uwierzytelnić „bobo” w oparciu o jej plik haseł uniksowych. The
program poprosi o hasło.

% dacsauth -m wymagane hasło unixowe -u bobo -prompt

W następnym przykładzie daksauth próbuje uwierzytelnić „bobo” przez NTLM
winders.example.com:

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

Ten przykład jest podobny do poprzedniego, z tą różnicą, że zewnętrzny moduł uwierzytelniający
jest używane, a hasło jest odczytywane z pliku. Ze względu na moduł zewnętrzny, dodatkowy
należy podać konfigurację; w szczególności lokalizacja kluczy federacyjnych i
Należy podać nazwy federacji i jurysdykcji.

% dacsauth -m https://example.example.com/cgi-bin/dacs/local_ntlm_authenticate \
hasło wystarczające -OSAMBA_SERVER="winders.example.com" \
-fn PRZYKŁAD -fj FEDROOT -u bobo -pf mojehasło \
-DVFS="[klucze_federacji]dacs-fs:/usr/local/dacs/federacje/przyklad/klucze_federacji"

Aby uwierzytelnić się względem Google[17] konto [email chroniony], można użyć:

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

W poniższym przykładzie oceniane jest wyrażenie w celu ustalenia, czy uwierzytelnianie
powinno się udać. Użytkownik („bobo”) jest proszony o podanie hasła. Tylko jeśli ciąg „foo” jest
podane, czy uwierzytelnienie się powiedzie. Bardziej realistyczny przykład może wywołać inny program
pomóż w podjęciu decyzji, np.

% dacsauth -m wyrażenie wyrażenie suffi \
-expr '${Args::HASŁO} eq "foo" ? ${Args::USERNAME} : ""' -user bobo -prompt

Uwierzytelnianie na serwerze Apache Htdigest plik haseł jest wykonywany w następujący sposób
przykład, gdzie hasło jest odczytywane ze stdin:

% echo „test” | dacsauth -m Apache Digest wystarczający \
-OAUTH_MODULE=mod_auth_digest \
-OAUTH_FILE=/usr/local/apache2/conf/passwords.digest \
-OAUTH_REALM="Obszar autoryzacji podsumowania DACS" \
-ty bobo -pf -

Uwierzytelnianie poprzez moduł PAM działa inaczej niż pozostałe moduły - a nawet więcej
skomplikowane w użyciu - ponieważ daksauth może być konieczne kilkakrotne uruchomienie, w zależności od czego
informacje wymagane przez PAM. Zamiast zwracać decyzję tak/nie, daksauth może wydrukować
wyświetla monit o podanie dodatkowych informacji na standardowe wyjście. Prosimy o zapoznanie się ze szczegółami operacyjnymi przedstawionymi w
dacs_authenticate(8)[18] i pamd(8)[19] przed próbą użycia tego modułu.

Poniższy przykład ilustruje użycie modułu z wiersza poleceń. Raz podstawowy
pomysły są zrozumiałe, powinno być jasne, jak napisać scenariusz do wykonania
niezbędne iteracje. Szczegóły w przykładzie, takie jak ścieżki, mogą wymagać dostosowania
Twoje środowisko. Należy pamiętać, że w tym przykładzie nazwa użytkownika nie została określona za pierwszym razem
daksauth jest uruchamiany, chociaż mógłby tak być, gdyby był znany.

% dacsauth -m pam monit wystarczający \
-vfs "[klucze_federacji]dacs-fs:/usr/local/dacs/federations/dss/klucze_federacji" \
-OPAMD_HOST=localhost -OPAMD_PORT=dacs-pamd -fj PRZYKŁAD -fn TEST
AUTH_PROMPT_VAR1="Zaloguj się:"
AUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"
% dacsauth -m pam monit wystarczający \
-vfs "[klucze_federacji]dacs-fs:/usr/local/dacs/federations/dss/klucze_federacji" \
-OAUTH_PROMPT_VAR1="bobo" \
-OAUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"-fj EXAMPLE -fn TEST
AUTH_PROMPT_VAR2="Hasło:"
AUTH_TRANSID="10.0.0.124:52188:88417:5ffb0015f21ea546"
% dacsauth -m pam monit wystarczający \
-vfs "[klucze_federacji]dacs-fs:/usr/local/dacs/federations/dss/klucze_federacji" \
-OAUTH_PROMPT_VAR2="ahasło" \
-OAUTH_TRANSID="10.0.0.124:57849:85748:9997c5588a6239e3"-fj EXAMPLE -fn TEST

Pierwszy raz daksauth zostanie uruchomiony w przykładzie, zwraca monit o podanie nazwy użytkownika
(„Login:”), który jest powiązany ze zmienną transakcji AUTH_PROMPT_VAR1 oraz
identyfikator transakcji (AUTH_TRANSID). To drugie trzeba przekazać następnemu
egzekucje daksauth. Drugi bieg daksauth przekazuje nazwę użytkownika („bobo”) i
zwraca kolejny monit („Hasło:”) powiązany ze zmienną transakcji
AUTH_PROMPT_VAR2. Trzecie uruchomienie przekazuje hasło („apassword”), ale nie pojawia się żaden monit
zwrócony, wskazując, że sesja została zakończona i status wyjścia programu jest odzwierciedlany
wynik uwierzytelnienia.

Wskazówka
Czy daksauth wymaga hasła do odzyskania ról, zależy od konkretnych ról
używany moduł. Na przykład hasło nie jest wymagane przez role_lokalne_unix[20] lub
role_lokalne[21] w celu uzyskania ról, ale local_ldap_roles[22] prawdopodobnie będzie potrzebować
hasło umożliwiające powiązanie z katalogiem i uzyskanie ról.

Ten przykład drukuje ciąg roli dla użytkownika „bobo”, wywołując metodę wbudowaną
role_lokalne_unix[20] moduł:

% dacsauth -r unix -u bobo
bobo,koło,www,użytkownicy

Następny przykład jest podobny do poprzedniego, z tą różnicą, że używany jest zewnętrzny moduł ról:

% dacsauth -r https://example.example.com/cgi-bin/dacs/local_unix_roles \
-DVFS="[federation_keys]dacs-fs:/usr/local/dacs/federations/federation_keys" \
-fn PRZYKŁAD -u bobo
bobo,koło,www,użytkownicy

Moduł ról zewnętrznych może zostać uruchomiony na innym hoście niż ten, który jest uruchomiony
daksauth. Pod warunkiem, że daksauth został zainstalowany i jest nim pasujący plik federation_keys
dostępny na hoście lokalnym, hostem lokalnym nie musi być a DAC jurysdykcję lub ją posiadasz
inny DAC konfiguracja.

Poniższy przykład drukuje plik rola ciąg[23] dla użytkownika „bobo”, znanego w
katalog o nazwie zwyczajowej „Bobo Baggins”, używając (zewnętrznego) local_ldap_roles[22]
moduł i metoda wiązania „bezpośredniego”:

% 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 PRZYKŁAD -fj FEDROOT -podpowiedź
DnsAdmins, Print_Operators, Domain_Admins, Administratorzy

Ponieważ jest zbyt wiele flag, które można łatwo i poprawnie umieścić w wierszu poleceń, plik
potrzebne do tego opcje są odczytywane z pliku określonego przez -Z flag.
Zapewnia to również bezpieczniejszy sposób przekazywania haseł do programu; zapewnić ten dostęp
do pliku jest odpowiednio ograniczone. Plik
/usr/local/dacs/ldap_roles_options_direct może zawierać następującą konfigurację:

LDAP_BIND_METHOD=bezpośredni
LDAP_ADMIN_URL*="ldap://winders.example.com/CN=" . encode(url,${Args::DACS_USERNAME}) . ",CN=Użytkownicy,DC=przykład,DC=com"

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

Poniższy przykład jest podobny do poprzedniego, z tą różnicą, że używa wiązania „pośredniego”.
metoda i dlatego nie trzeba podawać nazwy zwyczajowej użytkownika:

% 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 PRZYKŁAD -fj FEDROOT -p boboshasło
DnsAdmins, Print_Operators, Domain_Admins, Administratorzy

Plik /usr/local/dacs/ldap_roles_options_indirect może zawierać konfigurację taką jak
to:

LDAP_BIND_METHOD=pośredni
LDAP_ADMIN_URL=ldap://winders.example.com/CN=Administrator,CN=Użytkownicy,DC=przykład,DC=com

# Wyszukaj w obszarze Użytkownicy...
LDAP_SEARCH_ROOT_DN=CN=Użytkownicy,DC=przykład,DC=com

LDAP_ADMIN_PASSWORD=Tajne hasło administratora
LDAP_SEARCH_FILTER*="(sAMAccountName=${Args::DACS_USERNAME})"
LDAP_ROLES_SELECTOR*="${LDAP::attrname}" eq "memberOf" ? strtr(ldap(rdn_attrvalue, \
ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""

Załóżmy, że ktoś chce skorzystać daksauth w celu uwierzytelnienia użytkownika poprzez LDAP w sposób analogiczny do
ta konfiguracja dacs.conf:


Adres URL "http://example.example.com/cgi-bin/dacs/local_ldap_authenticate"
STYL „hasło, dodaj_role”
KONTROLA „wymagana”
LDAP_BIND_METHOD „bezpośredni”
LDAP_USERNAME_URL* '"ldap://winders.example.com/cn=" . encode(url, ${Args::USERNAME}) . ",cn=Użytkownicy,dc=przykład,dc=lokalny"'
LDAP_USERNAME_EXPR* '"${LDAP::sAMAccountName}"'
LDAP_ROLES_SELECTOR* '"${LDAP::attrname}" eq "memberOf" \
? strtr(ldap(rdn_attrvalue, ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""'


Plik taki jak ten (np. /usr/local/dacs/ldap_auth_options_direct) będzie zawierał
następujące dyrektywy:

LDAP_BIND_METHOD=bezpośredni
LDAP_USERNAME_URL*="ldap://winders.example.com/cn=" . encode(url, ${Args::USERNAME}) . ",cn=Użytkownicy,dc=przykład,dc=lokalny"
LDAP_USERNAME_EXPR*="${LDAP::sAMAccountName}"
LDAP_ROLES_SELECTOR*="${LDAP::attrname}" eq "memberOf" \
? strtr(ldap(rdn_attrvalue, ldap(dn_index, "${LDAP::attrvalue}", 1)), " ", "_") : ""

Uwierzytelnianie można następnie przeprowadzić za pomocą polecenia takiego jak to:

% dacsauth -fj FEDROOT -m http://example.example.com/cgi-bin/dacs/local_ldap_authenticate hasło wystarczy \
-Of /usr/local/dacs/ldap_auth_options_direct \
-DVFS="[federation_keys]dacs-fs:/usr/local/dacs/federations/federation_keys" \
-fn PRZYKŁAD -u bobo -podpowiedź

DIAGNOSTYKA

Program kończy pracę z wartością 0, jeśli uwierzytelnienie powiodło się lub z wartością 1, jeśli uwierzytelnienie nie powiodło się lub
wystąpił błąd.

Korzystaj z dacsauth online, korzystając z usług onworks.net