Attribute für AD User : userAccountControl
Das Active Directory Attribut userAccountControl beinhaltet eine Reihe von Flags, die wichtige Grundeigenschaften eines Benutzerobjektes festlegen und mit denen der Status des betreffenden User Accounts abgefragt oder verändert werden kann.
userAccountControl
LDAP Name | userAccountControl |
Datentyp | Integer (DWORD - 4 Bytes) |
Multivalue (Array) | Nein |
System Flags | 0x12 |
Search Flags | 0x19 |
Im Global Catalog? | Ja |
Attribute ID | 1.2.840.113556.1.4.8 |
AD DB Attributname | User-Account-Control |
ADSI datatype | 7 - Integer |
LDAP syntax | 1.3.6.1.4.1.1466.115.121.1.27 - Integer |
Wird verwendet in ... | > W2K |
Schema Doku | Microsoft - MSDN |
Neben der reinen Spezifikation des Attributes in der Schema-Dokumentation gibt es noch diese zwei wichtigen Dokumente über die Bedeutung der verschiedenen userAccountControl Flags:
MSDN: Open Specifications - [MS-SAMR] - 3.1.1.8.10 - userAccountControl
Hier die einzelnen Flags mit anschließender Erläuterung:
Flag-Wert (Binär) | (Dezimal) | |
0000000000000000000000000000000x | 1 | Reserviert, muß stets auf 0 gesetzt werden |
00000000000000000000000000000010 | 2 | UF_ACCOUNT_DISABLE |
00000000000000000000000000000x00 | 4 | Reserviert, muß stets auf 0 gesetzt werden |
00000000000000000000000000001000 | 8 | UF_HOMEDIR_REQUIRED |
00000000000000000000000000010000 | 16 | UF_LOCKOUT |
00000000000000000000000000100000 | 32 | UF_PASSWD_NOTREQD |
00000000000000000000000001000000 | 64 | UF_PASSWD_CANT_CHANGE |
00000000000000000000000010000000 | 128 | UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED |
00000000000000000000000x00000000 | 256 | Reserviert, muß stets auf 0 gesetzt werden |
00000000000000000000001000000000 | 512 | UF_NORMAL_ACCOUNT |
000000000000000000000x0000000000 | 1024 | Reserviert, muß stets auf 0 gesetzt werden |
00000000000000000000100000000000 | 2048 | UF_INTERDOMAIN_TRUST_ACCOUNT |
00000000000000000001000000000000 | 4096 | UF_WORKSTATION_TRUST_ACCOUNT |
00000000000000000010000000000000 | 8192 | UF_SERVER_TRUST_ACCOUNT |
00000000000000000x00000000000000 | 16384 | Reserviert, muß stets auf 0 gesetzt werden |
0000000000000000x000000000000000 | 32768 | Reserviert, muß stets auf 0 gesetzt werden |
00000000000000010000000000000000 | 65536 | UF_DONT_EXPIRE_PASSWD |
00000000000000100000000000000000 | 131072 | UF_MNS_LOGON_ACCOUNT |
00000000000001000000000000000000 | 262144 | UF_SMARTCARD_REQUIRED |
00000000000010000000000000000000 | 524288 | UF_TRUSTED_FOR_DELEGATION |
00000000000100000000000000000000 | 1048576 | UF_NOT_DELEGATED |
00000000001000000000000000000000 | 2097152 | UF_USE_DES_KEY_ONLY |
00000000010000000000000000000000 | 4194304 | UF_DONT_REQUIRE_PREAUTH |
00000000100000000000000000000000 | 8388608 | UF_PASSWORD_EXPIRED |
00000001000000000000000000000000 | 16777216 | UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION |
00000010000000000000000000000000 | 33554432 | UF_NO_AUTH_DATA_REQUIRED |
00000100000000000000000000000000 | 67108864 | UF_PARTIAL_SECRETS_ACCOUNT |
0000x000000000000000000000000000 | 134217728 | Reserviert, muß stets auf 0 gesetzt werden |
000x0000000000000000000000000000 | 268435456 | Reserviert, muß stets auf 0 gesetzt werden |
00x00000000000000000000000000000 | 536870912 | Reserviert, muß stets auf 0 gesetzt werden |
0x000000000000000000000000000000 | 1073741824 | Reserviert, muß stets auf 0 gesetzt werden |
x0000000000000000000000000000000 | 2147483648 | Reserviert, muß stets auf 0 gesetzt werden |
Wenn mehrere Flags für einen bestimmten Account gesetzt sind, dann werden einfach die Dezimalwerte dieser Flags addiert und ergeben somit den Wert von userAccountControl. Beispiele:
Normaler Benutzer | ||
00000000000000000000001000000000 | 512 | UF_NORMAL_ACCOUNT |
Summe | 512 |
Deaktivierter Benutzer | ||
00000000000000000000000000000010 | 2 | UF_ACCOUNT_DISABLE |
00000000000000000000001000000000 | 512 | UF_NORMAL_ACCOUNT |
Summe | 514 |
Benutzer, dessen Passwort nicht abläuft | ||
00000000000000000000001000000000 | 512 | UF_NORMAL_ACCOUNT |
00000000000000010000000000000000 | 65536 | UF_DONT_EXPIRE_PASSWD |
Summe | 66048 |
Um Bits im Attribut userAccountControl zu setzen oder zu löschen, kann man so vorgehen:
UF_ACCOUNT_DISABLE ( 2 )
Falls dieses userAccountControl Bit gesetzt ist, ist der betreffende Benutzer Account deaktiviert (disabled) und kann sich nicht mehr an der Domäne anmelden.
Bitte nicht verwechseln mit dem Intruder Lockout Mechanismus, bei dem ein Benutzer gesperrt ist wenn er zu oft in zu kurzer Zeit sein Passwort falsch eingibt.
Wenn man einen deaktivierten Benutzer mit dem Löschen des
UF_ACOUNT_DISABLE Flags aktivieren will, so wird dies nur gelingen, wenn sein Passwort den geltenden Passwortrichtlinien entspricht. Wenn in Ihrer Umgebung leere Passwörter verboten sind, der deaktivierte Benutzer kein Passwort hat (weil er z.B. gerade erst erzeugt wurde), so läßt er sich nicht aktivieren: Es kommt zu einem Laufzeitfehler (-2147016651 : LDAP_UNWILLING_TO_PERFORM). Kann ein Benutzer in solchen Fällen trotz leerem Kennwort doch aktiviert werden, ist vielleicht das userAccountControl Flag UF_DONT_EXPIRE_PASSWD gesetzt...
UF_HOMEDIR_REQUIRED ( 8 )
Falls dieses userAccountControl Bit gesetzt ist, muß der Benutzer über die Verzeichniseigenschaft "Benutzerlaufwerk" verfügen => das LDAP Attribut homeDirectory muß vorhanden sein. So weit die Theorie. In der Praxis kann diese Bit jedoch auch gesetzt werden, ohne dass das System einen Fehler zurückgibt, selbst wenn für den betreffenden Benutzer kein Benutzerlaufwerk konfiguriert wurde.
UF_LOCKOUT ( 16 )
Vorsicht: Diese Bit reagiert nicht in der erwarteten Weise!
Dieses userAccountControl Bit soll eigentlich anzeigen, dass der Benutzer durch den Intruder Lockout Mechanismus gesperrt ist (diese Sperre kann nur durch das System selbst ausgelöst werden). Es handelt sich hier jedoch um ein Überbleibsel aus der Windows NT Zeit. Für Active Directory Benutzer ist diese Bit auch bei gesperrten Benutzern NIE gesetzt - wenn Sie wissen wollen, ob ein Account gesperrt ist, so verwenden Sie am besten das Attribut lockoutTime:
Gesperrte Benutzer kann man mit folgendem LDAP-Filter suchen:
Ist man gerade mit einem User-Objekt
über LDAP verbunden, so kann man auch das Attribut msDS-User-Account-Control-Computed untersuchen. Dieses gibt im Unterschied zu userAccountControl im UF_LOCKOUT Bit tatsächlich wieder ob ein Account ausgesperrt ist. Es ist jedoch ein Constructed Attribut, so dass es leider nicht in LDAP Suchvorgängen als Filter benutzt werden kann.
UF_PASSWD_NOTREQD ( 32 )
Ist dieses userAccountControl Bit gesetzt, unterliegt der Benutzer nicht einer vielleicht vorhandenen Richtlinie bezüglich der Passwort-Länge. Er kann also ein kürzeres Passwort haben als es eigentlich vorgeschrieben ist, oder er kann sogar kein Passwort haben, auch wenn leere Passwörter verboten sind. Diese Eigenschaft ist in den normalen GUI-Tools (Active Directory Users and Copmputers) nicht sichtbar!
UF_PASSWD_CANT_CHANGE ( 64 )
Vorsicht: Diese Bit reagiert nicht in der erwarteten Weise!
Dieses userAccountControl Bit soll eigentlich anzeigen, dass das Passwort für den betreffenden Account durch den Account selbst nicht geändert werden kann. Dennoch passiert nichts dergleichen, wenn man das Bit setzt (Es wird allerdings auch kein Fehler zurückgegeben... lediglich der Wert des Bits bleibt unverändert). Wollen Sie wirklich dafür sorgen, dass das Passwort nicht mehr geändert werden darf, so müssen sie das erweiterte Recht "Change Passwort" für den Benutzer selbst und jeden anderen verweigern.
In der Rechteliste ist diese Verweigerung auch für den Eintrag "SELF" gesetzt. Wenn man die Berechtigungen aus einem Batch heraus ändern will, so kann man dies mit zwei DSACLS-KOmmandos erreichen:
REM Password Change verhindern
DSACLS "cn=PhilippFoeckeler,dc=selfadsi,dc=org" /D Everyone:CA;"Change Password"
REM Password Change erlauben
DSACLS "cn=PhilippFoeckeler,dc=selfadsi,dc=org" /G Everyone:CA;"Change Password"
DSACLS "cn=PhilippFoeckeler,dc=selfadsi,dc=org" /G SELF:CA;"Change Password"
Übrigens: Ein Passwort zu ändern ("change") ist nicht das Gleiche wie ein Passwort zurückzusetzen
("reset"). Ein Administrator kann im besagten Fall natürlich immer noch einen Passwort-Reset durchführen.
UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED ( 128 )
Ist dieses Bit gesetzt, dann wird für diesen Benutzer das Passwort zwar verschlüsselt, aber in reversibler Form im Verzeichnis gespeichert. Wie der Ausdruck reversible schon andeudet: Im Prinzip könnte man auch sagen, dass mit dieser Einstellung das Passwort des Benutzers mit den entsprechenden Berechtigungen ausgelesen werden kann (=> Security-Lücke!!).
Man braucht das UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED Flag, wenn eine Applikation die Passwörter der Benutzer kennen muß, um diese zu authentifizieren. Dies ist z.B. der Fall, wenn man im RAS (Remote Access) die alte CHAP-Autnetication verwenden will/muß, oder wenn man in einer im Active Directory eingebetteten IIS-Umgebung die Digest Authentication verwenden will.
Normalerweise werden Passwörter nur als nicht umkehrbare Hashwerte in der AD Datenbank gespeichert. Man sollte diese Option also NIE benutzen, wenn es nicht unbedingt sein muß.
UF_NORMAL_ACCOUNT ( 512 )
Dieses Bit zeigt an, dass es sich um einen normalen Benutzer-Account handelt. Dies von anderen Account-Arten zu unterscheiden ist notwendig, da nicht nur USer-Objekte ein userAccountControl Attribut haben, sondern auch Computer-Objekte und andere, die Domänencontroller oder Trust-Beziehungen repräsentieren.
UF_INTERDOMAIN_TRUST_ACCOUNT ( 2048 )
Dieses userAccountControl Bit zeigt an, dass es sich um einen Account handelt, der eine Trust-Verbindung zu einer externen Domäne repräsentiert. Normalerweise ist der Name des Account der NetBIOS-Name der betreffenden Domäne mit einem "$" am Ende. Bei einem Benutzer sollte dieses Flag nie gesetzt sein.
UF_WORKSTATION_TRUST_ACCOUNT ( 4096 )
Dieses userAccountControl Bit zeigt an, dass es sich um einen Maschinen-Account eines normalen Rechners oder Memberserver der Domäne handelt. Bei einem Benutzer sollte dieses Flag nie gesetzt sein.
UF_SERVER_TRUST_ACCOUNT ( 8192 )
Dieses Bit zeigt an, dass es sich um einen Domänen-Controller Account handelt. Bei einem Benutzer sollte dieses Flag nie gesetzt sein.
UF_DONT_EXPIRE_PASSWD ( 65536 )
Ist dieses userAccountControl Bit gesetzt, unterliegt der Benutzer nicht einer vielleicht vorhandenen Richtlinie bezüglich einer erzwungenen Passwort-Änderung: Sein Passwort läuft nie ab.
UF_MNS_LOGON_ACCOUNT ( 131072 )
Dieses Bit zeigt an, dass es sich um einen Majority Node Set (MNS) Account handelt, derartige Account werden für den Betrieb von Clusterknoten ab Windows Server 2003 benötigt, bei denen die Quorum-Daten auf keinem Shared Medium Laufwerk liegen. Bei einem Benutzer sollte dieses Flag nie gesetzt sein.
UF_SMARTCARD_REQUIRED ( 262144 )
Dieses Bit zeigt an, dass für den betreffenden Account lediglich ein Smartcard-Logon für die interaktive Anmeldung an der domäne erlaubt ist. Andere Authentifizierungsmechanismen sind nicht zugelassen. Ist diese Flag gesetzt, so läuft das Passwort des Accounts nie ab (er gibt ja kein Passwort ein, sondern verwendet die Smartcard...).
UF_TRUSTED_FOR_DELEGATION ( 524288 )
Dieses userAccountControl Bit zeigt an, dass es sich um einen Account handelt, der für Windows-Dienste verwendet werden kann - und zwar in der Art, dass der Dienst zeitweise die Identität eines Users annimmt, der den Dienst gerade in Anspruch nimmt. Dies ist z.B. der Fall, wenn der Server-Dienst auf der lokalen Platte genau die gleichen Rechte hat wie der Benutzer, der gerade auf ein freigegebenes Netzwerklaufwerk zugreift. Man nennt diesen Vorgang auch Impersonation.
UF_NOT_DELEGATED ( 1048576 )
Dieses Bit zeigt an, dass es sich um einen Account handelt, bei dem ein Dienst NIE die Identität annehmen darf (sozusagen der umgekehrte Fall zum UF_TRUSTED_FOR_DELEGATION Bit).
UF_USE_DES_KEY_ONLY ( 2097152 )
Diese Bit zeigt an, dass bei der Kerberos-Authentisierung des betreffenden Accounts NUR der Algorithmus DES (Data Encryption Standard) für die Generierung von Tickets verwendet werden darf. Dies sollte nur bei Accounts gesetzt werden, die sich nicht von Windows aus in der Domäne anmelden wollen (unter Windows stehen stets mindestens DES und RC4 zur Verfügung).
Eigentlich sollte dies insgesamt keine große Rolle mehr spielen, denn auch DES wird heutzutage nicht mehr als der beste Algorithmus angesehen. Seit Vista und Windows Server 2008 steht auch der viel modernere AES (Advanced Encryption Standard) Algorithmus für die Kerberos-Authentisierung an einem Domänencontroller zur Verfügung. Zur Signalisierung, welche Algorithmen bei der anmeldung eines bestimmten Accounts unterstützt werden sollen, steht mittlerweile das modernere Attribut msDS-SupportedEncryptionTypes zur Verfügung. Dieses regelt die Verständigung zwischen Client und Domänencontroller bezüglich der Verschlüsselungsalgorithmen.
UF_DONT_REQUIRE_PREAUTH ( 4194304 )
Diese Bit zeigt an, dass bei der Kerberos-Authentisierung des betreffenden Accounts keine so genannte Pre-Authentication durchgeführt werden muß. Dies ist nur für ältere Kerberos-client notwendig, die sich von fremden Systemen in der Domäne anmelden müssen und keine Kerberos Pre-Authentication beherrschen. Für Accounts, die sich unter Windows anmelden, oder eben für Maschinen-Accounts von Windows-Domänenrechnern soll dieses Flag NIE gesetzt werden, denn die Pre-Authentication verhindert bestimmte Formen von Dictionary Angriffe auf die Kerberos Anmeldung.
UF_PASSWORD_EXPIRED ( 8388608 )
Vorsicht: Diese Bit reagiert nicht in der erwarteten Weise!
Will man wirklich wissen, ob das Passwort eines Account abgelaufen ist, kann man auch das Attribut msDS-User-Account-Control-Computed untersuchen, dieses gibt im Unterschied zu userAccountControl im UF_LOCKOUT Bit tatsächlich wieder ob das Passwort des Accounts tatsächlich abgelaufen ist. Es ist jedoch ein Constructed Attribut, so dass es leider nicht in LDAP Suchvorgängen als Filter benutzt werden kann.
Wenn man das Ablaufen eines Passwortes ertwingen will, so setzt man das Benutzer-Attribut pwdLastSet auf -1.
Komplizierter wird es, wenn man wissen will, wann genau ein Passwort ablaufen wird. Man muß dies selbst errechnen aus dem maxPwdAge-Attribut der Domäne und dem pwdLastSet-Attribut des Accounts. Es handelt sich dabei um Microsoft Integer8-Werte, die etwas Aufwand beim Handling erfordern. Unter Windows 2008
ist ein neues LDAP Attribut dazugekommen, das einem die Berechnung erspart: msDS-UserPasswordExpiryTimeComputed. Auch diese ist ein Constructed Attiribut, so dass es leider nicht in LDAP Suchvorgängen als Filter benutzt werden kann. Vorsicht auch bei eigenen Berechnungen in AD-Umgebungen ab Windows Server 2008: Es könnten hier noch Einstellungen aus den so genannten Fine Grained PAssword Policies eine Rolle spielen.
UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION ( 16777216 )
Diese Bit zeigt an, dass der Benutzer ein Kerberos-Ticket im Namen eines anderen Benutzers anfordern darf. Dies ist in seltenen Fällen für Service-Accounts notwendig, die so genannte S4U2 Self Service Tickets vom Domänen-Controller benötigen. Dies beinhaltet die komplette Verschleierung der Identität und geht weit über die normale Impersonation hinaus, die bei Diensten manchmal eine Rolle spielt. Deswegen sollte diese Flag nur gesetzt sein wenn dies wirklich notwendig ist.
UF_NO_AUTH_DATA_REQUIRED ( 33554432 )
Diese Bit zeigt an, dass der betreffende Account im Kerberos-Anmeldeprozess ein Ticket ausgestellt bekommt, in dem die so genannten Privilege Attribute Certificate (PAC) Daten nicht enthalten sind. Die PAC-Datenstruktur ist eine Microsoft-spezifische Kerberos-Erweiterung und enthält Informationen über die Security ID des Benutzers und der Gruppen, in der er enthalten ist. Dieses Bit ist nur dann von Bedeutung, wenn sich der betreffende Account von einer fremden Nicht-Windows-Maschine in der Domäne anmeldet und dabei PAC nicht unterstützt.
UF_PARTIAL_SECRETS_ACCOUNT ( 67108864 )
Diese Bit zeigt an, dass es sich um einen ReadOnly Domänen-Controller Account handelt. Bei diesen Maschinen-Accounts ist stets auch das Flag UF_WORKSTATION_TRUST_ACCOUNT gesetzt. Bei einem Benutzer sollte dieses Flag nie gesetzt sein.