How many of you get appropriate notice from managers and HR when a new employee
arrives or terminates service? That many? You're lucky. The best of companies
are realizing they have a lot at stake in the period of time between employee
termination and the disabling of that employee's accounts and system access.
Rudely, they're spending more on researching how to quickly sever the employee
from the company data than they are in figuring out how to get that employee
up and running on the first day. It's sad but necessary, too. Consider how long
it takes to get data, to tamper with it or to divulge it to competitors. It
doesn't take long.
But if you're like most of us, there may be a significant period between employee
termination and the notification you receive. In some cases, IT staff may never
be notified. Yet, if those machine and user accounts are left active, the chance
of exploitation increases dramatically. You're not going to meet your data security
obligation in this environment and you do need to communicate constantly to
HR the importance of being on the notification list. Until then, you've still
the responsibility of managing the network with the best knowledge you can gather
about employee and system account status.
There are some things unique about computer accounts in an NT domain. Amongst
those things is the default password policy on the computer accounts. Did you
know that NT Domain member computers will contact the domain and negotiate a
password change every 7 days? It's a handy thing to know. That knowledge can
be used to identify machine accounts that should be removed from the domain.
Again, scripting is your friend for this job. Knowledge of WSH and ADSI are
getting more and more critical as you try to keep your systems in shape.
This month, we'll keep a promise we made in the last installment. We'll identify
every machine that hasn't changed its password in the last 90 days and make
the assumption that this machine is no longer in service (and this IS an assumption
unless you can prove the system is no longer around). Further, we'll work on
deleting the domain accounts for those systems with such aged credentials.
Const ForReading = 1, ForWriting = 2, ForAppending = 8
On Error Resume Next
strCurPath= Left(strScriptPath, _
If Right(strCurPath,1)<>"\" Then strCurPath=strCurPath
LogFile=strCurPath & _
Set objFSO = CreateObject("scripting.FileSystemObject")
set f = objFSO.OpenTextFile(LogFile, ForAppending, True, -2)
LogAction "Report Generated: " & Now() & vbNewLine
On Error Resume Next
Set Domain=GetObject("WinNT://" & strDomain)
For Each Member in Domain
& "/" & Member.Name & _
returned in seconds since changed
for 90 days. These are the only one's we'll log
> 7776000 Then
Member.Name & ", " & strDays & _
"Deleted account for " & Member.Name
Note that you may merely want to get a list of those old accounts before deleting
them. In that eventuality, comment out the "Call strDomain.Delete"
line in the CompAccounts subroutine and the LogAction line that follows it.
You'll notice that the CompAccounts routine also has an unusual bit of math
in it. Well, the math is normal but the numbers are pretty wild. The values
for the password age are in seconds since the change. 90 days = 60 seconds/minute
* 60 minutes/hour * 24 hours/day * 90 days=7776000 seconds.
To run the script, copy/paste the code to a text file and call it OldCompAccts.vbs.
Modify the strDomainName variable with the name of your NT Domain and call it
from the command line as such:
The script above will create a log file in the same directory with the script
called "ExpiredDomainComputerAccounts.log". In the file will be listed
every machine account which hasn't changed its password on the domain in the
specified last 90 days. Left unmodified, the script will also delete the machine's
account from the domain.
So far, we've treated the basics of administering Windows networks based primarily
on the characteristics of the domain's computers. It makes sense that we would
because these are the sorts of things administrators are expected to do but
aren't expected to take a great deal of time to perform. Since you'll be doing
this sort of thing over and over again and none of us are paid to continue doing
our jobs in inefficient ways, it should be obvious that automating these jobs
is a natural requirement.
As you examine the logs produced by our scripts, you may also be starting to
understand that we have been doing exactly the things that the Unix folks have
wished we would for so long. We're managing our network (although just scratching
the surface), we're adding 'depth' to the native shell, we're doing these things
remotely and we're producing an audit trail, logs of our actions and attempted
actions to describe the state of the domain at any given time. And by following
those practices, we're addressing basic security concerns by learning and controlling
exactly what systems have access to domain resources.
Oh, but there's more
to come later.