Results for category "Windows"

42 Articles

Gruppenrichtlinien

Ich möchte hier mal ganz kurz auf zwei Seiten hinweisen, die ganz brauchbare Informationen zum Thema Active Directory und Exchange haben.
Zum einen behandelt http://www.gruppenrichtlinien.de/ -wie die URL schon sagt- das Thema Gruppenrichtlinien & Active Directory. Zum anderen muss einfach http://www.msxfaq.de/ erwähnt werden. Die Seite ist bei Exchange-Problemen die erste Anlaufstelle.

Fehler "Es steht nicht genügend Serverspeicher zur Verfügung"

Der zweite Fehler, der am Wochenende beim Zugriff auf freigegebene Ordner auftrat war “Es steht nicht genügend Serverspeicher zur Verfügung”.

Google brachte die Lösung: In der Registry muss der Schlüssel HKLMSystemCurrentControlSetServicesLANManServerParametersIRPStackSize (DWORD) höher gesetzt werden. Standard ist Dezimal 11, kann aber ohne Probleme auf 50 gestellt werden – was auch das Maximum ist.
Sollte der Schlüssel nicht existieren, muss er hinzugefügt werden.

Nach dem Ändern des Keys muss der Dienst “Server” neu gestartet werden, bzw. muss sich der ggw. angemeldete Benutzer neu anmelden.

Fehler "Zugriff verweigert" beim Öffnen eines freigegebenen Ordners in der Netzwerkumgebung

Einer der Fehler, den ich am Wochenende auf der LAN bekam, war folgender:

Sie haben eventuell keine Berechtigung diese Netwerkressource zu verwenden. Wenden sie sich an den Administrator des Servers um herauszufinden, ob Sie über Berechtigung verfügen.
Zugriff verweigert.

Der Fehler trat auf, als ich auf einen freigegebenen Ordner in der Netzwerkumgebung zugreifen wollte. Beide Rechner (Client + Server) waren Windows XP-Maschinen. Das Gast-Konto war aktiviert und die Lese-Berechtigung für die Freigabe war auch ok.

Nach längerem Forschen fand ich des Rätsels Lösung:
Unter Systemsteuerung > Verwaltung > Lokale Sicherheitsrichtlinie > Lokale Richtlinien > Zuweisen von Benutzerrechten müssen zwei Einträge geändert werden:

In Auf diesen Computer vom Netzwerk aus zugreifen muss explizit der Benutzer “Gast” aufgenommen werden.

Wobei hingegen bei Zugriff vom Netzwerk auf diesen Computer verweigern der Eintrag “Gast” entfernt werden muss.

Wie man sich mit Hilfe von Apache Trac mit dem Active Directory verbindet

Nach langer Überlegungsphase habe ich heute endlich mal den Schritt gewagt und Trac mit dem Active Directory verbunden. Alle Benutzer, die sich an Trac anmelden, werden im AD authentiziert und autorisiert.

Allerdings benutze ich dafür nicht LdapPlugin , sondern AccountManagerPlugin (AMP).

AMP ruft, nachdem Benutzername und Passwort in der Trac-Seite eingegeben worden, eine beliebig definierbare Adresse auf und überprüft, ob der Webserver einen 200er- oder 401er-Statuscode zurückgibt. Das komplette Plugin ist nicht mehr als 30 Zeilen lang.

Zuerst muss AMP installiert werden, danach müssen in der trac.ini des Projekts folgende Optionen gesetzt werden:


[components]
trac.web.auth.LoginModule = disabled
acct_mgr.http.HttpAuthStore = enabled
acct_mgr.web_ui.LoginModule = enabled
acct_mgr.web_ui.RegistrationModule = disabled
acct_mgr.htfile.HtPasswdStore = disabled
acct_mgr.admin.AccountManagerAdminPage = enabled
acct_mgr.web_ui.AccountModule = enabled

[account-manager]
authentication_url = $HOST$/$SUBURL$
password_store = HttpAuthStore

$URL$ wird durch die URL ersetzt, die vom Apache überprüft werden soll.

Die httpd.conf (oder $VHOST$.conf) muss so abgeändert werden:

# Benötigte Module laden
LoadModule auth_module modules/mod_auth.so
LoadModule ldap_module modules/util_ldap.so
LoadModule auth_ldap_module modules/mod_auth_ldap.so

SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracEnvParentDir c:/server/trac
PythonOption TracUriRoot /trac

AuthType Basic
AuthName "Trac Active Directory"
AuthLDAPURL "ldap://domaincontroller.domain.local:389/OU=$OU$,DC=$DOMAIN$,DC=local?sAMAccountName?sub?(objectClass=user)"
AuthLDAPBindDN "$LDAP-BENUTZER$@$DOMAIN$.local"
AuthLDAPBindPassword "$PASSWORT$"
authldapauthoritative Off
require group CN=Trac-Gruppe,DC=$DOMAIN$,DC=local

Der obige Code stammt aus einem unserer Virtual-Hosts und muss natürlich entsprechend eurer Umgebung angepasst werden.

Wichtig ist, dass $SUBURL$ auf eine bestehende Datei im DocumentRoot liegt, diese kann leer sein. Außerdem darf die Trac-Instanz nicht direkt über “/” zu erreichen sein, da sonst die $SUBURL$ durch den Python-Handler verwaltet wird.

Das obige Beispiel benutzt kein SSL. $DOMAIN$ muss durch die Domäne ersetzt werden, $LDAP-BENUTZER$ entspricht einem Benutzer, der im Active Directory existiert und $PASSWORT$ entspricht … naja dem Passwort halt.

Das Binden ist nötig, da Windows (2003) von Haus aus keine anonymen Zugriffe erlaubt.

Nun muss im Active Directory eine neue Sicherheitsgruppe mit dem Namen “Trac-Gruppe” erstellt werden, in der die erlaubten Benutzer eingetragen werden.

Das war es eigentlich auch schon.

Zur Fehleranalyse ist es sinnvoll, im Apache den LogLevel auf “debug” zu setzen und zu schauen, dass der Apache sich auch wirklich mit dem Active Directory verbinden kann, d.h. die Binding-Credentials in Ordnung sind.

Native Win32 Ports of some GNU utilities

Ich bin so eben über das Projekt unxutils gestolpert: Im Gegensatz zu Cygwin werden die Programme nativ (also nur in Abhängigkeit der msvcrt.dll) ausgeführt.
Unter anderem sind tail, find und grep implementiert. Eigentlich so die wichtigsten Sachen. Ich werde das morgen mal bei mir auf meiner Workstation ausprobieren und wenn es so funktioniert, wie ich mir erhoffe, wirds auch auf allen Servern im Netz deployt.

Creddump: Python-Script zum Dumpen von Windows Security Principals

Brendan Dolan hat das Tool creddump releast: Es extrahiert aus der Windows-Registry die LSA-Secrets und gecachten Domain-Accounts OHNE das Windows läuft.
Unter http://code.google.com/p/creddump/ lässt es sich downloaden-

Warum ich das schreibe? Ich habe das PHP-Script zum Extrahieren des Windows-XP-CD-Keys von PHP auf Perl portiert und würde es gerne als Python-Script zur Verfügung stellen. So könnte creddump main restore_cd_key beinhalten und ließe sich auf einer der nächsten SystemRescueCD-Releases veröffentlichen.
Mal abwarten…

PropertyPage-Extension für MMC "Active Directory Benutzer und Computer" in C#

Ausgangspunkt dieses Artikels war ein Gespräch vor ein paar Tagen: “Wäre schön, wenn wir jedem unserer Mitarbeiter eine Mitarbeiter-Nummer im ActiveDirectory vergeben könnten.”
Ich googelte im Internet und fand diesen Artikel auf InformIT.
Er erklärt recht gut, wie man die Mitarbeiter-Nummer in das passende MMC “Active Directory Benutzer und Computer” einbindet.

Allerdings war ich von der Darstellung nicht sonderlich begeistert: Ich wollte in den Eigenschaften der Mitarbeiter ein eigenes Tab haben. Zuerst suchte ich bei Microsoft und fand einige Dokumente auf den MSDN-Seiten. Allerdings hatte ich kein Nerv auf C++ und entschied mich, MMC 3.0 und .NET bzw. C# zu verwenden.

Mit der Installation des .NET Frameworks 3.5 sollte das MMC-Assembly mitinstalliert werden. Danach suchte ich mir im Internet ein paar Code-Schnippsel zusammen:
Auf einer französische Seite fand ich den Code zum rudimentären Erzeugen einer PropertyPage. Für die Benutzung des Codes muss das MMC-Assembly von C:WINDOWSsystem32microsoft.managementconsole.dll eingebunden werden.
Mir stellte sich nun die Frage: Wie komme ich an den ausgewählten Benutzer heran?
Die Newsgroup microsoft.public.management.mmc war hilfreich. Ich hatte nun den LDAP-DN des ausgewählten Benutzers. Der Rest war trivial: Mit System.DirectoryServices stellte ich eine Verbindung zum Active Directory her und zog mir die Daten des Benutzers:

DirectoryEntry oUser = new DirectoryEntry(_searchDSN);
String employeeNumber = oUser.Properties["employeeNumber"].Value.ToString();

und konnte mit oUser.CommitChanges() meine Änderungen zurück ins AD schreiben.

Mit Hilfe des Tools InstallUtil lässt sich das erstellte Assembly in der Registry verankern und benutzen.

Erweiterung des ActiveDirectory Schemas

Wir planen bereits seit längerer Zeit unser ActiveDirectory um eigene Attribute zu erweitern.
Unter http://www.informit.com/articles/article.aspx?p=169630&seqNum=1 gibt es dazu eine leicht verdauliche Anleitung. Ich wusste vorher gar nicht, dass neu erstellte Attribute automatisch im Kontextmenü des Active Directory-MMC erscheinen.

Neben dieser einfachen Möglichkeit des Hinzufügens von Kontext-Einträgen, gibt es auch die Möglichkeit, eigene Property Sheets zu erstellen.
Wenn man sich z.B. die Eigenschaften eines Objekts im Active Directory-MMC anzeigen lässt, kann man dort sein eigenes Property Sheet hinzufügen. Ist leider nicht ganz so trivial: Microsoft beschreibt dies in seiner Doku. Zuerst muss ein Node Type in der Registry registriert werden. Dieser Node Type bezieht sich auf eine AD-Objektklasse (z.B. Benutzer).
Danach muss ein “Property Sheet Extension Snap-In” erstellt werden. Dieses COM-Objekt muss das Interface IExtendPropertySheet implementieren. Sobald dies geschehen ist, sollte es funktionieren 😉

SQL Server: Stored Procedures per SOAP veröffentlichen / Zugriff aufs ActiveDirectory

Für die kommende Umstellung in unserem Firmen-Netzwerk habe ich heute morgen mal recherchiert.
Mit Hilfe des SQL Server (2005) lassen sich einige nette Sachen realisieren. Man kann z.B. über ein ADSDSOObject den Domänencontroller ansprechen und somit auf das Active Directory zugreifen. Der Artikel von Brendan Tompkins beschreibt das recht gut.

Weiterhin lassen sich HTTP Endpoints definieren. Das bedeutet, dass der SQL Server ohne installiertem IIS in der Lage ist, Stored Procedures automatisch als SOAP-Methoden inklusive passendem WSDL zu veröffentlichen. Ahmed Mosa hat dies in seinem Blog sehr gut erklärt.