Samba (Active Directory) és apikey

Linux-haladó

Sziasztok!

Minden felhasználónak a felh+jelszó páros mellett szeretném, hogyha "apikey"-jel is be tudna lépni.

Példa:
felh: gipszjakab
jelszó: gipszjakab456789

felh: apikey
jelszó: SG.Sw8jCEzMS3GITZ8RIwZfug.VBTVGHGV95H5GqRRe5sFwLejCP7hEGI8lWykc-TfJ5-L1

Ez a gmailnél a two factor authentication-nél az "app password" (alkalmazásjelszavak) menüpont alatt érhető el.

Vajon ilyet meg lehetne csinálni Samba alatt? Windows-os kliensek felh+jelszóval lépnének be
(mint eddig), a programok (amiknek szüksége van az adott felhasználó jelszavára) pedig csak ilyen hosszú kulccsal.

Csinált már valaki ilyet?
(Gondolom csak én vagyok lemaradva)

  • 1422 megtekintés

( Oops | 2017. 02. 14., k – 06:55 )

Ez lényegében azt jelenti, hogy egy felhasználónak két jelszava van, egy rövid, meg egy mocsok hosszú, nem?

Az is egy megoldás.
Mármint minden mocsok hosszú jelszóhoz a felhasználót is el kell találni.

De ahol apikey van, ott a felhasználó ugyanaz (apikey), és a jelszóból derül ki, hogy melyik felhasználó (tehát a jelszóban benne van a felhasználónév és a jelszó is, csak mocsok hosszú).

Lényeges elem még, hogy a gyenge felh+jelszóval limitálod, hogy honnan lehet belépni (pl. csak helyi hálóról).

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( SzBlackY | 2017. 02. 14., k – 07:19 )

Mi a probléma, amit meg akarsz oldani?

Szerk.: ill. mi a cél, amit el akarsz érni? Miért kell ez? Biztonság? "Másnak is van"? Jó ötletnek tűnik? ...

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

A felhasználóktól "nem lehet elvárni" a kellően bonyolult jelszót. Viszont a felhasználótól el lehet várni, hogyha internet felől jön, akkor használjon VPN-t.

Viszont írtam már pár automatizáló programot. Egy weboldalon belép (másik felh+jelszóval), és ez a weboldal "tudja" a felhasználónevét jelszavát, amivel aztán automatizáló feladatokat hajt végre a felhasználó nevében.

A gond egyrészt a gyenge jelszavakból adódik. Az internet felől olyan 100-500 jelszó/óra próbálkozást kapok (pl. smtp ssl-en (587 port), tud a felhasználó időzített levelet küldeni (pl. találkozót szervezni 20-30 résztvevővel). Ahol minden résztvevő egyedi url-t kap, és ott a saját időpontját ki tudja választani, az egyedi url-t emailben kapja meg.
Namost a multkoriban az egyik felhasználó jelszavát próbálkozással betalálták, és el akartak küldeni egy rakat levelet a felhasználó nevében.

A másik gond a felhasználó jelszóváltoztatásából jön. Amit a weboldalon is le kellene követni.
Viszont ha a weboldalnak lenne saját kellően hosszú (~= feltörhetetlen) jelszava, akkor ott nem kellene piszkálni.

Szóval a jelszókezelést szeretném központosítani, és különszedni a hús-vér felhasználókat, a felhasználó nevében ügyködő programoktól.

Elég sok ilyen automata dolgot tudnak indítani a felhasználók, szóval gyakorlatban használják,
márcsak a jelszókérdést kellene megnyugtatóan rendezni.

Ráadásul ha ez menne, akkor a weboldal (amit kívülről is elérnek) tudhatna 2FA beléptetést, és a benti jelszavukkal lehetne nyomulni.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Na jó, itt most több dolgok belekevertél:

- 2FA úgy általában mindenre nem fog menni, nagyon sok esetben protokoll-szinten nincs rá lehetőség. HTTP-re oké.
- Brute force: old meg alkalmazás-szinten vagy külön eszközzel (fail2ban). Esetleg használj account lock-out-ot, de akkor meg bárki kizárhat bárkit a rendszeredből, ha tudja a felhasználónevét. Ill. tegyél fel egy GeoIP iptables modult, és fehérlistázd az országokat.

Egy weboldalon belép (másik felh+jelszóval)

Miért másik jelszóval lép be? Auth-old központilag az AD-ból, brute force ellen meg napló+fail2ban.

A problémát (jelszó birtokában a user megszemélyesíthető) nem fogod tudni azzal megoldani, hogy kiosztasz mindenféle tokeneket, egyszerűen átnevezted a problémát: token birtokában a user megszemélyesíthető. Az API-key-es dolog a Google-nek arra kell, hogy üzemeltetési határokon túl működhessen a megszemélyesítés, és egyesével visszavonhatóak legyenek dolgok.

A példádra visszatérve: a webszerveredben biztosan megbízol, mert elérhetővé tennéd számára az API kulcsokat, amikkel ki tudja küldeni a levelet. Mivel a webszervered tudja ismeri az API kulcsát, bárkinek a nevében tudna amúgy is levelet küldeni. Innentől kezdve nincs különbség aközött, hogy játszol az API kulcsokkal és aközött, hogy a mail szerveren nyitsz egy 588-as portot egyedül a webszerver felé és azt mondod, hogy ő küldhet bármilyen levelet, mert ezt ígyis-úgyis megteheti.

Ha arra kell, hogy Béla a gépén beállította a mail fiókját, és nem akarod, hogy akárhányszor Béla jelszót vált a levelezője is rákérdezzen a jelszóra, arra jó lehet. Felviszel (Dovecot) egy pl. SQL passdb-t, ami lekéri, hogy létezik-e az adott kulcs és ha igen, mi a hozzá tartozó user, problem solved. Cserébe eldobtad az _összes_ identity management lehetőséget, amit az AD nyújt (pl. egy fiók tiltásánál törölnöd kell a hozzá tartozó api kulcsokat is, különben a mail servered továbbra is boldogan kiszolgálja).

--
Egyébként a korrekt megoldás erre a problémára a Kerberos és a constrained delegation vagy forwardable ticket. A webszervered (mondjuk egy mod_auth_gssapi-val) kér egy S4U2Proxy ticketet a klienstől, azzal azokat a Kerberizált szolgáltatásokat, amiket engedélyezel neki, a usert megszemélyesítve el tud érni. Mondjuk ehhez az is kell, hogy a webes kliensed tartományi tag legyen és elérje a KDC-t, ill. kerberizálnod kell mindent.

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

> A problémát (jelszó birtokában a user megszemélyesíthető) nem fogod tudni azzal megoldani, hogy kiosztasz mindenféle tokeneket,

Mar hogy a viharba ne? Ha LAN felol engeded a gyenge felh+jelszot, kivulrol meg csak az apikey+bonyolult_jelszo. Brute force ellen majdnem olyan jo mint egy sshkey.

> Brute force: old meg alkalmazás-szinten vagy külön eszközzel (fail2ban)

Mostanaban botnetek probalkoznak: azaz szinte minden probalkozas kulon IP. Egy IP-rol max 2 probalkozas jon, ritkan 3.

Mivel a dolgozok jo resze rendszeresen jar kulfoldon (havi szinten 1-1 hetet), igy a geoip alapu dolgoktol felek.

Itt egy apikey dokumentacio: https://sendgrid.com/docs/Classroom/Basics/API/what_is_my_api_key.html
A hossza van vagy 70 bajt.

Meg gondolkodok mit csinaljak. Lehet, hogyha elotte megnez egy weboldalt, akkor az ip-je whitelistre kerul 2 napra. Es utana mar csinalhat amit akar a felh+jelszoval.

Jo lenne a felh+jelszokezelest kozpontositani...

> A webszervered (mondjuk egy mod_auth_gssapi-val) kér egy S4U2Proxy ticketet a klienstől,

Az, hogy minden webszerver authot tovabbdobok az nem jarhato ut szerintem. Akkor mar ugy kellene csinalni, mint ahogy a synology is csinalja. Ha belepteted AD-ba, akkor le tudod frissiteni a komplett AD-t, es ugy lokalisan autholja a felhasznalot.
Ha valtoztatsz valamit (felhasznalo jelszavat pl.), akkor csak utana tudsz belepni, hogyha adminkent ranyomtal a synology control panelban az active directory sync-re.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Mostanaban botnetek probalkoznak: azaz szinte minden probalkozas kulon IP. Egy IP-rol max 2 probalkozas jon, ritkan 3.

Akkor alkalmazás szinten: account lockout. Ha központi authot csinálsz (Samba/AD), akkor ezt "ingyen" megkapod (4.2 és utáni verziókban samba-tool domain passwordpolicy környékén tudod beállítani).

Brute force ellen majdnem olyan jo mint egy sshkey.

A delegálhatóságot nem oldja meg, de ha ez kell (web/mail/..., kívülről elérhető szolgáltatások), akkor csinálj egy saját CA-t és azonosíts mindenkit cert alapján. Visszavonható, központosított, ...

Az, hogy minden webszerver authot tovabbdobok az nem jarhato ut szerintem.

Kerberosszal csak egyszer terheled auth-tal a KDC-t, utána már az először megkapott tickettel azonosítanak a kliensek. (egyébként működhet az, amit a RedHat-os/Fedorás Cockpit csinál, hogy a login screen JS-ből teszi ki a usernév/jelszót mezőt, _miután_ csinált egy xmlhttprequest-et [hogy a user ne kapjon jelszó ablakot] egy GSSAPI-t használó url-re és visszakapott egy hibakódot. Ha sikerült a GSSAPI auth, bevágja a sessionbe, hogy ki a user, és azonnal átirányít a nyitólapra)

---
Egyébként újabb ötlet (talán hosszabb távon ez a legbiztonságosabb): kliensek belülről Kerberizált szolgáltatásokkal, kívülről certekkel dolgoznak. Leszámítva, hogy neked, mint CA-nak időnként az aláírással/visszavonással/... foglalkoznod kell, nincs sok különbség az API key-hez képest (mármint ugyanúgy külső azonosító token), viszont legalább a szerver/kliens programok jobb eséllyel fogják támogatni értelmesen (pl. tök jó lehet a mail naplóban azt olvasni, hogy "apikey" egész nap küldözgeti a leveleket)

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

Egy ideje nem tudtam ezzel jatszani.
Odaig eljutottam, hogy AD-val tud autholni a programom (node ldapjs), es meg tudom allapitani, hogy a felhasznalo+jelszo helyes vagy nem.

Es itt megint beszippantott egy hetre egy fekete lyuk:
active directorybol password cache-t kb. lehetetlen kinyerni.
Tehat a lenyeg az lenne, hogy a jelszo adatbazis leszinkronizalna az app, es
mindenkit le tudna helyileg ellenorizni. De termeszetesen csak a hash-et.

Erre van millio stackoverflow-os kerdes is, pl:
https://security.stackexchange.com/questions/100271/extract-password-ha…

Egyebkent megneztem a synology-t is, hogy hogyan csinalja, mert oda belepve is
kb. azonnal authol. De ha az active directory gepet a halozatrol kiveszem, akkor
ott is megakad a belepes.
(Bar mintha lenne valamennyi cache-e, de a komplett adatbazis hash-et nem kapja meg imho).

Igy arra a vegkovetkeztetesre jutottam, hogy a legegyszerubb, hogyha a windows-os AD-t kivaltom SAMBAval, es akkor linux alatt azt oldok meg amit akarok:) (pl. mysql-be teszem a felh+jelszavakat)

Szoval most a kiteroprojekt egy normalis SAMBA telepites AD-val, window 7,8,10 beleptetessel.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Tehat a lenyeg az lenne, hogy a jelszo adatbazis leszinkronizalna az app, es mindenkit le tudna helyileg ellenorizni. De termeszetesen csak a hash-et.

Ne.

Inkább csináld azt, hogy az ldapjs elé teszel egy cache-t, ami auth request-kor ellenőrzi, hogy volt-e azzal a jelszóval (tetszőlegesen hasheld) sikeres belépés az elmúlt X időben, ha igen, engedje be (és szintén cache-ből olvassa be a user adatait). Ha nem volt ilyen kísérlet, akkor kérdezze az ldap-ot, ha nincs ldap, akkor meg hajtsa el a usert.

Alternatív megoldás, hogy a cache felelősséget átadod egy winbind-nak (az tud offline auth-ot) vagy sssd-nek (szintén) és mondjuk pam-on keresztül ellenőrizteted az auth adatokat.

Igy arra a vegkovetkeztetesre jutottam, hogy a legegyszerubb, hogyha a windows-os AD-t kivaltom SAMBAval, es akkor linux alatt azt oldok meg amit akarok:) (pl. mysql-be teszem a felh+jelszavakat)

Ha AD-t akarsz és nem régi NT domain-t (kliensek nem fogják szeretni), akkor nem, akkor a Samba saját LDAP-jában kell, hogy legyenek a usereid.

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

Az alap problémám, hogy amit használnak, az az interneten van, így nem szívesen autholnék egy külső weboldalról egy belső AD-ra.

Igazából még azt se találtam ki, hogy hogyan menne ez az auth kívülről.
Helyi hálón próbáltam ki, ott persze működik.
Nem szívesen nyitnék a nagy világba 139, 88, 445-ös portokat:
https://wiki.samba.org/index.php/Samba_AD_DC_Port_Usage

Szóval lehet, hogy az auth requestet át kellene dobni egy belső hálón lévő "gateway"-nek, ami aztán authol, és visszaadja az eredményt (https-en).

Biztos van erre valami best practice...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ha nem lennének 7-es kliensek is _és_ mindegyik kliens tartományi tag lenne, akkor csinálhatnád, hogy az alkalmazás Kerberos-szal hitelesít (mod_auth_gssapi-val pl.), az AD melletti DMZ-ben meg felteszel egy KDC proxy-t (pl.: https://github.com/latchset/kdcproxy). Így két 443 kell össz-vissz, a KDC proxy elég, ha tcp-n/udp-n csak a kerberos portokat éri el, és neten keresztüli single sign-ont kaptál. (Szerk.: Disclaimer - ezzel _még_ nem játszottam el, de határozottan tetszik az ötlet :) )

Szóval lehet, hogy az auth requestet át kellene dobni egy belső hálón lévő "gateway"-nek, ami aztán authol, és visszaadja az eredményt (https-en).

Az AD mellett DMZ-be fel tudsz tenni egy SAML/OAUTH/Shibboleth/akármirandomlégyszihitelesítsaweben mókát, ott akkor megintcsak egy ldap portot kell csak engedélyezned egy saját felügyelet alatt álló szervernek, akár működhet is. Kérdés, hogy az appot mennyire bonyolult erre felkészíteni.

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

( Zsugabubus | 2017. 06. 01., cs – 12:49 )

Miért nem csinálsz egy service accountot az automatizálónak, olyan hosszú jelszóval, ami belefér, ennek az acc-nak meg beállítod, hogy hozzáférjen ahhoz, amihez a felhasználónak kell. Szerintem nem jó ötlet keverni a valós és az ilyen szervíz usereket.

tök jó lenne olyan szinten megoldani, ahogy a google-nél van:
https://console.developers.google.com/apis/credentials/key/

generálhatsz apikeyeket (többet is), és ezt te magad, mint user megteheted.

Ezt szeretném igazából leutánozni AD alapokon:)

Biztos tök egyszerű, és van kismillió tutorial, csak én nem találom.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ez filozofia kerdes, bar nem tudom, hogy miert jott elo.

A csopiknal kell egy atyauristen (eg. rendszergazda) aki vegigmegy a fajlokon, es eldonti, hogy kinek van joga hozza.

Mig a masik esetben, minden valakie, aki aztan eldonti, hogy kivel osztja meg.

De ez a mostani felvetestol tok fuggetlen problema (itt most single-sign-on van, amit kb. elvetettem mert firefoxhoz is kiegeszito kell hozza, kozponti auth, apikey (kivulrol csak bonyolult felh+jelszoval lehessen bejonni), stb).

Persze lattam olyan megvalositast is, hogy a webappnak van egy kulon felhasznaloneve, aki egyebkent az AD-t is tudja query-zni.
Es kitallozza, hogy a user aki belepett az adott csoport tagja-e, es a webapp aztan eldonti, hogy teljesiti a user kereset, vagy sem.
(ebben az esetben a webappnak eleve van joga teljesiteni a user kereset, amit o megtagad, ha kell).

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Azért jött elő, mert a google ezt tudja, az AD meg azt. Tekintheted filozófiai kérdésnek, de ha egyszer az implementáció az egyiket tudja, akkor neked kéne alkalmazkodnod. Csoporttagságot egyébként a user is tudhat állítani a saját fájljain. Viszont egyet nem írtál még, hogy egyáltalán milyen szolgáltatáshoz akarod használni ezt +jelszót? Csak úgy AD-be bejelentkezni elég öncélú lenne.

Egyébként SzBlackY szösszenetét átgondolva, keytab fájlt csinálhatsz a user adataival, amivel kérhetsz Kerberos tikettet, fájmegosztáshoz való csatlakozáshoz ez biztos felhasználható, az MS webappjaihoz is.

a webalkalmazas a user neveben tud levelet kuldeni utemezve throttling-gal.
Nevjegyet kezel (12ezer), verziokezelessel, csoportokkal, tulajdonos atadassal.
Ez szinkronizal a carddav szerverrel ami az outlookkal.
Projektet lehet kezelni vele, fajlt tud betenni a belso haloba.
Ilyesmi.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

amit kb. elvetettem mert firefoxhoz is kiegeszito kell hozza

Hát az attól függ :) Domain tag gépről nem (Kerberos/NTLM), nem-domain tagról fallbackelhetsz sima HTTP Basic auth-ra (az apache-os mod_gssapi is tudja már, a RedHat-osok egy darabig nem akarták bele tenni) - az egyetlen hátulütő, hogy a profilban engedélyezned kell (network.negotiate-auth.trusted-uris) a címeket, amik auth-olhatnak (shameless plug: nézz szét az itteni blogomon, linkelek egy github repót, group policy alapú firefox profil csesztetéshez).

Persze lattam olyan megvalositast is, hogy a webappnak van egy kulon felhasznaloneve, aki egyebkent az AD-t is tudja query-zni.
Es kitallozza, hogy a user aki belepett az adott csoport tagja-e, es a webapp aztan eldonti, hogy teljesiti a user kereset, vagy sem.

Azért ennél is tovább lehet menni, ha igazán kártyavárat akarsz építeni és nem gond, ha csak a bolygók megfelelő együttállásánál mennek a dolgok :) Ha tisztán Kerberos alapon hitelesítesz, használhatsz S4U2Proxy kiegészítést, amivel a Kerberizált szolgáltatásod (ez ugye jelen esetben a webapp-od) más Kerberizált szolgáltatásokhoz (amiket expliciten engedélyezel neki) érvényes ticket-et kérhet ki, ha felmutatja a usertől kapott ticketjét (leegyszerűsítve - Constrained delegation néven hivatkozik rá az MS, tőlük származik). Így a webappnak csak egy SPN kell a hozzá tartozó keytabbal, semmilyen extra jogosultság nem kell neki, mindig legfeljebb ahhoz fér hozzá, amihez a bejelentkzett user is. Tehát pl. egy doksi megosztós site-on eljátszhatod, hogy a storage-nak egy smb share-t használsz, amikor a user el akar érni egy doksit, akkor az ő nevében kéred ki a fájlt, és ha elhajt a fájlszerver, akkor közlöd a userrel, hogy "jahátbocs" - és egyébként olyan ACL-ezést csinálhatsz, amilyet csak akarsz/enged a Windows/NT ACL rendszer. Persze sajnos ez eléggé kártyavár még, de lehet vele játszani.

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

Ha más nem, bővíts LDAP sémát (IANA-nál beregisztrálhatsz Private Enterprise-ként, és akkor lesz globálisan egyedi OID-d is hozzá), egy sima többértékű attribútummal, aztán ACL-lel lődd be, hogy SELF tudja írni/olvasni (vagy ha az API kulcs kezelőd is egy külön szervíz fiókkal megy, akkor arra), a szervíz account-od, ami az auth-ot végzi tudja olvasni, aztán kb. készen is vagy. Az authentikáció rész meg van azzal, hogy indítasz egy LDAP search-öt, hogy van-e ilyen kulcs a rendszerben, az authorizációt pedig már intézheted csoporttagság alapján. A userről szükséges esetleges adatok meg ott vannak mellette.

Persze az LDAP séma módosítás többé-kevésbé MS-nél egy visszavonhatatlan művelet (Sambánál egyszer belefutottam egy ismétlődő OID-be... sikerült kiszednem, de...), úgyhogy egy teszt környezetben NAGYON teszteld végig, mielőtt élesbe is deployolod.

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

Itt par 5let elojott, igy valoszinu egy honapra megint eltunok, vagy ahogy az idom engedi.

De a legegyszerubb az lesz, hogy valahogy authol az AD-hoz, de a jelszot elteszi maganal is (a hashet), majd mar csak akkor authol amikor nagyon szukseges (tehat a user nem a webappon belul marad, hanem mas adathoz is hozza akar ferni a webappon keresztul).

A kerdes az, hogy valahogyan lehet-e lekerni az AD-t, hogy a sok user+felh kozul valamelyik modosult-e. Azaz a helyi cache-t lehet-e invalidalni valahogy.
Felh+ jelszo honapon belul szinte tuti nem valtozik.

Vagy itt is maradok a favago megoldasnal, es amikor beprobalkozok a felh+jelszoval es nem egyezik a regivel, akkor a komplett lokalis cache-t invalidalom.

Valoszinu az AD hozzaferest kiveszem egy kulon kis service-be, hogy ne legyek nagyon platform fuggo. Meg hatha egyszer az ms tenyleg becsodol.
Minden even varom:).

Valami oauth-os moka jobb lenne, csak ugy latom az ms, most az azure-on keresztul adja:
https://technet.microsoft.com/en-us/library/dn633593.aspx

De ezt a vonalat is korbe kell jarni. Mielott valami nagyon egyedi dolog kerekedne...

Szerintem, ha atmigralok samba ala, akkor az egesz problemakor kenyelmesebb lesz a szamomra... :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szerintem, ha atmigralok samba ala, akkor az egesz problemakor kenyelmesebb lesz a szamomra... :)

Ha nem teljesen mindegy, hogy Samba AD vagy MS AD van-e mögötte, akkor rossz a megoldás, mert valami olyat akarsz csinálni, amit nem kéne.

Én továbbra is az sssd-t/winbind-ot ajánlanám (akár úgy, hogy kihúzol egy tunnelt az egyik DC és a webapp szervere közé), különben jó eséllyel egy csomó funkcionalitást újra kell implementálnod (lásd: cachelés [csak akkor, ha nem érhető el a DC], az összes lehetséges ok, ami miatt nem kéne, hogy sikerüljön az auth [fejből: lejárt fiók, lejárt jelszó, túl sok sikertelen próbálkozás, forrásgép/idő korlátozás, letiltott fiók, ...]). Lehet kézzel, egyesével mindegyiket nézegetni, de ahhoz bele kell menned az AD sémákba.

--
De egyébként ha adnál részleteket (kik fogják elérni a webappot, hogyan fogják elérni a webappot, a klienseket mennyire tudod konfigurálni, ...), lehet, hogy tudnánk pontosabb ötleteket adni.

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

Nem szeretnek folyamatos authot, mert a lokalis halo internete az nem a legmegbizhatobb. Szoval cache-eles az muszaj.
Meg olyat is, hogy egy session-on belul, ha nem sikerul autholni rogton akkor a hatterben a webapp azert probalkozhat, mikozben hagyja a usert dolgozni.

Szoval nem akarok ilyen login.live.com szintu valamit... :-D

>Ha nem teljesen mindegy, hogy Samba AD vagy MS AD van-e mögötte, akkor rossz a megoldás, mert valami olyat akarsz csinálni, amit nem kéne.

Ez meg az a vonulat volt, amikor a samba jelszavait egy kulso adatbazisba (mysql) tarolom, amit aztan akar a sambat megkerulve is tudnam olvasni...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( khiraly | 2017. 06. 01., cs – 16:33 )

Összefoglalva, amolyan hangosan gondolkodás.

Létrehozok egy lokális Oauth szervert, kb. ilyet:
https://github.com/oauthjs/node-oauth2-server

Ez fogadja https-en keresztül a felh+jelszót, amit memóriában megjegyez, és visszaad egy tokent.
Ez lenne a AD gateway, amit mondjuk DMZ-be is betehetek.

Jelenleg, lehet, hogy az oauth felesleges is, és elég egy GO/NOGO válasz.

Az egész oauth szervernek az a lényege, hogy bruteforce-t megakadályozza, ne kelljen új portot a nagyvilágba megengedni.

Köszönöm az értelmes javaslatokat, át fogom nyálazni őket.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....