We hebben onlangs ons oude file systeem vaarwel gezegd. Dit file systeem was een SAN en bestond uit 2xW2K3 servers in een cluster + Hitachi Storage Unit. Op de W2K3 server hadden we een (local) DFS structuur opgebouwd. Deze servers stonden in domain ABC.
Users uit domain XYZ konden zonder problemen op de DFS share van domain ABC. Om gecontroleerd toegang tot ons domain te verschaffen van buitenaf, hadden we een groep aangemaakt --> OutsideABC.
Het nieuwe systeem is een EMC Celerra NAS. Ik hoef niet uit te leggen wat het verschil is tussen een SAN en een NAS denk ik.
De Celerra biedt de mogelijkheid een DFS structuur op te bouwen op een CIFS server. Hiervoor dient men een klein file system op de Celerra aan te maken. De DFS structuur komt dus op dit file system.
Om een DFS share aan te maken is een Windows bak nodig. Via Connect to Another Computer kan men toegrijpen op de CIFS server en de Shares bekijken/rechten veranderen, die zijn aangemaakt. Via mmc snapin Distributed File System kan men op dezelfde manier als dat bij Windows kan, een DFS structuur opbouwen.
De nieuwe DFS structuur is in wezen een kopie van de oude structuur. We hadden dan ook gedacht dat we eigenlijk niet veel problemen zouden tegenkomen, maar.....
Het probleem
Users uit trusted domain XYZ kunnen de DFS share op domain ABC niet benaderen.
De melding
Configuration could not be read from the domain controller, either because the domain controller is unavailable or access has been denied.
De DFS Share (local dfs)
\\servernaam.ABC.company.net\DFS
De Permissions
DFS share: everyone + OutsideABC --> Full Control
NTFS rechten gezet op mappen
De User
Test user account gecreeerd in domain XYZ
De verschillende platvormen
- EMC Celerra (Linux based)
- 1 CIFS server (servernaam.ABC.company.net)
- DFS structuur op CIFS server aangemaakt via een W2K3 server (Connect to another Computer --> CIFS Server)
- Client XP Professional SP2/3
Wat kan wel/niet?
Wel
- Wanneer de test user uit domain XYZ inlogt op een client die is aangemaakt in domain ABC en inlogt op domain XYZ
- Wanneer de test user inlogt op domain XYZ kan deze bij een "normale" share (dus buiten de DFS) op de CIFS server in domain ABC (bijvoorbeeld: \\servernaam1.ABC.company.net\test)
- De test user kan wel de shares/directories zien onder \\servernaam1.ABC.company.net
Niet
- Wanneer de test user inlogt op domain XYZ op z'n eigen fysieke netwerk
- Wanneer de test user met een account uit het ABC domain inlogt op een client uit datzelfde domain en via een remote desktop connection inlogt op een terminal server uit domain XYZ, gaat het niet.
Aldus: Client/User domain ABC --> Login RDP domain XYZ --> mapping naar DFS domain ABC
Het vreemde is dus wanneer ik een client gebruik die is aangemaakt in domain XYZ en fysiek aan dit netwerk hangt, er niet bij kan. Maar wanneer ik een client gebruik die is aangemaakt in domain ABC en inlog op domain XYZ de test user er wel bij kan.
Wat heb ik allemaal geprobeerd?
- Contact opgenomen met de support partner. Zij hebben een ticket geopend bij de leverancier. Tot op heden niet met een oplossing gekomen
- Logs bekeken op Celerra. De logs geven een foutmelding over domain XYZ. De support partner beweert (maar niet met zekerheid) dat het ligt aan de Windows kant.
2009-02-27 07:40:21: SMB: 3:[vdm1] Domain='XYZ' trusted DC='-': ignored errorFlags=0x0 DCStatus=0x547,1355
- Een test DFS structuur opgebouwd op een Windows server. Hierbij heb ik het pad opgegeven die wijst naar een map op de Celerra
- Rechten op shares/ntfs gechecked.
- De group Domain Computers uit domain XYZ op de share gezet met READ permissions
- Gezocht met Google op 0x547, dit geeft 2 hits. Maar de artikelen zijn niet op mijn probleem van toepassing.
- Gezocht met Google op Configuration could not be read from the domain controller, either because the domain controller is unavailable or access has been denied. Maar de artikelen zijn niet op mijn probleem van toepassing.
Een simple grafische weergave
Ik hoop dat het een beetje duidelijk is zo.
Users uit domain XYZ konden zonder problemen op de DFS share van domain ABC. Om gecontroleerd toegang tot ons domain te verschaffen van buitenaf, hadden we een groep aangemaakt --> OutsideABC.
Het nieuwe systeem is een EMC Celerra NAS. Ik hoef niet uit te leggen wat het verschil is tussen een SAN en een NAS denk ik.
De Celerra biedt de mogelijkheid een DFS structuur op te bouwen op een CIFS server. Hiervoor dient men een klein file system op de Celerra aan te maken. De DFS structuur komt dus op dit file system.
Om een DFS share aan te maken is een Windows bak nodig. Via Connect to Another Computer kan men toegrijpen op de CIFS server en de Shares bekijken/rechten veranderen, die zijn aangemaakt. Via mmc snapin Distributed File System kan men op dezelfde manier als dat bij Windows kan, een DFS structuur opbouwen.
De nieuwe DFS structuur is in wezen een kopie van de oude structuur. We hadden dan ook gedacht dat we eigenlijk niet veel problemen zouden tegenkomen, maar.....
Het probleem
Users uit trusted domain XYZ kunnen de DFS share op domain ABC niet benaderen.
De melding
Configuration could not be read from the domain controller, either because the domain controller is unavailable or access has been denied.
De DFS Share (local dfs)
\\servernaam.ABC.company.net\DFS
De Permissions
DFS share: everyone + OutsideABC --> Full Control
NTFS rechten gezet op mappen
De User
Test user account gecreeerd in domain XYZ
De verschillende platvormen
- EMC Celerra (Linux based)
- 1 CIFS server (servernaam.ABC.company.net)
- DFS structuur op CIFS server aangemaakt via een W2K3 server (Connect to another Computer --> CIFS Server)
- Client XP Professional SP2/3
Wat kan wel/niet?
Wel
- Wanneer de test user uit domain XYZ inlogt op een client die is aangemaakt in domain ABC en inlogt op domain XYZ
- Wanneer de test user inlogt op domain XYZ kan deze bij een "normale" share (dus buiten de DFS) op de CIFS server in domain ABC (bijvoorbeeld: \\servernaam1.ABC.company.net\test)
- De test user kan wel de shares/directories zien onder \\servernaam1.ABC.company.net
Niet
- Wanneer de test user inlogt op domain XYZ op z'n eigen fysieke netwerk
- Wanneer de test user met een account uit het ABC domain inlogt op een client uit datzelfde domain en via een remote desktop connection inlogt op een terminal server uit domain XYZ, gaat het niet.
Aldus: Client/User domain ABC --> Login RDP domain XYZ --> mapping naar DFS domain ABC
Het vreemde is dus wanneer ik een client gebruik die is aangemaakt in domain XYZ en fysiek aan dit netwerk hangt, er niet bij kan. Maar wanneer ik een client gebruik die is aangemaakt in domain ABC en inlog op domain XYZ de test user er wel bij kan.
Wat heb ik allemaal geprobeerd?
- Contact opgenomen met de support partner. Zij hebben een ticket geopend bij de leverancier. Tot op heden niet met een oplossing gekomen
- Logs bekeken op Celerra. De logs geven een foutmelding over domain XYZ. De support partner beweert (maar niet met zekerheid) dat het ligt aan de Windows kant.
2009-02-27 07:40:21: SMB: 3:[vdm1] Domain='XYZ' trusted DC='-': ignored errorFlags=0x0 DCStatus=0x547,1355
- Een test DFS structuur opgebouwd op een Windows server. Hierbij heb ik het pad opgegeven die wijst naar een map op de Celerra
- Rechten op shares/ntfs gechecked.
- De group Domain Computers uit domain XYZ op de share gezet met READ permissions
- Gezocht met Google op 0x547, dit geeft 2 hits. Maar de artikelen zijn niet op mijn probleem van toepassing.
- Gezocht met Google op Configuration could not be read from the domain controller, either because the domain controller is unavailable or access has been denied. Maar de artikelen zijn niet op mijn probleem van toepassing.
Een simple grafische weergave
Ik hoop dat het een beetje duidelijk is zo.
[ Voor 5% gewijzigd door NRGetic op 04-03-2009 15:54 . Reden: Plaatje toegevoegd ]
I used to be schizophrenic, but we are okay now.
/u/8/oog3.png?f=community)
:strip_icc():strip_exif()/u/4167/bacall8.jpg?f=community)
