apache NTLM auth helyett valami mást

Linux-security

Sziasztok!

Érdeklődni szeretnék, hogy valaki használ -e valami más technológiát apache szerver domain auth-ra?
Igazából valami olyasmi kellene, hogy a felhasználó a böngészőjével belépne egy weboldalra és automatikusan felküldi a domain name és password párost, viszont ha nem tartományi gép lépne be a felületre, akkor az kézzel beírja a felhasználói név és jelszópárost, aztán kész :)

Idáig a apache kerberos moduljával szívtam, de az istennek sem jön össze :(

Valakinek ötlete?

Köszönöm szépen

  • 1084 megtekintés

( Szenti v | 2017. 01. 25., sze – 20:58 )

Ha domain van, akkor miért nem IIS, NTLM hitelesítéssel, Internet Explorerrel?

( SzBlackY | 2017. 01. 25., sze – 21:03 )

mod_auth_krb... nagyon gyatra kód (talán még az 1-es szériával kezdték, azóta párszor elég szépen belenyúltak az Apache auth alrendszereibe [pl. szétszedték authn-re és authz-re], azt meg csak patchelgették), de ha egyszer belövöd, akkor működik.

A RedHat-osoknál volt egy pont, amikor berágtak rá és elkezdtek egy újat csinálni már GSSAPI-val (a változatosság kedvéért egy újabb "jajmostmárazörökidőkremgoldjuknektekazauthproblémát" API :) ), mod_auth_gssapi néven... a rossz hír, hogy amikor utoljára néztem, mindegyik disztró még olyan verziót szállított belőle, ami nem támogatta a basic auth fallbacket, úgyhogy az a feltételed bukó vele. (2015 március-i a v1.1.0, amiben már ott van): https://github.com/modauthgssapi/mod_auth_gssapi/releases

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Mondanám, hogy egy klist-et írj, de amint anonimizálod, pont azok a részletek mennek szét, amiknek jelentőségük van :)

A teljesség igénye nélkül amikbe én eddig belefutottam:
1) SPN-nél a HTTP nagybetűs legyen (case sensitive)
2) A rövid (pl.: web) és a teljes (pl.: web.example.com) címekre is hozz létre SPN-t
3) Ha a fenti példában a web egy CNAME, akkor csinálj új keytab-ot az A rekorddal :)
4) Ha az A rekord nem az, amit a reverse-d ad (ha van), akkor csinálj új keytab-ot :) [azzal együtt, hogy értem, hogy mire gondolt a költő, amikor összerakták a Krb kanonikalizálást, a fenti Simo Sorce <<úgy emlékszem>> véleményével értek egyet, hogy semmi értelme, kifejezetten káros és eleve minek]
--
És akkor, hátha: nézd meg, hogy egy elutasított lekérés után van-e ticketed ahhoz a szerverhez (klist... meglepődtem, de már Win alatt is van).

--
Szerk.: Jah, még egy, ami miatt egy darabig csapkodtam már a billentyűzetet: ellenőrizd, hogy a legutoljára exportált keytab van-e a gépen.
Oh, még egy: Oh, és hogy tudja-e az Apache olvasni a keytabot.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( mekflaj | 2017. 01. 26., cs – 08:38 )

Igen, a felhasznalo igenis irja be a felhasznalo nevet és jelszot, a bongeszoben pedig tiltva legyen a jelszo megjegyzese.

Jo, nem tudom pontosan milyen rendszerrol beszelunk, de ha authentikaciot igyenyel akkor biztos olyan adatokat szolgaltat amikhez a hozzaferes korlatozott.

Igen, a felhasznalo igenis irja be a felhasznalo nevet és jelszot, a bongeszoben pedig tiltva legyen a jelszo megjegyzese.

Itt most pont arról van szó, hogy ez ne kelljen :) Vannak erre szép (Kerberos) és tiszta takony (minden más, amivel az MS próbálkozott az évek során :) ) megoldások. Ettől éppen hogy biztonságosabb lesz a rendszer, mert az authentikációt kiveszed az app kezéből és központosítod.

Aztán lehet tovább játszani a delegated credentials-zal (a mod_auth_gssapi OOB támogatja, a RedHat-os mod_auth_kerb csomagban van rá némi támogatás patchelve), amivel pl. a fenti szituban beállíthatod, hogy a webszervered sikeres auth után megszemélyesíthesse a usered. Ami persze ugyanígy működhet egy user/pass-szal, de azzal már nem tudod előírni, hogy a tényleg szenzitív adatokhoz csak smart carddal lehessen hozzáférni (ami viszont egy kattintás: adott usernél bekattintod, hogy az interaktív bejelentkezéshez smart kártya kelljen)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

És akkor mi a megoldás? Minden rendszerhez külön user/pass páros? (azt írtad, hogy azt kérjen)
Az nagyon rövid úton azt fogja jelenteni, hogy a Béla felírja rossz esetben egy post-itre, jó esetben egy "Jelszavak.docx" fájlba a jelszavait. Amit Gizi, aki az SSO-val megszemélyesítheti Bélát, ha hozzáfér a nem lezárt gépéhez, ugyanúgy el tud olvasni, mert hozzáfér a nem lezárt géphez.

Ha ez egy valós támadási vektor, akkor elő kell írni a smart card-ot és/vagy policyból kidobni egy 30 másodperc után induló, lockolt munkaállomásra visszatérő képernyővédőt; így egy nyitva felejtett gép 30 másodpercig ad támadási felületet.

Másik lehetőség, ha tényleg fontosak az adatok: authentikáció SSO-val, aztán authorizáció egy második faktorral (pl. freeOTP, Google Authenticator stb.). Persze attól még az a támadási felület megmarad, hogy megvárom, amíg Béla belép, aztán intravénásan beletolok egy kis ciánt és kitépem a kezéből a mobilját, és megszemélyesítem...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)