Ügyességi játék

Hozzászólások

Ezert van a kereses funkcio benne ----> Adminolni IS tudni kell :P

A kereso kepernyon (advanced mode) at lehet meretezni a kepernyot ha esetleg rosszul keresel es 300000000000 talalat lenne.

mod:

Amugy meg miert nem groupokba van rendezve a jogosultsagkiosztas az adott akarmin amit sysadminkent buzeralsz? Akkor nem kellene jatszani az ablakkal csak az adott groupba betenni/kivenni marketing marcsit...

_elbaszott UI dizájn_

640-en két userrel még jó volt, csak azóta nem fejlesztették tovább.
a csilivili felület alatt rengeteg őskövület van, amihez már nem nyúlnak hozzá.

egyébként csinálhatnád egyszerűen így is:


$acl = Get-Acl \\fs1\shared\sales
$AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule("ENTERPRISE\T.Simpson","FullControl","Allow")
$acl.SetAccessRule($AccessRule)
$acl | Set-Acl \\fs1\shared\sales

--
nincs aláírásom

"640-en két userrel még jó volt, csak azóta nem fejlesztették tovább.
a csilivili felület alatt rengeteg őskövület van, amihez már nem nyúlnak hozzá."

Ha így van, akkor azt feljebb miért nem lehetett leírni? Miért kell terelni, hogy "de há' ezt 25 kattintással többel így meg így is meg tudnád csinálni"? Nem érdekel, hogyan lehetne még megcsinálni. Van egy módszer, ami ott van kettő kattintásara és egy rakás szar. Nem mélyen a rendszerben, hogy ne verje ki a szemet.

Ezzel kellene foglalkozni, nem kiadásról kiadásra új start menüt, meg egyéb lófaszt reszelni.

--
trey @ gépház

Ez ráadásul még rosszabb is, mert nemhogy másként kell használni, hanem amit eredetileg felvetett (ABC sorrendbe rendezés) pont, hogy szembe megy az ACL feldolgozási módjával (sorrendbe tett szabályok, első matching szabály nyer), vagyis biztonsági és akár teljesítmény problémákat is okozhatna; még ha a legtöbb esetben nincs olyan bonyolult szabályrendszer, aminek a jelentésén egy ÁBC-be rendezés módosítana a jelentésen (mármint a rendezés és úgy általában a rendezés _lehetőségének_ megadásával az admin által érzékelt és a valós, a rendszer által betartatott jelentések között eltérés lehet), de elképzelhető.
A nem átméretezhető ablak felvetés már jogos, ahogy az is, hogy a win tele van ilyenek legacy szeméttel és mindig mekkora hír, ha egyet-egyet kiszednek (pl. https://hup.hu/cikkek/20180509/fejlettebb_sorvege_jel_tamogatast_kapott…).

Egyébként ha az MS valaha hozzányúlna az ACL szerkesztő ablakhoz (kétlem, túl sok helyen van a rendszerben), szvsz. egy szűrő mezőt kéne csak bele tenni (+ átmérezhetőség...), hogy gyorsan kereshetők legyenek az ACE-k (ha meg még SID-et/SID részletet is meg lehetne adni a keresőben, ill. mondjuk *Mancikák formában feloldhatnál csoportnevet tagokra [na, ez pl. bődületesen lassú lenne, btw.], az mindennek a non plus ultraja lenne)

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

Ugye, azt most nem akarod komoly arccal elmagyarázni, hogy egy számítógép - főleg a mai teljesítményben - nem képes egy bárhonnan jövő, tetszőleges adathalmazt valamilyen szempont alapján növekvő vagy csökkenő sorrendbe állítani és megjeleníteni?

--
trey @ gépház

A számítógép igen, az _admin_ nem (na meg nem csak adminok nézik ezt a felületet). Ha az admint hagyod, hogy _rendezzen_ security identifier-re, az admin-ban azt a hatást fogod kelteni, hogy a szabályok sorrendje mindegy. Holott marhára nem az. Ha csak _szűrni_ hagyod, végig a feldolgozás tényleges sorrendjét fogja látni az admin/user.

A teljesítményt két helyen írtam:

1) nem a szerkesztéskor, hanem az eléréskor _jöhet_ elő. Ugyanúgy, ahogy mikrooptimalizálhatsz az iptables szabályokkal (pl. elsőként established accept, mert azt már egyszer nézted), egy szarul megírt program, ami másodpercenként rengeteg fájl open/close műveletet végez egy elég bonyolult ACL-el egy sok tízezer felhasználós/csoportos tartományban, már észrevehető lehet (mondjuk a Kerberos PAC-ba beletákolt csoporttagságokkal legalább a DC-hez menő roundtripet megspórolják, de még azzal együtt is n*m halmazművelet lesz).

2) a másik az X csoportba tartozó userek listázása. Ami egyszerű, ha a csoportban csak userek vannak és abból se túl sok. Kicsit bonyolultabb, ha sok user van benne. Sokkal bonyolultabb, ha a csoportban vannak másik csoportok és rekurzívan végig kell őket járnod. Ha meg a cross-forest azonosítók is bejönnek a képbe, még sokkal lassabb. De hogy ez mennyire nem hatékony: az inverz probléma (egy user _összes_ csoporttagságának a felsorolása, ugyanígy rekurzívan) olyannyira elérte az MS ingerküszöbét, hogy az LDAP szerverükben egy (csak one level scope-al lekérhető...) virtuális attribútumot (tokenGroups) hoztak rá létre, így legalább egy helyben fut le a keresés és nincs hálózati roundtrip.

valamilyen szempont alapján növekvő vagy csökkenő sorrendbe

Amikor legutoljára láttam Mikrotik winbox-ot, abban az iptables szabályokat lehetett sorba rendezni... aki azt kitalálta, azt egy baseball-ütővel addig kéne ütni, amíg rá nem jön, mit cseszett el, ott még legalább a szabályoknak mellékhatása is van... másrészt mi legyen a szempont pl. source IP-nél? Lexikografikus? Numerikus? És a jump-nál? És a...

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

A sorrend kérdést úgy is fel lehet oldani, hogy bevezetsz egy oszlopot a sorszámnak, ami együtt marad a sorával.

Rendezés pozíció alapján (default):


  Position ↓   Group or User  
 ------------ --------------- 
  1            User 1
  2            Group 1
  3            Group 2

Rendezés ACE alapján:


  Position   Group or User ↓  
 ---------- ----------------- 
  2          Group 1
  3          Group 2
  1          User 1

Ja, ezt használja a Mikrotik is. Aztán ebből lesz az, hogy sakkozol, hogy mit akarhatott a kolléga egy-egy szabállyal, ami - mivel rossz helyen volt - soha nem futott le, de négykor műszak vége, inkább accept all :(

És mondjuk egy standard Windows ACL-nél (csak additív jogosultságok és aztán a default deny-ra bízod a többit) tényleg lehetne akármilyen sorrendben is, a jelentésén nem változtat, de az első deny rule-nál borul a dolog.

Egyébként a megszokások és a félreértett context: már jópár éve annak, hogy az MS megváltoztatta a GPO-k elérési módját (a számítógép fiók kér le mindent, aztán adja tovább a usereknek), még aki már bele is futott és tud róla, anbak is extra terhelés, hogy emlékezzen, hogy ennek megfelelően ossza ki a jogosultságokat, mert kicsit más a szabályok jelentése, mint mindenhol máshol, és ez sehol nincs jelölve - ugyanez pepitában, ha sorrend-helyes szabályokat rendezhetsz: emlékezned kell, hogy más s jelentése a szabály listádnak, mint ahogy első ránézésre látod.

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

https://nefaria.com/2016/06/ms16-072-breaks-security-filtering-on-group… (a frissítés azonosítójára kijön belőle hivatalos MS doksi is, ez volt az első, ahol megtaláltam :) )

Gyakorlatilag a Security filtering korábban úgy ment, hogy mind a gép, mind a user frissítgette a saját magára vonatkozó GPO-kat, közvetlenül a DC-t csesztetve - ahol pedig a sysvol megosztás fájlrendszerében és az LDAP-ban a GPO objektumhoz tartozó ACL-el volt korlátozva, hogy ki érheti el. A fenti update ezt változtatta meg arra, hogy mindig csak a gép accountjával éri el a sysvol megosztást/DC-t, aztán a gép belül "továbbosztja" (az ACL-ek betartatásával) az egyes usereknek.

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