Windows domain telepítésre és kapcsolódó feladatokra szakember (1-2 hetes projektmunka)

Fórumok

Az alábbi munkára várnánk - BME TTK - embert és ajánlatot:

  1. Windows 2019 alapon domain kialakítás, Remote Dekstop Server beüzemelés, konfigurálás.
    A két domain Controller virtuális gépen (valószínűleg VirtualBox) alá kerülne, a Remote Desktop szervernek egy HP DL360 Gen9 lenne az kiszolgálója.
    File-kiszolgálóként vagy az RDS-t vagy egy Samba4-es Linuxos gépet használnánk. (Tulajdonképp mindkettő indokolható, majd kérünk segítséget a helyes döntéshez.)
  2. Roaming profiles, folder redirection
  3. Az RDS-en a lokálisan tárolt profil adott idő után törlődjön
  4. Desktop gépeken(egyelőre csak Win 10) a lokálisan tárolt profil ne törlődjön
  5. A RDS-en az alap felhasználókat 2 órányi inaktivitás után jelentkeztesse ki a rendszer
    • Egy adott csoport (AllowLongSession) tagjai maradjanak bejelentkezve amíg saját maguk ki nem lépnek.
  6. Az alap felhasználó csak a C:\Program Files, a C:\Program Files(x86), a C:\ProgramData és a C:\Windows könyvtárakból indíthasson programokat.
    • Egy meghatározott csoport (ExecOwnCode) tagjai a Home drive-juk meghatározott könyvtárából  is indíthatnak.
    • Mindenféle a user által a user profiljába települő program telepítésének tiltása.
  7. A rendszergazdának legyen legalább olvasási joga a felhasználók Home és Profile könyvtáraihoz (kézi, vagy saját eszközös mentéshez)
  8. Windows áruház tiltása (RDS-en és desktop gépeken is)
  9. Candy Crash Soda Saga és egyéb automatikusan felmászó szemetek tiltása (RDS-en és desktop gépeken is)
  10. extra policy-k egyéb programokhoz (Office, Firefox, Chrome)
    • rákérdezés mentéskor, nyitóképernyő és hasonlók. 4-5 darab
  11. Default felhasználói profil (ok).
    Elég sok olyan programot használunk, amit nem lehet GPO-ból szabályozni, vagy nem eléggé.
    Jó lenne, ha egy előre beállítgatott környezetet tudnánk adni az új felhasználóknak.
    • Ha lehet, jó lenne 4 különböző előkészített profil, (angol/magyar, alap/haladó) amiből tudunk választani, ha új felhasználót csinálunk
    • Mandatory profil:
      Előző környezetben a mandatory profilok használatakor elég zavaró volt, hogy néhány hónap múlva a folyamatosan frissülő programok egyre zaklatták a zárolt profilú felhasználókat az új funkcióik reklámozásával, beállításával. Nem tudom, erre van-e valami jól bevált megoldás?
  12. Linuxos felhasználók AD-ben való tárolása (ha jól sejtem, ehhez csak sémabővítés kell)
  13. FreeRadius integráció Wifi authentikációhoz
    Ezt előző rendszerben sikerült nekem is, de ha gond van, jól jön, ha valaki a windows oldali logokat tudja olvasni/értelmezni.
    • Csak meghatározott csoport, vagy OU tagjainak akarunk wifi-hozzáférést
    • AD-ben nem szereplő, ideiglenes vendég-felhasználókat is szeretnénk.
  14. OwnCloud / NextCloud integráció
    Ezt előző rendszerben sikerült nekem is, de ha gond van, jól jön, ha valaki a windows oldali logokat tudja olvasni/értelmezni.
  15. Nyomtatók integrálása authentikációhoz
    Van néhány Konica-Minolta Bizhub nyomtatónk, amik a felhasználókezelést tudnák AD-ből venni. Jó lenne, ha ez a gyakorlatban is működne.

Az első 11 pont ami mindenképp szükséges, a 12-15 pontok extrák. Ezt az ajánlatban is kérjük külön választani.

Érdeklődni lehet a kapcsolat fülön vagy a windowsmunka@math.bme.hu e-mail címen.

(A hirdetés a HUP-Profession szabadkártya felhasználásával került kihelyezésre)

Hozzászólások

Szerkesztve: 2021. 11. 01., h – 18:02

Kellő tisztelettel megjegyezném, hogy a roaming profil és a Windows 10 nem barátok, két éve olvasok utána és két éve ezzel szívok.. például egy újraindítás után -ugyanazon a gépen- a legritkább esetben kapom vissza az Asztalt úgy ahogy kiléptem :-)

Remek... :(
Ezzel a romaing profillal nekem mindig gondom volt. Szükség az persze lenne rá, mert nem feltétlenül ugyanahhoz a géphez ül le a user. De kezdetben a telepakolt asztal mozgatása tartott percekig, aztán kitalálták a folder redirection-t, de utána jöttek a user profil roaming részébe szemetelő, cache-elő, sőt oda települő programok...

Remélem, egy napi szinten Windows rendszerekkel foglalkozó ember tud valami értelmes megoldást arra, hogy több gépen belépve ugyanazt lássa a user, és mellé ne tartson percekig a belépés. Linuxon ezt az nfs-home, meg a pam_mount már az ókori görögöknél is megoldotta ezt. :)

--vagy ott vannak az Adobe CC és egyéb Adobe termékek, amik kb. egy-két gigát pakolnak az AppData\Romaing\Adobe mappába, egy profil pár nap alatt meghízik négy gigásra a kötelező "újdonságok / mit tud az új verzió" demóktól, aztán azt szinkronizáld, amikor vagy ötvenen lógnak még a hálón.. Hogy ezzel nem akarnak valamit kezdeni Redmond-ban...

Ezzel pont nem redmondban kellene kezdeni valamit.

Ha egy idióta a kimondottan profile szinkronizálandó mappát teleszórja hülyességgel, akkor az oprendszernek kutya kötelessége a hülyeséget végigrángatni a hálón, akkor is, ha 100 user van és sokáig tart.

A kedves fejlesztő meg próbálja már meg megkülönböztetni az appdata\local -t az appdata\roaming-tól, nem olyan nehéz az.

Linuxon is tudsz telepíteni repo-ból, meg repo-n kívülről is, csak az utóbbit lehetőség szerint kerüli az ember. Windowsnál meg pont fordítva van. De szerintem már így is marad. Évtizedeket késtek vele, nem hiszem, hogy valaha is az appstore válna az elsődleges forrássá windowson.

Bocs, de ilyet te is tudsz csinálni úgy kb. Windows 2000 óta. Igaz, kicsit más szisztémával.

Kulcs: csinálsz GPO-kat, abban kiajánlasz alkalmazásokat, de nem gépre, hanem userekre téve. Így a userek akár telepíthetik is az alkalmazásokat. Utoljára Win7-nél csináltam ilyet. Működött.

Továbbá ott van a System Center is ezek kezelésére (SCCM). Így nem kell GPO-kal küzdened. Ha önkiszolgáló portált akarsz, akkor pedig SCSM, mint Microsoft megoldás.

RDS esetén ezen megint nem kellene annyira agyalni, hiszen központilag megoldod, menedzseled.

egy napi szinten Windows rendszerekkel foglalkozó ember tud valami értelmes megoldást arra, hogy több gépen belépve ugyanazt lássa a user,

Ez, amit szeretnél, nem lehetséges korrektül Windows alatt.

Csináljuk, már nagyon régóta, de verzióról verzióra egyre szarabb, és egyre több vele a szopás. Az XP-nél még egész elviselhető volt, a Win7 már elég rücskös volt, a Win10-nél pedig ott tartunk, hogy noha a userek zöme már gyakorlatilag csak egy böngészőt meg Word/Excelt használ - ennek ellenére még így is a használhatatlanság határán van a dolog. Pl. indít a user egy Chrome-ot, netezik fél órát, és telibassza a hálózati könyvtárát több száz MB-nyi szeméttel (ez csak a Chrome profilban levő, a weboldalak által tárolt local data cuccok, a cache már rég át van tolva a TEMP könyvtárba, és maga a Chrome profil is már a hálózati meghajtóra megy), a fájlszerver meg megtelik a guánóval. És kb. a "cronból takarítunk éjszakánként" az egyetlen, icipicit is működőképesnek tűnő megoldás.

Windows áruház tiltása (RDS-en és desktop gépeken is)

Ezt mi megcsináltuk. Most az összes ilyen foskupac ki van herélve már az install image-ből is, plusz a GPO minden lehetőség tilt, amin keresztül bármilyen ilyesmi szar felmehetne. Sajnos ez túl jól sikerült (pl. nincs calculator, mert az már csak ilyen áruházas szarság formájában létezik, bár felmerült, hogy egy Win7-es gépről a régi calc.exe-t felmásoljuk mindenhova, Redmond meg bekaphassa, bőnyállal). Sikerült már egy-két olyan programba is belefutni, amiknek valamelyik komponense Store-os formátumban van, persze azokat a tiltás miatt nem is lehetett felrakni, szóval nem biztos, hogy így maradhat a tiltás...

Linuxon ezt az nfs-home, meg a pam_mount már az ókori görögöknél is megoldotta ezt.

Use Linux. Komolyan. Le kell nevelni a népeket a fosról.

A Windows lényege, hogy vagy úgy használod, ahogy Redmondban mondják, vagy szopni fogsz. És ők azt mondják, hogy egy ember - egy gép. Egy gép - egy ember. Personal workstation. Mindenkinek dedikált gép, amit csak ő használ, és ő csak azt használja. Lehet ez a gép egy VM is, de emberhez kell rendelni. Azaz a roaming profile-t felejtsd el, és a user is alapvetően úgy számoljon, hogy a profilbeállításai egyik napról a másikra ha elvesznek (pl. reinstall), akkor Így Járt(tm).

Arra a feladatra, hogy publikus gép, amit random emberek használhatnak, arra ők azt a megoldást tudják felajánlani, hogy minden login alkalmából kap egy default üres profilt a felhasználó, logoutnál pedig a beállításai elvesznek. Ha a user ehhez hozzászokik, akkor pl. egy Windows reinstall sem fogja mélyen érinteni. :D

Linuxos felhasználók AD-ben való tárolása (ha jól sejtem, ehhez csak sémabővítés kell)

Ha jót akarsz, akkor nem próbálsz inkompatibilis fajokat összeengedni (lásd Gary Larson idevágó karikatúráját: https://ifunny.co/picture/zorak-you-idiot-you-ve-mixed-incompatible-species-in-the-48QDZVTi8).

Nekünk az vált be, hogy az AD adatbázisába kívülről toljuk bele a felhasználói adatokat (forced provisioning), ami nyilvánvalóan azzal jár, hogy jelszót alapvetően az AD-n kívülről kell váltani, cserébe egészen precízen megválaszthatjuk a jelszópolicynkat. Ezzel van a legkevesebb szopás, és bármikor tud menni egy reprovisioning, mondjuk egy reinstall után (mottónk: a fasznak van kedve mentegetni az AD adatbázisát).

Ez, amit szeretnél, nem lehetséges korrektül Windows alatt.

Ezt mint Windowszal is játszó Linuxos mondod, vagy mint Linuxot is ismerő MS expert? Csak mert nekem, mint Linuxos embernek szintén nem sikerült zöld ágra vergődnöm vele, de nem hiszem, hogy az a hivatalos MS álláspont, hogy ez így nem megy és pont. Vagy ebbe már minden nagyvállalati ügyfelük belenyugodott, és sehol nincs már roaming???

Nekünk az vált be, hogy az AD adatbázisába kívülről toljuk bele a felhasználói adatokat (forced provisioning), ami nyilvánvalóan azzal jár, hogy jelszót alapvetően az AD-n kívülről kell váltani

Igazából közös jelszót szeretnék, ahová csak lehet, mert az átlag usernek 1 jelszó is sok. :) Az általatok használt megoldásban hogy változik a Windowsos jelszó, ha Linuxon változtatott a user, illetve mi van, ha windows-on ad meg új jelszót a felhasználó?

Ezt mint Windowszal is játszó Linuxos mondod, vagy mint Linuxot is ismerő MS expert?

Hát most ez nézőpont kérdése. MS expertnek azt szokás nevezni, aki úgy általában az MS főbb szarjait és különösen a latest & greatest feature-öket ismeri. Én pl. kifejezetten nem szeretnék azokkal a dolgaikkal intim közelségbe kerülni, amiket sikerült eddig elkerülni. Az az alap hozzáállásom pl., hogy ha valami feature-ről elsőre nem látom, hogy miért is lenne jó, akkor arra nincs szükségem. Másrészt amivel meg foglalkoztam, na azokba a baromságokba amennyi energiát én beleöltem az elmúlt évtizedekben, hát annyi energiabefektetéssel egy egyetemet is simán el lehet végezni. Csak ebbe a roaming profile-os szarságba összesen sok hónapnyi melót belement már. Tulajdonképpen lehet ezt játszadozásnak is nevezni... 

az a hivatalos MS álláspont, hogy ez így nem megy és pont.

Úgy általában az az MS álláspontja a cuccairól, hogy tessék, ezt kapod, ezt használd, úgy, ahogy le van írva, és ne akarj mást. Amíg a dokumentált, hivatalos úton sétálsz (sose térj le a sárga útról!), addig szépen illatoznak a virágok, de az ösvényről letérve nagyon hamar a dzsindzsásban találod magad, és ott semmi segítségre nem számíthatsz.

A roaming profile magában megy. Ezt mondja a MS is. Egy kurva nagy gond van vele: a való életbeli alkalmazásokkal használhatatlan, mert GB-osra nő a profilod. És ez már nagyon régen így van. Ezért vezették be a folder redirectiont. Amivel együtt már sokkal jobb a helyzet, csak ez a "megoldás" egy valag új problémát vet fel. És ezen problémák egy részére már tényleg az a MS hivatalos mondása, hogy ha ezekbe beleütközöl (márpedig bele fogsz), akkor arra a könyvtárra ne akard inkább használni. Így viszont leszűkül a profile redirection által adott megoldás hatásköre, és visszajön a roaming profile önnön durva valósága.

Mivel az alkalmazások kívül esnek a MS hatáskörén, így joggal mondják azt, hogy ez nem az ő dolguk, panaszkodjál a szoftver vendornál. Akik meg kb. leszarják az egészet, így sikerült is körbeérni.

sehol nincs már roaming???

Te, én rendes, igazi nagyvállalati környezetben nem emlékszem, hogy láttam-e valaha roaming profile-t. Sőt, mivel 10-15+ éve kb. mindenki dedikált gépet használ már szinte minden nagyvállalatnál (ezen belül is leginkább mindenki dedikált laptopot kap), így valójában igény sincs már rá, hiszen mindened az egy szem gépeden van, ha esetleg van egy laptop is meg egy másik géped is, akkor meg valami consumer adatszinkronizációval befogják a túl hangosan kérdező felhasználók száját. Az meg a felhasználó egyéni szoc. problémája, hogy a végtelen sok windowsos meg alkalmazásszintű beállítását szeretné széttekergetni, aztán másik gépre átvarázsolni. Ezt a nagyvállalati IT department leszarja, ez egy felhasználói problémát, kattintgasson csak a user, ha ilyen elvakult, és nem jók neki a default beállítások (ha már feltételenül windowsozni akar - tetszettek volna forradalmat csinálni ugye). Szóval valójában azért sincs a nagyvállaloknál roaming, mert a problémát egyszerűbb úgy megoldani, hogy azt mondjuk: nincs is probléma.

Az általatok használt megoldásban hogy változik a Windowsos jelszó, ha Linuxon változtatott a user, illetve mi van, ha windows-on ad meg új jelszót a felhasználó?

Amíg lehetett NT domain alapokon tolni a Windows oldalt, addig Samba 3-mal meg lehetett csinálni, hogy tényleg egy szem jelszava legyen natív módon a felhasználónak, és ha nyom Windows alól egy jelszóváltoztatást, akkor mindegyik jelszóhasht updatelte a rendszer automatikusan. Natív Win domain controllerrel ez nyilván nem ment már kezdetben sem, továbbá az AD bevezetésével a Samba 4 is felzárkózott a natív Win AD szerver működéséhez (konkrétan annyira precízen másolták le a MS AD üzleti logikáját, hogy szinte minden limitáció és rugalmatlanság is belenőtt a Sambába is), és immáron ezt nem lehet elérni egyáltalán.

Azaz van egy AD jelszava a júzernek, meg egy nem AD jelszava (nevezzük linuxosnak, bár valójában ez leginkább egy LDAP jelszó). A Windowsból az AD jelszavát tudja eltekerni a júzer - ha megengedjük neki, vagy ha admin az illető, a linuxos környezetből pedig az LDAP jelszavát tudja frissíteni (az LDAP protokoll tud olyat, hogy EXOP jelszóváltás, és elvileg az nss-pam-ldap beállítható, hogy a passwd ezt hívja meg).

Mi viszont azt az álláspontot képviseljük, hogy a usernek megtiltjuk a jelszóváltást (ez Linuxon egyszerű, nem konfigurálunk EXOP-ot, és máris nem tud változtatni, illetve az LDAP-ban eleve nem adunk neki írásjogot a saját mezőire), Winen kikapcsoljuk a normál usereknek a jelszóváltási lehetőséget, így csak az adminok tudnak beletúrni nemkívánatos módon, mindenki másnak csak kintről lehet jelszóváltoztatást végeznie. Amúgy a szinkronizáció úgy van megálmodva, hogy az eltéréseket (lokálisan eltekert jelszavakat) egy kiküszöbölendő hibának tartja, így ideig-óráig tart ki az, amit véletlenül vagy szándékosan sikerült eltekernie valakinek.

"Az az alap hozzáállásom pl., hogy ha valami feature-ről elsőre nem látom, hogy miért is lenne jó, akkor arra nincs szükségem." - remélhetőleg ezt majd kinövöd, és eljön a "ezt miért találták ki, valójában mire jó?" kérdésfelvetés időszaka is.

"Azaz van egy AD jelszava a júzernek, meg egy nem AD jelszava (nevezzük linuxosnak, bár valójában ez leginkább egy LDAP jelszó). A Windowsból az AD jelszavát tudja eltekerni a júzer - ha megengedjük neki, vagy ha admin az illető, a linuxos környezetből pedig az LDAP jelszavát tudja frissíteni (az LDAP protokoll tud olyat, hogy EXOP jelszóváltás, és elvileg az nss-pam-ldap beállítható, hogy a passwd ezt hívja meg)."

Normális esetben a jelszócsere mindkét helyről normálisan működik, és egy jelszava van az usernek az AD-ben, ha nektek ez nem megy, akkor keresgéljetek még - igaz, ehhez az AD-t nem egy ldap-os backendnek kell Linuxon használni.

"Az az alap hozzáállásom pl., hogy ha valami feature-ről elsőre nem látom, hogy miért is lenne jó, akkor arra nincs szükségem." - remélhetőleg ezt majd kinövöd, és eljön a "ezt miért találták ki, valójában mire jó?" kérdésfelvetés időszaka is.

Az eredeti mondatból kimaradt, hogy "MS-technológiák esetén". És ez azért fontos, mert náluk általában "akárhogy rakom össze, mindig tank jön ki belőle" mottóra történnek a dolgok. Ezt a mintát az ember egy idő után felismeri, és nem nézi meg 42-edszerre is, hogy vajon a legfrissebb classic technológiájuk használható-e értelmesen olyan környezetben, ahol nem csakis és kizárólag MS termékek vannak - mert szinte mindig az a válasz, hogy kb. nem. Általában totál rugalmatlan, semmivel se kompatibilis, szabványos protokollokat vagy egyáltalán nem ismer, vagy direkt úgy van megcsinálva, hogy csak névleg létezzen a szabványos protokoll támogatása, de pont ne működjön rendesen mások termékeivel, stb.

Ebből következik egy stratégiai döntéshelyzet: vagy amit csak lehet, MS megoldással akarsz megcsinálni, vagy amit csak lehet, azt nem MS megoldással. Azaz az egyik esetben jöhet az MS expert, aki álmából felkeltve is megmondja, hogy az adott feladatra melyik MS termék az egyetlen melegen ajánlott megoldás (különben sok-sok szívásnak nézel elébe), a másik esetben meg alapvetően mindenhol el akarod kerülni az MS cuccait, hacsak más megoldás nem marad (mert mondjuk Windows desktopra van szüksége a népeknek). A két stratégiai út között aknamező van. Minél messzebb kolbászolsz be erre a mezőre, annál súlyosabb a helyzet.

Na én olyan környezetekben mozgok, ahol a második stratégia mentén történnek a dolgok.

Normális esetben a jelszócsere mindkét helyről normálisan működik, és egy jelszava van az usernek az AD-ben, ha nektek ez nem megy, akkor keresgéljetek még - igaz, ehhez az AD-t nem egy ldap-os backendnek kell Linuxon használni.

Haha. Ha a fentebb említett első stratégiai úton halad valaki, akkor az egy elképzelhető felállás, hogy annyi csak a feladat, hogy a kivételnek tekinthető Linuxokon is bírjanak belépni az AD-s jelszavaikkal a népek. Igen, ez valóban megvalósítható egy sima AD adatbázissal. Persze a szokásos MS korlátokat így is meg fogja tapasztalni a delikvens, de az max. üzleti döntések szintjén (meg anyagilag) jelent erőszakot.

A második stratégiai út viszont oda szokott vezetni, hogy más feladatok is vannak, több más rendszer is szeretné a felhasználói adatait LDAP adatbázisban tárolni, és nem mindegyik ilyen rendszernek elég az a szolgáltatási szint, amit a MS-féle korlátozott/rugalmatlan LDAP emuláció tud, proprietary MS protokollokat meg nem szeretnének beszélni. Szóval az nagyon frankó, hogy a Linux tud nem pusztán LDAP backendként authentikálni AD-ból, de vannak olyan rendszerek, amiknek ez nem elég. És amikor a viccbéli kidönthetetlen oszlop és megállíthatatlan ágyúgolyó találkozik, na akkor el kell döntened, hogy mit engedsz el. A második stratégián haladóknak ez elég egyszerű döntés, hiszen a stratégiai céllal ellentétes, hogy az MS oldal súlya nőjön tovább.

"Szóval az nagyon frankó, hogy a Linux tud nem pusztán LDAP backendként authentikálni AD-ból, de vannak olyan rendszerek, amiknek ez nem elég. " - nem csak authentikáció megy AD-s alapon, de sebaj, úgy tűnik, te tényleg nem vagy tájékozott az AD-vel integrálódás terén. Ahol a "csak ldap" authentikáció nem elég, ott neki lehet ugrani kerberos-t használni (pbis+AD, és ha jól csinálod, "pipa"), ha több/jobban szofisztikált megoldás kell (HBAC, illetve n+1 PAM-ot használó szolgáltatás "becsövezése" a központi aaa-ba), akkor ipa(+trust az ad-hez).

Mindkettőhöz volt már szerencsém, ahogy az "AD, mint LDAP backend" megoldáshoz is. Ez utóbbi amennyire egyszerű/fapad, annyira buta - és nem, egy pucér OpenLDAP sem volt sokkal jobb... Sőt.

 

 te tényleg nem vagy tájékozott az AD-vel integrálódás terén.

Nem vagyok tájékozott az AD-val integrálódás terén. De te látom igen. Szóval itt a feladat:

Adott egy protokoll, amiben egy NTLM hash formájában érkezik a jelszava a júzernek. Nem opció, hogy clear textet kérünk, nem opció, hogy kerberosozunk, mert egy szál NTLM hash van csak (ha nincs kenyerük, miért nem esznek kalácsot, ugye). Persze üzemeltethetnénk jelszófeltörő backendet is, ami előállítja a hashből a clear textet, de gondolom ezt a megoldást rögtön elvethetjük.

Hogyan veszed rá az AD-t, hogy az NTLM hash alapján megmondja, hogy a felhasználó jelszava helyes-e? Alternatívaként persze az is elég, ha jó LDAP backendként kiszolgáltatja a felhasználó NTLM hashét, és akkor majd az alkalmazás elvégzi a string összehasonlítás műveletét...

Ja, és nem kell elmagyarázni, hogy ez úgy nem biztonságos, ahogy van, hiszen az NTLM jelen esetben clear text ekvivalens a rossz fiúk kezében. Az üzleti elvárás ugyanis kőkemény: bármiféle további konfigurálás nélkül üzemelnie kell tudnia már meglevő, régesrég megírt szoftvereknek is, amik pontosan ennyit tudnak alapbeállításokkal. és nem többet.

És kb. a "cronból takarítunk éjszakánként" az egyetlen, icipicit is működőképesnek tűnő megoldás.

Ezt kérném kifejteni, mert szükségem lenne rá.

Egyébként nálunk működik rendesen a roaming profile, igaz linux a szerver és nem win. Csak a bejelentkezési idő a sok _néhány_ usernél. 

Ezt kérném kifejteni, mert szükségem lenne rá.

Hát megnézed pl. a Chrome vagy a FF profilját, ami a fájlszerveren lakozik, és megírod azt a scriptet, ami a kívánt változtatásokat elvégzi a szerveren levő fájlokban (pl. adott könyvtárat üresre törlöd). És ezt nem a user nevében, a user workstationjén futtatod, amikor éppen belép/kilép, hanem a fájlszerveren, éjszaka, for ciklusban mindegyik felhasználóra.

Már bocsánat, de a roaming profile fölött eljárt az idő, deprecated funkció. Még XP idején, kis profilokkal nagyjából jól működött. Azóta eljárt felette az idő. Nettó baromság alkalmazni már.
Használj folder redirectiont, konfiguráld be jól az alkalmazásokat (ha lehetséges). Esetleg nézz utána az UE-V-nek, hogy mennyire támogatják az alkalmazásaid. Ez önmagában több hetes munka.

Vedd rá a usereket, hogy a documents mappát használják, tárolják ott az anyagaikat.
Továbbá ott van a RemoteApp is.

RDS esetén meg nem is nagyon kell ezzel szenvedni. Csak át kell terelned a felhasználókat oda.

Szerkesztve: 2021. 11. 01., h – 21:25

A rossz hír az, hogy ez nem 1-2 hetes munka, hanem sokkal több. Szerintem még a versenyszférában sem csinálnak meg ennyi mindent. Talán nem is szükséges. Btw. pl. egy központi vezérlős ESET-tel a korlátozások jelentős részét be tudjátok állítani. Én azt javaslom, hogy redukáljátok a minimálisan szükséges igényekre a listát. Alap dolgok: Domain, Windows Security Baseline GPO-k, Samba4 fájlszerver (smb3 TLS?, ZFS?, shadow copy?), extra: Linux authentikáció AD-ból (TLS?). A VirtualBox-ot nem igazán értem. 9-es pont: ha jól tudom Windows 10 Enterprise előfizetés kell ehhez (havidíjas). Ezek után jönnek az egyedi GPO beállítások és integrációk és itt lehet igazán időben, térben és pénzben is elszállni. Én egyébként egy NoSQL adatbázisban tárolnám amit csak lehet és onnan frissíteném a user és egyéb adatbázisokat szkriptekkel.

Régi klasszikus:

"Mi az alábbiak alapján tudunk dolgozni:

-olcsón

-gyorsan

- jól

Ön ezekből egyszerre kettőt választhat ..."

Megfelelő rendszerterv, IBSZ, és még egy pár ismérv alapján tényleg elég hamar össze lehet klikkelni. Igaz én még nem láttam ilyesmit. :-( Mindig van valami csavar, vagy bonyodalom, és a "piros bicikli sem lesz ott!"

Igaza van. Az általad megadott határidő nagyon csücskösen elég, ha minden jól és elsőre megy (nem fog) és a tesztelés is gyorsan megy. Egy hasonló f*shalmot rugdostunk vissza az életbe az utóbbi másfél évben. 
a roaming profilt felejtsd el. Meg lehet e csinálni? Hát persze bokán is lőheted magad egy 9mm-essel csak ugye nem akarod.

AzureAD, intune és sccm vagy mi a szösz a neve éppen is legyen a listán

"12. Linuxos felhasználók AD-ben való tárolása (ha jól sejtem, ehhez csak sémabővítés kell)" - A kérdés az, hogy mit szeretnél AD-ben tárolni, illetve az authentikációra mit szeretnél használni, milyen Linuxokon? Egy "zöldmezős" infrastruktúrában én IPA+sssd vonalon indulnék el Linuxos auth ügyében (hint: IPA-AD trust, az userek az AD-ban, a HBAC és az egyéb extrák az IPA-ban), de lehet pbis-sel is szórakozni, és akkor "simán" az AD-be lépteted a Linuxokat, és megadhatod, hogy melyik AD-s csoport(ok) tagjai léphetnek be az adott gépre. Az egyikhez sem kell AD sémát maszírozni.

Bő tíz éve, hogy ilyesmivel utoljára szenvedtem, te úgy rémlik, hogy valami sémabővítéssel a felhasználónak lett posix username, uid, gid, unixhome tulajdonsága, amit a GUI-n vagy ldap parancsokkal be lehetett állítani, hasonlóan a csoportoknak is meg lett a linuxos id-je. Aztán a linuxos kliensek kerberos/ldap párossal kapcsolódtak az AD-hez, és onnan vették a felhasználókat.

A direktben kerberos+ldap vonalat passzolom, ahelyett ott az IPA (ami ha kell, trust-on keresztül "tudja" az AD-s usereket), sima AD-s auth-hoz vagy sssd-t, vagy pbis-t használok - egyik sem igényelt semmilyen mókolást a DC-n - azon kívül persze, hogy a Linuxot fel kell venni az AD-ba. (a licenszelési dolgokat meghagyva az ezzel foglalkozó szakértőknek).

Felejtsd el a sémabővítést. Fölösleges.
Én már 10 éve is tettem be Linuxokat AD-be. Centos, RHEL és SLES voltak a disztribúciók. A cél akkor az volt, hogy akár a linuxos, akár a windowsos gépen, sőt, még akár a GIT-be is ugyanazzal az AD-s felhasználó névvel és jelszóval tudott a user belépni. Szinte tiszta SSO volt.

Egyébként az is igaz, amit a többiek is írtam és a trustokkal biztosítani az átjárhatóságot.

Nem kevés helyen ez is csak álom... (Belépve egy ts-re a következőre onnan átlépve ne kérjen usert/jelszót...) Sajnos nem értettem (akkor se, meg most se...) annyira a Windows/AD/TS miegyebekhez, hogy tudjam, mit kell kikalapálni, hogy működjön, időm meg nem volt utánatúrni, bár azért kíváncsi vagyok, mit kellett volna másképp csinálni az ex kollégáknak...

a telepitgetesi jogosultsag mizeria tudtommal SCCM/SCOM nelkul nem fog menni...

freeradius helyett megfontolando inkabb az NPS (vagy az ala berakva es proxyzva). a tanusitvannyal jokat lehet szopdosni, win10 mar nem eszi meg az EAP-TLS radiust ha nem jo a certje, ra se kerdez...

own/nextcloud: ha csak az kell hogy a login+jelszo ad-bol (LDAP) jojjon az nem nagy kunszt, ha rendes integraciot akarsz, SSO-val hogy az ad-be bejelentkezett user mar ne kelljen kulon logineljen oda is, na az mar izgibb. plane mindez webdav-al megfejelve, hogy a home-ja mellett a share-ket is lassa drive-kent.

btw ez szerintem siman olyan ertekhatar lesz hogy csak kozbesz jatszik, nemde?

Szerkesztve: 2021. 11. 02., k – 09:05

Szomorú látni, h. pont ezen intézményen belül nincs szakértelem akár az info karról (AUT tanszék híresen MSFT-expert emberei), akár (még) lelkes hallgatókkal (sönhercből senki?) ilyen (amúgy teljesen sztenderd üzemeltetési) feladatokat megoldani.

Őszintén szólva én olyan embert, aki ilyen szinten elboldogul a Windowszal, nem csak a BME-n, de az ég adta világon sehol nem láttam. Sőt, sokszor azt tapasztalom, hogy a kényszerből windowst is piszkálni kényszerülő linux adminok többet hoznak ki a windowsból, mint a windows üzemeltetők.

Más részről meg olyat is láttam már, hogy egy MS által dedikált többszázezres napidíjú mérnök heteket szopott egy levelezés Linuxról MS cuccokra való migrálásával.  Szóval már rég nem értik ők sem, hogy mit alkottak. :)

Bocsánat, de ez nagyon nem igaz.
Rengeteg jó szakember van, aki ért a Windowshoz is, Linuxhoz is. Csak jó helyen kell keresni.

Már bocsánat, de egy MS mérnöknek miért is kellene értenie a a Linuxos levelezőrendszerhez default értenie? Ami legtöbbször tákolt-hákolt megoldás (pl: ilyen-olyan db séma, szkriptek - akár Perlben is stb.) mondjuk egy Exchange-hez képest.

Ami legtöbbször tákolt-hákolt

Tiltakozom! Egy (pl.: Perl) kódot megalkotni, ami segíti a rendszert hozzásimítani az igényekhez inkább művészet. 10 üzemeltető 11-féleképpen alkot rá valami egyedi, elegáns, de leginkább működő kódot.

M$ oldaláról pl. az itt emlegetett roaming profil: Most akkor van, vagy nincs?! Ha van, akkor legyen már w11-ig normálisan implementálva, hogy ne kelljen "tákolni".

Egy (pl.: Perl) kódot megalkotni, ami segíti a rendszert hozzásimítani az igényekhez inkább művészet. 10 üzemeltető 11-féleképpen alkot rá valami egyedi, elegáns, de leginkább működő kódot.

És ezzel le is írtad, hogy mi egyúttal a hátránya. Ahol mondjuk nem 10 üzemeltető dolgozik, hanem 100, ott baromira nem jön jól a 110 féle megoldás. :)

Tetszőleges programozási nyelven lehet write-only kódot írni, ahogy Perl-ben is lehet olvashatót és a nyelvet ismerőknek könnyen értelmezhetőt alkotni. Igénytelen kódgányoló/botcsinálta admin persze tud olyan scriptet elkövetni, hogy néhány hét múlva maga sem fogja érteni, de ha igényes, akkor nem csinál ilyet.

A "dobozos" ebből a szempontból pont ugyanolyan mint a "felhő szolgáltató": attól még, hogy más 'vasa'/kódja ugyanúgy lehet elérhetetlen/fos :D. Csak a hibák kezelésénél megint felmerül a felelősség-lehetőség mérleg..

A művészet szép dolog. Értékelendő. Csak egy műremekhez minden művész másképp áll hozzá, másképp módosít rajta. A végén meg lehet, hogy csökken a művészeti értéke. Bármily hihetetlen, ez igaz a tényleges műalkotások restaurálására is.

A roaming profil nem ajánlott, deprecated, outdated státuszú. Nem fejlesztik, nem tesznek bele új feature-t. Tessék elfelejteni.
Tudom, hogy fáj egyeseknek ez. Ez van. Számtalan MS megvalósítással megtörtént már ez (pl: DirectAccess).

Lásd:
- https://social.technet.microsoft.com/Forums/windows/en-US/51ed0925-5365…
- https://tweaks.com/windows/67273/just-say-no-to-roaming-profiles/
- https://www.windowscentral.com/microsoft-lists-features-deprecated-and-… (itt csak a taskbar settings roamingról ír, ami érintőlegesen kapcsolódik)
- https://docs.microsoft.com/en-us/windows-server/storage/folder-redirect…

Erre pár dolgot mondanék:
- Rengetegen elmentek a BME-ről az utóbbi időben (10-15 év). Jó szakemberek is.
- Közbeszerzés.
- Pénzelvonás, átcsoportosítás, nadrágszíj húzás.
- Az egyetemen belül is megy a "széthúzás", egymás "legyőzése". Divatosan: érdekérvényesítés.

Ezt azert meg lehet csinalni, a megfelelo technologiaval, tudassal es nyilvan penzzel licenszre (ket heten belül is), de ahogy olvasom a leirast nekem ugy jon le, hogy a szukseges budget nem igazan van meg...

Licenszek meg vannak, a tudás (nekem windowshoz) hiányzik. De úgy tűnik máshol is hiány lehet, mert eddig semmi fronton sehonnan semmi ajánlat. :(
Egyelőre úgy tűnik, nem is az anyagi oldal az igazán szűk keresztmetszet.

De azt se bánom, ha valaki 2 hónap alatt rakja össze, belefér az időbe, csak ne olyan napidíjban gondolkozzon, mint az, akinek ez egy hét alatt megvan. :)

Ahoz hogy értelmes szakembert kapj erre a feladatra először át kellene beszélni a projectet, mert van a kiírásban érdekes sok helyen:

A virtualboxot prod dchez használni amatőrségre utal.

Plusz az exe-k indítása random mappából az pont csak arra jó hogy a felhasználóidat szivatod vele, kiírásban pl a windows\* benne van, de pl user joggal írható a windows\temp ami patternmatchel az allowlistre.

Az RDS az szenvedős, ha nincs olyan szabályozási környezet ami miatt nem hagyhatja el az adat az adott intézmány/ország területét, inkább felejtős, vagy ha remoteapp is működik, az tisztább szárazabb biztonságosabb érzést nyújt. 

Ha tényleg ez kell - és ezt ennyiből nem tudom eldönteni - akkor + rds gateway másik szerveren mondjuk, best practicek alapján.

Rendszergazda olvasási jog userdirekhez - menti az átirányított foldereket + FS-t valami kulturált backup megoldás, ez fölös/megkérdőjelezhető.

És most jön a szopás része - ez pár óra v pár nap programonként, attól függ mit/mennyire szeretnél és ez mennyire nehéz.
Elég sok olyan programot használunk, amit nem lehet GPO-ból szabályozni, vagy nem eléggé.

A wifi az egy külön mise, milyen legkisebb kompatibilitást szeretél, ki kezeli, milyen rendszer adja fel a vendégeket, stb. Az egy külön ember szakterülete kb. Gányolni meg lehet, de az olyan is lesz.

Owncloudot még 3-4 éve próbáltam, szenvedős volt "felhős filemegosztónak" használni; Biztosan ez kell-e?

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

Nagyrészt egyébként látszik hogy mit szeretnél, és alapvetően nem is rossz a koncepció de ahogy leírod az alapján kellene aki megarchitektálja windowsos vonalról, nem csak az aki lépésenként végrehajtja ezeket a dolgokat.

Ahoz hogy értelmes szakembert kapj erre a feladatra először át kellene beszélni a projectet, mert van a kiírásban érdekes sok helyen:

Úgy gondolom, hogy először is kellene egy ember, aki képes ilyen szinten kezelni a Windowst, aztán nyilván lehet finomítani a dolgokat. Nem ez a szakterületünk, nyitottak vagyunk egy hozzáértő ötleteire.

A virtualboxot prod dchez használni amatőrségre utal.

Lehet bármi más virtualizáció, de szerintem fölösleges volna rá két fizikai vasat elpocsékolni, és licenszköltségnek sem örülnénk. Az sem árt, ha olyan virtualizáció, amivel már képben vagyunk. A XEN HVM + windows server párossal már szokat szívtam, HyperV-t jelenleg nem használunk, felhőbe nem akarjuk kitolni az DC-t.

Plusz az exe-k indítása

Itt alapvetően az a cél, hogy ne indítson mindenféle letöltött/behozott szemetet, csak azt, ami telepítve van a gépre. Főleg ne indítson olyat, ami aztán a home-jába telepítene.

Az RDS az szenvedős...

Eddig (W2003 majd W2008 alatt) nem tűnt annak. Ráadásul van hozzá 150 darab vékonykliens, amit RDS nélkül lehet kukázni, PC-re cserélni, majd azt a rakás PC-t telepíteni managelni. Szerintem az a szívás. Új program telepítés 150 PC-re, vagy egy RDS-re: melyik a nagyobb szopás? Csomó dolgot nem lehet AD-ből rendesen felrakni, de az is igaz, vannak fejlesztők, akik még mindig a egy gép - egy (admin) user szinten állnak.

Rendszergazda olvasási jog userdirekhez - menti az átirányított foldereket + FS-t valami kulturált backup megoldás, ez fölös/megkérdőjelezhető.

Kulturált backup és a Windows nekem nehezen fér meg egy mondatban. :)
De ezer más ok miatt is jól jöhet a direkt hozzáférés. Pl. a userenkénti több GB cache kipucolására.
Ha jól emlékszem, ez csak egy GPO setting a userek felvétele előtt, és utána nem kell szenvedni, ha valamiért szükség van rá.

Wifi:
No ne már, amíg élt a W2008 DC, addig beléptettem rá egy linuxos gépet, feldobtam egy freeradius-t ntlm_auth-tal, és már működött is szépen a WPA2-EAP. A --require-membership-of meg még a csoportra való korlátozást is megoldotta. A vendégeket meg kézzel beledobtam a users fájlba. Nyilván, ha nagyobb vendég-forgalom van, akkor lehet hozzá egy webes management rendszert csinálni egy szabad délutánon.

OwnCloud:
Nálunk minden gond nélkül működik. Igaz, nem fájlmegosztónak (vagyis nem WebDAV-val), hanem szinkronizálásra. Én még a CalDAV és CardDAV részét is használom egy rakás eszközzel, mivel ezeket az adatokat sem kívánom házon kívül tárolni. Emlékeim szerint ennél sem volt fél óra az AD auth összehozása...

"két fizikai vasat elpocsékolni": Ez teljesen téves útvonal, ebbe egy tényleges szakértő sem fog belemenni. Pont, hogy a két DC két külön fizikai vason kell, hogy legyen. Persze az lehet, hogy mindkét vason belül virtualizáltan fut, de akkor is, a lényeg, hogyha az egyik vasad fizikailag meghal, akkor még ne álljon le minden. Futó DC nélkül nagyjából az 1-15.-ig felsorolt pontok közül semmi sem fog működni.

Ha HyperV-t nem szeretnétek akkor még ott az esxi. Én ezt a két technológiát ismerem, lehet hogy más is működne.

Futtatás korlátozásnál látszott hogy mi a cél, csak felhívtam a figyelmed hogy lukas az általad javasolt megoldás.

Az RDS valóban ok ebben az esetben, a 150 vékonykliens indokolja.

A Windows és a kultúrált backup megfér egymás mellett, sokan használják is :)

Ha cachet kell pucolni, akkor ott valami konfig szinten van elbaltázva, nem kellene hogy ez a napi rutin része legyen. Kvóta és/vagy logoff scriptből takarítani. 

Wifi:
Általában van egy belső meg guest ssid, a vendég külön tűzfalszabályokkal, kb dns+http(s) kivételével minden tiltva. Sávszélesség limitálva. Ahogy leírtad úgy valóban megy, de nem az a best practice vendég wifi beállítására.

CalDAV, CardDAV kiváltására exchange nélkül valóban nincs natív megoldás. Ha csak authot kell állítani az valóban nem sok.

Ez nem 1-2 hét, hanem 1-2 hónap ha rendesen meg akarod csinálni, nem csak összehányni valahogy...

A beépített szenny szemetek kigyomlálása pedig baromira nem egyszerű.... Csak az pár hét GPO, teszt, guglizás és szopás.

Illetve érdemes lenne átgondolni, pl. linux userek tárolása AD-ban helyett, linux tartományba léptetése, és tartományi userrel belépés a linuxokra.

"Sose a gép a hülye."

Szerkesztve: 2021. 11. 03., sze – 12:53

Igyekszem rövidre fogni:
Először is az általad leírt lista már jó pont 0. körben. Viszont mindenképp finomítani kell még, ki kellene dolgozni a részleteket. Tele van olyan részlettel, amelyek megvalósítása lehet 1 órás, 1 hónapos vagy akár 1 éves munka is. Töménytelen buktatóval. Szerintem te se akarod, hogy egy kártyavárat kapj, majd azzal szenvedj.

Pár általános kérdésem:
1. Ezt megcsinálja valaki. Utána ki fogja üzemeltetni, a frissítéseket elvégezni?
2. Nyilván a rendszert dokumentálni is kellene. Ezt ki fogja elvégezni? Milyen mélységben?
3. Mekkora a pénzkeret, amit erre szántok? Közbeszerzés vagy sem? Mennyire szól ebbe bele a kancellária, IIG vagy ez egy tanszéken belüli dolog?
4. Mi lett azzal a rendszerrel, amit még kb. 12-13 éve láttam a H-ban és 2 srác mutatta, hogy mennyire jól működik a vékonyklienses rendszer? A nevekre már pontosan nem emlékszem. 100 Mbit/s-os hálón szuperül elműködtek linuxos alapokon.
 

Szakmai kérdéseim, felvetéseim (csak néhány):
0. Ha Windows domain, akkor kell minimum 2 DC. Ha több van, az csak jobb. Sok erőforrást maga a DC nem eszik.
1. Megtervezte már valaki a AD-t fizikailag, logikailag? Milyen OU-k lesznek?
2. 7. pont: Ezt biztos akarjátok? Kutatási anyagok, publikációk és GDPR miatt kérdezem.
3. 10. pont: Megvan már, hogy melyik programhoz (pl: Firefox) pontosan milyen beállításokat szeretnétek?
4. 12. pont: Nem kell sémabővítés.
5. 13. pont: Nálatok nem megy a BME Wifi? IIG (régi TIO)-t nem tudtátok meggyőzni, hogy bővítsenek? Így nem nektek kellene szívni vele. Ha saját wifit akarsz, akkor  802.1x-szel, tanúsítvány alapon? Ki fogja a tanúsítványokat menedzselni? Netalán Windows CA AD integrált módban + Windows NPS-re gondoltál?
6. 15. pont: Ez szerintem rutinfeladat. Windows nyomtatószerver és kész. Ha mérni is akarod, hogy ki mennyit nyomtat, akkor nem a Windows nyomtatószerver a barátod. Kell találni valami 3rd party megoldást.
7. Virtualboxot felejtsd el sürgősen! Nem erre való. Esxi, HyperV, Xen, KVM a barátod. Tervezz failoverrel / HA-val, ha nem akarod, hogy a tanszéki, egyetemi kollégák csúnyán nézzenek rád.
8. A backupot ki, mikor, mivel, hová fogja végezni? Ki fogja elkészíteni az erre épülő DR tervet?
9. Az új rendszerhez nyilván oktatni is kellene a felhasználókat. Ezt ki, mikor fogja elvégezni?
10. Notebookok vannak a rendszerben? Ha igen, akkor az alapból borítja az eredeti elképzelést.

Licencekből (ha jól tudom), akkor rengeteg ingyen vagy minimális térítés ellenében jár. A teljes MS portfolióban is gondolkodhattok.

Annyit még utolsó gondolatként, hogy nem mindent érdemes MS technológiával megvalósítani. Át kell gondolni, hogy hol mi érdemes. Ha valamire Linux vagy BSD a jobb, akkor azt kell használni.

1.) Üzemeltetés/frissítés részt a windowsos kolléga szerintem meg tudja oldani. Egy ilyen rendszert összelőni viszont nem.
2.) Rendszer dokumentálás, BME-n? :) Már rég a tűzoltás fázisban vagyunk...
3.) Ezt én sajnos nem tudom. Viszem az ajánlatot, aztán bólintanak. Csak az a kérdés, hogy le-fel, vagy jobbra-balra. Valószínűleg megbízási szerződést tudunk csinálni önállóan is, de a fizetési mód kitalálását majd a gazdaságisokra bízzuk.
4.) Azt a linuxos vékonykliens rendszert én csináltam, és nincs is vele semmi gond, amíg csak linuxot akarnak használni. (No jó, a KDE azért tud szivatni néha.) Ugyanezek a linuxos kliensek kapcsolódtak egy W2008 szerverhez is RDP-vel. Ezt kellene leváltani, meg az időközben kipusztult Windows domaint visszaállítani. Én viszont Linuxos vonalon mozgok. Ok, van pár MCP-m Win2003-hoz, de az ide kevés lesz :)

----

0.) Nyilván legalább 2 DC és nyilván legalább 2 külön vason. A mai hardverek mellet viszont bőven megfér szerintem virtualizálva. Ha rajtam múlik eleve két eltérő virtualizációba tenném a 2 DC-t, és szívem szerint még egy samba4-et is raknék mellé harmadiknak.
1.) Igen, ez már megvan/megvolt még a 2008-as időkben.
2.) Igen. Linux alatt ez nekem tök természetes. Nem is igazán értem ezt az admin ne férjen hozzá szemléletet. Így is, úgy is hozzá tud férni ha akar, maximum többet kell érte dolgoznia... Másrészt amit lehet, igyekszek nem windows-ra bízni, így a mentés is menni kifelé rsync-kel linuxra, onnan meg vinné a szokásos linux backup. Persze lehet a másik irányból is támadni, és Linuxról megosztani a fájlokat a Win felé, de ebben az esetben a hálózati keresztmetszet nem a backupot lassítja, hanem az éles használatot.
3.) Lényegében igen. A firefox mondjuk pont egyszerűbb állat, annak nem feltétlen kell GPO, annak lehet mandatory és default konfigoka adni fájlból.
4.) Lehet, ebben nem vagyok elég járatos. Viszont a jelenlegi linuxos UID-eket jó lenne megtartani.
5.) A BME egy nagy mamut, és ennek megfelelő a dolgok sebessége. Egy új kollégának jó pár hét, mire elkészülnek az egyetemi azonosítói, és tudja használni a BME wifit, vagy az eduroam-ot. Vendégoktatók, külső óraadók esete meg még zűrösebb. Addig jutottunk, hogy az IIG eszközein kaptunk egy SSID-t, amihez mi adjuk a radius-t.
6.) Ha "csak" nyomtató lenne, igazad volna. De egy egy nagy MFP. Másol, scannel, kérheted, hogy csak akkor jöjjön ki a nyomtatás, mikor oda mentél és azonosítottad magad. Ehhez már kell az auth.
7.) Ok, Virtualbox-ot és is csak tesztelni szoktam használni. A Xen-t nyúzom élesben, de a HVM-mel, meg a PV windows driverekkel már többet szívtam, mint ami jól esik. Hyper-V hez illene valami Win szerver, ami viszont nincs. Desktop W10-re meg mégse pakolnám ki a DC-t. Esxi úgy tudom fizetős állat, a KVM-et még nem próbáltam.
8.) Mint fent írtam, valahogy linuxra át, és onnan már sínen vagyunk. Ok, persze, NTFS jogosultságok meg felhasználó kezelés az még mókás lehet. Jelenleg windowson DR-nek megelégszünk azzal, hogy megvannak a fájlok, ha kell, elő tudjuk ásni.
9.) Nyilván soha, senki. Kapacitás sincs rá, de a felhasználók nagy része mereven el is zárkózik. Én Linux témákban egyszer próbáltam összeszervezni, teljes kudarc volt. Önképzés, autodidakta számítógéphasználat. :)
10.) Notebook az független jószág. Leltártól eltekintve privát eszköz. Wifire, szeparált subnetbe mehet vele.

7-hez:  ESX fizetos (mint allat), az ESXi ingyenes (biztos ezt jelenti az i betu a neveben :)), bizonyos korlatozasokkal (tudtommal nincs HA/vCenter es talan a ram is korlatozva van/volt).

en sok helyen futtatok win servert qemu-val (KVM), nem nehez. a virtio drivereket beadod a redhat-es iso-bol amiben rendes alairt driverek vannak, es megy gyorsan stabilan. van ahol 5 eve fut gond nelkul igy egy szamlazo rendszer szervere, de DC-t is futtatok egyik ugyfelnel igy.  telepiteskor VNC-vel elered a konzoljat, utana meg mar eleg az RDP is.  van egy par trukk amivel tovabb lehet kimelni az eroforrasokat, pl. be lehet neki hazudni qemuval hogy hyper-v alatt fut, es akkor meg jobban viselkedik, kevesbe eszi a cpu-t idle allapotban :)

https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/

https://github.com/qemu/qemu/blob/master/docs/hyperv.txt

Régebben dolgoztam is a BME-n 1,5 évig. Így szerencsére/sajnos ismerem a működést. Picit lassú, picit mamut, amúgy működik.
Akkor 90%, hogy mi már találkoztunk még 2008-2009-ben. :) Az a linuxos rendszer nagyon tetszett.

Van egy olyan rossz érzésem, hogy nálatok is óriási gondok vannak. És nagyon ég a ház...
Gondolatkísérlet: Valaki jelentkezik erre, számol 2 hét munkával (10*8 óra), mondjuk 8e Ft+ÁFA/óra órabérrel vállalkozóként. Ez 640e Ft+ÁFA. Ha alanyi adómentes, akkor persze nincs ÁFA. Szerinted mennyire fog ettől az ajánlattól a tanszéki vezető, a gazdaságis, az IIG szívrohamot kapni (ha meglátják)? Mert van egy olyan érzésem, hogy itt már az egyetemi politika is erősen közbeszól... Erősen.

Ami esetleg felmerült bennem, hogy megadnám neked 1-2 exkollégám elérhetőségét, akik még mindig a BME-n vannak és Linux, Windows expertek is. Lehet, hogy így házon (egyetemen) belül tudnátok segíteni egymásnak. Ez érdekelhet téged, a tanszéket?

----

Kiegészítéseim a pontokhoz:
2.) Ha nincs olyan előírás, hogy bizonyos dolgokhoz csak szűk körben tudjanak hozzáférni (pl: ipari titkok, kutatás stb. miatt), akkor elfogadom. Office fájlokat például lehet védeni RMS-sel. Hiába másolja le valaki őket, akkor se fogja tudni elolvasni, kinyomtatni - policytól függően.
4.) Utolsó emlékeim szerint ezek változnának. Persze meg lehet azt is oldani, hogy ne, csak a megvalósítást végig kell gondolni és tesztelni alaposan.
6.) Itt lehet gond pl: SMB1 miatt - már ha csak ezt támogatja az eszköz.
7.) Hyper-V-hez nem kötelező Windows Server. Van külön Hyper-V Server termék is, ami ingyenes, letölthető, telepíthető. Gyakorlatilag egy Windows Server Core csak Hyper-V szerepkörrel. Mindazonáltal mivel van Windows licencetek, így emiatt sem kell aggódni.
 

Valóban érdekesen tud működni a BME. Időnként milliós árfekvésű notebookok jönnek szembe, máskor meg egeret is saját zsebből vesz az ember, mert nem győzi kivárni a hivatalos utat.

Szerintem a vas és a licenszek bekerülési ára mellet 8-10 évente egy ilyen összegű installációs költség épp eszű helyen nem volna szabad, hogy gondot okozzon. (Csak desktop licenszei vannak az egyetemnek, a Server licenszek, meg a RDP CAL-ok azok nekünk is fizetősek, bár szerencsére az academic árszabás kíméletesebb, mint a business.)

Nagyon szívesen látok házon belülről is bárkit, aki tud ebben segíteni, még az anyagiak elintézése is nagyságrendekkel egyszerűbb egy keresetkiegészítés formájában. Szóval megköszönöm, ha összecsatolsz valakikkel, akik értenek hozzá, és van rá szabad kapacitásuk.

Valóban érdekesen tud működni a BME. Időnként milliós árfekvésű notebookok jönnek szembe, máskor meg egeret is saját zsebből vesz az ember, mert nem győzi kivárni a hivatalos utat

Mert volt a laptopra pályázati támogatás, a normál működésre meg nincs keret. Ennyi a titka ennek, nem BME-specifikus jelenség.

Nem lesz. Sok sikert.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

Én Microsoft termékekkel foglalkozom, ebből a szemszögből vizsgálva pedig:

0. - Szerintem érdemes lenne ajánlatot kérni a témában releváns (Microsoft partner) cégektől. Azt nem tudom, hogy közbeszerzés, vagy valami más, kreatív módon fogjátok megoldani, de innen indulnék. Rengeteg jó MS szakember van itthon, csak kicsit kutatni kell. Kisvállalkozásokban bújnak meg, mert ott van rugalmasság. :)

1. Domain, RDS, fájlszerver - Az nagyon fontos, hogy ezek a szolgáltatások ne egy VM-en fussanak. És ha már RDS, én javaslom, hogy maradjon konzekvens a rendszer. Lehet rám mondani, hogy MS bérenc (az is vagyok :) ), de a vitathatatlan előnye, ha minden MS, akkor nem kell szenvedni később az integrációval, vagy azzal, amikor az egy verzió váltásnál szétesik (vállalton belül azért általában figyelnek egy ideig a backward compatibility-re).

2. Roaming profiles, folder redirection - Sok múlik azon, milyen a hálózat, szerintem ez abszolút megvalósítható, de fel kell mérni alaposan a környezetet, ez sok idő.

3. Szerintem ez 1 pontos kérdés, könnyen megoldható.

4. Szintén

5-8. Rutin feladat bármelyik közepes képességű Wndows rendszergazdának, ezzel biztosan nem lesz gond.

9. Ilyet régebben csináltam, ha jól emlékszem, akkor van lehetőség az ilyen ajánlott és egyéb appok mellőzésére.

10. Ha jól tudom, mindegyik megoldható GPO-val, érdemes így csinálni.

11. Talán ezt tényleg nehéz szépen megcsinálni, de nem lehetetlen, esetleg ez valóban időigényes lehet.

12. Ez már régen is ment mindenféle sémabővtés nélkül, úgy emlékszem legalábbis, hogy 2003-as tartományvezérlőre léptettem be Ubuntu 8.10-et

13. NPS szerver ha már úgy is van Windows? A többi egyértelmű.

14. LDAP megoldható, nem nagy kunszt.

15. Windows fájlszerveren jól elvan a nyomtatószerver role is.

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

Ami fontos, 2 (vagy több) DC, 2 (vagy több) Hypervisor-on futtatva. Mert ha az leborul és nincs párja, akkor sokat fog csörögni a telefon.

A virtualbox játszani nagyon jó, de éles környezetben nincs helye. Hyper-V vagy ESXI

Ha már Windows Server-t licenszelsz, akkor érdemes kiszámolni, neked mi érné meg jobban? Eleve, a Hyper-V kiszolgáló (akár Core, akár Desktop Experience-el) mellé tudsz még két VM-et aktiválni per licensz. Tehát a Hypervisor kérdést úgy is lefedi a licenszelés. De ebben is mindenképp MS partnerhez fordulnék, a sales fogja tudni megmondani, mik a pontos árak. Ha kell egyéb management tool (Pl. Virtual Machine Manager), az persze plusz licensz, de a leírásdoból arra gyanakszom, erre itt nem lenne szükség, Hyper-V manager is lefedi az igényeket.

Egyébként nettó két hét alatt ez simán megvalósítható, de bruttó lesz legalább 3 hónap, mire minden úgy fog működni, ahogyan az eredeti elképzelés szerint kellene. Mindig jön majd újabb user voice, hogy ez-az nem úgy van, vagy még nem működik, a finomhangolás pedig szintén idő és költségigényes tud lenni.

És dokumentálni, dokumentálni, dokumentálni! :) Nagyon hálátlan dolog egészen addig, amíg valami meg nem borul, vagy valamit meg kell keresni.

Ha valamit kihagytam, vagy pontatlan voltam sorry, de remélem, tudtam segíteni.

pár észrevételem lenne a projekttel kapcsolatban:

1, mint ahogyan páran leírták már, ilyen funkció lista mellett normális virtuális platform kell, ami VMWARE (ESXi) vagy MS Hyper-v. A VMWARE-ből létezik akadémia licenc is, érdemes elgondolkodni rajta. Mind a kettőnek van előnye is meg hátránya, de ilyen igény mellett nem játszik a Virtualbox. Az MS rendszerek szeretnek együtt dolgozni, tehát ha AD-t használsz, akkor oda Windows fájlszerver kell, és nem egy Samba. 

2-6, lehet, hogy ami jól működött linux alatt, az nem fog megfelelően működni Windows alatt (vándorló profilok). Érdemes inkább dedikált VM-ket adni a felhasználóknak, hogy mindig egy gépre lépjenek be, és ne több gép között mozogjanak. Így egyszerűsödik az élet, könnyebb a licenceket kezelni (kevesebb gépen kell), kevesebb gépet kell üzemeltetni. Minden ilyen nagyobb "technológiai" váltásnál el kell gondolkodni azon, hogy hogyan tudjuk egyszerűsíteni a működést, és lehet hogy jobb szolgáltatást váltani (megszüntetni), mint szívni azzal, hogy nem működik az implementációja. Biztos, hogy szükség van RDS farmra, ha mindenki dedikált gépet kap? (van mind a két gyártónak egyébként VDI megoldása ilyen esetekre)

7, érdemes inkább egy megfelelő backup megoldást választani (a VEEAM-t javaslom), mert egyszerűn lehet visszaállítani fájlokat, extra jogosultság nélkül. 

8-11, sok minden szabályozható GPO-val vagy akár a legtöbb antivirus programmal is (fájlok blokkolása), de érdemes lenne elgondolkodni azon is, hogy a gépek üzemeltetésére beállítani egy management platformot, ami nagyban megkönnyiti az üzemeltetést (MS oldalról SCCM, vagy például ManageEngine Desktop Central.) Ettől kezdve van lehetőség saját telepítő csomagok gyártására, olyan beállításokkal amilyet te akarsz. (pl. kikapcsolt automatikus frissítéssel), és a management platformon keresztül egyszerűen tudod a klienseken telepíteni. A cél minden esetben az, hogy egyszerűsítsük a kliens oldali üzemeltetést és automatizáljunk amit lehet.

12, nem használtam még ilyet, de szerintem már sémabővítés nélkül is megoldható.    

13, Inkább a Windows-ba beépített NPS, hogy egy platformon legyen minden kezelve. De ehhez megfelelő Wi-Fi-s eszközök is kellenek, amiken be tudod állítani a több SSID-t illetve az egyenkénti auth. megoldást. A Guest-re voucher/captiva portál lehet a megoldás, ami az AD-tól függetlenül működik. De ez is függ attól, hogy a fizikai eszközökön mit lehet beállítani, de magukról az eszközökről nincs információnk. (mielőtt valaki felvetné: lehetne az AD-ba tenni a vendég eléréseket, de szerintem nem jó megoldás ilyenekkel teleszemetelni az AD-t)

14-

15: erre mindenképp a gyártóval kell egyeztetni, hogy milyen megoldást tud kínálni, de ez csak akkor működőképes, ha a felhasználók valamilyen kártyás auth.-t (pl a beléptető kártyával) tudnak végrehajtani a nyomtatónál, mert az gyors és egyszerűsíti a használatot a részükre.        

ami fontos lehet még:

- nem ismerjük a jelenlegi architektúra (hálózat) felépítését, mert az sok mindent befolyásol. (pl kell-e távoli hozzáférést nyújtani, milyen biztonsági szabályoknak kell megfelelni). Ezt a projekt elején fel kell mérni és utána lehet tervezni.

- szerintem is inkább 1-2 hónap, mint 1-2 hét, mert fokozatosan haladunk előre, és ez nemcsak abból áll, hogy felhúzok egy AD-t, hanem más lépések is vannak mögötte (pl. PKI infra.).  (és december közepétől megáll az élet M.o. és felsőbb szintű döntéshozók nélkül nem lehet egy ilyen projektet végrehajtani) 

- lehet a felhasználói oktatáson gondolkodni, de ki fogja végrehajtani is mikor. Érdemes inkább dokumentációt adni a felhasználó kezébe, hogy mit hogyan ér el és használhat. Ezt az újonnan érkezőknek is elég a kezébe nyomni. 

Ha kesz a melo majd ird mar meg, hogy mennyi ideig tartott pls. Az utokor szamara is hasznos lenne.