PRobleem met sysprep en domein

Pagina: 1
Acties:

  • segil
  • Registratie: Januari 2003
  • Laatst online: 13:48
Hallo, ik weet niet of dit de juiste groep is, ik heb een probleem met Win2k domein.

Ik heb het volgende probleem met het klonen van systemen in een Windows 2000
netwerk. Het lukt me niet om na het gebruiken van Sysprep een computer lid te
maken van een domein met een bepaald domainaccount. Ik krijg dan de
melding 'Toegang geweigerd'.

Alle w2k prof. systemen zijn lid van één domein. Dit zijn ongeveer 25 systemen.
Tot voorkort kloonde we een computer door een Ghost image te gebruiken van
een andere, zelfde systeem.
Na het Ghosten, unplugde we het systeem, logde lokaal in, maakte de computer lid
van een workgroep en veranderde de computernaam. Opnieuw opstarten,
netwerk aansluiten, lokaal inloggen en lid maken van het domein. Het lid maken
van het domein en tevens installeren van software wordt gedaan door een
domainaccount (install-user), die bepaalde rechten heeft.
Op deze manier werd de computernaam gewijzigd en dit werkte goed.
(is dit een correcte, juiste manier om een computernaam te wijzigen?)

Nu ben ik bezig geweest met de utility Sysprep van Microsoft. Ik heb het idee dat
dit een betere manier is om een computernaam te wijzigen. Ik installeerde
een nieuw systeem met alle software en instellingen met het speciale
domainaccount (install-user), koppelde deze los van het domein (door lid te maken
van een workgroup), draaide erna Sysprep met een aangepaste sysprep.inf, en van dit systeem heb ik een Ghost image gemaakt.
Als ik nu de image terug zet, krijg ik de mini-setup te zien van Sysprep, waarbij ik ook een computernaam kan ingeven. Reboot en ik kan lokaal inloggen. Dit werkt allemaal goed. Nu wil ik de computer lid maken van het domein en doe dit door het juiste domein in te vullen. Windows vraagt dan om een gebruikersaccount die hiervoor gemachtigd is.
Als ik hiervoor het domainaccount install-user gebruik, krijg ik de mededeling 'Toegang geweigerd'! Het lukt mij niet om met dit account de computer lid te maken van het domein, terwijl dit wel lukte voordat ik Sysprep gebruikte.
Lid maken met een ander domain adminaccount gaat wel goed. Ik moet alleen wel dit ene account kunnen gebruiken.
Iemand enig idee hoe dit komt? Heeft het iets te maken met sysprep, die de SIDs enzo wijzigt? Is het wijzigen van de computernaam ook een goede oplossing
na het klonen van een systeem, of moet je toch iets als sysprep of Ghostwalker gebruiken?
Ter info, bij het installeren van de systemen wordt lokaal een profiel aangemaakt voor de domainaccount install-user, en deze is ook aanwezig in de Ghost-image.

  • Equator
  • Registratie: April 2001
  • Laatst online: 28-04 13:26

Equator

Crew Council

#whisky #barista

Ter info, bij het installeren van de systemen wordt lokaal een profiel aangemaakt voor de domainaccount install-user, en deze is ook aanwezig in de Ghost-image.
Vul de gegevens van deze install_user eens in met:
code:
1
2
DOMAINNAME\install-user
password

ANders gebruikt hij de lokale (client) install-user accoutn gegevens en die mist de rechten om deze actie uit te voeren.

[ Voor 29% gewijzigd door Equator op 09-01-2003 13:44 ]


  • Arno
  • Registratie: Juli 2000
  • Laatst online: 22:34

Arno

PF5A

CyberJ schreef op 09 January 2003 @ 13:43:
Vul de gegevens van deze install_user eens in met:
code:
1
2
DOMAINNAME\install-user
password

ANders gebruikt hij de lokale (client) install-user accoutn gegevens en die mist de rechten om deze actie uit te voeren.
Als een domain opgeeft in de sysprep.inf
code:
1
2
3
4
[Identification]
    JoinDomain=domain
    DomainAdmin=user
    DomainAdminPassword=********
Gaat sysprep er zelf vanuit dat je dat domain wilt joinen :)

Overigens kun je met de setupnamager op de Windows 2000 pro/server CD prima sysprep.inf files genereren, laatst nog gedaan :)

"Supercars are made to mess around with G-forces, hypercars are made to mess around with G-strings"
Jeremy Clarkson


Verwijderd

Je moet dat Install-User account wel permissies geven om computers te creëren in het domein. Volgens mij is dat het, Overigens is het correct dat je Sid wijzigt met sysprep en niet als je iets kloont met ghost of zo, je zou ook de switch /nosidgen kunnnen gebruiken om dit tegen te gaan.

  • Equator
  • Registratie: April 2001
  • Laatst online: 28-04 13:26

Equator

Crew Council

#whisky #barista

Verwijderd schreef op 09 January 2003 @ 14:17:
Je moet dat Install-User account wel permissies geven om computers te creëren in het domein. Volgens mij is dat het, Overigens is het correct dat je Sid wijzigt met sysprep en niet als je iets kloont met ghost of zo, je zou ook de switch /nosidgen kunnnen gebruiken om dit tegen te gaan.
Als jij je SID niet wijzigd, dan krijg je vanzelf wel problemen. SID moet uniek zijn op het netwerk/domain

Goede oplossing van Traag. _/-\o_

  • Zwelgje
  • Registratie: November 2000
  • Laatst online: 20-01 19:37
CyberJ schreef op 09 January 2003 @ 14:31:
[...]


Als jij je SID niet wijzigd, dan krijg je vanzelf wel problemen. SID moet uniek zijn op het netwerk/domain

Goede oplossing van Traag. _/-\o_
op zich zou het geen probleem zijn om met duplicate sids te werken, kijk werkstations mogen wel clonen van elkaar zijn met dezelfde SID, echter domain controllers niet!

het zou geen problemen moeten opleveren, kijk als je rechten uitdeeld op een lokale machine (en dus in een werkgroup gaat werken is het problematisch) mocht je bijvoorbeeld op WS1 een user aanmaken met de naam 'pietje', en op WS2 ook een user met de naam 'henk'... tja dan hebben ze dus dezelfde SID en dus dezelfde rechten.. (problematisch met het toekennen van rechten dus..)

en ja in een domain heb je daar geen last van aangezien je dan een centrale userdatabase met sids hebt (AD)

ik citeer een artikel van MS:

"Consequences of duplicate SIDs in a domain environment
If you had the same 500 disk-imaged desktop computers running in a domain model, all with the same SID, the impact is significantly lessened. All users are logging into a domain and are being assigned a domain-based user SID. This SID is, by nature of the domain model, guaranteed to be unique and can be used to secure files and resources within the network. The Security Account Manager has no problems distinguishing users because they are coming from a common, centralized domain security database and all processes and tokens are running within each user's security context. Note You will still have local security issues when dealing with local machine accounts (administrator, guest, etc.) as outlined above. "


Einde citaat

http://www.microsoft.com/...deploy/depopt/cloning.asp

neemt natuurlijk niet weg dat het niet wenselijk is om allemaal dezelfde workstation SIDS te hebben... maar het gaat wel werken

A wise man's life is based around fuck you


  • Arno
  • Registratie: Juli 2000
  • Laatst online: 22:34

Arno

PF5A

zwelgje schreef op 12 January 2003 @ 00:31:
neemt natuurlijk niet weg dat het niet wenselijk is om allemaal dezelfde workstation SIDS te hebben... maar het gaat wel werken
Om eerlijk te zijn geloof ik daar niets van. Als jij PC's gaat clonen, heb je automatisch dezelfde netbiosname. Twee Windows hosts met dezelfde netbiosname gaat fout in hetzelfde netwerk. Als je (handmatig of via sysprep) de netbiosname of domain membership aanpast, dan verandert ook direct de SID van de Windows host. Hierdoor zullen 2 Windows hosts NOOIT hetzelfde ID hebben.

"Supercars are made to mess around with G-forces, hypercars are made to mess around with G-strings"
Jeremy Clarkson


  • Zwelgje
  • Registratie: November 2000
  • Laatst online: 20-01 19:37
Traag schreef op 12 January 2003 @ 00:48:
[...]
Om eerlijk te zijn geloof ik daar niets van. Als jij PC's gaat clonen, heb je automatisch dezelfde netbiosname. Twee Windows hosts met dezelfde netbiosname gaat fout in hetzelfde netwerk. Als je (handmatig of via sysprep) de netbiosname of domain membership aanpast, dan verandert ook direct de SID van de Windows host. Hierdoor zullen 2 Windows hosts NOOIT hetzelfde ID hebben.
als je een nt useraccount renamed veranderd ook niet de SID.. zo werkt het met netbios names ook,

de sid blijft dan gelijk

ff opgezocht..

The SID Duplication Problem
The problem with cloning is that it is only supported by Microsoft in a very limited sense. Microsoft has stated that cloning systems is only supported if it is done before the GUI portion of Windows Setup has been reached. When the install reaches this point the computer is assigned a name and a unique computer SID. If a system is cloned after this step the cloned machines will all have identical computer SIDs. Note that just changing the computer name or adding the computer to a different domain does not change the computer SID. Changing the name or domain only changes the domain SID if the computer was previously associated with a domain


http://www.sysinternals.com/ntw2k/source/newsid.shtml

handige tool trouwens dat newsid, gebruik het al een aantal jaartjes

[ Voor 41% gewijzigd door Zwelgje op 12-01-2003 01:07 ]

A wise man's life is based around fuck you


Verwijderd

tuurlijk werken dezelfde netbios namen niet ,da's nogal vrij logisch.

Ik kan je toch uit praktijk ervaring vertellen dat EN een win2k AD structuur, EN gekloonde computers (met ghost ofzo, want sysprep verandert SIDS) met dezelfde SIDS hele rare/enge/onverklaarbare problemen gaat geven.

Maar om op jou verhaal cq. vraag terug te komen, het probleem is idd dat de install-user OF niet voldoende rechten heeft, OF dat je hem moet invullen als zijn NETBIOSNAMEDOMAIN\username, of username@FQDNdomain dan MOET en WERKT het gewoon.

  • localhost
  • Registratie: November 1999
  • Niet online

localhost

Ook in geel, groen, paars, wit

Grote kans dat het volgende het geval is (dit is nml. ook onze situatie):

Nieuwe machines (nieuwe Netbios machine naam) kan het een useraccount DOMAINNAME\Install-user worden toegevoerd aan het domain. Bestaande machines kan deze account echter niet toevoegen/verwijderen/wijzigen. Een ingreep van de Domain administrator is dan noodzakelijk.

Handig om iemand zonder DomainAdmin rechten toch een machine te kunnen laten toevoegen, zonder de beveiliging van de rest van het netwerk in gevaar te brengen.
Pagina: 1