faq-o-matic.net » Frank Röder

AD Snapshots „Deluxe“

Frank Röder — Sun, 26 Oct 2008 16:36:12 +0000

Dass man unter Windows Server 2008 mit dem Kommandozeilenprogramm „ntdsutil“ Snapshots von einem produktiven Active Directory erstellen kann, ist bereits weitläufig bekannt. Siehe dazu z.B. unseren Artikel:

[faq-o-matic.net » Windows Server 2008: Snapshots des Active Directory]
http://www.faq-o-matic.net/2007/04/30/windows-server-2008-snapshots-des-active-directory/

Wenn man sich allerdings etwas eingehender mit dieser Funktion beschäftigt, dann wird man recht schnell feststellen, dass man mit diesen Snapshots nicht viel anfangen kann. Wenn man zum Beispiel Veränderungen nachverfolgen möchte, die seit dem Erstellen des Snapshots aufgetreten sind, dann ist das mit den Boardmitteln des Servers recht mühselig beziehungsweise in größeren Umgebungen fast unmöglich. Deshalb habe ich schon des Öfteren darüber nachgedacht, ein Tool zu entwickeln, was automatisch diese Veränderungen auffinden kann und diese dann zur Darstellung bringt.

Bevor ich solche großen Projekte anfange, bemühe ich „google“, um eventuell Lösungsansätze oder auch schon fertige Anwendungen zu finden. Dabei ist mir das Tool „Directory Service Comparison Tool 1.2.1” aufgefallen, was durch Fredrik Lindström entwickelt wurde. Dieses MMC Snapin erfüllt alle Dinge, die man sich bei der Arbeit mit AD Snapshots nur wünschen kann.

Zu den Features zählen:

Anzeigen von Unterschieden zwischen Objekten im produktiven Active Directory und einem Active Directory Snapshot
Wiederherstellen von Objektattributen mit der Hilfe eines Snapshots
Wiederherstellen gelöschter Objekte im produktiven Active Directory
Wiederherstellen von Gruppenmitgliedschaften

Damit man mit diesem Tool arbeiten kann, benötigt man als Erstes einen AD Snapshot, der mit dem Kommandozeilenprogramm „dsamain“ bereitgestellt wurde. Wie Snapshots erstellt und bereitgestellt werden, wird in unserem oben aufgeführten Artikel erklärt.

Danach benötigt man natürlich noch das „Directory Service Comparison Tool 1.2.1”.
Nach dem Herunterladen und Installieren hat kann man es als Snapin in eine MMC hinzufügen.

Anschließend muss man eine Verbindung zum produktiven Active Directroy und zum bereitgestellten Snapshot herstellen.

Wenn die Verbindung erfolgreich war, kommt es noch zu einer kleinen Abfrage. Diese Abfrage ist notwendig, da bei einem Active Directory Snapshot die „highestCommitedUSN“ verändert wird. Dadurch erscheint der Snapshot aktueller als das produktive Active Directory. Diesen Bug hat Fredrik galant umschifft, indem er ein Attribut eines Benutzers solange aktualisiert, bis das produktive Active Directory eine höhere „highestCommitedUSN“ als der Snapshot hat.

Nachdem das erledigt ist, werden sofort die Unterschiede zwischen beiden Versionen angezeigt. Ich habe in meiner Demoumgebung alle Möglichkeiten nachgestellt. Als Erstes habe ich bei einer bereits existierenden Gruppe das Feld „Beschreibung“ ausgefüllt.

Auch mein neuerstellter Benutzer wurde einwandfrei durch das Tool erkannt.

Bei meinem dritten Versuch habe ich ein Objekt im produktiven Active Directory gelöscht. Das Tool erkennt dieses gelöschte Objekt und bietet auch das Wiederherstellen an. Der Vorteil des Wiederherstellens von Objekten aus einem Snapshot heraus besteht darin, dass man auch alle Attribute des Objektes wiederherstellen kann. Dadurch kann man zum Beispiel bei gelöschten Benutzern auch die Gruppenmitgliedschaften wiederherstellen.

Alles in allem kann man auf dieses Tool nicht verzichten, wenn man ernsthaft mit Active Directory Snapshots arbeiten will.

Vielen Dank an Fredrik für die Zeit und Mühe, die er in dieses Tool investiert hat.

RDP absichern – aber wie?

Frank Röder — Wed, 20 Aug 2008 18:44:46 +0000

Die Remotedesktopverwaltung ist jedem Administrator sicherlich ans Herz gewachsen. Dass durch das Aktivieren der Remotedesktopverbindungen auch User zumindest schon einmal bis zum Logonfenster des Servers kommen, ist hier aber ein kleines Ärgernis bzw. Sicherheitsrisiko. Zumindest wird der eine oder andere User versuchen, ob ihm eine erfolgreiche Anmeldung möglich ist. Man könnte natürlich den Zugriff auf RDP durch entsprechende Firewallregeln schützen. Das ist aber unter gewissen Umständen nicht so einfach möglich.

Ein nützliches Tool, was ich schon länger in meiner Werkzeugkiste habe, ist „2xSecureRDP4“. Mit diesem Tool hat man die Möglichkeit, seine RDP Zugänge besser abzusichern. Der Administrator kann hier die RDP Verbindungen auf Basis der IP-Adresse, der MAC Adresse, des Client Computernamens, der Clientversion oder auch der Tageszeit festmachen. Dadurch ist diese Lösung wesentlich flexibler als das Einrichten von Firewallregeln. Wer es möchte, kann dann auch noch für die einzelnen Filter eigene Popup Meldungen definieren, die dem User dann angezeigt werden, wenn er einen Verbindungsversuch startet, der auf einen Filter passt. Alles in allem ein sehr nützliches Tool, was zudem auch noch Freeware ist und unter Windows Server 2000 und Windows Server 2003 installiert werden kann. Heruntergeladen werden kann es z.B. unter http://www.download25.com/2x-securerdp-for-terminal-services-download.html.

Kuriose Fundstücke

Frank Röder — Fri, 15 Aug 2008 19:19:11 +0000

Ab und zu kommt einen bei der Arbeit auch die eine oder andere kuriose Sache unter. Für eine Demonstration wollte ich die msgina.dll manipulieren.

Dabei bin ich über diesen Dialog gestolpert. Ab und zu scheinen die Entwickler bei Microsoft, einen eigenwilligen Humor zu entwickeln. Damit auch nicht euer Computer "verarmt", spendiert ihm doch einfach mal eine neue Platte oder etwas mehr RAM. Man will ja nicht, dass der eigene Rechner in die ewigen Jagdgründe geht…..

Adam und Eva

Frank Röder — Sat, 26 Jan 2008 12:43:14 +0000

Immer mehr netzwerkfähige Geräte, wie zum Beispiel Scanner oder auch Telefonanlagen, unterstützen das Einlesen der Benutzer per LDAP. Leider kranken diese Geräte oft an der fehlenden Fähigkeit, sich an einem LDAP Server zu authentifizieren oder anderen Dingen. Manchmal steht der Administrator auch vor der Aufgabe, dass beispielsweise eine Telefonanlage von mehreren Firmen genutzt wird und diese per LDAP angebunden werden soll. Welcher Administrator möchte es, dass seine Domänencontroller von einer Telefonanlage dieser Art abgefragt werden? Dadurch hätten ja unter Umständen auch andere Firmen lesenden Zugriff auf das Active Directory Verzeichnis. Genau für diese Art von Einsatzzweck hat Microsoft das Produkt ADAM entwickelt.

ADAM (Active Directory Application Mode) ist eine Art abgespecktes Active Directory, mit dem man genau diese Dinge realisieren kann, ohne dabei sein Netzwerk in Gefahr zu bringen. Microsoft liefert für ADAM auch entsprechende Werkzeuge, damit man auch ohne Programmierkenntnisse zwischen Active Directory und der ADAM Instanz eine Synchronisation durchführen kann. Wie funktioniert aber jetzt das Ganze und was wird als Voraussetzung benötigt? Im einfachsten Fall reicht hier der Einsatz von Windows XP Professional als ADAM Server. Wer möchte, kann auch einen Windows 2003 Server einsetzen. Für diesen Artikel habe ich auf der Active Directory Seite und auf der ADAM Seite einen Windows Server 2003 R2 eingesetzt. Glücklicherweise kann man unter Windows Server 2003 R2 den ADAM Dienst direkt als Windows Komponente installieren.
OK, was muss man tun, um ADAM zu konfigurieren. Als Erstes muss man die Installation über die Windows Komponenten vornehmen.

Nachdem die Installation abgeschlossen ist, findet man unter „Start -> Programme" den neuen Ordner „ADAM". Unterhalb des Ordners findet man eine Option „ADAM-Instanz erstellen". Mit dieser Option wird ADAM letztendlich lauffähig gemacht.

Da in meinem Demonetzwerk noch keine Instanz besteht, muss hier die Option „Eine eindeutige Instanz installieren" ausgewählt werden. Im nächsten Schritt wird jetzt der Instanzenname abgefragt. Da ich in diesem Artikel als Beispiel ein Telefonbuch installieren will, nenne ich meine Instanz kreativerweise „Telefonbuch FAQ-O-MATIC".

Im nächsten Schritt fragt der Assistent nach den Portnummern, auf denen die Instanz arbeiten soll. Wenn es sich bei dem Server, auf dem ADAM installiert wird, um einen Domänencontroller handelt, dann schlägt der Assistent automatisch Ports vor, die nicht von Active Directory belegt werden. Mein Demosystem ist ein einfacher Mitgliedsserver, auf dem kein Active Directory installiert ist. Deshalb werden vom Assistenten die Standardports für LDAP (389) und LDAP/SSL (636) vorgeschlagen.

Nachdem die Ports festgelegt wurden, möchte der Assistent eine Anwendungspartition erstellen. Die Anwendungspartition wird zukünftig die Benutzerobjekte aufnehmen, die die Telefonanlage dann über eine LDAP Suche abfragen kann. Ich übergehe diesen Schritt, um später demonstrieren zu können, wie man eine Partition auf der Kommandozeile anlegt.

Bei der nächsten Frage möchte der Assistent wissen, wo er die ADAM Datenbank ablegen soll. Hier sollte man prüfen, ob der Speicherplatz auf dem Systemlaufwerk noch ausreichend ist. In den seltensten Fällen macht sich ein Verschieben der Datenbanken auf eine andere Partition bzw. ein anderes Laufwerk erforderlich.

Im nächsten Schritt möchte der Assistent wissen, unter welchem Benutzerkonto der Dienst laufen soll. Auch hier kann man den Standardvorschlag bestehen lassen. Das Benutzerkonto „Netzwerkdienst" ist ein eingeschränkter Security Principal, der für diese Aufgabe geeignet ist.

Jetzt muss ein Benutzerkonto angegeben werden, was administrative Rechte über diese Instanz erhält. Der Einfachheit halber lasse ich hier den Domänen-Administrator stehen. Hier könnte man natürlich auch einen anderen „normalen" Benutzer auswählen.

Damit in einer ADAM Instanz überhaupt Objekte erstellt werden können, benötigt man ein Schema, was diese Objekte beschreibt. Auf der nächsten Seite des Assistenten hat man die Möglichkeit, bestimmte LDF Dateien für die Erweiterung des Schemas zu importieren. Wir benötigen diese Dateien nicht, da wir die Erweiterung später vornehmen.

Nachdem der Assistent noch kurz eine Zusammenfassung der Setup Parameter anzeigt, beginnt er anschließend mit der Installation.
Damit Objekte aus der bestehenden Active Directory Umgebung in die ADAM Instanz repliziert werden können, muss als nächstes das Schema erweitert werden. Im Installationsverzeichnis von ADAM befinden sich dafür zwei LDF-Dateien. Zum Einen ist das die Datei „MS-AdamSchemaW2K3.LDF" für das Schema eines Windows 2003 Active Directory und zum Anderen die Datei „MS-AdamSyncMetadata.LDF", die für den Objektabgleich benötigt wird.

Der Import der LDF Dateien wird über das aus Active Directory bekannte Kommandozeilenprogramm „ldifde" realisiert.
ldifde -i -f MS-AdamSyncMetadata.LDF -s localhost -c "cn=configuration,dc=x" #configurationNamingContext

ldifde -i -f MS-AdamSchemaW2K3.LDF -s localhost -t -c "cn=configuration,dc=x" #configurationNamingContext

Somit ist die ADAM Instanz vorbereitet. Was jetzt noch fehlt, ist die Anwendungspartition, die die Userobjekte anschließend aufnehmen soll. Für diese Aufgabe steht das Programm „dsmgmt.exe" zur Verfügung. Das Gleiche geht aber auch mit „ntdsutil".

Jetzt ist ADAM für die erste Synchronisation bereit. Für den Abgleich zwischen Active Directory und ADAM stellt Microsoft das Programm „adamsync" zur Verfügung. Adamsync benötigt eine XML-Konfigurationsdatei, in der alle wichtigen Parameter festgehalten sind. Im Installationsverzeichnis existiert bereits eine Beispieldatei. Diese muss nur noch auf die eigenen Bedürfnisse angepasst werden.

"1.0"?>

 
  FAQ-O-MATIC
  object
  faq-o-matic.net
  dc=faq-o-matic,dc=net
  
  
  dc=faqomatic
  
   <base-dn>dc=faq-o-matic,dc=netbase-dn>
   <object-filter>(&(objectclass=user)(telephoneNumber=*))object-filter>
   
    givenname
    sn
    telephoneNumber
    
   
  
  
   
    2
    600
   
   
  
 
 
  
  
  
  
  
  
  
  string>string>
  
  
  object-update>object-update>

Gehen wir die wichtigsten Elemente der XML Datei einmal durch. Im Element „" wird nur eine Beschreibung festgelegt. Mit Hilfe dieser Beschreibung kann man durch „adamsync /list localhost" die installierten Konfigurationen besser identifizieren. Die Elemente „source-ad-name" und „source-ad-partition" identifizieren die Quelldomäne. Mit „source-ad-name" wird der FQDN der Quelldomäne festgelegt und mit „source-ad-partition" die Active Directory Partition, in der die zu synchronisierenden Objekte gesucht werden. Das Element „" gibt die Zielpartition an, in der die synchronisierten Objekte erstellt werden sollen. Adamsync ermittelt die zu synchronisierenden Objekte über eine LDAP Suche. Für diese Suche werden zwei Dinge benötigt. Als Erstes muss ein „" festgelegt werden. Dieser distinguished Name beschreibt den Ausgangspunkt der LDAP Suche. Danach wird der eigentliche Suchfilter festgelegt. Da wir die ADAM Instanz als Telefonbuch nutzen wollen, werden nur Benutzer synchronisiert, die auch eine Telefonnummer besitzen. Dadurch ergibt sich folgender LDAP Filter:

„(&(objectclass=user)(telephoneNumber=*))"

Das kaufmännische „Und" kann aber nicht in der XML Datei interpretiert werden. Deshalb muss dieses Sonderzeichen in der XML Datei kodiert werden.

„(&(objectclass=user)(telephoneNumber=*))"

Als nächstes kommen wir zu den Attributen, die für unsere Objekte mit repliziert werden sollen. Für ein Telefonbuch muss ja ein Userobjekt nicht mit allen Attributen repliziert werden. Für diesen Anwendungsfall sollte die Angabe von Vorname, Nachname und Telefonnummer ausreichen. Welche Attribute repliziert werden, kann man über das Element „" steuern. Da für den Anwendungsfall „Telefonbuch" nur drei Attribute repliziert werden müssen, habe ich mich dafür entschieden, diese Attribute über „" anzugeben. Wenn die Zahl der zu synchronisierenden Attribute überwiegen sollte und man nur einige wenige von der Synchronisation ausschließen will, dann kann man diese über „" ausschließen. Ein weiterer wichtiger Punkt ist das „". Darüber kann gesteuert werden, was passieren soll, wenn ein Objekt in der Quelle gelöscht wird. Dazu aber an späterer Stelle mehr.

Nachdem alle Einstellungen in der XML Datei vorgenommen wurden, kann diese jetzt installiert werden. Dafür bietet das Tool „adamsync" den Schalter „/install" an.

adamsync /i localhost NAMEDERXMLDATEI.XMLJetzt ist ADAM für die erste Synchronisation bereit.

adamsync /sync localhost dc=faqomatic

Ein Wort zur Performance. In der Active Directory Domäne, die hier als Quelle genutzt wurde, existieren 20.000 Benutzerobjekte. Der erste Synchronisationsvorgang, zwischen Active Directory und ADAM, nahm ca. 2 Minuten und 30 Sekunden in Anspruch. Dabei wurden ca. 68,1 MB an Daten übertragen. Jede weitere Synchronisation wurde innerhalb von 5 Sekunden beendet und es wurden dabei ca. 69 KB übertragen.

Nachdem also die erste Replikation erfolgreich abgelaufen ist, kann man die oben stehende Kommandozeile als geplanten Task einrichten. Dadurch kann ein periodischer Abgleich zwischen Active Directory und ADAM sichergestellt werden. Was passiert aber mit den gelöschten Objekten? Diese bleiben bei der momentanen Konfiguration bestehen. Hier kommt jetzt das Element „" der XML Konfigurationsdatei ins Spiel. Über das Unterelement „" kann bestimmt werden, aller wie viel Sychronisationszyklen eine Überprüfung auf gelöschte Objekte vorgenommen wird. Das Unterelement „" gibt an, wie viele Objekte auf einmal untersucht werden sollen. Wenn wir in unserem Beispiel für „" den Wert „2" setzen und für „" den Wert 500, dann bedeutet dies, dass „adamsync" im schlimmsten Fall 80 Replikationszyklen benötigt, um alle Objekte auf einen eventuellen Löschvorgang zu prüfen. Findet adamsync ein im Active Directory gelöschtes Objekt, dann wird es auch in der Adaminstanz entfernt. Um die Performance hier einmal zu testen, habe ich mit drei verschiedenen Werten in „" gearbeitet.

Wert in	Dauer	Ges. und Empf. Daten
5.000	33 Sekunden	Empfangen: ca. 2MB Gesendet: ca. 1,5MB
10.000	1 Minute 20 Sekunden	Empfangen: ca. 4MB Gesendet: ca. 3MB
20.000	2 Minuten 15 Sekunden	Empfangen: ca. 8MB Gesendet: ca. 6MB

Leider gibt es bei der Synchronisation einen unschönen Nebeneffekt. Adamsync scheint bei der Synchronisation der gelöschten Objekte den LDAP Filter „(&(objectclass=user)(telephoneNumber=*))" zu nutzen. Da bei einem Löschvorgang aber das Attribut „telephoneNumber" vom Objekt entfernt wird, kann adamsync ein gelöschtes Objekt nicht korrekt erkennen. Das kann dazu führen, dass adamsync alle synchronisierten Objekte verwirft und in den Container „LostAndFound" der ADAM Partition verschiebt. Dieser Tatsache kann man aber mit einem kleinen Hack entgegenwirken. Dazu muss man im Active Directory Schema der Quelle eine kleine Anpassung im Attribut „telephoneNumber" vornehmen. Durch das Verändern der Eigenschaft „searchflags" im Attribut „telephoneNumber" kann man verhindern, dass dieses Attribut von einem Objekt entfernt wird. Dazu muss die Eigenschaft „searchflags" des Attributs „telephoneNumber" auf den dezimalen Wert 8 gesetzt werden. Dieser Wert entspricht binär dem vierten Bit.

Dadurch bleibt beim Löschen eines Objekts dieses Attribut am gelöschten Objekt erhalten und adamsync kann eine erfolgreiche Synchronisation durchführen.

Kommen wir jetzt zum letzten Punkt dieses Artikels. Jetzt muss nur noch sichergestellt werden, dass auch mit einer anonymen Anmeldung auf die Informationen im ADAM lesend zugegriffen werden kann. Um das zu ermöglichen, müssen zwei Schritte durchgeführt werden. Als erstes muss der anonymen Anmeldung erlaubt werden, sich ohne Authentifizierung mit der Telefonbuch Partition zu verbinden. Standardmäßig ist das nicht erlaubt. Um es zu ermöglichen, muss das „dsHeuristics" Attribut in den Eigenschaften des Directory Services Objekts der Konfigurationspartition auf den Wert „0000002001000" angepasst werden.

Jetzt kann zumindest schon ein LDAP Bind auf alle Partitionen der ADAM Instanz durchgeführt werden. Dadurch kann aber eine anonyme Anmeldung noch keine Objekte der einzelnen Partitionen lesen. Damit die einzelnen Partitionen auch durchsucht werden können, fügt man im einfachsten Fall das Konto „Anonymous-Anmeldung" in die ADAM Rolle „Readers" der entsprechenden Partition hinzu.

Jetzt können die Userobjekte in der ADAM Partition auch ohne Authentifizierung gelesen werden. Damit wäre es jetzt möglich, diese ADAM Instanz für das Erstellen eines Telefonbuchs zu nutzen.

Störrischer FSRM

Frank Röder — Sat, 19 Jan 2008 14:28:55 +0000

Seit der Einführung von Windows Server 2003 R2 hat der Administrator endlich ein Werkzeug in der Hand, mit dem er sehr schnell und effektiv den Speicherplatzbedarf seiner Netzwerkbenutzer auf den Dateiservern analysieren kann. Durch das Erstellen von Speicherberichten kann der Administrator auf einen Blick erkennen, wie viel Speicherplatz ein Benutzer auf einem bestimmten Laufwerk in Anspruch nimmt. Zusätzlich können die Berichte auch noch eingeschränkt werden. Das heißt, man kann beispielsweise nach Duplikaten suchen oder auch nach Dateien die schon eine längere Zeit nicht mehr benutzt wurden.

Der Ressourcen-Manager für Dateiserver ist also ein rundum nützliches Werkzeug, das in die Werkzeugsammlung eines jeden Administrators gehört. Ein weiterer Vorteil ist die sehr einfache Einrichtung und Konfiguration des Ressourcen-Manager für Dateiserver.

Neulich bei einem Kunden kam das Problem auf, dass der Platz für die Datensicherung nicht mehr ausreichte. Leider kann man bei diesem Kunden nicht mit Kontingenten auf den Laufwerken arbeiten. Die Mitarbeiter nutzen hier sehr große Videodateien und andere Binärdaten, die auch recht schnell auf ein Gigabyte und mehr anwachsen können. Die einzelnen Laufwerke der Server sind mit mehreren Terabyte an Daten gefüllt. Was liegt also näher, als einfach mal einen Speicherreport zu erstellen. Ziel des Speicherberichtes war es, Duplikate dieser Video- und Binärdateien aufzuspüren und dann entsprechend zu löschen. Nach einer kurzen Diskussion hatte ich die Freigabe des dort angestellten Administrators und konnte den Ressourcen-Manager für Dateiserver installieren. Nach der Installation und einem anschließenden Neustart machte ich mich an die Erstellung des Berichtes, und von da an nahm das Unheil seinen Lauf.

Nachdem ich das Laufwerk mit dem größten Datenvolumen identifiziert hatte, wollte ich für dieses Laufwerk einen Speicherbericht erstellen. Nach dem Einrichten und dem Klicken auf „OK“ ereilte mich diese Fehlermeldung:

Für mich kam diese Fehlermeldung genauso unerwartet wie für den Server. OK, was also tun? Der erste Blick ging also in das Ereignisprotokoll, denn das wurde mir ja in der sehr ausführlichen Fehlermeldung vorgeschlagen. Das offenbarte mir dann Folgendes:

Ereignistyp: Fehler
Ereignisquelle: FSRM
Ereigniskategorie: Keine
Ereigniskennung: 0
Datum: 19.01.2008
Zeit: 11:03:27
Benutzer: Nicht zutreffend
Computer: W2K3-SRV1
Beschreibung:
Unerwarteter Fehler beim MMC-Snap-In Ressourcen-Manager für Dateiserver
bei Microsoft.Storage.SrmMmc.ReportTask.SaveChanges(ISrmReportManager reportManager)
bei Microsoft.Storage.SrmMmc.StorageReportTaskPropertySheet.SaveChanges()
bei Microsoft.Storage.SrmMmc.PropertySheet.OnOkButtonClicked(Object sender, EventArgs eventArgs)
Ungültiges Argument: NamespaceRoots[0] = 'E:\'
bei Microsoft.Storage.SrmMmc.ISrmReport.put_NamespaceRoots(Object[] namespaceRoots)
bei Microsoft.Storage.SrmMmc.ReportTask.SaveChanges(ISrmReportManager reportManager)
Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Super! Das Laufwerk „E:\“ ist also ein ungültiges Argument. Warum es ein „ungültiges Argument“ ist, bleibt aber offen. Der Eintrag im Ereignisprotokoll brachte mich also auch keinen Schritt weiter.

Da ging mir kurzzeitig folgendes durch den Kopf: Da steh ich nun, ich armer Tor!
Und bin so klug als wie zuvor. (J.W.v.Goethe / Faust I)

Also hieß es wieder „selbst ist der Administrator“. Im nächsten Schritt habe ich mir gedacht, wenn das System mir nicht das Problem verraten will, dann muss ich selbst suchen. Eine andere Alternative blieb mir auch nicht übrig. Für alle Phänomene, die mit dem Dateisystem auftreten, bietet sich als Werkzeug „Filemon“ an. Mit Filemon kann man alle Zugriffe auf das Dateisystem in Echtzeit verfolgen. Also habe ich die Zugriffe des Ressourcen-Manager für Dateiserver protokolliert. Das Ergebnis sah so aus:

Aha, siehe da, ein „ACCESS DENIED“ für den Prozess „srmhost.exe“. Dieser Prozess ist der Dienst, unter dem der Ressourcen-Manager für Dateiserver läuft. Der Dienst selbst läuft unter dem Benutzerkonto „SYSTEM“. Warum kommt aber hier diese Fehlermeldung? Als Nächstes habe ich mir also die NTFS Berechtigung des Laufwerks angesehen und hier lag auch des Rätsels Lösung:

(Berechtigungen des Laufwerks)

(Standardberechtigungen eines NTFS Laufwerks nach der Formatierung)

Der Administrator vor Ort hatte die NTFS Berechtigungen des Laufwerks verändert und dem Benutzerkonto „SYSTEM“ die Zugriffsrechte auf das Laufwerk entzogen. Dadurch hat der Ressourcen-Manager für Dateiserver natürlich keinen Zugriff auf das Laufwerk.

Was mich an diesem Sachverhalt sehr ärgert, ist nicht das fehlende Benutzerkonto bzw. die fehlenden Berechtigungen, sondern die miserable Fehlerbehandlung innerhalb des Ressourcen-Manager für Dateiserver. Mit einer Fehlermeldung à la „Kein Zugriff auf das Laufwerk E:\“ hätte ich ca. vier Stunden eher im Feierabend sein können. Schade, dass an der Fehlermeldung nicht dieser Button existierte:

http://www.youtube.com/watch?v=1Q_EPUXlyME

Ich hätte nur zu gern davon Gebrauch gemacht …

Keine verwandten Beiträge.

Maulkorb für den OU-Admin

Frank Röder — Sun, 13 Jan 2008 19:41:20 +0000

In vielen Active-Directory-Umgebungen wird die Möglichkeit genutzt, bestimmten Mitarbeitern Berechtigungen auf das Active Directory zu geben. So könnte man zum Beispiel dem Azubi der IT-Abteilung das Recht einräumen, neue Benutzer in Active Directory anzulegen. Dadurch kann der Azubi also keinen Schaden anrichten. Er kann ja nur neue Benutzer anlegen …

Leider bringt man dadurch sein Active Directory auch in Gefahr. Durch dieses Recht könnte eine Person, die entsprechende Berechtigungen besitzt, eine unbegrenzte Anzahl von Objekten anlegen. Das heißt also, sie kann die Datenbank durch unbedarfte Experimente oder mit bösen Absichten bis zum Platzen füllen. Dadurch würde dann ein erhöhtes Replikationsaufkommen zwischen den Domänencontrollern auftreten. Die Folge wären dann erhöhte Replikationslatenzen. Durch diese Latenzen könnte es passieren, dass wichtige Informationen verspätet auf andere Domänencontroller repliziert werden. Ein weiteres mögliches Szenario wäre das Überlaufen der Festplattenpartition, auf der sich die Active Directory Datenbank befindet. Wie einfach so ein Angriff zu realisieren ist, demonstriert folgendes Skript:



set objRootDSE = GetObject("LDAP://rootDSE")

set objOU = GetObject("LDAP://ou=OU-Delegiert," & objRootDSE.Get("defaultNamingContext"))

For i=1 To 1000000

  set objUser = objOU.Create("User","cn=BenutzerNr" & i)

  objUser.Put "sAmAccountName", "BenutzerNr" & i

  objUser.Put  "givenName","Testbenutzer"

  objUser.Put "mail","hallo@hallo.de"

  objUser.Put "telePhoneNumber", "++49 (351) 123454678"

  objUser.Put "sn", "Test"

  objUser.Put "wwwHomePage","www.faq-o-matic.net"

objUser.SetInfo

objUser.AccountDisabled = False

objUser.SetPassword "Geheim$$2008"

objUser.Setinfo

next

Durch dieses Skript werden so ganz nebenbei 1.000.000 Benutzerobjekte angelegt. Diese belasten natürlich unnötigerweise die Active-Directory-Datenbank. Was kann man aber dagegen tun, um solche DoS-Attacken auf das AD zu verhindern?

Seit Windows 2003 gibt es die Möglichkeit, Kontingente auf das Active Directory zu vergeben. Dadurch kann ein Administrator bestimmen, wie viele Objekte ein Benutzer oder auch eine Sicherheitsgruppe im AD anlegen kann.

Wie funktioniert das Ganze aber? Microsoft stellt für die Verwaltung bzw. Einrichtung von Kontingenten leider kein grafisches Verwaltungsprogramm zur Verfügung. Um Kontingente auf eine Verzeichnispartition zu vergeben, muss der Administrator die Kommandozeile bemühen. Wie sieht das nun in der Praxis aus?

Nehmen wir einmal an, dass in der AD-Domäne „faq-o-matic.net“ die OU „OU-Delegiert“ existiert. Auf diese OU hat der Benutzer „Paul Schmidt“ das Recht bekommen, neue Benutzer anzulegen.

Mit dem Kommandozeilenprogramm „dsadd quota“ kann der Administrator dem Benutzer jetzt ein Kontingent einrichten.

dsadd quota -part dc=faq-o-matic,dc=net –acct faq-o-matic\p.schmidt -qlimit 500

Durch dieses Kontingent ist jetzt der Benutzer Paul Schmidt auf das Anlegen von 500 Benutzern beschränkt.
Wie kann man jetzt aber die bereits angelegten Kontingente einsehen? Für diese Aufgabe kann man zum einen das Snapin „Active Directory Benutzer und Computer“ benutzen oder auch die Kommandozeile bemühen.

Um alle Kontingente einzusehen, reicht ein:

dsquery quota

Wer es etwas genauer wissen will, kann die Kommandozeile noch erweitern.

dsquery quota | dsget quota -dn -acct -qlimit

Wenn man jetzt noch einsehen will, wieviel ein Benutzer bereits von seinem Kontingent verbraucht hat, kann man das Kommandozeilenprogramm „dsget“ einsetzen.

dsget partition „dc=faq-o-matic,dc=net“ -topobjowner

Durch dieses Kommando kann man einsehen, wie viele Objekte ein Benutzer oder eine Gruppe in der angegebenen Partition besitzt. Standardmäßig gibt „dsget“ die ersten top zehn Benutzer aus. Man kann hier hinter den Parameter „-topjobowner“ eine Zahl angeben, die beeinflusst, wie viele Benutzer oder Gruppen angezeigt werden. Durch die Angabe von „0“ werden alle Benutzer angezeigt.
Vorsicht! Bei der Angabe von „0“ kann der Domänencontroller stark ausgelastet werden und die Abfrage kann sehr viel Zeit in Anspruch nehmen.

Was ist aber, wenn Paul vorhandene Objekte gelöscht hat? Werden diese Objekte auch in das Kontingent mit einbezogen? Die Antwort für diese Frage lautet „jein“. Wenn der Benutzer Objekte löscht, dann werden diese zu 100% für die Dauer der Tombstone Lifetime auf sein Kontingent angerechnet. In einer einheitlichen Umgebung unter Windows 2003 SP1, die nicht durch ein Update von Windows 2000 bzw. Windows 2003 installiert wurde, beträgt die Tombstone Lifetime 180 Tage. Unser Benutzer muss also für 180 Tage auch mit den gelöschten Objekten leben.
Windows wäre aber nicht Windows, wenn es dort nicht noch eine Möglichkeit gäbe, dieses Problem zu umgehen. Man kann für jede Partition eine globale Einstellung vornehmen, zu wie viel Prozent ein gelöschtes Objekt in die Kontingentberechnung eingeht. Diese Festlegung kann über die Kommandozeile getroffen werden:

dsmod partition "dc=faq-o-matic,dc=net" -qtmbstnwt 10

ACHTUNG! Der Parameter „-qtmbstnwt“ ist in der Hilfe von „dsmod partition“ falsch dargestellt. Dort steht als erforderlicher Parameter „-qtmbstawt“. Dieser Eintrag ist falsch!

Was heißt das nun in der Praxis:

In der obigen Kommandozeile haben wir also den Prozentsatz für die gelöschten Objekte in der Domänenpartition auf 10 Prozent festgelegt. Wenn unser Nutzer Paul ein Kontingent von 350 Objekten hat, dann kann er 3500 gelöschte Objekte besitzen, bevor sein Kontingent erschöpft ist.

Jetzt kommt natürlich der Test, ob unser oben angelegtes Kontingent auch Wirkung zeigt. Paul wird jetzt das Skript auf unser AD loslassen und damit den Versuch starten, unser AD lahm zu legen. Kurz nachdem Paul das Skript ausgeführt hat, schmettert ihm das Active Directory eine Fehlermeldung entgegen.

Pauls Kontingent wurde erschöpft und er kann keine weiteren Objekte im Active Directory anlegen. Dadurch wurde Pauls Angriff auf das AD verhindert.

Mehrere Kennwortrichtlinien in einer Domäne

Frank Röder — Mon, 21 May 2007 13:57:00 +0000

Endlich ist es soweit! Unterschiedliche Kennwortrichtlinien können innerhalb einer Domäne definiert werden. Microsoft hat die Administratoren erhört und führt mit Windows Server 2008 ("Longhorn") die Möglichkeit ein, unterschiedliche Kennwortrichtlinien innerhalb einer Domäne zu definieren. Wer jetzt hier erwartet, dass er das bequem über die MMC "Active Directory-Benutzer und -Computer" festlegen kann, wird leider enttäuscht. Hier wird wieder Handarbeit nötig.

Um die Kennwortrichtlinien technisch zu realisieren, hat Microsoft zwei neue Klassen im AD definiert. Um diese Klassen bzw. die eigentliche Funktion nutzen zu können, muss sich die Domäne im Funktionslevel "Windows Server 2008" befinden. Die Klasse "ms-DS-Password-Settings-Container" ist dafür zuständig, neue Kennwortrichtlinien aufzunehmen.
Das eigentliche Objekt dafür wird automatisch während der Installation von Active Directory in der Domänenpartition eingerichtet. Die Klasse "ms-DS-Password-Settings" stellt die eigentlichen Kennwortrichtlinien dar. Diese Richtlinien müssen innerhalb des Containers "Password Settings Container" angelegt werden. Finden kann man diesen Container unter folgendem Distinguished Name:

"CN=Password Settings Container,CN=System,DC=testdom,DC=de"

Wer jetzt denkt, dass er die angelegten Richtlinien mit einer Organisationseinheit verknüpfen kann, ist leider auf dem Holzweg. Die Kennwortrichtlinien lassen sich nur mit Benutzerobjekten, InetOrgPerson-Objekten und globalen Sicherheitsgruppen verknüpfen. Dies muss aber kein Nachteil sein, denn man kann dadurch Mitglieder einer administrativen Gruppe zwingen, wesentlich sicherere Kennwörter zu nutzen als die normalen Benutzer, die sich in der gleichen Organisationseinheit befinden.

Jetzt könnte es durch diesen Sachverhalt passieren, dass durch direkte oder indirekte Gruppenmitgliedschaften der Benutzer mit mehreren Kennwortrichtlinien verknüpft ist. Um die effektive Richtlinie zu ermitteln, nutzt der Windows-Server-2008-Domänencontroller das Attribut "ms-DS-Password-Settings-Precedence" der Klasse "ms-DS-Password-Settings". Dieses Attribut kann mit einem beliebigen Integer-Wert gefüllt werden. Als Mindestwert ist hier "1" vorgegeben. Die Kennwortrichtlinie mit dem niedrigsten Wert im Attribut "ms-DS-Password-Settings-Precedence" hat die höchste Priorität und setzt alle anderen Richtlinien außer Kraft. Sollte es passieren, dass zwei Richtlinien die gleiche Priorität besitzen, dann wird die Richtlinie gezogen, die die kleinste GUID hat. Dieser Vorgang ist natürlich nicht sonderlich transparent. Deshalb empfiehlt Microsoft, für jede Kennwortrichtlinie eine eindeutige Priorität zu vergeben.

Ablaufdarstellung der Kennwortrichtlinienauswertung

Zum Anlegen einer eigenen Richtlinie ist im Container "Password Settings Container" ein neues "msDS-Password-Settings" Objekt zu erstellen.

Als Erstes gibt man dem Objekt einen CN. In meinem Beispiel habe ich den Namen "Policy-Restricted" gewählt.

Im nächsten Schritt werden alle verbindlichen Attribute des Objekts abgefragt.

msDS-PasswordSettingsPrecedence = Kennwortrichtlinienpriorität
msDS-PasswordReversibleEncryptionEnabled = Kennwort mit umkehrbarer Verschlüsselung speichern
msDS-PasswordHistoryLength = Kennwortchronik erzwingen
msDS-PasswordComplexityEnabled = Kennwort muss Komplexitätsvoraussetzungen entsprechen
msDS-MinimumPasswordLength = Minimale Kennwortlänge
msDS-MinimumPasswordAge = Minimales Kennwortalter
msDS-MaximumPasswordAge = Maximales Kennwortalter
msDS-LockoutThreshold = Kontensperrschwelle
msDS-LockoutObservationWindow = Zurücksetzungsdauer des Kontosperrungszählers
msDS-LockoutDuration = Kontosperrdauer

Bei allen Attributen, die mit Zeitwerten zu tun haben, muss der Administrator etwas Rechenarbeit leisten. Diese Zeitwerte werden als ein Vielfaches von -100 Nanosekunden dargestellt. Dadurch wird zum Beispiel das minimale Kennwortalter von einem Tag folgendermaßen errechnet:

-24*60*60*(10ˆ7) = -864000000000

Ich habe für meine Testrichtlinie folgende Werte festgelegt:

msDS-MinimumPasswordAge = -864000000000 = 1 Tag
msDS-MaximumPasswordAge = -17280000000000 = 20 Tage
msDS-LockoutObservationWindow = -36000000000 = 1 Stunde
msDS-LockoutDuration = -72000000000 = 2 Stunden

Im nächsten Schritt muss diese Richtlinie einem Benutzer oder einer Gruppe zugewiesen werden. Ich habe mich in diesem Beispiel für eine Gruppe entschieden. Dadurch habe ich die Möglichkeit, durch die Mitgliedschaft in dieser Gruppe die Kennwortrichtlinien zu steuern, die sich auf ihre Mitglieder auswirken. Jede definierte Richtlinie besitzt ein Attribut mit dem Namen "msDS-PsoAppliesTo". Dieses Attribut ist ein multivalued Attribut, das also mehrere Werte aufnehmen kann. Als Wert müssen hier die Distinguished Names der einzelnen globalen Gruppen oder Benutzer hinterlegt werden, auf die sich diese Richtlinie auswirken soll.

In meiner Testumgebung habe ich eine Organisationseinheit mit dem Namen "Password-Policies" unterhalb der Domäne angelegt. In dieser Organisationseinheit befindet sich eine globale Gruppe "Pass-Test". Mit dieser Gruppe möchte ich meine Kennwortrichtlinie verknüpfen.

Ich fülle also das Attribut "msDS-PsoAppliesTo" meiner Kennwortrichtlinie mit dem Distinguished Name meiner globalen Gruppe.

CN=Pass-Test,OU=Password-Policies,DC=testdom,DC=de

Zusätzlich befindet sich in meiner Organisationseinheit ein Benutzer "Frank Röder". Diesen Benutzer mache ich zum Mitglied der Gruppe "Pass-Test". Dadurch wirken sich jetzt die Einstellungen meiner Richtlinie auf diesen Benutzer aus.
Überprüfen kann man die effektive Richtlinie natürlich auch. In der MMC "Active Directory Benutzer und Computer" befindet sich in den Eigenschaften eines Benutzerobjekts eine Registerkarte "Attribute Editor". Darüber kann man alle Attribute eines Benutzerobjekts einsehen. Für uns ist hier das Attribut "msDS-ResultantPSO" interessant. Dieses Attribut wird mit dem distinguished Name der effektiven Kennwortrichtlinie aufgefüllt.

ACHTUNG! Bei diesem Attribut handelt es sich um ein "constructed Attribute", das bedeutet, es wird zur Laufzeit erstellt und kann nicht in LDAP-Suchfiltern verwendet werden. Man kann also keine Suche starten à la "Gib mir bitte alle Benutzer zurück, auf die sich Richtlinie "xyz" auswirkt."

Standardkennwort bei Benutzern prüfen

Frank Röder — Tue, 23 Jan 2007 18:14:00 +0000

Manchmal werden Benutzer durch eine Migration, beim Neuanlegen oder auch beim Zurücksetzen des Kennwortes mit einem Standardkennwort versehen. Ab und zu wird dann vergessen, bei der erstmaligen Anmeldung von einem Benutzer an der Domäne einen Kennwortwechsel zu erzwingen. Leider ist es nicht möglich, die Kennwörter der Benutzer aus dem Active Directory direkt auszulesen, da diese nur als Hashwert in der Active-Directory-Datenbank abgelegt sind. Mit einem kleinen Trick kann man aber mehrere Benutzerobjekte prüfen, ob diese ein bekanntes Standardkennwort noch verwenden.

Um dieses Ziel zu erreichen, haben Nils Kaczenski und ich ein kleines VB-Script geschrieben, das diesen Job übernimmt. Das Skript liest in einer bestimmten OU alle Benutzerkonten aus und verwendet von diesen den SamAccountName (Prä-Windows-2000-Anmeldename) plus das Standardkennwort, um ein Netzlaufwerk auf einem Fileserver zu mappen. Wenn dieses Netzlaufwerkmapping gelingt, dann kann man davon ausgehen, dass dieses Benutzerkonto noch das Standardkennwort verwendet. Sollte ein Fehler dabei auftreten, dann verwendet dieses Konto kein Standardkennwort mehr.

Alle Benutzerkonten, unter denen das Netzlaufwerkmapping funktioniert, werden in einer Textdatei protokolliert. Wichtig ist noch, dass der Fileserver, auf dem die Testfreigabe erstellt wurde, um das Netzlaufwerk zu mappen, kein DC ist (dieser würde nicht mehrere Verbindungen unter verschiedenen Benutzerkontexten gleichzeitig vom selben Rechner zulassen), sondern ein Memberserver oder im einfachsten Falle eine Workstation.

Das Skript wird folgendermaßen in der CMD aufgerufen:
cscript check_standard_password.vbs

Das Skript hier einfach per Copy&Paste in eine Textdatei einfügen und als „check_standard_password.vbs“ abspeichern.

   1: '=================================================================

   2: '

   3: '

   4: ' NAME: check_standard_password

   5: '

   6: ' AUTHOR: Nils Kaczenski, Frank Röder

   7: ' DATE  : 17.01.2007

   8: '

   9: ' COMMENT: Teamarbeit;-)

  10: '

  11: '=================================================================

  12: 'Hier die einzelnen Variablen definieren

  13: 'DN der OU, die durchsucht werden soll

  14: strDN = "" 'Beispiel "OU=TestOU,OU=oberOU,DC=test,DC=de"

  15: 'Pfad zum Logfile, in dem die User mit Standardkennwort eingetragen werden

  16: sollen

  17: strLogPath = "" 'Beispiel "c:\logfile.txt"

  18: 'UNC-Pfad, der zum Test gemappt werden soll

  19: strTestUNC = "" 'Beipiel "\\testserver\testshare"

  20: 'Wie sieht das Standardkennwort aus?

  21: strPass = "" 'Beispiel "Standardkennw0rt"

  22: 'AB HIER NICHTS MEHR VERÄNDERN!

  23: '===========================================================================

24:

  25: Set objOU = GetObject ("LDAP://" & strDN)

  26: objOU.Filter = Array("User")

  27: Set objNet = CreateObject ("WScript.Network")

  28: Set objFso = CreateObject("Scripting.FileSystemObject")

  29: Set objTs = objFso.OpenTextFile(strLogPath, 2, True)

  30: objTs.WriteLine Now

  31: objTs.writeline("Folgende Benutzer verwenden noch " _

  32:     & "das initiale Kennwort:")

  33: Set WshShell = WScript.CreateObject("WScript.Shell")

  34: On Error Resume Next

  35: For Each user In objOU

  36:     ' Usernamen ausgeben

  37:     WScript.Echo user.Name

  38:     ' Test: Laufwerk verbinden

  39:     objNet.MapNetworkDrive "X:", strTestUNC, _

  40:         , user.SamAccountName, strPass

  41:     ' Fehler aufgetreten?

  42:     If Err.Number = 0 Then

  43:         ' Nein, User protokollieren

  44:         objTs.writeline(user.Samaccountname)

  45:     Else

  46:         ' Ja, Fehler anzeigen

  47:         WScript.Echo "Fehler " & Err.number _

  48:             & " (" & Err.Description & ") " _

  49:             & "bei User: " & user.Name

  50:         Err.Clear

  51:     End If

  52:     objNet.RemoveNetworkDrive "X:"

  53: Next

Was ist ABE?

Frank Röder — Tue, 31 Oct 2006 18:14:00 +0000

Bis jetzt musste man als Windows-Admin damit leben, dass Benutzer, die auf einem Fileserver arbeiten, stellenweise Ordner in Freigaben gesehen haben, auf die sie eigentlich keinen Zugriff hatten. Dies ließ sich bis jetzt nur gekonnt umschiffen, wenn man die Ordner nur nach den Sicherheitseinstellungen gruppiert hat. Seit dem Service Pack 1 für Windows Server 2003 ist es nun möglich, die ABE (Acces-based Enumeration) zu nutzen, um Objekte, auf die keine Zugriffsberechtigung besteht, für die Nutzer auszublenden.

ACHTUNG: Die Freigabe selbst wird nicht ausgeblendet, auch wenn der Benutzer keine Zugriffsrechte hat. Lediglich der Inhalt einer Freigabe wird ausgeblendet, auf den keine Zugriffsrechte bestehen.

Was benötigt man dafür:

Windows 2003 Server SP1
Download ABE

Der Download für ABE ist ca. 800 KB groß. Nachdem man es heruntergeladen und installiert hat, ist man sofort einsatzbereit. In den Eigenschaften des freigegebenen Ordners findet man jetzt eine neue Registerkarte "Access Based Enumeration", mit der man das Feature aktivieren kann. Microsoft sagt, das sich dieses Feature nicht negativ auf die Performance des Fileservers auswirkt.

Weitere Informationen findet ihr auch bei Microsoft in TechNet.

Einige hochwertige Drittanbieter-Systeme haben ABE übrigens ebenfalls integriert. Das trifft beispielsweise auf die Storage-Systeme (Filer) von Network Appliance zu, die seit der Betriebssystemversion Data ONTAP 7.2 (Herbst 2006) das ABE-Feature unterstützen.

Wie kann ich eine SMS von der Kommandozeile versenden?

Frank Röder — Tue, 31 Oct 2006 07:17:00 +0000

Wenn auf einem Server Ausfälle eintreten oder vielleicht auch einmal der Strom ausfällt, dann will man als gewissenhafter Administrator natürlich sofort informiert werden. Eine Benachrichtigung per E-Mail ist aber eher unzuverlässig, denn wenn der Strom weg ist, dann ist natürlich auch der Router aus, der die Internetverbindung herstellt. Viele Monitoring-Programme, die die Netzwerkkomponenten, Server und Internetverbindungen überwachen, bieten die Möglichkeit, bei bestimmten Ereignissen vom Administrator erstellte Skripte aufzurufen.

Was liegt da näher, als solche dringenden Nachrichten direkt per SMS auf ein Handy zuzustellen. Grundsätzlich ist der Versand von SMS Nachrichten über ein an dem Com-Port angeschlossenes Handy über AT-Befehle möglich. Diese könnte man mit dem Hyperterminal an das Handy senden. Leider lässt sich aber das Hyperterminal nicht automatisieren. Durch Zufall bin ich auf die Webseite www.smslib.org aufmerksam geworden.

Der Autor Thanasis Delenikas hat dort eine Library veröffentlicht, mit der man unter .NET 2.0 SMS versenden kann. Ich habe diese Library genutzt und eine kleine C# Konsolenanwendung erstellt, die es ermöglicht, SMS von der Kommandozeile aus zu versenden. Nach der Installation kann man diese Anwendung folgendermaßen aus einer Batchdatei aufrufen:

cmdsms.exe -Comport COM1 -Baudrate 57600 -Nummer +491722344321 -Message "EineNachricht mit max. 160 Zeichen"

Der Parameter "-Comport" gibt den COM-Port an, an dem das Handy angeschlossen ist. Über den Parameter "-Baudrate" wird die Baudrate für die Kommunikation mit dem Handy festgelegt. Über den Parameter "-Nummer" wird die Empfängernummer festgelegt. Bitte hier versuchen, das internationale Format zu nutzen. Mit dem Parameter "-Message" wird die Nachricht festgelegt. Die Länge der Nachricht ist auf 160 Zeichen beschränkt. Sollte die Zeichenanzahl überschritten werden, dann schneidet "cmdsms.exe" alle weiteren Zeichen ab.

Das Tool kann hier heruntergeladen werden:

Note: There is a file embedded within this post, please visit this post to download the file.

ACHTUNG! Ich übernehme keinerlei Garantie für die korrekte Funktionsweise des Tools und kann natürlich auch keinerlei Support leisten. Sie können dieses Tool frei einsetzen und auch weiterverbreiten.

Vorraussetzungen:
.Net 2.0 Framework
Ein an einem COM-Port angeschlossenes Handy (bzw. ein GSM-Modem)

faq-o-matic.net » Frank Röder

AD Snapshots „Deluxe“

Verwandte Beiträge:

RDP absichern – aber wie?

Verwandte Beiträge:

Kuriose Fundstücke

Verwandte Beiträge:

Adam und Eva

Verwandte Beiträge:

Störrischer FSRM

Maulkorb für den OU-Admin

Verwandte Beiträge:

Mehrere Kennwortrichtlinien in einer Domäne

Verwandte Beiträge:

Standardkennwort bei Benutzern prüfen

Verwandte Beiträge:

Was ist ABE?

Verwandte Beiträge:

Wie kann ich eine SMS von der Kommandozeile versenden?

Verwandte Beiträge: