[Windows 2003] Useraccounts moven naar nieuwe forrest

[herminator]

Met behulp van ADMT willen we useraccounts gaan moven met een roaming profile van forrest a naar forrest b. Tussen deze 2 zit een two-way-trust.
ADMT geeft na het moven de volgende melding in de log.

RR2:7207 Skipping \\server\profielen$\user15, rc=5 Access is denied.

De administrator uit forrest a en b hebben full control over de profielmappen.
Toch krijgen we die access denied.

Ook hebben we in domain security policy en Domain controller security policy "Let everyone permissions apply to anonymous" aangezet.

Om wat dingen te proberen hebben we ook everyone full control over de profiel map gegeven maar zelfs dan ging het niet.

In het exchange 2003 boek staat het op zich prima beschreven over hoe het moet maar foutmeldingen hebben ze daar dus nooit helaas.

Dit is in een testomgeving dus we kunnen eindeloos dingen proberen.

[Verwijderd]

De everyone van de domain group of de everyone op de lokale computers ?

In geval van het domain everyone, welke rechten hebben deze effectief op de lokale stations ?

[Verwijderd]

herminator schreef op donderdag 03 augustus 2006 @ 15:25:

RR2:7207 Skipping \\server\profielen$\user15, rc=5 Access is denied.
De administrator uit forrest a en b hebben full control over de profielmappen.

weet je dat zeker? namelijk bij het aanmaken van een profile dir worden de rechten niet gepropageerd, maar worden ze opnieuw gezet. (block inherentance)

[ Voor 12% gewijzigd door Verwijderd op 03-08-2006 16:24 ]

[herminator]

Ja maar handmatig zet ik de rechten er even in voordat ik die wizard gebruik.
Op de lokale stations hoeft toch niks gedaan te worden omdat de profielen op de server staan. (roaming profiles)

En wat betreft die everyone was meer een test. Het lijkt me niet echt de bedoeling om dat bij het echte werk te gaan doen. Ik zit eigenlijk een beetje vast op welke user nou eigenlijk gedenied wordt.
Want als een admin al full control heeft en toch ergens een deny zit vraag ik me af waar het dan verkeerd gaat. Misschien dat het niks met rechten op een profile map te maken heeft?

[ Voor 10% gewijzigd door herminator op 03-08-2006 19:37 ]

[_Arthur]

Filemon downloaden (http://www.sysinternals.com/Utilities/Filemon.html). Tool draaien op de server waar de profielen-directories op staan en nog eens je script/ADMT uitvoeren. In filemon kijken naar de ACCESS DENIED melding en kijken met welk account het bestand/directory wordt benadert dat geen rechten heeft.

[ Voor 10% gewijzigd door _Arthur op 03-08-2006 22:30 ]

[Verwijderd]

herminator schreef op donderdag 03 augustus 2006 @ 19:36:
Ja maar handmatig zet ik de rechten er even in voordat ik die wizard gebruik.
Op de lokale stations hoeft toch niks gedaan te worden omdat de profielen op de server staan. (roaming profiles)

En wat betreft die everyone was meer een test. Het lijkt me niet echt de bedoeling om dat bij het echte werk te gaan doen. Ik zit eigenlijk een beetje vast op welke user nou eigenlijk gedenied wordt.
Want als een admin al full control heeft en toch ergens een deny zit vraag ik me af waar het dan verkeerd gaat. Misschien dat het niks met rechten op een profile map te maken heeft?

Volgens mij de zogenaamde "system" account

Als je vermoedt dat er ergens een "deny" zit, vraag je toch even "effective permissions" op?
En dan specifiek van de System account.

Ook nog even een vraag, is user15 de enige met dit probleem ?

[ Voor 11% gewijzigd door Verwijderd op 04-08-2006 12:01 ]

[herminator]

Nee met alle users hetzelfde probleem
Filemon geeft geen deny's aan.
Effective permissions hadden we al bekeken van verschillende accounts.
De system acount is nog een idee. om te bekijken.

Voor de rest is het zo dat als we de profiles met ntfs rechten kopieren naar het nieuwe domein de nieuwe users er wel in kunnen omdat ze dezelfde sid's hebben. Op zich werkt het waarschijnlijk wel.
[e-mail] kan namelijk in de map van [e-mail]. zonder expliciet [e-mail] toe te voegen.
Dus als het goed werkt laten we het waarschijnlijk zo.

Alle profiel bestanden zien we voorbijkomen in de log dat ze aangepast worden.en dan pas als laatste de foutmelding.

[Verwijderd]

herminator schreef op zaterdag 05 augustus 2006 @ 10:52:
Nee met alle users hetzelfde probleem
Filemon geeft geen deny's aan.
Effective permissions hadden we al bekeken van verschillende accounts.
De system acount is nog een idee. om te bekijken.

Voor de rest is het zo dat als we de profiles met ntfs rechten kopieren naar het nieuwe domein de nieuwe users er wel in kunnen omdat ze dezelfde sid's hebben. Op zich werkt het waarschijnlijk wel.
[e-mail] kan namelijk in de map van [e-mail]. zonder expliciet [e-mail] toe te voegen.
Dus als het goed werkt laten we het waarschijnlijk zo.

Alle profiel bestanden zien we voorbijkomen in de log dat ze aangepast worden.en dan pas als laatste de foutmelding.

Gaat prima werken, maar een migratie met SID History is natuurlijk wel een Security issue. Weet niet voor wat voor een organizatie je dit gaat doen, maar als Security een beetje gevoelig ligt zou ik dit zeker niet gaan doorzetten.

[herminator]

Tis een vrij groot bedrijf. +- 250 man.
Je doelt waarschijnlijk hierop.

Be paranoid about security

The paranoid among us shouldn't need to look too hard to find a way in which SID History has the potential to be a really bad idea from a security perspective. All an attacker would need to do would be to find the SID of an administrative account from the domain on the other side of the trust, and then inject that SID into their own SID History attribute. (In network security parlance, this is known as an elevation of privilege attack.)

Maar microsoft zegt weer

Migrating SID history does not present a security risk because SID filtering is in place between the source and target forests

[Verwijderd]

herminator schreef op zondag 06 augustus 2006 @ 00:59:
Tis een vrij groot bedrijf. +- 250 man.
Je doelt waarschijnlijk hierop.

Be paranoid about security

The paranoid among us shouldn't need to look too hard to find a way in which SID History has the potential to be a really bad idea from a security perspective. All an attacker would need to do would be to find the SID of an administrative account from the domain on the other side of the trust, and then inject that SID into their own SID History attribute. (In network security parlance, this is known as an elevation of privilege attack.)

Dit zou ik eerder geloven dan de gebruikelijk 'er is niets aan de hand' propoganda van Microsoft. Maar nogmaals, Het hangt er maar net vanaf hoe kwetsbaar dat 250 man grote bedrijf is. Is het een bankje of erger nog aandelen toko, zou ik er niet voor gaan. Doen ze in Autobanden. tsja dan is het wel te overwegen zeg maar..

[Verwijderd]

Dit is wel een goede uitleg van Mark Minassi:
http://www.minasi.com/forum/topic.asp?TOPIC_ID=19040