Vista - check all Active Directory users for default password

Hi,
Our Help Desk has up until recently being stupidly creating all new user
accounts with the same default password and NOT setting the flag to force a
password change at first logon.

Does anyone have a scriptlet that checks an AD user's password ?

I want to run the script against all AD users to check which ones have the
default
password.

Regards
Michael

"RIMikeG" <RIMikeG@xxxxxx> wrote in message
news:54885FE4-D6AA-4D26-8314-4C7A8480F37E@xxxxxxThe first question is this: are you responsible for the help desk staff, or
are you one of the people wanting to exploit their poor practices?

The second question is this: if you were looking for an exploit, would you
have said that that was your purpose?

If there is an actual concern that some accounts may be ineffectively
protected, I would suggest setting all accounts to force a password change
at the next logon. You could check the password change dates, but it sounds
as if your HD people are unlikely to have logged the password resets, so
that will be of little use.

/Al

Al,
If I was a hacker I wouldn't have to ask how to do this. Your assumption of
ill-intent is therefore a little negative.

I'm a project manager tasked with addressing the failures of our employee
provisioning and termination processes. Having just disabled 600 user
accounts of people no longer with the organisation because of failures of our
HR, Payroll and Helpdesk functions I'm now trying to fix the 'new starter'
process - and that includes the security isssue created by the Helpdesk
giving the same default password to new accounts.

I'm NOT after a password cracking utility here - just something that can
check whether accounts still have the ONE default password. I can then tack
on the bit of code from Microsoft's script centre to force a password change.

If you are not interested in helping please don't reply.

Regards
Michael Green





"Al Dunbar" wrote:

Michael wrote:
One way to check if the password value matches the default is to attempt to
change it (using the ChangePassword method of the user object which requires
that you provide the existing password), but that is unacceptable. The only
other method I can think of is to attempt to bind to an object using
alternate credentials. For example:
===========
Const ADS_SECURE_AUTHENTICATION = &H1

strUser = "MyDomain\TestUser"
strUser = "cn=TestUser,ou=West,dc=MyDomain,dc=com"
strPassword = "zyx123q"

Set objNS = GetObject("LDAP:")
On Error Resume Next
Set objDomain = objNS.OpenDSObject("LDAP://dc=MyDomain,dc=com", strUser,
strPassword, ADS_SECURE_AUTHENTICATION)
If (Err.Number = 0) Then
On Error GoTo 0
Wscript.Echo "User " & strUser & " has default password"
Else
On Error GoTo 0
Wscript.Echo "User " & strUser & " is OK"
End If
========
The user name can be in either of the forms shown above. To runs similar
code against every user in the domain will be slow, but you could use ADO to
retrieve all user DN's. For example (not tested):
========
Option Explicit

Dim adoCommand, adoConnection, strBase, strFilter, strAttributes
Dim objRootDSE, strDNSDomain, strQuery, adoRecordset
Dim strUser, strPassword, objNS, strUser, strPassword, objDomain

Const ADS_SECURE_AUTHENTICATION = &H1

Set objNS = GetObject("LDAP:")

' Specify the default password to be checked.
strPassword = "password"

' Setup ADO objects.
Set adoCommand = CreateObject("ADODB.Command")
Set adoConnection = CreateObject("ADODB.Connection")
adoConnection.Provider = "ADsDSOObject"
adoConnection.Open "Active Directory Provider"
adoCommand.ActiveConnection = adoConnection

' Search entire Active Directory domain.
Set objRootDSE = GetObject("LDAP://RootDSE")
strDNSDomain = objRootDSE.Get("defaultNamingContext")
strBase = "<LDAP://" & strDNSDomain & ">"

' Filter on user objects.
strFilter = "(&(objectCategory=person)(objectClass=user))"

' Comma delimited list of attribute values to retrieve.
strAttributes = "distinguishedName"

' Construct the LDAP syntax query.
strQuery = strBase & ";" & strFilter & ";" & strAttributes & ";subtree"
adoCommand.CommandText = strQuery
adoCommand.Properties("Page Size") = 100
adoCommand.Properties("Timeout") = 30
adoCommand.Properties("Cache Results") = False

' Run the query.
Set adoRecordset = adoCommand.Execute

' Enumerate the resulting recordset.
Do Until adoRecordset.EOF
' Retrieve user DN.
strUser = adoRecordset.Fields("distinguishedName").Value
' Attempt to bind to domain object with alternate credentials.
' Trap the error if the attempt fails.
On Error Resume Next
Set objDomain = objNS.OpenDSObject("LDAP://" & strDNSDomain, _
strUser, strPassword, ADS_SECURE_AUTHENTICATION)
If (Err.Number = 0) Then
On Error GoTo 0
Wscript.Echo "User " & strUser & " has default password"
End If
On Error GoTo 0
' Move to the next record in the recordset.
adoRecordset.MoveNext
Loop

' Clean up.
adoRecordset.Close
adoConnection.Close
========
This script should be run at a command prompt with the cscript host. It will
echo the DN of all users with the default password as specified in the
script. You could redirect the output to a text file. This could take
awhile, as it must bind to every user object in the domain. You could
restrict the program to one OU by specifying the AdsPath of the OU as the
base of the query (the value of the variable strBase). You could then expire
the password for the users found to still be using the default.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

"RIMikeG" <RIMikeG@xxxxxx> wrote in message
news:7D5C58E1-26E5-45C5-8924-FD1791B85826@xxxxxxTrue enough - if you were a *professional* hacker. But I have encountered
people looking for ways to diddle their company's IT security setup - just
to show themselves they could do it.
I did not assume ill-intent, I merely assumed that I did not know your
intent. The phrase "...stupidly creating..." made you sound more like an
amateur hacker than a project manager. Had you given more of a narrative
such as below, it would have been clearer.
I did give a suggestion that, although perhaps somewhat extreme (expiring
all passwords), would have demonstrated that the company takes password
security seriously.

Back the the "stupidly creating" issue: were the account admins doing that
perhaps because the written policy regarding such procedures is somewhat
vague? My organization suffers from that syndrome too, where we assume that
professional administrators will intrinsically know and follow best
practice. While some do, that is a potentially very dangerous assumption to
make.
Here's a question: are you absolutely sure that your administrators,
recognizing the danger of a common default password, have never used their
own default password and then neglected to force a reset at first logon? If
some of them did that, then the approach you are taking will leave some
accounts with a password created and known by an admin that has not been
changed by the user. Hence my earlier suggestion to force all passwords to
be changed on the next logon.
On the contrary, this is an area of interest and concern to me. IMHO, in
addition to specifying all related steps of procedures such as resetting
user passwords, I would strongly recommend implementing them in a scripted
solution.

Because our organization is also vague on the specifics, I know a number of
admins at other sites who often use a common default, whether the day of the
week, the username, "secret", "wordpass", or the like. Knowing I would
repeat myself and being too lazy to enter a user password twice, I wrote a
script that is implemented as a taskpad icon. It generates and sets a random
password that meets our complexity requirements and displays it in a memo to
the user that I then print and give to the user. The script also enables the
account if disabled. The memo has a sign-off section where they indicate how
they received the memo (was it still sealed in an envelope, for example) and
whether or not they were able to set a new password (either because they
just have trouble with our complexity policy, or because someone else has
already logged in and changed the password). If I do not get the sign-off
sheet back in a week or so, I follow up to make sure that the right person
is using the account.

/Al