[Win2003]SFC beinvloeden om dcpromo.exe weg te laten *

[Verwijderd]

Naar aanleiding van [rml][ WIN2K] File Protection tip[/rml]

We zijn hier aan het testen met 2003, maar vinden geen oplossing voor onderstaande.
Ik wil zorgen dat DCPROMO.EXE niet meer uitvoerbaar is, maar die SFC blijft hem maar terugzetten. Na een search kwam ik op bovenstaande, maar deze blijken allemaal niet te werken voor Win2003.
Hoe kan ik dit nu omzeilen? Ik wil liefst SFC niet volledig uitschakelen. Als dit toch niet anders kan en ik SFC wel volledig moet uitzetten, heeft dit dan zware implicaties?

[momania]

Titel even wat duidelijker gemaakt

[Verwijderd]

Godver :-)
Ik begin dus telkens aan een titel en vergeet hem dan volledig te zetten.
Wederom mijn oprechte excuses, ik heb meer koffie nodig

[momania]

Hier iig settings om het een en ander in de registry aan te passen:

quote: http://www.microsoft.com/...x#XSLTsection130121120120

Additional Registry Settings
All registry settings for WFP/System File Checker are located in HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Winlogon. By default, only Administrators and System will be able to modify these settings.


SFCDisable (REG_DWORD)


0 = enabled (default).
1 = disabled, prompt at boot to re-enable (debugger required).
2 = disabled at next boot only, no prompt to re-enable (debugger required).


SFCScan (REG_DWORD)
0 = do not scan protected files at boot (default).
1 = scan protected files at every boot.
2 = scan protected files once.

SFCQuota (REG_DWORD)
n = size (in megabytes) of dllcache quota.
FFFFFFFF = cache-protected system files on the local hard drive.

SFCShowProgress (REG_DWORD)
0 = System File Checker progress meter is not displayed.
1 = System File Checker progress meter is displayed (default).

SFCDllCacheDir (REG_EXPAND_SZ)
Path = local location of dllcache directory (default is %Systemroot%\system32\dllcache).

[elevator]

Als het je overigens puur erom gaat dat die file niet toegankelijk is, zou je een "Deny" ACL voor Everyone kunnen zetten.

[stylezzz99]

Verwijder de file eens in "C:\*\system32\dllcache" en daarna in "C:\*\system32". kijken of dit werkt. Als de file niet in de system32 dir zit zoek dan eens met geavanceerde opties naar dit bestand als het goed vind je hem twee of drie keer.

Eventueel als je niets vindt:
Zorg wel dat je alle verborgen bestanden in kan zien, ook de Windows beveiligde, via Windows Verkenner -> extra -> mapopties -> weergave -> geavanceerde instellingen. Loop het rijtje even af, je snapt het wel en anders vraag je het even .

Hoopt dat het werkt. Weet je zeker dat dit bestand weg kan???

Download XP lite om de file protection uit te zetten, de tip hiervoor hierboven werkt niet aangezien er een nieuwe moeilijke tweak nodig is om het zelfde te bereiken dan voor heen bij Windows 2000. Daar was het makkelijker en werkte de register tweak wel. Bij de versies vanaf XP SP1 niet meer! Nieuwe beveiligingsinstellingen.

[ Voor 33% gewijzigd door stylezzz99 op 06-11-2003 15:28 ]

[mutsje]

DCPromo is uberhaupt alleen uitvoerbaar door mensen die lid zijn van Enterprise Administrators group en administrators group. Waar zou je in godsnaam aan een server gaan lopen tweaken als je basic security nog niet in orde is. Als je eerst zorgt dat basic security in orde is. Dan kun je rustig die server gelocked laten staan want normale users kunnen er toch niet op in loggen...

[Verwijderd]

We hebben er een Deny ACL op gezet, en dat is idd genoeg.
Bij het verwijderen uit de dllcache bleef ie mekkeren achter het netwerkpath of de cd, tot ik sfc volledig uitschakel. En dat gaan we dus niet doen.

En @ Mutsje:

De reden is tamelijk simpel: Iemand met admin-rechten die graag experimenteert, maar er weinig van afweet. En de admin-rechten zijn nu eenmaal om bepaalde management-redenen niet af te nemen. Maw: het is iemand in de beheerders-groep, maar niet langs de windows-kant. We willen dan ook enkele voor-de-hand-liggende zaken afschermen.
En de security audit is volop bezig, maar je kan nu eenmaal niet alles tegelijk in orde hebben... spijtig genoeg.

[mutsje]

Hier kan ik je dan alleen maar gelijk in geven Jay Jay. Let alleen wel op dat je documenteerd waar je Acces is Denied zet omdat dit alles overruled.

[Verwijderd]

Verwijderd schreef op 07 november 2003 @ 09:33:
En @ Mutsje:

De reden is tamelijk simpel: Iemand met admin-rechten die graag experimenteert, maar er weinig van afweet. En de admin-rechten zijn nu eenmaal om bepaalde management-redenen niet af te nemen. Maw: het is iemand in de beheerders-groep, maar niet langs de windows-kant. We willen dan ook enkele voor-de-hand-liggende zaken afschermen.
En de security audit is volop bezig, maar je kan nu eenmaal niet alles tegelijk in orde hebben... spijtig genoeg.

Dan maak je toch voor elke administratieve taak een speciale groep met rechten? Zo kun je per user rechten toekennen door gewoon groepen toe te voegen, bijvoorbeeld de groep "Server Rebooters", "Backup Operators", "Account Operators", "Pagefile Creators" of "Local Workstation Administrators". Zo hoef je iemand geen volledige admin rechten toe te kennen, maar toch heeft hij voor zijn functie rechten om te kunnen beheren.

[Verwijderd]

Momenteel is dat allemaal dubbel en onnodig werk voordat de migratie naar 2003 rond is. En het enige punt is dat ze momenteel voor de test-memberservers niet voor de grap Dcpromo gaan draaien want ik denk dat onze NT4 - domeincontrollers dat niet zo graag gaan hebben. Aangezien er al zoveel werk in de migratie steekt heb ik, noch mijn collega zin om voor het bestaande platform de hele security te gaan omschroeven om dit en soortgelijke zaken nu te voorkomen. Daar hebben we simpelweg de tijd en de middelen niet voor en zal moeten wachten. Als de tijd er rijp voor is zal ook de herziening wel komen op het gebied van security en auditing. Het is dus niet van niet willen, noch van niet kunnen, eerder van niet in de tijdsplanning vallen.

[mutsje]

Wat je imho het beste kunt doen om te kijken of een migratie goed verloopt is gewoon een nt4 bdc installeren, deze lostrekken van het domain dan uppen naar PDC. (zodat je alle users & dergelijke hebt) Dan gewoon de 2003 cd-rom erin en upgraden dit heb ik inmiddels 2x getest en ik ga het ook gewoon keihard zo uitvoeren op het moment dat ik het JA woordt van het MT krijg. Werkte tijdens de test prima en alle users krijgen keurig 2 namen (oude en nieuwe) wat tijdens een migratie normaal is.

[ArCadE]

Verwijderd schreef op 07 november 2003 @ 10:42:

En het enige punt is dat ze momenteel voor de test-memberservers niet voor de grap Dcpromo gaan draaien want ik denk dat onze NT4 - domeincontrollers dat niet zo graag gaan hebben.

Hm, dus jij draait test in een produktieomgeving... lijkt met niet zo heel verstandig...

En waarom zouden de nt4 controller dat niet zo graag hebben? In mixed mode is er niets aan de hand lijkt me.... Security is zo te zien geen belangrijke issue bij jullie ...

[ Voor 63% gewijzigd door ArCadE op 07-11-2003 11:39 . Reden: edit ]

[Verwijderd]

Gezien ieder's reacties lijkt mij de beste oplossing om DCPROMO.EXE bij de denied programs te knallen. Alleen als een admin kwade bedoelingen heeft dan zal hij de policy gewoon verwijderen en DCPROMO.EXE uitvoeren.

Zodra de testomgeving als productieomgeving wordt uitgerold, dan plaats je alle groepen, en dan verwijder je de policy weer

[mutsje]

een testomgeving als productie omgeving uitrollen is wel erg ondoordacht om eerlijk te zijn. Je loopt te testen toevoegen verwijderen wordt brakker en dan als productie promoten . Imho is een testomgeving om te testen hoe je een productie omgeving goed om kunt zetten naar een nieuw operating system.

[Verwijderd]

Degene waar we dit van willen beschermen kennen niets van policy's. Het gaat er gewoon om dat ze niet op dat exe'tje kunnen klikken :-)

En effe overlopen want ik krijg hier vanalles naar mijn kop:

2003 draait niet als TEST in de productieomgeving. Er draaien gewoon al een aantal MEMBER-servers op 2003, zoals de AV-server, de printserver,....
Daarbuiten gaan we, aangezien de geringe grootte van onze omgeving hoogstwaarschijnlijk niet upgraden, maar met een schone lei proberen te beginnen.
En nog eens daarbuiten, op gebied van security hangen sommige dochterondernemingen nu eenmaal vast aan het beleid van hogerhand, en hoewel we dat graag zouden willen, zullen sommige dingen niet rap doorgevoerd worden.

En van die mixed-mode... sorry hoor, maar zo maar ineens een dcpromo doen, met daarbij dus de activatie van Active-dir zou hier rampzalig aflopen, omwille van de complexe structuur van trusts waar wij mee samenhangen naar boven toe :-)

[luckyme_]

ArCadE schreef op 07 november 2003 @ 11:36:
[...]
En waarom zouden de nt4 controller dat niet zo graag hebben? In mixed mode is er niets aan de hand lijkt me....

Als je die 2k dc in hetzelfde domein hangt zal de NT4 PDC daar toch heel anders over denken hoor......

[Verwijderd]

Ik denk eerder dat onze pdc dan helemaal niet meer denkt

[Verwijderd]

Verwijderd schreef op 07 november 2003 @ 12:03:
Degene waar we dit van willen beschermen kennen niets van policy's. Het gaat er gewoon om dat ze niet op dat exe'tje kunnen klikken

In dat geval is de Restricted Programs List de beste uitkomst

[Verwijderd]

Verwijderd schreef op 07 november 2003 @ 12:03:
Degene waar we dit van willen beschermen kennen niets van policy's. Het gaat er gewoon om dat ze niet op dat exe'tje kunnen klikken :-)

en die nono's hebben administrator rechten op het domain? zo niet, dan kunnen ze het zowieso niet runnen

[Verwijderd]

Ze hebben dit inderdaad, ze zijn beheerder van de andere omgevingen zoals oa as/400. En zoals vermeld kan ik niet zomaar hun domain-admin rechten afpakken.

[mutsje]

Verwijderd schreef op 07 november 2003 @ 12:03:
Degene waar we dit van willen beschermen kennen niets van policy's. Het gaat er gewoon om dat ze niet op dat exe'tje kunnen klikken :-)

En effe overlopen want ik krijg hier vanalles naar mijn kop:

2003 draait niet als TEST in de productieomgeving. Er draaien gewoon al een aantal MEMBER-servers op 2003, zoals de AV-server, de printserver,....
Daarbuiten gaan we, aangezien de geringe grootte van onze omgeving hoogstwaarschijnlijk niet upgraden, maar met een schone lei proberen te beginnen.
En nog eens daarbuiten, op gebied van security hangen sommige dochterondernemingen nu eenmaal vast aan het beleid van hogerhand, en hoewel we dat graag zouden willen, zullen sommige dingen niet rap doorgevoerd worden.

En van die mixed-mode... sorry hoor, maar zo maar ineens een dcpromo doen, met daarbij dus de activatie van Active-dir zou hier rampzalig aflopen, omwille van de complexe structuur van trusts waar wij mee samenhangen naar boven toe :-)

Je moet natuurlijk wel kijken waar jij je ROOT domain controllers neer gaat zetten en de rest van de sites kun je gewoon working domain controllers met working global catalog servers maken (dus sites). Heb je niet eens meer trusts nodig maar krijg je een mooie transparante omgeving. In Exchange 2003 ga je dan Universal Distribution Lists of nog beter Query-bases Distribution Lists gebruiken(ook universal).

[Verwijderd]

Met een totaal van 200 pc's en 30 servers gaan wij niet veel te zeggen hebben in een organisatie met meer dan 55000 client's en enkele duizenden servers.
Wij zijn ons al zelfstandig aan het voorbereiden, in afwachting van "the big company" zodat we zeker niet van de een op de andere dag gaan te horen krijgen: voila, maak maar dat je op 2003 zit.
Maar de globale structuur staat nog helemaal niet vast. Wij zijn dus alle member servers al op 2003 aan het zetten, en onze templates klaar aan het maken, zodat we, vanaf het moment dat we groen licht en richtlijnen krijgen, toch al het grootste gedeelte achter de rug hebben.
Nuja, ik moet zelf ook nog eerst op cursus vertrekken, want mijn eigen active-directory kennis is momenteel nog net ietsje te laag

[ArCadE]

Verwijderd schreef op 07 november 2003 @ 13:17:
Ze hebben dit inderdaad, ze zijn beheerder van de andere omgevingen zoals oa as/400. En zoals vermeld kan ik niet zomaar hun domain-admin rechten afpakken.

Hm, toevallig ook een OS/390 omgeving? Zeker tivoli ook draaien? In dat geval kunnen ze vanaf de OS/390 omgeving vanalles doen zonder Admin te zijn op het NT4 domein....

[bolke]

Verwijderd schreef op 07 november 2003 @ 11:40:
Gezien ieder's reacties lijkt mij de beste oplossing om DCPROMO.EXE bij de denied programs te knallen. Alleen als een admin kwade bedoelingen heeft dan zal hij de policy gewoon verwijderen en DCPROMO.EXE uitvoeren.

Zodra de testomgeving als productieomgeving wordt uitgerold, dan plaats je alle groepen, en dan verwijder je de policy weer

Verwijderd schreef op 07 november 2003 @ 12:24:
[...]
In dat geval is de Restricted Programs List de beste uitkomst

En dan kijken of dit nog werkt:
Start - run
tiep in CMD en druk op OK
op de command prompt even DCPROMO.EXE intypen....

Klein bugje is Windows.

[ Voor 14% gewijzigd door bolke op 09-11-2003 21:00 ]

[Verwijderd]

Okee, we zijn eruit
Bedankt allemaal voor het advies.