Sicherheitslücke : Leeres Passwort im Active Directory trotz aktiver Kennwortrichtlinie
Wir hatten im laufe der Woche festgestellt, dass einige Konten im Active Directory aktiv waren und ein leeres Passwort enhielten. Dieses ist normalerweise bei einer sicheren Kennwortrichtlinie nicht möglich, dachte ich bisher.
Index
„UserAccountControl“ – Attribute
Der Grund dafür liegt am Attribut „UserAccountControl“ wie ich feststellen musste.
An diesem Attribut kann das Flag „PASSWD_NOTREQD“ gesetzt sein. Wenn dieses Flag gesetzt ist, so kann ein Domänen Administrator an der Passwortpolicy vorbei ein leeres Passwort für den Account vergeben. Der Benutzer selber kann dieses jedoch nicht vornehmen.
Man kann im Active Directory nach solchen Accounts suchen, welche dieses Flag gesetzt haben.
Der folgende LDAP Filter sucht nach Accounts, welche aktiv sind, ein leeres Passwort haben und das Flag „PASSWD_NOTREQD“ gesetzt haben.
|
1 |
(&(objectClass=user)(objectCategory=person)(userAccountControl=544)(pwdLastSet=0)) |
Bei Accounts mit gesetzten Flag „PASSWD_NOTREQD“ hat das Attribut „UserAccountControl“ der Wert 544. Der Standardwert des Attributes „UserAccountControl“ beim anlegen eines Accounts ist 512. Das Flag „PASSWD_NOTREQD“ erhöht diesen Wert um 32 auf 544.
Warum wurde das Flag PASSWD_NOTREQD gesetzt?
Das „PASSWD_NOTREQD“ Flag kann gesetzt werden durch
- eine Migration von NT4
- die Verwendung von IADsContainer.Create, IADs.Put oder IADs.SetInf
- das Anlegen von Benutzern über ADSIEDIT.MSC
In dem folgenden Link wird beschrieben, wie man das Attribut „UserAccountControl“ entsprechend von diesem Flag „befreien“ kann. https://technet.microsoft.com/en-us/library/ee617249.aspx
|
1 2 3 4 |
$usersWithNoPwdRequired = Get-ADUser -LDAPFilter "(&(objectClass=user)(objectCategory=person)(userAccountControl:1.2.840.113556.1.4.803:=544))" foreach($user in $usersWithNoPwdRequired ){ Set-ADAccountControl $user -PasswordNotRequired $false } |
Eine Beschreibung des Attributes „UserAccountControl“ findet man unter folgendem Link.
https://support.microsoft.com/kb/305144.
2 Comments
Leave your reply.