Inhaltsverzeichnis > Attribute für Active Directory 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-ADTS] - 2.2.15 - userAccountControl Bits
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:
Const ADS_UF_ACCOUNT_DISABLE = 2Const ADS_UF_HOMEDIR_REQUIRED = 8Const ADS_UF_LOCKOUT = 16Const ADS_UF_PASSWD_NOTREQD = 32Const ADS_UF_PASSWD_CANT_CHANGE = 64Const ADS_UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED = 128Const ADS_UF_NORMAL_ACCOUNT = 512Const ADS_UF_INTERDOMAIN_TRUST_ACCOUNT = 2048Const ADS_UF_WORKSTATION_TRUST_ACCOUNT = 4096Const ADS_UF_SERVER_TRUST_ACCOUNT = 8192Const ADS_UF_DONT_EXPIRE_PASSWD = 65536Const ADS_UF_MNS_LOGON_ACCOUNT = 131072Const ADS_UF_SMARTCARD_REQUIRED = 262144Const ADS_UF_TRUSTED_FOR_DELEGATION = 524288Const ADS_UF_NOT_DELEGATED = 1048576Const ADS_UF_USE_DES_KEY_ONLY = 2097152Const ADS_UF_DONT_REQUIRE_PREAUTH = 4194304Const ADS_UF_PASSWORD_EXPIRED = 8388608Const ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION = 16777216Const ADS_UF_NO_AUTH_DATA_REQUIRED = 33554432Const ADS_UF_PARTIAL_SECRETS_ACCOUNT = 67108864Set obj = GetObject("LDAP://cn=philipp,cn=users,dc=cerrotorre,dc=de")'Der Benutzer wird deaktiviert (Flag Bit setzen):obj.userAccountControl = obj.userAccountControl or ADS_UF_ACCOUNT_DISABLEobj.SetInfo'Der Benutzer wird aktiviert (Flag Bit löschen):obj.userAccountControl = obj.userAccountControl xor ADS_UF_ACCOUNT_DISABLEobj.SetInfo
Download Script
Wenn man Benutzer mit bestimmten userAccountControl Eigenschaften sucht (über eine LDAP Suche), dann benötigt man spezielle LDAP-Filter, um die Suche auf diejenigen einzuschränken, die in diesem Wert bestimmte Bits gesetzt oder nicht gesetzt haben:
Const ADS_UF_ACCOUNT_DISABLE = 2Const ADS_UF_PASSWD_NOTREQD = 32Const ADS_UF_DONT_EXPIRE_PASSWD = 65536'Alle Accounts, die deaktiviert sind:' => ADS_UF_ACCOUNT_DISABLE = 2' => ldapFilter = "(userAccountControl:1.2.840.113556.1.4.803:=2)"'Alle Accounts, die nicht deaktiviert sind:' => ADS_UF_ACCOUNT_DISABLE = 2' => ldapFilter = "(!(userAccountControl:1.2.840.113556.1.4.803:=2))"'Alle Accounts, die kein Passwort benötigen ODER deren Passwort nie abläuft:' => ADS_UF_PASSWD_NOTREQD And ADS_UF_DONT_EXPIRE_PASSWD = 32 + 65536 = 65568' => ldapFilter = "(userAccountControl:1.2.840.113556.1.4.804:=65568)"'Alle Accounts, die deaktiviert sind UND die kein Passwort benötigen:' => ADS_UF_PASSWD_NOTREQD And ADS_UF_ACCOUNT_DISABLE = 32 + 2 = 34' => ldapFilter = "(userAccountControl:1.2.840.113556.1.4.803:=34)"
Download Script
< nach oben
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...
< nach oben
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.
< nach oben
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:
'Entsperren eines Benutzers:Set user = GetObject("LDAP://cn=sandra,ou=user,dc=cerrotorre,dc=de")user.lockoutTime = 0 user.SetInfo
Download Script
Gesperrte Benutzer kann man mit folgendem LDAP-Filter suchen:
'Alle Accounts, die gesperrt sind:' => ldapFilter = "(&(objectClass=user)(lockoutTime>=0))"
Download Script
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.
< nach oben
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!
< nach oben
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.
< nach oben
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ß.
< nach oben
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.
< nach oben
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.
< nach oben
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.
< nach oben
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.
< nach oben
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.
< nach oben
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.
< nach oben
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...).
< nach oben
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.
< nach oben
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).
< nach oben
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.
< nach oben
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.
< nach oben
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.
< nach oben
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.
< nach oben
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.
< nach oben
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.
< nach oben
< zurück zur Attribut-Liste
< zurück zu SelfADSI Startseite
