Windows Server 2008 - cudno ponasanje ...

Da pokusam da opisem problem:

- preko 'remote desktop connection' administriram Windows Server 2008 (na 'geografski udaljenoj lokaciji'),
- prije nedjelju dana sam dobio zahtjev da se za neki fajl definise 'Full control' pristup za korisnika X, a za korisnike iz neke dvije grupe, samo Read i Read&Execute, a za sve ostale korisnike da nema mogucnosti nikakvog pristupa. Postavio sam odgovarajuce pristupe i provjerio u 'Effective permissions' (za sve korisnike) da li je sve kako treba i javio korisniku da moze da radi,
- prekjuce mi je javljeno (od strane korisnika) da svi domenski korisnici imaju 'Full control' nad pomenutim fajlom. Provjerim i, zaista, u 'Security' tab-u stoji da 'Domain Users' grupa ima 'Full Control' nad fajlom. Vratim ponovo, NTFS dozvole, kao sto su i bile, ponovo provjerim u 'Effective permissions', vidim da je sve kako treba i zamolim korisnika da, kad dodje na posao, provjeri dozvole i da mi javi. Po dolasku na posao, korisnik javlja da su dozvole kako treba, medjutim, poslije nekog vremena, dozvole su se ponovo promijenile (ponovo stoji da grupa 'Domain Users' ima 'Full control' nad pomenutim fajlom).

Pitanja:
- da li je moguce da postoji nekakav mehanizam u samom Windows Server 2008, koji mijenja definisane NTFS dozvole?

Ima li neko ideju sta je moguci uzrok ovakvog ponasanja?

Potpis

Programming is fun, but writing good software is hard ...

Podesi audit za definisani file ili folder, i pokusaj da vidis sta se desava. Ja inace uvijek koristim deny permisije jer su one uvijek jace od svih ostalih...

Potpis

Bojan

Dakle, definitivno mi treba pomoc - ili nesto ne radim dobro (veca vjerovatnoca) ili sam server mijenja permissions za file (bez ikakvog traga o tome u 'audit'-u).
Potrudicu se da detaljnije opisem problem.

Postoji folder, recimo, FOLDER_1 i u njemu fajl, recimo: FILE_1.
Postoji i OU, nazovimo je OU_1, u kojoj su korisnici koji treba da pristupaju folderu FOLDER_1 i fajlu FILE_1.
Jedan clan iz OU_1, nazovimo ga CLAN_1, treba da ima 'Modify' permissions nad fajlom FILE_1 - svi ostali clanovi iz OU_1, samo 'Read' and 'Read&Execute'.

Dalje, OU_1, nad folderom FOLDER_1 ima dodijeljen permission 'MODIFY'.
Nad fajlom FILE_1, OU_1 ima 'Read' i 'Read&Execute', a clan CLAN_1, nad fajlom FILE_1 ima dodijeljen permission 'MODIFY'.
Pri ovome, kad je definisan permission nad fajlom FILE_1, za OU_1 je deselektovan checkbox 'Inherit from parent the permission entries ...'.

Svi dodijeljeni permissions su provjereni u 'Effective permissions' i dobijen je rezultat:
- OU_1 nad fajlom FILE_1 ima 'Read' i 'Read&Execute'
- CLAN_1, nad fajlom FILE_1 ima 'Modify'.

Postavio sam 'audit' nad fajlom FILE_1 i to za 'Everyone' , dogadjaj: 'Change permission' (Event ID = 4670). Vide se dva entrija sa ovim EventID-em i to se odnosi na dogadjaj kada sam ja dodijelio permissions.

Sta se dogadja - poslije nekog vremena dolazi do promjene dodijeljenih permissions nad fajlom FILE_1 (pri ovome nema nikakvog zapisa u log-u):
- OU_1 dobija permission 'Modify' nad fajlom FILE_1 (pri cemu stoji selektovan checkbox 'Inherit from parent the permission entries ...'),
- CLAN_1 se vise ne vidi u ACL-u, to jest ne postoji kao korisnik kome su dodijeljeni permissions nad fajlom FILE_1.

Epilog: svi clanovi iz OU_1 imaju Modify nad fajlom FILE_1.

Ponavljam, nema zapisa u logu o dogadjaju sa EventID=4670 (a to je 'permission changed').

Jos nesto: postoji vremenska razlika (jer je server na geografski udaljenoj lokaciji) izmedju trenutka setovanja permissions-a (to uradim ja) i pocetka radnog vremena (to jest rada nad tim fajlom).
Danas sam definitivno utvrdio da se to desava poslije pristupa fajlu od strane korisniak CLAN_1 (dakle, jedinog iz OU_1, kome je dodijeljen permissions 'Modify') ???

Molio bih za pomoc, savjet ... ja nemam ideju sta je uzrok ovom desavanju ???

Da li, mozda, nisam dobro podesio permissions-e ? Ponavljam:
- Effective permissions pokazuje da su setovanja u skladu sa zadanim,
- Dolazi do promjene ACL za FILE_1,
- Nema nikakvog traga o izmjeni ACL-a u log-u,
- Do promjene dolazi tek kad CLAN_1 pocne sa pristupom fajlu (provjerio sam, CLAN_1 nije clan nikakve administratorske grupe)

Hvala unaprijed ...

Potpis

Programming is fun, but writing good software is hard ...

Hm, da li taj folder treba da ima inherit perimisije od perenta? Zasto koristis OU za usere a ne security grupe ? Pokusaj sa security grupama. Moram priznati da mi je ovo malo sve konfuzno, ali sad sam u nekoj guzvi pa ne mogu da nacrtam sebi to, pokusacu kasnije da vidim sta bi moglo biti.

Potpis

Bojan

Evo sad sam provjerio, nisam bio precizan:

- OU_1 nije OU (organizational unit) - nego je 'security group' i nalazi se u nekoj OU ...

Znaci, postoji OU, a u okviru nje jedna 'security group', recimo GRUPA_1.

I sada:
- GRUPA_1 treba da ima MODIFY nad folderom FOLDER_1
- SAMO jedan clan iz GRUPA_1, treba da ima MODIFY na fajlom FILE_1 (koji se nalazi u folderu FOLDER_1)
- OSTALI clanovi iz GRUPA_1, treba da imaju Read i Read&Execute nad fajlom FILE_1 (koji se nalazi u folderu FOLDER_1)

Hvala na javljanju ...

Potpis

Programming is fun, but writing good software is hard ...

Kakve su permisjie grupe everyone i register user ?

Potpis

Bojan

Hehe, ovo zna biti frustrirajuce ali me cudi da do sad niste
naisli na ovaj "problem".

Vise o tome na http://blogs.technet.com/b/ask...-adminsdholder-and-sdprop.aspx

Everyone grupa nema nikakvih permisija nad pomenutim fajlom.
'register user' ne postoji u domenu ...

Potpis

Programming is fun, but writing good software is hard ...

Kao prvo, hvala ti na javljanju ... Moram da priznam da o ovome nista nisam znao.
Citao sam preko vikenda o ovome, ne znam da li sam ja ovo dobro shvatio:

- Server 2008 ima mehanizam kojim stiti odredjene naloge, koji pripadaju odredjenim (zasticenim, odnosno, 'protected') grupama, od izmjena ACL-a?

- ne mogu da nadjem vezu sa 'mojim' problemom: ja imam OU i u njoj 'security' grupu. Ova grupa nije clan nijedne od 'protected' grupa koje stiti ovaj mehanizam (adminsdholder), niti je ijedan njen clan uclanjen u neku od 'protected' grupa (koje stiti adminsdholder). Svi clanovi ove 'security' grupe su clanovi grupe 'Domain users' (ali, koliko sam ja uspio da procitam, ova grupa nije na listi 'sticenih' od strane mehanizma adminsdholder).

Na 'http://technet.microsoft.com/e...ine/2009.09.sdadminholder.aspx' pise: 'One thing to keep in mind is that users are protected by AdminSDHolder if they have direct or transitive membership in a security or distribution group. Distribution groups are included because a distribution group can be converted to a security group.'

Da li ovo znaci da se svaka 'security' grupa potpada pod mehanizam zastite 'adminsdholder' ?
Ako je i to tacno, opet ne mogu da nadjem vezu sa 'mojim' problemom?!

Ako sam dobro razumio, SDPROP bi, ako nesto nije u redu, u nekom vremenskom roku, promijenio dozvole koje sam dodijelio.

Zbog vremenske razlike, izmedju trenutka (mog) setovanja permisija i pocetka rada na lokaciji servera (odnosno, pristupa pomenutom fajlu), prodje minimum 6 sati svakog dana - promjena u ACL-u se desava tek kada na udaljenoj loakciji dodje do pristupa pomenutom fajlu.

Ja od pocetka razmisljam, da li, mozda, ja grijesim u samoj dodjeli permisija:
- ja imam 'security' grupu koja ima dodijeljenu permisiju 'Modify' nad folderom,
- ja toj 'security' grupi dodjeljujem 'Read' i 'Read&Execute' nad jednim fajlom , u tom folderu, a
- samo jednom korisniku, iz te security grupe, dodjeljujem 'Modify' nad tim fajlom.

Mada, tab 'Effective permissions' (za taj fajl) mi vraca korektne dozvole za sve akaunte ...

Jos jednom hvala, procitao sam nesto, za mene, novo ...

Potpis

Programming is fun, but writing good software is hard ...

Koja je vrijednost atributa adminCount usera koji pristupaju tom fajlu/fajlovima?

Rezultat komande: ' ldifde -f ldifdeoutput.txt -r "(&(objectcategory=person)(objectclass=user)(admincount=1))" ' je da postoje 4 (cetiri) objekta u domenu sa setovanim AdminCount:

1. dn: CN=Administrator,CN=Users,DC=xxx,DC=yyy
2. dn: CN=krbtgt,CN=Users,DC=xxx,DC=yyy
3. dn: CN=Backup,CN=Users,DC=xxx,DC=yyy
4. dn: CN=BTEAM14,OU=bgteam,DC=xxx,DC=yyy

Niko od user-a, koji pristupaju doticnom fajlu, nije na ovoj listi. Ponavljam: ti user-i su clanovi DomainUsers (samo).

Ono sto me je iznenadilo je to da je moj domenski account (BTEAM14) sa setovanim atributom AdminCount ? Ja nisam nista zadavao ( u vezi toga). Ima li to nekog uticaja ??? (ja se logujem u domen 'remotely', preko VPN-a sa svojim username-om, tj. bteam14 - svu administraciju radim iz remote desktop-a, ali sa administratorskim nalogom).

Zahvalan za javljanje ...

Potpis

Programming is fun, but writing good software is hard ...

Sad sam ponovo procitao temu od pocetka pa da rezimiramo.
Da li je za taj folder u securityu maknuta kvacica "Include inheritable...."? za secutrity groupu i usera1, odnosno nad tim permissionima.

Za folder, grupa ima permisiju 'Modify', koju je naslijedila, kako da kazem, sa 'parent' folder-a. Znaci, nad doticnim folderom, za 'security grupu' (o kojoj je rijec) je potvrdjen checkbox: 'Include inheritable permissions from this object's parent'.

Dalje, za fajl u predmetnom folderu, stoje permisije:
- za 'security grupu': 'Read' i 'Read&Execute', sa ukinutim checkbox-om: 'Include inheritable permissions from this object's parent'.
- za jednog clana iz ove 'security grupe', permisija je 'Modify', sa ukinutim checkbox-om: 'Include inheritable permissions from this object's parent'.

Provjerim u 'Effective permissions':
- grupa, nad fajlom, ima permisije 'Read' i 'Read&Execute' i 'maknutu kvacicu' za: 'Include inheritable permissions from this object's parent',
- samo jedan clan grupe ima permisiju 'Modify' i 'maknutu kvacicu' za: 'Include inheritable permissions from this object's parent'.

Za 'owner'-a sam proglasio Administrator-a.

Receno mi je da ostavim da grupa ima 'Modify' nad folderom, da bi u buduce i drugi korisnici mogli da kreiraju fajlove, nad kojima bi samo oni imali Modify, a ostali raed i raed&execute.

Potpis

Programming is fun, but writing good software is hard ...

Ajd za pocetak nad tim folderom za tu security grupu iskljuci nasljedivanje prava od
parenta i kad te pita sta da ucini sa trenutnim pravima klikni na Add. Zatim vidi jel
su sva prava na tim folderom ok i onda klikni na "Replace all child object....".

Iskljucio sam 'naslijedjivanje', za grupu, od parenta, nad folderom ... sva prava su kako treba (i nad folderom i nad fajlom), praticu sta se desava, pa cu se javiti ...

> i onda klikni na "Replace all child object....
Nije htio da prihvati 'klik' na ovaj checkbox, to jest, moguce je kliknuti i potvrditi ovaj checkbox, ali kad kliknem na dugme Apply i naknadno provjerim sve permisije (klikom na dugme Advanced), ovaj checkbox stoji nepotvrdjen ...

Hvalal jos jednom ...

Potpis

Programming is fun, but writing good software is hard ...

Ne vrijedi, opet vraca permisije tako da grupa ima modify nad fajlom. I to, ostalo je, na folderu, da grupa ne nasledjuje nista od parent-a, a na fajlu stoji da je grupa naslijedila (iako sam to ukinuo) permisiju od parenta?!
Iz ACL-a, za fajl, se 'izbrise' taj jedan user, koji jedini treba da ima modify and fajlom, a i owner se prebaci na tog user-a ...
U logu nema nista na temu izmjene permisija (EventID=4670, permission change, nema nijednog zapisa na tu temu) - a evidentno je da se promjena desila ?!
U logu postoje zapisi o pristupu fajlu, od strane user-a. Ono sto me interesuje, uvijek se moze naci zapis da je taj korisnik pristupa fajlu, i da je tip pristupa, izmedju ostalog" 'Delete' ? Jel' to znaci da je izbrisao fajl ili sta li?

U pravu si, ovo je zaista frustrirajuce ... a ne volim da ne znam uzrok za ovakve stvari :)

Potpis

Programming is fun, but writing good software is hard ...

Procitaj ovo http://support.microsoft.com/kb/308419 polagano pa vidi jel si negdje fulao.
Posto se ownership prebaci na usera mislim da permissions nisu dobro podesene.

Jos nisam rijesio ovaj problem, ali sam ustanovio sto se desava:
- fajl, koji je u pitanju (za koji se definisu permisije), je XLS fajl (Excel file),
- kada mu pristupa korisnik koji ima permisiju 'Modify' i uradi neku izmjenu i klikne na 'Save', server samo pamcenje radi iz dva 'koraka': 'Delete' pa 'Save' (ovo sam sigurno ustanovio, jer kad namjestim 'Audit' na fajl, uvijek je poslednji zapis u log-u tipa: 'Delete'),
- znaci, server uradi 'Delete' postojeceg fajla (na kome sam namjestio permisije), a onda kreira novi fajl, a taj novi fajl naslijedi permisije od parent-a (roditeljskog foldera) - jednostavno, sve sto sam namjestio se izbrise (ukljucujuci i Audit setovanja), a nove permisije (ukljucujuci i vlasnika) se naslijede sa roditeljskog foldera. SVI cekboksovi na temu 'Inheritance' od 'parent object' NISU potvrdjeni ...

Kako da podesim da novokreirani fajl ne naslijedi permisije od roditelja?

Potpis

Programming is fun, but writing good software is hard ...

Izgleda da je uzrok lociran: http://support.microsoft.com/kb/102888

Potpis

Programming is fun, but writing good software is hard ...

Uzrok resetu NTFS permisija, za Microsoft Office fajlove (XLS, DOC, PPT, ...), lezi u samom nacinu rada ovih aplikacija: one KREIRAJU TMP fajlove (aNnvokreirani fajl nasledjuje permisije sa parent folder-a), u kojima cuvaju novi sadrzaj, a sama operacija SAVE se sastoji od: DELETE originalnog fajla + RENAME tmp fajla (u ime originalnog).

Rjesenje, koje ce zadovoljiti trazeni korisnicki zahtjev (da samo jedan korisnik moze da mijenja sadrzaj fajla, a ostali samo da 'gledaju') jeste da se permsiije dodijele FOLDER-u:
- GRUPA_KORISNIKA -> Read, Read&Execute
- SAMO_JEDAN_KORISNIK (iz GRUPA_KORISNIKA) -> Modify

Samom fajlu NE treba zadavati NIKAKVE posebne permisije, nego treba CEKIRATI checkbox za nasledjivanje ('Inherit from parent folder ...').

Svaki put kad uradite SAVE (iz Excell-a), fajl ce 'povuci' (preciznije, naslijediti) permisije sa parent folder-a i to je to.

E sad, ovo nosi, po meni, veliki problem, jer Modify sadrzi i DELETE permisiju, pa SAMO_JEDAN_KORISNIK moze da obrise i sam folder (kao i njegov sadrzaj). No, to je vec neka druga tema ...

Znaci, odgonetnuo sam zasto je doalzilo do reseta NTFS permisija ... nadam se da ce jos nekom ovo saznanje biti od koristi ...

Pozdrav i hvala svima koji su se javljali ...

Potpis

Programming is fun, but writing good software is hard ...