Dit is geen vraag, meer een mededeling
Als je MBSA (Microsoft Baseline Security Analyzer) draait op een server, dan wordt je waarschijnlijk gewezen op een "potentieel gevaar" en wordt je geadviseerd "RestrictAnonymous" in het register op 2 te zetten.
MBSA waarschuwt bij mijn weten netjes dat 't gevaarlijk kan zijn deze waarde te veranderen (zeker op een Domain Controller), maar omdat het nooit een probleem heeft opgeleverd heb ik dat altijd netjes gedaan om zo de server zo goed mogelijk te beschermen.
Nu blijkt dus, dat als je Ghost 8.0 gebruikt om clients te herinstalleren en automatisch aan een domein laat joinen, dat deze setting een probleem kan opleveren.
Wil je weten waar deze setting voor dient bekijk dan eens MSKB artikel Q246261.
Kom je dus in je eventlog deze melding(en) tegen, dan weet je wat je te doen staat (RestrictAnonymous weer op 0 zetten dus)!
Naar nu blijkt, zijn er ondertussen (anderhalf jaar nadat ik MBSA ben gaan gebruiken dus) meer gebruikers die last hebben van deze setting (RestrictAnonymous=2 dus) zoals je kunt zien op Google:
• Google Web
• Google Groups
Advies is dus: Niet meer naar MBSA luisteren (wat betreft deze setting) en dus lekker op 0 laten staan.
Waarom meld je dat hier dan
Om meerdere redenen:
• Omdat er op google op het moment van schrijven niks over te vinden is (ook op GoT niet overigens)
• Omdat mijn 2 collega's zich de afgelopen 2 dagen rot hebben gezocht naar een oplossing hiervoor
• Om toekomstige tweakers dus een boel werk te besparen
• Omdat ik GoT toch een beetje beschouw als een "Knowledge Base", en dit soort tips/truucs hoort daar nu eenmaal in
• Omdat mijn collegae minstens (letterlijk) 3 uur met symantec hebben moeten bellen om dit uit te vinden... Die tijd en het daarvoor benodigde beltegoed wil ik jullie dus ook besparen.
Ik heb zoveel mogelijk trefwoorden (o.a. GhostJoinDomainUser, eventID nr's e.d.) in deze post opgenomen die op deze fout betrekking hebben zodat 't topic straks goed te vinden is mocht iemand hier naar zoeken.
Als je MBSA (Microsoft Baseline Security Analyzer) draait op een server, dan wordt je waarschijnlijk gewezen op een "potentieel gevaar" en wordt je geadviseerd "RestrictAnonymous" in het register op 2 te zetten.
MBSA waarschuwt bij mijn weten netjes dat 't gevaarlijk kan zijn deze waarde te veranderen (zeker op een Domain Controller), maar omdat het nooit een probleem heeft opgeleverd heb ik dat altijd netjes gedaan om zo de server zo goed mogelijk te beschermen.
Nu blijkt dus, dat als je Ghost 8.0 gebruikt om clients te herinstalleren en automatisch aan een domein laat joinen, dat deze setting een probleem kan opleveren.
Wil je weten waar deze setting voor dient bekijk dan eens MSKB artikel Q246261.
Kom je dus in je eventlog deze melding(en) tegen, dan weet je wat je te doen staat (RestrictAnonymous weer op 0 zetten dus)!
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| EventID: 529 Logon Failure: Reason: Unknown user name or bad password User Name: GhostJoinDomainUser Domain: XXXXX Logon Type: 3 Logon Process: NtLmSsp Authentication Package: NTLM Workstation Name: XXXXX EventID: 681 The logon to account: GhostJoinDomainUser by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 from workstation: XXXXX failed. The error code was: 3221225572 (en soms 3221225578) |
Naar nu blijkt, zijn er ondertussen (anderhalf jaar nadat ik MBSA ben gaan gebruiken dus) meer gebruikers die last hebben van deze setting (RestrictAnonymous=2 dus) zoals je kunt zien op Google:
• Google Web
• Google Groups
Advies is dus: Niet meer naar MBSA luisteren (wat betreft deze setting) en dus lekker op 0 laten staan.
Waarom meld je dat hier dan
Om meerdere redenen:
• Omdat er op google op het moment van schrijven niks over te vinden is (ook op GoT niet overigens)
• Omdat mijn 2 collega's zich de afgelopen 2 dagen rot hebben gezocht naar een oplossing hiervoor
• Om toekomstige tweakers dus een boel werk te besparen
• Omdat ik GoT toch een beetje beschouw als een "Knowledge Base", en dit soort tips/truucs hoort daar nu eenmaal in
• Omdat mijn collegae minstens (letterlijk) 3 uur met symantec hebben moeten bellen om dit uit te vinden... Die tijd en het daarvoor benodigde beltegoed wil ik jullie dus ook besparen.
Ik heb zoveel mogelijk trefwoorden (o.a. GhostJoinDomainUser, eventID nr's e.d.) in deze post opgenomen die op deze fout betrekking hebben zodat 't topic straks goed te vinden is mocht iemand hier naar zoeken.
[ Voor 15% gewijzigd door RobIII op 01-09-2004 17:44 ]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij