[2008 R2] User heeft geen group-rechten op shares

dinsdag 8 december 2009 22:10

ye olde farte

je hebt twee compleet gescheiden SAMs op twee standalone machines waarmee je je users beheert.
Dit is geen probleem, dit is by design.

Dat je met een zelfde username/password combinatie met pre-7 operating systems bij andermans spullen kon komen heeft puur te maken met backwards compat aangaande het logon mechanisme (NTLMv2 preferred).

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device

Acties:

dinsdag 15 december 2009 21:22

Topicstarter

alt-92 schreef op dinsdag 08 december 2009 @ 21:31:
je hebt twee compleet gescheiden SAMs op twee standalone machines waarmee je je users beheert.
Dit is geen probleem, dit is by design.

Dat je met een zelfde username/password combinatie met pre-7 operating systems bij andermans spullen kon komen heeft puur te maken met backwards compat aangaande het logon mechanisme (NTLMv2 preferred).

Klopt, 2 SAMs en dat het by design is is me bekend. Heb username en wachtwoord vooralsnog voor het gemak gelijk op zowel werkstation als server. Maar ook als ik op de share inlog met "win2008\testuser" en het bijbehorende wachtwoord werkt het niet.

Zoals eerder gesteld: alles lijkt te kloppen (en het werkt ook als ik de rechten op gebruikersniveau instel) ware het niet dat Windows 2008 het "win2008\administrators" group membership van "win2008\testuser" over het hoofd lijkt te zien.

Edit: Gisteren zelfde situatie nagebouwd met out-of-the-box installatie van Windows 2008 (dus niet R2). Gek genoeg bestaat het probleem daar niet.

[ Voor 9% gewijzigd door HaveBlue op 19-12-2009 00:45 ]

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

dinsdag 15 december 2009 21:31

Topicstarter

Kom er maar niet uit. Iemand een idee

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

dutch_warrior

Hmm bijzonder probleempje

.
Is test user ook op het windows 7 werkstation lid van de groep administrators ?
Eigenlijk mag en moet dit ook niets uitmaken maarjah even dingen uitsluiten.

Is je server een domain controller of werk je met lokale groepen ? Ik ga uit van laatste...

dinsdag 15 december 2009 21:32

Acties:

bosgoed

HaveBlue schreef op dinsdag 08 december 2009 @ 20:22:

Op een netwerk werkstation met Windows 7 is een lokale gebruiker met admin rechten aangemaakt, laten we 'm "testuser" noemen. Deze gebruiker bestaat met hetzelfde wachtwoord als op het werkstation ook op de fileserver en is daar ook lid van de "Administrators" groep.

Ik neem aan dat als je met de lokale gebuiker inlogt niet op je domein maar op de lokale pc inlogt?

Thanks Mate

dinsdag 15 december 2009 21:56

Acties:

Turdie

Zit je fileserver in een AD domein? Als dat het geval is, kun je met een lokale user nooit met een lokaal account authenticeren voor voor resources in een domein. Daar heb je een domein account voor nodig.

Als het een fileserver in een werkgroep is, kun je alleen de resources benaderen met een lokaal account wat actief is op deze fileserver, nooit lokaal op je werkstation. Wat alt-92 ook al aangaf.

Is het zo duidelijk?

[ Voor 5% gewijzigd door Turdie op 15-12-2009 21:58 ]

dinsdag 15 december 2009 22:21

Acties:

dinsdag 15 december 2009 22:31

Topicstarter

dutch_warrior schreef op dinsdag 15 december 2009 @ 21:31:
Hmm bijzonder probleempje .
Is test user ook op het windows 7 werkstation lid van de groep administrators ?
Eigenlijk mag en moet dit ook niets uitmaken maarjah even dingen uitsluiten.

Is je server een domain controller of werk je met lokale groepen ? Ik ga uit van laatste...

"win7\testuser" is op het werkstation een administrator

Is niet verschrikkelijk relevant omdat ik op de server niet inlog als "win7\testuser" maar als "win2008\testuser".

bosgoed schreef op dinsdag 15 december 2009 @ 21:32:
[...]
Ik neem aan dat als je met de lokale gebuiker inlogt niet op je domein maar op de lokale pc inlogt?

Server hangt niet in een domein maar is gewoon lid van een werkgroep

shadowman12 schreef op dinsdag 15 december 2009 @ 21:56:
Zit je fileserver in een AD domein? Als dat het geval is, kun je met een lokale user nooit met een lokaal account authenticeren voor voor resources in een domein. Daar heb je een domein account voor nodig.

Als het een fileserver in een werkgroep is, kun je alleen de resources benaderen met een lokaal account wat actief is op deze fileserver, nooit lokaal op je werkstation. Wat alt-92 ook al aangaf.

Is het zo duidelijk?

Implicaties van een AD zijn me duidelijk maar dat is hier dus niet het geval. Feit is dat ik, zelfs wanneer ik met "win2008\testuser" op de shares inlog slechts leesrechten heb op de share. Als ik "win2008\testuser" specifiek per share als user toevoeg met de juiste permissies is er niets aan de hand en werkt het allemaal zoals je zou verwachten. Maar deze rechten moet 'ie ook al hebben door z'n administrators group membership.

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

bosgoed

maar ik begrijp dat dit voor 1 pc/gebruiker van toepassing is..

misschien dan toch maar per share even aangeven wat de rechten zijn.
Of je moet je server inrichten met een AD en dan gewoon als user inloggen op het domein.

Thanks Mate

dinsdag 15 december 2009 22:43

Acties:

dinsdag 15 december 2009 22:53

Topicstarter

bosgoed schreef op dinsdag 15 december 2009 @ 22:31:
maar ik begrijp dat dit voor 1 pc/gebruiker van toepassing is..

misschien dan toch maar per share even aangeven wat de rechten zijn.
Of je moet je server inrichten met een AD en dan gewoon als user inloggen op het domein.

Nee, het geldt niet voor 1 gebruiker. Alle gebruikers die op de server worden aangemaakt als lid van de administrators group hebben geen admin rechten tenzij ze als user worden toegevoegd aan de permissies van de shares. NTFS rechten kloppen zijn kloppend.

Nu is de situatie prima te overzien, maar het gaat om het feit dat lid zijn van de administrators group simpelweg niet wordt erkend over het netwerk.

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

bosgoed

Maar je draait alles in een werkgroep ipv een domein?
want in een Domein werken de rechten uitstekend!

Thanks Mate

dinsdag 15 december 2009 23:22

Acties:

dinsdag 15 december 2009 23:43

HaveBlue schreef op dinsdag 15 december 2009 @ 22:43:
[...]

Nee, het geldt niet voor 1 gebruiker. Alle gebruikers die op de server worden aangemaakt als lid van de administrators group hebben geen admin rechten tenzij ze als user worden toegevoegd aan de permissies van de shares. NTFS rechten kloppen zijn kloppend.

Nu is de situatie prima te overzien, maar het gaat om het feit dat lid zijn van de administrators group simpelweg niet wordt erkend over het netwerk.

De sAMAccountName is weliswaar gelijk, maar de SID is dat niet. Ik heb mij nog niet genoeg verdiept in SMB2 om duidelijkheid te scheppen hier over, maar de kans is groot dat daar je struikelblok ligt.

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

moppentappers

De SID's moeten (naar mijn weten) inderdaad gelijk zijn om de kunnen authentificeren met de file server. Hoewel met Windows Home Server je ook mappen alleen toegankelijk kan maken voor bepaalde gebruikersnaam/wachtwoord combinaties, maar dat zou net zo goed kunnen komen door de WHS software die op clients wordt geinstalleerd.

woensdag 16 december 2009 02:39

Acties:

Turdie

Razwer schreef op dinsdag 15 december 2009 @ 23:22:
[...]

De sAMAccountName is weliswaar gelijk, maar de SID is dat niet. Ik heb mij nog niet genoeg verdiept in SMB2 om duidelijkheid te scheppen hier over, maar de kans is groot dat daar je struikelblok ligt.

Een SID is een unieke variable waarde, dus zal die op iedere computer weer anders zijn.
Natuurlijk zijn er wel een aantal Well-Known SID'S

.

Ik vond ook nog dit:

UAC is set up to not allow access to default shares remotely. To enable, set this key in the registry
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy
0 - build filtered token (Remote UAC enabled)
1 - build elevated token (Remote UAC disabled)

[ Voor 41% gewijzigd door Turdie op 16-12-2009 03:00 ]

woensdag 16 december 2009 10:00

Acties:

woensdag 16 december 2009 13:03

shadowman12 schreef op woensdag 16 december 2009 @ 02:39:
[...]

Een SID is een unieke variable waarde, dus zal die op iedere computer weer anders zijn.

in een domein model heeft de account "piet" overal dezelfde SID. In een peer to peer omgeving waar de TS over begint zijn er dus 2 "piet" accounts met aparte SID. Dat is het grote verschil.

edit: btw, ieder heeft zijn eigen visie, maar ik zou niet op NTFS niveau gaan securen, maar op share level. NTFS gewoon op everyone full control en de share beveiligen.

[ Voor 17% gewijzigd door Razwer op 16-12-2009 10:03 ]

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

woensdag 16 december 2009 14:26

Topicstarter

Razwer schreef op woensdag 16 december 2009 @ 10:00:
[...]
in een domein model heeft de account "piet" overal dezelfde SID. In een peer to peer omgeving waar de TS over begint zijn er dus 2 "piet" accounts met aparte SID. Dat is het grote verschil.

edit: btw, ieder heeft zijn eigen visie, maar ik zou niet op NTFS niveau gaan securen, maar op share level. NTFS gewoon op everyone full control en de share beveiligen.

Het is inderdaad zo dat er twee "piet" accounts zijn (werkstation: "win7\testuser" én server: "win2008\testuser"). Maar ook wanneer je op een werkstation ingelogd bent met gebruikersaccount bijvoorbeeld "win7\anderegebruiker" en je logt in op de share met gebruikersaccount "win2008\testuser" is het zo dat je alleen read rechten hebt op de share, ondanks dat administrators group membership, NTFS-rechten én share-rechten je full control zouden moeten geven.

De manier van securen is nu niet relevant; zowel share- als NTFS permissies staan voor de relevante shares op full control. Wanneer ik dit probleem achter me heb gelaten spijker ik de boel dicht.

[ Voor 4% gewijzigd door HaveBlue op 18-12-2009 12:44 ]

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

woensdag 16 december 2009 15:15

alt-92 schreef op dinsdag 08 december 2009 @ 21:31:
Dat je met een zelfde username/password combinatie met pre-7 operating systems bij andermans spullen kon komen heeft puur te maken met backwards compat aangaande het logon mechanisme (NTLMv2 preferred).

Heb je dit stuk van alt-92 wel gelezen? Group membership gaan niet op sAMAccountName maar op SID. Je SID van je gebruiker is anders omdat je een workgroup model gebruikt. Waarschijnlijk moet je forceren een ander security protocol te gebruiken zodat hij de legacy manier gebruikt en je dus wel toelaat op group membership.
win 7 <--> server 2008R2 praten by default die 128bits encryptie.

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

woensdag 16 december 2009 15:31

ye olde farte

Afbeeldingslocatie: http://tweakers.net/ext/f/c8nKqtaDzhWt5PJtm51H8IyZ/full.png

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device

Acties:

KillerAce_NL

If it ain't broke...

Events op client en server al nagelopen ?
@Alt92: Ik kan me vergissen maar volgens mij postte de TS al dat ie authenticeert met server\user.

Ik begrijp uit zijn posts dat hij een standalone pc heeft en een server in zijn eigen workgroup.
Authenticeren werkt wel op de correcte manier, maar alleen als hij die testuser expliciet share ne ntfs rechten geeft. Als hij rechten uitdeelt aan de groep administrators en die user toevoegt aan de groep administrators dan werkt het NIET.

[ Voor 59% gewijzigd door KillerAce_NL op 16-12-2009 15:36 ]

woensdag 16 december 2009 15:50

Acties:

woensdag 16 december 2009 17:51

Topicstarter

Razwer schreef op woensdag 16 december 2009 @ 14:26:
[...]
Heb je dit stuk van alt-92 wel gelezen? Group membership gaan niet op sAMAccountName maar op SID. Je SID van je gebruiker is anders omdat je een workgroup model gebruikt. Waarschijnlijk moet je forceren een ander security protocol te gebruiken zodat hij de legacy manier gebruikt en je dus wel toelaat op group membership.
win 7 <--> server 2008R2 praten by default die 128bits encryptie.

Ja, gelezen en wat alt-92 zei was me al bekend. Maar de username en password voor beide gebruikers waren op dat moment voor het gemak hetzelfde. Met een andere gebruikersnaam inloggen lost het probleem niet op.

alt-92 schreef op woensdag 16 december 2009 @ 15:15:
[afbeelding]

Precies het plaatje zoals het er hier bij staat

KillerAce_NL schreef op woensdag 16 december 2009 @ 15:31:
Events op client en server al nagelopen ?

Ja. Geen onregelmatigheden.

@Alt92: Ik kan me vergissen maar volgens mij postte de TS al dat ie authenticeert met server\user.

Klopt

Ik begrijp uit zijn posts dat hij een standalone pc heeft en een server in zijn eigen workgroup.
Authenticeren werkt wel op de correcte manier, maar alleen als hij die testuser expliciet share ne ntfs rechten geeft. Als hij rechten uitdeelt aan de groep administrators en die user toevoegt aan de groep administrators dan werkt het NIET.

Dat is niet het hele verhaal, gaat namelijk niet om één standalone PC maar om account(s) die via het netwerk geen full control hebben terwijl ze dat op basis van hun grouprechten wel zouden moeten hebben. De rest van je verhaal klopt

[ Voor 45% gewijzigd door HaveBlue op 16-12-2009 17:11 ]

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

woensdag 16 december 2009 18:42

in dat geval even de feiten vast stellen:
lokaal inloggen == alles werkt prima
netwerk inloggen == werkt prima behalve vanaf windows 7? of je hebt alleen windows 7 geprobeert en daar werkt het niet?
NTFS == everyone full control
share == groep = full control?
bevestig aub en/of vul aan.

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

woensdag 16 december 2009 18:43

Topicstarter

Razwer schreef op woensdag 16 december 2009 @ 17:51:
in dat geval even de feiten vast stellen:

lokaal inloggen == alles werkt prima

netwerk inloggen == werkt prima behalve vanaf windows 7? of je hebt alleen windows 7 geprobeert en daar werkt het niet?
Alle PC's zijn voorzien van Windows 7 of Mac OS X. Heb het nog niet geprobeerd met Windows XP. Kan binnenkort een VM maken om te testen maar het is toch vreemd dat een probleem van deze aard bestaat tussen 2 OS'en die "voor elkaar gemaakt" zijn.

NTFS == everyone full control

share == groep = full control

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

woensdag 16 december 2009 19:09

kwestie van eliminatie. Test het vanaf XP. Werkt het dan WEL, ligt het aan je client. Werkt het dan NIET ligt het aan je server, waarschijnlijk ergens in de share permissions.

oh en sterker nog, 2008R2 == windows 7 x64. zelfde kernel in essentie

als je een cmd opent op beiden, zie je dezelfde windows versie staan.

[ Voor 29% gewijzigd door Razwer op 16-12-2009 18:44 ]

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

donderdag 17 december 2009 12:20

Topicstarter

Razwer schreef op woensdag 16 december 2009 @ 18:43:
kwestie van eliminatie. Test het vanaf XP. Werkt het dan WEL, ligt het aan je client. Werkt het dan NIET ligt het aan je server, waarschijnlijk ergens in de share permissions.

oh en sterker nog, 2008R2 == windows 7 x64. zelfde kernel in essentie als je een cmd opent op beiden, zie je dezelfde windows versie staan.

Ik heb een Windows Server 2003 R2 Standard VM tot m'n beschikking. Zal eens testen

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

donderdag 17 december 2009 13:23

Topicstarter

Probleem bestaat ook bij Windows XP/Windows Server 2003

Je zou bijna denken dat het 'by-design-behaviour' is. Heb de security policies op de server nagelopen en op het eerste oog niets kunnen vinden maar moet ook toegeven dat dat voor mij grijs gebied is

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

donderdag 17 december 2009 13:35

dan ligt het aan je share permissions of de security afhandeling daar van.
hoe heb je de share aangemaakt? via de sharing wizzard? of oldschool?

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

donderdag 17 december 2009 13:47

Topicstarter

Razwer schreef op donderdag 17 december 2009 @ 13:23:
dan ligt het aan je share permissions of de security afhandeling daar van.
hoe heb je de share aangemaakt? via de sharing wizzard? of oldschool?

Moet eigenlijk wel de security afhandeling zijn. Rechten kloppen.

Heb via de Server Manager een share ge-provisioned en daarmee zowel de NTFS als de SHARE rechten ingesteld. Probleem bestaat ook bij een virtuele testbak (met out-of-the-box install) dus het kan bijna niet aan de installatie liggen.

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

Gé Brander

MS SQL Server

Ok, inkoppertje misschien, maar heb je de share wizard gebruikt of heb je via de advanced share knop een share gemaakt? Ik denk zomaar even dat je share permissies verkeerd staan?

Dus, hoe zijn je share permissies en hoe zijn je ntfs permissies, kan je dat even aangeven?

Vroeger was alles beter... Geniet dan maar van vandaag, morgen is alles nog slechter!

donderdag 17 december 2009 13:54

Acties:

donderdag 17 december 2009 16:37

HaveBlue schreef op donderdag 17 december 2009 @ 13:35:
[...]

Moet eigenlijk wel de security afhandeling zijn. Rechten kloppen.

Heb via de Server Manager een share ge-provisioned en daarmee zowel de NTFS als de SHARE rechten ingesteld. Probleem bestaat ook bij een virtuele testbak (met out-of-the-box install) dus het kan bijna niet aan de installatie liggen.

probeer het eens op de oude handmatige manier...

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

donderdag 17 december 2009 17:35

Topicstarter

c70070540 schreef op donderdag 17 december 2009 @ 13:47:
Ok, inkoppertje misschien, maar heb je de share wizard gebruikt of heb je via de advanced share knop een share gemaakt? Ik denk zomaar even dat je share permissies verkeerd staan?

Dus, hoe zijn je share permissies en hoe zijn je ntfs permissies, kan je dat even aangeven?

De permissies staan niet verkeerd

SHARE: full control voor "win2008\administrators"
NTFS: full control voor "win2008\adminstrators"
Bestanden op de share hebben "win2008\administrators" als owner.

Desalniettemin hebben users uit de "win2008\administrators" group feitelijk alleen read rechten op deze share/bestanden.

Razwer schreef op donderdag 17 december 2009 @ 13:54:
[...]
probeer het eens op de oude handmatige manier...

Gedaan. SubInACL.exe geeft in beide gevallen dezelfde output

code:

C:\Program Files (x86)\Windows Resource Kits\Tools>subinacl /share unsorted

================
+Share unsorted
================
/control=0x0
/audit ace count   =0
/perm. ace count   =2
/pace =everyone         ACCESS_ALLOWED_ACE_TYPE-0x0
        Read
/pace =win2008\administrators  ACCESS_ALLOWED_ACE_TYPE-0x0
        Full Control


Elapsed Time: 00 00:00:00
Done:        1, Modified        0, Failed        0, Syntax errors        0
Last Done  : unsorted

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

donderdag 17 december 2009 17:46

als ik tijd heb (heb het redelijk druk) zal ik proberen je setup na te bouwen... want er moet toch echt iets niet goed staan...

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

Gé Brander

MS SQL Server

Het staat er toch duidelijk, everyone READ acces en windows2008\administrators FULL access...

Als iemand (je lokale user account van je windows 7) probeert te connecten, dan is het volgens mij normaal dat de Least Most Restrictive Rights boven de FULL controll gaat... Omdat dat account nooit in de windows2008\administrators group kan zitten...

Of mis ik nou wat aan je verhaal?

Vroeger was alles beter... Geniet dan maar van vandaag, morgen is alles nog slechter!

donderdag 17 december 2009 20:51

Acties:

donderdag 17 december 2009 23:48

Topicstarter

Razwer schreef op donderdag 17 december 2009 @ 17:35:
als ik tijd heb (heb het redelijk druk) zal ik proberen je setup na te bouwen... want er moet toch echt iets niet goed staan...

Ik heb het ook te druk om er echt eens een middag voor te gaan zitten en alles tot de bodem uit te pluizen maar ik zou het een 'geruststelling' vinden als jij het gedrag kunt reproduceren $_/-\o_$

c70070540 schreef op donderdag 17 december 2009 @ 17:46:
Het staat er toch duidelijk, everyone READ acces en windows2008\administrators FULL access...

Als iemand (je lokale user account van je windows 7) probeert te connecten, dan is het volgens mij normaal dat de Least Most Restrictive Rights boven de FULL controll gaat... Omdat dat account nooit in de windows2008\administrators group kan zitten...

Of mis ik nou wat aan je verhaal?

Het lokale windows 7 account probeert *niet* te connecten. Het inloggen gebeurt dus niet als "win7\testuser" maar als "win2008\testuser".

Wanneer ik "everyone" read access geef én de specifieke gebruiker "win2008\testuser" full control geef werkt het wel. Als "win2008\administrator" inloggen terwijl "everyone" read rechten geeft óók full control en deze account is 100% zeker lid van de "win2008\administrators" group

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

Yalopa

Less is more!

Ik denk dat het al 2 keer gezegd is maar je hebt het volgens mij nog niet opgepikt,

Zet je SHARE permissies op everyone:full control
Zet je NTFS permissies zoals je ze wil hebben, deze bepaald de effectieve rechten..

Test opnieuw..

Owja, normale users behoeven geen admin rechten, al helemaal niet op een server

[ Voor 14% gewijzigd door Yalopa op 17-12-2009 23:49 ]

You don't need eyes to see, you need vision

vrijdag 18 december 2009 08:51

Acties:

vrijdag 18 december 2009 09:39

Yalopa schreef op donderdag 17 december 2009 @ 23:48:
Ik denk dat het al 2 keer gezegd is maar je hebt het volgens mij nog niet opgepikt,

Zet je SHARE permissies op everyone:full control
Zet je NTFS permissies zoals je ze wil hebben, deze bepaald de effectieve rechten..

Test opnieuw..

Owja, normale users behoeven geen admin rechten, al helemaal niet op een server

waarom zou dit wel moeten werken en als je andersom secured niet? de logica hier van ontgaat mij.

persoonlijk ben ik geen fan van gepruts op NTFS niveau en secure ik liever op share level. NTFS securen is naar mijn mening voor department share achtige zaken. Maargoed, iedereen heeft zijn eigen visie...

en of users nu wel of niet admin moeten hebben; het gaat hier om een proof of concept wat gewoon moet werken.

[ Voor 7% gewijzigd door Razwer op 18-12-2009 08:52 ]

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

vrijdag 18 december 2009 11:00

Topicstarter

Yalopa schreef op donderdag 17 december 2009 @ 23:48:
Ik denk dat het al 2 keer gezegd is maar je hebt het volgens mij nog niet opgepikt,

Zet je SHARE permissies op everyone:full control
Zet je NTFS permissies zoals je ze wil hebben, deze bepaald de effectieve rechten..

Test opnieuw..

Owja, normale users behoeven geen admin rechten, al helemaal niet op een server

Ik zie geen nut van dichttimmeren op NTFS niveau tenzij voor lokaal gebruik. Als dat de gangbare manier zou zijn is het nut van share rechten toch discutabel

Enfin, zoals hierboven al enkele malen gemeld: met NTFS én SHARE rechten op full control heeft de user wél full control maar de group níet.

Daarnaast, de normale users hebben geen admin rechten. De admins uiteraard wél. Weet niet waar je vandaan haalt dat de normale users admin rechten hebben?

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

vrijdag 18 december 2009 12:10

Topicstarter

Ik heb het (deels) opgelost. Dat wil zeggen: ik hoef niet meer per user de permissies in te stellen. Oplossing was uiteindelijk het aanmaken van een nieuwe groep ("win2008\network administrators") en deze de juiste permissies op de shares te geven. Gek genoeg is de output van subinacl.exe hetzelfde als wanneer je de users member maakt van "win2008\administrators":

code:

C:\Users\Administrator>subinacl /share unsorted

================
+Share unsorted
================
/control=0x0
/audit ace count   =0
/perm. ace count   =2
/pace =everyone         ACCESS_ALLOWED_ACE_TYPE-0x0
        Read
/pace =win2008\network administrators   ACCESS_ALLOWED_ACE_TYPE-0x0
        Full Control


Elapsed Time: 00 00:00:00
Done:        1, Modified        0, Failed        0, Syntax errors        0
Last Done  : unsorted

Ik begrijp hier werkelijk geen snars van

Behandelt Windows 2008 de "administrators" onder water anders dan een handmatig aangemaakte groep met dezelfde permissies

[ Voor 9% gewijzigd door HaveBlue op 18-12-2009 11:14 ]

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

Gé Brander

MS SQL Server

HaveBlue schreef op vrijdag 18 december 2009 @ 09:39:
[...]

Ik zie geen nut van dichttimmeren op NTFS niveau tenzij voor lokaal gebruik. Als dat de gangbare manier zou zijn is het nut van share rechten toch discutabel

Enfin, zoals hierboven al enkele malen gemeld: met NTFS én SHARE rechten op full control heeft de user wél full control maar de group níet.

Daarnaast, de normale users hebben geen admin rechten. De admins uiteraard wél. Weet niet waar je vandaan haalt dat de normale users admin rechten hebben?

Sorry, maar voor jou is je probleem omschrijving misschien duidelijk, maar ik ben je weer helemaal kwijt.

Kan je eens even in een tabel zetten hoe je voor de groep de share en ntfs rechten hebt staan, wat er wel/niet lukt en voor de losse account de share en ntfs rechten hebt staan en wat er wel/niet lukt.

Misschien is het ook handig een kolom toe te voegen wat je verwacht.

Vroeger was alles beter... Geniet dan maar van vandaag, morgen is alles nog slechter!

vrijdag 18 december 2009 12:35

Acties:

vrijdag 18 december 2009 12:50

Topicstarter

c70070540 schreef op vrijdag 18 december 2009 @ 12:10:
[...]

Sorry, maar voor jou is je probleem omschrijving misschien duidelijk, maar ik ben je weer helemaal kwijt.

Kan je eens even in een tabel zetten hoe je voor de groep de share en ntfs rechten hebt staan, wat er wel/niet lukt en voor de losse account de share en ntfs rechten hebt staan en wat er wel/niet lukt.

Misschien is het ook handig een kolom toe te voegen wat je verwacht.

Zo houden we elkaar wel aan het werk

Ik heb de openingspost aangepast zodat deze duidelijk is voor een ieder die in de toekomst tegen het probleem aan loopt. De 'oplossing' voor mij (= aanmaken van nieuwe group met relevante admin rechten) is hierboven ook gegeven. De oplossing is in mijn geval ook reproduceerbaar tussen 2 VM's dus ik ga ervan uit dat iemand die in de toekomst dit probleem heeft hiermee ook geholpen is

Iedereen dank voor de tijd en het meedenken $_/-\o_$

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

vrijdag 18 december 2009 13:10

ye olde farte

HaveBlue schreef op vrijdag 18 december 2009 @ 09:39:

Ik zie geen nut van dichttimmeren op NTFS niveau tenzij voor lokaal gebruik. Als dat de gangbare manier zou zijn is het nut van share rechten toch discutabel

Het is een gangbare manier van provisioning van shares en de bijbehorende Folders.
Het enige wat je in feite zegt met share permissies Everyone=FC is dat je alles overlaat aan het onderliggende filesystem security.

NTFS ACLs bieden je nou eenmaal wat meer opties dan share ACLs omdat share permissies alleen maar vanaf dat éne nivo(en recursief) werken.

Nergens staat bij wet(matigheid) vastgelegd dat "Gij Zult Uwen Sharepermissies op EveryoneFC houden".
Mag je zelf weten of je dat wel of niet doet.
In grotere omgevingen is het wat gebruikelijker om enkel NTFS ACLs op een gecontroleerde manier in te zetten omdat dat nou eenmaal gebleken is qua onderhoud minder kwetsbaar voor dikke vingers te zijn.

Case in point is jouw verhaal:
Share = FC
NTFS = Groep_met_RW/RO/FC

In principe hoef je dan alleen naar je NTFS ACLs te kijken als je op een of ander manier geen toegang krijgt.

Maar de grootste 'denkfout' die er nu gemaakt is is imho het inzetten van de BuiltIn groepen voor dit soort zaken, en laten dat nou net de security principals zijn waar je zelf het minste aan wil wijzigen of zelfs kan wijzigen.

[ Voor 8% gewijzigd door alt-92 op 18-12-2009 12:54 ]

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device

Acties:

vrijdag 18 december 2009 13:18

@alt92, ik ben het volledig met je eens, maar hoe dan ook zou het in theorie wel moeten werken wat hij wil.

Newton's 3rd law of motion. Amateur moraalridder.

Acties:

vrijdag 18 december 2009 17:39

ye olde farte

Nee, want doordat je BuiltIn groups en accounts gaat inzetten krijg je met alle onverwachte en rare features te maken die als extra drempels (UAC met missing tokens) zijn opgegooid.

Ik geef ook niet voor niks aan (datgene wat uiteindelijk ook werkt) dat je een eigen groep moet gebruiken daarvoor en niet een Well-Known SID moet (mis)bruiken.

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device

Acties:

vrijdag 18 december 2009 20:04

Topicstarter

alt-92 schreef op vrijdag 18 december 2009 @ 13:18:
Nee, want doordat je BuiltIn groups en accounts gaat inzetten krijg je met alle onverwachte en rare features te maken die als extra drempels (UAC met missing tokens) zijn opgegooid.

Welke onverwachte features

Als dit by-design behaviour is moeten dit soort dingen moeten toch gewoon gedocumenteerd zijn

Heb net nog eens gezocht op Technet en Google Groups maar dit probleem komt of 1.) nergens anders voor of 2.) is gedocumenteerd maar ik kan het niet vinden. Ik kan me niet voorstellen dat er geen andere 'prosumer' gebruikers zijn die in een workgroup scenario de standaard "users" en "administrators" groups van dag tot dag gebruiken

Los daarvan kan ik me wel voorstellen dat het gebruik van non-built-in groups voor shares vanuit beveiligings- of compliancy oogpunt in het bedrijfsleven een best practice is

Ik geef ook niet voor niks aan (datgene wat uiteindelijk ook werkt) dat je een eigen groep moet gebruiken daarvoor en niet een Well-Known SID moet (mis)bruiken.

Ik zal erover heen lezen maar waar geef je dat aan

[ Voor 26% gewijzigd door HaveBlue op 18-12-2009 19:08 ]

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

vrijdag 18 december 2009 20:45

ye olde farte

Wil je nu zeggen dat UAC en token filtering ongedocumenteerd is?

ik heb een 864 GB floppydrive! - certified prutser - the social skills of a thermonuclear device

Acties:

vrijdag 18 december 2009 20:55

Topicstarter

alt-92 schreef op vrijdag 18 december 2009 @ 20:04:
Wil je nu zeggen dat UAC en token filtering ongedocumenteerd is?

Nee, dat zeg ik niet. Maar als dit een feature is zou je denken dat ook de implicaties voor file sharing ergens worden beschreven. En dat staat het met een omweg ook:

http://msdn.microsoft.com.../aa826699%28VS.85%29.aspx

Het document rept over de manier waarop een script wordt gedraaid maar het concept zal voor andere remote connections niet anders zijn. Interessante materie wel. Thanks, was ik zelf niet op gekomen $_/-\o_$

"So the whole basis for jazz music is based on the fact that the bass player could not play his instrument." - Miroslav Vitous

Acties:

sanfranjake

Computers can do that?

Dit is een nieuwe feature van Windows Vista en hoger, maar zou je uit kunnen zetten:
Description of User Account Control and remote restrictions in Windows Vista

edit:
had wel even f5 mogen drukken

[ Voor 17% gewijzigd door sanfranjake op 18-12-2009 20:56 ]

Mijn spoorwegfotografie
Somda - Voor en door treinenspotters

vrijdag 18 december 2009 21:15

Acties:

brid

Onze excuses voor het ongemak

Dat is er weer 1 om te onthouden

DIY NAS, Hoofd PC
Unchain your pc/laptop, buy a SSD!!!!!

vrijdag 18 december 2009 21:16

Acties: