Share access problemen na disablen van SMB signing op W2k3

[Tranzy]

Daar wij al een langere tijd last hebben van traagheid op ons SBS 2003 systeem heb ik meerdere artikelen gelezen waarin aangeraden wordt om SMB signing te disablen.

Ik heb via Group Policy Management op de SBS 2003 server het volgende gedaan:

To fix this problem three steps are involved:

Disable SMB policies in the 'Default Domain Controller Policy".
Disable SMB policies in the 'Default Domain Policy'.
Apply the policies to the server and the workstations.
The four settings in each policy are:

Microsoft Network server: Digitally sign communications (always)---> Disable
Microsoft Network server: Digitally sign communications (if client agrees)---> Disable
Microsoft Network client: Digitally sign communications (always)---> Disable
Microsoft Network client: Digitally sign communications (if server agrees)---> Disable

Daarna heb ik een gpupdate /force gedaan op de server.

Nu deed zich het volgende voor vanmorgen. Een drie tal werkstations (de laatste W2k) en één XP werkstation kunnen niet meer bij de shares komen.

Ik krijg ook een Access Denied op de server als ik de betreffende policies aanklik.

Ik heb de server nog niet ge-reboot (denk dat dat de oplossing zou kunnen zijn) omdat ik bang ben dat ik misschien meer problemen zal krijgen.

Ik heb gelezen dat ik de server misschien wel 2 keer zou moeten herstarten om de policies werkend te krijgen.

With these steps completed, you can now reboot computers to make the changes take affect. Note, because these group policies are applied to computers and network bindings, you will have to reboot the Server Twice because it cannot read AD policies to impact network conditions because the AD isn't started until the network section is already operating. You can avoid the need for two reboots by using the SECEDIT command to rush the policy.

Op een andere site staat het iets anders uitgelegd maar hebben ze het niet over rebooten. Zeker niet 2 keer.

terugdraaien van de wijzigingen zal denk ik niet gaan ivm met de access denied melding.

Het probleem zou ik kunnen oplossen volgens dit artikel van microsoft ..maar dan restore ik de settings zoals ik ze al had. En ik wil graag SMB Signing disabled hebben.

Dus misschien toch maar een reboot ?? graag advies in deze.

[alt-92]

Let je er wel op dat je nu SMB signing uitzet op een Domain Controller en dat de vereisten daar iets anders zijn als met een normale non-DC fileserver?

Ik zou dan ook voor een getrapte invoering hebben gekozen:
Eerst de harde requirement uitzetten, en daarna (als alles goed gaat) pas de request.

Ik krijg ook een Access Denied op de server als ik de betreffende policies aanklik.

Dan heb je zeker een issue die je nu nog kan oplossen.
Staat ook in You cannot open file shares or Group Policy snap-ins when you disable SMB signing for the Workstation or Server service on a domain controller aangegeven he..

Nog niet rebooten in ieder geval, want dan kun je je thermosfles koffie bij de hand houden.

Je kan de policy waarden namelijk nu nog via je registry terugzetten.

[ Voor 27% gewijzigd door alt-92 op 07-11-2007 14:46 ]

[Tranzy]

Nou het is gelukt. De server rebooten was hetgeen wat nog nodig was.

Ik zat even inderdaad met het idee dat ik nog wel eens een latertje kon krijgen als ik de server zomaar zou rebooten. Ik had een recente systemstate backup dus ik heb de server toch gereboot. Mocht het niet werken had ik een systemstate restore gedaan.

alt-92 schreef op woensdag 07 november 2007 @ 14:42:
Let je er wel op dat je nu SMB signing uitzet op een Domain Controller en dat de vereisten daar iets anders zijn als met een normale non-DC fileserver?

Zou je dit eens nader willen uitleggen. Ik ben hier toevallig een 2003 standard R2 server aan het installeren en dat wordt de nieuwe server voor een ERP pakket en Fileserver. Daar zat ik aan te denken om gelijk de SMB signing van aan te passen.

Gelijk een andere vraag nu ik toch lekker bezig ben klein beetje Offtopic maargoed.

Ik heb de nieuwe server zo ingedeeld:

• HP Proliant ML370T05 X/E5320-1 2GB (1 x /QC 1.86Ghz (2 x
  4MB cache) 1066 FSB/2 x512MB/SA P400-256)
• HP X/E5320/QC 1.86 Ghz/2 x 4MB cache/1066 FSB processor
  voor ML370G5
• 2 GB geheugenmodule (PC2 5300 Fully Buffered DIMMs / DDR2 /
  2 x 1GB)
• 512MB cache en BBWC upgrade voor SA P400
• 72.8-GB 10K SFF SAS disk (10K SFF SAS hot pluggable)
• 146-GB 10K SFF SAS vaste schijf optie (10K. SFF SAS. hot
  pluggable)

Nu heb ik:

C = 2x 72gb in Raid1 (OS) (kleine was er niet anders had ik wel 36gb genomen)
D = 2x 72gb in Raid1 (Interbase Database 7) Dit ivm performance op mirror ipv Raid5
E = 4x 146gb in Raid5 (Files)

Wat vinden jullie van ShadowCopy enablen op alle schijven (zowiezo op de E..maar op C en D?)

[alt-92]

Tranzy schreef op woensdag 07 november 2007 @ 15:25:

Zou je dit eens nader willen uitleggen. Ik ben hier toevallig een 2003 standard R2 server aan het installeren en dat wordt de nieuwe server voor een ERP pakket en Fileserver. Daar zat ik aan te denken om gelijk de SMB signing van aan te passen.

Bij het booten van je DC wordt geprobeerd de \sysvol share te vinden, als er dan afwijkingen in SMB signing zijn kan die share niet uitgelezen worden waardoor policies en aanmelden niet werken.
Wat ook in dat artikel beschreven staat.

Op een normale fileserver heb je geen sysvol, en dat betekent dat je daar wat minder risico's mee gaat lopen.
Sowieso: alles wat je aan security-related settings wijzigt op een (SBS) domain controller moet je gewoon goed over nadenken en testen.
Noem een IPsec rule, als je daar wat verkeerd mee doet krijg je never nooit meer een nieuwe machine in je domain aangemeld

Gelijk een andere vraag nu ik toch lekker bezig ben klein beetje Offtopic maargoed.

D = 2x 72gb in Raid1 (Interbase Database 7) Dit ivm performance op mirror ipv Raid5

Wat vinden jullie van ShadowCopy enablen op alle schijven (zowiezo op de E..maar op C en D?)

Bedenk voor jezelf eens wat de (nadelige) effecten kunnen zijn van het aanzetten van VSS op een disk waar een SQL DB op draait?

[Tranzy]

Ja...ok op zo'n manier.. daar ben ik me van op de hoogte wat betreft de SYSVOL share. Maar point taken.

Wat betreft Shadowcopy:
Zo dacht ik dus ook ...maar aangezien deze VSS maar 2 keer per dag draait dacht ik dat dit niet echt voor veel overlast zal zorgen.

[alt-92]

Totdat je DB corrupt raakt.
En dan? Vraag het desnoods na bij je leverancier.