Gulp
-
Gesamte Inhalte
4.468 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Gulp
-
-
Ich habe da so meine Zweifel....
Es stimmt zwar, dass die SAM bei einem DC inaktiv ist, was aber nicht bedeutet, dass das Computer Objekt des DC's selbst keine SID hat. Schliesslich hat der DC auch eine GUID (kann man übrigens auch im DNS unter den _MSDCS sehen).
Also zusamen gefasst:
Es gibt lokale, sich auf einem Computer befindlichen Benutzerobjekte SID's. Diese sind aber wie gesagt lokal, und setzen sich wenn ich mich nicht täusche, aus einem Teil Computer SID und und einem zufälligen Teil zusammen.
Es gibt aber auch Domänen SID's (Benutzer, Gruppen, Computer, usw. ...eben jedes Objekt). In einer Domäne spielen lokale SID eine untergeordnete Rolle, da man ja üblicherweise auf AD als Benutzerdatenbank und nicht die SAM eines einzelnen Computers zurück greifft. Wenn man zum beispiel die Domain User als Mitglied der lokalen Haupbenutzer hinzufügt, dann wird das zwar in der SAM des betreffenden Computers gespeichert, allerdings wird auf AD als Objekt Datenbank zurückgegriffen.
Ausserdem könnten GPO und desweiteren gar nicht angewandt werden, wenn DC's keine Computer SID hätten. Worauf soll sich denn ein GPO referenzieren, ob es angewandt wird oder nicht?
Gruss
Velius
Dass ein DC keine Computer-SID hat sagte ich doch gar nicht! Er hat eine, aber eben eine im Active Directory.
Nicht-DC's haben aber zwei Computer-SID's, eine lokale (die der DC nicht hat) und eine im Active Directory. Diese beiden unterscheiden sich, wie Du trefflich bemerkt hast, weil die lokale Computer-SID des Nicht-DC bei der Installation zufällig erstellt wird. Die Zweite Computer-SID, ich will sie mal Domänen-Computer-SID nennen (entspricht dem Domänen Computerkonto), wird beim Domänenbeitritt erstellt und auch im AD gespeichert.
Summary:A security identifier (SID) is a unique value of variable length that is used to identify a security principal or security group in Windows operating systems. Well-known SIDs are a group of SIDs that identify generic users or generic groups. Their values remain constant across all operating systems.
This information is useful for troubleshooting issues involving security. It is also useful for potential display problems that may be seen in the ACL editor. A SID may be displayed in the ACL editor instead of the user or group name.
Nachzulesen in Well-known security identifiers in Windows operating systems
@blub:
Sorry, da hab ich mich echt verguckt, es ist der Infrastructure-Master, der nicht auf den GC gehört. siehe FSMO placement and optimization on Active Directory domain controllers
Mit verspäteter Replikation meinte ich unter anderem dieses hier (manchmal sollte ich mir wirklich Gedanken über eindeutige Ausdrücke machen ;) ) : Windows 2000 SID filtering prevents the replication of schema naming contexts and of configuration naming contexts
So nun noch ein wenig 'Bettlektüre' zu den SID's:
Grüsse
Gulp
-
Hehe, wieder mal mein Lieblingsthema SID's:
Ein Domain Controller zeigt lediglich die Domain SID an. Diese muss bei allen Domain Controllern identisch sein. Die lokale SID, die bei der Installation vergeben wird, wird bei DC's nach dcpromo nicht mehr verwendet. (Versuche mal bei einem DC zB einen lokalen Benutzer anzulegen - für lokale Objekte wird die eben diese lokale SID verwendet, für Domänen Objekte eben die omain SID + den aktuellen Relative ID Pool, den der Poolmaster verwaltet.)
DC's unterscheiden sich selbst anhand der DC-Computerkonten im Directory.
Bei den SID's geht's reichlich kompliziert zu.
Es gibt lokale SID's, die in Arbeitsgruppen die grosse Rolle spielen. Lokale SID's haben alle Workstations, egal ob diese in einer Domain oder nur in einer Arbeitsgruppe sind. Diese lokalen SID's werden unter anderem für lokale Anmeldungen benutzt. (In einem domänenbasierten Netzwerk hat zB auch der lokale Workstation Admin administrativen Zugriff über das Netzwerk auf die Workstation, aber auch der Domänenadmin.)
Es gibt Domänen SID's. DC's haben diese Domänen SID und hängen eine relative ID (RID) dran, um die Eindeutigkeit der ID zu gewährleisten. Dieser RID Pool wird von einem DC verwaltet (wie Betriebsmasterrolle, etc).
Domaincontroller werden standardmässig ihrer lokalen Kontenverwaltung nach dcpromo beraubt, daher spielt die lokale SID für DC's (fast) keine Rolle mehr.
Günter's Link verweist auch 'nur' auf duplicate SID's in der SAM, also bereits SID's aus Domänen. Die lokalen SID's sind da aussen vor.
Tatsächlich kann es auch im Domänenumfeld in manchen ungünstigen Konstellationen zu doppelten Domänen-SID's kommen (Thema: RID-Master auf GlobalCatalogue DC, verspätete Replikation bei Vetrauensstellungen und mehr), die man bei MS mit Hilfe von SIDFiltering in den Griff bekommen kann. (MS KB 315062 )
Grüsse
Gulp
-
Danke! War das erste was ich probiert hatte leider sagt er der Treiber wäre noch in Verwendung und könne daher nicht gelöscht werden.
Da gibts nen einfachen Trick:
Druckwarteschlange in den Diensten beenden und anschliessend Treiber deinstallieren, Druckwarteschlange neu starten, fertig.
Grüsse
Gulp
-
@Grizzly999
Ich hatte schon mal beobachtet, die SID eines Rechners ändert sich durch einen Domänenbeitritt nicht.
Im Rahmen meiner Versuche mit dem Ändern der Domänenzugehörigkeit (in diesem Thread) habe ich die Rechner-SID jeweils mit psgetsid ausgelesen und keine Änderung beobachten können.
Gruß
Edgar
Stimmt die Rechner SID bleibt gleich, ist ja auch eine lokale SID, die im ADS keine Rolle spielt. Wohl aber in der Kommunikation von Client zu Client (auch das solls in Domänen ja geben) ...
Hier ein Auszug aus http://www.sysinternals.com/Utilities/NewSid.html (den Edgar abe sicher schon kennt ;) ):
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.
To understand the problem that cloning can cause, it is first necessary to understand how individual local accounts on a computer are assigned SIDs. The SIDs of local accounts consist of the computer's SID and an appended RID (Relative Identifier). The RID starts at a fixed value, and is increased by one for each account created. This means that the second account on one computer, for example, will be given the same RID as the second account on a clone. The result is that both accounts have the same SID.
Duplicate SIDs aren't an issue in a Domain-based environment since domain accounts have SID's based on the Domain SID. But, according to Microsoft Knowledge Base article Q162001, "Do Not Disk Duplicate Installed Versions of Windows NT", in a Workgroup environment security is based on local account SIDs. Thus, if two computers have users with the same SID, the Workgroup will not be able to distinguish between the users. All resources, including files and Registry keys, that one user has access to, the other will as well.
Another instance where duplicate SIDs can cause problems is where there is removable media formated with NTFS, and local account security attributes are applied to files and directories. If such a media is moved to a different computer that has the same SID, then local accounts that otherwise would not be able to access the files might be able to if their account IDs happened to match those in the security attributes. This is not be possible if computers have different SIDs.
Wenn ich mich recht entsinne wird die SID des Computerkontos in einer Domäne aber mit Hilfe der lokalen Computer SID generiert, wobei zwar nicht die komplette lokale SID herhalten muss, schliesslich muss ja auch zumindest ein Teil der Domänen-SID im Computerkonto hinterlegt sein, damit man den Rechner als Teil der Domäne identifizieren kann.
Ich muss gleich mal gucken ob es zwischen der SID eines Computerkontos in einer Domäne und der lokalen Computer-SID Gemeinsamkeiten gibt.
Grüsse
Gulp
-
Natürlich geht das. Das Laptop wird unter Arbeitsplatz/Eigenschaften/Computername erst zur einen Domäne hinzugefügt, und dann einfach zu noch einer Domäne, ohne das Laptop vorher wieder zu einer Arbeitsgruppe hinzuzufügen und somit aus einer Domäne wieder heraus.
Logisch sollte sein das in beiden Domänen das Computerkonto und ein entsprechendes Benutzerkonto existent ist.
In einer Schulungsumgebung macht sich dies gut.
Gruß
Baba
Hmm... sowas hab ich auch schon mal probiert und dann ne dicke Fehlermeldung bekommen.
Ausserdem wage ich zu bezweifeln, dass dies in einer Produktiv-Umgebung zB mit GPO's, differenzierter File-Security und Netz-Security, Datenbanken und Drittanbietersoftware wirklich reibungslos funzt.
Naja, ich lass mir gerne auch das Gegenteil beweisen.
Grüsse
Gulp
-
Moin, moin ...
... ein neuer Tag beginnt. Kaffee ist schon mal anwesend, so wie ich. Heiss is der Kaffee auch. Schmecken tut er nicht wirklich, wer hat das gebraut, der Azubi oder was?
Hier liegen noch ein paar Kitkat Riegel neben dem Linux Server *indieRundewerf* ....
Am Dienstag wird ein ein Server zum neuen DC hochgestuft *freu* und dann kann ich endlich die alte Samba Domäne wegwerfen. Wird zwar noch einen Rattenschwanz an Clientanpassungen nach sich ziehen, aber da kann ich wieder ein paar User gängeln *diabolischgrins*.
Möge es noch viele Dienstage wie diesen geben! :D
Grüsse
Gulp
-
... snip ....
Zu Schwierigkeiten im Netzwerk: Ich habe schon Netze vorgefunden aus geklonten Clients mit identischer SID. Das Netzwerk funktionierte Aus von identischen SISs resultierenden Problemen war nichts zu erkennen.
Ging mir auch schon so und das lief auch so cirka 1 Jahr problemlos. Dann gings aber los mit Problemen, Rechner konnten nicht mehr in die Domäne, Anmeldeprobleme, Synchronisationsprobleme mit Profilen, Zugriffsprobleme auf Freigaben und und und ...
Das Ganze war eine NT 4 Domäne mit NT 4 Clients und wurde ständig mit Rechnern erweitert. Komischerweise waren diese Phänomene weg, als ich dann mit NewSID alle Kisten mit neuen SID's versorgt hatte.
Bei W2K/W2K3 kriegen durch die Verwendung des ADS aber auch mehr Objekte SID's, als bei NT (weils auch mehr Objekte gibt), daher spielt die SID auch eine wichtigere Rolle.
Trotzdem fallen die Probleme oft 'nur' in speziellen Fällen und Konstellationen auf.
Grüsse
Gulp
-
Hi,
das geht zum einen mit der Kommandozeile oder aber mit Amok Delay.
Einfach mal nach googeln.
Die Dateien dort dann einfach in den Papierkorb von Amok Delay schieben,
der löscht die dann beim Neustart.
Interessanter wäre aber, wer die Dateien im Zugriff hat.
dann könntest du den Prozess killen und dann löschen.
Grüße Cat
Das bekommt man doch ganz einfach mit dem Process Explorer von sysinternals raus. Ausserdem lässt sich damit gezielt nach dem geöffneten Handle suchen und dieses Handle kann auch damit geschlossen werden. Danach ist ein löschen der Datei problemlos möglich. Und das in der Regel ohne Neustart .....
Grüsse
Gulp
-
Der Rechnername spielt da eine eher untergeordnete Rolle. Jedes Objekt im ADS (so auch Computerkonten) hat eine eindeutige SID (Security Identifier), die sich auch zwischen Domänen unterscheidet.
Da sich die Kombination von Computer SID und Domänen SID von Client A und Client B unterscheiden wird schon beim lokalen Authentifizierungsversuch gemerkt, dass hier was nicht stimmt und da ruft der Client den DC zur Hilfe, vereinfacht ausgedrückt.
Grüsse
Gulp
-
Is ganz einfach .... (jedenfalls eigentlich)
Das ist der Ausgangspunkt: Du hast eine Domäne A mit DC und mehreren Clients. Genauso eine Konstellation B. Client aus Domäne A soll auf Client aus Domäne B zugreifen.
Ganz vereinfacht gesagt:
Der Client aus Domäne A versucht mit seinem Computerkonto (in Domäne A ja vorhanden) auf Client aus Domäne B zuzugreifen. Da der Client keine Computerkonten verwaltet, fragt der seinen DC B, der guckt nach, ob er Domäne A kennt bzw ob er Domäne A vertraut. Kennt/vertraut der DC B der Domäne A nicht lehnt er den Zugriff ab.
Sonst könnte ja jeder auf beliebige Clients zugreifen.
Alternativ ist eine Verbindung auf lokaler Basis der Clients nicht ganz unmöglich, dazu muss man nur einen entsprechenden lokalen User des Clients verwenden. Leider muss man nach jedem Neustart die Session erneuern, also entweder neu verbinden oder das entsprechende Passwort eintippeln.
Eine Vertrauensstellung hast Du ja jetzt, die erübrigt das oben genannte.
Gruss
Gulp
-
hi,
wie du was eingefügt bekommst? ipconfig /all?
Ausführen im cmd, bearbeiten, alles markieren, kopieren in das Fenster zur Antwort
Ich weiss zwar nicht was Du bei Windows 98 mit 'ipconfig /all' erreichen willst, ich kann Dir aber sagen, was Du erreichen wirst. Eine Fehlermeldung ....
Bei Windows 98 geht wohl nur 'winipcfg' .... (liefert aber auch die gewünschte Info).
Grüsse
Gulp
-
Sicher funkt der DC dazwischen, ist ja auch logisch, denn die Clients sind Teil der Domäne. Egal, ob Du per Name oder IP des Clients auf Ressourcen (in Deinem Fall die DB) zugreifen möchtest.
Zunächst wird der Client versuchen den Zugriff zu authentisieren und genau da kommt der DC ins Spiel, da der Client Mitglied in der Domäne ist.
Du solltest die Vertrauensstellung der beiden DC's mal prüfen und gegebenfalls erneuern, dann dürfte das wieder funktionieren.
Grüsse
Gulp
-
Mahlzeit ....
würde am liebsten auch zu Tisch ... wenn ich denn hier weg könnte ... also fällt mal wieder Mittag aus. Manno, das hasse ich ja. :( :suspect:
Also, wieder mit Kaffee und Zigaretten den Hunger betäuben ....
Hmm, ich glaube am Freitag stell ich mal ein bisschen was im Netzwerk um, damit hier ein bisschen Bewegung in den Laden kommt. Neuer Server wär ja nicht schlecht ... und macht Spass.
-
Brauchst Du einen geeigneten Switch mit Portbasierter Security (CISCO hat sowas im Programm) für, meines wissens kann man beim Server keine MAC Adressen vom Zugriff auf eine Domäne abhalten (ausser über den Umweg der DHCP Vergabe für mehrere Subnetze, die nicht miteinander kommunizieren können).
Grüsse
Gulp
-
Moin ....
... ich glaub ich werd erst jetzt so richtig wach, obwohl ich schon fast 2 Stunden auf der Arbeit bin.
Irgendwie scheint auch der Kaffee nich mehr zu wirken .....
* indieRundewink *
Gulp
-
Office 2003 bietet mit dem "Microsoft Office 2003 Assistent zum Speichern eigener Einstellungen" die Möglichkeit alle Konteninformationen von einem PC auf einen anderen zu Übertragen. (zu finden unter Start --> Programme --> Microsoft Office --> Microsoft Office Tools)
Damit gelingt recht einfach ein "Umzug" von Outlook.
Grüsse
Gulp
-
Mittagspause? Wat'n dat?
** nocheinKaffeehol **
-
Da gibt's mehrere Möglichkeiten, schau Dir mal folgende Links an:
Den letzten Hinweis (mit der ipxfer.exe) habe ich bei solchen Update Problemen schon öfter erfolgreich eingesetzt. Dies geht am Einfachsten über ein temporäres Logon-Script (je nach Client Anzahl ein paar Tage bis ein paar Wochen), welches je nach Anzahl der Clients und deren Anmeldeverhalten, ein paar Tage oder eben ein paar Wochen verwendet wird. Es spielt dabei keine Rolle, wie oft Clients diesen Befehl ausführen.
Grüsse
Gulp
-
Dr. Melzer hat recht, das wird nicht gehen. Erstens wegen mangelnder Treiber-/TWAIN Unterstützung auf dem 2003 Server und ausserdem wirst Du den ohne entsprechende Software nicht freigeben können.
Lediglich die gescannten Bilder wirst Du von einem XP/2k/NT/ME/9x Client auf eine zentrale Freigabe des 2003 Servers schaufeln können.
Dafür gibt es, wie Dr. Melzer dies schon treffend bemerkte, spezielle angepasste Scanner (HP Digital Sender, etc)
Grüsse
Gulp
-
... der Gulp arbeitet noch ....
-
Das müsste von den jeweiligen Setups unterstützt werden, aber keine Ahnung, ob das auch tatsächlich vorgesehen ist. Bei Novell ist es zumindest wahrscheinlich.
Zumindest für diverse Novell Client Versionen gibts ein paar brauchbare Anleitungen in der Novell Knowledgebase für diverse Silent Installationen/Deinstallationen. Wird aber wohl darauf hinauslaufen, dass Du einige Parameter mitgeben musst. Je nach verwendeter Technik eine ini oder so, da der Client wissen will was alles (nur TCP/IP oder TCP/IP und IPX/SPX oder nur IPX/SPX, IPX Rahmentyp, bevorzugter Server, Bindery oder NDS, SingleSignOn und so weiter) installiert werden soll.
Möglicherweise hilft auch ein Ausführen der jeweiligen setup.exe mit dem Parameter -? oder /?, meistens schmeissen die EXE dann ein paar Setup Parameter aus.
Grüsse
Gulp
-
Bei mir funzt das wunderbar ... egal mit welcher Dateiart.
Schau mal nach was das überhaupt für eine Datei ist, vielleicht ist's auch nur eine Verknüpfung auf die Notes.exe (kann mir nämlich nicht vorstellen, dass die EXE für Notes auf'm Desktop liegt.).
Also dann del /S /Q "C:\Dokumente und Einstellungen\All Users\Desktop\notes.lnk"
Grüsse
Gulp
-
Rmdir heisst RemoveDirectory ....
Notes.ini ist kein Directory (also Ordner), sondern ein File (also Datei), ebenso die notes.exe.
Da hilft der Befehl delete (del), ausserdem setzt man Pfade mit enthaltenen Leerzeichen in Anführungszeichen: "C:\Dokumente und Einstellungen\All Users\Desktop\notes.exe"
Hoffe das bringt Dich weiter ...
Grüsse
Gulp
-
ich bin ganz zufrieden mit http://www.flashpeak.com/sbrowser/
Domäne und Notebook
in Windows Forum — LAN & WAN
Geschrieben
Auch wenn Vertrauensstellungen zwischen Domänen bestehen, sind mehrere Domänen im Anmeldedialog auswählbar.
Ich traue der Geschichte mit dem Hinzufügen eines Hosts an mehreren Domänen immer noch nicht so recht, auch wenn's zu funktionieren scheint.
Grüsse
Gulp