LDAP vs AD

Microsoft Windows

A cegnel eleg kaotikus az autentikalas... mondjuk leginkabb nincs semmi semmivel integralva, kb ahany eszkoz annyi user adatbazis. Szinte minden beszel LDAP-ot, gondoltam felrakork egy OpenLDAP szervert (vagy kettot, hogy tukor is legyen) es szepen lassan bekotok mindent arra. Csakhogy...

Mindenfele gepeink vannak, Linux, OS-X es persze Windows-ok, mar van egy Windows domain active directory-val is (ezt nem en csinaltam, talan Windows 2008 serverrel... ha ez szamit). Namost a problemam az, hogy ez hogy fog egyutt menni az en LDAP-ommal. Vagy hagyjam is az OpenLDAP-ot es hasznaljam kozvetlenul az AD-t? Ez utobbitol egy kicsit fazom, nem vagyok jartas a Windows vilagban igazan es amugy is, az OpenLDAP-ot jobban alakithatonak erzem, ha kesobb mas dolgokra is akarnam hasznalni...

Letezik olyan, hogy az AD kulso LDAP-bol (vagy kulso akarmibol) autentikaljon? Talan ez lenne a legjobb nekem... de felek ilyen nincs, vagy csak oriasi szivasok aran.

Esetleg szinkronizalhatnek is az OpenLDAP meg az AD kozott "kezzel", vagyis valami trigger alapjan. Ha modositja a user a jelszavat itt, akkor az modosul odaat is... (Szerintem jelszo szinkron eleg, nincs sok user, nem gond felvenni kezzel oket ket helyre, utana meg a jelszo szinkron kell csak.) Es ha ez mukodhet akkro melyik iranyba konyebb szinkronizalni? (A mindket irany tul mesesen hangzik.)

----------------------------------------------------------

update1 (2013.07.04.)

Na, halad a projekt... igerem ha keszen lesz irok valami kis howto-t, egyreszt mert erdekes, masreszt mert ahogy latom sokakat erdekel.

Nincs teljesen a kezemben a dontes... ugyhogy vegul az lett, hogy minden az AD-ben van, azt okositom fel UnixHomeDirectory, meg hasonlo atributumokkal userenkent. Szoval nincs meg egy LDAP, csak az AD-van, abban oldok meg mindent. A usernevek is egysegesek lesznek, de ott is hosszuakat kell hasznalnom (hosszu: keresztnev.vezeteknev), aminek nem orulok, de azota megbaratkoztam a gondolatal, ha mukodni fog a usereknek valoban egyszerubb lesz az elet (nem kell ketfelet megjegyezni, meg ertetlenkedni, hogy miert van ketfele).

Jelenleg "proof of concept" mar mukodik, vagyis egy AD userrel be tudok jelentkezni egy olyan Linux hostra amin ez a user lokalisan nem letezik, sot a userhez tartozo groupok is az AD-bol jonnek. Van meg nehany megoldando problema:

  • A legnagyobb bajom, hogy az AD-hez nem sikerult anonymous modon csatlakoznom, vagy ugy egyaltalan az AD-hez valo hozzaferest nem nagyon tudom szabalyozni. Most felvettem egy user-t az AD-ba csak azert, hogy a Linuxos kliensek elerjek az LDAP-ot. Vegulis lehet, hogy ez jo igy, de mindket esetben (anonymous vagy user) jo lenne szabalyozni, hogy ezek az adminisztrativ userek mit ernek el az AD-ben, vegulis csak nehany agat kell tudniuk olvasni es ott sem feltetlenul minden attributumot.
  • A userekhez kezzel kell felvenni a Unix tulajdonsagokat az AD-ben (pl a mar emlitett UnixHomeDirectory), raadasul annyira kezzel, hogy nem is lattam ra opciot, hogy a GUI tamogatna, konkretan a mar modositott usereknek a Unix tulajdonsagai sem jelennek meg a GUI-n. A kisebbik baj, hogy nem latszik, a nagyobbik, hogy kezzel kell csinalnom, mikozben minden ertek elore szamolhato. A kerdesem: letezik olyan, hogy egy userfelvetelre automatikusan elsuljon egy script, ami meg csinal vele ezt-azt?
  • Az elozohoz reszben kapcsolodo problema, hogy nem lattam az AD user mar letezo atributumai kozott uidNumber-hez hasonlo azonositot (csak vaksi vagyok?), igy ezt jelenleg szamolnom kell, vagyis meg kell neznem az osszes mar felvett uidNumber-t es kivalasztani a kovetkezot. Vegulis nem akkora gond, ha az elozo pont teljesul (vagyis lesz automatikusan elsolu script), akkor megoldom, de mennyivel szebb lenne, ha csak az aktualis user objektumbol szarmaztathato lenne ez a szam
  • Baj van meg az offline hasznalattal. Vagyis amikor egy Linuxos laptop user az irodaban belep a gepere (AD-bol autentikal, autorizal), majd kikapcsolja, hazamegy, ott bekapcsolja (ekkor az AD-t epp nem eri el) es szeretne belepni... Erre talaltam a libpam-ccreds ami a jelszo cache-elesre mar jo, de ugye nekem nem csak jelszo kellene, hanem homedir, meg login shell, stb. Raadasul azt se lattam meg, hogy mennyi ideig cache-el, vagy hogy ezt barmi modon kontrolalhatnam, pedig ez is fontos lenne, hogy akar hetekig tudjon valaki offline dolgozni.

Az AD egy Windows Server 2012 ha ez szamit valamit.

----------------------------------------------------------

update2 (2013.11.06.)

No, egész jól állok. Az eredeti cél már teljesült, vannak Linux klienseim amik az AD-ból autentikálnak. Most viszont már látok egy két dolgot amit majd még szeretnék megcsinálni...
Mindenesetre, ahogy igértem, az eddigiekből írtam egy howto-t, fogyasszátok egészséggel:
hup.hu/blog/traktor: howto: Linux klines Windows Active Directory domain-ben

  • 29886 megtekintés

( Zsugabubus | 2013. 06. 28., p – 16:27 )


Letezik olyan, hogy az AD kulso LDAP-bol (vagy kulso akarmibol) autentikaljon? Talan ez lenne a legjobb nekem... de felek ilyen nincs, vagy csak oriasi szivasok aran.

Nincs. Windows nem beszél kizárólag LDAP-ot (és Kerberost), kellenek neki az AD egyéb nyűgjei.
Ha már ott az AD szerver, érdemes a Linuxokhoz is használni, Kerberossal. Egész jól működik. Kliens annyi van, mint égen a csillag, nss_ldap, nss_ldapd, sssd, maga a samba (winbindd), jópár fizetős is akad (Quest Authentication Services pl. kifejezetten AD-hez van).

En nem banom ha van AD-nek egyeb nyugje, csak ha a jelszomezot hajlando lenne mashonnan kiolvasni (pontosabban a jelszot mashol ervenyesittetni), az mar eleg lenne nekem. Nem zavar, hogy emellett az AD meg csillio dolgot tarol.

Es az AD-ben tarolt adatokat mennyire tudom faragni? Pl, ha szeretnek egy UnixHome (/hom/jani) mezot felvenin az AD-be a userekhez, azt megtehetem? Na es pont ez amiert az AD melyebb hasznalatat elkerulnem ha lehet. Nem ertek hozza, es tartok tole, hogy az MS se pont arra talalta ezt ki amire en hasznalni akarom...

Vagy csinaljak egy OpenLDAP-ot az autorizaciora (home dir, ilyesmi) es az autentikacio menjen az AD-bol? Itt meg az a bajom, hogy az AD-ben keresznev.vezeteknev alaku usernevek vannak, azokat meg le is kene kepeznem valahogy mas UNIX usernevekre... Persze ezt asszem egyebkent sem uszom meg, valszeg el kell ernem, hogy az AD-ben is normalis 8 karakter hosszu usernevek legyenek.

Na igen, kerberosrol meg nem is beszeltem... Pl olyat tudnek csinalni egy Windows AD-vel, hogy en a Linuxos kliensemen kerek egy ticket-et es azzal mondjuk bessh-zok egy tavoli (szinten Linux) szerverre? Felek nem...

Aztan meg az is gond, hogy kicsit leegyszerusitettem fent a helyzetet, azt mondatam van Linux, OS-X meg Win. Valojaban meg csillio eszkoz van (NAS, webes alkalmazasok) amiket szinten integralni kellene. De gondolom ami tud LDAP-ot, azt az AD-vel is ossze lehet kotni.

"Es az AD-ben tarolt adatokat mennyire tudom faragni?"
Akár teljesen, szabvány LDAP eszközökkel.

" Pl, ha szeretnek egy UnixHome (/hom/jani) mezot felvenin az AD-be a userekhez, azt megtehetem?"
Meg, de fölösleges, a Microsoft már megtette helyetted:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680522(v=vs.8…

Unix jelszót is tárolhatsz: http://msdn.microsoft.com/en-us/library/windows/desktop/ms680526(v=vs.8…

Ha ne adj' Isten mégiscsak sémát kéne bővítened, amit nem valószínűsítenék: http://msdn.microsoft.com/en-us/library/windows/desktop/ms676929(v=vs.8…

"olyat tudnek csinalni egy Windows AD-vel, hogy en a Linuxos kliensemen kerek egy ticket-et es azzal mondjuk bessh-zok egy tavoli (szinten Linux) szerverre? Felek nem..."
Nem kell félned, igen.

Üdv,
Marci

Hmm... ez sajnos jol hangzik. :)
Pedig szerettem volna megallni, hogy Windowsos tudast kelljen felszednem. :) Na meg, gondolkodom rajta, ha tavol tudnek maradni az AD piszkalastol, az meg mindig jobban tetszene. Ha masert nem, mert gyorsabban haladnek. (Legalabbis kezdetben biztos.) DE amugy masert is. ;)

Hello,

nem visszafordítható, bár a létrehozott osztályok és attributumok letilthatók (defunct).
Az AD visszatölthető a sémabővítés előtti állapotra (authoritative restore) azonban erre alaposan érdemes felkészülni, ha ilyet tervezünk.
Egyébként nehezen tudom elképzelni, hogy többszöri tesztelésen kívül mi az az ok, amiért vissza akarnék vonni egy osztály/attributum létrehozását. Neked miért kellene?

Üdv,
Marci

nem kenyszer miatt, hanem arrol van/volt szo, hogy egy spamszurohoz akartam AD tamogatast csinalni, es ezt az 1.0-ban ugy oldottam meg, hogy pl. a spamszuro policy beallitasokhoz csinaltam megfelelo objektumokat. De kesobb rajottem, hogy sokkal praktikusabb ezt a spamszuron belul a sajat adatbazisaban megoldani. Ezert toroltem volna az igy foloslegesse valo elemeket es tipusokat az AD-bol, ha nem emlekeztem volna ra, hogy ez nem fog menni... :-)

Diktatorok kezikonyve

Oks, azt hittem nem tudom mirol van szo, de ez az amit en hanyagul "ldapsearch -b..."-nek neveztem. Csak nem esett le, hogy ennek mi koze lesz az egesz autentikacios folyamathoz... de most mar megvan. Tehat a pam nem ugy fog autentikalni, hogy kiveszi az LDAP-bol a user/jelszo(hash) parost, hanem egyszeruen megnezi, hogy az adott user+jelszo-val tud-e az LDAP-hoz (ez esetben AD-hez) csatlakozni, igy van?


The password is stored in the Active Directory on a user object in the unicodePwd attribute. This attribute can be written under restricted conditions, but it cannot be read. The attribute can only be modified; it cannot be added on object creation or queried by a search.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;269190

Valahol meg még a LanMan password is tárolva van (mint a Sambán), de azt nem írja hol, meg az kikapcsolható.

Na, lehet, hogy lassan rabeszelem magam az AD komolyan vetelere... meg egy dolgot latok kritikusnak, hogy az AD-ben "keresztnev.vezeteknev" alaku userneveim vannak, amit Linuxon nem szivesen hasznalnek. Letezik az, hogy minden usernek legyen egy "alias" usere is? Vagyis, hogy a Ferenc.Toth-ot hasznalhassa Windowson, "feri"-t meg Linux-ra ssh-zaskor. Hmm... bar lehet, hogy ez overkill, mindenki elete egyszerubb lenne, ha csak egy usernev lenne... Na, de azert erdekel, megoldhato?

Hu, fejbol meg nem mondom, de asszem ha csak siman atnevezed oket, az mukodni fog, az eredeti nevet meg rakd be displayName -nak. Illetve, ha mar arra jarsz, erdemes ugy megirni a scriptet, hogy a nev reszei bekeruljenek a surname es a givenName attributumokba is, ha azok uresek lenennek. A Windowsos logint ez nem fogja befolyasolni, mert az a sAMAccountName alapjan megy.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A "problemmentesen autentikalnak" meg a "rendszer teljes koruen tamogatja" kozott azert en oriasi szakadekot latok. Nem mondom, hogy nem fog mukodni, de nem latok okot, hogy szivassam vele magam, szivast meg mar elore latok vele. (Lasd kicsit lejjeb a "top"-ot, ami nyilvan csak egy pelda ami eszembe jutott.)

Mert zavar.

Teszt.Ferenc a top-ban (nem kell sokat agyalni rajta, hogy hamar eljohet az a szituacio, amikor ez nem csak zavaro, de konkretan akadalyoz is (nem lehet ket usert megkulonboztetni): 


  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+ COMMAND                                                 
 8172 Teszt.Fe  20   0 92584 2300 1652 S    0  0.0   0:00.00 su                                                      
 8180 Teszt.Fe  20   0 32816 9852 1672 S    0  0.1   0:00.35 bash

Mondjuk nekem az is faj amikor az adduser-hez mar force kapcsolot kell hasznalni... De lehet, hogy csak egyszeruen konzervativ vagyok. Nem latom az igazi elonyet a hosszu userneveknek.

Nem vagyok programozó, de más úton biztos meg tudnám oldani ha arról lenne szó, de azért valljuk be, hogy nem tűnik olyan nagyon ördögtőlvalónak az ötlet, hogy támogassa, főleg egy ilyen alapvető program és ne kelljen trükközni/faragni, kényelmesebb lenne mindenkinek ez sem egy utolsó szempont.

nem fos az, csak nem arra lett anno kitalálva hogy a 20 akárhány karakterű felhasználó nevekkel használják.
a linuxok tipikusan nem nagy.józsefné.mária.tardakövesi.gizella-ra lett szabva hanem john.smith-re stb.
+ ha túl hosszúak a nevek használjatok ID. több banknál is láttam, és mielőtt lefikáztok, működött és a userkek,
még az ablaknál ülő Marika is megtanulta az azonosítóját vagy felírta magának. kb ilyenek voltak
1294783uid
ez ugye 1 híján 10 millió usert kezel. hol van ennél több? szerintem még a kínai állami szféra is kisebb mivel nem egy rendszer kezeli az egészet.

ja meg hogy hogy lehet a UID alapján megtalálni az embert? egy webes felület ahol lelehet kérdezni a publikus user attribótumokat és kész is. mindjárt kiderül hogy hogy Kiss János csinálta a gebaszt BAZ megyéből és nem az aki mellett ül.
ennyi.
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

Ilyen helyen/létszámnál már egyértelműen kell egy normális felhasználókezelés, ami LDAP/AD héttér mellett tökéletesen megoldja a 678gjaka - Gisz Jakab összerendelést. Ez lehet webes/grafikus felület is, de unix-os környezetben egy getent passwd 678gjaka is elég kell legyen.

Azért remélem érzed a workaround szagát a dolognak...

De mindegy, nincs kedvem ma még egyszer elvitatkozni valakivel amiatt, hogy nehogy már a fos, valós igényekre nem felkészült eszközökhöz kelljen a feladatot alakítani. Kit érdekel, hogy mire lett szabva 20 évvel ezelőtt az Unix, 2013 van. Ha beírom, hogy top, nem azt akarom látni, hogy d123123123 user okozza a gebaszt, hogy aztán még külön listát kelljen bogarásznom, hanem azt, hogy akkor kovács bélának a fejébe kell a baltát beleállítani...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azért remélem érzed az ellentmondás szagát a mondandódnak.

Mivel a (nem 20, hanem több, mint 40) évvel ezelőtt kitalált UNIX rendszerek jellemzőit vette át a Linux is, így bizonyos dolgok olyanok, mint azokban. Tekintve, hogy a szerverek jelentős részén nincs grafikus felület, és meglehetősen kis számban használják ezeket a gépeket a rendszergazdák 1600x1200 (vagy pláne e fölötti) pixelszámú framebuffer konfiggal, ellenben meglehetősen gyakori a 80x25-ös karakteres üzemmód (*), az ls/top és társai nem a valós igényekhez, hanem a valós körülményekhez igazodnak, és ekkora kijelzőre optimalizálták őket.

Igényem nekem is lenne értelmesen gondolkodó vitapartnerre, de többségében olyanokkal találkozom, akik hőzöngenek gondolkodás helyett, így aztán alkalmazkodok a körülményekhez.

(Személy szerint kurva idegesítőnek tartom, hogy a mai napig találkozok olyan wines alkalmazással, ami fix, átméretezhetetlen ablakmérettel dolgozik - akár az up-to-date űberfasza oprendszer szerves részét képezők között is, de azért nem fogom kurva fennhájázó módon kioktatni Gipsz Jakabot arról, hogy mekkora fasz azért, mert ő azt használja.)

(*) rendezzünk szavazást az általános konzol/terminálemulátor méretről

"bizonyos dolgok olyanok, mint azokban"
De ezen konnyu valtoztatni.

"meglehetősen kis számban használják ezeket a gépeket a rendszergazdák 1600x1200 (vagy pláne e fölötti) pixelszámú framebuffer konfiggal, ellenben meglehetősen gyakori a 80x25-ös karakteres üzemmód"

Ez kisse idejetmult elkepzeles. Ma a rendszergazdak viszonylag nagy resze felevente-evente egyszer ha latja a sajat gepenek a konzoljat, es akkor altalaban nem topot vagy ilyesmit futtat, hanem peldaul a RAID BIOS-t turja. A legtobb esetben pedig de, 1280x1024-ben vagy meg nagyobban nezi a gep konzoljat SSH-n at.

De egyebkent adodik egy nagyon jo megoldas: intelligensen roviditeni. Ha nem ferne ki - de csak akkor! -, rakja ki az UID-ot, ha meg kifer, akkor mehet a felhasznalonev ugy, ahogy van. Es a terminal meretet lekerdezni ma mar nem ordongosseg, kozepesen hulyeknek szant C tutorialok kezdodnek ugy, hogy hogyan allapitsuk meg a terminal mereteit ioctl hivasokkal.

Tudom, egy rohadt eretnek vagyok, mert azt varom, hogy 2013-ban azt varom, hogy egy app ne az 1987-es szemleletmoddal tolja, hanem annal kisse modernebbel.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Az ssh-s elereshez:

http://hup.hu/node/125253#comment-1618964

Az inteligens roviditessel egyetertek, de azzal pontosan ott vagyunk, ahonnan a hoborges elindult:
ha valakinek nem tul jo az Sz123456 loginnev, annak ugyanannyira nem lesz jo a 12345678 UID a listaban.

Aki meg 2013-as szemleletmodot var, annak tobb lehetosege van:

- hasznal 2013-as rendszert
- hasznal regebbi rendszert es aktivan tesz azert, hogy megfeleljen az igenyeinek
- trollkodik

Már ne is haragudj, de hol élsz te? Egyrészt köszöni szépen, meglehetősen sok desktop app van, ami képes távoli szerverre csatlakozni, (pl. sql management studio, csak hogy egyet is említsek), másrészt a grafikus driver és a grafikus felület két külön fogalom. Harmadrészt ez a szerverre nem rakunk grafikus felületet miért is van? Ja, mert az ipar megint megragadt egy n+rengeteg évvel korábbi bullshitnél, mert nem volt képes saját korlátain és vi+bash fanboiok előítéletein túllépni?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Speciel használok, csak épp a jelen téma az volt, hogy van néhány kőkorszakban megragadt rendszer, ahol ilyen apróságok "akadályozzák" meg az emberek munkáját, mint egy nyomi ls meg ps kimenetének limitációi.

Gondolom érezhető, hogy mennyire ciki, ilyen "bagatel" dolgok miatt "má$" rendszert javasolni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Errol jut eszembe. a Windowsos 'cmd' a mai napig nem rakhato teljes kepernyore, csak fuggolegesen maximalizalhato, vizszintesen ragaszkodik a 80 karakterhez. Sot a "vaciuj" powershell-t is ilyenre csinaltak valamiert.

Mindezt nem azert irom, hogy mondhassam, hogy "na latod a Windows is szar", csak mert tenyleg nem ertem miert hagytak igy. Bosszanto, ugyanugy ahogy Linuxon a hosszu usernevek kezelese.

O, anyam. Kivancsi vagyok hany ember talalta ezt meg magatol (ugy ertem akinek nem megmondtak -mint nekem-, hogy ott van, hanem kellett neki, megkereste es megtalalta ott). :)

Masreszt ez igy meg mindig nem dinamikus megoldas es eleg nehezkes is (nyitok egy ablakot, jobb klikk, popup, nyomkod...), meg akkor se ha lehet mas defaultot beallitani (nemtom lehet-e).

Gyanítom, hogy az egérrel való függőleges állítgatás is csak azért van, mert az semmilyen hatással nincs a terminálra, csak a megjelenítésére, míg a vízszintes igen (hiszen az befolyásolja a tördelést). Azért ne felejtsük el, hogy ez a konzolablak gyakorlatilag ugyanaz, mint ami az első NT-ben is volt, és úgy tudom kicsit spécibb, mint a többi ablak. Tehát technikai oka is lehet annak, hogy nincs megoldva a vízszintes átméretezés egérrel.

NNNNa, éppen aktuális szopás: ps kimenetének használása (ahelyett, hogy normális API hivással menne) és struktúrálatlan text fosásban való adattúrás (+ apróbb programhiba + saleses kollégák kreatív közreműködése) => Local DoS && rendszerösszeomlás.

<3 Linux & CLI toolkit

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Persze, nyilván tisztább lett volna úgy megírni, csak most egy pillanatra vonatkoztassunk el, hogy a ps kimenetéről volt szó... (Egyébként jelen esetben "normálisan megoldva" ugyanúgy félrevezetett volna valakit a procfs-ből kiolvasható érték, de ez már más kérdés).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kimenet feldolgozás... "ls -l --full-time" - mondjuk egy RHEL3 (esetleg RGHEL4, nem tudom, melyik) esetén egészen másképp néz ki, mint egy RHEL5-ön... Kellő mértékű szívást lehet vele okozni sok embernek, ha egy alkalmazás a régire épít, és a legtöbb esetben úgy oldják meg, hogy viszik magukkal a régi binárist, és a PATH-ban elöl szerepel a /home/apphome/bin...

( Cajga | 2013. 06. 28., p – 23:49 )

Tarolj minden usert AD-ben es a windowsokat ahhoz autentikald. Majd szinkronizald le FreeIPA-ra es a Linuxaidat meg ahhoz. Youtube-on talalsz videot hogyan kell szinkronizalni. Red Hat oldalan pedig talalsz doksit a freeIPA-rol.

A Windows Serverek eléréséhez a processzoronkénti licencen túl - néhány kivételtől eltekintve - minden felhasználónak/készüléknek rendelkeznie kell egy hozzáférési licenccel (Client Access License, CAL) vagy a hozzáférésnek egy External Connector licencen keresztül kell történnie.

Üdv,
Marci

Attól függ.
A Linux-os gépek/felhasználók jelenleg elérnek bármilyen Windows Server-en futó szolgáltatást vagy adatot?
Pl. File Server-t, Print Server-t, valamilyen Windows Server-en futó webes szolgáltatást/alkalmazást, adatbázist - akár más szerverek közbeiktatásával?

Üdv,
Marci

Beszeljunk csak authentikaciorol az egyszeruseg kedveert. Tehat 2 esetet erdekes (mert ugye vannak windows-ok es emiatt kell AD):
1. Csak AD van es valamilyen modon a linuxok direktbe authentikalnak az AD-vel (winbind, 3rd party software etc.).
2. A userek AD-ben vannak. Azt leszinkronizaljuk egy FreeIPA szerverbe es a linuxok ahhoz authentikalnak.

Melyiknel kell tobb CAL?

A szükséges CAL-ok száma a csatlakoztatott készülékek/felhasználók számától függ. Emiatt, véleményem szerint, azonos mennyiségű CAL szükséges.
A pontos használati feltételeket a Product Use Rights dokumentum tartalmazza, ennek tanulmányozását javaslom.

Üdv,
Marci

Koszi a valaszt. Valaszod alapjan en arra kovetkeztetnek, hogy a 2. esetben kevesebb CAL kell mivel csak a FreeIPA csatlakozik a Windows-hoz mig az elso verzional minden Linuxos gep.
De annyira nem erdekel a dolog, hogy Microsoftos license-eket olvasgassak. Azt hittem, hogy az itteni Winguru kollegak egybol ravagjak. :)

Hello,

nem számít, hogy az érintett eszközök közvetlenül csatlakoznak a Windows Serverhez vagy valamilyen közbetett szerveren/eszközön át, amely a Windows Server felé csak egy kapcsolatot nyit: ugyanannyi licenc kell.
Ez az ún. multiplexing, amiről a fent hivatkozott PUR ezt mondja:
"Multiplexing
Hardware or software you use to pool connections, reroute information, reduce the number of devices or users that directly access or use the product, or reduce the number of operating system environments (or OSEs), devices or users the product directly manages, (sometimes referred to as “multiplexing” or “pooling”), does not reduce the number of licenses of any type that you need."

Üdv,
Marci

Ezt régen is "csodáltam", hogy hogyan próbálja a kb. lehetetlent belefogalmazni a m$ a licenszstruktúrájába...

Keresztkérdés: egy nyilvános, ingyenes, anoním, de regisztrációt/bejelentkezést igénylő webes szolgáltatás esetére (mondjuk ha egy ebay-szerű vagy gmail-szerű valamit akarna valaki ilyen alapokon megcsinálni) milyen kivétel van a licenszfeltételek közé beiktatva? Mert az nyilvánvalóan irreális, hogy ilyen esetben a világ összes számítógépére megvegye valaki a CAL-t...

Hello,

a Szervezeten kívüli, tömeges felhasználók licencelésére szolgálnak az External Connector licencek. Ebben az esetben ezen külső felhasználók számára a hozzáférési licencet az External Connector adja, tehát CAL nem szükséges számukra. Egyébként ebben is - mint minden licenckérdésben - segít a PUR:

"External Connector License means a license attached to a Server that permits access to the server software by External Users.
External Users means users that are not either your or your affiliates’ employees, or your or your affiliates’ onsite contractors or onsite agents."

Üdv,
Marci

Szerintem meg kell, mert a CAL az - ahogy en ertem a MS licencinget - nagyjabol az engedelyezett user objektumok utan fizetendo. Tehat ha barmit az AD-bol akarsz authentikalni, akkor az osszes userednek kell CAL aki a 'barmi'-be be akar lepni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nincs forras, valaki nekem egyszer igy magyarazta. Fenntartom a tevedes lehetoseget, tekintve, hogy az MS licensinget nem latom at teljes mertekben. De az biztosnak latszik, hogy van valamifele kapcsolat az user objektumok meg a cal kozott. Ha kiokositasz, azt megkoszonom.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Hello,

csak a saját véleményemet tudom leírni, a licencfeltételeket nem értelmezhetem senki helyett.
Én nem tudok konkrét kapcsolatról az AD user objektumok meg a CAL között.
Viszont minden, a szerverhez csatlakozó készülékhez/felhasználóhoz CAL-t kell rendelni, ezért szerintem is kell CAL.
Pár következmény:
-Ha Neked van két user objektumod (egy normál meg egy admin), nem kell Neked 2 CAL.
-Ha van 15 service account-od az AD-ben, azok miatt nem kell külön CAL-okat venni.
-Ha a kilépett Kollégák accountjait nem törlöd, nem kell miattuk CAL-t hozzájuk rendelve tartani.

Üdv,
Marci

En ha jol ertem, annyi CAL kell, ahanynak koze van a windows-hoz. Pl. ha a penzugy, meg a sales, meg marketing a windows-on fugg, attol meg a dev-ek vigan elvannak az IPA-val, mikozben egy es ugyanaz az adatbazis lenyegeben.

Az mondjuk nem tiszta, ez a userekkel, de mi van a gepekkel? Azok csak akkor erdekesek, ha a domainbe vannak leptetve?

tompos

Gondolom igen, hat ami csak ugy all a sarokban es porosodik, annak jo esellyel computer accountja sincs. Ugyanez vonatkozik az osszes workgroupba kotott cuccra, vagy azokra, amiken egyaltalan nincs SMB-kompatibilis szerviz. Azok meg sem jelennek a rendszerben (legalabbis az AD-ben).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Hello,

ha az IPA az AD-ből veszi a dev-ek bejelentkeztetéséhez szükséges információt, akkor az én véleményem szerint multiplexing miatt az érintett dev-eknek kell licenc.

CAL-ból két féle van: felhasználóra illetve eszközre szóló és az Ügyfél választja ki a neki kedvezőbbet. A felhasználó az első esetben akárhány eszközről elérheti a szervert, míg a másik esetben egy-egy eszközt akárhányan használhatnak a szerver elérésére.

Üdv,
Marci

( kisg v | 2013. 07. 02., k – 16:31 )

Az nem derült ki, hogy nagyságrendileg mekkora lenne a domain, de pl. mehetsz teljesen Linux irányból is Samba4-gyel, ami AD kompatibilis. Egy kisebb domaint már rá lehet bízni. Ha nagyobb / bonyolultabb dolgot akarsz építeni, akkor Windows-zal lehet, hogy jobban jársz. Ha nem akarsz heggeszteni, akkor zentyal.org, teljesen weben konfigurálható a Linuxos AD.

( Zsugabubus | 2013. 07. 04., cs – 23:09 )

Az új problémákhoz:

A negyediket megoldja az nscd.
Az elsőt meg megoldhatot úgy is, hogy minden géphez csinálsz egy computer accountot, ennek meg by default adsz egy olyan csoporttagságot, mint a windowsos computer accountoknak.

Vagy ha egyszerűen akarod: használj winbinddet, az jó az elsőre és az utolsóra is.

A WINes GUI-t nem tudom, hogy lehet feléleszteni, de nekem rémlik, hogy van ott Unix attribútum szerkesztő.

Az nscd nem az igazi... vagy az en tudasom nem eleg meg az nscd-hez. Egyreszt kikapcsolas utan is mukodnie kell, szerintem az nscd alapbol nem tud ilyet. De a meg nagyobb baj, hogy ezek a cache-ek ugy mukodnek, hogy ha valami megvan a cache-ben, akkor azt mar nem kell keresni... Igy ha mondjuk beallitok 1 honapos TTL-t a cache-ben, az azt jelenti, hogy az AD-ben minden valtozas nagyon lassan fog lecsorogni a kliensekhez, raadasul nem is egy idoben (inkonzisztencia).

Nekem egy olyan cache megoldas kell ami:

  • file-ba ir es egy ujrainditas utan is "emlekszik" a rekordokra
  • jol szabalyozhato, hogy mit es mennyi ideig tarol
  • ha az AD elerheto, akkor igyekszik onnan olvasni, ha nem akkor a sajat tarolt adatait hasznalja (meg szebben: ha az AD elerheto akkor kisebbek a TTL-ek, mint amikor offline)

nscd is fájlba ír, de próbálj meg egy sima nscd restartot, nem veszik el a cache.
A positive-time-to-live és a negative-time-to-live paraméterekkel meg minden beállítható.

Az nss_ldapd tud olyat, hogy szól az nscd-nek, hogy törölje a cachet, amikor kapcsolat van az LDAP szerverhez.

http://arthurdejong.org/nss-pam-ldapd/nslcd.conf.5
nscd_invalidate

De a winbindd használata még egyszerűbb AD-hez.

Nem vagyok igazan kepben nscd-ben, de nekem az remlik, hogy ha korabban bajom volt a cache-sel (mert mondjuk tartalmazott egy azota mar torolt usert), akkor epp az segitett, ha ujrainditottam az nscd-t...

nslcd.conf-ban nem latok semmi cache-elesre vonatkozo parametert (cache-el ez egyaltalan?). Nem is ertem, hogy pontosan mire jo ez, miert akarna valaki ezt hasznalni, ha csak user-eket, group-okat tart LDAP-ban.

nslcd az nem nscd, az nem cache. A kettő tud együtt működni.
Nekem inkább az nscd -i passwd, ami segíteni szokott.

az nslcd az egy új nss_ldap és pam_ldap számára egy démon, jobb, mint a régi nss_ldap és pam_ldap (ami a www.padl.com-on van).

Hogy miért jobb:
http://arthurdejong.org/nss-pam-ldapd/

De hasonló, többet tudó dolog az sssd is.

Mondd mar el, melyikbe. Amennyire en tudom, az nscd pont azert jo, mert memoriaba cachel, es a cache-e nem perzisztens, vagyis egy sima nscd restart elfelejteti vele az elozoleg becachelt ertekeket. Ilyten modon nincs is ertelme, hogy fajlba cacheljen...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( BaT | 2013. 07. 04., cs – 23:25 )

A másodikra: ahogy nézem triggerek nincsenek, egy elég érdekes workaroundot javasolnak itt. De mi lenne, ha már a felhasználó felvételét is script végezné? PowerShell támogatása elég jónak tűnik (még szép).

( nomad84 (nem ellenőrzött) | 2013. 07. 05., p – 08:04 )

Centrify Express

Tobb ilyen "dobozos" megoldas is van. Nekem nem szimpatikus az ilyesmi, mert egyreszt elfedi a lenyeget (vagyis sose erted meg mi mukodik a hatterben igazan), es kisebb a kontrolom is felette. Kollegam mar osszerakott likewise-zal egy ilyen AD integraciot. Nem tetszett. Az ilyen dobozos megoldasokban az a "szep", hogy nagyobb nehezsegek nelkul mukodnek elsore, csak "kisebb" problemak vannak. A kisebb problemak aztan vagy soha nem javulnak meg (nem tamogatott valami), vagy oriasi szivas van veluk, vagyis annyi munka mintha osszeraktam volna az egeszet az alapoktol. Es ha ne adj isten valamit a sajat izlesedre szabnal... akkro rogton letersz a tamogatott utrol. A kollegam altal osszerakott megoldasban pl DOMAIN\\user alaku usernevekkel kellett belepni... Vegulis neki igy is jo volt.

Ne erts felre. A dobozos termeknek nem a ganyolas az ellenkezoje. Amit csinalok az szepen szabvanyos dolgokbol van osszerakva (gondolom amugy pont azokbol amivel ez a tool is dolgozik). Es azt is elhiszem, hogy van olyan dobozos cucc, ami pont tudna azt ami nekem kell es mindezt szepen. De en inkabb vegigjarom az alapokat es erteni akarom mi tortenik, hogy ha kesobb valami gond van, akkor tudjak mihez nyulni, ne csak az adott termek GUI-an, kelljen a megfelelo gombot keresni, ami ha pont nincs ott, akkor szivas.

( arpi_esp v | 2013. 07. 25., cs – 15:11 )

"A legnagyobb bajom, hogy az AD-hez nem sikerult anonymous modon csatlakoznom, vagy ugy egyaltalan az AD-hez valo hozzaferest nem nagyon tudom szabalyozni. Most felvettem egy user-t az AD-ba csak azert, hogy a Linuxos kliensek elerjek az LDAP-ot."

ez ilyen. alternativa (en is ezt hasznalom) a SASL authentikacio, ilyenkor a beleptetendo userrel+jelszoval authentikalsz az ldap-ba (akar cyrus saslauthd-vel) sasl protokollal. elonye, hogy nem kell a DN url hozza, csak a sima usernev+realm(domain)+jelszo. raadasul nem kuldi at plaintextben, csak md5 hash-t.

a bind-auth nem megy csak teljes DN-es url-el, ahhoz meg altalaban keresgelni kell eloszor az ldap-ban, ahhoz meg belepni egy mar ismert userrel...

3. lehetoseg a kerberos (-Y gssapi), ehhez is kell egy usert letrehozni ad-be es ahhoz egy keytab-ot de legalabb a jelszot nem kell a linuxon tarolnod hozza.

A'rpi

Az autentikaciot mar megoldottam kerberos-szal, de az LDAP bind igy sem uszhato meg, mert kellenek az infok a userrol (uid, home, shell, stb).

Azota megneztem kicsit az AD jogosultsag-okat, es amit eddig latok az szornyu. Kb minden userre egyesevel (jobb klikk, stb) allithatom be a jogokat. Olyan opciot meg nem talaltam, hogy ez rekurzivan megoldhato legyen pl, plane nem olyat, hogy az LDAP kapcsolaton keresztul allitsam ezt be. powershellel biztos meg lehet oldani.... de azert bosszanto, hogy egy "chmod -R ..."-et le kell programozni... Marmitn ha egyaltalan tenyleg igazam van es nincs ez megoldva valahogy okosabban.

A chmod-ot kepletesen ertettem. Vagyis a Linux filerendszerben hasznalt chmod -R... -nek keresnem az AD-s megfelelojet. Arrol beszelek, hogy egy adott AD objektumnak milyen tulajdonsagahoz ki milyen modon ferjen hozza. Pl jo lenne, ha anonymouskent elernem adott userek minden unix tulajdonsagat...

Igy mukodik most nalam, bar mondjuk senki nem rohog.
Ezt beallitom 30+ gepen (es meg szerencses vagyok, ez nem egy nagy halozat), ami nem is gond, mert az LDAP/AD matatas miatt ugyis hozza kell turnom minden gephez. Viszont igy 30+ gepre bedrotoztam egy jelszot, amit igy kvazi sosem fogok megvaltoztatni, akkor meg minek a jelszo.

De jo, latom mar, hogy jelszoval kell megoldanom, mert kulonben itt is pont igy fog belekotni mindenki. ;)

Igen, en konkretan sajat ubuntu repot hasznalok, sajat csomagokkal. Ezzel az a baj, hogy egy jelszovaltozasnak azonnal le kellene futnia az osszes gepen, nincs ugye "turelmi ido", ha megvaltoztatom a jelszot az AD-ben, akkor ugyanabban a pillanatban kellene mindenhol lecserelnem a konfigot, kulonben az atallassal zokkenok lesznek (mar eleve ize, hogy egy jelszovaltas "atallasnak" szamit). De mindegy, ezt is meg fogom tudni oldani, csak macera, es mindez a macera azert, hogy egy olyan security hole-t betomjek, amit nem erzek fontosnak.

Az hogy te mit erzel es mit nem erzel fontosnak, az a te egyeni problemad. Enteprise kornyezetben az auditalatlan cimtarhozzaferes megengedhetetlen, az AD pedig enterprise kornyezetbe keszult.

Azt sem ertem egyebkent, hogy miert valtanal jelszot. Ha pedig kompromittalodik a jelszo, akkor nem feltetlen az lesz a legnagyobb bajod, hogy minden gepen le kell utni.

Ami a sajat csomagokat illeti: ez mind szep es jo, csak loalkatreszt nem er. Ugyanis a csomagfrissiteshez ugyanugy be kell lepkedned minden gepre egyenkent, es frissiteni. A konfig menedzsment eszkozok azert jok, mert kepesek neked mindezt automatikusan, idozitetten megtenni. Tehat fut egy kis daemon a hatterben, adott idokozonkent csekkol, es lehuzza az uj konfigot.

Egyebkent a GSSAPI SASL authentikacio pont megkerulne neked az egesz kerdest, mert ott eloszor a Kerberoshoz authentikalsz, es csak utana az LDAP-hoz - tehat kb. nem fordulhat az elo, hogy nincs ervenyes ticketed, max akkor, ha valami daemon akarna LDAP-ozni - de az meg tudjon mar LDAP simple bindet legalabb...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Fogsz egy tech001 usert. Amikor közeledik a jelszólejárat ideje, akkor fogsz egy tech002-t azonos jogokkal, de mondjuk két év múlva lejáró jelszóval, és szépen átvakarod az összes kliensedet tech002 userre. Amikor mind elfogy, akkor a tech001 user letiltható - aztán a következő jelszólejárat előtt előszeded. Vagy hagyod az egészet, és kerberos-ra állsz át. :-)

Erre van a kerberos, a kerberos db-t meg br lehet tolni ldap-ba is. Ekkor ha van egy replikált (master-master) ldap-od, a kerberos szervereknek meg mindkét ldap-ot beállítod, és a kerberos replikációval sem kell törődni. És egyszerű mint a szög, kliens oldalon meg sssd-vel lehet variálni,auth mellett egyéb dolgokat(sudo, ssh, alkalmazások) is be tudsz állítani.
--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

Jo, csinalok csoportokat (mar vannak), de akkor meg mindig ott van, hogy minden egyes objektumra, -aminek az elerhetoseget szabalyozni akarom- ra kell kattintanom jobbal es ott beallitani, hogy ki mit erhet el. Ez az en bajom. Illetve biztosan nem csak igy lehet, mert azt nem hiszem el, hogy egy sokszaz useres AD-nel az adminok ezt igy csinaljak... de en meg nem talaltam meg a megfelelo modot.

Ha egy adott OU-n belüli (akár al OU-kban lévő) összes user objektumra akarsz jogot adni valakinek, vagy egy csoportnak, vagy akár anonymous-nak (ez utóbbit én sem ajánlanám):

http://windowsitpro.com/security/granting-permissions-ad-user-object-pr…

http://windowsitpro.com/site-files/windowsitpro.com/files/archive/windo…

Összedobtok valami hoki-poki webes felületet, oda csinálsz egy keytab-ot a megfelelő jogosultságokkal, onnan elérhető, és máris ok minden, és a biztonság sem sérült
--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

1. Anonymous szolgáltatást nem nyújtunk - ez alap volt eddig - legalábbis eddigi munkahelyeimen
2. ldaps + user/pass n darab gépre letárolva - macerás sok gép esetén
3. kerberos nem ördögtől való, ha jól be van minden állítva (idő!!!), jó a hálózat nem sok munkát ad - főleg ha ldap-ban van tárolva és ldap-al replikálva

Lehet egyszerűsíteni is, minek a wifit védeni, share-ekre jogosultság fölös macera, a tűzfal meg plussz hibaforrás, kapcsoljuk ki

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

1, anonymous LDAP meglepodnel, mennyi helyen van. mivel nincs benne semmi, amit amugy sem lehet a ceges nevjegyzekbol kinezni, igy mi is a bajod vele?
2, minek kene barmit tarolni?
3, ki mondta, h ordogtol valo? csupan megegy, az adott feladatra teljesen haszontalan hibaforras a rendszerben

a tuzfalas, shares terelesed meg egyszeruen baromsag.

1. auditon lehetne ezt magyarázni, de nekem is az a véleményem, hogy minden adat csak jogosultság ellenőrzés után legyen elérhető. Pl wifin betörnek máris vihető sokminden - címjegyzék, wiki, intranetes oldalak, és ez további segítség pl ad/ldap töréshez
2. bind user/passwd ha nem anonymous vagy kerberos auth van
3. nyilván át kell gondolni a körülményeket, nem ágyúval verébre, de kínos ha bukta van.

A terelésért bocs, csak fenn tudok akadni, amikor akár üzleti döntés vagy it-n belüli lustaság miatt adatok mennek ki. Tűzoltás, kárfelmérés, elemzés, és közben magyarázkodás: hogy hát ő nem tudta, nem gondolta, ilyet még nem hallott

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

Csendben megjegyzem, hogy az ilyesmi cégeknél abszolút nem kirívó eset, hogy a recepciós asztalán kinyomtatva ott figyel az épület összes dolgozójának címlistája: név, asztal/szoba, vonalas telefonszám, mobiltelefonszám. Sőt, sok munkatárs asztalán is ott figyel ugyanez kinyomtatva.
Tehát ha valaki fizikailag hozzáfér a cég irodájához, az bizony ilyen, sőt még ennél sokkal kritikusabb dolgokhoz hozzáfér. Egy belső címtár ezekhez képest már semmi extrát nem tartalmaz.

Régi nóta, hogy az adatlopások jelentős részét belső emberek követik el. És az, hogy a dolgozó _jogosult_ az adatok megismerésére, az nem jelenti azt, hogy névtelenül teheti azt. Azonosítatlan kérdezősködőnek nem szokás céges adatokat az arcába tolni. Szó volt a recepciósnnál/dolgozóknál lévő, akár kinyomtatott céges telefonkönyvről. Ha azt állítom a recepciósnak, hogy itt dolgozok (mondjuk mától), akkor kezembe nyomja azt? Jó esetben nem.

Az egyedül nem mászkáló vendég meg... Elméletnek jó, de ilyen nem sok helyen működik ténylegesen. Sőt.

abban, hogy kik dolgoznak a cegnel, mi az emailcimuk, esetleg melyik epuletben dolgoznak szinte nulla piaci erteke van. legtobbszor ugyanis ez az informacio fent van a neten is, megjobban publikusabb formaban. nem ertem ezt miert olyan nehez megerteni. _senki_ nem mondta, hogy a jelszo hasheket kene anon bindel kitolni minden juzerrol, vagy a fizetesi kategoriajat. azoknak nem is szabad egy rendszerben lennie ezekkel.

Normális esetben a teljes név- és e-mailcímeket tartalmazó lista nem publikus (milyen jó is lenne a spammer címlisták összeállítóinak...) de sebaj, hajtogasd csak a kódgányolós felfogásodat, abban neked van nagyobb tapasztalatod, információbiztonság területén meg nekem. Egy céges címtárból azonosítás nélkül nem javasolt adatot szolgáltatni. Semmilyet.

Azert van kulonbseg. Az a cimlista, ami fenn van az interneten, az jobb esetben ellenorzott, meg jobb esetben pedig jova is van hagyva a rajta szereplok altal, hogy publikus lesz. Ugyanakkor nem tudok nem gondolni arra, hogy az internetre kirakott (peldaul a ceg weboldalan) szereplo listaban nincs ott mindenki, mert senkinek semmi koze ahhoz, hogy Kiss Jolan Izabella telefonkozpontos a cegnel dolgozik.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Vannak kifelé publikált adatok, kapcsolattartó stb, de nem minden. Pl hivatal, ügyintéző mobilja nyilvános, ügyfél szomat este 8kor részegen hivogat, hogy mé nem kaptammega családipótlékot, segélyt, vagy pl internetszolgáltatónál éjszaka hogy nincsennetem, csinádmánmeg vagy dolgozói email cimek netre kirakva

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

ok, jogos, benéztem, már fáradok, de akkor is tartom, hogy csak auth után legyen bármilyen céges adat elérhető - és ez igaz mobil eszközökre. wifi, ellopott telefon, notebook titkosítás nélkül jelentős kockázat
--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

es pont!!11!!! mindig imadok ilyen baromarcokkal vitatkozni. cuncimokus, ki mondta, hogy minden publikus? olvass mar vissza, aztan majd gyere vissza, ha erted mirol beszelek. onnan indult a dolog, hogy azt mondtam, hogy anonymous binddel a legjobb autholni. ehhez meg csak az sem kell btw, hogy 5 attribnal tobbet adjon vissza auth nelkul az a szerencsetlen szerver.

Cuncimókusozz mást - biztonsági megfontolások alapján nem jó dolog bárkinek, aki a hálózathoz bármilyen módon hozzáfér a címtárhoz is automatice hozzáférést adni.
Az, hogy a baromarcú kódgányolók (meg te) ezt nem bírják felfogni, az voltaképp jó, mert így bőven van munkája a biztonsági területnek is.

Leszámítva azt, hogy:
-így kicsit könnyebbé válik leDOS-olni a DC-ket, pl. túlterheléssel.
-ha van egy sebezhetőség pl. buffer overflow az implementációban, azt már authentikáció nélküli támadó is kihasználhatja.
-a céges telefonkönyv tele van PII-al. Lehet, hogy nyilvános a cég dolgozóinak, de egyik részről ők sem csinálhatnak vele kontroll nélkül bármit, másik részről a jogosultak általában nem azonosak a hálózati végponthoz hozzáférőkkel.

Üdv,
Marci

( turul16 v | 2013. 07. 28., v – 15:56 )

http://www.freeipa.org/page/Main_Page --Normal redszerekhez.
(Windowsok local usert tudnak authenticalni kulso rendszerbol, de mas user adatabazist nem ertenek.
Vagyis minden usernek lokalisan leteznie kell windowson, es csak az auth lesz kulso szolgaltatasbol)

Ha AD -nak latszo free targy kell a szokasos open componensekbol:
http://wiki.samba.org/index.php/Samba_AD_DC_HOWTO

A windowsok nem tisztan ldap/kerberost beszelnek, van ott NetBios meg ldap/udp.., meg ki tudja mi..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Samba4-ben mi a szokásos komponens az NTP-t* és az opcionális Bind-ot leszámítva? :)

AFAIK CMIIW az eredeti terv tényleg az volt (még 2003-ban), hogy elérhető komponensekből (MIT/Heimdal Krb-nek, OpenLDAP/386LDAP/... LDAP-nak, Bind DNS-hez, Samba fájlkiszolgálónak/RPC szervernek, remélem nem hagytam ki semmit) legyen összesakkozható, de a Krb-t dobniuk kellett (nem tudom miért) és hozni sajátot, a külső LDAP-okat dobniuk kellett (midegyikkel volt valami a tranzakció-kezelés környékén) és hozni sajátot, egy időben a Bind-ot "dobniuk kellett" (ok, megmaradt, ráadásul most már jól együtt is működnek, de az aláírt DNS update-al volt annyi gond, hogy egyszerűbbnek tűnt újat írni, lásd Andrew Tridgell kapcsolódó blogbejegyzését a belső DNS-ről és a dlopen DLZ driver megjelenéséről) és írniuk sajátot.

Szerk.: Nem bántani akarom a Samba4-et, csak a szokásos komponensekhez nincs túl sok köze.

BlackY
*: Ráadásul ez sem "szokásos", mert bele kellett rakniuk az ntp_signd socket támogatást, és az aktuális stable verzióban még mindig van ilyen figyelmeztetés: "MS-SNTP signd operations currently block ntpd degrading service to all clients."